Re: TDPL in Russian

[Max Samukha]

On 11/10/2010 12:22 AM, Andrei Alexandrescu wrote:

Just got word from my editor that TDPL has been approved for translation
in Russian.

Andrei


Поздравляю! Надеюсь, что перевод будут делать долго, дорого и о..енно.

Re: TDPL in Russian

[Eldar Insafutdinov]

#1054;#1090;#1083;#1080;#1095;#1085;#1099;#1077; 
#1085;#1086;#1074;#1086;#1089;#1090;#1080;!

#1058;#1077;#1084; #1085;#1077; #1084;#1077;#1085;#1077;#1077;, 
#1084;#1085;#1086;#1075;#1080;#1077; 
#1089;#1086;#1075;#1083;#1072;#1089;#1103;#1090;#1089;#1103; 
#1089;#1086; #1084;#1085;#1086;#1081; #1095;#1090;#1086; 
#1087;#1088;#1080; #1076;#1086;#1083;#1078;#1085;#1086;#1084; 
#1074;#1083;#1072;#1076;#1077;#1085;#1080;#1080; 
#1072;#1085;#1075;#1083;#1080;#1081;#1089;#1082;#1080;#1084;
#1103;#1079;#1099;#1082;#1086;#1084;, 
#1090;#1077;#1093;#1085;#1080;#1095;#1077;#1089;#1082;#1080;#1077; 
#1082;#1085;#1080;#1075;#1080; #1083;#1091;#1095;#1096;#1077; 
#1095;#1080;#1090;#1072;#1090;#1100; #1074; 
#1086;#1088;#1080;#1075;#1080;#1085;#1072;#1083;#1077;. #1053;#1086; 
#1088;#1091;#1089;#1089;#1082;#1080;#1081; 
#1087;#1077;#1088;#1077;#1074;#1086;#1076; 
#1073;#1091;#1076;#1077;#1090;
#1086;#1090;#1083;#1080;#1095;#1085;#1099;#1084; 
#1074;#1099;#1093;#1086;#1076;#1086;#1084; #1076;#1083;#1103; 
#1084;#1085;#1086;#1075;#1080;#1093; 
#1087;#1088;#1086;#1075;#1088;#1072;#1084;#1084;#1080;#1089;#1090;#1086;#1074;,
 #1082;#1086;#1090;#1086;#1088;#1099;#1077; #1077;#1097;#1077; 
#1085;#1077; #1090;#1072;#1082; #1093;#1086;#1088;#1086;#1096;#1086; 
#1079;#1085;#1072;#1102;#1090;
#1090;#1077;#1093;#1085;#1080;#1095;#1077;#1089;#1082;#1080;#1081; 
#1072;#1085;#1075;#1083;#1080;#1081;#1089;#1082;#1080;#1081;.

Re: TDPL in Russian

[Denis Koroskin]

On Wed, 10 Nov 2010 14:34:46 +0300, Eldar Insafutdinov  
e.insafutdi...@gmail.com wrote:


#1054;#1090;#1083;#1080;#1095;#1085;#1099;#1077;  
#1085;#1086;#1074;#1086;#1089;#1090;#1080;!


#1058;#1077;#1084; #1085;#1077;  
#1084;#1077;#1085;#1077;#1077;,  
#1084;#1085;#1086;#1075;#1080;#1077;  
#1089;#1086;#1075;#1083;#1072;#1089;#1103;#1090;#1089;#1103;  
#1089;#1086; #1084;#1085;#1086;#1081; #1095;#1090;#1086;  
#1087;#1088;#1080; #1076;#1086;#1083;#1078;#1085;#1086;#1084;  
#1074;#1083;#1072;#1076;#1077;#1085;#1080;#1080;  
#1072;#1085;#1075;#1083;#1080;#1081;#1089;#1082;#1080;#1084;
#1103;#1079;#1099;#1082;#1086;#1084;,  
#1090;#1077;#1093;#1085;#1080;#1095;#1077;#1089;#1082;#1080;#1077;  
#1082;#1085;#1080;#1075;#1080; #1083;#1091;#1095;#1096;#1077;  
#1095;#1080;#1090;#1072;#1090;#1100; #1074;  
#1086;#1088;#1080;#1075;#1080;#1085;#1072;#1083;#1077;.  
#1053;#1086; #1088;#1091;#1089;#1089;#1082;#1080;#1081;  
#1087;#1077;#1088;#1077;#1074;#1086;#1076;  
#1073;#1091;#1076;#1077;#1090;
#1086;#1090;#1083;#1080;#1095;#1085;#1099;#1084;  
#1074;#1099;#1093;#1086;#1076;#1086;#1084; #1076;#1083;#1103;  
#1084;#1085;#1086;#1075;#1080;#1093;  
#1087;#1088;#1086;#1075;#1088;#1072;#1084;#1084;#1080;#1089;#1090;#1086;#1074;,  
#1082;#1086;#1090;#1086;#1088;#1099;#1077; #1077;#1097;#1077;  
#1085;#1077; #1090;#1072;#1082;  
#1093;#1086;#1088;#1086;#1096;#1086;  
#1079;#1085;#1072;#1102;#1090;
#1090;#1077;#1093;#1085;#1080;#1095;#1077;#1089;#1082;#1080;#1081;  
#1072;#1085;#1075;#1083;#1080;#1081;#1089;#1082;#1080;#1081;.


Might be more readable here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announcearticle_id=19609

Re: [OT] DVCS

[Jérôme M. Berger]

Bruno Medeiros wrote:
 On 28/10/2010 18:51, Jérôme M. Berger wrote:
 Bruno Medeiros wrote:
 But isn't the staging area similar, if not identical to SVN? I mean, in
 svn you also have to do a command svn add to add new files to the
 sandbox. They won't get commit otherwise, right?

 (note: im somewhat familiar with SVN and Git, but not with Mercurial)

 No, because in Git if you make changes to an existing file, you
 need to add that file again. In both SVN or Mercurial, you need to
 add new files, but once a file is in the repository, any changes
 to the file get committed by default (although there are ways to
 commit only some files in both Mercurial and SVN and ways to commit
 only some changes in Mercurial).

 Jerome
 
 I see. Well, it's not identical then, but still, it seems very similar,
 since one can use git commit -a to do the same as svn commit, isn't
 that so? I mean, is there any aspect to Git's staging area that makes
 git commit -a not be equivalent to svn commit ? (obviously for this
 question interactions with Git-only features should not be considered)
 
 
 My confusion here stems not so much from the discussion in this thread,
 but from another discussion elsewhere on the web (not D related) where I
 also saw a developer comment that Git's staging index default behavior
 was more complex that necessary, and that it should be the simple thing
 by default. There was an implication, from the way he said it, that this
 was an issue of at least medium importance.
 However, from my understanding, in the whole landscape of version
 control issues and comparisons, this one seems of very low importance,
 if not borderline irrelevance. Because even if a developer using Git
 shoots himself in the foot with this... it will be only *once*, on the
 learning phase. After that you'd know and remember to use git commit
 -a so the mistake would not be repeated. A /one-time issue/ cannot
 possibly be anywhere near in importance than a /many-times issue/.
 
 
Ah, but it is a many-times issue. It is even an every-times issue.
The problem here is that you need to remember to add the appropriate
option each and every time you want to commit. Proper interface
design would be to have the common usage be the default and have an
option to enable the complex usage (especially for the most common
command).

Additionally this makes it a lot more difficult to move back and
forth between several systems: imagine if all VCSes required special
options to do a simple commit, now each time you want to commit, you
need to remember whether this particular VCS requires an option and
which option you need to add to get the simple behaviour.

Moreover, this is just the tip of the iceberg. The whole git UI is
designed like that and full of small irritations and inconsistencies.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr




signature.asc
Description: OpenPGP digital signature

Re: TDPL in Russian

[Stanislav Blinov]

10.11.2010 1:22, Andrei Alexandrescu пишет:
Just got word from my editor that TDPL has been approved for 
translation in Russian.


Andrei


Congratulations!

Though I only can second Max's hopes. I'd hate it if it results in yet 
another unreadable do-no-good stuff, as is too often with Russian 
translations.

Re: TDPL in Russian

[Stanislav Blinov]

10.11.2010 3:22, Walter Bright пишет:

Andrei Alexandrescu wrote:
Just got word from my editor that TDPL has been approved for 
translation in Russian.


Da, Tovarish!


Aw come on! Where did you ever get that stuff?..

Re: TDPL in Russian

[Stanislav Blinov]

10.11.2010 14:34, Eldar Insafutdinov пишет:

Отличные новости! Тем не менее, многие согласятся со мной что при 
должном владении английским языком, технические книги лучше читать в 
оригинале. Но русский перевод будет отличным выходом для многих 
программистов, которые еще не так хорошо знают технический английский 


I'd allow myself a translation:

Great news! Nevertheless, many will agree that with adequate English 
skills technical books are best read as they are. However, Russian 
translation would be nice for many programmers who don't know 
technical English well yet.


I agree, but only if the translation is adequate. Otherwise, it'll most likely 
just scare off newcomers.

P.S. Guys, let's be polite, please! Yes, the news are great, but let's not 
cause eyestrain to  non-Russian speaking people.

Re: TDPL in Russian

[Simen kjaeraas]

Stanislav Blinov bli...@loniir.ru wrote:

P.S. Guys, let's be polite, please! Yes, the news are great, but let's  
not cause eyestrain to  non-Russian speaking people.


Но Россия это весело!
(But russian is fun!)

--
Simen

Re: TDPL in Russian

[Eldar Insafutdinov]

Come on, this thread gives us a great excuse!

Re: TDPL in Russian

[digited]

Eldar Insafutdinov Wrote:

 #1054;#1090;#1083;#1080;#1095;#1085;#1099;#1077; 
 #1085;#1086;#1074;#1086;#1089;#1090;#1080;!
 
 #1058;#1077;#1084; #1085;#1077; #1084;#1077;#1085;#1077;#1077;, 
 #1084;#1085;#1086;#1075;#1080;#1077; 
 #1089;#1086;#1075;#1083;#1072;#1089;#1103;#1090;#1089;#1103; 
 #1089;#1086; #1084;#1085;#1086;#1081; #1095;#1090;#1086; 
 #1087;#1088;#1080; #1076;#1086;#1083;#1078;#1085;#1086;#1084; 
 #1074;#1083;#1072;#1076;#1077;#1085;#1080;#1080; 
 #1072;#1085;#1075;#1083;#1080;#1081;#1089;#1082;#1080;#1084;
 #1103;#1079;#1099;#1082;#1086;#1084;, 
 #1090;#1077;#1093;#1085;#1080;#1095;#1077;#1089;#1082;#1080;#1077; 
 #1082;#1085;#1080;#1075;#1080; #1083;#1091;#1095;#1096;#1077; 
 #1095;#1080;#1090;#1072;#1090;#1100; #1074; 
 #1086;#1088;#1080;#1075;#1080;#1085;#1072;#1083;#1077;. 
 #1053;#1086; #1088;#1091;#1089;#1089;#1082;#1080;#1081; 
 #1087;#1077;#1088;#1077;#1074;#1086;#1076; 
 #1073;#1091;#1076;#1077;#1090;
 #1086;#1090;#1083;#1080;#1095;#1085;#1099;#1084; 
 #1074;#1099;#1093;#1086;#1076;#1086;#1084; #1076;#1083;#1103; 
 #1084;#1085;#1086;#1075;#1080;#1093; 
 #1087;#1088;#1086;#1075;#1088;#1072;#1084;#1084;#1080;#1089;#1090;#1086;#1074;,
  #1082;#1086;#1090;#1086;#1088;#1099;#1077; #1077;#1097;#1077; 
 #1085;#1077; #1090;#1072;#1082; 
 #1093;#1086;#1088;#1086;#1096;#1086; #1079;#1085;#1072;#1102;#1090;
 #1090;#1077;#1093;#1085;#1080;#1095;#1077;#1089;#1082;#1080;#1081; 
 #1072;#1085;#1075;#1083;#1080;#1081;#1089;#1082;#1080;#1081;.

I agree, but my first Delphi, C++ and STL books were in russian, that really 
helped a lot.
We'll see about the quality of translation and pricing, i hope it will be good.

Re: TDPL in Russian

[Eldar Insafutdinov]

This was in reply to http://article.gmane.org/gmane.comp.lang.d.announce/5763 . 
I
should probably start use a proper client instead of web-interface for replying 
to
these news groups.

Re: TDPL in Russian

[Stanislav Blinov]

10.11.2010 18:54, Eldar Insafutdinov пишет:

This was in reply to http://article.gmane.org/gmane.comp.lang.d.announce/5763 . 
I
should probably start use a proper client instead of web-interface for replying 
to
these news groups.



It's probably because of me: I post via mailing list, and almost every 
reply to my posts isn't properly threaded. But I'm kinda out of options, 
because at work I only have mail, no Internet at all :(

Re: TDPL in Russian

[Walter Bright]

Stanislav Blinov wrote:

10.11.2010 3:22, Walter Bright пишет:

Andrei Alexandrescu wrote:
Just got word from my editor that TDPL has been approved for 
translation in Russian.


Da, Tovarish!


Aw come on! Where did you ever get that stuff?..


The movies, naturally!

Re: TDPL in Russian

[Dmitry Olshansky]

On 10.11.2010 1:22, Andrei Alexandrescu wrote:
Just got word from my editor that TDPL has been approved for 
translation in Russian.


Andrei

Awesome!

P.S. God, if you hear me,  please, send us some _adequate_ Russian 
translators/reviewers.


--
Dmitry Olshansky

Re: TDPL in Russian

[Max Samukha]

On 11/10/2010 08:25 PM, Dmitry Olshansky wrote:

On 10.11.2010 1:22, Andrei Alexandrescu wrote:

Just got word from my editor that TDPL has been approved for
translation in Russian.

Andrei

Awesome!

P.S. God, if you hear me, please, send us some _adequate_ Russian
translators/reviewers.



It seems I am not alone in my disliking of recent Russian translations. 
Nostalgic digression: when the USSR was keen on copying American 
microchip design, IT-related technical translations were much better.

Re: TDPL in Russian

[Stanislav Blinov]

Walter Bright wrote:

Stanislav Blinov wrote:

10.11.2010 3:22, Walter Bright пишет:

Andrei Alexandrescu wrote:
Just got word from my editor that TDPL has been approved for 
translation in Russian.


Da, Tovarish!


Aw come on! Where did you ever get that stuff?..


The movies, naturally!


I bet none of them was Soviet or Russian :-P

Re: TDPL in Russian

[Stanislav Blinov]

Simen kjaeraas wrote:

Stanislav Blinov bli...@loniir.ru wrote:

P.S. Guys, let's be polite, please! Yes, the news are great, but let's 
not cause eyestrain to  non-Russian speaking people.


Но Россия это весело!
(But russian is fun!)



Oh, it certainly is. Sadly, the language nowadays suffers greatly from 
mindless attempts to mix in a good deal of English. I don't mind 
English, it's just that that mutation transforms both languages into 
freaks :(

Re: TDPL in Russian

[Nick Sabalausky]

Stanislav Blinov stanislav.bli...@gmail.com wrote in message 
news:ibf3dm$29e...@digitalmars.com...
 Simen kjaeraas wrote:
 Stanislav Blinov bli...@loniir.ru wrote:

 P.S. Guys, let's be polite, please! Yes, the news are great, but let's 
 not cause eyestrain to  non-Russian speaking people.

 ?? ?? ??? ??!
 (But russian is fun!)


 Oh, it certainly is. Sadly, the language nowadays suffers greatly from 
 mindless attempts to mix in a good deal of English. I don't mind English, 
 it's just that that mutation transforms both languages into freaks :(

English is already a freak language! :)

FWIW, This is the extent of my Russian knowledge: Nyet, Da, Vodka, Dasha, 
Big Fuzzy Hat. I can't read Cyrillic, but I've wondered if the founder of 
Toys ? Us was Russian ;)

There's also a couple things I don't have the slightest idea how to spell 
(so I'm just going to try to spell phonetically), and I'm not sure they're 
even Russian, but I know it's some sort of eastern-european language, I 
think Czech: Yuck she mush Dovja. (My great-grandfather was Czech (IIRC) 
and taught my brother, sister and I that way back when he was still around.)

Re: why a part of D community do not want go to D2 ?

[Don]

so wrote:
Sean took all the code he had written. The other minor contributors 
did not yet give permission for their code to be used, so of course it 
could not be included.


This is the single big thing on this tango vs phobos issue i never 
understand.
What are the reasons/motives behind this other than stupid politics? Why 
wouldn't they give permission?


Nobody knows, apart from the people involved. They've made no statement 
(not even privately).

Re: Passing dynamic arrays

[Jens Mueller]

  I see your point. You argue that the behavior is consistent. My point is
  that this consistency can lead to bugs. I may forget the ref. But I'll
  keep in mind to never forget the ref if it is needed.
  
  Jens
 
 Well, in the case of classes, I don't think it would be very common.
 
 For arrays it can be nice since you can assign back a slice of the array that 
 you want to work with.
 
 void main(string args) {
 args = args[1..$];
 }
 
 Otherwise I suggest you start labeling all parameters with in. Then you are 
 prevented from modifying the reference, and can decide if it should be a ref 
 parameter. Who knows, maybe you'll find a reason to leave it off.

With dynamic arrays I totally agree. Slicing is very useful. I just want
a safe rule to work with it. Maybe that's not needed anymore because by
now I spend enough time on this that probably I'll never forget.
With in I also disallow changing the object itself, right? I want to
only forbid the changing of the reference of an argument inside the
function. With in/const I disallow every change. I may want to change
data of an array.

Jens

PS
The more we talk about it, the more I come to the conclusion that this
is just something you need to know. I can live with that.

Re: why a part of D community do not want go to D2 ?

[klickverbot]

On 11/10/10 12:00 AM, Walter Bright wrote:

[…] Producing another incompatible split with D2 will not be of an

 advantage to anyone, and will just give people reasons not to use D
 at all.

I probably wouldn't get the problem anyway, and I have been using both 
D1/Tango and, recently, D2/Phobos, and I never understood the reasons 
for the recent clash in the first place (besides, to me, slightly … 
childish … behavior on both sides), but:


Has anyone actually proposed that? If not, I fear that comments like 
this just help spreading FUD around the current situation of D, not 
unlike the (in my eyes) exaggeration of licensing issues…

Re: why a part of D community do not want go to D2 ?

[Jacob Carlborg]

On 2010-11-09 23:04, Don wrote:

Jacob Carlborg wrote:

On 2010-11-09 17:43, Andrei Alexandrescu wrote:

I wouldn't be surprised if Tango chose to turn away from compatibility
for the second time (be it theoretical compatibility for now since there
is no Tango for D2). The technical reasons are dwindling and became
tenuous to argue for, but however weak they are, they could be used to
promote a political motivation: a Tango/D2 offering would come again as
an either-or proposition for a standard library that precludes usage of
Tango2 and Phobos2 together. In my opinion that would be an extremely
dangerous gambit.


Clearly we don't see this in the same way. I see it like this, because
Tango was first it's druntime that chose to turn away from compatibility.


Sorry, that is completely false. druntime was created specifically to
allow Phobos and Tango to co-exist. At the time, almost all of the code
in druntime was written by Sean, and he was leading the Tango runtime
development. The expectation was that Tango would continue to use Sean's
runtime, it was just in a separate project.


Of course that would be the preferred way, there should have been some 
kind of agreement for this (maybe there was but never fulfilled?) But 
you also have to look at it from Tangos point of view. Why would Tango 
drop support for anything that isn't DMD 32bit? Or should Tango keep 
half of it's runtime in it's own repository and for the other half use 
druntime.



For this to work the Tango team and the druntime
contributors/maintainers have collaborate and work together on a
runtime.


That runtime is druntime. If there is no understanding of that at Tango,
that is suicide.


Apparently not, since Sean ripped out all that wasn't necessary for
Phobos but is necessary for Tango. Why are you blaming everything on
Tango all the time?


Sean took all the code he had written. The other minor contributors did
not yet give permission for their code to be used, so of course it could
not be included.


I really think it's a shame they couldn't/wanted to give permission for 
their code to be used.


--
/Jacob Carlborg

Re: why a part of D community do not want go to D2 ?

[Jacob Carlborg]

On 2010-11-09 22:45, Andrei Alexandrescu wrote:

On 11/9/10 12:33 PM, Jacob Carlborg wrote:

On 2010-11-09 17:43, Andrei Alexandrescu wrote:

On 11/9/10 1:42 AM, Jacob Carlborg wrote:

On 2010-11-08 20:55, Andrei Alexandrescu wrote:

It is my perception (though I might be wrong) that the dichotomy has
become to some extent political. D2 offers little political
incentive to
a Tango port. Tango is currently the de facto standard library for
D1 as
the vast majority of D1 users use D1 and Tango in conjunction, which
precludes use of the underpowered Phobos1 (D1's de jure standard
library). Due to Sean's work on making druntime independently
available,
porting to D2 would lower Tango's status from the standard library to
one of the libraries that may be used in conjunction with Phobos2.


Here's the problem with that: since Sean basically forked the Tango
runtime, removed any non DMD specific code and any code for a platform
that DMD doesn't support. And stopped contributing to Tango while
others
improved the Tango runtime we're back at square one with two
incompatiable runtimes and the Tango runtime still seems to be better.


It's not difficult to offer e.g. an incompatible C runtime that is
slightly better than the standard one. People generally don't do that
but instead add libraries on top of that because they understand the
advantages of compatibility.


There was a good standard library that you forked and never added back
any changes to it.


This must be some confusion. I didn't fork anything. Besides, it's not
useful to fall into the pattern of finger pointing.


Ok, you wasn't not a good word in this case and I apologize. What I 
meant with you was you as a group consisting of the people working 
on Phobos and druntime and/or the people that agreed (I'm assuming it 
was more than one person) we should build a new runtime for D2 based on 
the Tango runtime. I guess I just should have written Sean.



I wouldn't be surprised if Tango chose to turn away from compatibility
for the second time (be it theoretical compatibility for now since there
is no Tango for D2). The technical reasons are dwindling and became
tenuous to argue for, but however weak they are, they could be used to
promote a political motivation: a Tango/D2 offering would come again as
an either-or proposition for a standard library that precludes usage of
Tango2 and Phobos2 together. In my opinion that would be an extremely
dangerous gambit.


Clearly we don't see this in the same way. I see it like this, because
Tango was first it's druntime that chose to turn away from compatibility.


That would be a tenuous point to make in more than one way. Druntime was
a major effort to foster runtime standardization made by its author
himself and with intentions that I consider most transparent. I'd find
it very difficult to concoct a hypothesis in which Sean comes across as
not acting in the best interest of the D community.


Yes, I also think that Sean acted in the best interest of the D community.


That very concern - the best interest of the D community - has
unequivocally been the reason for which Sean and other chose to leave
petty fights to others and join Phobos, which has no political agenda.
That's supposed to tell someone something. You are gladly invited to
attempt to convince me otherwise, but the sheer facts at hand would make
it difficult for you to build a case. I mean it's possible - for any
number of good reasons - to ignore mounting evidence for some time, but
at some point the waking up and smelling of the coffee is inevitable.


I can agree with most of this and I think it's ridiculous that some 
Tango contributors don't want to contribute their code to 
Phobos/druntime. But I don't agree that it's the best interest of the D 
community that Sean stopped conributing to Tango. That's basically why 
we have this problem he never folded back any changes to Tango (as far 
as I know).



For this to work the Tango team and the druntime
contributors/maintainers have collaborate and work together on a
runtime.


That runtime is druntime. If there is no understanding of that at Tango,
that is suicide.


Apparently not, since Sean ripped out all that wasn't necessary for
Phobos but is necessary for Tango. Why are you blaming everything on
Tango all the time?


There's no reason to get up in arms. I didn't blame anything on anyone,
just stated my view of the state of affairs. I'm hardly vested
emotionally in the matter so I'm not interested in dramatic posturing,
assigning blame, or drawing sweeping conclusions. One thing I would be
interested in is improving things going forward. I think that will be
possible once we all let bygones be bygones and see what we can do to
push D forward.


Andrei


That's good, I also want to push D forward. It's just that sometimes I'm 
having a hard time to believe what you're writing above (last 
section/paragraph) when reading other posts by you.


--
/Jacob Carlborg

Re: Apache mod_d needs C to instantiate D interpreter?

[Jacob Carlborg]

On 2010-11-10 01:25, Nick Sabalausky wrote:

Eric Poggeldnewsgro...@yage3d.net  wrote in message
news:ibcn72$2u3...@digitalmars.com...

On 11/9/2010 12:17 AM, Nick Sabalausky wrote:

Andrei Alexandrescuseewebsiteforem...@erdani.org   wrote in message
news:ibaepi$vf...@digitalmars.com...


People at Facebook told me that the adoption of D inside the company
might
be helped if they could simply write?d ... ?   to insert D code into a
page. I'm not sure how difficult such a plugin would be to implement.


I'm very suprised by that. That's become considered very bad style by
most
of the [professional] web dev world quite awhile ago, and for very good
reason. Rails-, django- and even ASP.NET-style pass variables into an
HTML
template approaches have proven to be...well...frankly, much less
shitty.




I've always felt the opposite way.  It's been a while since I've worked
with Asp.net controls, but I remember something like this:

ul id=List/ul
.
// Later, in C#
for (int i=0; i10; i++)
 List.innerHtml += li + sanitize(someArray[i]) +/li



Ouch, yea, that is awful (but I've done worse - I once tried to build HTML
buy manually adding nodes to an XML DOM...it seemed like a good idea until I
actually started doing it). I've done very little with ASP.NET, and it's
been awhile since I've even looked at it, but my understanding is that
you're supposed to do it more like this:

!-- template for defining a List here --
ul id=List/ul

!-- template for defining a ListElem here --
li id=ListElem/li

someListElem.innerHtml = sanitize(someArray[i])

Or something vaguely like that anyway. Yea, it's definitely still not as
good as rails/django/haxeIgniter/etc, though. A good HTML templating system
like what those use won't lead you to HTML-string-concatenation. I just
mentioned ASP.NET because I seemed to remember it being template-based in
some way.


As far as I know you could create a framework using ASP.NET that is as 
good as rails/django/haxeIgniter/etc. You could write almost the same 
could as the PHP example below in ASP.NET, just replace ?php with % 
and ?= with %=. Although it will look somewhat ugly at the end with % 
} %



While php would do something like:

ul id=List
 ?php foreach($someArray as $item):?
 li?=sanitize($item)?/li
 ?php endforeach?
/ul

Granted, C# is a much nicer language than php, and when in php, I always
separate model and controller logic from the html view, but the immediate
mode of php embedding helps me avoid the awkwardness of building html
through string concatenations in another file.  I get to see the html
structure exactly as it is.



I could probably live with that as long as the PHP template stayed
view-only and didn't grow too much logic.


This is where people usually jump in and suggest a templating system, but
I think it's silly to invent a second language when the first is more than
up to the task.  I always find myself thinking:  I know how to do this in
php or java, but how do I do this in the templating language?

I welcome counter-arguments.  Maybe I can be enlightened?


If you look up StringTemplate (related to ANTLR), there was a fairly
convincing explanation, although the more I think about it, I can't remember
what the hell it was (something about forcing excess logic to stay out of
the view, I guess, maybe...honestly I totally forget).





--
/Jacob Carlborg

Re: Apache mod_d needs C to instantiate D interpreter?

[Jacob Carlborg]

On 2010-11-10 03:28, Eric Poggel wrote:

On 11/9/2010 7:25 PM, Nick Sabalausky wrote:

I could probably live with that as long as the PHP template stayed
view-only and didn't grow too much logic.


Are there any web-friendly languages that are mature, offer the sanity
and static typing of C#, and the immediate mode of php?


Scala using the Lift framework perhaps. Scala has built in support for 
XML literals. Acutally I think Lift is more into the idea of creating 
new HTML-tags instead of mixing Scala and HTML.


--
/Jacob Carlborg

Re: why a part of D community do not want go to D2 ?

[Jacob Carlborg]

On 2010-11-10 00:00, Walter Bright wrote:

Tobias Pfaff wrote:

1. Bitter fighting about a possible non-nullable type for D3(!).
Discussion style: Noone will take away my right to write unsafe code
! vs. Down with the reckless cowboy coders. Are we discussing guns
or coding here?
That, and purposedly overhearing the other's real point.


I don't know that it's bitter, spirited might be a better term. I like
spirited discussions.



2. Tango vs. Phobos. Wow. I really really wished we were over that by
now. It's been like two years since I last looked in here, and still
the same thing.

So, while I like the language and will probably stick around here
anyway, it might me a good thing to avoid this experience for other
people interested in D peeking into the newsgroup. Also, with (2), I
don't really get the point here. Whatever exactly happend between the
tango/phobos fraction -- the best thing to do to get everyone on board
again is probably to just to make phobos2 a library everyone enjoys to
use. And avoid starting discussions on who did what wrong over and over.
And while still lacking a few of the high-level features of Tango
(higher level network, streaming, etc.) it feels like the direction is
right.


I agree. The reasons for the Tango split long ago, whatever the merit of
those reasons was, have long since passed. Producing another
incompatible split with D2 will not be of an advantage to anyone, and
will just give people reasons not to use D at all.

Jacob has recently decided to help out with improvements to druntime; I
take that as a very welcome sign towards ending the differences.


I don't want to increase any separation in the D community and would 
hope peoeple could agree more. I have no problems what so ever 
contributing both to Tango and Phobos/druntime. And I'm happy to license 
any of my code to whatever license would be need for a give D project.



With all that been said, I'm looking forward to using D for a while,
after fighting the C++ template code monster for the last years.


Great!


--
/Jacob Carlborg

Re: Apache mod_d needs C to instantiate D interpreter?

[Jacob Carlborg]

On 2010-11-10 00:57, Eric Poggel wrote:

On 11/9/2010 12:17 AM, Nick Sabalausky wrote:

Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message
news:ibaepi$vf...@digitalmars.com...


People at Facebook told me that the adoption of D inside the company
might
be helped if they could simply write?d ... ? to insert D code into a
page. I'm not sure how difficult such a plugin would be to implement.


I'm very suprised by that. That's become considered very bad style by
most
of the [professional] web dev world quite awhile ago, and for very good
reason. Rails-, django- and even ASP.NET-style pass variables into an
HTML
template approaches have proven to be...well...frankly, much less
shitty.




I've always felt the opposite way. It's been a while since I've worked
with Asp.net controls, but I remember something like this:

ul id=List/ul
.
// Later, in C#
for (int i=0; i10; i++)
List.innerHtml += li + sanitize(someArray[i]) + /li

While php would do something like:

ul id=List
?php foreach($someArray as $item):?
li?=sanitize($item)?/li
?php endforeach?
/ul


I would as well. I don't think it's wrong adding a some code to the 
views to help write HTML, the example above is a perfect example.



Granted, C# is a much nicer language than php, and when in php, I always
separate model and controller logic from the html view, but the
immediate mode of php embedding helps me avoid the awkwardness of
building html through string concatenations in another file. I get to
see the html structure exactly as it is.

This is where people usually jump in and suggest a templating system,
but I think it's silly to invent a second language when the first is
more than up to the task. I always find myself thinking: I know how to
do this in php or java, but how do I do this in the templating language?

I welcome counter-arguments. Maybe I can be enlightened?


Isn't a PHP kind of a template system? It's created for web development 
and to be able to mix HTML and PHP out of the box.


--
/Jacob Carlborg

Pls. bury this damned hatchet very deep (was Re: why a part of D community do not want go to D2 ?)

[Gour]

On Wed, 10 Nov 2010 11:51:19 +0100
 Jacob == Jacob Carlborg wrote:

Jacob Of course that would be the preferred way, there should have
Jacob been some kind of agreement for this (maybe there was but never
Jacob fulfilled?) But you also have to look at it from Tangos point of
Jacob view. Why would Tango drop support for anything that isn't DMD
Jacob 32bit? Or should Tango keep half of it's runtime in it's own
Jacob repository and for the other half use druntime.

It is very disappointing to see how many people in D community are
(still) behaving like a little children pointing fingers at each other
saying You did that to me!!

I am probably more happy just arriving here recently and I can
understand that some mistakes were done and (some) people may feel
hurt...

However, I'm sure that D community is not the only place in the
universe where people might get hurt, but if you cannot go over it,
it's shame...

Forgive, stay and contribute to push D(2) forward.

Otherwise, if the above is not possible, stop whining and find a
better language/community to contribute to.

(Recently I did not agree with some steps done in one CMS community,
complained, became banned from the forums..andn ow I am enjoying a new
CMS community without burning too much brain cycles over the past experience.)
This constant crying over the spilled milk does not make sense for
adult people. The time won't be brought back. Let's learn the lesson
and move forward. Take it or leave it...


Sincerely,
Gour

 -- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: why a part of D community do not want go to D2 ?

[retard]

Wed, 10 Nov 2010 11:56:18 +0100, Jacob Carlborg wrote:

 On 2010-11-10 00:00, Walter Bright wrote:
 I agree. The reasons for the Tango split long ago, whatever the merit
 of those reasons was, have long since passed. Producing another
 incompatible split with D2 will not be of an advantage to anyone, and
 will just give people reasons not to use D at all.

 Jacob has recently decided to help out with improvements to druntime; I
 take that as a very welcome sign towards ending the differences.
 
 I don't want to increase any separation in the D community and would
 hope peoeple could agree more. I have no problems what so ever
 contributing both to Tango and Phobos/druntime. And I'm happy to license
 any of my code to whatever license would be need for a give D project.

A dual licensing scheme for all code might help a bit (since both parties 
refuse to switch licensing). There are also

 - stylistic issues (OOP style structured Tango vs quick'n'dirty Phobos 
API) - this causes annoying technical incompatibilities

 - psychological issues (Tango's charismatic leaders vs dull politically 
correct office persons and almost anynomous lone coders porting Boost 
code written in other languages). I believe strong personalities like Jon 
Harrop and Paul Graham actually have an overall positive effect. It's not 
a big secret that Andrei has boosted D's adoption quite a bit - this has 
more to do with the strong personality than technical issues.

 - project management issues (Tango uses trac heavily and the leaders 
have modern project management skills, Phobos developers have developed a 
new inefficient ad-hoc software process model without the big picture 
'planning' phase and without any communication between the team and the 
product owner)

 - platform issues (not everyone agrees D2 is a perfect upgrade route - 
how is this even surprising? Look at the number of people *not* using D, 
it shouldn't be a surprise that there are people who dislike D2, but like 
D1)

 - an axe fight between some key persons. I believe this can be solved if 
there weren't those other annoying problems.

These are all my subjective opinions. Feel free to throw the first rock, 
after all I'm just a stupid troll.

For me the technical issues have the greatest priority. If I want a full 
flexible Java style stream I/O interface and these kind of things, there's 
no way in hell I'll let you shove the Phobos style ideology down my 
throat. I'd have to create a PhoTango wrapper to actually use these.

The political issues aren't that interesting. If I'm coding in Java or 
C#, I don't even know the names of the stdlib developers. Maybe Doug Lea. 
But he left Oracle for political reasons..

Re: Apache mod_d needs C to instantiate D interpreter?

[sybrandy]

On 11/09/2010 06:57 PM, Eric Poggel wrote:

I've always felt the opposite way. It's been a while since I've worked
with Asp.net controls, but I remember something like this:

ul id=List/ul
.
// Later, in C#
for (int i=0; i10; i++)
List.innerHtml += li + sanitize(someArray[i]) + /li

While php would do something like:

ul id=List
?php foreach($someArray as $item):?
li?=sanitize($item)?/li
?php endforeach?
/ul

Granted, C# is a much nicer language than php, and when in php, I always
separate model and controller logic from the html view, but the
immediate mode of php embedding helps me avoid the awkwardness of
building html through string concatenations in another file. I get to
see the html structure exactly as it is.

This is where people usually jump in and suggest a templating system,
but I think it's silly to invent a second language when the first is
more than up to the task. I always find myself thinking: I know how to
do this in php or java, but how do I do this in the templating language?

I welcome counter-arguments. Maybe I can be enlightened?


No offense, but I don't even like the C# solution.  It's still mixing 
the formatting with code.  As I stated in a different reply in this 
thread, Perls Template::Recall on CPAN is the best templating solution 
I've found as it completely separates the template from the code.  Also, 
it's not tied to just HTML/XML, so it can be used for a variety of 
purposes.  Lastly, by having the separation of code and template, one 
person can be responsible for designing the HTML for the web page while 
another can populate the HTML.  If the HTML changes, it can be done in a 
way that the code does not change.


Casey

Re: why a part of D community do not want go to D2 ?

[klickverbot]

On 11/10/10 1:38 PM, klickverbot wrote:

I probably wouldn't get the problem anyway, and[…]


Whoops, s/and/as/ there…

Re: Apache mod_d needs C to instantiate D interpreter?

[Roman Ivanov]

== Quote from Nick Sabalausky (a...@a.a)'s article
 Eric Poggel dnewsgro...@yage3d.net wrote in message
 news:ibd00s$dl...@digitalmars.com...
  On 11/9/2010 7:25 PM, Nick Sabalausky wrote:
  I could probably live with that as long as the PHP template stayed
  view-only and didn't grow too much logic.
 
  Are there any web-friendly languages that are mature, offer the sanity and
  static typing of C#, and the immediate mode of php?
 I doubt it. The only php immediate mode stuff I'm aware of PHP itself, and
 classic-style ASP using either VBScript or JScript (And sort of ColdFusion,
 but you'd probably just be better off with PHP). The unpopularity of that
 style probably means that nothing else like that is in the works. And
 web-oriended languages seem to usually be dynamic aside from the Java and
 ASP.NET camps.

== Quote from Nick Sabalausky (a...@a.a)'s article
 Eric Poggel dnewsgro...@yage3d.net wrote in message
 news:ibd00s$dl...@digitalmars.com...
  On 11/9/2010 7:25 PM, Nick Sabalausky wrote:
  I could probably live with that as long as the PHP template stayed
  view-only and didn't grow too much logic.
 
  Are there any web-friendly languages that are mature, offer the sanity and
  static typing of C#, and the immediate mode of php?
 I doubt it. The only php immediate mode stuff I'm aware of PHP itself, and
 classic-style ASP using either VBScript or JScript

Ahem...

http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-razor.aspx

Re: Apache mod_d needs C to instantiate D interpreter?

[Adam Ruppe]

Eric Poggel wrote:
 Are there any web-friendly languages that are mature, offer the sanity and
 static typing of C#, and the immediate mode of php?


We could do it in D, somewhat easily. Here's an implementation with only mild
bugginess:

===

import std.file;
import std.string;
import std.stdio;
import std.process;

void main(string[] args) {
string imports = q{
import std.stdio;
import std.string;
import std.file;
import std.conv;
import std.algorithm;
import std.date;
};

string mainf = `void main(string[] args) {`;

bool inD = false;

string currentLiteral = ;

string currentPrinter = ;

void addToCurrentLiteral(string s) {
currentLiteral ~= s.replace(`, `~\`\~`);
}

void outputCurrentLiteral() {
if(currentLiteral.length == 0)
return;

mainf ~= writef(\%s\, `~currentLiteral~`);;

currentLiteral.length = 0;
}

void appendCode(string line) {
outputCurrentLiteral;
if(line.length  6  line[0..6] == import)
imports ~= line;
else
mainf ~= line;
}

foreach(ln; stdin.byLine) {
string line = ln.idup ~ \n;
  modeSwitch:
if(line.length == 0)
continue;
if(!inD) {
int idx = line.indexOf(?);
if(idx == -1) {
addToCurrentLiteral(line);
} else {
char c = line[idx+2];
switch(c) {
case 'd':

addToCurrentLiteral(line[0..idx]);
inD = true;
line = line[idx + 3 .. $];
goto modeSwitch;
break;
case '=':

addToCurrentLiteral(line[0..idx]);

int end =
line[idx+2..$].indexOf(?);
if(end == -1) throw new
Exception(?= ? must be on one line);
end += idx + 2;

outputCurrentLiteral;

mainf ~= `writef(%s,
`~line[idx+3..end].replace(``, `\`)~`);`;

line = line[end+2..$];
goto modeSwitch;
break;
default:
addToCurrentLiteral(line);
}
}
} else {
int idx = line.indexOf(?);

if(idx == -1) {
appendCode(line);
} else {
appendCode(line[0..idx]);
line = line[idx+2..$];
inD = false;
goto modeSwitch;
}
}
}

outputCurrentLiteral;

mainf ~= `}`;

std.file.write(/tmp/tempdprog.d, imports ~ mainf);

system(dmd -run /tmp/tempdprog.d);
}

===


Here's an example of use:

==

$ cat test.dhp
hello world
?d auto eat = eat me!; ?
this is awful
?=eat?
?d
string functionsWorkToo() {
return because nested functions rock!;
}

writeln(functionsWorkToo());
?
Bye!

===

And running it:

==
$ cat test.dhp | ./dhp
hello world

this is awful
eat me!
because nested functions rock!

Bye!




Of course, you'll want to add an automatic import for a cgi module so that's
available, and change the writefs to cgi.outs or whatever, but that's easy. (You
could use mine: http://arsdnet.net/dcode/cgi.d or your own)

The big bug I know of is if the ? appears in a quoted string it'll screw up. 
But
meh, it's a 15 minute implementation.



A huge improvement would be to send the code to rdmd instead of a temp file then
dmd like I did here. rdmd will cache the executable and give it a unique 
temporary
name so it will be faster and less prone to overwrites. But that just now came 
to
my mind...



To use it like php, you'd just add an apache handler to treat those dhp files 
as a
CGI application... and you might need to add a shebang to the top too so the OS
knows what program to run.

A tiny apache module could 

Re: Apache mod_d needs C to instantiate D interpreter?

[Radu]

On 11/8/2010 11:45 PM, JFD wrote:

A potential mod_d Apache module would go a long way to promote D language to
the web application world.

But it seems that implementing a mod_d Apache module may require that C
instantiates a D language interpreter (similar to Py_NewInterpreter() for
Python), or do the functionality of RDMD with compiled code caching, but in C.
  Is that possible?  (Presumably it might be possible to hack up a solution,
but could there be an officially supported way?)

I know that FastCGI with RDMD can do something similar, but a mod_d should
have higher system performance and scalability.

Thank you.  D is the best!  Keep up the good work.



My experience with Wt ( http://www.webtoolkit.eu/wt ) was quite nice.

Mind that its more than a simple template system and brings quite a few 
advanced idioms to the table like signal/slots, components, adaptive 
degradation for rendering ( uses Ajax and server push were available ).



They also have a nice set of ports for Java and Ruby, maybe D would fit 
nicely among them.


/Radu

Call to immutable method during immutable construction

[Jens Mueller]

Hi,

according to TDPL p. 294 the following call to fun should not be
allowed. But it compiles and I see not why that shouldn't be allowed. I think
it's a bug in TDPL but I'm unsure.

class A {
int a;
int[] b;
this() immutable {
a = 5;
b = [ 1, 2, 3 ];
fun();
}
void fun() immutable {
}
}

Any opinions?

Jens

Re: Apache mod_d needs C to instantiate D interpreter?

[Adam Ruppe]

Nick Sabalausky wrote:
 (but I've done worse - I once tried to build HTML
 buy manually adding nodes to an XML DOM...it seemed like a good idea
 until I actually started doing it).

This is actually one of the methods I've been using in my D web apps throughout
the year. It's not that bad if you extend DOM with D.

Compare:

auto table = cast(Table) document.getElementById(mytable);
assert(table !is null);

foreach(item; myArray) {
table.appendRow(th(item.id),
new Link(item.name, myappurl, [mode: view-item-details, id :
to!string(item.id)),
item.owner,
item.comments.brief);
}


With the godawful equivalent in Javascript. The DOM extensions also make
multi-page forms trivial:

auto form = cast(Form) document.getElementById(my-form);
assert(form !is null);

foreach(k, v; cgi.post)
form.setValue(k, v);


That adds all the data POSTed in to the form. form.setValue is smart enough to
work with existing fields, or add new ones as hidden inputs. (Existing fields
including check boxes, selects, radio groups, etc. It Just Works with just about
any html.)


I used to dread having to make edit capabilities.

input type=text name=whatever value=?= $myVal /

And setting myVal and repeating over and over and over and over and over and 
over
and over again. Then the hell:

input type=checkbox name=sucky ?php if(isset($_POST['sucky'])) echo
'checked=checked; else echo ''; ? /

Then hell isn't strong enough of a word.

selectoption value=1 ?= ($value == 1) ? selected : ?blah/option
REPEAT REPEAT REPEAT /select


Now, I can just use the two line loop and it works in all cases. Another huge
benefit of the extended dom is:

h2.innerText = myTitle;


The innerText property, a MS extension in Javascript, automatically escapes the
string for safe output (like all DOM methods, except for innerHTML itself) and 
is
easy to use.

No:

h2.appendChild(document.createTextNode(myTitle));

Ugh.





Anyway with a few little DOM extensions, this actually becomes quite usable. It
isn't always perfect, so my code also has variables in the template: {$myVar} in
the html and in the D, document.vars[myVar] = to!string(whatever); Naturally,
the template variables are all automatically escaped.



The last thing I added are a could special html tags and attributes.

include file=blah / to share template files.

table class=striped
ul class=striped

etc.etc. Elements with the striped class get every other relevant child marked
with class=odd, so I can add the color or whatever in the css file:

table.striped .odd { background-color: teal; color: red !important; }

(lol colors)

The program is smart enough to mark only the correct elements as .odd. If it is
ul.striped, it gets every other immediate li child. For a table, it goes for 
table
 tbody  tr.odd.

(This reminds me: document.getElementsBySelector() is a godsend extension too.)




But, generally, what other templates solve with loops or recursion, I try to 
solve
with classes and css. We've been live for 8 months now, and I haven't felt the
need to add looping to my template. The closest I have is:

list from=collection format=html output format for each element /

But even this very rarely actually specifies the format: the context-aware code
does the right thing in most situations, and when it doesn't, it tends to be a 
one
or two line DOM fixup anyway.


Doesn't this violate Model and View separation??? No, I don't think so. The 
HTML
at this level is extremely minimal, if any is specified in the code at all. It
only decorates the semantics of the data, which isn't really view related. Give 
it
just enough markup so the stylesheet can take over without needing to pull your
hair out.

I wonder how many of the HTML template solutions were made by people who don't
understand CSS. CSS can't really do all the work by itself, so you keep the html
framework around it, but when it comes down to styling individual data elements,
CSS is really very good at it. If you are changing the html to change your view 
at
that level, I'd say you're doing it wrong, template or no template.

Re: Passing dynamic arrays

[Steven Schveighoffer]

On Tue, 09 Nov 2010 15:13:55 -0500, Pillsy pillsb...@gmail.com wrote:


Steven Schveighoffer Wrote:


On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy pillsb...@gmail.com wrote:

[...]
 Ah! This is a lot of what was confusing me about arrays; I still  
thought

 they had this behavior. The fact that they don't makes me a good deal
 more comfortable with them, though I still don't like the
 non-deterministic way that they may copy their elements or they may
 share structure after you append stuff to them.



As I said before, this rarely affects code.  The common cases I've seen:



1. You append to an array and return it.
2. You modify data in the array.
3. You use a passed in array as a buffer, which means you overwrite the
array, and then start appending when it runs out of space.



I don't ever remember seeing:


You append to an array, then go back and modify the first few bytes of  
the

array.
I've certainly encountered situations in at least one other language  
where standard library functions will return mutable arrays which may or  
may not share structure with their inputs. This has been such a frequent  
source of pain when using that language that I tend to react very  
negatively to the possibility in any context.


Care to name names?  I want to understand this dislike of D arrays,  
because out of all the languages I've ever used, D arrays are by far the  
easiest and most intuitive to use.  I don't expect to be convinced, but at  
least we can have some debate on this, and maybe we can avoid mistakes  
made by other languages.



Let's assume this is a very common thing and absolutely needs to be
addressed.  What would you like the behavior to be?


Using a different, library type for a buffer you can append to. I think  
of a buffer or abstract list you can cheaply append to as a different  
sort of type from a fixed size buffer anyway, since it so often is a  
different type. Arrays/slices are a very basic type in D, and I'm  
generally thinking that giving your basic types simpler, easier to  
understand semantics is worth paying a modest cost.


There was a time when the T[new] idea was expected to be part of the  
language.  Both Andrei and Walter were behind it, and seldom does  
something not make it into the language when that happens.


It turns out, that after all the academic and theoretical discussions were  
finished, and it came time to implement, it was a clunky and confusing  
feature.  Andrei said that for TDPL he had a whole table dedicated to what  
type to use in which cases (T[] or T[new]) and he didn't even know how to  
fill out the table.


The beauty of D's arrays are that the slice and the array are both the  
same type, so you only need to define one function to handle both, and  
appending just works.  I feel like this is simply a case of 'not well  
enough understood.'


BTW, you can allocate a fixed buffer by doing:

T[BUFSIZE] buffer;

This cannot be appended to.  It is still difficult to allocate one of  
these on the heap, which is a language shortcoming, but it can be fixed.



[...]

IMO, the benefits of just being able to append to an array any time you
want without having to set up some special type far outweighs this  
little

quirk that almost nobody encounters.  You can append to *any* array, no
matter where the data is located, or whether the data is a slice, and it
just works.  I can't see how anyone would prefer another solution!


There's a difference between appending and appending in place. The  
problem with not appending in place (and arrays not having the  
possibility of a reserve that's larger than the actual amount, of  
course) is one of efficiency. Having


auto s = foo;
s ~= bar;

result in a new array being allocated that is of length 6 and contains  
foobar, and assigning that array to `s`, is obviously useful and  
desirable behavior. If the expansion can happen in place, that's a  
perfectly reasonable performance optimization to have in the case of  
strings or other immutable arrays. Indeed, one of the reasons that  
functional programming and GC go together like peanut butter and jelly  
is that together they let you get all sorts of wins in terms of  
efficiency from shared structure.


However, I've found working with languages that mix a lot of imperative  
and functional constructs (Lisp is one, but not the only one) that if  
you're going to do this, it's really very important that there not be  
any doubt about when mutable state is shared and when it isn't. D is  
trying to be that same kind of multi-paradigm language. This means that,  
for mutable arrays, having


int[] x = [1, 2, 3];
x ~= [4, 5, 6];


To leave no doubt about whether this reallocates or not try:

bool willReallocate = x.length + 3  x.capacity;

But I still don't understand this concept.  If you find out it's not going  
to reallocate, what are you going to do?  I mean, you have three cases  
here:


1. You *don't* want it to reallocate -- well, you can't 

Re: datetime review part 2 [Update 4]

[Steven Schveighoffer]

On Tue, 09 Nov 2010 18:48:30 -0500, bearophile bearophileh...@lycos.com  
wrote:



Yao G.:


Ugh. The datetime.d file is 1.5 MB? 0_o


So it will be very well tested :)  Look, the huge benefit of unit tests  
are that they are inline with the code.  Either you want that or you want  
small files, I don't understand the expectation that the file should be  
small and compact as long as the implementation is...


I 100% agree with Jonathan, just ignore the unit tests, and look at the  
API.  (BTW, this is where a nice doc generator like the one Tango uses  
would come in handy -- it shows the implementation if you click on the  
function name).



My suggestions:
- Keep only 5-10% of the tests inside the datetime.d module, and move  
the other 90-95% in a separated datetime test module.
- Use deterministic (repeatable) random data in a loop to perform some  
compact fuzzy testing
- Use alias or string mixing to greatly reduce the amount of text  
contained in the tests. Tuples help a lot. All those lines may be  
replaced with a single loop that contains something like:
assertEqual(SysTime(DateTime(z0, x1, x2, x3, x4, x5),  
FracSec.from!msecs(x6)).dayOfGregorianCal, x7)

Where the xn data comes from an array of typecons.Tuples like:
Data5(2010, 11, 1, 23, 59, 59, 999, 734_077)


Well, I'm not certain that this is the reason, but calendars are riddled  
with corner cases.  I would expect a well-tested date/time library to test  
all those corner cases.


I know when writing the Date/Time code for Tango, there were quite a few  
odd cases to test.


As long as the corner cases are tested, I think the rest of the fluff  
could possibly be reduced.  However, on the other hand, unit tests cost  
nothing except to make the low-file-size purists cringe :)  I say leave  
them all in, there are no requirements on the size and style of unit  
tests, just that they fully test the library.


-Steve

Re: What every D programmer really wants

[Steven Schveighoffer]

On Wed, 10 Nov 2010 00:37:49 -0500, Yao G. yao.go...@spam.gmail.com  
wrote:


On Tue, 09 Nov 2010 23:28:09 -0600, Andrew Wiley debio...@gmail.com  
wrote:



Please do not feed the trolls.


But he's the same troll :/ Using a bunch of socket puppets.


Are those IPV4 or V6 socket puppets?

-Steve

Is Walter tired of D?

[casualobserver]

His post seem reactionary rather that driving. Perhaps bearophile,
who seems to have quite some verve for D, should take the reigns?
What I'd like to see is Walter's and Bearophile's views on the
direction of D... the language, the process.. everything.

Re: why a part of D community do not want go to D2 ?

[Steven Schveighoffer]

On Wed, 10 Nov 2010 05:51:19 -0500, Jacob Carlborg d...@me.com wrote:

Of course that would be the preferred way, there should have been some  
kind of agreement for this (maybe there was but never fulfilled?) But  
you also have to look at it from Tangos point of view. Why would Tango  
drop support for anything that isn't DMD 32bit? Or should Tango keep  
half of it's runtime in it's own repository and for the other half use  
druntime.


I think this is the whole point of Jacob's that is being missed -- Tango  
supports LDC, GDC, and DMD, and druntime supports only DMD.  When druntime  
first was developed, it was a clone of Tango's runtime, but only with dmd  
support.  I can't remember why support for the other compilers was  
removed, but I don't think it was malicious in nature, I think it was a  
point of maintenance or lack of ownership.  I would expect that if someone  
wanted to support druntime for Tango (BTW, the D1 branch is still in  
druntime, just 2 years old) with LDC and GDC support, I don't think Sean  
would object.  But I can't speak for Sean...


But this aside, there was never any point for Tango to adopt druntime --  
phobos 1 was not going to adopt it, and Tango is not going to be ported to  
D2.  Compatibility is an academic pipe dream that will never occur.


-Steve

Re: why a part of D community do not want go to D2 ?

[Jacob Carlborg]

On 2010-11-10 12:43, retard wrote:

Wed, 10 Nov 2010 11:56:18 +0100, Jacob Carlborg wrote:


On 2010-11-10 00:00, Walter Bright wrote:

I agree. The reasons for the Tango split long ago, whatever the merit
of those reasons was, have long since passed. Producing another
incompatible split with D2 will not be of an advantage to anyone, and
will just give people reasons not to use D at all.

Jacob has recently decided to help out with improvements to druntime; I
take that as a very welcome sign towards ending the differences.


I don't want to increase any separation in the D community and would
hope peoeple could agree more. I have no problems what so ever
contributing both to Tango and Phobos/druntime. And I'm happy to license
any of my code to whatever license would be need for a give D project.


A dual licensing scheme for all code might help a bit (since both parties
refuse to switch licensing). There are also

  - stylistic issues (OOP style structured Tango vs quick'n'dirty Phobos
API) -  this causes annoying technical incompatibilities

  - psychological issues (Tango's charismatic leaders vs dull politically
correct office persons and almost anynomous lone coders porting Boost
code written in other languages). I believe strong personalities like Jon
Harrop and Paul Graham actually have an overall positive effect. It's not
a big secret that Andrei has boosted D's adoption quite a bit - this has
more to do with the strong personality than technical issues.

  - project management issues (Tango uses trac heavily and the leaders
have modern project management skills, Phobos developers have developed a
new inefficient ad-hoc software process model without the big picture
'planning' phase and without any communication between the team and the
product owner)

  - platform issues (not everyone agrees D2 is a perfect upgrade route -
how is this even surprising? Look at the number of people *not* using D,
it shouldn't be a surprise that there are people who dislike D2, but like
D1)

  - an axe fight between some key persons. I believe this can be solved if
there weren't those other annoying problems.

These are all my subjective opinions. Feel free to throw the first rock,
after all I'm just a stupid troll.

For me the technical issues have the greatest priority. If I want a full
flexible Java style stream I/O interface and these kind of things, there's
no way in hell I'll let you shove the Phobos style ideology down my
throat. I'd have to create a PhoTango wrapper to actually use these.

The political issues aren't that interesting. If I'm coding in Java or
C#, I don't even know the names of the stdlib developers. Maybe Doug Lea.
But he left Oracle for political reasons..


I basically agree with all this.

--
/Jacob Carlborg

Re: why a part of D community do not want go to D2 ?

[Walter Bright]

Jacob Carlborg wrote:
I don't want to increase any separation in the D community and would 
hope peoeple could agree more. I have no problems what so ever 
contributing both to Tango and Phobos/druntime. And I'm happy to license 
any of my code to whatever license would be need for a give D project.


This is great news! Thank you!

Re: why a part of D community do not want go to D2 ?

[Walter Bright]

retard wrote:
A dual licensing scheme for all code might help a bit (since both parties 
refuse to switch licensing). There are also


Releasing under the Boost license will make it compatible with both. Such is 
kinda the point with the Boost license, and why we chose it.



It's not 
a big secret that Andrei has boosted D's adoption quite a bit - this has 
more to do with the strong personality than technical issues.


Maybe, but Andrei's technical contribution has been very large. So has his book. 
Andrei's reputation in the programming community has been well earned through 
his technical contributions.

Re: What every D programmer really wants

[Yao G.]

On Wed, 10 Nov 2010 09:13:31 -0600, Steven Schveighoffer  
schvei...@yahoo.com wrote:



But he's the same troll :/ Using a bunch of socket puppets.


Are those IPV4 or V6 socket puppets?

-Steve


He he he. s/socket/sock

On a serious note, I think that they are IPV6 sockets.

--
Yao G.

Re: datetime review part 2 [Update 4]

[bearophile]

Steven Schveighoffer:

 Well, I'm not certain that this is the reason, but calendars are riddled  
 with corner cases.  I would expect a well-tested date/time library to test  
 all those corner cases.

I have never suggested to remove unit tests. But in several languages and 
projects there is the convention of moving the tests in a separated place when 
they become very large. Currently the unittest support in D doesn't allow to do 
this this well. So I suggest to improve the way DMD manages unittests, to allow 
a handy and safe move of them in another module, when the programmer desires so 
(named unittests are probably a good starting point for this).

Bye,
bearophile

Re: Is Walter tired of D?

[Yao G.]

On Wed, 10 Nov 2010 09:27:16 -0600, casualobserver c...@bigcorp.com wrote:


His post seem reactionary rather that driving. Perhaps bearophile,
who seems to have quite some verve for D, should take the reigns?
What I'd like to see is Walter's and Bearophile's views on the
direction of D... the language, the process.. everything.


Sight. You are too obvious. At least change your posting style :)

--
Yao G.

Re: why a part of D community do not want go to D2 ?

[lurker #5]

As a long time lurker I witnessed the last, rather infamous event when this 
topic
was brought up.
The way I see it the situation has only deteriorated further since then.
There are still resources spent on managing the political situation, to avoid
license infringement, supporting two libraries, duplicating code because of
license issues, not to mention the time spent on just discussing the situation.
Since the developers of the alternative standard library obviously have 
ulterior
motives, the only solution is to cut them out of the D ecosystem. This can be
easily achieved if Walter stopped showing this compassionate attitude toward 
them,
and started to officially not recommend the use of that library, in any public
forum where the issue is brought up. After a year of this their high attitude
would probably sink to the level where is belongs.
This would not undo the damage they had already done, but at least it would
neutralize any threat they represent to D2.

Re: Call to immutable method during immutable construction

[Jonathan M Davis]

On Wednesday, November 10, 2010 06:14:07 Jens Mueller wrote:
 Hi,
 
 according to TDPL p. 294 the following call to fun should not be
 allowed. But it compiles and I see not why that shouldn't be allowed. I
 think it's a bug in TDPL but I'm unsure.
 
 class A {
 int a;
 int[] b;
 this() immutable {
 a = 5;
 b = [ 1, 2, 3 ];
 fun();
 }
 void fun() immutable {
 }
 }
 
 Any opinions?

Well, regardless of what the correct behavior is, dmd is not entirely in line 
with TDPL yet, so there's a good chance that dmd just hasn't been updated to 
match TDPL yet.

Now, I'd have to read the appropriate section of the book again (and I don't 
have it on me at the moment) to be sure, but IIRC, the reasoning as to why 
calling fun() was illegal was because all member variables must be initialized 
in an immutable constructor only once, and they cannot be accessed before they 
are used, so you'd have to be sure that any other functions which  were called 
didn't access them (including any pre or post-conditions or the invariant), and 
the compiler is supposed to take the easy and simple route of simply 
disallowing 
calls to other member functions in an immutable constructor rather than trying 
to verify that the functions being called didn't access those variables 
(particularly since even if the functions being called didn't access any member 
variables, the functions that _they_ call could, and it could get pretty nasty 
to verify).

Now, it could be that this particular situation is still legal, because the 
compiler is able to see that you initialized all of the member variables 
_before_ calling fun().

If it's straightforward enough for the compiler to verify that you never call 
any member functions prior to initializing all member variables in an immutable 
constructor (and the compiler may _have_ to be able to be that smart anyway to 
guarantee that it initializes each member variable exactly once), then I don't 
see why it shouldn't be legal to call them after all member variables have been 
initalized, but I don't know if the compiler has to be that smart, and in 
reality, it's not actually valuable when you think about it. What could fun() 
actually do which would be useful? You're not returning anything from either it 
or the constructor, and it's immutable, so it can't alter any state anywhere. 
It 
would only make sense for it to be legal if all member variables had already 
been initialized, but at that point, there's no point to calling any other 
functions, since they'd have to be immutable and if they're immutable, you 
can't 
do anything with them except return a result, and since you're in an immutable 
constructor, and all member variables are already initialized, you can't do 
anything useful with that result.

So, while I don't necessarily see anything wrong with calling fun() in this 
situation being legal, I don't see the point.

- Jonathan M Davis

Re: why a part of D community do not want go to D2 ?

[Daniel Gibson]

lurker #5 schrieb:

As a long time lurker I witnessed the last, rather infamous event when this 
topic
was brought up.
The way I see it the situation has only deteriorated further since then.
There are still resources spent on managing the political situation, to avoid
license infringement, supporting two libraries, duplicating code because of
license issues, not to mention the time spent on just discussing the situation.
Since the developers of the alternative standard library obviously have 
ulterior
motives, the only solution is to cut them out of the D ecosystem. This can be
easily achieved if Walter stopped showing this compassionate attitude toward 
them,
and started to officially not recommend the use of that library, in any public
forum where the issue is brought up. After a year of this their high attitude
would probably sink to the level where is belongs.
This would not undo the damage they had already done, but at least it would
neutralize any threat they represent to D2.


Yeah right, that's gonna help. Walter acting like a douche will certainly 
attract people to use D2.

Re: why a part of D community do not want go to D2 ?

[FeepingCreature]

thank you oldtimer Wrote:

 oldtimer Wrote:
 
 Is it a coincidence that all the complaints seem to come from a single 
 person? Let's take a look at my killfile:
 
 ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz, bjarne 
 yesterday, blaise pascal, cal, chmod+x, crap, darth tango, domino, ellis 
 peters, foobar, gareth charnock, gcc-lurker, girlprogrammer, godworshipper, 
 gryphon, her3tic, jameskan, jane doe, jarett billingsley, jer, languagefan, 
 larry coder, lars ivar douchesund, levenshtein, lurker, nobody, oldtimer, 
 pipe dream, pointing hand, retard, retard++, retarded.clear(), scott, steveh, 
 superdan, user, wah, william t. fnk, yoda, typeerasure, uriel (reddit), 
 eternium (reddit), iliekcaeks (reddit), feepingcreature (reddit), 
 parametricpoly (reddit), nfxjfg (bugzilla), and many more!
 

Wow.

I must be INSANELY productive.

Maybe you should listen to me.

Re: datetime review part 2 [Update 4]

[Dmitry Olshansky]

On 10.11.2010 4:52, Jonathan M Davis wrote:

On Tuesday, November 09, 2010 17:34:15 Jonathan M Davis wrote:

On Tuesday, November 09, 2010 16:23:56 Yao G. wrote:

On Tue, 09 Nov 2010 18:11:59 -0600, Jonathan M Davis
jmdavisp...@gmx.com

wrote:

I think that the real question here is how good the API is.

I think that the sheer size of the library, specially with a datetime.d
file with almost 31,600 lines of code (granted, most of them are unit
test and documentation), makes a little difficult to analyze or give a
proper review of the code. It will takes a fair share time to do it.
Maybe that's why very few people has given criticism or suggestions. I
only gave a cursory view (you need to scroll a lot just to find the
implementation code), but I'll give it a more throughly review tonight.

That's quite understandable, but that's part of the reason that the ddoc
html files are there. You don't actually have to go trolling through the
code to look at the API.

I should probably add that it would be worth it for folks to just look at the
documentation for what they would generally try and do with a datetime module
and see whether they can do it reasonably well and what problems they'd have.
While looking at the module as a whole is definitely needed, just having folks
look at the portions that they'd use and commenting on that would be useful. Is
getting the time easy enough and intuitive enough? Is doing what you need to do
with time in basic applications once you have it easy or intuitive enough? Etc.

- Jonathan M Davis


OK, I looked through the docs, to me it's very solid. I fact I never 
written any code that heavily uses date-time stuff, most of the time I 
just converted everything to UNIX timestamp, and back to printable form, 
once the processing is done.


One suggestion about docs - since SysTime and DateTime have similar API, 
wouldn't it be better to merge documentation
and represent it in form of a table (like the one in std.container, 
unfortunately ATM  it's screwed up )?
 In the same table you could also place functions specific for SysTime, 
just add a remark to it.

Another one - group overloads together, consider for instance std.algorithm.
It doesn't leak all of it's template specializations for all kinds of 
ranges with the same ddoc comment.  You shouldn't i.e.

const pure bool_intersects_(in Interval/interval/);
Whether the given/interval/overlaps with this/interval/.
const pure bool_intersects_(in PosInfInterval!(TP)/interval/);
Whether the given/interval/overlaps with this/interval/.
...
It only could get you tired - there is no new information at all.
May I also humbly suggest you create the second table describing generic 
Interval notion (with specifics fro infinite ones marked as such).


And one more thing about the _API_ itself:
auto interval = Interval!Date(Date(2010, 9, 2), Date(2010, 9, 27));
auto func = IRange.everyDayOfWeek!Date(DayOfWeek.monday);
auto range = interval.fwdRange(func);

I'd preffer more simple and generic things, they tend to combine with 
std.algorothm so nicely (It's just an idea worth researching).
IMHO also could remove a ton of code from date-time, that do not belong 
here anyway.

My try at the code above would be:
auto interval = Interval!Date(Date(2010, 9, 2), Date(2010, 9, 27));
auto onlyMondays = filter!((x){ return x.dayOfWeek == DayOfWeek.monday });
auto range = onlyMondays (interval.by!days); //reuses the same 
convention for add and roll, more coherent


P.S. [Nitpicking]

Some typos in docs:
int_diffMonths_(in Date/rhs/);
... You can get the difference in _yours_ by subtracting the year 
property of two Dates,...
Should be years? Same thing in SysTime and DateTime, that just proves 
my earlier point - documentations for these could be merged.

---
struct_SysTime_;
_SysTime_is the type used when you want _to_ the current time from 
the system or if you're doing anything that involves time zones...

   Should be to get?

[/Nitpicking]

--
Dmitry Olshansky

Build Linux shared library from DMD

[Steve Teale]

In the Apache mod_d thread I saw:

gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0 libhello.a

Has anyone tried this with libphobos2.a?

std.crypto

[Steve Teale]

Has anyone got something that would be a nucleus for this?

Re: std.crypto

[Daniel Gibson]

Steve Teale schrieb:

Has anyone got something that would be a nucleus for this?



I've used http://www.dsource.org/projects/dcrypt with D1 (just simple HMAC-SHA1 
signing, so I can't tell how well the other stuff works).

Re: why a part of D community do not want go to D2 ?

[dsimcha]

== Quote from so (s...@so.do)'s article
 But a question comes to mind. For library development (or just everything
 if that matters) is the top down OOP approach ideal/right way?
 It is just an idiom that might have elegant solutions for certain tasks.

Frankly, for a library, I hate it in most cases.  Libraries need to make the
simple use cases sufficiently simple that people aren't tempted to roll their 
own.
 This means minimum boilerplate.  Don't make it a class if it can be a free
function.  Don't make me import/search through zillions of tiny modules when I'm
probably going to want to use most of them at the same time.  Don't make me
instantiate 15 layers of decorators just to read in a file line by line (*cough*
Java *cough).

When it comes to the more complicated use cases, trying to anticipate these is
rather difficult.  It's often not too hard to make complicated things possible 
by
writing an OO wrapper on top of a designed-for-simplicity API.  OTOH, if you 
need
to write a bunch of wrappers to avoid needing lots of boilerplate code in the
common cases, you've by definition failed at making simple things simple.

Re: Apache mod_d needs C to instantiate D interpreter?

[Nick Sabalausky]

Radu r...@foo.bar wrote in message news:ibe95h$gl...@digitalmars.com...
 On 11/8/2010 11:45 PM, JFD wrote:
 A potential mod_d Apache module would go a long way to promote D 
 language to
 the web application world.

 But it seems that implementing a mod_d Apache module may require that C
 instantiates a D language interpreter (similar to Py_NewInterpreter() for
 Python), or do the functionality of RDMD with compiled code caching, but 
 in C.
   Is that possible?  (Presumably it might be possible to hack up a 
 solution,
 but could there be an officially supported way?)

 I know that FastCGI with RDMD can do something similar, but a mod_d 
 should
 have higher system performance and scalability.

 Thank you.  D is the best!  Keep up the good work.


 My experience with Wt ( http://www.webtoolkit.eu/wt ) was quite nice.

 Mind that its more than a simple template system and brings quite a few 
 advanced idioms to the table like signal/slots, components, adaptive 
 degradation for rendering ( uses Ajax and server push were available ).


 They also have a nice set of ports for Java and Ruby, maybe D would fit 
 nicely among them.


Very interesting. Reminds me of ASP.NET in that it tries to work at 
stateful widget level, except (from a brief glance at the homepage) it 
looks like it may actually pull it off and be something I could actually 
trust. I'm definitely going to dig further into that.

Re: Ruling out arbitrary cost copy construction?

[Emil Madsen]

Make the syntax ugly? - so you cant avoid seeing it?

On 29 October 2010 19:40, Andrei Alexandrescu seewebsiteforem...@erdani.org
 wrote:

 On 10/29/10 12:18 CDT, dsimcha wrote:

 == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
 article

 To recap:
 1. Arbitrary cost copy construction:
 + Makes value types easy to define: just hook the copying code into
 this(this)
 + Is familiar to programmers coming from C++
 + If it fails, fails early, not surprisingly during a later operation


 BTW, I don't see why failing during a variable assignment is any less bad
 than
 failing during any other seemingly innocuous operation.


 One problem is that copying is often implicit and as such more difficult to
 see with the naked eye.

 Andrei




-- 
// Yours sincerely
// Emil 'Skeen' Madsen

Re: Build Linux shared library from DMD

[Jacob Carlborg]

On 2010-11-10 20:12, Steve Teale wrote:

In the Apache mod_d thread I saw:

gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0 libhello.a

Has anyone tried this with libphobos2.a?


Phobos cannot currently be used as a dynamic library. DMD cannot produce 
correct PIC for building dynamic libraries.


--
/Jacob Carlborg

Re: why a part of D community do not want go to D2 ?

[Walter Bright]

dsimcha wrote:

Libraries need to make the
simple use cases sufficiently simple that people aren't tempted to roll their 
own.


Hear hear. For example, one of the goals with D strings was to make them so good 
that people wouldn't invent their own string classes.

Re: why a part of D community do not want go to D2 ?

[Jacob Carlborg]

On 2010-11-10 21:42, Eric Poggel wrote:

On 11/10/2010 3:16 PM, dsimcha wrote:

Don't make it a class if it can be a free
function.


I agree with most of the others except for this one.

I can type Math. and instantly see my choices. It also helps namespace
conflicts without having to do selective imports or use the slightly
longer std.math.log


You can have renamed imports: import Math = std.math; and the you can 
use Math. as you want.


--
/Jacob Carlborg

Re: why a part of D community do not want go to D2 ?

[Eric Poggel]

On 11/10/2010 3:16 PM, dsimcha wrote:

Don't make it a class if it can be a free
function.


I agree with most of the others except for this one.

I can type Math. and instantly see my choices.  It also helps 
namespace conflicts without having to do selective imports or use the 
slightly longer std.math.log

Re: Apache mod_d needs C to instantiate D interpreter?

[Nick Sabalausky]

Nick Sabalausky a...@a.a wrote in message 
news:ibev09$1vf...@digitalmars.com...
 Radu r...@foo.bar wrote in message news:ibe95h$gl...@digitalmars.com...
 On 11/8/2010 11:45 PM, JFD wrote:
 A potential mod_d Apache module would go a long way to promote D 
 language to
 the web application world.

 But it seems that implementing a mod_d Apache module may require that 
 C
 instantiates a D language interpreter (similar to Py_NewInterpreter() 
 for
 Python), or do the functionality of RDMD with compiled code caching, but 
 in C.
   Is that possible?  (Presumably it might be possible to hack up a 
 solution,
 but could there be an officially supported way?)

 I know that FastCGI with RDMD can do something similar, but a mod_d 
 should
 have higher system performance and scalability.

 Thank you.  D is the best!  Keep up the good work.


 My experience with Wt ( http://www.webtoolkit.eu/wt ) was quite nice.

 Mind that its more than a simple template system and brings quite a few 
 advanced idioms to the table like signal/slots, components, adaptive 
 degradation for rendering ( uses Ajax and server push were available ).


 They also have a nice set of ports for Java and Ruby, maybe D would fit 
 nicely among them.


 Very interesting. Reminds me of ASP.NET in that it tries to work at 
 stateful widget level, except (from a brief glance at the homepage) it 
 looks like it may actually pull it off and be something I could actually 
 trust. I'm definitely going to dig further into that.


Hmm, I see it's GPL, though. Maybe it's unwarranted, but GPL makes me 
*really* nervous.

Re: why a part of D community do not want go to D2 ?

[so]

I agree with most of the others except for this one.

I can type Math. and instantly see my choices.  It also helps  
namespace conflicts without having to do selective imports or use the  
slightly longer std.math.log


You can get the same thing with a namespace/module named math, after all  
it is an IDE feature.


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Call to immutable method during immutable construction

[Jens Mueller]

Jonathan M Davis wrote:
 On Wednesday, November 10, 2010 06:14:07 Jens Mueller wrote:
  Hi,
  
  according to TDPL p. 294 the following call to fun should not be
  allowed. But it compiles and I see not why that shouldn't be allowed. I
  think it's a bug in TDPL but I'm unsure.
  
  class A {
  int a;
  int[] b;
  this() immutable {
  a = 5;
  b = [ 1, 2, 3 ];
  fun();
  }
  void fun() immutable {
  }
  }
  
  Any opinions?
 
 Well, regardless of what the correct behavior is, dmd is not entirely in line 
 with TDPL yet, so there's a good chance that dmd just hasn't been updated to 
 match TDPL yet.
 
 Now, I'd have to read the appropriate section of the book again (and I don't 
 have it on me at the moment) to be sure, but IIRC, the reasoning as to why 
 calling fun() was illegal was because all member variables must be 
 initialized 
 in an immutable constructor only once, and they cannot be accessed before 
 they 
 are used, so you'd have to be sure that any other functions which  were 
 called 
 didn't access them (including any pre or post-conditions or the invariant), 
 and 
 the compiler is supposed to take the easy and simple route of simply 
 disallowing 
 calls to other member functions in an immutable constructor rather than 
 trying 
 to verify that the functions being called didn't access those variables 
 (particularly since even if the functions being called didn't access any 
 member 
 variables, the functions that _they_ call could, and it could get pretty 
 nasty 
 to verify).

Right. That is why calling fun shouldn't be possible. So you say it's
not handled by dmd yet.

 Now, it could be that this particular situation is still legal, because the 
 compiler is able to see that you initialized all of the member variables 
 _before_ calling fun().

Right. That could also be the case. And my question is what is the case.
Is it the simple route that is not implemented at all or is it this more
advanced route that is already implemented?
I just checked by moving fun() to the beginning. Still works. Further
initializing a member in fun() is not allowed. But accessing a member in
fun works irrespective when it is called.
Actually I find this behavior better than the one defined in TDPL.

 If it's straightforward enough for the compiler to verify that you never call 
 any member functions prior to initializing all member variables in an 
 immutable 
 constructor (and the compiler may _have_ to be able to be that smart anyway 
 to 
 guarantee that it initializes each member variable exactly once), then I 
 don't 
 see why it shouldn't be legal to call them after all member variables have 
 been 
 initalized, but I don't know if the compiler has to be that smart, and in 
 reality, it's not actually valuable when you think about it. What could fun() 
 actually do which would be useful? You're not returning anything from either 
 it 
 or the constructor, and it's immutable, so it can't alter any state anywhere. 

You mean alter A's state. It could change something outside of A, couldn't it?

 It would only make sense for it to be legal if all member variables
 had already been initialized, but at that point, there's no point to
 calling any other functions, since they'd have to be immutable and if
 they're immutable, you can't do anything with them except return a
 result, and since you're in an immutable constructor, and all member
 variables are already initialized, you can't do anything useful with
 that result.

See above.

 So, while I don't necessarily see anything wrong with calling fun() in this 
 situation being legal, I don't see the point.

My main point is that I'd like to know what is implemented as in
mentioned TDPL and what isn't.
But I agree with you that calling an immutable member function from the
immutable constructor is probably less useful.

Jens

Re: why a part of D community do not want go to D2 ?

[Sean Kelly]

Jacob Carlborg Wrote:

 On 2010-11-09 23:04, Don wrote:
  Jacob Carlborg wrote:
  On 2010-11-09 17:43, Andrei Alexandrescu wrote:
  I wouldn't be surprised if Tango chose to turn away from compatibility
  for the second time (be it theoretical compatibility for now since there
  is no Tango for D2). The technical reasons are dwindling and became
  tenuous to argue for, but however weak they are, they could be used to
  promote a political motivation: a Tango/D2 offering would come again as
  an either-or proposition for a standard library that precludes usage of
  Tango2 and Phobos2 together. In my opinion that would be an extremely
  dangerous gambit.
 
  Clearly we don't see this in the same way. I see it like this, because
  Tango was first it's druntime that chose to turn away from compatibility.
 
  Sorry, that is completely false. druntime was created specifically to
  allow Phobos and Tango to co-exist. At the time, almost all of the code
  in druntime was written by Sean, and he was leading the Tango runtime
  development. The expectation was that Tango would continue to use Sean's
  runtime, it was just in a separate project.
 
 Of course that would be the preferred way, there should have been some 
 kind of agreement for this (maybe there was but never fulfilled?) But 
 you also have to look at it from Tangos point of view. Why would Tango 
 drop support for anything that isn't DMD 32bit? Or should Tango keep 
 half of it's runtime in it's own repository and for the other half use 
 druntime.

I maintained a D1 branch of druntime for ages thinking that it might be a good 
transition point for Tango, but no one ever used it.  I was also very careful 
to avoid creating any incompatibilities with the Tango runtime for quite a 
while, but finally had to choose between letting the library stagnate in 
anticipation of an event that would likely never happen and moving forward.  I 
do still try to avoid changing existing user-facing code though.  Also, if you 
compare the two now, I think you'll find that the Tango runtime has diverged 
from the original design far more than druntime, so there's little apparent 
interest there in facilitating a merge.  Either way, as there's been little 
apparent effort in porting Tango to D2, this whole discussion is moot.

  For this to work the Tango team and the druntime
  contributors/maintainers have collaborate and work together on a
  runtime.
 
  That runtime is druntime. If there is no understanding of that at Tango,
  that is suicide.
 
  Apparently not, since Sean ripped out all that wasn't necessary for
  Phobos but is necessary for Tango. Why are you blaming everything on
  Tango all the time?
 
  Sean took all the code he had written. The other minor contributors did
  not yet give permission for their code to be used, so of course it could
  not be included.
 
 I really think it's a shame they couldn't/wanted to give permission for 
 their code to be used.

There was another simpler reason as well, which was that I didn't want to 
speculatively maintain code for various compilers or whatever just in case they 
decided to use druntime one day.  It's far less effort to simply add whatever's 
needed when that day comes.  Also, I do still feel that the druntime SVN 
shouldn't have to be the repository used for every compiler runtime or garbage 
collector implementation.  That was necessary in Tango because Tango was an 
alternative library, so for any hope of Tango being used we had to do all the 
work ourselves.  It's far from being an optimal workflow however.

Re: Call to immutable method during immutable construction

[Jonathan M Davis]

On Wednesday 10 November 2010 13:01:55 Jens Mueller wrote:
 You mean alter A's state. It could change something outside of A, couldn't
 it?

I suppose that it could. I forgot about that. It's certainly not something that 
I'd ever think of doing. It would be bizarre to alter global state from a const 
or immutable function.

  So, while I don't necessarily see anything wrong with calling fun() in
  this situation being legal, I don't see the point.
 
 My main point is that I'd like to know what is implemented as in
 mentioned TDPL and what isn't.

I suspect that someone like Don or Walter would have to answer in this case. 
They're the most likely to know what the compiler is actually doing vs what 
they 
intend it to do. A bug report on it should likely be opened though, since it 
doesn't match TDPL. Either it needs to be fixed to match TDPL (which is likely 
in 
this case), or it needs to be made clear what behavior it's supposed to have, 
at 
which point the TDPL errata should be updated.

- Jonathan M Davis

Re: The D Scripting Language

[Tomek Sowiński]

Andrei Alexandrescu napisał:

 I'm having trouble thinking of something that would go in this module
 that wouldn't be a better fit somewhere else. What do you envision?
 
 I thought of it for a bit, but couldn't come up with anything :o). I
 think you're right!

Yeah, I think std.all would be just fine, or as Pelle proposed, a module 
publicly importing a first-aid kit for scripting.

 Someone proposed to add something like
 http://docs.python.org/library/fileinput.html to Phobos. I think it's a
 good idea. We have all mechanics in place (byLine/byChunk, chain). So it
 should be easy to define byLine to accept an array of filenames:
 
 import std.stdio;
 void main(string args[]) {
 getopt(args, ...);

Speaking of getopt, when writing the 'grep' snippet I missed anonymous options 
a lot:

bool h, i; string expr; string[] files;
getopt(args, h,h, i,i, expr, files);

They can be implemented with relatively little effort.

 foreach (line; File.byLine(args[1 .. $]) {
 ...
 }
 }
 
 I hypothetically made byLine a static method inside File to avoid
 confusing beginners (one might think on first read that byLine goes line
 by line through an array of strings).

The hipothetical version gave me exactly this impression. Moreover, the element 
type should be tuple(line, current file 
name or a pointer to File). So maybe File.byFileLine(...)?

-- 
Tomek

Re: The D Scripting Language

[Stanislav Blinov]

Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


foreach (line; File.byLine(args[1 .. $]) {
...
}
}

I hypothetically made byLine a static method inside File to avoid
confusing beginners (one might think on first read that byLine goes line
by line through an array of strings).


The hipothetical version gave me exactly this impression. Moreover, the element type should be tuple(line, current file 
name or a pointer to File). So maybe File.byFileLine(...)?




I too got confused. But personally, I don't like byFileLine either. 
Maybe something like Files range:


File.byLine(files(args[1..$])))

or

files(args[1..$]).byLine

?

Re: Apache mod_d needs C to instantiate D interpreter?

[Radu]

On 11/10/2010 10:47 PM, Nick Sabalausky wrote:

Nick Sabalauskya...@a.a  wrote in message
news:ibev09$1vf...@digitalmars.com...

Radur...@foo.bar  wrote in message news:ibe95h$gl...@digitalmars.com...

On 11/8/2010 11:45 PM, JFD wrote:

A potential mod_d Apache module would go a long way to promote D
language to
the web application world.

But it seems that implementing a mod_d Apache module may require that
C
instantiates a D language interpreter (similar to Py_NewInterpreter()
for
Python), or do the functionality of RDMD with compiled code caching, but
in C.
   Is that possible?  (Presumably it might be possible to hack up a
solution,
but could there be an officially supported way?)

I know that FastCGI with RDMD can do something similar, but a mod_d
should
have higher system performance and scalability.

Thank you.  D is the best!  Keep up the good work.



My experience with Wt ( http://www.webtoolkit.eu/wt ) was quite nice.

Mind that its more than a simple template system and brings quite a few
advanced idioms to the table like signal/slots, components, adaptive
degradation for rendering ( uses Ajax and server push were available ).


They also have a nice set of ports for Java and Ruby, maybe D would fit
nicely among them.



Very interesting. Reminds me of ASP.NET in that it tries to work at
stateful widget level, except (from a brief glance at the homepage) it
looks like it may actually pull it off and be something I could actually
trust. I'm definitely going to dig further into that.



Hmm, I see it's GPL, though. Maybe it's unwarranted, but GPL makes me
*really* nervous.




This wasn't a show stopper for me, but I can see your point. There are 
quite a few of nice things engineered in that framework and usually 
delivers what it claims.


If license is an issue a similar D framework can mimic those nice traits 
Wt has.


/Radu

Re: why a part of D community do not want go to D2 ?

[bearophile]

Eric Poggel:

 On 11/10/2010 3:16 PM, dsimcha wrote:
  Don't make it a class if it can be a free
  function.
 
 I agree with most of the others except for this one.

Object oriented programming is a way to think about code, so it may come more 
natural to you, or less natural, according to the way you think (often your 
first language matters a lot. If your first language was OOP then probably 
objects are more natural for you).

But in the end OOP was invented to face problems present in larger programs. OO 
is infrastructure that adds some complexity to reduce complexity in larger 
programs. It's not wise to add complexity unless it's necessary. So using a 
class where a free functions is enough may be over-engineering.

Bye,
bearophile

Re: Apache mod_d needs C to instantiate D interpreter?

[Nick Sabalausky]

sybrandy sybra...@gmail.com wrote in message 
news:ibbkh3$fv...@digitalmars.com...
 Ahh, I see that's written by the ANTLR/StringTemplate guy. I never read 
 that
 paper, but the docs for his StringTemplate were a big part of what 
 convinced
 me that template engines shouldn't try to be full-fledged imperative
 programming languages.



 I've done web development for a chunk of my career and I have to agree. To 
 me, there should be a clean separation between code and templates. 
 Templates that have looping in them are garbage to me as now you have 
 logic in two different places.

 The best templating solution that I've seen is Template::Recall for Perl 
 (http://search.cpan.org/~gilad/Template-Recall-0.15/lib/Template/Recall.pm)

 In this case, there is no logic in the template.  You render the 
 different parts of the template as needed and you have full control within 
 your code.  To me, something like this should be part of the standard 
 library as it would make outputting formatted text much easier in those 
 cases where there is a standardized format, like XML or HTML.


Judging by that link, yea, that sounds a lot like StringTemplate: 
http://www.antlr.org/wiki/display/ST/StringTemplate+Documentation

Re: why a part of D community do not want go to D2 ?

[Andrew Wiley]

On Wed, Nov 10, 2010 at 4:00 PM, bearophile bearophileh...@lycos.comwrote:

 Eric Poggel:

  On 11/10/2010 3:16 PM, dsimcha wrote:
   Don't make it a class if it can be a free
   function.
 
  I agree with most of the others except for this one.

 Object oriented programming is a way to think about code, so it may come
 more natural to you, or less natural, according to the way you think (often
 your first language matters a lot. If your first language was OOP then
 probably objects are more natural for you).

 But in the end OOP was invented to face problems present in larger
 programs. OO is infrastructure that adds some complexity to reduce
 complexity in larger programs. It's not wise to add complexity unless it's
 necessary. So using a class where a free functions is enough may be
 over-engineering.


One thought here:
If Tango is still useful in the D world but there isn't too much enthusiasm
about porting it to D2, why not break its functionality (that isn't already
in Phobos 2) down into a set of supplemental libraries that can be included
as needed? This would seem to give the best of both worlds because there is
no longer a runtime split, the functionality and APIs provided by Tango is
still available as needed, and porting becomes something that can easily be
done incrementally.
Thoughts? Criticisms? Denunciations?

Re: The D Scripting Language

[Andrei Alexandrescu]

On 11/10/10 1:45 PM, Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


I'm having trouble thinking of something that would go in this module
that wouldn't be a better fit somewhere else. What do you envision?


I thought of it for a bit, but couldn't come up with anything :o). I
think you're right!


Yeah, I think std.all would be just fine, or as Pelle proposed, a module 
publicly importing a first-aid kit for scripting.


Someone proposed to add something like
http://docs.python.org/library/fileinput.html to Phobos. I think it's a
good idea. We have all mechanics in place (byLine/byChunk, chain). So it
should be easy to define byLine to accept an array of filenames:

import std.stdio;
void main(string args[]) {
getopt(args, ...);


Speaking of getopt, when writing the 'grep' snippet I missed anonymous options 
a lot:

bool h, i; string expr; string[] files;
getopt(args, h,h, i,i,expr,files);

They can be implemented with relatively little effort.


Not getting the example. How would anonymous options work?


Andrei

Re: why a part of D community do not want go to D2 ?

[Jesse Phillips]

Walter Bright Wrote:

 dsimcha wrote:
  Libraries need to make the
  simple use cases sufficiently simple that people aren't tempted to roll 
  their own.
 
 Hear hear. For example, one of the goals with D strings was to make them so 
 good 
 that people wouldn't invent their own string classes.

And yet we still get those that want a class, or even limit the capability of 
arrays so that a class is more appealing. (Had a friend that hated the idea 
that D went back to array of characters, then he saw that arrays could actually 
do stuff)

Re: datetime review part 2 [Update 4]

[Tomek Sowiński]

Jonathan M Davis napisał:

 Latest: http://is.gd/gSwDv

My 2 cents:

Units of time are represented more naturally by an integer enum (could be 
anonymous) than a string.

A problem recurring in many methods:

/+ref+/ Date opOpAssign(string op, D)(in D duration) nothrow
if((op == + || op == -) 
   (is(Unqual!D == Duration) ||
is(Unqual!D == TickDuration)))
{
static if(op == +)
{
static if(is(Unqual!D == Duration))
return addDays(convert!(hnsecs, 
days)(duration.total!hnsecs));
else static if(is(Unqual!D == TickDuration))
return addDays(convert!(hnsecs, days)(duration.hnsecs));
}
else
{
static if(is(Unqual!D == Duration))
return addDays(convert!(hnsecs, 
days)(-duration.total!hnsecs));
else static if(is(Unqual!D == TickDuration))
return addDays(convert!(hnsecs, days)(-duration.hnsecs));
}
}

If you're static if'ing each statement, it's a good sign the method should be 
broken up into two overloads.
BTW, what was the problem with returning by ref?

As others pointed out, repetition hurts and hinders understanding repetition 
hurts and hinders understanding repetition 
hurts and hinders understanding repetition hurts and hinders understanding 
repetition hurts and hinders understanding 
repetition hurts and hinders understanding... :)

Finally, bordering on bikeshed, weekdays' names are long and months' are short. 
Having both short and long names for 
weekdays and months would solve the inconsistency and satisfy everyone.
 
 After some discussion on the runtime list, it was decided that core.time
 and std.datetime should share their Duration type, so I created time.d as
 a prospective core.time and moved or copied datetime's Duration and any
 other types or functions that it needed to time.d and made it so that
 datetime publically imports time. So, if accepted, time would become
 core.time, and datetime would become std.datetime.

Are there any plans for a Calendar interface to allow user implementations that 
distinguish business days and holidays?

 Also, since invariants can now be marked pure, I marked some of the
 invariants pure and increased the number of functions marked as pure.
 Unfortunately, due to the fact that many Phobos functions still aren't
 pure (to!() and format() in particular), as well as bug #5191, many
 functions that should be pure, aren't. But we're closer. Also, bug #4867
 continues to prevent SysTime from being able to be immutable, and a couple
 of bugs regarding invariants and templates make it so that a number of
 functions that should return ref this, can't.

Maybe I'm late on the 'pure' changes, but how come all the setters are pure? I 
mean it modifies the (hidden) argument of 
the function, so it shouldn't be, no?

-- 
Tomek

Re: why a part of D community do not want go to D2 ?

[Daniel Gibson]

Andrew Wiley schrieb:


One thought here:
If Tango is still useful in the D world but there isn't too much 
enthusiasm about porting it to D2, why not break its functionality (that 
isn't already in Phobos 2) down into a set of supplemental libraries 
that can be included as needed? 


Or just put it in one library and call it Tango2 or something like that ;)

(To allow porting of all kinds of Tango programs, about every Tango class would 
have to be ported to D2 anyway, so one could just as well do a proper port. 
Because of druntime it could coexist with Phobos2 - which was really the point 
of druntime for D2. Unfortunately nobody wanted to do this hitherto).

Re: why a part of D community do not want go to D2 ?

[Andrew Wiley]

On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson metalcae...@gmail.comwrote:

 Andrew Wiley schrieb:


 One thought here:
 If Tango is still useful in the D world but there isn't too much
 enthusiasm about porting it to D2, why not break its functionality (that
 isn't already in Phobos 2) down into a set of supplemental libraries that
 can be included as needed?


 Or just put it in one library and call it Tango2 or something like that
 ;)

 (To allow porting of all kinds of Tango programs, about every Tango class
 would have to be ported to D2 anyway, so one could just as well do a proper
 port. Because of druntime it could coexist with Phobos2 - which was really
 the point of druntime for D2. Unfortunately nobody wanted to do this
 hitherto).


Well, with Phobos 2, it may be that the cost of porting Tango no longer
outweighs the benefits of the extra functionality. My point was that it
doesn't have to be one large library that replaces Phobos, it could just be
a set of libraries ported as needed that provide the APIs that were most
useful in Tango.

Re: why a part of D community do not want go to D2 ?

[Andrew Wiley]

On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson metalcae...@gmail.comwrote:

 Andrew Wiley schrieb:


 One thought here:
 If Tango is still useful in the D world but there isn't too much
 enthusiasm about porting it to D2, why not break its functionality (that
 isn't already in Phobos 2) down into a set of supplemental libraries that
 can be included as needed?


 Or just put it in one library and call it Tango2 or something like that
 ;)

 (To allow porting of all kinds of Tango programs, about every Tango class
 would have to be ported to D2 anyway, so one could just as well do a proper
 port. Because of druntime it could coexist with Phobos2 - which was really
 the point of druntime for D2. Unfortunately nobody wanted to do this
 hitherto).


It's also worthy of note that I wasn't addressing the porting of Tango
programs specifically. The modular approach does lose there.

Re: why a part of D community do not want go to D2 ?

[Daniel Gibson]

Andrew Wiley schrieb:



On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson metalcae...@gmail.com 
mailto:metalcae...@gmail.com wrote:


Andrew Wiley schrieb:


One thought here:
If Tango is still useful in the D world but there isn't too much
enthusiasm about porting it to D2, why not break its
functionality (that isn't already in Phobos 2) down into a set
of supplemental libraries that can be included as needed?


Or just put it in one library and call it Tango2 or something like
that ;)

(To allow porting of all kinds of Tango programs, about every Tango
class would have to be ported to D2 anyway, so one could just as
well do a proper port. Because of druntime it could coexist with
Phobos2 - which was really the point of druntime for D2.
Unfortunately nobody wanted to do this hitherto).


It's also worthy of note that I wasn't addressing the porting of Tango 
programs specifically. The modular approach does lose there. 



I thought with [...] the functionality and APIs provided by Tango is still 
available as needed, and porting becomes something that can easily be done 
incrementally.

you meant porting Tango programs to D2, I'm sorry if I misunderstood.

I guess having some Tango modules (e.g. for Streams or XML) for D2 may be 
useful, until there are an adequate alternatives in Phobos.. but it would most 
probably harm the acceptance of these alternatives, once they're ready.

Re: The D Scripting Language

[Tomek Sowiński]

Andrei Alexandrescu napisał:

 Speaking of getopt, when writing the 'grep' snippet I missed anonymous
 options a lot:

 bool h, i; string expr; string[] files;
 getopt(args, h,h, i,i,expr,files);

 They can be implemented with relatively little effort.
 
 Not getting the example. How would anonymous options work?

// Let's match assignments.
auto args = [program.exe, .*=.*;, file1.d, file2.d, file3.d];
bool h, i; string expr; string[] files;
getopt(args, h,h, i,i, expr, files);
assert(!h);
assert(!i);
assert(expr == .*=.*;);
assert(files == [file1.d, file2.d, file3.d]);
assert(args == [program.exe]);

Staying conservative, anonymous options would only be allowed at the end of the 
option list, because their order matters (unlike named options). Perhaps this 
can 
be relaxed with time.

-- 
Tomek

Re: Build Linux shared library from DMD

[JFD]

== Quote from Jacob Carlborg (d...@me.com)'s article
 On 2010-11-10 20:12, Steve Teale wrote:
  In the Apache mod_d thread I saw:
 
  gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0 libhello.a
 
  Has anyone tried this with libphobos2.a?
 Phobos cannot currently be used as a dynamic library. DMD cannot produce
 correct PIC for building dynamic libraries.

GDC can build shared library (phobos works, too), but currently not DMD, it 
seems.
 Please see that other thread for more details.

Re: The D Scripting Language

[Andrei Alexandrescu]

On 11/10/10 3:58 PM, Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


Speaking of getopt, when writing the 'grep' snippet I missed anonymous
options a lot:

bool h, i; string expr; string[] files;
getopt(args, h,h, i,i,expr,files);

They can be implemented with relatively little effort.


Not getting the example. How would anonymous options work?


// Let's match assignments.
auto args = [program.exe, .*=.*;, file1.d, file2.d, file3.d];
bool h, i; string expr; string[] files;
getopt(args, h,h, i,i,expr,files);
assert(!h);
assert(!i);
assert(expr == .*=.*;);
assert(files == [file1.d, file2.d, file3.d]);
assert(args == [program.exe]);

Staying conservative, anonymous options would only be allowed at the end of the
option list, because their order matters (unlike named options). Perhaps this 
can
be relaxed with time.


I still don't see added value over the existing situation. Currently 
getopt leaves whatever wasn't an option in args[1 .. $] (without 
shuffling order), so the code above would simply use args[1] for expr 
and args[2 .. $] for files.



Andrei

Re: Apache mod_d needs C to instantiate D interpreter?

[JFD]

== Quote from Jacob Carlborg (d...@me.com)'s article
 On 2010-11-09 01:37, JFD wrote:
  Yes, you're right.  One should implement Apache module in D.
 
  One thing is that Apache module entry point expects a C function.  I've 
  figure
  that that one could just add extern(C) in front of D function to be 
  callable from
  C, so that was easy.  Also, Apache expects .so shared library, and one 
  could build
  it roughly like this:
 
  Let DMD build a .a library:
  dmd -fPIC -lib libhello.d
 
  Then convert it to shared library:
  gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0 libhello.a
 
  Could DMD build .so shared library directly (did I miss something)?
 
  Then it's all D from there on.  Cool!
 
  Thank you.
 Dynamic libraries doesn't work currently with DMD on Linux. They do work
 with DMD using Tango on Mac OS X where DMD also can build dynamic
 libraries directly (with the -dylib flag).

I did some tests, here's the result: Apache module (.so shared library) written 
in
C is working fine when linked with D shared library built by GDC (4.3.4), as
something like this:

gdc -fPIC -c libfoo.d -o libfoo.o
gdc -shared -Wl,-soname,libfoo.so.0 \
  -o libfoo.so.0.0 libfoo.o -lc

It looks like one could potentially also write the Apache module entirely in D,
too, after matching some data types, but I haven't tried it yet.

Too cool!  Someone could start writing Apache module for D language web
applications anytime... :)

I can call  GDC-built D shared library from C executable or C shared library
without problem.  And it's working with phobos.

It appears that DMD currently cannot create shared library on Linux, as you 
said.
 It can however create static library (.a) as above.  C executable program is
working fine with it.  But C shared library that calls D static library gets 
stack
error when the shared library is loaded.

Re: why a part of D community do not want go to D2 ?

[Jonathan M Davis]

On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:
 Walter Bright Wrote:
  dsimcha wrote:
   Libraries need to make the
   simple use cases sufficiently simple that people aren't tempted to roll
   their own.
  
  Hear hear. For example, one of the goals with D strings was to make them
  so good that people wouldn't invent their own string classes.
 
 And yet we still get those that want a class, or even limit the capability
 of arrays so that a class is more appealing. (Had a friend that hated the
 idea that D went back to array of characters, then he saw that arrays
 could actually do stuff)

Well, of course his first reaction was negative. Arrays suck in other languages 
in comparison to D. Having strings be arrays in C is horrible. I'd be annoyed 
to 
have strings be arrays if you were using Java arrays, and they're a definite 
improvement over C - if nothing else because they know their length. Strings as 
arrays work in D precisely because D arrays are so awesome. I've never used 
another language which had arrays which were even close to as awesome as the 
ones in D.

- Jonathan M Davis

Re: why a part of D community do not want go to D2 ?

[Andrew Wiley]

On Wed, Nov 10, 2010 at 5:43 PM, Daniel Gibson metalcae...@gmail.comwrote:

 Andrew Wiley schrieb:



 On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson metalcae...@gmail.commailto:
 metalcae...@gmail.com wrote:

Andrew Wiley schrieb:


One thought here:
If Tango is still useful in the D world but there isn't too much
enthusiasm about porting it to D2, why not break its
functionality (that isn't already in Phobos 2) down into a set
of supplemental libraries that can be included as needed?


Or just put it in one library and call it Tango2 or something like
that ;)

(To allow porting of all kinds of Tango programs, about every Tango
class would have to be ported to D2 anyway, so one could just as
well do a proper port. Because of druntime it could coexist with
Phobos2 - which was really the point of druntime for D2.
Unfortunately nobody wanted to do this hitherto).


 It's also worthy of note that I wasn't addressing the porting of Tango
 programs specifically. The modular approach does lose there.


 I thought with [...] the functionality and APIs provided by Tango is still
 available as needed, and porting becomes something that can easily be done
 incrementally.
 you meant porting Tango programs to D2, I'm sorry if I misunderstood.

 I guess having some Tango modules (e.g. for Streams or XML) for D2 may be
 useful, until there are an adequate alternatives in Phobos.. but it would
 most probably harm the acceptance of these alternatives, once they're ready.


Well, my assumption was that Phobos 2 was pretty much complete. If more
functionality is planned, then that's definitely a higher priority because
long term, that's a much better solution than any supplemental library.

And yes, D arrays are awesome. The best (solid) evidence I've seen of that
was the performance comparison on XML parsing where Tango utterly destroyed
every other major library.
I can also recall once when I was working on a Java project with the guy
that first introduced me to D, and he had a mysterious class called DArray
in his Java code with strange methods like slice. A month or so later, I
wound up making a similar class in another project.

Re: why a part of D community do not want go to D2 ?

[Jonathan M Davis]

On Wednesday, November 10, 2010 17:53:08 Andrew Wiley wrote:
 Well, my assumption was that Phobos 2 was pretty much complete. If more
 functionality is planned, then that's definitely a higher priority because
 long term, that's a much better solution than any supplemental library.

Goodness, no. Phobos is nowhere near complete. Whole modules such as std.json, 
std.xml, and std.stream are planned for deprecation in favor of newer 
implementations (which haven't been done yet). New modules are on the way - 
such 
as std.datetime and std.parallelism. std.container has almost nothing in it - 
SList and Array. It's supposed to get pretty much every container which would 
be 
considered fairly standard, but those implementations haven't been completed 
yet. std.algorithm continues to get tweaked all the time. Phobos is changing 
all 
the time.

Phobos is way better than it was, but it's far from done. There's plenty of 
work 
left to do on it. Eventually, what's there will likely stabilize to the point 
that even its ABI won't generally change (except presumably for major releases 
when necessary or when outright new functionality is added), but it's still in 
quite a bit of flux. The general API isn't even yet stable (though a lot of it 
doesn't change often). I fully expect that once Phobos is fully mature, it will 
rival Tango in every respect. But there's still a lot of work to be done on it.

- Jonathan M Davis

Thoughts on parallel programming?

[jfd]

Any thoughts on parallel programming.  I was looking at something about Chapel
and X10 languages etc. for parallelism, and it looks interesting.  I know that
it is still an area of active research, and it is not yet (far from?) done,
but anyone have thoughts on this as future direction?  Thank you.

Kill implicit joining of adjacent strings

[bearophile]

Do you seen anything wrong in this code? It compiles with no errors:

enum string[5] data = [green, magenta, blue red, yellow];
static assert(data[4] == yellow);
void main() {}


Yet that code asserts. it's an excellent example of why a sloppy 
compiler/language sooner or later comes back to bite your ass.
I've recently had another bug caused by automatic joining of adjacent strings. 
I think this is the 3rd I have found in my D code. This is enough.

In C the joining of adjacent strings is sometimes useful, but explicit is 
better than implicit, and D has a short and good operator to perform joining of 
strings, the ~, and D strings are allowed to span multi-lines.

C code ported to D that doesn't put a ~ just raises a compile time error that's 
easy to understand and fix. So this doesn't change the meaning of C code, just 
asks the programmer to improve the code, and the change requires is fully 
mechanical.

The compiler need to be able to perform the joining at compile time, so zero 
run-time overhead is present. The result is the same as before, it's just a 
syntax change.

My bug report has more info and a partial patch:
http://d.puremagic.com/issues/show_bug.cgi?id=3827

Despite Walter seems to ignore C#, C# is a very well designed language, 
polished, and indeed it refuses automatic joining of adjacent strings:

public class Test {
public static void Main() {
string s = hello  world;
}
}

That C# code gives the error:

prog.cs(3,35): error CS1525: Unexpected symbol `world'
Compilation failed: 1 error(s), 0 warnings

This is one of the about twenty little/tiny changes I am waiting for D.

So please kill automatic joining of adjacent strings in D with fire.

Thank you,
bearophile

Re: Thoughts on parallel programming?

[bearophile]

jfd:

 Any thoughts on parallel programming.  I was looking at something about Chapel
 and X10 languages etc. for parallelism, and it looks interesting.  I know that
 it is still an area of active research, and it is not yet (far from?) done,
 but anyone have thoughts on this as future direction?  Thank you.

In past I have shown here two large posts about Chapel, that's a language 
contains several good ideas worth stealing, but my posts were mostly ignored.

Chapel is designed for heavy numerical computing on multi-cores or multi-CPUs, 
it has good ideas of CPU-localization of the work, while D isn't much serious 
about that kind of parallelism (yet). So far D has instead embraced 
message-passing, that's fit for other purposes.

Bye,
bearophile

Re: Kill implicit joining of adjacent strings

[Brad Roberts]

Nagging is one way to accomplish change, but it's sure annoying.  If you feel
the feature is import, you know where to get the source.  Give it a shot.
Contribution of code is oh so much more valuable than a constant stream of you
should change...

Repeatedly claiming that Walter ignores 'X' is another way to get a reaction,
but it's also very annoying.  You're far from the only person to pull this card
out.  Do you _honestly_ believe he's that narrow minded or are you just trying
to get enough of a rise out of such claims that he'll drop what he's doing and
focus on your nag-of-the-day?

Sigh.. it get's old, fast.

Back to lurk mode,
Brad

On 11/10/2010 6:34 PM, bearophile wrote:
 Do you seen anything wrong in this code? It compiles with no errors:
 
 enum string[5] data = [green, magenta, blue red, yellow];
 static assert(data[4] == yellow);
 void main() {}
 
 
 Yet that code asserts. it's an excellent example of why a sloppy 
 compiler/language sooner or later comes back to bite your ass.
 I've recently had another bug caused by automatic joining of adjacent 
 strings. I think this is the 3rd I have found in my D code. This is enough.
 
 In C the joining of adjacent strings is sometimes useful, but explicit is 
 better than implicit, and D has a short and good operator to perform joining 
 of strings, the ~, and D strings are allowed to span multi-lines.
 
 C code ported to D that doesn't put a ~ just raises a compile time error 
 that's easy to understand and fix. So this doesn't change the meaning of C 
 code, just asks the programmer to improve the code, and the change requires 
 is fully mechanical.
 
 The compiler need to be able to perform the joining at compile time, so zero 
 run-time overhead is present. The result is the same as before, it's just a 
 syntax change.
 
 My bug report has more info and a partial patch:
 http://d.puremagic.com/issues/show_bug.cgi?id=3827
 
 Despite Walter seems to ignore C#, C# is a very well designed language, 
 polished, and indeed it refuses automatic joining of adjacent strings:
 
 public class Test {
 public static void Main() {
 string s = hello  world;
 }
 }
 
 That C# code gives the error:
 
 prog.cs(3,35): error CS1525: Unexpected symbol `world'
 Compilation failed: 1 error(s), 0 warnings
 
 This is one of the about twenty little/tiny changes I am waiting for D.
 
 So please kill automatic joining of adjacent strings in D with fire.
 
 Thank you,
 bearophile

Re: Kill implicit joining of adjacent strings

[Yao G.]

On Wed, 10 Nov 2010 20:34:07 -0600, bearophile bearophileh...@lycos.com  
wrote:



Do you seen anything wrong in this code? It compiles with no errors:

enum string[5] data = [green, magenta, blue red, yellow];
static assert(data[4] == yellow);
void main() {}


Yet that code asserts. it's an excellent example of why a sloppy  
compiler/language sooner or later comes back to bite your ass.


Stop blaming the compiler for your own carelessness.



In C the joining of adjacent strings is sometimes useful, but explicit  
is better than implicit, and D has a short and good operator to perform  
joining of strings, the ~, and D strings are allowed to span multi-lines.


I find it useful, and I like it. I like to break long strings into smaller  
ones
and put each one in one line. I know that you can do that using one single  
string, but

some syntax hightlighters don't like it that way.

Despite Walter seems to ignore C#, C# is a very well designed language,  
polished, and indeed it refuses automatic joining of adjacent strings:

[...]
This is one of the about twenty little/tiny changes I am waiting for D.


Maybe you should switch to C# :)


So please kill automatic joining of adjacent strings in D with fire.


No.


Thank you,
bearophile



--
Yao G.

Re: Thoughts on parallel programming?

[dsimcha]

== Quote from jfd (j...@nospam.com)'s article
 Any thoughts on parallel programming.  I was looking at something about Chapel
 and X10 languages etc. for parallelism, and it looks interesting.  I know that
 it is still an area of active research, and it is not yet (far from?) done,
 but anyone have thoughts on this as future direction?  Thank you.

Well, there's my std.parallelism library, which is in review for inclusion in
Phobos.  (http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html,
http://www.dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d)


One unfortunate thing about it is that it doesn't use (and actually bypasses) 
D's
thread isolation system and allows unchecked sharing.  I couldn't think of any 
way
to create a pedal-to-metal parallelism library that was simultaneously useful,
safe and worked with the language as-is, and I wanted something that worked
**now**, not next year or in D3 or whatever, so I decided to omit safety.

Given that the library is in review, now would be the perfect time to offer any
suggestions on how it can be improved.

Re: Kill implicit joining of adjacent strings

[Jonathan M Davis]

On Wednesday 10 November 2010 18:56:02 Brad Roberts wrote:
 Nagging is one way to accomplish change, but it's sure annoying.  If you
 feel the feature is import, you know where to get the source.  Give it a
 shot. Contribution of code is oh so much more valuable than a constant
 stream of you should change...
 
 Repeatedly claiming that Walter ignores 'X' is another way to get a
 reaction, but it's also very annoying.  You're far from the only person to
 pull this card out.  Do you _honestly_ believe he's that narrow minded or
 are you just trying to get enough of a rise out of such claims that he'll
 drop what he's doing and focus on your nag-of-the-day?
 
 Sigh.. it get's old, fast.

If nothing else, the sheer number of requests guarantees that they won't all be 
done even if they were all great and really should be done. Bearophile does 
have 
a lot of good things to say, but he says so much so often that sometimes it 
becomes hard not to just tune him out.

As for this particular request, I tend to agree. I don't see in point in 
adjacent strings concatenating. I never write my code that way, and it does 
seem 
error-prone. I'm not sure that I'm all that against it being in the language, 
but if it were my choice, I wouldn't have had it.

- Jonathan M Davis

Re: Kill implicit joining of adjacent strings

[Vladimir Panteleev]

On Thu, 11 Nov 2010 04:34:07 +0200, bearophile bearophileh...@lycos.com  
wrote:



So please kill automatic joining of adjacent strings in D with fire.


Yes please. I didn't even know this feature existed in D, but I was  
recently bitten by a bug in a C++ program - also due to a missing comma in  
an array of string literals.


Yao G.: use ~.

--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Kill implicit joining of adjacent strings

[so]

blue red


I guess it exists because of a few use cases other than this one.
For this particular example, you are right i couldn't see it and i checked  
two times!


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Kill implicit joining of adjacent strings

[bearophile]

Brad Roberts:

 Nagging is one way to accomplish change, but it's sure annoying.

Right. I was a little too much nervous, sometimes I need to control myself a 
little more :-)


 If you feel the feature is import, you know where to get the source.  Give it 
 a shot.

There is already a partial patch. And modifying just my own version of D is 
less than useless.


 Contribution of code is oh so much more valuable than a constant stream of 
 you
 should change...

Right.


 Repeatedly claiming that Walter ignores 'X' is another way to get a reaction,
 but it's also very annoying.  You're far from the only person to pull this 
 card
 out.  Do you _honestly_ believe he's that narrow minded or are you just trying
 to get enough of a rise out of such claims that he'll drop what he's doing and
 focus on your nag-of-the-day?

I don't fully understand you. He sometimes ignores 'X', but he's busy, so I 
don't expect him to know everything. This is why I have written this and other 
posts, to not let this X be ignored.

I am not asking to remove implicit joining of adjacent strings today, but I'd 
like this to be considered for future change.


 Sigh.. it get's old, fast.

I don't understamd this speech figure, sorry.

Bye,
bearophile

Re: Kill implicit joining of adjacent strings

[bearophile]

Yao G.:

 Stop blaming the compiler for your own carelessness.

If a simple common human error is avoidable at compile-time then it's the duty 
of the compiler to avoid it. Blaming the programmer is just silly (and it's 
against one of the main philosophical differences between C and D). I suggest 
you to read some books by Donald Norman about the design of everyday things, 
and their error-prone interfaces, that explain very well why you are very wrong:
http://en.wikipedia.org/wiki/Donald_Norman


 I find it useful, and I like it. I like to break long strings into smaller 
 ones
 and put each one in one line. I know that you can do that using one single  
 string, but
 some syntax hightlighters don't like it that way.

This string of yours:

string someText = I find it useful, and I like it. I like to break long 
strings into smaller ones
and put each one in one line. I know that you can do that using one single 
string, but
some syntax hightlighters don't like it that way.;

Now becomes:

string someText = I find it useful, and I like it. I like to break long 
strings into smaller ones ~
and put each one in one line. I know that you can do that using one single 
string, but ~
some syntax hightlighters don't like it that way.;

Bye,
bearophile

Re: Kill implicit joining of adjacent strings

[Pillsy]

so wrote:

  blue red

 I guess it exists because of a few use cases other than this one.

It's sometimes nice to be able to break up really long string literals, but it 
looks like it's mostly a C holdover. In C it helps with some preprocessor 
macros, but D doesn't have preprocessor macros, so the main reason for having 
it isn't there.

Either way, it's not exactly a make or break feature.

Cheers,
Pillsy

Re: Kill implicit joining of adjacent strings

[bearophile]

so:

 For 3 lines yes but how about a long file? Not everyone using vim!

There is very little D2 code around... and I don't think very large amounts of 
concatenated strings in the source code are a good programming practice.


 What about this one?
 
 red blue = error
 
 red
 blue = pass

That's a special case, special cases are bad for the programmer's diet :-)

Bye,
bearophile