BCS <none anon.com> writes:

The video is up:

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

-- 
... <IXOYE><

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

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

(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

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

"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

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

Arth Lloyd Flores <floresarthlloyd gmail.com> writes:

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

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

-- 
-Arth

"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

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

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

"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

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.

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

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.

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"));

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.
 

 I wouldn't use this, at least without a sane default exception,

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

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.

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

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.

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

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?

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.

 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.

6g.

Andrei

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

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

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

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

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.

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

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

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

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.

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.
 

 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.

But it becomes a problem again if you have to jump to separate compilation

-- 
... <IXOYE><

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.

"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 )

"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

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

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

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

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

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

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?

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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.

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

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

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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

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

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

On reddit:

http://www.reddit.com/r/programming/comments/cx09f/google_tech_talk_andrei_alexandrescu_three_cool/

Good talk, Andrei!

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

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,

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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/

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.

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.

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

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

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.

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

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?

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.

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.

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.

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.

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

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

Google might help.

 
 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.

Yes, llvm doesn't support exception handling on windows.

 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.

There are.

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

O.o

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 )

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.

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.

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.

It shouldn't be the problem of the user, I agree.
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.

Yes you are ;)

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.

 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.

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.

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.
 

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

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

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.

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.

 can you please elaborate a bit?
 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.

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.

can you please elaborate a bit?
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

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

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.

 can you please elaborate a bit?
 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.


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.

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.

 can you please elaborate a bit?
 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.

 
 
 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!

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.

 can you please elaborate a bit?
 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 :)

I think it's fair to compare dmd against other PL projects (python, 
ruby, php etc.) How are those organized?

Andrei

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.

 can you please elaborate a bit?
 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

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?

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

"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

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"

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.

 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"

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.

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.

 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"

 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

"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

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?

"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

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…

"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

Russel Winder <russel russel.org.uk> writes:

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 =

=20
 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=

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

 =20
 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 =

=20
 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

"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

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.

"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

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.

"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

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.

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

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

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 

government about 75 years ago?

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

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.
 

 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
 

 government about 75 years ago?
 
 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><

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.

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.

"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

Russel Winder <russel russel.org.uk> writes:

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=

eason=20
 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=

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

t.

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

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.

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.

Russel Winder <russel russel.org.uk> writes:

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

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

"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

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

"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

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.

Russel Winder <russel russel.org.uk> writes:

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

"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

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…

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.

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.

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.

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.

 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.

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.

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 

there are 
 '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.

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 

 there are 
 '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

"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

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

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.

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.

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. 

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.

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)

)

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.

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

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

"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

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

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

"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  

 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?

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

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.

"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

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.

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 

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,

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.

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?

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 

it. What's 

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 

developers with this?

See my other comment on the thread.

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

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.

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.

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)…

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

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.

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

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.

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

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.

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

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.

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.

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

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.

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.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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?

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.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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

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

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!

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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.

"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

"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=

n  =

 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

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

"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

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

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

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.

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.

"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

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. 

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.

 One trick that can work wonders here is treating ddoc as lisp code, most
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.

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

 One trick that can work wonders here is treating ddoc as lisp code, most 
 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.

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.

Hey, you are the first person I heard of that also uses PN2 :) . It 
isn't a full-featured IDE but it's a great editor for programming, isn't 
  it.

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

 Hey, you are the first person I heard of that also uses PN2 :) . It  
 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.

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.

 Hey, you are the first person I heard of that also uses PN2 :) . It 
 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.

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

 Hey, you are the first person I heard of that also uses PN2 :) . It isn't 
 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.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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.

 Hey, you are the first person I heard of that also uses PN2 :) . It isn't
 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.

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.

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

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

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.

"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/

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

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

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 

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.

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.

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.

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.

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.

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.

 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.

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);

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

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.

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

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

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.

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

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.

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

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

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.

 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.

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.

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.
 

 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.
 

 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.
 

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

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=,;

 This seems excessive.

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

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=,;

This seems excessive.

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

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=,;

 This seems excessive.

 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 macro for the ; is needed because you might want to strip it out in
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

Walter Bright <newshound2 digitalmars.com> writes:

Johannes Pfau wrote:
[...] lots of stuff

Some good arguments.

lurker <lurk lurk.net> writes:

Johannes Pfau Wrote:

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

 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.


 bla blah blah bla

{snip}

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

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

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.

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

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.

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.

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.

Well different people, different opinions I guess. The phobos
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.

yes candydoc is nice, but AFAIK it's not maintained since quite some time.

-- 
Johannes Pfau

Justin Johansson <no spam.com> writes:

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

It tells that C++ is crappy for software development.

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

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

 It tells that C++ is crappy for software development.

 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

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?

 It tells that C++ is crappy for software development.

 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

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?

 It tells that C++ is crappy for software development.
 
 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?

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.

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

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?

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

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

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

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?

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

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

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?

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

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

"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

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?

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.

"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

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

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

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

  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.

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

Philippe Sigaud <philippe.sigaud gmail.com> writes:

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?

It transforms ddoc mark-up into TeX mak-up?

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

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

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.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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.

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.

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?
 

 I have had exactly same thought when I've first seen DDoc a week ago
 

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

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.

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

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.

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.

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.

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

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.

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. 

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

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

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.

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

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.

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

BCS <none anon.com> writes:

Hello Walter,

 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,

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

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?

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

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.

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

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.

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

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.

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.
 

 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.
 

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

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.

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.
 

 Yes.
 

Now all we need is that someone else....

-- 
... <IXOYE><

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.

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?
 

 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.
 

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

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

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?
 

 Which one are you thinking about?
 

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

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/

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.

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.

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!

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

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.

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?

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.

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!

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

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

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

Jesse Phillips <jessekphillips+D gmail.com> writes:

Steven Schveighoffer Wrote:

 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?

My two comments are, shouldn't paragraphs be handled with a blank line? And yes
there is a document on ddoc

http://digitalmars.com/d/2.0/ddoc.html

"Nick Sabalausky" <a a.a> writes:

"Jesse Phillips" <jessekphillips+D gmail.com> wrote in message 
news:i3hr7p$1s1$1 digitalmars.com...
 Steven Schveighoffer Wrote:

 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?

 My two comments are, shouldn't paragraphs be handled with a blank line?

YES.

And along those exact lines, may I say I'm a big fan of the Natural Docs 
approach. IMO, comments should be [*easily*] readable *before* being run 
through a doc generator, not just after. Of course, in that regard (not to 

(I've never understood MS's enormous obsession with XML), but DDoc still has 
that same fundamental problem.

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:
 (I've never understood MS's enormous obsession with XML), but DDoc still has 
 that same fundamental problem.

I think that's a nice example of Conway's Law:
http://en.wikipedia.org/wiki/Conway%27s_Law


:-)

Bye,
bearophile

Justin Spahr-Summers <Justin.SpahrSummers gmail.com> writes:

On Sat, 7 Aug 2010 01:19:03 -0400, Nick Sabalausky <a a.a> wrote:
 
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message 
 news:i3hr7p$1s1$1 digitalmars.com...
 Steven Schveighoffer Wrote:

 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?

 My two comments are, shouldn't paragraphs be handled with a blank line?

 
 YES.
 
 And along those exact lines, may I say I'm a big fan of the Natural Docs 
 approach. IMO, comments should be [*easily*] readable *before* being run 
 through a doc generator, not just after. Of course, in that regard (not to 

 (I've never understood MS's enormous obsession with XML), but DDoc still has 
 that same fundamental problem.

Just in case you haven't seen this page before:
http://www.charlespetzold.com/etc/CSAML.html

;)

BCS <none anon.com> writes:

Hello Justin Spahr-Summers,

 On Sat, 7 Aug 2010 01:19:03 -0400, Nick Sabalausky <a a.a> wrote:
 
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message
 news:i3hr7p$1s1$1 digitalmars.com...
 
 Steven Schveighoffer Wrote:
 
 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?

 My two comments are, shouldn't paragraphs be handled with a blank
 line?
 

 YES.
 
 And along those exact lines, may I say I'm a big fan of the Natural
 Docs approach. IMO, comments should be [*easily*] readable *before*
 being run through a doc generator, not just after. Of course, in that

 horrid XML comments (I've never understood MS's enormous obsession
 with XML), but DDoc still has that same fundamental problem.
 

 Just in case you haven't seen this page before:
 http://www.charlespetzold.com/etc/CSAML.html
 ;)
 

I wonder how long that took to write. Just the typing must have taken some 
time but if you factor in the time take to recover from the laughter induce 
injuries it may have taken weeks!

-- 
... <IXOYE><

"Nick Sabalausky" <a a.a> writes:

"Justin Spahr-Summers" <Justin.SpahrSummers gmail.com> wrote in message 
news:MPG.26c91a1af538b8829896b8 news.digitalmars.com...
 On Sat, 7 Aug 2010 01:19:03 -0400, Nick Sabalausky <a a.a> wrote:
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message
 news:i3hr7p$1s1$1 digitalmars.com...
 Steven Schveighoffer Wrote:

 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?

 My two comments are, shouldn't paragraphs be handled with a blank line?

 YES.

 And along those exact lines, may I say I'm a big fan of the Natural Docs
 approach. IMO, comments should be [*easily*] readable *before* being run
 through a doc generator, not just after. Of course, in that regard (not 
 to

 (I've never understood MS's enormous obsession with XML), but DDoc still 
 has
 that same fundamental problem.

 Just in case you haven't seen this page before:
 http://www.charlespetzold.com/etc/CSAML.html

 ;)

That's great! I hadn't seen that before. Love it. I did experience a couple 
seconds of sheer horror before I realized it was a joke :)

"Mike James" <foo bar.com> writes:

"Justin Spahr-Summers" <Justin.SpahrSummers gmail.com> wrote in message 
news:MPG.26c91a1af538b8829896b8 news.digitalmars.com...
 On Sat, 7 Aug 2010 01:19:03 -0400, Nick Sabalausky <a a.a> wrote:
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message
 news:i3hr7p$1s1$1 digitalmars.com...
 Steven Schveighoffer Wrote:

 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?

 My two comments are, shouldn't paragraphs be handled with a blank line?

 YES.

 And along those exact lines, may I say I'm a big fan of the Natural Docs
 approach. IMO, comments should be [*easily*] readable *before* being run
 through a doc generator, not just after. Of course, in that regard (not 
 to

 (I've never understood MS's enormous obsession with XML), but DDoc still 
 has
 that same fundamental problem.

 Just in case you haven't seen this page before:
 http://www.charlespetzold.com/etc/CSAML.html

 ;)

Best April Fools joke I've seen in a while :-)
No doubt someone will implement it for the exercise...

-=mike=- 

Adrian Matoga <epi atari8.info> writes:

On 2010-08-09 05:47, Justin Spahr-Summers wrote:
 On Sat, 7 Aug 2010 01:19:03 -0400, Nick Sabalausky <a a.a> wrote:
 "Jesse Phillips" <jessekphillips+D gmail.com> wrote in message 
 news:i3hr7p$1s1$1 digitalmars.com...
 Steven Schveighoffer Wrote:

 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?

 My two comments are, shouldn't paragraphs be handled with a blank line?

 YES.

 And along those exact lines, may I say I'm a big fan of the Natural Docs 
 approach. IMO, comments should be [*easily*] readable *before* being run 
 through a doc generator, not just after. Of course, in that regard (not to 

 (I've never understood MS's enormous obsession with XML), but DDoc still has 
 that same fundamental problem.

 
 Just in case you haven't seen this page before:
 http://www.charlespetzold.com/etc/CSAML.html
 
 ;)

But, you see, it was easy to believe it was truth. :)

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 06 Aug 2010 16:27:37 -0400, Jesse Phillips  
<jessekphillips+D gmail.com> wrote:

 Steven Schveighoffer Wrote:

 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?

 My two comments are, shouldn't paragraphs be handled with a blank line?  
 And yes there is a document on ddoc

 http://digitalmars.com/d/2.0/ddoc.html

Thanks, I hadn't seen that page (looks like there's a missing parentheses  
in there too! ;)

I'll have to see if I can get vim to read ddoc properly so I can edit it  
fine the next time.

I agree 100%, get rid of all the $(P's.  I'd rather see natural text.  I'm  
a big fan of trac's wiki format, where formatting is pretty natural.  i.e.  
a bulleted list looks like this:

  * item 1
  * item 2

You still need tags for things like bold or italic, but those should be  
few and far between.  And of course, you need macros for dynamic content  
generation.

-Steve

bearophile <bearophileHUGS lycos.com> writes:

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

I avoid all editors based on Scintilla because it is too much slow for me :-)

Bye,
bearophile

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

You mean slow in terms of productivity? With that I tend to agree. Most
scintilla-based editors that I've tried don't offer much more than what is
already in Scintilla. It's tends to be a sci-component wrapped in some GUI,
with options hidden in some menu somewhere that you have to hunt down (I
really prefer text files for settings, like in Scite). But it does load huge
files very fast, and seems to handle Unicode well (I've only tried on a
couple of files where it displayed unicode correctly, and VIM displayed
garbage).

On Sun, Aug 8, 2010 at 5:44 AM, bearophile <bearophileHUGS lycos.com> wrote:

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

 I avoid all editors based on Scintilla because it is too much slow for me
 :-)

 Bye,
 bearophile

"Nick Sabalausky" <a a.a> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:i3l961$22a5$1 digitalmars.com...
 Nick Sabalausky:
 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).

 I avoid all editors based on Scintilla because it is too much slow for me 
 :-)

?? I'm assuming that's a joke but I can't tell...?

Adrian Matoga <epi atari8.info> writes:

On 2010-08-08 19:10, Nick Sabalausky wrote:
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:i3l961$22a5$1 digitalmars.com...
 Nick Sabalausky:
 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).

 I avoid all editors based on Scintilla because it is too much slow for me 
 :-)

 
 ?? I'm assuming that's a joke but I can't tell...?
 

I'm sure bearophile simply has a DMA channel between his brain and his 
computer's memory. ;) In that case, any editor for mortals is indeed way 
too slow. :)

Adrian

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

Damn I must be stupid or something, I thought PN was closed source the last
time I checked it out. It supports Python scripting as well.. hmm. I'll have
to check it out. :)

2010/8/8 Adrian Matoga <epi atari8.info>

 On 2010-08-08 19:10, Nick Sabalausky wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:i3l961$22a5$1 digitalmars.com...

 Nick Sabalausky:

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

 I avoid all editors based on Scintilla because it is too much slow for me
 :-)

 ?? I'm assuming that's a joke but I can't tell...?

 I'm sure bearophile simply has a DMA channel between his brain and his
 computer's memory. ;) In that case, any editor for mortals is indeed way too
 slow. :)

 Adrian

"Nick Sabalausky" <a a.a> writes:

"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.189.1281288584.13841.digitalmars-d puremagic.com...
 Damn I must be stupid or something, I thought PN was closed source the 
 last
 time I checked it out. It supports Python scripting as well.. hmm. I'll 
 have
 to check it out. :)

It also has damn good handling of various UTF-encodings and different 
line-endings. For instance, I see this (auto-detected) menu option and I 
just smile: http://www.semitwist.com/download/pn2utf.png 

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

OT, but since we were on the subject of text editors I found a vim
keybinding script that some guy made a while ago and I've modified it to
work with a hotkey app called AutoHotkey_L (check
http://www.autohotkey.net/~Lexikos/AutoHotkey_L/ ). AHK_L is a modification
of the original AutoHotkey but has some nicer features, its Windows-only
unfortunately.

Right now it's just a basic script that allows you to switch from "vim-mode"
to the usual "default" mode (although I called it insert like in vim). When
you're in vim-mode, you can use the basic navigation keys, like JKL: (I've
assigned mine to IJKL however), moving the cursor to next/previous words
(and a number modifier before that to skip X number of words).

The cool thing is that it works with Scite. And if it works with Scite, it
probably works with most other Scintilla-based editors, provided that the
shortcuts are all the same there. I've tested it with PN and it works there
as well. Hell, it even works in Firefox!

I've only had a brief experience with VIM a few months ago, so I don't even
know the scratch of what it offers. But I'm thinking of expanding the
script, so one could potentially use it in *any* text editor. If there are
any VIM-enthusiasts that know AHK and would like to contribute, maybe I
could set up a repo someplace. Otherwise, I'll keep updating it for my own
use atm.

Download the script from here;



Copy-paste the code in a text file, save the file as an .ahk file. Make sure
you've got AHK_L installed and run the script. Use caps-lock to switch
between modes. Have fun.


On Sun, Aug 8, 2010 at 7:49 PM, Nick Sabalausky <a a.a> wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.189.1281288584.13841.digitalmars-d puremagic.com...
 Damn I must be stupid or something, I thought PN was closed source the
 last
 time I checked it out. It supports Python scripting as well.. hmm. I'll
 have
 to check it out. :)

 It also has damn good handling of various UTF-encodings and different
 line-endings. For instance, I see this (auto-detected) menu option and I
 just smile: http://www.semitwist.com/download/pn2utf.png

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

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.

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