On Sat, 2013-03-02 at 12:52 -0800, Walter Bright wrote:
On 3/2/2013 12:08 PM, H. S. Teoh wrote:
On Sat, Mar 02, 2013 at 12:02:08PM -0800, Walter Bright wrote:
On 3/2/2013 11:42 AM, Russel Winder wrote:
On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
On 3/2/2013 7:43 AM, Russel
03-Mar-2013 12:03, Russel Winder пишет:
On Sat, 2013-03-02 at 12:52 -0800, Walter Bright wrote:
On 3/2/2013 12:08 PM, H. S. Teoh wrote:
On Sat, Mar 02, 2013 at 12:02:08PM -0800, Walter Bright wrote:
On 3/2/2013 11:42 AM, Russel Winder wrote:
On Sat, 2013-03-02 at 11:30 -0800, Walter Bright
Am 03.03.2013 08:55, schrieb Jonathan M Davis:
On Saturday, March 02, 2013 09:36:37 Jonathan M Davis wrote:
On Saturday, March 02, 2013 15:07:33 Sönke Ludwig wrote:
The docs target was just a quick draft added to have meaningful list
of standard built types and hasn't really been tested. I'll
On Sunday, 3 March 2013 at 08:03:53 UTC, Russel Winder wrote:
Yes because the C/C++/D/etc. compilers are attempting to
predict the
control flow of the program in execution and optimize all cases
for all
possibilities. JIT's are just focussing on the runtime
bottlenecks with
the actual data as
I really like this and never never understood reason behind
automatically generated .di files, as much as difficulties with
separation of interface and implementation. If there is one thing
that prevents me to say that D module system is 100% better than
C++ - here it is. If there is something
On Sunday, 3 March 2013 at 05:48:30 UTC, Walter Bright wrote:
On 3/2/2013 8:36 PM, js.mdnq wrote:
On Saturday, 2 March 2013 at 23:09:57 UTC, Walter Bright wrote:
On 3/2/2013 3:00 PM, Andrej Mitrovic wrote:
On 3/2/13, Dicebot m.stras...@gmail.com wrote:
Wow, I have never known something like
On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
Regarding CTFE - it is a reason to not use this layout for
generic algorithm libraries and similar stuff, but there is no
point in allowing application module code for CTFE by an
accident.
It is the virtual vs final by default argument.
Mini thing: Redirect.none is not documented
On Sunday, 3 March 2013 at 11:03:55 UTC, deadalnix wrote:
On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
Regarding CTFE - it is a reason to not use this layout for
generic algorithm libraries and similar stuff, but there is no
point in allowing application module code for CTFE by an
On 3/3/2013 12:03 AM, Russel Winder wrote:
Yes because the C/C++/D/etc. compilers are attempting to predict the
control flow of the program in execution and optimize all cases for all
possibilities. JIT's are just focussing on the runtime bottlenecks with
the actual data as being used. This
On Tuesday, 26 February 2013 at 18:48:08 UTC, Jonathan M Davis
wrote:
On Tuesday, February 26, 2013 09:02:11 Steven Schveighoffer
wrote:
On one hand, I think the correct behavior is to return null,
and let the
program deal with checking the error, or use get if they have
a default.
If we throw
Walter Bright:
and I have trouble thinking of any significant improvements to
code gen that could be made with runtime data.
I've seen that the JavaHotSpot is able to unroll loops with a
length known only at run-time. It unrolls them only when the
run-time statistics say it's advantageous.
When modules are initialized, druntime will first run the module
initializers before running the module tls initializers ignoring the
dependencies between the modules. This will lead to a access of a
unitialized module if the module ctor of one module uses tls data of
another module. Example:
Really what is needed is gc arrays and ngc arrays as well as
other essential features. e.g., gc arrays would not be part of
the core spec while ngc arrays would.
You can already use slices without a gc, like this:
T[] allocate(T)(int n)
{
return (cast(T*) malloc(T.sizeof * n))[0 .. n];
}
On Sunday, March 03, 2013 12:11:16 deadalnix wrote:
On Tuesday, 26 February 2013 at 18:48:08 UTC, Jonathan M Davis
I think that it's far more correct to say that exceptions are
for situations
where it's reasonable for code to assume that something's the
case when it
might not be or when
On 20 February 2013 02:03, bearophile bearophileh...@lycos.com wrote:
Don:
Simd comparison generally doesn't return a bool, it returns a bool array,
one per element.
Does (arr[] 10) mean is every element in arr less than 10 OR is any
element of arr less than 10 OR create a bool array
On Sunday, 3 March 2013 at 11:08:33 UTC, Dicebot wrote:
On Sunday, 3 March 2013 at 11:03:55 UTC, deadalnix wrote:
On Sunday, 3 March 2013 at 10:47:34 UTC, Dicebot wrote:
Regarding CTFE - it is a reason to not use this layout for
generic algorithm libraries and similar stuff, but there is
no
On Sunday, 3 March 2013 at 13:19:35 UTC, deadalnix wrote:
...
Ah, beg my pardon, misunderstood you a bit. Still, difference I
am trying to point is that virtual vs final does not rely on
actual method implementation at all, while proper CTFE function
needs to be written with CTFE in mind as
Manu:
If you want to do component-wise logic,
the typical approach is to use component-wise selection, eg:
uint4 mask = compareGreater(a, b); // - build a bit mask of
0's (false)
Isn't something like this better?
uint4 mask = a b;
Bye,
bearophile
I don't think opCmp can fit that model?
But aside from that, I think that's misleading, and suggests to the user
that it's a trivial operation.
Additionally, it's not necessarily even possible in a portable way.
I also think most users would expect that comparison operators produce a
boolean
On Mar 3, 2013 10:56 AM, Dicebot m.stras...@gmail.com wrote:
On Sunday, 3 March 2013 at 05:48:30 UTC, Walter Bright wrote:
On 3/2/2013 8:36 PM, js.mdnq wrote:
On Saturday, 2 March 2013 at 23:09:57 UTC, Walter Bright wrote:
On 3/2/2013 3:00 PM, Andrej Mitrovic wrote:
On 3/2/13, Dicebot
Hi people.
So I've been AWOL a while, and I'll still be intermittent for some weeks
yet, but I'm trying to work on std.simd and also my dconf talks in any gaps
I can.
However, in order to do a thorough job, I'm missing some tools. I wonder if
anyone can help me out...?
I need to do some rather
On Saturday, 2 March 2013 at 18:48:37 UTC, Dicebot wrote:
On Saturday, 2 March 2013 at 17:26:52 UTC, js.mdnq wrote:
For the same reason that most embedded languages use C and not
C++. Obviously it is easier to implement a subset of something
than the full set(at the very least, less work).
On Sunday, 3 March 2013 at 11:57:36 UTC, bearophile wrote:
Walter Bright:
and I have trouble thinking of any significant improvements to
code gen that could be made with runtime data.
I've seen that the JavaHotSpot is able to unroll loops with a
length known only at run-time. It unrolls
On Sunday, 3 March 2013 at 13:56:57 UTC, Iain Buclaw wrote:
I intend to fix this problem in gdc at least by removing
_tlsstart and
_tlsend from the library.
Regards
Ugh, which problem are you speaking about? betterC flag is not
working properly in gdc or what?
On Mar 3, 2013 1:58 PM, Manu turkey...@gmail.com wrote:
Hi people.
So I've been AWOL a while, and I'll still be intermittent for some weeks
yet, but I'm trying to work on std.simd and also my dconf talks in any gaps
I can.
However, in order to do a thorough job, I'm missing some tools. I
I know that GDC and LDC can produce ARM code, but what about D runtime -
does it work reliably?
GCC has min and max operators, and the syntax is very clever:
min = a ? b;
max = a ? b;
Ie, a shorthand of the ?: operator, in a similar way that C# has '??'
(another really nice shorthand).
On 2 March 2013 10:20, bearophile bearophileh...@lycos.com wrote:
Maybe #* #max #min? (Also usable
On 2 March 2013 07:51, Paul D. Anderson
paul.d.removethis.ander...@comcast.andthis.net wrote:
1. They are hard to type or otherwise enter in to a text file.
I have × and ÷ on my keyboard; it's AltGr + '='/'+', no center-dot though :(
I've always wanted those 2 operators! Sadly ascii just
On Mar 3, 2013 2:21 PM, Dicebot m.stras...@gmail.com wrote:
On Sunday, 3 March 2013 at 13:56:57 UTC, Iain Buclaw wrote:
I intend to fix this problem in gdc at least by removing _tlsstart and
_tlsend from the library.
Regards
Ugh, which problem are you speaking about? betterC flag is not
Yes, all of them (and more, bonus points for PS3's Cell PPE/SPU
toolchains!) :)
But I don't really need to run it... I just tend to compile with -S. I know
what the resulting code should look like from years of experience.
I can easily verify the proper opcodes are emitted, register assignment is
On 2013-03-02 17:48, John Colvin wrote:
It does.
Failing to beat mature, optimised C is not anything to be ashamed of,
but being slower than python would be an abject failure of D as a
compiled, systems programming language.
Then D needs to get faster, or we need to switch to C for some std
On 2013-03-02 20:27, Walter Bright wrote:
In D, you can write custom versions of algorithms to exploit unique
characteristics of particular data structures. I don't regard that as a
failure.
If you use the most obvious function/way from the standard library to
perform a task in Python and
On Sunday, 3 March 2013 at 12:01:10 UTC, Benjamin Thaut wrote:
Is this a bug, or is this intended beahvior? I always believed
that with all the dependency detenction that is done such
situation should not happen.
It's intended behaviour.
Remember that shared static this() is only run once
On Sunday, 3 March 2013 at 15:09:58 UTC, Jacob Carlborg wrote:
On 2013-03-02 17:48, John Colvin wrote:
It does.
Failing to beat mature, optimised C is not anything to be
ashamed of,
but being slower than python would be an abject failure of D
as a
compiled, systems programming language.
On Sunday, 3 March 2013 at 12:05:00 UTC, jerro wrote:
Really what is needed is gc arrays and ngc arrays as well as
other essential features. e.g., gc arrays would not be part of
the core spec while ngc arrays would.
You can already use slices without a gc, like this:
T[] allocate(T)(int n)
{
Am 03.03.2013 16:29, schrieb Peter Alexander:
On Sunday, 3 March 2013 at 12:01:10 UTC, Benjamin Thaut wrote:
Is this a bug, or is this intended beahvior? I always believed that
with all the dependency detenction that is done such situation should
not happen.
It's intended behaviour.
Remember
On Sunday, 3 March 2013 at 13:24:39 UTC, Dicebot wrote:
On Sunday, 3 March 2013 at 13:19:35 UTC, deadalnix wrote:
...
Ah, beg my pardon, misunderstood you a bit. Still, difference I
am trying to point is that virtual vs final does not rely on
actual method implementation at all, while
On Sunday, 3 March 2013 at 07:27:51 UTC, Daniel Murphy wrote:
Now you're as up-to-date as I am on what I'm thinking.
I did something like that before (token-level pattern matching)
and found
the number of special cases to be much much too high. You need
so much
context information you're
auto objectSource = new FileSource(../libs/object.d);
auto object = lex!((line, index, length) {
import std.stdio;
writeln(new location 2 ! , cast(void*) objectSource);
return Location(objectSource, line, index, length);
})(objectSource.content);
Running this, I
On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
auto objectSource = new FileSource(../libs/object.d);
auto object = lex!((line, index, length) {
import std.stdio;
writeln(new location 2 ! , cast(void*) objectSource);
return Location(objectSource, line,
I could probably get you a bare bones compiler (no library) - it *will* be
Linux though... I can give you a login to a server if you like to play
with it. Otherwise I could give cygwin a try...
Regards
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
On Mar 3, 2013 2:58 PM, Manu
On Sunday, 3 March 2013 at 16:51:15 UTC, Iain Buclaw wrote:
Is this a dmd thing, or does it affect other compilers? (don't
have a laptop to test at the moment).
I don't know, the code is not compilable with 2.060 (or 2.061) so
I'm unable to test how gdc does on that one.
On Mar 3, 2013 5:01 PM, deadalnix deadal...@gmail.com wrote:
On Sunday, 3 March 2013 at 16:51:15 UTC, Iain Buclaw wrote:
Is this a dmd thing, or does it affect other compilers? (don't have a
laptop to test at the moment).
I don't know, the code is not compilable with 2.060 (or 2.061) so I'm
On Sunday, 3 March 2013 at 17:03:24 UTC, Iain Buclaw wrote:
On Mar 3, 2013 5:01 PM, deadalnix deadal...@gmail.com wrote:
On Sunday, 3 March 2013 at 16:51:15 UTC, Iain Buclaw wrote:
Is this a dmd thing, or does it affect other compilers?
(don't have a
laptop to test at the moment).
I
Am Sun, 3 Mar 2013 23:33:27 +1000
schrieb Manu turkey...@gmail.com:
Hi people.
So I've been AWOL a while, and I'll still be intermittent for some
weeks yet, but I'm trying to work on std.simd and also my dconf talks
in any gaps I can.
However, in order to do a thorough job, I'm missing
On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
auto objectSource = new FileSource(../libs/object.d);
auto object = lex!((line, index, length) {
import std.stdio;
writeln(new location 2 ! , cast(void*) objectSource);
return Location(objectSource, line,
Am Sun, 03 Mar 2013 15:21:30 +0100
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
I know that GDC and LDC can produce ARM code, but what about D
runtime - does it work reliably?
I'm not sure if anyone did extensive testing. I compiled used
dustmite on the raspberry pi and that worked well
On Mar 3, 2013 5:46 PM, Johannes Pfau nos...@example.com wrote:
Am Sun, 03 Mar 2013 15:21:30 +0100
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
I know that GDC and LDC can produce ARM code, but what about D
runtime - does it work reliably?
I'm not sure if anyone did extensive testing. I
On Sunday, 3 March 2013 at 05:48:30 UTC, Walter Bright wrote:
...
Yes, and those will fail to link.
Ok, checked this out. While it is cool that you can get all fat
stuff out and get your hello world of the same binary size as
plain C one, resulting language is actually less usable than C
On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
On 2013-03-02 17:48, John Colvin wrote:
It does.
Failing to beat mature, optimised C is not anything to be ashamed of,
but being slower than python would be an abject failure of D as a
compiled, systems programming language.
Then D needs to get
On 3/3/2013 7:07 AM, Jacob Carlborg wrote:
If you use the most obvious function/way from the standard library to perform a
task in Python and you do the same in D. If the D version is slower that's not
good.
Sure. But you should be cognizant of exactly what it is you're comparing, or
you're
On Sun, 03 Mar 2013 15:50:10 +0100, Manu turkey...@gmail.com wrote:On 2 March 2013 07:51, Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net wrote:
1. They are hard to type or otherwise enter in to a text file.
I have × and ÷ on my keyboard; it's AltGr + '='/'+', no center-dot though
How does Dan build the MinGW toolchains?
No library is fine for my purposes.
I don't have access to a linux machine atm, but I should do in a week or 2.
If that's the only option, then I can wait till then... just leaves me with
a bit less time.
On 4 March 2013 02:57, Iain Buclaw
Andrei Alexandrescu:
Gone. http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html
Do you know why?
Those ? ? look nice enough, and maybe they are worth adding to
D.
But it's also useful to keep max and min as free functions
because they are useful for higher-order functions (and
On Mar 3, 2013 10:48 PM, Manu turkey...@gmail.com wrote:
How does Dan build the MinGW toolchains?
No library is fine for my purposes.
I don't have access to a linux machine atm, but I should do in a week or
2. If that's the only option, then I can wait till then... just leaves me
with a bit
On Mar 3, 2013 9:41 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org
wrote:
On 3/3/13 9:42 AM, Manu wrote:
GCC has min and max operators, and the syntax is very clever:
min = a ? b;
max = a ? b;
Ie, a shorthand of the ?: operator, in a similar way that C# has '??'
(another
Those ? ? look nice enough, and maybe they are worth adding
to D.
But they are not essential.
Maybe they were removed because they are too much non-standard.
It's like and and or: and and or are much better than
and ||, but adding them to just one compiler, and keeping
the older operators
On Sunday, 3 March 2013 at 22:58:02 UTC, bearophile wrote:
Andrei Alexandrescu:
Gone.
http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html
Do you know why?
Probably because they were non-standard, but don't look
non-standard. It's not fun finding them in code that you want to
On Sunday, 3 March 2013 at 16:07:58 UTC, Benjamin Thaut wrote:
Am 03.03.2013 16:29, schrieb Peter Alexander:
On Sunday, 3 March 2013 at 12:01:10 UTC, Benjamin Thaut wrote:
Is this a bug, or is this intended beahvior? I always
believed that
with all the dependency detenction that is done such
x86 and x64 are already available. I've seen ARM builds kicking around too
which I've already done some work with. I'm not sure if they're up to date,
but it's probably fine for me to use.
Linux or bare metal + no library for the others will suit me now.
Whatever's easiest.
Google seem to have a
Cool, well that'll definitely help! :)
On 4 March 2013 09:02, Iain Buclaw ibuc...@ubuntu.com wrote:
On Mar 3, 2013 10:48 PM, Manu turkey...@gmail.com wrote:
How does Dan build the MinGW toolchains?
No library is fine for my purposes.
I don't have access to a linux machine atm, but I
...it occurs to me that MIPS doesn't really have a single standardised SIMD
instruction set.
There are a few extensions. I've worked on 3 popular MIPS devices; they all
have SIMD, but they are all different.
I'm not sure they are available as options in the standard GCC MIPS arch. I
think they
Nooo!
Why would they! ;)
Well I still think they're a great shorthand.
On 4 March 2013 07:38, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote:
On 3/3/13 9:42 AM, Manu wrote:
GCC has min and max operators, and the syntax is very clever:
min = a ? b;
max = a ? b;
Ie, a
On Sunday, 3 March 2013 at 17:03:24 UTC, Iain Buclaw wrote:
On Mar 3, 2013 5:01 PM, deadalnix deadal...@gmail.com wrote:
On Sunday, 3 March 2013 at 16:51:15 UTC, Iain Buclaw wrote:
Is this a dmd thing, or does it affect other compilers?
(don't have a
laptop to test at the moment).
I
On Sunday, 3 March 2013 at 17:27:52 UTC, Maxim Fomin wrote:
On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
auto objectSource = new FileSource(../libs/object.d);
auto object = lex!((line, index, length) {
import std.stdio;
writeln(new location 2 ! , cast(void*)
On Sunday, 3 March 2013 at 20:18:58 UTC, Walter Bright wrote:
On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
On 2013-03-02 17:48, John Colvin wrote:
It does.
Failing to beat mature, optimised C is not anything to be
ashamed of,
but being slower than python would be an abject failure of D
as a
Zach the Mystic reachbutminusthisz...@googlymail.com wrote in message
news:kidboshnjpowpyqrt...@forum.dlang.org...
On Sunday, 3 March 2013 at 07:27:51 UTC, Daniel Murphy wrote:
Now you're as up-to-date as I am on what I'm thinking.
I did something like that before (token-level pattern
A bit of celebration is in order because step by step D is
becoming usable :-)
DMD 2.063 will have a significant improvement, this bug seems now
fixed:
http://d.puremagic.com/issues/show_bug.cgi?id=3825
This program:
import std.stdio;
void main() {
string[] words = [how, are, you,
Maybe it is time to look at the python implementation and see
why it is faster.
It isn't faster:
$ time python3 test.py
real0m14.217s
user0m14.209s
sys 0m0.004s
$ gdmd -O -inline -release -noboundscheck test
$ time ./test
real0m5.323s
user0m5.312s
sys 0m0.008s
D code
jerro:
$ time python3 test.py
Are Python3 strings still like wstrings/dstrings, or have they
applied the patch that makes them UTF8?
Bye,
bearophile
Dear D pros,
As a fan of D, I was hoping to be able to get similar results as
this fellow on stack overflow, by noting his tuning steps;
http://stackoverflow.com/questions/5142366/how-fast-is-d-compared-to-c
Sadly however, when I pull out a simple matrix multiplication
benchmark from the old
On Monday, 4 March 2013 at 03:20:57 UTC, jerro wrote:
Maybe it is time to look at the python implementation and see
why it is faster.
It isn't faster:
$ time python3 test.py
real0m14.217s
user0m14.209s
sys 0m0.004s
$ gdmd -O -inline -release -noboundscheck test
$ time ./test
On Monday, 4 March 2013 at 03:48:45 UTC, J wrote:
Dear D pros,
As a fan of D, I was hoping to be able to get similar results
as this fellow on stack overflow, by noting his tuning steps;
http://stackoverflow.com/questions/5142366/how-fast-is-d-compared-to-c
Sadly however, when I pull out a
Your benchmark code updated to D2:
http://codepad.org/WMgu6XQG
Bye,
bearophile
On Monday, 4 March 2013 at 04:12:18 UTC, bearophile wrote:
Your benchmark code updated to D2:
http://codepad.org/WMgu6XQG
Sorry, this line:
enum size_t SIZE = 200;
Should be:
enum size_t SIZE = 2_000;
Bye,
bearophile
John Colvin:
First things first:
You're not just timing the multiplication, you're timing the
memory allocation as well. I suggest using
http://dlang.org/phobos/std_datetime.html#StopWatch to do some
proper timings in D
Nope, what matters is the total program runtime.
Bye,
bearophile
So this should be better:
http://codepad.org/B5b4uyBM
Bye,
bearophile
Generally for such matrix benchmarks if you chose the compilation
flags really well (including link-time optimization!) I've seen
that with LDC you get good enough timings.
Bye,
bearophile
On 3/3/13 9:31 PM, deadalnix wrote:
On Sunday, 3 March 2013 at 20:18:58 UTC, Walter Bright wrote:
On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
On 2013-03-02 17:48, John Colvin wrote:
It does.
Failing to beat mature, optimised C is not anything to be ashamed of,
but being slower than python
On 3/3/13 10:48 PM, J wrote:
Dear D pros,
As a fan of D, I was hoping to be able to get similar results as this
fellow on stack overflow, by noting his tuning steps;
http://stackoverflow.com/questions/5142366/how-fast-is-d-compared-to-c
Sadly however, when I pull out a simple matrix
I suggest that you move this line
GC.disable;
to the first line.
I don't see how you are doing your timings so that part is a wild
card.
Also note that when the GC is re-enabled it can add a significant
amount of time to the tests. You are not explicitly re-enabling
the GC, but I don't
On Monday, 4 March 2013 at 04:22:01 UTC, bearophile wrote:
So this should be better:
http://codepad.org/B5b4uyBM
Bye,
bearophile
@bearophile: Thank you! Unfortunately the
http://codepad.org/B5b4uyBM code runs a bit *slower* than the
original D code. Yikes!
$ gdmd -O -inline -release
On 4 March 2013 14:50, J priv...@private-dont-email-dont-spam.com wrote:
On Monday, 4 March 2013 at 04:22:01 UTC, bearophile wrote:
So this should be better:
http://codepad.org/B5b4uyBM
Bye,
bearophile
@bearophile: Thank you! Unfortunately the http://codepad.org/B5b4uyBMcode
runs a
On Monday, 4 March 2013 at 04:36:30 UTC, Andrei Alexandrescu
wrote:
On 3/3/13 9:31 PM, deadalnix wrote:
On Sunday, 3 March 2013 at 20:18:58 UTC, Walter Bright wrote:
On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
On 2013-03-02 17:48, John Colvin wrote:
It does.
Failing to beat mature,
I remember you were talking about D top bug list (15 or 10).
Can you tell the whole list?
On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu
wrote:
A chat in IRC revealed a couple of possible improvements to the
development scenario in which the interface file (.di) is
managed manually and separately from the implementation file
(.d).
After discussing a few ideas with
+1_000_000_000
Yes please!
It's near impossible to get a brief overview of a class at a glance in D!
On 3 March 2013 15:35, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On Friday, 22 July 2011 at 22:06:20 UTC, Andrei Alexandrescu wrote:
1. The compiler shall accept method definitions
On Sunday, 3 March 2013 at 11:00:52 UTC, Sönke Ludwig wrote:
Mini thing: Redirect.none is not documented
Ok, thanks!
On Monday, 4 March 2013 at 02:10:12 UTC, deadalnix wrote:
On Sunday, 3 March 2013 at 17:27:52 UTC, Maxim Fomin wrote:
On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
auto objectSource = new FileSource(../libs/object.d);
auto object = lex!((line, index, length) {
import
On 2013-03-03 16:41, John Colvin wrote:
I agree that anything that makes us faster is good, but I wouldn't go so
far as to say we've failed if we're not as fast as the very fastest.
No, but if we need to drop down to C to get fast enough.
--
/Jacob Carlborg
On 2013-03-03 21:18, Walter Bright wrote:
Nothing in this thread suggests that D needs to switch its library
implementations to C.
Then that's good.
Interestingly, I tried the indexOf() benchmark using C's memchr() and
memcmp() from VC's runtime library. It was not faster than Andrei's
On 3/3/2013 11:38 PM, Jacob Carlborg wrote:
On 2013-03-03 16:41, John Colvin wrote:
I agree that anything that makes us faster is good, but I wouldn't go so
far as to say we've failed if we're not as fast as the very fastest.
No, but if we need to drop down to C to get fast enough.
I can't
On Monday, 4 March 2013 at 07:10:20 UTC, Maxim Fomin wrote:
No specific advice except for dropping everything except
FileSource definition and lex template. By the way, what is
objectSource.content? A tuple of line, index, length?
The problem is that lex is massive : it is a whole lexer.
On Monday, 4 March 2013 at 04:49:20 UTC, Andrei Alexandrescu
wrote:
You're measuring the speed of a couple of tight loops. The
smallest differences in codegen between them will be on the
radar. Use straight for loops or foreach (i; 0 .. limit) for
those loops...
Thanks Andrei!
I validated
Can anyone advise on the theoretical basis for the
unpredictableSeed method in std.random? I've tried googling
around for the theory of good thread-safe seed generation
methods but haven't really found anything. :-(
I have to ask: what would be a good unpredictableSeed by
definition? With
Am Sun, 03 Mar 2013 09:58:41 +0100
schrieb Ivan Kazmenko ga...@mail.ru:
Can anyone advise on the theoretical basis for the
unpredictableSeed method in std.random? I've tried googling
around for the theory of good thread-safe seed generation
methods but haven't really found anything.
03-Mar-2013 12:58, Ivan Kazmenko пишет:
Can anyone advise on the theoretical basis for the unpredictableSeed
method in std.random? I've tried googling around for the theory of
good thread-safe seed generation methods but haven't really found
anything. :-(
I have to ask: what would be a good
On 03/03/13 10:06, Johannes Pfau wrote:
Am Sun, 03 Mar 2013 09:58:41 +0100
schrieb Ivan Kazmenkoga...@mail.ru:
Can anyone advise on the theoretical basis for the
unpredictableSeed method in std.random? I've tried googling
around for the theory of good thread-safe seed generation
methods but
On 03/03/2013 09:58 AM, Ivan Kazmenko wrote:
I have to ask: what would be a good unpredictableSeed by definition? With the
current implementation, three downsides come to my mind:
1. Process ID, thread ID and system tick are insecure sources of randomness and
can provide just a few bits of
1 - 100 of 162 matches
Mail list logo
