www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Andrei's Google Talk

reply BCS <none anon.com> writes:
The video is up:

http://www.youtube.com/watch?v=RlVpPstLPEc

-- 
... <IXOYE><
Aug 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 The video is up:
 http://www.youtube.com/watch?v=RlVpPstLPEc

Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program. At 8.56: The video says that D builds structure on the C memory model. Years ago C99 has essentially replaced alloca() with something structurally equal but nicer and more type-safe, the Variable Length Arrays, that I prefer over D alloca(). At 14.00: I did know nothing about the number of times a C++ compiler looks at code chars :-) At 14.42: You compare the performance of a D compiler with the performance of a C++ compiler. But Delphi compiler was/is very fast (and probably the FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal) code to compile. I think on average it takes only two thousand clock ticks to compile one line of ObjectPascal code. It sounds a lot, but it means that with a modern single-core CPU you can produce your binary file from a one million ObjectPascal lines long program in less than two seconds. ObjectPascal type system looks a bit simpler than D one (despite it has OOP, generics, modules, inline asm, dynamic strings, records, all basic D types, etc), so this isn't a fully apple-to-apple comparison. 27.50, "transactional file copy": this example was script-like, and as short as possible to fit into one single slide, so in this case I think using enforce() is OK. But in true programs I suggest all D programmers to use DesignByContract with assert() more and to use enforce() less. Among other things enforce() kills inlining possibilities and inflates code. In D.learn I have seen people use enforce() in a situation where DbC is designed for. I think the D community needs to learn a bit more DbC, and in my opinion to do this the leaders have to lead the way. 42.00: I don't know what Big-O() encapsulation is. I think later you explain it a bit more, but I have lost the meaning. 53.00, slide 26: regarding sealed containers: I like the idea of an Hierarchical Allocator for C: http://swapped.cc/halloc/ The idea is simple, when you call a malloc-like function you put the pieces of memory in a hierarchy. And later with a single function call you can free a whole linked list, or a whole data structure that can contain a linked list and and two arrays, or the whole memory allocated by all the data structures used in a whole section of your program. In my opinion this is cool in C. In D with sealed containers you may be able to do something similar. 55.14: Very nice slide :-) In my dlibs1 the Levenshtein distance function is implemented for random accessible inputs only, so it doesn't work correctly with UTF8/UTF16. On an 7-bit ASCII it's probably faster than the Phobos2 one because it is heavily optimized. When the input arrays are small (like two small strings) it uses alloca() to allocate on the stack the array needed by the dynamic programming algorithm, because in my code I often call Levenshtein on small strings and I have seen for this code stack allocation increases performance significantly (another design option that here I have not used is to optionally use heap memory allocated outside the Levenshtein function, as often Tango functions do). 57.36: The Wikipedia Levenshtein entry can be improved a bit, to remove the random access requirement, if not already done :-) Often in practice you have to pay a certain performance price for genericity. So an interesting question is, with the current DMD compiler how much slower than an array-based Levenshtein function is the generic Phobos one when the input is for example a couple of ubyte arrays? If it's only about two or three times slower then it's probably good enough. 1.12.50: Your explanation of the difference between a compiler optimization and an properly defined language feature was nice :-) 1.14.57: I think you have missed to explain the trusted too that joins the safe and unsafe worlds (in a precedent moment in the talk you have not talked about __gshared, but seems more acceptable). 1.16.04, the question about future success of D: This is not an easy question. Probably the Next Big Language will be JavaScript, that probably will be used in really many situations. Java will probably keep being used a lot in commercial settings, even if only as legacy language. A language that I think has a good chance to become widely used in numerical scientific computations is Chapel, that so far the D community seems to have ignored (I have seen only Bartosz Milewski write about it a bit), despite my repeated attempts to put it in evidence, because I think it contains several very good ideas that are essentially ignored in D. Regarding D2, a problem is of course that D is mostly a system language and the ecological niche for system languages is small and probably will keep being small. Today languages for the Web become way more widespread (and here I have see no enthusiasm in the idea of using D on the Google NaCl platform, to use it on the Web). A language as C#4 is very good in both commercial applications (often database-centric, where LINQ helps a lot) and it can be used to write many desktop/generic applications too, thanks to its IDE, its wide standard library and the possibility to use other languages (like IronPython, F# etc) to create normal dlls that can be used as the C# ones (Mono too helps). Eventually a version of D2 for the CLI platform will partially solve this problem. Young programmers grow up used to program in JavaScript/Python/PHP and see as more and more alien some lower-level knowledge that is almost necessary to program _efficiently_ in D. D also gives you almost all you can find in the pure Java language, but my experience shows me that if you program in D as you program in Java your programs often come out too much slower than the Java ones (often just because of the D GC), so D is not a drop-in replacement for Java: in D you don't have a powerfully optimizing virtual machine under the language that catches and optimizes away a very large number of "efficiency bugs" of your Java code, you have to actually write good D code if you want efficient D programs. In the time has taken me to see and comment the video the number of people that have seen it has gone from 3 to 322. This is a lot in a short time. Bye and thank you for the ride, bearophile
Aug 03 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 27.50, "transactional file copy": this example was script-like, and as short
 as possible to fit into one single slide, so in this case I think using
 enforce() is OK. But in true programs I suggest all D programmers to use
 DesignByContract with assert() more and to use enforce() less. Among other
 things enforce() kills inlining possibilities and inflates code. In D.learn I
 have seen people use enforce() in a situation where DbC is designed for. I
 think the D community needs to learn a bit more DbC, and in my opinion to do
 this the leaders have to lead the way.

There's a misunderstanding here. Contract programming is for detecting program bugs. enforce() is for detecting and handling errors such as disk failures and bad user input. They are COMPLETELY DIFFERENT and must not be conflated. (For example, assert() goes away when compiled with the -release switch. enforce() does not.)
Aug 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:
 Yes, but as has been discussed and resolved on phobos mailing list, usage  
 errors should not be handled via uncaught exceptions.

Do you have some URL for that discussion? Bye, bearophile
Aug 04 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:
 Hm... let me see:
 http://lists.puremagic.com/pipermail/phobos/2010-July/001480.html
 I think this is what started the discussion.

Thank you for the link. I have read all the long thread and this time my hero is Leandro Lucarella :-) Bye, bearophile
Aug 04 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/04/2010 06:38 AM, Steven Schveighoffer wrote:
 On Tue, 03 Aug 2010 17:56:44 -0400, Walter Bright
 <newshound2 digitalmars.com> wrote:

 bearophile wrote:
 27.50, "transactional file copy": this example was script-like, and
 as short
 as possible to fit into one single slide, so in this case I think using
 enforce() is OK. But in true programs I suggest all D programmers to use
 DesignByContract with assert() more and to use enforce() less. Among
 other
 things enforce() kills inlining possibilities and inflates code. In
 D.learn I
 have seen people use enforce() in a situation where DbC is designed
 for. I
 think the D community needs to learn a bit more DbC, and in my
 opinion to do
 this the leaders have to lead the way.

There's a misunderstanding here. Contract programming is for detecting program bugs. enforce() is for detecting and handling errors such as disk failures and bad user input. They are COMPLETELY DIFFERENT and must not be conflated.

Yes, but as has been discussed and resolved on phobos mailing list, usage errors should not be handled via uncaught exceptions. I think the example is flawed in that regard. I wouldn't bring it up, but people who haven't followed that discussion might get the wrong idea from this example.

Well I agree with the spirit but let me say this. If all I want is a short script that does the right thing, I don't care whether failure comes with a stack trace caboose. So I don't think the example is flawed at all - it stands as a short correct script that does something useful. Andrei
Aug 04 2010
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
On 03/08/10 22:56, Walter Bright wrote:
 bearophile wrote:
 27.50, "transactional file copy": this example was script-like, and as
 short
 as possible to fit into one single slide, so in this case I think using
 enforce() is OK. But in true programs I suggest all D programmers to use
 DesignByContract with assert() more and to use enforce() less. Among
 other
 things enforce() kills inlining possibilities and inflates code. In
 D.learn I
 have seen people use enforce() in a situation where DbC is designed
 for. I
 think the D community needs to learn a bit more DbC, and in my opinion
 to do
 this the leaders have to lead the way.

There's a misunderstanding here. Contract programming is for detecting program bugs. enforce() is for detecting and handling errors such as disk failures and bad user input. They are COMPLETELY DIFFERENT and must not be conflated. (For example, assert() goes away when compiled with the -release switch. enforce() does not.)

I agree. Still, I agree with bearophile that 'enforce' should be avoided. It is a quick-and-dirty solution for situations where a proper exception should be issued. Essentially, an 'enforce' violation says "Something went wrong!" without giving a clue about the real problem. That's OK in the development phase but should be replaced when the code matures. And as for the concept of "user input" vs. "contracts": A library interface is *not* a user interface. After some consideration, I agree that a library should always check its input even in "release" mode. However - this should be solved by selectively toggling contract checking rather than replacing contracts by "enforce" statements.
Aug 04 2010
parent reply BCS <none anon.com> writes:
Hello Norbert,

 And as for the concept of "user input" vs. "contracts": A library
 interface is *not* a user interface. After some consideration, I agree
 that a library should always check its input even in "release" mode.
 However - this should be solved by selectively toggling contract
 checking rather than replacing contracts by "enforce" statements.

In some cases, particularly where the preconditions are external to the process, your assertion is severely weakened if it doesn't fail completely. 1) Checking external state is generally costly so why require it to be done twice? 2) It's error prone: because it's external state, in almost all cases the calling code will needs to implement the same check and treat it as an input error. 3) It sill doesn't work because external state, in general, can change between the check and the call. A possibly better solution would be to use an error handling strategy approach, Have the called function throw and exception supplied by the calling function.
 

... <IXOYE><
Aug 05 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BCS (none anon.com)'s article
 A possibly better solution would be to use an error handling strategy approach,
 Have the called function throw and exception supplied by the calling function.


I wouldn't use this, at least without a sane default exception, because it forces the caller of a function to write boilerplate for error handling (beyond what's necessary for cleanup/rollback in case of an error) even if the caller can't actually handle the errors. This severely smacks of overengineering and making the uncommon case possible at the expense of making the common case simple, and largely defeats two main purposes for exceptions: 1. Noone should have to explicitly think about how to propagate any error. One and only one level should have to think about handling it and the rest of the levels just need to be able to clean up in case of an error. 2. Exceptions are supposed to provide a sane default that's useful for small scripts (exiting the program with a decent error message). If you force the user to explicitly specify an exception to be thrown, you lose this convenience. On the other hand, if you provide a sane default exception, this might be reasonable as long as it doesn't bloat the API too much.
Aug 05 2010
next sibling parent Pelle <pelle.mansson gmail.com> writes:
On 08/05/2010 05:34 PM, dsimcha wrote:
 == Quote from BCS (none anon.com)'s article
 A possibly better solution would be to use an error handling strategy approach,
 Have the called function throw and exception supplied by the calling function.


I wouldn't use this, at least without a sane default exception, because it forces the caller of a function to write boilerplate for error handling (beyond what's necessary for cleanup/rollback in case of an error) even if the caller can't actually handle the errors. This severely smacks of overengineering and making the uncommon case possible at the expense of making the common case simple, and largely defeats two main purposes for exceptions: 1. Noone should have to explicitly think about how to propagate any error. One and only one level should have to think about handling it and the rest of the levels just need to be able to clean up in case of an error. 2. Exceptions are supposed to provide a sane default that's useful for small scripts (exiting the program with a decent error message). If you force the user to explicitly specify an exception to be thrown, you lose this convenience. On the other hand, if you provide a sane default exception, this might be reasonable as long as it doesn't bloat the API too much.

enforce(a<b, "a needs to be smaller than b"); // Exception enforceEx!(RangeError)(a < length, "a out of bounds"); //RangeError Isn't this exactly what you want? Probably, an overload for enforce could be made, so this works: enforce(a < len, new RangeError("out of bounds"));
Aug 05 2010
prev sibling parent BCS <none anon.com> writes:
Hello dsimcha,

 == Quote from BCS (none anon.com)'s article
 
 A possibly better solution would be to use an error handling strategy
 approach, Have the called function throw and exception supplied by
 the calling function.
 


Yeah. Good defaults would be a must. But I was trying to say that would be better than making precondition violations from external state be fatal errors. -- ... <IXOYE><
Aug 05 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 At 14.42: You compare the performance of a D compiler with the performance of
 a C++ compiler. But Delphi compiler was/is very fast (and probably the
 FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal)
 code to compile. I think on average it takes only two thousand clock ticks to
 compile one line of ObjectPascal code. It sounds a lot, but it means that
 with a modern single-core CPU you can produce your binary file from a one
 million ObjectPascal lines long program in less than two seconds.
 ObjectPascal type system looks a bit simpler than D one (despite it has OOP,
 generics, modules, inline asm, dynamic strings, records, all basic D types,
 etc), so this isn't a fully apple-to-apple comparison.

Some context is in order. The talk was given at Google and aimed at what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well. Andrei put together a benchmark that shows that D compiles 4 times faster than Go. As far as I know, Google has no interest in Delphi or ObjectPascal, so how those compilers perform is irrelevant.
Aug 03 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Leandro Lucarella wrote:
 I was surprised by that, can you publish what the benchmark was, and
 what compilers were used?

Andrei has it, I'll leave it up to him.
Aug 03 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:
 D2's (relative) slowness I've tracked down to import std.stdio; - it
 instantiates a bunch of templates just on import. We should be able to
 fix this with a little work, and put D even further ahead of the
 competition.

I have done two little benchmarks, using dmd 2.047, compiling just with "dmd test.d": import std.c.stdio: printf; void main() { printf("%d\n", 10); } import std.stdio: writeln; void main() { writeln(10); } The program with printf compiles in 0.05 seconds, and the binary is 101_404 bytes, while the program with writeln compiles in about 0.30 seconds and produces a binary of 235_036 bytes, the asm shows tons of templates and functions. Bye, bearophile
Aug 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Adam Ruppe:
 D2's (relative) slowness I've tracked down to import std.stdio; - it
 instantiates a bunch of templates just on import. We should be able to
 fix this with a little work, and put D even further ahead of the
 competition.

I have done two little benchmarks, using dmd 2.047, compiling just with "dmd test.d": import std.c.stdio: printf; void main() { printf("%d\n", 10); } import std.stdio: writeln; void main() { writeln(10); } The program with printf compiles in 0.05 seconds, and the binary is 101_404 bytes, while the program with writeln compiles in about 0.30 seconds and produces a binary of 235_036 bytes, the asm shows tons of templates and functions. Bye, bearophile

I've improved on this a bit, and further improvements are easy. If you print strings, write and writeln simply forward to printf. Similar special casing can be done for simple and frequent cases. BTW, speed of compilation of very short programs is not very relevant as long as it's reasonably good. Andrei
Aug 03 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 BTW, speed of compilation of very short programs is not very relevant as 
 long as it's reasonably good.

Also, the compile speed of std.stdio isn't that important because on a large project it is only compiled/loaded once, no matter how many times it is imported. This is a huge reason for D's speed. The problem, though, is all the stuff in the .obj file.
Aug 03 2010
parent BCS <none anon.com> writes:
Hello Walter,

 Andrei Alexandrescu wrote:
 
 BTW, speed of compilation of very short programs is not very relevant
 as long as it's reasonably good.
 

large project it is only compiled/loaded once, no matter how many times it is imported. This is a huge reason for D's speed.

But it becomes a problem again if you have to jump to separate compilation -- ... <IXOYE><
Aug 03 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el  3 de agosto a las 15:08 me escribiste:
 bearophile wrote:
 At 14.42: You compare the performance of a D compiler with the performance of
 a C++ compiler. But Delphi compiler was/is very fast (and probably the
 FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal)
 code to compile. I think on average it takes only two thousand clock ticks to
 compile one line of ObjectPascal code. It sounds a lot, but it means that
 with a modern single-core CPU you can produce your binary file from a one
 million ObjectPascal lines long program in less than two seconds.
 ObjectPascal type system looks a bit simpler than D one (despite it has OOP,
 generics, modules, inline asm, dynamic strings, records, all basic D types,
 etc), so this isn't a fully apple-to-apple comparison.

Some context is in order. The talk was given at Google and aimed at what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well. Andrei put together a benchmark that shows that D compiles 4 times faster than Go.

I was surprised by that, can you publish what the benchmark was, and what compilers were used? I tried Go when it came out and it felt faster than D to compile (which is reasonable because is a much simpler language).

I tested on two laptops (Ubuntu and Mac OSX). I compiled the two languages' standard libraries by using the provided makefiles, after touching all .go and all .d files involved. Then I divided the compilation times by the line counts of *.go/*.d files as wc has them and compared the results. On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45. I had an online demo prepared for the talk, but I decided to not use it. Andrei
Aug 03 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  3 de agosto a las 19:48 me escribiste:
 Leandro Lucarella wrote:
 Walter Bright, el  3 de agosto a las 15:08 me escribiste:
 bearophile wrote:
 At 14.42: You compare the performance of a D compiler with the performance of
 a C++ compiler. But Delphi compiler was/is very fast (and probably the
 FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal)
 code to compile. I think on average it takes only two thousand clock ticks to
 compile one line of ObjectPascal code. It sounds a lot, but it means that
 with a modern single-core CPU you can produce your binary file from a one
 million ObjectPascal lines long program in less than two seconds.
 ObjectPascal type system looks a bit simpler than D one (despite it has OOP,
 generics, modules, inline asm, dynamic strings, records, all basic D types,
 etc), so this isn't a fully apple-to-apple comparison.

what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well. Andrei put together a benchmark that shows that D compiles 4 times faster than Go.

what compilers were used? I tried Go when it came out and it felt faster than D to compile (which is reasonable because is a much simpler language).

languages' standard libraries by using the provided makefiles, after touching all .go and all .d files involved. Then I divided the compilation times by the line counts of *.go/*.d files as wc has them and compared the results. On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.

Seems like a very fair benchmark, I'm really surprised. Which Go compiler did you tried, gccgo or gc (6g/8g)? IIRC gccgo is much slower than gc.

6g. Andrei
Aug 03 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Andrei,

 On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.
 
 I had an online demo prepared for the talk, but I decided to not use
 it.

That /would/ be rather blunt (or pointed, I'm not sure). -- ... <IXOYE><
Aug 03 2010
prev sibling parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Andrei Alexandrescu napisał:

 I tested on two laptops (Ubuntu and Mac OSX). I compiled the two
 languages' standard libraries by using the provided makefiles, after
 touching all .go and all .d files involved. Then I divided the
 compilation times by the line counts of *.go/*.d files as wc has them
 and compared the results.
 
 On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.

Was D with or without --unittest? I'm asking because unittests are instances and plenty of Phobos is templates for which AFAIK much work is deferred to instantiation. Tomek
Aug 04 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/04/2010 01:38 PM, Tomek Sowiński wrote:
 Andrei Alexandrescu napisał:

 I tested on two laptops (Ubuntu and Mac OSX). I compiled the two
 languages' standard libraries by using the provided makefiles, after
 touching all .go and all .d files involved. Then I divided the
 compilation times by the line counts of *.go/*.d files as wc has them
 and compared the results.

 On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.

Was D with or without --unittest? I'm asking because unittests are instances and plenty of Phobos is templates for which AFAIK much work is deferred to instantiation.

No -unittest. In Phobos the unittest build turns -unittest on separately for each module, so I can't quickly test the build speed with -unittest on. That being said, there's still plenty of non-template code in Phobos. BTW Phobos is built in release mode (as I assume go's library is). Building in debug mode reduces build time by more than a third. Andrei
Aug 04 2010
parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Andrei Alexandrescu napisał:

 On 08/04/2010 01:38 PM, Tomek Sowiński wrote:
 Andrei Alexandrescu napisał:

 I tested on two laptops (Ubuntu and Mac OSX). I compiled the two
 languages' standard libraries by using the provided makefiles, after
 touching all .go and all .d files involved. Then I divided the
 compilation times by the line counts of *.go/*.d files as wc has them
 and compared the results.

 On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.

Was D with or without --unittest? I'm asking because unittests are instances and plenty of Phobos is templates for which AFAIK much work is deferred to instantiation.

No -unittest. In Phobos the unittest build turns -unittest on separately for each module, so I can't quickly test the build speed with -unittest on. That being said, there's still plenty of non-template code in Phobos. BTW Phobos is built in release mode (as I assume go's library is). Building in debug mode reduces build time by more than a third.

Hm.. OK. I'm looking forward to round 2, measures taken at the end of the food chain -- a large executable program. Hopefully both languages will soon have enough speciments to choose from. Tomek
Aug 05 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Adam Ruppe wrote:
 The Digital Mars EMCAScript implementation is insanely fast too. It
 comes in at about 80x faster than IE6 - its contemporary competition.
 Now, the new browsers beat it out by several times, but it took them a
 lot of years to catch up.

Yeah, at the time (10 years ago) I shopped it around to the various browser vendors, and nobody believed the speed increase. Sigh.
Aug 03 2010
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i3aofk$242d$1 digitalmars.com...
 Adam Ruppe wrote:
 The Digital Mars EMCAScript implementation is insanely fast too. It
 comes in at about 80x faster than IE6 - its contemporary competition.
 Now, the new browsers beat it out by several times, but it took them a
 lot of years to catch up.

Yeah, at the time (10 years ago) I shopped it around to the various browser vendors, and nobody believed the speed increase. Sigh.

Out of curiosity, what sorts of people did you speak to? The actual developers or, well, people who aren't primarily developers? The latter tend to be complete morons ( "I don't know anything about programming, but I'm very good at identifying people who are good at it.": http://www.semitwist.com/articles/article/view/human-resource -the-expert-novices )
Aug 07 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/03/2010 04:31 PM, bearophile wrote:
 BCS:

 The video is up: http://www.youtube.com/watch?v=RlVpPstLPEc

Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program.

Thanks. I hope the difference is in the "good" direction. Somehow I find it difficult to grok the right tone on the Usenet. Regarding this talk, I was so nervous during it that I was (and am after watching the recording) unable to assess the talk's quality. I was mostly on autopilot throughout; for example I seem to vaguely recall at some point there were some people standing in the back, but I have no idea when they appeared.
 27.50, "transactional file copy": this example was script-like, and
 as short as possible to fit into one single slide, so in this case I
 think using enforce() is OK. But in true programs I suggest all D
 programmers to use DesignByContract with assert() more and to use
 enforce() less. Among other things enforce() kills inlining
 possibilities and inflates code. In D.learn I have seen people use
 enforce() in a situation where DbC is designed for. I think the D
 community needs to learn a bit more DbC, and in my opinion to do this
 the leaders have to lead the way.

I agree with Walter that enforce() is the only right choice there.
 42.00: I don't know what Big-O() encapsulation is. I think later you
 explain it a bit more, but I have lost the meaning.

Sorry. By that I mean an abstraction that uses information hiding to make complexity an implementation detail, instead of an interface requirement. Consider e.g. at(int) for a sequence container which makes no claim about complexity.
 57.36: The Wikipedia Levenshtein entry can be improved a bit, to
 remove the random access requirement, if not already done :-) Often
 in practice you have to pay a certain performance price for
 genericity. So an interesting question is, with the current DMD
 compiler how much slower than an array-based Levenshtein function is
 the generic Phobos one when the input is for example a couple of
 ubyte arrays? If it's only about two or three times slower then it's
 probably good enough.

The implementation using only forward access is not slower in theory because it never needs to search to an index. It is a bit slower on ASCII strings because it needs one extra test per character to assess its width. But on UTF strings it saves time by avoiding copying and by working correctly :o). Thanks, Andrei
Aug 03 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 57.36: The Wikipedia Levenshtein entry can be improved a bit, to
 remove the random access requirement, if not already done :-) Often
 in practice you have to pay a certain performance price for
 genericity. So an interesting question is, with the current DMD
 compiler how much slower than an array-based Levenshtein function is
 the generic Phobos one when the input is for example a couple of
 ubyte arrays? If it's only about two or three times slower then it's
 probably good enough.

The implementation using only forward access is not slower in theory because it never needs to search to an index. It is a bit slower on ASCII strings because it needs one extra test per character to assess its width. But on UTF strings it saves time by avoiding copying and by working correctly :o).

I have done three benchmarks, because I am curious. This is compiled with dmd 2.047 with -O -release -inline, the strings used are longhish, about 1200 chars long. To test what you have said I have cast the strings to immutable(ubyte)[] before calling levenshteinDistance, this can be done when you are sure the strings are 7 bit ASCII, and indeed the running times are different, about 1.66 seconds against 2.57 seconds on a slow 32 bit Windows PC: import std.algorithm: levenshteinDistance; import std.c.stdio: printf; void main() { string s1 = "Returns the Levenshtein distance between s and t." ~ "The Levenshtein distance computes the minimal amount of edit operations" ~ "necessary to transform s into t."; string s2 = "Returns the Lovenshtein distonce between p and q." ~ "The Lovenshtein distonce computes the minimal amount of odit operations" ~ "necessary to transform p into q."; for (int i; i < 3; i++) { s1 ~= s1; s2 ~= s2; } int d; for (int i; i < 40; i++) { static if (1) { // 2.57 seconds d += levenshteinDistance(s1, s2); } else { // 1.66 seconds alias immutable(ubyte)[] ImmutableubytesArray; d += levenshteinDistance(cast(ImmutableubytesArray)s1, cast(ImmutableubytesArray)s2); } } printf("%d\n", d); } Then I have tried the same strings with the Levenshtein distance functions of the dlibs1, with dmd v1.042 (I have not yet ported the dlibs1 to D2, and probably there will be no need to port lot of the stuff, because Phobos2 contains more stuff) with -O -release -inline, using the same strings, the running time is about 0.25 seconds: import std.c.stdio: printf; import d.func: editDistanceFast; void main() { string s1 = "Returns the Levenshtein distance between s and t." ~ "The Levenshtein distance computes the minimal amount of edit operations" ~ "necessary to transform s into t."; string s2 = "Returns the Lovenshtein distonce between p and q." ~ "The Lovenshtein distonce computes the minimal amount of odit operations" ~ "necessary to transform p into q."; for (int i; i < 3; i++) { s1 ~= s1; s2 ~= s2; } int d; for (int i; i < 40; i++) { // 0.25 seconds d += editDistanceFast(s1, s2); } printf("%d\n", d); } Unfortunately my editDistanceFast can't be used in Phobos2 for licence issues, because this pure-D1 (no asm used) routine is an improvement of C code written by another person that is not compatible with the Boost licence :-( Bye, bearophile
Aug 03 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i3a5d6$pig$1 digitalmars.com...
 On 08/03/2010 04:31 PM, bearophile wrote:
 BCS:

 The video is up: http://www.youtube.com/watch?v=RlVpPstLPEc

Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program.

Thanks. I hope the difference is in the "good" direction. Somehow I find it difficult to grok the right tone on the Usenet. Regarding this talk, I was so nervous during it that I was (and am after watching the recording) unable to assess the talk's quality. I was mostly on autopilot throughout; for example I seem to vaguely recall at some point there were some people standing in the back, but I have no idea when they appeared.

I thought the talk was great. :)
 27.50, "transactional file copy": this example was script-like, and
 as short as possible to fit into one single slide, so in this case I
 think using enforce() is OK. But in true programs I suggest all D
 programmers to use DesignByContract with assert() more and to use
 enforce() less. Among other things enforce() kills inlining
 possibilities and inflates code. In D.learn I have seen people use
 enforce() in a situation where DbC is designed for. I think the D
 community needs to learn a bit more DbC, and in my opinion to do this
 the leaders have to lead the way.

I agree with Walter that enforce() is the only right choice there.

For a slide-presentation I agree. But if I were writing it for myself, I would just use "if()" and "return 1;". (I do like enforce() for other uses though.)
 42.00: I don't know what Big-O() encapsulation is. I think later you
 explain it a bit more, but I have lost the meaning.

Sorry. By that I mean an abstraction that uses information hiding to make complexity an implementation detail, instead of an interface requirement. Consider e.g. at(int) for a sequence container which makes no claim about complexity.

I used to disagree with that, but I think I've been sufficiently convinced.
Aug 07 2010
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 8/3/2010 5:21 PM, Adam Ruppe wrote:
 
 Then, just ditch that sloooow GNU ld on linux.

I played with using gold some.. a newer linker, and in general it's a good bit faster then the older ld (I want to say it was about half the runtime, ie, twice as fast). However, in running the dmd test suite, gold causes failures that don't appear with the older ld. I haven't invested the time to dig into it.. it was a quick and dirty experiment. Not that gold is up to the speed of optlink, but any improvement is good. :) If anyone is interested in reducing the test case (hopefully to the point of not requiring any d runtime or phobos code -- ie seriously minimal -- I can go find the .d code that triggered the problem. On the other hand, it'd probably be easy enough to find just by running the dmd test suite that's checked into the svn tree. I bet it's not one of the few tests that aren't public yet. Later, Brad
Aug 03 2010
prev sibling parent reply awishformore <awishformore nospam.plz> writes:
On 03/08/2010 23:31, bearophile wrote:
 BCS:

 The video is up:
 http://www.youtube.com/watch?v=RlVpPstLPEc

Thank you for the link and thank you to Andrei for the very nice talk. I think the link can be put on Reddit too, if not already present. When Andrei talks he seems a little different from the Andrei that writes in this newsgroup. The talk was quite interactive, and the idea of giving away books for good questions was a good one. The people in the room seem to know how to program. ... In the time has taken me to see and comment the video the number of people that have seen it has gone from 3 to 322. This is a lot in a short time. Bye and thank you for the ride, bearophile

I'm a bit surprised, and positively so. The talk now has only less views than 2 videos of 2010 and I'm sure it will surpass these in due time, too. Seems like D is more popular and has more momentum left than I thought, after all. Good to see and thanks for the nice talk Andrei. /Max
Aug 05 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from awishformore (awishformore nospam.plz)'s article
 I'm a bit surprised, and positively so. The talk now has only less views
 than 2 videos of 2010 and I'm sure it will surpass these in due time,
 too.

Can you clarify this? Relative to what? All of YouTube (no way)? All Google Tech Talk videos?
Aug 05 2010
next sibling parent awishformore <awishformore nospam.plz> writes:
On 05/08/2010 17:55, Andrej Mitrovic wrote:
 On Thu, Aug 5, 2010 at 5:38 PM, dsimcha <dsimcha yahoo.com
 <mailto:dsimcha yahoo.com>> wrote:

     == Quote from awishformore (awishformore nospam.plz)'s article
      > I'm a bit surprised, and positively so. The talk now has only
     less views
      > than 2 videos of 2010 and I'm sure it will surpass these in due time,
      > too.

     Can you clarify this?  Relative to what?  All of YouTube (no way)?
       All Google
     Tech Talk videos?


 I only see some 5k views on that video. And there are videos with over
 100k views from the google tech talk channel. Maybe it's shown on his
 personal page which makes it look like its a top video of 2010.

It's the third most watched video of all published google tech talks of 2010. Of course it's miles away from videos like Go with over 200k views, which is from 2009. I just found it nice to see that there is more interest in the google tech talk about D than in most other "normal" tech talks. /Max
Aug 05 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jeff Nowakowski:
I keep seeing reports from people running into bugs, unfinished features, and
incomplete documentation. There's no end in sight, either, yet a book has been
released and the language is promoted as if it were a finished product.<

A software product is "finished" some time after its death. Living languages are unfinished things. And not all bug reports are born equal. Some of them are minor enhancement requests, other are important enhancement requests that put a patch on some important limit or problem, others are holes in the documentation, others are minor bugs, improvements for error messages or bugs that have some temporary workaround, others are bugs that hit very uncommon situations. Only a very small percentage of the bugs are both bad and very easy to stumble upon, and then there are problems that stop you from using the compiler on some operation system. Don takes care of keeping an eye on the most important bugs, critical ones or blocking ones, and they slowly get addressed. As time passes and large things are fixed, the less important bugs will be filled, if in the meantime people have shown interest in D. As the D community grows (if D has success) more people will be able to spot bugs, submit patches, and more bugs will be fixed. In that moment Walter will need to delegate more, but the D community is not there yet. D is a C++-class language, it's a large language, and it's made of many parts, so there are probably thousands of bugs left to be fixed, but most of them are not critical :-) So far I have added more than 230 bug reports to Bugzilla, some of them are ugly crashes, etc, but only a small percentage of them are "important", probably less than 20. -------------- Andrej Mitrovic:
 I only see some 5k views on that video.

5k views in few days is a lot. So there is surely some interest toward D. C++ is slowly becoming a niche language, but it's a large niche still, and it's years that people try to look for something better. But even if no new features are added to D2 for some time, I think it will take something like two more years to have a language+compiler good enough for serious purposes. Bye, bearophile
Aug 05 2010
prev sibling next sibling parent Pelle <pelle.mansson gmail.com> writes:
On 08/03/2010 06:04 PM, BCS wrote:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

http://www.reddit.com/r/programming/comments/cx09f/google_tech_talk_andrei_alexandrescu_three_cool/ Good talk, Andrei!
Aug 03 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
BCS wrote:
 The video is up:
 http://www.youtube.com/watch?v=RlVpPstLPEc

And Hacker News: http://news.ycombinator.com/item?id=1572025
Aug 03 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el  3 de agosto a las 15:08 me escribiste:
 bearophile wrote:
At 14.42: You compare the performance of a D compiler with the performance of
a C++ compiler. But Delphi compiler was/is very fast (and probably the
FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal)
code to compile. I think on average it takes only two thousand clock ticks to
compile one line of ObjectPascal code. It sounds a lot, but it means that
with a modern single-core CPU you can produce your binary file from a one
million ObjectPascal lines long program in less than two seconds.
ObjectPascal type system looks a bit simpler than D one (despite it has OOP,
generics, modules, inline asm, dynamic strings, records, all basic D types,
etc), so this isn't a fully apple-to-apple comparison.

Some context is in order. The talk was given at Google and aimed at what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well. Andrei put together a benchmark that shows that D compiles 4 times faster than Go.

I was surprised by that, can you publish what the benchmark was, and what compilers were used? I tried Go when it came out and it felt faster than D to compile (which is reasonable because is a much simpler language). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- EXTRAÑA RELACION ENTRE UN JUBILADO Y UN JABALI -- Crónica TV
Aug 03 2010
prev sibling next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:
 
 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- no longer afraid of the dark or midday shadows nothing so ridiculously teenage and desperate, nothing so childish - at a better pace, slower and more calculated, no chance of escape,
Aug 03 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

Yellow shirt? Yes, I plan to ask Benjamin about his whereabouts and send him a book. Andrei
Aug 03 2010
prev sibling next sibling parent reply Rory Mcguire <rjmcguire gm_no_ail.com> writes:
Leandro Lucarella wrote:

 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:
 
 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

What type of apps are you looking for? I have a couple of smtp apps.
Aug 04 2010
next sibling parent Rory Mcguire <rjmcguire gm_no_ail.com> writes:
Leandro Lucarella wrote:

 Rory Mcguire, el  4 de agosto a las 12:37 me escribiste:
 Leandro Lucarella wrote:
 
 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:
 
 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

What type of apps are you looking for?

Anything that can be automatically run for benchmarking, if they do intensive use of the GC or need small pauses, much better. But if it's D2, I'm sorry but is too late, I'll stick to D1 for now, when I'm finish I probably try to port it to D2 and ask again.
 I have a couple of smtp apps.

SMTP as in Simple Mail Transfer Protocol?

yes. I have a threaded smtp benchmark app and an smtp blackhole server, for instance. I use them to benchmark my java smtp server. I'll try find my D1 stuff if you would like it.
Aug 04 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <luca llucax.com.ar> wrote in message 
news:20100804132228.GG21917 llucax.com.ar...
 Rory Mcguire, el  4 de agosto a las 12:37 me escribiste:
 Leandro Lucarella wrote:

 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

What type of apps are you looking for?

Anything that can be automatically run for benchmarking, if they do intensive use of the GC or need small pauses, much better. But if it's D2, I'm sorry but is too late, I'll stick to D1 for now, when I'm finish I probably try to port it to D2 and ask again.

Building Goldie's documentation (it uses a custom doc generator) using "makeDocs" might work: http://www.semitwist.com/goldiedocs/v0.3/Docs/Tools/GenDocs/ There's a number of places in it right now where it uses .dup to work around D1's lack of D2-style const. And with the default settings in the "makeDocs" script (it's just a one-liner), it does a fair amount of string-building via the concatenation operator. Yea, I need to optimize ;) On my (aging) system the whole thing currently takes 20 seconds to run. It does do a bit of file I/O though, I don't know if that would get in the way of what you're trying to measure. You'd have to install Goldie (and SemiTwist D Tools) first: http://www.semitwist.com/goldiedocs/v0.3/Docs/Install/ I think people have generally been avoiding writing GC-intensive code in D though. Although, come to think of it, bearophile could probably supply you with some deliberately GC-intensive code specifically for benchmarking.
Aug 04 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:
 Yes, I borrowed some deliberately GC-intensive benchmarks done by him,
 most notably the voronoi generator[1], which made me sweat[2] more than
 once :)

On my site you can find four other Olden benchmarks: em3d tsp bisort bh http://bit.ly/cYlQUe And I hope to add one or two more when time allows me to :-) Probably they are D2 code, but probably converting them to D1 is not hard. The versions fitter for you are the first ones translated from Java to D, because the optimized versions minimize the heap activity to increase performance (and the speed difference is usually large). Bye, bearophile
Aug 04 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:
 Thanks, that would be the xxx01.d I guess, right?

Right, generally. Inside each zip there is usually a text file that explains what each file/version is, and more. Some of those readme contain enough material to write a paper about :-) Bye, bearophile
Aug 04 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <luca llucax.com.ar> wrote in message 
news:20100804192922.GM21917 llucax.com.ar...
 Nick Sabalausky, el  4 de agosto a las 12:51 me escribiste:
 What type of apps are you looking for?

Anything that can be automatically run for benchmarking, if they do intensive use of the GC or need small pauses, much better. But if it's D2, I'm sorry but is too late, I'll stick to D1 for now, when I'm finish I probably try to port it to D2 and ask again.

Building Goldie's documentation (it uses a custom doc generator) using "makeDocs" might work: http://www.semitwist.com/goldiedocs/v0.3/Docs/Tools/GenDocs/ There's a number of places in it right now where it uses .dup to work around D1's lack of D2-style const. And with the default settings in the "makeDocs" script (it's just a one-liner), it does a fair amount of string-building via the concatenation operator. Yea, I need to optimize ;) On my (aging) system the whole thing currently takes 20 seconds to run. It does do a bit of file I/O though, I don't know if that would get in the way of what you're trying to measure. You'd have to install Goldie (and SemiTwist D Tools) first: http://www.semitwist.com/goldiedocs/v0.3/Docs/Install/

Thanks I'll see if it's not much trouble to install, I'd like to build a benchmark without tons of dependencies.

If you do have any troubles installing, please let me know. I want to try to keep it as easy as possible. The standard build system used does require xfbuild or rebuild ATM, but that's only because the rdmd included with D1 is still out-of-date and has a certain blocking bug that was fixed in trunk a few months ago. If you really don't want to use xfbuild or rebuild, you *probably* can get the latest trunk rdmd and change the build scripts to call stbuild with "-tool:rdmd" instead of "-tool:xf" or "-tool:re".
Aug 04 2010
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 04/08/10 00:18, Leandro Lucarella wrote:
 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

I know of several large apps written in D, they're all D1/Tango. -- Robert http://octarineparrot.com/
Aug 04 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/04/2010 05:16 PM, Robert Clipsham wrote:
 I know of several large apps written in D, they're all D1/Tango.

The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2. People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.
Aug 04 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
 On 08/04/2010 05:16 PM, Robert Clipsham wrote:
 I know of several large apps written in D, they're all D1/Tango.

The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2. People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.

Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support. Andrei
Aug 04 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Walter is more silent than usual because he's working very hard on the 
 64-bit compiler. He hopes to have one by the end of this month. His next 
 big goal is shared library support.

I am sorry to say this, but I think porting the current back-end to 64 bit is a waste of time because it will not be used for professional usages. I think LLVM will be the main back-end for professional usages of D2, with maybe GDC2 or later even a dotnet D2 compiler too. I think it's more important for Walter to focus on filling D2 design holes, removing front-end bugs and implementing unfinished features (I'd also like Walter to modify the D2 front-end to make it a bit simpler to attach it to LLVM). Bye, bearophile
Aug 04 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:
 Get back to me when LDC starts to actually /work/. It is *completely
 unusable* in its current state and its developers don't seem to care.

Go back to read my post again, it doesn't contain the name "LDC". Bye, bearophile
Aug 04 2010
parent Petr Janda <janda.petr gmail.com> writes:
 Go back to read my post again, it doesn't contain the name "LDC".

But LDC is the D frontend for LLVM right, so wouldn't it be more useful to talk about LDC rather than LLVM?
Aug 04 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Andrei Alexandrescu:
 Walter is more silent than usual because he's working very hard on the
 64-bit compiler. He hopes to have one by the end of this month. His next
 big goal is shared library support.


will be the main back-end for professional usages of D2, with maybe GDC2 or later even a dotnet D2 compiler too. Why is DMD not usable professionally? I think that, since a key niche for D is scientific computing, 64-bit is an absolute must-have. No other issue with D has caused me half as much pain as lack of 64-bit support when I use D for bioinformatics work on large datasets. Not lack of shared library support, not misc. compiler bugs, not lack of library support, not lack of IDE support, not even lack of precise GC. In hindsight, D is such an awesome language that I still don't regret using it and working around the lack of 64 support, but at times I felt like I was trapped in the caveman era with an old 8086 and the 640K barrier. Yes, LDC will hopefully be ported to D2 eventually, or another LLVM-based D compiler might be written. Yes, GDC2 may be caught up eventually. Regardless, the flagship implementation still needs to be good at what the language claims to be good at, and if the language seems to be targetting scientific computing, and claims to be somewhat mature, lack of 64-bit support in the reference implementation is simply inexcusable. P.S. None of this should be construed as an attack, complaint, etc. against Walter. I understand the need to get the core language spec stable before working on tool chain issues, and until recently D2 made no claim to being "somewhat mature". Now that it is making that claim, 64-bit support is being taken seriously, as it should be.
Aug 04 2010
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello bearophile,

 Andrei Alexandrescu:
 
 Walter is more silent than usual because he's working very hard on
 the 64-bit compiler. He hopes to have one by the end of this month.
 His next big goal is shared library support.
 

bit is a waste of time because it will not be used for professional usages. I think LLVM will be the main back-end for professional usages of D2, with maybe GDC2 or later even a dotnet D2 compiler too. I think it's more important for Walter to focus on filling D2 design holes, removing front-end bugs and implementing unfinished features (I'd also like Walter to modify the D2 front-end to make it a bit simpler to attach it to LLVM).

For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC. So he needs to have a back end that he can work on so he's going to work on the back end he has, the one that DMD is using now. Also, I'll bet that about the same time that DMD64 comes out, DMC64 will to and that is also valuable in it's own right. -- ... <IXOYE><
Aug 04 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
mwarning wrote:
 On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:
 
 For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

I remember that statement has appeared before, but I can't remember the reason that was given.

Because when I've had the roomful of lawyers do their due diligence on me, saying "I never looked at the source code" is an effective defense against any claims of possible infringement. When I say that, they click their briefcases shut, say "we're done here", and leave.
Aug 05 2010
next sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Thu, 5 Aug 2010, Leandro Lucarella wrote:

 Walter Bright, el  5 de agosto a las 13:34 me escribiste:
 Because when I've had the roomful of lawyers do their due diligence
 on me, saying "I never looked at the source code" is an effective
 defense against any claims of possible infringement. When I say
 that, they click their briefcases shut, say "we're done here", and
 leave.

That seems a little stupid, there are billions of open source projects, and I never hear anyone giving that excuse not to contribute. Your argument about having to convince people that a feature have merits or the bigger inertia to do changes is a valid one, but that one is just bogus.

False comparisons. Walter commercially licenses DMC which shares a lot of code with DMD. Looking at LLVM and GCC would open him up to legalities that are easily avoided by not. MOST open source contributors aren't in that sort of position. Would Oracle be in a tough spot if someone on their sql engine team contributed to the mysql code base (prior to it's being brought into the oracle family)? Absolutely. Even with it as part of the family, I bet good money that maintain a nice tight separation of resources to avoid the potential of tainting their commercial baby with gpl issues. Bogus? Not even a little. Later, Brad
Aug 05 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el  5 de agosto a las 13:34 me escribiste:
 mwarning wrote:
 On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:

 For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

I remember that statement has appeared before, but I can't remember the reason that was given.

on me, saying "I never looked at the source code" is an effective defense against any claims of possible infringement. When I say that, they click their briefcases shut, say "we're done here", and leave.

That seems a little stupid, there are billions of open source projects, and I never hear anyone giving that excuse not to contribute.

Have you ever been specifically grilled by lawyers if you stole code from gcc? I have. When people are going to invest a lot of money in your stuff, it better be clean.
Aug 05 2010
parent gcc-lurker <lurker lurk.org> writes:
Walter Bright Wrote:

 Leandro Lucarella wrote:
 Walter Bright, el  5 de agosto a las 13:34 me escribiste:
 mwarning wrote:
 On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:

 For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

I remember that statement has appeared before, but I can't remember the reason that was given.

on me, saying "I never looked at the source code" is an effective defense against any claims of possible infringement. When I say that, they click their briefcases shut, say "we're done here", and leave.

That seems a little stupid, there are billions of open source projects, and I never hear anyone giving that excuse not to contribute.

Have you ever been specifically grilled by lawyers if you stole code from gcc? I have. When people are going to invest a lot of money in your stuff, it better be clean.

I thought the FSS owned GCC. It seems the smelly Stallman is using his evil powers and unaware henchmen to force the freedom down our throats. That's why we should use unrestrictive commercial friendly licenses only such as the Phobos/Boost alliance and BSD. Say no to (L)GPL!
Aug 05 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el  5 de agosto a las 13:34 me escribiste:
 mwarning wrote:
 On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:

 For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

I remember that statement has appeared before, but I can't remember the reason that was given.

on me, saying "I never looked at the source code" is an effective defense against any claims of possible infringement. When I say that, they click their briefcases shut, say "we're done here", and leave.

That seems a little stupid, there are billions of open source projects, and I never hear anyone giving that excuse not to contribute. Your argument about having to convince people that a feature have merits or the bigger inertia to do changes is a valid one, but that one is just bogus. And BTW, not all projects have the high inertia DMD have, a lot of projects are much more permeable and more open to external contributions. Obviously there will be always a little more work to coordinate work with others when not all the decisions are made by only you (as is now with the DMD backend), but I don't think it would be that bad either, and the tradeoff of what you gain vs. what you loose will be probably at large in your favor (at least in the long term) if you decided to start using LLVM as the backend. Not that I'm expecting you to do it, I'm just saying :)

I think it's fair to compare dmd against other PL projects (python, ruby, php etc.) How are those organized? Andrei
Aug 05 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/08/2010 00:43, Leandro Lucarella wrote:
 Walter Bright, el  5 de agosto a las 13:34 me escribiste:
 mwarning wrote:
 On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:

 For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

I remember that statement has appeared before, but I can't remember the reason that was given.

Because when I've had the roomful of lawyers do their due diligence on me, saying "I never looked at the source code" is an effective defense against any claims of possible infringement. When I say that, they click their briefcases shut, say "we're done here", and leave.

That seems a little stupid, there are billions of open source projects, and I never hear anyone giving that excuse not to contribute. Your argument about having to convince people that a feature have merits or the bigger inertia to do changes is a valid one, but that one is just bogus.

Also, quite a lot of those billion open source projects have commercial-friendly licenses (BSD, Boost, Apache licence, Eclipse Pubic License, etc.), so naturally their contributors do not have all these worries of taint. I find myself wishing some more OSS projects had commercial-friendly licenses. :-/ In particular LLVM, as I do agree it might have been great if Walter were able to work with it without these IP worries. -- Bruno Medeiros - Software Engineer
Sep 20 2010
parent reply klickverbot <see klickverbot.at> writes:
On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?
Sep 20 2010
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

Oh, from this discussion, I thought LLVM was GPL or LGPL, but not BSD (or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone. -- Bruno Medeiros - Software Engineer
Sep 20 2010
next sibling parent reply Don <nospam nospam.com> writes:
retard wrote:
 Mon, 20 Sep 2010 14:14:09 -0400, Steven Schveighoffer wrote:
 
 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been
 great
 if Walter were able to work with it without these IP worries.


(or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

makes it undesirable license for commercial use. The issue is taint. I find this aspect of copyright and licensing highly dubious (I can barely remember what I did last week, not to mention some souce code I read last year), but the issue is this: Let's say Walter does read LLVM source code, and then works on another compiler project for another company that is completely proprietary. LLVM has some possible connection to interject and say "you have to give LLVM developers credit," even if Walter didn't copy any code. Yeah, it's ridiculous and absurd, but possible.

So the another company goes bankrupt if Walter has to mention the name 'LLVM developers' in the documentation nobody reads and in an About dialog nobody ever reads? I understand this when the other project (LLVM in this case) has some viral license like GPL, but in this case they only expect moral attribution. Your ideology is sick: "we must steal as much as possible from the open source dickheads without giving attribution, and turn the code into proprietary DRM shit to enslave the world muhahaha"

I think there's no problem with using the liberal license in a compiler, or in fact in any app. Walter deliberately errs on the paranoid side, because of past court experiences he's had. It's only in the standard library that the licensing can be a problem -- we don't want "hello world" to require binary attribution.
Sep 20 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/09/2010 21:48, Don wrote:
 retard wrote:
 Mon, 20 Sep 2010 14:14:09 -0400, Steven Schveighoffer wrote:

 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been
 great
 if Walter were able to work with it without these IP worries.


(or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

makes it undesirable license for commercial use. The issue is taint. I find this aspect of copyright and licensing highly dubious (I can barely remember what I did last week, not to mention some souce code I read last year), but the issue is this: Let's say Walter does read LLVM source code, and then works on another compiler project for another company that is completely proprietary. LLVM has some possible connection to interject and say "you have to give LLVM developers credit," even if Walter didn't copy any code. Yeah, it's ridiculous and absurd, but possible.

So the another company goes bankrupt if Walter has to mention the name 'LLVM developers' in the documentation nobody reads and in an About dialog nobody ever reads? I understand this when the other project (LLVM in this case) has some viral license like GPL, but in this case they only expect moral attribution. Your ideology is sick: "we must steal as much as possible from the open source dickheads without giving attribution, and turn the code into proprietary DRM shit to enslave the world muhahaha"

I think there's no problem with using the liberal license in a compiler, or in fact in any app. Walter deliberately errs on the paranoid side, because of past court experiences he's had. It's only in the standard library that the licensing can be a problem -- we don't want "hello world" to require binary attribution.

Ah, I see now. I was only thinking in terms of the compiler, where it would not be a big deal if someone accused that the compiler used BSD-licensed code. But for the standard library, it would not be good at all. -- Bruno Medeiros - Software Engineer
Sep 23 2010
prev sibling next sibling parent reply klickverbot <see klickverbot.at> writes:
On 9/21/10 3:55 PM, Steven Schveighoffer wrote:
 People seem to think that an accusation is proof. If someone says you
 stole their code, because you read it, it's not always true. It's just
 much easier to prove you didn't steal it if you didn't read it.

And how exactly are you going to prove that you didn't read it?
Sep 21 2010
next sibling parent klickverbot <see klickverbot.at> writes:
 And how exactly are you going to prove that you didn't read it?

I should add that the whole situation seems like a paranoid's man version of »a burnt child dreads the fire« to me, but I guess Walter has his reasons…
Sep 21 2010
prev sibling next sibling parent reply klickverbot <see klickverbot.at> writes:
On 9/21/10 4:31 PM, Steven Schveighoffer wrote:
 Huh? Look, this isn't an issue of being deceitful, it's an issue of the
 defensible strength of "yes, I read it, but I didn't copy anything" vs.
 "no I didn't read it, so I couldn't have copied anything." If you don't
 believe the person, then it's up to you to prove they're lying.
 […]
 It's even possible to read code, understand the ideas, and write your
 own code to implement the ideas (commonly done via a clean-room
 implementation).

I guess I don't quite understand US copyright laws here: Here in Europe, if somebody accuses you of copying their work, they have to prove that you in fact did copy it. Let's assume that person manages to convince a judge that your code is in fact a copy of theirs. To defend yourself, it should not really make a difference whether you claim that you read that code or not. Even if it mattered whether you looked at the code or not (at least for Europe, I'm reasonably sure that it does not), how are you going to convince the judge that you didn't look at the source code? After all, for Open Source projects, the source code is publicly available at the internet, and if you did not write your program in jail or deep down in the ocean in a submarine, there is always the possibility that you could have looked at the code. As I said, I don't really know much about the US copyright laws, but if you are used to common European jurisdiction, this situation seems pretty bizarre…
Sep 21 2010
next sibling parent reply klickverbot <see klickverbot.at> writes:
On 9/21/10 5:01 PM, Steven Schveighoffer wrote:
 People aren't convicted on "possibilities" they are convicted on
 proof.

Okay, I suppose I was not as clear about my point as I hoped I would be: This is exactly what I wanted to say – if you want to sue somebody for copying your code, it has to be proven that they took your code, not just possible. But I don't see how just reading other people's code would affect that – either you copied it, or you didn't. My point about the source being freely available on the internet was just to illustrate that claiming »But, your honor, I didn't even read that other piece of code« does not seem like a very strong defense to me *if the court has already been convinced that you copied other code*, e.g. by an expert's opinion. I should also add that I am no lawyer, and I am generally only very modestly experienced in legal issues, so please bear with me if my questions don't make much sense – I just want to understand the reason why Walter is so exceptionally afraid of looking at other projects. To me, it seems a bit as if a researcher refused to keep himself informed about scientific progress in the field he is working on, just because he could be accused of stealing from other people (yes, that's a weak analogy, I know). Oh, and I am perfectly aware of the fact that there is no common European jurisdiction in these matters, but to the best of my knowledge, the laws regarding intellectual property are quite similar from a high-level point of view in many European countries – and probably in large contrast with US copyright laws, which is what I intended to hint at.
Sep 21 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 I am sure Walter reads other code, and especially learns about languages
 other than C, C++ and D -- not to do so would be to abdicate one's
 professional responsibility to stay up to date in one's field.  The
 problem is to set up a clear barrier to the accusation of copying.  So
 to take a well known example:  FOSS project contributors should never
 read Microsoft copyright code, and Microsoft employees should never read
 GPL and LGPL code -- substitute any profit-making company that relies on
 licence revenues for Microsoft, it is just that using Microsoft here is
 almost certainly not libellous.   Rigidly following behaviour such as
 this is not a total defence in a copyright action, but it sets a pattern
 of corporate and individual behaviour that makes a copyright
 infringement less likely and more difficult to prove sufficiently to win
 an action.

Back in the 80's, making a clone PC required copying the BIOS, or at least people assumed it would. This put a huge barrier in place, as IBM had a reputation of aggressively suing anyone who might infringe. This nut was eventually cracked by Phoenix, who set up 3 groups: Group 1. read the IBM PC BIOS, and wrote a specification for it. Group 2. implemented the specification, and WAS NOT ALLOWED TO EVER LOOK AT THE IBM PC BIOS CODE. Group 3. a group of lawyers who read (1) and (2) and verified there was no copying No communication between G1 and G2 was allowed that did not go through G3. They were kept physically separated. Extensive documentation was made of every step in this process. It left absolutely no crack for IBM to drive a lawsuit through, and it worked. The market for clones was blown wide open, and Phoenix made a fortune supplying the BIOSes for them.
Sep 21 2010
prev sibling parent Kagamin <spam here.lot> writes:
klickverbot Wrote:

 This is exactly what I wanted to say – if you want to sue somebody for 
 copying your code, it has to be proven that they took your code, not 
 just possible. But I don't see how just reading other people's code 
 would affect that – either you copied it, or you didn't.

By reading other people's code you rob them.
Sep 21 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 The fact that the code is available does not make it likely that you 
 copied it!  You can't just publish code and then claim any similar code 
 *must* be yours because it's impossible for someone not to look at your 
 code.  People aren't convicted on "possibilities" they are convicted on 
 proof.

Copyright infringement is a civil, not criminal, case, and so a decision is based on a "preponderance" of evidence rather than proof "beyond a reasonable doubt".
Sep 21 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I didn't exactly mean beyond a reasonable doubt, but I think the point 
 of not ever looking at or touching another's source is equivalent to 
 proof of the contrary, no?  I think they at least have to prove that you 
 accessed the code :)  I don't think "because the source is available 
 online" is evidence at all, that was my point.  Otherwise, you'd have to 
 cancel your internet service just to be safe...

Right, and the source code may even reside on your disk (sheesh, I've got terabytes of stuff on disks, there may very well be source code to something on that!). Access is not proof that one looked at it. It comes down to one's credibility, coupled with absence of other evidence of copying (like matching source text).
Sep 21 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 One other way to ensure you have evidence to the contrary is to use 
 source control.  Not only is it good for productivity and disaster 
 recovery, but it shows perfect snapshots of how you developed the code, 
 and the timeline of development.  So even if your code *does* end up 
 looking similar, you can show how you independently came up with the 
 similar code.

I agree that using source control is a great defense against false accusations. I've switched to using it for my projects because of that.
Sep 21 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 Maybe, but I'm fairly certain that Walter *has* consulted copyright 
 lawyers about this, and his decision is a reflection of that 
 discussion.  Judging by that, I think we can assume via anecdotal 
 evidence that his position is pretty solid.

I've been involved in copyright infringement cases from both directions, both as accused and accuser. Not having copied code does not guarantee you won't be accused of infringement. But doing everything practical to make it hard for others to get traction for their case helps avoid very expensive legal bills. A couple examples: 1. I once got a very grumpy email from a person accusing me of selling his software without a license. I dug up an email from him to me that was several years old giving me permission, and forwarded that to him. I got a very contrite apology back. It pays to keep your old emails. 2. A major corporation contracted me to do some work for them. I did, and they shipped it, but refused to pay me. They claimed they "rewrote it from scratch". An 'nm' on their binary showed that 95% of the names in the software were identical to what I provided them. They folded. 3. A couple of programmers decided that they had created the game Empire. I produced registered copyrights that predated their claim of initially writing it by 5 years. They folded. 4. Twice I've had people try to trick me into shipping code that *they* stole. 5. I was once accused of stealing A's software, when A had stolen it from me. This is only some of the crap I've had to put up with. I know many people think I'm paranoid and overreact to this. I'm the one who'll get stuck with the legal bills, though, so I think I'll stick with being paranoid. Oh, and saying "I never looked at that source code" is a satisfactory answer to a phalanx of corporate copyright lawyers, in my experience.
Sep 21 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 People often settle not because they are wrong, but because it's 
 cheaper.  Rather be still in business and "wrong" than prove I'm right 
 in the process of going bankrupt.

It's like driving - even if you have the right of way, it still pays to look out for other cars. Being "dead" right doesn't work for me.
Sep 21 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
klickverbot wrote:
 On 9/21/10 3:55 PM, Steven Schveighoffer wrote:
 People seem to think that an accusation is proof. If someone says you
 stole their code, because you read it, it's not always true. It's just
 much easier to prove you didn't steal it if you didn't read it.

And how exactly are you going to prove that you didn't read it?

You can't. But it makes it that much harder for the accusers.
Sep 21 2010
prev sibling next sibling parent reply Gary Whatmore <no spam.spam> writes:
Steven Schveighoffer Wrote:

 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros  
 <brunodomedeiros+spam com.gmail> wrote:
 
 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been  
 great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

Oh, from this discussion, I thought LLVM was GPL or LGPL, but not BSD (or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

BSD includes a binary attribution clause (not sure about LLVM), which makes it undesirable license for commercial use.

--- Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. --- The way I understand this is: attach the (c) notice to the source code and to the documentation and/or other materials provided with the distribution. This doesn't in any way force you to include the license in the executable. Where did you get that idea from? Can you give some examples when this is bad for commercial software or are you just trolling? - G.W.
Sep 23 2010
next sibling parent reply Don <nospam nospam.com> writes:
Gary Whatmore wrote:
 Steven Schveighoffer Wrote:
 
 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros  
 <brunodomedeiros+spam com.gmail> wrote:

 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been  
 great
 if Walter were able to work with it without these IP worries.


(or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

makes it undesirable license for commercial use.

--- Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. --- The way I understand this is: attach the (c) notice to the source code and to the documentation and/or other materials provided with the distribution.

This doesn't in any way force you to include the license in the executable. No, but you have to include the license WITH the executable (in the 'documentation and other materials'). Which is fine if in fact there are 'documentation and other materials'. But it would seem to prohibit distribution of a bare executable.
Sep 23 2010
parent reply Juanjo Alvarez <fake fakeemail.com> writes:
On Thu, 23 Sep 2010 09:53:33 +0200, Don <nospam nospam.com> wrote:
 No, but you have to include the license WITH the executable (in the 
 'documentation and other materials'). Which is fine if in fact 

 'documentation and other materials'. But it would seem to prohibit 
 distribution of a bare executable.

You can include it in the about box, in the --help switch, etc. Many programs do it that way and I never heard of any problem with that.
Sep 26 2010
parent reply lurker <lurk lurking.net> writes:
Juanjo Alvarez Wrote:

 On Thu, 23 Sep 2010 09:53:33 +0200, Don <nospam nospam.com> wrote:
 No, but you have to include the license WITH the executable (in the 
 'documentation and other materials'). Which is fine if in fact 

 'documentation and other materials'. But it would seem to prohibit 
 distribution of a bare executable.

You can include it in the about box, in the --help switch, etc. Many programs do it that way and I never heard of any problem with that.

A valid corner case example was given here: a hello world application. A minimal hello world application is "Hello world!" + the bytes used to make the syscall. The license text would bloat the executable horribly. Thus, BSD isn't suitable for *all* commercial application development. QED
Sep 26 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Simen kjaeraas wrote:
 lurker <lurk lurking.net> wrote:
 
 A valid corner case example was given here: a hello world application. 
 A minimal hello world application is "Hello world!" + the bytes used 
 to make the syscall. The license text would bloat the executable 
 horribly. Thus, BSD isn't suitable for *all* commercial application 
 development. QED

So how is business in the "Hello world!" sales line of work? :p

Our choices are for anyone distributing a D app, commercial or not: 1. require a --help switch printing the attribution 2. require an about box printing the attribution 3. require a string embedded in the binary with attribution 4. assure users that even though the license says it requires binary attribution, we'll look the other way if they omit it and promise we won't sue 5. argue with lawyers about what the binary attribution actually means 6. argue with customers who won't use D because their lawyers were unsure of what the binary attribution actually means 7. have endless threads in the n.g. discussing how the binary attribution requirement should be satisfied by users 8. send lawyer letters to D users castigating them for not including binary attribution -- OR --- **** use a license that doesn't require binary attribution ****
Sep 26 2010
next sibling parent reply Juanjo Alvarez <fake fakeemail.com> writes:
On Sun, 26 Sep 2010 14:15:40 -0700, Walter Bright 
<newshound2 digitalmars.com> wrote:
 Our choices are for anyone distributing a D app, commercial or not:

Ok. I was not arguing for changing D's license to BSD but about not worrying so much about looking at BSD code or incorporating the occasional bit of code. AFAIK the BSD license it's not virical or people using Microsoft network API should include the attribution, which doesn't happen. Same with GPL or LGPL code incorporating code from BSD or all the userspace apps on the Free/Open BSD OSes.
Sep 26 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Juanjo Alvarez wrote:
 On Sun, 26 Sep 2010 14:15:40 -0700, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 Our choices are for anyone distributing a D app, commercial or not:

Ok. I was not arguing for changing D's license to BSD but about not worrying so much about looking at BSD code or incorporating the occasional bit of code. AFAIK the BSD license it's not virical or people using Microsoft network API should include the attribution, which doesn't happen. Same with GPL or LGPL code incorporating code from BSD or all the userspace apps on the Free/Open BSD OSes.

The problem is, the BSD license *is* viral. If I look at BSD licensed code, and someone accuses me of incorporating bits of it into Phobos, then those bits must be removed or Phobos becomes BSD licensed and so every user gets infected with it, too. If you say "that'll never happen", consider that twice that exact issue has come up. Linking with a DLL is not viral, but statically linking a BSD licensed library *is* viral.
Sep 26 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Juanjo Alvarez wrote:
 (d) the BSD does not have a requirement for the distribution of source 
 code. It is not clear whether this means there is a deficiency in the 
 Open Source Definition. 

The Boost license does not require source distribution.
Sep 26 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 reimplement everything from scratch (aka NIH)

Nobody's stopping you or anyone else from using BSD code with D, nor has any intent or even capability to stop you. What we're not going to do, however, is force everyone to follow BSD's licensing rules by putting BSD licensed code into the core D runtime library.
Sep 26 2010
parent reply Johannes Pfau <spam example.com> writes:
On 27.09.2010 02:35, Walter Bright wrote:
 retard wrote:
 reimplement everything from scratch (aka NIH)

Nobody's stopping you or anyone else from using BSD code with D, nor has any intent or even capability to stop you. What we're not going to do, however, is force everyone to follow BSD's licensing rules by putting BSD licensed code into the core D runtime library.

So libevent/libev and libcurl will never be used in phobos? That's bad because an event loop implementation is required for high-performance IO. Reimplementing it from scratch is lots of work. (Reimplementing what libcurl offers is lots of work too, but HTTP client code is not that important for a standard library) Why can't we link dynamically to C bsd licensed libraries? Code which didn't use the curl / libev stuff then wouldn't have to include the bsd license. If someone used curl / libev he would have to ship the dlls himself and include the license - that seems fair to me. -- Johannes Pfau
Sep 27 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-09-27 14:18, Johannes Pfau wrote:
 On 27.09.2010 02:35, Walter Bright wrote:
 retard wrote:
 reimplement everything from scratch (aka NIH)

Nobody's stopping you or anyone else from using BSD code with D, nor has any intent or even capability to stop you. What we're not going to do, however, is force everyone to follow BSD's licensing rules by putting BSD licensed code into the core D runtime library.

So libevent/libev and libcurl will never be used in phobos? That's bad because an event loop implementation is required for high-performance IO. Reimplementing it from scratch is lots of work. (Reimplementing what libcurl offers is lots of work too, but HTTP client code is not that important for a standard library) Why can't we link dynamically to C bsd licensed libraries? Code which didn't use the curl / libev stuff then wouldn't have to include the bsd license. If someone used curl / libev he would have to ship the dlls himself and include the license - that seems fair to me.

I don't think Walter would mind adding bindings to libevent/libev and libcurl and dynamically link to them. -- /Jacob Carlborg
Sep 27 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 However, I am not Walter, so I can't say exactly why he doesn't read 
 BSD-style source but is OK reading boost-style source.  Maybe his 
 interpretation is different from yours.

On the other hand, why mess with it? I don't want to argue with lawyers about what it may or may not mean, nor do I want to argue with customers who are suspicious about what it might mean. The Boost license doesn't have this problem.
Sep 23 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 You mess with it so you can use code from other projects that may help 
 you make DMD a better product :)
 
 It's not like there's no gain from reading/using others' code.
 
 One reason not to do it, however, is the taint issue.  There's a 
 possibility that BSD compiler code you read has similarities to code you 
 may write in Phobos, and if that's the case, the owner of the BSD code 
 may request that you put their BSD license in Phobos.  We've seen first 
 hand how ridiculously little evidence can provoke such an accusation.

Twice the issue of possible infringement/taint by Phobos developers on Tango code has come up. If this comes up among friends, it can definitely come up from people who do not have our best interests at heart. With the Boost license, this is not even a potential issue, nor is it a rock in our shoe causing aggravation, mistrust, and bad feelings. I want, and think it best for D, that people be free to use the Phobos code however they want to for whatever they want to, without issue, argument, or worrying about what binary attribution means.
Sep 23 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Juanjo Alvarez wrote:
 Well, Windows NT and 2000 (not sure about the latest versions) included 
 the attribution in the about box. You can't get more commercial than 
 Microsoft. I don't see the problem on including some lines of text on 
 parts nobody looks anyway.

If nobody cares about it, why force it on people? I just don't get it. What's the benefit of the binary attribution clause? Why burden all D developers with this?
Sep 26 2010
next sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Sun, 26 Sep 2010 14:04:54 -0700, Walter Bright 
<newshound2 digitalmars.com> wrote:
 If nobody cares about it, why force it on people? I just don't get 

I said that nobody looks there, not that nobody cares. Obviously the authors of the BSD licensed code care.
 the benefit of the binary attribution clause? Why burden all D 

See my other comment on the thread.
Sep 26 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 Lawyers. They burden us all.

I often wonder why it is that lawyers say they can't find work, yet I can't find one who charges less than $200/hr.
Sep 26 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

The Boost license we use in Phobos is more liberal than BSD. And that's exactly why we picked it. It was the most liberal one we could find that was in wide use.
Sep 21 2010
parent klickverbot <see klickverbot.at> writes:
On 9/21/10 10:58 PM, Walter Bright wrote:
 klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

The Boost license we use in Phobos is more liberal than BSD. And that's exactly why we picked it. It was the most liberal one we could find that was in wide use.

Yes, and I agree that Boost was and is a good choice for a standard library – binary attribution is a no-go for many applications. But Bruno was referring to LLVM, and for a compiler, BSD seems like a reasonable choice to me (parties like Apple and Adobe are free to use it, but cannot claim they wrote it themselves). Oh, by the way, none of my comments were intended to be an insult against you, I were really just curious why you have an exceptionally defensive opinion on possible copyright infringements (well, for the Open Source world, at least)…
Sep 21 2010
prev sibling next sibling parent mwarning <moritzwarning web.de> writes:
On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:

 For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

Hi, can you please elaborate a bit? I remember that statement has appeared before, but I can't remember the reason that was given.
Aug 05 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Adam Ruppe wrote:
 To abandon DMD for that is language suicide.

Well, one reason (certainly not the only one) I keep with the current dmd back end is that I don't need to spend time convincing some other organization to fix/improve/customize it for better D support. I can just get it done. Being in control of the toolchain has a lot of benefits. For example, look at gdb, and trying to get it to support D - not for the patches themselves, but getting them accepted into the standard gdb.
Aug 05 2010
prev sibling next sibling parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
is funny because on fedora ldc works fine on 32 and 64 bits. Now is in official
fedora same as tango.
And some other project will do soon like:
- mango
- derelict

but yes is a linux system ( sorry )
Aug 05 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el  5 de agosto a las 13:34 me escribiste:
 mwarning wrote:
On Thu, 05 Aug 2010 03:23:25 +0000, BCS wrote:

For a number of IP/legal reasons, Walter CAN'T work on LLVM or LDC.

I remember that statement has appeared before, but I can't remember the reason that was given.

Because when I've had the roomful of lawyers do their due diligence on me, saying "I never looked at the source code" is an effective defense against any claims of possible infringement. When I say that, they click their briefcases shut, say "we're done here", and leave.

That seems a little stupid, there are billions of open source projects, and I never hear anyone giving that excuse not to contribute. Your argument about having to convince people that a feature have merits or the bigger inertia to do changes is a valid one, but that one is just bogus. And BTW, not all projects have the high inertia DMD have, a lot of projects are much more permeable and more open to external contributions. Obviously there will be always a little more work to coordinate work with others when not all the decisions are made by only you (as is now with the DMD backend), but I don't think it would be that bad either, and the tradeoff of what you gain vs. what you loose will be probably at large in your favor (at least in the long term) if you decided to start using LLVM as the backend. Not that I'm expecting you to do it, I'm just saying :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El techo de mi cuarto lleno de estrellas
Aug 05 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been  
 great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

Oh, from this discussion, I thought LLVM was GPL or LGPL, but not BSD (or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

BSD includes a binary attribution clause (not sure about LLVM), which makes it undesirable license for commercial use. The issue is taint. I find this aspect of copyright and licensing highly dubious (I can barely remember what I did last week, not to mention some souce code I read last year), but the issue is this: Let's say Walter does read LLVM source code, and then works on another compiler project for another company that is completely proprietary. LLVM has some possible connection to interject and say "you have to give LLVM developers credit," even if Walter didn't copy any code. Yeah, it's ridiculous and absurd, but possible. Walter's position is, "If I don't look at any code, then I can't possibly be connected." While extreme, there's no loopholes or legal arguments against it. It's like an iron-clad alibi. -Steve
Sep 20 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 20 Sep 2010 14:14:09 -0400, Steven Schveighoffer wrote:

 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:
 
 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been
 great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

Oh, from this discussion, I thought LLVM was GPL or LGPL, but not BSD (or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

BSD includes a binary attribution clause (not sure about LLVM), which makes it undesirable license for commercial use. The issue is taint. I find this aspect of copyright and licensing highly dubious (I can barely remember what I did last week, not to mention some souce code I read last year), but the issue is this: Let's say Walter does read LLVM source code, and then works on another compiler project for another company that is completely proprietary. LLVM has some possible connection to interject and say "you have to give LLVM developers credit," even if Walter didn't copy any code. Yeah, it's ridiculous and absurd, but possible.

So the another company goes bankrupt if Walter has to mention the name 'LLVM developers' in the documentation nobody reads and in an About dialog nobody ever reads? I understand this when the other project (LLVM in this case) has some viral license like GPL, but in this case they only expect moral attribution. Your ideology is sick: "we must steal as much as possible from the open source dickheads without giving attribution, and turn the code into proprietary DRM shit to enslave the world muhahaha"
Sep 20 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 20 Sep 2010 16:29:13 -0400, retard <re tard.com.invalid> wrote:

 Mon, 20 Sep 2010 14:14:09 -0400, Steven Schveighoffer wrote:

 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been
 great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

Oh, from this discussion, I thought LLVM was GPL or LGPL, but not BSD (or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It does not seem to be the case that LLVM would send lawyers to anyone.

BSD includes a binary attribution clause (not sure about LLVM), which makes it undesirable license for commercial use. The issue is taint. I find this aspect of copyright and licensing highly dubious (I can barely remember what I did last week, not to mention some souce code I read last year), but the issue is this: Let's say Walter does read LLVM source code, and then works on another compiler project for another company that is completely proprietary. LLVM has some possible connection to interject and say "you have to give LLVM developers credit," even if Walter didn't copy any code. Yeah, it's ridiculous and absurd, but possible.

So the another company goes bankrupt if Walter has to mention the name 'LLVM developers' in the documentation nobody reads and in an About dialog nobody ever reads?

No, but it's a negative thing to require attribution in the standard library. The compiler is probably fine, but Walter's *business* is writing compilers. He avoids reading other compiler's code because he does not want to have that compiler come after him even when he didn't copy the code.
 I understand this when the other project (LLVM
 in this case) has some viral license like GPL, but in this case they only
 expect moral attribution. Your ideology is sick: "we must steal as much
 as possible from the open source dickheads without giving attribution,
 and turn the code into proprietary DRM shit to enslave the world  
 muhahaha"

People seem to think that an accusation is proof. If someone says you stole their code, because you read it, it's not always true. It's just much easier to prove you didn't steal it if you didn't read it. Note that we are not talking about actual copying that is the problem. If there wasn't the side effect of people believing that your mind is tainted with their code and any other code you write must be a derivative work, I'm sure Walter would have no problem copying LLVM and giving attribution. -Steve
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 10:21:38 -0400, klickverbot <see klickverbot.at> wrote:

 On 9/21/10 3:55 PM, Steven Schveighoffer wrote:
 People seem to think that an accusation is proof. If someone says you
 stole their code, because you read it, it's not always true. It's just
 much easier to prove you didn't steal it if you didn't read it.

And how exactly are you going to prove that you didn't read it?

Huh? Look, this isn't an issue of being deceitful, it's an issue of the defensible strength of "yes, I read it, but I didn't copy anything" vs. "no I didn't read it, so I couldn't have copied anything." If you don't believe the person, then it's up to you to prove they're lying. With copyright law, it's perfectly lawful to come up with the same thing independently, and there is no violation. It's even possible to read code, understand the ideas, and write your own code to implement the ideas (commonly done via a clean-room implementation). Ideas are not copyrightable, the media is what's copyrighted. -Steve
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 10:45:18 -0400, klickverbot <see klickverbot.at> wrote:

 On 9/21/10 4:31 PM, Steven Schveighoffer wrote:
 Huh? Look, this isn't an issue of being deceitful, it's an issue of the
 defensible strength of "yes, I read it, but I didn't copy anything" vs.
 "no I didn't read it, so I couldn't have copied anything." If you don't
 believe the person, then it's up to you to prove they're lying.

> It's even possible to read code, understand the ideas, and write your > own code to implement the ideas (commonly done via a clean-room > implementation). I guess I don't quite understand US copyright laws here: Here in Europe, if somebody accuses you of copying their work, they have to prove that you in fact did copy it. Let's assume that person manages to convince a judge that your code is in fact a copy of theirs. To defend yourself, it should not really make a difference whether you claim that you read that code or not. Even if it mattered whether you looked at the code or not (at least for Europe, I'm reasonably sure that it does not), how are you going to convince the judge that you didn't look at the source code? After all, for Open Source projects, the source code is publicly available at the internet, and if you did not write your program in jail or deep down in the ocean in a submarine, there is always the possibility that you could have looked at the code.

If you copy something, there is usually evidence that you did so, like a lack of development of your code (all of a sudden, a complete working version was checked in!). But besides that, if you have a track record of never reading competitor's source, and the evidence supports that, then I don't see how the judge cannot reverse the ruling. This newsgroup would serve as good evidence that Walter does not look at others' source. The fact that the code is available does not make it likely that you copied it! You can't just publish code and then claim any similar code *must* be yours because it's impossible for someone not to look at your code. People aren't convicted on "possibilities" they are convicted on proof.
 As I said, I don't really know much about the US copyright laws, but if  
 you are used to common European jurisdiction, this situation seems  
 pretty bizarre…

I'm not sure how Europe's copyright laws work, but in the US, if you didn't copy it, it doesn't violate copyright law. You can't copy something that you don't have the original for, so even if your work appears very similar (as code very often does -- styles are similar, algorithms usually are the same, etc.), it's not copying unless you had access to the source *AND* copied it. If in Europe, the only evidence a judge looks at is if the code is similar, I'm glad I don't live in Europe... -Steve
Sep 21 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-09-21 at 16:45 +0200, klickverbot wrote:
[ . . . ]
 I guess I don't quite understand US copyright laws here: Here in Europe,=20
 if somebody accuses you of copying their work, they have to prove that=20
 you in fact did copy it. Let's assume that person manages to convince a=20
 judge that your code is in fact a copy of theirs. To defend yourself, it=20
 should not really make a difference whether you claim that you read that=20
 code or not.

I guess you are not a lawyer, I know I am not. I wonder if you have ever acted as an expert witness? I suspect not, but I know I have.
 Even if it mattered whether you looked at the code or not (at least for=20
 Europe, I'm reasonably sure that it does not), how are you going to=20
 convince the judge that you didn't look at the source code? After all,=20
 for Open Source projects, the source code is publicly available at the=20
 internet, and if you did not write your program in jail or deep down in=20
 the ocean in a submarine, there is always the possibility that you could=20
 have looked at the code.

You are correct about the UK situation. What an individual has done or not done is not a primary factor, although it can be used in a circumstantial way.
 As I said, I don't really know much about the US copyright laws, but if=20
 you are used to common European jurisdiction, this situation seems=20
 pretty bizarre=E2=80=A6

There is no European jurisdiction in these matters -- at least not yet. What happens in France, Germany, UK, Italy, etc. is independent until such time that a directive is issued regarding copyright law.=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 21 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-09-21 at 11:01 -0400, Steven Schveighoffer wrote:
[ . . . ]
 If you copy something, there is usually evidence that you did so, like a =

 lack of development of your code (all of a sudden, a complete working =20
 version was checked in!).  But besides that, if you have a track record o=

 never reading competitor's source, and the evidence supports that, then I=

 don't see how the judge cannot reverse the ruling.

It's all down to balance of probabilities, at least in the UK. Just because there is a history of not copying in the past doesn't necessarily mean you didn't this time.
 This newsgroup would serve as good evidence that Walter does not look at =

 others' source.

Actually I suspect not per se, but it might add weight to other evidence.
 The fact that the code is available does not make it likely that you =20
 copied it!  You can't just publish code and then claim any similar code =20
 *must* be yours because it's impossible for someone not to look at your =20
 code.  People aren't convicted on "possibilities" they are convicted on =20
 proof.

The interesting question is what constitutes proof. I am not a lawyer so cannot give you a full answer but having been an expert witness on a fairly regular basis I can tell you most of these things are in the end settled by the two expert witnesses in their joint report -- at least in the UK.
 I'm not sure how Europe's copyright laws work, but in the US, if you =20
 didn't copy it, it doesn't violate copyright law.  You can't copy =20
 something that you don't have the original for, so even if your work =20
 appears very similar (as code very often does -- styles are similar, =20
 algorithms usually are the same, etc.), it's not copying unless you had =20
 access to the source *AND* copied it.

I suspect us having these sorts of debate is fairly fruitless unless we have some practicing copyright lawyers on the list who can advise us. When it comes to issues of these sort the gossip of programmers who have not had pupilage in copyright law in the jurisdiction you are operating in tends to be misdirected.
 If in Europe, the only evidence a judge looks at is if the code is =20
 similar, I'm glad I don't live in Europe...

Judges don't look at evidence such as this expert witnesses do. What is so good about the USA system that makes the various European systems something you wish to avoid? What really worries me about exchanges such as this is that people make statements from position of insufficient knowledge, possibly in entirely good faith, but they nonetheless give people the wrong impression of reality. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 13:08:30 -0400, klickverbot <see klickverbot.at> wrote:

 On 9/21/10 5:01 PM, Steven Schveighoffer wrote:
 People aren't convicted on "possibilities" they are convicted on
 proof.

Okay, I suppose I was not as clear about my point as I hoped I would be: This is exactly what I wanted to say – if you want to sue somebody for copying your code, it has to be proven that they took your code, not just possible. But I don't see how just reading other people's code would affect that – either you copied it, or you didn't.

Yeah, and if you never possessed the original, then you didn't :) That is the point. It's impossible to go back in time and observe someone not copying something, so we have to rely on evidence afterwards. I'd find it very hard to believe that someone would be convicted on copying something they've never seen or possessed before they published their version.
 My point about the source being freely available on the internet was  
 just to illustrate that claiming »But, your honor, I didn't even read  
 that other piece of code« does not seem like a very strong defense to me  
 *if the court has already been convinced that you copied other code*,  
 e.g. by an expert's opinion.

AFAIK, this exact thing happened to Walter (although, it was for the opposing lawyers, not a judge). I'd also find it hard to believe that that statement comes into play after the judge is convinced. Also, consider that many professional developers have this philosophy, so it's not an unprecedented defense.
 I should also add that I am no lawyer, and I am generally only very  
 modestly experienced in legal issues, so please bear with me if my  
 questions don't make much sense – I just want to understand the reason  
 why Walter is so exceptionally afraid of looking at other projects.

I don't see how I can make it clearer. You can't copy something you don't have or have never seen. If it's well documented that you haven't had it or seen it, then any thing that seems like a copy still cannot be a copy. I think the situation you are thinking of where a judge is already convinced that copying occurred without considering if the person had the original just doesn't exist, unless you are talking about a corrupt judge. I should say, I'm not a lawyer either, but I feel that I understand the ideas behind copyright (I am completely ignorant with court proceedings, but I'm just using common sense here). My interpretations may be simplistic, but I don't see how you can argue that someone copied something without coming into contact with the original.
 To me, it seems a bit as if a researcher refused to keep himself  
 informed about scientific progress in the field he is working on, just  
 because he could be accused of stealing from other people (yes, that's a  
 weak analogy, I know).

This is completely different, science is based almost entirely on prior work. Nobody sets out to test a radical new theory, they test theories of slight modifications from other scientists' work. More importantly scientists who create physical entities can patent those entities. Patents have very different rules from copyright. Also, from that standpoint, Walter most likely can read articles about ideas that other compiler developers write, or documentation, without reading the source code. Remember, ideas are not copyrightable.
 Oh, and I am perfectly aware of the fact that there is no common  
 European jurisdiction in these matters, but to the best of my knowledge,  
 the laws regarding intellectual property are quite similar from a  
 high-level point of view in many European countries – and probably in  
 large contrast with US copyright laws, which is what I intended to hint  
 at.

No clue, I don't have any idea how any European judicial systems work. -Steve
Sep 21 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-09-21 at 19:08 +0200, klickverbot wrote:
[ . . . ]
 I should also add that I am no lawyer, and I am generally only very=20
 modestly experienced in legal issues, so please bear with me if my=20
 questions don't make much sense =E2=80=93 I just want to understand the r=

 why Walter is so exceptionally afraid of looking at other projects.

I am sure Walter reads other code, and especially learns about languages other than C, C++ and D -- not to do so would be to abdicate one's professional responsibility to stay up to date in one's field. The problem is to set up a clear barrier to the accusation of copying. So to take a well known example: FOSS project contributors should never read Microsoft copyright code, and Microsoft employees should never read GPL and LGPL code -- substitute any profit-making company that relies on licence revenues for Microsoft, it is just that using Microsoft here is almost certainly not libellous. Rigidly following behaviour such as this is not a total defence in a copyright action, but it sets a pattern of corporate and individual behaviour that makes a copyright infringement less likely and more difficult to prove sufficiently to win an action.
 To me, it seems a bit as if a researcher refused to keep himself=20
 informed about scientific progress in the field he is working on, just=20
 because he could be accused of stealing from other people (yes, that's a=20
 weak analogy, I know).

Actually I think it is a strong point. It comes to the heart of the problem. Programmers must read code in order to work and also in order to learn and stay up to date. This is the primary conflict.
 Oh, and I am perfectly aware of the fact that there is no common=20
 European jurisdiction in these matters, but to the best of my knowledge,=20
 the laws regarding intellectual property are quite similar from a=20
 high-level point of view in many European countries =E2=80=93 and probabl=

 large contrast with US copyright laws, which is what I intended to hint a=

I believe you are right, I think the there is a great deal of similarity in all the jurisdictions in the mix here -- at least for copyright, for IP law generally I think there are much wider variations. The problem is though that despite this, the actual laws and indeed legal systems, are different and it is in such details that we loose any ability to generalize. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 12:47:58 -0400, Russel Winder <russel russel.org.uk>  
wrote:

 On Tue, 2010-09-21 at 11:01 -0400, Steven Schveighoffer wrote:
 [ . . . ]
 If you copy something, there is usually evidence that you did so, like a
 lack of development of your code (all of a sudden, a complete working
 version was checked in!).  But besides that, if you have a track record  
 of
 never reading competitor's source, and the evidence supports that, then  
 I
 don't see how the judge cannot reverse the ruling.

It's all down to balance of probabilities, at least in the UK. Just because there is a history of not copying in the past doesn't necessarily mean you didn't this time.

True, but it does help in your claim. If it only comes down to probabilities without considering the fact that someone did not have possession of the original, I'd call that a broken system.
 This newsgroup would serve as good evidence that Walter does not look at
 others' source.

Actually I suspect not per se, but it might add weight to other evidence.

That's what I meant.
 The fact that the code is available does not make it likely that you
 copied it!  You can't just publish code and then claim any similar code
 *must* be yours because it's impossible for someone not to look at your
 code.  People aren't convicted on "possibilities" they are convicted on
 proof.

The interesting question is what constitutes proof. I am not a lawyer so cannot give you a full answer but having been an expert witness on a fairly regular basis I can tell you most of these things are in the end settled by the two expert witnesses in their joint report -- at least in the UK.

Not a lawyer either, and I've never been involved in copyright infringement except as an observer of news. But there must be *some* consideration for evidence that no originals were in the defendant's possession?
 I'm not sure how Europe's copyright laws work, but in the US, if you
 didn't copy it, it doesn't violate copyright law.  You can't copy
 something that you don't have the original for, so even if your work
 appears very similar (as code very often does -- styles are similar,
 algorithms usually are the same, etc.), it's not copying unless you had
 access to the source *AND* copied it.

I suspect us having these sorts of debate is fairly fruitless unless we have some practicing copyright lawyers on the list who can advise us. When it comes to issues of these sort the gossip of programmers who have not had pupilage in copyright law in the jurisdiction you are operating in tends to be misdirected.

Maybe, but I'm fairly certain that Walter *has* consulted copyright lawyers about this, and his decision is a reflection of that discussion. Judging by that, I think we can assume via anecdotal evidence that his position is pretty solid.
 If in Europe, the only evidence a judge looks at is if the code is
 similar, I'm glad I don't live in Europe...

Judges don't look at evidence such as this expert witnesses do.

I meant, if they don't consider evidence that the person did not possess at any time the original item that is alleged to be copied. I didn't mean if the judge actually looks at the code side by side :)
 What is so good about the USA system that makes the various European
 systems something you wish to avoid?

My entire experience with what the European system consists of comes from this thread, that's all I'm basing my statement on :) I did predicate my statement with a pretty large if (which I believe isn't true, but that's what people are telling me).
 What really worries me about exchanges such as this is that people make
 statements from position of insufficient knowledge, possibly in entirely
 good faith, but they nonetheless give people the wrong impression of
 reality.

Probably. But why are you worried? If we're just two morons discussing what we don't understand, who cares? :) -Steve
Sep 21 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 21 Sep 2010 16:21:38 +0200, klickverbot wrote:

 On 9/21/10 3:55 PM, Steven Schveighoffer wrote:
 People seem to think that an accusation is proof. If someone says you
 stole their code, because you read it, it's not always true. It's just
 much easier to prove you didn't steal it if you didn't read it.

And how exactly are you going to prove that you didn't read it?

The western court system AFAIK operates with the presumption of innocence. I've seen some cases against GPLed software. The commercial company used freely licensed code without releasing their own associated code in any form. Although they tried to convince it's a contract violation and GPL is an invalid contract anyways, the judges decided to apply the copyright law in these cases and the GPL project won the case. What kind of evidence they used against the infringing application? Well, the offending software only came in binary form and the original was publicly available as source code. The binaries contained function signatures, function body code, and strings in exactly the same form as the GPLed software when compiled with some mainstream copiler (MSVC++, GCC). The shady company later tried to obfuscate these signatures in updated versions but the experts showed how the code is essentially the same after removing the obfuscation (same calling sequences, same logic paths etc.) In my opinion it's difficult to find phony evidence against a software developer in Europe, because associations like EFF may assist you, software isn't patentable, and very small pieces of code aren't even copyrightable. It's quite unlikely that given two nontrivial application they share many function signatures or strings. An innocent software developer won't start obfuscating his sources when some commercial entity starts threatening.
Sep 21 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Tue, 21 Sep 2010 13:54:38 -0400, Steven Schveighoffer wrote:

 On Tue, 21 Sep 2010 12:47:58 -0400, Russel Winder <russel russel.org.uk>
 wrote:

 What is so good about the USA system that makes the various European
 systems something you wish to avoid?

My entire experience with what the European system consists of comes from this thread, that's all I'm basing my statement on :) I did predicate my statement with a pretty large if (which I believe isn't true, but that's what people are telling me).

My experience with the American system is that even if you do wrong (steal code), if you have enough cash on you, you can usually settle the case and clear your reputation. For example when Andrei's employer was accused of stealing the facebook code and idea, he paid a big $$$ sum of money and they all promised to shut up. That's how things work in jolly good America. That's just my interpretation, don't know if it's true.
Sep 21 2010
parent reply BCS <none anon.com> writes:
Hello retard,

Just today, I had it pointed out to me that one of the major political
differences 
between the US and Europe is that, as a generality, Europeans, trust the 
government more than corporations, where Americans, if we trust either, it's 
the corporations. It stands to reason too; the US was populated by the people 
who didn't like living under European governments.

And just to be complete, need I remind you who was running Germany's government 
about 75 years ago?

-- 
... <IXOYE><
Sep 21 2010
next sibling parent BCS <none anon.com> writes:
Hello BCS,

 Hello retard,
 
 Just today, I had it pointed out to me that one of the major political
 differences between the US and Europe is that, as a generality,
 Europeans, trust the government more than corporations, where
 Americans, if we trust either, it's the corporations. It stands to
 reason too; the US was populated by the people who didn't like living
 under European governments.
 
 And just to be complete, need I remind you who was running Germany's
 government about 75 years ago?
 

OTOH take a look at big business in the US about 25-50 years before that. p.s. I'm not bashing either side, I just want to point out that some major differences of view exist. -- ... <IXOYE><
Sep 21 2010
prev sibling parent reply Don <nospam nospam.com> writes:
BCS wrote:
 Hello retard,
 
 Just today, I had it pointed out to me that one of the major political 
 differences between the US and Europe is that, as a generality, 
 Europeans, trust the government more than corporations, where Americans, 
 if we trust either, it's the corporations. It stands to reason too; the 
 US was populated by the people who didn't like living under European 
 governments.

For sure. That's why the US is such a beaurocratic country: if you don't trust your government, you need a big layer of beaurocracy to add additional checks. Interestingly the lack of trust of the government doesn't occur in other New World countries like Australia -- it seems fairly specific to the US.
 And just to be complete, need I remind you who was running Germany's 

I don't think that's relevant. The US lack of trust of government is very much older than that. "The right to bear arms".
Sep 21 2010
parent BCS <none anon.com> writes:
Hello Don,

 BCS wrote:
 
 Hello retard,
 
 Just today, I had it pointed out to me that one of the major
 political differences between the US and Europe is that, as a
 generality, Europeans, trust the government more than corporations,
 where Americans, if we trust either, it's the corporations. It stands
 to reason too; the US was populated by the people who didn't like
 living under European governments.
 

don't trust your government, you need a big layer of beaurocracy to add additional checks. Interestingly the lack of trust of the government doesn't occur in other New World countries like Australia -- it seems fairly specific to the US.
 And just to be complete, need I remind you who was running Germany's
 

I don't think that's relevant. The US lack of trust of government is very much older than that. "The right to bear arms".

There was two point in that: 1) Europeans don't trust their government more because it's more trust worthy (it isn't) and 2) http://en.wikipedia.org/wiki/Godwin's_law#Corollaries_and_usage -- ... <IXOYE><
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 14:26:37 -0400, retard <re tard.com.invalid> wrote:

 Tue, 21 Sep 2010 13:54:38 -0400, Steven Schveighoffer wrote:

 On Tue, 21 Sep 2010 12:47:58 -0400, Russel Winder <russel russel.org.uk>
 wrote:

 What is so good about the USA system that makes the various European
 systems something you wish to avoid?

My entire experience with what the European system consists of comes from this thread, that's all I'm basing my statement on :) I did predicate my statement with a pretty large if (which I believe isn't true, but that's what people are telling me).

My experience with the American system is that even if you do wrong (steal code), if you have enough cash on you, you can usually settle the case and clear your reputation. For example when Andrei's employer was accused of stealing the facebook code and idea, he paid a big $$$ sum of money and they all promised to shut up. That's how things work in jolly good America. That's just my interpretation, don't know if it's true.

How horrible! Facebook, come steal my code please, I need some $$$ ;) -Steve
Sep 21 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 21 Sep 2010 14:29:31 -0400, Steven Schveighoffer wrote:

 On Tue, 21 Sep 2010 14:26:37 -0400, retard <re tard.com.invalid> wrote:
 
 Tue, 21 Sep 2010 13:54:38 -0400, Steven Schveighoffer wrote:

 On Tue, 21 Sep 2010 12:47:58 -0400, Russel Winder
 <russel russel.org.uk> wrote:

 What is so good about the USA system that makes the various European
 systems something you wish to avoid?

My entire experience with what the European system consists of comes from this thread, that's all I'm basing my statement on :) I did predicate my statement with a pretty large if (which I believe isn't true, but that's what people are telling me).

My experience with the American system is that even if you do wrong (steal code), if you have enough cash on you, you can usually settle the case and clear your reputation. For example when Andrei's employer was accused of stealing the facebook code and idea, he paid a big $$$ sum of money and they all promised to shut up. That's how things work in jolly good America. That's just my interpretation, don't know if it's true.

How horrible!

The point is, if you have enough money, you don't need to publicly admit you don't have any moral standards and you're a scumbag. It won't make a stain in your reputation. But I already discussed the ethical side of things with you and noticed our thinking differs.
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 14:38:43 -0400, retard <re tard.com.invalid> wrote:

 Tue, 21 Sep 2010 14:29:31 -0400, Steven Schveighoffer wrote:

 On Tue, 21 Sep 2010 14:26:37 -0400, retard <re tard.com.invalid> wrote:

 Tue, 21 Sep 2010 13:54:38 -0400, Steven Schveighoffer wrote:

 On Tue, 21 Sep 2010 12:47:58 -0400, Russel Winder
 <russel russel.org.uk> wrote:

 What is so good about the USA system that makes the various European
 systems something you wish to avoid?

My entire experience with what the European system consists of comes from this thread, that's all I'm basing my statement on :) I did predicate my statement with a pretty large if (which I believe isn't true, but that's what people are telling me).

My experience with the American system is that even if you do wrong (steal code), if you have enough cash on you, you can usually settle the case and clear your reputation. For example when Andrei's employer was accused of stealing the facebook code and idea, he paid a big $$$ sum of money and they all promised to shut up. That's how things work in jolly good America. That's just my interpretation, don't know if it's true.

How horrible!

The point is, if you have enough money, you don't need to publicly admit you don't have any moral standards and you're a scumbag. It won't make a stain in your reputation. But I already discussed the ethical side of things with you and noticed our thinking differs.

People often settle not because they are wrong, but because it's cheaper. Rather be still in business and "wrong" than prove I'm right in the process of going bankrupt. From what I remember, you were on the "it's ok to steal as long as you feel justified" side of things, no? -Steve
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 10:45:18 -0400, klickverbot <see klickverbot.at> wrote:

 On 9/21/10 4:31 PM, Steven Schveighoffer wrote:
 Huh? Look, this isn't an issue of being deceitful, it's an issue of the
 defensible strength of "yes, I read it, but I didn't copy anything" vs.
 "no I didn't read it, so I couldn't have copied anything." If you don't
 believe the person, then it's up to you to prove they're lying.

> It's even possible to read code, understand the ideas, and write your > own code to implement the ideas (commonly done via a clean-room > implementation). I guess I don't quite understand US copyright laws here: Here in Europe, if somebody accuses you of copying their work, they have to prove that you in fact did copy it. Let's assume that person manages to convince a judge that your code is in fact a copy of theirs. To defend yourself, it should not really make a difference whether you claim that you read that code or not. Even if it mattered whether you looked at the code or not (at least for Europe, I'm reasonably sure that it does not), how are you going to convince the judge that you didn't look at the source code? After all, for Open Source projects, the source code is publicly available at the internet, and if you did not write your program in jail or deep down in the ocean in a submarine, there is always the possibility that you could have looked at the code. As I said, I don't really know much about the US copyright laws, but if you are used to common European jurisdiction, this situation seems pretty bizarre…

Hm.. I may see why there is a disconnect here. You might think I mean someone copied the code without actually reading it? That's not what I'm talking about. What I'm talking about is a case where it appears snippets/parts of someone's project appear in another, but the author of the other never downloaded/viewed/possessed in any way the original project's source. So I don't mean "copied without viewing" I mean "did not ever possess the original." That's what I meant by not having looked at the code. Does this make sense? -Steve
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 16:08:12 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 The fact that the code is available does not make it likely that you  
 copied it!  You can't just publish code and then claim any similar code  
 *must* be yours because it's impossible for someone not to look at your  
 code.  People aren't convicted on "possibilities" they are convicted on  
 proof.

Copyright infringement is a civil, not criminal, case, and so a decision is based on a "preponderance" of evidence rather than proof "beyond a reasonable doubt".

In these cases yes, but there are criminal copyright infringement cases. I didn't exactly mean beyond a reasonable doubt, but I think the point of not ever looking at or touching another's source is equivalent to proof of the contrary, no? I think they at least have to prove that you accessed the code :) I don't think "because the source is available online" is evidence at all, that was my point. Otherwise, you'd have to cancel your internet service just to be safe... It's also possible that someone printed out all the code of a competitor's compiler and executed drive-by leafleting of the code at your house, and you accidentally picked up some code snippits out of curiosity, but we can't convict on the possibility that it could have happened. I would think they'd have to show that the timelines match up, there's lack of evidence that you developed it internally, etc. Just the fact that it *could be* downloaded isn't proof. -Steve
Sep 21 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Sep 2010 16:55:37 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 I didn't exactly mean beyond a reasonable doubt, but I think the point  
 of not ever looking at or touching another's source is equivalent to  
 proof of the contrary, no?  I think they at least have to prove that  
 you accessed the code :)  I don't think "because the source is  
 available online" is evidence at all, that was my point.  Otherwise,  
 you'd have to cancel your internet service just to be safe...

Right, and the source code may even reside on your disk (sheesh, I've got terabytes of stuff on disks, there may very well be source code to something on that!). Access is not proof that one looked at it. It comes down to one's credibility, coupled with absence of other evidence of copying (like matching source text).

One other way to ensure you have evidence to the contrary is to use source control. Not only is it good for productivity and disaster recovery, but it shows perfect snapshots of how you developed the code, and the timeline of development. So even if your code *does* end up looking similar, you can show how you independently came up with the similar code. -Steve
Sep 21 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2010-09-21 at 18:48 +0100, Russel Winder wrote:
[ . . . ]
 I believe you are right, I think the there is a great deal of similarity
 in all the jurisdictions in the mix here -- at least for copyright, for
 IP law generally I think there are much wider variations.  The problem
 is though that despite this, the actual laws and indeed legal systems,
 are different and it is in such details that we loose any ability to
 generalize.

Interesting. It looks like the Court of Justice of the EU may be asked to clarify UK case law, based on EU directives, which in turn would lead to a harmonization of copyright law across the whole of the EU. http://www.contractoruk.com/004998.html --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 22 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 Sep 2010 03:38:47 -0400, Gary Whatmore <no spam.spam> wrote:

 Steven Schveighoffer Wrote:

 On Mon, 20 Sep 2010 13:46:19 -0400, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:

 On 20/09/2010 16:13, klickverbot wrote:
 On 9/20/10 5:10 PM, Bruno Medeiros wrote:
 I find myself wishing some more OSS projects had commercial-friendly
 licenses. :-/ In particular LLVM, as I do agree it might have been
 great
 if Walter were able to work with it without these IP worries.

You want something even more liberal than BSD?

Oh, from this discussion, I thought LLVM was GPL or LGPL, but not BSD (or more concretely, a variant of BSD from what I see). What is the issue then of Walter taking a look at the LLVM code? It

 not seem to be the case that LLVM would send lawyers to anyone.

BSD includes a binary attribution clause (not sure about LLVM), which makes it undesirable license for commercial use.

--- Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. --- The way I understand this is: attach the (c) notice to the source code and to the documentation and/or other materials provided with the distribution. This doesn't in any way force you to include the license in the executable. Where did you get that idea from? Can you give some examples when this is bad for commercial software or are you just trolling?

You know, I always thought it said clearly that binary distributions must contain the license, but I think you are right. The sentence is not very clear what happens when you distribute a binary only. To me it reads that you include the license text *only* in the accompanying documentation, but what if there is no accompanying documentation or materials? This could of course be solved by just including a text file with the license in it. I have newfound interpretation of the BSD license, and I'm not so sure that it can't be used in the compiler. In the standard library, probably not, we don't want to force someone who uses D to always distribute a specific license file. However, I am not Walter, so I can't say exactly why he doesn't read BSD-style source but is OK reading boost-style source. Maybe his interpretation is different from yours. -Steve
Sep 23 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 Sep 2010 13:36:30 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 However, I am not Walter, so I can't say exactly why he doesn't read  
 BSD-style source but is OK reading boost-style source.  Maybe his  
 interpretation is different from yours.

On the other hand, why mess with it? I don't want to argue with lawyers about what it may or may not mean, nor do I want to argue with customers who are suspicious about what it might mean. The Boost license doesn't have this problem.

You mess with it so you can use code from other projects that may help you make DMD a better product :) It's not like there's no gain from reading/using others' code. One reason not to do it, however, is the taint issue. There's a possibility that BSD compiler code you read has similarities to code you may write in Phobos, and if that's the case, the owner of the BSD code may request that you put their BSD license in Phobos. We've seen first hand how ridiculously little evidence can provoke such an accusation. -Steve
Sep 23 2010
prev sibling next sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Mon, 20 Sep 2010 14:14:09 -0400, "Steven Schveighoffer" 
<schveiguy yahoo.com> wrote:
 another company that is completely proprietary.  LLVM has some 

 connection to interject and say "you have to give LLVM developers 

 even if Walter didn't copy any code.  Yeah, it's ridiculous and 

Well, Windows NT and 2000 (not sure about the latest versions) included the attribution in the about box. You can't get more commercial than Microsoft. I don't see the problem on including some lines of text on parts nobody looks anyway.
Sep 26 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
lurker <lurk lurking.net> wrote:

 A valid corner case example was given here: a hello world application. A  
 minimal hello world application is "Hello world!" + the bytes used to  
 make the syscall. The license text would bloat the executable horribly.  
 Thus, BSD isn't suitable for *all* commercial application development.  
 QED

So how is business in the "Hello world!" sales line of work? :p -- Simen
Sep 26 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 26 Sep 2010 14:15:40 -0700, Walter Bright wrote:

 Simen kjaeraas wrote:
 lurker <lurk lurking.net> wrote:
 
 A valid corner case example was given here: a hello world application.
 A minimal hello world application is "Hello world!" + the bytes used
 to make the syscall. The license text would bloat the executable
 horribly. Thus, BSD isn't suitable for *all* commercial application
 development. QED

So how is business in the "Hello world!" sales line of work? :p

Our choices are for anyone distributing a D app, commercial or not:

(
 
 1. require a --help switch printing the attribution 2. require an about
 box printing the attribution 3. require a string embedded in the binary
 with attribution 4. assure users that even though the license says it
 requires binary attribution, we'll look the other way if they omit it
 and promise we won't sue 5. argue with lawyers about what the binary
 attribution actually means 6. argue with customers who won't use D
 because their lawyers were unsure of what the binary attribution
 actually means 7. have endless threads in the n.g. discussing how the
 binary attribution requirement should be satisfied by users 8. send
 lawyer letters to D users castigating them for not including binary
 attribution

AND
 use large amounts of existing code to boost adoption and make D faster
 a mature platform for real world application development

)
 
       -- OR ---

(
 
 **** use a license that doesn't require binary attribution ****

AND
 reimplement everything from scratch (aka NIH)

)
Sep 26 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 26 September 2010 14:04:54 Walter Bright wrote:
 Juanjo Alvarez wrote:
 Well, Windows NT and 2000 (not sure about the latest versions) included
 the attribution in the about box. You can't get more commercial than
 Microsoft. I don't see the problem on including some lines of text on
 parts nobody looks anyway.

If nobody cares about it, why force it on people? I just don't get it. What's the benefit of the binary attribution clause? Why burden all D developers with this?

Lawyers. They burden us all. Perhaps they think we're pack animals... ;) - Jonathan M Davis
Sep 26 2010
prev sibling next sibling parent Juanjo Alvarez <juanjux thatwebmailofgoogleproperty.com> writes:
On Sun, 26 Sep 2010 17:00:23 -0700, Walter Bright wrote:


 The problem is, the BSD license *is* viral. If I look at BSD licensed
 code, and someone accuses me of incorporating bits of it into Phobos,
 then those bits must
   be removed or Phobos becomes BSD licensed and so every user gets
   infected with
 it, too.
 
 If you say "that'll never happen", consider that twice that exact issue
 has come up.
 
 Linking with a DLL is not viral, but statically linking a BSD licensed
 library *is* viral.

True. My "AFAIK" was wrong; I stand corrected: http://www.groklaw.net/article.php?story=20070114093427179 Summary: (a) the BSD appears to require that modifications be distributed only under the terms of the BSD, and that this requirement therefore cascades down to subsequent generations of code; (b) the license does not appear to permit the relicensing of BSD code under the terms of any other license, at least in so far as any restrictions in other licenses would seem not to be binding; (c) there may be some scope for arguing that the term “modification” to the code is restricted or limited in some fashion. However, as the license only permits redistribution of “modifications” the BSD does not permit the redistribution of any derivative work which is not a modification; (d) the BSD does not have a requirement for the distribution of source code. It is not clear whether this means there is a deficiency in the Open Source Definition.
Sep 26 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 26 Sep 2010 17:15:40 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Simen kjaeraas wrote:
 lurker <lurk lurking.net> wrote:

 A valid corner case example was given here: a hello world application.  
 A minimal hello world application is "Hello world!" + the bytes used  
 to make the syscall. The license text would bloat the executable  
 horribly. Thus, BSD isn't suitable for *all* commercial application  
 development. QED


Our choices are for anyone distributing a D app, commercial or not: 1. require a --help switch printing the attribution 2. require an about box printing the attribution 3. require a string embedded in the binary with attribution 4. assure users that even though the license says it requires binary attribution, we'll look the other way if they omit it and promise we won't sue 5. argue with lawyers about what the binary attribution actually means 6. argue with customers who won't use D because their lawyers were unsure of what the binary attribution actually means 7. have endless threads in the n.g. discussing how the binary attribution requirement should be satisfied by users 8. send lawyer letters to D users castigating them for not including binary attribution -- OR --- **** use a license that doesn't require binary attribution ****

At the risk of furthering this pointless debate, I'll say that you did not include: 4.1 Include a license file with the distribution with the BSD license text I agree with you that BSD is not the right license for a standard library, for the simple fact that you do not want to put *any* requirements on your users, even if they are as benign as "include this license file with your binary," but Gary's original point seems to be lost here -- there is no binary attribution clause. There is a clause requiring that the materials distributed *along side* the binary include the license in at least one of them. Analyzing the paragraph that requires "binary attribution": 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. If this didn't mean "in the other materials", then that part of the sentence would be eliminated. It doesn't mean in the binary, it means in the documentation and/or other materials. It's not an insignificant thing, it made me rethink my views on the BSD license. I still think that's too restrictive for a standard library, and it does nothing to alleviate fears of taint. -Steve
Sep 27 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-05 03:22, Andrei Alexandrescu wrote:
 On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
 On 08/04/2010 05:16 PM, Robert Clipsham wrote:
 I know of several large apps written in D, they're all D1/Tango.

The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2. People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.

Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support. Andrei

For shared library support on Linux I think http://d.puremagic.com/issues/show_bug.cgi?id=4583 is a blocker. For Mac OS X a patch is already available (of which the dmd part has already been applied) http://d.puremagic.com/issues/show_bug.cgi?id=4080 . BTW compiling Tango as a dynamic library on Mac OS X has been possible the last couple of months. -- /Jacob Carlborg
Aug 05 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 For shared library support on Linux I think 
 http://d.puremagic.com/issues/show_bug.cgi?id=4583 is a blocker. For Mac 
 OS X a patch is already available (of which the dmd part has already 
 been applied) http://d.puremagic.com/issues/show_bug.cgi?id=4080 . BTW 
 compiling Tango as a dynamic library on Mac OS X has been possible the 
 last couple of months.

One thing about OS X is that all object files are sharable, so if your code even works on the Mac it will be possible to put it in a shared library. Things are much more complex on Linux.
Aug 05 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-05 19:42, Walter Bright wrote:
 Jacob Carlborg wrote:
 For shared library support on Linux I think
 http://d.puremagic.com/issues/show_bug.cgi?id=4583 is a blocker. For
 Mac OS X a patch is already available (of which the dmd part has
 already been applied)
 http://d.puremagic.com/issues/show_bug.cgi?id=4080 . BTW compiling
 Tango as a dynamic library on Mac OS X has been possible the last
 couple of months.

One thing about OS X is that all object files are sharable, so if your code even works on the Mac it will be possible to put it in a shared library. Things are much more complex on Linux.

I was not saying it's going to be easy to make shared libraries work on Linux. I've tried to make shared libraries working on Linux starting with the same approach I used when making them work on Mac OS X. Issue 4583 is how far I got, then I couldn't get further. I'm just pointing out that fixing issue 4583 is where one could start to make shared libraries work on Linux. -- /Jacob Carlborg
Aug 05 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 I was not saying it's going to be easy to make shared libraries work on 
 Linux. I've tried to make shared libraries working on Linux starting 
 with the same approach I used when making them work on Mac OS X. Issue 
 4583 is how far I got, then I couldn't get further. I'm just pointing 
 out that fixing issue 4583 is where one could start to make shared 
 libraries work on Linux.

Thanks for helping out with this. I appreciate it.
Aug 05 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-08-05 22:56, Walter Bright wrote:
 Jacob Carlborg wrote:
 I was not saying it's going to be easy to make shared libraries work
 on Linux. I've tried to make shared libraries working on Linux
 starting with the same approach I used when making them work on Mac OS
 X. Issue 4583 is how far I got, then I couldn't get further. I'm just
 pointing out that fixing issue 4583 is where one could start to make
 shared libraries work on Linux.

Thanks for helping out with this. I appreciate it.

You're welcome, I'm glad I can be of any help. -- /Jacob Carlborg
Aug 06 2010
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/04/2010 09:22 PM, Andrei Alexandrescu wrote:
 Walter is more silent than usual because he's working very hard on the
 64-bit compiler. He hopes to have one by the end of this month. His next
 big goal is shared library support.

While those are both important, isn't it even more important to have the existing 32-bit implementation complete? How can you showcase a language that's incomplete and buggy? Can't both those features wait until after D2 is considered polished enough to be released? I keep seeing reports from people running into bugs, unfinished features, and incomplete documentation. There's no end in sight, either, yet a book has been released and the language is promoted as if it were a finished product.
Aug 05 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:i3ekaf$14hd$1 digitalmars.com...
 On 08/04/2010 09:22 PM, Andrei Alexandrescu wrote:
 Walter is more silent than usual because he's working very hard on the
 64-bit compiler. He hopes to have one by the end of this month. His next
 big goal is shared library support.

While those are both important, isn't it even more important to have the existing 32-bit implementation complete? How can you showcase a language that's incomplete and buggy? Can't both those features wait until after D2 is considered polished enough to be released?

Perhaps. But a debate on the ideal priority-ranking could go in circles forever. At the end of the day, something needs to just be picked, worked on, done, and move on, even if it isn't the perfect choice.
 I keep seeing reports from people running into bugs, unfinished features, 
 and incomplete documentation. There's no end in sight, either, yet a book 
 has been released and the language is promoted as if it were a finished 
 product.

Most of those aren't really breakers, though. Even with all of that stuff I'm still far more productive in D than any other language I use. I imagine many other D users feel the same. But lack of 64-bit is a breaker (or near-breaker) for some people, and it's also an obstacle for PR. And the better the PR is, the better chances we have of getting more people coming in and helping out with other aspects, etc. So there'd be benefits to focusing more on misc bugs, features, documentation, but there's also benefits to focusing on 64-bit. And Walter's gotta at least choose something.
Aug 05 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jeff Nowakowski wrote:
 On 08/04/2010 09:22 PM, Andrei Alexandrescu wrote:
 Walter is more silent than usual because he's working very hard on the
 64-bit compiler. He hopes to have one by the end of this month. His next
 big goal is shared library support.

While those are both important, isn't it even more important to have the existing 32-bit implementation complete? How can you showcase a language that's incomplete and buggy? Can't both those features wait until after D2 is considered polished enough to be released? I keep seeing reports from people running into bugs, unfinished features, and incomplete documentation. There's no end in sight, either, yet a book has been released and the language is promoted as if it were a finished product.

I've been deferring adding 64 bit support for years. Not having it is the biggest barrier to the adoption of D there is right now.
Aug 05 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/05/2010 01:23 PM, retard wrote:
 Wed, 04 Aug 2010 20:22:09 -0500, Andrei Alexandrescu wrote:

 On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
 On 08/04/2010 05:16 PM, Robert Clipsham wrote:
 I know of several large apps written in D, they're all D1/Tango.

The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2. People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.

Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.

Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is * managing the communication with the user community * managing the communication with the language/compiler developers * managing the bugfixes to the spec * managing the compiler bugfix release (minor version) process * managing the language development debate * coordinating the future language development (roadmap page of the trac) * managing the public relations with the people outside the core community It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.

I think this is a gross misrepresentation. Are you sure you're not forgetting a lot of contributors? If anything, the trend is toward opening the doors to more, not less people. Andrei
Aug 05 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 I understood that all the contributors are waiting for the decision of a 
 single person.

Not true, that only applies to the compiler. Phobos is managed by several people who have commit privileges.
 Walter needs to review all compiler patches,

Yes, because I need to keep a handle on exactly how the compiler works. If I lose track of it, it can become a mess of things like "this seems to work" with little understanding. I want to especially thank Don Clugston for his invaluable help in reviewing submitted compiler patches, testing them, fixing a lot of the hard problems, and making it easy for me.
 he needs to 
 review all patches to the spec, he needs to defend D on reddit, 
 newsgroups, and all other forums.

More like I want to. Anyone else is welcome to help out here. I am hardly in a position to stop anyone from helping there <g>.
 He handles the whole release process.

That actually is about to change.
 He doesn't tell anything about future directions so nobody knows about 
 them.

What's unclear about it?
 The management model doesn't scale when you get more and more 
 contributors. At some point Walter won't have enough time to review all 
 contributions even if it didn't do anything else.

You're right, I can't review them all. In particular, I am fairly uninvolved in the development of Phobos, other than popping up now and then to complain about something :-)
 For example now that he is focusing on 64-bit support, all discussion 
 about rewriting the spec, fixing bugs, improving the other parts of the 
 toolchain, or developing the language further (D 2.1 or 3.0) has stalled. 

This is nonsense, as I'm not stopping anyone from helping out with any of that. In fact, tomorrow I have a lunch date with a fellow who is working on a D debugger. As another example of many who have stepped up with invaluable help, Shin Fujishiro did the pioneering work to get D2 working on FreeBSD.
 Many people have asked bearophile to stop discussing new language 
 features because it takes away too much valuable time from Walter. 
 Something is wrong here.

I haven't asked bearophile or anyone else to stop discussing new language features. Anyone is free on this n.g. to ask whatever they want of others, and everyone is free to accede to or ignore those requests. Here's an incomplete list of people who are in charge of various aspects of D: Me: compiler Sean: druntime Brad Roberts: bugzilla, mailing lists, D test suite Brad Anderson: D source code repository Jan Knepper: site hosting Several people: Phobos (generally under Andrei's leadership) Helmut Leitner: D wiki Andrei: build master (coming soon!) Of course, LDC, GDC, Tango, Dil, and all the other libraries and tools, etc., are all led by their various self-selected groups, not me.
Aug 05 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-05 21:37, Walter Bright wrote:
 retard wrote:
 I understood that all the contributors are waiting for the decision of
 a single person.

Not true, that only applies to the compiler. Phobos is managed by several people who have commit privileges.
 Walter needs to review all compiler patches,

Yes, because I need to keep a handle on exactly how the compiler works. If I lose track of it, it can become a mess of things like "this seems to work" with little understanding. I want to especially thank Don Clugston for his invaluable help in reviewing submitted compiler patches, testing them, fixing a lot of the hard problems, and making it easy for me.
 he needs to review all patches to the spec, he needs to defend D on
 reddit, newsgroups, and all other forums.

More like I want to. Anyone else is welcome to help out here. I am hardly in a position to stop anyone from helping there <g>.
 He handles the whole release process.

That actually is about to change.
 He doesn't tell anything about future directions so nobody knows about
 them.

What's unclear about it?

Basically there's no road map, especially no official. What will happen in one month? Two months? Half a year? The only way to get some idea about what will happen is following the newsgroups and even doing that you don't know what actually will end up in the compiler. You also have to follow the commits to the repository and then it's already too late, it has already happened.
 The management model doesn't scale when you get more and more
 contributors. At some point Walter won't have enough time to review
 all contributions even if it didn't do anything else.

You're right, I can't review them all. In particular, I am fairly uninvolved in the development of Phobos, other than popping up now and then to complain about something :-)
 For example now that he is focusing on 64-bit support, all discussion
 about rewriting the spec, fixing bugs, improving the other parts of
 the toolchain, or developing the language further (D 2.1 or 3.0) has
 stalled.

This is nonsense, as I'm not stopping anyone from helping out with any of that. In fact, tomorrow I have a lunch date with a fellow who is working on a D debugger. As another example of many who have stepped up with invaluable help, Shin Fujishiro did the pioneering work to get D2 working on FreeBSD.
 Many people have asked bearophile to stop discussing new language
 features because it takes away too much valuable time from Walter.
 Something is wrong here.

I haven't asked bearophile or anyone else to stop discussing new language features. Anyone is free on this n.g. to ask whatever they want of others, and everyone is free to accede to or ignore those requests. Here's an incomplete list of people who are in charge of various aspects of D: Me: compiler Sean: druntime Brad Roberts: bugzilla, mailing lists, D test suite Brad Anderson: D source code repository Jan Knepper: site hosting Several people: Phobos (generally under Andrei's leadership) Helmut Leitner: D wiki Andrei: build master (coming soon!) Of course, LDC, GDC, Tango, Dil, and all the other libraries and tools, etc., are all led by their various self-selected groups, not me.

-- /Jacob Carlborg
Aug 05 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 What's unclear about it?

Basically there's no road map, especially no official. What will happen in one month? Two months? Half a year? The only way to get some idea about what will happen is following the newsgroups and even doing that you don't know what actually will end up in the compiler. You also have to follow the commits to the repository and then it's already too late, it has already happened.

The roadmap is 64 bit Linux, followed by shared library support under Linux. Concurrently and for the near future, the concentration will be on toolchain and usability issues, not new language features. 64 bits on other platforms will follow once it proves out on Linux.
Aug 05 2010
next sibling parent reply awishformore <awishformore nospam.plz> writes:
On 05/08/2010 22:42, Walter Bright wrote:
 Jacob Carlborg wrote:
 What's unclear about it?

Basically there's no road map, especially no official. What will happen in one month? Two months? Half a year? The only way to get some idea about what will happen is following the newsgroups and even doing that you don't know what actually will end up in the compiler. You also have to follow the commits to the repository and then it's already too late, it has already happened.

The roadmap is 64 bit Linux, followed by shared library support under Linux. Concurrently and for the near future, the concentration will be on toolchain and usability issues, not new language features. 64 bits on other platforms will follow once it proves out on Linux.

So the 64bit support you're working on will not be for Windows? /Max
Aug 05 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
awishformore wrote:
 64 bits on other platforms will follow once it proves out on Linux.

So the 64bit support you're working on will not be for Windows?

Not initially. 64 bit C on Windows uses a different ABI, the exception handling support is different, there's no linker (oops), etc. It's a much harder job.
Aug 05 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 awishformore wrote:
 
 64 bits on other platforms will follow once it proves out on Linux.
 


handling support is different,

And I'm guessing that 90% of the work on Linux will go directly into the windows version. Sounds like a good plan to me.
 there's no linker (oops), etc. It's a much harder job.

While you fix that, could you also add support for another linker to the win32 version? -- ... <IXOYE><
Aug 06 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
BCS wrote:
 While you fix that, could you also add support for another linker to the 
 win32 version?

Which one are you thinking about?
Aug 06 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 Unfortunately, having to use dmc for C or C++ in order to link it with D code
in 
 Windows would make D a non-starter for any project that couldn't be in pure D 
 where I work. Most of our stuff is cross-platform between Linux and Windows, 
 using gcc on Linux and Visual Studio on Windows, and I don't think that
there's 
 any hope of getting anyone to switch to using dmc. If D code could be linked 
 with code generated by Microsoft's compiler, then I'd have a much better
chance 
 of getting folks where I work to use D. As it is, it would have to be for 
 standalone projects only, and most of our projects aren't standalone.

I hadn't realized that was a barrier.
Aug 06 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 Unfortunately, in order to be able to use D where I work, I'd have to be able
to 
 link the D code with C/C++ code which has been built with Visual Studio and
its 
 compiler and linker. And, if I understand correctly, that means that the D
code 
 has to be linked with Microsoft's linker. If that's a misunderstanding on my 
 part, then linking D with Microsoft's linker would be unnecessary, and dmc 
 should do the job just fine (though only needing the one C/C++ linker over two 
 would still be an improvement). But as I understand it, any C or C++ code
which 
 is going to be used with D code in Windows has to have been built with dmc.

This actually used to be possible with dmc, but Microsoft has repeatedly changed formats (some of them are secret, too) and I gave up endlessly chasing those changes.
Aug 06 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 So, it is understandably not possible to do the linking with dmc. Would it be 
 possible to make it so that dmd could link using Microsoft's linker? Or is 
 enough of what Microsoft's doing secret and/or too difficult to keep track of
to 
 make it possible to use Microsoft's linker with dmd?

At this point, I don't know. I just recall it being a constant drain on my time to keep things working as MS would change their compiler, libraries, and tools.
Aug 06 2010
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 Jonathan M Davis wrote:
 
 Unfortunately, in order to be able to use D where I work, I'd have to
 be able to link the D code with C/C++ code which has been built with
 Visual Studio and its compiler and linker. And, if I understand
 correctly, that means that the D code has to be linked with
 Microsoft's linker. If that's a misunderstanding on my part, then
 linking D with Microsoft's linker would be unnecessary, and dmc
 should do the job just fine (though only needing the one C/C++ linker
 over two would still be an improvement). But as I understand it, any
 C or C++ code which is going to be used with D code in Windows has to
 have been built with dmc.
 

repeatedly changed formats (some of them are secret, too) and I gave up endlessly chasing those changes.

Would you be open to allowing semi official builds of DMD? That would be have builds of DMD that use the official DMD code base except for an object file generator mainland by someone else. It seems that would be a clean separation point that shouldn't break to often and you already have, what, 4 different versions now? A good build system should make this an almost no effort proposition on your part: you develop as normal and whenever you do a release, the other versions would get built, tested and if they pass, posted to the site, if not, the owners (not you) get contacted. -- ... <IXOYE><
Aug 07 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
BCS wrote:
 Would you be open to allowing semi official builds of DMD? That would be 
 have builds of DMD that use the official DMD code base except for an 
 object file generator mainland by someone else.

Yes.
Aug 07 2010
parent BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 Would you be open to allowing semi official builds of DMD? That would
 be have builds of DMD that use the official DMD code base except for
 an object file generator mainland by someone else.
 


Now all we need is that someone else.... -- ... <IXOYE><
Aug 07 2010
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 8/7/2010 10:03 AM, BCS wrote:
 
 Would you be open to allowing semi official builds of DMD? That would be have
 builds of DMD that use the official DMD code base except for an object file
 generator mainland by someone else. It seems that would be a clean separation
 point that shouldn't break to often and you already have, what, 4 different
 versions now?
 

Why keep it separate? If someone goes through the effort of an object file generator that helps improve interoperability with visual studio produced obj files, it should just be folded in.
Aug 07 2010
parent BCS <none anon.com> writes:
Hello Brad,

 On 8/7/2010 10:03 AM, BCS wrote:
 
 Would you be open to allowing semi official builds of DMD? That would
 be have builds of DMD that use the official DMD code base except for
 an object file generator mainland by someone else. It seems that
 would be a clean separation point that shouldn't break to often and
 you already have, what, 4 different versions now?
 

file generator that helps improve interoperability with visual studio produced obj files, it should just be folded in.

The point is to avoid having Walter pay all the burden of maintaining it. (Also it's one step in the direction of a more distributed development.) -- ... <IXOYE><
Aug 07 2010
prev sibling parent BCS <none anon.com> writes:
Hello Walter,

 BCS wrote:
 
 While you fix that, could you also add support for another linker to
 the win32 version?
 


I'm not. I was just assuming the solution would be to add support for an existing 64bit capable windows linker. And I'm guess that most of that would would be shared with adding support for a 32 bit one as well (assuming a pair of linkers that support the same file format can be found). -- ... <IXOYE><
Aug 07 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-05 17:42:58 -0400, Walter Bright <newshound2 digitalmars.com> said:

 64 bit C on Windows uses a different ABI, the exception handling 
 support is different, there's no linker (oops), etc. It's a much harder 
 job.

Which makes me think of two small unimportant questions I'm curious about: What will be the 64-bit D calling convention? Will it follow the host platform's C calling convention? or will it be more uniform across platforms? Also, why is 32-bit D using its own calling convention instead of reusing an already existing one? Why not use the host platform's C calling convention? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 06 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 What will be the 64-bit D calling convention? Will it follow the host 
 platform's C calling convention?

Yes.
 or will it be more uniform across platforms?

No.
 Also, why is 32-bit D using its own calling convention instead of 
 reusing an already existing one?

Generates smaller/faster code.
 Why not use the host platform's C calling convention?

Which one of a dozen or so <g>? Everyone else ditched all the plethora of calling conventions when going to 64 bit, and I see no good reason not to join them.
Aug 06 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday, August 06, 2010 15:27:36 Walter Bright wrote:
 BCS wrote:
 While you fix that, could you also add support for another linker to the
 win32 version?

Which one are you thinking about?

Presumably Microsoft's linker if that's at all possible. Unfortunately, having to use dmc for C or C++ in order to link it with D code in Windows would make D a non-starter for any project that couldn't be in pure D where I work. Most of our stuff is cross-platform between Linux and Windows, using gcc on Linux and Visual Studio on Windows, and I don't think that there's any hope of getting anyone to switch to using dmc. If D code could be linked with code generated by Microsoft's compiler, then I'd have a much better chance of getting folks where I work to use D. As it is, it would have to be for standalone projects only, and most of our projects aren't standalone. - Jonathan M Davis
Aug 06 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday, August 06, 2010 16:35:57 Walter Bright wrote:
 Jonathan M Davis wrote:
 Unfortunately, having to use dmc for C or C++ in order to link it with D
 code in Windows would make D a non-starter for any project that couldn't
 be in pure D where I work. Most of our stuff is cross-platform between
 Linux and Windows, using gcc on Linux and Visual Studio on Windows, and
 I don't think that there's any hope of getting anyone to switch to using
 dmc. If D code could be linked with code generated by Microsoft's
 compiler, then I'd have a much better chance of getting folks where I
 work to use D. As it is, it would have to be for standalone projects
 only, and most of our projects aren't standalone.

I hadn't realized that was a barrier.

It certainly wouldn't be for me personally for my own stuff (though I probably wouldn't be programming on Windows anyway), but the company I work for (and actually any that I've worked for which has used C++) has specificaly used Visual Studio with Microsoft's compiler and linker, and getting them to change that would take _lot_ of convincing if not be outright impossible. So, if D code needs to link with the same linker as the C/C++ code in order for them to work together, then linking D with dmc instead of Microsoft's linker does become a serious barrier. Unfortunately, in order to be able to use D where I work, I'd have to be able to link the D code with C/C++ code which has been built with Visual Studio and its compiler and linker. And, if I understand correctly, that means that the D code has to be linked with Microsoft's linker. If that's a misunderstanding on my part, then linking D with Microsoft's linker would be unnecessary, and dmc should do the job just fine (though only needing the one C/C++ linker over two would still be an improvement). But as I understand it, any C or C++ code which is going to be used with D code in Windows has to have been built with dmc. - Jonathan M Davis
Aug 06 2010
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.165.1281141748.13841.digitalmars-d puremagic.com...
 but the company I work for (and
 actually any that I've worked for which has used C++) has specificaly used 
 Visual
 Studio with Microsoft's compiler and linker

Intel's C/C++ compiler is very popular too, particularly in game development (unless my information is out-of-date, which it may very well be by now... :/ ...fucking web...). I don't know if it has it's own linker or not, or what object format it uses, though.
Aug 06 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 06 August 2010 18:07:51 Walter Bright wrote:
 Jonathan M Davis wrote:
 Unfortunately, in order to be able to use D where I work, I'd have to be
 able to link the D code with C/C++ code which has been built with Visual
 Studio and its compiler and linker. And, if I understand correctly, that
 means that the D code has to be linked with Microsoft's linker. If
 that's a misunderstanding on my part, then linking D with Microsoft's
 linker would be unnecessary, and dmc should do the job just fine (though
 only needing the one C/C++ linker over two would still be an
 improvement). But as I understand it, any C or C++ code which is going
 to be used with D code in Windows has to have been built with dmc.

This actually used to be possible with dmc, but Microsoft has repeatedly changed formats (some of them are secret, too) and I gave up endlessly chasing those changes.

So, it is understandably not possible to do the linking with dmc. Would it be possible to make it so that dmd could link using Microsoft's linker? Or is enough of what Microsoft's doing secret and/or too difficult to keep track of to make it possible to use Microsoft's linker with dmd? - Jonathan M Davis
Aug 06 2010
prev sibling next sibling parent reply Neal Becker <ndbecker2 gmail.com> writes:
Walter Bright wrote:

 Jacob Carlborg wrote:
 What's unclear about it?

Basically there's no road map, especially no official. What will happen in one month? Two months? Half a year? The only way to get some idea about what will happen is following the newsgroups and even doing that you don't know what actually will end up in the compiler. You also have to follow the commits to the repository and then it's already too late, it has already happened.

The roadmap is 64 bit Linux, followed by shared library support under Linux. Concurrently and for the near future, the concentration will be on toolchain and usability issues, not new language features. 64 bits on other platforms will follow once it proves out on Linux.

I'm delighted to hear 64bit linux and shared lib. Very much looking forward to it. Let me know if I can help test.
Aug 05 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Neal Becker wrote:
 I'm delighted to hear 64bit linux and shared lib.  Very much looking forward 
 to it.  Let me know if I can help test.

Sign up to the beta mailing list!
Aug 05 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-05 22:42, Walter Bright wrote:
 Jacob Carlborg wrote:
 What's unclear about it?

Basically there's no road map, especially no official. What will happen in one month? Two months? Half a year? The only way to get some idea about what will happen is following the newsgroups and even doing that you don't know what actually will end up in the compiler. You also have to follow the commits to the repository and then it's already too late, it has already happened.

The roadmap is 64 bit Linux, followed by shared library support under Linux. Concurrently and for the near future, the concentration will be on toolchain and usability issues, not new language features. 64 bits on other platforms will follow once it proves out on Linux.

Now why isn't this on the website? I mean, you have to figure out yourself what the roadmap is by reading these posts. Until just recently one could thought that porting optlink to C was on the roadmap (at least as a long time goal) and I guess get up to date with TDPL. Then suddenly out of no where we can see commits about 64bit. What happened to those? Are they still on the roadmap? -- /Jacob Carlborg
Aug 06 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 Who is working on the D spec documentation, if anyone? I know Andrei and 
 others work on the Phobos docs, but what about the D docs?

The D docs are actually part of the Phobos under source control, and the people who work on the library have commit privileges for it. Although nobody has checked in any changes to it other than the changelog and some minor formatting stuff.
Aug 05 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrej Mitrovic wrote:
 
 
 On Thu, Aug 5, 2010 at 10:37 PM, Walter Bright 
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:
 
     Andrej Mitrovic wrote:
 
         Who is working on the D spec documentation, if anyone? I know
         Andrei and others work on the Phobos docs, but what about the D
         docs?
 
 
     The D docs are actually part of the Phobos under source control, and
     the people who work on the library have commit privileges for it.
     Although nobody has checked in any changes to it other than the
     changelog and some minor formatting stuff.
 
 
 I've filed a bunch of reports in bugzilla, regarding the D2 
 documentation. I've also provided fixes for most of the issues I've 
 found (but I haven't looked at *all* of the documentation yet). I'm 
 hoping someone could have a look at these sooner or later and update the 
 specs. :)

Andrej, I wanted to say for a while that I've been following and I appreciate your diligence in following through TDPL's examples and beyond, and then filing any bugs you find. Andrei
Aug 05 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Andrej Mitrovic wrote:
 I've filed a bunch of reports in bugzilla, regarding the D2 
 documentation. I've also provided fixes for most of the issues I've 
 found (but I haven't looked at *all* of the documentation yet). I'm 
 hoping someone could have a look at these sooner or later and update 
 the specs. :)

Andrej, I wanted to say for a while that I've been following and I appreciate your diligence in following through TDPL's examples and beyond, and then filing any bugs you find.

I agree. Thank you very much, Andrej!
Aug 05 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> ()  ϣ  Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them. One reason of it I can think of: parsing speed and ambiguities (same as with <templates>) Anyway, when D will take over the world, they will have to change HTML syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros. -- /Jacob Carlborg
Aug 06 2010
next sibling parent reply Johannes Pfau <spam example.com> writes:
On 06.08.2010 19:23, Steven Schveighoffer wrote:
 On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob me.com> wrote:
 
 On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them.


 One reason of it I can think of: parsing speed and ambiguities (same as
 with <templates>)

 Anyway, when D will take over the world, they will have to change HTML
 syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros.

Does ddoc output in pdf? And besides, most of the tags *are* html tags, they're even the same tag name. I can't imagine there's no htmltopdf program that would do exactly that. Regarding the <span class="bold"> thing, can't you just do this in css: b { whatever; } and override what <b> does? There are probably macros which do other things that xhtml/css cannot do, but I don't think we should use macros for every html element. For example, the $(V1) and $(V2) tags. We need a good solution for that, and I think having dmd work those out is fine. I also don't mind using the macros for more dynamic stuff. I just think the formatting stuff can remain html, and all the macros should be defined/documented somewhere. I like this explanation from Alexander: In the end it's just markup language and I don't see much use in learning more then one of them. It's just a thought, it might be blowing out of proportion a bit. Granted I think I would have felt more comfortable using html directly, but it wasn't that hard to learn, and I was able to work through the issues. I just wish I had some editor help... -Steve

A simple html to pdf conversion might not produce good results. In the long term something like http://sphinx.pocoo.org together with ReStructuredText might be the best solution (for general documentation, not for api documentation though). But the initial effort to 'port' the existing documentation is quite high. -- Johannes Pfau
Aug 06 2010
parent David Gileadi <gileadis NSPMgmail.com> writes:
On 8/6/10 11:24 AM, Graham Fawcett wrote:
 On Fri, 06 Aug 2010 19:56:55 +0200, Johannes Pfau wrote:

 A simple html to pdf conversion might not produce good results.

Converting *anything* to PDF might not produce good results. :) There's at least one excellent, open-source HTML-to-PDF converter: http://code.google.com/p/wkhtmltopdf/

For what it's worth I've been using wkhtmltopdf to generate PDF versions of the D site and documentation. My hope is that generating them can become part of the build and that the latest versions can be always available for download instead of the somewhat-outdated version that the site currently links to. I've filed a couple of bugs with wkhtmltopdf and they're being fixed--the developer is great. The output isn't as nice as what Sphinx might generate, but it's not bad either.
Aug 06 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob me.com> wrote:
 
 On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them.


 One reason of it I can think of: parsing speed and ambiguities (same as
 with <templates>)

 Anyway, when D will take over the world, they will have to change HTML
 syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros.

Does ddoc output in pdf? And besides, most of the tags *are* html tags, they're even the same tag name. I can't imagine there's no htmltopdf program that would do exactly that.

The reason they're the same is that the docs were originally written in html. The original conversion to ddoc was done via search and replace. One of the HUGE benefits of ddoc is that it does highlighting of the D code. That instantly saved Walter a lot of time. Seriously, converting it to ddoc did improve productivity.
Aug 06 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Steven Schveighoffer wrote:

 On Fri, 06 Aug 2010 14:26:48 -0400, Don <nospam nospam.com> wrote:
 
 Steven Schveighoffer wrote:
  Does ddoc output in pdf?  And besides, most of the tags *are* html
 tags, they're even the same tag name.  I can't imagine there's no
 htmltopdf program that would do exactly that.

The reason they're the same is that the docs were originally written in html. The original conversion to ddoc was done via search and replace. One of the HUGE benefits of ddoc is that it does highlighting of the D code. That instantly saved Walter a lot of time. Seriously, converting it to ddoc did improve productivity.

Oh, I totally agree for the code samples. And some of the other macros like $(V1). But the manual markup, like marking every paragraph like this: $(P This is some text that is in a paragraph, and for some reason, we need a special tag for it instead of using &lt;p&gt;, one that is hard to find the closing tag for, because every tag's closing tag is simply a lone close parentheses like this:) doesn't really make much difference than using <p>...</p>. The advantage of using html tags for formatting like this means editors will recognize tags, and everyone and their mother knows what html tags look like. -Steve

One trick that can work wonders here is treating ddoc as lisp code, most editors are very helpful with that.
Aug 06 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Lutger wrote:
 doesn't really make much difference than using <p>...</p>.  The advantage
 of using html tags for formatting like this means editors will recognize
 tags, and everyone and their mother knows what html tags look like.

are very helpful with that.

I hadn't thought of that, but you're right. All you need is a parenthesis matching command. Heck, I think I even wrote one for Emacs 25 years ago.
Aug 06 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i3i3v6$kj6$2 digitalmars.com...
 Lutger wrote:
 doesn't really make much difference than using <p>...</p>.  The 
 advantage
 of using html tags for formatting like this means editors will recognize
 tags, and everyone and their mother knows what html tags look like.

editors are very helpful with that.

I hadn't thought of that, but you're right. All you need is a parenthesis matching command. Heck, I think I even wrote one for Emacs 25 years ago.

I use Programmer's Notepad 2 which does parenthesis-matching out-of-the-box.
Aug 06 2010
parent reply Mafi <mafi example.org> writes:
Am 07.08.2010 06:39, schrieb Nick Sabalausky:
(...)
 I use Programmer's Notepad 2 which does parenthesis-matching out-of-the-box.

isn't a full-featured IDE but it's a great editor for programming, isn't it.
Aug 07 2010
next sibling parent Adrian Matoga <epi atari8.info> writes:
On 2010-08-07 21:56, Yao G. wrote:
 On Sat, 07 Aug 2010 04:36:27 -0500, Mafi <mafi example.org> wrote:
 
 Am 07.08.2010 06:39, schrieb Nick Sabalausky:
 (...)
 I use Programmer's Notepad 2 which does parenthesis-matching 
 out-of-the-box.

isn't a full-featured IDE but it's a great editor for programming, isn't it.

I use it too. In fact, it was thanks to Nick that I learned about PN2. He commented something about it few months ago (or several, I don't remember), here in the NG, and I gave it a try. Now it's what I use for my D2 programming.

I just gave it a try and I like it. I got used to Notepad++, but PN2 seems to have simpler and more intuitive interface. Thanks.
Aug 07 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Mafi" <mafi example.org> wrote in message 
news:i3j9el$5m7$1 digitalmars.com...
 Am 07.08.2010 06:39, schrieb Nick Sabalausky:
 (...)
 I use Programmer's Notepad 2 which does parenthesis-matching 
 out-of-the-box.

a full-featured IDE but it's a great editor for programming, isn't it.

There are a number of things I would definitely like to see added/improved: http://code.google.com/p/pnotepad/issues/list?can=1&q=reporter%3Ansetbtgnws But those are generally fairly minor things, and a number of them I think are really more scintilla than PN2 (PN2 uses the scintilla text-edit control). So yea, overall I've been very happy with it, much more than any other editor I've tried. Doesn't have the sluggishness and bloat of VS.NET and Eclipse (doesn't have all the bells and whistles of Eclipse, but I can live without bells and whistles, especially if I'm not using Java). Doesn't have the strange "10% CPU usage while idle" or long start-up time or non-MRU-based ctrl-tab system that C::B has, or C::B's insistence on always trying to open HTML in a WYSIWYG instead of text-mode. Doesn't do the weird "EOL isn't treated as EOL" behavior some other editors do. Doesn't require tons of configuration. Highlights D out-of-the-box (and *not* by pretending it's C/C++). And it does all the basics I need, like basic project support, external command-line tools, customizable cmd-line-tool output parsing for jump-to-file/line/position, keyboard commands for comment/indent/unindent, find in files, show/hide whitespace and/or EOL markers, tabs <-> spaces, doesn't try to use any weird skins, doesn't waste UI space, doesn't have "invisible-text-syndrome", etc.
Aug 07 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Don wrote:
 The reason they're the same is that the docs were originally written in 
 html. The original conversion to ddoc was done via search and replace.
 One of the HUGE benefits of ddoc is that it does highlighting of the D 
 code. That instantly saved Walter a lot of time.
 Seriously, converting it to ddoc did improve productivity.

Here's what it has done, and this is real live experience because they were originally 100% html: 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it. 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output. 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway. 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them. 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before. 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros. 7. I can update URLs across the site trivially, such as if bugzilla changes its URL. 8. As Don mentioned, it will automagically syntax highlight D code. 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher). 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.
Aug 06 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-07 00:54, Walter Bright wrote:
 Don wrote:
 The reason they're the same is that the docs were originally written
 in html. The original conversion to ddoc was done via search and replace.
 One of the HUGE benefits of ddoc is that it does highlighting of the D
 code. That instantly saved Walter a lot of time.
 Seriously, converting it to ddoc did improve productivity.

Here's what it has done, and this is real live experience because they were originally 100% html: 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it. 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output. 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway. 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them. 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before. 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros. 7. I can update URLs across the site trivially, such as if bugzilla changes its URL. 8. As Don mentioned, it will automagically syntax highlight D code. 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher). 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.

I think for any serious HTML work you need a server side language to help you. -- /Jacob Carlborg
Aug 07 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 3. these other systems also support generating correct, conforming HTML/
 XML/TeX/PDF/MAN/whatever. With ddoc you need to use some semi-official 
 templates you need to dig from the newsgroup archives. Doxygen provides 
 all this by default. How is that bad for productivity?

If you would be willing to clean up those templates and submit them, I'll make them part of the official distribution.
 So overall the other systems are much better and I also think I could 
 write something 10 times better than ddoc in 2..7 days if someone would 
 give me an untainted GPL licensed frontend that didn't look so butt ugly.

I'd welcome your contributions to improving ddoc.
Aug 14 2010
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
retard wrote:
 Sat, 07 Aug 2010 16:54:03 +0200, Jacob Carlborg wrote:
 

 So overall the other systems are much better and I also think I could 
 write something 10 times better than ddoc in 2..7 days if someone would 
 give me an untainted GPL licensed frontend that didn't look so butt ugly.

What prevents you from contributing to the frontend under its current license?
Aug 14 2010
parent reply Don <nospam nospam.com> writes:
retard wrote:
 Sat, 14 Aug 2010 20:24:33 -0500, Yao G. wrote:
 
 On Sat, 14 Aug 2010 20:20:49 -0500, Mike Parker <aldacron gmail.com>
 wrote:


 What prevents you from contributing to the frontend under its current
 license?

for him :|

I'm using the same argumentation as Walter here. If I ever contributed code to the proprietary dmd, I would get sued by a group of lawyers when contributing code later to some other proprietary / open source compiler. Even seeing the code might taint my mind. Just like Walter refuses to read Tango's code to prevent license issues with Phobos.

 Dmd's code also has several problems. I don't think it supports multi-
 core CPUs very well when parsing files. The other issues are: forward 
 reference bugs, lack of a good internal garbage collector (CTFE & 
 templates), not well documented (I know nearly nothing about compiler 
 implementation).

Those things are all true, but not relevant to ddoc. The ddoc code is just doc.c, which is 58kB in size. You're quite right in saying that something much better could be produced in a week or so of work. The existing ddoc was made in about a week, and I've spent a couple of days fixing some of the most obvious bugs. Now that most of the wrong-code and compiler error bugs are fixed, other stuff is becoming higher priority. Still, the fact that there are a thousand open compiler bugs, and only a couple of people working on the compiler is a pretty obvious limitation. Would be great if someone put a concerted effort into ddoc for a
Aug 14 2010
parent Ellis Peters <epeters donthavemail.com> writes:
Don Wrote:

 retard wrote:
 Sat, 14 Aug 2010 20:24:33 -0500, Yao G. wrote:
 
 On Sat, 14 Aug 2010 20:20:49 -0500, Mike Parker <aldacron gmail.com>
 wrote:


 What prevents you from contributing to the frontend under its current
 license?

for him :|

I'm using the same argumentation as Walter here. If I ever contributed code to the proprietary dmd, I would get sued by a group of lawyers when contributing code later to some other proprietary / open source compiler. Even seeing the code might taint my mind. Just like Walter refuses to read Tango's code to prevent license issues with Phobos.

 Dmd's code also has several problems. I don't think it supports multi-
 core CPUs very well when parsing files. The other issues are: forward 
 reference bugs, lack of a good internal garbage collector (CTFE & 
 templates), not well documented (I know nearly nothing about compiler 
 implementation).

Those things are all true, but not relevant to ddoc. The ddoc code is just doc.c, which is 58kB in size. You're quite right in saying that something much better could be produced in a week or so of work. The existing ddoc was made in about a week, and I've spent a couple of days fixing some of the most obvious bugs. Now that most of the wrong-code and compiler error bugs are fixed, other stuff is becoming higher priority. Still, the fact that there are a thousand open compiler bugs, and only a couple of people working on the compiler is a pretty obvious limitation. Would be great if someone put a concerted effort into ddoc for a

The advantage of ddoc is that it's simple. That makes it practical for us to use. No need to read long manuals, we can straight away write production quality documents with few macros. Even the idioms are very intuitive unlike foo and bar in Javadoc. I don't think the type signatures need better structure in the output. Walter usually foresees what is the most pragmatic solution. Seriously we should kick the retard out of here, he's only trolling with no useful arguments. Moderation.votes++
Aug 15 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Yao G. Wrote:

 You are just becoming a parody of yourself.

Everyone deserves respect when expresses opinions honestly and in an civil way, even when the ideas are wrong. Bye, bearophile
Aug 14 2010
next sibling parent awishformore <awishformore nospam.plz> writes:
On 15/08/2010 04:51, retard wrote:
 Sat, 14 Aug 2010 21:33:30 -0500, Yao G. wrote:

 On Sat, 14 Aug 2010 21:18:19 -0500, retard<re tard.com.invalid>  wrote:

 [snip]

Thanks for your informative post. I'm really glad that you don't use such primitive, butt-ugly tools like DDOC.

You don't need to use it either. Why do you think it's a personal attack if I'm evaluating some tool and don't see it fit for some part of the community? Do you think my opinions would have more value if I wrote under my real name? ''Yao G.'' is also too generic to disclose any identity using typical search engines. Even if I knew your real name, it would have zero value to me since it would still be some generic wise guy who disagreed but had actually really nothing to say.

Troll. /Max
Aug 14 2010
prev sibling next sibling parent Ellis Peters <epeters donthavemail.com> writes:
retard Wrote:

 Sat, 14 Aug 2010 21:33:30 -0500, Yao G. wrote:
 
 On Sat, 14 Aug 2010 21:18:19 -0500, retard <re tard.com.invalid> wrote:
 
 [snip]

Thanks for your informative post. I'm really glad that you don't use such primitive, butt-ugly tools like DDOC.

You don't need to use it either. Why do you think it's a personal attack if I'm evaluating some tool and don't see it fit for some part of the community? Do you think my opinions would have more value if I wrote under my real name? ''Yao G.'' is also too generic to disclose any identity using typical search engines. Even if I knew your real name, it would have zero value to me since it would still be some generic wise guy who disagreed but had actually really nothing to say.

Go away troll! Your just waisting our time. Go write some real world code and talk less shit. There's nothing to loose. DDOC is better than doxygen. We don't need to argue that here, because everyone is a fan of D. We know you're a Haskell fanboy so climb to your ivory tower and stay there. This newsgroups needs more practically minded people who value productivity.
Aug 14 2010
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Adam Ruppe (destructionator gmail.com)'s article
 To me, the biggest appeal of ddoc is that it doesn't require markup to
 give good enough results. It's almost mindless to use.

Not only that, because it doesn't require markup, the docs look good as plain text comments, not just when processed into HTML.
Aug 14 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
dsimcha wrote:
 == Quote from Adam Ruppe (destructionator gmail.com)'s article
 To me, the biggest appeal of ddoc is that it doesn't require markup to
 give good enough results. It's almost mindless to use.

Not only that, because it doesn't require markup, the docs look good as plain text comments, not just when processed into HTML.

That wasn't by accident :-). One of the explicit major goals of Ddoc was to not require any markup unless you are getting into more advanced use of it. Some of the design was compromised to make that work, but I think the results are worth it.
Aug 14 2010
parent reply lurker <lurkers lurking.org> writes:
Walter Bright Wrote:

 dsimcha wrote:
 == Quote from Adam Ruppe (destructionator gmail.com)'s article
 To me, the biggest appeal of ddoc is that it doesn't require markup to
 give good enough results. It's almost mindless to use.

Not only that, because it doesn't require markup, the docs look good as plain text comments, not just when processed into HTML.

That wasn't by accident :-). One of the explicit major goals of Ddoc was to not require any markup unless you are getting into more advanced use of it. Some of the design was compromised to make that work, but I think the results are worth it.

Unlike doxygen, Ddoc almost accepts plain english. It's not hard to see how much better designed Ddoc is *for D code*. A generic document generator can never support unit tests, contracts and so forth. I disagree with our ''retard'' completely.
Aug 14 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
lurker wrote:
 Walter Bright Wrote:
 
 dsimcha wrote:
 == Quote from Adam Ruppe (destructionator gmail.com)'s article
 To me, the biggest appeal of ddoc is that it doesn't require markup to
 give good enough results. It's almost mindless to use.

comments, not just when processed into HTML.

require any markup unless you are getting into more advanced use of it. Some of the design was compromised to make that work, but I think the results are worth it.

Unlike doxygen, Ddoc almost accepts plain english. It's not hard to see how much better designed Ddoc is *for D code*. A generic document generator can never support unit tests, contracts and so forth. I disagree with our ''retard'' completely.

A doxygen example from http://www.stack.nl/~dimitri/doxygen/docblocks.html : /** * a normal member taking two arguments and returning an integer value. * param a an integer argument. * param s a constant character pointer. * see Test() * see ~Test() * see testMeToo() * see publicVar() * return The test results */ int testMe(int a,const char *s); The Ddoc equivalent: /** * a normal member taking two arguments and returning an integer value. * Params: * a = an integer argument. * s = a constant character pointer. * See_Also: * Test() * ~Test() * testMeToo() * publicVar() * Returns: * The test results */ int testMe(int a,const char *s);
Aug 14 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
  - the markup/macro syntax is NIH new.

Not really. The macro syntax is copied from make. And it's utterly trivial. I'd like to know how the macro system is inadequate for generating Latex, man, etc. format.
Aug 15 2010
parent reply Johannes Pfau <spam example.com> writes:
On 15.08.2010 23:27, Walter Bright wrote:
 retard wrote:
  - the markup/macro syntax is NIH new.

Not really. The macro syntax is copied from make. And it's utterly trivial. I'd like to know how the macro system is inadequate for generating Latex, man, etc. format.

I think it's not a problem with the macro system, but with the few macros emitted by dmd: There are enough macros for the doc comments (DDOC_SUMMARY, DDOC_DESCRIPTION, ...) but not for the types. DDOC_DECL, DDOC_DECL_DD and DDOC_*_MEMBERS are just not enough to extract detailed information. This also puts quite some restrictions on the layout of the resulting documentation. In this case ddoc is very tied to html: These macros seem modeled directly after the DD DT DL html elements. I tried to enhance the ddoc output over the last few weeks and it's not ready to be released yet, but for example this is the macro structure I've chosen for function definitions: DDOC_FUNCTION DDOC_FUNCTION_HEADER_CONTAINER DDOC_FUNCTION_TEMPLATE_HEADER DDOC_FUNCTION_HEADER DDOC_TYPE_FUNCTION DDOC_FUNCTION_PREFIX DDOC_TYPE_MODIFIER DDOC_EXTRA_MODIFIER DDOC_TRUST DDOC_FUNCTION_RETURN_TYPE DDOC_FUNCTION_NAME DDOC_FUNCTION_PARAMETERS DDOC_FUNCTION_LPAREN DDOC_FUNCTION_PARAMETER DDOC_FUNCTION_PARAMETER_STC (storage class) DDOC_FUNCTION_PARAMETER_TYPE DDOC_FUNCTION_PARAMETER_NAME [DDOC_FUNCTION_PARAMETER_DEFAULT] [DDOC_FUNCTION_COMMA] [DDOC_FUNCTION_VARARGS] DDOC_FUNCTION_RPAREN DDOC_DECLARATION_SEMICOLON DDOC_DITTO DDOC_FUNCTION_HEADER... DDOC_FUNCTION_TEMPLATE_HEADER... DDOC_TEMPLATE_HEADER DDOC_FUNCTION_DOC One major aspect in my changes is that there should be no hardcoded output: everything can be redefined through macros, though sane defaults should be provided. Example: DDOC_DECLARATION_SEMICOLON=; DDOC_FUNCTION_VARARGS=...; DDOC_FUNCTION_COMMA=,; With more macros you can generate advanced looking documentation, for example, this is what I currently have: druntime docs: http://jpf.byethost10.com/druntime/doc/object.html simple tests: http://jpf.byethost10.com/demo/doc/ddoc/tests/simple/vars.html (druntime 2.047 in the right upper corner is still hardcoded...) I also have xml output, but the xml ddoc file isn't complete yet (template support is missing) http://jpf.byethost10.com/demo_xml/ddoc/tests/simple/ And there's also a problem with phobos:in some cases the sources contain html. In other cases there are custom macros in modules which can only emit html(std.math, TABLE_SV, ...) and afaik you can't override module level macros with .ddoc files? -- Johannes Pfau
Aug 15 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Johannes Pfau wrote:
 On 15.08.2010 23:27, Walter Bright wrote:
 retard wrote:
  - the markup/macro syntax is NIH new.

I'd like to know how the macro system is inadequate for generating Latex, man, etc. format.

I think it's not a problem with the macro system, but with the few macros emitted by dmd: There are enough macros for the doc comments (DDOC_SUMMARY, DDOC_DESCRIPTION, ...) but not for the types. DDOC_DECL, DDOC_DECL_DD and DDOC_*_MEMBERS are just not enough to extract detailed information.

Ok.
 This also puts quite some restrictions on the layout of the
 resulting documentation. In this case ddoc is very tied to html: These
 macros seem modeled directly after the DD DT DL html elements.

They are.
 I tried to enhance the ddoc output over the last few weeks and it's not
 ready to be released yet, but for example this is the macro structure
 I've chosen for function definitions:
 
 DDOC_FUNCTION
     DDOC_FUNCTION_HEADER_CONTAINER
         DDOC_FUNCTION_TEMPLATE_HEADER
         DDOC_FUNCTION_HEADER
             DDOC_TYPE_FUNCTION
                 DDOC_FUNCTION_PREFIX
                 DDOC_TYPE_MODIFIER
                 DDOC_EXTRA_MODIFIER
                 DDOC_TRUST
                 DDOC_FUNCTION_RETURN_TYPE
                 DDOC_FUNCTION_NAME
                 DDOC_FUNCTION_PARAMETERS
                     DDOC_FUNCTION_LPAREN
                     DDOC_FUNCTION_PARAMETER
                         DDOC_FUNCTION_PARAMETER_STC (storage class)
                         DDOC_FUNCTION_PARAMETER_TYPE
                         DDOC_FUNCTION_PARAMETER_NAME
                         [DDOC_FUNCTION_PARAMETER_DEFAULT]
                         [DDOC_FUNCTION_COMMA]
                     [DDOC_FUNCTION_VARARGS]
                     DDOC_FUNCTION_RPAREN
             DDOC_DECLARATION_SEMICOLON
         DDOC_DITTO
             DDOC_FUNCTION_HEADER...
             DDOC_FUNCTION_TEMPLATE_HEADER...
             DDOC_TEMPLATE_HEADER
     DDOC_FUNCTION_DOC
 
 One major aspect in my changes is that there should be no hardcoded
 output: everything can be redefined through macros, though sane defaults
 should be provided. Example:
 DDOC_DECLARATION_SEMICOLON=;
 DDOC_FUNCTION_VARARGS=...;
 DDOC_FUNCTION_COMMA=,;

This seems excessive.
 With more macros you can generate advanced looking documentation, for
 example, this is what I currently have:
 druntime docs: http://jpf.byethost10.com/druntime/doc/object.html
 simple tests:
 http://jpf.byethost10.com/demo/doc/ddoc/tests/simple/vars.html (druntime
 2.047 in the right upper corner is still hardcoded...)
 
 I also have xml output, but the xml ddoc file isn't complete yet
 (template support is missing)
 http://jpf.byethost10.com/demo_xml/ddoc/tests/simple/
 
 And there's also a problem with phobos:in some cases the sources contain
 html. In other cases there are custom macros in modules which can only
 emit html(std.math, TABLE_SV, ...)

These should be fixed, but that's not a problem with Ddoc.
 and afaik you can't override module level macros with .ddoc files?

Right.
Aug 15 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Walter,

 Johannes Pfau wrote:
 
 On 15.08.2010 23:27, Walter Bright wrote:
 
 retard wrote:
 
 - the markup/macro syntax is NIH new.
 

trivial. I'd like to know how the macro system is inadequate for generating Latex, man, etc. format.

macros emitted by dmd: There are enough macros for the doc comments (DDOC_SUMMARY, DDOC_DESCRIPTION, ...) but not for the types. DDOC_DECL, DDOC_DECL_DD and DDOC_*_MEMBERS are just not enough to extract detailed information.

 This also puts quite some restrictions on the layout of the
 resulting documentation. In this case ddoc is very tied to html:
 These
 macros seem modeled directly after the DD DT DL html elements.

 I tried to enhance the ddoc output over the last few weeks and it's
 not ready to be released yet, but for example this is the macro
 structure I've chosen for function definitions:
 
 DDOC_FUNCTION
 DDOC_FUNCTION_HEADER_CONTAINER
 DDOC_FUNCTION_TEMPLATE_HEADER
 DDOC_FUNCTION_HEADER
 DDOC_TYPE_FUNCTION
 DDOC_FUNCTION_PREFIX
 DDOC_TYPE_MODIFIER
 DDOC_EXTRA_MODIFIER
 DDOC_TRUST
 DDOC_FUNCTION_RETURN_TYPE
 DDOC_FUNCTION_NAME
 DDOC_FUNCTION_PARAMETERS
 DDOC_FUNCTION_LPAREN
 DDOC_FUNCTION_PARAMETER
 DDOC_FUNCTION_PARAMETER_STC (storage class)
 DDOC_FUNCTION_PARAMETER_TYPE
 DDOC_FUNCTION_PARAMETER_NAME
 [DDOC_FUNCTION_PARAMETER_DEFAULT]
 [DDOC_FUNCTION_COMMA]
 [DDOC_FUNCTION_VARARGS]
 DDOC_FUNCTION_RPAREN
 DDOC_DECLARATION_SEMICOLON
 DDOC_DITTO
 DDOC_FUNCTION_HEADER...
 DDOC_FUNCTION_TEMPLATE_HEADER...
 DDOC_TEMPLATE_HEADER
 DDOC_FUNCTION_DOC
 One major aspect in my changes is that there should be no hardcoded
 output: everything can be redefined through macros, though sane
 defaults
 should be provided. Example:
 DDOC_DECLARATION_SEMICOLON=;
 DDOC_FUNCTION_VARARGS=...;
 DDOC_FUNCTION_COMMA=,;


Unless you are setting up a new output format, you will never see them. In that light, it doesn't seem excessive to me. -- ... <IXOYE><
Aug 15 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
BCS wrote:
 One major aspect in my changes is that there should be no hardcoded
 output: everything can be redefined through macros, though sane
 defaults
 should be provided. Example:
 DDOC_DECLARATION_SEMICOLON=;
 DDOC_FUNCTION_VARARGS=...;
 DDOC_FUNCTION_COMMA=,;


Unless you are setting up a new output format, you will never see them. In that light, it doesn't seem excessive to me.

Adding features because one can isn't good enough. One should only add features if they fill a real need. I don't see a point to things like a macro for a ;.
Aug 15 2010
parent reply Johannes Pfau <spam example.com> writes:
On 16.08.2010 04:53, Walter Bright wrote:
 BCS wrote:
 One major aspect in my changes is that there should be no hardcoded
 output: everything can be redefined through macros, though sane
 defaults
 should be provided. Example:
 DDOC_DECLARATION_SEMICOLON=;
 DDOC_FUNCTION_VARARGS=...;
 DDOC_FUNCTION_COMMA=,;


Unless you are setting up a new output format, you will never see them. In that light, it doesn't seem excessive to me.

Adding features because one can isn't good enough. One should only add features if they fill a real need. I don't see a point to things like a macro for a ;.

the final output. With hardcoded ; this is not easily doable. If you look at the posted examples you will see that I hide the ; for most types. This is the only way to achieve something like <span class="ddoc_semicolon">;</span> which now allows all kinds of css stuff. The xml output for example completely ignores semicolons and commas, because they don't make sense there. <returns>void</returns> <name>testFunction</name> <parameters> <parameter> <type>int</type> <name>i</name> </parameter> <parameters>... Also consider that all macros have sane defaults. No one is required to redefine them if it's not needed. In fact most macros default to a simple $0 and unless you redefine these you'll never come across them. I agree though that there are lots of macros, maybe too many. But it's hard to find the point between too few and too many. This remembers me, that there is another limitation with the macro system. Consider for example: DDOC_CLASS DDOC_PROTECTION DDOC_FUNTION DDOC_PROTECTION In the DDOC_PROTECTION macro you never know whether this is the protection for the function or for the class. If you need different output for DDOC_PROTECTION depending on that, you'll have to define DDOC_CLASS_PROTECTION and DDOC_FUNCTION_PROTECTION or you have to generate xml first <ddoc_class><ddoc_protetion>private</ddoc_protetion></ddoc_class> and process this xml further, because with xml you can extract the parent elements. I know this is by design, and it's not a huge problem. But it means you need even more macros if you want to make rich output possible without a custom post processor. I know that the phobos problem is not directly a problem of ddoc. I just mentioned it because it also makes generating documentation for other formats harder. These phobos macros should maybe be moved to the std.ddoc file. But then we have custom phobos macros which must be redefined for generating a different output format and if every project defines there own macros like that, making .ddoc files to output to different formats soon becomes a mess. I agree that macros to output tables etc are needed though. But it's important that not every project defines it's own table macros. And one more problem, though not directly related to the macro system: If one really documented code in a WYSIWYG way and would not think he might be generating html, he could use <,> and &. This would definitely break html, which means you must make assumptions about the final output format in the documentation or you might break it. -- Johannes Pfau
Aug 16 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Johannes Pfau wrote:
[...] lots of stuff

Some good arguments.
Aug 16 2010
prev sibling parent reply lurker <lurk lurk.net> writes:
Johannes Pfau Wrote:

 On 16.08.2010 04:53, Walter Bright wrote:
 BCS wrote:
 This seems excessive.

them. In that light, it doesn't seem excessive to me.

Adding features because one can isn't good enough. One should only add features if they fill a real need.


 bla blah blah bla

 
 -- 
 Johannes Pfau

This is unbelievable douchebaggery. The default ddoc IS good enough for most of us. There is simply no need for more complex tools. I think ddoc hits the sweet spot here by providing semi-professional looking html documents. Like someone said earlier, you can always spent a week worth of time creating a better tool for document generation. Doxygen STILL doesn't support D. What does this tell? It tells that C++ is crappy for software development. The millions of C++ users haven't been able to write a docgen support for D. It's just not possible. OTOH a qualified compiler veteran such as Walter wrote a better tool in less than a week, blindfolded.
Aug 16 2010
next sibling parent reply Johannes Pfau <spam example.com> writes:
On 16.08.2010 22:36, lurker wrote:
 
 This is unbelievable douchebaggery. The default ddoc IS good enough for most
of us. There is simply no need for more complex tools. I think ddoc hits the
sweet spot here by providing semi-professional looking html documents. Like
someone said earlier, you can always spent a week worth of time creating a
better tool for document generation.
 
 Doxygen STILL doesn't support D. What does this tell? It tells that C++ is
crappy for software development. The millions of C++ users haven't been able to
write a docgen support for D. It's just not possible. OTOH a qualified compiler
veteran such as Walter wrote a better tool in less than a week, blindfolded.

What's the point of this post? I never wanted to replace ddoc in any way - the syntax is the best documentation syntax that I've seen, the WYSIWYG ideology is great and it's great that ddoc can output to different formats. If it sounded like I was flaming or something, I did not want to. (I agree, the last point about <,> is quite hypothetical) But there are little problems with ddoc - I mentioned a few, some more are already known and some of these might even exist in doxygen as well. (I don't know doxygen and I always thought it's generated documentation looks ugly. I only know the msdn / ndoc / qooxdoo.org api documentation which IMHO beat doxygen) Sure most of these issues are often not important. But if it's possible why not fix these? Why is spending one week (of my time) to enhance ddoc (and fix the known bugs, I want to provide a fix for the known problem with stray parenthesis in the next few days) a bad thing? BTW: what do you consider to be "default ddoc"? I agree that the phobos documentation is fine, but there is no default ".ddoc" file shipped with dmd and the documentation generated without a special .ddoc file is not that great. -- Johannes Pfau
Aug 16 2010
parent reply lurker <lurk lurk.net> writes:
Johannes Pfau Wrote:

 On 16.08.2010 22:36, lurker wrote:
 
 This is unbelievable douchebaggery. The default ddoc IS good enough for most
of us. There is simply no need for more complex tools. I think ddoc hits the
sweet spot here by providing semi-professional looking html documents. Like
someone said earlier, you can always spent a week worth of time creating a
better tool for document generation.
 
 Doxygen STILL doesn't support D. What does this tell? It tells that C++ is
crappy for software development. The millions of C++ users haven't been able to
write a docgen support for D. It's just not possible. OTOH a qualified compiler
veteran such as Walter wrote a better tool in less than a week, blindfolded.

What's the point of this post? I never wanted to replace ddoc in any way - the syntax is the best documentation syntax that I've seen, the WYSIWYG ideology is great and it's great that ddoc can output to different formats. If it sounded like I was flaming or something, I did not want to. (I agree, the last point about <,> is quite hypothetical)

Whatever. I feel insulted. :-(
 
 But there are little problems with ddoc - I mentioned a few, some more
 are already known and some of these might even exist in doxygen as well.
 (I don't know doxygen and I always thought it's generated documentation
 looks ugly. I only know the msdn / ndoc / qooxdoo.org api documentation
 which IMHO beat doxygen) Sure most of these issues are often not
 important. But if it's possible why not fix these? Why is spending one
 week (of my time) to enhance ddoc (and fix the known bugs, I want to
 provide a fix for the known problem with stray parenthesis in the next
 few days) a bad thing?

Fixing problems is good, but when creating documentation the main focus is on communicating ideas. All kinds of fancy colors just distract people. I like default Phobos docs. It's hard to find something as simple from other language communities. The C++ documentation sucks so much that I mostly read dead tree books. And I think simple macros are better than tons of semicolon rules.
 
 BTW: what do you consider to be "default ddoc"? I agree that the phobos
 documentation is fine, but there is no default ".ddoc" file shipped with
 dmd and the documentation generated without a special .ddoc file is not
 that great.

I meant that one or candydoc.
Aug 16 2010
next sibling parent Johannes Pfau <spam example.com> writes:
On 16.08.2010 23:10, lurker wrote:
 Johannes Pfau Wrote:
 
 Fixing problems is good, but when creating documentation the main focus is on
communicating ideas. All kinds of fancy colors just distract people. I like
default Phobos docs. It's hard to find something as simple from other language
communities. The C++ documentation sucks so much that I mostly read dead tree
books. And I think simple macros are better than tons of semicolon rules.

documentation layout really does a great job at being simple and still good-looking. But when heavy template usage is documented (std.algorithm) I sometimes feel lost (in std.algorithm 'Until' is an example for that). I think some color there is helpful. But the great thing about ddoc is you can have both. The semicolon rules are important for xml - I don't want semicolons in my xml output ;-) (Though it could be argued whether xml output is needed at all)
 
 I meant that one or candydoc.

-- Johannes Pfau
Aug 16 2010
prev sibling next sibling parent Ellis Peters <epeters donthavemail.com> writes:
retard Wrote:

 Mon, 16 Aug 2010 17:10:12 -0400, lurker wrote:
 
 Johannes Pfau Wrote:
 
 On 16.08.2010 22:36, lurker wrote:
 
 This is unbelievable douchebaggery. The default ddoc IS good enough
 for most of us. There is simply no need for more complex tools. I
 think ddoc hits the sweet spot here by providing semi-professional
 looking html documents. Like someone said earlier, you can always
 spent a week worth of time creating a better tool for document
 generation.
 
 Doxygen STILL doesn't support D. What does this tell? It tells that
 C++ is crappy for software development. The millions of C++ users
 haven't been able to write a docgen support for D. It's just not
 possible. OTOH a qualified compiler veteran such as Walter wrote a
 better tool in less than a week, blindfolded.

What's the point of this post? I never wanted to replace ddoc in any way - the syntax is the best documentation syntax that I've seen, the WYSIWYG ideology is great and it's great that ddoc can output to different formats. If it sounded like I was flaming or something, I did not want to. (I agree, the last point about <,> is quite hypothetical)

Whatever. I feel insulted. :-(

And they try to convince themselves that I'm the troll..

Just. Go. To. Your. Ivory. Tower. period.
Aug 17 2010
prev sibling parent Justin Johansson <no spam.com> writes:
On 17/08/10 06:57, retard wrote:
 Mon, 16 Aug 2010 17:10:12 -0400, lurker wrote:

 Johannes Pfau Wrote:

 On 16.08.2010 22:36, lurker wrote:
 This is unbelievable douchebaggery. The default ddoc IS good enough
 for most of us. There is simply no need for more complex tools. I
 think ddoc hits the sweet spot here by providing semi-professional
 looking html documents. Like someone said earlier, you can always
 spent a week worth of time creating a better tool for document
 generation.

 Doxygen STILL doesn't support D. What does this tell? It tells that
 C++ is crappy for software development. The millions of C++ users
 haven't been able to write a docgen support for D. It's just not
 possible. OTOH a qualified compiler veteran such as Walter wrote a
 better tool in less than a week, blindfolded.

What's the point of this post? I never wanted to replace ddoc in any way - the syntax is the best documentation syntax that I've seen, the WYSIWYG ideology is great and it's great that ddoc can output to different formats. If it sounded like I was flaming or something, I did not want to. (I agree, the last point about<,> is quite hypothetical)

Whatever. I feel insulted. :-(

And they try to convince themselves that I'm the troll..

You are not a troll my dear retard. I am a troll.
Aug 17 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
On 17/08/10 06:06, lurker wrote:
 Doxygen STILL doesn't support D. What does this tell?

On the contrary. Time and time again I try to restart a pet project of mine in D and time and time again I find myself reverting to C++. This tells me, not so much that D is crappy for software development, rather that D cannot cut the production code that I can currently produce at less cost and *angst* than in C++. Mind you, I do wish for something better than C++ but for my enterprise, D does not do it in the large. D remains for me a cute language for small production runs akin to a little bit of Algol-ish scripting. Throw a bit of static type-checking into Javascript and a decent macro facility and JS might cut it just as well ;-) Still I lurk around here for maybe much the same reasons as others: a hope for some Nirvana in the future and this NG being a nice place to share that future hope for in the present. Cheers Justin Johansson
Aug 17 2010
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Justin Johansson Wrote:

 On 17/08/10 06:06, lurker wrote:
 Doxygen STILL doesn't support D. What does this tell?

On the contrary. Time and time again I try to restart a pet project of mine in D and time and time again I find myself reverting to C++. This tells me, not so much that D is crappy for software development, rather that D cannot cut the production code that I can currently produce at less cost and *angst* than in C++.

Why?
Aug 17 2010
prev sibling parent Justin Johansson <no spam.com> writes:
On 18/08/10 01:58, Steven Schveighoffer wrote:
 On Tue, 17 Aug 2010 11:50:22 -0400, Justin Johansson <no spam.com> wrote:

 On 17/08/10 06:06, lurker wrote:
 Doxygen STILL doesn't support D. What does this tell?

On the contrary. Time and time again I try to restart a pet project of mine in D and time and time again I find myself reverting to C++. This tells me, not so much that D is crappy for software development, rather that D cannot cut the production code that I can currently produce at less cost and *angst* than in C++.

I don't know if you've posted your source of angst already, so at the risk of asking you to do something you've already done, can you let us

 know what aspects of D make you switch back to C++? These kinds of
 things can be very helpful in either A) guiding the D devs on where we
 should focus our attention or B) helping you use D appropriately if you
 are unaware of some features that already solve your problems.

 -Steve

I won't be rehashing all issues that I've commented on the past as it is just a matter of time before some of these are resolved. e.g. Shared objects on Linux was a show-stopper for me earlier on but believe Walter has this on his radar now. The main reason why I hesitate to restart my pet project in D right now is the trouble with const and, more importantly, immutable (this being an attractive feature of D for me at least in concept). This issue is getting a lot of prime time in the thread "Status of Const" so it's no point reiterating it here, suffice to say that while the feature looks good on paper the model requires a rework and/or bugs fixed as is being discussed in that thread at the moment. -- Justin
Aug 19 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el 15 de agosto a las 19:53 me escribiste:
 BCS wrote:
One major aspect in my changes is that there should be no hardcoded
output: everything can be redefined through macros, though sane
defaults
should be provided. Example:
DDOC_DECLARATION_SEMICOLON=;
DDOC_FUNCTION_VARARGS=...;
DDOC_FUNCTION_COMMA=,;


Unless you are setting up a new output format, you will never see them. In that light, it doesn't seem excessive to me.

Adding features because one can isn't good enough. One should only add features if they fill a real need. I don't see a point to things like a macro for a ;.

What about < and &? =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Borrowing money from a friend is like having sex. It just completely changes the relationship. -- George Constanza
Aug 15 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 16 Aug 2010 17:10:12 -0400, lurker wrote:

 Johannes Pfau Wrote:
 
 On 16.08.2010 22:36, lurker wrote:
 
 This is unbelievable douchebaggery. The default ddoc IS good enough
 for most of us. There is simply no need for more complex tools. I
 think ddoc hits the sweet spot here by providing semi-professional
 looking html documents. Like someone said earlier, you can always
 spent a week worth of time creating a better tool for document
 generation.
 
 Doxygen STILL doesn't support D. What does this tell? It tells that
 C++ is crappy for software development. The millions of C++ users
 haven't been able to write a docgen support for D. It's just not
 possible. OTOH a qualified compiler veteran such as Walter wrote a
 better tool in less than a week, blindfolded.

What's the point of this post? I never wanted to replace ddoc in any way - the syntax is the best documentation syntax that I've seen, the WYSIWYG ideology is great and it's great that ddoc can output to different formats. If it sounded like I was flaming or something, I did not want to. (I agree, the last point about <,> is quite hypothetical)

Whatever. I feel insulted. :-(

And they try to convince themselves that I'm the troll..
Aug 16 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 17 Aug 2010 11:50:22 -0400, Justin Johansson <no spam.com> wrote:

 On 17/08/10 06:06, lurker wrote:
 Doxygen STILL doesn't support D. What does this tell?

On the contrary. Time and time again I try to restart a pet project of mine in D and time and time again I find myself reverting to C++. This tells me, not so much that D is crappy for software development, rather that D cannot cut the production code that I can currently produce at less cost and *angst* than in C++.

I don't know if you've posted your source of angst already, so at the risk of asking you to do something you've already done, can you let us know what aspects of D make you switch back to C++? These kinds of things can be very helpful in either A) guiding the D devs on where we should focus our attention or B) helping you use D appropriately if you are unaware of some features that already solve your problems. -Steve
Aug 17 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 Wouldn't it be better to just write html when that's all your asking 
 ddoc to do?

As I mentioned, I've tried it that way, and ddoc makes me 2 or even 3 times more productive doing it.
Aug 07 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 On Sun, 08 Aug 2010 00:26:42 -0400, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 Steven Schveighoffer wrote:
 Wouldn't it be better to just write html when that's all your asking 
 ddoc to do?

As I mentioned, I've tried it that way, and ddoc makes me 2 or even 3 times more productive doing it.

You're not getting what I'm saying, so I'll just stop :)

Sorry.
 
 Thanks for trying.
 
 -Steve

Aug 09 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob me.com> wrote:
 
 On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them.


 One reason of it I can think of: parsing speed and ambiguities (same as
 with <templates>)

 Anyway, when D will take over the world, they will have to change HTML
 syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros.

Does ddoc output in pdf?

I have an experimental std.ddoc that generates TeX. I understand your arguments - they're pretty much echoing those of myself and of Janice Caron when we first saw the Phobos docs. It didn't take me a long time to appreciate ddoc. Right now I'm considering converting my entire website to use ddoc. HTML is a pile of dung to actually write text in, and somehow I always up editing the raw HTML no matter how much editors are trying to hide it from me. So how about this - give it a while and it's not impossible that your view might change. Andrei
Aug 06 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-06 19:23, Steven Schveighoffer wrote:
 On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them.


 One reason of it I can think of: parsing speed and ambiguities (same as
 with <templates>)

 Anyway, when D will take over the world, they will have to change HTML
 syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros.

Does ddoc output in pdf? And besides, most of the tags *are* html tags, they're even the same tag name. I can't imagine there's no htmltopdf program that would do exactly that. Regarding the <span class="bold"> thing, can't you just do this in css: b { whatever; }

Many/some of the "style" tags have been deprecated in XHTML/HTML5. Now, apparently "b" wasn't one of them as I first thought.
 and override what <b> does? There are probably macros which do other
 things that xhtml/css cannot do, but I don't think we should use macros
 for every html element. For example, the $(V1) and $(V2) tags. We need a
 good solution for that, and I think having dmd work those out is fine. I
 also don't mind using the macros for more dynamic stuff. I just think
 the formatting stuff can remain html, and all the macros should be
 defined/documented somewhere.

 I like this explanation from Alexander:

 In the end it's just markup language and I don't see much use in
 learning more then one of them.

 It's just a thought, it might be blowing out of proportion a bit.
 Granted I think I would have felt more comfortable using html directly,
 but it wasn't that hard to learn, and I was able to work through the
 issues. I just wish I had some editor help...

 -Steve

Would it be better to write in XML that then converts it to the output format? -- /Jacob Carlborg
Aug 07 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I just did (fixed a lot of stuff in the array page).

Thank you.
 A couple comments:
 1. There is no guideline for updating the spec (at least that I could 
 find).  I deduced $(V1) and $(V2) and figured out what $(LNAME2) is, but 
 lack of guidelines may be partially to blame for why few people edit it.
 2. It seems like the documentation is HTML written as ddoc.  I see $(P) 
 tags, $(LI) tags, etc.   Can't we just write it as HTML?

Nooooo, I tried to get away from that! HTML is a horrible format. Besides, I've also had thoughts of being able to use the macros to generate things like Latex output or man page output from the same source text.
 I think many 
 would feel much more comfortable that way.  It's also more supported by 
 editors.  I forgot a closing parentheses on one tag, and it screwed up 
 the entire page.  I had to find it by hand, whereas an HTML editor could 
 red-flag a tag without a closing tag, or you could run it through an XML 
 verifier (if it's xhtml).

I often make that mistake. But the editor I use (microemacs) has a fabulous feature, F3, which finds the matching ( { [ < > ] } ) #ifdef/#elif/#else/#endif when the cursor is placed on one of those. It makes it utterly trivial to find the mismatch. BTW, back when the doc was in HTML, it was absolutely rife with mismatched HTML open and close tags. The fact that browsers would render it anyway I did not regard as a feature. The Ddoc macro format helps enormously in generating *correct* HTML. I've now got the entire D website using Ddoc, and the macros have enabled me to establish a common, and customizable, look and feel across the entire site just by adjusting the macro definitions. The other feature of the macro method is, obviously, that they can be customized to generate all sorts of things. I believe that candydoc relies on that.
Aug 06 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i3i2m7$i9d$1 digitalmars.com...
 But the editor I use (microemacs) has a fabulous feature, F3, which finds 
 the matching ( { [ < > ] } ) #ifdef/#elif/#else/#endif when the cursor is 
 placed on one of those. It makes it utterly trivial to find the mismatch.

Many editors will automatically highlight a match/mismatch without even pressing a key. For instance, I use Programmer's Notepad 2: Even out-of-the-box, if you place the cursor on a ( { [ ] } ), in a ddoc comment or anywhere else, then both that character and the matching one will turn bold and blue. If there isn't a matching one, then the one under the cursor turns bold and red. That's helped me many times.
 BTW, back when the doc was in HTML, it was absolutely rife with mismatched 
 HTML open and close tags. The fact that browsers would render it anyway I 
 did not regard as a feature.

My opinion on that has changed somewhat over the years. Originally, my opinion was "Huh? That seems dumb." Now I consider it one of the stupidest, most colossal, and most painful blunders of the 1990's.
 The other feature of the macro method is, obviously, that they can be 
 customized to generate all sorts of things. I believe that candydoc relies 
 on that.

Many web monkeys would probably argue "That's what CSS is for!" But, of course, CSS is shit for layouts. Doubly-so for non-fixed-width layouts. About the only thing it doesn't suck for is formatting, but even that could be better (ex: Is there *any* consistent logic to what's "font-" and what's "text-"?). And I'll see your "HTML/XML syntax is a horrid verbose mess", and raise you a "(X)HTML's shittiness extends far beyond the syntax."
Aug 06 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 And I'll see your "HTML/XML syntax is a horrid verbose mess", and raise you 
 a "(X)HTML's shittiness extends far beyond the syntax."

What's odd about how pointlessly verbose it is, is it was designed in the era of modems. You'd think that tightening up the syntax would be a priority.
Aug 06 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 08/07/2010 01:40 AM, Walter Bright wrote:
 What's odd about how pointlessly verbose it is, is it was designed in
 the era of modems. You'd think that tightening up the syntax would be a
 priority.

Do you really think those <p> tags and <a href> tags were choking the 14.4 modems of the time? When HTML was first designed, it was a simple markup language. The real bandwidth killers were when people put pictures (*gasp*) in their HTML pages. It got really annoying when people decided to use image maps for navigation, which meant you couldn't browse with pictures turned off. Ah, good times.
Aug 07 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jeff Nowakowski wrote:
 On 08/07/2010 01:40 AM, Walter Bright wrote:
 What's odd about how pointlessly verbose it is, is it was designed in
 the era of modems. You'd think that tightening up the syntax would be a
 priority.

Do you really think those <p> tags and <a href> tags were choking the 14.4 modems of the time? When HTML was first designed, it was a simple markup language.

A typical HTML source file is about double the size it needs to be if HTML were designed better. A lot of sites did work hard to try to shrink their HTML pages so they'd load faster.
 The real bandwidth killers were when people put pictures (*gasp*) in 
 their HTML pages. It got really annoying when people decided to use 
 image maps for navigation, which meant you couldn't browse with pictures 
 turned off.

Yeah, I remember sitting and waiting a lot. Don't miss that.
Aug 07 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i3k9kd$2hnc$1 digitalmars.com...
 The real bandwidth killers were when people put pictures (*gasp*) in 
 their HTML pages. It got really annoying when people decided to use image 
 maps for navigation, which meant you couldn't browse with pictures turned 
 off.

Yeah, I remember sitting and waiting a lot. Don't miss that.

I still have to do that on many sites when I turn JS on.
Aug 07 2010
prev sibling next sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
On 08/07/2010 02:45 PM, Walter Bright wrote:
 A typical HTML source file is about double the size it needs to be if
 HTML were designed better. A lot of sites did work hard to try to shrink
 their HTML pages so they'd load faster.

Double the size? There's no way that was true back when HTML first came out. The gobs of tables and 1 pixel image crap for formatting was not there at the beginning. There were no style sheets. There wasn't JavaScript, which is where a lot of the bloat comes from these days. I think you came late to the party and didn't see it evolve at the earliest stages. The first pages were basically headers, paragraphs of text, and links. A small picture on a page would overwhelm any amount of HTML markup.
Aug 07 2010
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 Jeff Nowakowski wrote:
 On 08/07/2010 01:40 AM, Walter Bright wrote:
 What's odd about how pointlessly verbose it is, is it was designed in
 the era of modems. You'd think that tightening up the syntax would be a
 priority.

Do you really think those <p> tags and <a href> tags were choking the 14.4 modems of the time? When HTML was first designed, it was a simple markup language.

A typical HTML source file is about double the size it needs to be if HTML were designed better. A lot of sites did work hard to try to shrink their HTML pages so they'd load faster.

For example, haml with Ruby on Rails: http://haml-lang.com/ The markup is readable and maps very easy to html.
Aug 07 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-08-08 01:02, Lutger wrote:
 Walter Bright wrote:

 Jeff Nowakowski wrote:
 On 08/07/2010 01:40 AM, Walter Bright wrote:
 What's odd about how pointlessly verbose it is, is it was designed in
 the era of modems. You'd think that tightening up the syntax would be a
 priority.

Do you really think those<p> tags and<a href> tags were choking the 14.4 modems of the time? When HTML was first designed, it was a simple markup language.

A typical HTML source file is about double the size it needs to be if HTML were designed better. A lot of sites did work hard to try to shrink their HTML pages so they'd load faster.

For example, haml with Ruby on Rails: http://haml-lang.com/ The markup is readable and maps very easy to html.

haml is a great language but it is converted to html so there is no space saving. -- /Jacob Carlborg
Aug 08 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Alexander Malakhov wrote:
 Also, for example, what if I want to put extra ')' paren into $(D text)?
 I think there is (simple) solution, but that is one more thing to learn.

RPAREN=) $(D text $(RPAREN) ) You'll see a few of those in the macros, in particular $(DOLLAR) to embed a dollar sign. It's not so bad, every markup language needs an escape method.
Aug 06 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 This is the same method used in some text editors (e.g. Scite uses this 
 exact same method for variables, $() ).

Yah, I just used the makefile syntax.
Aug 06 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Ok, Walter is working on a 64-bit compiler, then on the shared library 
 support. That's great. But many of us would like to know who is
 
  * managing the communication with the user community
  * managing the communication with the language/compiler developers
  * managing the bugfixes to the spec
  * managing the compiler bugfix release (minor version) process
  * managing the language development debate
  * coordinating the future language development (roadmap page of the trac)
  * managing the public relations with the people outside the core 
 community
 
 It seems Walter wants to be a lonely wolf. Nobody else is allowed to do 
 anything listed above unless you're Andrei. There are no managers, we 
 only have experts working with their favorite features and no 
 communication exists between these persons or the community.

There are quite a few people actively contributing to all of the above. Perhaps you don't monitor the D mailing lists where a lot of this activity is going on. If there's a particular one you want to contribute to, you're welcome to join us.
Aug 05 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 I'd like to design D 3.0 features and the new LLVM based compiler with 
 bearophile and fill the roadmap page in the trac page. Is that ok? How 
 can I start?

Just do it. You don't need anyone's permission.
Aug 05 2010
prev sibling parent Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 8/4/2010 9:22 PM, Andrei Alexandrescu wrote:
 Walter is more silent than usual because he's working very hard on the
 64-bit compiler. He hopes to have one by the end of this month. His next
 big goal is shared library support.

Awesome! Go Walter!
Aug 05 2010
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el  5 de agosto a las 14:42 me escribiste:
 awishformore wrote:
64 bits on other platforms will follow once it proves out on Linux.

So the 64bit support you're working on will not be for Windows?

Not initially. 64 bit C on Windows uses a different ABI, the exception handling support is different, there's no linker (oops), etc. It's a much harder job.

Suddenly LLVM Windows support doesn't seem so bad ;) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- No debemos temer a la muerte, porque es la mejor recompensa de la vida. -- Ren & Stimpy
Aug 05 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
bioinfornatics, el  5 de agosto a las 22:04 me escribiste:
 is funny because on fedora ldc works fine on 32 and 64 bits. Now is in official
 fedora same as tango.
 And some other project will do soon like:
 - mango
 - derelict
 
 but yes is a linux system ( sorry )

Same for Debian/Ubuntu. It has limitations (specially on Windows because of LLVM limitations) but is far from unusable. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Home, home again. I like to be here when I can. When I come home cold and tired It's good to warm my bones beside the fire.
Aug 05 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 04/08/2010 00:18, Leandro Lucarella wrote:
 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

Indeed. In fact, I think that was one of the more important and interesting questions. And not just for the talk, but for the future as well, whenever newcomers try to evaluate D. This a litmus test of sorts, to see if everything in the language really adds up, and is in fact useful and powerful in practice. And I think it is important to bear in mind the distinction between D2 and D1 in this question. If you present D2 with all its nifty new features and radical changes from D1, people will want to know what is the biggest application in *that* language. They want to know if all those features really and up, and if people are really using that language. I think that if D1 apps are mentioned, that's ok, but it would be best to note that they are from an earlier, simpler version of the language. -- Bruno Medeiros - Software Engineer
Sep 20 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 8/3/10, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrei put together a benchmark that shows that D compiles 4 times faster
 than Go.

I've found D1 tends to be much faster than D2 as well. The dmd version 1 is so fast that I often think it doesn't even run! D2's (relative) slowness I've tracked down to import std.stdio; - it instantiates a bunch of templates just on import. We should be able to fix this with a little work, and put D even further ahead of the competition. Then, just ditch that sloooow GNU ld on linux. On a related note, I've gotta say Digital Mars has always been way ahead of the competition on speed. DMC was my first compiler. dmc+optlink is just insanely fast, even on my old Pentium 1. When I first went to Linux+gcc, it was a huge shock. Compared to dmc, gcc is a snail. And it was even worse back then! The Digital Mars EMCAScript implementation is insanely fast too. It comes in at about 80x faster than IE6 - its contemporary competition. Now, the new browsers beat it out by several times, but it took them a lot of years to catch up.
Aug 03 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 8/3/10, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 BTW, speed of compilation of very short programs is not very relevant as
 long as it's reasonably good.

I don't know. Large programs is certainly very important, but I think small ones are too. The reason is a very quick compile on small programs means you can compete directly with the interpreted languages for quick toys. Imagine being able to use rdmd --eval where you would use sed and grep, and see quick changes work just as easily. I'd love it. (rdmd's caching does a really good job for repeated uses, but when toying with sed, I often keep tweaking the line until it works. In that case, rdmd is just a wee bit too slow to recompile.)
Aug 03 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el  3 de agosto a las 19:48 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el  3 de agosto a las 15:08 me escribiste:
bearophile wrote:
At 14.42: You compare the performance of a D compiler with the performance of
a C++ compiler. But Delphi compiler was/is very fast (and probably the
FreePascal compile too), I have never "waited" for my Delphi (ObjectPascal)
code to compile. I think on average it takes only two thousand clock ticks to
compile one line of ObjectPascal code. It sounds a lot, but it means that
with a modern single-core CPU you can produce your binary file from a one
million ObjectPascal lines long program in less than two seconds.
ObjectPascal type system looks a bit simpler than D one (despite it has OOP,
generics, modules, inline asm, dynamic strings, records, all basic D types,
etc), so this isn't a fully apple-to-apple comparison.

Some context is in order. The talk was given at Google and aimed at what would be interesting to Googlers. Google uses C++ extensively, and Rob Pike (of Go) listed as a motivator for Go the compile speed problems with C++. Rob made a point of how fast Go compiled code, and Go's compile speed has been praised a lot on Reddit as well. Andrei put together a benchmark that shows that D compiles 4 times faster than Go.

I was surprised by that, can you publish what the benchmark was, and what compilers were used? I tried Go when it came out and it felt faster than D to compile (which is reasonable because is a much simpler language).

I tested on two laptops (Ubuntu and Mac OSX). I compiled the two languages' standard libraries by using the provided makefiles, after touching all .go and all .d files involved. Then I divided the compilation times by the line counts of *.go/*.d files as wc has them and compared the results. On OSX dmd was 4.3 times faster. On Ubuntu, the ratio was 4.45.

Seems like a very fair benchmark, I'm really surprised. Which Go compiler did you tried, gccgo or gc (6g/8g)? IIRC gccgo is much slower than gc.
 I had an online demo prepared for the talk, but I decided to not use it.

It would be a good selling point (is not the same hearing than seeing :). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- In a world without fences, who need gates?
Aug 03 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el  3 de agosto a las 19:56 me escribiste:
 Leandro Lucarella wrote:
BCS, el  3 de agosto a las 16:04 me escribiste:
The video is up:

http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

Yellow shirt? Yes, I plan to ask Benjamin about his whereabouts and send him a book.

Ask him to write a killer app in D and publish it in return :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Me encanta el éxito; por eso prefiero el estado de progreso constante, con la meta al frente y no atrás. -- Ricardo Vaporeso. Punta del Este, Enero de 1918.
Aug 03 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 The video is up:
 
 http://www.youtube.com/watch?v=RlVpPstLPEc

Per popular demand, I uploaded the slides here: http://erdani.com/d/three-cool-things-about-d.pdf Andrei
Aug 03 2010
parent Rory Mcguire <rjmcguire gm_no_ail.com> writes:
Andrei Alexandrescu wrote:

 BCS wrote:
 The video is up:
 
 http://www.youtube.com/watch?v=RlVpPstLPEc

Per popular demand, I uploaded the slides here: http://erdani.com/d/three-cool-things-about-d.pdf Andrei

Shouldn't your file copy example have used File.tmpfile()?
Aug 04 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 03 Aug 2010 17:56:44 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 bearophile wrote:
 27.50, "transactional file copy": this example was script-like, and as  
 short
 as possible to fit into one single slide, so in this case I think using
 enforce() is OK. But in true programs I suggest all D programmers to use
 DesignByContract with assert() more and to use enforce() less. Among  
 other
 things enforce() kills inlining possibilities and inflates code. In  
 D.learn I
 have seen people use enforce() in a situation where DbC is designed  
 for. I
 think the D community needs to learn a bit more DbC, and in my opinion  
 to do
 this the leaders have to lead the way.

There's a misunderstanding here. Contract programming is for detecting program bugs. enforce() is for detecting and handling errors such as disk failures and bad user input. They are COMPLETELY DIFFERENT and must not be conflated.

Yes, but as has been discussed and resolved on phobos mailing list, usage errors should not be handled via uncaught exceptions. I think the example is flawed in that regard. I wouldn't bring it up, but people who haven't followed that discussion might get the wrong idea from this example. -Steve
Aug 04 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 03 Aug 2010 20:21:49 -0400, Adam Ruppe <destructionator gmail.com>  
wrote:

 On 8/3/10, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrei put together a benchmark that shows that D compiles 4 times  
 faster
 than Go.

I've found D1 tends to be much faster than D2 as well. The dmd version 1 is so fast that I often think it doesn't even run! D2's (relative) slowness I've tracked down to import std.stdio; - it instantiates a bunch of templates just on import. We should be able to fix this with a little work, and put D even further ahead of the competition.

I also feel that templates inappropriately slow down compilation. For dcollections, when compiling without unit tests enabled, compilation is less than a second. With unit tests enabled, which instantiate about 8 instances of each object (of which there are 8), compilation takes over a minute. I still don't know why, but it seems to be evenly spread throughout compilation (compiling with -v shows it progressing through many functions).
 Then, just ditch that sloooow GNU ld on linux.

I would be surprised if ld was a culprit in compilation slowdown. -Steve
Aug 04 2010
prev sibling next sibling parent Arth Lloyd Flores <floresarthlloyd gmail.com> writes:
--00163683381c146f97048cff8ecc
Content-Type: text/plain; charset=ISO-8859-1

How I wish I were there... for the book :D

That was a nice talk Andrei.. I congratulate you..

-- 
-Arth

--00163683381c146f97048cff8ecc
Content-Type: text/html; charset=ISO-8859-1

How I wish I were there... for the book :D<div><br></div><div>That was a nice
talk Andrei.. I congratulate you..<br><br>-- <br>-Arth<br>
</div>

--00163683381c146f97048cff8ecc--
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Rory Mcguire, el  4 de agosto a las 12:37 me escribiste:
 Leandro Lucarella wrote:
 
 BCS, el  3 de agosto a las 16:04 me escribiste:
 The video is up:
 
 http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

What type of apps are you looking for?

Anything that can be automatically run for benchmarking, if they do intensive use of the GC or need small pauses, much better. But if it's D2, I'm sorry but is too late, I'll stick to D1 for now, when I'm finish I probably try to port it to D2 and ask again.
 I have a couple of smtp apps.

SMTP as in Simple Mail Transfer Protocol? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Que el viento y la lluvia sean dos hermanos y corran furiosos por los terraplenes de Víctor Heredia. -- Ricardo Vaporeso. Lanús, 1912.
Aug 04 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 04 Aug 2010 09:03:45 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:

 Steven Schveighoffer:
 Yes, but as has been discussed and resolved on phobos mailing list,  
 usage
 errors should not be handled via uncaught exceptions.

Do you have some URL for that discussion?

Hm... let me see: http://lists.puremagic.com/pipermail/phobos/2010-July/001480.html I think this is what started the discussion. -Steve
Aug 04 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 04 Aug 2010 10:15:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 08/04/2010 06:38 AM, Steven Schveighoffer wrote:
 On Tue, 03 Aug 2010 17:56:44 -0400, Walter Bright
 <newshound2 digitalmars.com> wrote:

 bearophile wrote:
 27.50, "transactional file copy": this example was script-like, and
 as short
 as possible to fit into one single slide, so in this case I think  
 using
 enforce() is OK. But in true programs I suggest all D programmers to  
 use
 DesignByContract with assert() more and to use enforce() less. Among
 other
 things enforce() kills inlining possibilities and inflates code. In
 D.learn I
 have seen people use enforce() in a situation where DbC is designed
 for. I
 think the D community needs to learn a bit more DbC, and in my
 opinion to do
 this the leaders have to lead the way.

There's a misunderstanding here. Contract programming is for detecting program bugs. enforce() is for detecting and handling errors such as disk failures and bad user input. They are COMPLETELY DIFFERENT and must not be conflated.

Yes, but as has been discussed and resolved on phobos mailing list, usage errors should not be handled via uncaught exceptions. I think the example is flawed in that regard. I wouldn't bring it up, but people who haven't followed that discussion might get the wrong idea from this example.

Well I agree with the spirit but let me say this. If all I want is a short script that does the right thing, I don't care whether failure comes with a stack trace caboose. So I don't think the example is flawed at all - it stands as a short correct script that does something useful.

Yes, the utility would be useful and would serve its purpose as a quick-and-dirty script. I shouldn't have labeled it flawed :) A more polished script would be less careless about usage messages, but would require more code. -Steve
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Rory Mcguire, el  4 de agosto a las 18:38 me escribiste:
 What type of apps are you looking for?

Anything that can be automatically run for benchmarking, if they do intensive use of the GC or need small pauses, much better. But if it's D2, I'm sorry but is too late, I'll stick to D1 for now, when I'm finish I probably try to port it to D2 and ask again.
 I have a couple of smtp apps.

SMTP as in Simple Mail Transfer Protocol?

yes. I have a threaded smtp benchmark app and an smtp blackhole server, for instance. I use them to benchmark my java smtp server. I'll try find my D1 stuff if you would like it.

If it's D1/Tango, yes, I would be interested. Thank you. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Con vos hay pica, patovica! -- Sidharta Kiwi
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Nick Sabalausky, el  4 de agosto a las 12:51 me escribiste:
 What type of apps are you looking for?

Anything that can be automatically run for benchmarking, if they do intensive use of the GC or need small pauses, much better. But if it's D2, I'm sorry but is too late, I'll stick to D1 for now, when I'm finish I probably try to port it to D2 and ask again.

Building Goldie's documentation (it uses a custom doc generator) using "makeDocs" might work: http://www.semitwist.com/goldiedocs/v0.3/Docs/Tools/GenDocs/ There's a number of places in it right now where it uses .dup to work around D1's lack of D2-style const. And with the default settings in the "makeDocs" script (it's just a one-liner), it does a fair amount of string-building via the concatenation operator. Yea, I need to optimize ;) On my (aging) system the whole thing currently takes 20 seconds to run. It does do a bit of file I/O though, I don't know if that would get in the way of what you're trying to measure. You'd have to install Goldie (and SemiTwist D Tools) first: http://www.semitwist.com/goldiedocs/v0.3/Docs/Install/

Thanks I'll see if it's not much trouble to install, I'd like to build a benchmark without tons of dependencies.
 I think people have generally been avoiding writing GC-intensive code in D 
 though. Although, come to think of it, bearophile could probably supply you 
 with some deliberately GC-intensive code specifically for benchmarking.

Yes, I borrowed some deliberately GC-intensive benchmarks done by him, most notably the voronoi generator[1], which made me sweat[2] more than once :) [1] http://codepad.org/xGDCS3KO [2] http://llucax.com.ar/blog/blog/post/-7a56a111 -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Be nice to nerds Chances are you'll end up working for one
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
bearophile, el  4 de agosto a las 16:25 me escribiste:
 Leandro Lucarella:
 Yes, I borrowed some deliberately GC-intensive benchmarks done by him,
 most notably the voronoi generator[1], which made me sweat[2] more than
 once :)

On my site you can find four other Olden benchmarks: em3d tsp bisort bh http://bit.ly/cYlQUe And I hope to add one or two more when time allows me to :-) Probably they are D2 code, but probably converting them to D1 is not hard. The versions fitter for you are the first ones translated from Java to D, because the optimized versions minimize the heap activity to increase performance (and the speed difference is usually large).

Thanks, that would be the xxx01.d I guess, right? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Qué sabía Galileo de astronomía, Mendieta! Lo que pasa es que en este país habla cualquiera. -- Inodoro Pereyra
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Robert Clipsham, el  4 de agosto a las 22:16 me escribiste:
 On 04/08/10 00:18, Leandro Lucarella wrote:
BCS, el  3 de agosto a las 16:04 me escribiste:
The video is up:

http://www.youtube.com/watch?v=RlVpPstLPEc

Nice talk, I think the guy that asked what is the biggest application written in D deserved a book. I'm suffering the lack of D applications for benchmarking the GC, I had to stay with D1 because Dil is the *only* non-trivial application written in D that I could find, and is D1/Tango.

I know of several large apps written in D, they're all D1/Tango.

Public? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Can you stand up? I do believe it's working, good. That'll keep you going through the show Come on it's time to go.
Aug 04 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 8/4/10, bearophile <bearophileHUGS lycos.com> wrote:
 I am sorry to say this, but I think porting the current back-end to 64 bit
 is a waste of time because it will not be used for professional usages. I
 think LLVM will be the main back-end for professional usages of D2

Get back to me when LDC starts to actually /work/. It is *completely unusable* in its current state and its developers don't seem to care. I don't understand what you see in it.
Aug 04 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--0016e64c26a4cb2cd7048d1595ff
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 5, 2010 at 5:38 PM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from awishformore (awishformore nospam.plz)'s article
 I'm a bit surprised, and positively so. The talk now has only less views
 than 2 videos of 2010 and I'm sure it will surpass these in due time,
 too.

Can you clarify this? Relative to what? All of YouTube (no way)? All Google Tech Talk videos?

I only see some 5k views on that video. And there are videos with over 100k views from the google tech talk channel. Maybe it's shown on his personal page which makes it look like its a top video of 2010. --0016e64c26a4cb2cd7048d1595ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 5:38 PM, dsimcha = <span dir=3D"ltr">&lt;<a href=3D"mailto:dsimcha yahoo.com">dsimcha yahoo.co= m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le= ft: 1ex;"> =3D=3D Quote from awishformore (awishformore nospam.plz)&#39;s article<br> <div class=3D"im">&gt; I&#39;m a bit surprised, and positively so. The talk= now has only less views<br> &gt; than 2 videos of 2010 and I&#39;m sure it will surpass these in due ti= me,<br> &gt; too.<br> <br> </div>Can you clarify this? =A0Relative to what? =A0All of YouTube (no way)= ? =A0All Google<br> Tech Talk videos?<br> </blockquote></div><br>I only see some 5k views on that video. And there ar= e videos with over 100k views from the google tech talk channel. Maybe it&#= 39;s shown on his personal page which makes it look like its a top video of= 2010.<br> --0016e64c26a4cb2cd7048d1595ff--
Aug 05 2010
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--0016367fabb122adff048d16e2e7
Content-Type: text/plain; charset=ISO-8859-1

It might be becoming a niche language for smaller to medium-sized projects.
But it's being used in a host of big applications, from games to game tools,
3D tools, audio tools, compilers, front ends and back ends to just about
everything. I don't think many of these will be ported to a different
language (such as D) unless absolutely necessary. For those big projects C++
isn't going anywhere any time soon.

On Thu, Aug 5, 2010 at 6:45 PM, bearophile <bearophileHUGS lycos.com> wrote:

 C++ is slowly becoming a niche language, but it's a large niche still, and
 it's years that people try to look for something better. But even if no new
 features are added to D2 for some time, I think it will take something like
 two more years to have a language+compiler good enough for serious purposes.

 Bye,
 bearophile

--0016367fabb122adff048d16e2e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It might be becoming a niche language for smaller to medium-sized projects.= But it&#39;s being used in a host of big applications, from games to game = tools, 3D tools, audio tools, compilers, front ends and back ends to just a= bout everything. I don&#39;t think many of these will be ported to a differ= ent language (such as D) unless absolutely necessary. For those big project= s C++ isn&#39;t going anywhere any time soon.<br> <br><div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 6:45 PM, bearophile <= span dir=3D"ltr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophile= HUGS lycos.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204= ); padding-left: 1ex;"> C++ is slowly becoming a niche language, but it&#39;s a large niche still, = and it&#39;s years that people try to look for something better. But even i= f no new features are added to D2 for some time, I think it will take somet= hing like two more years to have a language+compiler good enough for seriou= s purposes.<br> <br> Bye,<br> <font color=3D"#888888">bearophile<br> </font></blockquote></div><br> --0016367fabb122adff048d16e2e7--
Aug 05 2010
parent BCS <none anon.com> writes:
Hello Andrej,

 It might be becoming a niche language for smaller to medium-sized
 projects. But it's being used in a host of big applications, from
 games to game tools, 3D tools, audio tools, compilers, front ends and
 back ends to just about everything. I don't think many of these will
 be ported to a different language (such as D) unless absolutely
 necessary. For those big projects C++ isn't going anywhere any time
 soon.
 

Even if that's true, eventually those programs will be replace with clean-slate replacements. -- ... <IXOYE><
Aug 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 04 Aug 2010 20:22:09 -0500, Andrei Alexandrescu wrote:

 On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
 On 08/04/2010 05:16 PM, Robert Clipsham wrote:
 I know of several large apps written in D, they're all D1/Tango.

The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2. People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.

Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.

Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is * managing the communication with the user community * managing the communication with the language/compiler developers * managing the bugfixes to the spec * managing the compiler bugfix release (minor version) process * managing the language development debate * coordinating the future language development (roadmap page of the trac) * managing the public relations with the people outside the core community It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.
Aug 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Thu, 05 Aug 2010 13:31:18 -0500, Andrei Alexandrescu wrote:

 On 08/05/2010 01:23 PM, retard wrote:
 Wed, 04 Aug 2010 20:22:09 -0500, Andrei Alexandrescu wrote:

 On 08/04/2010 07:25 PM, Jeff Nowakowski wrote:
 On 08/04/2010 05:16 PM, Robert Clipsham wrote:
 I know of several large apps written in D, they're all D1/Tango.

The incomplete state of D2 has to be the most embarrassing question that could have been asked at Andrei's talk, but then you'd have to be familiar with D to ask that question. Andrei likes to talk about presentations showing only what's good, but he gave a whole talk about an incomplete language while hawking his book for said language, but made no mention of D1 vs D2. People often ask for a status, but there never seems to be good answers. Where's the roadmap? What's being worked on? What's left to fix? Is there a release date that's being worked towards? It used to coincide with the release of Andrei's book, but that has come and gone.

Walter is more silent than usual because he's working very hard on the 64-bit compiler. He hopes to have one by the end of this month. His next big goal is shared library support.

Ok, Walter is working on a 64-bit compiler, then on the shared library support. That's great. But many of us would like to know who is * managing the communication with the user community * managing the communication with the language/compiler developers * managing the bugfixes to the spec * managing the compiler bugfix release (minor version) process * managing the language development debate * coordinating the future language development (roadmap page of the trac) * managing the public relations with the people outside the core community It seems Walter wants to be a lonely wolf. Nobody else is allowed to do anything listed above unless you're Andrei. There are no managers, we only have experts working with their favorite features and no communication exists between these persons or the community.

I think this is a gross misrepresentation. Are you sure you're not forgetting a lot of contributors? If anything, the trend is toward opening the doors to more, not less people.

I understood that all the contributors are waiting for the decision of a single person. Walter needs to review all compiler patches, he needs to review all patches to the spec, he needs to defend D on reddit, newsgroups, and all other forums. He handles the whole release process. He doesn't tell anything about future directions so nobody knows about them. The management model doesn't scale when you get more and more contributors. At some point Walter won't have enough time to review all contributions even if it didn't do anything else. For example now that he is focusing on 64-bit support, all discussion about rewriting the spec, fixing bugs, improving the other parts of the toolchain, or developing the language further (D 2.1 or 3.0) has stalled. Many people have asked bearophile to stop discussing new language features because it takes away too much valuable time from Walter. Something is wrong here.
Aug 05 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Thu, 05 Aug 2010 11:41:58 -0700, Walter Bright wrote:

 retard wrote:
 Ok, Walter is working on a 64-bit compiler, then on the shared library
 support. That's great. But many of us would like to know who is
 
  * managing the communication with the user community * managing the
  communication with the language/compiler developers * managing the
  bugfixes to the spec
  * managing the compiler bugfix release (minor version) process *
  managing the language development debate * coordinating the future
  language development (roadmap page of the trac) * managing the public
  relations with the people outside the core
 community
 
 It seems Walter wants to be a lonely wolf. Nobody else is allowed to do
 anything listed above unless you're Andrei. There are no managers, we
 only have experts working with their favorite features and no
 communication exists between these persons or the community.

There are quite a few people actively contributing to all of the above. Perhaps you don't monitor the D mailing lists where a lot of this activity is going on. If there's a particular one you want to contribute to, you're welcome to join us.

I'd like to design D 3.0 features and the new LLVM based compiler with bearophile and fill the roadmap page in the trac page. Is that ok? How can I start?
Aug 05 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--0016e6d588b94d2a62048d18d2b9
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 5, 2010 at 9:37 PM, Walter Bright <newshound2 digitalmars.com>wrote:

 Me: compiler
 Sean: druntime
 Brad Roberts: bugzilla, mailing lists, D test suite
 Brad Anderson: D source code repository
 Jan Knepper: site hosting
 Several people: Phobos (generally under Andrei's leadership)
 Helmut Leitner: D wiki
 Andrei: build master (coming soon!)

 Of course, LDC, GDC, Tango, Dil, and all the other libraries and tools,
 etc., are all led by their various self-selected groups, not me.

Who is working on the D spec documentation, if anyone? I know Andrei and others work on the Phobos docs, but what about the D docs? --0016e6d588b94d2a62048d18d2b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 9:37 PM, Walter Bright <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound= 2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, = 204); padding-left: 1ex;"> <br> Me: compiler<br> Sean: druntime<br> Brad Roberts: bugzilla, mailing lists, D test suite<br> Brad Anderson: D source code repository<br> Jan Knepper: site hosting<br> Several people: Phobos (generally under Andrei&#39;s leadership)<br> Helmut Leitner: D wiki<br> Andrei: build master (coming soon!)<br> <br> Of course, LDC, GDC, Tango, Dil, and all the other libraries and tools, etc= ., are all led by their various self-selected groups, not me.<br> </blockquote></div><br>Who is working on the D spec documentation, if anyon= e? I know Andrei and others work on the Phobos docs, but what about the D d= ocs?<br> --0016e6d588b94d2a62048d18d2b9--
Aug 05 2010
prev sibling next sibling parent mwarning <moritzwarning web.de> writes:
On Wed, 04 Aug 2010 22:19:02 -0400, Adam Ruppe wrote:

 On 8/4/10, bearophile <bearophileHUGS lycos.com> wrote:
 I am sorry to say this, but I think porting the current back-end to 64
 bit is a waste of time because it will not be used for professional
 usages. I think LLVM will be the main back-end for professional usages
 of D2

Get back to me when LDC starts to actually /work/. It is *completely unusable* in its current state and its developers don't seem to care. I don't understand what you see in it.

LDC for llvm 2.7 doesn't have debug support because the LDC debug info code only works for llvm 2.6. I assume that's what you call unusable? There are bugs as well, sure. But nothing too serious from what I know about. LDC is developed on a personal by need/interest basis. Atm. the original developers don't have time or much interest in LDC. It's a volunteer effort from the beginning and everyone is invited to work on ldc.
Aug 05 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 8/5/10, mwarning <moritzwarning web.de> wrote:
  I assume that's what you call unusable?

I mean unusable in the literal sense: $ ./ldc ./ldc: error while loading shared libraries: libelf.so.0: cannot open shared object file: No such file or directory I hear it also doesn't do D2 at all, which is unacceptable, and that it doesn't do exceptions in Windows - thus meaning it doesn't work there at all for any real programs - which is unacceptable AND unforgivable. AFAIK, the Windows unusability is in LLVM itself. Honestly, I'd be surprised if there's a single person on the planet who uses a D LLVM compiler professionally today given its limitations. LDC is garbage, and that's all that actually exists. To abandon DMD for that is language suicide.
Aug 05 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--0016367fb69d3b4e7d048d1998fe
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 5, 2010 at 10:37 PM, Walter Bright
<newshound2 digitalmars.com>wrote:

 Andrej Mitrovic wrote:

 Who is working on the D spec documentation, if anyone? I know Andrei and
 others work on the Phobos docs, but what about the D docs?

The D docs are actually part of the Phobos under source control, and the people who work on the library have commit privileges for it. Although nobody has checked in any changes to it other than the changelog and some minor formatting stuff.

I've filed a bunch of reports in bugzilla, regarding the D2 documentation. I've also provided fixes for most of the issues I've found (but I haven't looked at *all* of the documentation yet). I'm hoping someone could have a look at these sooner or later and update the specs. :) --0016367fb69d3b4e7d048d1998fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 10:37 PM, Walter = Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">= newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(2= 04, 204, 204); padding-left: 1ex;"> <div class=3D"im">Andrej Mitrovic wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Who is working on the D spec documentation, if anyone? I know Andrei and ot= hers work on the Phobos docs, but what about the D docs?<br> </blockquote> <br></div> The D docs are actually part of the Phobos under source control, and the pe= ople who work on the library have commit privileges for it. Although nobody= has checked in any changes to it other than the changelog and some minor f= ormatting stuff.<br> </blockquote></div><br>I&#39;ve filed a bunch of reports in bugzilla, regar= ding the D2 documentation. I&#39;ve also provided fixes for most of the iss= ues I&#39;ve found (but I haven&#39;t looked at *all* of the documentation = yet). I&#39;m hoping someone could have a look at these sooner or later and= update the specs. :)<br> --0016367fb69d3b4e7d048d1998fe--
Aug 05 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--0016367fab0bbd6a85048d1a65f2
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 5, 2010 at 11:27 PM, Walter Bright
<newshound2 digitalmars.com>wrote:

 Andrei Alexandrescu wrote:

  Andrej Mitrovic wrote:
 I've filed a bunch of reports in bugzilla, regarding the D2
 documentation. I've also provided fixes for most of the issues I've found
 (but I haven't looked at *all* of the documentation yet). I'm hoping someone
 could have a look at these sooner or later and update the specs. :)

Andrej, I wanted to say for a while that I've been following and I appreciate your diligence in following through TDPL's examples and beyond, and then filing any bugs you find.

I agree. Thank you very much, Andrej!

Hey, you're welcome guys. Anything to help out D and the community. And I have to say Thanks to you two and the guys who helped me out in NG. --0016367fab0bbd6a85048d1a65f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 11:27 PM, Walter = Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" = target=3D"_blank">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><bloc= kquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-lef= t: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Andrei Alexandrescu wrote:<div><br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Andrej Mitrovic wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I&#39;ve filed a bunch of reports in bugzilla, regarding the D2 documentati= on. I&#39;ve also provided fixes for most of the issues I&#39;ve found (but= I haven&#39;t looked at *all* of the documentation yet). I&#39;m hoping so= meone could have a look at these sooner or later and update the specs. :)<b= r> </blockquote> <br> Andrej,<br> <br> I wanted to say for a while that I&#39;ve been following and I appreciate y= our diligence in following through TDPL&#39;s examples and beyond, and then= filing any bugs you find.<br> </blockquote> <br></div> I agree. Thank you very much, Andrej!<br> </blockquote></div><br>Hey, you&#39;re welcome guys. Anything to help out D= and the community. And I have to say Thanks to you two and the guys who he= lped me out in NG.<br> --0016367fab0bbd6a85048d1a65f2--
Aug 05 2010
prev sibling next sibling parent mwarning <moritzwarning web.de> writes:
On Thu, 05 Aug 2010 16:39:19 -0400, Adam Ruppe wrote:

 On 8/5/10, mwarning <moritzwarning web.de> wrote:
  I assume that's what you call unusable?

I mean unusable in the literal sense: $ ./ldc ./ldc: error while loading shared libraries: libelf.so.0: cannot open shared object file: No such file or directory

 
 I hear it also doesn't do D2 at all, which is unacceptable, and that it
 doesn't do exceptions in Windows - thus meaning it doesn't work there at
 all for any real programs - which is unacceptable AND unforgivable.

 AFAIK, the Windows unusability is in LLVM itself.

 Honestly, I'd be surprised if there's a single person on the planet who
 uses a D LLVM compiler professionally today given its limitations.

 LDC is garbage, and that's all that actually exists. To abandon DMD for 
 that is language suicide.

Aug 05 2010
prev sibling next sibling parent mwarning <moritzwarning web.de> writes:
On Thu, 05 Aug 2010 13:55:40 -0700, Walter Bright wrote:

 Adam Ruppe wrote:
 To abandon DMD for that is language suicide.

Well, one reason (certainly not the only one) I keep with the current dmd back end is that I don't need to spend time convincing some other organization to fix/improve/customize it for better D support. I can just get it done. Being in control of the toolchain has a lot of benefits. For example, look at gdb, and trying to get it to support D - not for the patches themselves, but getting them accepted into the standard gdb.

Thanks for the clarification. Imho, doing/checking everything already has taken years and will continue to take many years. I don't think it's a very viable concept.
Aug 05 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
On 8/5/10, mwarning <moritzwarning web.de> wrote:
 Google might help.

I know what it is, but I have /zero/ respect for people who shove their dependencies on me. It shouldn't be my problem. One of the reasons I went with Digital Mars early on is that DMC just works when you unzip it. DMD continues that tradition, and it is very nice. I'm spoiled.
Aug 05 2010
prev sibling next sibling parent mwarning <moritzwarning web.de> writes:
On Thu, 05 Aug 2010 19:29:05 -0400, Adam Ruppe wrote:

 On 8/5/10, mwarning <moritzwarning web.de> wrote:
 Google might help.

I know what it is, but I have /zero/ respect for people who shove their dependencies on me. It shouldn't be my problem.

But that happens and it's definitely not intentional (afaik). What file have you downloaded? What distribution you use?
 One of the reasons I went with Digital Mars early on is that DMC just
 works when you unzip it. DMD continues that tradition, and it is very
 nice.
 
 I'm spoiled.

Aug 05 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 05 Aug 2010 16:37:36 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Andrej Mitrovic wrote:
 Who is working on the D spec documentation, if anyone? I know Andrei  
 and others work on the Phobos docs, but what about the D docs?

The D docs are actually part of the Phobos under source control, and the people who work on the library have commit privileges for it. Although nobody has checked in any changes to it other than the changelog and some minor formatting stuff.

I just did (fixed a lot of stuff in the array page). A couple comments: 1. There is no guideline for updating the spec (at least that I could find). I deduced $(V1) and $(V2) and figured out what $(LNAME2) is, but lack of guidelines may be partially to blame for why few people edit it. 2. It seems like the documentation is HTML written as ddoc. I see $(P) tags, $(LI) tags, etc. Can't we just write it as HTML? I think many would feel much more comfortable that way. It's also more supported by editors. I forgot a closing parentheses on one tag, and it screwed up the entire page. I had to find it by hand, whereas an HTML editor could red-flag a tag without a closing tag, or you could run it through an XML verifier (if it's xhtml). -Steve
Aug 06 2010
prev sibling next sibling parent reply "Alexander Malakhov" <anm programmer.net> writes:
Steven Schveighoffer <schveiguy yahoo.com> =D0=C9=D3=C1=CC(=C1) =D7 =D3=D7=
=CF=A3=CD =D0=C9=D3=D8=CD=C5 Fri, 06  =

Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc.  I see $(P=

 tags, $(LI) tags, etc.   Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many  would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be = pretty straightforward
 It's also more supported by editors.  I forgot a closing parentheses o=

 one tag, and it screwed up the entire page.  I had to find it by hand,=

 whereas an HTML editor could red-flag a tag without a closing tag, or =

 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there wi= ll always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)?= I think there is (simple) solution, but that is one more thing to learn.= In the end it's just markup language and I don't see much use in learnin= g more then one of them. One reason of it I can think of: parsing speed and ambiguities (same as with <templates>) Anyway, when D will take over the world, they will have to change HTML syntax to fit what everyone already knows ) -- = Alexander
Aug 06 2010
parent BCS <none anon.com> writes:
Hello Alexander,

 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме
 Fri, 06  Aug 2010 18:28:41 +0700:
 
 2. It seems like the documentation is HTML written as ddoc.  I see
 $(P)  tags, $(LI) tags, etc.   Can't we just write it as HTML?
 


There are a few pieces that I'd like to see stay as customizable markup, the BNF rules for one because it would allow the rules to be run with a different set of macros and, for example, generate input to a parser generator. Once such a system is set up it would make it trivially easy to keep the docs and parser in sync. If people really don't like the current system and if an appropriate XSLT library could be found, then converting the current system to generate XML tags and run it through some XSLT pass should be just as powerful as what we have now but better supported by existing tools. -- ... <IXOYE><
Aug 07 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them.


 One reason of it I can think of: parsing speed and ambiguities (same as
 with <templates>)

 Anyway, when D will take over the world, they will have to change HTML
 syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros.

Does ddoc output in pdf? And besides, most of the tags *are* html tags, they're even the same tag name. I can't imagine there's no htmltopdf program that would do exactly that. Regarding the <span class="bold"> thing, can't you just do this in css: b { whatever; } and override what <b> does? There are probably macros which do other things that xhtml/css cannot do, but I don't think we should use macros for every html element. For example, the $(V1) and $(V2) tags. We need a good solution for that, and I think having dmd work those out is fine. I also don't mind using the macros for more dynamic stuff. I just think the formatting stuff can remain html, and all the macros should be defined/documented somewhere. I like this explanation from Alexander: In the end it's just markup language and I don't see much use in learning more then one of them. It's just a thought, it might be blowing out of proportion a bit. Granted I think I would have felt more comfortable using html directly, but it wasn't that hard to learn, and I was able to work through the issues. I just wish I had some editor help... -Steve
Aug 06 2010
prev sibling next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Fri, 06 Aug 2010 19:56:55 +0200, Johannes Pfau wrote:

 A simple html to pdf conversion might not produce good results. 

Converting *anything* to PDF might not produce good results. :) There's at least one excellent, open-source HTML-to-PDF converter: http://code.google.com/p/wkhtmltopdf/ There is also the very good Prince XML, which is free for non-commercial use: http://princexml.com/
 in the long term something like http://sphinx.pocoo.org together with
 ReStructuredText might be the best solution (for general
 documentation, not for api documentation though). But the initial
 effort to 'port' the existing documentation is quite high.

That would just introduce a different markup language that someone will have to learn. I like ReST and have used it extensively -- but why not Markdown, or MediaWiki Markup, or Texinfo, or etc. ad nauseum? Meanwhile, the intial effort to 'port' the existing documentation to HTML is zero. :) Best, Graham
Aug 06 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Aug 2010 14:26:48 -0400, Don <nospam nospam.com> wrote:

 Steven Schveighoffer wrote:
  Does ddoc output in pdf?  And besides, most of the tags *are* html  
 tags, they're even the same tag name.  I can't imagine there's no  
 htmltopdf program that would do exactly that.

The reason they're the same is that the docs were originally written in html. The original conversion to ddoc was done via search and replace. One of the HUGE benefits of ddoc is that it does highlighting of the D code. That instantly saved Walter a lot of time. Seriously, converting it to ddoc did improve productivity.

Oh, I totally agree for the code samples. And some of the other macros like $(V1). But the manual markup, like marking every paragraph like this: $(P This is some text that is in a paragraph, and for some reason, we need a special tag for it instead of using &lt;p&gt;, one that is hard to find the closing tag for, because every tag's closing tag is simply a lone close parentheses like this:) doesn't really make much difference than using <p>...</p>. The advantage of using html tags for formatting like this means editors will recognize tags, and everyone and their mother knows what html tags look like. -Steve
Aug 06 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Aug 2010 15:02:26 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 06 Aug 2010 11:48:00 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2010-08-06 17:41, Alexander Malakhov wrote:
 Steven Schveighoffer <schveiguy yahoo.com> писал(а) в своём
письме  
 Fri,
 06 Aug 2010 18:28:41 +0700:

 2. It seems like the documentation is HTML written as ddoc. I see  
 $(P)
 tags, $(LI) tags, etc. Can't we just write it as HTML?

I have had exactly same thought when I've first seen DDoc a week ago
 I think many would feel much more comfortable that way.

I have virtually zero exp with HTML/XML, but DDocs syntax seems to be pretty straightforward
 It's also more supported by editors. I forgot a closing parentheses  
 on
 one tag, and it screwed up the entire page. I had to find it by hand,
 whereas an HTML editor could red-flag a tag without a closing tag, or
 you could run it through an XML verifier (if it's xhtml).

Good points. And XML is not going to disappear anytime soon, so there will always be a lot of people familiar with it, as wall as tool for it. So I think it would be reasonable to have <tag/> syntax and HTML tags like <B>, <I> etc. Also, for example, what if I want to put extra ')' paren into $(D text)? I think there is (simple) solution, but that is one more thing to learn. In the end it's just markup language and I don't see much use in learning more then one of them.


 One reason of it I can think of: parsing speed and ambiguities (same  
 as
 with <templates>)

 Anyway, when D will take over the world, they will have to change HTML
 syntax to fit what everyone already knows )

One reason is why HTML is not used directly is that you could output the documentation in other formats than HTML, like PDF. A second reason to use macros (i.e. $(B arg)) instead of HTML is that this allows you to have the macro expand into something like this <span class="bold">arg</span> instead of <b>arg<b>. Of course one could define a language in XML to use instead of the macros.


I have an experimental std.ddoc that generates TeX. I understand your arguments - they're pretty much echoing those of myself and of Janice Caron when we first saw the Phobos docs. It didn't take me a long time to appreciate ddoc. Right now I'm considering converting my entire website to use ddoc. HTML is a pile of dung to actually write text in, and somehow I always up editing the raw HTML no matter how much editors are trying to hide it from me.

Heh. by editor I meant vim :) I meant syntax highlighting, and matching tags, not something like frontpage. I wouldn't mind the current docs, but I'd like to have some document to know what tags are defined and what they mean (like a ddocdoc), and how to define new tags. Maybe this already exists? The one issue I had is that closing tags are hard to spot. When I edited the arrays.dd file, first vim refused to do any syntax highlighting, so everything was black and white (horror!). Second, while adding anchors to all the headers (which by the way are still in html), I missed one closing parentheses. So ddoc decided to match the global closing $(D_SPEC tag with the opening $(LNAME2 tag I forgot to close. The result was no menu appeared on the left. A proper html editor (not wysiwyg) would have highlighted tags, and flagged the missing <a> closing tag if I had done the anchors that way. I'm not saying html is the end-all of the docs, I think we need some sort of macro system. But perhaps we can use an already-existing one instead of ddoc.
 So how about this - give it a while and it's not impossible that your  
 view might change.

I don't plan on writing tons of standalone ddoc documentation :) I generally just comment my functions and let ddoc take care of the generation. For documenting code, I think ddoc is great. But the spec is not code. It contains code snipits, and I think ddoc is great for those, but simply spitting out a bullet list is handled just fine by html or some other standard markup language. -Steve
Aug 06 2010
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--0016e6d7eeb478ba60048d2e161a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 6, 2010 at 21:02, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 I have an experimental std.ddoc that generates TeX.

From a 'pure ddoc' file or from a .d file?

Would it allow (theoretically) for literate programming? weave("file.ld"); // creates file.tex tangle("file.ld"); // creates file.d
 I understand your arguments - they're pretty much echoing those of myself
 and of Janice Caron when we first saw the Phobos docs. It didn't take me a
 long time to appreciate ddoc. Right now I'm considering converting my entire
 website to use ddoc. HTML is a pile of dung to actually write text in, and
 somehow I always up editing the raw HTML no matter how much editors are
 trying to hide it from me.

 So how about this - give it a while and it's not impossible that your view
 might change.

I still would like DDoc to allow for some sectioning: /** section: sectionName some section comments. This section is all about fun and foo. */ // fun doc fun(); //foo doc foo(); /** section: next section,about bar and baz */ etc. But, as far as I understand it, right the comments are all associated to the next declaration. Philippe --0016e6d7eeb478ba60048d2e161a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote">On Fri, Aug 6, 2010 at 21:02, Andrei Alexand= rescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org= ">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class=3D"h5"><br></div></div> I have an experimental std.ddoc that generates TeX.<br></blockquote><div><b= r>From a &#39;pure ddoc&#39; file or from a .d file?<br>It transforms ddoc = mark-up into TeX mak-up?<br><br>Would it allow (theoretically) for literate= programming?<br> <br>weave(&quot;file.ld&quot;); // creates file.tex<br>tangle(&quot;file.ld= &quot;); // creates file.d<br><br>=A0</div><blockquote class=3D"gmail_quote= " style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, = 204); padding-left: 1ex;"> I understand your arguments - they&#39;re pretty much echoing those of myse= lf and of Janice Caron when we first saw the Phobos docs. It didn&#39;t tak= e me a long time to appreciate ddoc. Right now I&#39;m considering converti= ng my entire website to use ddoc. HTML is a pile of dung to actually write = text in, and somehow I always up editing the raw HTML no matter how much ed= itors are trying to hide it from me.<br> <br> So how about this - give it a while and it&#39;s not impossible that your v= iew might change.<br></blockquote><div><br>I still would like DDoc to allow= for some sectioning:<br><br>/**<br>section: sectionName<br>some section co= mments. This section is all about fun and foo.<br> */<br><br>// fun doc<br>fun();<br><br>//foo doc<br>foo();<br><br>/**<br>sec= tion: next section,about bar and baz<br>*/<br>etc.<br><br>But, as far as I = understand it, right the comments are all associated to the next declaratio= n.<br> <br>Philippe<br><br></div></div> --0016e6d7eeb478ba60048d2e161a--
Aug 06 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--e0cb4e887453fe726a048d2f6978
Content-Type: text/plain; charset=ISO-8859-1

This is the same method used in some text editors (e.g. Scite uses this
exact same method for variables, $() ).

2010/8/7 Walter Bright <newshound2 digitalmars.com>

 Alexander Malakhov wrote:

 Also, for example, what if I want to put extra ')' paren into $(D text)?
 I think there is (simple) solution, but that is one more thing to learn.

RPAREN=) $(D text $(RPAREN) ) You'll see a few of those in the macros, in particular $(DOLLAR) to embed a dollar sign. It's not so bad, every markup language needs an escape method.

--e0cb4e887453fe726a048d2f6978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is the same method used in some text editors (e.g. Scite uses this exa= ct same method for variables, $() ).<br><br><div class=3D"gmail_quote">2010= /8/7 Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digit= almars.com">newshound2 digitalmars.com</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"im"=
Alexander Malakhov wrote:<br>

r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Also, for example, what if I want to put extra &#39;)&#39; paren into $(D t= ext)?<br> I think there is (simple) solution, but that is one more thing to learn.<br=

<br></div> =A0RPAREN=3D)<br> <br> =A0$(D text $(RPAREN) )<br> <br> You&#39;ll see a few of those in the macros, in particular $(DOLLAR) to emb= ed a dollar sign. It&#39;s not so bad, every markup language needs an escap= e method.<br> </blockquote></div><br> --e0cb4e887453fe726a048d2f6978--
Aug 06 2010
prev sibling next sibling parent mwarning <moritzwarning web.de> writes:
On Thu, 05 Aug 2010 22:34:34 +0000, mwarning wrote:

 On Thu, 05 Aug 2010 13:55:40 -0700, Walter Bright wrote:
 
 Adam Ruppe wrote:
 To abandon DMD for that is language suicide.

Well, one reason (certainly not the only one) I keep with the current dmd back end is that I don't need to spend time convincing some other organization to fix/improve/customize it for better D support. I can just get it done. Being in control of the toolchain has a lot of benefits. For example, look at gdb, and trying to get it to support D - not for the patches themselves, but getting them accepted into the standard gdb.

Thanks for the clarification. Imho, doing/checking everything already has taken years and will continue to take many years. I don't think it's a very viable concept.

.. but I hope it works out well. :)
Aug 06 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday, August 06, 2010 15:54:51 Walter Bright wrote:
 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very
 hard to read.

Note to self: Don't go anywhere near Walter when he's reading HTML. - Jonathan M Davis
Aug 06 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sat, 07 Aug 2010 04:36:27 -0500, Mafi <mafi example.org> wrote:

 Am 07.08.2010 06:39, schrieb Nick Sabalausky:
 (...)
 I use Programmer's Notepad 2 which does parenthesis-matching  
 out-of-the-box.

isn't a full-featured IDE but it's a great editor for programming, isn't it.

I use it too. In fact, it was thanks to Nick that I learned about PN2. He commented something about it few months ago (or several, I don't remember), here in the NG, and I gave it a try. Now it's what I use for my D2 programming.
Aug 07 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Aug 2010 18:54:51 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Don wrote:
 The reason they're the same is that the docs were originally written in  
 html. The original conversion to ddoc was done via search and replace.
 One of the HUGE benefits of ddoc is that it does highlighting of the D  
 code. That instantly saved Walter a lot of time.
 Seriously, converting it to ddoc did improve productivity.

Here's what it has done, and this is real live experience because they were originally 100% html: 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it. 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output. 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway. 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them. 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before. 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros. 7. I can update URLs across the site trivially, such as if bugzilla changes its URL. 8. As Don mentioned, it will automagically syntax highlight D code. 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher). 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.

First, for 5 and 6, that is what CSS is for. Second, I agree with all your other points (except for the eye bleeding thing). But I find the tagging for just formatting (such as $(P, $(B $(TT) very hard to read and hard to diagnose. It looks to me like writing D code like this: mixin("int i = 1;"); mixin("i += 2;"); instead of this: int i = 1; i += 2; Sure, the mixins are dynamic, but you are not using them in a dynamic way... Wouldn't it be better to just write html when that's all your asking ddoc to do? Or does the risk of blindness dissuade you too much? FWIW, I work with HTML, CSS, php, and smarty templates every day. I understand the value of dynamic content, but I don't use dynamic techniques to generate static content, that's written in good old html. -Steve -Steve
Aug 07 2010
parent BCS <none anon.com> writes:
Hello Steven,

 Wouldn't it be better to just write html when that's all your asking
 ddoc  to do?  Or does the risk of blindness dissuade you too much?

What about the point (brought up else where) about being able to also generate *non* HTML from the same source? OTOH, I agree that HTML as macros has it's flaws, how about if they were switched to something a bit more high level, something that indicates what it is doing not how it should be done?
Aug 07 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
--0016363107893a3418048d53294b
Content-Type: text/plain; charset=ISO-8859-1

Hehe, actually there's a way to disable the CTRL+Tab behavior in C::B and
let Scintilla handle it the default way. Which is what I did, but then I
uncovered a bug where C::B would crash if I were using CTRL+Tab while the
text editor was not active. I'm still waiting for a better patch for D
support in C::B, or I'll have to get off my lazy bum and configure
everything manually.

On Sun, Aug 8, 2010 at 5:36 AM, Nick Sabalausky <a a.a> wrote:

 "Mafi" <mafi example.org> wrote in message
 news:i3j9el$5m7$1 digitalmars.com...
 Am 07.08.2010 06:39, schrieb Nick Sabalausky:
 (...)
 I use Programmer's Notepad 2 which does parenthesis-matching
 out-of-the-box.

a full-featured IDE but it's a great editor for programming, isn't it.

There are a number of things I would definitely like to see added/improved: http://code.google.com/p/pnotepad/issues/list?can=1&q=reporter%3Ansetbtgnws But those are generally fairly minor things, and a number of them I think are really more scintilla than PN2 (PN2 uses the scintilla text-edit control). So yea, overall I've been very happy with it, much more than any other editor I've tried. Doesn't have the sluggishness and bloat of VS.NET and Eclipse (doesn't have all the bells and whistles of Eclipse, but I can live without bells and whistles, especially if I'm not using Java). Doesn't have the strange "10% CPU usage while idle" or long start-up time or non-MRU-based ctrl-tab system that C::B has, or C::B's insistence on always trying to open HTML in a WYSIWYG instead of text-mode. Doesn't do the weird "EOL isn't treated as EOL" behavior some other editors do. Doesn't require tons of configuration. Highlights D out-of-the-box (and *not* by pretending it's C/C++). And it does all the basics I need, like basic project support, external command-line tools, customizable cmd-line-tool output parsing for jump-to-file/line/position, keyboard commands for comment/indent/unindent, find in files, show/hide whitespace and/or EOL markers, tabs <-> spaces, doesn't try to use any weird skins, doesn't waste UI space, doesn't have "invisible-text-syndrome", etc.

--0016363107893a3418048d53294b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hehe, actually there&#39;s a way to disable the CTRL+Tab behavior in C::B a= nd let Scintilla handle it the default way. Which is what I did, but then I= uncovered a bug where C::B would crash if I were using CTRL+Tab while the = text editor was not active. I&#39;m still waiting for a better patch for D = support in C::B, or I&#39;ll have to get off my lazy bum and configure ever= ything manually. <br> <br><div class=3D"gmail_quote">On Sun, Aug 8, 2010 at 5:36 AM, Nick Sabalau= sky <span dir=3D"ltr">&lt;a a.a&gt;</span> wrote:<br><blockquote class=3D"g= mail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(= 204, 204, 204); padding-left: 1ex;"> &quot;Mafi&quot; &lt;<a href=3D"mailto:mafi example.org">mafi example.org</= a>&gt; wrote in message<br> news:i3j9el$5m7$1 digitalmars.com...<br> <div><div></div><div class=3D"h5">&gt; Am 07.08.2010 06:39, schrieb Nick Sa= balausky:<br> &gt; (...)<br> &gt;&gt;<br> &gt;&gt; I use Programmer&#39;s Notepad 2 which does parenthesis-matching<b= r> &gt;&gt; out-of-the-box.<br> &gt;&gt;<br> &gt;&gt;<br> &gt; Hey, you are the first person I heard of that also uses PN2 :) . It is= n&#39;t<br> &gt; a full-featured IDE but it&#39;s a great editor for programming, isn&#= 39;t it.<br> <br> </div></div>There are a number of things I would definitely like to see add= ed/improved:<br> <a href=3D"http://code.google.com/p/pnotepad/issues/list?can=3D1&;q=3Dre= porter%3Ansetbtgnws" target=3D"_blank">http://code.google.com/p/pnotepad/is= sues/list?can=3D1&amp;q=3Dreporter%3Ansetbtgnws</a><br> <br> But those are generally fairly minor things, and a number of them I think<b= r> are really more scintilla than PN2 (PN2 uses the scintilla text-edit<br> control).<br> <br> So yea, overall I&#39;ve been very happy with it, much more than any other<= br> editor I&#39;ve tried. Doesn&#39;t have the sluggishness and bloat of <a hr= ef=3D"http://VS.NET" target=3D"_blank">VS.NET</a> and<br> Eclipse (doesn&#39;t have all the bells and whistles of Eclipse, but I can = live<br> without bells and whistles, especially if I&#39;m not using Java). Doesn&#3= 9;t have<br> the strange &quot;10% CPU usage while idle&quot; or long start-up time or<b= r> non-MRU-based ctrl-tab system that C::B has, or C::B&#39;s insistence on al= ways<br> trying to open HTML in a WYSIWYG instead of text-mode. Doesn&#39;t do the w= eird<br> &quot;EOL isn&#39;t treated as EOL&quot; behavior some other editors do. Do= esn&#39;t require<br> tons of configuration. Highlights D out-of-the-box (and *not* by pretending= <br> it&#39;s C/C++). And it does all the basics I need, like basic project supp= ort,<br> external command-line tools, customizable cmd-line-tool output parsing for<= br> jump-to-file/line/position, keyboard commands for comment/indent/unindent,<= br> find in files, show/hide whitespace and/or EOL markers, tabs &lt;-&gt; spac= es,<br> doesn&#39;t try to use any weird skins, doesn&#39;t waste UI space, doesn&#= 39;t have<br> &quot;invisible-text-syndrome&quot;, etc.<br> <br> <br> </blockquote></div><br> --0016363107893a3418048d53294b--
Aug 08 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 08 Aug 2010 00:26:42 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 Wouldn't it be better to just write html when that's all your asking  
 ddoc to do?

As I mentioned, I've tried it that way, and ddoc makes me 2 or even 3 times more productive doing it.

You're not getting what I'm saying, so I'll just stop :) Thanks for trying. -Steve
Aug 09 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 07 Aug 2010 16:54:03 +0200, Jacob Carlborg wrote:

 On 2010-08-07 00:54, Walter Bright wrote:
 Don wrote:
 The reason they're the same is that the docs were originally written
 in html. The original conversion to ddoc was done via search and
 replace. One of the HUGE benefits of ddoc is that it does highlighting
 of the D code. That instantly saved Walter a lot of time. Seriously,
 converting it to ddoc did improve productivity.

Here's what it has done, and this is real live experience because they were originally 100% html: 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it. 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output. 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway. 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them. 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before. 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros. 7. I can update URLs across the site trivially, such as if bugzilla changes its URL. 8. As Don mentioned, it will automagically syntax highlight D code. 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher). 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.

I think for any serious HTML work you need a server side language to help you.

Comparing hand-written html to ddoc is a bit unfair. I've used several CMS and template systems. They even have good support for D. My experiences tell me that 1. ddoc has worse productivity than real document generators such as doxygen or good cms/markup/web template systems. 2. these other systems also support commenting out stuff 3. these other systems also support generating correct, conforming HTML/ XML/TeX/PDF/MAN/whatever. With ddoc you need to use some semi-official templates you need to dig from the newsgroup archives. Doxygen provides all this by default. How is that bad for productivity? 4. these other systems also support conditional compilation 5-6. these other systems also support separating the style/layout from the structure. 7. ditto (and it's better than what ddoc produces by default) 8. ditto (and it's better than what ddoc produces). ddoc doesn't extract all components of symbol signatures in a structured way. 9. ditto 10. the other systems look better than ddoc So overall the other systems are much better and I also think I could write something 10 times better than ddoc in 2..7 days if someone would give me an untainted GPL licensed frontend that didn't look so butt ugly.
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
You are just becoming a parody of yourself.

Keep trying, though.

On Sat, 14 Aug 2010 15:06:04 -0500, retard <re tard.com.invalid> wrote:

 Sat, 07 Aug 2010 16:54:03 +0200, Jacob Carlborg wrote:

 On 2010-08-07 00:54, Walter Bright wrote:
 Don wrote:
 The reason they're the same is that the docs were originally written
 in html. The original conversion to ddoc was done via search and
 replace. One of the HUGE benefits of ddoc is that it does highlighting
 of the D code. That instantly saved Walter a lot of time. Seriously,
 converting it to ddoc did improve productivity.

Here's what it has done, and this is real live experience because they were originally 100% html: 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it. 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output. 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway. 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them. 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before. 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros. 7. I can update URLs across the site trivially, such as if bugzilla changes its URL. 8. As Don mentioned, it will automagically syntax highlight D code. 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher). 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.

I think for any serious HTML work you need a server side language to help you.

Comparing hand-written html to ddoc is a bit unfair. I've used several CMS and template systems. They even have good support for D. My experiences tell me that 1. ddoc has worse productivity than real document generators such as doxygen or good cms/markup/web template systems. 2. these other systems also support commenting out stuff 3. these other systems also support generating correct, conforming HTML/ XML/TeX/PDF/MAN/whatever. With ddoc you need to use some semi-official templates you need to dig from the newsgroup archives. Doxygen provides all this by default. How is that bad for productivity? 4. these other systems also support conditional compilation 5-6. these other systems also support separating the style/layout from the structure. 7. ditto (and it's better than what ddoc produces by default) 8. ditto (and it's better than what ddoc produces). ddoc doesn't extract all components of symbol signatures in a structured way. 9. ditto 10. the other systems look better than ddoc So overall the other systems are much better and I also think I could write something 10 times better than ddoc in 2..7 days if someone would give me an untainted GPL licensed frontend that didn't look so butt ugly.

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Aug 14 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Saturday 14 August 2010 13:06:04 retard wrote:
 Comparing hand-written html to ddoc is a bit unfair. I've used several
 CMS and template systems. They even have good support for D. My
 experiences tell me that
 
 1. ddoc has worse productivity than real document generators such as
 doxygen or good cms/markup/web template systems.
 
 2. these other systems also support commenting out stuff
 
 3. these other systems also support generating correct, conforming HTML/
 XML/TeX/PDF/MAN/whatever. With ddoc you need to use some semi-official
 templates you need to dig from the newsgroup archives. Doxygen provides
 all this by default. How is that bad for productivity?
 
 4. these other systems also support conditional compilation
 
 5-6. these other systems also support separating the style/layout from
 the structure.
 
 7. ditto (and it's better than what ddoc produces by default)
 
 8. ditto (and it's better than what ddoc produces). ddoc doesn't extract
 all components of symbol signatures in a structured way.
 
 9. ditto
 
 10. the other systems look better than ddoc
 
 So overall the other systems are much better and I also think I could
 write something 10 times better than ddoc in 2..7 days if someone would
 give me an untainted GPL licensed frontend that didn't look so butt ugly.

It's quite possible that other documentation generators are better than ddoc, but to some extent, that's not the point. ddoc is supposed to be simple and always available with the D compiler so that there is always a doc generator which you can count on. By having it included with the compiler, it encourages people to actually write documentation and generate it. People who actually care about writing good documentation anyway and are looking for powerful doc generators can easily use more powerful doc generators such as doxygen. Whether ddoc exists or not has no effect on that. So, I don't think that there's really much reason to harp on ddoc. If there are improvements which can be made to it without making it more complex or harder to use, then I'm sure that Walter is open to them (especially if they make it simpler and/or _easier_ to use). But it's not meant to be the end all and be all of doc generators. It's meant to be a basic, simple tool that you can count on being there. If you want fancier, more powerful doc generation, you're free to use 3rd party doc generators like doxygen. - Jonathan M Davis
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sat, 14 Aug 2010 20:20:49 -0500, Mike Parker <aldacron gmail.com> wrote:

 What prevents you from contributing to the frontend under its current  
 license?

Apparently he doesn't like butt-ugly frontends. That's the game breaker for him :| -- Yao G.
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sat, 14 Aug 2010 20:32:18 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 Yao G. Wrote:

 You are just becoming a parody of yourself.

Everyone deserves respect when expresses opinions honestly and in an civil way, even when the ideas are wrong. Bye, bearophile

Civil way? Really? But you are right about the freedom to express opinions. -- Yao G.
Aug 14 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 14 Aug 2010 21:32:18 -0400, bearophile wrote:

 Yao G. Wrote:
 
 You are just becoming a parody of yourself.

Everyone deserves respect when expresses opinions honestly and in an civil way, even when the ideas are wrong.

I just made some arguments against using ddoc since in my opinion it provides lower productivity than the competing tools. There are perfectly valid reasons to not use it. These are my opinions: - the markup/macro syntax is NIH new. It might be simpler for Walter to improve on, but a user i) has to learn yet another new syntax (it's quite likely that a developer already knows html/xml or javadoc/doxygen style or something like markdown) and ii) the user has to adapt to changes because the functionality is very primitive and users expect more features as the user base grows. This is a real issue if the project grows beyond say 5000 LOC. The managers/users of the documented project might expect features such as a TOC or inter-module hyperlinks. - the existing ddoc documents encourage writing in "html 3.2 optimized" way. Other document generators try to provide a generic interface with documentation syntax that improves the readability of the source code. As a result, doxygen generates all kinds of documentation output, but ddoc is mostly used to produce html pages. The candydoc system with its terrible javascript hangs many older workstations. The same functionality is better achieved with a more complete document generator. - the simple utility looks intriguing at first, however it doesn't scale much up. You might wish for new features/bugfixes, but the tool has very low priority. You can check the commit history - nothing revolutionary happens usually. Also, contributing new code to the toolchain requires an order of magnitude more effort than learning some other document generator. That probably explains why ddoc development is so dead. Someone might ask, why I don't contribute or use ddoc. I have my custom made filters for .d files and I use doxygen. Works just fine. On web pages I use a template engine with syntax highlighting support. These system also support D just fine nowadays. This way I've maximized my productivity. I can use the same documentation tool for C/C++/Java/C#/D projects. No need to learn new syntax.
 It's meant to be a basic, simple tool that you can count on being
 there. If you want fancier, more powerful doc generation, you're free
 to use 3rd party doc generators like doxygen.

The default toolchain creates a certain kind of ecosystem. Ddoc encourages amateurish hobbyist project look and feel. It can't even compete with javadoc or rdoc feature-wise. Comparing with C or C++ here is moot, because those languages were invented more or less before these kind of document generators even existed. Usually the larger projects count on tools being there. But it sounds weird to encourage the use of primitive ddoc in those projects.
Aug 14 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 14 Aug 2010 20:24:33 -0500, Yao G. wrote:

 On Sat, 14 Aug 2010 20:20:49 -0500, Mike Parker <aldacron gmail.com>
 wrote:
 
 
 What prevents you from contributing to the frontend under its current
 license?

Apparently he doesn't like butt-ugly frontends. That's the game breaker for him :|

I'm using the same argumentation as Walter here. If I ever contributed code to the proprietary dmd, I would get sued by a group of lawyers when contributing code later to some other proprietary / open source compiler. Even seeing the code might taint my mind. Just like Walter refuses to read Tango's code to prevent license issues with Phobos. Dmd's code also has several problems. I don't think it supports multi- core CPUs very well when parsing files. The other issues are: forward reference bugs, lack of a good internal garbage collector (CTFE & templates), not well documented (I know nearly nothing about compiler implementation).
Aug 14 2010
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
To me, the biggest appeal of ddoc is that it doesn't require markup to
give good enough results. It's almost mindless to use.
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sat, 14 Aug 2010 21:18:19 -0500, retard <re tard.com.invalid> wrote:

 [snip]

Thanks for your informative post. I'm really glad that you don't use such primitive, butt-ugly tools like DDOC. -- Yao G.
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sat, 14 Aug 2010 21:30:28 -0500, retard <re tard.com.invalid> wrote:

 I'm using the same argumentation as Walter here. If I ever contributed
 code to the proprietary dmd, I would get sued by a group of lawyers when
 contributing code later to some other proprietary / open source compiler.
 Even seeing the code might taint my mind.

Huh?... The front end is GPLed, just stay away from the back end. The doc generator is in the former part. You are criticizing the doc generator right? How would yo be sued contributing to a GPLed code? Or are you just pulling a strawman? -- Yao G.
Aug 14 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 14 Aug 2010 21:33:30 -0500, Yao G. wrote:

 On Sat, 14 Aug 2010 21:18:19 -0500, retard <re tard.com.invalid> wrote:
 
 [snip]

Thanks for your informative post. I'm really glad that you don't use such primitive, butt-ugly tools like DDOC.

You don't need to use it either. Why do you think it's a personal attack if I'm evaluating some tool and don't see it fit for some part of the community? Do you think my opinions would have more value if I wrote under my real name? ''Yao G.'' is also too generic to disclose any identity using typical search engines. Even if I knew your real name, it would have zero value to me since it would still be some generic wise guy who disagreed but had actually really nothing to say.
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sat, 14 Aug 2010 21:51:45 -0500, retard <re tard.com.invalid> wrote:

 You don't need to use it either. Why do you think it's a personal attack
 if I'm evaluating some tool and don't see it fit for some part of the
 community? Do you think my opinions would have more value if I wrote
 under my real name? ''Yao G.'' is also too generic to disclose any
 identity using typical search engines. Even if I knew your real name, it
 would have zero value to me since it would still be some generic wise guy
 who disagreed but had actually really nothing to say.

I don't really care either way ''retard'' :) -- ''Yao G.'' the wise guy that disagreed and had really nothing to say.
Aug 14 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Saturday 14 August 2010 20:42:42 Ellis Peters wrote:
 Go away troll! Your just waisting our time. Go write some real world code
 and talk less shit. There's nothing to loose.
 
 DDOC is better than doxygen. We don't need to argue that here, because
 everyone is a fan of D. We know you're a Haskell fanboy so climb to your
 ivory tower and stay there. This newsgroups needs more practically minded
 people who value productivity.

Well, if he's being a troll, don't feed him. There's no need to respond so negatively. It will just feed the flames of any argument. While I do think that retard has a tendancy to be a troll sometimes, your response to him is nasty enough that plenty of people would think that _you_'re being a troll. Let's please try and keep things civil around here. - Jonathan M Davis
Aug 14 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sun, 15 Aug 2010 16:27:57 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 I'd like to know how the macro system is inadequate for generating  
 Latex, man, etc. format.

I'm attempting to generate DocBook 5.0 xml files using DDOC. I'll let you know what issues I find. -- Yao G.
Aug 15 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 03/08/2010 17:04, BCS wrote:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

That Sean in the red/orange shirt, that Andrei talked to, is that Sean Kelly? -- Bruno Medeiros - Software Engineer
Sep 20 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
Bruno Medeiros Wrote:

 On 03/08/2010 17:04, BCS wrote:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

That Sean in the red/orange shirt, that Andrei talked to, is that Sean Kelly?

Yeah.
Sep 20 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/09/2010 00:49, Sean Kelly wrote:
 Bruno Medeiros Wrote:

 On 03/08/2010 17:04, BCS wrote:
 The video is up:

 http://www.youtube.com/watch?v=RlVpPstLPEc

That Sean in the red/orange shirt, that Andrei talked to, is that Sean Kelly?

Yeah.

Interesting. You look young, and I thought you would be much older, for some reason. If you don't mind the silliness, can I ask your exact age? :) -- Bruno Medeiros - Software Engineer
Sep 23 2010