date:20091014


Walter Bright wrote:
The main purpose of this is to correct a couple of regressions that were 
blocking QtD and Tango.


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.050.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.035.zip

Many thanks to the numerous people who contributed to this update.


Sweet, JSON output, looks like it wasn't very hard to write :)

Re: dmd 1.050 and 2.035 release

2009-10-14 Thread Walter Bright


Jeremie Pelletier wrote:

Sweet, JSON output, looks like it wasn't very hard to write :)


It was rather trivial. But it's a bit primitive right now. The problem 
is I'm not writing a consumer of this data, so I'm not sure what it 
should contain. Consider it as a trial balloon.


I'm interested in hearing from those who are making plugins to Vim, 
Emacs, source code browsers, etc., who can use this, and what more is 
needed.


I don't want to just throw in a grab-bag of cruft.

Re: dmd 1.050 and 2.035 release

Walter Bright:

Using DMD 2.035 I have tried to compile:

void main() {}

Using:

dmd -X temp.d

And the compiler crashes.

Regarding the -X name, isn't something like -json better? Or better to 
unify the switch for json output and normal ddoc output in some way.
Even better, DMD2 compilation switches may need a bit of global 
clean-up/rationalization (and they must be chosen taking in account the needs 
and constraints of the LDC compiler too, so both compilers can share all or 
most the same switches, simplifying the change of compiler a bit).

Bye,
bearophile

Re: Array literals' default type


Ellery Newcomer wrote:

Bill Baxter wrote:

foo((1,2)); // um, what?

You see that kind of thing in Python all the time, with NumPy at
least.  Array dimensions for example are set with a tuple.  So
   x = array((1,2), dtype=int)
And very common to see things like numpy.zeros((10,20)).


This is one place [of many] where you can't say, Oh, leave off the
parens and it's a comma exp. That leaves me in the lurch.


When offered semantic ambiguity, just say no.

You didn't really show any examples of ambiguity that I could see.
Some of those examples may have a legal meaning in C, so that's an
issue if so.



If you try to add tuple expressions AND keep comma expressions, you
either can't recurse from paren exp to comma exp (or any exp, really) or
you have semantic ambiguity. If you can't recurse comma exps, they're
nothing more than semicolons. Worthless, so you might as well remove them.

Or you have to introduce a new syntax.

aside

Actually, making comma exp a little uglier might be an appealing
solution. something like

CommaExp - , CommaExp
CommaExp - AsgExp

gives you

auto a = (,1,2); // a = 2
auto a = (1,2); // a = (1,2)

You still have the problem of ( nonCommaExp ), though. And
user-friendliness issues.

I'm sure others could think of better ideas.


You do NOT need to keep the comma operator. What you do need to do, 
though, is make sure that any use of , doesn't silently produce 
different behaviour to what it would do in C.

Re: Amusing D facts: typesafe variadic arrays are lazy!

2009-10-14 Thread downs

Jeremie Pelletier wrote:
 Andrei Alexandrescu wrote:
 Chris Nicholson-Sauls wrote:
 downs wrote:

 Here is a funny consequence of this amusing fact:

 if you overload opAssign in a struct with lazy T[] dgs..., you can
 achieve the following syntax


 WithFlag(GL_BLEND, true) = WithDepthMask(false) = tex.With =
 Quads = {
   foreach (i, q; qa) {
 float f = 1f*i / qa.length; Color(1f-f, f, 1f);
 TexCoord(0f, 0f); Vertex(q.points[0]);
 TexCoord(1f, 0f); Vertex(q.points[1]);
 TexCoord(1f, 1f); Vertex(q.points[3]);
 TexCoord(0f, 1f); Vertex(q.points[2]);
   }
 };

 That's... just beautiful...

 -- Chris Nicholson-Sauls

 Not getting it... could someone please explain?

 Andrei
 
 From what I get, he has something like this:
 
 struct WithFlag(int OP, bool enable) {
 static void opAssign(T)(lazy T next) {
 static if(enable) glEnable(OP);
 else glDisable(OP);
 next();
 }
 }
 
 struct WithDepthMask(bool enable) {
 static void opAssign(T)(lazy T next) {
 glDepthMask(enable);
 next();
 }
 }
 
 struct Tex {
 void opAssign(T)(lazy T next) {
 glBindTexture(_tex);
 next();
 }
 }
 
 struct Quads {
 static void opAssign(T)(lazy T commands) {
 glBegin(GL_QUADS);
 commands();
 glEnd();
 }
 }
 
 I don't know if thats his exact code, but from what I can remember of gl
 from memory it should look like this.
 
 Jeremie

Very close. There's another workaround required to enable the = {} syntax.


The T in question can either be a void, in which case we're assigning a 
function call, or a void delegate(), in which case we're assigning a subscope.

Because the parameter is lazy, in the case of void delegate() we actually have 
to call it doubly nestedly!

This leads to the following code.

 const string LazyCall=
 static if (is(T==void)) t();
 else static if (is(T==void delegate())) t()();
 else static assert(false, T.stringof);
 ;

...


 template PrimitiveScope(string NAME, string WHICH) {
   const string PrimitiveScope=struct ~NAME~ {
 static void opAssign(T)(lazy T t) {
   glBegin(~WHICH~); scope(exit) glEnd();
   ~LazyCall~
 }
   };
 }

...

 mixin(Concat!(MAP!(PrimitiveScope, 2,
   Points, GL_POINTS, Lines, GL_LINES,
   LineLoop, GL_LINE_LOOP, LineStrip, GL_LINE_STRIP,
   Triangles, GL_TRIANGLES, TriangleStrip, GL_TRIANGLE_STRIP,
   TriangleFan, GL_TRIANGLE_FAN, Quads, GL_QUADS,
   QuadStrip, GL_QUAD_STRIP, Polygon, GL_POLYGON
 )));

:deranged grin: I love templates!

Re: Get name of alias parameter at compile time?

2009-10-14 Thread Jacob Carlborg


On 10/14/09 06:36, dsimcha wrote:

Is there a way to get the name of an alias parameter at compile time?  For
example:

void doStuff() {
 // Do stuff.
}

void templ(alias fun)() {
writeln(fun.stringof);  // Prints doStuff.
}


Do you want that to print fun instead of doStuff?

Re: Revamped concurrency API

Bartosz Milewski:

It's good to know that my ideas are still circulating in the D community. 
Thanks, guys!

They will keep circulating! And there's not just D in computer science, future 
computer languages may use your ideas. Someday I'll design my own C-like 
language, simpler (and more limited in scope) than D ;-)


Since I'm now put on the spot, I have to explain my recent detachment from D.

This makes me (and surely many other persons here) a little sad. 

D is an engineering project, and it's not small. And the first thing to learn 
about all sizeable real-world engineering projects (like the creation of a 
large bridge, or many other things) is that they are first of all politics. 
They are not the result of rationality, even if often some rationality is 
required. All large engineering project come out of a large amount of 
compromises. If you pretend to see one of such systems to come out of 
rationality alone, you will never see a real one. 

So every time you have to fight for the rationality to prevail, and you have to 
be ready to accept some compromises. It's life.


it's hard for me to subscribe to the good enough philosophy (as long as it's 
better that C++, it's fine for D).

D language is largely grown, and not designed. D is not Scala or Haskell. I 
think there is not enough brain mass in this group to design rationally a 
C++-class language. Probably there's not even brain mass to design a 
Python-class language. D2 will surely have a big amount of design mistakes, 
every one here can list you some of them. But one of the best qualities of 
Walter is that he's not frozen, he sometimes seems to move very slowly, but he 
never stops moving, and usually he eventually sees the light (and when this 
happens it's usually a small surprise for everyone else, like the show of a 
rabbit pulled out of a hat). So I think some of the design mistakes of D2 will 
be fixed in D3 :-)


My impression is that, as the release of D2 and the publication of Andrei's 
book are nearing, this attitude is gaining ground. I try to fight this 
attitude but it's an uphill battle. Or, as Andrei puts it, I start whining and 
give up ;-).

Andrei's book comes too much early, forcing rhythms that I think aren't good 
for D2. On the other hand no software is ever finished, it's just abandoned. 
And you must not think of D2 as the finished product :-) You may even think of 
D2 as just a bridge toward D3 :-) D2 is probably just an experiment, to 
experimentally see what design ideas are good and what to throw away and 
redesign. And such things are slow. So you may want to come back in few years, 
to try to improve the concurrency design of D3 :-)


The semantics of shared. I can live with postponing the implementation of 
the race-free type system, but not with the compiler inserting barriers around 
all shared reads and writes, even inside synchronized sections.

This is a topic that can be discussed. If enough people think this is a 
problem, then eventually Walter may change his mind, or he may design something 
better, etc. If no one discussed problems they can't be fixed/improved. I know 
that discussing things and accepting compromises is a pain, but it's an 
inevitable pain. Rationality alone usually never wins, you need politics too.


The C++-derived template metaprogramming mess. Especially when C++0x provides 
better support for variadic templates than D (see my upcoming blog). I fought 
successfully for non-functional approach to string mixins. The same is needed 
for more general templates. In my opinion, there should not be any part of the 
language that is understandable only by seasoned library writers.

Again, this seems a small piece of D2, so it may be fixed if enough people 
think this is bad. You can explain what do you want to change here, and people 
will see and think. Eventually it may even be fixed.


The better than Java aspect of D ignores the latest development in Java. In 
particular the work on non-null pointers

We have discussed weeks about nonnull references in D (and I have even 
discussed about nonnull pointers too), I have done my best. A good percentage 
of people have said that they like to try this idea. Walter in the end was not 
interested (I think). But maybe in future the situation will change. There's 
always hope on this. At the end I have seen no one say This is a totally wrong 
idea and will never see the light in D.


and the use of annotations for type-system extensions. Annotations are being 
added to D as we speak because it finally became obvious that no amount of 
cleverness can make object properties work without additional syntax. So the 
patching begins, without a clear vision of the role of annotation in future D.

Annotations in D are just an embryo, and I think they come from no design yet, 
they are just a bit copied from Java. If you have a vision for their role in D, 
then it's a very good moment to talk and show such vision. I am sure we will be

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Lars T. Kyllingstad


Don wrote:

Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign 
don't seem to be up to snuff because they don't catch operations like


a[b] += c;

with reasonable expressiveness and efficiency.

Last night this idea occurred to me: we could simply use overloading 
with the existing operator names. Consider:


a += b

gets rewritten as

a.opAddAssign(b)

Then how about this - rewrite this:

a[b] += c

as

a.opAddAssign(b, c);

There's no chance of ambiguity because the parameter counts are 
different. Moreover, this scales to multiple indexes:


a[b1, b2, ..., bn] = c

gets rewritten as

a.opAddAssign(b1, b2, ..., bn, c)

What do you think? I may be missing some important cases or threats.


Andrei


Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.

The indexing thing was something I didn't have a solution for.

BTW we need to deal with slices as well as indexes. I think the way to 
do this is to make a slice into a type of index.



I like the idea of enforcing relationships between operators. In fact, I 
think we can take it even further, and require that operator overloading 
in general *must* follow mathematical rules, and anything else leads to 
undefined behaviour. For example, if n is an integer, a and b are 
scalars, and x and y are general types, the compiler should be free to 
rewrite


 n*x  --  x + x + ... + x--  2*x + 2*x + ...
x^^n  --  x * x * ... * x--  x^^2 * x^^2 * ...
   x/a + y/b  --  (b*x + a*y)/(a*b)

and so on, based on what it finds to be the most efficient operations. 
(Note how I snuck my favourite suggestion for an exponentiation operator 
in there. I *really* want that.)


-Lars

Re: A possible solution for the opIndexXxxAssign morass

Don:

 BTW we need to deal with slices as well as indexes. I think the way to 
 do this is to make a slice into a type of index.

Such slice also needs a way to specify the end of the enclosing interval, the $ 
syntax.
Slice may enjoy a lot a third optional argument (default = 1), that represents 
the stride.

(In the Chapel language all this is generalized into the concept of Domain, 
that I think is a good language feature to introduce in D).

Bye,
bearophile

So many years I was following D...

2009-10-14 Thread Iamgottingcrazy

Should I bear this??

module teststructarray;

import std.stdio;
import core.stdc.stdlib:system;

struct Point
{
  int x;
  int y;
}
static Point[2] pArray1=
[
  {0,0},{0,1},//watch here!
];

static Point pArray2[2][3]=
[
  [{0,0},{0,1},{0,2}],
  [{1,0},{1,1},{1,2}],//watch here,without the last comma,the prog can't get 
compiled!!
];
void main()
{
  foreach(int i,point;pArray1)
writefln(Point(%d)={%d,%d},i,pArray1[i].x,pArray1[i].y);
  
  foreach(points;pArray2)
  {
foreach(point;points)
{
  writef(Point(%d,%d)\t,point.x,point.y);
}
write(\n);
  }
  system(pause);//watch when this line gets executed
}

Try compile and run.

Re: A possible solution for the opIndexXxxAssign morass


Lars T. Kyllingstad wrote:

Don wrote:

Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign 
don't seem to be up to snuff because they don't catch operations like


a[b] += c;

with reasonable expressiveness and efficiency.

Last night this idea occurred to me: we could simply use overloading 
with the existing operator names. Consider:


a += b

gets rewritten as

a.opAddAssign(b)

Then how about this - rewrite this:

a[b] += c

as

a.opAddAssign(b, c);

There's no chance of ambiguity because the parameter counts are 
different. Moreover, this scales to multiple indexes:


a[b1, b2, ..., bn] = c

gets rewritten as

a.opAddAssign(b1, b2, ..., bn, c)

What do you think? I may be missing some important cases or threats.


Andrei


Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.

The indexing thing was something I didn't have a solution for.

BTW we need to deal with slices as well as indexes. I think the way to 
do this is to make a slice into a type of index.



I like the idea of enforcing relationships between operators. In fact, I 
think we can take it even further, and require that operator overloading 
in general *must* follow mathematical rules, and anything else leads to 
undefined behaviour. For example, if n is an integer, a and b are 
scalars, and x and y are general types, the compiler should be free to 
rewrite


 n*x  --  x + x + ... + x--  2*x + 2*x + ...
x^^n  --  x * x * ... * x--  x^^2 * x^^2 * ...
   x/a + y/b  --  (b*x + a*y)/(a*b)

and so on, based on what it finds to be the most efficient operations. 


Unfortunately, the last one doesn't work for reals. a*b could overflow 
or underflow.

x/ real.max + y / real.max   is exactly 2.0 if x and y are both real.max
But
(real.max * x + real.max *y)/(real.max * real.max) is infinity/infinity 
= NaN.


The others don't always work in general, either. I'm worried about 
decimal floats. Say n==10, then it's an exact operation; but addition 
isn't exact. It always works for n==2, since there's at most one 
roundoff in both cases.


But I do feel that with floating-point, we've lost so many identities, 
that we must preserve every one which we have left.


(Note how I snuck my favourite suggestion for an exponentiation operator 
in there. I *really* want that.)


I want it too. Heck, I might even make a patch for it g.

Re: So many years I was following D...

Iamgottingcrazy:

 Should I bear this??

With D1 it seems to work:
http://codepad.org/hpslrHHs

Bye,
bearophile

Re: Revamped concurrency API

Bartosz Milewski wrote:

Nick B Wrote:

Nick B wrote:

Andrei Alexandrescu wrote:

bearophile wrote:

Andrei Alexandrescu:

Unfortunately, Bartosz has declined to contribute.

I have read a good amount of his interesting blog posts, he has shown
me many things I didn't know about. And he was very happy about the
idea of helping D concurrency. Do you know why he has changed his
mind regarding this? Maybe because Walter has refused the
uniqueness/lend ideas?

You may want to email Bartosz and ask him.

Andrei

I will ask him, via his blog, and then will post the link.

Nick B.

here it is.

http://bartoszmilewski.wordpress.com/2009/09/22/ownership-systems-against-data-races/#comment-922

Nick B.

It's good to know that my ideas are still circulating in the D community. Thanks, guys!

Since I'm now put on the spot, I have to explain my recent detachment from D.

I didn't so much decline to contribute as hit a wall. I'm a bit of a perfectionist and it's hard for me to subscribe to the good enough philosophy (as long as it's better that C++, it's fine for D). My impression is that, as the release of D2 and the publication of Andrei's book are nearing, this attitude is gaining ground. I try to fight this attitude but it's an uphill battle. Or, as Andrei puts it, I start whining and give up ;-).

Please stay in touch, we will try to win you back...

Of the issues you mention, this one seems the easiest to address:

As far as my thread work went, I had an almost working implementation of spawn,
except for a nasty compiler bug which resisted all efforts to reduce it to a
simple test case.

Could you give us _any_ kind of test case (even if it's enormous)?

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Lars T. Kyllingstad


Don wrote:

Lars T. Kyllingstad wrote:

Don wrote:

Andrei Alexandrescu wrote:
Right now we're in trouble with operators: opIndex and opIndexAssign 
don't seem to be up to snuff because they don't catch operations like


a[b] += c;

with reasonable expressiveness and efficiency.

Last night this idea occurred to me: we could simply use overloading 
with the existing operator names. Consider:


a += b

gets rewritten as

a.opAddAssign(b)

Then how about this - rewrite this:

a[b] += c

as

a.opAddAssign(b, c);

There's no chance of ambiguity because the parameter counts are 
different. Moreover, this scales to multiple indexes:


a[b1, b2, ..., bn] = c

gets rewritten as

a.opAddAssign(b1, b2, ..., bn, c)

What do you think? I may be missing some important cases or threats.


Andrei


Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.

The indexing thing was something I didn't have a solution for.

BTW we need to deal with slices as well as indexes. I think the way 
to do this is to make a slice into a type of index.



I like the idea of enforcing relationships between operators. In fact, 
I think we can take it even further, and require that operator 
overloading in general *must* follow mathematical rules, and anything 
else leads to undefined behaviour. For example, if n is an integer, a 
and b are scalars, and x and y are general types, the compiler should 
be free to rewrite


 n*x  --  x + x + ... + x--  2*x + 2*x + ...
x^^n  --  x * x * ... * x--  x^^2 * x^^2 * ...
   x/a + y/b  --  (b*x + a*y)/(a*b)

and so on, based on what it finds to be the most efficient operations. 


Unfortunately, the last one doesn't work for reals. a*b could overflow 
or underflow.

x/ real.max + y / real.max   is exactly 2.0 if x and y are both real.max
But
(real.max * x + real.max *y)/(real.max * real.max) is infinity/infinity 
= NaN.


Good point. I am thinking like a mathematician, not a programmer. :)


The others don't always work in general, either. I'm worried about 
decimal floats. Say n==10, then it's an exact operation; but addition 
isn't exact. It always works for n==2, since there's at most one 
roundoff in both cases.


But the case x*2 -- x+x would also likely be the most common in terms 
of optimisation, right?



But I do feel that with floating-point, we've lost so many identities, 
that we must preserve every one which we have left.


(Note how I snuck my favourite suggestion for an exponentiation 
operator in there. I *really* want that.)


I want it too. Heck, I might even make a patch for it g.


If you do, make sure to announce it loudly and clearly on the NG. Don't 
want to miss it. ;)


-Lars

DIP6

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

Java's syntax has the advantage of having to type less when the annotation has 
no arguments: @annotation vs. [annotation].

In both cases you have a two-keys overhead.

Re: A possible solution for the opIndexXxxAssign morass

Robert Jacques Wrote:

 Also needed is an extension of the opDollar to return different values  
 based on the index:
 opDollar(size_t index);

Dollar is just a synonym for length, isn't it?

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Lars T. Kyllingstad


Kagamin wrote:

Robert Jacques Wrote:

Also needed is an extension of the opDollar to return different values  
based on the index:

opDollar(size_t index);


Dollar is just a synonym for length, isn't it?



Yes, but if opIndex and opSlice take multiple indices (like in a matrix) 
opDollar needs a way to distinguish between the different dimensions.


-Lars

New XML parser written for D1 and D2. - XMLP_01.zip (0/1)

2009-10-14 Thread Michael Rynn



I made a validating or optionally none validating XML parser in D.

It can read and parse  files and external dtds and entities with
differrent BOM and encodings.

This xmlp (XmlPieceParser class) passes 100% on both validating and
non-validating modes for the following test sets:- oasis, sun, xmltes
and  ibm.  I have not dared to try any of the xml 1.1 or other tests.
The warnings given by, if you choose to intercept them,  for not
well-formed or  non-valid documents may not necessarily be
illuminating.

My brief try of a modified std.xml against some of these tests led me
to chuck it, as I learned more what the parser is actually supposed to
do.  This one is all my own mistakes and bad coding habits, written
from near scratch, after giving up on std.xml, and taking what I could
from std.encoding.
I have also made a front end xmlp.delegator module that emulates the
delagate callback model of std.xml.

To use, you need to have a class derived from  XmlParserInput, of
which there are two instances, StreamParserInput and StringParserInput
in xmlp.input.   These wrap an InputRange interface (empty, front,
popFront). 

Give a new XmlPieceParser the input, and an optional base directory
path, and call nextPiece()  repeatedly to get bits of the rather
sparse  XmlTree model  defined in xmlp.xmldom. Or call the static
XmlPieceParser.ReadDocument to get the entire thing at once.

  I dont know how the Tango xml parser would cope with the w3c tests.
Any resemblance to what is in the Tango xml parser will be pure
coincidence, as a brief glance at that code some long time ago left me
none wiser.

I learnt a lot of XML minutiae while getting it to parse the hundreds
of w3c test cases. 

Some validation, such as the ELEMENT content particles validater still
has wet glue and cement, and is not gauranteed to validate the all
deterministic  content modesl. So if you get a good test case please
send.

I am sure this release will be considered to be code bloated at the
moment.  With all those test cases, some conditional coding became a
bit too contrived.  After coding it for while it just got too big.
Alhough I do think I got better at it towards the end.  There is some
scope for shrinkage.

Very possibly there is a non-validating parser inside that is a fair
bit smaller that this, that could one day be created by conditional
compiled or re-coded from it. 

The package has a base module name of xmlp.  I am not aiming for
std.xml as yet.

-
Michael Rynn

New XML parser written for D1 and D2.

2009-10-14 Thread Michael Rynn



I have made a validating or optionally none validating XML parser in
D.

It can read and parse  files and external dtds and entities with
differrent BOM and encodings.

This xmlp (XmlPieceParser class) passes 100% on both validating and
non-validating modes for the following test sets:- oasis, sun, xmltes
and  ibm.  I have not dared to try any of the xml 1.1 or other tests.
The warnings given by, if you choose to intercept them,  for not
well-formed or  non-valid documents may not necessarily be
illuminating.

My brief try of a modified std.xml against some of these tests led me
to chuck it, as I learned more what the parser is actually supposed to
do.  This one is all my own mistakes and bad coding habits, written
from near scratch, after giving up on std.xml, and taking what I could
from std.encoding.
I have also made a front end xmlp.delegator module that emulates the
delagate callback model of std.xml.

To use, you need to have a class derived from  XmlParserInput, of
which there are two instances, StreamParserInput and StringParserInput
in xmlp.input.   These wrap an InputRange interface (empty, front,
popFront).  the bool validate flag is false by default.

Give a new XmlPieceParser the input, and an optional base directory
path, and call nextPiece()  repeatedly to get bits of the rather
sparse  XmlTree model  defined in xmlp.xmldom. Or call the static
XmlPieceParser.ReadDocument to get the entire thing at once.

 This parser should be adaptable to use with Tango, as there is only
minimal dependence on Phobos.
  I dont know how the Tango xml parser would cope with the w3c tests.
Any resemblance of this to the Tango xml parser will be pure
coincidence, as a brief glance at the Tango code some long time ago
left me none wiser.

I learnt a lot of XML minutiae while getting it to parse the hundreds
of w3c test cases.  I've included the conformance test program and
scripts as one of the examples.

Some validation, such as the ELEMENT content particles validater still
has wet glue and cement, and is not gauranteed to validate each and
every  deterministic  content model. 

I am sure this release will be considered to be code bloated at the
moment.  With all those test cases, some conditional coding and
variants became a bit too contrived.  After coding it for while it
just got too big. Alhough I do think I got better at it towards the
end.  There is some scope for shrinkage. The windows binary with D2 of
the XmlConformance test suite runner is 

Very possibly there is a non-validating parser inside that is a fair
bit smaller that this, that could one day be created by conditional
compiled or re-coded from it. 

The package has a base module name of xmlp.  I am not aiming for
std.xml as yet.  

There are of course lots of other things in the XML world,
schemas,relax-ng  xsl xpointer and xpath,  and this parser almost
brings us to this century.

But I would like to have it made available so others can test.

Where and to whom can I post the 56 KB source code zip?

-
Michael Rynn

Re: A possible solution for the opIndexXxxAssign morass

Lars T. Kyllingstad Wrote:

 Yes, but if opIndex and opSlice take multiple indices (like in a matrix) 
 opDollar needs a way to distinguish between the different dimensions.

size_t length(size_t idx);

Re: So many years I was following D...

2009-10-14 Thread Fawzi Mohamed


On 2009-10-14 10:48:10 +0200, bearophile bearophileh...@lycos.com said:


Iamgottingcrazy:


Should I bear this??


With D1 it seems to work:
http://codepad.org/hpslrHHs

Bye,
bearophile


maybe because you actually used the correct sequence of dimensions...

int[2][3] x;
x.length is 3, this is a 3 dimensional array of 2 dimensional arrays...

Fawzi

Re: So many years I was following D...

2009-10-14 Thread Gide Nwawudu

On Wed, 14 Oct 2009 04:26:38 -0400, Iamgottingcrazy
shouldilearnt...@digitalmars.com wrote:

Should I bear this??

module teststructarray;

import std.stdio;
import core.stdc.stdlib:system;

struct Point
{
  int x;
  int y;
}
static Point[2] pArray1=
[
  {0,0},{0,1},//watch here!
];

static Point pArray2[2][3]=
[
  [{0,0},{0,1},{0,2}],
  [{1,0},{1,1},{1,2}],//watch here,without the last comma,the prog can't get 
 compiled!!
];
void main()
{
  foreach(int i,point;pArray1)
writefln(Point(%d)={%d,%d},i,pArray1[i].x,pArray1[i].y);
  
  foreach(points;pArray2)
  {
foreach(point;points)
{
  writef(Point(%d,%d)\t,point.x,point.y);
}
write(\n);
  }
  system(pause);//watch when this line gets executed
}

Try compile and run.

Looks like a version of the following bug.

http://d.puremagic.com/issues/show_bug.cgi?id=2477

Gide

Re: DIP6

2009-10-14 Thread Ary Borenszweig


Kagamin wrote:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Java's syntax has the advantage of having to type less when the annotation has 
no arguments: @annotation vs. [annotation].


In both cases you have a two-keys overhead.


No, why?

Re: A possible solution for the opIndexXxxAssign morass

On Wed, Oct 14, 2009 at 12:48 AM, Lars T. Kyllingstad
pub...@kyllingen.nospamnet wrote:
 Don wrote:

 Andrei Alexandrescu wrote:

 Right now we're in trouble with operators: opIndex and opIndexAssign
 don't seem to be up to snuff because they don't catch operations like

 a[b] += c;

 with reasonable expressiveness and efficiency.

 Last night this idea occurred to me: we could simply use overloading with
 the existing operator names. Consider:

 a += b

 gets rewritten as

 a.opAddAssign(b)

 Then how about this - rewrite this:

 a[b] += c

 as

 a.opAddAssign(b, c);

 There's no chance of ambiguity because the parameter counts are
 different. Moreover, this scales to multiple indexes:

 a[b1, b2, ..., bn] = c

 gets rewritten as

 a.opAddAssign(b1, b2, ..., bn, c)

 What do you think? I may be missing some important cases or threats.


 Andrei

 Well timed. I just wrote this operator overloading proposal, part 1.
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
 I concentrated on getting the use cases established.

 The indexing thing was something I didn't have a solution for.

 BTW we need to deal with slices as well as indexes. I think the way to do
 this is to make a slice into a type of index.


 I like the idea of enforcing relationships between operators. In fact, I
 think we can take it even further, and require that operator overloading in
 general *must* follow mathematical rules, and anything else leads to
 undefined behaviour. For example, if n is an integer, a and b are scalars,
 and x and y are general types, the compiler should be free to rewrite

         n*x  --  x + x + ... + x    --  2*x + 2*x + ...
        x^^n  --  x * x * ... * x    --  x^^2 * x^^2 * ...
   x/a + y/b  --  (b*x + a*y)/(a*b)

 and so on, based on what it finds to be the most efficient operations. (Note
 how I snuck my favourite suggestion for an exponentiation operator in there.
 I *really* want that.)

You have to be careful when you go rewriting mathematical expressions
on the computer, though.  The numerical error for two mathematically
identical expressions can be quite different when evaluated in finite
precision arithmetic.

I'd love an exponentiation operator, too.

--bb

Re: DIP6

On Wed, Oct 14, 2009 at 5:47 AM, Ary Borenszweig a...@esperanto.org.ar wrote:
 Kagamin wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6

 Java's syntax has the advantage of having to type less when the
 annotation has no arguments: @annotation vs. [annotation].

 In both cases you have a two-keys overhead.

 No, why?

Maybe you have a different keyboard layout than Kagamin and me.

On a US layout --
@  is Shift+2
but [ and ] are single keystrokes.

--bb

Re: A possible solution for the opIndexXxxAssign morass


Lars T. Kyllingstad wrote:

Kagamin wrote:

Robert Jacques Wrote:

Also needed is an extension of the opDollar to return different 
values  based on the index:

opDollar(size_t index);


Dollar is just a synonym for length, isn't it?



Yes, but if opIndex and opSlice take multiple indices (like in a matrix) 
opDollar needs a way to distinguish between the different dimensions.


-Lars


I think the compiler should rewrite $ to __currentarray.length in unary 
index expressions, and to __currentarray.length!(n) in multiple index 
expressions.


Andrei

Re: DIP6


Bill Baxter wrote:

On Wed, Oct 14, 2009 at 5:47 AM, Ary Borenszweig a...@esperanto.org.ar wrote:

Kagamin wrote:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Java's syntax has the advantage of having to type less when the
annotation has no arguments: @annotation vs. [annotation].

In both cases you have a two-keys overhead.

No, why?


Maybe you have a different keyboard layout than Kagamin and me.

On a US layout --
@  is Shift+2
but [ and ] are single keystrokes.

--bb


Back when I started programming on a french canadian layout, most of 
these symbols were located at crazy places, like ? is shift-6, [], {}, 
 are all found using right-alt + one of the many keys close to enter, 
which are used for accents, really annoying. Even the backslash is 
located at right-alt + the key left to 1.


And people here wonder why I custom order my laptops and keyboards to 
get native US layouts..


Jeremie

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Robert Jacques


On Wed, 14 Oct 2009 06:11:22 -0400, Kagamin s...@here.lot wrote:


Robert Jacques Wrote:


Also needed is an extension of the opDollar to return different values
based on the index:
opDollar(size_t index);


Dollar is just a synonym for length, isn't it?


User types can also override Dollar, though I don't remember off the top  
of my head how.

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Robert Jacques

On Wed, 14 Oct 2009 10:31:06 -0400, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:



Don wrote:

Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.


I'm not sure multiplication is generally commutative (e.g. in linear  
algebra it isn't). So why should a * x be interchangeable with x * a?


Also, the much-discussed identity:

x @= y  --  x = x @ y

is difficult to enforce statically in practice. I think some types would  
want to define both to achieve good efficiency. It would be hard for the  
compiler to render one unnecessary or to prove that the two are  
equivalent.



Andrei


When a is a scaler, a * x = x * a generally holds. It's only when  
something isn't a scaler, i.e. x1 * x2 != x2 * x1, that community(?)  
doesn't hold.

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Jason House

Andrei Alexandrescu Wrote:

 Right now we're in trouble with operators: opIndex and opIndexAssign 
 don't seem to be up to snuff because they don't catch operations like
 
 a[b] += c;
 
 with reasonable expressiveness and efficiency.

I would hope that *= += /= and friends could all be handled efficiently with 
one function written by the programmer. As I see it, there are 3 basic steps:
1. Look up a value by index
2. Mutate the value
3. Store the result

it's possible to use opIndex for #1 and opIndexAssign for #3, but that's not 
efficient. #1 and #3 should be part of the same function, but I think #2 
shouldnot be. What about defining an opIndexOpOpAssign that accepts a delegate 
for #2 and then use compiler magic to specialize/inline it?

Re: DIP6

2009-10-14 Thread Frank Benoit

Jeremie Pelletier schrieb:
 Back when I started programming on a french canadian layout, most of
 these symbols were located at crazy places, like ? is shift-6, [], {},
  are all found using right-alt + one of the many keys close to enter,
 which are used for accents, really annoying. Even the backslash is
 located at right-alt + the key left to 1.
 
 And people here wonder why I custom order my laptops and keyboards to
 get native US layouts..
 
 Jeremie

Hehe, same here in Germany

Re: Revamped concurrency API

bearophile wrote:

Bartosz Milewski:

It's good to know that my ideas are still circulating in the D community. Thanks,
guys!

They will keep circulating! And there's not just D in computer science, future
computer languages may use your ideas. Someday I'll design my own C-like
language, simpler (and more limited in scope) than D ;-)

Since I'm now put on the spot, I have to explain my recent detachment from D.

This makes me (and surely many other persons here) a little sad.

Same here, I read your blog with much interest and check it almost daily
for updates, your ideas about concurrency are really inspiring!

I'm also sure many of us here, me included, did our first steps in GUI
programming years ago by following your tutorial on reliable software.

D is an engineering project, and it's not small. And the first thing to learn about all sizeable real-world engineering projects (like the creation of a large bridge, or many other things) is that they are first of all politics. They are not the result of rationality, even if often some rationality is required. All large engineering project come out of a large amount of compromises. If you pretend to see one of such systems to come out of rationality alone, you will never see a real one.

So every time you have to fight for the rationality to prevail, and you have to
be ready to accept some compromises. It's life.

I still have faith that Walter and Andrei can filter out all the ideas
here no matter how heated up the arguments and come up with a design
that will be a decent compromise in the requested features and design
changes.

it's hard for me to subscribe to the good enough philosophy (as long as it's
better that C++, it's fine for D).

D language is largely grown, and not designed. D is not Scala or Haskell. I
think there is not enough brain mass in this group to design rationally a
C++-class language. Probably there's not even brain mass to design a
Python-class language. D2 will surely have a big amount of design mistakes,
every one here can list you some of them. But one of the best qualities of
Walter is that he's not frozen, he sometimes seems to move very slowly, but he
never stops moving, and usually he eventually sees the light (and when this
happens it's usually a small surprise for everyone else, like the show of a
rabbit pulled out of a hat). So I think some of the design mistakes of D2 will
be fixed in D3 :-)

The brain mass is there, more than enough too. Its the manpower that
lacks, we propose way more features than we have manpower to implement
in time to either release them or properly test them and see if the
design works as good as wanted.

A lot of us would like to contribute to the compiler and library but
we're already busy with our daily jobs, maybe Walter needs to hire half
this newsgroup and build us an office :o)

My impression is that, as the release of D2 and the publication of Andrei's book
are nearing, this attitude is gaining ground. I try to fight this attitude but
it's an uphill battle. Or, as Andrei puts it, I start whining and give up ;-).

Andrei's book comes too much early, forcing rhythms that I think aren't good
for D2. On the other hand no software is ever finished, it's just abandoned.
And you must not think of D2 as the finished product :-) You may even think of
D2 as just a bridge toward D3 :-) D2 is probably just an experiment, to
experimentally see what design ideas are good and what to throw away and
redesign. And such things are slow. So you may want to come back in few years,
to try to improve the concurrency design of D3 :-)

I agree here, while I think Andrei's book is a must for the community to
grow, it should rush the compiler. I strongly believe D2 needs proper
shared and lent semantics, or else we're just creating a stepping stone
for D3, leaving D2 in a state that isn't suited for concurrent model
implementations in a type-safe manner.

I don't mind however getting the spec ready with the features coming in
the near future as part of D2 (either in patch releases or minor
releases, ie 2.1).

The semantics of shared. I can live with postponing the implementation of the
race-free type system, but not with the compiler inserting barriers around all shared reads
and writes, even inside synchronized sections.

This is a topic that can be discussed. If enough people think this is a
problem, then eventually Walter may change his mind, or he may design something
better, etc. If no one discussed problems they can't be fixed/improved. I know
that discussing things and accepting compromises is a pain, but it's an
inevitable pain. Rationality alone usually never wins, you need politics too.

I brought up this topic a number of time without much success. Shared is
hard to work with right now without tons of casting. It's also way too
easy to accidentally write recursive locks with the current synchronized
model, which is a nice fallback

Re: DIP6

Frank Benoit Wrote:

  And people here wonder why I custom order my laptops and keyboards to
  get native US layouts..
  
  Jeremie
 
 Hehe, same here in Germany

In non-latin keyboard layouts there's no latin symbols at all. Feel the 
difference.

Re: Revamped concurrency API


Jeremie Pelletier wrote:

Jeremie Pelletier wrote:
I agree here, while I think Andrei's book is a must for the community 
to grow, it should rush the compiler. I strongly believe D2 needs 
proper shared and lent semantics, or else we're just creating a 
stepping stone for D3, leaving D2 in a state that isn't suited for 
concurrent model implementations in a type-safe manner.


s/should rush/shouldn't rush/


For the record, I delayed signing for the book for quite a few months. 
Before I did sign, there was solemn agreement in the D team that we can 
commit. The book is already late by a few months. If the book is trying 
to rush anything, it's doing a lousy job at that.


Andrei

Re: DIP6

2009-10-14 Thread Ary Borenszweig


Bill Baxter wrote:

On Wed, Oct 14, 2009 at 5:47 AM, Ary Borenszweig a...@esperanto.org.ar wrote:

Kagamin wrote:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Java's syntax has the advantage of having to type less when the
annotation has no arguments: @annotation vs. [annotation].

In both cases you have a two-keys overhead.

No, why?


Maybe you have a different keyboard layout than Kagamin and me.

On a US layout --
@  is Shift+2
but [ and ] are single keystrokes.

--bb


Ah, two keys. I thought two chars. But I use the pinky finger to do the 
shift, isn't that less that a full blown finger to do [ or ]?

Re: A possible solution for the opIndexXxxAssign morass

On Wed, Oct 14, 2009 at 7:42 AM, Jason House
jason.james.ho...@gmail.com wrote:
 Andrei Alexandrescu Wrote:

 Right now we're in trouble with operators: opIndex and opIndexAssign
 don't seem to be up to snuff because they don't catch operations like

 a[b] += c;

 with reasonable expressiveness and efficiency.

 I would hope that *= += /= and friends could all be handled efficiently with 
 one function written by the programmer. As I see it, there are 3 basic steps:
 1. Look up a value by index
 2. Mutate the value
 3. Store the result

And as Chad J reminds us, same goes for in-place property mutations
like  a.b += c.
It's just a matter of  accessing  .b  vs .opIndex(b).   And really
same goes for any function  a.memfun(b) += c could benefit from the
same thing (a.length(index)+=3 anyone?)

 it's possible to use opIndex for #1 and opIndexAssign for #3, but that's not 
 efficient. #1 and #3 should be part of the same function, but I think #2 
 shouldnot be. What about defining an opIndexOpOpAssign that accepts a 
 delegate for #2 and then use compiler magic to specialize/inline it?

It could also be done using a template thing to inject the mutate the
value operation:

void opIndexOpOpAssignOpSpamOpSpamSpamSpam(string Op)(Thang c, Thing idx) {
 ref v = lookup [idx] however you like
 mixin(v ~Op~ c;);
 store to v to [idx] however you like
}

or make it an alias function argument and use Op(v, b).

Sparse matrices are a good case to look at for issues.  a[b] is
defined for every [b], but if the value is zero nothing is actually
stored.  So there may or may not be something you can return a
reference to.   In C++ things like std::map just declare that if you
try to access a value that isn't there, it gets created.  That way
operator[] can always return a reference.   It would be great if we
could make a[b] not force a ref return in cases where there is no
lvalue that corresponds to the index (or property) being accessed.
Gracefully degrade to the slow path in those cases.

A good thing about a template is you can pretty easily specify which
cases to allow using template constraints:

void opIndexOpOpAssignOpSpamOpSpamSpamSpam(string Op)(Thang c, Thing b)
   if (Op in += -=)
{
   ...
}

(+ 1 small dream there about 'in' being defined to mean substring
search for string arguments -- that doesn't currently work does it?)

If the template can't be instantiated for the particular operation,
then the compiler would try to revert to the less efficient standby:
auto tmp = a[b];
tmp op= c;
a[b] = tmp;

The whole thing can generalize to all accessors too.  Instead of just
passing the Op, the compiler could pass the accessor string, and args
for that accessor.  Here an accessor means .opIndex(b),  .foo, or
even a general .memfun(b)


void opIndexOpOpAssignOpSpamOpSpamSpamSpam(string Member, string
Op)(Thang c, Thing b)
   if (Member in .foo() .bar() .opIndex())
{
 string call = ctReplace(Member, (), (b));  // Member looks
like .memfun()  this turns it into .memfun(b)
 ref v = mixin(this ~ call ~ ;);
  any extra stuff you want to do on accesses to v 
 mixin(v ~Op~ c;);
  store v back to member 
}

It's ugly and perhaps too low-level, but that can be worked on if the
general principle is sound.   Utility functions can be defined to do
whatever it is that turns out to be a recurring pattern.  Lack of
being virtual could be a problem for classes.

--bb

Re: D marketplace

Walter Bright Wrote:

 I'm considering setting up another D newsgroup called D.marketplace. In 
 it, you can essentially post advertisements for your D products, hang 
 out a shingle offering your D consulting services, post want ads for D 
 programmers, anything business oriented that's related to D.
 
 Is this something needed?

Good idea Walter.

I'd be particularly interested to know the availability of

1. D professionals ::= people that ask the going market rate for programming 
services,
as this is their core business), or

2. D professional hobbyists ::= people that are willing to do D programming 
tasks for low $
as this is their hobby business. i.e. feel that it's nice to earn some reward 
for D programming
but will do stuff for the experience, challenge and sheer joy of it.  Lawyers 
call this
pro-bono don't they? :-)

-- Justin Johansson

email: proc...@domain-as-per-ng-post

Re: Revamped concurrency API


Andrei Alexandrescu wrote:



For the record, I delayed signing for the book for quite a few months. 
Before I did sign, there was solemn agreement in the D team that we can 
commit. [snip]



Commit to what, exactly ?

Nick B

Re: Revamped concurrency API


Nick B wrote:

Andrei Alexandrescu wrote:



For the record, I delayed signing for the book for quite a few months. 
Before I did sign, there was solemn agreement in the D team that we 
can commit. [snip]



Commit to what, exactly ?

Nick B



Commit to delivering the book and the language matching it.

Andrei

Communicating between in and out contracts


Consider a Stack interface:

interface Stack(T) {
   bool empty();
   ref T top();
   void push(T value);
   void pop();
   size_t length();
}

Let's attach contracts to the interface:

interface Stack(T) {
   bool empty();
   ref T top()
   in {
  assert(!empty());
   }
   void push(T value);
   out {
  assert(value == top());
   }
   void pop()
   in {
  assert(!empty());
   }
   size_t length()
   out(result) {
  assert((result == 0) == empty());
   }
}

So far so good. The problem is now that it's impossible to express the
contract the length after push() is the length before plus 1.

Eiffel offers the old keyword that refers to the old object in a
postcondition. But it seems quite wasteful to clone the object just to
have a contract look at a little portion of the old object.

I was thinking of having the two contracts share the same scope. In that
case we can write:

   void push(T value);
   in {
  auto oldLength = length();
   }
   out {
  assert(value == top());
  assert(length == oldLength + 1);
   }

Walter tried to implement that but it turned out to be very difficult
implementation-wise. We tossed around a couple of other ideas, without
making much progress. In particular inlining the contract bodies looks
more attractive than it really is. If you have any suggestion, please share.


Thanks,

Andrei

Re: Communicating between in and out contracts

2009-10-14 Thread Lutger

Between sharing the whole object and sharing scope lies specifying exactly 
what to share, I'd think.

Here is one possible syntax, like regular function calls. Parameter types 
can possibly be inferred and omitted:

void push(T value);
in {
   out(length());
}
out(size_t oldLength) {
   assert(value == top());
   assert(length == oldLength + 1);
}

Re: A possible solution for the opIndexXxxAssign morass

On Wed, Oct 14, 2009 at 9:34 AM, Bill Baxter wbax...@gmail.com wrote:
 On Wed, Oct 14, 2009 at 7:42 AM, Jason House
 jason.james.ho...@gmail.com wrote:
 Andrei Alexandrescu Wrote:

 Right now we're in trouble with operators: opIndex and opIndexAssign
 don't seem to be up to snuff because they don't catch operations like

 a[b] += c;

 with reasonable expressiveness and efficiency.

 I would hope that *= += /= and friends could all be handled efficiently with 
 one function written by the programmer. As I see it, there are 3 basic steps:
 1. Look up a value by index
 2. Mutate the value
 3. Store the result

 And as Chad J reminds us, same goes for in-place property mutations
 like  a.b += c.
 It's just a matter of  accessing  .b  vs .opIndex(b).   And really
 same goes for any function  a.memfun(b) += c could benefit from the
 same thing (a.length(index)+=3 anyone?)

 it's possible to use opIndex for #1 and opIndexAssign for #3, but that's not 
 efficient. #1 and #3 should be part of the same function, but I think #2 
 shouldnot be. What about defining an opIndexOpOpAssign that accepts a 
 delegate for #2 and then use compiler magic to specialize/inline it?

 It could also be done using a template thing to inject the mutate the
 value operation:

 void opIndexOpOpAssignOpSpamOpSpamSpamSpam(string Op)(Thang c, Thing idx) {
     ref v = lookup [idx] however you like
     mixin(v ~Op~ c;);
     store to v to [idx] however you like
 }

 or make it an alias function argument and use Op(v, b).

 Sparse matrices are a good case to look at for issues.  a[b] is
 defined for every [b], but if the value is zero nothing is actually
 stored.  So there may or may not be something you can return a
 reference to.   In C++ things like std::map just declare that if you
 try to access a value that isn't there, it gets created.  That way
 operator[] can always return a reference.   It would be great if we
 could make a[b] not force a ref return in cases where there is no
 lvalue that corresponds to the index (or property) being accessed.
 Gracefully degrade to the slow path in those cases.

 A good thing about a template is you can pretty easily specify which
 cases to allow using template constraints:

 void opIndexOpOpAssignOpSpamOpSpamSpamSpam(string Op)(Thang c, Thing b)
       if (Op in += -=)
 {
   ...
 }

 (+ 1 small dream there about 'in' being defined to mean substring
 search for string arguments -- that doesn't currently work does it?)

 If the template can't be instantiated for the particular operation,
 then the compiler would try to revert to the less efficient standby:
 auto tmp = a[b];
 tmp op= c;
 a[b] = tmp;

 The whole thing can generalize to all accessors too.  Instead of just
 passing the Op, the compiler could pass the accessor string, and args
 for that accessor.  Here an accessor means .opIndex(b),  .foo, or
 even a general .memfun(b)


 void opIndexOpOpAssignOpSpamOpSpamSpamSpam(string Member, string
 Op)(Thang c, Thing b)
   if (Member in .foo() .bar() .opIndex())
 {
     string call = ctReplace(Member, (), (b));  // Member looks
 like .memfun()  this turns it into .memfun(b)
     ref v = mixin(this ~ call ~ ;);
      any extra stuff you want to do on accesses to v 
     mixin(v ~Op~ c;);
      store v back to member 
 }

 It's ugly and perhaps too low-level, but that can be worked on if the
 general principle is sound.   Utility functions can be defined to do
 whatever it is that turns out to be a recurring pattern.  Lack of
 being virtual could be a problem for classes.


After mulling over it some more, basically what I'm describing is
simply a function that gives the user a chance to rewrite the AST of
these kinds of .memfun(args) op=  type operations.

When the compiler sees obj.memfun(b) += c
It gives that bit of the syntax tree to the AST manipulator function
(if obj defines one) and the function can then alter it however
desired.

This is made somewhat clunky by the fact that our only representation
for ASTs is strings.

Actually this could just be a CTFE function.   It doesn't need to be a template.

Just imagine there's a compile-time struct passed in that could do
things like this:

string opWhateverAssign(AST syntax)
{
 // First some examples:
 // Assume obj.memfun(b0,b1) += c   is what appeared in source code.
 enum s0 = syntax.args;  // yields b0, b1 -- compiler knows args
to this fn are called b0 and b1
 enum s1 = syntax.args[0]; // yields b0
 enum s2 = syntax.rvalue; // yields c
 enum s3 = syntax.member;  // yields  memfun
 enum s4 = syntax.formatCallString(v = $syntax.member( x,y ));
// yields v=memfun(x,y)
 enum s5 = syntax.defaultImpl; // yields auto v=memfun(b0,b1);
v+=c; memfun(b0,b1)=v;

 // ok now I'll actually do something
 static if (syntax.member == opIndex) {
   // say this is a sparse matrix class
   return ctFormat(q{
   if (!this.matrix_contains($syntax.args)) {

Re: New XML parser written for D1 and D2.


Michael Rynn wrote:


I have made a validating or optionally none validating XML parser in
D.

It can read and parse  files and external dtds and entities with
differrent BOM and encodings.


[snip]


Very possibly there is a non-validating parser inside that is a fair
bit smaller that this, that could one day be created by conditional
compiled or re-coded from it. 


The package has a base module name of xmlp.  I am not aiming for
std.xml as yet.  


There are of course lots of other things in the XML world,
schemas,relax-ng  xsl xpointer and xpath,  and this parser almost
brings us to this century.

But I would like to have it made available so others can test.

Where and to whom can I post the 56 KB source code zip?

-
Michael Rynn


Michael

I would like to suggest that you contact the Tango community on IRC , at 
  #D.tango  , ( you can access them via  http://webchat.freenode.net/ 
) and  offer this code to them. You will likely need to describe the 
additional functionality over the existing Tango XML parser, additional 
 validation etc. How it could be intergrated into the existing Tango 
code base.


regards
Nick B

Re: Goodbye

2009-10-14 Thread Chris Nicholson-Sauls


Saaa wrote:
Yigal Chripun yigal...@gmail.com wrote in message 
news:hb2u2n$2if...@digitalmars.com...

On 13/10/2009 20:24, Saaa wrote:

Yigal Chripun wrote


ego has nothing to do with being smart.
you can be extremely smart without getting on people's nerves all the
time.

A smart person can choose when to get on somebody's nerves ;)


The bible says about Noah that he was the most just and moral person in 
his generation.

There are two opposed interpretations for this:
positive: his generation was so morally corrupt that managing to be moral 
in such a harsh environment is a virtue.
negative: Noah is moral relative to his generation which doesn't mean a 
lot on an absolute scale since his generation was so corrupt.


not all men are born equal so we all choose from the above points of view.
you can either decrease the value of others to feel good about yourself or 
you can strive to improve yourself and therefore increase your value in 
the eyes of others. the latter is harder but it's the only beneficial way 
for mankind. obviously, being egotistical belongs to the former.


consider this:
when a person asks a question on the NG (might be extremly stupid 
question) the (smart) person to reply can either give a snide remark and 
thereby decrease the size of this community by one or give constructive 
information, relevant links, etc and gain one more D programmer. I'd say 
that the latter is the smart choice.

we have a saying in Hebrew which translates roughly as:
a smart man knows how to avoid a pitfall which a knowledgeable person can 
figure a way out of.


Getting on somebody's nerves doesn't necessarily serve as a way to feel
better about oneself.
Also, improving oneself doesn't necessarily mean others will see this 
improvement.

And, improving oneself is sometimes easier than making somebody else
feel bad about her/his self.
A snide remark doesn't always mean the other person will leave.
The Hebrew saying is mostly about the difference between being smart and
being intelligent; a tad unrelated.

The important word in my sentence was can: being able to choose the
emotion in which you'd like to react.
Learning how Not to let your blood boil when expecting a snide remark
is another good ability, I think. 





The most important thing is remembering that black text on a white screen carries 
absolutely no emotional information whatsoever, in either direction, in any case.  The 
exception that proves the rule, of course, is ZOMG NERD RAGE ALLCAPS.  Otherwise, there's 
nothing to go on.

Re: Revamped concurrency API


Andrei Alexandrescu wrote:




Commit to what, exactly ?

Nick B



Commit to delivering the book and the language matching it.

Andrei


To meet a final release of D 2.0 ?

Nick B

Re: DIP6

2009-10-14 Thread Chris Nicholson-Sauls


Ary Borenszweig wrote:

Bill Baxter wrote:
On Wed, Oct 14, 2009 at 5:47 AM, Ary Borenszweig 
a...@esperanto.org.ar wrote:

Kagamin wrote:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Java's syntax has the advantage of having to type less when the
annotation has no arguments: @annotation vs. [annotation].

In both cases you have a two-keys overhead.

No, why?


Maybe you have a different keyboard layout than Kagamin and me.

On a US layout --
@  is Shift+2
but [ and ] are single keystrokes.

--bb


Ah, two keys. I thought two chars. But I use the pinky finger to do the 
shift, isn't that less that a full blown finger to do [ or ]?


I was thinking the same thing... but then again I don't think typing Ctl-Alt-K [ 
Ctl-Alt-K Ctl-Alt-K just to get an eth (ð) is a big deal...


-- Chris Nicholson-Sauls

Re: Revamped concurrency API


Nick B wrote:

Andrei Alexandrescu wrote:




Commit to what, exactly ?

Nick B



Commit to delivering the book and the language matching it.

Andrei


To meet a final release of D 2.0 ?

Nick B


Yes, that's the plan. D2 final release begets TDPL, and TDPL describes 
the final release of D2.


Andrei

Re: Communicating between in and out contracts

2009-10-14 Thread Chris Nicholson-Sauls


Andrei Alexandrescu wrote:

Consider a Stack interface:

interface Stack(T) {
   bool empty();
   ref T top();
   void push(T value);
   void pop();
   size_t length();
}

Let's attach contracts to the interface:

interface Stack(T) {
   bool empty();
   ref T top()
   in {
  assert(!empty());
   }
   void push(T value);
   out {
  assert(value == top());
   }
   void pop()
   in {
  assert(!empty());
   }
   size_t length()
   out(result) {
  assert((result == 0) == empty());
   }
}

So far so good. The problem is now that it's impossible to express the
contract the length after push() is the length before plus 1.

Eiffel offers the old keyword that refers to the old object in a
postcondition. But it seems quite wasteful to clone the object just to
have a contract look at a little portion of the old object.

I was thinking of having the two contracts share the same scope. In that
case we can write:

   void push(T value);
   in {
  auto oldLength = length();
   }
   out {
  assert(value == top());
  assert(length == oldLength + 1);
   }

Walter tried to implement that but it turned out to be very difficult
implementation-wise. We tossed around a couple of other ideas, without
making much progress. In particular inlining the contract bodies looks
more attractive than it really is. If you have any suggestion, please 
share.



Thanks,

Andrei


How hard would it be to do something like this: collect any local variables declared in 
the precondition into a structure, and make that structure transparently available to the 
postcondition.  So your push case above gets rewritten to something like this:


__magic_tmp = {
typeof( length() ) oldLength;
}
in {
__magic_tmp.oldLength = length();
}
out {
assert(value == top());
assert(length == __magic_tmp.oldLength + 1);
}

Honestly Lutger's idea of passing the data like parameters might be better, I'm just 
somehow uneasy about the look of out(foo,bar).


-- Chris Nicholson-Sauls

Re: A possible solution for the opIndexXxxAssign morass


Jason House wrote:

Bill Baxter Wrote:


On Wed, Oct 14, 2009 at 7:42 AM, Jason House
jason.james.ho...@gmail.com wrote:

Andrei Alexandrescu Wrote:


Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like

a[b] += c;

with reasonable expressiveness and efficiency.

I would hope that *= += /= and friends could all be handled efficiently with 
one function written by the programmer. As I see it, there are 3 basic steps:
1. Look up a value by index
2. Mutate the value
3. Store the result

And as Chad J reminds us, same goes for in-place property mutations
like  a.b += c.
It's just a matter of  accessing  .b  vs .opIndex(b).   And really
same goes for any function  a.memfun(b) += c could benefit from the
same thing (a.length(index)+=3 anyone?)


it's possible to use opIndex for #1 and opIndexAssign for #3, but that's not 
efficient. #1 and #3 should be part of the same function, but I think #2 
shouldnot be. What about defining an opIndexOpOpAssign that accepts a delegate 
for #2 and then use compiler magic to specialize/inline it?

It could also be done using a template thing to inject the mutate the
value operation:


The only issue with templates is that they're never virtual


You can make virtuals out of templates, but not templates out of 
virtuals. I think Walter is now inclined to look at a template-based 
solution for operator overloading. That would save a mighty lot of code 
without preventing classes that prefer virtual dispatch from doing so.


Andrei

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Jason House

Bill Baxter Wrote:

 On Wed, Oct 14, 2009 at 7:42 AM, Jason House
 jason.james.ho...@gmail.com wrote:
  Andrei Alexandrescu Wrote:
 
  Right now we're in trouble with operators: opIndex and opIndexAssign
  don't seem to be up to snuff because they don't catch operations like
 
  a[b] += c;
 
  with reasonable expressiveness and efficiency.
 
  I would hope that *= += /= and friends could all be handled efficiently 
  with one function written by the programmer. As I see it, there are 3 basic 
  steps:
  1. Look up a value by index
  2. Mutate the value
  3. Store the result
 
 And as Chad J reminds us, same goes for in-place property mutations
 like  a.b += c.
 It's just a matter of  accessing  .b  vs .opIndex(b).   And really
 same goes for any function  a.memfun(b) += c could benefit from the
 same thing (a.length(index)+=3 anyone?)
 
  it's possible to use opIndex for #1 and opIndexAssign for #3, but that's 
  not efficient. #1 and #3 should be part of the same function, but I think 
  #2 shouldnot be. What about defining an opIndexOpOpAssign that accepts a 
  delegate for #2 and then use compiler magic to specialize/inline it?
 
 It could also be done using a template thing to inject the mutate the
 value operation:

The only issue with templates is that they're never virtual

Re: Communicating between in and out contracts


Lutger wrote:
Between sharing the whole object and sharing scope lies specifying exactly 
what to share, I'd think.


Here is one possible syntax, like regular function calls. Parameter types 
can possibly be inferred and omitted:


void push(T value);
in {
   out(length());
}
out(size_t oldLength) {
   assert(value == top());
   assert(length == oldLength + 1);
}



I think this could work. One of Walter's ideas was to pass the entire 
old object as an argument to out. Passing handpicked data is more work 
for the user but faster.


Perhaps this would simplify things a bit:

void push(T value);
in {
   auto oldLength = length;
}
out(oldLength) {
   assert(value == top());
   assert(length == oldLength + 1);
}

Whatever parameters you pass to out they'd be matched by name with stuff 
defined in the in contract. That poses a problem because until now 
out(whatever) automatically passed the result to the out contract under 
the name whatever.



Andrei

Re: Communicating between in and out contracts


Lutger wrote:
Between sharing the whole object and sharing scope lies specifying exactly 
what to share, I'd think.


Here is one possible syntax, like regular function calls. Parameter types 
can possibly be inferred and omitted:


void push(T value);
in {
   out(length());
}
out(size_t oldLength) {
   assert(value == top());
   assert(length == oldLength + 1);
}



I like this, but I wouldnt make a regular function call:

void push(T value)
in {
out auto oldLength = length();
}
out {
assert(value == top());
assert(length() == oldLength + 1);
}
body {
...
}

If you declare  variables as 'out' in a precondition, they are hidden 
from the body and visible in the post condition.


The implementation of this is as easy as pushing oldLength on the stack 
in the precondition and poping it in the postcondition.


Jeremie

Re: Goodbye


Chris Nicholson-Sauls wrote

 The most important thing is remembering that black text on a white screen 
 carries absolutely no emotional information whatsoever, in either 
 direction, in any case.  The exception that proves the rule, of course, is 
 ZOMG NERD RAGE ALLCAPS.  Otherwise, there's nothing to go on.

I too think we should make this a html NG :)

Re: A possible solution for the opIndexXxxAssign morass

2009-10-14 Thread Robert Jacques

On Wed, 14 Oct 2009 16:49:28 -0400, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:



Jason House wrote:

Bill Baxter Wrote:


On Wed, Oct 14, 2009 at 7:42 AM, Jason House
jason.james.ho...@gmail.com wrote:

Andrei Alexandrescu Wrote:


Right now we're in trouble with operators: opIndex and opIndexAssign
don't seem to be up to snuff because they don't catch operations like

a[b] += c;

with reasonable expressiveness and efficiency.
I would hope that *= += /= and friends could all be handled  
efficiently with one function written by the programmer. As I see it,  
there are 3 basic steps:

1. Look up a value by index
2. Mutate the value
3. Store the result

And as Chad J reminds us, same goes for in-place property mutations
like  a.b += c.
It's just a matter of  accessing  .b  vs .opIndex(b).   And really
same goes for any function  a.memfun(b) += c could benefit from the
same thing (a.length(index)+=3 anyone?)

it's possible to use opIndex for #1 and opIndexAssign for #3, but  
that's not efficient. #1 and #3 should be part of the same function,  
but I think #2 shouldnot be. What about defining an opIndexOpOpAssign  
that accepts a delegate for #2 and then use compiler magic to  
specialize/inline it?

It could also be done using a template thing to inject the mutate the
value operation:

 The only issue with templates is that they're never virtual


You can make virtuals out of templates, but not templates out of  
virtuals. I think Walter is now inclined to look at a template-based  
solution for operator overloading. That would save a mighty lot of code  
without preventing classes that prefer virtual dispatch from doing so.


Andrei


I've done something similar for a SmallVec struct. Most of the operator  
overloads are actually aliases of templated functions (one each for  
uni-ops, bi-ops, bi-op_r and opassign)

Re: Revamped concurrency API

2009-10-14 Thread Bartosz Milewski

bearophile Wrote:

 
 it's hard for me to subscribe to the good enough philosophy (as long as 
 it's better that C++, it's fine for D).
 
 D language is largely grown, and not designed. D is not Scala or Haskell. 
 ...
  So I think some of the design mistakes of D2 will be fixed in D3 :-)
 

With every release of D we are narrowing our options. After D2 and TDPL, 
backward compatibility will become a major thing, so every ad-hoc feature in D2 
will have to be carried over. 

Why is C++ so bad? Not for lack of brainpower. It's because it fell into the 
compatibility trap (essentially from day one). 

There are some areas of D, like Andrei's ranges, that are well thought out and 
theoretically sound (we hope), but there are also hacks upon hacks that make my 
hair stand on end.

Re: New XML parser written for D1 and D2.

Michael Rynn wrote
 I have made a validating or optionally none validating XML parser in
 D.
nice


 But I would like to have it made available so others can test.
Maybe add it as an enhancement in bugzilla


 Where and to whom can I post the 56 KB source code zip?
NG attachement? Or is that considered bad manners?

Re: Communicating between in and out contracts

2009-10-14 Thread Lutger

Andrei Alexandrescu wrote:

 Lutger wrote:
 Between sharing the whole object and sharing scope lies specifying
 exactly what to share, I'd think.
 
 Here is one possible syntax, like regular function calls. Parameter types
 can possibly be inferred and omitted:
 
 void push(T value);
 in {
out(length());
 }
 out(size_t oldLength) {
assert(value == top());
assert(length == oldLength + 1);
 }
 
 
 I think this could work. One of Walter's ideas was to pass the entire
 old object as an argument to out. Passing handpicked data is more work
 for the user but faster.
 
 Perhaps this would simplify things a bit:
 
 void push(T value);
 in {
 auto oldLength = length;
 }
 out(oldLength) {
 assert(value == top());
 assert(length == oldLength + 1);
 }
 
 Whatever parameters you pass to out they'd be matched by name with stuff
 defined in the in contract. That poses a problem because until now
 out(whatever) automatically passed the result to the out contract under
 the name whatever.
 
 
 Andrei

Right, I forgot about that, you do need that return variable or have to 
invent a magic name. Jeremie's proposal doesn't have that problem, taking 
the reverse route of letting in{} define which variabeles are to be passed 
to the out function.

So either would work:
  in{
  auto oldLength = length;
  out(oldLength);
  }
or:
  in{
  out auto oldLength = length;
  }

Whatever syntax is chosen, it doesn't strike me as cumbersome to handpick 
variables considering what you get from it. Also, some conditions may depend 
on calculated values, in those cases it may even be more straightforward  
than checking an old copy of the object.

Re: Revamped concurrency API


Don wrote:

Bartosz Milewski wrote:



[snip]



Please stay in touch, we will try to win you back...

Of the issues you mention, this one seems the easiest to address:

As far as my thread work went, I had an almost working implementation 
of spawn, except for a nasty compiler bug which resisted all efforts 
to reduce it to a simple test case.


Could you give us _any_ kind of test case (even if it's enormous)?


Bartosz - are you able to provide a test case as requested by Don ?
Then it might be possible, to get this bug fixed.

Nick B.

MathExp: KISS or All-Out?

2009-10-14 Thread dsimcha

I'm working on some mathy modules that I'd like to eventually contribute to
Phobos, or, if they're too niche, to a standalone lib.  One that I've alluded
to here in the past few days is MathExp.  Basically what it does is
parse/interpret/evaluate/manipulate mathematical expressions at runtime.
Here's a summary of what I've got working so far:

MathExp numerator = mathExp(x^2 * cos(x), x);
MathExp denominator = mathExp(exp(-x), x);
MathExp ratio = numerator / denominator;

// Print the result of
// (x^2 * cos(x)) / (exp(-x)) evaluated at x = 5.
writeln(ratio(5));

// Compute a derivative symbolically.
MathExp derivDenominator = denominator.derivative(x);

I'm trying to figure out which one makes more sense in the grand scheme of
things.  MathExp might be best kept very simple and stupid and pretty much
left as is, possibly even with the symbolic differentiation capabilities
removed (though these contribute surprisingly little to the weight of the
code; I wrote most of them in one evening just to see if I could).  It would
be easy to use, understand and debug, but be very stupid and have virtually no
semantic understanding of the expressions it's manipulating.  It wouldn't even
be able to simplify, for example, (1 + x + 1) - (x + 2).

On the other hand, I could take this to the nth degree and add things like
decent printing capabilities (right now, my toString() method is a huge
kludge, is intended for debugging purposes, and puts in tons of unnecessary
parentheses).  I could figure out how to add some semantic analysis to
simplify expressions, maybe symbolic equation solving in some simple cases,
etc.  The downside to this is that I would be reinventing the computer algebra
system in D, which might be a bit too much for a small hobby project that's
intended as a Phobos module.  I'd likely make the code an order of magnitude
more complicated than it is now and might end up reinventing a square wheel or
writing some really buggy code.

If the goal here is to build a Phobos module or standalone plain old library,
do you think the KISS approach or the full-fledged approach is more useful to
the D community?

Re: Revamped concurrency API

2009-10-14 Thread Bartosz Milewski

Nick B Wrote:
 
  Could you give us _any_ kind of test case (even if it's enormous)?
 
 Bartosz - are you able to provide a test case as requested by Don ?
 Then it might be possible, to get this bug fixed.
 
 Nick B.

I can send you the files I have checked out. 

The problem was in core.thread. I tried to implement a struct Tid (thread ID) 
with reference-counting semantics and deterministic destruction. It passed all 
the tests, but when it was used in one particular place in druntime it produced 
incorrect assembly. Even the slightest change made the bug disappear, so I 
wasn't able to reproduce it under controlled conditions.

Unfortunately, I have undone some of my changes trying to bypass the bug, so at 
the moment I don't even have the buggy version, but it can be reconstructed. We 
can discuss it off-line, if you want. Use my email address with -nospam removed.

Re: New XML parser written for D1 and D2.

Saaa Wrote:

 Michael Rynn wrote
  I have made a validating or optionally none validating XML parser in
  D.
 nice
 
 
  But I would like to have it made available so others can test.
 Maybe add it as an enhancement in bugzilla
 
 
  Where and to whom can I post the 56 KB source code zip?
 NG attachement? Or is that considered bad manners?

Why is the an Add File button on NG web posting form?
Maybe that button should have an etiquette instruction aside it?

Re: Revamped concurrency API

2009-10-14 Thread Adam D. Ruppe

On Wed, Oct 14, 2009 at 05:56:10PM -0400, Bartosz Milewski wrote:
 The problem was in core.thread. I tried to implement a struct Tid (thread ID) 
 with reference-counting semantics and deterministic destruction. It passed 
 all the tests, but when it was used in one particular place in druntime it 
 produced incorrect assembly. Even the slightest change made the bug 
 disappear, so I wasn't able to reproduce it under controlled conditions.

Was it by any chance a null this pointer making its way into the ebx register
somehow, thus causing an access violation on Windows seemingly at random?
(My bug didn't happen if I compiled the exact same code on Linux - I figure
 it must be a Windows codegen problem.)

If so, I've been fighting that bug for over two years, similarly unable to
track down a small test case. I haven't put it on bugzilla since I can't
even really prove it exists to an outsider. I just keep hoping that the
next dmd release will magically fix it.

-- 
Adam D. Ruppe
http://arsdnet.net

Re: New XML parser written for D1 and D2.


Justin Johansson wrote
 Saaa Wrote:

 Michael Rynn wrote
  I have made a validating or optionally none validating XML parser in
  D.
 nice

 
  But I would like to have it made available so others can test.
 Maybe add it as an enhancement in bugzilla

 
  Where and to whom can I post the 56 KB source code zip?
 NG attachement? Or is that considered bad manners?

 Why is the an Add File button on NG web posting form?
Never actually looked at the web posing form.

 Maybe that button should have an etiquette instruction aside it?
No, I think it is ok to use it if the button is there.
If we weren't supposed to use it some instructions would be in place.
But then I think removing the button would be the better option.

Re: New XML parser written for D1 and D2.

Michael Rynn wrote
 Where and to whom can I post the 56 KB source code zip?
Attaching it to an enhancement in bugzilla would be best, I think.

Re: New XML parser written for D1 and D2.

2009-10-14 Thread Brad Roberts

On Thu, 15 Oct 2009, Saaa wrote:

 Justin Johansson wrote
  Saaa Wrote:
 
  Michael Rynn wrote
   I have made a validating or optionally none validating XML parser in
   D.
  nice
 
  
   But I would like to have it made available so others can test.
  Maybe add it as an enhancement in bugzilla
 
  
   Where and to whom can I post the 56 KB source code zip?
  NG attachement? Or is that considered bad manners?
 
  Why is the an Add File button on NG web posting form?
 Never actually looked at the web posing form.
 
  Maybe that button should have an etiquette instruction aside it?
 No, I think it is ok to use it if the button is there.
 If we weren't supposed to use it some instructions would be in place.
 But then I think removing the button would be the better option.

Given that code is almost always undergoing change, posting to a forum (be 
it ng, email, web based forums, whatever) seems like a less than ideal 
path to go down.  Put it on dsource, or a website, or anywhere that's easy 
to update without having to push lots of data to lots of people.

Just a thought,
Brad

Re: New XML parser written for D1 and D2.


Saaa wrote:

Michael Rynn wrote

Where and to whom can I post the 56 KB source code zip?
Attaching it to an enhancement in bugzilla would be best, I think. 


Yes please. Making the code work with ranges as input would be great.

Andrei

Re: Communicating between in and out contracts

2009-10-14 Thread Rainer Deyke

Andrei Alexandrescu wrote:
 Eiffel offers the old keyword that refers to the old object in a
 postcondition. But it seems quite wasteful to clone the object just to
 have a contract look at a little portion of the old object.

You don't need to clone the whole object.  You just need to cache the
properties that are used with 'old'.  In other words, this functionality:

void push(T value);
in {
   auto oldLength = length();
}
out {
   assert(value == top());
   assert(length == oldLength + 1);
}

...can be expressed with this syntax:

   void push(T value);
   out {
  assert(value == top());
  assert(length == old length + 1);
   }

The syntax with 'old' is more concise, easier to read, and does the same
thing.  What's wrong with it (other than adding yet another keyword to
the language)?


-- 
Rainer Deyke - rain...@eldwood.com

Re: New XML parser written for D1 and D2.

Andrei Alexandrescu Wrote:

 Saaa wrote:
  Michael Rynn wrote
  Where and to whom can I post the 56 KB source code zip?
  Attaching it to an enhancement in bugzilla would be best, I think. 
 
 Yes please. Making the code work with ranges as input would be great.
 
 Andrei

Hi Andrei,

Still being a D apprentice and not 100% conversant with D terminology yet, I 
assume,
and not wanting to make an *ass* out of *u* and *me* :-),
that by ranges you mean making use of D sub char[] arrays over the input so 
as to
minimize/obviate the need to allocate lots of small(er) strings to hold element 
tagnames,
attribute names and values, text node contents and so on.

This assumption being correct, can you confirm or otherwise that the 
consequence of such
a design would mean that by parsing, say, a 1MB XML in-memory document, 
constructing a
node tree from the same and having the nodes directly referencing substrings in 
the input document via string ranges, the entire 1MB would be locked into 
memory by the GC and not
collectable until the node tree itself is done with?

Now I might be completely off track;  perhaps instead you are thinking of SAX 
style
parsing and passing arguments to the SAX event handling function via the said 
ranges.  In
this scenario I guess the SAX client could decide whether or not to .dup the 
ranges.

Depending on your clarification, I may have further comment based upon my 
practical
experience in the XML domain.

Regards

Justin Johansson

Re: New XML parser written for D1 and D2.


Justin Johansson wrote:

Andrei Alexandrescu Wrote:


Saaa wrote:

Michael Rynn wrote

Where and to whom can I post the 56 KB source code zip?
Attaching it to an enhancement in bugzilla would be best, I think. 

Yes please. Making the code work with ranges as input would be great.

Andrei


Hi Andrei,

Still being a D apprentice and not 100% conversant with D terminology yet, I 
assume,
and not wanting to make an *ass* out of *u* and *me* :-),
that by ranges you mean making use of D sub char[] arrays over the input so 
as to
minimize/obviate the need to allocate lots of small(er) strings to hold element 
tagnames,
attribute names and values, text node contents and so on.


He meant range structs as found in std.range and their array wrappers in 
std.array.



This assumption being correct, can you confirm or otherwise that the 
consequence of such
a design would mean that by parsing, say, a 1MB XML in-memory document, 
constructing a
node tree from the same and having the nodes directly referencing substrings in the input 
document via string ranges, the entire 1MB would be locked into memory by the 
GC and not
collectable until the node tree itself is done with?


That is not the goal of ranges, a memory mapped file would be more 
efficient for what you describe.


A range is D's version of streams, so for example a simple reader might 
look like:


void read(T)(in T range) if(isInputRange!T) {
while(!range.empty()) {
auto elem = range.front();
// process element
range.popFront();
}
}

The range implementation can be a simple 'string', a 'char[]', or a 
custom network channel that blocks on front() if the data is still loading.



Now I might be completely off track;  perhaps instead you are thinking of SAX 
style
parsing and passing arguments to the SAX event handling function via the said 
ranges.  In
this scenario I guess the SAX client could decide whether or not to .dup the 
ranges.


I think you confuse ranges with slices. Ranges are simply an interface 
for sequential or random data access. DOM trees and SAX callbacks are 
different methods of parsing the xml, a range is a method of accessing 
the data :)


Speaking of SAX, do we have a D implementation yet? If not I could write 
one, it sounds fun.



Depending on your clarification, I may have further comment based upon my 
practical
experience in the XML domain.

Regards

Justin Johansson

Re: New XML parser written for D1 and D2.

Jeremie Pelletier Wrote:

 He meant range structs as found in std.range and their array wrappers in 
 std.array.

Oh, okay.  Just groked src and looks like it is a D2 only thing.  Do you happen 
to know
what the derivation of the word range with respect to streams is?  I haven't 
come
across it before used in this context.

 A range is D's version of streams, so for example a simple reader might 
 look like:
 
 void read(T)(in T range) if(isInputRange!T) {
   while(!range.empty()) {
   auto elem = range.front();
   // process element
   range.popFront();
   }
 }
 
 I think you confuse ranges with slices. Ranges are simply an interface 
 for sequential or random data access. DOM trees and SAX callbacks are 
 different methods of parsing the xml, a range is a method of accessing 
 the data :)

Yes seems that way; my question apparently asked upon D1 knowledge only.

Re SAX, it easy enough to get James Clark's Expat 'C' parser happening with D.
That has an event-based API.  Perhaps all the std D library needs do is wrap 
this.
Whilst it's open source, dunno about the specific licensing issues though.

-- JJ

Re: New XML parser written for D1 and D2.

2009-10-14 Thread Walter Bright


Saaa wrote:

Michael Rynn wrote

I have made a validating or optionally none validating XML parser in
D.

nice


But I would like to have it made available so others can test.

Maybe add it as an enhancement in bugzilla


Where and to whom can I post the 56 KB source code zip?

NG attachement? Or is that considered bad manners?


Yeah, it's bad manners g.

I recommend dsource.org.

Re: New XML parser written for D1 and D2.

2009-10-14 Thread Jason House

Justin Johansson Wrote:

 Jeremie Pelletier Wrote:
 
  He meant range structs as found in std.range and their array wrappers in 
  std.array.
 
 Oh, okay.  Just groked src and looks like it is a D2 only thing.  Do you 
 happen to know
 what the derivation of the word range with respect to streams is?  I 
 haven't come
 across it before used in this context.

If you're familiar with C++, that's easy.   Ranges are a generalization for a 
pair of iterators. If that doesn't make sense, think of an iterator as a read 
cursor in a stream/array/data structure. To safely scan with the cursor 
requires a starting point and an end point. Andrei has a video titled 
iterators must go

Re: New XML parser written for D1 and D2.

Jeremie Pelletier Wrote:

 Justin Johansson wrote:
  Jeremie Pelletier Wrote:
  
  He meant range structs as found in std.range and their array wrappers in 
  std.array.
  
  Oh, okay.  Just groked src and looks like it is a D2 only thing.  Do you 
  happen to know
  what the derivation of the word range with respect to streams is?  I 
  haven't come
  across it before used in this context.
 
 I don't know where the word range comes from, sorry. I see them as 
 streams because they work just the same, except for the different method 
 names (ie front/back and put instead of read and write respectively).
 
  A range is D's version of streams, so for example a simple reader might 
  look like:
 
  void read(T)(in T range) if(isInputRange!T) {
 while(!range.empty()) {
 auto elem = range.front();
 // process element
 range.popFront();
 }
  }
   
  I think you confuse ranges with slices. Ranges are simply an interface 
  for sequential or random data access. DOM trees and SAX callbacks are 
  different methods of parsing the xml, a range is a method of accessing 
  the data :)
  
  Yes seems that way; my question apparently asked upon D1 knowledge only.
  
  Re SAX, it easy enough to get James Clark's Expat 'C' parser happening with 
  D.
  That has an event-based API.  Perhaps all the std D library needs do is 
  wrap this.
  Whilst it's open source, dunno about the specific licensing issues though.
  
  -- JJ
  
 
 Isn't expat slower than libxml2's SAX? Anyways I'd rather code a SAX 
 module in D, if only to better know the internals of this method.

I don't know if it is slower or not .. just that it is reliable and deals with 
all subtleties of XML and
coming from James Clark (one cool dude), I suspect he probably got it right.  
Oh, and it written
in agnostic C.
It's easy enough though to write an XML parser and SAX like interface in an 
afternoon, 
maybe flow into the evening, and get 98% of the way there.
The other 2% will take you a month of Sundays.
That's the problem with XML is that it's deceptively simple.  Apparently Sun 
cannot even get it
right or just didn't bother.  Elliotte Rusty Harold's done a pretty good job 
with XOM; it's
held in very high regard in the Java/XML community.

As Michael Rynn (who started this thread) can vouch,
if you are looking for a model, std.xml (in D2) is *not* the role.

Cheers
Justin Johansson

Re: Goodbye

2009-10-14 Thread Nick Sabalausky

Chris Nicholson-Sauls ibisbase...@gmail.com wrote in message 
news:hb5bnq$1k4...@digitalmars.com...

 The most important thing is remembering that black text on a white screen 
 carries absolutely no emotional information whatsoever, in either 
 direction, in any case.

Thank goodness I use white text on a black screen, I get nothing but 
emotional info!

Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]

2009-10-14 Thread Yigal Chripun


On 12/10/2009 10:47, Don wrote:


Ah, OK. My cursory glance at Nemerle just screamed hack. But first
impressions can be misleading.
No doubt as a C-family language, they have some useful ideas.
But if Christopher's analysis is correct, the macro bit is different
to the plugin bit. I think allowing the ASTs to be _modified_ by
plugins is the path to madness, but a read-only ABI is OK (it's hard to
see how compile-time reflection is possible without creating some kind
of API).



modifying the AST is dangerous but how would you do things like making a 
class implement an interface without modifying the list of interfaces 
the class implements ?


[serialize]
class Foo {...}

the Nemerle macro above transform this into:

class Foo : Serializable { ... }

what would be your design for this?

Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]


Yigal Chripun wrote:

On 12/10/2009 10:47, Don wrote:


Ah, OK. My cursory glance at Nemerle just screamed hack. But first
impressions can be misleading.
No doubt as a C-family language, they have some useful ideas.
But if Christopher's analysis is correct, the macro bit is different
to the plugin bit. I think allowing the ASTs to be _modified_ by
plugins is the path to madness, but a read-only ABI is OK (it's hard to
see how compile-time reflection is possible without creating some kind
of API).



modifying the AST is dangerous but how would you do things like making a 
class implement an interface without modifying the list of interfaces 
the class implements ?


[serialize]
class Foo {...}

the Nemerle macro above transform this into:

class Foo : Serializable { ... }

what would be your design for this?


I don't think it should be done that way. Either it should be intrusive 
(eg, require you to derive from Serializable), or else entirely external 
(and operate via reflection). Eg, possibly by declaring 
Serializable!(Foo) after the definition of Foo.
It's an excellent question though, we might need some language changes 
to get a good solution. But I think it's very important to enforce that 
the only way to modify the AST is indirect, through code.


One of the strengths I see of the string mixins, despite their syntactic 
ugliness, is that metaprogramming transformations are only ever syntax 
sugar: there is _always_ a source-code equivalent; moreover, it's 
trivially available, simply by expanding all of the mixins (and Descent 
will show it to you). It's not clear to me that that remains true if you 
can manipulate the AST directly. Of course, if you allow direct access 
to the AST, you have unlimited power. Capturing as much of the power as 
possible, without the danger, is the challenge.

Should I compare pointers with is of == ?

2009-10-14 Thread #ponce

It's a bit unclear to me. 

I know I must compare references with is but pointers ?

Re: Should I compare pointers with is of == ?

2009-10-14 Thread #ponce

#ponce Wrote:

 It's a bit unclear to me. 
 
 I know I must compare references with is but pointers ?
 
 

There is a typo in the title. Should I compare pointers with is oR == ?

Re: Should I compare pointers with is of == ?

2009-10-14 Thread Moritz Warning

On Wed, 14 Oct 2009 08:15:01 -0400, #ponce wrote:

 It's a bit unclear to me.
 
 I know I must compare references with is but pointers ?

There is no difference because you can't overload the == operator etc. 
for pointers.

Re: Should I compare pointers with is of == ?

2009-10-14 Thread Steven Schveighoffer


On Wed, 14 Oct 2009 08:15:01 -0400, #ponce alil...@gmail.com wrote:


It's a bit unclear to me.

I know I must compare references with is but pointers ?


Like Moritz said, there is no semantic difference with pointers, but you  
may consider comparing with is if you are looking for equivalence.  It  
cannot ever be overridden, so if for some reason you decided to change  
your pointer to a class reference, it doesn't accidentally morph into a  
virtual call (possibly to a null object causing a segfault).


-Steve

Re: Should I compare pointers with is of == ?

2009-10-14 Thread #ponce

Thanks for the answers.

Re: Should I compare pointers with is of == ?


Steven Schveighoffer wrote:

On Wed, 14 Oct 2009 08:15:01 -0400, #ponce alil...@gmail.com wrote:


It's a bit unclear to me.

I know I must compare references with is but pointers ?


Like Moritz said, there is no semantic difference with pointers, but you 
may consider comparing with is if you are looking for equivalence.  It 
cannot ever be overridden, so if for some reason you decided to change 
your pointer to a class reference, it doesn't accidentally morph into a 
virtual call (possibly to a null object causing a segfault).


-Steve


I agree, I only learned recently that == is not a direct pointer 
comparison for classes, I had to scramble all around my code to replace 
them with is and !is, so for good habit I'd go with using is for pointer 
equality too.


Jeremie

Re: Eliminate all Protection Attributes


Manfred_Nowak wrote:

For C# in

http://www.codeproject.com/Articles/42929/Csharp-4-0-Exposer-an-evil-
DynamicObject.aspx

describes code to disable all restrictions of visibility.

Is such possible in D too?

-manfred 


I don't think so, its really not a good thing to do anyways.

Re: Should I compare pointers with is of == ?

2009-10-14 Thread BCS


Hello #ponce,


It's a bit unclear to me.

I know I must compare references with is but pointers ?



Because it's always safe, I tend to use 'is' in any cases where one side 
could be null.

Re: Should I compare pointers with is of == ?

2009-10-14 Thread Max Samukha

On Wed, 14 Oct 2009 14:20:24 -0400, Justin Johansson n...@spam.com
wrote:

#ponce Wrote:

 It's a bit unclear to me. 
 
 I know I must compare references with is but pointers ?

Thanks for asking this question ponce; I've been getting into the habit of 
using 'is' for both pointers
and classes, so in similar vein to ponce's question, I'd like to ask if the 
following (where foo is
eother a pointer of class ref) is being overly pendantic in the case of null 
if tests:

if (foo !is null) {
  // can do something with foo
}

as opposed to the shorter form, but possibly incorrect or less safe

if (foo) {
  // can do somthing with foo
}

I think I would prefer the shorter form if its 100% good.

If you compare pointers or class references, it is 100% good to use
the shorter form. It is only 87% good if you compare arrays because
the shorter form means if (arr.ptr). So, if you are in the camp of
those who do not make a distinction between empty and null arrays you
should always use if (arr.length).


Thanks all.

Re: Should I compare pointers with is of == ?

Max Samukha Wrote:

 On Wed, 14 Oct 2009 14:20:24 -0400, Justin Johansson n...@spam.com
 wrote:
 
 #ponce Wrote:
 
  It's a bit unclear to me. 
  
  I know I must compare references with is but pointers ?
 
 Thanks for asking this question ponce; I've been getting into the habit of 
 using 'is' for both pointers
 and classes, so in similar vein to ponce's question, I'd like to ask if the 
 following (where foo is
 eother a pointer of class ref) is being overly pendantic in the case of null 
 if tests:
 
 if (foo !is null) {
   // can do something with foo
 }
 
 as opposed to the shorter form, but possibly incorrect or less safe
 
 if (foo) {
   // can do somthing with foo
 }
 
 I think I would prefer the shorter form if its 100% good.
 
 If you compare pointers or class references, it is 100% good to use
 the shorter form. It is only 87% good if you compare arrays because
 the shorter form means if (arr.ptr). So, if you are in the camp of
 those who do not make a distinction between empty and null arrays you
 should always use if (arr.length).

Thanks Max for clear and concise answer.
Now I can sleep again. :-) Justin.

Installing D1 and D2 side by side on linux

I got motivated by Walter putting out latest cuts of D1 and D2 (a D2 update in 
less than
a week recently!), so ...

Rather than having a single global install of DMD for linux, I'd like to have 
both D1 and D2
installed (i.e. distros unzipped into)
/opt/dmd1 and /opt/dmd2 respectively

and then be able to envoke rdmd on either version using the full path to the 
executable.

Unfortunately seems like this doesn't work and rdmd can't find dmd in either 
case:

D1

/opt/dmd1/linux/bin/rdmd test.d
sh: dmd: not found

D2

/opt/dmd2/linux/bin/rdmd test.d
sh: dmd: not found
sh: dmd: not found

So what's the best way to do a side-by-side install of D1 and D2 on linux?

As usual, thanks for all kind assistance,

-- Justin Johansson

[Issue 2158] Static associative array initialisation causes segmentation fault

http://d.puremagic.com/issues/show_bug.cgi?id=2158


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||clugd...@yahoo.com.au
 Resolution||FIXED


--- Comment #1 from Don clugd...@yahoo.com.au 2009-10-14 00:08:04 PDT ---
This was fixed sometime before DMD2.022

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2983] Elaborate restricted variadic function does not compile

http://d.puremagic.com/issues/show_bug.cgi?id=2983


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don clugd...@yahoo.com.au 2009-10-14 00:09:03 PDT ---
This is failing because 'a' isn't available while in the constraint.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 730] broken operator handling of ifloat/idouble/ireal

http://d.puremagic.com/issues/show_bug.cgi?id=730


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||clugd...@yahoo.com.au
 Resolution||FIXED


--- Comment #4 from Don clugd...@yahoo.com.au 2009-10-14 00:07:25 PDT ---
Fixed in DMD1.048

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3395] Ambiguous array operations

http://d.puremagic.com/issues/show_bug.cgi?id=3395



--- Comment #1 from Sobirari Muhomori dfj1es...@sneakemail.com 2009-10-14 
01:31:43 PDT ---
This also has to do with type safety.
---
a[]=b[];
---
This expression is ambiguous. What was meant? Copy items from b[] slice to a[]
slice or assign b[] slice to each item in a[] slice?
Ambiguity resolution:
---
a[]=b[]; //copy items from b to a
a[]=b; //assign b slice to each item in a slice
a[]=b[0..$]; //ditto
---

And types for the operation must match or an error will be issued.
---
T[] a,b;
a[]=b;
---
Currently this is accepted, but should fail, the right side expression in this
assignment must be of type T (or T[] with array op).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3392] a cast of this to void in tango.core.Thread is not allowed

http://d.puremagic.com/issues/show_bug.cgi?id=3392



--- Comment #3 from Fawzi Mohamed fa...@gmx.ch 2009-10-14 01:49:24 PDT ---
thanks!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2815] Attributes at end of file accepted

http://d.puremagic.com/issues/show_bug.cgi?id=2815


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-14 
02:02:37 PDT ---
This appears to already be fixed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3396] New: Call of abstract method not detected by semantic check

http://d.puremagic.com/issues/show_bug.cgi?id=3396

   Summary: Call of abstract method not detected by semantic check
   Product: D
   Version: 2.031
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dfj1es...@sneakemail.com


--- Comment #0 from Sobirari Muhomori dfj1es...@sneakemail.com 2009-10-14 
02:20:30 PDT ---
---
abstract class A
{
abstract void M();
}

class B:A
{
override void M(){ writeln(B.M); super.M(); }
}

int main()
{
auto b=new B();
b.M();
return 0;
}
---

dmd -c tmp.d -w -o-

dmd -w -run tmp.d
OPTLINK (R) for Win32  Release 8.00.1
Copyright (C) Digital Mars 1989-2004  All rights reserved.
tmp.obj(tmp)
 Error 42: Symbol Undefined _D3tmp1A1MMFZv
--- errorlevel 1

Compilation with -o- passes successfully.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3397] New: Unintended function call to static opCall

http://d.puremagic.com/issues/show_bug.cgi?id=3397

   Summary: Unintended function call to static opCall
   Product: D
   Version: 1.048
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: moritzwarn...@web.de


--- Comment #0 from Moritz Warning moritzwarn...@web.de 2009-10-14 06:27:15 
PDT ---
Tested with DMD 1.049 and svn r208.
It's a blocker for Tango.

Error: cannot implicitly convert expression (stack.pop()) of type Pair!(uint)
to uint



struct Pair(T)
{
static Pair opCall(T a, T b)
{
return Pair.init;
}
}

struct Stack(T)
{
T pop()
{
return T.init;
}
}

void main()
{
Stack!(Pair!(uint)) stack;
Pair!(uint) item = stack.pop; //this line fails, works with stack.pop() or
auto
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3392] a cast of this to void in tango.core.Thread is not allowed

http://d.puremagic.com/issues/show_bug.cgi?id=3392


Moritz Warning moritzwarn...@web.de changed:

   What|Removed |Added

 CC||moritzwarn...@web.de


--- Comment #4 from Moritz Warning moritzwarn...@web.de 2009-10-14 06:39:49 
PDT ---
Works with r208. Thanks!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 2983] Elaborate restricted variadic function does not compile

http://d.puremagic.com/issues/show_bug.cgi?id=2983



--- Comment #2 from Andrei Alexandrescu and...@metalanguage.com 2009-10-14 
07:01:38 PDT ---
(In reply to comment #1)
 This is failing because 'a' isn't available while in the constraint.

Exactly. The idea is that making the parameter names available would simplify
writing template constraints a lot.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 3398] New: Version block inside a union screws data alignment