John Reimer wrote:
> [snip]
> 
> Probably more history here than you, but it was kind of fun looking back on it.  If anyone sees some inaccurancies, be sure to correct.
> 
> -JJR

"inaccurancies" should be "inaccuracies".

:P

Thanks for the look back.

  -- Daniel

Hello Daniel,

> John Reimer wrote:
> 
>> [snip]
>> 
>> Probably more history here than you, but it was kind of fun looking
>> back on it.  If anyone sees some inaccurancies, be sure to correct.
>> 
>> -JJR
>> 
> "inaccurancies" should be "inaccuracies".
> 
> :P
> 
> Thanks for the look back.
> 
> -- Daniel
> 


lol... thanks :) 

-JJR

Hello Daniel,

> John Reimer wrote:
> 
>> [snip]
>> 
>> Probably more history here than you, but it was kind of fun looking
>> back on it.  If anyone sees some inaccurancies, be sure to correct.
>> 
>> -JJR
>> 
> "inaccurancies" should be "inaccuracies".
> 
> :P
> 
> Thanks for the look back.
> 
> -- Daniel
> 


Incidentally for those that don't remember Daniel Keep... he's another one of "those guys". ;)

Daniel, I ran across one of your contributions the other day:  

http://prowiki.org/wiki4d/wiki.cgi?DanielKeep/TextInD

I recall the long discussion on UTF/Unicode back then.  Nice wiki page. :)

-JJR

John Reimer wrote:
> Hello Daniel,
> 
>> John Reimer wrote:
>>
>>> [snip]
>>>
>>> Probably more history here than you, but it was kind of fun looking
>>> back on it.  If anyone sees some inaccurancies, be sure to correct.
>>>
>>> -JJR
>>>
>> "inaccurancies" should be "inaccuracies".
>>
>> :P
>>
>> Thanks for the look back.
>>
>> -- Daniel
>>
> 
> 
> Incidentally for those that don't remember Daniel Keep... he's another one of "those guys". ;)
> 
> Daniel, I ran across one of your contributions the other day: http://prowiki.org/wiki4d/wiki.cgi?DanielKeep/TextInD
> 
> I recall the long discussion on UTF/Unicode back then.  Nice wiki page. :)
> 
> -JJR

I'm surprised you didn't call me out on the evil monster that is Tango's Variant type.  Or the Zip code.  I really need to find time to go through all the bugs against that stuff and fix them all...

 -- Daniel

John Reimer wrote:

> Hello tim,
> 
>> On Sun, 04 Jan 2009 01:40:03 +1300, John Reimer <terminal.node@gmail.com>  wrote:
>> 
>>> Hello Don,
>>> 
>>>> Tim M wrote:
>>>> 
>>>>> On Sat, 03 Jan 2009 08:17:17 +1300, Michael P. <baseball.mjp@gmail.com> wrote:
>>>>>> Okay, so right now, I'm making a small game(Mario) using DAllegro.
>>>>>> I
>>>>>> use build, and every time, I have to type this in to compile my
>>>>>> progress:
>>>>>> build mario alleg.lib
>>>>>> Now, I know it's not a lot of typing. But considering I type mario
>>>>>> wrong every so often, and I generally want to execute it after,
>>>>>> assuming there is not compiler errors, it takes time.
>>>>>> In a .bat file right now, I have this:
>>>>>> build mario alleg.lib
>>>>>> mario
>>>>>> But, mario will execute even if there are errors found by dmd.
>>>>>> Is there anything that I can use to see if errors were found, and
>>>>>> if
>>>>>> there isn't, execute it, and if there is, don't execute it?
>>>>>> DMD1.036, Windows XP, Build/Bud 3.04
>>>>> I thought everyone used dsss with d now. http://dsource.org/projects/dsss.
>>>> No way! On Windows, bud is much better. dsss can't build dlls, for example, which is a blocker for me. It also seems to be based around the flawed concept that you have a small number of build configurations.
>>>> 
>>> Yes, I think bud is still quite good on windows (and faster than dsss),  even though I don't use it.  But there's no replacing dsss on linux at  the moment. It's nice to have the cross-platform option of dsss on win32  too.
>>> 
>>> That said, if bud worked (easily) on linux, I might actually go back to  using it again, since dsss doesn't seem to be going anywhere and recent  releases have been getting slower and bulkier (possibly due to the  combined effect of recent dmd releases). :-(
>>> 
>>> -JJR
>>> 
>> Could you both explain a bit more about this as dsss says it is based on  rebuild and rebuild is based on bud. So I though that dsss > rebuild > bud.
>> 
> 
> 
> Here's a little history:
> 
> Bud (aka build) is a utility originally developed and still (I think)
> maintained
> by Derek Parnell.  Derek developed it (now probably beyond original
> recognition)
> from a tiny tool called dmake (see
> http://prowiki.org/wiki4d/wiki.cgi?Dmake) that was offered to the
> community around 2004 by Helmut Leitner (who doesn't appear to hang around
> D much anymore even though he seems to still maintain the wiki4d site).
> 
> dmake, in turn, borrowed significantly from Burton Radons' D tool called
> 'digc,' which was originally part of the very first significant D GUI
> project
> called dig (see http://www.opend.org/dig/index.html).  This was way back
> circa 2003, I think.  Burton, a prolific and guru-class D programmer (who
> has had a fair bit of influence on the D language itself), still pops in
> here now and again just to unsettle things with his clever D creations
> that he apparently still works on in secret. :)
> 
> Bud expanded the original dmake with many more options.  A port to linux was also created, but it never caught on very well, I think partly because Derek was not keen on Linux development.  Anyway, build was always problematic on linux, such that it is now mostly recoginized for its very good win32 platform capabilites.
> 
> DSSS appeared when Gregor Richards came into the D scene.  Basically, when
> Gregor came here, he brought with him experience developing a universal
> package system for linux distributions (among other things) see
> http://oblisk.codu.org.
>  Gregor was (and is) another one of those gifted and prolific development
> gurus that D tends to attract.  Many of us had been discussing how much D
> needed improved build facilities for multiple platforms.  Something seemed
> to click and in 2006, Gregor had released an early version of dsss which
> was basically a somewhat independent perspective on a "build/bud" tool but
> with a much broader purpose than just building software.  It was a net
> installer,
> a source builder, and a package manager (almost) all in one.  The only
> major
> thing lacking was package version control.  But he added some very simple
> but ingenious naming conventions for D object files and libraries that now
> should be considered mandatory for all D development.
> 
> The major difference with dsss that made it such a contrast from Derek's
> build was that the underlying "rebuild" tool made use of the whole Dmd
> frontend
> in order to parse source files accurately for dependencies.  Despite the
> double overhead, dsss still managed to be fast (at least during the early
> versions), but obviously not as fast as "build" which resorted to very
> simple
> parsing techniques for import statements.  There certainly were advantages
> and disadvanatages to this approach.  However, build's simplicity has
> actually caused it's attraction to grow again, as the contrast of dsss's
> complexity
> begins to show the benefits of a lighter design.  Future versions of dsss,
> I think, were going to adopt a different design approach as a result of
> this.
> 
> Later revisions added more and more great features (nothing that
> particularly weighed down it's rebuild component), including excellent
> support for both windows and linux, multiple compiler configurations,
> multiple "standard"
> library configurations (basically extreme customizability).  It pretty
> much
> became the defacto standard build tool for D.  Since then, the project has
> began to languish for various reasons, some related to the author's
> business with school and others relating to interaction difficulties with
> the dmd
> compiler technology.  There were problems with the dmd compile system that
> forced Gregor to make the dsss build process much slower (see oneatatime
> compile option) in the interest of stability. Nonetheless, version 0.75
> still
> seems to be the best version to use as of now.  More recent versions seem
> to be unbearably slow due to the effect of recent frontend dmd code.
> 
> There is still tremendous potential to improve these tools, but I think we're just waiting for the next wave of inspiration to fall on someone here. :)
> 
> Probably more history here than you, but it was kind of fun looking back on it.  If anyone sees some inaccurancies, be sure to correct.
> 
> -JJR

Sometimes people post interesting tidbits fit for the wiki in here ;)

Daniel Keep wrote:
> I'm surprised you didn't call me out on the evil monster that is Tango's Variant type.  Or the Zip code.  I really need to find time to go through all the bugs against that stuff and fix them all...

Tango's Variant works for anything you give it. That's a bit more than I can say for Phobos' Variant.

Tim M wrote:
> 
>> No way! On Windows, bud is much better. dsss can't build dlls, for example, which is a blocker for me. It also seems to be based around the flawed concept that you have a small number of build configurations.
> 
> 
> GC'd memory and DLL just don't go well together. I use C++ for my dlls but D for the main apps now. It's just about ok for single threaded. Most of the time I have to write dlls for existsing apps that I have no source for so thats why I can't use ddl either.

I go the other way around -- app is in C++, DLLs are in D. The API is entirely extern(C).

== Quote from Don (nospam@nospam.com)'s article
> Tim M wrote:
> >
> >> No way! On Windows, bud is much better. dsss can't build dlls, for example, which is a blocker for me. It also seems to be based around the flawed concept that you have a small number of build configurations.
> >
> >
> > GC'd memory and DLL just don't go well together. I use C++ for my dlls but D for the main apps now. It's just about ok for single threaded. Most of the time I have to write dlls for existsing apps that I have no source for so thats why I can't use ddl either.
> I go the other way around -- app is in C++, DLLs are in D. The API is
> entirely extern(C).

I think the extern (C) approach is safest, but I may as well mention that DMD 2.0 / Phobos does provide limited support for a D app that uses objects defined in a D DLL.  The Runtime.loadLibrary() call will override the DLLs GC to use the app's GC instead, so passing objects across the DLL boundary becomes possible.  I'm personally not terribly fond of this idea because it has a bunch of issues, but it *does* exist in the DMD distro today.

Oh, I suppose I should mention that multithreaded DLLs (ie DLLs that spawn their own threads) are not supported at the moment.  This can change if necessary, but it will mean yet more complex machinery in some parts of the runtime that are already pretty dicey.  Truth be told I'd rather just do away with the whole idea altogether.


Sean