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!

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

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

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

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

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

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

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

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 )

-- 
Alexander

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