date:20110204

On Friday 04 February 2011 00:23:05 Andre Tampubolon wrote:
> Thanks. Now I managed to succesfully build dmd and druntime.
> The next is phobos. I got this:
> 
> make -f win32.mak
> dmd -c -O -release -nofloat -w -d etc\c\zlib.d -ofCzlib.obj
> object.d: Error: module object is in file 'object.d' which cannot be read
> Specify path to file 'object.d' with -I switch

Is druntime one directory below Phobos? That is, are the phobos and druntime 
directories in the same directory? If not, the phobos build will fail to find 
druntime - which would include object.d - and then it can't build.

- Jonathan M Davis

Re: David Simcha's std.parallelism

David,

On Thu, 2011-02-03 at 20:56 -0500, dsimcha wrote:
> Ok, I finally got around to tackling most of this.  See individual 
> replies below.

Any chance you can put this package in a separate DVCS repository (I'll
assume Git given the way the rest of D is going) so that updates can be
picked up and tried out?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: std.xml should just go

2011-02-04 Thread Don


Andrei Alexandrescu wrote:

On 2/3/11 7:56 PM, BLS wrote:



I got more and more the feeling that the D2 monster was made just for
ranges. The smart and elegant D1 design is definitely dead an gone. I
think I am not the only one who would prefer a D1 plus instead of D2.
bjoern


All in all it's fair to say that if you hate ranges you're going to 
dislike D2, and there's little that can be done about that.


Yes, but...

I think we really, really, need to work on making Phobos less daunting.
Right now, we have most of the functionality. But some things are 
unnecessarily complicated -- some are historical, some are workarounds 
for compiler bugs (many of which are now fixed), some are rough edges in 
the language definition which could probably be fixed.


We don't have many examples; many discussions and explanations assume 
too much familiarity with terminology and concepts from functional 
programming languages; and probably most importantly, we don't have 
tutorials.


All these things can and will be fixed. But right now, the learning 
curve is horrible, and it's a major turnoff for people.

Re: std.xml should just go


Max Samukha wrote:

.NET and Qt do have slices of some kind:

http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx
http://doc.qt.nokia.com/latest/qstringref.html#details

I am not sure whether their XML libraries use those.


.net's slices are inadequate, because its strings are not interchangeable with 
slices. When they're not interchangeable, then you wind up being forced to make 
copies.

Re: std.unittests [updated] for review

2011-02-04 Thread Brad Roberts

On 2/1/2011 9:12 AM, Andrei Alexandrescu wrote:
> On 2/1/11 10:51 AM, Michel Fortin wrote:
>> On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
>>  said:
>> TypeInfo holds a pointer to the toString function, so if the compiler
>> passes the two operands as D-style variadic arguments to the assert
>> handler, the assert handler can use toString to print them. The operator
>> should be passed as a string.
> 
> In that case problem solved. Don, if you arrange things such that this 
> user-level code:
> 
> int a = 42;
> double b = 3.14;
> assert(a <= b, "Something odd happened");
> 
> ultimately calls this runtime function:
> 
> assertCmpFailed("<=", "42", "3.14", "Something odd happened");
> 
> I promise I'll discuss with Sean and implement what it takes in druntime to 
> get that completed.
> 
> We need to finalize that before Feb 7 though because on that date the vote 
> for Jonathan's library closes. If you do
> implement that, probably we'll need to reject the library in the current form 
> and propose back an amended version.
> 
> 
> Andrei

I agree with Don.  The proposed set of functions are great from an output 
perspective, but awful from a crisp syntax
standpoint.  They're a work around for the underlying problem: assert needs a 
UI face lift (though I remember when
assert didn't even support a text output -- adding that was my first 
contribution to the compiler/language).  There are
certainly complexities in pulling apart the bool expression though, and I'm not 
sure what a good solution is for that.

If there's any sort of consensus around focusing on assert instead (and I 
recognize that there isn't yet), some pre-set
arbitrary deadline isn't terribly relevant.  Having one by the 7th is kinda 
unlikely.

As a further point against the assertPred!op model, consider why the use of 
postfix/rpn calculators is restricted to a
very small subset of advanced calculators.  It's just now how most people think 
about expressions.

Later,
Brad

Re: std.xml should just go

2011-02-04 Thread Andrei Alexandrescu


On 2/4/11 3:15 AM, Don wrote:

Andrei Alexandrescu wrote:

On 2/3/11 7:56 PM, BLS wrote:



I got more and more the feeling that the D2 monster was made just for
ranges. The smart and elegant D1 design is definitely dead an gone. I
think I am not the only one who would prefer a D1 plus instead of D2.
bjoern



All in all it's fair to say that if you hate ranges you're going to
dislike D2, and there's little that can be done about that.


Yes, but...

I think we really, really, need to work on making Phobos less daunting.
Right now, we have most of the functionality. But some things are
unnecessarily complicated -- some are historical, some are workarounds
for compiler bugs (many of which are now fixed), some are rough edges in
the language definition which could probably be fixed.

We don't have many examples; many discussions and explanations assume
too much familiarity with terminology and concepts from functional
programming languages; and probably most importantly, we don't have
tutorials.

All these things can and will be fixed. But right now, the learning
curve is horrible, and it's a major turnoff for people.


Absolutely. There are some major strides we have and can make, enabled 
by recent bug fixes and language improvements. For example a lot of 
things are made considerably easier by auto returns. Then I think 
relaxing the rules for eponymous templates would tremendously reduce 
code size for a variety of templates. Finally, eliminating bugs and 
undue limitations from the language will again allow us to simplify 
things a lot.


With documentation and tutorials I am confident the entire community 
will help in time.



Andrei

Re: std.unittests [updated] for review

2011-02-04 Thread Andrei Alexandrescu


On 2/4/11 3:27 AM, Brad Roberts wrote:

On 2/1/2011 9:12 AM, Andrei Alexandrescu wrote:

On 2/1/11 10:51 AM, Michel Fortin wrote:

On 2011-02-01 11:31:54 -0500, Andrei Alexandrescu
  said:
TypeInfo holds a pointer to the toString function, so if the compiler
passes the two operands as D-style variadic arguments to the assert
handler, the assert handler can use toString to print them. The operator
should be passed as a string.


In that case problem solved. Don, if you arrange things such that this 
user-level code:

int a = 42;
double b = 3.14;
assert(a<= b, "Something odd happened");

ultimately calls this runtime function:

assertCmpFailed("<=", "42", "3.14", "Something odd happened");

I promise I'll discuss with Sean and implement what it takes in druntime to get 
that completed.

We need to finalize that before Feb 7 though because on that date the vote for 
Jonathan's library closes. If you do
implement that, probably we'll need to reject the library in the current form 
and propose back an amended version.


Andrei


I agree with Don.  The proposed set of functions are great from an output 
perspective, but awful from a crisp syntax
standpoint.  They're a work around for the underlying problem: assert needs a 
UI face lift (though I remember when
assert didn't even support a text output -- adding that was my first 
contribution to the compiler/language).  There are
certainly complexities in pulling apart the bool expression though, and I'm not 
sure what a good solution is for that.

If there's any sort of consensus around focusing on assert instead (and I 
recognize that there isn't yet), some pre-set
arbitrary deadline isn't terribly relevant.  Having one by the 7th is kinda 
unlikely.

As a further point against the assertPred!op model, consider why the use of 
postfix/rpn calculators is restricted to a
very small subset of advanced calculators.  It's just now how most people think 
about expressions.

Later,
Brad


We need to have at least a definite decision by Feb 7 from Don and 
Walter that work will be put or not into improving assert as discussed.


Andrei

Re: std.xml should just go

2011-02-04 Thread Max Samukha


On 02/04/2011 11:24 AM, Walter Bright wrote:

Max Samukha wrote:

.NET and Qt do have slices of some kind:

http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx
http://doc.qt.nokia.com/latest/qstringref.html#details

I am not sure whether their XML libraries use those.


.net's slices are inadequate, because its strings are not
interchangeable with slices. When they're not interchangeable, then you
wind up being forced to make copies.


Right. The same applies to Qt. Whenever a QStringRef is converted to 
QString, a copy is made.

Re: std.xml should just go


On 02/04/2011 08:34 AM, Jonathan M Davis wrote:

Slices: just one more reason why D's arrays kick the pants of other languages'
arrays...


What are the other ones?

Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go


On 02/04/2011 10:15 AM, Don wrote:

Andrei Alexandrescu wrote:

On 2/3/11 7:56 PM, BLS wrote:



I got more and more the feeling that the D2 monster was made just for
ranges. The smart and elegant D1 design is definitely dead an gone. I
think I am not the only one who would prefer a D1 plus instead of D2.
bjoern



All in all it's fair to say that if you hate ranges you're going to dislike
D2, and there's little that can be done about that.


Yes, but...

I think we really, really, need to work on making Phobos less daunting.
Right now, we have most of the functionality. But some things are unnecessarily
complicated -- some are historical, some are workarounds for compiler bugs
(many of which are now fixed), some are rough edges in the language definition
which could probably be fixed.

We don't have many examples; many discussions and explanations assume too much
familiarity with terminology and concepts from functional programming
languages; and probably most importantly, we don't have tutorials.

All these things can and will be fixed. But right now, the learning curve is
horrible, and it's a major turnoff for people.


I do agree.
Would like to help on some of those points (eg tutorials, howtos, examples, and 
generally rewriting docs so that they do not assume familiarity fith FP /and/ 
with 99% of C++): but those points raised by Don, precisely, prevent me from 
getting a knowledge of D2 the language good enough to even dare thinking at 
such contributions. Nice clercle ;-)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go


On 02/04/2011 10:32 AM, Andrei Alexandrescu wrote:

relaxing the rules for eponymous templates


About that, I would love a tutorial about eponymous templates starting with 
their /purpose/ (why does this feature even exist? what does it /mean/? what 
does it compare/oppose to? why is one supposed to need/enjoy it? how is it 
supposed to help & make code better mirror model?) Same for alias template 
params. Same for a rather long list of features, probably.


Moreover, said purpose should be summarized in one line introducing *every* 
feature in language and stdlib references.


Denis
--
_
vita es estrany
spir.wikidot.com

A better assert() [was: Re: std.unittests [updated] for review]

Andrei:

> We need to have at least a definite decision by Feb 7 from Don and 
> Walter that work will be put or not into improving assert as discussed.

I think that fixing assert() is a better strategy, even it may require more 
work. A problem with assert is that it wants to do too many things, so there 
are problems:
- assert(0); to mean HALT, that gives some problems
- assert(class_instance); that calls its invariant. (I vaguely remember a 
problem with this with struct instance invariants).
- Not good enough for unittests, as seen in this thread.

So an effort to improve assert may solve all four those problems. Removing the 
two purposes (moving them to specialized and explicit features, specialized 
little tools) and adding the functionality we desire in unittesting.

Bye,
bearophile

Re: Who here actually uses D?


On 03/01/2011 20:53, Daniel Gibson wrote:

Am 02.01.2011 05:00, schrieb Walter Bright:

Caligo wrote:

You don't get it! If only one back-end was used then there wouldn't be
three different groups working on three different projects that try to
accomplish the same thing.


Back when there was only one D compiler, people complained there was
only one. They needed more to feel comfortable using it. Now that there
are three, the complaints switch 180 degrees.


It's just different (kinds of) people complaining ;-)


Indeed. But also, and in all fairness, I think some of the people that 
complained there was only one compiler, had in mind the desire to have a 
*different* implementation of a D compiler (this would be helpful, for 
example, to validate the "specification" of the D language). But that is 
not what we have, all current three compilers are based on DMD.


(note: I'm not implying having more compiler implementations is an 
important thing right now, or in the near future)



--
Bruno Medeiros - Software Engineer

Re: A better assert() [was: Re: std.unittests [updated] for review]

> Removing the two purposes (moving them to specialized and explicit features, 
> specialized little tools)

I want to stress the fact that moving those two unrelated sub-features away 
from assert into specialized features is not going to increase the language 
complexity, because those features are _already_ present and programmers need 
to remember them already. But currently they are hidden, half-invisible, and 
they interact badly with other things. So moving them into explicit little 
features makes the language more explicit, more readable and helps to remove 
warts, it doesn't make the language more complex (it may just increase 
front-end compiler complexity a bit).

Bye,
bearophile

Re: A better assert() [was: Re: std.unittests [updated] for review]

On Friday 04 February 2011 04:10:37 bearophile wrote:
> Andrei:
> > We need to have at least a definite decision by Feb 7 from Don and
> > Walter that work will be put or not into improving assert as discussed.
> 
> I think that fixing assert() is a better strategy, even it may require more
> work. A problem with assert is that it wants to do too many things, so
> there are problems: - assert(0); to mean HALT, that gives some problems
> - assert(class_instance); that calls its invariant. (I vaguely remember a
> problem with this with struct instance invariants). - Not good enough for
> unittests, as seen in this thread.
> 
> So an effort to improve assert may solve all four those problems. Removing
> the two purposes (moving them to specialized and explicit features,
> specialized little tools) and adding the functionality we desire in
> unittesting.

Making assert smarter with regards to errors so that it's better suited for 
unit 
tests makes sense, and I do find the assert(class_instance) bit to be rather 
disturbing given that it conflicts with how conditional checks using class 
instances usually works (I only recently found out that assert worked that way 
with class instances). However, I don't see why there would be any problem with 
assert(0) meaning halt. It's a normal assert in non-release mode and it sticks 
around in release mode, becoming a halt instruction. I use it that way all the 
time. I don't see any problem with it whatsoever.

- Jonathan M Davis

A monitor for every object

I have found an interesting post by Scott Johnson in this Lambda the Ultimate 
thread:
http://lambda-the-ultimate.org/node/724#comment-6621

He says:

>9th circle: Concurrent mutable state. The obnoxious practice of mutating 
>shared state from multiple threads of control, leading into a predictable 
>cycle of race conditions, deadlocks, and other assorted misbehavior from which 
>there is no return. And if a correct solution (for synchronization) is found 
>for a given program, chances are any substantial change to the program will 
>make it incorrect again. But you won't find it, instead your customer will. 
>Despite that, reams of code (and TONS of middleware) has been written to try 
>and make this tractable. And don't get me started on a certain programming 
>language which starts with "J" that saw fit to make EVERY object have its very 
>own monitor<

This is just one quotation, but I have found similar comments four or five 
other times around the Web.

So is the design choice of copying this part of the Java design inside D good? 
I'd like opinions on this topic.

Recently I have suggested an optional @nomonitor annotation for D classes (to 
optionally remove a word from class instances and to reduce class instantiation 
overhead a bit). Another option is doing the opposite, and defining a 
@withmonitor annotation where you want a class to have a monitor.

Bye,
bearophile

Re: A better assert() [was: Re: std.unittests [updated] for review]

Jonathan M Davis:

> However, I don't see why there would be any problem with 
> assert(0) meaning halt. It's a normal assert in non-release mode and it 
> sticks 
> around in release mode, becoming a halt instruction. I use it that way all 
> the 
> time. I don't see any problem with it whatsoever.

There was a recent discussion about this. The final consensus was that 
assert(0) to mean HALT is a small wart in the D language, but it's not worth 
fixing it, because it's a small enough defect. But if now assert() gets a 
significant facelift, then this little problem may be fixed along with the 
other two.

Bye,
bearophile

Re: A better assert() [was: Re: std.unittests [updated] for review]

> So moving them into explicit little features makes the language more

The two little features I am talking about are:
- a halt() somewhere like in core.bitop or std.intrinsic or the default object 
module to replace assert(0);
- And to use class_instance.invariant() to replace assert(class_instance).

Bye,
bearophile

Re: A better assert() [was: Re: std.unittests [updated] for review]

On Friday 04 February 2011 04:30:42 bearophile wrote:
> Jonathan M Davis:
> > However, I don't see why there would be any problem with
> > assert(0) meaning halt. It's a normal assert in non-release mode and it
> > sticks around in release mode, becoming a halt instruction. I use it
> > that way all the time. I don't see any problem with it whatsoever.
> 
> There was a recent discussion about this. The final consensus was that
> assert(0) to mean HALT is a small wart in the D language, but it's not
> worth fixing it, because it's a small enough defect. But if now assert()
> gets a significant facelift, then this little problem may be fixed along
> with the other two.

Well, aside from the fact that I don' t think that it's a wart at all, I would 
point out that TDPL specifically points out that assert(false) is converted to 
a 
halt instruction. So, given that it's not a serious problem, I really don't 
think that it's reasonable to change it. At this point, for us to change 
something that's in TDPL, it pretty much needs to need changing, and I really 
don't think that assert(0) qualifies.

- Jonathan M Davis

Re: David Simcha's std.parallelism

2011-02-04 Thread dsimcha

I could move it over to github, though I'll wait to do that until I get 
a little more comfortable with Git.  I had never used Git before until 
Phobos switched to it.  In the mean time, to remind, the code is at:


http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d

The docs are at:

http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html

On 2/4/2011 3:45 AM, Russel Winder wrote:

David,

On Thu, 2011-02-03 at 20:56 -0500, dsimcha wrote:

Ok, I finally got around to tackling most of this.  See individual
replies below.


Any chance you can put this package in a separate DVCS repository (I'll
assume Git given the way the rest of D is going) so that updates can be
picked up and tried out?

Re: A monitor for every object

2011-02-04 Thread Mafi


Am 04.02.2011 13:26, schrieb bearophile:

I have found an interesting post by Scott Johnson in this Lambda the Ultimate 
thread:
http://lambda-the-ultimate.org/node/724#comment-6621

He says:


9th circle: Concurrent mutable state. The obnoxious practice of mutating shared state from 
multiple threads of control, leading into a predictable cycle of race conditions, deadlocks, 
and other assorted misbehavior from which there is no return. And if a correct solution (for 
synchronization) is found for a given program, chances are any substantial change to the 
program will make it incorrect again. But you won't find it, instead your customer will. 
Despite that, reams of code (and TONS of middleware) has been written to try and make this 
tractable. And don't get me started on a certain programming language which starts with 
"J" that saw fit to make EVERY object have its very own monitor<


This is just one quotation, but I have found similar comments four or five 
other times around the Web.

So is the design choice of copying this part of the Java design inside D good? 
I'd like opinions on this topic.

Recently I have suggested an optional @nomonitor annotation for D classes (to 
optionally remove a word from class instances and to reduce class instantiation 
overhead a bit). Another option is doing the opposite, and defining a 
@withmonitor annotation where you want a class to have a monitor.

Bye,
bearophile
Please note that D has a syntax for such things (optimizations with 
little behavior change). It called 'pragma'. Exchange @nomonitor with 
pragma(nomonitor) and I'm for your idea. pragma looks and feels better IMO.


Mafi

PS: cant see any @ttributes more :(

Re: A monitor for every object

On Fri, 04 Feb 2011 07:26:22 -0500, bearophile   
wrote:


I have found an interesting post by Scott Johnson in this Lambda the  
Ultimate thread:

http://lambda-the-ultimate.org/node/724#comment-6621

He says:

9th circle: Concurrent mutable state. The obnoxious practice of  
mutating shared state from multiple threads of control, leading into a  
predictable cycle of race conditions, deadlocks, and other assorted  
misbehavior from which there is no return. And if a correct solution  
(for synchronization) is found for a given program, chances are any  
substantial change to the program will make it incorrect again. But you  
won't find it, instead your customer will. Despite that, reams of code  
(and TONS of middleware) has been written to try and make this  
tractable. And don't get me started on a certain programming language  
which starts with "J" that saw fit to make EVERY object have its very  
own monitor<


This is just one quotation, but I have found similar comments four or  
five other times around the Web.


So is the design choice of copying this part of the Java design inside D  
good? I'd like opinions on this topic.


Recently I have suggested an optional @nomonitor annotation for D  
classes (to optionally remove a word from class instances and to reduce  
class instantiation overhead a bit). Another option is doing the  
opposite, and defining a @withmonitor annotation where you want a class  
to have a monitor.


D's monitors are lazily created, so there should be no issue with resource  
allocation.  If you don't ever lock an object instance, it's not going to  
consume any resources.  Most of the time the extra word isn't noticed  
because the memory size of a class is usually not exactly a power of 2.


D also allows you to replace it's monitor with a custom monitor object  
(i.e. core.sync.Mutex) so you can have more control over the mutex, assign  
the same mutex to multiple objects, use conditions, etc.  It's much more  
flexible than Java or C# IMO.


-Steve

Re: Portability bug in integral conversion


On 17/01/2011 00:09, Andrei Alexandrescu wrote:

On 1/16/11 5:24 PM, Graham St Jack wrote:

On 16/01/11 08:52, Andrei Alexandrescu wrote:

We've spent a lot of time trying to improve the behavior of integral
types in D. For the most part, we succeeded, but the success was
partial. There was some hope with the polysemy notion, but it
ultimately was abandoned because it was deemed too difficult to
implement for its benefits, which were considered solving a minor
annoyance. I was sorry to see it go, and I'm glad that now its day of
reckoning has come.

Some of the 32-64 portability bugs have come in the following form:

char * p;
uint a, b;
...
p += a - b;

On 32 bits, the code works even if a < b: the difference will become a
large unsigned number, which is then converted to a size_t (which is a
no-op since size_t is uint) and added to p. The pointer itself is a
32-bit quantity. Due to two's complement properties, the addition has
the same result regardless of the signedness of its operands.

On 64-bits, the same code has different behavior. The difference a - b
becomes a large unsigned number (say e.g. 4 billion), which is then
converted to a 64-bit size_t. After conversion the sign is not
extended - so we end up with the number 4 billion on 64-bit. That is
added to a 64-bit pointer yielding an incorrect value. For the
wraparound to work, the 32-bit uint should have been sign-extended to
64 bit.

To fix this problem, one possibility is to mark statically every
result of one of uint-uint, uint+int, uint-int as "non-extensible",
i.e. as impossible to implicitly extend to a 64-bit value. That would
force the user to insert a cast appropriately.

Thoughts? Ideas?


Andrei

It seems to me that the real problem here is that it isn't meaningful to
perform (a-b) on unsigned integers when (a

That's too inefficient.

Andrei


Really? :/ Even if the runtime error can be optionally disabled on 
compilation, like arrays bound checking?



--
Bruno Medeiros - Software Engineer

Re: What Makes A Programming Language Good


On 18/01/2011 05:20, Walter Bright wrote:

http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/



"I quit being a professional programmer."

I usually avoid discussions and dismiss out of hand opinions about 
software development from those who no longer develop code (did that 
recently with my boss, to cut off a discussion). Mostly for time saving, 
it's not that I think they automatically wrong, or even likely to be wrong.


Still, I read that article, and it's not bad, there are some good 
points. In fact, I strongly agree, in essence, with one of the things he 
said: That language ecosystems are what matter, not just the language 
itself. At least for most programmers, what you want is to develop 
software, software that is useful or interesting, it's not about staring 
at the beauty of your code and that's it.
This, any language community that focuses excessively on the language 
only and forsakes, dismisses, or forgets the rest of the toolchain and 
ecosystem, will never succeed beyond a niche. (*cough* LISP *cough*)


--
Bruno Medeiros - Software Engineer

Re: What Makes A Programming Language Good


On 18/01/2011 16:29, Andrei Alexandrescu wrote:


Package management something we really need to figure out for D.
Question is, do we have an expert on board (apt-get architecture, cpan,
rubygems...)?

Andrei


I agree. Having worked on Eclipse a lot, which uses OSGi as the 
underlying package management system, I really stand by it's usefulness. 
For larger projects it is chaos without it (more or less chaos depending 
on the particular situation).



--
Bruno Medeiros - Software Engineer

Re: renamepalooza time


On 22/01/2011 00:16, Andrei Alexandrescu wrote:


Ever since I worked with STL, I fell in love with
names_with_underscores. I can't explain it, but my feeling is that code
using that convention is calm and levelheaded.



The explanation for that could very well be some form of Pavlovian 
reinforcement/conditioning. :)


--
Bruno Medeiros - Software Engineer

Re: A monitor for every object

2011-02-04 Thread Kagamin

bearophile Wrote:

> a certain programming language which starts with "J" that saw fit to make 
> EVERY object have its very own monitor<
> So is the design choice of copying this part of the Java design inside D 
> good? I'd like opinions on this topic.

C# has this design too, but locking a common object directly is not used. C# 
used to create separate object for locking, the property to access it being 
called SyncRoot. It's implementation is a usual combination of new object() and 
CompareExchange.

http://msdn.microsoft.com/en-us/library/system.collections.icollection.syncroot.aspx

I don't feel the need for locking functionality in Object, this is usually a 
major design decision for a couple of classes - even in a large project. After 
all, after this design decision you should also carefully implement the locking 
in the code using the object, this will take some time, so it can't be a 
light-minded decision.

Re: How to build the druntime (Windows)?

2011-02-04 Thread Andre Tampubolon


Well previously phobos and druntime directories were in the same directory.
So I move druntime directory into phobos', and the layout looks like this:
04-Feb-11  09:22 PM  .
04-Feb-11  09:22 PM  ..
04-Feb-11  08:28 AM 3,918 crc32.d
04-Feb-11  09:22 PM 0 dirr.txt
04-Feb-11  03:20 PM  druntime
04-Feb-11  08:28 AM  etc
04-Feb-11  08:28 AM 8,400 index.d
04-Feb-11  08:28 AM 1,361 LICENSE_1_0.txt
04-Feb-11  08:28 AM 9,523 posix.mak
04-Feb-11  08:28 AM  std
04-Feb-11  08:28 AM14,464 std.ddoc
04-Feb-11  08:28 AM 3,498 unittest.d
04-Feb-11  08:28 AM30,394 win32.mak

Still fail to build, though...

On 04-Feb-11 3:33 PM, Jonathan M Davis wrote:

On Friday 04 February 2011 00:23:05 Andre Tampubolon wrote:

Thanks. Now I managed to succesfully build dmd and druntime.
The next is phobos. I got this:

make -f win32.mak
dmd -c -O -release -nofloat -w -d etc\c\zlib.d -ofCzlib.obj
object.d: Error: module object is in file 'object.d' which cannot be read
Specify path to file 'object.d' with -I switch


Is druntime one directory below Phobos? That is, are the phobos and druntime
directories in the same directory? If not, the phobos build will fail to find
druntime - which would include object.d - and then it can't build.

- Jonathan M Davis



--
- Andre Tampubolon -

Re: A monitor for every object

2011-02-04 Thread Kagamin

Kagamin Wrote:

> bearophile Wrote:
> 
> > a certain programming language which starts with "J" that saw fit to make 
> > EVERY object have its very own monitor<
> > So is the design choice of copying this part of the Java design inside D 
> > good? I'd like opinions on this topic.
> 
> C# has this design too, but locking a common object directly is not used. C# 
> used to create separate object for locking, the property to access it being 
> called SyncRoot. It's implementation is a usual combination of new object() 
> and CompareExchange.

Ah, I forgot to say, that C# has a sort of guideline to lock the SyncRoot 
instead of collection itself.

Re: Should we have an Unimplemented Attribute?

On 2/4/11, Jonathan M Davis  wrote:
> On Thursday 03 February 2011 20:51:01 Andrej Mitrovic wrote:
>> Ah, I've just realized we already have the @disable attribute. This is
>> practically what I was looking for.
>
> That's more for doing stuff like disabling functions which the compiler
> normally
> takes care of if you don't - such as opAssign on arrays - but I suppose that
> you
> could use it for what you were looking for. Really though, I'd say that
> correct
> solution is usually to just comment out the code.
>
> - Jonathan M Davis
>

I don't find that to be a good solution, unless I add another comment
stating why the code was commented out. Otherwise, how am I to figure
out why I commented some code out when I read it several weeks later?
Is the code unfinished, faulty, a test case, ready to be removed, etc?
Who knows..

You can take a look at Phobos for plenty of examples of commented out
code, without any backup comments stating why they're commented out.
Try figuring out why they're commented out if you haven't written that
code yourself. You can only guess, or ask in the NG and hope someone
remembers why.

Re: What Makes A Programming Language Good


"I quit being a professional programmer."

I usually avoid discussions and dismiss out of hand opinions about  
software development from those who no longer develop code (did that  
recently with my boss, to cut off a discussion). Mostly for time saving,  
it's not that I think they automatically wrong, or even likely to be  
wrong.


We are still in the stone age of programming, what has changed in last 10  
years? Nothing.

Re: A better assert() [was: Re: std.unittests [updated] for review]


On 02/04/2011 01:16 PM, bearophile wrote:

Removing the two purposes (moving them to specialized and explicit features, 
specialized little tools)


I want to stress the fact that moving those two unrelated sub-features away 
from assert into specialized features is not going to increase the language 
complexity, because those features are _already_ present and programmers need 
to remember them already. But currently they are hidden, half-invisible, and 
they interact badly with other things. So moving them into explicit little 
features makes the language more explicit, more readable and helps to remove 
warts, it doesn't make the language more complex (it may just increase 
front-end compiler complexity a bit).


+++

Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go

2011-02-04 Thread Kagamin

Max Samukha Wrote:

> .NET and Qt do have slices of some kind:
> 
> http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx
> http://doc.qt.nokia.com/latest/qstringref.html#details
> 
> I am not sure whether their XML libraries use those.

C# uses old good String.

std.unittests/exception Update and Vote

Okay, the latest code and documentation is here: http://is.gd/HZQwNz

I've also made the changes in my github fork of Phobos here: 
https://github.com/jmdavis/phobos . So, if this passes the vote, it's just a 
pull request away from being in Phobos.

assertPred, assertThrown, assertNotThrown, and collectExceptionMsg have been 
merged into std.exception and their documentation updated again. There are 
fewer 
examples now, and hopefully it's more to everyone's liking, though the changes 
aren't drastic. Hopefully, I didn't miss anything that needed changing.

Also, since collectExceptionMsg was catching Throwable and collectException was 
catching Exception, I made them both templated on the type to catch with 
Exception as the default. So, you can use both to catch any Throwable, but they 
default to Exception, so no code should break as a result. I kept Exception in 
their names with the idea that you really shouldn't be catching Throwable or 
Errors except in exception circumstances, so collectException is more correct 
for general use and its name doesn't encourage people to catch the wrong thing 
(it also avoids having to create an alias for backwards compatability).

We're coming up on the time when the proposal has to be voted in or out (Feb 
7th). It looks like Don and/or Walter _may_ make it so that assert is improved 
such that it does some of what assertPred does, printing much better error 
messages, and if that's the case, assertPred will need to be reworked or tossed 
entirely (but whether that happens depends on what they decide between now and 
Feb 7th). So, unless Andrei has a problem with it, I'd ask that you vote for 
assertPred separately from assertThrown, assertNotThrown, and 
collectExceptionMsg. So, if it's decided that assert is going to be improved 
and 
assertPred won't work as is, at least we can get assertThrown, assertNotThrown, 
and collectExceptionMsg into Phobos (assuming that they pass the vote). If 
assert is improved and assertPred doesn't make it in, and some portion of 
assertPred's other capabilities should still be in Phobos, they can be reworked 
in a future proposal (though if assert doesn't get improved, then they're in 
assertPred as it is).

So, please make any last comments or suggestions on this proposal, and vote on 
whether you think that assertPred should be in Phobos (assuming that assert 
isn't going to be improved such that assertPred isn't necessary) and whether 
you 
think that assertThrown, assertNotThrown, and collectExceptionMsg should get in 
regardless of whether assertPred does.

- Jonathan M Davis

Re: A better assert() [was: Re: std.unittests [updated] for review]


On 02/04/2011 01:40 PM, bearophile wrote:

So moving them into explicit little features makes the language more


The two little features I am talking about are:
- a halt() somewhere like in core.bitop or std.intrinsic or the default object 
module to replace assert(0);


What about exit()? What would be the practical or semantic diff of halt() 
compared to exit()?


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Should we have an Unimplemented Attribute?

On Friday 04 February 2011 06:42:20 Andrej Mitrovic wrote:
> On 2/4/11, Jonathan M Davis  wrote:
> > On Thursday 03 February 2011 20:51:01 Andrej Mitrovic wrote:
> >> Ah, I've just realized we already have the @disable attribute. This is
> >> practically what I was looking for.
> > 
> > That's more for doing stuff like disabling functions which the compiler
> > normally
> > takes care of if you don't - such as opAssign on arrays - but I suppose
> > that you
> > could use it for what you were looking for. Really though, I'd say that
> > correct
> > solution is usually to just comment out the code.
> > 
> > - Jonathan M Davis
> 
> I don't find that to be a good solution, unless I add another comment
> stating why the code was commented out. Otherwise, how am I to figure
> out why I commented some code out when I read it several weeks later?
> Is the code unfinished, faulty, a test case, ready to be removed, etc?
> Who knows..
> 
> You can take a look at Phobos for plenty of examples of commented out
> code, without any backup comments stating why they're commented out.
> Try figuring out why they're commented out if you haven't written that
> code yourself. You can only guess, or ask in the NG and hope someone
> remembers why.

Marking it as disabled doesn't help much. You still don't know _why_ it was 
disabled. Even if you know that that means that it's unfinished, you still 
wouldn't know what state it was in. If you did, commenting it out would have 
been plenty. So, regardless, you really should have an explanatory comment. I'm 
not about to claim that the commented out but unexplained code in Phobos is how 
such code should have been dealt with, but I really do think that unfinished 
code 
should be left commented until it _is_ finished. If an explanatory comment is 
necessary, then it should be added. Using @disable wouldn't make an explanatory 
comment any less necessary.

- Jonathan M Davis

Re: A better assert() [was: Re: std.unittests [updated] for review]

2011-02-04 Thread Daniel Gibson


Am 04.02.2011 15:57, schrieb spir:

On 02/04/2011 01:40 PM, bearophile wrote:

So moving them into explicit little features makes the language more


The two little features I am talking about are:
- a halt() somewhere like in core.bitop or std.intrinsic or the
default object module to replace assert(0);


What about exit()? What would be the practical or semantic diff of
halt() compared to exit()?

Denis


IIRC halt should produce a core-dump, so you can use a debugger to see 
what went wrong afterwards.


Cheers,
- Daniel

Re: A better assert() [was: Re: std.unittests [updated] for review]

On Friday 04 February 2011 04:40:35 bearophile wrote:
> > So moving them into explicit little features makes the language more
> 
> The two little features I am talking about are:
> - a halt() somewhere like in core.bitop or std.intrinsic or the default
> object module to replace assert(0); - And to use
> class_instance.invariant() to replace assert(class_instance).

assert(0) has the advantage of being a normal assertion in non-release mode. It 
also makes it clear that that code path should _never_ be reached. I don't 
think 
that halt would be as clear in that regard and it _certainly_ wouldn't imply 
that it would be a normal assert in non-release mode. We'd then have problems 
with halt not actually being halt in non-release mode...

I'm _definitely_ against changing assert(0). The real question though is 
whether 
you can convince Walter (which I doubt, but I don't know). Still, making such a 
change _would_ contradict TDPL, which is supposed to be a major no-no at this 
point.

- Jonathan M Davis

Re: A better assert() [was: Re: std.unittests [updated] for review]

2011-02-04 Thread Adam Ruppe

bearophile wrote:
> - assert(0); to mean HALT, that gives some problems

I like it. It's convenient and clear - assert(0) means
you cannot proceed in any situation, and that should include
release modes. (Indeed, IMO any assert that can be proven
to fail at compile time should always remain and one proven
to succeed can always be removed.

Only if the compiler isn't sure does it actually do a runtime
check. -release simply says "if not sure, trust me and don't bother"
instead of the default of "if not sure, check for me".

I think the compiler pretty much does this already.)

> - assert(class_instance); that calls its invariant. (I vaguely
> remember a problem with this with struct instance invariants).

Again, I think this makes sense too. assert(n) is saying, in
principle, "ensure n is valid". Calling the invariant is part
of ensuring it is valid.

The only problem is a minor bug - it forgets to check for null
before calling the invariant. That should, of course, be fixed,
but the main behavior makes sense.

Re: renamepalooza time

2011-02-04 Thread Mafi


Am 04.02.2011 15:11, schrieb Bruno Medeiros:

On 22/01/2011 00:16, Andrei Alexandrescu wrote:


Ever since I worked with STL, I fell in love with
names_with_underscores. I can't explain it, but my feeling is that code
using that convention is calm and levelheaded.



The explanation for that could very well be some form of Pavlovian
reinforcement/conditioning. :)


I would say it's the Stockholm syndrom :)

Mafi

Re: Calling method by name.

2011-02-04 Thread Jacob Carlborg


On 2011-02-04 04:29, Robert Jacques wrote:

On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg  wrote:


On 2011-02-03 05:52, Robert Jacques wrote:

On Wed, 02 Feb 2011 12:55:37 -0500, %u  wrote:


I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?

Would something like the following be possible?

string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);

Thanks


I've been working on an update to std.variant, which includes a
compile-time reflection to runtime-reflection system. (See
https://jshare.johnshopkins.edu/rjacque2/public_html/) From the docs:

Manually registers a class with Variant's runtime-reflection system.
Note that Variant automatically registers any types it is exposed. Note
how in the example below, only Student is manually registered; Grade is
automatically registered by Variant via compile-time reflection of
Student.

module example;
class Grade { real mark; }
class Student { Grade grade; }
void main(string[] args) {
Variant.__register!Student;
Variant grade = Object.factory("example.Grade");
grade.mark(96.6);
assert(grade.mark == 96.6);
}

And dynamic method/field calls are handled via the __reflect(string
name, Variant[] args...) method like so:

grade.__reflect("mark",Variant(96.6));
assert(grade.__reflect("mark") == 96.6);


Why would you need to pass in Variants in __reflect? Why not just make
it a variadic method and automatically convert to Variant?



Well, opDispatch does exactly that. __reflect, on the other hand, was
designed as a quasi-backend function primarily for a) internal use
(hence the double underscore), b) scripting language
interfacing/implementing and c) user-extension. So efficiency was of key
importance. And the reflection system is extensible, as Variant knows to
call __reflect on user defined types. This makes things like prototype
style objects possible. (There's even a beta implementation of a
prototype object in the library) But this requires that the use
__reflect methods not be templated.

I'm not well versed in dynamic reflection and its use cases, so when I
considered the combination of a runtime method name and compile-time
argument type information, I classed it as 'rare in practice'. But if
that's not the case, I'd like to know and would greatly appreciate a use
case/unit test.


I recommend looking at Ruby, it has very good support for runtime 
reflection. ActiveRecord in Rails is hevaly based on runtime reflection. 
For example, given the following Ruby class:


class Post < ActiveRecord::Base
end

The class "Post" maps to the database table "posts", no configuration is 
necessary. Then you can use the column names in the table as fields to 
set and get data, like this:


post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database

All this is done using runtime reflection. Then you can query the 
database, also using runtime reflection:


Post.find_by_name_and_body("some title", "the body")

Will find the first row where "title" and "body" matches the given values.

--
/Jacob Carlborg

Re: new documentation format for std.algorithm

2011-02-04 Thread Jeff Nowakowski


On 02/03/2011 06:15 PM, David Nadlinger wrote:


This is exactly the issue I was talking about, using relative font
sizes in their current incarnation doesn't solve any problems per
se.


It does, as I explained in my other post to you. Repeating an assertion
is not a logical argument.


Also, it's precisely the point where one's ideal conceptions and
reality differ. Just imagine what would happen if Wikipedia used a
font-size of 1: Millions of users would complain that the body copy
is way too large for something encyclopedic in nature.


Imagine if they used a font-size of 1 and hardly anybody complained. You 
just made up some crazy number.


I'd like to know exactly why Wikipedia chose the font size they did. I 
looked around and couldn't find any reason for it. They did at one time 
do a usability study, but it didn't mention anything about font sizes. 
I'm willing to bet this decision was poorly made by scant evidence and 
personal preference of a few.



In the end, web development is not about constructing an ideal(istic)
world, but about catering end user needs. If you can unite the two
goals, that's great, but ignoring reality usually doesn't quite work
out well…


Exactly so, but the problem is that a certain set of web designers have 
fooled themselves into a fantasy that they have actually come to some 
practical solution by settling on "standard" pixel sizes, when they have 
chosen a solution that cannot work and fails in practice.


At least when you use default sizes and flow layout it works in a usable 
manner, meaning zoom works properly and the text should be at a readable 
size. It also allows for an approach where at least a user has a 
standard way to display their preferred font size by default instead of 
by the whims of some designer who treats the web as a print medium.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)


On 01/02/2011 23:07, Walter Bright wrote:

Bruno Medeiros wrote:

A more serious issue that I learned (or rather forgotten about before
and remembered now) is the whole DVCSes keep the whole repository
history locally aspect, which has important ramifications. If the
repository is big, although disk space may not be much of an issue,


I still find myself worrying about disk usage, despite being able to get
a 2T drive these days for under a hundred bucks. Old patterns of thought
die hard.


Well, like I said, my concern about size is not so much disk space, but 
the time to make local copies of the repository, or cloning it from the 
internet (and the associated transfer times), both of which are not 
neglectable yet.
My project at work could easily have gone to 1Gb of repo size if in the 
last year or so it has been stored on a DVCS! :S


I hope this gets addressed at some point. But I fear that the main 
developers of both Git and Mercurial may be too "biased" to experience 
projects which are typically somewhat small in size, in terms of bytes 
(projects that consist almost entirely of source code).
For example, in UI applications it would be common to store binary data 
(images, sounds, etc.) in the source control. The other case is what I 
mentioned before, wanting to store dependencies together with the 
project (in my case including the javadoc and source code of the 
dependencies - and there's very good reasons to want to do that).


In this analysis:
http://code.google.com/p/support/wiki/DVCSAnalysis
they said that Git has some functionality to address this issue:
"Client Storage Management. Both Mercurial and Git allow users to 
selectively pull branches from other repositories. This provides an 
upfront mechanism for narrowing the amount of history stored locally. In 
addition, Git allows previously pulled branches to be discarded. Git 
also allows old revision data to be pruned from the local repository 
(while still keeping recent revision data on those branches). With 
Mercurial, if a branch is in the local repository, then all of its 
revisions (back to the very initial commit) must also be present, and 
there is no way to prune branches other than by creating a new 
repository and selectively pulling branches into it. There has been some 
work addressing this in Mercurial, but nothing official yet."


However I couldn't find more info about this, and other articles and 
comments about Git seem to omit or contradict this... :S

Can Git really have an usable but incomplete local clone?

--
Bruno Medeiros - Software Engineer

Re: std.xml should just go

2011-02-04 Thread Eric Poggel


On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote:

At this point there is no turning back from ranges, unless we come about
with an even better idea (I discussed one with Walter but we're not
pursuing it yet).


Care to elaborate on the new idea?  Or at least a quick summary so we're 
not all left wondering?

Re: Calling method by name.

2011-02-04 Thread Adam Ruppe

Jacob Carlborg wrote:
> The class "Post" maps to the database table "posts", no configuration is
> necessary. Then you can use the column names in the table as fields to
> set and get data, like this:
>
> post = Post.new
> post.title = "some title"
> post.body = "the body"
> post.save # will update the database

Note that you can do this kind of thing with D's compile time
reflection and CTFE as well. That particular example works
in my own DataObject class (except I called it "commitChanges"
instead of "save").

Some of the stuff is just dynamic; just sugar around a string[string].
Most my own use of "runtime reflection" is just having some CTFE
go through and put the compile time info into those strings which
are used at runtime.

I do that for calling functions by name too, but mine does rely
upon some static info that probably isn't available to the OP.

For example for both, my new newsreader does both:

http://arsdnet.net/d-web-site/nntp/get-message

That screen is automatically generated by this prototype:

Post getMessage(string newsgroup, string messageId) {

The name of the function and arguments in the URL are pulled from
that single line of code. It uses the types of the arguments to
automatically generate an appropriate form.

The way I did it was to put all the public functions in a static
struct. Then, I mixin a template (called FancyMain!(methodStruct))
which scans the struct and generates the needed hashmaps and
delegates to call its methods by name.

http://arsdnet.net/d-web-site/arsd/web.d

That code is very ugly... but look at the prepareReflection and
generateWrapper functions.

Re: new documentation format for std.algorithm

2011-02-04 Thread David Nadlinger


On 2/4/11 4:39 PM, Jeff Nowakowski wrote:

It does, as I explained in my other post to you. Repeating an assertion
is not a logical argument.


I tried to explain the issue to you, but you have been quick to dismiss 
any attempt to do so based on your own opinion. I won't spend any more 
time on this fruitless discussion, but I can only suggest you to set out 
and try to design/implement a few non-trivial websites yourself, closely 
listening to user feedback. Maybe you'll come up with a revolutionary 
new solution for the problems that will inevitably pop up, but maybe 
you'll also discover that the designers of the most frequented sites 
aren't exactly complete dorks either.


David

Re: Is D still alive?

Although I don't find the original post to be a troll, (despite the 
title), I could not resist poking some fun...



 Still Alive? 

This was a triumph!
I'm making a note here: "HUGE SUCCESS!!"

It's hard to overstate, my satisfaction.

D programming Language:
We do what we must, because we can.

For the good of all of us.
Except the ones who are dead.

But there's no sense crying, over every mistake.
You just keep on trying, till you run out of code.
And the desiderata gets achieved.
And you make a neat module, for the people who are, still alive.

I'm not even angry...
I'm being so sincere right now-
Even though you broke my compiler, and killed me.
And tore the linker to pieces.
And threw every piece into a fire.
As they burned it hurt because, I was so happy for you!

Now, these points of data, make a beautiful line.
And we're out of beta. We're releasing on time!
So I'm GLaD I got burned-
Think of all the things we learned-
for the people who are, still alive.


Go ahead and leave me...
I think I'd prefer to stay inside...
Maybe you'll find someone else, to help you?
Maybe the Go Language?
THAT WAS A JOKE! HAHA - FAT CHANCE.

Anyway this code is great!
It's so delicious and moist!

Look at me: still talking, when there's science to do!
When I look out there, it makes me GLaD I'm not you.

I've experiments to run.
There is research to be done.
On the people who are, still alive.
And believe me I am, still alive.
I'm doing science and I'm, still alive.
I feel fantastic and I'm, still alive.
While you're dying I'll be, still alive.
And when you're dead I will be, still alive.

--
Bruno Medeiros - Software Engineer

Re: David Simcha's std.parallelism

On Fri, 2011-02-04 at 08:09 -0500, dsimcha wrote:
> I could move it over to github, though I'll wait to do that until I get 
> a little more comfortable with Git.  I had never used Git before until 
> Phobos switched to it.  In the mean time, to remind, the code is at:
> 
> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d

It seems that DSource Subversion service is even worse (much worse) than
that of GoogleCode.  I appear to be unable to checkout just the
parallelFuture directory with any of Git, Mercurial, Bazaar, or
Subversion (!).  It either gives a 500 Error or a OPTIONS failure :-
This does not bode well for extracting anything from that area of the
Subversion repository.  (Unless I am doing something wrong, which is
entirely possible.)

Given that I am not about to checkout everything in scrapple/browser
just to get one file, I'll wait till you feel able to switch to Git.
Don't think of this as an attempt to put pressure on you, it is really
just an excuse for me not to do something.

> The docs are at:
> 
> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html

Can this not go under version control as well?

Thanks.

PS  I strongly recommend you find ways of learning Git, although I
prefer Mercurial and Bazaar to Git, any of these three make developing a
pleasure compared to using Subversion.  Once you get into DVCS there is
no turning back from being far more productive.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: std.xml should just go

On 2/4/11, spir  wrote:
>
> About that, I would love a tutorial about eponymous templates starting with
> their /purpose/ (why does this feature even exist? what does it /mean/? what
> does it compare/oppose to? why is one supposed to need/enjoy it? how is it
> supposed to help & make code better mirror model?) Same for alias template
> params. Same for a rather long list of features, probably.
>

But both of these are already explained in the manual:
http://www.digitalmars.com/d/2.0/template.html (search for Implicit
Template Properties)
http://www.digitalmars.com/d/2.0/template.html (search for Template
Alias Parameters)

Granted, eponymous templates aren't explained in much detail on that page.
As for explaining how they work together, I did write that short
template tutorial
(http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but
you've already seen that. :)

However, I do not think we should write tutorials on single features
alone. I've read a bunch of books that explain the language in
feature-by-feature basis, but neglect to tie everything together. For
example, "Learning Python" is this 1200 page book about Python 3,
explaining the language feature by feature but never really discussing
the language as a whole. It's only good as a reference, which
ironically defeats the book's title. OTOH "Dive into Python 3"
gradually introduces you to more features of the language, but always
has code examples where you can see multiple features of the language
being used. (IIRC there were string processing examples which used
regex, multiple modules, and unittests all at once).

Having a perspective on how all features tie together is crucial to
understanding the purpose of individual features themselves. In my
opinion!

Re: std.xml should just go


spir wrote:

On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
Slices: just one more reason why D's arrays kick the pants of other 
languages'

arrays...


What are the other ones?


Scope guard is another.

I would argue that transitive const is, too, but the benefits of that are harder 
to see.

Re: std.xml should just go

> Scope guard is another.

Scope guard is awesome with C libs that have complicated
acquire/release rules. Saves my butt. :D

Re: std.xml should just go


BLS wrote:
I got more and more the feeling that the D2 monster was made just for 
ranges.


The only range support that is actually in the language is in foreach. That can 
be ignored if you prefer.


Unix's core structure is that everything is a file. Operations are strung 
together as operations on files, the output of each "filter" is fed as a file 
into the next one. The huge success is that so many operations are implementable 
as filters, and that filters can be plugged together in any order.


There have been many attempts to duplicate this success in programming 
languages, called "component" programming.


Lisp is, of course, a very early example. It accomplished this by "everything is 
a list", and so diverse operations on lists could all be componentized snapped 
together.


Microsoft COM is another example, built on top of OOP.

C++'s hat in that ring is iterators, and to some extent it was successful. I 
think C++ would be dead now if not for iterators.


I'm as convinced as I can be without a decade of experience behind it, that 
ranges are the new paradigm for component programming. The more Phobos APIs are 
reworked to use ranges, the more componentized things get. I don't think we've 
quite reached the tipping point yet, but we're close.


Although I said earlier that the only explicit range support in D2 is in 
foreach, a lot of the enhancements and adjustments to D2 were to better support 
ranges.

Re: new documentation format for std.algorithm

2011-02-04 Thread Jeff Nowakowski


On 02/04/2011 11:38 AM, David Nadlinger wrote:


I tried to explain the issue to you, but you have been quick to
dismiss any attempt to do so based on your own opinion.


You've made silly arguments about opinion yourself, stating that a
million Wikipedia users would complain if the default font setting was
used. That was what you came up instead of responding to a detailed
argument from me. Pure intellectual laziness.

You've completely ignored the problems of the variety of real-world
resolutions, monitor sizes, and preferred font sizes. You've ignored the
problems caused by designs that do not flow, especially as it relates to
zoom. You've ignored the fact that relative fonts and flow layout do not
have this problem.

You're advocating that people's explicit preferences should be ignored
in favor of designers who think the Web should act as a print medium.
You've ignored the fact that the Web was explicitly designed to not be
such a medium, and in practice cannot be due to the myriad of devices
connected to it.


maybe you'll also discover that the designers of the most frequented
sites aren't exactly complete dorks either.


I've seen tons of designs by high-profile sites, and many are 
pointlessly broken for me. I've seen them redesigned after having been 
in a workable state and then made broken by an obsession of pixel-based 
layout. The problem is these designers are control-freaks and don't 
understand the Web.

Re: David Simcha's std.parallelism

2011-02-04 Thread Ellery Newcomer


svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/

works for me

On 02/04/2011 11:28 AM, Russel Winder wrote:

On Fri, 2011-02-04 at 08:09 -0500, dsimcha wrote:

I could move it over to github, though I'll wait to do that until I get
a little more comfortable with Git.  I had never used Git before until
Phobos switched to it.  In the mean time, to remind, the code is at:

http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d


It seems that DSource Subversion service is even worse (much worse) than
that of GoogleCode.  I appear to be unable to checkout just the
parallelFuture directory with any of Git, Mercurial, Bazaar, or
Subversion (!).  It either gives a 500 Error or a OPTIONS failure :-
This does not bode well for extracting anything from that area of the
Subversion repository.  (Unless I am doing something wrong, which is
entirely possible.)

Re: David Simcha's std.parallelism

2011-02-04 Thread Gour

On Fri, 04 Feb 2011 17:28:25 +
Russel Winder  wrote:

> PS  I strongly recommend you find ways of learning Git, although I
> prefer Mercurial and Bazaar to Git, any of these three make
> developing a pleasure compared to using Subversion.  Once you get
> into DVCS there is no turning back from being far more productive.

For my own stuff I use and I'm very happy with Fossil SCM, but when I
have to do something with other projects, now I use Bazaar with its
set of plugins bzr-{git,hg,svn} (although 'hg' is not on par with the
rest), so everything can be done with bzr and 'explorer' plugin is
also nice.

Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA

signature.asc
Description: PGP signature

Re: David Simcha's std.parallelism

On Fri, 2011-02-04 at 12:12 -0600, Ellery Newcomer wrote:
> svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
> 
> works for me
[ . . . ]
> >> Phobos switched to it.  In the mean time, to remind, the code is at:
> >>
> >> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d

Hummm... spot the error.  It works for me now I know ;-)

I should have tried harder I guess.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: std.xml should just go

On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright  
 wrote:



spir wrote:

On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
Slices: just one more reason why D's arrays kick the pants of other  
languages'

arrays...

 What are the other ones?


Scope guard is another.

I would argue that transitive const is, too, but the benefits of that  
are harder to see.


There are many features small in detail but superb in practice.
But still, i keep saying D has design errors as well, to me the biggest  
one and maybe the main reason why D1 crowd is hostile to D2.


Const system (CS):

CS in theory a great thing, in practice it has many corner cases, simply  
it doesn't worth having.
D had(still has) a chance to fix this issue in two different ways, either  
avoid it or don't leave holes. This hole is not that explicit in C++  
because it is not transitive.

Transitive const brings something with it... transitivity!

Now, what i mean with this:

---
struct A {
B whatever;
bool opEquals(A a) {
		return whatever == a.whatever;  // just comparision, this function is  
const

}
bool anything(A a) {
whatever = 2; // here i have an assignment, this function is 
not const
return whatever;
}
}
---

It doesn't matter what signature you use for the function, compiler is  
aware and will output an error when you do the opposite of the signature.  
If this is the case, why do we need that signature?

Its presence just makes things complicated and with actually no reason.

---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever;
}
}

const(A) a;
A b;
bool e = a == b;


Thanks;

Re: Calling method by name.


On 02/04/2011 04:33 PM, Jacob Carlborg wrote:

On 2011-02-04 04:29, Robert Jacques wrote:

On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg  wrote:




Well, opDispatch does exactly that. __reflect, on the other hand, was
designed as a quasi-backend function primarily for a) internal use
(hence the double underscore), b) scripting language
interfacing/implementing and c) user-extension. So efficiency was of key
importance. And the reflection system is extensible, as Variant knows to
call __reflect on user defined types. This makes things like prototype
style objects possible. (There's even a beta implementation of a
prototype object in the library) But this requires that the use
__reflect methods not be templated.

I'm not well versed in dynamic reflection and its use cases, so when I
considered the combination of a runtime method name and compile-time
argument type information, I classed it as 'rare in practice'. But if
that's not the case, I'd like to know and would greatly appreciate a use
case/unit test.


I recommend looking at Ruby, it has very good support for runtime reflection.
ActiveRecord in Rails is hevaly based on runtime reflection. For example, given
the following Ruby class:

class Post < ActiveRecord::Base
end

The class "Post" maps to the database table "posts", no configuration is
necessary. Then you can use the column names in the table as fields to set and
get data, like this:

post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database

All this is done using runtime reflection. Then you can query the database,
also using runtime reflection:

Post.find_by_name_and_body("some title", "the body")

Will find the first row where "title" and "body" matches the given values.


FWIW, python example of "Calling method by name" (using no exotic feature):

class C:
def __init__(self, x):
self.x = x
def write (self, thing):
print "%s == %s ? %s" \
  %(self.x,thing, self.x==thing)

def runMethodWithArgs (object, name, *args):
method = getattr(object, name)
method(*args)

c= C(1.11)
runMethodWithArgs(c, "write", 2.22)
# --> 1.11 == 2.22 ? False

(Explanations if needed.)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: More on the necessity and difficulty of a package management system

On 26/01/2011 22:45, Andrei Alexandrescu wrote:

Seems to be unduly difficult in Python:

http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps

We need to have a good solution for D.

Andrei

I'm not really familiar with Python so I didn't understand all the
implications with the issues he encountered on that article. From what I
understand, Python on its own (the Python installation) does not allow
multiple versions of the same library to be installed on it, thus the
necessity of virtualenv. If that is the case, that seems a pretty bad
design to me, for the reasons he mentioned. virtualenv should be the
default way to do things. I mean, it's DLL Hell all over again, only in
a different platform (Python runtime instead of Windows). People keep
making the same mistakes...

As for the rest of the article, well, it's mostly about web application
deployment, which is a different concern (although related) to a package
and version management system. We don't even have anything to deploy to
in D, AFAIK.

In my view, these are the features/concerns that should be considered
for a package management system:

1: "package" version and dependency management (ie, verifying the
correct dependencies are present)
2: A well defined, structured, and hopefully platform independent, way
to compile source "packages", transforming them into binary "packages".
3: Adding, removing, or updating "packages" from some shared repository
online (either a central repository or not).
4: A way to publish new "packages" into shared repositories (either a
central repository or not).

5: Additional I would also like the possibility to add another layer of
visibility/encapsulation to "packages", that is, to specify which
modules/types/packages/etc should be visible to external "packages".
This idea is taken from OSGi, and it would subsume the need for this:

http://d.puremagic.com/issues/show_bug.cgi?id=2529
, and is generally a very nice mechanism to expose a clean API, that
may not be possible with D's protection modifiers (public, private,
etc.) alone, for large projects at least.

I think concerns 1, 2, 5 are the most important ones (4 not so much).
Concern 2 however, is likely also the hardest one to implement, by far.
(note the "structured" and "platform-independent" qualifiers... we
should strive to stay clear from make/automake crap and the likes as far
away as possible)

1 and 5 are particularly of interest to me, because it is the way I
would like to implement project dependencies in DDT, from the start,
instead of having something which is just IDE specific. Much better to
have a toolchain standard.

--
Bruno Medeiros - Software Engineer

Re: std.xml should just go


This hole is not that explicit in C++ because it is not transitive.


Ignore this line...

Btw, if i made myself clear to at least one person, please let me know  
since this is (at least to me) very important.

Re: std.xml should just go


so wrote:
It doesn't matter what signature you use for the function, compiler is 
aware and will output an error when you do the opposite of the 
signature. If this is the case, why do we need that signature?



Examine the API of a function in a library. It says it doesn't modify anything 
reachable through its arguments, but is that true? How would you know? And how 
would you know if the API doc doesn't say?


You'd fall back to const by convention, and that is not reliable and does not 
scale. You have to manually go through an entire hierarchy of function calls to 
figure out if one might change a member of the data structure, and then after a 
few maintenance cycles, you have to do that all over again.


Or not, and just hope for the best (which is what happens in practice).

The "why", then, is that guarantees are better than hope.

Re: std.xml should just go


Andrej Mitrovic wrote:

Having a perspective on how all features tie together is crucial to
understanding the purpose of individual features themselves. In my
opinion!


Of course, but both are necessary.

Re: std.xml should just go

2011-02-04 Thread Jesse Phillips

so Wrote:

> It doesn't matter what signature you use for the function, compiler is  
> aware and will output an error when you do the opposite of the signature.  
> If this is the case, why do we need that signature?
> Its presence just makes things complicated and with actually no reason.

Are you saying that having the compiler auto detect const functions is better? 
This has been discussed and not considered a 'hole.' By declaring the function 
const the compiler is able to inform you when you make a call which no longer 
makes this true. It does mean const will be used less then in C++, but if we 
just remove it that would still be the case.

Re: std.xml should just go

On 2/4/11, Walter Bright  wrote:
> Andrej Mitrovic wrote:
>> Having a perspective on how all features tie together is crucial to
>> understanding the purpose of individual features themselves. In my
>> opinion!
>
> Of course, but both are necessary.
>

Well, I'm saying that you've already done your part of the job in the
manual. Well at least most of it, there's a few sections missing but
this was reported in bugzilla.

Re: std.xml should just go


On Fri, 04 Feb 2011 13:49:42 -0500, so  wrote:



Now, what i mean with this:

---
struct A {
B whatever;
bool opEquals(A a) {
		return whatever == a.whatever;  // just comparision, this function is  
const

}
bool anything(A a) {
whatever = 2; // here i have an assignment, this function is 
not const
return whatever;
}
}
---

It doesn't matter what signature you use for the function, compiler is  
aware and will output an error when you do the opposite of the  
signature. If this is the case, why do we need that signature?

Its presence just makes things complicated and with actually no reason.


Actually, there are two reasons.

First, it's due to the compilation model of D.  Without the signature to  
convey the information, the compiler cannot make any guarantees.  It is  
legal to declare simply a function signature without the relevant source,  
in order to link against the function.  This means, the compiler does not  
have access to the source, so if it doesn't have access to the source, how  
does it know that the function is const or not?


Second, it has to do with the desires of the developer who's writing the  
function.


Let's say you have your code, and the opEquals is treated as const due to  
the implicit detection of the compiler.  Now, you realize your code that  
compares B types is really slow, so you want to do some sort of caching of  
the data:


struct A
{
   private B whatever; // changed to private for illustration purposes
   private md5 previousCompare;
   private bool previousCompareResult;

   bool opEquals(A a)
   {
  md5 ah = getMd5sum(a);
  if(ah != previousCompare)
  {
 previousCompare = ah;
 previousCompareResult = (whatever == a.whatever);
  }
  return previousCompareResult;
   }
...
}

So what does the compiler do?  Well, not only would this function now  
silently not be const, it silently un-consts all functions that call it.


The point is, many times, people want the compiler to tell them "hey, wait  
a minute, you marked this as const, but you're trying to do non-const  
things!"  As it turns out, it's really useful to know "this function is  
not going to change your object/struct."  logically, you can make a lot of  
assumptions based on that.  If the compiler doesn't help you enforce that,  
then stuff like the above creeps into the code, and your const expectation  
is broken.


What's somewhat unfortunate is that once you mark something as const, you  
have to mark all sorts of other things as const.  So for example, B's  
opEquals must also be const.  However, if you properly mark items as const  
when they really are const, this should already be the case.


The statement that "you don't need to use const if you don't want to" is  
really weak.  If you use D libraries, you will undoubtedly have to use  
const (once const is sane and libraries start using it).   But using it is  
not "pointless" and does add value.


-Steve

newcomer-friendly doc [was: Re: std.xml should just go]


On 02/04/2011 06:30 PM, Andrej Mitrovic wrote:

On 2/4/11, spir  wrote:


About that, I would love a tutorial about eponymous templates starting with
their /purpose/ (why does this feature even exist? what does it /mean/? what
does it compare/oppose to? why is one supposed to need/enjoy it? how is it
supposed to help&  make code better mirror model?) Same for alias template
params. Same for a rather long list of features, probably.



But both of these are already explained in the manual:
http://www.digitalmars.com/d/2.0/template.html (search for Implicit
Template Properties)
http://www.digitalmars.com/d/2.0/template.html (search for Template
Alias Parameters)


I've read this thrice ;-) Precisely, this doc is nice & rather good; but, for 
me, doesn't answer the /base/ question. You'll find there what you need if you 
already have an idea on what you're supposed to need it for. Reason why I chose 
these example, precisely... but there are tons of parts of D2 that would 
benefit of a good introduction, really starting from the base (and not 
implicitely assuming 10 years of C++ programming --esp. about vocabulary: 
people here don't seem to realise how much words they use everyday can be 
misleading coming from != background, or even not be used elsewhere in 
programming).



Granted, eponymous templates aren't explained in much detail on that page.
As for explaining how they work together, I did write that short
template tutorial
(http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but
you've already seen that. :)


Yop, thanks for that.


However, I do not think we should write tutorials on single features
alone. I've read a bunch of books that explain the language in
feature-by-feature basis, but neglect to tie everything together. For
example, "Learning Python" is this 1200 page book about Python 3,
explaining the language feature by feature but never really discussing
the language as a whole. It's only good as a reference, which
ironically defeats the book's title. OTOH "Dive into Python 3"
gradually introduces you to more features of the language, but always
has code examples where you can see multiple features of the language
being used. (IIRC there were string processing examples which used
regex, multiple modules, and unittests all at once).

Having a perspective on how all features tie together is crucial to
understanding the purpose of individual features themselves. In my
opinion!


I do agree. I also miss a great picture of D2, and even more of Phobos2 ('s 
future overall design). But aren't both necessary? If one doesn't get a given 
feature's purpose, how can it find its place meaningfully in the great picture?


Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go


On 02/04/2011 06:33 PM, Walter Bright wrote:

spir wrote:

On 02/04/2011 08:34 AM, Jonathan M Davis wrote:

Slices: just one more reason why D's arrays kick the pants of other languages'
arrays...


What are the other ones?


Scope guard is another.

I would argue that transitive const is, too, but the benefits of that are
harder to see.


Agreed.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go


On 02/04/2011 07:49 PM, so wrote:

On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright 
wrote:


spir wrote:

On 02/04/2011 08:34 AM, Jonathan M Davis wrote:

Slices: just one more reason why D's arrays kick the pants of other languages'
arrays...

What are the other ones?


Scope guard is another.

I would argue that transitive const is, too, but the benefits of that are
harder to see.


There are many features small in detail but superb in practice.
But still, i keep saying D has design errors as well, to me the biggest one and
maybe the main reason why D1 crowd is hostile to D2.

Const system (CS):

CS in theory a great thing, in practice it has many corner cases, simply it
doesn't worth having.
D had(still has) a chance to fix this issue in two different ways, either avoid
it or don't leave holes. This hole is not that explicit in C++ because it is
not transitive.
Transitive const brings something with it... transitivity!

Now, what i mean with this:

---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever; // just comparision, this function is const
}
bool anything(A a) {
whatever = 2; // here i have an assignment, this function is not const
return whatever;
}
}
---

It doesn't matter what signature you use for the function, compiler is aware
and will output an error when you do the opposite of the signature. If this is
the case, why do we need that signature?
Its presence just makes things complicated and with actually no reason.

---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever;
}
}

const(A) a;
A b;
bool e = a == b;


Thanks;


Runs with opEquals signature expected by the compiler:

struct A {
int whatever;
const bool opEquals(ref const(A) a) {
return whatever == a.whatever;
}
}
unittest {
const(A) a;
A b;
assert(a == b);
}

But what do you actually /mean/?

Denis
--
_
vita es estrany
spir.wikidot.com

Re: newcomer-friendly doc [was: Re: std.xml should just go]

spir:

> (and not implicitely assuming 10 years of C++ programming --esp. about 
> vocabulary:

I've seen too many times people in D newsgroups assume that most D programmers 
come from C++ and know C++ well enough. This is bad.

Bye,
bearophile

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

2011-02-04 Thread Michel Fortin

On 2011-02-04 11:12:12 -0500, Bruno Medeiros 
 said:



Can Git really have an usable but incomplete local clone?


Yes, it's called a shallow clone. See the --depth switch of git clone:



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: std.xml should just go


Actually, there are two reasons.

First, it's due to the compilation model of D.  Without the signature to  
convey the information, the compiler cannot make any guarantees.  It is  
legal to declare simply a function signature without the relevant  
source, in order to link against the function.  This means, the compiler  
does not have access to the source, so if it doesn't have access to the  
source, how does it know that the function is const or not?


You can solve this at linking, but i have no idea about linking process,  
it would probably add overhead (data).


Second, it has to do with the desires of the developer who's writing the  
function.


Let's say you have your code, and the opEquals is treated as const due  
to the implicit detection of the compiler.  Now, you realize your code  
that compares B types is really slow, so you want to do some sort of  
caching of the data:


struct A
{
private B whatever; // changed to private for illustration purposes
private md5 previousCompare;
private bool previousCompareResult;

bool opEquals(A a)
{
   md5 ah = getMd5sum(a);
   if(ah != previousCompare)
   {
  previousCompare = ah;
  previousCompareResult = (whatever == a.whatever);
   }
   return previousCompareResult;
}
...
}

So what does the compiler do?  Well, not only would this function now  
silently not be const, it silently un-consts all functions that call it.


You changed the function and the new function is not working, just what  
you expect.
It is not silently is it? Unlike you use "A a" instead of "const A a".  
this const alone would give you all the guaranties you need.


The point is, many times, people want the compiler to tell them "hey,  
wait a minute, you marked this as const, but you're trying to do  
non-const things!"  As it turns out, it's really useful to know "this  
function is not going to change your object/struct."  logically, you can  
make a lot of assumptions based on that.  If the compiler doesn't help  
you enforce that, then stuff like the above creeps into the code, and  
your const expectation is broken.


I understand the importance of the signatures, but i am trying to  
understand if this is also practical. What i am saying is, indeed there  
are many expectations but one thing (not necessarily the solution) is that  
unless you use "const A a" having const signatures/guaranties pointless,  
right?

Re: std.xml should just go


so wrote:
You changed the function and the new function is not working, just what 
you expect.
It is not silently is it? Unlike you use "A a" instead of "const A a". 
this const alone would give you all the guaranties you need.


What would you do in the case of pointers to functions, virtual functions, 
functions implemented with inline assembly, and functions for which the source 
is not available?

Re: std.xml should just go

Examine the API of a function in a library. It says it doesn't modify  
anything reachable through its arguments, but is that true? How would  
you know? And how would you know if the API doc doesn't say?


You are right, but try to look at this from another angle (probably i am  
not making any sense here). Should "D const" be perceived this way?

When i say "const A", it broadly means don't assign to this.

You'd fall back to const by convention, and that is not reliable and  
does not scale. You have to manually go through an entire hierarchy of  
function calls to figure out if one might change a member of the data  
structure, and then after a few maintenance cycles, you have to do that  
all over again.


I have no idea how to solve this for documentation and such but the second  
you compile the source, everything will be clear as day.

Re: std.xml should just go

2011-02-04 Thread Jeff Nowakowski


On 02/03/2011 10:07 PM, Walter Bright wrote:


The way to get a high performance string parser in D is to take
advantage of one of D's unique features - slices. Java, C++, C#, etc.,
all rely on copying strings. With D you can just use slices into the
original XML source text. If you're copying the text, you're doing it
wrong.


Java's substring() does not copy the text, at least in the official JDK 
implementation. Unfortunately, it doesn't specify this behavior as part 
of the String API.

Re: std.xml should just go


so wrote:
Examine the API of a function in a library. It says it doesn't modify 
anything reachable through its arguments, but is that true? How would 
you know? And how would you know if the API doc doesn't say?


You are right, but try to look at this from another angle (probably i am 
not making any sense here). Should "D const" be perceived this way?

When i say "const A", it broadly means don't assign to this.


That's "head const", which is what C++ has. The const system in C++ does not 
work. If you view const strictly as a storage class, that fails as soon as you 
introduce pointers.



You'd fall back to const by convention, and that is not reliable and 
does not scale. You have to manually go through an entire hierarchy of 
function calls to figure out if one might change a member of the data 
structure, and then after a few maintenance cycles, you have to do 
that all over again.


I have no idea how to solve this for documentation and such but the 
second you compile the source, everything will be clear as day.


As I wrote in another reply to you, there are many cases where the compiler 
cannot determine this.

Re: What Makes A Programming Language Good

Bruno Medeiros:

> That language ecosystems are what matter, not just the language itself.

This is true, but only once your language is already very good :-)

Bye,
bearophile

Re: std.xml should just go

What would you do in the case of pointers to functions, virtual  
functions, functions implemented with inline assembly, and functions for  
which the source is not available?


Just like we don't know if the derived class overrides a given function,  
we could do something similar i suppose?
Similar could be applied to functions without source, after all we don't  
know until linking that the provided function has the right signature. I  
am sorry if these doesn't make sense for a compiler writer, i have no idea  
about the process :)

Re: std.xml should just go


On Fri, 04 Feb 2011 15:26:07 -0500, so  wrote:


Actually, there are two reasons.

First, it's due to the compilation model of D.  Without the signature  
to convey the information, the compiler cannot make any guarantees.  It  
is legal to declare simply a function signature without the relevant  
source, in order to link against the function.  This means, the  
compiler does not have access to the source, so if it doesn't have  
access to the source, how does it know that the function is const or  
not?


You can solve this at linking, but i have no idea about linking process,  
it would probably add overhead (data).


Yes, but that requires a custom linker/object file format.  Java does  
this, and D could do it, but it requires a major investment of time/effort.


Second, it has to do with the desires of the developer who's writing  
the function.


Let's say you have your code, and the opEquals is treated as const due  
to the implicit detection of the compiler.  Now, you realize your code  
that compares B types is really slow, so you want to do some sort of  
caching of the data:


struct A
{
private B whatever; // changed to private for illustration purposes
private md5 previousCompare;
private bool previousCompareResult;

bool opEquals(A a)
{
   md5 ah = getMd5sum(a);
   if(ah != previousCompare)
   {
  previousCompare = ah;
  previousCompareResult = (whatever == a.whatever);
   }
   return previousCompareResult;
}
...
}

So what does the compiler do?  Well, not only would this function now  
silently not be const, it silently un-consts all functions that call it.


You changed the function and the new function is not working, just what  
you expect.
It is not silently is it? Unlike you use "A a" instead of "const A a".  
this const alone would give you all the guaranties you need.


It is silent.  This is a basic difference in philosophy.  What it boils  
down to is declaration vs. usage.


Let's say I *don't* use const A a anywhere, so my code just compiles, I  
then release my library, and your code breaks because you do use const A  
a.  You might just be screwed, because I say "I don't care, I never meant  
that function to be const".  Now, you are stuck on an older version of the  
library, or forced to make drastic changes to your code.


Conversely, if the compiler *requires* the const decoration in the  
signature, your code never compiles to begin with, you can either work  
around the limitation, file a bug, or use a different library.  But since  
the API isn't going to change, you can be sure future versions of my code  
will work.


I feel the second scenario is better for all -- declare what you intend  
for the API, then there are no surprises later.


-Steve

Re: A monitor for every object

Steven Schveighoffer:

> D's monitors are lazily created, so there should be no issue with resource  
> allocation.  If you don't ever lock an object instance, it's not going to  
> consume any resources.

One more thing.
I remember working with LDC some developers to speed up the stack (scope) 
allocation of class instances (in D1), and I remember one of the slows down 
comes from the need to call something that sets the monitor pointer. This call 
to the runtime was never inlined by ldc, so it was a significant cost compared 
to similar class instances stack allocated by the JavaVM through escape 
analysis. So moniror management has a cost in LDC and I presume in DMD too, 
unless some inlining here will be somehow forced.

Bye,
bearophile

Re: A monitor for every object

Steven Schveighoffer:

> Most of the time the extra word isn't noticed  
> because the memory size of a class is usually not exactly a power of 2.

I'd like to know in a normal object oriented program how much memory this 
design actually wastes.

Thank you to you and Kagamin for your answers,
bye,
bearophile

High performance XML parser

I am now intensely accumulating information on how to go about creating a 
high-performance parser as it quickly became clear that my old one won't 
deliver. And if anything is clear is that memory is the key.

One way is the slicing approach mentioned on this NG, notably used by RapidXML. 
I already contacted Marcin (the author) to ensure that using solutions inspired 
by his lib is OK with him; it is. But I don't think I'll go this way. One 
reason is, surprisingly, performance. RapidXML cannot start parsing until the 
entire document is loaded and ready as a random-access string. Then it's 
blazingly fast but the time for I/O has already elapsed. Besides, as Marcin 
himself said, we need a 100% W3C-compliant implementation and RapidXML isn't 
one.

I think a much more fertile approach is to operate on a forward range, perhaps 
assuming bufferized input. That way I can start parsing as soon as the first 
buffer gets filled. Not to mention that the end result will use much less 
memory. Plenty of the XML data stream is indents, spaces, and markup -- there's 
no reason to copy all this into memory.

To sum up, I belive memory and overlapping I/O latencies with parsing effort 
are pivotal.

Please comment on this.

-- 
Tomek

Re: std.xml should just go

On Fri, 04 Feb 2011 22:44:51 +0200, Walter Bright  
 wrote:



so wrote:
Examine the API of a function in a library. It says it doesn't modify  
anything reachable through its arguments, but is that true? How would  
you know? And how would you know if the API doc doesn't say?
 You are right, but try to look at this from another angle (probably i  
am not making any sense here). Should "D const" be perceived this way?

When i say "const A", it broadly means don't assign to this.


That's "head const", which is what C++ has. The const system in C++ does  
not work. If you view const strictly as a storage class, that fails as  
soon as you introduce pointers.


No no! I mean the way it works in D. I tried to say that: because of the  
semantic of C++ const, it maybe maybe a good idea to have signatures but  
with the semantics in D const it is not that needed.

Re: std.xml should just go

On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski   
wrote:



On 02/03/2011 10:07 PM, Walter Bright wrote:


The way to get a high performance string parser in D is to take
advantage of one of D's unique features - slices. Java, C++, C#, etc.,
all rely on copying strings. With D you can just use slices into the
original XML source text. If you're copying the text, you're doing it
wrong.


Java's substring() does not copy the text, at least in the official JDK  
implementation. Unfortunately, it doesn't specify this behavior as part  
of the String API.


Yes, but Java's strings are immutable.  Typically a buffered I/O stream  
has a mutable buffer used to read data.  This necessitates a copy.  At the  
very least, you need to continue allocating more memory to hold all the  
strings.


-Steve

Re: High performance XML parser


On Fri, 04 Feb 2011 16:02:39 -0500, Tomek Sowiński  wrote:

I am now intensely accumulating information on how to go about creating  
a high-performance parser as it quickly became clear that my old one  
won't deliver. And if anything is clear is that memory is the key.


One way is the slicing approach mentioned on this NG, notably used by  
RapidXML. I already contacted Marcin (the author) to ensure that using  
solutions inspired by his lib is OK with him; it is. But I don't think  
I'll go this way. One reason is, surprisingly, performance. RapidXML  
cannot start parsing until the entire document is loaded and ready as a  
random-access string. Then it's blazingly fast but the time for I/O has  
already elapsed. Besides, as Marcin himself said, we need a 100%  
W3C-compliant implementation and RapidXML isn't one.


I think a much more fertile approach is to operate on a forward range,  
perhaps assuming bufferized input. That way I can start parsing as soon  
as the first buffer gets filled. Not to mention that the end result will  
use much less memory. Plenty of the XML data stream is indents, spaces,  
and markup -- there's no reason to copy all this into memory.


To sum up, I belive memory and overlapping I/O latencies with parsing  
effort are pivotal.


Please comment on this.


Here is how I would approach it (without doing any research).

First, we need a buffered I/O system where you can easily access and  
manipulate the buffer.  I have proposed one a few months ago in this NG.


Second, I'd implement the XML lib as a range where "front()" gives you an  
XMLNode.  If the XMLNode is an element, it will have eager access to the  
element tag, and lazy access to the attributes and the sub-nodes.  Each  
XMLNode will provide a forward range for the child nodes.


Thus you can "skip" whole elements in the stream by popFront'ing a range,  
and dive deeper via accessing the nodes of the range.


I'm unsure how well this will work, or if you can accomplish all of it  
without reallocation (in particular, you may need to store the element  
information, maybe via a specialized member function?).


-Steve

Re: A better assert() [was: Re: std.unittests [updated] for review]

Jonathan M Davis:

> assert(0) has the advantage of being a normal assertion in non-release mode.

What is this useful for? To me this looks like a significant disadvantage. If I 
want a HALT (to tell the compiler a point can't be reached, etc) I want it in 
every kind of compilation of the program.


> It also makes it clear that that code path should _never_ be reached.

The replacement for assert(0) is meant to be more clear in its purpose compared 
to assert(0). It may be named thisCantHappen(), or assertZero(), etc.


> The real question though is whether you can convince Walter (which I doubt, 
> but I don't know).

This topic was already discussed, and I think the result of the discussion was 
that this change of assert(false) is not worth it. But if asserts gets inproved 
for other purposes, then this is a chance to work on improving assert(0) too.


> Still, making such a change _would_ contradict TDPL, which is supposed to be 
> a major no-no at this point.<

I like TDPL, I respect Andrei and you, I agree that TDPL is a kind of reference 
for D2, but please stop using TDPL as a The Bible in many of your posts. Not 
even Andrei himself looks so religiously attached as you to the contents of 
TDPL :-) A little flexibility is acceptable.

--

Adam Ruppe:

>Again, I think this makes sense too. assert(n) is saying, in principle, 
>"ensure n is valid". Calling the invariant is part of ensuring it is valid. 
>The only problem is a minor bug - it forgets to check for null before calling 
>the invariant. That should, of course, be fixed, but the main behavior makes 
>sense.<

Something like class_instance.invariant() is better because:
- It's explicit and readable. While you need to read the D manual to know that 
assert(class_instance) tests the invariant too, and not just that 
class_instance reference is not null. I remember other persons in D.learn not 
knowning/suprised by that assert(class_instance) tests the invariant too.
- It removes a special case, and special cases kill languages. Struct instances 
too allow an invariant, but they are not callable with assert(), see below. A 
syntax like structlass_instance.invariant() is shared with the class one.

struct Foo {
int x;
invariant() { assert(x == 1); }
}
void main() {
Foo f;
assert(f);
}


DMD 2.051:
test.d(7): Error: expression f of type Foo does not have a boolean value

Bye,
bearophile

Re: David Simcha's std.parallelism

dsimcha napisał:

> I could move it over to github, though I'll wait to do that until I get 
> a little more comfortable with Git.  I had never used Git before until 
> Phobos switched to it.  In the mean time, to remind, the code is at:
> 
> http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
> 
> The docs are at:
> 
> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html

Please run the docs through a spell-checker, there are a few typos:

asyncBuf() - for ecample
stop() - waitied
lazyMap() - Parameters;

But I think it's good overall. These primitives are in demand.

-- 
Tomek

Re: High performance XML parser

2011-02-04 Thread Michel Fortin


On 2011-02-04 16:02:39 -0500, Tomek Sowiński  said:

I am now intensely accumulating information on how to go about creating 
a high-performance parser as it quickly became clear that my old one 
won't deliver. And if anything is clear is that memory is the key.


One way is the slicing approach mentioned on this NG, notably used by 
RapidXML. I already contacted Marcin (the author) to ensure that using 
solutions inspired by his lib is OK with him; it is. But I don't think 
I'll go this way. One reason is, surprisingly, performance. RapidXML 
cannot start parsing until the entire document is loaded and ready as a 
random-access string. Then it's blazingly fast but the time for I/O has 
already elapsed. Besides, as Marcin himself said, we need a 100% 
W3C-compliant implementation and RapidXML isn't one.


I think a much more fertile approach is to operate on a forward range, 
perhaps assuming bufferized input. That way I can start parsing as soon 
as the first buffer gets filled. Not to mention that the end result 
will use much less memory. Plenty of the XML data stream is indents, 
spaces, and markup -- there's no reason to copy all this into memory.


To sum up, I belive memory and overlapping I/O latencies with parsing 
effort are pivotal.


I agree it's important, especially when receiving XML over the network, 
but I also think it's important to be able to be able to support 
slicing. Imagine all the memory you could save by just making slices of 
a memory-mapped file.


The difficulty is to support both models: the input range model which 
requires copying the strings and the slicing model where you're just 
taking slices of a string.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: newcomer-friendly doc [was: Re: std.xml should just go]

On 2/4/11, spir  wrote:
> but there are tons of parts of D2 that would
> benefit of a good introduction, really starting from the base (and not
> implicitely assuming 10 years of C++ programming --esp. about vocabulary:
> people here don't seem to realise how much words they use everyday can be
> misleading coming from != background, or even not be used elsewhere in
> programming).
>

So how would you go about doing this?

Re: High performance XML parser

Michel Fortin napisał:

> I agree it's important, especially when receiving XML over the network, 
> but I also think it's important to be able to be able to support 
> slicing. Imagine all the memory you could save by just making slices of 
> a memory-mapped file.
> 
> The difficulty is to support both models: the input range model which 
> requires copying the strings and the slicing model where you're just 
> taking slices of a string.

These are valid concerns. Yet, in overwhelming majority XML documents come from 
hard-drive and network -- these are the places we need to drill. I fear that 
trying to cover every remote use case will render the library incomprehensible.

-- 
Tomek

Re: High performance XML parser

2011-02-04 Thread Simen kjaeraas


Steven Schveighoffer  wrote:


Here is how I would approach it (without doing any research).

First, we need a buffered I/O system where you can easily access and  
manipulate the buffer.  I have proposed one a few months ago in this NG.


Second, I'd implement the XML lib as a range where "front()" gives you  
an XMLNode.  If the XMLNode is an element, it will have eager access to  
the element tag, and lazy access to the attributes and the sub-nodes.   
Each XMLNode will provide a forward range for the child nodes.


Thus you can "skip" whole elements in the stream by popFront'ing a  
range, and dive deeper via accessing the nodes of the range.


I'm unsure how well this will work, or if you can accomplish all of it  
without reallocation (in particular, you may need to store the element  
information, maybe via a specialized member function?).


Question:

For the lazily computed attributes and subnodes, will accessing one element
cause all elements to be computed? Same goes for getting the number of
elements.

Also, can this be efficiently combined with mmapping? What I sorta imagine
is a kind of lazy slice: It determines whether it ends within this page,  
and

if not, does not progress past that page until asked to do so.

--
Simen

Re: new documentation format for std.algorithm

2011-02-04 Thread Jérôme M. Berger

Jeff Nowakowski wrote:
> On 02/04/2011 11:38 AM, David Nadlinger wrote:
>> maybe you'll also discover that the designers of the most frequented
>> sites aren't exactly complete dorks either.
> 
> I've seen tons of designs by high-profile sites, and many are
> pointlessly broken for me. I've seen them redesigned after having been
> in a workable state and then made broken by an obsession of pixel-based
> layout. The problem is these designers are control-freaks and don't
> understand the Web.

Plus, very often there are two categories of “designers” working on
these sites. The first do not know anything about the web and create
a mockup of the site using Photoshop, then the others (who do know
at least some html+css, or at least Dreamweaver) are required by
their managers (who know even less than the first category) to match
the Photoshop design exactly on the manager's computer. The easiest
(or even only) way to do that is to set all dimensions in pixels.
And the result is something that ranges from bad to horrible for
most other people.

Jerome

PS: Yes, I know, this probably does not apply to wikipedia but I am
pretty sure it applies to most “professional” web sites.
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr

signature.asc
Description: OpenPGP digital signature

Re: David Simcha's std.parallelism

2011-02-04 Thread Jérôme M. Berger

Russel Winder wrote:
> On Fri, 2011-02-04 at 12:12 -0600, Ellery Newcomer wrote:
>> svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
>>
>> works for me
> [ . . . ]
 Phobos switched to it.  In the mean time, to remind, the code is at:

 http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
> 
> Hummm... spot the error.  It works for me now I know ;-)
> 
> I should have tried harder I guess.
> 
Not knowing what you did, my bet is that you used the web interface
URL instead of the real svn URL (i.e you forgot the “svn.” at the
beginning).

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



signature.asc
Description: OpenPGP digital signature

Re: A monitor for every object

2011-02-04 Thread Jérôme M. Berger

Steven Schveighoffer wrote:
> D's monitors are lazily created, so there should be no issue with
> resource allocation. 
What happens if two threads attempt to create a monitor for the
same object at the same time? Is there a global lock to avoid race
conditions in this case?

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



signature.asc
Description: OpenPGP digital signature

Re: High performance XML parser

Steven Schveighoffer napisał:

> Here is how I would approach it (without doing any research).
> 
> First, we need a buffered I/O system where you can easily access and  
> manipulate the buffer.  I have proposed one a few months ago in this NG.
> 
> Second, I'd implement the XML lib as a range where "front()" gives you an  
> XMLNode.  If the XMLNode is an element, it will have eager access to the  
> element tag, and lazy access to the attributes and the sub-nodes.  Each  
> XMLNode will provide a forward range for the child nodes.
> 
> Thus you can "skip" whole elements in the stream by popFront'ing a range,  
> and dive deeper via accessing the nodes of the range.
> 
> I'm unsure how well this will work, or if you can accomplish all of it  
> without reallocation (in particular, you may need to store the element  
> information, maybe via a specialized member function?).

Heh, yesterday when I couldn't sleep I was sketching the design. I converged to 
a pretty much same concept, so your comment is reassuring :).

The design I'm thinking is that the node iterator will own a buffer. One 
consequence is that the fields of the current node will point to the buffer 
akin to foreach(line; File.byLine), so in order to lift the input the user will 
have to dup (or process the node in-place). As new nodes will be overwritten on 
the same piece of memory, an important trait of the design emerges: cache 
intensity. Because of XML namespaces I think it is necessary for the buffer to 
contain the current node plus all its parents. Namespaces are the technical 
reason but having access to the path all the way to the root node is of value, 
regardless. This suggests mark-release memory management. The buffer will have 
to be long enough to fit the deepest tag sequence: theoretically infinite, not 
that much in practice. Like I said, the buffer will be owned by the iterator so 
probably deterministic deallocation is possible when the processing is done.

One drawback is that you won't know you're dealing with a well-formed DOM until 
the closing tag comes. If it doesn't, it'll of course throw, but the malformed 
DOM may already have been digested. So providing some rollback possibility is 
up to the user.

-- 
Tomek

Re: David Simcha's std.parallelism

2011-02-04 Thread dsimcha

== Quote from Tomek Sowiński (j...@ask.me)'s article
> Please run the docs through a spell-checker, there are a few typos:
> asyncBuf() - for ecample
> stop() - waitied
> lazyMap() - Parameters;
> But I think it's good overall. These primitives are in demand.
> --
> Tomek

I will certainly tie up all of these kinds of loose ends when all the bigger
picture stuff is taken care of and this thing is ready to be committed.  It's 
just
that I don't see the point in worrying about such minor details before the 
overall
content is finalized.

Re: High performance XML parser

2011-02-04 Thread Denis Koroskin


On Sat, 05 Feb 2011 00:02:39 +0300, Tomek Sowiński  wrote:

I am now intensely accumulating information on how to go about creating  
a high-performance parser as it quickly became clear that my old one  
won't deliver. And if anything is clear is that memory is the key.


One way is the slicing approach mentioned on this NG, notably used by  
RapidXML. I already contacted Marcin (the author) to ensure that using  
solutions inspired by his lib is OK with him; it is. But I don't think  
I'll go this way. One reason is, surprisingly, performance. RapidXML  
cannot start parsing until the entire document is loaded and ready as a  
random-access string. Then it's blazingly fast but the time for I/O has  
already elapsed. Besides, as Marcin himself said, we need a 100%  
W3C-compliant implementation and RapidXML isn't one.


I think a much more fertile approach is to operate on a forward range,  
perhaps assuming bufferized input. That way I can start parsing as soon  
as the first buffer gets filled. Not to mention that the end result will  
use much less memory. Plenty of the XML data stream is indents, spaces,  
and markup -- there's no reason to copy all this into memory.


To sum up, I belive memory and overlapping I/O latencies with parsing  
effort are pivotal.


Please comment on this.



I don't have much experience with XML, but as far as I can tell DOM parser  
pretty much needs to store entire file in memory. You can also load and  
parse files asynchronously.
By the contrary, SAX parsers don't require having entire file in memory,  
but that's completely different approach to XML parsing.



I'd also recommend you to take a look at pugixml, which is being developed  
and supported by my co-worker since 2006. It is free (MIT license), small,  
lightweight, fast, clean and has very good documentation.

Re: High performance XML parser

> Steven Schveighoffer napisał:
> 
> > Here is how I would approach it (without doing any research).
> > 
> > First, we need a buffered I/O system where you can easily access and  
> > manipulate the buffer.  I have proposed one a few months ago in this NG.
> > 
> > Second, I'd implement the XML lib as a range where "front()" gives you an  
> > XMLNode.  If the XMLNode is an element, it will have eager access to the  
> > element tag, and lazy access to the attributes and the sub-nodes.  Each  
> > XMLNode will provide a forward range for the child nodes.
> > 
> > Thus you can "skip" whole elements in the stream by popFront'ing a range,  
> > and dive deeper via accessing the nodes of the range.
> > 
> > I'm unsure how well this will work, or if you can accomplish all of it  
> > without reallocation (in particular, you may need to store the element  
> > information, maybe via a specialized member function?).
> 
> Heh, yesterday when I couldn't sleep I was sketching the design. I converged 
> to a pretty much same concept, so your comment is reassuring :).
> 
> The design I'm thinking is that the node iterator will own a buffer. One 
> consequence is that the fields of the current node will point to the buffer 
> akin to foreach(line; File.byLine), so in order to lift the input the user 
> will have to dup (or process the node in-place). As new nodes will be 
> overwritten on the same piece of memory, an important trait of the design 
> emerges: cache intensity. Because of XML namespaces I think it is necessary 
> for the buffer to contain the current node plus all its parents. Namespaces 
> are the technical reason but having access to the path all the way to the 
> root node is of value, regardless. This suggests mark-release memory 
> management. The buffer will have to be long enough to fit the deepest tag 
> sequence: theoretically infinite, not that much in practice. Like I said, the 
> buffer will be owned by the iterator so probably deterministic deallocation 
> is possible when the processing is done.
> 
> One drawback is that you won't know you're dealing with a well-formed DOM 
> until the closing tag comes. If it doesn't, it'll of course throw, but the 
> malformed DOM may already have been digested. So providing some rollback 
> possibility is up to the user.
 
Oh, and the direction of iteration (deeper/farther) will of course be 
controllable in fashion you presented.

-- 
Tomek

Re: David Simcha's std.parallelism

On Fri, 2011-02-04 at 23:06 +0100, "Jérôme M. Berger" wrote:
> Russel Winder wrote:
> > On Fri, 2011-02-04 at 12:12 -0600, Ellery Newcomer wrote:
> >> svn ls http://svn.dsource.org/projects/scrapple/trunk/parallelFuture/
> >>
> >> works for me
> > [ . . . ]
>  Phobos switched to it.  In the mean time, to remind, the code is at:
> 
>  http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/std_parallelism.d
> > 
> > Hummm... spot the error.  It works for me now I know ;-)
> > 
> > I should have tried harder I guess.
> > 
>   Not knowing what you did, my bet is that you used the web interface
> URL instead of the real svn URL (i.e you forgot the “svn.” at the
> beginning).

That is part of the error, the other part of it is `sed 's/\/browser//'`
put the two together and you transform failure into success :-)

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: A monitor for every object