Creating tempfile takes too long: GNAT or Windows bug?

Creating tempfile takes too long: GNAT or Windows bug?

[Mário Amado Alves]

Hi all.

Creating a temporary file (see test code below) is taking the
unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my
laptop. Has someone had this sort of problem?

On Linux (same compiler version), in another machine, it takes a
reasonable time: 0.0004 seconds.

On Linux the compiler warns:

"/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adalib/libgnat.a(a-adaint.o):
In function `__gnat_tmp_name':
a-adaint.o(.text+0x504): the use of `tmpnam' is dangerous, better use
`mkstemp'"

which sounds like something related to the issue--but there is no
issue on Linux.

On Windows it does not emit this warning--but the problem manifests
itself! Painfully!

Thanks a lot,
--MAA

---------------
-- test code --
---------------

with Ada.Direct_IO;
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Calendar; use Ada.Calendar;

procedure Test_File is

  package Character_IO is new Ada.Direct_IO (Character);
  use Character_IO;
  Tempfile : Character_IO.File_Type;
  T_Start, T_End : Time;
      
begin

  T_Start := Clock;
  Create (File => Tempfile, Mode => Inout_File);
  T_End := Clock;
  Put_Line ("Tempfile took" & Duration'Image (T_End - T_Start) & "
seconds to create!");
  
end;

Re: Creating tempfile takes too long: GNAT or Windows bug?

[BREHMER Philippe,]

M�rio Amado Alves a �crit :
> 
> Hi all.
> 
> Creating a temporary file (see test code below) is taking the
> unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my
> laptop. Has someone had this sort of problem?
> 
> On Linux (same compiler version), in another machine, it takes a
> reasonable time: 0.0004 seconds.
> 

On windows 98 (with GNAT 3.14p), the result is :

Tempfile took 0.014593775seconds to create!

Re: Creating tempfile takes too long: GNAT or Windows bug?

[tmoran]

>unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my laptop.
  Your program runs in 0.000987276 seconds on my laptop with XP.
Could that 30 seconds be waiting for a timeout on trying to access a
LAN or some such thing?

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Warren W. Gay VE3WWG]

M�rio Amado Alves wrote:
> Hi all.
> 
> Creating a temporary file (see test code below) is taking the
> unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my
> laptop. Has someone had this sort of problem?

I believe this problem has been discussed before in
this group. Perform a Google search, and you might
get additional information on this.

Another possibility is that your temp directory has 100's, if
not 1000's of leftover temp files in it. I experienced this
problem with my family's Win98 system because one piece of
software creates a temp file everytime it runs (I havn't
determined which it is), but fails to clean them up (ain't
commercial software wonderful?)  I ended up creating a
simple C program that periodically cleans out any of these
that are n days old. This improved the general performance
of all applications affected, _significantly_.  There were
literally, several 1000 of temp files, mostly empty. This
causes extremely long directory searches.

But I seem to recall there was another reason for the
performance penalty as well. Search Google.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> commercial software wonderful?)  I ended up creating a
> simple C program that periodically cleans out any of these

Why not Ada?

> that are n days old. This improved the general performance
> of all applications affected, _significantly_.  There were

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Pascal Obry]

maa@liacc.up.pt (M�rio Amado Alves) writes:

> Creating a temporary file (see test code below) is taking the
> unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my
> laptop. Has someone had this sort of problem?

No. On my Windows XP laptop I got:

   Tempfile took 0.000792279seconds to create!

with GNAT 3.15a1 (similar time with GNAT 3.16w).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Marin David Condic]

Preben Randhol <randhol+news@pvv.org> wrote in message
news:slrnaq8u1b.8sv.randhol+news@kiuk0152.chembio.ntnu.no...
> Warren W. Gay VE3WWG wrote:
> > commercial software wonderful?)  I ended up creating a
> > simple C program that periodically cleans out any of these
>
> Why not Ada?
>
Probably because its quicker and easier to use OS calls with C because the
OS is written in C. Dipping into an Ada binding to access C stuff always
feels like an unnatural act and invariably complicates the job. Just another
data point indicating it would be useful to have an Ada OS and that the
argument "Well, you can always bind to blah blah blah..." is seldom
compelling. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Preben Randhol]

Marin David Condic wrote:
> Probably because its quicker and easier to use OS calls with C because the
> OS is written in C. Dipping into an Ada binding to access C stuff always

In Gnat.OS_Lib

   function File_Time_Stamp (Name : String) return OS_Time;
   --  Given the name of a file, Name, obtains and returns the time stamp.
   --  This function can be used for an unopend file.

   procedure Delete_File (Name : String; Success : out Boolean);

:-)

> feels like an unnatural act and invariably complicates the job. Just another
> data point indicating it would be useful to have an Ada OS and that the
> argument "Well, you can always bind to blah blah blah..." is seldom
> compelling. :-)

Well if you drag the argument further you might end up with "why use Ada
at all?".

Preben who thinks making hacks in Ada is just as fast or faster than C 
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Creating tempfile takes too long: GNAT or Windows bug? Solved

[Mário Amado Alves]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote:
> . . . 
> Another possibility is that your temp directory has 100's, if
> not 1000's of leftover temp files in it. . . .

You're right. After locating the proper directory, I found out it had
11124 files totalling more than 47Mbytes! It seems this relatively
small number is nevertheless too much for Windows. After cleaning it
up I'm getting 0.008 seconds (to create a temp file). 10 times longer
than on Linux, but still reasonable.

Thanks all very much,
--MAA

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Warren W. Gay VE3WWG]

Preben Randhol wrote:
> Marin David Condic wrote:
> 
>>Probably because its quicker and easier to use OS calls with C because the
>>OS is written in C. Dipping into an Ada binding to access C stuff always
> 
> In Gnat.OS_Lib
> 
>    function File_Time_Stamp (Name : String) return OS_Time;
>    --  Given the name of a file, Name, obtains and returns the time stamp.
>    --  This function can be used for an unopend file.
> 
>    procedure Delete_File (Name : String; Success : out Boolean);
> 
> :-)
> 
>>feels like an unnatural act and invariably complicates the job. Just another
>>data point indicating it would be useful to have an Ada OS and that the
>>argument "Well, you can always bind to blah blah blah..." is seldom
>>compelling. :-)
> 
> Well if you drag the argument further you might end up with "why use Ada
> at all?".
> 
> Preben who thinks making hacks in Ada is just as fast or faster than C 

I had a feeling this sort of debate would break out if I confessed
to using C for a "solution" ;-)

Since the question was asked, I'll explain my reasons:

  - In my mind, this was a "nuisance assignment"
  - I wanted/needed a GUI front end
  - GtkAda is OK, but I find that it is still bit of a
    struggle to get things right there (some comments on
    this later)
  - I was in a hurry
  - I had MS Visual Studio available and used MFC for
    the GUI to get the job done.

There is no doubt that if I wanted to do this "right", I
would suffer through any barriers there might be for Ada
(and there wasn't/isn't that much of a barrier really). But
the bottom line was that I wanted to do other more fun
things in Ada and this flippin temp file problem needed to
be addressed ASAP.

So to summarize: I was in a hurry, and MS VC was available,
and MFC is/was easy for a simple input GUI form (it accepts
multiple wildcard pathnames, and the # of days to retain
files before deleting them).

Now a point for discussion for GtkAda:

I need to be careful here, because I don't want to criticize
volunteer's efforts in this area. I would rather encourage
them to continue with their efforts, since I think their
goals are in line with most of ours in the Ada & GUI sense.
However, I do have a few concerns about the
implementation as it stands.

Forgive me if I don't quite have the facts correct here, because
it's been a while since I last worked with GtkAda...

My main concern was with the implementation of certain aspects
of GtkAda, concerning the use of typing. It seemed to me that
there are too many places that require "data conversions" to
occur in the application source code (I am thinking of parameters
in certain callbacks where there was some sort of function to
mangle things into the right type). It seems to me that there should
be a better way to handle this correctly. Either through
generics, or through the object'Class mechanism using
inheritance. Converting from a base type to a derived type
would be acceptable IMHO, although it does have the disadvantage
that it is not properly checked until run time (generics OTOH
would catch problems at compile time).

IIRC, there was a certain amount of reliance on a GStrings
package/interface too, which annoyed me (and other seemingly
C like types).  I would have preferred a native String interface
rather than yet another strings package. The numeric types
should not at least look like C types (maybe I'm just being
picky about this one).

Finally, it seems that every time I try to compile a recent
version of GtkAda on FreeBSD, it has numerous
compile and install issues. This puts me off, as it will
any user that must go through this same process. As a result,
I give up and say "try again in a few months".

Are these fair comments? Or am I just getting cranky?

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Preben Randhol wrote:
> Now a point for discussion for GtkAda:
> 
> I need to be careful here, because I don't want to criticize
> volunteer's efforts in this area. I would rather encourage
> them to continue with their efforts, since I think their
> goals are in line with most of ours in the Ada & GUI sense.
> However, I do have a few concerns about the
> implementation as it stands.

Me, too :).

> Forgive me if I don't quite have the facts correct here, because
> it's been a while since I last worked with GtkAda...
> 
> My main concern was with the implementation of certain aspects
> of GtkAda, concerning the use of typing. It seemed to me that
> there are too many places that require "data conversions" to
> occur in the application source code (I am thinking of parameters
> in certain callbacks where there was some sort of function to
> mangle things into the right type). It seems to me that there should
> be a better way to handle this correctly. 

I agree the current situation is not up to "Ada standards". For
example, just yesterday I cut and pasted a callback. It compiled
without error, did the Gtk "connect" call without error, but failed
with a stack error (not an Ada exception; just a Windows signal) at
run time. It turned out I had missed a parameter in the callback;
something an Ada compiler is supposed to catch at compile time.

> Either through generics, or through the object'Class mechanism using
> inheritance. Converting from a base type to a derived type would be
> acceptable IMHO, although it does have the disadvantage that it is
> not properly checked until run time (generics OTOH would catch
> problems at compile time).

I have not looked at it closely enough to see what the real problem
is. I suspect it is a matter of writing complete bindings, and then
writing an Ada polymorphic wrapper. But it's not that simple, because
Gtk has its own object/dispatching model. That model is very powerful,
and we don't want to lose it. We also want to be able to keep up with
Gtk changes/evolution, so we don't want to much investment in the
binding layer that might have to change.

> IIRC, there was a certain amount of reliance on a GStrings
> package/interface too, which annoyed me (and other seemingly C like
> types). 

I have not encountered GStrings in my GtkAda work, so they may be gone.

> I would have preferred a native String interface rather than yet
> another strings package. The numeric types should not at least look
> like C types (maybe I'm just being picky about this one).
> 
> Finally, it seems that every time I try to compile a recent
> version of GtkAda on FreeBSD, it has numerous
> compile and install issues. This puts me off, as it will
> any user that must go through this same process. As a result,
> I give up and say "try again in a few months".

I'm using a binary release for Windows. It's quite old; Gtk 1.2. There
is now a Gtk 2.0, and GtkAda 2.0 for Linux. It seems like every
question I post to the GtkAda mailing list is answered with "that
works in Gtk 2.0". So I have the same complaint you do, but for
Windows.

I'm going to try to compile GtkAda for Cygwin, and see what that does.
Cygwin ought to be close enough to Linux by now for this to work.

-- 
-- Stephe

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Jeffrey Carter]

Marin David Condic wrote:
> Preben Randhol <randhol+news@pvv.org> wrote in message
> news:slrnaq8u1b.8sv.randhol+news@kiuk0152.chembio.ntnu.no...
> 
>>Warren W. Gay VE3WWG wrote:
>>
>>>commercial software wonderful?)  I ended up creating a
>>>simple C program that periodically cleans out any of these
>>
>>Why not Ada?
>>
> 
> Probably because its quicker and easier to use OS calls with C because the
> OS is written in C. Dipping into an Ada binding to access C stuff always
> feels like an unnatural act and invariably complicates the job. Just another
> data point indicating it would be useful to have an Ada OS and that the
> argument "Well, you can always bind to blah blah blah..." is seldom
> compelling. :-)

I just have

for %%f in (%temp%\*.*) do del %%f

in my autoexec.bat.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> Forgive me if I don't quite have the facts correct here, because it's
> been a while since I last worked with GtkAda...

OK :-)

> 
> My main concern was with the implementation of certain aspects of
> GtkAda, concerning the use of typing. It seemed to me that there are
> too many places that require "data conversions" to occur in the
> application source code (I am thinking of parameters in certain
> callbacks where there was some sort of function to mangle things into
> the right type). It seems to me that there should be a better way to
> handle this correctly. Either through generics, or through the
> object'Class mechanism using inheritance. Converting from a base type
> to a derived type would be acceptable IMHO, although it does have the
> disadvantage that it is not properly checked until run time (generics
> OTOH would catch problems at compile time).

Please let us know which version of GtkAda you have tried. It sounds
like it is a long time ago as I don't recognise these things in any of
the later versions (from at least 1 year ago).

> IIRC, there was a certain amount of reliance on a GStrings
> package/interface too, which annoyed me (and other seemingly C like
> types).  I would have preferred a native String interface rather than
> yet another strings package. The numeric types should not at least
> look like C types (maybe I'm just being picky about this one).

Gstrings?

> Finally, it seems that every time I try to compile a recent version of
> GtkAda on FreeBSD, it has numerous compile and install issues. This
> puts me off, as it will any user that must go through this same
> process. As a result, I give up and say "try again in a few months".

What issues?

> Are these fair comments? Or am I just getting cranky?

I find it a bit hard to relate to them as I haven't experienced these.
If you could be a bit more spesific perhaps I could see your point.

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Preben Randhol]

Stephen Leake wrote:
> I agree the current situation is not up to "Ada standards". For
> example, just yesterday I cut and pasted a callback. It compiled
> without error, did the Gtk "connect" call without error, but failed
> with a stack error (not an Ada exception; just a Windows signal) at
> run time. It turned out I had missed a parameter in the callback;
> something an Ada compiler is supposed to catch at compile time.

Can you show us how it looks?

> I'm using a binary release for Windows. It's quite old; Gtk 1.2. There
> is now a Gtk 2.0, and GtkAda 2.0 for Linux. It seems like every
> question I post to the GtkAda mailing list is answered with "that
> works in Gtk 2.0". So I have the same complaint you do, but for
> Windows.

I'm also waiting for the GtkAda 2.0 as it has propper support for
languages etc...

> I'm going to try to compile GtkAda for Cygwin, and see what that does.
> Cygwin ought to be close enough to Linux by now for this to work.

Check the docs here: http://www.gimp.org/~tml/gimp/win32/


   Using GTK+ in your own programs

   In order to use the DLLs as distributed in programs you build
   yourself, you must use either gcc-2.95.2 (or later, 2.95.3 certainly
   works, dunno about GCC 3), or Microsoft Visual C++ 5 or 6. With gcc,
   you should use the -mno-cygwin and -fnative-struct flags. Using any
   other gcc setup will not work. (Hint: struct field alignment. Hint 2:
   msvcrt.dll.) If you don't understand what I am talking about, just
   trust me.

   If you are porting a program that uses GTK+ 1.2 on Unix, use GTK+
   1.3.0 on Windows. Don't be afraid of the 1.3 version number, it
   actually is mostly like 1.2.7, API-wise.

   You are expected to be pretty experienced to be able to use GTK+ in
   your own programs. This isn't Visual Basic. Please don't bother the
   lists with elementary questions without first browsing the archives.

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Marin David Condic]

Preben Randhol <randhol+news@pvv.org> wrote in message
news:slrnaqasl9.93n.randhol+news@kiuk0152.chembio.ntnu.no...
>
> In Gnat.OS_Lib
>
>    function File_Time_Stamp (Name : String) return OS_Time;
>    --  Given the name of a file, Name, obtains and returns the time stamp.
>    --  This function can be used for an unopend file.
>
>    procedure Delete_File (Name : String; Success : out Boolean);
>
> :-)
>
O.K. For a hack, using a compiler dependent package is probably O.K. -
Assuming for the moment that the environment in question is a Gnat
environment. You might not have it if you use another compiler.


> > feels like an unnatural act and invariably complicates the job. Just
another
> > data point indicating it would be useful to have an Ada OS and that the
> > argument "Well, you can always bind to blah blah blah..." is seldom
> > compelling. :-)
>
> Well if you drag the argument further you might end up with "why use Ada
> at all?".
>
But you'd have to drag the argument pretty hard across some rough terrain.
:-) Its one thing to say "My project needs all these large C libraries - why
do I want to complicate my life by using something other than C to implement
my project?" (And this is generally how it goes - look at projects that rely
heavily on any significant library and no matter how much better some other
language may be, they very seldom go far afield from whatever that library
was written in.) Its quite another thing to say "My project doesn't make
extensive use of an OS or library, but I'm going to avoid Ada anyway
because, well, just because!" :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Marin David Condic]

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3DA5B8E6.3010109@cogeco.ca...
>
> So to summarize: I was in a hurry, and MS VC was available,
> and MFC is/was easy for a simple input GUI form (it accepts
> multiple wildcard pathnames, and the # of days to retain
> files before deleting them).
>
My point is that this is a *perfectly* legitimate argument and one that is
made every day in businesses that build software. "I've got to get it out
the door in a hurry (because profit depends on getting there first - not
getting there in Ada) and MSVC (or insert your favorite language, IDE,
library) gets me there more quickly than I can with Ada..."

Its not that Ada is somehow or other inherently slow in development. I think
its capable of being significantly faster - especially if one considers test
and debug time to be part of "development". Its just that when some other
language offers massive libraries of reasonably reliable stuff and
reasonably spiffy tools to slap an application together quickly, its hard to
compete if all you've got is a descent language and the argument that you
can always bind to all that spiffy stuff you bought with the other language.
(Why have two languages?) If there was an equivalent MSVAda with an MFC-Ada
and all that other cool stuff sitting on you're computer right next to the
MSVC package, you'd probably have done the hack in Ada, right?

I don't know how Ada as a language and/or user community can get something
vaguely resembling a large class library and/or a spiffy development
environment (although GPS may hold some promise) but I think its a key
ingredient. I've seen, and been part of, efforts in the past to develop
libraries and I might be willing to do so again. The hard part is getting
proper acceptance and the proper forum for the project so that it actually
gets done and actually gets used.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Preben Randhol]

Marin David Condic wrote:
> O.K. For a hack, using a compiler dependent package is probably O.K. -
> Assuming for the moment that the environment in question is a Gnat
> environment. You might not have it if you use another compiler.

So your point is that one should use C and the Microsoft libraries in
stead? Last time I checked I don't even have a C compiler for my Window
OSes and I certainly cannot compile it on Linux. :-) It seems a bit
unfair that for Ada one have to make everything both platform and
compiler independant while for C one doesn't when one compare the two.

Besides it isn't that hard to use the GNAT.OS_Lib with another compiler
I should think.

> But you'd have to drag the argument pretty hard across some rough terrain.
>:-) Its one thing to say "My project needs all these large C libraries - why
> do I want to complicate my life by using something other than C to implement
> my project?" (And this is generally how it goes - look at projects that rely
> heavily on any significant library and no matter how much better some other
> language may be, they very seldom go far afield from whatever that library
> was written in.) Its quite another thing to say "My project doesn't make
> extensive use of an OS or library, but I'm going to avoid Ada anyway
> because, well, just because!" :-)

:-)

-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Creating tempfile takes too long: GNAT or Windows bug?

[James Ross]

(M�rio Amado Alves) wrote:

>Creating a temporary file (see test code below) is taking the
>unreasonable time of 30+ seconds on Windows XP (with GNAT 3.14p) on my
>laptop. Has someone had this sort of problem?
>
>On Linux (same compiler version), in another machine, it takes a
>reasonable time: 0.0004 seconds.

GNAT 3.14p, Windows 2000, 2.4G P4, UDMA 133 HD (Desktop)
Tempfile took 0.000312330seconds to create!

GNAT 3.13p, Windows XP, 1.0G P3, UDMA 66 HD (Notebook)
Tempfile took 0.001299048seconds to create!

JR

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Marin David Condic]

Preben Randhol <randhol+news@pvv.org> wrote in message
news:slrnaqdm6m.4ob.randhol+news@kiuk0152.chembio.ntnu.no...
>
> So your point is that one should use C and the Microsoft libraries in
> stead? Last time I checked I don't even have a C compiler for my Window
> OSes and I certainly cannot compile it on Linux. :-) It seems a bit
> unfair that for Ada one have to make everything both platform and
> compiler independant while for C one doesn't when one compare the two.
>
I was thinking more along the linds of this: "I have a c compiler. My OS is
written in C. The C function interfaces are sitting right there. Hack a
program to make an OS call or two..." That as opposed to: "I have an Ada
compiler. My OS is written in C. I've got to play around with building a
binding to whatever it is I need from the OS or at least use some binding
that may be there and is "unnatural" for Ada (can't just use strings and
integers and such - got to go create pointers and things from Interfaces.C).
It becomes more work, so why didn't I just hack the little job in C?"

It may not be a far stretch to hack a lot of things in Ada - I've done it
enough times myself. I'm just observing that people have a tendency to go
down the path of least resistance and if everything surrounding you is C,
its less likely that the job is going to be done in Ada.

Note that this works two ways - if the OS and everything surrounding it is
in Ada, it would be less likely one would end up doing things in C, right?
;-)


> Besides it isn't that hard to use the GNAT.OS_Lib with another compiler
> I should think.
>

I suppose, but if you had the Gnat code, chances are you have Gnat so why
would you be using another compiler? Its not so much an issue of a portable
library for Ada and no insistance on a portable library for C. Its more a
case of observing that when the surrounding environment is done with a given
language, it tends to promote use of that language. Although, to whatever
extend Ada can provide a portable library of things to interface to the
native OS, the better off it is, I think.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Preben Randhol]

Marin David Condic wrote:
> I was thinking more along the linds of this: "I have a c compiler. My OS is
> written in C. The C function interfaces are sitting right there. Hack a
> program to make an OS call or two..." That as opposed to: "I have an Ada
> compiler. My OS is written in C. I've got to play around with building a
> binding to whatever it is I need from the OS or at least use some binding
> that may be there and is "unnatural" for Ada (can't just use strings and
> integers and such - got to go create pointers and things from Interfaces.C).
> It becomes more work, so why didn't I just hack the little job in C?"

But if one has Gnat (which is freely available) the bindings you needed
in this case were available. So no problem :-)

> It may not be a far stretch to hack a lot of things in Ada - I've done it
> enough times myself. I'm just observing that people have a tendency to go
> down the path of least resistance and if everything surrounding you is C,
> its less likely that the job is going to be done in Ada.

Well I find it easier and faster to hack things with Ada. Even using
strings is easier.

> Note that this works two ways - if the OS and everything surrounding it is
> in Ada, it would be less likely one would end up doing things in C, right?
> ;-)

:-) Hope so.
> 
> I suppose, but if you had the Gnat code, chances are you have Gnat so why
> would you be using another compiler? Its not so much an issue of a portable
> library for Ada and no insistance on a portable library for C. Its more a
> case of observing that when the surrounding environment is done with a given
> language, it tends to promote use of that language. Although, to whatever
> extend Ada can provide a portable library of things to interface to the
> native OS, the better off it is, I think.

Yes, I understand, but still...

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf

Re: Creating tempfile takes too long: GNAT or Windows bug?

[Simon Clubley]

In article <3DA5D8AC.6020201@acm.org>, Jeffrey Carter <jrcarter@acm.org> writes:
> 
> I just have
> 
> for %%f in (%temp%\*.*) do del %%f
> 
> in my autoexec.bat.
> 

I can't resist asking you what happens if temp gets unset for some reason ?

:-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Lada of the computing world.

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Warren W. Gay VE3WWG]

Preben Randhol wrote:
> Warren W. Gay VE3WWG wrote:
...
>>My main concern was with the implementation of certain aspects of
>>GtkAda, concerning the use of typing. It seemed to me that there are
>>too many places that require "data conversions" to occur in the
>>application source code (I am thinking of parameters in certain
>>callbacks where there was some sort of function to mangle things into
>>the right type). It seems to me that there should be a better way to
>>handle this correctly. Either through generics, or through the
>>object'Class mechanism using inheritance. Converting from a base type
>>to a derived type would be acceptable IMHO, although it does have the
>>disadvantage that it is not properly checked until run time (generics
>>OTOH would catch problems at compile time).
> 
> Please let us know which version of GtkAda you have tried. It sounds
> like it is a long time ago as I don't recognise these things in any of
> the later versions (from at least 1 year ago).

It was 1.x of some sort. Here is a snippit that bugs me:

    procedure On_Clist2_Select_Row
      (Object : access Gtk_Clist_Record'Class;
       Params : Gtk.Arguments.Gtk_Args)
    is
       Row_X : Gint := To_Gint (Params, 1);
--    Rows  : Gint := To_Gint (Params, 2);
--    Evt   : Gdk_Event := To_Event (Params, 3);
    begin
       ...

The Params argument is of type Gtk.Arguments.Gtk_Args. To get the
real args, I have to use a bunch of To_G*() conversion calls. If
the API changes at some later date, this now incorrect code will not
be caught at compile time. This bugs me because, as a GUI, this
error may not be noticed for a long time -- in fact, it is likely
the user will find it instead of me. ;-)

Alternatively, the API may never change, but I may not code this
correctly. Once again, I may not be the one that discovers the
problem in a large GUI project.

Where possible, I would prefer to get one consistent strongly
typed interface. If "select row" only returns certain info, then
IMHO the callback should be tailored for this, or at the minimum,
the event data could be a discriminated type.

>>IIRC, there was a certain amount of reliance on a GStrings
>>package/interface too, which annoyed me (and other seemingly C like
>>types).  I would have preferred a native String interface rather than
>>yet another strings package. The numeric types should not at least
>>look like C types (maybe I'm just being picky about this one).

I don't think much of using Gint as a data type, but maybe I am
being fussy. I'd prefer to user more strongly typed data types that
match the parameter or argument's purpose, than any general purpose
argument. If you must, Gint as a base type might be ok.

> Gstrings?

I guess my memory had a parity error on this one.

>>Finally, it seems that every time I try to compile a recent version of
>>GtkAda on FreeBSD, it has numerous compile and install issues. This
>>puts me off, as it will any user that must go through this same
>>process. As a result, I give up and say "try again in a few months".
> 
> What issues?

I'd have to go back and retry this, because there were several compile
time issues. Too many for me to remember right now, and too many to
plow through at the time. If I try it again RSN, I'll email you directly.

Warren.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Creating tempfile takes too long: GNAT or Windows bug? (& GtkAda)

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> 
> It was 1.x of some sort. Here is a snippit that bugs me:
> 
>     procedure On_Clist2_Select_Row
>       (Object : access Gtk_Clist_Record'Class;
>        Params : Gtk.Arguments.Gtk_Args)
>     is
>        Row_X : Gint := To_Gint (Params, 1);
> --    Rows  : Gint := To_Gint (Params, 2);
> --    Evt   : Gdk_Event := To_Event (Params, 3);
>     begin
>        ...
> 
> The Params argument is of type Gtk.Arguments.Gtk_Args. To get the
> real args, I have to use a bunch of To_G*() conversion calls. If
> the API changes at some later date, this now incorrect code will not
> be caught at compile time. This bugs me because, as a GUI, this
> error may not be noticed for a long time -- in fact, it is likely
> the user will find it instead of me. ;-)

Yes I agree with you there. Perhaps this is what you look for:

--------------------------------------------------------------------------
--  This small examples show how you can create your own marshallers when
--  you want to create a handler for a signal that has no predefined
--  marshaller.
--
--  NOTE: you should already be quite familiar with how handlers and
--  marshallers work in GtkAda before trying to understand this example.
--
--  Most of the time, in this case, you should simply create a general
--  handler such as defined in the generic packages in Gtk.Handlers, and
--  as demonstrated in the first example below.
--  In that case, the conversion from C's System.Address types to your own
--  types is done directly in your handler.
--
--  In other cases, for instance when you reuse the same signal multiple
--  times, it might be cleaner to define a marshaller, so that your handlers
--  can have typed parameters. This is the second example demonstrated
--  below.
--
--  This example interfaces to a signal defined in the gtktipsquery.h in the
--  gtk+ distribution. The signal is called "widget_entered", and is called to
--  display a tooltip every time the pointer enteres a new widget
--  The general form for handlers, as defined in the C package is:
--
--    void  (*widget_entered) (GtkTipsQuery   *tips_query,
--                             GtkWidget      *widget,
--                             const gchar    *tip_text,
--                             const gchar    *tip_private);
--
--  There is no predefined marshaller for it in gtk-marshallers.ads

with Gtk.Arguments;
with Gtk.Handlers;
with Gtk.Marshallers;
with Gtk.Tips_Query; use Gtk.Tips_Query;
with Gtk.Widget;     use Gtk.Widget;

package Own_Marshaller is

   package Tips_Handlers is new Gtk.Handlers.Callback
     (Widget_Type => Gtk.Tips_Query.Gtk_Tips_Query_Record);

   --------------------
   -- First solution --
   --------------------

   --  First and simpler solution: use the general form for handlers, as
   --  defined in gtk-handlers.
   --  This does not require anything special, and the conversion of
   --  arguments will have to be done in the handler itself.
   --
   --  Example of use:
   --     see general_tips.adb

   procedure My_General_Tips (Tips   : access Gtk_Tips_Query_Record'Class;
                              Params : Gtk.Arguments.Gtk_Args);


   ---------------------
   -- Second solution --
   ---------------------

   --  If you want your handlers to directly have the
   --  correct number of parameters (and correctly typed), you have to
   --  provide your own marshallers. The subprogram below is the correct
   --  form for the handler, and the package implements the marshaller.
   --
   --  This solution is more work, but on the other hand is easier to reuse
   --  when the package below has been written.
   --
   --  Example of use:
   --     see specific_tips.adb

   procedure My_Specific_Tips (Tips   : access Gtk_Tips_Query_Record'Class;
                               Widget : access Gtk_Widget_Record'Class;
                               Text   : String;
                               Tips_P : String);

   package My_Tips_Marshaller_Pkg is
      type Handler is access
        procedure (Tips   : access Gtk_Tips_Query_Record'Class;
                   Widget : access Gtk_Widget_Record'Class;
                   Text   : String;
                   Tips_P : String);
      procedure My_Tips_Marshaller (Tips   : access Gtk_Tips_Query_Record'Class;
                                    Params : Gtk.Arguments.Gtk_Args;
                                    Cb     : Gtk.Marshallers.General_Handler);
      function To_Marshaller (Cb : Handler)
                             return Tips_Handlers.Marshallers.Marshaller;
   end My_Tips_Marshaller_Pkg;

end Own_Marshaller;

with Gtk.Marshallers;  use Gtk.Marshallers;
with Unchecked_Conversion;

package body Own_Marshaller is

   ---------------------
   -- My_General_Tips --
   ---------------------

   procedure My_General_Tips (Tips   : access Gtk_Tips_Query_Record'Class;
                              Params : Gtk.Arguments.Gtk_Args)
   is
      --  Have to do the conversion by hand
      Widget : Gtk_Widget := Gtk_Widget (Gtk.Arguments.To_Object (Params, 1));
      Text   : String     := Gtk.Arguments.To_String (Params, 2);
      Tips_P : String     := Gtk.Arguments.To_String (Params, 3);

   begin
      null;  --  Whatever you want here
   end My_General_Tips;


   ----------------------
   -- My_Specific_Tips --
   ----------------------

   procedure My_Specific_Tips (Tips   : access Gtk_Tips_Query_Record'Class;
                               Widget : access Gtk_Widget_Record'Class;
                               Text   : String;
                               Tips_P : String)
   is
   begin
      null;  --  Whatever you want here
   end My_Specific_Tips;

   ----------------------------
   -- My_Tips_Marshaller_Pkg --
   ----------------------------

   package body My_Tips_Marshaller_Pkg is

      function To_Handler is new Unchecked_Conversion
        (Gtk.Marshallers.General_Handler, Handler);
      function To_General_Handler is new Unchecked_Conversion
        (Handler, Gtk.Marshallers.General_Handler);

      ------------------------
      -- My_Tips_Marshaller --
      ------------------------

      procedure My_Tips_Marshaller (Tips   : access Gtk_Tips_Query_Record'Class;
                                    Params : Gtk.Arguments.Gtk_Args;
                                    Cb     : Gtk.Marshallers.General_Handler)
      is
         My_Cb : Handler := To_Handler (Cb);
      begin
         --  Basically, we do the same thing as in My_General_Tips above
         My_Cb (Tips,
                Gtk_Widget (Gtk.Arguments.To_Object (Params, 1)),
                Gtk.Arguments.To_String (Params, 2),
                Gtk.Arguments.To_String (Params, 3));
      end My_Tips_Marshaller;

      -------------------
      -- To_Marshaller --
      -------------------

      function To_Marshaller (Cb : Handler)
                             return Tips_Handlers.Marshallers.Marshaller
      is
      begin
         return (Func  => To_General_Handler (Cb),
                 Proxy => My_Tips_Marshaller'Access);
      end To_Marshaller;

   end My_Tips_Marshaller_Pkg;

end Own_Marshaller;

-----------------------------------------------------------------------------

It is taken from the examples in the document that comes with the
library.

> I don't think much of using Gint as a data type, but maybe I am
> being fussy. I'd prefer to user more strongly typed data types that
> match the parameter or argument's purpose, than any general purpose
> argument. If you must, Gint as a base type might be ok.

No I use Integer or Natural etc and I do Gint (variable) if needed in
function call.

Preben
-- 
Ada95 is good for you.
http://libre.act-europe.fr/Software_Matters/02-C_pitfalls.pdf