• Robert Fraser (1/1) Jun 03 2007 DSSS seems like a great tool, but only a very small subset of available ...
• Gregor Richards (14/15) Jun 03 2007 How many times have I asked myself this question X-D
• Bill Baxter (12/36) Jun 03 2007 I think it just takes time. I've only started tinkering around with
• Derek Parnell (8/12) Jun 03 2007 Remind me again ... what's DSSS?
• janderson (4/28) Jun 03 2007 I think DSSS needs to come setup with any D specific IDEs. Its the best...
• Pragma (13/37) Jun 04 2007 All I can offer are my personal experiences with trying to DSSS-ify a fe...
• Lars Ivar Igesund (7/13) Jun 04 2007 Why can't you use "dsss build" and "dsss install" ?
• Pragma (5/16) Jun 04 2007 Hrm... maybe I missed an update somewhere along the way. Does it still ...
• Gregor Richards (22/40) Jun 04 2007 Yes, it still only looks in the current path. I haven't added your -file...
• Pragma (14/60) Jun 04 2007 Good point. Let me ask you this then: is it possible to pass -version t...
• torhu (31/32) Jun 04 2007 For us Windows users, tools like these are a bit foreign. Probably in
• Lutger (9/19) Jun 04 2007 I have not started using DSSS for a while for the same reasons, I was
• Dan (3/4) Jun 04 2007 I too am interested in DSSS. I'm a bit of a perfectionist... I've spent...
• Jason House (4/8) Jun 04 2007 I'd like that feature too. In addition, I have scripts that generate d
• Jason House (4/5) Jun 04 2007 Looking at the docs for 0.65 (README.overview), I see it says that it's
• Derek Parnell (11/17) Jun 04 2007 As far as I know, Gregor took some of the concepts in Bud and wrote Rebu...
• Gregor Richards (4/14) Jun 04 2007 Outdated documentation bug. Thanks for pointing that out. It does indeed...

Robert Fraser <fraserofthenight gmail.com> writes:

DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

Gregor Richards <Richards codu.org> writes:

Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

How many times have I asked myself this question X-D

The unfortunate truth is that most of the tools installable via DSSS 
aren't even DSSS-maintained. I made the dsss.conf files for them and 
maintain said dsss.conf files as patches.

Basically, it's a chicken-and-egg problem. Because D grew up to where it 
is with no standard system for installation of libraries, trying to 
force people to use one now is a bit difficult. I guess all I can say 
is: If you have some specific library you'd like added to `dsss net`, 
write the dsss.conf file yourself, and I can add it as a patch. It's a 
gross, temporary solution, but at least it would allow dependent 
libraries to be fully DSSS'd.

If somebody wants to start a DSSS advocacy group ... ^^

  - Gregor Richards

Bill Baxter <dnewsgroup billbaxter.com> writes:

Gregor Richards wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

 
 How many times have I asked myself this question X-D
 
 The unfortunate truth is that most of the tools installable via DSSS 
 aren't even DSSS-maintained. I made the dsss.conf files for them and 
 maintain said dsss.conf files as patches.
 
 Basically, it's a chicken-and-egg problem. Because D grew up to where it 
 is with no standard system for installation of libraries, trying to 
 force people to use one now is a bit difficult. I guess all I can say 
 is: If you have some specific library you'd like added to `dsss net`, 
 write the dsss.conf file yourself, and I can add it as a patch. It's a 
 gross, temporary solution, but at least it would allow dependent 
 libraries to be fully DSSS'd.
 
 If somebody wants to start a DSSS advocacy group ... ^^
 
  - Gregor Richards

I think it just takes time.  I've only started tinkering around with 
DSSS recently and figuring out how to write DSSS.conf files.  (The new 
developer-oriented docs are very helpful by the way).   People who 
started developing their projects a long while ago already have 
solutions worked out for compiling their code, and for the most part, 
nobody is interested in rewriting a build system that works unless they 
really really have to.

But I think it's likely newer projects (and newer D developers) will 
adopt dsss from the start.  ... As long as someone remembers to ask 
every month or so why dsss/rebuild aren't more popular than they are.  :-)

--bb

Derek Parnell <derek nomail.afraid.org> writes:

On Sun, 03 Jun 2007 16:30:03 -0700, Gregor Richards wrote:

 Robert Fraser wrote:
 DSSS seems like a great tool... ANy ideas on why it's not more widely used?

 
 How many times have I asked myself this question X-D

Remind me again ... what's DSSS?   <G>

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Author of Bud :P"
4/06/2007 2:18:19 PM

janderson <askme me.com> writes:

Gregor Richards wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

 
 How many times have I asked myself this question X-D
 
 The unfortunate truth is that most of the tools installable via DSSS 
 aren't even DSSS-maintained. I made the dsss.conf files for them and 
 maintain said dsss.conf files as patches.
 
 Basically, it's a chicken-and-egg problem. Because D grew up to where it 
 is with no standard system for installation of libraries, trying to 
 force people to use one now is a bit difficult. I guess all I can say 
 is: If you have some specific library you'd like added to `dsss net`, 
 write the dsss.conf file yourself, and I can add it as a patch. It's a 
 gross, temporary solution, but at least it would allow dependent 
 libraries to be fully DSSS'd.
 
 If somebody wants to start a DSSS advocacy group ... ^^
 
  - Gregor Richards

I think DSSS needs to come setup with any D specific IDEs.  Its the best 
way for it to succeeded.

-Joel

Pragma <ericanderton yahoo.removeme.com> writes:

Gregor Richards wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

 
 How many times have I asked myself this question X-D
 
 The unfortunate truth is that most of the tools installable via DSSS 
 aren't even DSSS-maintained. I made the dsss.conf files for them and 
 maintain said dsss.conf files as patches.
 
 Basically, it's a chicken-and-egg problem. Because D grew up to where it 
 is with no standard system for installation of libraries, trying to 
 force people to use one now is a bit difficult. I guess all I can say 
 is: If you have some specific library you'd like added to `dsss net`, 
 write the dsss.conf file yourself, and I can add it as a patch. It's a 
 gross, temporary solution, but at least it would allow dependent 
 libraries to be fully DSSS'd.
 
 If somebody wants to start a DSSS advocacy group ... ^^
 
  - Gregor Richards

All I can offer are my personal experiences with trying to DSSS-ify a few of my
projects:

I'm still finding it hard to develop reasonably complex DSSS scripts only
because there's only one possible mode of 
testing them: net install.  There's no option to execute dsss.conf from the
filesystem (via "-file <filename>" or 
somesuch), so I can't test my dsss.conf file out locally before exposing it to
the world (unless I'm mistaken).  IMO, 
that's a big problem.

Another thing that's hurting adoption is that DSSS is still left-of-center in
the D software landscape.  This is that 
chicken-and-egg problem you cite.  This tool won't become the core of anyone's
toolkit until everything they could 
possibly want is supported by it.

Other than that, the documentation has come along by leaps and bounds since you
started this, Gregor.  At first this was 
a real sticking point, but I'm just now starting to get my head around things.

-- 
- EricAnderton at yahoo

Lars Ivar Igesund <larsivar igesund.net> writes:

Pragma wrote:

 I'm still finding it hard to develop reasonably complex DSSS scripts only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

Why can't you use "dsss build" and "dsss install" ?

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Pragma <ericanderton yahoo.removeme.com> writes:

Lars Ivar Igesund wrote:
 Pragma wrote:
 
 I'm still finding it hard to develop reasonably complex DSSS scripts only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

 
 Why can't you use "dsss build" and "dsss install" ?
 

Hrm... maybe I missed an update somewhere along the way.  Does it still look
only in the current path, or can you 
specify a path for the dsss.conf file via those two methods?

-- 
- EricAnderton at yahoo

Gregor Richards <Richards codu.org> writes:

Pragma wrote:
 Lars Ivar Igesund wrote:
 Pragma wrote:

 I'm still finding it hard to develop reasonably complex DSSS scripts 
 only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

 Why can't you use "dsss build" and "dsss install" ?

 
 Hrm... maybe I missed an update somewhere along the way.  Does it still 
 look only in the current path, or can you specify a path for the 
 dsss.conf file via those two methods?
 

Yes, it still only looks in the current path. I haven't added your -file 
option for two reasons:
     1) I have no idea why it's supposed to be useful.
     2) Nobody else has asked for it.

No wait, three reasons:
     3) It becomes very ambiguous if you have a subdirectory with its 
own dsss.conf file: Then you have to answer the question "Should it look 
at that dsss.conf file, or one relative to the -file provided one?" And 
whichever way I answer that, 50% of the people who use this feature will 
think my answer is wrong. Hell, I'll think my own answer is wrong.

No! Four reasons:
     4) Having the dsss.conf file next to the source just makes sense. 
While /allowing/ it to be elsewhere is hardly /forcing/ it to be 
elsewhere, it does encourage confusion. I'd hate to see people go "well, 
I'm not sure how to integrate my Windows-only dsss.conf and my 
GNU/Linux-only dsss.conf (using version() blocks is soooooooooo 
confusing), so I'll just require you to run dsss build -file 
dsssConfDir/windows/dsss.conf"

And, I completely fail to understand how "have to modify the dsss.conf 
file in place" leads to "can't test it before exposing it to the world."

  - Gregor Richards

Pragma <ericanderton yahoo.removeme.com> writes:

Gregor Richards wrote:
 Pragma wrote:
 Lars Ivar Igesund wrote:
 Pragma wrote:

 I'm still finding it hard to develop reasonably complex DSSS scripts 
 only
 because there's only one possible mode of
 testing them: net install.  There's no option to execute dsss.conf from
 the filesystem (via "-file <filename>" or
 somesuch), so I can't test my dsss.conf file out locally before 
 exposing
 it to the world (unless I'm mistaken).  IMO, that's a big problem.

 Why can't you use "dsss build" and "dsss install" ?

 Hrm... maybe I missed an update somewhere along the way.  Does it 
 still look only in the current path, or can you specify a path for the 
 dsss.conf file via those two methods?

 
 Yes, it still only looks in the current path. I haven't added your -file 
 option for two reasons:
     1) I have no idea why it's supposed to be useful.
     2) Nobody else has asked for it.
 
 No wait, three reasons:
     3) It becomes very ambiguous if you have a subdirectory with its own 
 dsss.conf file: Then you have to answer the question "Should it look at 
 that dsss.conf file, or one relative to the -file provided one?" And 
 whichever way I answer that, 50% of the people who use this feature will 
 think my answer is wrong. Hell, I'll think my own answer is wrong.
 
 No! Four reasons:
     4) Having the dsss.conf file next to the source just makes sense. 
 While /allowing/ it to be elsewhere is hardly /forcing/ it to be 
 elsewhere, it does encourage confusion. I'd hate to see people go "well, 
 I'm not sure how to integrate my Windows-only dsss.conf and my 
 GNU/Linux-only dsss.conf (using version() blocks is soooooooooo 
 confusing), so I'll just require you to run dsss build -file 
 dsssConfDir/windows/dsss.conf"

Good point.  Let me ask you this then: is it possible to pass -version through
DSSS to the .conf file?  I'd be more than 
happy to maintain things from a single root .dsss file if I can provide
different install options in some fashion. 
Barring that, what is the recommended way to set up sub-projects that share the
same root; that's really all that I'm after.

Take DDL for instance: there's the SDK (everything), and the pre-built
utilities package. The former includes both, 
where the latter should be stand-alone.  Currently, DSSS will only let me
support the "everything" option.

There's also projects like Enki that have a similar split, as it's a binary
bundled with a runtime library for use with 
generated code.  So having the binary's sourcecode *optionally* installed would
be a plus, as to reduce confusion. 
Otherwise, your best option is to install using --prefix, which would dump the
runtime library outside the main library 
location.

 
 And, I completely fail to understand how "have to modify the dsss.conf 
 file in place" leads to "can't test it before exposing it to the world."
 
  - Gregor Richards


No worries Gregor. :)  Obviously, I'm not up to speed with DSSS yet, and have
yet to completely grok how things are 
supposed to work.  Frankly, I'm glad to be mistaken - that means I'm the only
one stuck ATM, which is a good thing for DSSS.

-- 
- EricAnderton at yahoo

torhu <fake address.dude> writes:

Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. Any ideas on why
it's not more widely used?

For us Windows users, tools like these are a bit foreign.  Probably in 
part because they are command line based, and windows is a bit limited 
in that department.  But I also like to know exactly what I'm 
downloading, where it's installed etc.  Any kind of automated 
downloading or installation makes that harder.  But it's probably a lot 
easier once you've gotten used to the tool, be it DSSS or whatever.  I 
just don't see it as worth the brain power right now.  Maybe I never 
will.  On linux, where the command line is the natural command center, I 
might have used dsss all the time, who knows.

Just having all D related downloads under D:\zips\programming\D\ on my 
HD is great, because I can just browse that folder if I can't remember 
the name of a tool or library I know I used a year ago.  It's all very 
basic and human-friendly.  Taking the time to figure out how to use a 
new debugger seems a better investment of time, I already know how to 
download files and how to build D apps without much trouble.

The only library I work on is DAllegro.  It's built by bud (considering 
switching to just batch files) on windows and gnu make on linux and OS 
X.  Maybe I'll make it retrievable through dsss net, but it seems wrong 
to require a language-specific build tool for something that's so simple 
to build.  But the download part could be a way to get more linux people 
to try it out.  Of course, having to still download the required C 
library to link with might defeat the purpose.  But maybe DSSS can do 
that to?

I don't mean to bash on dsss, I'm just explaining why I'm not using it 
myself.  Except for building Tioport SWT and tangobos, that is.  I wish 
people would explain to me why they don't use DAllegro, but I'm guessing 
the answer is "SDL for teh win".  So be it.

Maybe if DSSS' net feature was hooked up to dsource.org somehow?  It 
could download the autogenerated zips of specific revisions of the 
projects.  For all I know, this is already possible.

Lutger <lutger.blijdestijn gmail.com> writes:

torhu wrote:
 Just having all D related downloads under D:\zips\programming\D\ on my 
 HD is great, because I can just browse that folder if I can't remember 
 the name of a tool or library I know I used a year ago.  It's all very 
 basic and human-friendly.  Taking the time to figure out how to use a 
 new debugger seems a better investment of time, I already know how to 
 download files and how to build D apps without much trouble.

I have not started using DSSS for a while for the same reasons, I was 
getting along just fine with build. But it's a really nice tool. Some 
more reasons to use it:
- very easy to setup, everything is standard and transparent
- automatic dependencies: this is just awesome
- candydoc build without hassles
- simple for simple projects, but flexible if you need more

 I don't mean to bash on dsss, I'm just explaining why I'm not using it 
 myself.  Except for building Tioport SWT and tangobos, that is.  I wish 
 people would explain to me why they don't use DAllegro, but I'm guessing 
 the answer is "SDL for teh win".  So be it.

SDL for teh win, sorry :)

Dan <murpsoft hotmail.com> writes:

Robert Fraser Wrote:

 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

I too am interested in DSSS.  I'm a bit of a perfectionist... I've spent closer
to 80 hours just tinkering with the architecture of Walnut 2.x; my issue would
be with version control as well.  I would need it to allow me to produce
several executables from the same source - a batch interpreter, an interactive
interpreter, a dll com server jscript replacement, and a dll/lib spidermonkey
replacement.  All of those ought to use the same sources.

Is that possible?

Jason House <jason.james.house gmail.com> writes:

Dan wrote:
 I too am interested in DSSS.  I'm a bit of a perfectionist... I've spent
closer to 80 hours just tinkering with the architecture of Walnut 2.x; my issue
would be with version control as well.  I would need it to allow me to produce
several executables from the same source - a batch interpreter, an interactive
interpreter, a dll com server jscript replacement, and a dll/lib spidermonkey
replacement.  All of those ought to use the same sources.

I'd like that feature too.  In addition, I have scripts that generate d 
files.  Before I can get rid of my trusty makefiles, I need something to 
allow me to do that easily.

 
 Is that possible?
 

Jason House <jason.james.house gmail.com> writes:

Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

Looking at the docs for 0.65 (README.overview), I see it says that it's 
based on bud.  Is that correct?  Are bud and rebuild the same thing, or 
did the project switch over to using bud instead of rebuild?

Derek Parnell <derek nomail.afraid.org> writes:

On Mon, 04 Jun 2007 22:08:49 -0400, Jason House wrote:

 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of available D
libraries are installable via it. I can see it turning into something like
CPAN, where you can easily get a module and its required dependencies, without
really having to worry about version compatibility, etc, etc. ANy ideas on why
it's not more widely used?

 
 Looking at the docs for 0.65 (README.overview), I see it says that it's 
 based on bud.  Is that correct?  Are bud and rebuild the same thing, or 
 did the project switch over to using bud instead of rebuild?

As far as I know, Gregor took some of the concepts in Bud and wrote Rebuild
from the DigitalMars C++ source code of the D-frontend.

They are not the same product even though they overlap with some of their
functionality. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
5/06/2007 1:20:41 PM

Gregor Richards <Richards codu.org> writes:

Jason House wrote:
 Robert Fraser wrote:
 DSSS seems like a great tool, but only a very small subset of 
 available D libraries are installable via it. I can see it turning 
 into something like CPAN, where you can easily get a module and its 
 required dependencies, without really having to worry about version 
 compatibility, etc, etc. ANy ideas on why it's not more widely used?

 
 Looking at the docs for 0.65 (README.overview), I see it says that it's 
 based on bud.  Is that correct?  Are bud and rebuild the same thing, or 
 did the project switch over to using bud instead of rebuild?

Outdated documentation bug. Thanks for pointing that out. It does indeed 
use rebuild.

  - Gregor Richards