James Dunne wrote:
> Why do some people get all up in arms about top-posting?  It's retarded.  It absolutely does not change the meaning or flow of conversation in a newsgroup.  This might be true if each post were a single sentence, but mostly they're not.  Besides, it's not hard to draw the lines between posts... Older ones are prefixed in '>'s everywhere, and the new stuff is not.  Personally, I don't enjoy scrolling to the very bottom to find a new post appended in reply to an older post, especially if that new post happens to be rather long.  For the longest time, I thought top-posting meant posting a new thread, since it was on the top level of discussion.  It must've sounded ridiculous of me to ask how to not top-post. =P
> 
> Sorry for interrupting the flow here Georg... ;)
> 
> An idea to extend existing library/binary file formats with extra information for reflection?  Sounds kind of hairy to me.
> 
> I would advise to check the specs of most popular executable/linkable formats (ELF, COFF, OMF, etc.) to see if such a thing is already supported without modification; sort of like a "miscellaneous" section.  If such a thing were allowed, then a specification for a custom format containing necessary reflection information for D should be drawn up, agreed upon, and implemented.  It should store its information within that miscellaneous section, with an obvious marker so as to not confuse with any other potential information stored within that section.
> 
> Georg Wrede wrote:
> 
>> (Sorry for top-posting, I'm in the middle of something right now, and I just got a raw idea to throw at you guys!)
>>
>> The different lib and dll formats specify things quite meticulously. Now, if we wanted to make a "file type" that is compatible _and_ contains data that we need, then:
>>
>> why not just slap our own data at the end of the lib/dll?
>>
>> So, for example, if a file format only describes entry points and function names, we might slap a description of return values, function parameters, and whatever else we consider important (e.g. compiler version, or some such) simply at the end of that file.
>>
>> This has of course to be tested, so no tools (binutils or other) crash with these files. With any good luck, this might be an easy "chewing gum and cardboard" solution, that we can use for the time being.
>>
>> (Just a Temporary Solution(TM) that the FAA airliner disaster investigators will find 5 years from now still being used. :-)
>>
>>
>> Dave wrote:
>>
>>> In article <ddpan3$6fg$1@digitaldaemon.com>, Hasan Aljudy says...
>>>
>>>> Vathix wrote:
>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The problem with that is the current lib files are very low level and  dangerous. To distribute a lib file you have to force users to use the  same compiler version and any other libs you use have to be for that same  version. Say you want to use libs from 2 different sources and both rely  on a different compiler version. Well, now you're pretty much screwed.  Even if they successfully link to a program, there still can be hidden  problems, such as access violations because there was supposed to be a  pointer to something at a certain location but now it's somewhere else. If  D could have a new form of lib file that knew more about the language and  didn't depend on compiler version as much, hopefully not even depend on  compiler brand (implementation) much, and possibly use an intermediate  code form, it would be a lot safer and better in many respects.
>>>>
>>>>
>>>>
>>>> I really don't know anything about lib files, so I don't know how much sense am I gonna make here, but here's an idea:
>>>> How about an intermediate file (between .d and .lib) that contains both stripped declarations and .lib content (whatever that is), so that it's easy for any compiler/linker/whatever to extract both declarations and/or .lib from that file (let's just call that file "dlib" for now).
>>>>
>>>> In other words, embed stripped declarations directly into lib files.
>>>>
>>>> What I'm proposing is that instead of having the compiler produce lib files, it produces the "dlib" file, or have it only produce that file on a special compiler switch.
>>>>
>>>> is that a reasonable proposal? or is it extreemly stupid?
>>>
>>>
>>>
>>>
>>> I think that is very reasonable and from what I gather it can actually be done.
>>>
>>> When the compiler tries to resolve an import that isn't in the path, it looks in
>>> the library and/or .obj files, right?
>>>
>>> I believe it can also be done in such a way so that other languages could use
>>> the same libraries (they would just ignore the section of the object files
>>> containing the D symbols).
>>>
>>> Just think:
>>>
>>> - Import code and libs. in one file (end of version issues between headers and
>>> libs.)
>>>
>>> - One file per library to distribute.
>>>
>>> - Reflection/introspection w/o having to strip executable library code (This
>>> would make runtime loading/linking much easier and portable, right Pragma?).
>>>
>>> - Same library file could be used by other languages (they would have to provide
>>> their own forward declarations).
>>>
>>> If you also store some type of implementation specified binary symbols of all of
>>> the code instead of just stripped declarations:
>>>
>>> - You could potentially distribute closed-source libraries made up of just
>>> template code in binary format using the current D instantiation model (w/o
>>> implicit function template instantiation).
>>>
>>> - The extra info. could be used by the compiler, e.g.: to inline functions. The
>>> info. not referenced would not make it into .exe's (stipped by most modern
>>> linkers) so it wouldn't bloat applications.
>>>
>>> Now all that would be a big step forward, IMO!
>>>
>>> - Dave
>>>
>>>

You guys should check out Eric's project, DDL (D Dynamic Libraries). He's dealing with these sort of issues, and I think you will be impressed with the progress hes made so far. http://dsource.org/projects/ddl/

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

I think this is a weak point of D right now. Having to strip code out of a file to make it a header file is just silly.

Special dlib files make me a little nervous though. I need to be able to access the library files from C.

--Traveler Hauptman

Sean Kelly wrote:
> In article <dgd52g$2ff3$1@digitaldaemon.com>, James Dunne says...
> 
>>Why do some people get all up in arms about top-posting?
> 
> 
> This is  Alf P. Steinbach's signature file (from the c++ newsgroups):
> 
> ---
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail? 
> 
> 

Yes, I've seen many like that, and it just doesn't hold.  Most posts are not one-liners.  Such an example is of the most extreme case where everyone uses top-posting.  It shouldn't bother you anyway if you've been following the conversation.  Just find the new post and read on. It's easier to find it at the top than to start at the bottom and scroll up.

In article <dgek0t$s46$1@digitaldaemon.com>, James Dunne says...
>
>Sean Kelly wrote:
>> In article <dgd52g$2ff3$1@digitaldaemon.com>, James Dunne says...
>> 
>>>Why do some people get all up in arms about top-posting?
>> 
>> This is  Alf P. Steinbach's signature file (from the c++ newsgroups):
>> 
>> ---
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing on usenet and in e-mail?
>
>Yes, I've seen many like that, and it just doesn't hold.  Most posts are not one-liners.  Such an example is of the most extreme case where everyone uses top-posting.  It shouldn't bother you anyway if you've been following the conversation.  Just find the new post and read on. It's easier to find it at the top than to start at the bottom and scroll up.

It's really only an issue for me with long discussions, as I might have to read pages of text in reverse to get a context for the current post.  Also, I like to insert replies inline, which isn't possible with top-posting.


Sean

In article <dgedae$kgp$1@digitaldaemon.com>, Traveler Hauptman says...
>
>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.
>>
>
>I think this is a weak point of D right now. Having to strip code out of a file to make it a header file is just silly.

Having to manually maintain a separate header is worse.  Besides, Java works the same way.

>Special dlib files make me a little nervous though. I need to be able to access the library files from C.

So declare everything extern (C) and build standard C libraries.


Sean

In article <dgedae$kgp$1@digitaldaemon.com>, Traveler Hauptman says...
>
>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.
>
>I think this is a weak point of D right now. Having to strip code out of a file to make it a header file is just silly.

By the way.  Did you know that compiled .NET programs actually contain the full source code as well?  I assume this is to allow portions to be compiled while the application is running, but I was amazed that the code isn't even obfuscated.  You have to buy a third party tool to do this if you want to protect your IP when shipping .NET applications.


Sean

> By the way.  Did you know that compiled .NET programs actually contain the full
> source code as well?  I assume this is to allow portions to be compiled while
> the application is running, but I was amazed that the code isn't even
> obfuscated.  You have to buy a third party tool to do this if you want to
> protect your IP when shipping .NET applications.

Geez!

I suggested this for D code that would be used instead of scripts, for quite a long time ago. Didn't catch on too well.

It has its merits in many situations, but not when you are selling software. And of course, you have to _buy_ something to fix it. As always.

Georg Wrede wrote:
>> By the way.  Did you know that compiled .NET programs actually contain the full
>> source code as well?  I assume this is to allow portions to be compiled while
>> the application is running, but I was amazed that the code isn't even
>> obfuscated.  You have to buy a third party tool to do this if you want to
>> protect your IP when shipping .NET applications.
> 
> 
> Geez!
> 
> I suggested this for D code that would be used instead of scripts, for quite a long time ago. Didn't catch on too well.
> 
> It has its merits in many situations, but not when you are selling software. And of course, you have to _buy_ something to fix it. As always.

For .Net?  Visual Studio .Net comes with Dotfuscator, which obfuscates the symbol table so that the .Net code cannot be reverse engineered into any *meaningful* representation.

In fact, I don't believe the distributed binaries actually contain the "full source code" of the program, as you state.  It's just that the .Net code is compiled into MSIL, which, like Java, is easily reverse engineered.  It doesn't help that the binaries also contain all of the symbolic information from the original code, i.e. local variable names are preserved.

In article <dgf21b$1b80$1@digitaldaemon.com>, James Dunne says...
>
>Georg Wrede wrote:
>>> By the way.  Did you know that compiled .NET programs actually contain
>>> the full
>>> source code as well?  I assume this is to allow portions to be
>>> compiled while
>>> the application is running, but I was amazed that the code isn't even
>>> obfuscated.  You have to buy a third party tool to do this if you want to
>>> protect your IP when shipping .NET applications.
>> 
>> 
>> Geez!
>> 
>> I suggested this for D code that would be used instead of scripts, for quite a long time ago. Didn't catch on too well.
>> 
>> It has its merits in many situations, but not when you are selling software. And of course, you have to _buy_ something to fix it. As always.
>
>For .Net?  Visual Studio .Net comes with Dotfuscator, which obfuscates the symbol table so that the .Net code cannot be reverse engineered into any *meaningful* representation.

I didn't know about that.  I'll admit I only know about this because a .NET person in the office told me about it.  Perhaps he was unaware of this tool.

>In fact, I don't believe the distributed binaries actually contain the "full source code" of the program, as you state.  It's just that the .Net code is compiled into MSIL, which, like Java, is easily reverse engineered.  It doesn't help that the binaries also contain all of the symbolic information from the original code, i.e. local variable names are preserved.

Exactly.  The aforementioned person had a decompiler he'd gotten online somewhere and I was amazed to see that it spat out our source code exactly as it was written.  I expected it would a bit more like decompiled C++ code.  I've wondered whether a JIT build of .NET applications (instead of the .NET assembly format) would contain so much information, but I never bothered to test it.


Sean

this could be done very easily with the front end code, it could be used to emit a public 'header' module from the entire source code

the front end could also be turned into a metaprogramming system that could do compile time source manipuation for all sorts of powerfull things, like reflection, emitting, extending the languge etc

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