In article <cedhpe$2jja$1@digitaldaemon.com>, Niko Korhonen says...
>
>J C Calvarese wrote:
>> If this is really important to you, I don't know why we (and by we and mean Walter) couldn't implement a .dar file format. It could be .zip-format file containing stripped headers and a corresponding .lib.
>
>While I can't say that doesn't sound tempting, I'll say no. It's not really /that/ important. It doesn't apply to me or my personal developing methodologies very much, what I asked was more of a theoretical question for (future) business aspects of D.

Fair enough.

I wasn't trying to guilt anyone into doing anything.

I was just hinting that since D is pretty easy to parse, the DMD front end source is public, and open source archiving code is out there (such as std.zip), this is probably something that someone could develop -- even without Walter's help. (And Walter has shown that he'll accept donated code.)

This particular topic has come up before (not recently, but several times). I guess I've just read too many "Oh, D really needs this" messages in the past.

D is designed to allow both open and closed source projects, so that everyone can be happy. And allowing stripped headers is a part of that idea.

jcc7

In article <cedhr2$2jjk$2@digitaldaemon.com>, Matthew says...
>
>Quite right. The idea that all software must be open-source is indicative of a peurile notion amongst many NG-hangers, i.e. that everything in the IT world should be free. I've never had a paying client for whom an open-source model could ever conceivably be appropriate. To not recognise this, or to not care, is simply stupid, and demonstrates an attitude that is not commensurate with the long term aims of D (and of Walter).
>
>I completely agree that the DMD distribution should include tools to assist with closed-source development, and urge Walter (or anyone with a bit of spare time) to consider how we can get this with 1.0.

Agreed.  But to the open source folks I will say that I'm quite willing to pay extra for libraries that ship with full source code, so long as the license doesn't require me to give credit in my docs or any other such nonsense.


Sean

"parabolis" <parabolis@softhome.net> skrev i en meddelelse news:cecegg$22k5$1@digitaldaemon.com...
> Martin M. Pedersen wrote:
> This is actually an intriguing idea. (Besides the fact that
> humans would not be able to read the stripped down files.)

It would require only a very simple tool to extract the interfaces.

I think it is desirable to keep the interface with compiled code. If they are separate as in C, it opens up for inconsistencies - something that I'm sure every C/C++ programmer here has learned to hate. Many years ago I was working with Turbo Pascal, and it's TPU-files was the combination of the compiled code and the interface. It worked very well, and also allowed the compiler to do lazy recompilation minimizing the need for tools such as "make". I don't know how Delphi works today. I think this approach would be very similar to Turbo Pascal's TPU-files, except that they are compatible with a C development environment, and we have the complexities of libraries to consider too.

> OMF format (which is what dm uses) does have a comment field
> that might be repurposed to do just that. (COMMENT type 0xDA
> should work)

I thought so :-)

Regards,
Martin M. Pedersen

In article <cedhr2$2jjk$2@digitaldaemon.com>, Matthew says...
>
>The idea that all software must be open-source is indicative of a peurile
>notion amongst many NG-hangers,
>i.e. that everything in the IT world should be free.

Quite right. Why? Did someone on this newsgroup claim that all software must be open source? Or that everything in the IT world should be free? I must have missed that post.

I don't think it unreasonable though to suggest that if someone is likely to gain commercially from the use of a tool, that they shouldn't necessarily expect that tool to be handed to them on a plate free of charge. But that's just an opinion, and it does seems a shame that one can't express such things on this forum without incurring overreaction.

Jill

PS. Come on, lighten up, Matthew. Nothing enclosed within <rant> and </rant> should ever be taken too seriously. Just imagine like I'm complaining about the price of fish or the state of the bus service or something, and take it on that level. I thought Niko's response to my post was perfectly reasonable. Why spoil it? Let's keep this place fun.

Martin M. Pedersen wrote:

> "parabolis" <parabolis@softhome.net> skrev i en meddelelse
> news:cecegg$22k5$1@digitaldaemon.com...
> 
>>Martin M. Pedersen wrote:
>>This is actually an intriguing idea. (Besides the fact that
>>humans would not be able to read the stripped down files.)
> 
> 
> It would require only a very simple tool to extract the interfaces.
> 
> I think it is desirable to keep the interface with compiled code. If they
> are separate as in C, it opens up for inconsistencies - something that I'm
> sure every C/C++ programmer here has learned to hate. Many years ago I was
> working with Turbo Pascal, and it's TPU-files was the combination of the
> compiled code and the interface. It worked very well, and also allowed the
> compiler to do lazy recompilation minimizing the need for tools such as
> "make". I don't know how Delphi works today. I think this approach would be
> very similar to Turbo Pascal's TPU-files, except that they are compatible
> with a C development environment, and we have the complexities of libraries
> to consider too.
> 

Actually I saw someone suggest .dar files which sound like they could do what you want them to. In Java .jar files are .zip files which (usually compression level of 0). The internals are treated in a manner similar to /lib/... So the suggestion allows for:
    /lib/... obj files here
    /inc/... auto created stripped down/include files here
    /src/... full source file here if you want
    /kitchen-sink/... self explanatory

Provided the compiler can read/write directly to .dar files then it can also automatically save the stripped down .d file in the appropriate /inc/ directory.

Then D would also need a seperate .dar management tool but given zlib capabilities already exist the whole idea is really probably quite simply realizable.

You will thus be able to distribute your whole package with full or stripped down source along with any necc. .obj files and with decent compression.

David Tiktin schrieb:
> Yes, there could be a solution along these lines.  But does D allow you to "reopen" a class definition?

No. I think it should rather done like in C++: you make a complete class declaration in the "header" part, excluding code, and then fill in the methods below in the version(implementation) part, e.g.

X.this(int x) {
   x_ = x;
}

x_ has to be defined in the public part anyway, because else the class definition would be incomplete, size unknown, and thus it would all break when you create a class derived from X.

> If it did, I suppose you could just do:
[...]
>   import x.impl;
[...]

This line cannot work properly, because qualified names for classes would be different. Perhaps one could make alias fix that, but i think then it would be too seducing to place data members here, and thus break the definition.

You should also be aware, that D automatically evaluates functions for inlining, if their source is available during compilation. If not, then... bad luck. D is geared towards whole-program optimizations, which might be the next big thing which might cause Java and CLI/.NET to grow stronger, and C++ to fall back a bit.

This question of source protection has actually popped up a couple of times in the long history of D newsgroups, back when it wasn't that crowded and i read all the couple of thousands messages per year. It was agreed upon that when commercial compilers appear, they could foresee a format to replace lib, containing part compiled code, part declarations, part parsed representation of inlinable functions. For current development, it would be putting a priority on a wrong spot - there is way too much primary things to iron out. But an external tool would be thinkable, which would be based on a stripper anyway, plus an archive and compilation manager. Have a mercy with Walter: he cannot clone himself, people hardly help him, and he doesn't have a time machine.

-eye

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cedvfk$2rfq$1@digitaldaemon.com...
> In article <cedhr2$2jjk$2@digitaldaemon.com>, Matthew says...
> >
> >The idea that all software must be open-source is indicative of a peurile
> >notion amongst many NG-hangers,
> >i.e. that everything in the IT world should be free.
>
> Quite right. Why? Did someone on this newsgroup claim that all software must be open source? Or that everything in the IT world should be free? I must have missed that post.
>
> I don't think it unreasonable though to suggest that if someone is likely to gain commercially from the use of a tool, that they shouldn't necessarily expect that tool to be handed to them on a plate free of charge. But that's just an opinion, and it does seems a shame that one can't express such things on this forum without incurring overreaction.
>
> Jill
>
> PS. Come on, lighten up, Matthew. Nothing enclosed within <rant> and </rant> should ever be taken too seriously. Just imagine like I'm complaining about the price of fish or the state of the bus service or something, and take it on that level. I thought Niko's response to my post was perfectly reasonable. Why spoil it? Let's keep this place fun.

I am light. I just like carping on from time to time. (Which I know you know by now.)

Niko Korhonen wrote:
> 
> Arcane Jill wrote:
> > It would be "helpful" only for those people wishing to hide their source code from the rest of us.
> 
> I'm not asking "how can I close my sources" just out of spite. In fact, I /am/ a fan of open source, and all of my personal projects are BSD-licensed anyway.
> 
> But the fact is that not all software development is done by open source -oriented individuals. Only a small minority of it is. It's a common business practice not to divulge your intellectual property. I asked the question strictly with business considerations of the D language in mind.

I remember that Burton Radons built a solution for his libraries and distributed them this way.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com