www.digitalmars.com         C & C++   DMDScript  

D - D OO projects and Intellisense and leds

reply Ant <Ant_member pathlink.com> writes:
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.
- Imports are declared inside the class body except for
  the super class and implemented interfaces

(When I started changing leds to comply with these rules
I manage to segfault the compiler 0.77. I revert to the
previous version but keept a backup of that one)

Are out there enough OO guys to start an OO D movement?
I guess it's too soon for that.

I started intellisense for leds. For now I have some
limitations when searching for definitions outside
the current source file. I search only for files
with the same name as the type of the current object.

So, for now "import dui.All" is meaningless to leds…

Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.

as intellisense is marked TM on the MS pages
I'm calling it 'code lookup'.

My code lookup is based on my code browser,
so all the limitation of the code browser
are reflected. (for instance the 'invariante'
and in general any block "{}" that's
not a function will confuse the code browser)

See how it looks like at the leds screenshots page.

http://leds.sourceforge.net

If you decide to try leds beware that there are some
simple limitations (at least for now) on a project
directory tree naming that might not be explicit on the manual.
Please direct any questions to the leds discussion group.

you can use leds to edit a 1 file project and compile it
and run it with one click hummm... I gonna change that
to allows "implict projects" or "auto projects" where
all the files opened and not associated with any other
project will be compiled together.
Seems like a good idea for small tests.

Remember that although leds is used to
develop leds it is alpha quality only.

The code browser and code lookup are the last two major
features I intende to include on leds before
making in a bit more configurable and ready for all.

Ant
dui page (nothing new) http://dui.sourceforge.net
Jan 06 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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 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. I posted about this a few months ago, because I think it is more than a minor problem. I hate source files with thousands of lines - it just gets hard to find your way around in them. It should be up to the programmer how he wants to organize his source files! In that post I proposed to allow directory-modules, where all files in a directory are part of the same module. 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. I.e. introduce a package protection level and allow all classes from the same package to access package-members of other classes in the same package. Hauke
Jan 06 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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 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.
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? I remember friends from C++ never used it 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.
If friends are really necessary I vote for that. Ant
Jan 06 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
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
Jan 06 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <btei1o$m4q$1 digitaldaemon.com>, Ilya Minkov says...
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".
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. I've no idea how that works for languages like japanese...?
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?
As I said I don't really use it but I believe that protected and default (no access modifier) members are accessible from the entire package (?)
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.
Seems good. It's probably better can't really say. Ant
Jan 06 2004
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Ant wrote:
I remember friends from C++ never used it in java.
Did they make all public in Java?
As I said I don't really use it but I believe that protected and default (no access modifier) members are accessible from the entire package (?)
Java has 4 protection levels: public, package, protected and private. "package" protection is the default. It means that all other classes from the same package may access the member, but no one else. Hauke
Jan 06 2004
prev sibling parent Mark T <Mark_member pathlink.com> writes:
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"
Jan 07 2004
prev sibling next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Ilya Minkov wrote:
 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.
Hmmm. I think that would be the easiest way to solve this problem. Not necessarily the most elegant one, but oh well - let's stay pragmatic ;). How about it, big W? Hauke
Jan 06 2004
prev sibling parent reply "C" <dont respond.com> writes:
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
Jan 06 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
C wrote:
 This is way off topic, but in this month's CUJ they have an article abo=
ut
 tail call optimization, in it he sites a refrence for a thesis written =
at
 Technische Universitat Munchen :).
Nice. I'm quite surprised someone would poke on my domain adress. ;)
 Is it a pretty good school ?
I'm just in the 3rd semester, but i would say so. At least compared to=20 Ludwig Maximillian University (LMU), which is also in M=FCnchen, and=20 offers almost all the same study courses and many more. LMU is good for=20 its non-technical faculties, such as law, biology, medicine, and so on.=20 We also have a medical faculty, but even it is technologically biased.=20 But my opinion must be biased as well. Ask those studying at the LMU. :> = I would say TUM has somewhat more attention payed to students, and the=20 professors are quite active in research. University of Technology (TUM) has been slowly moving way outside the=20 city, so i believe all the lazy people are probably going to the LMU=20 now. ;) Apart from me. I have severe problems with motivation. ;(=20 Doesn't depend on the university though, it's just heavy baggage from my = former and pre-former lives. -eye
Jan 06 2004
prev sibling parent "Jan-Eric Duden" <jeduden whisset.com> writes:
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
Jan 07 2004
prev sibling parent "Ben Woodhead" <ben dragondoor.com> writes:
Hey, I have atleast one purpose for it. I created an Application Framework
that defined WinMain as a friend (since its not a class) so that when using
my App Framework, everthing was being handled in the Application Class but
that ment allowing WinMain (on a windows platform) and main to have access
to the Applications Framework private data when it was first started.
This made for a really nice way to work in more then one os and make it a
lot like java. Instead of needing a main you simply overload the Application
Framework and define the sections that you want. Nice and easy.

Ben

"Ant" <Ant_member pathlink.com> wrote in message
news:bteh52$kma$1 digitaldaemon.com...
 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 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.
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? I remember friends from C++ never used it 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.
If friends are really necessary I vote for that. Ant
Jan 06 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
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 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.
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? I remember friends from C++ never used it 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.
If friends are really necessary I vote for that. Ant
Jan 06 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
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 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.
hmmmm... friend. Never though of that. That's because I never use it. Is it really necessary?
Yes, for some things it is. For example, imagine a Tree class that wants to return an enumerator object. The tree class doesn't expose the internal data pointers, but you need the enumerator to access them directly (say, because of performance). That's one of the cases where friends can be useful.
 Isn't that just a shortcut or workaround on the general rule
 of encapsulation?
No, it allows for better encapsulation. The alternative is usually to make the members public, which allows everyone to access them, not just that one other class that needs it. I think the Java way (package access) is better than the C++ friend concept. It is less specific, i.e. more classes gain access to a member than really necessary, but it is also easier to manage and understand. Also, it can be argued that you do not need to protect a classes member that fiercely against elements of the same package, because usually they are all under the same designer's control. Hauke
Jan 06 2004
prev sibling next sibling parent reply Lewis <dethbomb hotmail.com> writes:
looks good ant, do you plan on a windows version also?
regards
lewis

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.
 - Imports are declared inside the class body except for
   the super class and implemented interfaces
 
 (When I started changing leds to comply with these rules
 I manage to segfault the compiler 0.77. I revert to the
 previous version but keept a backup of that one)
 
 Are out there enough OO guys to start an OO D movement?
 I guess it's too soon for that.
 
 I started intellisense for leds. For now I have some
 limitations when searching for definitions outside
 the current source file. I search only for files
 with the same name as the type of the current object.
 
 So, for now "import dui.All" is meaningless to leds…
 
 Due to the flexibility on naming D modules I'm
 Very happy that D doesn't import all the modules
 in the current 'package' automatically.
 That would make a nightmare to find out the
 source file with a particular class definition.
 
 as intellisense is marked TM on the MS pages
 I'm calling it 'code lookup'.
 
 My code lookup is based on my code browser,
 so all the limitation of the code browser
 are reflected. (for instance the 'invariante'
 and in general any block "{}" that's
 not a function will confuse the code browser)
 
 See how it looks like at the leds screenshots page.
 
 http://leds.sourceforge.net
 
 If you decide to try leds beware that there are some
 simple limitations (at least for now) on a project
 directory tree naming that might not be explicit on the manual.
 Please direct any questions to the leds discussion group.
 
 you can use leds to edit a 1 file project and compile it
 and run it with one click hummm... I gonna change that
 to allows "implict projects" or "auto projects" where
 all the files opened and not associated with any other
 project will be compiled together.
 Seems like a good idea for small tests.
 
 Remember that although leds is used to
 develop leds it is alpha quality only.
 
 The code browser and code lookup are the last two major
 features I intende to include on leds before
 making in a bit more configurable and ready for all.
 
 Ant
 dui page (nothing new) http://dui.sourceforge.net
 
 
Jan 06 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <btehka$lbl$1 digitaldaemon.com>, Lewis says...
looks good ant, do you plan on a windows version also?
regards
lewis
sure.
Jan 06 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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.
Jan 08 2004
parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 08 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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
  
Jan 08 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I think DIDE and leds should define a common plug-in architecture - D beans,
if you like - such that people can write modules for, and thereby expand,
the powers of both.

I see advantages and disadvantages to open-source and closed-source, but if
both have an extensible architecture, then it's win-win. If they share that
architecture, it's win-win-win


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:btk3hb$4fh$1 digitaldaemon.com...
 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
Jan 08 2004
next sibling parent reply "C" <dont respond.com> writes:
Hmm cool idea!

SciTE now now supports scripting with LUA.  As soon as that is 100% I'll
incoporate it.  If we could define a common interface through LUA , then
that would be awesome I think.

C
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btl0hp$1g9q$1 digitaldaemon.com...
 I think DIDE and leds should define a common plug-in architecture - D
beans,
 if you like - such that people can write modules for, and thereby expand,
 the powers of both.

 I see advantages and disadvantages to open-source and closed-source, but
if
 both have an extensible architecture, then it's win-win. If they share
that
 architecture, it's win-win-win


 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:btk3hb$4fh$1 digitaldaemon.com...
 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
Jan 08 2004
parent reply "Bruce Dodson" <bruce_dodson_except_this_part hotmail.com> writes:
Maybe the Extension Interface should be refactored into
something that is not quite as SciTE specific, so that other
Scintilla based editors and IDEs can more easily implement
the "host" side of the protocol.  Then it would be a
win-win-win-win.

"C" <dont respond.com> wrote in message
news:btl0p3$1gi3$1 digitaldaemon.com...
 Hmm cool idea!

 SciTE now now supports scripting with LUA.  As soon as
that is 100% I'll
 incoporate it.  If we could define a common interface
through LUA , then
 that would be awesome I think.

 C
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btl0hp$1g9q$1 digitaldaemon.com...
 I think DIDE and leds should define a common plug-in
architecture - D
 beans,
 if you like - such that people can write modules for,
and thereby expand,
 the powers of both.

 I see advantages and disadvantages to open-source and
closed-source, but
 if
 both have an extensible architecture, then it's win-win.
If they share
 that
 architecture, it's win-win-win


 "J Anderson" <REMOVEanderson badmama.com.au> wrote in
message
 news:btk3hb$4fh$1 digitaldaemon.com...
 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
Jan 08 2004
parent "C" <dont respond.com> writes:
How's that going ?  Was / Is it very hard to integrate ?  I thought you and
the team were going to bring the extensions to scintilla  , or just SciTE
For now ?

C


"Bruce Dodson" <bruce_dodson_except_this_part hotmail.com> wrote in message
news:btl4q3$1mff$1 digitaldaemon.com...
 Maybe the Extension Interface should be refactored into
 something that is not quite as SciTE specific, so that other
 Scintilla based editors and IDEs can more easily implement
 the "host" side of the protocol.  Then it would be a
 win-win-win-win.

 "C" <dont respond.com> wrote in message
 news:btl0p3$1gi3$1 digitaldaemon.com...
 Hmm cool idea!

 SciTE now now supports scripting with LUA.  As soon as
that is 100% I'll
 incoporate it.  If we could define a common interface
through LUA , then
 that would be awesome I think.

 C
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btl0hp$1g9q$1 digitaldaemon.com...
 I think DIDE and leds should define a common plug-in
architecture - D
 beans,
 if you like - such that people can write modules for,
and thereby expand,
 the powers of both.

 I see advantages and disadvantages to open-source and
closed-source, but
 if
 both have an extensible architecture, then it's win-win.
If they share
 that
 architecture, it's win-win-win


 "J Anderson" <REMOVEanderson badmama.com.au> wrote in
message
 news:btk3hb$4fh$1 digitaldaemon.com...
 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
Jan 08 2004
prev sibling parent Ant <duitoolkit yahoo.ca> writes:
On Fri, 09 Jan 2004 12:36:45 +1100, Matthew wrote:

 I think DIDE and leds should define a common plug-in architecture - D beans,
 if you like - such that people can write modules for, and thereby expand,
 the powers of both.
I have no idea how it's done. any pointers? Ant
Jan 08 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...
Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.
of course the best way to do it is to forget the file system altogether and store the source code on a data base. The compiler should be able to accept a stream of data instead of files. (we can always generate files on compilation time for the compiler use) To do the intellisense searches we would just throw a sql select to our database. We could also store the object files (units) with dates and times and compilation options... I actually thought of doing that when I started the leds project but I decided to go conservative as I needed a tool immediately. (don't be surprised if in the future the leds dependencies include PostgreSQL;) Ant
Jan 06 2004
parent reply "C" <dont respond.com> writes:
sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...
 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...
Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.
of course the best way to do it is to forget the file system altogether and store the source code on a data base. The compiler should be able to accept a stream of data instead of files. (we can always generate files on compilation time for the compiler use) To do the intellisense searches we would just throw a sql select to our database. We could also store the object files (units) with dates and times and compilation options... I actually thought of doing that when I started the leds project but I decided to go conservative as I needed a tool immediately. (don't be surprised if in the future the leds dependencies include PostgreSQL;) Ant
Jan 06 2004
parent reply Luke D <Luke_member pathlink.com> writes:
Do you really need to store the whole source?  Wouldn't just the type info be
sufficient, or even just the name of the file where the type info can be found?
I doubt Intellisence stores the whole source.

Forgive me if I'm misinformed.

In article <btfbbs$1tgf$1 digitaldaemon.com>, C says...
sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...
 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...
Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.
of course the best way to do it is to forget the file system altogether and store the source code on a data base. The compiler should be able to accept a stream of data instead of files. (we can always generate files on compilation time for the compiler use) To do the intellisense searches we would just throw a sql select to our database. We could also store the object files (units) with dates and times and compilation options... I actually thought of doing that when I started the leds project but I decided to go conservative as I needed a tool immediately. (don't be surprised if in the future the leds dependencies include PostgreSQL;) Ant
Jan 06 2004
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <btfj9e$2a2j$1 digitaldaemon.com>, Luke D says...
Do you really need to store the whole source?  Wouldn't just the type info be
sufficient, or even just the name of the file where the type info can be found?
I doubt Intellisence stores the whole source.

Forgive me if I'm misinformed.
Forgive me if I miss lead you. You are right. The idea was to store the entire source code in a data base instead of using a file system. Of course if the source is on a file you parse it and store only the info you are going to use. for a minute there I thought you had looked at my source code as I'm storing the function bodies. But that's just an hack because I didn't create a method to extract a range of lines of text from the scintilla component. It's a pain: gotta get the position from each line then get the lenght of text then... So that hack was a simple way of testing the function parser. only the current function (method) needs to be parsed (eventually) the other function bodies are skipped. AH! AH! why store the start and end line of the functions? what I need is the start and end positions (offset) on the entire text. And thats valid for every element type (enums, structs, classes...). (thanks) Ant dictionaryCheck("Intellisence") ? "Intellisence" : "Intellisense";
In article <btfbbs$1tgf$1 digitaldaemon.com>, C says...
sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...
 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...
Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.
of course the best way to do it is to forget the file system altogether and store the source code on a data base. The compiler should be able to accept a stream of data instead of files. (we can always generate files on compilation time for the compiler use) To do the intellisense searches we would just throw a sql select to our database. We could also store the object files (units) with dates and times and compilation options... I actually thought of doing that when I started the leds project but I decided to go conservative as I needed a tool immediately. (don't be surprised if in the future the leds dependencies include PostgreSQL;) Ant
Jan 06 2004
prev sibling parent "C" <dont respond.com> writes:
For just intellisense I imagine the tags would be sufficient , you probably
want something in memory though.  MSVC 6's tags and code completeion suck ,
most of the time it just plain does not work for me.

I probably wouldnt put source files into a DB , only to write them to hard
drive again.  Though I like the idea of streaming data to the compiler :).

C

"Luke D" <Luke_member pathlink.com> wrote in message
news:btfj9e$2a2j$1 digitaldaemon.com...
 Do you really need to store the whole source?  Wouldn't just the type info
be
 sufficient, or even just the name of the file where the type info can be
found?
 I doubt Intellisence stores the whole source.

 Forgive me if I'm misinformed.

 In article <btfbbs$1tgf$1 digitaldaemon.com>, C says...
sqllite might also be a good choice.

C

"Ant" <Ant_member pathlink.com> wrote in message
news:btfaud$1sng$1 digitaldaemon.com...
 In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...
Due to the flexibility on naming D modules I'm
Very happy that D doesn't import all the modules
in the current 'package' automatically.
That would make a nightmare to find out the
source file with a particular class definition.
of course the best way to do it is to forget the file system altogether and store the source code on a data base. The compiler should be able to accept a stream of data instead of files. (we can always generate files on compilation time for the compiler use) To do the intellisense searches we would just throw a sql select to our database. We could also store the object files (units) with dates and times and compilation options... I actually thought of doing that when I started the leds project but I decided to go conservative as I needed a tool immediately. (don't be surprised if in the future the leds dependencies include PostgreSQL;) Ant
Jan 06 2004
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
In article <bteffd$i6a$1 digitaldaemon.com>, Ant says...
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.
- Imports are declared inside the class body except for
  the super class and implemented interfaces
how about another one: - if the module name doens't start with a capital letter it doesn't define 1 and only 1 object. so we could have dui.Widget dui.Window for the classes Widget and Window and dui.all for ease of importing a bunch of things or dui.structs dui.fontStructs to import all the necessary structures for a task. that would get rid of some excess rigidity that might not be really necessary and would also be 'almost' intellisense 'friendly'. I think I like it. prepare to change your dui applications ;) (oh! no! - say 3 million people around the world) Of course we still have the friend across modules problem (thanks for the example guys). Ant
Jan 06 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jan 06 2004
parent reply Ant <Ant_member pathlink.com> writes:
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
Jan 06 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
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
Jan 06 2004
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jan 06 2004
parent Ant <Ant_member pathlink.com> writes:
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
Jan 06 2004