Justin Johansson schrieb:
> I'm just wondering for a moment if D might be a good vehicle for
> developing a browser extension for Firefox, or any other browser for
> that matter.
>
> Has anyone either considered doing, or has actually done, any browser
> extension development with D and have some
Sean Kelly wrote:
Walter Bright Wrote:
Mixing D's gc world with manually managed memory isn't hard, as
long as the following rules are followed:
1. don't allocate in one language and expect to free in another 2.
keep a 'root' to all gc allocated data in the D side of the fence
(otherwise it ma
Walter Bright Wrote:
>
> Mixing D's gc world with manually managed memory isn't hard, as long as
> the following rules are followed:
>
> 1. don't allocate in one language and expect to free in another
> 2. keep a 'root' to all gc allocated data in the D side of the fence
> (otherwise it may get
Justin Johansson wrote:
> Ellery Newcomer wrote:
>> Ellery Newcomer wrote:
>>> Bill Baxter wrote:
Yes, Yigal said basically that. The question I have is what practical
difference does that make to the language?
Seems no different from defining the empty tuple to be void, then
r
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 3:57 PM, retard wrote:
Tue, 17 Nov 2009 14:38:57 -0800, Bill Baxter wrote:
I agree, a tuple of one element (doesn't matter what type, array in
this case) should be semantically identical to that single element.
proper semantics for language supporte
Nick Sabalausky wrote:
"Justin Johansson" wrote in message
news:hdvrmr$215...@digitalmars.com...
I'm just wondering for a moment if D might be a good vehicle for
developing a browser extension for Firefox, or any other browser for that
matter.
Has anyone either considered doing, or has actua
Nick Sabalausky wrote:
"Justin Johansson" wrote in message
news:hdvrmr$215...@digitalmars.com...
I'm just wondering for a moment if D might be a good vehicle for
developing a browser extension for Firefox, or any other browser for that
matter.
Has anyone either considered doing, or has actua
"Justin Johansson" wrote in message
news:hdvrmr$215...@digitalmars.com...
> I'm just wondering for a moment if D might be a good vehicle for
> developing a browser extension for Firefox, or any other browser for that
> matter.
>
> Has anyone either considered doing, or has actually done, any br
I'm just wondering for a moment if D might be a good vehicle for
developing a browser extension for Firefox, or any other browser for
that matter.
Has anyone either considered doing, or has actually done, any browser
extension development with D and have some thoughts or experience to share?
Nick Sabalausky wrote:
"AJ" wrote in message news:hdr79b$1cm...@digitalmars.com...
Tim Matthews wrote:
AJ wrote:
Is D about to go commercial?
D is not intended as a scam for someones profit
Oh? Is it the current direction. Oh, yeah, bill gates is stupid (I think
so).
That came strai
The use of version(...) in D has the potential for some very elegant
portable code design. However, from most of the libraries I have seen,
it is abused and misused turning it into a portability nightmare.
http://dsource.org/projects/dmd/browser/trunk/src/mars.c#L313 defines
the following ver
Bartosz Milewski wrote:
Walter Bright Wrote:
BCS wrote:
would you agree that it is not something the programer can predict in
advance?
He can, but it is not reasonable to expect him to. But it's still
deterministic.
I've been following this discussion about determinism and I think it addres
dsimcha wrote:
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
dsimcha Wrote:
The one thing that I think has been missing from this discussion is, what would
be
the alternative if we didn't have this "non-deterministic" reallocation? How
else
could you **efficiently**
Bill Baxter wrote:
It's pretty common to see bits of a namespace get spread across many files.
There's no way to do that in D. But I wouldn't go so far as to say
it's a necessity.
Yeah, Andrei and I talked about that and if it was a worthwhile
capability. We decided it was a misfeature in tha
On Tue, 17 Nov 2009 18:34:32 -0500, retard wrote:
Tue, 17 Nov 2009 15:04:01 -0800, Bill Baxter wrote:
On Tue, Nov 17, 2009 at 2:53 PM, Robert Jacques
*sigh* The reason the compiler would have to create a temporary struct,
is because that's what a tuple is at runtime. Tuples need to be compa
Ellery Newcomer wrote:
Ellery Newcomer wrote:
Bill Baxter wrote:
Yes, Yigal said basically that. The question I have is what practical
difference does that make to the language?
Seems no different from defining the empty tuple to be void, then
renaming void to unit.
--bb
If you have unit di
On Tue, Nov 17, 2009 at 4:58 PM, Ellery Newcomer
wrote:
> Bill Baxter wrote:
>>
>> Yes, Yigal said basically that. The question I have is what practical
>> difference does that make to the language?
>> Seems no different from defining the empty tuple to be void, then
>> renaming void to unit.
>>
On Tue, Nov 17, 2009 at 4:38 PM, Bartosz Milewski
wrote:
> Walter Bright Wrote:
>
>> BCS wrote:
>> > would you agree that it is not something the programer can predict in
>> > advance?
>>
>> He can, but it is not reasonable to expect him to. But it's still
>> deterministic.
>
> I've been following
Ellery Newcomer wrote:
> Bill Baxter wrote:
>> Yes, Yigal said basically that. The question I have is what practical
>> difference does that make to the language?
>> Seems no different from defining the empty tuple to be void, then
>> renaming void to unit.
>>
>>
>> --bb
>
> If you have unit dist
Bill Baxter wrote:
>
> Yes, Yigal said basically that. The question I have is what practical
> difference does that make to the language?
> Seems no different from defining the empty tuple to be void, then
> renaming void to unit.
>
>
> --bb
If you have unit distinct from void, you could use it
On Tue, Nov 17, 2009 at 4:12 PM, Walter Bright
wrote:
> Bill Baxter wrote:
>>
>> On Tue, Nov 17, 2009 at 7:07 AM, bearophile
>> wrote:
>>>
>>> Mike Hearn:
>>>
With a few minor improvements (eg namespace support) that'd save a lot
of time.<
>>>
>>> This change to D language is not planne
On Tue, Nov 17, 2009 at 3:57 PM, retard wrote:
> Tue, 17 Nov 2009 14:38:57 -0800, Bill Baxter wrote:
>
>>> I agree, a tuple of one element (doesn't matter what type, array in
>>> this case) should be semantically identical to that single element.
>>>
>>> proper semantics for language supported tup
KennyTM~ wrote:
> On Nov 18, 09 07:25, Ellery Newcomer wrote:
>> Bill Baxter wrote:
>>> On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer
>>> wrote:
Bill Baxter wrote:
> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
>> On Nov 18, 09 05:40, Ellery Newcomer wrote:
>>> Bill Baxte
On Wed, 18 Nov 2009 01:03:39 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Tue, 17 Nov 2009 23:42:06 +0300, bearophile
wrote:
Found on Lambda the Ultimate, Thirty person-years of memory management
development goes Open Source:
http://www.ravenbrook.com/project/mps/doc/200
Walter Bright Wrote:
> BCS wrote:
> > would you agree that it is not something the programer can predict in
> > advance?
>
> He can, but it is not reasonable to expect him to. But it's still
> deterministic.
I've been following this discussion about determinism and I think it addresses
the pr
== Quote from Bartosz Milewski (bartosz-nos...@relisoft.com)'s article
> dsimcha Wrote:
> >
> > The one thing that I think has been missing from this discussion is, what
> > would be
> > the alternative if we didn't have this "non-deterministic" reallocation?
> > How else
> > could you **efficie
Ellery Newcomer, el 17 de noviembre a las 17:01 me escribiste:
> Bill Baxter wrote:
> > On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
> >> On Nov 18, 09 05:40, Ellery Newcomer wrote:
> >>> Bill Baxter wrote:
> However, I think for the good of humanity we can accept that one
> little b
Mike Hearn wrote:
- Bindings to the core libraries for accessing things like
GFS/BigTable and doing RPCs: optional but the utility of any language
that can't use them is limited. C++ compatibility would certainly
make this easier but SWIG integration would make it even easier
still, as we already
dsimcha Wrote:
>
> The one thing that I think has been missing from this discussion is, what
> would be
> the alternative if we didn't have this "non-deterministic" reallocation? How
> else
> could you **efficiently** implement dynamic arrays?
In the long run (D3), I proposed using the "uniqu
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 7:07 AM, bearophile wrote:
Mike Hearn:
With a few minor improvements (eg namespace support) that'd save a lot of time.<
This change to D language is not planned. You can explain why you think
namespace support is useful (and you can explain those o
Yigal Chripun wrote:
> KennyTM~ wrote:
>> On Nov 18, 09 05:40, Ellery Newcomer wrote:
>>> Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
>>>
>>> int[] i;
>>>
>>> auto a =
Tue, 17 Nov 2009 14:38:57 -0800, Bill Baxter wrote:
>> I agree, a tuple of one element (doesn't matter what type, array in
>> this case) should be semantically identical to that single element.
>>
>> proper semantics for language supported tuples should IMO include: 1)
>> syntax to explicitly [de]
On Nov 18, 09 07:25, Ellery Newcomer wrote:
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer
wrote:
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
However, I think for the good of human
retard wrote:
> workplace. It might be valuable principle for your employer
mah wut? :)
Mon, 16 Nov 2009 18:22:24 -0500, Adam D. Ruppe wrote:
> On Mon, Nov 16, 2009 at 05:00:56PM -0600, Ellery Newcomer wrote:
>> wrong. assignment has higher precedence than comma.
>
> Oh, duh. And I use that fact in for loops all the time too...
>
>> change the first to
>>
>> a = (b, c);
>
>
Tue, 17 Nov 2009 22:01:37 +0200, Yigal Chripun wrote:
> I see what you're saying about two birds with one stone but from my POV
> instead of replacing old cruft with a useful and friendly to use new
> feature you just added more cruft and hacks to poorly support said
> feature with unfriendly and
Mon, 16 Nov 2009 17:08:58 -0600, Ellery Newcomer wrote:
> dsimcha wrote:
>>
>> Axe. Looks like the only things it's good for are making code
>> undreadable and abusing for loop syntax to...
>>
>> Make code unreadable.
>>
>> When the heck would this be significantly more readable, safer, or more
Tue, 17 Nov 2009 15:04:01 -0800, Bill Baxter wrote:
> On Tue, Nov 17, 2009 at 2:53 PM, Robert Jacques
>> *sigh* The reason the compiler would have to create a temporary struct,
>> is because that's what a tuple is at runtime. Tuples need to be compact
>> (like structs) so that they can be passed
Robert Jacques schrieb:
To the best of my knowlegde, D only supports align(1) and align(4). On
the other hand, compile time introspection allows my CUDA api to convert
alignment correctly for any given struct.
gotta look that up in your code.
Maybe I also find some other ideas for writing m
Ellery Newcomer wrote:
> Bill Baxter wrote:
>> On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer
>> wrote:
>>> Bill Baxter wrote:
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
> On Nov 18, 09 05:40, Ellery Newcomer wrote:
>> Bill Baxter wrote:
>>> However, I think for the good
Bill Baxter wrote:
> On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer
> wrote:
>> Bill Baxter wrote:
>>> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
> Bill Baxter wrote:
>> However, I think for the good of humanity we can accept that o
On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer
wrote:
> Bill Baxter wrote:
>> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
>>> On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
> However, I think for the good of humanity we can accept that one
> little bizarre exam
Ellery Newcomer wrote:
> Ellery Newcomer wrote:
>> Bill Baxter wrote:
>>> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
> Bill Baxter wrote:
>> However, I think for the good of humanity we can accept that one
>> little bizarre example
Bill Baxter wrote:
> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
>> On Nov 18, 09 05:40, Ellery Newcomer wrote:
>>> Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
>>> in
Ellery Newcomer wrote:
> Bill Baxter wrote:
>> On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
>>> On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
> However, I think for the good of humanity we can accept that one
> little bizarre example of legal C syntax not doing th
On Tue, Nov 17, 2009 at 2:53 PM, Robert Jacques wrote:
> On Tue, 17 Nov 2009 15:20:06 -0500, Yigal Chripun
> wrote:
>
>> Robert Jacques wrote:
>>>
>>> On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter
>>> wrote:
>>>
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques
wrote:
>
> On T
On Tue, 17 Nov 2009 15:20:06 -0500, Yigal Chripun
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter
wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques
wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 20
> I agree, a tuple of one element (doesn't matter what type, array in this
> case) should be semantically identical to that single element.
>
> proper semantics for language supported tuples should IMO include:
> 1) syntax to explicitly [de]construct tuples and no auto-flattening
> 2) a tuple of on
KennyTM~ wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
int[] i;
auto a = (i)[0];
what does this do?
(i) should not construct a
Walter Bright:
> I've been looking at forcing an order of eval on all expressions. This
> will improve portability and repeatability. In some experiments I've
> done, the effect on performance is minimal.
I/we can do some benchmarks... I am curious.
But I agree that forcing an order of expressi
Bill Baxter:
> > (i) should not construct a tuple. Probably (i,).
>
> That's Python's solution and it seems to work out ok.
Tuple syntax for 0, 1, n items is one of the few things that I don't like of
Python :-)
In Python this is an empty tuple:
()
Or:
tuple()
This is a tuple with 1 item:
x,
Thi
Denis Koroskin wrote:
On Tue, 17 Nov 2009 23:42:06 +0300, bearophile
wrote:
Found on Lambda the Ultimate, Thirty person-years of memory management
development goes Open Source:
http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/
Bye,
bearophile
Hmm, looks *very* interesti
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ wrote:
> On Nov 18, 09 05:40, Ellery Newcomer wrote:
>>
>> Bill Baxter wrote:
>>>
>>> However, I think for the good of humanity we can accept that one
>>> little bizarre example of legal C syntax not doing the same thing in
>>> D.
>>
>> int[] i;
>>
>> auto
On Tue, 17 Nov 2009 23:42:06 +0300, bearophile
wrote:
Found on Lambda the Ultimate, Thirty person-years of memory management
development goes Open Source:
http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/
Bye,
bearophile
Hmm, looks *very* interesting, thanks for a link
On Tue, 17 Nov 2009 15:12:50 -0500, Trass3r wrote:
I originally posted a question about this in D.learn. bearophile advised
me to ask for that feature here.
Original post:
==
OpenCL requires all types to be naturally aligned.
The D specs state:
"AlignAttribute is ignored when
On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
int[] i;
auto a = (i)[0];
what does this do?
(i) should not construct a tuple. Probably (
Bill Baxter wrote:
>
> However, I think for the good of humanity we can accept that one
> little bizarre example of legal C syntax not doing the same thing in
> D.
int[] i;
auto a = (i)[0];
what does this do?
Bill Baxter wrote:
Not sure how odious people would find forcing an order of eval on
tuples, though.
I've been looking at forcing an order of eval on all expressions. This
will improve portability and repeatability. In some experiments I've
done, the effect on performance is minimal.
On Tue, Nov 17, 2009 at 1:02 PM, Bill Baxter wrote:
> I bet if we search hard enough we can find other examples of bizarre C
> that get interpreted differently by D.
Here's a biggie: the value type fixed-size arrays recently introduced.
It aint hard to find examples of C code like this that wil
Tomas Lindquist Olsen:
> yep, D provides no way to do this, they'd all align to 4 bytes (at
> least on x86-32)
The idea, that I suggested to the LDC team too, is to extend the semantics of
align, no new syntax seems needed:
align(8) alias int[4] Foo;
align(8) double good;
Bye,
bearophile
On Tue, Nov 17, 2009 at 11:30 AM, Ellery Newcomer
wrote:
> Leandro Lucarella wrote:
>> Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste:
> void fun1(int a);
> void fun1(Tuple!(int,int) a);
>
> fun1( (a=fizbang(), a+b) );
These are not code ported from *C*.
>>> all
On Tue, Nov 17, 2009 at 9:12 PM, Trass3r wrote:
> I originally posted a question about this in D.learn. bearophile advised me
> to ask for that feature here.
>
>
> Original post:
> ==
>
> OpenCL requires all types to be naturally aligned.
>
> The D specs state:
> "AlignAttribute is ign
On Tue, Nov 17, 2009 at 11:02 AM, div0 wrote:
>> I guess mixin struct could allow a kind of static multiple
>> inheritance. But if that's desirable, then probably alias this should
>> just be extended to enable that. Seems like the two are so similar
>> that whatever alias this lacks in feature
Found on Lambda the Ultimate, Thirty person-years of memory management
development goes Open Source:
http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/
Bye,
bearophile
Robert Jacques wrote:
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
wrote:
Robert Jacques wrote:
I originally posted a question about this in D.learn. bearophile advised
me to ask for that feature here.
Original post:
==
OpenCL requires all types to be naturally aligned.
The D specs state:
"AlignAttribute is ignored when applied to declarations that are not
struct members."
Robert Jacques wrote:
On Tue, 17 Nov 2009 01:44:30 -0500, yigal chripun
wrote:
Robert Jacques Wrote:
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b => tuple(a,b), since it
On Nov 18, 09 02:58, Ellery Newcomer wrote:
KennyTM~ wrote:
On Nov 17, 09 23:44, Ellery Newcomer wrote:
Leandro Lucarella wrote:
Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste:
Justin Johansson wrote:
Great. Sounds like problem solved in that there is no problem.
So how do p
Leandro Lucarella wrote:
> Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste:
void fun1(int a);
void fun1(Tuple!(int,int) a);
fun1( (a=fizbang(), a+b) );
>>> These are not code ported from *C*.
>> all but the second fun1 are, and it could easily exist in D
>
> We ag
Andrei Alexandrescu Wrote:
> Sean Kelly wrote:
> > Tomas Lindquist Olsen Wrote:
> >
> >> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
> >> wrote:
> >>> I suppose nobody much cares if it writes out a corrupted audio file.
> >>> People
> >>> care very much if their airplane suddenly dives into
Ben Hanson Wrote:
> Hi there,
>
> My name is Ben Hanson and I am the author of lexertl
> (http://www.benhanson.net/lexertl.html), a lexical analyser generator written
> in C++. As the generator is modular, code generators can be added easily as
> separate files which means it is easy to output
Leandro Lucarella, el 17 de noviembre a las 16:05 me escribiste:
> Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste:
> > >>> Code ported from C should not compile if the comma expression is
> > >>> converted
> > >>> to a tuple literal because if a and b are int, typeof(a,b) is int now
Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste:
> >>> Code ported from C should not compile if the comma expression is
> >>> converted
> >>> to a tuple literal because if a and b are int, typeof(a,b) is int now
> >>> and
> >>> will be Tuple!(int, int) in the future, and I don't think
On Tue, 17 Nov 2009 02:51:13 -0800, Walter Bright
wrote:
>
>I suppose nobody much cares if it writes out a corrupted audio file.
>People care very much if their airplane suddenly dives into the ground.
>
>Be that as it may, it is certainly possible to catch seg faults in an
>exception handler a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Baxter wrote:
> On Mon, Nov 16, 2009 at 11:32 AM, div0 wrote:
>>>
>> vote++
>>
>> I was going to suggest it when I finished my spirit port, but I was
>> too lazy to in the end.
>>
>> It would be very handy as currently the only way support mul
Sean Kelly wrote:
Denis Koroskin Wrote:
Walter Bright Wrote:
Denis Koroskin wrote:
It is *non*-deterministic. The decision to reallocate depends
(or will depend) on LRU and it may be cleared by another thread
(e.g. another thread may reset it manually or via a GC cycle
run).
The LRU is thre
KennyTM~ wrote:
> On Nov 17, 09 23:44, Ellery Newcomer wrote:
>> Leandro Lucarella wrote:
>>> Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste:
Justin Johansson wrote:
> Great. Sounds like problem solved in that there is no problem.
>
> So how do people feel about
Tomas Lindquist Olsen wrote:
LDC requires a lot of changes to the frontend.
If you send me the changes, I can incorporate at least some of them,
making subsequent versions easier to port to LDC.
Tomas Lindquist Olsen wrote:
You spent quite a bit of effort explaining that segfaults never cause
memory corruption, so it seems fairly reasonable to assume that some
parts of the application state could still be valid and useful not to
throw away.
When a seg fault occurs, it is because your p
On Tue, Nov 17, 2009 at 5:58 PM, bearophile wrote:
> Tomas Lindquist Olsen:
>
>> LDC requires a lot of changes to the frontend.
>>
>> * DMD is not written as a cross compiler
>> * The runtime interfaces are hardcoded into the frontend semantics
>> * The ast rewrites dmd does are destructive and bu
On Tue, 17 Nov 2009 01:44:30 -0500, yigal chripun
wrote:
Robert Jacques Wrote:
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b => tuple(a,b), since it also solves the
multi-
On Nov 17, 09 23:44, Ellery Newcomer wrote:
Leandro Lucarella wrote:
Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste:
Justin Johansson wrote:
Great. Sounds like problem solved in that there is no problem.
So how do people feel about bill's suggestion to progress the issue
furth
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 1
Tomas Lindquist Olsen:
> LDC requires a lot of changes to the frontend.
>
> * DMD is not written as a cross compiler
> * The runtime interfaces are hardcoded into the frontend semantics
> * The ast rewrites dmd does are destructive and buggy
> * The dmd codegen is all over the frontend code, it w
Hi there,
My name is Ben Hanson and I am the author of lexertl
(http://www.benhanson.net/lexertl.html), a lexical analyser generator written
in C++. As the generator is modular, code generators can be added easily as
separate files which means it is easy to output code for any language.
I am i
Sean Kelly wrote:
Tomas Lindquist Olsen Wrote:
On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
wrote:
I suppose nobody much cares if it writes out a corrupted audio file. People
care very much if their airplane suddenly dives into the ground.
Be that as it may, it is certainly possible to ca
On Tue, Nov 17, 2009 at 7:07 AM, Don wrote:
> Bill Baxter wrote:
>>
>> Currently this doesn't work, because the CTFE function doesn't "know"
>> that it's running compile-time:
>>
>> int templ_incr(int x)() {
>> return x+1;
>> }
>>
>> int ctfe_incr(int x) {
>> return templ_incr!(x);
>> }
>>
>
Tomas Lindquist Olsen Wrote:
> On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
> wrote:
> >
> > I suppose nobody much cares if it writes out a corrupted audio file. People
> > care very much if their airplane suddenly dives into the ground.
> >
> > Be that as it may, it is certainly possible to c
On Tue, Nov 17, 2009 at 7:07 AM, bearophile wrote:
> Mike Hearn:
>
>>With a few minor improvements (eg namespace support) that'd save a lot of
>>time.<
>
> This change to D language is not planned. You can explain why you think
> namespace support is useful (and you can explain those other minor
Denis Koroskin Wrote:
> Walter Bright Wrote:
>
> > Denis Koroskin wrote:
> > > It is *non*-deterministic. The decision to reallocate depends (or will
> > > depend) on LRU and it may be cleared by another thread (e.g. another
> > > thread may reset it manually or via a GC cycle run).
> >
> > Th
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques wrote:
> On Tue, 17 Nov 2009 05:44:31 -0500, downs wrote:
>
>> Robert Jacques wrote:
>>>
>>> On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
>>> wrote:
>>>
Robert Jacques wrote:
>
> On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
On Tue, Nov 17, 2009 at 4:45 PM, dsimcha wrote:
> == Quote from Tomas Lindquist Olsen (tomas.l.ol...@gmail.com)'s article
>> I'm not sure if LDC will ever support D2 (at least wont be by my hand)
>
> What is it about D2 that makes this unlikely? I thought after LDC D1 support
> was
> stable and
== Quote from Tomas Lindquist Olsen (tomas.l.ol...@gmail.com)'s article
> I'm not sure if LDC will ever support D2 (at least wont be by my hand)
What is it about D2 that makes this unlikely? I thought after LDC D1 support
was
stable and the D2 spec and front end were stable, the natural progress
Leandro Lucarella wrote:
> Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste:
>> Justin Johansson wrote:
>>
>>> Great. Sounds like problem solved in that there is no problem.
>>>
>>> So how do people feel about bill's suggestion to progress the issue
>>> further?
>>>
>>> Be good to get
On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright
wrote:
> Max Samukha wrote:
>>
>> On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright
>> wrote:
>>
>>> If you've got a system that relies on the software continuing to function
>>> after an unexpected null seg fault, you have a VERY BADLY DESIGNED and
Mike Hearn Wrote:
>
> - Bindings to the core libraries for accessing things like GFS/BigTable and
> doing RPCs: optional but the utility of any language that can't use them is
> limited. C++ compatibility would certainly make this easier but SWIG
> integration would make it even easier still, a
On Tue, 17 Nov 2009 18:07:03 +0300, Don wrote:
Bill Baxter wrote:
Currently this doesn't work, because the CTFE function doesn't "know"
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a fun
On Tue, 17 Nov 2009 05:44:31 -0500, downs
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
wrote:
dsimcha wrote:
Axe. Looks like the only things it's good for are making co
Mike Hearn:
>With a few minor improvements (eg namespace support) that'd save a lot of
>time.<
This change to D language is not planned. You can explain why you think
namespace support is useful (and you can explain those other minor improvements
too).
>- Integration of a compiler with our i
Bill Baxter wrote:
Currently this doesn't work, because the CTFE function doesn't "know"
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used co
1 - 100 of 134 matches
Mail list logo
