On 9/8/11 1:28 PM, Marco Leise wrote:
> Am 08.09.2011, 18:52 Uhr, schrieb Simen Kjaeraas <simen.kjaras@gmail.com>:
>
>> On Thu, 08 Sep 2011 11:40:01 +0200, Sean Cavanaugh
>> <WorksOnMyMachine@gmail.com> wrote:
>>
>>> In the COM based land for D3D, there is just a number tacked onto the
>>> class name. We are up to version 11 (e.x. ID3D11Device). It works
>>> well and is definitely nicer once you are used to it, than calling
>>> everything New or FunctionEx, and left wondering what to do when you
>>> rev the interface again
>>
>> In the case of D3D though, D3D itself has a version number. The next
>> version
>> of std.xml will not be parsing XMLv2.0. When a version 2.0 of the XML
>> spec
>> shows up, what do we do about std.xml2, which parses version 1.1? And
>> what
>> do we call the new one? Should std.xml3 parse XMLv2.0?
>
> That is late in the discussion, but a valid point.

Waiting for a suggestion from the XML experts.

Andrei

On 9/8/11 2:02 PM, Jonathan M Davis wrote:
> I think that it makes perfect sense to use enums for flags. What I don't think
> makes sense is making the type of the variable which holds the flags to be that
> enum type unless _every_ possible combination of flags has its own flag so that
> &ing or |ing enums always results in a valid enum.

This ain't going to work because it would require the human user to write by hand a combinatorial number of symbols.

A ligthweight fixed-sized set with named members is a worthy abstraction for the standard library.


Andrei

On Thursday, September 08, 2011 15:04:56 Andrei Alexandrescu wrote:
> On 9/8/11 2:02 PM, Jonathan M Davis wrote:
> > I think that it makes perfect sense to use enums for flags. What I don't think makes sense is making the type of the variable which holds the flags to be that enum type unless _every_ possible combination of flags has its own flag so that &ing or |ing enums always results in a valid enum.
> 
> This ain't going to work because it would require the human user to write by hand a combinatorial number of symbols.
> 
> A ligthweight fixed-sized set with named members is a worthy abstraction for the standard library.

I agree. I'm not arguing that the user _should_ create such a combination of flags. That would be horrible. I'm just arguing that having a set of flags with enums, e.g.

enum Flag { a = 1, b = 2, c = 4, d = 8 };

and then having Flag.a | Flag.b or Flag.a & Flag.b result in a value of type Flag is not a good idea, because the result isn't a valid Flag. It should result in whatever the base type is (int in this case), and functions which take such flags &ed or |ed should take them using the base type, not the enum type.

- Jonathan M Davis

On 08/09/2011 21:02, Andrei Alexandrescu wrote:
> On 9/8/11 1:28 PM, Marco Leise wrote:
>> Am 08.09.2011, 18:52 Uhr, schrieb Simen Kjaeraas
>> <simen.kjaras@gmail.com>:
>>
>>> On Thu, 08 Sep 2011 11:40:01 +0200, Sean Cavanaugh
>>> <WorksOnMyMachine@gmail.com> wrote:
>>>
>>>> In the COM based land for D3D, there is just a number tacked onto the
>>>> class name. We are up to version 11 (e.x. ID3D11Device). It works
>>>> well and is definitely nicer once you are used to it, than calling
>>>> everything New or FunctionEx, and left wondering what to do when you
>>>> rev the interface again
>>>
>>> In the case of D3D though, D3D itself has a version number. The next
>>> version
>>> of std.xml will not be parsing XMLv2.0. When a version 2.0 of the XML
>>> spec
>>> shows up, what do we do about std.xml2, which parses version 1.1? And
>>> what
>>> do we call the new one? Should std.xml3 parse XMLv2.0?
>>
>> That is late in the discussion, but a valid point.
>
> Waiting for a suggestion from the XML experts.
>
> Andrei

I'm not really an XML expert, but I do recall that the XML Core Working Group shelved there plans to develop "XML2.0". All enhancements that are in the pipeline are separate projects with their own acronyms.

IMHO, even if there were an XML2.0 spec, I don't think it would effect the naming of the module in Phobos, because I doubt very much it would introduce anything that would require a complete rewrite. std.xml2 could just be extended to support the new features of the spec in the context of its existing architecture. But it is probably a moot point.

A...

On 09/08/2011 10:33 PM, Jonathan M Davis wrote:
> On Thursday, September 08, 2011 15:04:56 Andrei Alexandrescu wrote:
>> On 9/8/11 2:02 PM, Jonathan M Davis wrote:
>>> I think that it makes perfect sense to use enums for flags. What I don't
>>> think makes sense is making the type of the variable which holds the
>>> flags to be that enum type unless _every_ possible combination of flags
>>> has its own flag so that&ing or |ing enums always results in a valid
>>> enum.
>>
>> This ain't going to work because it would require the human user to
>> write by hand a combinatorial number of symbols.
>>
>> A ligthweight fixed-sized set with named members is a worthy abstraction
>> for the standard library.
>
> I agree. I'm not arguing that the user _should_ create such a combination of
> flags. That would be horrible. I'm just arguing that having a set of flags with
> enums, e.g.
>
> enum Flag { a = 1, b = 2, c = 4, d = 8 };
>
> and then having Flag.a | Flag.b or Flag.a&  Flag.b result in a value of type
> Flag is not a good idea, because the result isn't a valid Flag. It should
> result in whatever the base type is (int in this case), and functions which
> take such flags&ed or |ed should take them using the base type, not the enum
> type.
>
> - Jonathan M Davis

+1.

On Thu, 08 Sep 2011 17:34:50 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 09/08/2011 10:33 PM, Jonathan M Davis wrote:
>> On Thursday, September 08, 2011 15:04:56 Andrei Alexandrescu wrote:
>>> On 9/8/11 2:02 PM, Jonathan M Davis wrote:
>>>> I think that it makes perfect sense to use enums for flags. What I don't
>>>> think makes sense is making the type of the variable which holds the
>>>> flags to be that enum type unless _every_ possible combination of flags
>>>> has its own flag so that&ing or |ing enums always results in a valid
>>>> enum.
>>>
>>> This ain't going to work because it would require the human user to
>>> write by hand a combinatorial number of symbols.
>>>
>>> A ligthweight fixed-sized set with named members is a worthy abstraction
>>> for the standard library.
>>
>> I agree. I'm not arguing that the user _should_ create such a combination of
>> flags. That would be horrible. I'm just arguing that having a set of flags with
>> enums, e.g.
>>
>> enum Flag { a = 1, b = 2, c = 4, d = 8 };
>>
>> and then having Flag.a | Flag.b or Flag.a&  Flag.b result in a value of type
>> Flag is not a good idea, because the result isn't a valid Flag. It should
>> result in whatever the base type is (int in this case), and functions which
>> take such flags&ed or |ed should take them using the base type, not the enum
>> type.
>>
>> - Jonathan M Davis
>
> +1.

I could go either way on this.  On one hand, it's nice to say "this is a bitfield, and the compiler will force you to use my enumeration constants to build it", and on the other hand, anyone who passes in integers (especially something non-hex or non-binary like 12345) is asking for code-review rejection ;)

I did use an enumeration argument that included a single bit which could be or'd in the stdio overhaul.  It was still verifying the enum was valid in the contract, so it just as easily could be uint (or maybe it was ubyte?).  I don't suppose the type checking is all that critical.

-Steve

On 2011-09-08 21:54, Steven Schveighoffer wrote:
> On Thu, 08 Sep 2011 15:38:43 -0400, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-09-08 15:22, Steven Schveighoffer wrote:
>>> On Thu, 08 Sep 2011 09:16:40 -0400, Jacob Carlborg <doob@me.com> wrote:
>>>> The Tango XML parser doesn't read from a file, it takes the input as a
>>>> string. The parser isn't affected by I/O at all.
>>>
>>> So you have to read the entire file before sending it to the parser?
>>>
>>> Isn't that a bit limited? What if I have a 50MB file, I have to read it
>>> into a continuous memory block first?
>>>
>>> -Steve
>>
>> I'm just telling how Tango currently works, not how the XML module in
>> Phobos should work. But I guess it might be somewhat limited. 50MB
>> isn't that big to read into memory?
>
> Um... yeah, it is :) I have 1 GB of memory, my system starts thrashing
> with an app that consumes 750MB. So that's like 13 xml files read?
> Especially if I want to use DOM, I have to keep them around...

50MB is far from 750MB :), but I see your point.

> Not to mention that the GC has to allocate a contiguous space for it. So
> even if I have 100MB of garbage space, maybe none of it is usable, I
> still have to allocate a new block. I'm just surprised there isn't at
> least an option for a stream-based xml parser in Tango.
>
> One thing this does though, I always assumed it was Tango's I/O that
> accounts for its xml superiority. I wonder, does anyone count reading
> the file in any of the benchmarks?

As far as I know it's because of two reasons: it doesn't allocate any memory (uses slices) and all methods are final.

I have no idea about the benchmarks.

> I still think we can come close without having to pre-read an entire file.

I hope so as well.

>> I think it would be nice to be able to do both. If you read the whole
>> file before sending it to the parser you would know it doesn't perform
>> any I/O operations.
>
> I totally agree. I think there's ways to abstract the functionality for
> both memory-based and device-based i/o into one interface (part of the
> reason for the revamp).
>
> -Steve

A ranged based API as Jonathan and others have said.

-- 
/Jacob Carlborg