www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D has moved up to number 18!

reply Walter Bright <newshound digitalmars.com> writes:
http://www.tiobe.com/tpci.htm
Jun 05 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e62iae$13et$1 digitaldaemon.com...

 http://www.tiobe.com/tpci.htm


That's some serious wootage.

Though what's with ColdFusion moving up to 20?  Wasn't that some kind of 
side-of-the-road web language in the late 90s?  Or has it had some kind of 
revival?  And Visual FoxPro too.. weird.
Jun 05 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <e62qqh$1h7j$1 digitaldaemon.com>, Jarrett Billingsley says...

"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e62iae$13et$1 digitaldaemon.com...

 http://www.tiobe.com/tpci.htm


That's some serious wootage.


W00t.  We edged out Ruby.  Very nice. 


Though what's with ColdFusion moving up to 20?  Wasn't that some kind of 
side-of-the-road web language in the late 90s?  Or has it had some kind of 
revival? 


I can personally attest to ColdFusions merits and flaws as I use it on a daily
basis - its not pretty, but it does put food on the table.  AFAIK, its widely
used on government contracts thanks to the forward-thinking individuals that put
web applications in place there back in the early 90's - then it was the only
game in town next to perl CGI and a very early rendition ASP.

It was revitalized when Macromedia acquired Aleris and basically saved the
language from itself by reworking it as a J2EE web language (same niche as JSP).
The Java backend has done a lot for enabling interop with superior tools and
libraries (all Java), as well as making server admins much happier.  You can
even compile CF apps down to .war files for deployment, or mix and match with
jsp and vanilla Java code - so its like an alternate to the .NET stack for web
applications.

As far as revivals are concerned, you might be right. Macromedia had quite the
corporate blogroll and press for this product, and it looks like Adobe is
continuing the tradition and live documentation.  CFMX7 just  came out, so maybe
its here to stay for a while longer. :-/

- EricAnderton at yahoo
Jun 05 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:e62rul$1j08$1 digitaldaemon.com...


 W00t.  We edged out Ruby.  Very nice.


Damn, I just noticed that!  Take that, snooty esoteric interpreted 
languages!


 As far as revivals are concerned, you might be right. Macromedia had quite 
 the
 corporate blogroll and press for this product, and it looks like Adobe is
 continuing the tradition and live documentation.  CFMX7 just  came out, so 
 maybe
 its here to stay for a while longer. :-/


Bizarre.  I haven't even heard ColdFusion mentioned for years.
Jun 05 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e62iae$13et$1 digitaldaemon.com...

 http://www.tiobe.com/tpci.htm


 
 That's some serious wootage.
 
 Though what's with ColdFusion moving up to 20?  Wasn't that some kind of 
 side-of-the-road web language in the late 90s?  Or has it had some kind of 
 revival?  And Visual FoxPro too.. weird. 
 


I can't say why those have jumped up like they have, except to say that 
maybe it had something to do with TIOBE revising their query(ies) a 
while back.

I think both Cold Fusion and Foxpro still get some pretty heavy use out 
there - I suspect there's *a lot* of legacy applications still in use, 
and a lot of independent developers (CF) and small software shops 
(Foxpro) using them. Foxpro inherited a lot of the Dbase development 
back in the day. One just never sees them mentioned in IT magazines or 
taught at Uni. any more.
Jun 05 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message


 I can't say why those have jumped up like they have, except to say that 
 maybe it had something to do with TIOBE revising their query(ies) a while 
 back.


That's possible - I wiki'ed FoxPro, and in fact, it was only in December of 
last year that FoxPro even made it into the top 20.  So something weird had 
to have happened.


 I think both Cold Fusion and Foxpro still get some pretty heavy use out 
 there - I suspect there's *a lot* of legacy applications still in use, and 
 a lot of independent developers (CF) and small software shops (Foxpro) 
 using them.


Yeah, my father does still do some FoxPro from time to time when he's 
working on some small bussiness's databases (he's been a database engineer 
for umpteen years..).
Jun 05 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Dave wrote:

 Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e62iae$13et$1 digitaldaemon.com...

 http://www.tiobe.com/tpci.htm


 That's some serious wootage.

 Though what's with ColdFusion moving up to 20?  Wasn't that some kind 
 of side-of-the-road web language in the late 90s?  Or has it had some 
 kind of revival?  And Visual FoxPro too.. weird.


 
 I can't say why those have jumped up like they have, except to say that 
 maybe it had something to do with TIOBE revising their query(ies) a 
 while back.


I think it's got more to do with this:

http://fox.wikis.com/wc.dll?Wiki~GettingGoogledForTheTiobeMetricsCount

I'm a little suspicious of the Tiobe metrics; there's clearly _some_ 
distortion happening.


 I think both Cold Fusion and Foxpro still get some pretty heavy use out 
 there - I suspect there's *a lot* of legacy applications still in use, 
 and a lot of independent developers (CF) and small software shops 
 (Foxpro) using them. Foxpro inherited a lot of the Dbase development 
 back in the day. One just never sees them mentioned in IT magazines or 
 taught at Uni. any more.
Jun 05 2006
parent reply Dave <Dave_member pathlink.com> writes:
Don Clugston wrote:

 Dave wrote:

 Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e62iae$13et$1 digitaldaemon.com...

 http://www.tiobe.com/tpci.htm


 That's some serious wootage.

 Though what's with ColdFusion moving up to 20?  Wasn't that some kind 
 of side-of-the-road web language in the late 90s?  Or has it had some 
 kind of revival?  And Visual FoxPro too.. weird.


 I can't say why those have jumped up like they have, except to say 
 that maybe it had something to do with TIOBE revising their query(ies) 
 a while back.


 
 I think it's got more to do with this:
 
 http://fox.wikis.com/wc.dll?Wiki~GettingGoogledForTheTiobeMetricsCount


Heh, heh - The few Foxpro developers I know are really pragmatic and 
getting together and "gaming TIOBE" for the good of Foxpro would be 
right up their alley <g> Hats off to them :)

The last updated date on that corresponds to when the "jump" started to 
happen, I think...

Still, it does speak to at least an active Foxpro community out there yet.


 
 I'm a little suspicious of the Tiobe metrics; there's clearly _some_ 
 distortion happening.
 

 I think both Cold Fusion and Foxpro still get some pretty heavy use 
 out there - I suspect there's *a lot* of legacy applications still in 
 use, and a lot of independent developers (CF) and small software shops 
 (Foxpro) using them. Foxpro inherited a lot of the Dbase development 
 back in the day. One just never sees them mentioned in IT magazines or 
 taught at Uni. any more.
Jun 06 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb am 2006-06-06:

 Don Clugston wrote:



 I think it's got more to do with this:
 
 http://fox.wikis.com/wc.dll?Wiki~GettingGoogledForTheTiobeMetricsCount


 Heh, heh - The few Foxpro developers I know are really pragmatic and 
 getting together and "gaming TIOBE" for the good of Foxpro would be 
 right up their alley <g> Hats off to them :)


Let's see what impact some white hats have:
http://www.prowiki.org/wiki4d/wiki.cgi?PromotingD


 The last updated date on that corresponds to when the "jump" started to 
 happen, I think...

 Still, it does speak to at least an active Foxpro community out there yet.


from http://fox.wikis.com/wc.dll?Wiki%7ETiobeProgrammingLanguagePopularity









Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFEhbmh3w+/yD4P9tIRAvenAJ9rgxore9LrllfL1nqPkLrvMJUJSACgxXth
fMiRjyvMAcA32FeZxpnDytQ=
=Csg5
-----END PGP SIGNATURE-----
Jun 06 2006
prev sibling parent reply Dejan Lekic <dejan nu6.org> writes:
I have expected that to happen. I would not be surprised if D comes to 
top5 languages on TIOBE's TPCI list by the end of this year, and become 


As an experienced C/C++ developer (12+ years of commercial experience) i 
can only say that D will become language of choice whenever I am the one 
who decides what language to chose. I have very good reasons to do so.

1) Perfect scope() solution. Seriously, scope() keyword is IMHO one of 
the best new things i have seen so far - it shortens the code a lot, and 
puts necessary code where it belongs.

2) Amazing template support with solved syntax ambiguities.

3) Delegates.

4) Real modules. Packages and interfaces.

5) super keyword

6) array slicing

7) utf8 support

... and many more.

The only thing i really miss is better thread support. I have already 
proposed changes (about lock() keyword, and better thread 
synchronisation tuning), but you Mr. Bright did not respond. :) Some 
other guys did and they did like what i proposed.

*I have no words to express my apriciation for what you have done so 
far, and gave us all that for free.

Thank you Walter!*

Kind regards to you and whole D community.

Dejan Lekic
Jun 08 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Dejan Lekic wrote:

 The only thing i really miss is better thread support. I have already 
 proposed changes (about lock() keyword, and better thread 
 synchronisation tuning), but you Mr. Bright did not respond. :) Some 
 other guys did and they did like what i proposed.


Can you point me to the thread?


 *I have no words to express my apriciation for what you have done so 
 far, and gave us all that for free.
 
 Thank you Walter!*


You're welcome!
Jun 08 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e69jmh$bnq$1 digitaldaemon.com>, Walter Bright says...

Dejan Lekic wrote:

 The only thing i really miss is better thread support. I have already 
 proposed changes (about lock() keyword, and better thread 
 synchronisation tuning), but you Mr. Bright did not respond. :) Some 
 other guys did and they did like what i proposed.


Can you point me to the thread?


I guessing it's this:
http://www.digitalmars.com/d/archives/digitalmars/D/35240.html

jcc7
Jun 08 2006
parent reply Dejan Lekic <dejan nu6.org> writes:
Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
failed! :)
Yes, that is a very nice thread, with many good ideas which followed.
In short, the basic idea is to move thread support INTO the language. 

Best regards!
Jun 08 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
Dejan Lekic wrote:

 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language. 
 
 Best regards!


I'd like to interject that, if more threading support is to be added to 
the language, it may be worthwhile to look into moving away from 'native 
threads' (including pthreads) into something more lightweight as the 
internal basis for D threading. Like the recently posted StackThreads 
library maybe(?). Many other languages (especially functional languages) 
are taking this approach - better performance, flexibility and portability.

IMHO, it be best to either a) release v1.0 w/ thread support as-is and 
redesign it for v2 or b) delay v1 until it has any improvements Walter 
may deem worthy, because I can only see MT as becoming hugely important 
in the next couple of years.
Jun 08 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:

 Dejan Lekic wrote:

 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, 
 but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!


 
 I'd like to interject that, if more threading support is to be added to 
 the language, it may be worthwhile to look into moving away from 'native 
 threads' (including pthreads) into something more lightweight as the 
 internal basis for D threading. Like the recently posted StackThreads 
 library maybe(?). Many other languages (especially functional languages) 
 are taking this approach - better performance, flexibility and portability.


Yes and no.  With the number of processors on average systems increasing 
rapidly, there's definitely a place for kernel threads in today's world. 
  IMO Solaris handles threading fairly well as it automatically uses 
both user threads and kernel threads for the pthread API based on some 
system knowledge and influenced by some API parameters.  I like this 
better than cooperative user-level multithreading in most cases because 
it's easier to use and more flexible for the platform design, though it 
isn't quite so lightweight as mutexes and such must still be used.


 IMHO, it be best to either a) release v1.0 w/ thread support as-is and 
 redesign it for v2 or b) delay v1 until it has any improvements Walter 
 may deem worthy, because I can only see MT as becoming hugely important 
 in the next couple of years.


Definately.


Sean
Jun 08 2006
parent reply Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:

 Dave wrote:

 Dejan Lekic wrote:

 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
 myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!


 I'd like to interject that, if more threading support is to be added 
 to the language, it may be worthwhile to look into moving away from 
 'native threads' (including pthreads) into something more lightweight 
 as the internal basis for D threading. Like the recently posted 
 StackThreads library maybe(?). Many other languages (especially 
 functional languages) are taking this approach - better performance, 
 flexibility and portability.


 
 Yes and no.  With the number of processors on average systems increasing 
 rapidly, there's definitely a place for kernel threads in today's world. 
  IMO Solaris handles threading fairly well as it automatically uses both 
 user threads and kernel threads for the pthread API based on some system 
 knowledge and influenced by some API parameters.  I like this better 
 than cooperative user-level multithreading in most cases because it's 
 easier to use and more flexible for the platform design, though it isn't 
 quite so lightweight as mutexes and such must still be used.
 


I just had reason to take a look at the Solaris thread stuff the other 
day. Pretty cool.

So, I guess the challenge may be to try and provide flexible enough 
language mods. and (a reference) rt lib/compiler interface to 
accommodate the best for a given platform?


 IMHO, it be best to either a) release v1.0 w/ thread support as-is and 
 redesign it for v2 or b) delay v1 until it has any improvements Walter 
 may deem worthy, because I can only see MT as becoming hugely 
 important in the next couple of years.


 
 Definately.
 
 
 Sean
Jun 09 2006
parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:

 Sean Kelly wrote:

 Dave wrote:

 Dejan Lekic wrote:

 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
 myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!


 I'd like to interject that, if more threading support is to be added 
 to the language, it may be worthwhile to look into moving away from 
 'native threads' (including pthreads) into something more lightweight 
 as the internal basis for D threading. Like the recently posted 
 StackThreads library maybe(?). Many other languages (especially 
 functional languages) are taking this approach - better performance, 
 flexibility and portability.


 Yes and no.  With the number of processors on average systems 
 increasing rapidly, there's definitely a place for kernel threads in 
 today's world.  IMO Solaris handles threading fairly well as it 
 automatically uses both user threads and kernel threads for the 
 pthread API based on some system knowledge and influenced by some API 
 parameters.  I like this better than cooperative user-level 
 multithreading in most cases because it's easier to use and more 
 flexible for the platform design, though it isn't quite so lightweight 
 as mutexes and such must still be used.


 
 I just had reason to take a look at the Solaris thread stuff the other 
 day. Pretty cool.
 
 So, I guess the challenge may be to try and provide flexible enough 
 language mods. and (a reference) rt lib/compiler interface to 
 accommodate the best for a given platform?


I think so.  Personally, my main interest with new threading work is to 
provide something that avoids the need for direct of most synchronized 
blocks, thread construction, etc, as this stuff is notoriously difficult 
for even experienced programmers to get right.  In the past I've 
mentioned Herb Sutter's Concur project in relation to this, and there 
has been some discussion of related projects and technology as well. 
Were D to set its sights on concurrent programming I'd much prefer it be 
at this level rather than focusing on the traditional approach. 
However, I think a good interim solution (and to simplify implementing 
library support for this sort of thing) would be to expand the 
traditional interface somewhat, at least to include condvars and perhaps 
try-locks.  This can be done largely in library code (someone posted a 
condvar implementation a while back), but as it affects language 
semantics at least marginally I'd prefer it have some sort of official 
seal of approval.  For Ares I've been fairly careful so far to limit 
most of my changes to what I felt was readily identifiable as library 
code, as I don't want to muddy the waters about what is legal D syntax.


Sean
Jun 09 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <e6catg$10ck$1 digitaldaemon.com>, Sean Kelly says...

Dave wrote:

 Sean Kelly wrote:

 Dave wrote:

 Dejan Lekic wrote:

 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
 myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!


 I'd like to interject that, if more threading support is to be added 
 to the language, it may be worthwhile to look into moving away from 
 'native threads' (including pthreads) into something more lightweight 
 as the internal basis for D threading. Like the recently posted 
 StackThreads library maybe(?). Many other languages (especially 
 functional languages) are taking this approach - better performance, 
 flexibility and portability.


 Yes and no.  With the number of processors on average systems 
 increasing rapidly, there's definitely a place for kernel threads in 
 today's world.  IMO Solaris handles threading fairly well as it 
 automatically uses both user threads and kernel threads for the 
 pthread API based on some system knowledge and influenced by some API 
 parameters.  I like this better than cooperative user-level 
 multithreading in most cases because it's easier to use and more 
 flexible for the platform design, though it isn't quite so lightweight 
 as mutexes and such must still be used.


 
 I just had reason to take a look at the Solaris thread stuff the other 
 day. Pretty cool.
 
 So, I guess the challenge may be to try and provide flexible enough 
 language mods. and (a reference) rt lib/compiler interface to 
 accommodate the best for a given platform?


I think so.  Personally, my main interest with new threading work is to 
provide something that avoids the need for direct of most synchronized 
blocks, thread construction, etc, as this stuff is notoriously difficult 
for even experienced programmers to get right.  In the past I've 
mentioned Herb Sutter's Concur project in relation to this, and there 
has been some discussion of related projects and technology as well. 
Were D to set its sights on concurrent programming I'd much prefer it be 
at this level rather than focusing on the traditional approach. 
However, I think a good interim solution (and to simplify implementing 
library support for this sort of thing) would be to expand the 
traditional interface somewhat, at least to include condvars and perhaps 
try-locks.  This can be done largely in library code (someone posted a 
condvar implementation a while back), but as it affects language 
semantics at least marginally I'd prefer it have some sort of official 
seal of approval.  For Ares I've been fairly careful so far to limit 
most of my changes to what I felt was readily identifiable as library 
code, as I don't want to muddy the waters about what is legal D syntax.


I think condvars and try-locks would be great (semaphores too)... I'm wondering
if it would make sense for support of threads and related to just be added
directly to the language? New keywords, a built-in thread type and all? Or
something like building at least rudimentary OpenMP type functionality into the
language?

Ideally, I'd like to see thread/MP support such that it would eliminate much of
the productivity advantages that languages that are supposed to be able to
'auto-parallelize' loops may have (like Sun's new 'Fortress').

For D these things would still be explicit, like it should be for a GP/systems
orientated language, and would help keep the compiler implementation effort
reasonable as well. I can see support like that lasting well into the next
decade, until compilers or runtimes are truly smart-enough to do a really good
job at auto-parallelization and such. That is, if the syntax and semantics can
be made straight forward enough that better control is worth a bit more
development time for the general case, then I think a statically compiled D
could stay competitive in this area.
Jun 10 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Dave wrote:


 I think condvars and try-locks would be great (semaphores too)... I'm
 wondering if it would make sense for support of threads and related
 to just be added directly to the language? New keywords, a built-in
 thread type and all? Or something like building at least rudimentary
 OpenMP type functionality into the language?
 
 Ideally, I'd like to see thread/MP support such that it would
 eliminate much of the productivity advantages that languages that are
 supposed to be able to 'auto-parallelize' loops may have (like Sun's
 new 'Fortress').
 
 For D these things would still be explicit, like it should be for a
 GP/systems orientated language, and would help keep the compiler
 implementation effort reasonable as well. I can see support like that
 lasting well into the next decade, until compilers or runtimes are
 truly smart-enough to do a really good job at auto-parallelization
 and such. That is, if the syntax and semantics can be made straight
 forward enough that better control is worth a bit more development
 time for the general case, then I think a statically compiled D could
 stay competitive in this area.


[Sorry for vague terminology, etc., I've been up all night. :-/ ]

I'd really like to have both cooperative threads _and_ thread and/or MP 
support.

Of these two, I think cooperative threads is the bigger priority. It is 
also easier to implement (especially in a portable manner), and really 
it would behoove us to have a proper implementation in Phobos asap, and 
not only until D1.0! Especially when we have some very promising 
candidates already.

---

As an aside, I can imagine quite a few applications where I'd use _both_ 
cooperative threads and preemptive threads.

The parts that get used by cooperative threads only, would not need 
critical sections and thus be easy to write. Also, why not use them 
wherever they suffice. Only those places where both coop and preemptive 
manipulate something need critical sections and such.

So, in such an application we could strive towards a clean separation of 
the tasks that can be done with each of the two (or more) main 
("mutually pre-emptive") threads. Each could then "contain" possibly a 
number of cooperative threads -- without the whole thing becoming hard 
to manage.

What comes to mind are serious games, especially multiplayer, process 
automation (yes I'm at it right now!), robotics (even toy robotics ;-) 
), simulations, and real-time data streams control and manipulation.

Or a heavy-duty word processor, programming environment, database GUI, 
or 3D model designer. (In those, the UI could be done with cooperative 
threads. Another thread (possibly even containing cooperative 
("sub")threads) could then incrementally refine the rendition of 
objects, restructure data in the background, make "smarter" incremental 
temporary backups, etc.)

---

Being tired right now, I can't figure out which (if any) changes to the 
D language, would be unavoidable to get both of these not only useful -- 
but smooth, elegant, obvious and natural to use?
Jun 13 2006
prev sibling parent reply Dejan Lekic <dejan nu6.org> writes:
Dave, i have thought of your StackThreads library too. IMHO there is no need
for such thing, for average D programmer. Sure, i could be wrong. :) - I
have no time to talk about reasons as i rush to go to work now. :)

Kind regards - btw. i like StackThreads!
Jun 08 2006
parent Dave <Dave_member pathlink.com> writes:
Dejan Lekic wrote:

 Dave, i have thought of your StackThreads library too. IMHO there is no need
 for such thing, for average D programmer. Sure, i could be wrong. :) - I
 have no time to talk about reasons as i rush to go to work now. :)
 
 Kind regards - btw. i like StackThreads!
 


I wish I could take credit for it, but I can't :) A Mr. Lysenko wrote it 
(credits are here): http://assertfalse.com/ <g>

Frankly I haven't tried them out, but I think the idea has merit. I'll 
defer to the real experts on threading in this group as to the best way 
to approach things.

The reason I brought it up is: if somewhat of a re-design is done, it 
*may* make sense to look into basing it on something other than kernel 
threads - but then again maybe not (as Sean describes in a previous post).
Jun 09 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <e6abkk$1i2d$1 digitaldaemon.com>, Dejan Lekic says...

Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
failed! :)


I'm a guy. Some people call me Justin, but jcc7 is what I go by around here. ;)

You're welcome. I found it quickly with the search box at
http://www.digitalmars.com/d/index.html

jcc7
Jun 09 2006