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. :)

> 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.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

"BCSD" <BCSD_member@pathlink.com> wrote in message news:ddajld$2q7t$1@digitaldaemon.com...
> Use a stack to keep track of the state in each level of nesting. Whenever
> you
> find a '{' go back and check to se what type of block it is, push your
> current
> state, change your state and keep going. Whenever you find a '}' pop off a
> state. You would need to delay output (or backup occasionally) but it
> shouldn't
> be that bad. With a little more work it could even handle braces in
> quotes.

Sounds similar to what I'm doing now, although it might be a little difficult to determine the type of the block without a lexer / parser.  I suppose I could check for a few keywords, like "class," "struct," and "enum," and let those through, and just kill everything else.  Thanks!

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:ddah3h$2mn5$1@digitaldaemon.com...

Thanks for all the replies!  I'll try out BCSD's solution, and if that isn't quite robust enough, I'll see if I can get digc to work, and if _that_ doesn't work, I'll make something with DMDFE.  Thanks!

BCSD wrote:
> One solution suggests it’s self (if I have time I might try implementing it,
> later this week maybe).
> 
> Use a stack to keep track of the state in each level of nesting. Whenever you
> find a '{' go back and check to se what type of block it is, push your current
> state, change your state and keep going. Whenever you find a '}' pop off a
> state. You would need to delay output (or backup occasionally) but it shouldn’t
> be that bad. With a little more work it could even handle braces in quotes.
> 

It's probably better to toenize the text first. when strings are tokenized you don't have to worry about whether or not they have a '}' inside them .. you just look for '{' and '}' tokens.

I'm *trying* to do something like that, in java.
So far I only have toenization done .. although my concept of 'token' is probably different from what most people might conceptualize it .. beause I didn't read it in a book or study it in college, I just sort of made my own concept of it.
I'll gladly post it if anyone asks for it. But be aware that I haven't tested it heavily, as I am on my own.

Right now I'm trying to parse declarations, if that gets done properly, then I think it would be easy to strip off function bodies and whatnot.

> 
> 
> In article <ddah3h$2mn5$1@digitaldaemon.com>, Jarrett Billingsley says...
> 
>>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.. 
>>
>>
> 
> 
> 

On Tue, 9 Aug 2005 17:35:41 +0000 (UTC), pragma wrote:

> I think it's been mentioned in this thread that hacking DMDFE may be a way to go.  Another route would be to hack an existing utility that already understands version statements well: take a look at the source for 'build' over on dsource.org.  At the very least, it's already aware of brackets and strings, which would be the biggest hurdles for writing your own tool.
> 
> Good luck.
> 
> - EricAnderton at yahoo

Okay, okay, okay! ;-)

I'll add a "-strip" switch to create 'header' modules. Most of the code is already there.

-- 
Derek Parnell
Melbourne, Australia
10/08/2005 8:02:47 AM

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?

In article <1gzqddtap8a8$.1wwes1e06us88$.dlg@40tude.net>, Derek Parnell says...
>
>On Tue, 9 Aug 2005 17:35:41 +0000 (UTC), pragma wrote:
>
>> I think it's been mentioned in this thread that hacking DMDFE may be a way to go.  Another route would be to hack an existing utility that already understands version statements well: take a look at the source for 'build' over on dsource.org.  At the very least, it's already aware of brackets and strings, which would be the biggest hurdles for writing your own tool.
>> 
>> Good luck.
>> 
>> - EricAnderton at yahoo
>
>Okay, okay, okay! ;-)
>
>I'll add a "-strip" switch to create 'header' modules. Most of the code is already there.

Thanks, that'd be really cool!

Holger


>
>-- 
>Derek Parnell
>Melbourne, Australia
>10/08/2005 8:02:47 AM

In article <ddah3h$2mn5$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>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..
>

Is this it?

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26411

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?  
> 
> 

I guess it's relative.
For someone who wrote a C++ compiler, D would probably be very easy to parse.

"Derek Parnell" <derek@psych.ward> wrote in message news:1gzqddtap8a8$.1wwes1e06us88$.dlg@40tude.net...
> Okay, okay, okay! ;-)
>
> I'll add a "-strip" switch to create 'header' modules. Most of the code is already there.

w00tage.