int[void] intSet = [2:(), 3:(), 4:()]
oops, void[int] intSet = [2:(), 3:(), 4:()] rather.
I'm usually fairly ambivalent about the idea of statements
being
expressions, but I would *love* for switch to be usable as an
expression.
For instance, in Haxe, you can do stuff like the following,
which I get a
ton of use out of and often wish D had:
a = switch(b)
{
case 1: "foo";
ca
On 2012-07-09 07:22, Andrei Alexandrescu wrote:
Yah, I'm thinking "Bugs fixed" would be an anchor linked to the query,
then "What's new" would be a list just like until now.
Andrei
Another option would be to have a script that creates a list like we
have now based on that query. Then there's
Ladies and Gentlemen,
Today is a day to celebrate! By the time many of you read this you will be
waking up to a new day, and too a new D. As of 0530 07/09/2012 UTC the
programmers and testers of the D Development Team have merged an
unprecedented 37 pull requests; all in a single day.
A b
On 2012-07-08 22:15, Roman D. Boiko wrote:
Can you provide a *specific* example of performance optimization which a
custom D compiler would have, but parser generator would be unlikely to
catch up.
I'm not expert in this field but I've heard that it's harder to get good
error reporting with a
On Monday, July 09, 2012 08:33:31 Jacob Carlborg wrote:
> On 2012-07-08 22:05, Jonathan M Davis wrote:
> > Well, for the lexer and parser, we're probably okay (or very close to it).
> > As Daniel pointed out elsewhere in this thread, that part of the frontend
> > doesn't change much (particularly t
On 2012-07-08 22:05, Jonathan M Davis wrote:
Well, for the lexer and parser, we're probably okay (or very close to it). As
Daniel pointed out elsewhere in this thread, that part of the frontend doesn't
change much (particularly the lexer). There's definitely still some churn, but
it's nothing li
On 7/9/12 1:14 AM, Jonathan M Davis wrote:
Only the bugs fixed section of the changelog could work that way. We'd still
need to manually edit the WHATSNEW section. So, as long as the two can be
combined, that should work.
Yah, I'm thinking "Bugs fixed" would be an anchor linked to the query,
t
On Monday, July 09, 2012 01:08:45 Andrei Alexandrescu wrote:
> Hi all,
>
>
> Just found out that bugzilla has a possibility to query all issues fixed
> after a specific date:
>
> http://d.puremagic.com/issues/buglist.cgi?bug_status=RESOLVED&chfieldto=Now&;
> chfield=bug_status&query_format=advan
On 7/8/2012 2:32 PM, bearophile wrote:
Segmented stacks are useful for 32 bit address space. However, they are not
useful for 64 bit address spaces.
I think Go is meant to be used mostly on 64 bit servers.
Both the designers of Go and Rust are experienced people, and they plan to use
their lang
unfortunately OSX uses an older version of gdb and doesn't
support either python scripting nor -tui; and the macports
version of gdb (ggdb) doesn't work, even on the simplest
segfaulting C program, see
http://stackoverflow.com/questions/6092766/gdb-7-segfaulting.
Anyways I still think lldb is
On Sunday, 8 July 2012 at 13:48:36 UTC, Michaël Larouche wrote:
Hey folks !
I ported the LLVM Kaleidoscope to D if anyone is interessed.
https://github.com/mlarouche/llvm-d-tutorial
Man, this would have been like gold dust when I started fucking
around with LLVM. Nice work. :D
David, I would suggest you to create a proof-of-concept prototype
and pay attention to some non-trivial use cases. This way you'd
likely be able to reduce major risks significantly before making
any serious time investments.
On Sunday, 8 July 2012 at 21:22:39 UTC, Roman D. Boiko wrote:
On Sunday, 8 July 2012 at 21:03:41 UTC, Jonathan M Davis wrote:
It's been too long since I was actively working on parsers to
give any details, but it is my understanding that because a
hand-written parser is optimized for a specific
Walter Bright:
Thank you for your answers Walter, as you guess I am ignorant
about segmented stacks.
The trouble with segmented stacks are:
1. they have a significant runtime penalty
Also, they do not save RAM, they save address space. RAM is not
committed until a stack memory page is act
I believe it would not hurt generality or quality of a parser
generator if it contained sews for inserting custom (optimized)
s/sews/seams
On Sunday, 8 July 2012 at 21:03:41 UTC, Jonathan M Davis wrote:
It's been too long since I was actively working on parsers to
give any details, but it is my understanding that because a
hand-written parser is optimized for a specific grammar, it's
going to be faster.
My aim is to find out any
As someone that values readable code, I don't understand this
desire to turn every programming language into APL.
I would expect the abbreviations that rust uses to be perfectly
readable once you know the langauge.
On Sunday, July 08, 2012 22:15:26 Roman D. Boiko wrote:
> On Sunday, 8 July 2012 at 20:06:07 UTC, Jonathan M Davis wrote:
> > most of the focus right now from people interested in parsing
> > seems to be on pegged and parser generators (which are very
> > cool and in some ways much more interesting
On Sunday, 8 July 2012 at 20:06:07 UTC, Jonathan M Davis wrote:
most of the focus right now from people interested in parsing
seems to be on pegged and parser generators (which are very
cool and in some ways much more interesting, but I seriously
question that that's the performant way to go if
On Sunday, July 08, 2012 14:13:18 Jacob Carlborg wrote:
> On 2012-07-07 19:53, Jonathan M Davis wrote:
> > There are multiple issues here. The one that Andrei is raising is the fact
> > that D isn't properly formalized. Essentially, the compiler _is_ the spec,
> > and while the online spec _mostly_
On Sunday, 8 July 2012 at 13:49:50 UTC, bearophile wrote:
This seems a bit overkill to me:
It's also possible to avoid any type ambiguity by writing
integer literals with a suffix. The suffixes i and u are for
the types int and uint, respectively: the literal -3i has type
int, while 127u has
On 7/8/2012 6:49 AM, bearophile wrote:
I think in Go the function stack is segmented and growable as in Go. This saves
RAM if you need a small stack, and avoids stack overflows where lot of stack is
needed.
The trouble with segmented stacks are:
1. they have a significant runtime penalty
2. i
On Sunday, 8 July 2012 at 18:13:49 UTC, Stefan Scholl wrote:
"bearophile" wrote:
On default in Rust types are immutable. If you want the
mutable type you
need to annotate it with "mut" in some way.
Rust designers seems to love really short keywords, this is in
my opinion
a bit silly. On the
"bearophile" wrote:
> On default in Rust types are immutable. If you want the mutable type you
> need to annotate it with "mut" in some way.
>
> Rust designers seems to love really short keywords, this is in my opinion
> a bit silly. On the other hand in D you have keywords like "immutable"
> th
"timotheecour" writes:
> Is anybody planning to support the D programming language in lldb?
>
> Currently gdb on osx doesn't support D (name mangling issues on osx
> even though it works on linux), and anyways lldb offers much more than
> gdb with interactive debugging via python scripting among
On 7/7/2012 11:05 PM, Andrei Alexandrescu wrote:
Compilation is a huge bottleneck for any major C++ code base, and adding
hardware (distributing compilation etc) is survival, but definitely
doesn't scale to make the problem negligible.
In contrast, programmers have considerable control about ge
Thank for keeping us informed about Rust. i don't like the syntax, but
it is definitively an interesting language and something we should look
at as D people.
On 08/07/2012 15:49, bearophile wrote:
On Reddit they are currently discussing again about the Rust language,
and about the browser pr
On 08/07/2012 15:48, "Michaël Larouche" " wrote:
Hey folks !
I ported the LLVM Kaleidoscope to D if anyone is interessed.
https://github.com/mlarouche/llvm-d-tutorial
I love you !
=?UTF-8?B?Ik1pY2hhw6ts?=.Larouche" "@puremagic.com
wrote:
> On Sunday, 8 July 2012 at 14:32:19 UTC, Jens Mueller wrote:
> >=?UTF-8?B?Ik1pY2hhw6ts?=.Larouche"
> >"@puremagic.com wrote:
> >>Hey folks !
> >>
> >>I ported the LLVM Kaleidoscope to D if anyone is interessed.
> >>
> >>https://github.com/
On Sunday, 8 July 2012 at 14:32:19 UTC, Jens Mueller wrote:
=?UTF-8?B?Ik1pY2hhw6ts?=.Larouche"
"@puremagic.com wrote:
Hey folks !
I ported the LLVM Kaleidoscope to D if anyone is interessed.
https://github.com/mlarouche/llvm-d-tutorial
Nice.
I see that you converted LLVM's C interface to D.
On 07/08/2012 05:39 AM, Lukasz wrote:
On Sunday, 8 July 2012 at 08:05:58 UTC, Mattias wrote:
Hi, I spent some time recently learning D. I am curious about the best
way to implement something like X-includes in C. I.e. where one use
macros that you redefine at the include point.
This is indispen
=?UTF-8?B?Ik1pY2hhw6ts?=.Larouche" "@puremagic.com
wrote:
> Hey folks !
>
> I ported the LLVM Kaleidoscope to D if anyone is interessed.
>
> https://github.com/mlarouche/llvm-d-tutorial
Nice.
I see that you converted LLVM's C interface to D. Can you propose this
to Deimos (https://github.com/D-
Hey folks !
I ported the LLVM Kaleidoscope to D if anyone is interessed.
https://github.com/mlarouche/llvm-d-tutorial
On Reddit they are currently discussing again about the Rust
language, and about the browser prototype written in Rust, named
"Servo" (https://github.com/mozilla/servo ):
http://www.reddit.com/r/programming/comments/w6h7x/the_state_of_servo_a_mozilla_experiment_in/
So I've taken another look a
While writing certain parts of my own little standard library
(containers etc) I had to notice that D has a overcomplicated way of
especially postblitting and destructing structs. By overcomplicated I
mean that you don't have any other choice but to go through a TypeInfo
object to the process c
On 08-Jul-12 17:09, Johannes Pfau wrote:
Am Fri, 06 Jul 2012 01:24:04 +0400
schrieb Dmitry Olshansky :
The only thing I can think of that would require start function is
using unconventional initial vectors.
Those could be done as template parameters though? (If the hash is
written as a te
Am Fri, 06 Jul 2012 01:24:04 +0400
schrieb Dmitry Olshansky :
>
> The only thing I can think of that would require start function is
> using unconventional initial vectors.
>
Those could be done as template parameters though? (If the hash is
written as a templated struct).
But e.g. OpenSSL h
Is anybody planning to support the D programming language in lldb?
Currently gdb on osx doesn't support D (name mangling issues on
osx even though it works on linux), and anyways lldb offers much
more than gdb with interactive debugging via python scripting
among other niceties. The gdb patch
On Sunday, 8 July 2012 at 09:14:32 UTC, Dmitry Olshansky wrote:
On 08-Jul-12 13:05, Tobias Pankrath wrote:
Yup, LL(*) is my favorite so far.
That's Terence Parr's discovery, right? I've always liked
ANTLR, so if
PEGs turn out to have issues LL(*) sounds like a promising
alternative.
We sho
On Sunday, 8 July 2012 at 12:36:46 UTC, grace wrote:
hope, i can..
hope, i can..
On 2012-07-07 19:53, Jonathan M Davis wrote:
There are multiple issues here. The one that Andrei is raising is the fact
that D isn't properly formalized. Essentially, the compiler _is_ the spec, and
while the online spec _mostly_ follows it, it doesn't entirely, and the online
spec isn't always
The problem is that say LL(*) can be easily tweaked in place to
run various semantic actions as it parse the source. I think
GLR is harder to make do anything other then "parse & say it's
fine".
Did you look at Elkhound? According to the tutorial you can use
actions
in the same way as if you
On 2012-07-07 18:49, deadalnix wrote:
I tried that. This is almost impossible, dmd's parser and AST are very
tightly mixed with dmd's internals.
I suspected that.
--
/Jacob Carlborg
On 2012-07-08 06:16, Adam Wilson wrote:
As to compile speed, is LDC really *THAT* much slower than DMD so as to
cause C++ style speed issues? I thought one of the whole points of D is
that it doesn't need the epic numbers of passes and preprocessor that
C++ does precisely because that's what slo
On 08-Jul-12 14:48, Tobias Pankrath wrote:
On Sunday, 8 July 2012 at 09:14:32 UTC, Dmitry Olshansky wrote:
On 08-Jul-12 13:05, Tobias Pankrath wrote:
Yup, LL(*) is my favorite so far.
That's Terence Parr's discovery, right? I've always liked ANTLR, so if
PEGs turn out to have issues LL(*) sou
On 2012-07-07 20:49, Walter Bright wrote:
On 7/7/2012 3:46 AM, Jacob Carlborg wrote:
Theoretically you should be able to just look at the documentation
HAHAHAHAHAHAHAHAHAHAHA!!!
Yeah, I know how you feel about documentation.
--
/Jacob Carlborg
On 2012-01-25 18:07, Trass3r wrote:
Whats.necessary to use D in order to create C++ bindings ?
github.com/jacob-carlborg/dstep
I've released the first alpha/beta version:
http://forum.dlang.org/thread/jt9i6l$2go5$1...@digitalmars.com
--
/Jacob Carlborg
From Elkhound [1]
http://scottmcpeak.com/elkhound/sources/elkhound/algorithm.html
On Sunday, 8 July 2012 at 09:14:32 UTC, Dmitry Olshansky wrote:
On 08-Jul-12 13:05, Tobias Pankrath wrote:
Yup, LL(*) is my favorite so far.
That's Terence Parr's discovery, right? I've always liked
ANTLR, so if
PEGs turn out to have issues LL(*) sounds like a promising
alternative.
We sho
On Sunday, 8 July 2012 at 08:05:58 UTC, Mattias wrote:
Hi, I spent some time recently learning D. I am curious about
the best way to implement something like X-includes in C. I.e.
where one use macros that you redefine at the include point.
This is indispensable sometimes for keeping code in s
On 08-Jul-12 13:05, Tobias Pankrath wrote:
Yup, LL(*) is my favorite so far.
That's Terence Parr's discovery, right? I've always liked ANTLR, so if
PEGs turn out to have issues LL(*) sounds like a promising alternative.
We should also consider using GLR if LL(*) doesn't work.
GLR ... are yo
Yup, LL(*) is my favorite so far.
That's Terence Parr's discovery, right? I've always liked
ANTLR, so if PEGs turn out to have issues LL(*) sounds like a
promising alternative.
We should also consider using GLR if LL(*) doesn't work.
Am 08.07.2012 10:16, schrieb Andrea Fontana:
I wonder if you read my original message :)
I can't extract mongodb from the whole framework.
On Friday, 6 July 2012 at 23:40:21 UTC, Adam Wilson wrote:
On Fri, 06 Jul 2012 05:31:09 -0700, Andrea Fontana
wrote:
I see there's a c-mongo library bin
I wonder if you read my original message :)
I can't extract mongodb from the whole framework.
On Friday, 6 July 2012 at 23:40:21 UTC, Adam Wilson wrote:
On Fri, 06 Jul 2012 05:31:09 -0700, Andrea Fontana
wrote:
I see there's a c-mongo library binding called mongo-d-library
on github, but it
Hi, I spent some time recently learning D. I am curious about the
best way to implement something like X-includes in C. I.e. where
one use macros that you redefine at the include point.
This is indispensable sometimes for keeping code in sync.
For example, if we in an include header writes:
-
On Saturday, 7 July 2012 at 22:54:15 UTC, Timon Gehr wrote:
On 07/08/2012 12:23 AM, Mehrdad wrote:
On Saturday, 7 July 2012 at 22:00:43 UTC, H. S. Teoh wrote:
On Sat, Jul 07, 2012 at 11:39:59PM +0200, Mehrdad wrote:
This might sound silly, but how about if D stopped allowing
0..2
as a range, a
On Saturday, 7 July 2012 at 22:54:15 UTC, Timon Gehr wrote:
On 07/08/2012 12:23 AM, Mehrdad wrote:
You could go like this:
switch(input.front) {
case '0'..'9':
bool consumedtrailingdot;
output.put(parseNumber(input, consumedtrailingdot));
if(!consumedtrailingdot) con
On Sat, 07 Jul 2012 23:47:45 -0700, Walter Bright
wrote:
On 7/7/2012 9:16 PM, Adam Wilson wrote:
I still see pretty heinous backend problems crop up in
the bug reports for DMD.
Come on, it's pretty stable. Do you watch the bug reports for gcc? I
remember a guy recently ran some exhaustiv
60 matches
Mail list logo
