In article <ddaqoc$3d1$1@digitaldaemon.com>, Dejan Lekic says...
>
>
>I share this opinion even though I am not an open-source maniac. - Every
>normal human being would state "If you're not going to share your source,
>you don't deserve to use free tools.".
>It is imho fair enough if someone shares an apple with you today, for an
>instance, than if You are good person, You will share an apple with that
>person when You have it, or with some other person who gave an apple to
>that person you got an apple from. :)
>

I totally disagree. Sharing something because you expect something to be shared with you is no different than selling it.

On Wed, 10 Aug 2005 20:41:08 +0000 (UTC), bobef wrote:

>>The open source maniac: We don't need that kind of abomination. Let some company create a commercial tool for people who need it. If you're not going to share your source, you don't deserve to use free tools. Developers who are working for free shouldn't waste their time programming a tool to help creating nonfree/closed-source software.
>>
>>The pragmatic: This kind of tool would be very useful but open source developers have no time to create one and commercial developers aren't interested in making tools for a language with tiny user (=customer) base.
>>
> 
> Just an example: my app (lessequal.com/akide) is open source. Compiling and linking it takes 3 seconds on my pc when I pass all the files at once to dmd. But compiling each file w/o linking takes 40+ seconds! THIS IS SICK! Now I believe if we had headers it would take few seconds more than my 3... But now my source is so big I'd rather add intellisence to the ide (akide is developed on akide) and let it decide which files need recompiling instead of creating  all the headers... If I had to "rebuild all" more often my development should be SIGNIFICANTLY slower. So I don't know if we need tool to create headers or dmd should be smarter...

This is one of the reasons I wrote Build. By default, it only compiles those files that need to be compiled.

-- 
Derek Parnell
(skype: derek.j.parnell)
Melbourne, Australia
Download BUILD from ...
http://www.dsource.org/projects/build/ v2.09 released 10/Aug/2005

http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage

11/08/2005 9:35:17 AM

Shammah Chancellor wrote:
> In article <ddamm3$2uu2$1@digitaldaemon.com>, Burton Radons says...
> 
> 
>>digc has a tool for stripping function bodies.  The problem is that because of D's VERY complex versioning and debugging syntax there is no way to handle stripping robustly without understanding the entire language; it must parse the whole thing.  Which is a pickle, since D is not simple to parse at all and some of its syntax is so subtle that you practically need to depend upon DMD.  I think Ben has the right idea.
> 
> 
> 
> Funny, I thought D was supposed to be easy to parse?  

That claim needs to be contrasted with other languages which actually are easy to parse: LISP, Self, Smalltalk.  D is nowhere near their league.  Being easier to parse than C++ - and I think they're about equivalent if you're not tool-dependent - doesn't mean much.  That's like a pickup getting better gas mileage than a van.

Jarrett Billingsley wrote:
> Since my project nonagon isn't open-source (though that may change in the next few months), I distribute it as a lib with "headers" which just have declarations for all the classes and functions and whatnot.  In order to generate these "headers," I basically just have to remove all function bodies and replace them with semicolons.
> 
> The problem is that I did this manually at first, and it took me maybe 5-10 minutes to do it.  Now that nonagon has grown so much, It would probably take me close to an hour to replace all the function bodies with semicolons.
> 
> I wrote a "dumb" tool which basically counts the number of left and right braces, and based on the nesting level, it either outputs the text it reads or it doesn't.  The problem with this is that once I start adding things in like version blocks and nested classes, it'll start stripping things out that it's not supposed to.  It also doesn't strip out global-level function bodies.
> 
> Is there any kind of lexer/parser tool for D that will allow me to quickly strip out the function bodies?  Surely someone has run across this problem before.  Normally, I'd look into using the frontend, but, well, it's completely undocumented and written in C++.  And I really don't feel like spending a week and a half figuring out how to use the thing and then writing a tool.
> 
> Wasn't there some kind of D lexer tool written in D several months ago?  I can't find the NG thread.. 
> 
> 

Ok,  I was writing a tool to lex/parse/analyze d code, it's not nearly done at all, but it's in a stage that allowed me to hacke it in an attempt to make it a stripper tool.
I have absolutly no idea how reliable it is .. if anybody who wants to test/experiment/play with it, you're welcome. But I give no warranties at all ..

It's written in java, and I used a trial version of exelcsior jet to compile it to a native windows exe.
http://aljudy.org/dstuff/dstrip.jar << contains source
http://aljudy.org/dstuff/dstrip.exe

Here is a stripped version of build.d (of Dark Pernell's build) , it was stripped using this tool of mine.
http://aljudy.org/dstuff/strip-build.d

Note that it wasn't meant to be a stripping tool, it's more of a lexer/parser project I'm working on; but I just hacked it to make it strip, it probably has bugs, but hopefully it has some usefullness.

Jarrett Billingsley wrote:
> Since my project nonagon isn't open-source (though that may change in the next few months), I distribute it as a lib with "headers" which just have declarations for all the classes and functions and whatnot.  In order to generate these "headers," I basically just have to remove all function bodies and replace them with semicolons.
> 
> The problem is that I did this manually at first, and it took me maybe 5-10 minutes to do it.  Now that nonagon has grown so much, It would probably take me close to an hour to replace all the function bodies with semicolons.
> 
> I wrote a "dumb" tool which basically counts the number of left and right braces, and based on the nesting level, it either outputs the text it reads or it doesn't.  The problem with this is that once I start adding things in like version blocks and nested classes, it'll start stripping things out that it's not supposed to.  It also doesn't strip out global-level function bodies.
> 
> Is there any kind of lexer/parser tool for D that will allow me to quickly strip out the function bodies?  Surely someone has run across this problem before.  Normally, I'd look into using the frontend, but, well, it's completely undocumented and written in C++.  And I really don't feel like spending a week and a half figuring out how to use the thing and then writing a tool.
> 
> Wasn't there some kind of D lexer tool written in D several months ago?  I can't find the NG thread.. 
> 
> 


These kind of "strip" tools just amount to the same thing as C headers for a library.  D should and could do better.  Let's ditch the headers/import idea completely (aka "stripping") and create a tool (integrated into build perhaps?) that just reads the symbols directly from the *.lib file that the project links with (silent "stripping"). That way shipping the library itself would be the only thing necessary for closed projects.  This has been discussed before.  We don't really need more header files to mess with.  We're drifting back into the C/C++ age again if we go that route.

-JJR

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:ddlres$la8$1@digitaldaemon.com...
> Ok,  I was writing a tool to lex/parse/analyze d code, it's not nearly
> done at all, but it's in a stage that allowed me to hacke it in an attempt
> to make it a stripper tool.
> I have absolutly no idea how reliable it is .. if anybody who wants to
> test/experiment/play with it, you're welcome. But I give no warranties at
> all ..
>
> It's written in java, and I used a trial version of exelcsior jet to compile it to a native windows exe. http://aljudy.org/dstuff/dstrip.jar << contains source http://aljudy.org/dstuff/dstrip.exe

I'd like to try your tool, but (1) I tried running the dstrip.jar with "java -jar dstrip.jar", but it says it can't load the Main-Class manifest attribute (I have no idea what that means as I've never done anything with Java), and (2) the compiled version is missing XKRN37052.DLL.  It says you should use the JetPack II distribution utility.

Hi,

>These kind of "strip" tools just amount to the same thing as C headers for a library.  D should and could do better.  Let's ditch the headers/import idea completely (aka "stripping") and create a tool (integrated into build perhaps?) that just reads the symbols directly from the *.lib file that the project links with (silent "stripping"). That way shipping the library itself would be the only thing necessary for closed projects.  This has been discussed before.  We don't really need more header files to mess with.  We're drifting back into the C/C++ age again if we go that route.

Yes, please. This would be a big step forward.

Cheers,
--AJG.

Jarrett Billingsley wrote:
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:ddlres$la8$1@digitaldaemon.com...
> 
>>Ok,  I was writing a tool to lex/parse/analyze d code, it's not nearly done at all, but it's in a stage that allowed me to hacke it in an attempt to make it a stripper tool.
>>I have absolutly no idea how reliable it is .. if anybody who wants to test/experiment/play with it, you're welcome. But I give no warranties at all ..
>>
>>It's written in java, and I used a trial version of exelcsior jet to compile it to a native windows exe.
>>http://aljudy.org/dstuff/dstrip.jar << contains source
>>http://aljudy.org/dstuff/dstrip.exe
> 
> 
> I'd like to try your tool, but (1) I tried running the dstrip.jar with "java -jar dstrip.jar", but it says it can't load the Main-Class manifest attribute (I have no idea what that means as I've never done anything with Java), and (2) the compiled version is missing XKRN37052.DLL.  It says you should use the JetPack II distribution utility. 
> 
> 

I don't know how to distrbute my java projects either ..
tbh though, I think I agree with John Reimer
news://news.digitalmars.com:119/ddluoo$nm1$1@digitaldaemon.com

In article <ddmd1a$10r8$1@digitaldaemon.com>, Jarrett Billingsley says...
>
[snip]
>I'd like to try your tool, but (1) I tried running the dstrip.jar with "java -jar dstrip.jar", but it says it can't load the Main-Class manifest attribute (I have no idea what that means as I've never done anything with Java) ...
[snip]

Hi Jarrett,

you can extract the manifest.mf file with WinZip to META-INF/manifest.mf
(the META-INF directory should be created in the directory where dstrip.jar is).
Then change the content of manifest.mf to this single line:

Main-Class: lexer.tokens.Stripper

After that update the dstrip.jar with the jar tool from the jdk by giving the following command from the commandline (you need to be in the directory where dstrip.jar is).

jar uvfm dstrip.jar META-INF/manifest.mf

After that it is executable by typing: java -jar dstrip.jar

Note: You need to have JDK 1.5 installed in order to run it successfully! Hope this helps a little ...

Kind regards,
Stefan

"Stefan Zobel" <Stefan_member@pathlink.com> wrote in message news:ddnjug$202u$1@digitaldaemon.com...
> Hi Jarrett,
>
> you can extract the manifest.mf file with WinZip to META-INF/manifest.mf
> (the META-INF directory should be created in the directory where
> dstrip.jar is).
> Then change the content of manifest.mf to this single line:
>
> Main-Class: lexer.tokens.Stripper
>
> After that update the dstrip.jar with the jar tool from the jdk by giving
> the following command from the commandline (you need to be in the
> directory
> where dstrip.jar is).
>
> jar uvfm dstrip.jar META-INF/manifest.mf
>
> After that it is executable by typing: java -jar dstrip.jar
>
> Note: You need to have JDK 1.5 installed in order to run it successfully! Hope this helps a little ...

*Slaps forehead* Why of course, it's so obvious!  ;)

I don't have the JDK, so I guess I'm stuck.  Unless I download it of course.