Jump to page: 1 2
Thread overview
Why isn't DSSS ('s net portion) more widely used?
Jun 03, 2007
Robert Fraser
Jun 03, 2007
Gregor Richards
Jun 03, 2007
Bill Baxter
Jun 04, 2007
Derek Parnell
Jun 04, 2007
janderson
Jun 04, 2007
Pragma
Jun 04, 2007
Lars Ivar Igesund
Jun 04, 2007
Pragma
Jun 04, 2007
Gregor Richards
Jun 04, 2007
Pragma
Jun 04, 2007
torhu
Jun 04, 2007
Lutger
Jun 05, 2007
Jason House
Jun 05, 2007
Derek Parnell
Jun 05, 2007
Gregor Richards
June 03, 2007
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?
June 03, 2007
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
June 03, 2007
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
June 04, 2007
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
June 04, 2007
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
June 04, 2007
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.
June 04, 2007
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 :)
June 04, 2007
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
June 04, 2007
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
June 04, 2007
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
« First   ‹ Prev
1 2