Ant wrote:
> So, for now "import dui.All" is meaningless to leds…

At the risk of the changing the subject, have you thought of making use of Lars Ivar Igesund's dependency checker?
http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund

I've only briefly used it, but it seems to work (and the D community really needs tools like this).  And I love the price:
 * Permission to use, copy, modify, distribute and sell this software
 * and its documentation for any purpose is hereby granted without fee,
 * provided that the above copyright notice appear in all copies and
 * that both that copyright notice and this permission notice appear
 * in supporting documentation. It is provided "as is" without express
 * or implied warranty.

-- 
Justin
http://jcc_7.tripod.com/d/

In article <btfurs$2u1o$1@digitaldaemon.com>, J C Calvarese says...
>
>Ant wrote:
>> So, for now "import dui.All" is meaningless to leds…
>
>At the risk of the changing the subject, have you thought of making use of Lars Ivar Igesund's dependency checker? http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund
>
>I've only briefly used it, but it seems to work (and the D community really needs tools like this).  And I love the price:
>  * Permission to use, copy, modify, distribute and sell this software
>  * and its documentation for any purpose is hereby granted without fee,
>  * provided that the above copyright notice appear in all copies and
>  * that both that copyright notice and this permission notice appear
>  * in supporting documentation. It is provided "as is" without express
>  * or implied warranty.
>
>-- 
>Justin
>http://jcc_7.tripod.com/d/

Initially yes, that's why I looked at it
and made some suggestions.
but I ended up integrating every thing into
my code browser parser.

see the first post on this thread to understant what
I mean by that. (or lets move this conversation
to the leds group before someone complains about it...:(

Ant

On Wed, 07 Jan 2004 04:54:55 +0000, Ant wrote:

> In article <btfurs$2u1o$1@digitaldaemon.com>, J C Calvarese says...
>>
>> have you thought of making use
>>of Lars Ivar Igesund's dependency checker? http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund
>>
>>-- 
>>Justin
>>http://jcc_7.tripod.com/d/
> 
> Initially yes, that's why I looked at it
> and made some suggestions.
> but I ended up integrating

I don't mean his code... I mean the possibility
of browsing the import dependencies tree...
No illigal use of anyone else's code.

Ant

Ant wrote:
> In article <btfurs$2u1o$1@digitaldaemon.com>, J C Calvarese says...
> 
>>Ant wrote:
>>
>>>So, for now "import dui.All" is meaningless to leds…
>>
>>At the risk of the changing the subject, have you thought of making use of Lars Ivar Igesund's dependency checker?
>>http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund
>>
...
> Initially yes, that's why I looked at it
> and made some suggestions.
> but I ended up integrating every thing into
> my code browser parser.
I thought you had noticed it.  (I guess I just wanted to make sure you hadn't forgotten about it.)

> 
> see the first post on this thread to understant what
> I mean by that. 
After re-reading your original post (again), I can see better where you're coming from.  I guess part of the challenge is that when the goal is so ambitious it's hard to draw boundaries and the one-class/one-file idea could made life much easier for the code lookup routine (probably at small cost).

> (or lets move this conversation
> to the leds group before someone complains about it...:(
I think we should be able to talk about D code in the D group. :)

> 
> Ant


-- 
Justin
http://jcc_7.tripod.com/d/

In article <btg4r9$6jp$1@digitaldaemon.com>, J C Calvarese says...
>
>Ant wrote:
>> In article <btfurs$2u1o$1@digitaldaemon.com>, J C Calvarese says...
>> 
>>>Ant wrote:
>>>
>>>>So, for now "import dui.All" is meaningless to leds…
>>>
>>>At the risk of the changing the subject, have you thought of making use of Lars Ivar Igesund's dependency checker? http://www.wikiservice.at/d/wiki.cgi?LarsIvarIgesund
>>>
>...
>> Initially yes, that's why I looked at it
>> and made some suggestions.
>> but I ended up integrating every thing into
>> my code browser parser.
>I thought you had noticed it.  (I guess I just wanted to make sure you hadn't forgotten about it.)
>
>> 
>> see the first post on this thread to understant what
>> I mean by that.
> After re-reading your original post (again)

is it that badly written... :{  :)

>, I can see better where
> you're coming from.  I guess part of the challenge is that when the goal is so ambitious it's hard to draw boundaries and the one-class/one-file idea could made life much easier for the code lookup routine (probably at small cost).

maybe it's not as bad as I thought.
dui has 51000 lines and dmd compiles it
in about 3 seconds (less after the first time)
so even if code lookup has to parse most of the
files it should be fast enough.

But that's not only for the automatic parsers.
It's for the human users also.
I used to work on a system where the source files
were named TCS0234, TCS2567, TCS1103
(oops... now you know how old I am)
the really sad thing is that you end up memorizing
which number correspond to what routines...

Ant

A friend of mine said: "Yes".
But his opinion might be biased - he studies there. :)
-- 
Jan-Eric Duden
"C" <dont@respond.com> wrote in message
news:bter7u$14gb$1@digitaldaemon.com...
> This is way off topic, but in this month's CUJ they have an article about tail call optimization, in it he sites a refrence for a thesis written at Technische Universitat Munchen :).
>
> Is it a pretty good school ?
>
> C
>
>
> "Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:btei1o$m4q$1@digitaldaemon.com...
> > Ant wrote:
> > > In article <bteg8c$jdb$1@digitaldaemon.com>, Hauke Duden says...
> > >
> > >>Ant wrote:
> > >>
> > >>>Here are some rules I'd like to propose to for OO projects in D
> > >>>(nothing new) or, if you will, the "doo" standard:
> > >>>- 1 source file defines 1 public class or 1 public struct
> > >>>  or 1 public interface
> > >>>- the module name is the same as the class, struct or interface
> > >>>  it defines, this means the module name will start
> > >>>  with a capital letter.
> >
> > I'd say this is evil. Because of filesystem issues, module names should be left lower case. That is, for a class "MagnifficentWalter" i would make a module "magnifficent_walter".
> >
> > >>I would support that, if it wasn't for one thing: the D "friend"
rules.
> > >>Since two classes that need friend access to each other have to be in the same module, you are forced to also put them into the same file.
> >
> > Hmmm... Even Delphi has an {$INCLUDE} lexer directive.
> >
> > > hmmmm... friend. Never though of that. That's because I never
> > > use it. Is it really necessary?
> > > When is it and essential construct to solve something?
> > > Isn't that just a shortcut or workaround on the general rule
> > > of encapsulation?
> >
> > It is a shortcut to keep encapsulation intact.
> >
> > > I remember friends from C++ never used it in java.
> >
> > Did they make all public in Java?
> >
> > >>Another solution would be to update the friend rule to make friends a package-level concept (as in JAVA) instead of a module level one.
> >
> > Another solution: declare another module as a friend.
> >
> > -eye
> >
>
>

>What file systems? we're talking 21st century here...
>even the default file system for win98 (what ever that is)
>we never had any problem with the java standard.
>I remember now. If move your app from a case insensitive
>fs to another case sensitive you might have problems.

UNIX is case sensitive
Windows is case insensitive but is case preserving
I assume MacOS X follows the UNIX standard (I have never used it)

only DOS would convert everything to uppercase (hopefully no-one is still using that for serious software development)

We currently have no problems with our mixed UNIX and Windows development environments at work, in C/C++ if you use #include "MyHeader.h" in the code don't name the actual file "myheader.h"

Ant wrote:

>In article <btehka$lbl$1@digitaldaemon.com>, Lewis says...
>  
>
>>looks good ant, do you plan on a windows version also?
>>regards
>>lewis
>>    
>>
>
>sure.
>
>
>  
>
Please announce this when you do, as I can't wait to have a look see.

In article <btjuof$2um9$1@digitaldaemon.com>, J Anderson says...
>
>Ant wrote:
>
>>In article <btehka$lbl$1@digitaldaemon.com>, Lewis says...
>> 
>>
>>>looks good ant, do you plan on a windows version also?
>>>regards
>>>lewis
>>
>>sure.
>>
>Please announce this when you do, as I can't wait to have a look see.

I was "finishing" the code browser/lookup first.

This is not an easy decision! The problem is that each day
I delay the windows version I'm loosing market share to the
other D IDE ;)
But if I release it too soon the damage might be even worst (?) :(

Now I'm curious, What makes leds so appeling for windows use? I understand that linux user would like to try it but for windows you have DIDE.

anyway I see 3 big advantages of leds over DIDE
- it's open source
- it's written in D
- it's available for linux (and soon windows)

leds http://leds.sourceforge.net
other D IDE http://www.atari-soldiers.com

Ant

Ant wrote:

>In article <btjuof$2um9$1@digitaldaemon.com>, J Anderson says...
>  
>
>>Ant wrote:
>>
>>    
>>
>>>In article <btehka$lbl$1@digitaldaemon.com>, Lewis says...
>>> 
>>>
>>>      
>>>
>>>>looks good ant, do you plan on a windows version also?
>>>>regards
>>>>lewis
>>>>        
>>>>
>>>sure.
>>>
>>>      
>>>
>>Please announce this when you do, as I can't wait to have a look see.
>>    
>>
>
>I was "finishing" the code browser/lookup first.
>
>This is not an easy decision! The problem is that each day
>I delay the windows version I'm loosing market share to the
>other D IDE ;)
>But if I release it too soon the damage might be even worst (?) :(
>
>Now I'm curious, What makes leds so appeling for windows use?
>I understand that linux user would like to try it but for
>windows you have DIDE.
>
>anyway I see 3 big advantages of leds over DIDE
>- it's open source
>- it's written in D
>- it's available for linux (and soon windows)
>
>  
>
Exactly.  Once I start using it, and I don't like something I can make the changes.  DIDE is being written by one person, which I see these problems.
- When that person leaves the project the project dies.
- There is a potential for leds to move at a much faster pace then DIDE, once people start contributing.

That's not to say I don't like DIDE, though.

>leds http://leds.sourceforge.net
>other D IDE http://www.atari-soldiers.com
>
>Ant
>  
>