Perhaps, in this case, it would be a better idea for part of mango to move to deimos, and for mango to be dependent on deimos.  As I understand it, mango is supposed to be a server library, however something like streams should be in a standard library, like deimos.

John

On Tue, 22 Jun 2004 21:42:04 +0000, Arcane Jill wrote:

> In article <cba3cv$8l3$1@digitaldaemon.com>, Kris says...
>>
>>Or use mango.io to do a
>>
>>FileConduit in = new FileConduit (inpName, FileStyle.ReadExisting);
>>FileConduit out = new FileConduit (outName, FileStyle.WriteTruncate);
>>
>>in.copyTo (out);
>>
>><g>
> 
> Yes, I'm convinced, mango is brilliant. But much of my work involves writing libraries rather than applications, and there are arguments both for and against any one library being dependent upon any other. If some small portion of Deimos (for example) wanted to write to a file, would it be /fair/ to users of Deimos to require them also to download and link against Mango? Should libraries be independent of each other, or should at least the best of them become intertwined.
> 
> Based on what I've seen so far, I reckon Mango ought to become /the/ streams standard for D, in which case, no problem - but at least, I need to ask the question.
> 
> Arcane Jill

"teqDruid (formerly DemmeGod)"  wrote
> Perhaps, in this case, it would be a better idea for part of mango to move to deimos, and for mango to be dependent on deimos.  As I understand it, mango is supposed to be a server library, however something like streams should be in a standard library, like deimos.

Overall, Mango has a bent towards server-side processing but can be just as useful for client-side also. A case in point is mango.io, which is an independent package from the rest of the Mango family (there's a simple dependency list over here http://svn.dsource.org/svn/projects/mango/trunk/doc/html/index.html).

Mango.io could indeed be placed into Demios without issue, if you folks feel that's the right home for it. However, the point about mixing portions of libraries is a good one: sometimes a library must expose some of it's lower layers (perhaps as method arguments, or delegate parameters), and if said lower layer uses mango.io rather than phobos.io then a user might become righteously indignant. Sometimes standards are a good thing, regardless of whatever faults they may have. One way to fix such faults is to change the standard, but doing so in a democratic manner is no easy task <g>

On the other hand, it's not uncommon to see a grass-roots shift in practice once there's enough momentum behind a particular approach. Then it becomes easy to make a choice as to which dependency you wish to live with. Getting that initial momentum going is the hard part, regardless of any underlying perceived value.

All that aside, I'm personally a big fan of plugable systems. Although the extend of an IO package and the performance factors involved can sometimes make that impractical. It can certainly be done effectively for isolated scenarios.

- Kris

In article <cbaj13$10pl$1@digitaldaemon.com>, Kris says...
>
>Mango.io could indeed be placed into Demios without issue, if you folks feel that's the right home for it. However, the point about mixing portions of libraries is a good one: sometimes a library must expose some of it's lower layers (perhaps as method arguments, or delegate parameters), and if said lower layer uses mango.io rather than phobos.io then a user might become righteously indignant. Sometimes standards are a good thing, regardless of whatever faults they may have. One way to fix such faults is to change the standard, but doing so in a democratic manner is no easy task <g>

Mango.io has some very nice design features and it may well be a candidate for Demios.  I've been trying to get stream.d up to date mostly to have an alternate technique available for comparison.  I'm interedted in seeing the pros and cons of both methods :)

Sean

"Sean Kelly" wrote
> I've been trying to get stream.d up to date

Aren't you, Ben, and Walter far too busy doing other things ? <G>

In article <cbao56$17qa$1@digitaldaemon.com>, Kris says...
>
>"Sean Kelly" wrote
>> I've been trying to get stream.d up to date
>
>Aren't you, Ben, and Walter far too busy doing other things ? <G>

Free time is overrated ;)

Sean

In article <cbaj13$10pl$1@digitaldaemon.com>, Kris says...
>
>Mango.io could indeed be placed into Demios without issue, if you folks feel that's the right home for it. However, the point about mixing portions of libraries is a good one: sometimes a library must expose some of it's lower layers (perhaps as method arguments, or delegate parameters), and if said lower layer uses mango.io rather than phobos.io then a user might become righteously indignant. Sometimes standards are a good thing, regardless of whatever faults they may have. One way to fix such faults is to change the standard, but doing so in a democratic manner is no easy task <g>

While moving mango.io to Deimos is certainly possible, it wouldn't be my first choice. My first choice would be that mango.io is moved to *PHOBOS*. D absolutely requires a serious and well thought out streams package AS STANDARD.

Now, Deimos is kind of a testing ground for Phobos-wannabes. I don't imagine there's anything in Deimos/etc that wouldn't rather be in Phobos/std, but obviously we accept that things have to be "out there in the field" for a while, getting a good testing, getting all the bugs fixed, and so on. You wouldn't want something in Phobos unless it had passed that test. But the thing about mango.io is - it has ALREADY passed that test. It has been out there, in the field, for some time now; all the major bugs have been found and fixed; no-one is planning any reorganization of mango.io in the near future; the class and function names are not going to change. In short, it is stable.

What can I say? It's a question of power. Only Walter (so far as I know) has the power to move things to Phobos, but anyone can move things to Deimos.

But maybe it's also a question of organization. Maybe mango.io could divorce itself from the rest of Mango and move to Deimos for now (in which case everything else in Deimos will be able to call it without worrying about requiring additional libraries, which would certainly be great). But Deimos itself is nothing special - it's just another library, and there are plenty of them around. True, it's a library full of things that would rather be in Phobos, but Mango already has credibility in its own right. On the other hand, I'd be reluntant to download/import/link against a whole server package, if all I wanted to do was to open a file.

Let's be honest here - there are SERIOUS problems with std.stream. It is absurd
that calling new File(filename, FileMode.Out) will not delete (truncate) an old
file of the same name. It is absurd that, if you want to do this, you require
two statements: f = new File(); f.create(...);. It is absurd that if you want to
wrap this in a BufferedStream, you have to call create() /before/ you construct
the buffered stream (because BufferedStream has no create() function). And it is
pretty damn annoying that if you continually read from a BufferedStream which
buffers a File, using the readLine() function, then there appears to be no way
to distinguish between an empty line and end-of-file (they both return null, and
no exceptions are thrown). Why is there no Stream.eof() function? Please - let's
just replace it with something that JUST WORKS (and is actually documented).

So, personally, I think Walter should simply make us all happy by adding mango.io to Phobos (possibly renaming it to std.io en route) and deprecating std.stream. Failing that, moving mango.io to Deimos (etc.io ?) would be my second choice.

Arcane Jill

In article <cbc1t0$6h7$1@digitaldaemon.com>, Arcane Jill says...
>
>Let's be honest here - there are SERIOUS problems with std.stream. It is absurd
>that calling new File(filename, FileMode.Out) will not delete (truncate) an old
>file of the same name. It is absurd that, if you want to do this, you require
>two statements: f = new File(); f.create(...);. It is absurd that if you want to
>wrap this in a BufferedStream, you have to call create() /before/ you construct
>the buffered stream (because BufferedStream has no create() function). And it is
>pretty damn annoying that if you continually read from a BufferedStream which
>buffers a File, using the readLine() function, then there appears to be no way
>to distinguish between an empty line and end-of-file (they both return null, and
>no exceptions are thrown). Why is there no Stream.eof() function? Please - let's
>just replace it with something that JUST WORKS (and is actually documented).

I'm in the process of fixing all of this... just got bogged down writing a real ANSI compliant version of scanf (in my hour or two of free coding time per day). I agree that Mango.io is quite nice, but I don't want it to be chosen simply because there's nothing else comparable.

One thing I haven't addressed in stream.d and an area that Mango is also deficient is localized formatted i/o.  This perhaps isn't a requirement for 1.0, but it would be nice to see some discussion of what we may need in this area among folks who know.  Numeric formatting is pretty easy, but that still leaves character transcoding, doesn't it?

Sean

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cbc1t0$6h7$1@digitaldaemon.com...
> In article <cbaj13$10pl$1@digitaldaemon.com>, Kris says...
> >
> >Mango.io could indeed be placed into Demios without issue, if you folks
feel
> >that's the right home for it. However, the point about mixing portions of libraries is a good one: sometimes a library must expose some of it's
lower
> >layers (perhaps as method arguments, or delegate parameters), and if said lower layer uses mango.io rather than phobos.io then a user might become righteously indignant. Sometimes standards are a good thing, regardless
of
> >whatever faults they may have. One way to fix such faults is to change
the
> >standard, but doing so in a democratic manner is no easy task <g>
>
> While moving mango.io to Deimos is certainly possible, it wouldn't be my
first
> choice. My first choice would be that mango.io is moved to *PHOBOS*. D absolutely requires a serious and well thought out streams package AS
STANDARD.
>
> Now, Deimos is kind of a testing ground for Phobos-wannabes. I don't
imagine
> there's anything in Deimos/etc that wouldn't rather be in Phobos/std, but obviously we accept that things have to be "out there in the field" for a
while,
> getting a good testing, getting all the bugs fixed, and so on. You
wouldn't want
> something in Phobos unless it had passed that test. But the thing about
mango.io
> is - it has ALREADY passed that test. It has been out there, in the field,
for
> some time now; all the major bugs have been found and fixed; no-one is
planning
> any reorganization of mango.io in the near future; the class and function
names
> are not going to change. In short, it is stable.
>
> What can I say? It's a question of power. Only Walter (so far as I know)
has the
> power to move things to Phobos, but anyone can move things to Deimos.
>
> But maybe it's also a question of organization. Maybe mango.io could
divorce
> itself from the rest of Mango and move to Deimos for now (in which case everything else in Deimos will be able to call it without worrying about requiring additional libraries, which would certainly be great). But
Deimos
> itself is nothing special - it's just another library, and there are
plenty of
> them around. True, it's a library full of things that would rather be in
Phobos,
> but Mango already has credibility in its own right. On the other hand, I'd
be
> reluntant to download/import/link against a whole server package, if all I wanted to do was to open a file.


> Let's be honest here - there are SERIOUS problems with std.stream.

I don't know why std.stream is such a whipping boy, but I'll throw in my 2 cents:

> It is absurd
> that calling new File(filename, FileMode.Out) will not delete (truncate)
an old
> file of the same name. It is absurd that, if you want to do this, you
require
> two statements: f = new File(); f.create(...);.

seems easy enough to fix. I haven't played around with possible solutions but it would require changing just a few lines of code - possibly adding an optional input to the constructor to truncate or another FileMode or something.

> It is absurd that if you want to
> wrap this in a BufferedStream, you have to call create() /before/ you
construct
> the buffered stream (because BufferedStream has no create() function).

I'm not sure what a BufferedStream create() function would do. Do you mean
BufferedFile?

> And it is
> pretty damn annoying that if you continually read from a BufferedStream
which
> buffers a File, using the readLine() function, then there appears to be no
way
> to distinguish between an empty line and end-of-file (they both return
null, and
> no exceptions are thrown). Why is there no Stream.eof() function?

Stream.eof() exists.

> Please - let's
> just replace it with something that JUST WORKS (and is actually
documented).

Improving the doc would be nice.

> So, personally, I think Walter should simply make us all happy by adding mango.io to Phobos (possibly renaming it to std.io en route) and
deprecating
> std.stream. Failing that, moving mango.io to Deimos (etc.io ?) would be my
> second choice.
>
> Arcane Jill
>
>

"Sean Kelly" wrote
> One thing I haven't addressed in stream.d and an area that Mango is also deficient is localized formatted i/o.  This perhaps isn't a requirement
for 1.0,
> but it would be nice to see some discussion of what we may need in this
area
> among folks who know.  Numeric formatting is pretty easy, but that still
leaves
> character transcoding, doesn't it?

I wholeheartedly agree. Didn't Ben post something about Perl formatting? I think the combination of what Ben mentioned together with char transcoding would be a great thing for any IO package.

Note that mango.io is also completely deficient regarding unicode. There were too many unknowns at the time of writing, so it was left out until a more formal approach could be introduced. Thanks to Hauke and AJ, the latter appears to be happening (and mango.io will probably integrate their work as an additional flavour of Reader & Writer).

In general, how would people like to see formatted IO operate? What about Ben's idea? How should the upcoming unicode library operate within formatted IO? Or should it?

"Ben Hinkle" wrote
> I don't know why std.stream is such a whipping boy

I hope that's not the case, but the two certainly have alternate approaches. I don't understand it, but that can sometimes cause heated debate on this NG :-)

Personally, I feel std.stream and mango.io are very different animals ~ as such it's hard to compare and contrast. Perhaps it might be useful to clarify what some of the notions are/were behind mango.io, such that any further discussion might be more finely tuned?