Re: std.xml should just go
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
Re: std.xml should just go
On Wed, 02 Feb 2011 17:33:42 -0600, Andrei Alexandrescu wrote: > > Should we nuke it? >From orbit; it's the only way to be sure. Remove it with utter prejudice, before someone else makes the mistake of trying to use it.
Re: std.xml should just go
On Wednesday, February 02, 2011 15:33:42 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? I'm fine with that, but then again, I've never used it. Still, I see some benefit in deprecating and/or removing modules that we know that we want to replace. At _minimum_, we should really start adding module comments to such modules that say that the module is going to be replaced at a later date, so you shouldn't expect it to be usable in your code in the long term unless you copy the source. - Jonathan M Davis
Re: std.xml should just go
Andrei: > Should we nuke it? Yep. And do the same in similar situations. Bye, bearophile
Re: std.xml should just go
On 2/2/2011 3:33 PM, 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 How sure are you about the assertion? 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. This forum is, like it or not, a minority of the user base. Certainly the vocal people are the minority. I'm not against replacement, but I'd be concerned about removal before a replacement is available. Later, Brad
Re: std.xml should just go
Andrei Alexandrescu wrote: Should we nuke it? Nuke it. Old versions of Phobos are available to those who need it, and those should be very few. -- Simen
Re: std.xml should just go
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
Re: std.xml should just go
On 2/2/11 6:28 PM, Brad Roberts wrote: On 2/2/2011 3:33 PM, 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 How sure are you about the assertion? 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. This forum is, like it or not, a minority of the user base. Certainly the vocal people are the minority. It has certain bugs (http://d.puremagic.com/issues/buglist.cgi?quicksearch=xml) that seem to occur in quite common XML code (though I'm no expert) yet nobody is discussing them or voting for them. 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. Andrei
Re: std.xml should just go
On Wed, 02 Feb 2011 17:33:42 -0600, 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? Absolutely. -Lars
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: 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: 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: std.xml should just go
On Thu, 03 Feb 2011 08:33:42 +0900, 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? Good! Masahiro
Re: std.xml should just go
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. -- Tomek
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: 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
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: std.xml should just go
On Thu, 03 Feb 2011 15:48:45 -0500, 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'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: 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 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: 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
> 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
Steven Schveighoffer Wrote: > On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson > wrote: > > > Am 03.02.2011 22:26, schrieb Steven Schveighoffer: > >> On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson > >> 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 wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson 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
> wrote:
>
>> Am 03.02.2011 22:26, schrieb Steven Schveighoffer:
>>> On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson
>>> 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 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.announce&article_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: 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 > > > > wrote: > > > Am 03.02.2011 22:26, schrieb Steven Schveighoffer: > > >> On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson > > >> > > >> 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 Gibson wrote: Am 03.02.2011 22:26, schrieb Steven Schveighoffer: On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson 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 > 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.announce&article_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 Gibson > >> > >> wrote: > >>> Am 03.02.2011 22:26, schrieb Steven Schveighoffer: > On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson > > 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: 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: std.xml should just go
"Gary Whatmore" wrote in message news:iif81d$1ch8$1...@digitalmars.com... > Steven Schveighoffer Wrote: > >> On Thu, 03 Feb 2011 16:41:08 -0500, Daniel Gibson >> wrote: >> >> > Am 03.02.2011 22:26, schrieb Steven Schveighoffer: >> >> On Thu, 03 Feb 2011 16:03:55 -0500, Daniel Gibson >> >> 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 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: std.xml should just go
"Steven Schveighoffer" wrote in message news:op.vqcns2egeav7ka@steve-laptop... > On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger > 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 wrote: "Steven Schveighoffer" wrote in message news:op.vqcns2egeav7ka@steve-laptop... On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger 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
== 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
== 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 "no"s. ;)
Re: std.xml should just go
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
Steven Schveighoffer Wrote: > On Thu, 03 Feb 2011 18:22:21 -0500, Nick Sabalausky wrote: > > > "Steven Schveighoffer" wrote in message > > news:op.vqcns2egeav7ka@steve-laptop... > >> On Thu, 03 Feb 2011 17:53:24 -0500, David Nadlinger > >> 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. I think being overly correct politically is not necessary in this case. There's only one person against D now, the 'kris' or whatever his real name is. The way I see it, when Andrei came to the community, we all noticed how the better technical and leadership skills started to improve our situation. We've migrated to a more free license useable in commercial contexts unlike the viral Tango license with outrageous attribution clauses. Now instead of reinventing everything under a more closed "open" license, we can make use of commercial grade Boost licensed code. We also now have the good runtime by Sean (not kris) in D2 and naturally all better language features. TDPL is also more popular than the book by Tango developers, which is good for D. The whole Tango ship is sinking. Their most important developers have moved to the Phobos boat. Rest of them probably left D and found inferior mainstream languages. They're grown hatred towards D (which I can tell from the occasional trolling here) because of all those wasted years. Their only motivation to not open their codes is to revenge Walter. - G.W.
Re: std.xml should just go
On Thu, 03 Feb 2011 19:55:59 -0500, Gary Whatmore wrote: There are a few false statements in here, I feel like saying "I don't know this guy." I'm sorry I had to bring this up again... Tango is not evil, it is built much the same way Phobos is, from many enthusiastic developers who want to make things better. Not to mention their code is very good (I know, I wrote some of it, and I've read a lot of it). Unfortunately for us, some main contributors believe the license should not be changed (which is perfectly within their rights), and there's not much we can do about it except avoid using their code. We should just move on and forget about it. Let's see how good we can do on our own, I think we have the technical prowess to get reasonable performance in an XML library cleanly. -Steve
Re: std.xml should just go
On 03/02/2011 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 What about ... http://dsource.org/projects/xmlp well documented, well tested, reasonable speed. But I think std.xml is not the biggest problem. Problem #1 The chaotic non-managed way phobos evolves. Problem #2 Ignorance respective ignoring good stuff. What about adding BCS's units ? Problem #3 Andrei's range obsession. Andrei : Please show a pure range based implementation of, say, a Map. The basic ADT is already in place. I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern
Re: std.xml should just go
What about ... http://dsource.org/projects/xmlp well documented, well tested, reasonable speed. But I think std.xml is not the biggest problem. Problem #1 The chaotic non-managed way phobos evolves. What does that mean? Top down OOP? Problem #3 Andrei's range obsession. Andrei : Please show a pure range based implementation of, say, a Map. The basic ADT is already in place. This is wrong, having a unified (range for D) interface is necessary for many reasons, mainly composability. If you have arguments against ranges, say so we get to know them and maybe solve/replace with something better. I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. Isn't it apples to oranges? I agree on a few features D2 made mistakes but ranges not one of them. Also, you seem to favor "one paradigm (OOP) to rule them all" but at the same time against "one interface to rule them all" which is IMO more palatable comparing to the first one.
Re: std.xml should just go
Jonathan M Davis wrote: 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. The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong.
Re: std.xml should just go
Andrei Alexandrescu wrote: 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 The difficulty with that is if it's a pure input range, then the output cannot be slices of the input. * 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
Re: std.xml should just go
On 2/3/11 7:56 PM, BLS wrote: What about ... http://dsource.org/projects/xmlp well documented, well tested, reasonable speed. Cool. Is Michael Rynn willing to make a submission? But I think std.xml is not the biggest problem. Problem #1 The chaotic non-managed way phobos evolves. In recent times we have increased the number of active contributors base dramatically; we have been adding features and fixed bugs by the dozens with each release; we have improved the review process with two successful iterations (datetime and unittests); and we moved to github which further increases collaboration and contributions. Obviously there are many other ways in which we can improve phobos' evolution. Please share any ideas you might have. Problem #2 Ignorance respective ignoring good stuff. What about adding BCS's units ? Benjamin did not submit units for review. My understanding is that he is not interested in doing so, but has graciously offered the code for someone else to put it into a form appropriate for submission. Problem #3 Andrei's range obsession. Andrei : Please show a pure range based implementation of, say, a Map. The basic ADT is already in place. I don't understand this challenge. What would "pure range-based" mean? A map needs to offer iteration over its keys, values, and probably pairs of keys and values, and in addition has other primitives. The current way in which built-in associative arrays offers its keys and values (as a copy in an array) is inadequate for obvious reasons. I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern There are a few differences between D2 and D1 and it's entirely understandable that someone who enjoys D1 is not thrilled with D2. Here's a personal opinion - it may be a good time to face the notion that D1 will never make it to prime time. It is not equipped properly and it does not offer sufficient compelling advantages compared to other languages. This is an issue independent from D2. D1 does not have enough gasoline in the tank to go up the hill. On the other hand, D2 does. It has a better definition, a powerful concurrency model, true generic concepts, and a standard library to match. I believe ranges are a great idea, and not because it's mine (in fact it's rather derivative). A Phobos component that manipulates sequences is reasonably expected to work with ranges, because there's just so much infrastructure built on them. At this point there is no turning back from ranges, unless we come about with an even better idea (I discussed one with Walter but we're not pursuing it yet). Feel free to share anything you feel is lacking about ranges and better alternatives; emotional but vague characterizations are unlikely to help matters. All in all it's fair to say that if you hate ranges you're going to dislike D2, and there's little that can be done about that. Andrei
Re: std.xml should just go
On 2/3/11 9:11 PM, Walter Bright wrote: Andrei Alexandrescu wrote: 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 The difficulty with that is if it's a pure input range, then the output cannot be slices of the input. In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway. Andrei
Re: std.xml should just go
Andrei Alexandrescu wrote: On 2/3/11 9:11 PM, Walter Bright wrote: Andrei Alexandrescu wrote: 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 The difficulty with that is if it's a pure input range, then the output cannot be slices of the input. In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway. Sounds good.
Re: std.xml should just go
On 02/04/2011 01:55 AM, Gary Whatmore wrote: ... They're grown hatred towards D (which I can tell from the occasional trolling here) ... this (what you're playing) is called the game of the mirror Denis -- _ vita es estrany spir.wikidot.com
Re: std.xml should just go
> All in all it's fair to say that if you hate ranges you're going to > dislike D2, and there's little that can be done about that. > Well, you can just not use Phobos2. It's a standard library, not a mandatory library. -SiegeLord > > Andrei
Re: std.xml should just go
On 2011-02-03 22:27:08 -0500, Andrei Alexandrescu said: On 2/3/11 9:11 PM, Walter Bright wrote: Andrei Alexandrescu wrote: 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 The difficulty with that is if it's a pure input range, then the output cannot be slices of the input. In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway. The problem with parametrizing on the character width is that whether a parser parses a UTF-8 document or a UTF-16 document is determined at runtime by inspecting the document. How is the user of the parser supposed to decide in advance which to instantiate? And how the application is supposed to handle slices of different string types coming from those different parser instances? The actual low-level parser could indeed use a different instance depending on the text encoding as an optimization, but the end-user API should standardize on one string type. Unfortunately, if the XML file is not using the same text encoding as your standard string type, then you can't use slicing and have to create copies for each and every string... Another option is to use a "smart" string type that can accept strings slices of any encoding. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: std.xml should just go
On 2/3/11 11:01 PM, Michel Fortin wrote: On 2011-02-03 22:27:08 -0500, Andrei Alexandrescu said: On 2/3/11 9:11 PM, Walter Bright wrote: Andrei Alexandrescu wrote: 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 The difficulty with that is if it's a pure input range, then the output cannot be slices of the input. In that case it's fair to require sliceable ranges of characters then, or strings outright. It all boils down to stating one's assumptions and choices. Probably parameterizing on character width would be recommendable anyway. The problem with parametrizing on the character width is that whether a parser parses a UTF-8 document or a UTF-16 document is determined at runtime by inspecting the document. How is the user of the parser supposed to decide in advance which to instantiate? And how the application is supposed to handle slices of different string types coming from those different parser instances? In that case you'd want to store one specific format and convert to it in your I/O routine. Possibly you'd allow the user to choose the encoding format that best suits them. The actual low-level parser could indeed use a different instance depending on the text encoding as an optimization, but the end-user API should standardize on one string type. Unfortunately, if the XML file is not using the same text encoding as your standard string type, then you can't use slicing and have to create copies for each and every string... Another option is to use a "smart" string type that can accept strings slices of any encoding. All good points. Andrei
Re: std.xml should just go
On 02/04/2011 05:07 AM, Walter Bright wrote: Jonathan M Davis wrote: 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. The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong. .NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those.
Re: std.xml should just go
On Thursday 03 February 2011 23:17:10 Max Samukha wrote: > On 02/04/2011 05:07 AM, Walter Bright wrote: > > Jonathan M Davis wrote: > >> 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. > > > > The way to get a high performance string parser in D is to take > > advantage of one of D's unique features - slices. Java, C++, C#, etc., > > all rely on copying strings. With D you can just use slices into the > > original XML source text. If you're copying the text, you're doing it > > wrong. > > .NET and Qt do have slices of some kind: > > http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx > http://doc.qt.nokia.com/latest/qstringref.html#details > > I am not sure whether their XML libraries use those. Interesting. Slices are a rarity in C-based languages. In fact, I'd never even heard of them before I started learning D. But now it drives me nuts to not have them in C++. If I have to do much more string processing at work, I'll probably write a StringSlice class or something similar to wrap strings in just so I don't go insane. In any case, if you're not used to using slices, I'm not sure that it's the kind of thing that your average programmer is even going to think of, so it wouldn't surprise me at all if their XML libraries don't use their slicing constructs - though perhaps they do. It definitely helps that slices are built into D though. We really don't have a good excuse _not_ to use them in std.xml. Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis
Re: std.xml should just go
"Andrei Alexandrescu" wrote in message news:iifrf0$2g2q$1...@digitalmars.com... > > At this point there is no turning back from ranges, unless we come about > with an even better idea (I discussed one with Walter but we're not > pursuing it yet). Any teaser? You've got me really curious.
Re: std.xml should just go
On Thursday 03 February 2011 23:35:18 Nick Sabalausky wrote: > "Andrei Alexandrescu" wrote in message > news:iifrf0$2g2q$1...@digitalmars.com... > > > At this point there is no turning back from ranges, unless we come about > > with an even better idea (I discussed one with Walter but we're not > > pursuing it yet). > > Any teaser? You've got me really curious. They're Lone Ranges! They'll ride to your rescue! Or, maybe not... ;) But yes. That statement abouth finding something better than ranges does peek one's curiosity. Of course, Phobos is so entrenched in ranges at this point that it would probably have to be either _way_ better than ranges or similar that it would be easy to integrate it for it to go into Phobos anytime soon - which may be why it's not. - Jonathan M Davis
Re: std.xml should just go
Andrei Alexandrescu wrote: On 2/3/11 7:56 PM, BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern All in all it's fair to say that if you hate ranges you're going to dislike D2, and there's little that can be done about that. Yes, but... I think we really, really, need to work on making Phobos less daunting. Right now, we have most of the functionality. But some things are unnecessarily complicated -- some are historical, some are workarounds for compiler bugs (many of which are now fixed), some are rough edges in the language definition which could probably be fixed. We don't have many examples; many discussions and explanations assume too much familiarity with terminology and concepts from functional programming languages; and probably most importantly, we don't have tutorials. All these things can and will be fixed. But right now, the learning curve is horrible, and it's a major turnoff for people.
Re: std.xml should just go
Max Samukha wrote: .NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those. .net's slices are inadequate, because its strings are not interchangeable with slices. When they're not interchangeable, then you wind up being forced to make copies.
Re: std.xml should just go
On 2/4/11 3:15 AM, Don wrote: Andrei Alexandrescu wrote: On 2/3/11 7:56 PM, BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern All in all it's fair to say that if you hate ranges you're going to dislike D2, and there's little that can be done about that. Yes, but... I think we really, really, need to work on making Phobos less daunting. Right now, we have most of the functionality. But some things are unnecessarily complicated -- some are historical, some are workarounds for compiler bugs (many of which are now fixed), some are rough edges in the language definition which could probably be fixed. We don't have many examples; many discussions and explanations assume too much familiarity with terminology and concepts from functional programming languages; and probably most importantly, we don't have tutorials. All these things can and will be fixed. But right now, the learning curve is horrible, and it's a major turnoff for people. Absolutely. There are some major strides we have and can make, enabled by recent bug fixes and language improvements. For example a lot of things are made considerably easier by auto returns. Then I think relaxing the rules for eponymous templates would tremendously reduce code size for a variety of templates. Finally, eliminating bugs and undue limitations from the language will again allow us to simplify things a lot. With documentation and tutorials I am confident the entire community will help in time. Andrei
Re: std.xml should just go
On 02/04/2011 11:24 AM, Walter Bright wrote: Max Samukha wrote: .NET and Qt do have slices of some kind: http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx http://doc.qt.nokia.com/latest/qstringref.html#details I am not sure whether their XML libraries use those. .net's slices are inadequate, because its strings are not interchangeable with slices. When they're not interchangeable, then you wind up being forced to make copies. Right. The same applies to Qt. Whenever a QStringRef is converted to QString, a copy is made.
Re: std.xml should just go
On 02/04/2011 08:34 AM, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... What are the other ones? Denis -- _ vita es estrany spir.wikidot.com
Re: std.xml should just go
On 02/04/2011 10:15 AM, Don wrote: Andrei Alexandrescu wrote: On 2/3/11 7:56 PM, BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The smart and elegant D1 design is definitely dead an gone. I think I am not the only one who would prefer a D1 plus instead of D2. bjoern All in all it's fair to say that if you hate ranges you're going to dislike D2, and there's little that can be done about that. Yes, but... I think we really, really, need to work on making Phobos less daunting. Right now, we have most of the functionality. But some things are unnecessarily complicated -- some are historical, some are workarounds for compiler bugs (many of which are now fixed), some are rough edges in the language definition which could probably be fixed. We don't have many examples; many discussions and explanations assume too much familiarity with terminology and concepts from functional programming languages; and probably most importantly, we don't have tutorials. All these things can and will be fixed. But right now, the learning curve is horrible, and it's a major turnoff for people. I do agree. Would like to help on some of those points (eg tutorials, howtos, examples, and generally rewriting docs so that they do not assume familiarity fith FP /and/ with 99% of C++): but those points raised by Don, precisely, prevent me from getting a knowledge of D2 the language good enough to even dare thinking at such contributions. Nice clercle ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: std.xml should just go
On 02/04/2011 10:32 AM, Andrei Alexandrescu wrote: relaxing the rules for eponymous templates About that, I would love a tutorial about eponymous templates starting with their /purpose/ (why does this feature even exist? what does it /mean/? what does it compare/oppose to? why is one supposed to need/enjoy it? how is it supposed to help & make code better mirror model?) Same for alias template params. Same for a rather long list of features, probably. Moreover, said purpose should be summarized in one line introducing *every* feature in language and stdlib references. Denis -- _ vita es estrany spir.wikidot.com
Re: std.xml should just go
Max Samukha Wrote: > .NET and Qt do have slices of some kind: > > http://msdn.microsoft.com/en-us/library/1hsbd92d.aspx > http://doc.qt.nokia.com/latest/qstringref.html#details > > I am not sure whether their XML libraries use those. C# uses old good String.
Re: std.xml should just go
On 2/3/2011 10:20 PM, Andrei Alexandrescu wrote: At this point there is no turning back from ranges, unless we come about with an even better idea (I discussed one with Walter but we're not pursuing it yet). Care to elaborate on the new idea? Or at least a quick summary so we're not all left wondering?
Re: std.xml should just go
On 2/4/11, spir wrote: > > About that, I would love a tutorial about eponymous templates starting with > their /purpose/ (why does this feature even exist? what does it /mean/? what > does it compare/oppose to? why is one supposed to need/enjoy it? how is it > supposed to help & make code better mirror model?) Same for alias template > params. Same for a rather long list of features, probably. > But both of these are already explained in the manual: http://www.digitalmars.com/d/2.0/template.html (search for Implicit Template Properties) http://www.digitalmars.com/d/2.0/template.html (search for Template Alias Parameters) Granted, eponymous templates aren't explained in much detail on that page. As for explaining how they work together, I did write that short template tutorial (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but you've already seen that. :) However, I do not think we should write tutorials on single features alone. I've read a bunch of books that explain the language in feature-by-feature basis, but neglect to tie everything together. For example, "Learning Python" is this 1200 page book about Python 3, explaining the language feature by feature but never really discussing the language as a whole. It's only good as a reference, which ironically defeats the book's title. OTOH "Dive into Python 3" gradually introduces you to more features of the language, but always has code examples where you can see multiple features of the language being used. (IIRC there were string processing examples which used regex, multiple modules, and unittests all at once). Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion!
Re: std.xml should just go
spir wrote: On 02/04/2011 08:34 AM, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... What are the other ones? Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see.
Re: std.xml should just go
> Scope guard is another. Scope guard is awesome with C libs that have complicated acquire/release rules. Saves my butt. :D
Re: std.xml should just go
BLS wrote: I got more and more the feeling that the D2 monster was made just for ranges. The only range support that is actually in the language is in foreach. That can be ignored if you prefer. Unix's core structure is that everything is a file. Operations are strung together as operations on files, the output of each "filter" is fed as a file into the next one. The huge success is that so many operations are implementable as filters, and that filters can be plugged together in any order. There have been many attempts to duplicate this success in programming languages, called "component" programming. Lisp is, of course, a very early example. It accomplished this by "everything is a list", and so diverse operations on lists could all be componentized snapped together. Microsoft COM is another example, built on top of OOP. C++'s hat in that ring is iterators, and to some extent it was successful. I think C++ would be dead now if not for iterators. I'm as convinced as I can be without a decade of experience behind it, that ranges are the new paradigm for component programming. The more Phobos APIs are reworked to use ranges, the more componentized things get. I don't think we've quite reached the tipping point yet, but we're close. Although I said earlier that the only explicit range support in D2 is in foreach, a lot of the enhancements and adjustments to D2 were to better support ranges.
Re: std.xml should just go
On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright
wrote:
spir wrote:
On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
Slices: just one more reason why D's arrays kick the pants of other
languages'
arrays...
What are the other ones?
Scope guard is another.
I would argue that transitive const is, too, but the benefits of that
are harder to see.
There are many features small in detail but superb in practice.
But still, i keep saying D has design errors as well, to me the biggest
one and maybe the main reason why D1 crowd is hostile to D2.
Const system (CS):
CS in theory a great thing, in practice it has many corner cases, simply
it doesn't worth having.
D had(still has) a chance to fix this issue in two different ways, either
avoid it or don't leave holes. This hole is not that explicit in C++
because it is not transitive.
Transitive const brings something with it... transitivity!
Now, what i mean with this:
---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever; // just comparision, this function is
const
}
bool anything(A a) {
whatever = 2; // here i have an assignment, this function is
not const
return whatever;
}
}
---
It doesn't matter what signature you use for the function, compiler is
aware and will output an error when you do the opposite of the signature.
If this is the case, why do we need that signature?
Its presence just makes things complicated and with actually no reason.
---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever;
}
}
const(A) a;
A b;
bool e = a == b;
Thanks;
Re: std.xml should just go
This hole is not that explicit in C++ because it is not transitive. Ignore this line... Btw, if i made myself clear to at least one person, please let me know since this is (at least to me) very important.
Re: std.xml should just go
so wrote: It doesn't matter what signature you use for the function, compiler is aware and will output an error when you do the opposite of the signature. If this is the case, why do we need that signature? Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You'd fall back to const by convention, and that is not reliable and does not scale. You have to manually go through an entire hierarchy of function calls to figure out if one might change a member of the data structure, and then after a few maintenance cycles, you have to do that all over again. Or not, and just hope for the best (which is what happens in practice). The "why", then, is that guarantees are better than hope.
Re: std.xml should just go
Andrej Mitrovic wrote: Having a perspective on how all features tie together is crucial to understanding the purpose of individual features themselves. In my opinion! Of course, but both are necessary.
Re: std.xml should just go
so Wrote: > It doesn't matter what signature you use for the function, compiler is > aware and will output an error when you do the opposite of the signature. > If this is the case, why do we need that signature? > Its presence just makes things complicated and with actually no reason. Are you saying that having the compiler auto detect const functions is better? This has been discussed and not considered a 'hole.' By declaring the function const the compiler is able to inform you when you make a call which no longer makes this true. It does mean const will be used less then in C++, but if we just remove it that would still be the case.
Re: std.xml should just go
On 2/4/11, Walter Bright wrote: > Andrej Mitrovic wrote: >> Having a perspective on how all features tie together is crucial to >> understanding the purpose of individual features themselves. In my >> opinion! > > Of course, but both are necessary. > Well, I'm saying that you've already done your part of the job in the manual. Well at least most of it, there's a few sections missing but this was reported in bugzilla.
Re: std.xml should just go
On Fri, 04 Feb 2011 13:49:42 -0500, so wrote:
Now, what i mean with this:
---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever; // just comparision, this function is
const
}
bool anything(A a) {
whatever = 2; // here i have an assignment, this function is
not const
return whatever;
}
}
---
It doesn't matter what signature you use for the function, compiler is
aware and will output an error when you do the opposite of the
signature. If this is the case, why do we need that signature?
Its presence just makes things complicated and with actually no reason.
Actually, there are two reasons.
First, it's due to the compilation model of D. Without the signature to
convey the information, the compiler cannot make any guarantees. It is
legal to declare simply a function signature without the relevant source,
in order to link against the function. This means, the compiler does not
have access to the source, so if it doesn't have access to the source, how
does it know that the function is const or not?
Second, it has to do with the desires of the developer who's writing the
function.
Let's say you have your code, and the opEquals is treated as const due to
the implicit detection of the compiler. Now, you realize your code that
compares B types is really slow, so you want to do some sort of caching of
the data:
struct A
{
private B whatever; // changed to private for illustration purposes
private md5 previousCompare;
private bool previousCompareResult;
bool opEquals(A a)
{
md5 ah = getMd5sum(a);
if(ah != previousCompare)
{
previousCompare = ah;
previousCompareResult = (whatever == a.whatever);
}
return previousCompareResult;
}
...
}
So what does the compiler do? Well, not only would this function now
silently not be const, it silently un-consts all functions that call it.
The point is, many times, people want the compiler to tell them "hey, wait
a minute, you marked this as const, but you're trying to do non-const
things!" As it turns out, it's really useful to know "this function is
not going to change your object/struct." logically, you can make a lot of
assumptions based on that. If the compiler doesn't help you enforce that,
then stuff like the above creeps into the code, and your const expectation
is broken.
What's somewhat unfortunate is that once you mark something as const, you
have to mark all sorts of other things as const. So for example, B's
opEquals must also be const. However, if you properly mark items as const
when they really are const, this should already be the case.
The statement that "you don't need to use const if you don't want to" is
really weak. If you use D libraries, you will undoubtedly have to use
const (once const is sane and libraries start using it). But using it is
not "pointless" and does add value.
-Steve
Re: std.xml should just go
On 02/04/2011 06:33 PM, Walter Bright wrote: spir wrote: On 02/04/2011 08:34 AM, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... What are the other ones? Scope guard is another. I would argue that transitive const is, too, but the benefits of that are harder to see. Agreed. Denis -- _ vita es estrany spir.wikidot.com
Re: std.xml should just go
On 02/04/2011 07:49 PM, so wrote:
On Fri, 04 Feb 2011 19:33:09 +0200, Walter Bright
wrote:
spir wrote:
On 02/04/2011 08:34 AM, Jonathan M Davis wrote:
Slices: just one more reason why D's arrays kick the pants of other languages'
arrays...
What are the other ones?
Scope guard is another.
I would argue that transitive const is, too, but the benefits of that are
harder to see.
There are many features small in detail but superb in practice.
But still, i keep saying D has design errors as well, to me the biggest one and
maybe the main reason why D1 crowd is hostile to D2.
Const system (CS):
CS in theory a great thing, in practice it has many corner cases, simply it
doesn't worth having.
D had(still has) a chance to fix this issue in two different ways, either avoid
it or don't leave holes. This hole is not that explicit in C++ because it is
not transitive.
Transitive const brings something with it... transitivity!
Now, what i mean with this:
---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever; // just comparision, this function is const
}
bool anything(A a) {
whatever = 2; // here i have an assignment, this function is not const
return whatever;
}
}
---
It doesn't matter what signature you use for the function, compiler is aware
and will output an error when you do the opposite of the signature. If this is
the case, why do we need that signature?
Its presence just makes things complicated and with actually no reason.
---
struct A {
B whatever;
bool opEquals(A a) {
return whatever == a.whatever;
}
}
const(A) a;
A b;
bool e = a == b;
Thanks;
Runs with opEquals signature expected by the compiler:
struct A {
int whatever;
const bool opEquals(ref const(A) a) {
return whatever == a.whatever;
}
}
unittest {
const(A) a;
A b;
assert(a == b);
}
But what do you actually /mean/?
Denis
--
_
vita es estrany
spir.wikidot.com
Re: std.xml should just go
Actually, there are two reasons.
First, it's due to the compilation model of D. Without the signature to
convey the information, the compiler cannot make any guarantees. It is
legal to declare simply a function signature without the relevant
source, in order to link against the function. This means, the compiler
does not have access to the source, so if it doesn't have access to the
source, how does it know that the function is const or not?
You can solve this at linking, but i have no idea about linking process,
it would probably add overhead (data).
Second, it has to do with the desires of the developer who's writing the
function.
Let's say you have your code, and the opEquals is treated as const due
to the implicit detection of the compiler. Now, you realize your code
that compares B types is really slow, so you want to do some sort of
caching of the data:
struct A
{
private B whatever; // changed to private for illustration purposes
private md5 previousCompare;
private bool previousCompareResult;
bool opEquals(A a)
{
md5 ah = getMd5sum(a);
if(ah != previousCompare)
{
previousCompare = ah;
previousCompareResult = (whatever == a.whatever);
}
return previousCompareResult;
}
...
}
So what does the compiler do? Well, not only would this function now
silently not be const, it silently un-consts all functions that call it.
You changed the function and the new function is not working, just what
you expect.
It is not silently is it? Unlike you use "A a" instead of "const A a".
this const alone would give you all the guaranties you need.
The point is, many times, people want the compiler to tell them "hey,
wait a minute, you marked this as const, but you're trying to do
non-const things!" As it turns out, it's really useful to know "this
function is not going to change your object/struct." logically, you can
make a lot of assumptions based on that. If the compiler doesn't help
you enforce that, then stuff like the above creeps into the code, and
your const expectation is broken.
I understand the importance of the signatures, but i am trying to
understand if this is also practical. What i am saying is, indeed there
are many expectations but one thing (not necessarily the solution) is that
unless you use "const A a" having const signatures/guaranties pointless,
right?
Re: std.xml should just go
so wrote: You changed the function and the new function is not working, just what you expect. It is not silently is it? Unlike you use "A a" instead of "const A a". this const alone would give you all the guaranties you need. What would you do in the case of pointers to functions, virtual functions, functions implemented with inline assembly, and functions for which the source is not available?
Re: std.xml should just go
Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You are right, but try to look at this from another angle (probably i am not making any sense here). Should "D const" be perceived this way? When i say "const A", it broadly means don't assign to this. You'd fall back to const by convention, and that is not reliable and does not scale. You have to manually go through an entire hierarchy of function calls to figure out if one might change a member of the data structure, and then after a few maintenance cycles, you have to do that all over again. I have no idea how to solve this for documentation and such but the second you compile the source, everything will be clear as day.
Re: std.xml should just go
On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong. Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API.
Re: std.xml should just go
so wrote: Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You are right, but try to look at this from another angle (probably i am not making any sense here). Should "D const" be perceived this way? When i say "const A", it broadly means don't assign to this. That's "head const", which is what C++ has. The const system in C++ does not work. If you view const strictly as a storage class, that fails as soon as you introduce pointers. You'd fall back to const by convention, and that is not reliable and does not scale. You have to manually go through an entire hierarchy of function calls to figure out if one might change a member of the data structure, and then after a few maintenance cycles, you have to do that all over again. I have no idea how to solve this for documentation and such but the second you compile the source, everything will be clear as day. As I wrote in another reply to you, there are many cases where the compiler cannot determine this.
Re: std.xml should just go
What would you do in the case of pointers to functions, virtual functions, functions implemented with inline assembly, and functions for which the source is not available? Just like we don't know if the derived class overrides a given function, we could do something similar i suppose? Similar could be applied to functions without source, after all we don't know until linking that the provided function has the right signature. I am sorry if these doesn't make sense for a compiler writer, i have no idea about the process :)
Re: std.xml should just go
On Fri, 04 Feb 2011 15:26:07 -0500, so wrote:
Actually, there are two reasons.
First, it's due to the compilation model of D. Without the signature
to convey the information, the compiler cannot make any guarantees. It
is legal to declare simply a function signature without the relevant
source, in order to link against the function. This means, the
compiler does not have access to the source, so if it doesn't have
access to the source, how does it know that the function is const or
not?
You can solve this at linking, but i have no idea about linking process,
it would probably add overhead (data).
Yes, but that requires a custom linker/object file format. Java does
this, and D could do it, but it requires a major investment of time/effort.
Second, it has to do with the desires of the developer who's writing
the function.
Let's say you have your code, and the opEquals is treated as const due
to the implicit detection of the compiler. Now, you realize your code
that compares B types is really slow, so you want to do some sort of
caching of the data:
struct A
{
private B whatever; // changed to private for illustration purposes
private md5 previousCompare;
private bool previousCompareResult;
bool opEquals(A a)
{
md5 ah = getMd5sum(a);
if(ah != previousCompare)
{
previousCompare = ah;
previousCompareResult = (whatever == a.whatever);
}
return previousCompareResult;
}
...
}
So what does the compiler do? Well, not only would this function now
silently not be const, it silently un-consts all functions that call it.
You changed the function and the new function is not working, just what
you expect.
It is not silently is it? Unlike you use "A a" instead of "const A a".
this const alone would give you all the guaranties you need.
It is silent. This is a basic difference in philosophy. What it boils
down to is declaration vs. usage.
Let's say I *don't* use const A a anywhere, so my code just compiles, I
then release my library, and your code breaks because you do use const A
a. You might just be screwed, because I say "I don't care, I never meant
that function to be const". Now, you are stuck on an older version of the
library, or forced to make drastic changes to your code.
Conversely, if the compiler *requires* the const decoration in the
signature, your code never compiles to begin with, you can either work
around the limitation, file a bug, or use a different library. But since
the API isn't going to change, you can be sure future versions of my code
will work.
I feel the second scenario is better for all -- declare what you intend
for the API, then there are no surprises later.
-Steve
Re: std.xml should just go
On Fri, 04 Feb 2011 22:44:51 +0200, Walter Bright wrote: so wrote: Examine the API of a function in a library. It says it doesn't modify anything reachable through its arguments, but is that true? How would you know? And how would you know if the API doc doesn't say? You are right, but try to look at this from another angle (probably i am not making any sense here). Should "D const" be perceived this way? When i say "const A", it broadly means don't assign to this. That's "head const", which is what C++ has. The const system in C++ does not work. If you view const strictly as a storage class, that fails as soon as you introduce pointers. No no! I mean the way it works in D. I tried to say that: because of the semantic of C++ const, it maybe maybe a good idea to have signatures but with the semantics in D const it is not that needed.
Re: std.xml should just go
On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski wrote: On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all rely on copying strings. With D you can just use slices into the original XML source text. If you're copying the text, you're doing it wrong. Java's substring() does not copy the text, at least in the official JDK implementation. Unfortunately, it doesn't specify this behavior as part of the String API. Yes, but Java's strings are immutable. Typically a buffered I/O stream has a mutable buffer used to read data. This necessitates a copy. At the very least, you need to continue allocating more memory to hold all the strings. -Steve
Re: std.xml should just go
On 02/04/2011 09:52 PM, so wrote: What would you do in the case of pointers to functions, virtual functions, functions implemented with inline assembly, and functions for which the source is not available? Just like we don't know if the derived class overrides a given function, we could do something similar i suppose? The case is different --I mean the comparison does not hold IIUC. Virtual methods are /intended/ to be overriden, this is precisely part of their semantics. While the whole point of const-the-D-way is to ensure actual constness as marked in a given function's signature, whatever this function itself calls. The contract is such that the reader does not even need to watch further. Again, IIUC (please correct if I'm wrong on this). Denis -- _ vita es estrany spir.wikidot.com
Re: std.xml should just go
Andrej Mitrovic wrote: > On 2/4/11, spir wrote: >> >> About that, I would love a tutorial about eponymous templates starting >> with their /purpose/ (why does this feature even exist? what does it >> /mean/? what does it compare/oppose to? why is one supposed to need/enjoy >> it? how is it supposed to help & make code better mirror model?) Same for >> alias template params. Same for a rather long list of features, probably. >> > > But both of these are already explained in the manual: > http://www.digitalmars.com/d/2.0/template.html (search for Implicit > Template Properties) > http://www.digitalmars.com/d/2.0/template.html (search for Template > Alias Parameters) > > Granted, eponymous templates aren't explained in much detail on that page. > As for explaining how they work together, I did write that short > template tutorial > (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but > you've already seen that. :) > > However, I do not think we should write tutorials on single features > alone. I've read a bunch of books that explain the language in > feature-by-feature basis, but neglect to tie everything together. For > example, "Learning Python" is this 1200 page book about Python 3, > explaining the language feature by feature but never really discussing > the language as a whole. It's only good as a reference, which > ironically defeats the book's title. OTOH "Dive into Python 3" > gradually introduces you to more features of the language, but always > has code examples where you can see multiple features of the language > being used. (IIRC there were string processing examples which used > regex, multiple modules, and unittests all at once). > > Having a perspective on how all features tie together is crucial to > understanding the purpose of individual features themselves. In my > opinion! I agree, most of the 'dive into' books are excellent and complementary to reference materials. TDPL also has great little examples that illustrate the why of things, without ever becoming a mindless tutorial. It's hard to write such things however (witness the abundant amount of horrible technical writing), I truly admire those who can.
Re: std.xml should just go
The case is different --I mean the comparison does not hold IIUC. Virtual methods are /intended/ to be overriden, this is precisely part of their semantics. While the whole point of const-the-D-way is to ensure actual constness as marked in a given function's signature, whatever this function itself calls. The contract is such that the reader does not even need to watch further. Again, IIUC (please correct if I'm wrong on this). Denis Well you are thinking with the current usage. --- const int i; const A a; --- Think about these two lines. If this is a C++ code, you can't say much about their constness. But if this is a D code, you can say many things about each line and go even further and say their constness is exactly same! What i am getting at is that if we have this affinity between types and constness always a first class attribute why don't we go even further and drop the signatures all together and make constness accessible to every single D code written. Walter and Steve are talking about the contract feature we give to const signature, i am not saying it is wrong or it has lesser importance than they claim. I am just questioning if this what CS should be.
Re: std.xml should just go
On 2011-02-04 08:34, Jonathan M Davis wrote: Slices: just one more reason why D's arrays kick the pants of other languages' arrays... - Jonathan M Davis Ruby has array slices as well. A slice of an array refers to the original data just like in D. But on the other hand a new instance is created when making a slice (I assume, since everything is an object in Ruby). -- /Jacob Carlborg
