On Tuesday, 5 March 2013 at 22:38:11 UTC, Vladimir Panteleev
wrote:
By the way, I should mention that I ran into several issues
while trying to come up with the above example. The test
program does not work on Windows, for some reason I get the
exception:
std.process2.ProcessException@std\pro
On Tuesday, 5 March 2013 at 21:04:15 UTC, Vladimir Panteleev
wrote:
On Tuesday, 5 March 2013 at 20:19:06 UTC, Lars T. Kyllingstad
wrote:
A special thanks to Vladimir P. for pointing out an egregious
flaw in the original design.
But wait, there's more!
Aw, man
(please don't hurt me)
1
On Wednesday, March 06, 2013 02:44:07 Rob T wrote:
> On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
> [...]
>
> > My preference would be to completely replace the back-end with
> > LLVM. Why LLVM? Well as opposed to GCC it was designed from the
> > ground up to support many languag
Chris Cain:
I would _really_ like to see this, personally. I kind of doubt
it would happen, but I can dream...
I think Walter will keep using D to keep developing his back-end.
Not just for the reasons you listed, but because it would
potentially enable the compiler to use LLVM's JIT/interp
On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
My preference would be to completely replace the back-end with
LLVM. Why LLVM?
I would _really_ like to see this, personally. I kind of doubt it
would happen, but I can dream...
Not just for the reasons you listed, but because it w
On Tuesday, 5 March 2013 at 16:02:50 UTC, Steven Schveighoffer
wrote:
On Mon, 04 Mar 2013 21:58:57 -0500, eGust
wrote:
On Tuesday, 5 March 2013 at 02:15:33 UTC, anonymous wrote:
On Tuesday, 5 March 2013 at 02:01:47 UTC, eGust wrote:
Can I write something like this:
__gshared immutable foo
On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
[...]
My preference would be to completely replace the back-end with
LLVM. Why LLVM? Well as opposed to GCC it was designed from the
ground up to support many languages. The benefit here is that
it is possible to create standalone
On Tuesday, 5 March 2013 at 00:41:23 UTC, Andrej Mitrovic wrote:
3/5/13, Rob T wrote:
In that case it would be nice to avoid most of the class name
duplication, that's one of the things I really disliked about
C++.
I guess you meant:
class A
{
class B;
}
class A.B
{
// implementat
On Tuesday, 5 March 2013 at 20:51:02 UTC, Dicebot wrote:
As far as I get spirit of this proposal, compiler should do the
very same checks and complain on mismatch between interface and
implementation. Because it knows it is his interface, contrary
to C. And there is no sane way to avoid it in t
On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
My preference would be to completely replace the back-end with
LLVM.
+1
In addition to getting ARM and javascript (via emscripten)
output, going to LLVM brings the possibility of using its JIT to
make a REPL possible, and nice dy
On Wed, 27 Feb 2013 16:37:50 -0800, Andrei Alexandrescu
wrote:
Hello,
Walter and I have had a long conversation about the next radical thing
to do to improve D's standing. Like others in this community, we believe
it's a good time to consider bootstrapping the compiler. Having the D
c
On Tuesday, 5 March 2013 at 16:12:24 UTC, Steven Schveighoffer
wrote:
On Tue, 05 Mar 2013 03:22:00 -0500, Jonathan M Davis
wrote:
In general, a stream _is_ a range, making a lot of "stream"
stuff basically
irrelevant. What's needed then is a solid, efficient range
interface on top of
I/O
On Sunday, 24 February 2013 at 00:25:46 UTC, Jonathan M Davis
wrote:
On Saturday, February 23, 2013 16:09:43 H. S. Teoh wrote:
BTW, is "std.process2" just the temporary name, or are we
seriously
going to put in a "std.process2" into Phobos? I'm hoping the
former, as
the latter is unforgivably
On Tuesday, 5 March 2013 at 21:55:24 UTC, Steven Schveighoffer
wrote:
On Tue, 05 Mar 2013 16:04:14 -0500, Vladimir Panteleev
wrote:
4. Is there any way to deal with pipe clogging (pipe buffer
getting exceeded when manually handling both input and output
of a subprocess)? Can we query the num
On Tue, 05 Mar 2013 16:04:14 -0500, Vladimir Panteleev
wrote:
4. Is there any way to deal with pipe clogging (pipe buffer getting
exceeded when manually handling both input and output of a subprocess)?
Can we query the number of bytes we can immediately read/write without
blocking on a F
On Tuesday, 5 March 2013 at 12:40:32 UTC, Artur Skawina wrote:
One problem with string-based DSLs is scoping - they only work
properly when mixed in into the current scope.
auto c = mixin(myDSL!"a?:+:b");
mixin myDSL!("c", "a?:+:b");
mixin (myDSL!("c", "a?:+:b"));
// etc
is sometim
On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev
wrote:
On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
Perhaps then, what I think is the most significant point of
all is being missed. I can see a very clear reason why in
terms of source code, the interface and implementation
On Tuesday, 5 March 2013 at 20:19:06 UTC, Lars T. Kyllingstad
wrote:
A special thanks to Vladimir P. for pointing out an egregious
flaw in the original design.
But wait, there's more!
(please don't hurt me)
1. Typo: "plattform"
2. Is there any meaning in the idea of consolidating
spawnProce
On Tue, 05 Mar 2013 14:12:58 -0500, Dmitry Olshansky
wrote:
05-Mar-2013 22:49, Steven Schveighoffer пишет:
Everything else is read directly in (I have some heuristics to
try and prevent tiny reads, so if you want to say read 4 bytes, it will
first fill the stream buffer, then copy 4 bytes)
On Tuesday, 5 March 2013 at 20:47:11 UTC, Rob T wrote:
On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev
wrote:
Also, I don't think that we should consider that a class
declaration is the same thing as the class interface - for the
simple reason that a class declaration must also c
On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
Do you consider necessity to duplicate method signature when
overriding in descendant to be a significant code duplication
too? Because I fail to see the difference in this two case
On Tuesday, 5 March 2013 at 20:40:41 UTC, Vladimir Panteleev
wrote:
Also, I don't think that we should consider that a class
declaration is the same thing as the class interface - for the
simple reason that a class declaration must also contain
private fields and methods. Having to recompile
On Tuesday, 5 March 2013 at 19:59:13 UTC, Rob T wrote:
Perhaps then, what I think is the most significant point of all
is being missed. I can see a very clear reason why in terms of
source code, the interface and implementation must not be be
separated. Automated .di generation is a means to so
On Tuesday, 5 March 2013 at 18:00:59 UTC, H. S. Teoh wrote:
[...]
I've actually seen (and fixed) a case of two C functions that
were
declared with the same name in two different libraries, and in
one
module, the wrong library was linked in, thus linking the call
to the
wrong function, causing
On Tuesday, 5 March 2013 at 18:16:41 UTC, Dmitry Olshansky wrote:
Leverage UDAs ?
Yes that's one possible method, tagging the interface with
recognized attributes that guide the generation of the .di files.
If the generation is smart enough that we can do without, even
better.
The other
On Saturday, 23 February 2013 at 11:31:21 UTC, Lars T.
Kyllingstad wrote:
It's been years in the coming, but we finally got it done. :)
The upshot is that the module has actually seen active use over
those years, both by yours truly and others, so hopefully the
worst wrinkles are already irone
On Monday, 4 March 2013 at 06:51:15 UTC, Lars T. Kyllingstad
wrote:
On Sunday, 3 March 2013 at 11:00:52 UTC, Sönke Ludwig wrote:
Mini thing: Redirect.none is not documented
Ok, thanks!
I ended up simply removing it. There is no point in calling
pipeProcess without any redirection at all.
I curse the lack of an edit feature!
Correction of my main point:
... whatever goes in the .di should not be considered as your
"source code" because it should be auto generated from the source
(eg your .o files are not source code in the same way). If
there's ever a real reason
On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
Do you consider necessity to duplicate method signature when
overriding in descendant to be a significant code duplication
too? Because I fail to see the difference in this two cases.
I think there is a difference. For example the comp
On Tuesday, 5 March 2013 at 17:22:52 UTC, Rob T wrote:
Clearly there's a misunderstanding going on somewhere. For
example when I say "code duplication" you say "There is close
to zero code duplication." but from my POV there clearly is
code duplication and it is indeed significant and completel
05-Mar-2013 22:49, Steven Schveighoffer пишет:
On Tue, 05 Mar 2013 11:43:59 -0500, Dmitry Olshansky
wrote:
That's it.
C's iobuf stuff and locks around (f)getc are one reason for it being
slower. In D we need no stinkin' locks as stuff is TLS by default.
Plus as far as I understand your std.i
On Tue, 05 Mar 2013 11:43:59 -0500, Dmitry Olshansky
wrote:
That's it.
C's iobuf stuff and locks around (f)getc are one reason for it being
slower. In D we need no stinkin' locks as stuff is TLS by default.
Plus as far as I understand your std.io idea it was focused around
filling up u
05-Mar-2013 21:39, Rob T пишет:
On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a glance
in D!
Exactly for this reason, what about make this way at
On Tue, Mar 05, 2013 at 06:39:07PM +0100, Rob T wrote:
> On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
> >On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
> >>+1_000_000_000
> >>
> >>Yes please!
> >>It's near impossible to get a brief overview of a class at a
> >>glance in D!
> >
> >Exa
On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
Exactly for this reason, what about make this way at least the
recommended way, if
On Tuesday, 5 March 2013 at 12:20:15 UTC, Dicebot wrote:
On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
On 2013-03-05 09:48, Dicebot wrote:
I can find nothing on the topic of "separation" issue down
that link. In
fact I have never met a C/C++ programmer saying fact of
having
On Tue, Mar 05, 2013 at 01:40:19PM +0100, Artur Skawina wrote:
> On 03/05/13 00:23, H. S. Teoh wrote:
> > On Tue, Mar 05, 2013 at 12:17:06AM +0100, Marco Leise wrote:
> >> Am Mon, 04 Mar 2013 23:36:29 +0100
> >> schrieb "bearophile" :
> >>
> >>> jerro:
> >>>
> Of course, expression templates s
On Tuesday, 5 March 2013 at 14:40:57 UTC, Jacob Carlborg wrote:
On 2013-03-05 13:48, eles wrote:
True. But how does the compiler get this information if you're
using a pre compiled library and a .di file?
I imagine that a similar question was asked about the virtual
methods...
Hide that into
05-Mar-2013 20:12, Steven Schveighoffer пишет:
On Tue, 05 Mar 2013 03:22:00 -0500, Jonathan M Davis
wrote:
On Tuesday, March 05, 2013 09:14:16 BLM768 wrote:
While working on a project, I've started to realize that I miss
streams. If someone's not already working on bringing std.stream
up to s
On Tue, 05 Mar 2013 03:22:00 -0500, Jonathan M Davis
wrote:
On Tuesday, March 05, 2013 09:14:16 BLM768 wrote:
While working on a project, I've started to realize that I miss
streams. If someone's not already working on bringing std.stream
up to snuff, I think that we should start thinking ab
On Mon, 04 Mar 2013 21:58:57 -0500, eGust wrote:
On Tuesday, 5 March 2013 at 02:15:33 UTC, anonymous wrote:
On Tuesday, 5 March 2013 at 02:01:47 UTC, eGust wrote:
Can I write something like this:
__gshared immutable foo = {
auto
func1 = &fn1,
func2 = &fn2,
...
}
Or just
On 03/04/2013 04:46 PM, jerro wrote:
A bit better version:
http://codepad.org/jhbYxEgU
I think this code is good compared to the original (there are better
algorithms).
You can make it much faster even without really changing the algorithm.
Just by reversing the order of inner two loops like t
On 2013-03-05 13:48, eles wrote:
Maybe, but private variables should have nothing to do w.r.t. the
behaviour of the class, including its behaviour w.r.t. the sizeof()
operator and so on.
What compiler does know and what the user care about are different things.
True. But how does the compiler
On Tuesday, 5 March 2013 at 13:17:52 UTC, bearophile wrote:
jerro, Marco Leise, H. S. Teoh:
Of course, expression templates should also be much easier
to implement in D than they are in C++.
I don't remember seeing them implemented in D, so far.
Bye,
bearophile
Artur Skawina:
They are tr
On Monday, 4 March 2013 at 12:28:25 UTC, J wrote:
On Monday, 4 March 2013 at 08:02:46 UTC, J wrote:
That's a really good point. I wonder if there is a canonical
matrix that would be preferred?
I'm not sure if they are the recommended/best practice for
matrix handling in D at the moment (pleas
On Tuesday, 5 March 2013 at 12:19:17 UTC, Jacob Carlborg wrote:
On 2013-03-05 13:01, eles wrote:
The compiler will need to know the size of the class, for that
it needs to know the instance variables.
Maybe, but private variables should have nothing to do w.r.t. the
behaviour of the class, in
On 03/05/13 00:23, H. S. Teoh wrote:
> On Tue, Mar 05, 2013 at 12:17:06AM +0100, Marco Leise wrote:
>> Am Mon, 04 Mar 2013 23:36:29 +0100
>> schrieb "bearophile" :
>>
>>> jerro:
>>>
Of course, expression templates should also be much easier
to implement in D than they are in C++.
>>>
>>>
On Tuesday, 5 March 2013 at 12:19:17 UTC, Jacob Carlborg wrote:
The compiler will need to know the size of the class, for that
it needs to know the instance variables.
Quite an interesting problem to address, by the way. I am on the
side that it can be better addressed by providing some genera
"Iain Buclaw" wrote in message
news:mailman.235.1362482490.14496.digitalmar...@puremagic.com...
>
> I think C++ classes would be more ill to implement than what I see
> initially in that link.
>
All that pull request implements is some extended C++ mangling, for windows,
and not very well.
> M
On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
On 2013-03-05 09:48, Dicebot wrote:
I can find nothing on the topic of "separation" issue down
that link. In
fact I have never met a C/C++ programmer saying fact of having
a
separate headers is a problem, it was a loved feature if
On 2013-03-05 13:01, eles wrote:
Exactly for this reason, what about make this way at least the
recommended way, if not the single one?
You want to break every single piece of D code that uses classes?
What is to lose? As about what to win, basically each .d file will carry
its .di file (cla
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
Exactly for this reason, what about make this way at least the
recommended way, if not the single one?
What is to lose? As about what to
On Mar 5, 2013 6:56 AM, "Daniel Murphy" wrote:
>
> "David Nadlinger" wrote in message
> news:tbfgbhevqojgnawnx...@forum.dlang.org...
> >
> > Second, rewriting all of *LDC's* code in D would be a huge task, as the
> > use of C++ templates is pervasive through the LLVM C++ API (even if they
> > are
On 2013-03-05 09:48, Dicebot wrote:
I can find nothing on the topic of "separation" issue down that link. In
fact I have never met a C/C++ programmer saying fact of having a
separate headers is a problem, it was a loved feature if anything.
Problem was the way it was designed, via pre-processor.
On Monday, 4 March 2013 at 23:29:09 UTC, Araq wrote:
On Monday, 4 March 2013 at 21:58:34 UTC, Marco Leise wrote:
Am Fri, 1 Mar 2013 16:36:07 -0800
schrieb "H. S. Teoh" :
+1. With D's compile-time capabilities, DSLs give you
arbitrarily
complex custom syntax at essentially zero runtime cost. Yo
On Tuesday, 5 March 2013 at 08:08:27 UTC, Mike Parker wrote:
On Monday, 4 March 2013 at 18:27:47 UTC, cal wrote:
On Monday, 4 March 2013 at 16:28:36 UTC, D-ratiseur wrote:
Ok, thx, I've created the prototype and also tried to
dynamically
link the method. It's true that SetEndOfFile is not used
On Monday, 4 March 2013 at 23:36:18 UTC, Rob T wrote:
On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a
glance in D!
I agree it's very handy to get an overview of a class or struct
or module interf
On Monday, 4 March 2013 at 23:24:02 UTC, Rob T wrote:
One of the main selling points of the module system is to
prevent exactly what you are proposing, so I think there must
be a better solution.
Please explain. Main points of module system is to avoid
header compilation time hell and control
On Tuesday, March 05, 2013 09:14:16 BLM768 wrote:
> While working on a project, I've started to realize that I miss
> streams. If someone's not already working on bringing std.stream
> up to snuff, I think that we should start thinking about to do
> that.
> Of course, with ranges being so popular (
While working on a project, I've started to realize that I miss
streams. If someone's not already working on bringing std.stream
up to snuff, I think that we should start thinking about to do
that.
Of course, with ranges being so popular (with very good reason),
the new stream interface would p
On Monday, 4 March 2013 at 18:27:47 UTC, cal wrote:
On Monday, 4 March 2013 at 16:28:36 UTC, D-ratiseur wrote:
Ok, thx, I've created the prototype and also tried to
dynamically
link the method. It's true that SetEndOfFile is not used at all
in Phobos, that's explain well why the proto is not de
On Friday, 1 March 2013 at 18:30:34 UTC, Andrej Mitrovic wrote:
snip
Test post please ignore.
62 matches
Mail list logo
