On Wednesday, 12 December 2012 at 01:07:56 UTC, David Nadlinger
wrote:
After a long wait and many unexpected delays, there is finally
going to be a released version of LDC, the LLVM D compiler,
again! I'll keep this post short and (hopefully) sweet, a more
detailed announcement will follow
On 12/11/2012 09:33 PM, deadalnix wrote:
For once, I can come. So I will !
Woo hoo! :) Don't forget to say hi.
I suggest you also plan to join dinner afterwards, which almost always
includes the speaker.
See you and other Bay Area D people tonight... :)
Ali
On Wednesday, 12 December 2012 at 08:32:50 UTC, Peter Alexander
wrote:
On Wednesday, 12 December 2012 at 01:07:56 UTC, David Nadlinger
wrote:
After a long wait and many unexpected delays, there is finally
going to be a released version of LDC, the LLVM D compiler,
again! I'll keep this post
On Wednesday, 12 December 2012 at 07:36:22 UTC, Jacob Carlborg
wrote:
On 2012-12-12 02:07, David Nadlinger wrote:
After a long wait and many unexpected delays, there is finally
going to
be a released version of LDC, the LLVM D compiler, again!
Cool. Are there any plans to continue making
Good job. Compiles and passess all of the unittests of Tango-D2.
I'm extra glad that you fixed the installation instructions
too... the old ones were horrible.
-SiegeLord
Walter Bright wrote:
On 12/11/2012 10:35 PM, Han wrote:
Walter Bright wrote:
I'm interested in crafting D to be a language that people will like
and use.
Does that statement, then, represent a change in direction for the D
project? How long will this crafting take? Has this crafting been
On 12/11/2012 11:53 PM, Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
Many languages wander in the wilderness for years before they catch on.
BTW, many
12/12/2012 6:00 AM, Nick B пишет:
On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
On Monday, 10 December 2012 at 20:08:32 UTC, Andrei Alexandrescu wrote:
On 12/9/12 10:58 PM, Nick B wrote:
[about the Disruptor framework]
Would Andrei like to comment on any of the comments so far ??
Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
Many languages wander in the wilderness for years before they catch
on.
Wow (Wow!), it's like you were seeing
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts to do the computation and
assignment but then returns a bbyte instead of an int.
You should have no problems implicitly converting
Walter Bright wrote:
On 12/11/2012 11:53 PM, Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
Many languages wander in the wilderness for years before they
On 12/12/2012 12:07 AM, Han wrote:
So you are skirting the issue then, or going to come back and post a real
answer after you think about it some more?
Or are you just trolling and baiting?
Han wrote:
Walter Bright wrote:
On 12/11/2012 11:53 PM, Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch on.
Isn't D on that same historical path?
Many languages wander in the wilderness for years
12/12/2012 12:59 AM, Alex Rønne Petersen пишет:
[snip]
I'd mention that the most of idiomatic D code is agnostic with respect
to the origin of slice. The major reason to use slices is to avoid
allocations and thus the allocation scheme is not important up to the
point of explicit copy.
And at
On 12/12/2012 12:27 AM, Han wrote:
You KNOW that D has not been overlooked.
No, I don't know that. I just returned from a conference where few knew anything
at all about D, and were quite impressed by what I had to show.
Do you really think that D will ever have popularity to the level of
Hai :D I have seen your D program language on Google, it looks
cool! how much different is it to the C program language?
On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts to do the computation and
assignment but then returns a
On 2012-17-12 10:12, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts
On Wednesday, 12 December 2012 at 08:23:48 UTC, Simen Kjaeraas
wrote:
On 2012-09-12 00:12, js.mdnq js_adddot+m...@gmail.com wrote:
struct bbyte {
byte value;
...
}
bbyte a; bbyte b;
b = a + b; // uses bbyte's operators and casts to do the
computation and assignment but then returns a bbyte
I implement, say, a Matrix class, then I should be able to tell
the
compiler that certain Matrix expressions, say A*B+A*C, can be
factored
into A*(B+C), and have the optimizer automatically do this for
me based
on what is defined in the type. Or specify that
write(a);writeln(b);
can be
Am 11.12.2012 22:13, schrieb Andrei Alexandrescu:
On 12/11/12 3:54 PM, Rob T wrote:
On Monday, 10 December 2012 at 22:33:49 UTC, 1100110 wrote:
On 12/10/2012 05:16 AM, Mr. Anonymous wrote:
On Monday, 10 December 2012 at 02:10:43 UTC, Ellery Newcomer wrote:
Is anyone else noticing e.g.
On Wednesday, 12 December 2012 at 08:09:40 UTC, Dmitry Olshansky
wrote:
12/12/2012 6:00 AM, Nick B пишет:
On Monday, 10 December 2012 at 23:04:56 UTC, Nick B wrote:
[cut]
Ok, does anyone consider that this pattern, though not well
described,
has any value ?
Nick
It surely has.
Maybe,
On Wednesday, 12 December 2012 at 01:03:59 UTC, Rob T wrote:
On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
By support I meant specifically _bug fixes_. You can already
download all previous released versions from the website and
in no way am I arguing to change that policy.
Even
On Wednesday, 12 December 2012 at 00:43:39 UTC, H. S. Teoh wrote:
On Wed, Dec 12, 2012 at 01:26:08AM +0100, foobar wrote:
On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile
wrote:
foobar:
I would enforce overflow and underflow checking semantics.
Plus one or two switches to disable
On 12/12/2012 2:33 AM, foobar wrote:
This isn't a perfect solutions
since the compiler has builtin knowledge about int and does optimizations that
will be lost with a library type.
See my reply to bearophile about that.
On Wednesday, 12 December 2012 at 00:51:19 UTC, Walter Bright
wrote:
On 12/11/2012 3:44 PM, foobar wrote:
Thanks for proving my point. after all , you are a C++
developer, aren't you? :)
No, I'm an assembler programmer. I know how the machine works,
and C, C++, and D map onto that, quite
On Wednesday, 12 December 2012 at 10:35:26 UTC, Walter Bright
wrote:
On 12/12/2012 2:33 AM, foobar wrote:
This isn't a perfect solutions
since the compiler has builtin knowledge about int and does
optimizations that
will be lost with a library type.
See my reply to bearophile about that.
Arithmetic in computers is different from the math you learned
in school. It's 2's complement, and it's best to always keep
that in mind when writing programs.
From http://embed.cs.utah.edu/ioc/
Examples of undefined integer overflows we have reported:
An SQLite bug
Some problems in
foobar:
So basically you're suggesting to implement Integer and Word
library types using compiler intrinsics as a way to migrate to
better ML compatible semantics.
I think there were no references to ML in that part of Walter
answer.
Regarding performance and overflow checking, the
Araq:
So how does D improve on C's model?
There is some range analysis on shorter integral values. But
overall it shares the same troubles.
If signed integers are required to wrap around in D (no
undefined behaviour),
I think in D specs signed integers don't require the wrap-around
Machine/hardware have a explicitly defined register size and does
know nothing about sign and data type. fastest operation is
unsigned and fits to register size.
For example in your case, some algorithm that coded with
chained-if-checks may come unusable because it will slow.
And about C#
On 12-12-2012 09:30, Dmitry Olshansky wrote:
12/12/2012 12:59 AM, Alex Rønne Petersen пишет:
[snip]
I'd mention that the most of idiomatic D code is agnostic with respect
to the origin of slice. The major reason to use slices is to avoid
allocations and thus the allocation scheme is not
And about C# checked:
http://msdn.microsoft.com/ru-ru/library/74b4xzyw.aspx
By default it is only for constants. For expressions in runtime
it must be explicitly enabled.
en link: http://msdn.microsoft.com/en-us/library/74b4xzyw.aspx
On 11-12-2012 22:38, Rainer Schuetze wrote:
On 11.12.2012 22:08, Alex Rønne Petersen wrote:
On 11-12-2012 21:24, Rainer Schuetze wrote:
This stores the type info with the reference, not with the memory block,
but it does not make a big difference. (Actually it does: if the
reference only is
On Wednesday, 12 December 2012 at 02:44:42 UTC, Walter Bright
wrote:
UDAs are a primo example of this.
OT: Why those are not allowed on module decls and local decls? We
can't use UDAs on decls in unittest blocks. We can't use a UDA to
mark a module reflectable, can't put an attribute on a
On 12/11/12 8:20 PM, David Nadlinger wrote:
On Monday, 10 December 2012 at 00:47:09 UTC, Andrei Alexandrescu wrote:
It's official - http://wiki.dlang.org is our new wiki home.
Would anybody mind if I move the official LDC installation instructions
there? We currently have a few pages at the
On Wednesday, 12 December 2012 at 08:00:09 UTC, Walter Bright
wrote:
On 12/11/2012 11:53 PM, Walter Bright wrote:
On 12/11/2012 11:47 PM, Han wrote:
Walter Bright wrote:
ML has been around for 30-40 years, and has failed to catch
on.
Isn't D on that same historical path?
Many languages
On 12/12/12 1:37 AM, Jesse Phillips wrote:
There may be some helpful scripts to facilitate a new workflow, but the
examples given I feel just translate to learning a D specific git
commands. Seriously you'll end up with a layer of abstraction that will
make it harder for those familiar with git
On Wednesday, 12 December 2012 at 14:39:40 UTC, Michael wrote:
Machine/hardware have a explicitly defined register size and
does know nothing about sign and data type. fastest operation
is unsigned and fits to register size.
Frankly, the hardware knows nothing about classes and about
virtual
OTOH, I *never* asked for compulsory promotion, just mimicking
it. (in fact, I was not asking for anything, just addressed a
question) The idea is to guarantee, by the compiler, that the
final result of an integral arithmetic expression is AS IF all
integrals there are promoted to some
On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei
Alexandrescu wrote:
I disagree. I wrote a few git scripts for Facebook-specific
workflows and a lot of people (including me) use them.
May have been a knee jerk reaction. Good to hear it has been used.
git-start-new-feature:
$ git
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
It's time to do a release; to that end we should be working on
tidying up the regressions.
This will be the last official D1 release.
Just a heads up, GitHub has removed their Uploads feature[1].
Current uploads still work
On Tuesday, 11 December 2012 at 21:41:10 UTC, Pragma Tix wrote:
Soenke Ludwig, or ask here
http://news.rejectedsoftware.com/groups/rejectedsoftware.vibed/
IMO dlang should be powered by vibe.d
If Vibe.d is stable enough at this point (it's a WIP) then yes
that would be a good idea, and a
On 12/11/2012 12:41 AM, Andrei Alexandrescu wrote:
In turn, I'll be collecting thoughts and opinions in this thread, distilled from
previous discussions. We should develop a few simple git scripts (such as
git-start-new-feature or git-start-bugfix etc) supported by an equally simple
piece of
Is this a known bug or deliberate limitation?
void func(T)(T data) {
void subfunc1() {
process(data);
if (recurse) subfunc2(); // Error: subfunc2 undefined
}
void subfunc2() {
On Wed, Dec 12, 2012 at 07:04:17PM +0100, Joseph Rushton Wakeling wrote:
[...]
It seems to me that while process is clearly very important, what's
maybe necessary first is to identify what the actual results of the
process are intended to be. What should a 'stable version' of D
actually mean,
On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
To summarize:
2. The version scheme is meaningless. Please check out
http://www.mozilla.org/en-US/firefox/channel/#firefox as an
example. It's perfectly clear, you can choose what Mozilla
calls a channel - i.e release or beta.
I
On Wednesday, 12 December 2012 at 10:22:32 UTC, foobar wrote:
To summarize:
2. The version scheme is meaningless. Please check out
http://www.mozilla.org/en-US/firefox/channel/#firefox as an
example. It's perfectly clear, you can choose what Mozilla
calls a channel - i.e release or beta.
On Thursday, 6 December 2012 at 18:40:57 UTC, Alex Rønne Petersen
wrote:
Hi,
I decided to take a stab at reviving the new std.process
written by Lars T. Kyllingstad and Steven Schveighoffer.
The result is here:
https://github.com/alexrp/phobos/tree/new-std-process-update
I decided to
On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton
Wakeling wrote:
People have talked about Debian's unstable = testing = stable
model, but instead, why not consider something more akin to
Ubuntu's LTS and interim releases?
No, no, please. As already stated, distro release
On 2012-12-12 18:29, Brad Anderson wrote:
Just a heads up, GitHub has removed their Uploads feature[1].
That sucks :( . But thanks for the heads up.
--
/Jacob Carlborg
On Wednesday, 12 December 2012 at 18:33:17 UTC, Jesse Phillips
wrote:
If we release 2.61 as a stable, we would then develop new
features in which version? 2.62 beta 1? If so, when we release
2.61 with a bug fix which version do we release? 2.62? 2.61
stable 2?
You are right that version
On Wednesday, 12 December 2012 at 18:47:58 UTC, deadalnix wrote:
On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton
Wakeling wrote:
People have talked about Debian's unstable = testing =
stable model, but instead, why not consider something more
akin to Ubuntu's LTS and interim
On Wednesday, 12 December 2012 at 19:33:00 UTC, Rob T wrote:
On Wednesday, 12 December 2012 at 18:47:58 UTC, deadalnix wrote:
On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton
Wakeling wrote:
People have talked about Debian's unstable = testing =
stable model, but instead, why not
On 12/12/2012 03:45 AM, Walter Bright wrote:
On 12/11/2012 5:05 PM, bearophile wrote:
Walter Bright:
ML has been around for 30-40 years, and has failed to catch on.
OcaML, Haskell, F#, and so on are all languages derived more or less
directly
from ML, that share many of its ideas. Has
On 12/12/2012 07:03 PM, H. S. Teoh wrote:
Is this a known bug or deliberate limitation?
void func(T)(T data) {
void subfunc1() {
process(data);
if (recurse) subfunc2(); // Error: subfunc2 undefined
}
On 2012-12-12 19:03, H. S. Teoh wrote:
Is this a known bug or deliberate limitation?
void func(T)(T data) {
void subfunc1() {
process(data);
if (recurse) subfunc2(); // Error: subfunc2 undefined
}
On 12/12/2012 09:03 PM, Timon Gehr wrote:
On 12/12/2012 07:03 PM, H. S. Teoh wrote:
Is this a known bug or deliberate limitation?
void func(T)(T data) {
void subfunc1() {
process(data);
if (recurse) subfunc2(); // Error: subfunc2 undefined
}
Let me do some proposal. If people are happy with them, I can
start some wikification.
First here are the branch already existing :
dev : development branch. It is used to merge new features.
master : is the branch where the next version is stabilized
(right now, 2.061). It receive only bug
On 12 December 2012 17:29, Brad Anderson e...@gnuk.net wrote:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
It's time to do a release; to that end we should be working on tidying up
the regressions.
This will be the last official D1 release.
Just a heads up, GitHub has
On Wednesday, December 12, 2012 10:42:31 Simen Kjaeraas wrote:
Really? This certainly does not compile for me:
struct bbyte {
byte b;
alias b this;
}
void bar(bbyte b) {}
bbyte baz() {
byte b;
return b; // cannot implicitly convert expression (b) of type byte to
bbyte
}
void
On Wed, 12 Dec 2012, Iain Buclaw wrote:
On 12 December 2012 17:29, Brad Anderson e...@gnuk.net wrote:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
It's time to do a release; to that end we should be working on tidying up
the regressions.
This will be the last
I read all thread and conclude that developers want a one button
- 'do all what I need'.
As mentioned above, for example, python have a arbitrary int
(that implemented as C library ;)).
C can be used on many platforms. For each platform developer have
solution as library. Right way is
It seems it's not possible to call ModuleInfo.unitTest more than once.
The following code will not run the unit tests:
foreach (m ; ModuleInfo)
if (m m.unitTest)
m.unitTest();
But this code will:
foreach (m ; ModuleInfo)
if (m)
if (auto fp = m.unitTest)
On 12/12/2012 2:53 AM, foobar wrote:
One example that comes to mind is the
future version of JavaScript is implemented in ML.
Um, there are many implementations of Javascript. In fact, I have implemented it
in both C++ and D.
Timon Gehr:
(A silly workaround is the following, but I do not know if this
has been documented since it has been discovered:
The workaround I use was found by Don, is to the define an inner
static struct with static methods.
Bye,
bearophile
On Wednesday, 12 December 2012 at 18:04:43 UTC, Joseph Rushton
Wakeling wrote:
It seems to me that while process is clearly very important,
what's maybe necessary first is to identify what the actual
results of the process are intended to be. What should a
'stable version' of D actually mean,
For each platform developer have solution as library. Right way
is creating something new instead cutting something that exist.
Moving some of the things to from the library to the language is
hard and limitating, but sometimes it worths the effort.
An example: threads. C/C++ have those as
On 12/12/2012 4:51 AM, Araq wrote:
From http://embed.cs.utah.edu/ioc/
Examples of undefined integer overflows we have reported:
An SQLite bug
Some problems in SafeInt
GNU MPC
PHP
Firefox
GCC
PostgreSQL
LLVM
Python
We also reported bugs to BIND
On 12/12/2012 3:12 AM, foobar wrote:
Regarding performance and overflow checking, the example you give is x86
specific. What about other platforms? For example ARM is very popular nowadays
in the mobile world and there are many more smart-phones out there than there
are PCs. Is the same issue
On 12/12/2012 12:01 PM, Timon Gehr wrote:
That is certainly fixable. It is a mere QOI issue.
When you have a language that fundamentally disallows mutation, some algorithms
are doomed to be slower. I asked Erik Maijer, one of the developers of Haskell,
if the implementation does mutation
On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
If alias this isn't do an implict conversion, then there's a bug in alias
this. That's how implict conversion is done in D, and it's the whole point
of alias this.
And it does, as I relied on this to do the halffloat implementation.
On 12 December 2012 21:10, Brad Roberts bra...@puremagic.com wrote:
On Wed, 12 Dec 2012, Iain Buclaw wrote:
On 12 December 2012 17:29, Brad Anderson e...@gnuk.net wrote:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
It's time to do a release; to that end we should be
Thread (and etc) is a high level abstraction that requires a
support by hardware/software/instruction set. If it necessary,
library can be integrated to language. And it's another one
question about design.
Thread (and etc) is a high level abstraction that requires a
support by hardware/software/instruction set.
Not only. First of all, it requires that the compiler *knows* and
*understands* the concept of thread. This is why C mimicking C++
will *never* get as fast as a true C++ compiler, for
Even OOP possible in asm.
It's completely OT ;)
On Wednesday, 12 December 2012 at 21:51:00 UTC, Michael wrote:
Thread (and etc) is a high level abstraction that requires a
support by hardware/software/instruction set.
And you can do happily multi-threading on a single processor,
with no parallelization and so on. It is just time-slicing.
Here is a solution I came up with that seems to work fine and
does not require hard coding any values. Hence, it is useable.
Unfortunately it looks clunky and is: (and it would be nice to
speed up the the method call and possible code it in such a way
that if D directly supports this in the
Walter Bright:
Consider running a server farm. If you can make your code 5%
faster, you need 5% fewer servers. That translates into
millions of dollars.
Two comments:
- I've seen Facebook start from PHP, go to PHP compiled in some
ways, and lately start to switch to faster languages, so
On Wednesday, 12 December 2012 at 21:27:35 UTC, Walter Bright
wrote:
On 12/12/2012 3:12 AM, foobar wrote:
Regarding performance and overflow checking, the example you
give is x86
specific. What about other platforms? For example ARM is very
popular nowadays
in the mobile world and there are
On Wednesday, 12 December 2012 at 22:36:35 UTC, ixid wrote:
On Wednesday, 12 December 2012 at 21:27:35 UTC, Walter Bright
wrote:
On 12/12/2012 3:12 AM, foobar wrote:
Regarding performance and overflow checking, the example you
give is x86
specific. What about other platforms? For example ARM
On Wednesday, 12 December 2012 at 22:19:54 UTC, js.mdnq wrote:
Also, I initially tried to do
B!(A.b1.offsetof) b1;
a'la
http://forum.dlang.org/thread/mailman.2627.1355335532.5162.digitalmar...@puremagic.com
but dmd 2.060 crashes, which is why I moved on to using a
static if.
On Wednesday, 12 December 2012 at 21:17:31 UTC, Rob T wrote:
Can we agree to create a wiki page for defining what the main
goals are, and what we wish to achieve?
I agree with the listed points.
On 12/12/2012 2:17 PM, bearophile wrote:
Two comments:
- I've seen Facebook start from PHP, go to PHP compiled in some ways, and lately
start to switch to faster languages, so when you have tons of servers space and
electricity used by CPUs becomes important for the bottom line. On the other
On 12/12/2012 10:35 PM, Walter Bright wrote:
On 12/12/2012 12:01 PM, Timon Gehr wrote:
That is certainly fixable. It is a mere QOI issue.
When you have a language that fundamentally disallows mutation,
It does not.
some algorithms are doomed to be slower.
Here's a (real) quicksort:
On 12/12/2012 10:25 PM, Walter Bright wrote:
On 12/12/2012 4:51 AM, Araq wrote:
...
So how does D improve on C's model? If signed integers are required to
wrap
around in D (no undefined behaviour), you also prevent some otherwise
possible
optimizations (there is a reason it's still undefined
On Wed, Dec 12, 2012 at 10:17:30PM +0100, Rob T wrote:
[...]
If I write stuff like this in here, it'll just end up disappearing
into the black hole.
Can we agree to create a wiki page for defining what the main goals
are, and what we wish to achieve?
Once we have consensus on what is to
On 12/12/2012 3:23 PM, Timon Gehr wrote:
It is somewhat similar to (the still quite broken) 'pure' in D,
Broken how?
Provided the code is correct.
No language or compiler can prove code correct.
On 12/12/2012 3:23 PM, Timon Gehr wrote:
On 12/12/2012 10:35 PM, Walter Bright wrote:
some algorithms are doomed to be slower.
Here's a (real) quicksort:
http://stackoverflow.com/questions/5268156/how-do-you-do-an-in-place-quicksort-in-haskell
Ok, I'll bite.
Here's a program in Haskell and
On 12/12/2012 3:29 PM, Timon Gehr wrote:
On 12/12/2012 10:25 PM, Walter Bright wrote:
On 12/12/2012 4:51 AM, Araq wrote:
...
So how does D improve on C's model? If signed integers are required to
wrap
around in D (no undefined behaviour), you also prevent some otherwise
possible
optimizations
On Wednesday, 12 December 2012 at 22:58:47 UTC, Max Samukha wrote:
On Wednesday, 12 December 2012 at 22:19:54 UTC, js.mdnq wrote:
Also, I initially tried to do
B!(A.b1.offsetof) b1;
a'la
http://forum.dlang.org/thread/mailman.2627.1355335532.5162.digitalmar...@puremagic.com
but dmd
On Wednesday, 12 December 2012 at 23:47:26 UTC, Walter Bright
wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
On 12/12/2012 10:35 PM, Walter Bright wrote:
some algorithms are doomed to be slower.
Here's a (real) quicksort:
On Wednesday, 12 December 2012 at 06:19:14 UTC, Walter Bright
wrote:
You're not going to get performance with overflow checking even
with the best compiler support. For example, much arithmetic
code is generated for the x86 using addressing mode
instructions, like:
LEA EAX,16[8*EBX][ECX]
On Thursday, 13 December 2012 at 00:02:01 UTC, js.mdnq wrote:
Half done? Has it even been implemented at all?
http://dlang.org/class.html#nested
It is implemented for nested classes but not structs.
In any case my method seems to provide a solution to the
problem in the mean time. I have
Maybe, but I'm still not clear what are the differences between
a normal ring buffer (not a new concept) and this disruptor
pattern..
Key differences with a typical lock-free queue:
- Lightning fast when used correctly. It observes that not only
is locking expensive, even CAS (compare and
On Thursday, 13 December 2012 at 00:37:16 UTC, Max Samukha wrote:
On Thursday, 13 December 2012 at 00:02:01 UTC, js.mdnq wrote:
Half done? Has it even been implemented at all?
http://dlang.org/class.html#nested
It is implemented for nested classes but not structs.
In any case my method
On Wednesday, 12 December 2012 at 19:28:54 UTC, Rob T wrote:
2.61.0 = bugfixes = 2.61.1
2.61.0 = newfeatures = 2.62.0 beta 1
2.62 = preparing for stabilizing = 2.62 rc1
just some thoughts.
A 3 point numbering system used to differentiate between the
stable bug fix releases and the beta
On 12/13/2012 12:43 AM, Walter Bright wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
It is somewhat similar to (the still quite broken) 'pure' in D,
Broken how?
- There is no way to specify that a delegate is strongly pure without
resorting to type deduction, because
- Member
Walter Bright:
Java makes no attempt to detect integer overflows.
There are various kinds of code. In some kinds of programs you
want to be more sure that the result is correct, while other
kinds of programs this need is less strong.
I personally know people who write high speed trading
On 12/13/2012 12:47 AM, Walter Bright wrote:
On 12/12/2012 3:23 PM, Timon Gehr wrote:
On 12/12/2012 10:35 PM, Walter Bright wrote:
some algorithms are doomed to be slower.
Here's a (real) quicksort:
http://stackoverflow.com/questions/5268156/how-do-you-do-an-in-place-quicksort-in-haskell
1 - 100 of 188 matches
Mail list logo
