grauzone Wrote:
Do I see correctly, that you didn't need to introduce a MOC compiler for
D? And that the Signal and Slots implementation is written in pure D?
Yes. But it is limited. No information, no dynamic invokation, different type
of connections not implemented(but this theoretically
Nick Sabalausky escribió:
Daniel Keep daniel.keep.li...@gmail.com wrote in message
news:gmg4av$dq...@digitalmars.com...
Ary Borenszweig wrote:
lol :)
Yeah, well, for a directory listing they could have shown the full tree,
but if it's too big then it's ugly, and browsing folder by folder
Thank you!
Eldar Insafutdinov wrote:
David Ferenczi Wrote:
I'm glad to see this release and the progress of qtd!
Coudl you please provide a link to the tutrial? Many thanks!
Eldar Insafutdinov wrote:
It didn't take very long after previous post to make a first
implementation of
My hero! ;)
Daniel Keep:
Of course, if we had foreach support for tuple unpacking...
double euclideanDistance(Range)(Range as, Range bs, double limit)
{
limit *= limit;
double result = 0;
foreach( a, b ; zip(as, bs, ZipStyle.EnforceLength) )
{
auto t = a.head - b.head;
Lionello Lunesu wrote:
Frits van Bommel fvbom...@remwovexcapss.nl wrote in message
news:gmeqbr$137...@digitalmars.com...
LDC on the other hand needs to emit LLVM asm, which requires it to
specify an explicit return value. My approach is a way to extract that
return value from the inline asm,
On Fri, 06 Feb 2009 14:50:58 +0100, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
Clearly, changing your name iz the eaziezt
Simen Kjaeraas wrote:
On Fri, 06 Feb 2009 14:50:58 +0100, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
Clearly, changing your
On Fri, 06 Feb 2009 12:42:30 +0100, downs wrote:
This has been brought up before as an argument against the !in operator
(forcing us to resort to such workarounds as /notin/): that the !in
operator would have inconsistent syntax with in, because in returns a
pointer and !in would return a
On Fri, Feb 6, 2009 at 8:50 AM, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
Why do people keep performing s/tt/t/ on _my_ name?
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
On Fri, Feb 6, 2009 at 11:05 AM, Don nos...@nospam.com wrote:
With the druntime project, we now have a run time which is shared between
Tango and Phobos. This is a huge step forward, but it's still not much use
without some common user code.
The highest priorities which I see are, in order:
Don wrote:
With the druntime project, we now have a run time which is shared
between Tango and Phobos. This is a huge step forward, but it's still
not much use without some common user code.
The highest priorities which I see are, in order:
(1) the C standard library
tango.stdc = std.stdc
Hm. Name for a common namespace.. How about common.
Every time you introduce a new standard namespace, a bunch of innocent
existing D programs might become invalid.
On Fri, Feb 6, 2009 at 11:54 AM, grauzone n...@example.net wrote:
Hm. Name for a common namespace.. How about common.
Every time you introduce a new standard namespace, a bunch of innocent
existing D programs might become invalid.
Every time you unify two standard libraries, a
Frits van Bommel wrote:
Lionello Lunesu wrote:
Frits van Bommel fvbom...@remwovexcapss.nl wrote in message
news:gmeqbr$137...@digitalmars.com...
LDC on the other hand needs to emit LLVM asm, which requires it to
specify an explicit return value. My approach is a way to extract
that return
Frits van Bommel wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
You're in luck. They tend to do s/ndrei/lex/ on mine :o).
Andrei
You can use several _, for instance:
scala val a = List(10,5,2,48,75,84,96,85,3,21,52)
a: List[Int] = List(10, 5, 2, 48, 75, 84, 96, 85, 3, 21, 52)
scala val b = a reduceLeft (_ + _)
b: Int = 481
The only problem is if you want to change arg order. In this case you have
to use
On Fri, 06 Feb 2009 20:23:19 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Frits van Bommel wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
You're in luck.
downs wrote:
This is NOT a reason against !in. In fact, this so-called
inconsistency is already present in the language. If we remember,
!pointer already transforms it into a boolean, so it would actually
be more consistent if !in changed the return type to bool.
I agree. 'a != b' is short
Reply to dsimcha,
I've been thinking a little about the idea of returning tuples from
functions, w.r.t. Bugzilla 2628
(http://d.puremagic.com/issues/show_bug.cgi?id=2628). Would it be
feasible to solve this by making struct[index] for any struct w/o an
opIndex overload equivalent to
On Sat, Feb 7, 2009 at 1:54 AM, grauzone n...@example.net wrote:
Hm. Name for a common namespace.. How about common.
Every time you introduce a new standard namespace, a bunch of innocent
existing D programs might become invalid.
I do in fact have a top level package called
== Quote from BCS (a...@pathlink.com)'s article
Reply to dsimcha,
I've been thinking a little about the idea of returning tuples from
functions, w.r.t. Bugzilla 2628
(http://d.puremagic.com/issues/show_bug.cgi?id=2628). Would it be
feasible to solve this by making struct[index] for any
Nicolay Korslund wrote:
The exception problem and C could be sidestepped altogether by compiling to C++ instead
of pure C. All the major console SDKs at least will compile C++. This doesn't mean we
would need to use any more C++ features like classes or templates, the result could be
pretty
== Quote from Robert Fraser (fraseroftheni...@gmail.com)'s article
Nicolay Korslund wrote:
The exception problem and C could be sidestepped altogether by compiling to
C++ instead of pure C. All the major console SDKs at least will compile C++.
This
doesn't mean we would need to use any more
Sean Kelly wrote:
== Quote from Bill Baxter (wbax...@gmail.com)'s article
On Sat, Feb 7, 2009 at 1:54 AM, grauzone n...@example.net wrote:
Hm. Name for a common namespace.. How about common.
Every time you introduce a new standard namespace, a bunch of innocent
existing D
On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly s...@invisibleduck.org wrote:
== Quote from Bill Baxter (wbax...@gmail.com)'s article
On Sat, Feb 7, 2009 at 1:54 AM, grauzone n...@example.net wrote:
Hm. Name for a common namespace.. How about common.
Every time you introduce a new
Chris Nicholson-Sauls:
My only concern is druntime turning into a third stdlib. Have to draw
a line somewhere.
The bigger core becomes, the less stuff (and code) is done in two ways in Tango
and Phobos, so I think it's good to have a larger and larger core. This third
stdlib is the common
Rainer Deyke wrote:
downs wrote:
This is NOT a reason against !in. In fact, this so-called
inconsistency is already present in the language. If we remember,
!pointer already transforms it into a boolean, so it would actually
be more consistent if !in changed the return type to bool.
I
Reply to bearophile,
Chris Nicholson-Sauls:
My only concern is druntime turning into a third stdlib. Have to
draw a line somewhere.
The bigger core becomes, the less stuff (and code) is done in two ways
in Tango and Phobos, so I think it's good to have a larger and larger
core. This third
Robert Fraser wrote:
Nicolay Korslund wrote:
The exception problem and C could be sidestepped altogether by
compiling to C++ instead of pure C. All the major console SDKs at
least will compile C++. This doesn't mean we would need to use any
more C++ features like classes or templates, the
Andrei Alexandrescu wrote:
Frits van Bommel wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
You're in luck. They tend to do s/ndrei/lex/ on mine :o).
Andrei
Has anyone
Robert Jacques wrote:
Also, the x.y.z = 10 not doing anything when y is a struct from your
other post is a well known issue is all languages that have POD struct
(As far as I know). The solution is to move x.y to a ref return
property. Moving from POD members to functions in order to support
BCS wrote:
Reply to bearophile,
Chris Nicholson-Sauls:
My only concern is druntime turning into a third stdlib. Have to
draw a line somewhere.
The bigger core becomes, the less stuff (and code) is done in two ways
in Tango and Phobos, so I think it's good to have a larger and larger
core.
downs wrote:
A large part of the case for !in is that you can pronounce it a *not
in* b. !+, on the other hand, would be .. what? a not plus b? does
that mean a - b? :)
It's a question of consistent patterns versus special cases. If
'a !op b == !(a op b)', then the parser can rewrite all 'a
Andrei Alexandrescu:
That makes it looks like a structure built on political, not technical,
foundations. Without having thought much about it, I can say it doesn't
quite sound right.
Yet, in reality politics exists, and you can't just blind yourself thinking it
doesn't exists (extensive
Jarrett Billingsley wrote:
On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly s...@invisibleduck.org wrote:
== Quote from Bill Baxter (wbax...@gmail.com)'s article
On Sat, Feb 7, 2009 at 1:54 AM, grauzone n...@example.net wrote:
Hm. Name for a common namespace.. How about common.
Every
Rainer Deyke:
It's a question of consistent patterns versus special cases.
You may think that for humans it's better to have a very orthogonal language,
like for example Scheme.
There's also a famous quote about this, Programming languages should be
designed not by piling feature on top of
Reply to Andrei,
BCS wrote:
The only things that should go in are the things that both sides can
agree on how to do.
That makes it looks like a structure built on political, not
technical, foundations. Without having thought much about it, I can
say it doesn't quite sound right.
Andrei
== Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s article
On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly s...@invisibleduck.org wrote:
druntime already has core, is there truly a need for a second top-level
namespace?
The math library almost unarguably belongs in core, since
On Sat, Feb 7, 2009 at 8:54 AM, bearophile bearophileh...@lycos.com wrote:
Rainer Deyke:
It's a question of consistent patterns versus special cases.
You may think that for humans it's better to have a very orthogonal language,
like for example Scheme.
There's also a famous quote about
Don wrote:
The irony is that's Walter's the biggest goto advocate I know, other
than Linus Torvalds.
I don't mind being compared to Linus g.
Andrei Alexandrescu wrote:
Frits van Bommel wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a fake
Why do people keep performing s/s/z/ on my name? :(
You're in luck. They tend to do s/ndrei/lex/ on mine :o).
They do s/walter/nerd/ on
Bill Baxter:
(a !in b) should exist and it should be the same as !(a in b).
Of course.
Bye,
bearophile
BCS wrote:
Reply to dsimcha,
I've been thinking a little about the idea of returning tuples from
functions, w.r.t. Bugzilla 2628
(http://d.puremagic.com/issues/show_bug.cgi?id=2628). Would it be
feasible to solve this by making struct[index] for any struct w/o an
opIndex overload
Bill Baxter wrote:
On Fri, Feb 6, 2009 at 2:30 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Walter Bright wrote:
double euclideanDistance(Range)(Range a, Range b, double limit)
{
limit *= limit;
double result = 0;
for (; 1; a.next, b.next)
{
if
Jarrett Billingsley wrote:
On Fri, Feb 6, 2009 at 11:05 AM, Donnos...@nospam.com wrote:
With the druntime project, we now have a run time which is shared between
Tango and Phobos. This is a huge step forward, but it's still not much use
without some common user code.
The highest priorities
On Fri, Feb 6, 2009 at 6:53 PM, Chad J
gamerc...@__spam.is.bad__gmail.com wrote:
Oh my, here comes another wall of text.
I'm beginning to see the Phobos/Tango split as a very advantageous thing
for D, even neglecting the benefits in terms of forcing the community
and designers to think of
Bill Baxter wrote:
Note that D already has things like !. But quoth the spec:
For floating point comparison operators, (a !op b) is *NOT* the same
as !(a op b).
[emphasis added]
I had to check the spec for the difference. 'a ! b' and '!(a b)'
/are/ equivalent in the sense that '(a ! b)
Rainer Deyke wrote:
Bill Baxter wrote:
Note that D already has things like !. But quoth the spec:
For floating point comparison operators, (a !op b) is *NOT* the same
as !(a op b).
[emphasis added]
I had to check the spec for the difference. 'a ! b' and '!(a b)'
/are/ equivalent in
Jarrett Billingsley wrote:
On Fri, Feb 6, 2009 at 6:53 PM, Chad J
gamerc...@__spam.is.bad__gmail.com wrote:
another wall of text.
I'll have to say that I wholeheartedly disagree. (You knew this was coming.)
Even if they use a common runtime and small common core, nothing is
compatible
On Sat, 07 Feb 2009 04:43:05 +0300, Jarrett Billingsley
jarrett.billings...@gmail.com wrote:
On Fri, Feb 6, 2009 at 6:53 PM, Chad J
gamerc...@__spam.is.bad__gmail.com wrote:
Oh my, here comes another wall of text.
I'm beginning to see the Phobos/Tango split as a very advantageous thing
for
Hello Jarrett,
On Fri, Feb 6, 2009 at 8:50 AM, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Tomas Lindquist Olsen wrote:
The approach Fritz mentions should still allow inlining. Having a
fake
Why do people keep performing s/s/z/ on my name? :(
Why do people keep performing s/tt/t/
Don wrote:
With the druntime project, we now have a run time which is shared
between Tango and Phobos. This is a huge step forward, but it's still
not much use without some common user code.
The highest priorities which I see are, in order:
(1) the C standard library
tango.stdc = std.stdc
(2)
Andrei Alexandrescu wrote:
BCS wrote:
Reply to bearophile,
Chris Nicholson-Sauls:
My only concern is druntime turning into a third stdlib. Have to
draw a line somewhere.
The bigger core becomes, the less stuff (and code) is done in two ways
in Tango and Phobos, so I think it's good to
Whiners, the lot of yapeople keep thinking I am female!!! Hehe.
Thanks,
Kelly Wilson
P.S. Kelly is an old Irish surname that became a boys name and then a girls
name (very popular in the late 70's for girls).
Walter Bright Wrote:
Andrei Alexandrescu wrote:
Frits van Bommel wrote:
Hello Chad,
Jarrett Billingsley wrote:
On Fri, Feb 6, 2009 at 6:53 PM, Chad J
gamerc...@__spam.is.bad__gmail.com wrote:
another wall of text.
I'll have to say that I wholeheartedly disagree. (You knew this was
coming.)
Even if they use a common runtime and small common core, nothing is
Daniel Keep wrote:
Rainer Deyke wrote:
Bill Baxter wrote:
Note that D already has things like !. But quoth the spec:
For floating point comparison operators, (a !op b) is *NOT* the same
as !(a op b).
[emphasis added]
I had to check the spec for the difference. 'a ! b' and '!(a b)'
/are/
Don pisze:
Don wrote:
With the druntime project, we now have a run time which is shared
between Tango and Phobos. This is a huge step forward, but it's still
not much use without some common user code.
The highest priorities which I see are, in order:
(1) the C standard library
tango.stdc =
Denis Koroskin wrote:
Well put, thank you. Everyone finds this situation annoying. That's the
Number One problem of the D (remember top five poll?).
The problem as I see it is that there is an overlapping functionality in
Phobos and Tango (std.stream.Stream/tango.io.Conduit etc).
The solution
Daniel Keep wrote:
Rainer Deyke wrote:
This is, in my opinion, a significant design error in the language. The
difference between '!(a b)' and 'a ! b' is not obvious. There is
nothing about the operator '' that suggests that it should set a global
exception state, and there is nothing
http://d.puremagic.com/issues/show_bug.cgi?id=2647
Summary: typedef's and struct constructors
Product: D
Version: 2.023
Platform: PC
OS/Version: All
Status: NEW
Keywords: spec
Severity: minor
Priority: P2
On Fri, 06 Feb 2009 11:25:37 +0300, d-bugm...@puremagic.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=2647
Summary: typedef's and struct constructors
Product: D
Version: 2.023
Platform: PC
OS/Version: All
Status: NEW
Don wrote:
I don't think that will ever get fixed (unless you make a patch
yourself). Phobos BigInt was created by Janice, and she seems to have
completely disappeared. I'm working on Tango BigInt, which is completely
independent, and will replace Phobos BigInt eventually. ( == as soon as
64 matches
Mail list logo
