Just Visiting wrote:
Nick B Wrote:
Nick B wrote:
Jeremie Pelletier wrote:
Just Visiting wrote:
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux
x86_64
The ideas behind DmD looked promising to me. But most of my programs
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
It is if x is an _arbitrarily complex_ expression, and if that
expression is part of a _complex control flow_. The language definition
would have to decide exactly where complex is too complex in the
expression or the control flow. That complicates
Andrei Alexandrescu wrote:
> It is if x is an _arbitrarily complex_ expression, and if that
> expression is part of a _complex control flow_. The language definition
> would have to decide exactly where complex is too complex in the
> expression or the control flow. That complicates the language. A
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
If x is a complex expression and part of a complex control flow, it
becomes highly difficult what it means "at the beginning of the
function". It also becomes difficult to find a way to distinguish good
cases from bad cases without being overly cons
Rainer Deyke wrote:
> {
>auto old_x = x;
>try {
> F();
>} finally {
> G(old_x);
>}
> }
Not 'finally', unless postconditions are checked when the function
terminates with an exception. This is closer to correct:
{
auto old_x = x;
// Preconditions go here.
F()
Nick B Wrote:
> Nick B wrote:
> > Jeremie Pelletier wrote:
> >> Just Visiting wrote:
> >>> Last things I remember:
> >>>
> >>> - DmD is strictly 32-bit
> >>> - Someone ported a chronically outdated D-compiler variant to Linux
> >>> x86_64
> >>>
> >>> The ideas behind DmD looked promising to me. B
Nick Sabalausky Wrote:
> "Just Visiting" wrote in message
> news:hbdk23$2qo...@digitalmars.com...
> >
> > They usually
> > judge from the standpoint of their own momentary CPU
> > performance requirements.
>
> I can say exactly the same about people who defend setting their minimum
> system sp
Andrei Alexandrescu wrote:
> If x is a complex expression and part of a complex control flow, it
> becomes highly difficult what it means "at the beginning of the
> function". It also becomes difficult to find a way to distinguish good
> cases from bad cases without being overly conservative.
It l
Nick B wrote:
Jeremie Pelletier wrote:
Just Visiting wrote:
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux
x86_64
The ideas behind DmD looked promising to me. But most of my programs
showed at least a 2-fold performance
Jeremie Pelletier wrote:
Just Visiting wrote:
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux
x86_64
The ideas behind DmD looked promising to me. But most of my programs
showed at least a 2-fold performance increase once t
Robert Clipsham wrote:
Andrei Alexandrescu wrote:
Any other issues with AAs that you want to see fixed, and ideas
guiding a redesign?
Their speed. I did a benchmark a while ago comparing tango's HashMap
implementation and built in AAs, tango's hashmaps were twice as fast...
It'd be nice if t
Thu, 15 Oct 2009 23:18:22 -0500, Andrei Alexandrescu wrote:
> Jeremie Pelletier wrote:
>> Andrei Alexandrescu wrote:
>>> Jeremie Pelletier wrote:
Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> This goes into something more interesting that I th
Thu, 15 Oct 2009 21:55:07 -0500, Andrei Alexandrescu wrote:
> int[new] a;
> ...
> a = [1, 2, 3];
>
> What should that do?
To me a is an array, a reference type. Therefore assignment here means
rebinding a to a new array created from a literal.
> A: Ok, then how do I say the common operation "I
Just Visiting wrote:
My girl friend is driving a Porsche (no Italian sports car, sorry).
Who do you think had to pay for it? Yeah, you guessed right,
it was the guy who is tweaking software, so a bunch of
computers can survive their replacement by a year or two.
I just wonder what car make she'd
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Copying the object would be completely broken, so I'm sure that that's
*not* how Eiffel does it. "It denotes the value the expression had on
routine entry." In other words, the expression is evaluated once, on
routine entry, a
Andrei Alexandrescu wrote:
Any other issues with AAs that you want to see fixed, and ideas guiding
a redesign?
Their speed. I did a benchmark a while ago comparing tango's HashMap
implementation and built in AAs, tango's hashmaps were twice as fast...
It'd be nice if the built in language fea
"Just Visiting" wrote in message
news:hbdk23$2qo...@digitalmars.com...
>
> They usually
> judge from the standpoint of their own momentary CPU
> performance requirements.
I can say exactly the same about people who defend setting their minimum
system specs higher than they need to be. As soon a
Before I answer the previous message I'd like to thank
everyone for their feedback which was pretty helpful.
Now to Nick:
I really do not intend to offend anybody but you should
actually think before you question the necessity for
fast/responsive programs. People like you have used
similar argume
Nick Sabalausky wrote:
> "dolive" wrote in message
> news:hbcrm9$fo...@digitalmars.com...
>> bug fix is slower,should speed up the progress, fix more than 200 a
>> month. Very much looking forward to, thanks all !
>>
>
> Thank you. We had previously thought that fixing as few bugs as possible
>
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> Copying the object would be completely broken, so I'm sure that that's
>> *not* how Eiffel does it. "It denotes the value the expression had on
>> routine entry." In other words, the expression is evaluated once, on
>> routine entry, and the res
Leandro Lucarella wrote:
> Rainer Deyke, el 17 de octubre a las 14:24 me escribiste:
>> There is no "the object".
> There is an object if you have this:
>
> void f(SomeObjectWithLotsOfReferences obj) out {
> assert(old(obj).some_check());
> }
If 'obj' is a reference type and the reference itsel
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Also, from the Eiffel docs
(http://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.html):
The notation 'old expression' is only valid in a routine
postcondition. It denotes the value the expression had on
BCS wrote:
> Hello Ellery,
>
>> BCS wrote:
>>
>>> Hello Ellery,
>>>
Do LALR parsers care about arbitrary
lookahead? LL(k) parsers do.
>>> LALR needs to be able to unambiguously determine all the /completed/
>>> productions to the left of each point by looking at nothing beyond
>>> the ne
Rainer Deyke, el 17 de octubre a las 14:24 me escribiste:
> Christopher Wright wrote:
> > Rainer Deyke wrote:
> >> It seems that Eiffel had 'old' semantics that I've proposed all along.
> >> Any significant problems with this approach would have been discovered
> >> by the Eiffel community by now.
Walter Bright Wrote:
> >> 2. Optimizer collects the info, but ignores this, because people are
> >> annoyed by false positives.
clang analyzer tries to avoid false positives very hard. To the point that
every error message has link for sending a bug report.
> The problem crops up when there ar
"Ellery Newcomer" wrote in message
news:hbd6q8$1o5...@digitalmars.com...
>
> For some reason, my professor seems to be skipping LR parsing.
Gold's documentation has a lot of good starting point information:
http://www.devincook.com/goldparser/articles/lalr.htm
http://www.devincook.com/goldparse
"Nick Sabalausky" wrote in message
news:hbdana$27s...@digitalmars.com...
> "Ellery Newcomer" wrote in message
> news:hbd6q8$1o5...@digitalmars.com...
>>
>> For some reason, my professor seems to be skipping LR parsing.
>
> Gold's documentation has a lot of good starting point information:
>
> h
Max Samukha wrote:
On Sat, 17 Oct 2009 13:28:51 -0500, Andrei Alexandrescu
wrote:
Associative arrays are today quite problematic because they don't offer
any true iteration. Furthermore, the .keys and .values properties create
new arrays, which is wasteful.
Another issue with associative ar
"Yigal Chripun" wrote in message
news:hbd9d5$245...@digitalmars.com...
> On 17/10/2009 22:11, Nick Sabalausky wrote:
>>
>> They should make roads that are only usable by Italian sports cars, and
>> take
>> full advantage of their special characteristics. Any other roads are just
>> wasting my ti
"BCS" wrote in message
news:a6268ffb7838cc1d4346bad...@news.digitalmars.com...
> Hello Ellery,
>
>> BCS wrote:
>>
>>>
>>> (BTW I'm taking (but haven't yet finished) a compilers class so I
>>> might be missing something)
>>>
>> Small world :)
>>
>> For some reason, my professor seems to be skippin
On 17/10/2009 22:11, Nick Sabalausky wrote:
"Just Visiting" wrote in message
news:hbcbvs$1ee...@digitalmars.com...
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux x86_64
The ideas behind DmD looked promising to me. But most
Christopher Wright wrote:
> Rainer Deyke wrote:
>> It seems that Eiffel had 'old' semantics that I've proposed all along.
>> Any significant problems with this approach would have been discovered
>> by the Eiffel community by now.
>
> It requires duplicating the object. If the object is mutable, t
Hello Ellery,
BCS wrote:
Hello Ellery,
Do LALR parsers care about arbitrary
lookahead? LL(k) parsers do.
LALR needs to be able to unambiguously determine all the /completed/
productions to the left of each point by looking at nothing beyond
the next token to the right. This might not be con
"dolive" wrote in message
news:hbcrm9$fo...@digitalmars.com...
> bug fix is slower,should speed up the progress, fix more than 200 a month.
> Very much looking forward to, thanks all !
>
Thank you. We had previously thought that fixing as few bugs as possible
would be the best thing to do. Now
Hello Nick,
"Just Visiting" wrote in message
news:hbcbvs$1ee...@digitalmars.com...
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux
x86_64
The ideas behind DmD looked promising to me. But most of my programs
showed at least
Hello dsimcha,
6. The array of aaA structs can only have the following sizes:
immutable size_t[] prime_list = [
97UL,389UL,
1_543UL, 6_151UL,
24_593UL, 98_317UL,
393_241UL, 1_572_869UL,
6_291_469UL, 25_165_843UL,
100_663_319UL,402_653_189UL,
1_610_612_
"Just Visiting" wrote in message
news:hbcbvs$1ee...@digitalmars.com...
> Last things I remember:
>
> - DmD is strictly 32-bit
> - Someone ported a chronically outdated D-compiler variant to Linux x86_64
>
> The ideas behind DmD looked promising to me. But most of my programs
> showed at least a
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> Also, from the Eiffel docs
>> (http://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.html):
>>
>> The notation 'old expression' is only valid in a routine
>> postcondition. It denotes the value the expression had on routine
"Ellery Newcomer" wrote in message
news:hbcq8b$av...@digitalmars.com...
>
> Does GOLD let you manually specify how to resolve the ambiguities? Cuz
> you're going to have them with D, and murphy says they're going to be
> reduce-reduce :)
>
No. Reduce-reduce are errors and require adjusting the g
Denis Koroskin дµ½:
> On Sat, 17 Oct 2009 22:55:44 +0400, dolive wrote:
>
> > Eldar Insafutdinov ôµ½:
> >
> >> dolive Wrote:
> >>
> >> > bug fix is slower,should speed up the progress, fix more than 200 a
> >> month.
> >> > Very much looking forward to, thanks all !
> >> >
> >> > dolive
"Christopher Wright" wrote in message
news:hbcg2t$20i...@digitalmars.com...
> Jacob Carlborg wrote:
>> On 10/17/09 00:23, Christopher Wright wrote:
>>> Jacob Carlborg wrote:
On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
> GtkD supports Glade.
Yes, but GtkD doesn't use native
BCS wrote:
> Hello Ellery,
>
>> Do LALR parsers care about arbitrary
>> lookahead? LL(k) parsers do.
>>
>
> LALR needs to be able to unambiguously determine all the /completed/
> productions to the left of each point by looking at nothing beyond the
> next token to the right. This might not be co
On Sat, 17 Oct 2009 13:28:51 -0500, Andrei Alexandrescu
wrote:
>Associative arrays are today quite problematic because they don't offer
>any true iteration. Furthermore, the .keys and .values properties create
>new arrays, which is wasteful.
>
>Another issue with associative arrays is that ++a[
Sat, 17 Oct 2009 19:16:32 +, dsimcha thusly wrote:
> == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
> article
>> Associative arrays are today quite problematic because they don't offer
>> any true iteration. Furthermore, the .keys and .values properties
>> create new array
Hello Moritz,
On Sat, 17 Oct 2009 18:58:08 +, BCS wrote:
Hello Chris Nicholson-Sauls,
Idea: the .keys and .values properties, rather than creating arrays,
could create iterable ranges with the smallest possible footprint,
internally walking the tree structure.
what will this do?
forea
Hello Moritz,
On Sat, 17 Oct 2009 19:06:36 +, Moritz Warning wrote:
On Sat, 17 Oct 2009 18:58:08 +, BCS wrote:
what will this do?
foreach(key; aa.keys)
if(Test(key))
aa.remove(key);
It's undefined behavior.
You shouldn't try to mutate the aa while iterating. I hope that will
be
fi
On Sat, 17 Oct 2009 22:55:44 +0400, dolive wrote:
Eldar Insafutdinov дµ½:
dolive Wrote:
> bug fix is slower,should speed up the progress, fix more than 200 a
month.
> Very much looking forward to, thanks all !
>
> dolive
>
>
What have you personally done to make it possible?
sorry£¬I
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Associative arrays are today quite problematic because they don't offer
> any true iteration. Furthermore, the .keys and .values properties create
> new arrays, which is wasteful.
> Another issue with associative arrays i
Hello Ellery,
But what I'm wondering about LALR is will it have to back up if it
chooses wrong,
LALR can't backup
or can it sail on through in one parse attempt. I bet
it can.
What it will do is parse the "{", parse an expression and /then/ use what
comes next to decide what the stuff it
Hello Ellery,
Do LALR parsers care about arbitrary
lookahead? LL(k) parsers do.
LALR needs to be able to unambiguously determine all the /completed/ productions
to the left of each point by looking at nothing beyond the next token to
the right. This might not be conservative enough, but I s
On Sat, 17 Oct 2009 19:06:36 +, Moritz Warning wrote:
> On Sat, 17 Oct 2009 18:58:08 +, BCS wrote:
>
>> Hello Chris Nicholson-Sauls,
>>
>>> Andrei Alexandrescu wrote:
>>>
Associative arrays are today quite problematic because they don't
offer any true iteration. Furthermore, t
On Sat, 17 Oct 2009 18:58:08 +, BCS wrote:
> Hello Chris Nicholson-Sauls,
>
>> Andrei Alexandrescu wrote:
>>
>>> Associative arrays are today quite problematic because they don't
>>> offer any true iteration. Furthermore, the .keys and .values
>>> properties create new arrays, which is waste
Hello Christopher,
Lutger wrote:
Currently:
LDC is a mature compiler that does linux 64 bit well, but is not
available for D2, the 'alpha' branch of the language and also doesn't
work on windows.
LDC works on Windows, except for exception handling. Which is probably
a deal breaker for most
Hello Chris Nicholson-Sauls,
Andrei Alexandrescu wrote:
Associative arrays are today quite problematic because they don't
offer any true iteration. Furthermore, the .keys and .values
properties create new arrays, which is wasteful.
Another issue with associative arrays is that ++a[k] is hacke
Hello aJ,
Who is Walter Bright?
He's the guy who is makeing D. The other replies coever the rest.
Eldar Insafutdinov дµ½:
> dolive Wrote:
>
> > bug fix is slower,should speed up the progress, fix more than 200 a month.
> > Very much looking forward to, thanks all !
> >
> > dolive
> >
> >
>
> What have you personally done to make it possible?
>
sorry£¬I am a beginning student£¬I would l
Andrei Alexandrescu wrote:
Associative arrays are today quite problematic because they don't offer
any true iteration. Furthermore, the .keys and .values properties create
new arrays, which is wasteful.
Another issue with associative arrays is that ++a[k] is hacked, which
reflects a grave lan
Eldar Insafutdinov дµ½:
> dolive Wrote:
>
> > bug fix is slower,should speed up the progress, fix more than 200 a month.
> > Very much looking forward to, thanks all !
> >
> > dolive
> >
> >
>
> What have you personally done to make it possible?
>
sorry£¬I am a beginning student£¬I would l
Andrei Alexandrescu Wrote:
> Associative arrays are today quite problematic because they don't offer
> any true iteration. Furthermore, the .keys and .values properties create
> new arrays, which is wasteful.
>
> Another issue with associative arrays is that ++a[k] is hacked, which
> reflects
Associative arrays are today quite problematic because they don't offer
any true iteration. Furthermore, the .keys and .values properties create
new arrays, which is wasteful.
Another issue with associative arrays is that ++a[k] is hacked, which
reflects a grave language limitation. That needs
dolive Wrote:
> bug fix is slower,should speed up the progress, fix more than 200 a month.
> Very much looking forward to, thanks all !
>
> dolive
>
>
What have you personally done to make it possible?
bug fix is slower,should speed up the progress, fix more than 200 a month.
Very much looking forward to, thanks all !
dolive
Nick Sabalausky wrote:
> "Ellery Newcomer" wrote in message
> news:hbaom1$138...@digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Ellery Newcomer" wrote in message
>>> news:hbak0n$q5...@digitalmars.com...
I could count the number of places that are ambiguous syntactically or
semantica
Rainer Deyke wrote:
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
I honestly believe the whole "old" thing can't be made to work. Shall we
move on to other possibilities instead of expending every effort on
making this bear dance?
It definitely /can/ be made to work, for some value of "work".
dsimcha, el 17 de octubre a las 14:19 me escribiste:
> == Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> > Currently:
> > LDC is a mature compiler that does linux 64 bit well, but is not available
> > for D2, the 'alpha' branch of the language and also doesn't work on windows.
> > The
dsimcha wrote:
> == Quote from Lutger (lutger.blijdest...@gmail.com)'s article
>> Currently:
>> LDC is a mature compiler that does linux 64 bit well, but is not
>> available for D2, the 'alpha' branch of the language and also doesn't
>> work on windows. The outdated compiler you speak of would pro
Christopher Wright wrote:
language_fan wrote:
Sat, 17 Oct 2009 10:58:15 +0200, Frank Benoit thusly wrote:
In Tango search for "__USE_LARGEFILE64" to find the relevant places. Not
only other functions are used, also types and structures are different.
I think there was some talk about merging
== Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> Currently:
> LDC is a mature compiler that does linux 64 bit well, but is not available
> for D2, the 'alpha' branch of the language and also doesn't work on windows.
> The outdated compiler you speak of would probably be GDC, this pro
Just Visiting wrote:
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux x86_64
The ideas behind DmD looked promising to me. But most of my programs showed at
least a 2-fold performance increase once they were re-written for 64-b
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
> >> dsimcha wrote:
> >>> Does anyone know how to work with huge (2GB+) files in D2? std.stream has
> >>> overflow bugs (I haven't isolate
Lutger wrote:
Currently:
LDC is a mature compiler that does linux 64 bit well, but is not available
for D2, the 'alpha' branch of the language and also doesn't work on windows.
LDC works on Windows, except for exception handling. Which is probably a
deal breaker for most people.
language_fan wrote:
Sat, 17 Oct 2009 10:58:15 +0200, Frank Benoit thusly wrote:
In Tango search for "__USE_LARGEFILE64" to find the relevant places. Not
only other functions are used, also types and structures are different.
I think there was some talk about merging Tango and Phobos, but now
Rainer Deyke wrote:
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
I honestly believe the whole "old" thing can't be made to work. Shall we
move on to other possibilities instead of expending every effort on
making this bear dance?
It definitely /can/ be made to work, for some value of "work".
Jacob Carlborg wrote:
On 10/17/09 00:23, Christopher Wright wrote:
Jacob Carlborg wrote:
On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
GtkD supports Glade.
Yes, but GtkD doesn't use native controls.
A minor point, I think. Eclipse doesn't look very native and has
widespread acceptance.
dsimcha wrote:
== Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
dsimcha wrote:
Does anyone know how to work with huge (2GB+) files in D2? std.stream has
overflow bugs (I haven't isolated them yet) and can't return their size
correctly, std.stdio.File throws a ConvOverflowError in
Currently:
LDC is a mature compiler that does linux 64 bit well, but is not available
for D2, the 'alpha' branch of the language and also doesn't work on windows.
The outdated compiler you speak of would probably be GDC, this project has
recently been revived. The is no 64-bit dmd yet.
At the
Last things I remember:
- DmD is strictly 32-bit
- Someone ported a chronically outdated D-compiler variant to Linux x86_64
The ideas behind DmD looked promising to me. But most of my programs showed at
least a 2-fold performance increase once they were re-written for 64-bit.
Therefore 32-bit c
language_fan wrote:
> Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote:
>
>> Does Walter Bright use D for any projects himself?
>
> He makes "nice" html presentations of the language, demonstrating small
> code snippets. They are sometimes available online :S
DMDscript, the garbage colle
Jacob Carlborg wrote:
...
> GtkD doesn't use native controls, DFL is only for windows (last I
> checked).
Sure. But think of it this way: GtkD *is* the native controls (for Gnome),
only they are also usable on other platforms. Same way QT *is* native for
the KDE platform. (except QT does use n
Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> I honestly believe the whole "old" thing can't be made to work. Shall we
>> move on to other possibilities instead of expending every effort on
>> making this bear dance?
>
> It definitely /can/ be made to work, for some value of "work". It
> sa
On 10/17/09 10:31, Eric Suen wrote:
"Christopher Wright" wrote
Jacob Carlborg wrote:
On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
GtkD supports Glade.
Yes, but GtkD doesn't use native controls.
A minor point, I think. Eclipse doesn't look very native and has
widespread acceptance.
SWT
Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote:
> Does Walter Bright use D for any projects himself?
He makes "nice" html presentations of the language, demonstrating small
code snippets. They are sometimes available online :S
On 10/17/09 07:06, Nick Sabalausky wrote:
"Christopher Wright" wrote in message
news:hbarno$188...@digitalmars.com...
Jacob Carlborg wrote:
On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
GtkD supports Glade.
Yes, but GtkD doesn't use native controls.
A minor point, I think. Eclipse doesn
On 10/17/09 04:22, Eric Suen wrote:
"Lutger" wrote
Jacob Carlborg wrote:
Here is my thoughts and what I think is needed to build a really good
IDE and maybe get some attention from the enterprise. It's really not
enough for the compiler to output some json for an IDE to use, the whole
tool cha
On Fri, 16 Oct 2009 23:52:39 -0500, AJ wrote:
> Who is Walter Bright?
I've heard he is 7 feet tall and has a peg leg!
On 10/17/09 00:23, Christopher Wright wrote:
Jacob Carlborg wrote:
On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
GtkD supports Glade.
Yes, but GtkD doesn't use native controls.
A minor point, I think. Eclipse doesn't look very native and has
widespread acceptance.
It depends on what you
Sat, 17 Oct 2009 10:58:15 +0200, Frank Benoit thusly wrote:
> In Tango search for "__USE_LARGEFILE64" to find the relevant places. Not
> only other functions are used, also types and structures are different.
I think there was some talk about merging Tango and Phobos, but now since
Tango has bee
On 10/16/09 19:18, Lutger wrote:
Jacob Carlborg wrote:
Here is my thoughts and what I think is needed to build a really good
IDE and maybe get some attention from the enterprise. It's really not
enough for the compiler to output some json for an IDE to use, the whole
tool chain needs to be revi
AJ wrote:
Who is Walter Bright?
We are all Walter Bright.
AJ wrote:
Chris Nicholson-Sauls wrote:
The most important thing is remembering that black text on a white
screen carries absolutely no emotional information whatsoever, in
either direction, in any case.
1
<-- "panic"! THAT DOES NOT COMPUTE! DANGER, DANGER, Will Robinson!
Also remember: R
"Ellery Newcomer" wrote in message
news:hbaom1$138...@digitalmars.com...
>
> But what I'm wondering about LALR is will it have to back up if it
> chooses wrong, or can it sail on through in one parse attempt. I bet it
> can.
>
> And how about actual ambiguity? How well does GOLD handle that?
I a
"Justin Johansson" wrote in message
news:hbc1rs$c1...@digitalmars.com...
> Walter Bright Wrote:
>
>> AJ wrote:
>> > Who is Walter Bright?
>>
>> I am Oz, the Great and Powerful!
>
> Swell. Here's the broomstick of the Witch of the West. Will you now
> please grant us our requests?
I just want
Walter Bright Wrote:
> AJ wrote:
> > Who is Walter Bright?
>
> I am Oz, the Great and Powerful!
Swell. Here's the broomstick of the Witch of the West. Will you now please
grant us our requests?
Jeremie Pelletier schrieb:
> Frank Benoit wrote:
>> dsimcha schrieb:
>>> == Quote from Jeremie Pelletier (jerem...@gmail.com)'s article
dsimcha wrote:
> Does anyone know how to work with huge (2GB+) files in D2?
> std.stream has
> overflow bugs (I haven't isolated them yet) and ca
Andrei Alexandrescu wrote:
> Lutger wrote:
>
>> What is the benefit of variants here? Maybe I'm missing something, it
>> just seems a little verbose and lose out on the type system (IDE support
>> and such). Wouldn't it also tie the variant type to the language or is
>> that not a problem?
>
> T
"Christopher Wright" wrote
> Jacob Carlborg wrote:
>> On 10/16/09 12:58, Tomas Lindquist Olsen wrote:
>>> GtkD supports Glade.
>>
>> Yes, but GtkD doesn't use native controls.
>
> A minor point, I think. Eclipse doesn't look very native and has
> widespread acceptance.
SWT wrap native controls, a
96 matches
Mail list logo
