On Saturday, September 03, 2011 23:49:52 Walter Bright wrote:
> I still use printf a lot. One reason is because it is lightweight - using
> writeln blows up the size of your .obj file, making it hard to track down a
> back end bug. This is a long standing gripe I have with writeln.
Well, while tha
On 9/3/2011 10:09 PM, Steven Schveighoffer wrote:
I appreciate feedback, but I think there was a misunderstanding of what this
"review" was for. I think people thought I was proposing this as a ready-to-pull
replacement for std.stdio. That is not the case. It's very much up in the air
and under d
On Sun, 04 Sep 2011 00:30:33 -0400, Walter Bright
wrote:
On 9/3/2011 7:33 PM, Steven Schveighoffer wrote:
Please, leave all pitchforks and torches at rest for the moment :)
I know what I wrote was a bit brutal, but this needs to be settled
before we've gone so far down that path that tur
On 9/3/2011 7:33 PM, Steven Schveighoffer wrote:
Please, leave all pitchforks and torches at rest for the moment :)
I know what I wrote was a bit brutal, but this needs to be settled before we've
gone so far down that path that turning away then would be horribly unfair to you.
I think what
On Sun, 04 Sep 2011 00:06:47 -0400, Andrei Alexandrescu
wrote:
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability problems caused
by a blind toString
On Sunday, September 04, 2011 04:02:17 Andrej Mitrovic wrote:
> Seems to me like virtually every module in Phobos gets a complete
> rewrite sooner or later. Yikes! Afaik the upcoming ones are also
> std.xml, std.variant, maybe std.json too? (can't recall). Was there
> really so much bad code writte
On 9/3/2011 8:22 PM, dsimcha wrote:
However, at the time I actually thought he just hated
std.parallelism at a gut level and was looking for any excuse to keep it out of
Phobos. (I apologize for having thought this and therefore taken a much more
adversarial view of the review process than I sho
On 8/30/11 8:59 PM, Paul D. Anderson wrote:
Can someone clarify for me the status and/or direction of string
formatting in D?
[snip]
I agree there are major inefficiencies and composability problems caused
by a blind toString() that creates a whole new string without any
assistance. So we nee
On 9/3/2011 7:27 PM, dsimcha wrote:
These changes are purely under
the hood, though, and there should be zero code breakage.
Those are the great kind of changes, and it's also nice in that it means the API
was done reasonably right.
On Sat, 03 Sep 2011 23:45:17 -0400, Andrei Alexandrescu
wrote:
On 9/3/11 11:33 PM, Steven Schveighoffer wrote:
We have to break something in std.stdio, because it's fixated on FILE *.
We need something that allows FILE * to play the game, but is focused on
a D-based solution. Otherwise, we h
On Sunday, September 04, 2011 03:22:21 dsimcha wrote:
> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
>
> > I'm sure it will go up much more, but previously we've had a more
> > accepting attitude to new functionality at the cost of scrutiny (e.g.
> > std.xml and std.
On Fri, 02 Sep 2011 19:38:23 -0400, Timon Gehr wrote:
On 09/02/2011 07:46 PM, Steven Schveighoffer wrote:
It's arguable that the value of this interface is very low -- currently
it enables things like the builtin sort property on arrays (which I
think should be abolished ASAP), and allows AA's
On 9/3/11 11:33 PM, Steven Schveighoffer wrote:
We have to break something in std.stdio, because it's fixated on FILE *.
We need something that allows FILE * to play the game, but is focused on
a D-based solution. Otherwise, we have no room for improvement.
I'm not 100% convinced of that. We ca
On 9/3/11 4:40 PM, Timon Gehr wrote:
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a
On Sat, 03 Sep 2011 22:27:49 -0400, Andrei Alexandrescu
wrote:
On 9/3/11 9:53 PM, Walter Bright wrote:
On 9/3/2011 5:58 PM, Jonathan M Davis wrote:
However, if the code breakage
doesn't actually gain us anything, then we should avoid it. So,
complaints
about code breakage are valid, but the
On Saturday, September 03, 2011 18:53:00 Walter Bright wrote:
> On 9/3/2011 5:58 PM, Jonathan M Davis wrote:
> > However, if the code breakage
> > doesn't actually gain us anything, then we should avoid it. So,
> > complaints about code breakage are valid, but they aren't deal
> > breaking.
>
> Th
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> I'm sure it will go up much more, but previously we've had a more
> accepting attitude to new functionality at the cost of scrutiny (e.g.
> std.xml and std.json, both written by episodic contributors). (I really
> regret
On Sat, 03 Sep 2011 21:47:53 -0400, Andrei Alexandrescu
wrote:
On 9/3/11 3:54 PM, Andrei Alexandrescu wrote:
http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
Here are a few points following a pass through the dox:
* After thinking some more about it, I find the approach seek
On Sat, 03 Sep 2011 17:55:12 -0400, Michel Fortin
wrote:
On 2011-09-03 19:54:05 +, Andrei Alexandrescu
said:
Hello,
There are a number of issues related to D's current handling of
streams, including the existence of the imperfect etc.stream and the
over-specialization of std.st
On 9/3/11 10:02 PM, Andrej Mitrovic wrote:
Seems to me like virtually every module in Phobos gets a complete
rewrite sooner or later. Yikes! Afaik the upcoming ones are also
std.xml, std.variant, maybe std.json too? (can't recall). Was there
really so much bad code written in Phobos all along tha
On Sat, 03 Sep 2011 18:57:06 -0400, Andrej Mitrovic
wrote:
Also, changing structs to classes is gonna *massively* break code
everywhere. Why inheritance instead of a predicate like isInputStream
= is(typeof(T t; t.put; t.close)), you know the drill..
Because it breaks runtime swapping of I/
Ah, reading your post I see this is just a start of the overhaul. I
assumed this was already getting ready for a review. Names can be
fixed eventually. :)
On Sat, 03 Sep 2011 21:58:09 -0400, Steven Schveighoffer
wrote:
please read the previous comment, it includes a link to the source as well
as further explanations...
Boy, I could have planned this better...
-Steve
On Sat, 03 Sep 2011 20:47:05 -0400, Walter Bright
wrote:
What happens if I write:
printf("hello ");
writeln("world");
useCStdio();
This makes all the standard handles C-based.
And crap, I see I did not document it grr
See here:
https://github.com/schveiguy/phobos/b
On Sat, 03 Sep 2011 18:55:08 -0400, Andrej Mitrovic
wrote:
I dislike naming things with a leading "D" like "DInput". Shouldn't we
keep code that relies on C to be put in etc.c or somewhere?
I think the names are not great. The names are somewhat based on the
metamorphosis of the entire i
On Sat, 03 Sep 2011 21:23:26 -0400, Walter Bright
wrote:
On 9/3/2011 3:53 PM, dsimcha wrote:
Agreed, but in the big picture this overhaul still breaks way too much
code
without either a clear migration path or a clear argument about why
such extensive
breakage is necessary. The part abou
On 9/3/11 10:11 PM, Steven Schveighoffer wrote:
On Sat, 03 Sep 2011 17:20:53 -0400, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfe
On 9/3/11 9:53 PM, Walter Bright wrote:
On 9/3/2011 5:58 PM, Jonathan M Davis wrote:
However, if the code breakage
doesn't actually gain us anything, then we should avoid it. So,
complaints
about code breakage are valid, but they aren't deal breaking.
The larger the amount of code that is brok
== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> Seems to me like virtually every module in Phobos gets a complete
> rewrite sooner or later. Yikes! Afaik the upcoming ones are also
> std.xml, std.variant, maybe std.json too? (can't recall). Was there
> really so much bad code
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> Any overhaul of existing functionality needs to improve on existing
> functionality. Changes just to change aren't valuable. So, changes should
> generally avoiding breaking backwards compatibility unless we gain something
> from it.
I will come back with some more detailed feedback later on, but a few
nits that caught my eye:
- I don't think changing file from being a struct to a class is a good
idea. First, it breaks an awful lot of D/Phobos programs already out
there, both because of the struct->class change and becaus
On Sat, 03 Sep 2011 17:20:53 -0400, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfect etc.stream and the
over-specialization of std
Seems to me like virtually every module in Phobos gets a complete
rewrite sooner or later. Yikes! Afaik the upcoming ones are also
std.xml, std.variant, maybe std.json too? (can't recall). Was there
really so much bad code written in Phobos all along that they all
require a rewrite?
On Sat, 03 Sep 2011 15:54:05 -0400, Andrei Alexandrescu
wrote:
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std
On 9/3/2011 5:58 PM, Jonathan M Davis wrote:
However, if the code breakage
doesn't actually gain us anything, then we should avoid it. So, complaints
about code breakage are valid, but they aren't deal breaking.
The larger the amount of code that is broken, the more gain there must be to
justi
On 9/3/11 3:54 PM, Andrei Alexandrescu wrote:
http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html
Here are a few points following a pass through the dox:
* After thinking some more about it, I find the approach seek() plus
enumerated Anchor undesirable. It's a bad case of logical c
On 9/3/2011 3:53 PM, dsimcha wrote:
Agreed, but in the big picture this overhaul still breaks way too much code
without either a clear migration path or a clear argument about why such
extensive
breakage is necessary. The part about File(someFileName, someMode) is just the
first thing I noticed
On 9/4/11 3:04 AM, Andrej Mitrovic wrote:
Ooh ok. But how is it different from just using a bang? An example
would be nice there.
Imagine you have a template predicate »hasType«, which checks if the
passed expression has a type:
---
template hasType(T...) if (T.length == 1) {
enum hasType
Ooh ok. But how is it different from just using a bang? An example
would be nice there.
On Sunday, September 04, 2011 02:49:40 Marco Leise wrote:
> Am 04.09.2011, 00:57 Uhr, schrieb Andrej Mitrovic
>
> :
> > Also, changing structs to classes is gonna *massively* break code
> > everywhere. Why inheritance instead of a predicate like isInputStream
> > = is(typeof(T t; t.put; t.close)),
On 9/4/11 2:57 AM, Andrej Mitrovic wrote:
I think `not` is already in std.functional, the others look very
interesting though!
std.functional.not negates a function, my Not negates a template
predicate. Should probably make that clearer, though…
David
I think `not` is already in std.functional, the others look very
interesting though!
I should also note that I ripped these out of an existing code base
without thinking too much, feel free to ping me about any stupid
documentation, etc. oversights.
David
On 9/4/11 2:46 AM, David Nadlinger wrote:
As we currently aren't reviewing anything (We still need a review
manager for D
Am 04.09.2011, 00:57 Uhr, schrieb Andrej Mitrovic
:
Also, changing structs to classes is gonna *massively* break code
everywhere. Why inheritance instead of a predicate like isInputStream
= is(typeof(T t; t.put; t.close)), you know the drill..
Wasn't this overhaul _meant_ to break existing c
What happens if I write:
printf("hello ");
writeln("world");
?
As we currently aren't reviewing anything (We still need a review
manager for David's RegionAllocator or whatever we decide to receive
next? Do you want to get things going Jonathan? Should I do it again?
Anybody else?), I thought I would take the opportunity to ask for
comments on a few little
Also, changing structs to classes is gonna *massively* break code
everywhere. Why inheritance instead of a predicate like isInputStream
= is(typeof(T t; t.put; t.close)), you know the drill..
I dislike naming things with a leading "D" like "DInput". Shouldn't we
keep code that relies on C to be put in etc.c or somewhere?
== Quote from David Nadlinger (s...@klickverbot.at)'s article
> On 9/3/11 11:20 PM, dsimcha wrote:
> > 2. File(someFileName, someMode) needs to work. Not supporting this method
> > of
> > instantiating a File object would break way too much code.
> This one could easily be solved by aliasing Fil
On Sat, 03 Sep 2011 23:03:18 +0200, Timon Gehr wrote:
On 09/03/2011 03:12 PM, Martin Nowak wrote:
On Sat, 03 Sep 2011 11:50:25 +0200, Christophe
wrote:
void main()
{
auto foo = (int x = 10){ /* */ }
void delegate() bar = { return foo(); }
}
the compiler could in theory just automatically i
On 9/3/11 10:19 PM, jdrewsen wrote:
The (un)escape methods are located in the Protocol template and is used
for escaping strings for all of the protocols supported by libcurl. That
should be in the documentation of course.
Yes, sure – but do they add any value over the functions from std.uri?
On 9/3/11 11:20 PM, dsimcha wrote:
2. File(someFileName, someMode) needs to work. Not supporting this method of
instantiating a File object would break way too much code.
This one could easily be solved by aliasing File.open to (static) opCall().
David
Actually I'll generalize the comment I made before: As much as I like more
efficiency, I despise the massive overhaul and code breakage and the complexity
of
having a zillion tiny objects to do everything that File used to do. I would
like
to see the native I/O under the hood plus something mor
On 2011-09-03 19:54:05 +, Andrei Alexandrescu
said:
Hello,
There are a number of issues related to D's current handling of
streams, including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std.stdio whi
On 09/03/2011 11:34 AM, Jacob Carlborg wrote:
On 2011-09-02 21:11, Andrej Mitrovic wrote:
Code:
void main()
{
auto foo = (int x = 10){ /* */ };
void delegate() bar = foo;
}
Since foo takes an argument that already has a default it can be used
as a simple `void delegate()`, so maybe it makes se
On Saturday, September 03, 2011 17:03:33 Paul D. Anderson wrote:
> kenji hara Wrote:
> > 2011/8/31 Jonathan M Davis :
> > > Unfortunately however, the proposal seems to have gone nowhere thus
> > > far. Until it does, pretty much every object is just going to use
> > > toString without parameters,
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Hello,
> There are a number of issues related to D's current handling of streams,
> including the existence of the imperfect etc.stream and the
> over-specialization of std.stdio.
> Steve has worked on an extensive overha
On 09/03/2011 09:54 PM, Andrei Alexandrescu wrote:
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std.stdio which would
ob
On Sat, Sep 3, 2011 at 12:54 PM, Andrei Alexandrescu
wrote:
> Hello,
>
>
> There are a number of issues related to D's current handling of streams,
> including the existence of the imperfect etc.stream and the
> over-specialization of std.stdio.
>
> Steve has worked on an extensive overhaul of std
kenji hara Wrote:
> 2011/8/31 Jonathan M Davis :
> > Unfortunately however, the proposal seems to have gone nowhere thus far.
> > Until
> > it does, pretty much every object is just going to use toString without
> > parameters, and the problems with BigInt's toString remain. However, if the
> > p
On 09/03/2011 03:12 PM, Martin Nowak wrote:
On Sat, 03 Sep 2011 11:50:25 +0200, Christophe
wrote:
void main()
{
auto foo = (int x = 10){ /* */ }
void delegate() bar = { return foo(); }
}
the compiler could in theory just automatically insert a thunk like
this.
That sounds reasonable.
This
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a standard way to handle it, no
mainten
On Saturday, September 03, 2011 22:13:44 jdrewsen wrote:
> Den 01-09-2011 18:52, Timon Gehr skrev:
> > On 09/01/2011 06:39 PM, jdrewsen wrote:
> >> Den 01-09-2011 05:19, David Nadlinger skrev:
> >>> On 8/25/11 12:05 PM, Jonas Drewsen wrote:
> Actually would adding opCast!string() and opCast!(u
Den 01-09-2011 19:23, David Nadlinger skrev:
On 9/1/11 6:42 PM, jdrewsen wrote:
Den 31-08-2011 01:28, Sean Kelly skrev:
On Aug 17, 2011, at 6:19 PM, Jesse Phillips wrote:
Doe libcurl provide any facility for URL encoding/decoding? Or perhaps
there should be an accompanying submission for doing
Den 01-09-2011 18:52, Timon Gehr skrev:
On 09/01/2011 06:39 PM, jdrewsen wrote:
Den 01-09-2011 05:19, David Nadlinger skrev:
On 8/25/11 12:05 PM, Jonas Drewsen wrote:
Actually would adding opCast!string() and opCast!(ubyte[])() to
AsyncResult and Result allow for this?:
string content = Http.
Hello,
There are a number of issues related to D's current handling of streams,
including the existence of the imperfect etc.stream and the
over-specialization of std.stdio.
Steve has worked on an extensive overhaul of std.stdio which would
obviate the need for etc.stream and would improve
On 2011-09-03 17:45, Alex Rønne Petersen wrote:
Hi,
Imagine the following setup:
foo1.d: Compiled into a library. Has a couple of unit tests.
foo2.d: Compiled into the same library as foo1.d. Also has tests.
main.d: Dummy main function. Compiled into an executable. Links to
foo.a/.lib (produced
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a standard way to handle it, no
maintenance programmer will be confused by alias.
it need
On 9/2/11 9:52 PM, Andrej Mitrovic wrote:
On 9/3/11, Timon Gehr wrote:
Related: I think that function pointers should implicitly decay to
delegates. This would allow the compiler to optimize some delegate
literals to function pointers if they don't access the outer scope,
without breaking any c
On 9/3/11, zhang wrote:
> Maybe, std.utf.toUTF16z() can't support converting from an normal UTF16
> string in D to null-terminated string in C/C++ directly.
The new toUTFz (I'm not sure if that is the real name) in an upcoming
release will support this.
Hi,
Imagine the following setup:
foo1.d: Compiled into a library. Has a couple of unit tests.
foo2.d: Compiled into the same library as foo1.d. Also has tests.
main.d: Dummy main function. Compiled into an executable. Links to
foo.a/.lib (produced from foo1/2.d).
Assume that -unittest is pass
On 02/09/2011 20:15, Vladimir Panteleev wrote:
On Fri, 02 Sep 2011 22:07:29 +0300, Nick Sabalausky wrote:
Don't know why I never brought this up until now, but...
I know how much Andrei loves justified text, but maybe, just maybe,
it's not
such a great idea on the website's sidebar menu?:
ht
On Sat, 03 Sep 2011 11:50:25 +0200, Christophe
wrote:
void main()
{
auto foo = (int x = 10){ /* */ }
void delegate() bar = { return foo(); }
}
the compiler could in theory just automatically insert a thunk like
this.
That sounds reasonable.
This look like a library solution w
> void main()
> {
> auto foo = (int x = 10){ /* */ }
> void delegate() bar = { return foo(); }
> }
>
> the compiler could in theory just automatically insert a thunk like
> this.
That sounds reasonable.
>>> 1. provide an alias void delegate(const(char)[]) Sink; This should
>>> be in std.conv; or std.format;, because nobody wants to add it to
>>> every single module and if there is a standard way to handle it, no
>>> maintenance programmer will be confused by alias.
>>
On 2011-09-02 21:11, Andrej Mitrovic wrote:
Code:
void main()
{
auto foo = (int x = 10){ /* */ };
void delegate() bar = foo;
}
Since foo takes an argument that already has a default it can be used
as a simple `void delegate()`, so maybe it makes sense for `foo` to be
able to implicitl
> Zhang:
>
> > Project url: https://bitbucket.org/heromyth/scintillad
> > Current status: Not runnable, but compilable and debuggable.
>
> Have you found something in D/Phobos that has caused you troubles? After your
> experience do you desire something in D/Phobos to be different?
>
> Bye,
> b
> "zhang" wrote in message
> news:mailman.2638.1314964940.14074.digitalmar...@puremagic.com...
> > ScintillaD is a D port of Scintilla which is implemented in C++.
> >
> >
> > Project url: https://bitbucket.org/heromyth/scintillad
> > Current status: Not runnable, but compilable and debuggable.
>
I use VisualD as the IDE (which has two debug tools) for develop ScintillaD.
Most current bugs are caused by too much null classs objects in D which are
defined as auto variables not points in C++.
See this
http://www.digitalmars.com/d/archives/digitalmars/D/How_to_new_a_class_object_in_a_struc
On Fri, 02 Sep 2011 12:09:49 -0700, Jose Armando Garcia wrote:
> On Thu, Sep 1, 2011 at 5:57 AM, Lars T. Kyllingstad
> wrote:
>> On Wed, 31 Aug 2011 08:55:38 +, Lars T. Kyllingstad wrote:
>>
>>> I am starting in a new job on Monday, in which the primary programming
>>> language is C++. For t
80 matches
Mail list logo
