Am 18.12.2012 07:07, schrieb Andrei Alexandrescu:
Hello everyone,
We're very excited to announce the Call for Submissions for DConf 2013.
It's barebones right now but it has all of the information needed to get
everyone started!
http://dconf.org
Share away!
We have firm dates, and
On 18 December 2012 06:07, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Hello everyone,
We're very excited to announce the Call for Submissions for DConf 2013.
It's barebones right now but it has all of the information needed to get
everyone started!
http://dconf.org
Share
On 12/18/2012 1:31 AM, Iain Buclaw wrote:
I suppose you would want me to talk gdc. :o)
I suspect a session by you on gdc would generate a lot of interest. ditto for
David on ldc.
On Tuesday, 18 December 2012 at 06:07:42 UTC, Andrei Alexandrescu
wrote:
Hello everyone,
We're very excited to announce the Call for Submissions for
DConf 2013. It's barebones right now but it has all of the
information needed to get everyone started!
http://dconf.org
Share away!
We have
On 18 December 2012 06:07, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
We're very excited to announce the Call for Submissions for DConf 2013.
It's barebones right now but it has all of the information needed to get
everyone started!
http://dconf.org
D'oh, you've got the
On 12/18/12 12:14 PM, Iain Buclaw wrote:
On 18 December 2012 06:07, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
We're very excited to announce the Call for Submissions for DConf
2013. It's barebones right now but it has all of the
On 12/18/12 11:26 AM, John Colvin wrote:
On Tuesday, 18 December 2012 at 06:07:42 UTC, Andrei Alexandrescu wrote:
Hello everyone,
We're very excited to announce the Call for Submissions for DConf
2013. It's barebones right now but it has all of the information
needed to get everyone started!
On 18 December 2012 19:39, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 12/18/12 11:26 AM, John Colvin wrote:
On Tuesday, 18 December 2012 at 06:07:42 UTC, Andrei Alexandrescu wrote:
Hello everyone,
We're very excited to announce the Call for Submissions for DConf
2013.
On 12/18/12 2:46 PM, Iain Buclaw wrote:
Now it looks like some bad html. :o)
Refixed...
Andrei
On 18 December 2012 15:09, Walter Bright newshou...@digitalmars.com wrote:
On 12/18/2012 1:31 AM, Iain Buclaw wrote:
I suppose you would want me to talk gdc. :o)
I suspect a session by you on gdc would generate a lot of interest. ditto
for David on ldc.
Me and David had a chat and kinda
On Tuesday, 18 December 2012 at 07:48:01 UTC, Jacob Carlborg
wrote:
On 2012-12-17 23:12, Walter Bright wrote:
I have toyed with the idea many times, however, of having dmd
support
zip files. Zip files can contain an arbitrary file hierarchy,
with
individual files in compressed, encrypted, or
On Monday, 17 December 2012 at 23:40:19 UTC, Jonathan M Davis
wrote:
On Monday, December 17, 2012 10:23:45 monarch_dodra wrote:
Opinions? Just want to know how which direction to take my
future
developments.
How about we just require that they all return bool? I see no
reason to
support
12/18/2012 2:23 AM, Walter Bright пишет:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D go the same
route. Object files would then be looked at as minimal and stupid
variation of
module where symbols are identified by mangling (not
12/18/2012 4:42 AM, Walter Bright пишет:
On 12/17/2012 3:03 PM, deadalnix wrote:
I know that. I not arguing against that. I'm arguing against the fact
that this
is a blocker. This is blocker in very few use cases in fact. I just
look at the
whole picture here. People needing that are the
On Tuesday, December 18, 2012 10:23:18 monarch_dodra wrote:
On Monday, 17 December 2012 at 23:40:19 UTC, Jonathan M Davis
wrote:
On Monday, December 17, 2012 10:23:45 monarch_dodra wrote:
Opinions? Just want to know how which direction to take my
future
developments.
How about we
On Tuesday, December 18, 2012 01:45:14 Jonathan M Davis wrote:
On Tuesday, December 18, 2012 10:23:18 monarch_dodra wrote:
On Monday, 17 December 2012 at 23:40:19 UTC, Jonathan M Davis
wrote:
On Monday, December 17, 2012 10:23:45 monarch_dodra wrote:
Opinions? Just want to know how
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
Just one tidbit of information: I talked to Walter and we want to build into
the process the ability to modify any particular release. (One possibility is
to do so as part of paid support for large corporate users.) That means there
needs to be
On Tuesday, 18 December 2012 at 07:36:26 UTC, Marcel wrote:
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 that are rather long to type. So I
prefer a mid way between those two.
They aren't silly,
Bearophile has just entered his 1000th bug report into Bugzilla.
This is more than the three next most prolific contributers, combined.
The top ten bug reporters are (courtesy of Deskzilla):
1002 Bearophile
315 Andrej Mitrovic
308 Don Clugston
282 David Simcha
193 Andrei Alexandrescu
185
On Tuesday, 18 December 2012 at 06:52:27 UTC, Xinok wrote:
On another note, I highly doubt that std::sort uses a median
of medians algorithm, which would add much overhead and
essentially double the number of comparisons required with
little to no benefit. More likely, it simply chooses the
On Tuesday, 18 December 2012 at 00:15:04 UTC, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 02:08:55AM +0400, Dmitry Olshansky
wrote:
[...]
I suspect it's one of prime examples where UNIX philosophy of
combining a bunch of simple (~ dumb) programs together in
place of
one more complex program was
On 2012-48-18 11:12, Don Clugston d...@nospam.com wrote:
Bearophile has just entered his 1000th bug report into Bugzilla.
This is more than the three next most prolific contributers, combined.
The top ten bug reporters are (courtesy of Deskzilla):
1002 Bearophile
315 Andrej Mitrovic
308
On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright wrote:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D
go the same
route. Object files would then be looked at as minimal and
stupid variation of
module where symbols are
On Tuesday, 18 December 2012 at 00:48:40 UTC, Walter Bright wrote:
Wow, I think that's exactly what we could use! It serves
multiple optional use
cases all at once!
Was there a technical reason for you not getting around
towards implementing, or
just a lack of time?
There always seemed
On 12/18/12, foobar f...@bar.com wrote:
Besides, the other compilers merge in the same front-end
code so they'll gain the same feature anyway. There's no gain in
separating it out to rdmd.
Adding more front-end features adds more work for maintainers of
compilers which are based on the DMD
Marcel:
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 that are rather long to type. So I
prefer a mid way between those two.
They aren't silly, they're consistent. We have int, char, auto,
they
On 18 December 2012 10:27, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
Just one tidbit of information: I talked to Walter and we want to build
into
the process the ability to modify any particular release. (One
possibility
On 12/18/12, Don Clugston d...@nospam.com wrote:
Bearophile has just entered his 1000th bug report into Bugzilla.
I love his comment in the first report:
http://d.puremagic.com/issues/show_bug.cgi?id=3813
quote
This is my first bug report in this bug tracker. I will probably add here some
more
On 12/18/2012 01:40 PM, Iain Buclaw wrote:
I only accept beer payments. :o)
Bounties going on your tab at your pub(s) of choice? :-)
Is there an optimal pints:work ratio that we should take into account?
On Tuesday, 18 December 2012 at 12:36:31 UTC, Andrej Mitrovic
wrote:
On 12/18/12, foobar f...@bar.com wrote:
Besides, the other compilers merge in the same front-end
code so they'll gain the same feature anyway. There's no gain
in
separating it out to rdmd.
Adding more front-end features
On 18 December 2012 13:23, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 12/18/2012 01:40 PM, Iain Buclaw wrote:
I only accept beer payments. :o)
Bounties going on your tab at your pub(s) of choice? :-)
Is there an optimal pints:work ratio that we should take into
On Tuesday, 18 December 2012 at 11:43:18 UTC, foobar wrote:
On Monday, 17 December 2012 at 22:24:00 UTC, Walter Bright
wrote:
On 12/17/2012 2:08 PM, Dmitry Olshansky wrote:
I really loved the way Turbo Pascal units were made. I wish D
go the same
route. Object files would then be looked at as
On 12/18/12, Iain Buclaw ibuc...@ubuntu.com wrote:
I'd like to get the core developers of D Front-end to
work with the people maintaining other such compilers (GDC, LDC,
and any others that might come into existance) so that there can
genuinely be a shared, portable source base for the D
On 12/18/2012 02:43 PM, Iain Buclaw wrote:
You mean, the Ballmer peak for blood alcohol concentration?
Yes, experimental confirmation of this would be welcome. :-)
On 18 December 2012 14:07, Andrej Mitrovic andrej.mitrov...@gmail.comwrote:
On 12/18/12, Iain Buclaw ibuc...@ubuntu.com wrote:
I'd like to get the core developers of D Front-end to
work with the people maintaining other such compilers (GDC, LDC,
and any others that might come into
On 18 December 2012 14:25, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 12/18/2012 02:43 PM, Iain Buclaw wrote:
You mean, the Ballmer peak for blood alcohol concentration?
Yes, experimental confirmation of this would be welcome. :-)
Get me a year's supply of whiskey,
On 12/18/2012 5:32 AM, Gor Gyolchanyan wrote:
Good day, fellow D developers.
After spending much time figuring out how to make DMD work fluently under 64-bit
Windows 7 I've realized that this is not a trivial task and lots of people might
have trouble with this, so I've decided to post my
On 12/18/2012 1:33 AM, Dmitry Olshansky wrote:
More then that - the end result is the same: to avoid carrying junk into an app
you (or compiler) still have to put each function in its own section.
That's what COMDATs are.
Doing separate compilation I always (unless doing LTO or template
On 12/18/2012 3:43 AM, foobar wrote:
Honest question - If D already has all the semantic info in COMDAT sections,
It doesn't. COMDATs are object file sections. They do not contain type info, for
example.
* provide a byte-code solution to support the portability case. e.g Java
byte-code
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does not look up every (or any) name in the symbol table. I don't see any
advantage to
On 12/18/2012 7:06 AM, Walter Bright wrote:
On 12/18/2012 5:34 AM, Iain Buclaw wrote:
I'll let you all brood over that though, and would welcome any feedback to get
some sort of plan rolling (even if it's just a DIP).
I'm open to pull requests which abstract away some of the differences.
On 12/18/2012 5:34 AM, Iain Buclaw wrote:
I'll let you all brood over that though, and would welcome any feedback to get
some sort of plan rolling (even if it's just a DIP).
I'm open to pull requests which abstract away some of the differences.
Now that UDA's have extended their support to @attribute
https://github.com/D-Programming-Language/dmd/commit/0814f9decfdbcef644c4e89b02b8be192ed2e900
Should we take this as an opportunity for other compiler
maintainers to implement their own compiler-specific predefined
attributes?
On 18 December 2012 15:19, Iain Buclaw ibuc...@ubuntu.com wrote:
Potentially this can now be re-written as.
void die() @noreturn
{
abort();
}
By the way, this would be the first time that @noreturn has been brought up.
http://forum.dlang.org/thread/i9p9li$282u$1...@digitalmars.com
On 12/18/2012 07:52 AM, Xinok wrote:
While Smoothsort may be mathematically sound, it simply doesn't translate well
to computer hardware. It's a variant of heap sort which requires a great deal of
random access, whereas Timsort is a variant of merge sort which is largely
sequential and benefits
On 18 December 2012 15:24, Iain Buclaw ibuc...@ubuntu.com wrote:
On 18 December 2012 15:19, Iain Buclaw ibuc...@ubuntu.com wrote:
Potentially this can now be re-written as.
void die() @noreturn
{
abort();
}
By the way, this would be the first time that @noreturn has been brought
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
Should we take this as an opportunity for other compiler
maintainers to implement their own compiler-specific predefined
attributes?
I think it'd be great if we used magical full names, but
otherwise it is the same as the
Joseph Rushton Wakeling:
... but I would guess that given the O(1) memory requirements
it probably scales much better to sorting really, really large
data, no?
Why?
Bye,
bearophile
On 12/18/2012 04:30 PM, bearophile wrote:
Why?
Because if you have to allocate O(n) memory for another algorithm, that might
either give you a memory hit that you can't take (less likely these days, to be
fair), or simply take a large amount of time to allocate that degrades the
On 18 December 2012 15:29, Adam D. Ruppe destructiona...@gmail.com wrote:
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
Should we take this as an opportunity for other compiler maintainers to
implement their own compiler-specific predefined attributes?
I think it'd be
Iain Buclaw:
Where GDC has the following to allow developers to mark
functions with the backend attribute 'noreturn'.
pragma(attribute, noreturn)
void die()
{
abort();
}
Potentially this can now be re-written as.
void die() @noreturn
{
abort();
}
Would you guys stand for such a
On Tue, Dec 18, 2012 at 06:55:34AM -0800, Walter Bright wrote:
On 12/18/2012 3:43 AM, foobar wrote:
Honest question - If D already has all the semantic info in COMDAT
sections,
It doesn't. COMDATs are object file sections. They do not contain
type info, for example.
* provide a
On Tue, Dec 18, 2012 at 07:01:28AM -0800, Walter Bright wrote:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every
name in symbol table?), creating fake nodes when the result is
computed etc?
CTFE does not look up every (or any)
On 12/18/12 5:50 AM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 06:52:27 UTC, Xinok wrote:
On another note, I highly doubt that std::sort uses a median of
medians algorithm, which would add much overhead and essentially
double the number of comparisons required with little to no
On 12/18/2012 7:51 AM, H. S. Teoh wrote:
An idea occurred to me while reading this. What if, when compiling a
module, say, the compiler not only emits object code, but also
information like which functions are implied to be strongly pure, weakly
pure, @safe, etc., as well as some kind of symbol
On 12/18/2012 7:48 AM, bearophile wrote:
Is this name clashing acceptable?
Yes.
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
Should we take this as an opportunity for other compiler
maintainers to implement their own compiler-specific predefined
attributes?
Please, no!
Suppose GDC implements @noreturn (or whatever other attribute)
Later, LDC
On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander
wrote:
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
Should we take this as an opportunity for other compiler
maintainers to implement their own compiler-specific
predefined attributes?
Please, no!
Before
12/18/2012 6:51 PM, Walter Bright пишет:
On 12/18/2012 1:33 AM, Dmitry Olshansky wrote:
More then that - the end result is the same: to avoid carrying junk
into an app
you (or compiler) still have to put each function in its own section.
That's what COMDATs are.
Okay..
Doing separate
On 12/18/12 10:01 AM, Walter Bright wrote:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name
in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does not look up every (or any) name in the symbol
On 18 December 2012 16:43, Peter Alexander peter.alexander...@gmail.comwrote:
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
Should we take this as an opportunity for other compiler maintainers to
implement their own compiler-specific predefined attributes?
Please, no!
On 18 December 2012 16:58, Iain Buclaw ibuc...@ubuntu.com wrote:
On 18 December 2012 16:43, Peter Alexander
peter.alexander...@gmail.comwrote:
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
Should we take this as an opportunity for other compiler maintainers to
implement
12/18/2012 7:01 PM, Walter Bright пишет:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name
in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does not look up every (or any) name in the symbol table.
I remember a time, years ago (2008?), when he would pester everyone here
and had a reputation for finding bugs and *never reporting them*. People
used to tssk-tssk him on this.
Now, wow :)
Congratulations, bearophile!
Now, the real question is, what will be bug #10_000? We should let him have
On 12/18/2012 8:48 AM, Dmitry Olshansky wrote:
After dropping debug info I can't yet make heads or tails of what's in the exe
yet but it _seems_ to not include all of the unused code. Gotta investigate on a
smaller sample.
Generate a linker .map file (-map to dmd). That'll tell you what's in
On Tuesday, 18 December 2012 at 10:48:07 UTC, Don Clugston wrote:
Congratulations, Bugbear!
Congrats, bearophile! (What a loser I am...)
On 12/18/2012 8:54 AM, Andrei Alexandrescu wrote:
On 12/18/12 10:01 AM, Walter Bright wrote:
On 12/18/2012 1:43 AM, Dmitry Olshansky wrote:
Compared to doing computations on AST tries (and looking up every name
in symbol
table?), creating fake nodes when the result is computed etc?
CTFE does
I noticed that this doesn't work with the latest DMD from github:
import std.typetuple;
struct Foo{}
struct Bar{}
alias TypeTuple!(Foo, Bar) FooBar;
@FooBar
void foo(){}
pragma(msg, __traits(getAttributes, foo));
When trying to compile this, the compiler prints:
a.d(6): Error: cannot form
On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
But adequate bytecode designed for interpreters (see e.g. Lua) are designed for
faster execution. The way CTFE is done now* is a polymorphic call per AST-node
that does a lot of analysis that could be decided once and stored in ... *ehm*
... IR.
On 12/18/2012 4:35 AM, bearophile wrote:
in general the
naming choice of D is better than Rust.
A red letter day for D! Bearophile says that D does something better than some
other language!
:-)
Greetings
I thought I would be able to use allMembers/getMembers traits to access the
attributes of all the members of a class. But that fails me if some members
of the class are private.
Consider the code pasted below -- I get en error:
B.d(5): Error: class A.Foo member bar is not accessible
On Tue, Dec 18, 2012 at 08:12:51AM -0800, Walter Bright wrote:
On 12/18/2012 7:51 AM, H. S. Teoh wrote:
An idea occurred to me while reading this. What if, when compiling a
module, say, the compiler not only emits object code, but also
information like which functions are implied to be
On Tuesday, 18 December 2012 at 16:58:32 UTC, Iain Buclaw wrote:
Provide a situation where @noreturn attribute would mean
anything other
than telling the compiler to assume that the function cannot
return, and I
might please you on *that* particular attribute.
On *that* particular attribute,
On Tue, Dec 18, 2012 at 09:30:40AM -0800, Walter Bright wrote:
On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
[...]
Another point is that pointer chasing data-structures is not a recipe
for fast repeated execution.
To provide an analogy: executing calculation recursively on AST tree
of
On 12/18/2012 9:42 AM, H. S. Teoh wrote:
I was thinking more along the lines of things like fully automatic
purity, safety, exception inference. For example, every function body
eventually has to be processed by the compiler, so if a particular
function is inferred to throw exception X, for
On Tuesday, 18 December 2012 at 17:31:49 UTC, jerro wrote:
I noticed that this doesn't work with the latest DMD from
github:
import std.typetuple;
struct Foo{}
struct Bar{}
alias TypeTuple!(Foo, Bar) FooBar;
@FooBar
void foo(){}
pragma(msg, __traits(getAttributes, foo));
When trying to
On 12/18/2012 9:49 AM, H. S. Teoh wrote:
Is it too late to change CTFE to work via native code?
No, because doing so involves zero language changes. It is purely a
quality-of-implementation issue.
Besides the
effort required to rework the existing code (and perhaps the
cross-compiling
An interesting datapoint in regards to bytecode is Javascript. Note that
Javascript is not distributed in bytecode form. There is no Javascript VM. It is
distributed as source code. Sometimes, that source code is compressed and
obfuscated, nevertheless it is still source code.
How the end
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
I suspect there are other languages that do so, too.
Including (a buggy, incomplete subset of) D!
https://github.com/adamdruppe/dmd/tree/dtojs
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript.
Note that Javascript is not distributed in bytecode form. There
is no Javascript VM. It is distributed as source code.
Sometimes, that source code is compressed and
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
Javascript proves that bytecode is not required for write
once, run everywhere, which was one of the pitches for
bytecode.
What is required for w.o.r.e. is a specification for the source
code that precludes undefined and
On Tuesday, 18 December 2012 at 18:22:40 UTC, Max Samukha wrote:
Actually, they call JavaScript an IL for the next ten years.
s/an/the
On Tuesday, 18 December 2012 at 16:47:37 UTC, Peter Alexander
wrote:
On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander
wrote:
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw
wrote:
Should we take this as an opportunity for other compiler
maintainers to implement their own
On *that* particular attribute, I will accept that there isn't
much you could do differently from a theoretical standardised
version. The problem is, as soon as you add one compiler
specific attribute, it will be used as a precedence for adding
others.
You could just name compiler specific
On Tue, Dec 18, 2012 at 09:55:57AM -0800, Walter Bright wrote:
On 12/18/2012 9:42 AM, H. S. Teoh wrote:
I was thinking more along the lines of things like fully automatic
purity, safety, exception inference. For example, every function body
eventually has to be processed by the compiler, so if
On Tuesday, 18 December 2012 at 19:08:06 UTC, deadalnix wrote:
On Tuesday, 18 December 2012 at 16:47:37 UTC, Peter Alexander
wrote:
On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander
wrote:
On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw
wrote:
Should we take this as an
On 12/18/2012 10:29 AM, Peter Alexander wrote:
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
Javascript proves that bytecode is not required for write once, run
everywhere, which was one of the pitches for bytecode.
What is required for w.o.r.e. is a specification for the
On Tue, Dec 18, 2012 at 10:06:43AM -0800, Walter Bright wrote:
On 12/18/2012 9:49 AM, H. S. Teoh wrote:
Is it too late to change CTFE to work via native code?
No, because doing so involves zero language changes. It is purely a
quality-of-implementation issue.
Well, that much is obvious; I
On Tue, Dec 18, 2012 at 10:11:37AM -0800, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript. Note
that Javascript is not distributed in bytecode form. There is no
Javascript VM. It is distributed as source code. Sometimes, that
source code is compressed and
There is Emscripten which compiles LLVM to javascript, so you
could probably get D into JS like that also
https://github.com/kripken/emscripten
12/18/2012 9:30 PM, Walter Bright пишет:
On 12/18/2012 8:57 AM, Dmitry Olshansky wrote:
But adequate bytecode designed for interpreters (see e.g. Lua) are
designed for
faster execution. The way CTFE is done now* is a polymorphic call per
AST-node
that does a lot of analysis that could be
On 2012-12-18 17:48, Dmitry Olshansky wrote:
I'm using objconv by Agner Fog as I haven't got dumpobj (guess I'll buy
it if need be).
dumpobj is included in the DMD release, at least on Mac OS X.
--
/Jacob Carlborg
12/19/2012 12:01 AM, Jacob Carlborg пишет:
On 2012-12-18 17:48, Dmitry Olshansky wrote:
I'm using objconv by Agner Fog as I haven't got dumpobj (guess I'll buy
it if need be).
dumpobj is included in the DMD release, at least on Mac OS X.
And linux has it. Guess Windows sucks ...
--
Dmitry
Am Tue, 18 Dec 2012 20:06:16 +0100
schrieb jerro a...@a.com:
You could also define them in compiler
specific modules as has already been discussed in this thread,
but then code that used them without full names (including the
module name) would break if an attribute with the same name was
On Tuesday, 18 December 2012 at 12:42:23 UTC, Andrej Mitrovic
wrote:
On 12/18/12, Don Clugston d...@nospam.com wrote:
Bearophile has just entered his 1000th bug report into
Bugzilla.
I love his comment in the first report:
http://d.puremagic.com/issues/show_bug.cgi?id=3813
quote
This is my
On 2012-12-18 19:11, Walter Bright wrote:
Note also that Typescript compiles to Javascript. I suspect there are
other languages that do so, too.
CoffeeScript and Dart to mention two other languages that compile to
JavaScript.
--
/Jacob Carlborg
On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
An interesting datapoint in regards to bytecode is Javascript.
Note that Javascript is not distributed in bytecode form. There
is no Javascript VM. It is distributed as source code.
Sometimes, that source code is compressed and
On Tuesday, 18 December 2012 at 10:08:12 UTC, Jonathan M Davis
wrote:
We're probably stuck with std.algorithm allowing implict
conversions to bool
due to the fact that a fair bit of it has accepted that for a
while, but
accepting anything which explictly casts to bool would be
tantamount to
On 12/18/2012 08:26 PM, H. S. Teoh wrote:
On Tue, Dec 18, 2012 at 10:06:43AM -0800, Walter Bright wrote:
On 12/18/2012 9:49 AM, H. S. Teoh wrote:
Is it too late to change CTFE to work via native code?
No, because doing so involves zero language changes. It is purely a
On Tuesday, 18 December 2012 at 19:23:18 UTC, Peter Alexander
wrote:
I think this should be advertised that such a feature is in
some GDC's specific module, and that it can clash with any
library symbol at any time, as it is not a standardized
feature of the language.
Doesn't matter
1 - 100 of 238 matches
Mail list logo
