date:20110203

Am 03.02.2011 22:00, schrieb Lars T. Kyllingstad:
 On Thu, 03 Feb 2011 17:16:58 +, Adam Ruppe wrote:
 
 Eric Poggel wrote:
 I hate to mention this in light of Adam's work, but Reddit is open
 source--why not run our own deployment of it for D?

 I *really* dislike tree style interfaces. I find them incredibly hard to
 navigate.

 Of course, I'm fairly unlikely to use the web interface much anyway
 (whether mine or someone else - I prefer my mail client most the time),
 but still, it would be nice if it didn't suck.

 Anyway, I did a little more work on my thing this morning:

 http://arsdnet.net/d-web-site/nntp/thread-index?newsgroup=digitalmars.D

 There's now [Tree] and [Linear] links on the right to view the whole
 thread at once.


 Any ideas on how to improve that? I copied a few basic elements of
 reddit style sites, but I'm thinking that view works best for very short
 messages.
 
 I agree.  Subject, author and date should be shown in a tree view, but 
 you should never display more than one message body at a time.  The 
 average message on this forum is far too long for that.
 
 -Lars

I find it annoying to open each message in a thread manually.
I prefer a fully expanded thread with all bodies (or maybe partially expended by
subthreads or something when it's too big). This makes reading longer threads
much easier.
I haven't found a non-web-based news/mail client that does this yet, but going
to the next message with 'n' in Thunderbird certainly is less painful than
clicking the next message I want to read on a website.

Cheers,
- Daniel

Re: Phobos 2.051 CHM Help File

2011-02-03 Thread Joel Christensen


On 03-Feb-11 5:00 PM, Vladimir Panteleev wrote:

On Wed, 02 Feb 2011 05:48:07 +0200, Joel Christensen joel...@gmail.com
wrote:


I just get Navigation to the webpage was canceled what ever I've
click on in the left window.


http://thecybershadow.net/d/docs/#troubleshooting



Thanks Vladimir, got it working. The first thing I tried didn't work, 
but your links instructions did. :-)

Re: Calling method by name.


On 2011-02-02 21:11, Robert Clipsham wrote:

On 02/02/11 20:00, Jacob Carlborg wrote:

On 2011-02-02 20:42, Robert Clipsham wrote:

On 02/02/11 17:55, %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


As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.


Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.


If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.


Same here, but you would probably need to inherit from a common base 
class or use a mixin.


--
/Jacob Carlborg

Re: Calling method by name.


On 2011-02-02 22:51, Stanislav Blinov wrote:

On 02/02/2011 11:11 PM, Robert Clipsham wrote:

On 02/02/11 20:00, Jacob Carlborg wrote:

On 2011-02-02 20:42, Robert Clipsham wrote:

On 02/02/11 17:55, %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


As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.


Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.


If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.



AFAIK, D2's TypeInfo and friends do have an interface for runtime
reflection (methods offTi() and getMembers()), though a quick glance
shows they're not implemented, i.e. return null all the time.


I think the const is incorrect as well on getMembers.

--
/Jacob Carlborg

Re: std.xml should just go


On 2011-02-03 00:33, Andrei Alexandrescu wrote:

For a while we've espoused the strategy of keeping std.xml in Phobos
until something better comes along.

But recently we've started to rethink that.

Pretty much everyone who tries std.xml ends up disappointed. Anyone who
wants to bash D has std.xml as an easy pick. Anyone who looks at speed
comparisons sees std.xml there like a sore thumb. Finally, the mere
existence of a package, no matter how inadequate, stifles the initiative
of others working on it.

This all makes std.xml a net liability. It's not better than nothing;
it's worse than nothing.

Should we nuke it?


Andrei


Yes, hasn't this been done already ?

--
/Jacob Carlborg

Re: std.xml should just go

On Thursday 03 February 2011 02:01:35 Jacob Carlborg wrote:
 On 2011-02-03 00:33, Andrei Alexandrescu wrote:
  For a while we've espoused the strategy of keeping std.xml in Phobos
  until something better comes along.
  
  But recently we've started to rethink that.
  
  Pretty much everyone who tries std.xml ends up disappointed. Anyone who
  wants to bash D has std.xml as an easy pick. Anyone who looks at speed
  comparisons sees std.xml there like a sore thumb. Finally, the mere
  existence of a package, no matter how inadequate, stifles the initiative
  of others working on it.
  
  This all makes std.xml a net liability. It's not better than nothing;
  it's worse than nothing.
  
  Should we nuke it?
  
  
  Andrei
 
 Yes, hasn't this been done already ?

I don't think that anything has been removed from Phobos yet which didn't have 
a 
replacement ready.

- Jonathan M Davis

Re: new documentation format for std.algorithm

2011-02-03 Thread bearophile

Andrei:

 Someone mentioned in this thread that leaving all font sizes to default 
 causes the text to be too small.
 
 The rhetoric is convincing but I'm afraid it can't be properly 
 translated into reality.

There's a step between fixed font sizes and no information about font sizes at 
all: relative sizes (-1, -2, etc).

Bye,
bearophile

Re: std.xml should just go


On 2011-02-03 00:38, Daniel Gibson wrote:

Am 03.02.2011 00:33, schrieb Andrei Alexandrescu:

For a while we've espoused the strategy of keeping std.xml in Phobos until
something better comes along.

But recently we've started to rethink that.

Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants to
bash D has std.xml as an easy pick. Anyone who looks at speed comparisons sees
std.xml there like a sore thumb. Finally, the mere existence of a package, no
matter how inadequate, stifles the initiative of others working on it.

This all makes std.xml a net liability. It's not better than nothing; it's worse
than nothing.

Should we nuke it?


Andrei


You could explicitly deprecate it.

Or just nuke it, if someone still wants to use it (or is already using it) he
can copy the source-file to his project.

Cheers,
- Daniel


I've already done that for the Orange project.

--
/Jacob Carlborg

Re: Should we have an Unimplemented Attribute?


On 2011-02-03 00:38, Piotr Szturmaj wrote:

Andrej Mitrovic wrote:

We know what a Deprecated Attribute is for:
http://www.digitalmars.com/d/2.0/attribute.html#deprecated.

You can use a compiler switch to enable using these:
-d
allow deprecated features

But what about structs/classes/functions/etc which are partially
implemented, but still unusable? Marking them with deprecated doesn't
make sense, as this will likely confuse both the user and the library
writers. Would it be overkill to introduce a new attribute?

The idea came after I've spent some good time trying to get druntime's
getMembers function to work in my code, only to find out from this NG
that it's not properly implemented.

Discuss?


In C# there is NotImplementedException for that.

public class A
{
public int foo()
{
throw new NotImplementedException();
}
}

I see people ask for new attributes. Why not add user defined attributes
into language? C# has custom attributes and Java has custom annotations.

Custom attributes could be just classes (as in C#):

class GuidAttribute : Attribute
{
string guid;

this(string guid)
{
this.guid = guid;
}
}

used like this (COM interfaces):

@Guid(48eecd81-35d7-4d4e-9ab8-479a38713053)
interface MyInterface
{
byte foo();
ulong bar();
}

or used for ORM:

@DBTable(users)
struct UserRow
{
@NotNull string username;
@NotNull string password
ubyte age;
}

There would be also need for some method to enumerate those attributes
at compile time/run time. We already have that possibility for
predefined attributes.


I would love to have user defined attributes/annotations.

--
/Jacob Carlborg

Re: std.xml should just go


On 2011-02-03 01:47, Bernard Helyer wrote:

On Wed, 02 Feb 2011 16:28:27 -0800, Brad Roberts wrote:


I haven't used it nor am likely to,
but I also have trouble ruling out the potential that there's users for
which it works and they just aren't talking about it here.


I do not believe that it's possible that anyone has used std.xml
successfully for something substantial. :D


I've used std.xml in the Orange project (serialization library) with 
some modifications. Don't know if that would be counted as something 
substantial.


--
/Jacob Carlborg

Re: Should we have an Unimplemented Attribute?

On Thursday 03 February 2011 03:02:04 Jacob Carlborg wrote:
 On 2011-02-03 00:38, Piotr Szturmaj wrote:
  Andrej Mitrovic wrote:
  We know what a Deprecated Attribute is for:
  http://www.digitalmars.com/d/2.0/attribute.html#deprecated.
  
  You can use a compiler switch to enable using these:
  -d
  allow deprecated features
  
  But what about structs/classes/functions/etc which are partially
  implemented, but still unusable? Marking them with deprecated doesn't
  make sense, as this will likely confuse both the user and the library
  writers. Would it be overkill to introduce a new attribute?
  
  The idea came after I've spent some good time trying to get druntime's
  getMembers function to work in my code, only to find out from this NG
  that it's not properly implemented.
  
  Discuss?
  
  In C# there is NotImplementedException for that.
  
  public class A
  {
  public int foo()
  {
  throw new NotImplementedException();
  }
  }
  
  I see people ask for new attributes. Why not add user defined attributes
  into language? C# has custom attributes and Java has custom annotations.
  
  Custom attributes could be just classes (as in C#):
  
  class GuidAttribute : Attribute
  {
  string guid;
  
  this(string guid)
  {
  this.guid = guid;
  }
  }
  
  used like this (COM interfaces):
  
  @Guid(48eecd81-35d7-4d4e-9ab8-479a38713053)
  interface MyInterface
  {
  byte foo();
  ulong bar();
  }
  
  or used for ORM:
  
  @DBTable(users)
  struct UserRow
  {
  @NotNull string username;
  @NotNull string password
  ubyte age;
  }
  
  There would be also need for some method to enumerate those attributes
  at compile time/run time. We already have that possibility for
  predefined attributes.
 
 I would love to have user defined attributes/annotations.

I agree with that whole-heartedly. They really should be added at some point, 
though since they should be backwards compatible, there's not necessarily any 
rush given everything else that needs to be done. Still, I don't think that we 
need an attribute for this particular case.

- Jonathan M Davis

Re: D vs Go on reddit

2011-02-03 Thread Paulo Pinto

I had the oportunity to watch a presentation from Nikolaus Wirth, back in
2003, when I was at CERN.

One of the reasons that prevented Oberon to get better audience was the
tunnel
vision of its ETHZ creators.

I remember that they were talking about it as it is the best language in the
world, and
everyone else is a sad fool not to understand it, but will eventually
discover the real language.

Having said this, I find the language quite nice and it is a good live
example how to create a simple
systems programming language with GC, which allows the creation of a real
operating system.

Funny enough, the way Go binds methods to interfaces is similar to Component
Pascal, an Oberon's
sucessor.

--
Paulo

spir denis.s...@gmail.com wrote in message
news:mailman.1205.1296696481.4748.digitalmar...@puremagic.com...
On 02/03/2011 12:31 AM, bearophile wrote:
Walter:

http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0

I have one comment about one thing said by bnolsen:

Simplicity + Orthogonality == win.

I would like people who state such phrases to all spend 3 months (only)
programming exclusively in Oberon. From some point of view, it may
probably be considered the best language ever. Twice as expressive as
Modula with half of its features. It brings one the full power of
imperative, structured, object-oriented paradigms in a language
/completely/ described in 13 (!) pages of plain text.
It is a wonderful incarnation of the core any modern language should
possess, and how to do it properly. Language designers of the mainstream
paradigm could just start with Oberon as a clean, pure, safe, pedestal and
just build on it.
For a full set of reasons, probably, Oberon has not had any success. Among
them (?) the obsession of those guys at ETH Zürich at /not/ considering
practicality as beeing of any worth, I guess ;-) This transforms
programming in Oberon --a potentially enthusiasmic experience at first
sight-- into a battle of every instant against irritating corners,
annoying lacks, and against oneself to not explode one's screen out of
frustration.

What I want most is the language features to be implemented in a clean
way, with a clear semantics, with very few bad interactions with other
language features and very few pitfalls, and with a good clean syntax. If
this is done well enough, then I am able to learn and use hundreds of
features too (and lots of keywords).

Oberon is all what you ask for in the first sentence. On the other hand,
just /listing/ features D provides and Oberon does not would require
pages. Actually, its feature set is radically minuscule (and even more
when compared to its expressive power, I guess); this does not ensure
cleanness, consistency and orthogonality, indeed; but it may be impossible
to achieve those qualities as soon as features grow in number and,
primarily, in diversity. I guess, in fact, it is extremely difficult even
for super simple toy languages. Successes (from this point of view) like
Oberon are rarissim as far as I know. (*)

Denis

(*) Even Pascal Modula did not reach this point; precisely, Oberon
abandoned some of their features like enums and subrange types.
--
_
vita es estrany
spir.wikidot.com

Re: new documentation format for std.algorithm


On 02/03/2011 06:19 AM, Walter Bright wrote:

Jérôme M. Berger wrote:

Andrei Alexandrescu wrote:

I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


Professionally designed does not mean that they did the job right!


Apple's SDK documentation on their web site is literally painful for me to
read. The light grey on white coupled with small font is awful. For a company
focussed on design, I don't understand this.


You can probably fix that by setting personal bg/fg colors in your browser, and 
stating they should override the original page's colors.
Using firefox (probably others have similar feature) one can even write a whole 
CSS style sheet for web page rendering. (*)
I nearly never navigate letting page original colors, because of white 
backgrounds. Sometimes it's necessary when part of the text is actually kinds 
of B-on-W images (like math formulas on wikipedia).


Denis

(*) I use it mainly because Mozilla apps (firefox  thunderbird in my case) do 
not correctly follow system style settings; which I desperately need to change 
mainly to avoid white backgrounds everywhere, but this change implies changing 
/all/ other colors.

--
_
vita es estrany
spir.wikidot.com

Re: Uniform call syntax for implicit this.


On 02/03/2011 05:48 AM, %u wrote:

When implemented, will uniform call syntax work for the this
object even if not specified?

For example, will foo() get called in the following example?

void foo(A a, int b) {}

class A {
 void test() {
 this.foo(10);
 foo(10);
 }
}


Thanks


Do you mean in the last line? I hope not! Adding implicit reformulation on 
implicit reformulation does not help  making code readable.

foo(10) -- this.foo(10) -- foo(this, 10)
Anyway, a sensible limit can be placed in that foo is not a function member of 
A, (hopefully) preventing the first rewriting step to occur.


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

Re: new documentation format for std.algorithm

On Wed, 02 Feb 2011 03:45:59 -0500, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:



Following ideas and advice from this newsgroup, I have a draft at

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html

There are two tables, one with just the names and the other with names  
and a brief description. Let me know of any feedback. Thanks!


This looks *much* better.

One curiosity, on Opera, the Cheat Sheet title is separated from the  
actual table by a full page of white space.  Not sure why.  Firefox looks  
fine.


-Steve

Re: Calling method by name.

2011-02-03 Thread Stanislav Blinov


03.02.2011 12:54, Jacob Carlborg пишет:

On 2011-02-02 22:51, Stanislav Blinov wrote:


AFAIK, D2's TypeInfo and friends do have an interface for runtime
reflection (methods offTi() and getMembers()), though a quick glance
shows they're not implemented, i.e. return null all the time.


I think the const is incorrect as well on getMembers.

Actually, it's that those TypeInfo, MemberInfo et al. are not 
const-correct, as is the case for Object and other Object-related classes.

Re: Calling method by name.


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

On Wed, 02 Feb 2011 12:55:37 -0500, %u f...@jhgjhb.com 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?


--
/Jacob Carlborg

How to build the druntime (Windows)?

2011-02-03 Thread Andre Tampubolon


This is my situation: I put all the git stuffs in C:\dmd-dev.
There are 2 subdirectories in it: dmd and druntime

I managed to build dmd by make -f win32.mak

Trying the same thing for druntime:
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\atomic.di src\core\atomic.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\bitop.di src\core\bitop.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\cpuid.di src\core\cpuid.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\demangle.di src\core\demangle.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\dll_helper.di 
src\core\dll_helper.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\exception.di 
src\core\exception.d

dmd -c -d -o- -Isrc -Iimport -Hfimport\core\memory.di src\core\memory.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\runtime.di src\core\runtime.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\thread.di src\core\thread.d
src\core\thread.d(1601): Error: undefined identifier malloc

--- errorlevel 1

Any idea?

--
- Andre Tampubolon -

Re: new documentation format for std.algorithm


On 2011-02-03 07:21, Andrei Alexandrescu wrote:

On 2/2/11 11:06 PM, Jeff Nowakowski wrote:

On 02/02/2011 10:59 AM, Andrei Alexandrescu wrote:


(Absolute) font size does not belong to the page designer, instead to
the user. Just press dedicated key binding (often ctrl-), or whatever
command to set it appropriately.


I'm not sure about that. Facebook's site is professionally designed and
I think they use fixed font sizes all over the place.


There are tons of professionally designed big name sites all over the
web that use fixed-font sizes that either look terribly small or
terribly large, comparatively. Don't you experience this yourself?

The whole idea is just wrong. People browse the web in all kinds of
default font sizes, screen resolutions, and preferred browser width.
Your web page should flow naturally to whatever the user has.


Someone mentioned in this thread that leaving all font sizes to default
causes the text to be too small.


Is there a minimum font size to set?


The rhetoric is convincing but I'm afraid it can't be properly
translated into reality.


Andrei



--
/Jacob Carlborg

Re: Uniform call syntax for implicit this.


On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:


When implemented, will uniform call syntax work for the this
object even if not specified?

For example, will foo() get called in the following example?

void foo(A a, int b) {}

class A {
void test() {
this.foo(10);
foo(10);
}
}


I think it should work.


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

Re: new documentation format for std.algorithm


On 02/03/2011 12:26 AM, David Nadlinger wrote:


Yet I'd guess that 99% of all people on the web have never touched their
browsers default font size/style controls…


Then let them get the defaults. Do you think designers know better? They 
can't, because every screen and browser window comes in arbitrary 
resolutions and sizes.


What the designers do is pick something that looks good for them, and if 
they're /really/ professional, they'll assume some standard screen 
real-estate is available and design the page as if the user was browsing 
at that.


More likely they'll just try to please the managers.

Re: new documentation format for std.algorithm


On 02/03/2011 01:21 AM, Andrei Alexandrescu wrote:


Someone mentioned in this thread that leaving all font sizes to default
causes the text to be too small.

The rhetoric is convincing but I'm afraid it can't be properly
translated into reality.


It doesn't matter *what* you choose, somebody will complain it is too 
small or too large. That doesn't mean that some choices aren't better 
than others. Going by default size and making the fonts relative to that 
is the way to go, assuming smaller sizes are justified to squeeze in 
text to cramped spaces.


Large blocks of text descriptions should be at the default size. Then if 
somebody complains about that, tell them to fix their defaults instead 
of imposing their monitor and browser settings on the rest of the Internet.

Re: new documentation format for std.algorithm


On 2/3/11 4:24 AM, bearophile wrote:

Andrei:


Someone mentioned in this thread that leaving all font sizes to default
causes the text to be too small.

The rhetoric is convincing but I'm afraid it can't be properly
translated into reality.


There's a step between fixed font sizes and no information about font sizes at 
all: relative sizes (-1, -2, etc).

Bye,
bearophile


That is used but I don't think it helps choosing something that works 
well for everyone.


Andrei

Re: new documentation format for std.algorithm


On 2/3/11 9:11 AM, Jeff Nowakowski wrote:

On 02/03/2011 01:21 AM, Andrei Alexandrescu wrote:


Someone mentioned in this thread that leaving all font sizes to default
causes the text to be too small.

The rhetoric is convincing but I'm afraid it can't be properly
translated into reality.


It doesn't matter *what* you choose, somebody will complain it is too
small or too large. That doesn't mean that some choices aren't better
than others. Going by default size and making the fonts relative to that
is the way to go, assuming smaller sizes are justified to squeeze in
text to cramped spaces.

Large blocks of text descriptions should be at the default size. Then if
somebody complains about that, tell them to fix their defaults instead
of imposing their monitor and browser settings on the rest of the Internet.


Apparently at least for one person choosing the default makes the text 
too large. Making the default smaller in turn makes Wikipedia text too 
small.


I wouldn't want to require a change of defaults to see our website or to 
compete with Wikipedia :o).



Andrei

Re: How to build the druntime (Windows)?

2011-02-03 Thread Don


Andre Tampubolon wrote:

This is my situation: I put all the git stuffs in C:\dmd-dev.
There are 2 subdirectories in it: dmd and druntime

I managed to build dmd by make -f win32.mak

Trying the same thing for druntime:
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\atomic.di src\core\atomic.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\bitop.di src\core\bitop.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\cpuid.di src\core\cpuid.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\demangle.di src\core\demangle.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\dll_helper.di 
src\core\dll_helper.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\exception.di 
src\core\exception.d

dmd -c -d -o- -Isrc -Iimport -Hfimport\core\memory.di src\core\memory.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\runtime.di src\core\runtime.d
dmd -c -d -o- -Isrc -Iimport -Hfimport\core\thread.di src\core\thread.d
src\core\thread.d(1601): Error: undefined identifier malloc

--- errorlevel 1

Any idea?



You're not doing anything wrong.

It fails on the autotester as well:
http://d.puremagic.com/test-results/index.ghtml

This commit broke it:
https://github.com/D-Programming-Language/druntime/commit/1449d7bd75c656cb0215d73077549c896c10163f

Re: new documentation format for std.algorithm


On 2/3/11 4:06 PM, Jeff Nowakowski wrote:

What the designers do is pick something that looks good for them, and if
they're /really/ professional, they'll assume some standard screen
real-estate is available and design the page as if the user was browsing
at that.

More likely they'll just try to please the managers.


Sorry, I don't quite get your point there. Of course there is the 
standard 960px desktop viewport to target, and typical mobile device 
dimensions are getting more and more important as well. It's part of 
delivering a good job to make sure that your work looks splendid at the 
few »standard« configurations, and not too bad on the rest. Where is the 
contradiction? And what does »pleasing the managers« have to do with that?


I just wanted to point out that using relative font sizes has hardly any 
intrinsic advantages to just specifying sizes in pixels (zoom controls 
work for both). You just have to specify *everything* using one method, 
if you want to have a consistent, layout glitch-free experience for your 
users – and in the end, pixels often make your life easier because you 
tend to be dealing with stuff for which pixels are the native unit of 
measurement. [1]


David



[1] By the way, the situation is getting considerably better with the 
advance of CSS3 and web fonts, since you'll be able to go without pixel 
graphics for design elements a lot more.

Re: new documentation format for std.algorithm


On 02/03/2011 11:09 AM, Andrei Alexandrescu wrote:


Apparently at least for one person choosing the default makes the text
too large. Making the default smaller in turn makes Wikipedia text too
small.

I wouldn't want to require a change of defaults to see our website or to
compete with Wikipedia :o).


Can't you see the ridiculous of this argument? You are talking about the 
problems of one person, and then comparing it to one site. I feel like 
you completely ignored what I said.


So go ahead and change it to fixed. I'll now complain it doesn't work 
for me. Will you then change it back?

Re: Should we have an Unimplemented Attribute?

2011-02-03 Thread Gerrit Wichert

Am 02.02.2011 23:59, schrieb Andrej Mitrovic:
 But what about structs/classes/functions/etc which are partially
 implemented, but still unusable? Marking them with deprecated doesn't
 make sense, as this will likely confuse both the user and the library
 writers. Would it be overkill to introduce a new attribute?
   
What about version( comming_soon)   ?  :-)

Re: new documentation format for std.algorithm


On 02/03/2011 11:54 AM, David Nadlinger wrote:


Sorry, I don't quite get your point there. Of course there is the
standard 960px desktop viewport to target, and typical mobile device
dimensions are getting more and more important as well. It's part of
delivering a good job to make sure that your work looks splendid at the
few »standard« configurations, and not too bad on the rest. Where is the
contradiction? And what does »pleasing the managers« have to do with that?


What 960 pixel standard? Who the hell decided that? Who even knows how 
large a pixel is on my monitor, or my preferred browser width, or what 
font settings I might be using either due to preference or poor eyesight?


Laptop screens, desktop monitors, and mobile devices come in a dizzying 
array of sizes and resolutions.


The standard used to be 800x600 back in the 90s. The idea was idiotic 
then, and it's idiotic now. There are no standard display sizes on the 
web. The whole idea is trying to force-fit a print design mindset onto a 
medium that was explicitly designed to not have one.



I just wanted to point out that using relative font sizes has hardly any
intrinsic advantages to just specifying sizes in pixels (zoom controls
work for both).


Using pixels means it's much more likely that somebody is going to have 
to manually adjust the zoom. Also, fixing the amount of content you're 
going to display based on pixels, instead of properly flowing, is broken 
when the client's resolution doesn't match your chosen standard. They 
will either get too much content or not enough, and zooming won't help.

Re: std.xml should just go

2011-02-03 Thread Masahiro Nakagawa

On Thu, 03 Feb 2011 08:33:42 +0900, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:


For a while we've espoused the strategy of keeping std.xml in Phobos  
until something better comes along.


But recently we've started to rethink that.

Pretty much everyone who tries std.xml ends up disappointed. Anyone who  
wants to bash D has std.xml as an easy pick. Anyone who looks at speed  
comparisons sees std.xml there like a sore thumb. Finally, the mere  
existence of a package, no matter how inadequate, stifles the initiative  
of others working on it.


This all makes std.xml a net liability. It's not better than nothing;  
it's worse than nothing.


Should we nuke it?


Good!


Masahiro

Re: Uniform call syntax for implicit this.

2011-02-03 Thread bearophile

%u:

 When implemented, will uniform call syntax work for the this
 object even if not specified?

My impression of this situation is that uniform call syntax is a little syntax 
improvement that may cause big troubles.

Bye,
bearophile

Re: new documentation format for std.algorithm

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

Andrei Alexandrescu wrote:
 On 2/3/11 9:11 AM, Jeff Nowakowski wrote:
 On 02/03/2011 01:21 AM, Andrei Alexandrescu wrote:

 Someone mentioned in this thread that leaving all font sizes to default
 causes the text to be too small.

 The rhetoric is convincing but I'm afraid it can't be properly
 translated into reality.

 It doesn't matter *what* you choose, somebody will complain it is too
 small or too large. That doesn't mean that some choices aren't better
 than others. Going by default size and making the fonts relative to that
 is the way to go, assuming smaller sizes are justified to squeeze in
 text to cramped spaces.

 Large blocks of text descriptions should be at the default size. Then if
 somebody complains about that, tell them to fix their defaults instead
 of imposing their monitor and browser settings on the rest of the
 Internet.
 
 Apparently at least for one person choosing the default makes the text
 too large. Making the default smaller in turn makes Wikipedia text too
 small.
 
That is because Wikipedia text *is* to small! Wikipedia has the
font size set to 80% of the default, which means that they *want*
their text to be too small. That is not a reason why we should
emulate them.

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



signature.asc
Description: OpenPGP digital signature

Re: Uniform call syntax for implicit this.

Am 03.02.2011 15:57, schrieb Michel Fortin:
 On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:
 
 When implemented, will uniform call syntax work for the this
 object even if not specified?

 For example, will foo() get called in the following example?

 void foo(A a, int b) {}

 class A {
 void test() {
 this.foo(10);
 foo(10);
 }
 }
 
 I think it should work.
 
 

I think foo(10) should *not* be equivalent to foo(this, 10).

Re: D vs Go on reddit

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

bearophile wrote:
 Walter:
 
 http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0
 
 I have one comment about one thing said by bnolsen:
 
 Simplicity + Orthogonality == win.
 
Then why has not Lisp won over all competition years ago?

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



signature.asc
Description: OpenPGP digital signature

Re: Uniform call syntax for implicit this.


On 2011-02-03 12:43:12 -0500, Daniel Gibson metalcae...@gmail.com said:


Am 03.02.2011 15:57, schrieb Michel Fortin:

On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:


When implemented, will uniform call syntax work for the this
object even if not specified?

For example, will foo() get called in the following example?

void foo(A a, int b) {}

class A {
void test() {
this.foo(10);
foo(10);
}
}


I think it should work.


I think foo(10) should *not* be equivalent to foo(this, 10).


Personally, I'm not sure whether the uniform call syntax will be this 
much useful or not, but if it gets implemented I think foo(10) should 
be equivalent to foo(this, 10) in the case above. That said, it should 
not be ambiguous: if there is a member function foo and a global 
function foo and both matches the call, it's ambiguous and it should be 
an error.


Can this work in practice? We probably won't know until we have an 
implementation to play with.


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

Re: D vs Go on reddit

2011-02-03 Thread Ulrik Mikaelsson

2011/2/3 Jérôme M. Berger jeber...@free.fr:
        Then why has not Lisp won over all competition years ago?

                Jerome
You mean why(not(has(won(lisp,all(competition)),years_ago))) ?

Jokes aside, I think people in language-debates often forget that
high-level languages are really just layers of syntactical sugar over
machine-code. ASM is syntactical sugar over machince-code, C is
syntactical sugar over ASM, and D is mostly syntactic sugar over C.
They are merely ways to streamline certain programming-models, into a
language that encourages those idioms and constructs. Just about
anything that can be written in D, can be written with equivalent
semantics in C, but the D-version is likely to be faster to write, and
faster to comprehend.

The purpose of higher-level languages is to encourage good
programming style and readability. Period. The syntax is crucial here,
it determines which constructs will become readable, and which won't,
which in turn determines the mind-set of the programmer. Which is why
I consider syntactic sugar to be seriously under-appreciated and
undervalued in many language decisions.

Re: new documentation format for std.algorithm


On 02/03/2011 05:05 PM, Andrei Alexandrescu wrote:

There's a step between fixed font sizes and no information about font sizes
at all: relative sizes (-1, -2, etc).

Bye,
bearophile


That is used but I don't think it helps choosing something that works well for
everyone.


This cannot be done. Just design with 'content flow' and 'relative sizes' in 
mind. Then everything should look correct on the user-side; except for wished 
absolute content size (which depends on a set of uncontrollable factors from 
resolution to eye-sight), which the user can freely set via a variety of UI 
commands.


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

Re: new documentation format for std.algorithm


On 02/03/2011 04:11 PM, Jeff Nowakowski wrote:

On 02/03/2011 01:21 AM, Andrei Alexandrescu wrote:


Someone mentioned in this thread that leaving all font sizes to default
causes the text to be too small.

The rhetoric is convincing but I'm afraid it can't be properly
translated into reality.


It doesn't matter *what* you choose, somebody will complain it is too small or
too large. That doesn't mean that some choices aren't better than others. Going
by default size and making the fonts relative to that is the way to go,
assuming smaller sizes are justified to squeeze in text to cramped spaces.

Large blocks of text descriptions should be at the default size. Then if
somebody complains about that, tell them to fix their defaults instead of
imposing their monitor and browser settings on the rest of the Internet.


+++ (that's how I understand the issue as well, virulence apart)

A particular point is when you need a rather wide horizontal space, like in the 
initial design of the cheat sheet. This is to be avoided as much as possible 
because layout will be broken by people using narrow/low resolution devices or 
needing larger fonts than you have in mind or just test with.
In all cases, I guess the proper method is to avoid setting absolute widths (or 
implicitely requiring big ones via layout design such in the case of the cheat 
sheet) and just let content flow, according to user-side /actual/ width.


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

Re: Uniform call syntax for implicit this.

On Thursday, February 03, 2011 09:54:44 Michel Fortin wrote:
 On 2011-02-03 12:43:12 -0500, Daniel Gibson metalcae...@gmail.com said:
  Am 03.02.2011 15:57, schrieb Michel Fortin:
  On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:
  When implemented, will uniform call syntax work for the this
  object even if not specified?
  
  For example, will foo() get called in the following example?
  
  void foo(A a, int b) {}
  
  class A {
  void test() {
  this.foo(10);
  foo(10);
  }
  }
  
  I think it should work.
  
  I think foo(10) should *not* be equivalent to foo(this, 10).
 
 Personally, I'm not sure whether the uniform call syntax will be this
 much useful or not, but if it gets implemented I think foo(10) should
 be equivalent to foo(this, 10) in the case above. That said, it should
 not be ambiguous: if there is a member function foo and a global
 function foo and both matches the call, it's ambiguous and it should be
 an error.
 
 Can this work in practice? We probably won't know until we have an
 implementation to play with.

Except that if you have both a member function foo and a free function foo, how 
can you tell the compiler which to use? Assuming that foo(10) unambigously 
calls 
the free function, then you have a way to call the free function - or if 
.foo(10) calls the free function, then you have a way to call the free 
function. 
But how would you call the member function? this.foo(10) is ambiguous, and what 
other way is there? It seems to me that we'll be forced to make it so that if 
there's any ambiguity between a free function and a member function, then it's 
the member function that gets called rather than making the programmer be more 
explicit like we usually would - simply because there is no way for the 
programmer to be more explicit.

- Jonathan M Davis

Re: D vs Go on reddit

2011-02-03 Thread Walter Bright


Ulrik Mikaelsson wrote:

The purpose of higher-level languages is to encourage good
programming style and readability. Period. The syntax is crucial here,
it determines which constructs will become readable, and which won't,
which in turn determines the mind-set of the programmer. Which is why
I consider syntactic sugar to be seriously under-appreciated and
undervalued in many language decisions.



That's one way to put it. I view a programming language as a way to map the way 
humans think into the way the machine works. Orthogonal languages have a 
mathematical simplicity to them, but (as one quickly discovers when trying to 
implement a good user interface) people are just not orthogonal and do not think 
in an orthogonal matter. Good user interfaces tend to be enormously complex 
under the hood, all to create a simple, intuitive interface?


For example, why have do-while loops, while loops, for loops and foreach loops? 
Only one is really needed in an orthogonal language. The multiple forms persist 
in language after language because they fit the idiosyncracies of how our brains 
think about coding.


As many of you know, I like to work on my cars. My emergency toolkit has just a 
small handful of simple tools, like a screwdriver. I can use a screwdriver as a 
screw driver, a hammer, a lever, a chisel, a punch, a scraper, a mixer, even a 
bus bar (to short across the starter relay). It's good enough at those things to 
get me home.


But when I'm home, I reach for a tool designed specifically for the purpose. 
That means I've got a lot of tools. Yup.


I kind of view the complexity of D that way. There are a lot of tools in it 
for specific jobs. Yes, I could get the job done with a screwdriver and monkey 
wrench, but it would be ugly. I can do lambdas and closures and virtual 
functions in vanilla C, too, it's just darned messy, unappealing, time consuming 
and far more likely to skin my knuckles.

Re: D vs Go on reddit

2011-02-03 Thread so


Jokes aside, I think people in language-debates often forget that
high-level languages are really just layers of syntactical sugar over
machine-code. ASM is syntactical sugar over machince-code, C is
syntactical sugar over ASM, and D is mostly syntactic sugar over C.
They are merely ways to streamline certain programming-models, into a
language that encourages those idioms and constructs. Just about
anything that can be written in D, can be written with equivalent
semantics in C, but the D-version is likely to be faster to write, and
faster to comprehend.

The purpose of higher-level languages is to encourage good
programming style and readability. Period. The syntax is crucial here,
it determines which constructs will become readable, and which won't,
which in turn determines the mind-set of the programmer. Which is why
I consider syntactic sugar to be seriously under-appreciated and
undervalued in many language decisions.


One argument i often encounter about features, syntax in language  
discussions is What namespaces can do that namespace_func can't?.
Answer might be pretty obvious to many, but consider the corner cases of  
some namespace implementations. (C++ here)


You simply can't provide a clean library with the given namespace features.

---
namespace ns1 {
class A;

}

namespace ns2 {

class C {
A* pa;
};
}
---

but in D it is quite elegant.

---
module ns2;
private import ns1;

class C {
A* pa;
};
---

Re: D vs Go on reddit


On 02/03/2011 07:16 PM, Ulrik Mikaelsson wrote:

2011/2/3 Jérôme M. Bergerjeber...@free.fr:

Then why has not Lisp won over all competition years ago?

Jerome

You mean why(not(has(won(lisp,all(competition)),years_ago))) ?

Jokes aside, I think people in language-debates often forget that
high-level languages are really just layers of syntactical sugar over
machine-code. ASM is syntactical sugar over machince-code, C is
syntactical sugar over ASM, and D is mostly syntactic sugar over C.
They are merely ways to streamline certain programming-models, into a
language that encourages those idioms and constructs. Just about
anything that can be written in D, can be written with equivalent
semantics in C, but the D-version is likely to be faster to write, and
faster to comprehend.


The first part of this paragraph says, imo, something different from the second 
part.
I think there are two kinds of features over a core language: ones are as you 
say plain sugar; others (let's call them conceptual) introduce new semantic 
notions. To distingish those 2 kinds, one needs to observe how translation of 
code involving a given feature into the core language is to be done:

* sugar features only require plain rewriting
* conceptual features require a transformation of the code

The purpose of PL design, imo, is to figure out what kinds of notions people 
use to model and define them in the language. Then, expressing a model 
holding such notions using this language is direct. If a given notion does not 
exist in the language used, then one needs to transform the model before beeing 
able to express it; then, the code does not look like what it means (or 
should). This is what I call semantic distortion (and others conceptual 
mismatch).


The above distinction of 2 kinds of features is taken from a document called 
(IIRC) Expressive power of Programming languages, which itself builds on a 
similar distinction made in the field of logic formal languages.



The purpose of higher-level languages is to encourage good
programming style and readability. Period. The syntax is crucial here,
it determines which constructs will become readable, and which won't,
which in turn determines the mind-set of the programmer. Which is why
I consider syntactic sugar to be seriously under-appreciated and
undervalued in many language decisions.


Syntax  semantics play together in linguistic notions built into a language. 
Sugar features are purely syntactic, library features purely 
semantic/conceptual, linguistic features are both.


Trivial example: the notion of iteration expressed by 'foreach'. Why is it so 
successful, while it's usually trivial to do without it? I guess the reason is 
foreach expresses, as is, a notion that exists in the (mental) language of 
modelling. Without foreach, one needs to transform this notion into different 
semantics, using a general purpose looping construct (while), also involving 
elements that do not belong to the model (node pointer, ordinal index,...).
Since this is an extremely common idiom, we are used to decode it as 
iteration at first sight. But the code does /not/ inherently express 
iteration by itself:


foreach (node ; list) {
auto element = node.element;
doSomethingWith(element);
}

Node* node = list;
while (node) {
auto element = node.element;
doSomethingWith(element);
node = node.next;
}


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

Re: Uniform call syntax for implicit this.


On 2011-02-03 13:42:30 -0500, Jonathan M Davis jmdavisp...@gmx.com said:


On Thursday, February 03, 2011 09:54:44 Michel Fortin wrote:

On 2011-02-03 12:43:12 -0500, Daniel Gibson metalcae...@gmail.com said:

Am 03.02.2011 15:57, schrieb Michel Fortin:

On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:

When implemented, will uniform call syntax work for the this
object even if not specified?

For example, will foo() get called in the following example?

void foo(A a, int b) {}

class A {
void test() {
this.foo(10);
foo(10);
}
}


I think it should work.


I think foo(10) should *not* be equivalent to foo(this, 10).


Personally, I'm not sure whether the uniform call syntax will be this
much useful or not, but if it gets implemented I think foo(10) should
be equivalent to foo(this, 10) in the case above. That said, it should
not be ambiguous: if there is a member function foo and a global
function foo and both matches the call, it's ambiguous and it should be
an error.

Can this work in practice? We probably won't know until we have an
implementation to play with.


Except that if you have both a member function foo and a free function foo, how
can you tell the compiler which to use?


Indeed, that's a problem. The solution is to sidestep the problem. :-)

We just have to disallow declaring a module-level function and a 
class-level function with the same name and the same parameter types 
(including 'this' in the parameters).


void foo(A a, int i);

class A {
void foo(int i); // error, same as foo(A, int)
}

If the module-level function is in a different module, then you can use 
the module name to disambiguate if necessary. If they're in the same 
module, the compiler catches the error during semantic analysis of the 
module.


I'm not too sure how disruptive this change would be to existing code. 
I'm under the impression that this situation is rare, but I can't say 
for sure.



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

Re: new documentation format for std.algorithm


On 2/3/11 11:02 AM, Jeff Nowakowski wrote:

On 02/03/2011 11:09 AM, Andrei Alexandrescu wrote:


Apparently at least for one person choosing the default makes the text
too large. Making the default smaller in turn makes Wikipedia text too
small.

I wouldn't want to require a change of defaults to see our website or to
compete with Wikipedia :o).


Can't you see the ridiculous of this argument? You are talking about the
problems of one person, and then comparing it to one site. I feel like
you completely ignored what I said.

So go ahead and change it to fixed. I'll now complain it doesn't work
for me. Will you then change it back?


I guess you're right.

Anyhow, the site is up with hyphenation fixed (checked on Chrome, 
probably works in Konqueror too).



Andrei

Re: Uniform call syntax for implicit this.

2011-02-03 Thread bearophile

Michel Fortin:

 We just have to disallow declaring a module-level function and a 
 class-level function with the same name and the same parameter types 
 (including 'this' in the parameters).

No more special cases in D, please.

Bye,
bearophile

Re: Uniform call syntax for implicit this.

On Thu, 03 Feb 2011 14:15:11 -0500, Michel Fortin  
michel.for...@michelf.com wrote:


On 2011-02-03 13:42:30 -0500, Jonathan M Davis jmdavisp...@gmx.com  
said:



On Thursday, February 03, 2011 09:54:44 Michel Fortin wrote:
On 2011-02-03 12:43:12 -0500, Daniel Gibson metalcae...@gmail.com  
said:

Am 03.02.2011 15:57, schrieb Michel Fortin:

On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:

When implemented, will uniform call syntax work for the this
object even if not specified?
 For example, will foo() get called in the following example?
 void foo(A a, int b) {}
 class A {
void test() {
this.foo(10);
foo(10);
}
}

 I think it should work.

 I think foo(10) should *not* be equivalent to foo(this, 10).

 Personally, I'm not sure whether the uniform call syntax will be this
much useful or not, but if it gets implemented I think foo(10) should
be equivalent to foo(this, 10) in the case above. That said, it should
not be ambiguous: if there is a member function foo and a global
function foo and both matches the call, it's ambiguous and it should be
an error.
 Can this work in practice? We probably won't know until we have an
implementation to play with.
 Except that if you have both a member function foo and a free function  
foo, how

can you tell the compiler which to use?


Indeed, that's a problem. The solution is to sidestep the problem. :-)

We just have to disallow declaring a module-level function and a  
class-level function with the same name and the same parameter types  
(including 'this' in the parameters).


void foo(A a, int i);

class A {
void foo(int i); // error, same as foo(A, int)
}

If the module-level function is in a different module, then you can use  
the module name to disambiguate if necessary. If they're in the same  
module, the compiler catches the error during semantic analysis of the  
module.


I'm not too sure how disruptive this change would be to existing code.  
I'm under the impression that this situation is rare, but I can't say  
for sure.



The more I think about it (and read discussions like this), the more I  
think that uniform call syntax should only be allowed for types which  
cannot declare member functions (arrays, primitives, enums, etc.).   
Otherwise, we introduce new ambiguities that serve little purpose except  
annoyance.


If I have a function foo(A) and A has a member foo(), then foo(myA) should  
call the free function, myA.foo() should call the member.  If this doesn't  
continue to be correct, we have taken a step backwards.


-Steve

Re: Uniform call syntax for implicit this.

On Thursday, February 03, 2011 11:15:11 Michel Fortin wrote:
 On 2011-02-03 13:42:30 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
  On Thursday, February 03, 2011 09:54:44 Michel Fortin wrote:
  On 2011-02-03 12:43:12 -0500, Daniel Gibson metalcae...@gmail.com said:
  Am 03.02.2011 15:57, schrieb Michel Fortin:
  On 2011-02-02 23:48:15 -0500, %u dfl...@sgjds.com said:
  When implemented, will uniform call syntax work for the this
  object even if not specified?
  
  For example, will foo() get called in the following example?
  
  void foo(A a, int b) {}
  
  class A {
  void test() {
  this.foo(10);
  foo(10);
  }
  }
  
  I think it should work.
  
  I think foo(10) should *not* be equivalent to foo(this, 10).
  
  Personally, I'm not sure whether the uniform call syntax will be this
  much useful or not, but if it gets implemented I think foo(10) should
  be equivalent to foo(this, 10) in the case above. That said, it should
  not be ambiguous: if there is a member function foo and a global
  function foo and both matches the call, it's ambiguous and it should be
  an error.
  
  Can this work in practice? We probably won't know until we have an
  implementation to play with.
  
  Except that if you have both a member function foo and a free function
  foo, how can you tell the compiler which to use?
 
 Indeed, that's a problem. The solution is to sidestep the problem. :-)
 
 We just have to disallow declaring a module-level function and a
 class-level function with the same name and the same parameter types
 (including 'this' in the parameters).
 
   void foo(A a, int i);
 
   class A {
   void foo(int i); // error, same as foo(A, int)
   }
 
 If the module-level function is in a different module, then you can use
 the module name to disambiguate if necessary. If they're in the same
 module, the compiler catches the error during semantic analysis of the
 module.
 
 I'm not too sure how disruptive this change would be to existing code.
 I'm under the impression that this situation is rare, but I can't say
 for sure.

I take it then that you're suggesting that the compiler automatically select 
the 
member function when the conflicting free function is a separate module? What 
about if the class or struct was declared in a separate module but the free 
function is in the current module? You're back to the same problem again. The 
only solution I see is for the compiler to just always pick the member function 
if there's an ambiguity, but I don't know if that will cause other problems or 
not. It _could_ change which function is called if the member function 
disappears. Still, I don't see what else you we do, unless we tried to say that 
you couldn't declare a free function with the same name as a member function 
that you use in that module and which conflicted with that member function, but 
that seems awfully restrictive.

And then, of course, when you add alias this and opDispatch into the mix...

There are certain cases where UFCS looks _really_ appealing if not outright 
necesarry, but it could get ugly in some cases. I'm not sure that alias this 
and 
opDispatch really play nicely together at this point (I rarely use either). 
Adding UFCS on top of that would just make it worse. So, UFCS is _really_ 
appealing, but I don't know if it can be reasonably done.

- Jonathan M Davis

Re: std.xml should just go

On Thursday, February 03, 2011 11:30:17 Tomek Sowiński wrote:
 Andrei Alexandrescu napisał:
   I'm not against replacement, but I'd be concerned about removal before
   a replacement is available.
  
  My problem is that the mere presence is reducing the likelihood of a
  replacement coming about, in addition to the other liabilities.
 
 Is anyone tasked with a replacement yet? I had to write an XML parser at
 some point. It's plenty of work bringing up to industrial quality, so I'd
 have to know that before I dive in.

I think that at least a couple of people have said that they have the 
beginnings 
of a replacement, but I don't believe that anyone has stepped up to say that 
they'll actually complete and propose a module for inclusion in Phobos.

So, std.xml is still very much up in the air, and Tango has set a very high bar 
with regards to speed. And while we may not be able to match Tango for speed - 
especially at first - we'd definitely like to have an xml solution that's 
close. 
And that's not necessarily going to be easy - especially since we're inevitably 
going to want a range-based solution. And while ranges can be quite efficient, 
it 
can also be easy to make them inefficient if you're not careful.

- Jonathan M Davis

Re: new documentation format for std.algorithm

On Thursday, February 03, 2011 11:22:14 Andrei Alexandrescu wrote:
 On 2/3/11 11:02 AM, Jeff Nowakowski wrote:
  On 02/03/2011 11:09 AM, Andrei Alexandrescu wrote:
  Apparently at least for one person choosing the default makes the text
  too large. Making the default smaller in turn makes Wikipedia text too
  small.
  
  I wouldn't want to require a change of defaults to see our website or to
  compete with Wikipedia :o).
  
  Can't you see the ridiculous of this argument? You are talking about the
  problems of one person, and then comparing it to one site. I feel like
  you completely ignored what I said.
  
  So go ahead and change it to fixed. I'll now complain it doesn't work
  for me. Will you then change it back?
 
 I guess you're right.
 
 Anyhow, the site is up with hyphenation fixed (checked on Chrome,
 probably works in Konqueror too).

Confirmed. It looks fine in Konqueror now.

Overall, the table at the top makes things look much nicer.

- Jonathan M Davis

Re: D vs Go on reddit


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

That's one way to put it. I view a programming language as a way to map the way
humans think into the way the machine works. Orthogonal languages have a
mathematical simplicity to them, but (as one quickly discovers when trying to
implement a good user interface) people are just not orthogonal and do not
think in an orthogonal matter. Good user interfaces tend to be enormously
complex under the hood, all to create a simple, intuitive interface?

For example, why have do-while loops, while loops, for loops and foreach loops?
Only one is really needed in an orthogonal language. The multiple forms persist
in language after language because they fit the idiosyncracies of how our
brains think about coding.


Waow, that's just how I see the job of language design!

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

Re: std.xml should just go


On 2/3/11 1:30 PM, Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


I'm not against replacement, but I'd be concerned about removal before a 
replacement is available.


My problem is that the mere presence is reducing the likelihood of a
replacement coming about, in addition to the other liabilities.


Is anyone tasked with a replacement yet? I had to write an XML parser at some 
point. It's plenty of work bringing up to industrial quality, so I'd have to 
know that before I dive in.


Nobody that I know of. If you want to discuss design here while working 
on it, that would be great. I could think of a few high-level requirements:


* works with input ranges so we can plug it in with any source

* works with all UTF widths (statically selectable)

* avoids where possible memory allocation (perhaps by offering 
incremental access a la joiner())


* avoids often-called delegates in favor of alias functions

* is familiar in concept to people who've used today's successful XML 
libraries



Andrei

exercise on range: lexeme stream


Hello,

I have a working lexing toolkit that allows defining a lexer from a language's 
morphology, then let it scan sources. The result is a 'LexemeStream' struct, 
which just wraps an array of Lexeme's; for simplicity, each lexeme holds a 
string tag identifying the kind of lexeme, and the matched slice. Simple example:


Morphology morphology = [
[ SPACING ,`[\ \t]*` ],
[ OPEN_GROUP , `\(` ],
[ CLOSE_GROUP ,`\)` ],
[ number , `[\+\-]?[0-9]+(\.[0-9]+)?` ],
[ symbol , `[a-zA-A][a-zA-A0-9]*` ],
[ operator ,   `[\+\-\*\/]` ],
];
auto lexer = new Lexer(morphology);
// LexemeStream struct:
auto lexemes = lexer.lexemes(source);

LexemeStream mainly provides a single operational method 'match' that works 
more or less like D's builtin 'in' operator:

Lexeme* match (string tag)
It returns a pointer to the current lexeme if said lexeme is of the right kind, 
else null. LexemeStream maintains its own cursor (an ordinal index), so that a 
client parser does not need to update and pass around indices. Very practical. 
It also exposes an (automagically maintained) 'empty' boolean member. For 
instance, matching a number may look like:

NumberNode readNumber (LexemeStream lexemes) { // no index!
auto lexeme = lexemes.match(number);
if (!lexeme)
return null;
return new NumberNode(lexeme.slice);
// cursor has advanced for further parsing
}

From this point of view, LexemeStream behaves similarly to an input range. But 
match does both popFront and front, and even also maintains empty in the 
background. I wonder about the best way to rewrite LexemeStream into a regular 
range. (*) (**)


Random thoughts:
I wonder in fact whether LexemeStream matches (no pun intended ;-) the general 
notion of range, or instead is a different sort of beast; if the latter, then what?
The key point, maybe, is that the stream advances /on conditon/. In other 
words, we do not just traverse it like for a regular iteration. We may need a 
parameter to popFront holding said conditon (here, the 'tag'). Then, front 
could return null (or whatever flag value) when the condition is not fulfilled, 
in which case the range does not move forward at all.

The above func would then look like:

NumberNode readNumber (LexemeStream lexemes) { // no index!
lexemes.popFront(number);
auto lexeme = lexemes.front();
if (!lexeme)
return null;
return new NumberNode(lexeme.slice);
}

Another solution may be for popFront to return a boolean flag; then, a 
gentleman agreement is to read front only in positive (true) case:


NumberNode readNumber (LexemeStream lexemes) { // no index!
match = lexemes.popFront(number);
if (!match)
return null;
auto lexeme = lexemes.front();
return new NumberNode(lexeme.slice);
}

Denis

(*) A side issue (easily solvable) is that there must be a cursor. Meaning, 
LexemeStream cannot just shrink its internal array when matching. The reason is 
combinations of composite and choice patterns may require backtracking in 
lexeme stream:

T readAssignment (LexemeStream lexemes) {
auto cursor = lexemes.cursor// store initial cursor
// ... try  match target name ...
// ... try  match '=' ...
if (!lexeme) {
lexemes.cursor = cursor0;   // restore intiial cursor
return null;
}
// ... try  match value expression ...
}
T readStatement (LexemeStream lexemes) {
// read assignment|func-call|control-statement|...
}
A solution is to make popFront advance the cursor instead of eating the array, 
front return array[cursor] instead of array[0], and empty == (cursor = 
array.length) instead of (array.length == 0).


(**) I cannot really do it as aof now anyway, because of the bug (in 
formatValue template constraints) preventing a range to define toString, but am 
still highly interested in the exercise --if only for the future.

--
_
vita es estrany
spir.wikidot.com

Re: std.xml should just go

Andrei Alexandrescu napisał:

  Is anyone tasked with a replacement yet? I had to write an XML parser at 
  some point. It's plenty of work bringing up to industrial quality, so I'd 
  have to know that before I dive in.  
 
 Nobody that I know of. If you want to discuss design here while working 
 on it, that would be great.

Alright, I'm game. I'll assemble something discussable.

 I could think of a few high-level requirements:

My requirements are similar. (if I don't comment below, then I agree)

 * works with input ranges so we can plug it in with any source
 
 * works with all UTF widths (statically selectable)
 
 * avoids where possible memory allocation (perhaps by offering 
 incremental access a la joiner())

What you mean by incremental access? A lazy range? It's obvious for the lexer, 
but on a higher level? Not sure if I can start traversing the DOM until the 
closing tag comes (if at all)... A lazy range of tags defined in the global 
scope seems possible, though.

 * avoids often-called delegates in favor of alias functions

What use case of delegates are you talking about?

 * is familiar in concept to people who've used today's successful XML 
 libraries

-- 
Tomek

Re: std.xml should just go

Jonathan M Davis napisał:

 I think that at least a couple of people have said that they have the 
 beginnings 
 of a replacement, but I don't believe that anyone has stepped up to say that 
 they'll actually complete and propose a module for inclusion in Phobos.

Wimps ;-)

 So, std.xml is still very much up in the air, and Tango has set a very high 
 bar 
 with regards to speed. And while we may not be able to match Tango for speed 
 - 
 especially at first - we'd definitely like to have an xml solution that's 
 close. 
 And that's not necessarily going to be easy - especially since we're 
 inevitably 
 going to want a range-based solution. And while ranges can be quite 
 efficient, it 
 can also be easy to make them inefficient if you're not careful.

Speaking of Tango, may I look at it? I remember that beef over the first 
datetime and it gives me shivers...

-- 
Tomek

Re: Uniform call syntax for implicit this.


On 02/03/2011 08:15 PM, Michel Fortin wrote:

On 2011-02-03 13:42:30 -0500, Jonathan M Davis jmdavisp...@gmx.com said:




Except that if you have both a member function foo and a free function foo, how
can you tell the compiler which to use?


Indeed, that's a problem. The solution is to sidestep the problem. :-)

We just have to disallow declaring a module-level function and a class-level
function with the same name and the same parameter types (including 'this' in
the parameters).

void foo(A a, int i);

class A {
void foo(int i); // error, same as foo(A, int)
}

If the module-level function is in a different module, then you can use the
module name to disambiguate if necessary. If they're in the same module, the
compiler catches the error during semantic analysis of the module.

I'm not too sure how disruptive this change would be to existing code. I'm
under the impression that this situation is rare, but I can't say for sure.


How can you propose this, Michel? Complexify the language, and any 
implementation, just for a non-feature that makes code very hard to decode, by 
requiring a double mental rewriting operation:

foo(i) -- this.foo(i) -- foo(this,i)
what advantage does this feature provide? None. What additional drawback: see 
thread above.


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

Re: std.xml should just go


On Thu, 03 Feb 2011 15:48:45 -0500, Tomek Sowiński j...@ask.me wrote:


Jonathan M Davis napisał:

I think that at least a couple of people have said that they have the  
beginnings
of a replacement, but I don't believe that anyone has stepped up to say  
that

they'll actually complete and propose a module for inclusion in Phobos.


Wimps ;-)

So, std.xml is still very much up in the air, and Tango has set a very  
high bar
with regards to speed. And while we may not be able to match Tango for  
speed -
especially at first - we'd definitely like to have an xml solution  
that's close.
And that's not necessarily going to be easy - especially since we're  
inevitably
going to want a range-based solution. And while ranges can be quite  
efficient, it

can also be easy to make them inefficient if you're not careful.


Speaking of Tango, may I look at it? I remember that beef over the first  
datetime and it gives me shivers...


I'd recommend not looking at it based on past experience.

From this Tango forum post:  
http://www.dsource.org/projects/tango/forums/topic/389 it looks like it  
was based on sendero, which looks like it's GPL  
(http://sourceforge.net/projects/sendero/).  Not much help there, but you  
might get good luck contacting the sendero author to see if he is willing  
to change the license for Phobos (he obviously must have for Tango, since  
Tango is not GPL).


I believe it is a pull parser, though I'm not sure what that means.  What  
I do know about Tango is that they strive to avoid memory allocation at  
any cost.  Likely it uses the excellent buffering I/O that Tango has in  
order to avoid copying the input data once it is read from a file.  You  
will be hard pressed to compete with Tango until phobos gets better I/O  
support (it currently relies on C FILE * I/O).


-Steve

Re: std.xml should just go

Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Jonathan M Davis napisał:
 
 I think that at least a couple of people have said that they have the 
 beginnings 
 of a replacement, but I don't believe that anyone has stepped up to say that 
 they'll actually complete and propose a module for inclusion in Phobos.
 
 Wimps ;-)
 
 So, std.xml is still very much up in the air, and Tango has set a very high 
 bar 
 with regards to speed. And while we may not be able to match Tango for speed 
 - 
 especially at first - we'd definitely like to have an xml solution that's 
 close. 
 And that's not necessarily going to be easy - especially since we're 
 inevitably 
 going to want a range-based solution. And while ranges can be quite 
 efficient, it 
 can also be easy to make them inefficient if you're not careful.
 
 Speaking of Tango, may I look at it? I remember that beef over the first 
 datetime and it gives me shivers...
 

You probably shouldn't look at the source.
I dunno about the interface (documentation) - it's certainly not illegal to take
inspiration from it, but maybe then people will again claim that source was
stolen.. but when you claim that you haven't looked at the source it may be ok..

Maybe a clean-room approach is possible: Somebody else looks at the source and
documents what it does and how it does that (without copying anything) and you
could use that documentation for your own code.
If you don't want to clone it but have questions about how they did something
specific you could just ask here and (hopefully) someone looks it up and
explains it to you.

Cheers,
- Daniel

Re: Uniform call syntax for implicit this.


On 02/03/2011 08:43 PM, Steven Schveighoffer wrote:

The more I think about it (and read discussions like this), the more I think
that uniform call syntax should only be allowed for types which cannot declare
member functions (arrays, primitives, enums, etc.).  Otherwise, we introduce
new ambiguities that serve little purpose except annoyance.


More precisely, it should work with all types in position of first parameter, 
but using implicit this like with member functions. This is ok:

void f (C c, I i) {...}
auto c = new C();
I i;
c.f(i);
Don't you think so?

The case of member functions using implicit this requires a double rewrite:
f(i) -- this.f(i) -- f(this,i)
The second one corresponds to universal func call; but the first one is the 
automagic implicit this which, strictly speaking, should only work for members 
of the given type. f not beeing a member, the magic should not apply here. 
Note: if g is a member functon, then g(i) already works.
No ambiguity, no complication of the language, no headache for Walter et all, 
no unreadable code, no recurring issue on D-learn ;-)



If I have a function foo(A) and A has a member foo(), then foo(myA) should call
the free function, myA.foo() should call the member.  If this doesn't continue
to be correct, we have taken a step backwards.


Agreed.

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

Re: std.xml should just go

On Thursday 03 February 2011 12:48:45 Tomek Sowiński wrote:
 Jonathan M Davis napisał:
  I think that at least a couple of people have said that they have the
  beginnings of a replacement, but I don't believe that anyone has stepped
  up to say that they'll actually complete and propose a module for
  inclusion in Phobos.
 
 Wimps ;-)
 
  So, std.xml is still very much up in the air, and Tango has set a very
  high bar with regards to speed. And while we may not be able to match
  Tango for speed - especially at first - we'd definitely like to have an
  xml solution that's close. And that's not necessarily going to be easy -
  especially since we're inevitably going to want a range-based solution.
  And while ranges can be quite efficient, it can also be easy to make
  them inefficient if you're not careful.
 
 Speaking of Tango, may I look at it? I remember that beef over the first
 datetime and it gives me shivers...

I don't know. I wouldn't. It would just be safer that way. I avoid Tango 
completely, because I don't want even the possibility of being accused of 
copying anything from there. But maybe someone who's more in the know about 
Tango would have something different to say.

Regardless, as I understand it, the main reasons for Tango's speed in parsing 
xml is the fact that D's array slicing lets it avoid doing much in the way of 
copying. And while the new std.xml should be range-based, the slicing benefits 
should still hold (at least with built-in strings) as long as we avoid using 
range-based functions which would copy the data rather than slicing it.

- Jonathan M Davis

Re: std.xml should just go


On 02/03/2011 10:00 PM, Steven Schveighoffer wrote:

I believe it is a pull parser, though I'm not sure what that means.


http://en.wikipedia.org/wiki/XML#Pull_parsing
 ---

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

Re: std.xml should just go


On 02/03/2011 10:03 PM, Daniel Gibson wrote:

You probably shouldn't look at the source.
I dunno about the interface (documentation) - it's certainly not illegal to take
inspiration from it, but maybe then people will again claim that source was
stolen.. but when you claim that you haven't looked at the source it may be ok..

Maybe a clean-room approach is possible: Somebody else looks at the source and
documents what it does and how it does that (without copying anything) and you
could use that documentation for your own code.
If you don't want to clone it but have questions about how they did something
specific you could just ask here and (hopefully) someone looks it up and
explains it to you.


Mamma mia! In what world are we supposed to live!?

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

Re: std.xml should just go

On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com  
wrote:



Am 03.02.2011 21:48, schrieb Tomek Sowiński:

Jonathan M Davis napisał:

I think that at least a couple of people have said that they have the  
beginnings
of a replacement, but I don't believe that anyone has stepped up to  
say that

they'll actually complete and propose a module for inclusion in Phobos.


Wimps ;-)

So, std.xml is still very much up in the air, and Tango has set a very  
high bar
with regards to speed. And while we may not be able to match Tango for  
speed -
especially at first - we'd definitely like to have an xml solution  
that's close.
And that's not necessarily going to be easy - especially since we're  
inevitably
going to want a range-based solution. And while ranges can be quite  
efficient, it

can also be easy to make them inefficient if you're not careful.


Speaking of Tango, may I look at it? I remember that beef over the  
first datetime and it gives me shivers...




You probably shouldn't look at the source.
I dunno about the interface (documentation) - it's certainly not illegal  
to take
inspiration from it, but maybe then people will again claim that source  
was
stolen.. but when you claim that you haven't looked at the source it may  
be ok..


It has been posited by Tango's developers that simply looking at the  
documentation of a D library isn't enough to understand the library, you  
probably have looked at the source.  Until they change that opinion, I  
would avoid even the documentation.


http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html

The pertinent quote from there:

In my opinion, claiming a clean room implementation of an API in D is  
difficult, if for no other reason that it is (due to imperfect doc  
generation etc) somewhat difficult to properly study a D API without at  
the same time reading the source (or glimpsing at it).


Maybe a clean-room approach is possible: Somebody else looks at the  
source and
documents what it does and how it does that (without copying anything)  
and you

could use that documentation for your own code.
If you don't want to clone it but have questions about how they did  
something

specific you could just ask here and (hopefully) someone looks it up and
explains it to you.


Make sure if you follow this approach that you document exactly the  
process and how it was done.


-Steve

Re: Should we have an Unimplemented Attribute?

2011-02-03 Thread Andrej Mitrovic

On 2/3/11, Gerrit Wichert gwich...@yahoo.com wrote:
 Am 02.02.2011 23:59, schrieb Andrej Mitrovic:
 But what about structs/classes/functions/etc which are partially
 implemented, but still unusable? Marking them with deprecated doesn't
 make sense, as this will likely confuse both the user and the library
 writers. Would it be overkill to introduce a new attribute?

 What about version( comming_soon)   ?  :-)


version(in_imax_theatres_near_you) :)

Re: Uniform call syntax for implicit this.


On Thu, 03 Feb 2011 16:05:01 -0500, spir denis.s...@gmail.com wrote:


On 02/03/2011 08:43 PM, Steven Schveighoffer wrote:
The more I think about it (and read discussions like this), the more I  
think
that uniform call syntax should only be allowed for types which cannot  
declare
member functions (arrays, primitives, enums, etc.).  Otherwise, we  
introduce

new ambiguities that serve little purpose except annoyance.


More precisely, it should work with all types in position of first  
parameter, but using implicit this like with member functions. This is  
ok:

 void f (C c, I i) {...}
 auto c = new C();
 I i;
 c.f(i);
Don't you think so?


But what if C also defines f?  I don't think c.f(i) should fail in that  
case.  If it doesn't fail, then surprises/hijacking will occur (hey, I  
thought I was calling my f, what gives?!).  You could write code like this:


import std.somemodule : A;

void f(A a, int i) {...}

void foo()
{
  auto a = new A;
  a.f(1);
}

and then some day, the author of std.somemodule now decides he wants to  
add a member function f(int).  All of a sudden, all places you use a.f now  
mean something else (dangerous).  This is unacceptable.  It's also  
unacceptable for a.f to call your f (confusing/ambiguous, sometimes a.f  
means your f, sometimes it means the member), or to have the compiler  
error (annoying).  I don't see any good solution to this, except to say,  
nope, you just gotta write f(a, 1), tough shit.


I really don't understand the benefit of allowing a.f instead of f(a),  
it's a *trivial* gain at best.  Note that if I see your code, I'm going  
straight to the definition of A to try and find the f member function.  If  
I can't find it there, with UFC syntax, it could be anywhere.


OTOH, adding member functions to types that don't allow members, although  
equally as trivial (find(str, hi) vs. str.find(hi) ), at least is not  
ambiguous :)


-Steve

Re: std.xml should just go

Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com 
 wrote:
 
 Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Jonathan M Davis napisał:

 I think that at least a couple of people have said that they have the
 beginnings
 of a replacement, but I don't believe that anyone has stepped up to say 
 that
 they'll actually complete and propose a module for inclusion in Phobos.

 Wimps ;-)

 So, std.xml is still very much up in the air, and Tango has set a very 
 high bar
 with regards to speed. And while we may not be able to match Tango for 
 speed -
 especially at first - we'd definitely like to have an xml solution that's
 close.
 And that's not necessarily going to be easy - especially since we're 
 inevitably
 going to want a range-based solution. And while ranges can be quite
 efficient, it
 can also be easy to make them inefficient if you're not careful.

 Speaking of Tango, may I look at it? I remember that beef over the first
 datetime and it gives me shivers...


 You probably shouldn't look at the source.
 I dunno about the interface (documentation) - it's certainly not illegal to 
 take
 inspiration from it, but maybe then people will again claim that source was
 stolen.. but when you claim that you haven't looked at the source it may be 
 ok..
 
 It has been posited by Tango's developers that simply looking at the
 documentation of a D library isn't enough to understand the library, you
 probably have looked at the source.  Until they change that opinion, I would
 avoid even the documentation.
 
 http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
 
 The pertinent quote from there:
 
 In my opinion, claiming a clean room implementation of an API in D is
 difficult, if for no other reason that it is (due to imperfect doc generation
 etc) somewhat difficult to properly study a D API without at the same time
 reading the source (or glimpsing at it).
 

They can claim whatever they want.. if Tomek says he only looked at the
documentation (for an idea how a good interface for a XML lib may look like)
they can hardly prove anything.
Furthermore this (I haven't seen the source) is an argument that Walter will
(probably) accept when deciding whether to include the module in Phobos, because
he used it himself in the past IIRC.

 Maybe a clean-room approach is possible: Somebody else looks at the source 
 and
 documents what it does and how it does that (without copying anything) and 
 you
 could use that documentation for your own code.
 If you don't want to clone it but have questions about how they did something
 specific you could just ask here and (hopefully) someone looks it up and
 explains it to you.
 
 Make sure if you follow this approach that you document exactly the process 
 and
 how it was done.

Yes, it'd be best to do this publicly, e.g. in this newsgroup (or maybe the
phobos mailing list). So it's obvious who has seen the source and has written
the documentation that was used by someone else to write the code that may look
similar to the Tango code.

 
 -Steve

Cheers,
- Daniel

Re: std.xml should just go

2011-02-03 Thread Gary Whatmore

Steven Schveighoffer Wrote:

 On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com  
 wrote:
 
  Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
  On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson  
  metalcae...@gmail.com wrote:
 
  Am 03.02.2011 21:48, schrieb Tomek SowiÅski:
  Speaking of Tango, may I look at it? I remember that beef over the  
  first
  datetime and it gives me shivers...
 
 
  You probably shouldn't look at the source.
  I dunno about the interface (documentation) - it's certainly not  
  illegal to take
  inspiration from it, but maybe then people will again claim that  
  source was
  stolen.. but when you claim that you haven't looked at the source it  
  may be ok..
 
  It has been posited by Tango's developers that simply looking at the
  documentation of a D library isn't enough to understand the library, you
  probably have looked at the source.  Until they change that opinion, I  
  would
  avoid even the documentation.
 
  http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
 
  The pertinent quote from there:
 
  In my opinion, claiming a clean room implementation of an API in D is
  difficult, if for no other reason that it is (due to imperfect doc  
  generation
  etc) somewhat difficult to properly study a D API without at the same  
  time
  reading the source (or glimpsing at it).
 
 
  They can claim whatever they want.. if Tomek says he only looked at the
  documentation (for an idea how a good interface for a XML lib may look  
  like)
  they can hardly prove anything.
 
 This exact situation was the case of the prior-mentioned infringement  
 accusation.

It's sad to read how much these Tango assholes are trying to wreck the whole 
language. I doubt their implementation is any better than the high performance 
C++ libraries. I've been using RapidXML before and it's damn fast. My recipe 
for success would be: use the Boost license, do a clean room implementation 
inspired by the best C++ code, use ranges instead of slices or iterators, use 
Phobos free function and naming conventions, get Andrei's blessing. This will 
teach the Tango douchebags a lesson or two.

They always complain about us doing NIH code. But they're forcing us!

 -G.W.

Re: std.xml should just go

On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com  
wrote:



Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson  
metalcae...@gmail.com wrote:



Am 03.02.2011 21:48, schrieb Tomek Sowiński:
Speaking of Tango, may I look at it? I remember that beef over the  
first

datetime and it gives me shivers...



You probably shouldn't look at the source.
I dunno about the interface (documentation) - it's certainly not  
illegal to take
inspiration from it, but maybe then people will again claim that  
source was
stolen.. but when you claim that you haven't looked at the source it  
may be ok..


It has been posited by Tango's developers that simply looking at the
documentation of a D library isn't enough to understand the library, you
probably have looked at the source.  Until they change that opinion, I  
would

avoid even the documentation.

http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html

The pertinent quote from there:

In my opinion, claiming a clean room implementation of an API in D is
difficult, if for no other reason that it is (due to imperfect doc  
generation
etc) somewhat difficult to properly study a D API without at the same  
time

reading the source (or glimpsing at it).



They can claim whatever they want.. if Tomek says he only looked at the
documentation (for an idea how a good interface for a XML lib may look  
like)

they can hardly prove anything.


This exact situation was the case of the prior-mentioned infringement  
accusation.


-Steve

Re: std.xml should just go

Daniel Gibson napisał:

 They can claim whatever they want.. if Tomek says he only looked at the
 documentation (for an idea how a good interface for a XML lib may look like)
 they can hardly prove anything.

One remark: I haven't even looked at the doc. That's why I was asking may I 
look.

-- 
Tomek

Re: std.xml should just go

Am 03.02.2011 22:45, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com 
 wrote:
 
 Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson metalcae...@gmail.com 
 wrote:

 Am 03.02.2011 21:48, schrieb Tomek Sowiński:
 Speaking of Tango, may I look at it? I remember that beef over the first
 datetime and it gives me shivers...


 You probably shouldn't look at the source.
 I dunno about the interface (documentation) - it's certainly not illegal to
 take
 inspiration from it, but maybe then people will again claim that source was
 stolen.. but when you claim that you haven't looked at the source it may be
 ok..

 It has been posited by Tango's developers that simply looking at the
 documentation of a D library isn't enough to understand the library, you
 probably have looked at the source.  Until they change that opinion, I would
 avoid even the documentation.

 http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html

 The pertinent quote from there:

 In my opinion, claiming a clean room implementation of an API in D is
 difficult, if for no other reason that it is (due to imperfect doc 
 generation
 etc) somewhat difficult to properly study a D API without at the same time
 reading the source (or glimpsing at it).


 They can claim whatever they want.. if Tomek says he only looked at the
 documentation (for an idea how a good interface for a XML lib may look like)
 they can hardly prove anything.
 
 This exact situation was the case of the prior-mentioned infringement 
 accusation.
 
 -Steve

Was it? I thought the Author *had* looked at the Tango source but claimed not to
have used it?

Claiming that looking at the documentation isn't sufficient to understand how
the API works (from a users point of view, not internally) is pretty stupid:
1. it insults the modules author(s) (You're too stupid to write meaningful
documentation)
2. even if the documentation sucks one may have understood how to the API is
used by looking at code examples using it...

Well, however, so Tomek should probably not even look at the docs..

But when a possible API for the module is discussed maybe people with Tango
experience can contribute ideas (if the Tango XML API is any good, so far I've
only heard that their implementation is very fast, but nothing about usability).

(This situation really sucks. It's unbelievable how much FUD that prior incident
has created.)

Cheers,
- Daniel

Re: std.xml should just go

spir spir napisał:

  You probably shouldn't look at the source.
  I dunno about the interface (documentation) - it's certainly not illegal to 
  take
  inspiration from it, but maybe then people will again claim that source was
  stolen.. but when you claim that you haven't looked at the source it may be 
  ok..
 
  Maybe a clean-room approach is possible: Somebody else looks at the source 
  and
  documents what it does and how it does that (without copying anything) and 
  you
  could use that documentation for your own code.
  If you don't want to clone it but have questions about how they did 
  something
  specific you could just ask here and (hopefully) someone looks it up and
  explains it to you.  
 
 Mamma mia! In what world are we supposed to live!?

My thoughts exactly. I mean, as soon as Jonathan mentioned Tango's XML, I 
knee-jerkingly got paranoid and asked about legality of even reading about it 
to stay clear. I only hope having heard about it is legal.

-- 
Tomek

Re: std.xml should just go

On Thu, 03 Feb 2011 17:10:18 -0500, Daniel Gibson metalcae...@gmail.com  
wrote:




I thought the Author *had* looked at the Tango source but claimed not to
have used it?


See here:  
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announcearticle_id=18090


His English isn't perfect, but I took his statements to mean he did not  
read the source (as I re-asserted in a later message).


-Steve

Re: Uniform call syntax for implicit this.


On 02/03/2011 10:39 PM, Steven Schveighoffer wrote:

On Thu, 03 Feb 2011 16:05:01 -0500, spir denis.s...@gmail.com wrote:


On 02/03/2011 08:43 PM, Steven Schveighoffer wrote:

The more I think about it (and read discussions like this), the more I think
that uniform call syntax should only be allowed for types which cannot declare
member functions (arrays, primitives, enums, etc.). Otherwise, we introduce
new ambiguities that serve little purpose except annoyance.


More precisely, it should work with all types in position of first parameter,
but using implicit this like with member functions. This is ok:
void f (C c, I i) {...}
auto c = new C();
I i;
c.f(i);
Don't you think so?


But what if C also defines f? I don't think c.f(i) should fail in that case. If
it doesn't fail, then surprises/hijacking will occur (hey, I thought I was
calling my f, what gives?!). You could write code like this:

import std.somemodule : A;

void f(A a, int i) {...}

void foo()
{
auto a = new A;
a.f(1);
}

and then some day, the author of std.somemodule now decides he wants to add a
member function f(int). All of a sudden, all places you use a.f now mean
something else (dangerous). This is unacceptable. It's also unacceptable for
a.f to call your f (confusing/ambiguous, sometimes a.f means your f, sometimes
it means the member), or to have the compiler error (annoying). I don't see any
good solution to this, except to say, nope, you just gotta write f(a, 1),
tough shit.


Right, I agree.


I really don't understand the benefit of allowing a.f instead of f(a), it's a
*trivial* gain at best. Note that if I see your code, I'm going straight to the
definition of A to try and find the f member function. If I can't find it
there, with UFC syntax, it could be anywhere.


Ditto.


OTOH, adding member functions to types that don't allow members, although
equally as trivial (find(str, hi) vs. str.find(hi) ), at least is not
ambiguous :)


That's what I liked in UFCS. But more for conceptual  practical reasons: the 
(pseudo)type name, just like in OO, acts like a namespace englobing all related 
functionality. What I would love for Phobos; ideally, this would come with a 
module system designed in such a way that after:

import T;
I get access to *all* functionality for elements of type T, using syntax like:
t.f(...);
(Wherever f is actually implemented; obviously should be in T.d, but this seems 
to be an Utopia in Phobos.)


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

Re: std.xml should just go

On Thursday, February 03, 2011 13:51:41 Gary Whatmore wrote:
 Steven Schveighoffer Wrote:
  On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com
  
  wrote:
   Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
   On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
   
   metalcae...@gmail.com wrote:
   Am 03.02.2011 21:48, schrieb Tomek SowiÅski:
   Speaking of Tango, may I look at it? I remember that beef over the
   first
   datetime and it gives me shivers...
   
   You probably shouldn't look at the source.
   I dunno about the interface (documentation) - it's certainly not
   illegal to take
   inspiration from it, but maybe then people will again claim that
   source was
   stolen.. but when you claim that you haven't looked at the source it
   may be ok..
   
   It has been posited by Tango's developers that simply looking at the
   documentation of a D library isn't enough to understand the library,
   you probably have looked at the source.  Until they change that
   opinion, I would
   avoid even the documentation.
   
   http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
   
   The pertinent quote from there:
   
   In my opinion, claiming a clean room implementation of an API in D is
   difficult, if for no other reason that it is (due to imperfect doc
   generation
   etc) somewhat difficult to properly study a D API without at the same
   time
   reading the source (or glimpsing at it).
   
   They can claim whatever they want.. if Tomek says he only looked at the
   documentation (for an idea how a good interface for a XML lib may look
   like)
   they can hardly prove anything.
  
  This exact situation was the case of the prior-mentioned infringement
  accusation.
 
 It's sad to read how much these Tango assholes are trying to wreck the
 whole language. I doubt their implementation is any better than the high
 performance C++ libraries. I've been using RapidXML before and it's damn
 fast. My recipe for success would be: use the Boost license, do a clean
 room implementation inspired by the best C++ code, use ranges instead of
 slices or iterators, use Phobos free function and naming conventions, get
 Andrei's blessing. This will teach the Tango douchebags a lesson or two.
 
 They always complain about us doing NIH code. But they're forcing us!

There's no need to be rude. The Tango guys have done some great stuff. 
Benchmarks 
have shown that Tango creams most (if not all) other major xml libraries out 
there. It's lightning fast, and they've done solid work.

But they're using a different license and don't necessarily like the direction 
that D2 or Phobos has gone, since it's definitely different than what they've 
been 
doing, and they don't want people copying their code and putting it under a 
more 
permissive license. I don't happen to agree with them, but I see no reason to 
be 
rude to them about it.

Now, in some cases, if you can get ahold of the people who worked on a 
particular set of code in Tango, it _is_ possible to get them to agree to let 
you port their code to Phobos and the Boost license. However, that requires 
getting ahold of them and getting their consent, which isn't always easy. And 
they have every right to refuse if that's what they want.

Regardless, being rude doesn't help. All that's likely to do is beget rudeness 
on their part. Let's try and be civil.

- Jonathan M Davis

Re: std.xml should just go


On 2/3/11 3:51 PM, Gary Whatmore wrote:

Steven Schveighoffer Wrote:


On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibsonmetalcae...@gmail.com
wrote:


Am 03.02.2011 22:26, schrieb Steven Schveighoffer:

On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
metalcae...@gmail.com  wrote:


Am 03.02.2011 21:48, schrieb Tomek SowiÅ„ski:

Speaking of Tango, may I look at it? I remember that beef over the
first
datetime and it gives me shivers...



You probably shouldn't look at the source.
I dunno about the interface (documentation) - it's certainly not
illegal to take
inspiration from it, but maybe then people will again claim that
source was
stolen.. but when you claim that you haven't looked at the source it
may be ok..


It has been posited by Tango's developers that simply looking at the
documentation of a D library isn't enough to understand the library, you
probably have looked at the source.  Until they change that opinion, I
would
avoid even the documentation.

http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html

The pertinent quote from there:

In my opinion, claiming a clean room implementation of an API in D is
difficult, if for no other reason that it is (due to imperfect doc
generation
etc) somewhat difficult to properly study a D API without at the same
time
reading the source (or glimpsing at it).



They can claim whatever they want.. if Tomek says he only looked at the
documentation (for an idea how a good interface for a XML lib may look
like)
they can hardly prove anything.


This exact situation was the case of the prior-mentioned infringement
accusation.


It's sad to read how much these Tango assholes are trying to wreck the whole 
language. I doubt their implementation is any better than the high performance 
C++ libraries. I've been using RapidXML before and it's damn fast. My recipe 
for success would be: use the Boost license, do a clean room implementation 
inspired by the best C++ code, use ranges instead of slices or iterators, use 
Phobos free function and naming conventions, get Andrei's blessing. This will 
teach the Tango douchebags a lesson or two.

They always complain about us doing NIH code. But they're forcing us!


I think it's reasonable of me to ask avoiding reopening a debate that 
has little chance of being solved by emotional rhetoric.


Regarding taking inspiration from Tango code, I don't know what the 
exact licensing issues are but the lesson learned during past incidents 
is clear: Phobos contributors should conservatively avoid looking at 
Tango. This is not difficult because there are many XML libraries of 
good quality and performance. So let's.



Thanks,

Andrei

Re: std.xml should just go

Am 03.02.2011 23:29, schrieb Steven Schveighoffer:
 On Thu, 03 Feb 2011 17:10:18 -0500, Daniel Gibson metalcae...@gmail.com 
 wrote:
 

 I thought the Author *had* looked at the Tango source but claimed not to
 have used it?
 
 See here:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announcearticle_id=18090
 
 
 His English isn't perfect, but I took his statements to mean he did not read 
 the
 source (as I re-asserted in a later message).
 
 -Steve

Ok :)

Re: std.xml should just go

On Thursday, February 03, 2011 14:17:49 Tomek Sowiński wrote:
 spir spir napisał:
   You probably shouldn't look at the source.
   I dunno about the interface (documentation) - it's certainly not
   illegal to take inspiration from it, but maybe then people will again
   claim that source was stolen.. but when you claim that you haven't
   looked at the source it may be ok..
   
   Maybe a clean-room approach is possible: Somebody else looks at the
   source and documents what it does and how it does that (without
   copying anything) and you could use that documentation for your own
   code.
   If you don't want to clone it but have questions about how they did
   something specific you could just ask here and (hopefully) someone
   looks it up and explains it to you.
  
  Mamma mia! In what world are we supposed to live!?
 
 My thoughts exactly. I mean, as soon as Jonathan mentioned Tango's XML, I
 knee-jerkingly got paranoid and asked about legality of even reading about
 it to stay clear. I only hope having heard about it is legal.

Well, we're not looking to copy what they did. We're just looking to get 
performance that's similar. As I understand it, Tango's XML parser is one of 
the 
best out there as far as speed goes. From the benchmarks I've seen, it 
absolutely creams the competition. So, they're set a high bar, and we'd like to 
reach it. We probably won't be that fast at first, and we may never be that 
fast, 
but it's something to shoot for. Regardless, it's their performance that we're 
interested in, not necessarily their implementation. If they were more open and 
willing to share code, then building off of what they have and turning it into 
a 
range-based solution would likely make a lot of sense, but since that's not the 
case, we need to figure it out on our own.

- Jonathan M Davis

Re: std.xml should just go

On Thursday, February 03, 2011 14:36:06 Andrei Alexandrescu wrote:
 On 2/3/11 3:51 PM, Gary Whatmore wrote:
  Steven Schveighoffer Wrote:
  On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibsonmetalcae...@gmail.com
  
  wrote:
  Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
  On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
  
  metalcae...@gmail.com  wrote:
  Am 03.02.2011 21:48, schrieb Tomek SowiÅ„ski:
  Speaking of Tango, may I look at it? I remember that beef over the
  first
  datetime and it gives me shivers...
  
  You probably shouldn't look at the source.
  I dunno about the interface (documentation) - it's certainly not
  illegal to take
  inspiration from it, but maybe then people will again claim that
  source was
  stolen.. but when you claim that you haven't looked at the source it
  may be ok..
  
  It has been posited by Tango's developers that simply looking at the
  documentation of a D library isn't enough to understand the library,
  you probably have looked at the source.  Until they change that
  opinion, I would
  avoid even the documentation.
  
  http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
  
  The pertinent quote from there:
  
  In my opinion, claiming a clean room implementation of an API in D is
  difficult, if for no other reason that it is (due to imperfect doc
  generation
  etc) somewhat difficult to properly study a D API without at the same
  time
  reading the source (or glimpsing at it).
  
  They can claim whatever they want.. if Tomek says he only looked at the
  documentation (for an idea how a good interface for a XML lib may look
  like)
  they can hardly prove anything.
  
  This exact situation was the case of the prior-mentioned infringement
  accusation.
  
  It's sad to read how much these Tango assholes are trying to wreck the
  whole language. I doubt their implementation is any better than the high
  performance C++ libraries. I've been using RapidXML before and it's damn
  fast. My recipe for success would be: use the Boost license, do a clean
  room implementation inspired by the best C++ code, use ranges instead of
  slices or iterators, use Phobos free function and naming conventions,
  get Andrei's blessing. This will teach the Tango douchebags a lesson or
  two.
  
  They always complain about us doing NIH code. But they're forcing us!
 
 I think it's reasonable of me to ask avoiding reopening a debate that
 has little chance of being solved by emotional rhetoric.
 
 Regarding taking inspiration from Tango code, I don't know what the
 exact licensing issues are but the lesson learned during past incidents
 is clear: Phobos contributors should conservatively avoid looking at
 Tango. This is not difficult because there are many XML libraries of
 good quality and performance. So let's.

Agreed.

- Jonathan M Davis

Re: std.xml should just go


On 02/03/2011 11:10 PM, Daniel Gibson wrote:

Claiming that looking at the documentation isn't sufficient to understand how
the API works (from a users point of view, not internally) is pretty stupid:
1. it insults the modules author(s) (You're too stupid to write meaningful
documentation)
2. even if the documentation sucks one may have understood how to the API is
used by looking at code examples using it...


There is an obvious loophole in their argumentation: what if the author of the 
new lib has used the old one for years: thus perfectly understands the API from 
the client side, and certainly has a good idea of how it may well be 
implemented, even more beeing a library author (even more since client  
implementation languages are the same in this case).


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

Re: Uniform call syntax for implicit this.


On 2011-02-03 15:50:17 -0500, spir denis.s...@gmail.com said:

How can you propose this, Michel? Complexify the language, and any 
implementation, just for a non-feature that makes code very hard to 
decode, by requiring a double mental rewriting operation:

 foo(i) -- this.foo(i) -- foo(this,i)
what advantage does this feature provide? None. What additional 
drawback: see thread above.


I'm not really advocating for it. I'm just trying to figure out how it 
could be done, what impact it'd have, and what limitations should be 
put on it. This uniform call syntax has been talked a lot but never 
explored much. I think it's time we look at it so we understand the 
problems and the solutions and finally decide if its worth it or not.


What advantages should it provide? Mainly it makes member functions and 
standalone functions identical in usage, so whether something is a 
member or not becomes a implementation detail the user does not have to 
care about. Obviously, if we find out that it can't be done without 
complicating things, the feature should be abandoned.



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

Re: std.xml should just go


On 2/3/11 11:46 PM, Jonathan M Davis wrote:

[…] If they were more open and
willing to share code, then building off of what they have and turning it into a
range-based solution would likely make a lot of sense, but since that's not the
case, we need to figure it out on our own.


Just like Andrei said, I don't think this issue is worth being discussed 
over and over again, but I'm curious: Did somebody actually talk to 
»Tango« resp. the authors of its XML module concerning amendment for 
Phobos? It's needlessly fueling an »us vs. them« debate in an already 
small community of developers which drives me crazy…


David

Re: Uniform call syntax for implicit this.


On 2011-02-03 14:47:26 -0500, Jonathan M Davis jmdavisp...@gmx.com said:

I take it then that you're suggesting that the compiler automatically 
select the

member function when the conflicting free function is a separate module?


No, I haven't thought about that yet. That's one possibility, but it 
makes silent hijacking possible. Another is that the call is simply 
made ambiguous. If it's ambiguous, then you have to prefix it with the 
correct module or class name.


That said, before we go further, I think the complications (there are 
more) are far worse than the problem uniform call syntax is trying to 
solve (what problem exactly?). If D was designed with uniform call 
syntax in mind from the start, then it could probably have worked, but 
at the point we are now it's probably not that wise to change 
everything for a feature of unknown benefit.


Perhaps we should aim at something simpler...

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

Re: std.xml should just go

2011-02-03 Thread Nick Sabalausky

Gary Whatmore n...@spam.sp wrote in message 
news:iif81d$1ch8$1...@digitalmars.com...
 Steven Schveighoffer Wrote:

 On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson metalcae...@gmail.com
 wrote:

  Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
  On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
  metalcae...@gmail.com wrote:
 
  Am 03.02.2011 21:48, schrieb Tomek SowiÅski:
  Speaking of Tango, may I look at it? I remember that beef over the
  first
  datetime and it gives me shivers...
 
 
  You probably shouldn't look at the source.
  I dunno about the interface (documentation) - it's certainly not
  illegal to take
  inspiration from it, but maybe then people will again claim that
  source was
  stolen.. but when you claim that you haven't looked at the source it
  may be ok..
 
  It has been posited by Tango's developers that simply looking at the
  documentation of a D library isn't enough to understand the library, 
  you
  probably have looked at the source.  Until they change that opinion, I
  would
  avoid even the documentation.
 
  http://lists.puremagic.com/pipermail/phobos/2010-April/000370.html
 
  The pertinent quote from there:
 
  In my opinion, claiming a clean room implementation of an API in D is
  difficult, if for no other reason that it is (due to imperfect doc
  generation
  etc) somewhat difficult to properly study a D API without at the same
  time
  reading the source (or glimpsing at it).
 
 
  They can claim whatever they want.. if Tomek says he only looked at the
  documentation (for an idea how a good interface for a XML lib may look
  like)
  they can hardly prove anything.

 This exact situation was the case of the prior-mentioned infringement
 accusation.

 It's sad to read how much these Tango assholes are trying to wreck the 
 whole language. I doubt their implementation is any better than the high 
 performance C++ libraries. I've been using RapidXML before and it's damn 
 fast. My recipe for success would be: use the Boost license, do a clean 
 room implementation inspired by the best C++ code, use ranges instead of 
 slices or iterators, use Phobos free function and naming conventions, get 
 Andrei's blessing. This will teach the Tango douchebags a lesson or two.

 They always complain about us doing NIH code. But they're forcing us!


Nothing of that sort happened. One of the Tango guys was thoughtful enough 
to inform Walter of a situation that *could* be viewed by a purely 
hypothetical super-uptight third person as being potentially infringing. 
Walter is (perhaps understandably) paranoid about potential accusations so 
disallowed the code in question. This NG then exploded in speculation, and 
the Tango guys fueled that fire by being extremely reluctant to say anything 
at all about the matter. The problem was miscommunication and legal 
bullshit, *not* a good guys vs bad guys situation (if there was *any* bad 
guys side it's the court/legal system).

Re: std.xml should just go

On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger s...@klickverbot.at  
wrote:



On 2/3/11 11:46 PM, Jonathan M Davis wrote:

[…] If they were more open and
willing to share code, then building off of what they have and turning  
it into a
range-based solution would likely make a lot of sense, but since that's  
not the

case, we need to figure it out on our own.


Just like Andrei said, I don't think this issue is worth being discussed  
over and over again, but I'm curious: Did somebody actually talk to  
»Tango« resp. the authors of its XML module concerning amendment for  
Phobos? It's needlessly fueling an »us vs. them« debate in an already  
small community of developers which drives me crazy…


You are welcome to try.  I don't hold out much hope based on past.

I did not want to fuel a debate on us vs. them, Phobos and Tango can  
happily co-exist without crossing paths, I just wanted to respond Tomek to  
tread carefully based on Tango representatives' prior statements, since he  
asked.  The last thing I want to see again is someone waste effort, nobody  
likes to do that.  With the correct precautions, we don't have to go  
through this again.


I think Andrei said it best -- we can find other XML libraries to learn  
from.


-Steve

Re: D vs Go on reddit

2011-02-03 Thread Nick Sabalausky

spir denis.s...@gmail.com wrote in message 
news:mailman.1206.1296697460.4748.digitalmar...@puremagic.com...
 On 02/02/2011 10:37 PM, bearophile wrote:
 If a person looks at the history of computer languages, she sees 
 thousands of languages. Many of them were lot of work to be created, and 
 most of them have failed, over and over again. This has happened even to 
 languages better than many other languages present at their time, and 
 when you see this you get sad.

 Like in any other domain in our civilisation, the (hum) success (in 
 social sense: fame, power, money) of a programming language has exactly 
 nothing to do  with its quality.
 Actually, I rather think the opposite: that deep reasons allowing the 
 creation of a Good Thing play against its social success (could hardly 
 explain this clearly); and conversely. I would for instance blindly bet 
 1000? (or $, or £) that in, say, 18 months, Go will have reached a higher 
 level of success D will ever reach. Nothing to do with quality.
 I also bet Go not only will never be a good language, compared to other 
 modern ones in the same field, but will quickly become a big mess, and 
 worse and worse; while loads of people will sing for its fame (and more 
 and more of them, more and more loudly).


Wouldn't surprise me in the least. That's exactly what happened with Java.

Re: How to build the druntime (Windows)?

2011-02-03 Thread Sean Kelly

Don Wrote:

 Andre Tampubolon wrote:
  This is my situation: I put all the git stuffs in C:\dmd-dev.
  There are 2 subdirectories in it: dmd and druntime
  
  I managed to build dmd by make -f win32.mak
  
  Trying the same thing for druntime:
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\atomic.di src\core\atomic.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\bitop.di src\core\bitop.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\cpuid.di src\core\cpuid.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\demangle.di src\core\demangle.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\dll_helper.di 
  src\core\dll_helper.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\exception.di 
  src\core\exception.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\memory.di src\core\memory.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\runtime.di src\core\runtime.d
  dmd -c -d -o- -Isrc -Iimport -Hfimport\core\thread.di src\core\thread.d
  src\core\thread.d(1601): Error: undefined identifier malloc
  
  --- errorlevel 1
  
  Any idea?
  
 
 You're not doing anything wrong.
 
 It fails on the autotester as well:
 http://d.puremagic.com/test-results/index.ghtml
 
 This commit broke it:
 https://github.com/D-Programming-Language/druntime/commit/1449d7bd75c656cb0215d73077549c896c10163f

Sorry about that.  It should be fixed now.

Re: new documentation format for std.algorithm


On 2/3/11 6:42 PM, Jérôme M. Berger wrote:

That is because Wikipedia text *is* to small! Wikipedia has the
font size set to 80% of the default, which means that they *want*
their text to be too small. That is not a reason why we should
emulate them.


This is exactly the issue I was talking about, using relative font sizes 
in their current incarnation doesn't solve any problems per se. 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.


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…


David

Re: std.xml should just go

2011-02-03 Thread Nick Sabalausky

Steven Schveighoffer schvei...@yahoo.com wrote in message 
news:op.vqcns2egeav7ka@steve-laptop...
 On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger s...@klickverbot.at 
 wrote:

 On 2/3/11 11:46 PM, Jonathan M Davis wrote:
 [.] If they were more open and
 willing to share code, then building off of what they have and turning 
 it into a
 range-based solution would likely make a lot of sense, but since that's 
 not the
 case, we need to figure it out on our own.

 Just like Andrei said, I don't think this issue is worth being discussed 
 over and over again, but I'm curious: Did somebody actually talk 
 o  »Tango« resp. the authors of its XML module concerning amendment for 
 Phobos? It's needlessly fueling an »us vs. them« debate in an already 
 small community of developers which drives me crazy.

 You are welcome to try.  I don't hold out much hope based on past.


The main part of the problem is that Tango modules have many developers and 
*all* of the relevent contributors need to 1. be successfully contacted and 
2. give approval. That all stems purely from legal constraints (ie the 
interactions of licenses). Part two has never really been a problem, but as 
was learned, part one can be a real problem.

Re: std.xml should just go


On Thu, 03 Feb 2011 18:22:21 -0500, Nick Sabalausky a@a.a wrote:


Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.vqcns2egeav7ka@steve-laptop...

On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger s...@klickverbot.at
wrote:


On 2/3/11 11:46 PM, Jonathan M Davis wrote:

[.] If they were more open and
willing to share code, then building off of what they have and turning
it into a
range-based solution would likely make a lot of sense, but since  
that's

not the
case, we need to figure it out on our own.


Just like Andrei said, I don't think this issue is worth being  
discussed

over and over again, but I'm curious: Did somebody actually talk
o  »Tango« resp. the authors of its XML module concerning amendment for
Phobos? It's needlessly fueling an »us vs. them« debate in an already
small community of developers which drives me crazy.


You are welcome to try.  I don't hold out much hope based on past.



The main part of the problem is that Tango modules have many developers  
and
*all* of the relevent contributors need to 1. be successfully contacted  
and

2. give approval. That all stems purely from legal constraints (ie the
interactions of licenses). Part two has never really been a problem, but  
as

was learned, part one can be a real problem.


I hate to fuel this any further, but I want to re-iterate what I have  
learned.  Please re-read my summary (titled SHOO's Time code --  
conclusion) in the announce group.


I personally went through great lengths to satisfy 1.  It was 2 that was  
the problem.


Seeing that the same author who did not give approval to relicense the  
time code is an author of Tango's XML code, I doubt his views have changed.


-Steve

Re: std.xml should just go

2011-02-03 Thread %u

== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
 I hate to fuel this any further, but I want to re-iterate what I have
 learned.  Please re-read my summary (titled SHOO's Time code --
 conclusion) in the announce group.
 I personally went through great lengths to satisfy 1.  It was 2 that was
 the problem.
 Seeing that the same author who did not give approval to relicense the
 time code is an author of Tango's XML code, I doubt his views have changed.
 -Steve

With only two(or one even) off these three helping out: larsivi, kris and
stonecobra, you can get quite a bit of (older) code readable.

Re: std.xml should just go


On 2/4/11 12:30 AM, Steven Schveighoffer wrote:

I hate to fuel this any further, but I want to re-iterate what I have
learned. Please re-read my summary (titled SHOO's Time code --
conclusion) in the announce group.


Okay, sorry, I just noticed that some of the details already started to 
fade from my memory. I apologize for fueling the debate myself once 
again, let's leave it at that.


David

Re: std.xml should just go

On Thursday, February 03, 2011 15:51:10 %u wrote:
 == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
 
  I hate to fuel this any further, but I want to re-iterate what I have
  learned.  Please re-read my summary (titled SHOO's Time code --
  conclusion) in the announce group.
  I personally went through great lengths to satisfy 1.  It was 2 that was
  the problem.
  Seeing that the same author who did not give approval to relicense the
  time code is an author of Tango's XML code, I doubt his views have
  changed. -Steve
 
 With only two(or one even) off these three helping out: larsivi, kris and
 stonecobra, you can get quite a bit of (older) code readable.

Which brings us back to Andrei's point. There are plenty of other good XML 
libraries out there. We have no need to base Phobos code off of Tango. Let's 
just 
drop it and move on.

I only brought up Tango in the first place to point out that it is a goal of 
the 
new std.xml to at least come close to Tango's performance in parsing XML, 
because Tango's XML parser is very fast. It's a point which has been brought up 
before and I believe that it still holds. However, that doesn't mean that we 
need to deal with the Tango API or source code, and we definitely don't want 
any 
more debates about us vs them or any such nonsense.

Let's just move on.

- Jonathan M Davis

Re: std.xml should just go

2011-02-03 Thread %u

== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
 On Thursday, February 03, 2011 15:51:10 %u wrote:
  == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
 
   I hate to fuel this any further, but I want to re-iterate what I have
   learned.  Please re-read my summary (titled SHOO's Time code --
   conclusion) in the announce group.
   I personally went through great lengths to satisfy 1.  It was 2 that was
   the problem.
   Seeing that the same author who did not give approval to relicense the
   time code is an author of Tango's XML code, I doubt his views have
   changed. -Steve
 
  With only two(or one even) off these three helping out: larsivi, kris and
  stonecobra, you can get quite a bit of (older) code readable.
 Which brings us back to Andrei's point. There are plenty of other good XML
 libraries out there. We have no need to base Phobos code off of Tango. Let's 
 just
 drop it and move on.
 I only brought up Tango in the first place to point out that it is a goal of 
 the
 new std.xml to at least come close to Tango's performance in parsing XML,
 because Tango's XML parser is very fast. It's a point which has been brought 
 up
 before and I believe that it still holds. However, that doesn't mean that we
 need to deal with the Tango API or source code, and we definitely don't want 
 any
 more debates about us vs them or any such nonsense.
 Let's just move on.
 - Jonathan M Davis

I couldn't care less about any such debates and will not take part any of it.
As Steven Schveighoffer already contacted some of the Tango developers I thought
he might also have received a sure from one of them.. would be a waste to not 
at
least take a look at that devs code, if he exists.
But now that I reread Stevens post, he might have gotten only nos. ;)

Re: std.xml should just go

2011-02-03 Thread so


Let's just move on.


Like we could do the opposite, these tries of cooling down the sides  
quite pointless in this debate.

99.999(can continue)% of the posts about this were nothing but a monologue.

Re: std.xml should just go