Le 06/03/2014 12:43, sclytrack a écrit :
match (in a game), litchi (a fruit), dispatcher (to dispatch)
I believe you used dispatcher in the translated book. Had to look it up,
because it sounded too English.
Words containing tch seems to be taken for other languages.
Talking about
08-Mar-2014 05:23, Andrei Alexandrescu пишет:
On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
On Friday, 7 March 2014 at 20:43:45 UTC, Vladimir Panteleev wrote:
No, it doesn't.
import std.algorithm;
void main()
{
auto s = cassé;
08-Mar-2014 12:09, Dmitry Olshansky пишет:
08-Mar-2014 05:23, Andrei Alexandrescu пишет:
On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
On Friday, 7 March 2014 at 20:43:45 UTC, Vladimir Panteleev wrote:
No, it doesn't.
import
08-Mar-2014 05:18, Andrei Alexandrescu пишет:
On 3/7/14, 12:48 PM, Dmitry Olshansky wrote:
07-Mar-2014 23:57, Andrei Alexandrescu пишет:
On 3/6/14, 6:37 PM, Walter Bright wrote:
In Lots of low hanging fruit in Phobos the issue came up about the
automatic encoding and decoding of char ranges.
On Saturday, 8 March 2014 at 02:04:12 UTC, bearophile wrote:
Vladimir Panteleev:
It's not about types, it's about algorithms.
Given sufficiently refined types, it can be about types :-)
Bye,
bearophile
I think Bear is onto something, we already solved an analogous
problem in an elegant
On 03/08/2014 03:15 AM, Adam D. Ruppe wrote:
So the best we're looking to automate is input or perhaps forward
ranges. And how hard are these really to write?
yield query(string q) {
auto result = c_query(toStringz(q));
while(!HasRow(result))
yield GetNextRow(result);
}
OK,
On 03/08/2014 02:09 AM, H. S. Teoh wrote:
On Sat, Mar 08, 2014 at 01:14:29AM +0100, Timon Gehr wrote:
On 03/07/2014 02:37 AM, H. S. Teoh wrote:
Unfortunately, input ranges are somewhat tedious to write -- nice
foreach loops have to be broken up into .empty, .front, .popFront,
which is a lot of
On 3/7/2014 9:15 PM, Adam D. Ruppe wrote:
On Saturday, 8 March 2014 at 01:10:38 UTC, H. S. Teoh wrote:
Having a way to auto-generate input range boilerplate, though, would
be really, *really* nice.
Eh, I don't think it is a big deal and would be fairly limited compared
to the current setup.
(now Python 3 has yield that is usable for coroutines too, and
it has recently added another optimization).
The optimization for Python yield is present in F# too:
http://theburningmonk.com/2011/09/fsharp-yield-vs-yield/
And I have another paper about F# to show in this thread.
Bye,
And I have another paper about F# to show in this thread.
I have not yet found the paper, but I think this was the topic:
http://blogs.msdn.com/b/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx
Bye,
bearophile
On Fri, 2014-03-07 at 23:18 +, Bienlein wrote:
[…]
Would be awesome if D got some kind of CSP. I used to reproduce
[…]
to have little lock contention. With CSP you only have to fix the
way you deal with some channel or introduce some other channel.
CSP is truly a step ahead IMHO.
I have not yet found the paper,
Here it is:
http://tomasp.net/academic/papers/computation-zoo/
More on the same:
http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation_Expressions
http://msdn.microsoft.com/en-us/library/dd233182.aspx
Bye,
bearophile
On 3/8/2014 5:56 AM, Nick Sabalausky wrote:
What really itches at me is that we're so tantalizingly close with
opApply. The only real problem with it (aside from the return value
system being kinda awkward compared to a yield statement) is that it
can't be used as a range. And it can't be
On 02/27/2014 01:41 PM, Szymon Gatner wrote:
C#'s IObservable/IObserver made me think how would a dual [1][2] of
a range concept look in D. Since D has no equivalent IEnumerable (as
it is no needed thanks to templates) it is only about IEnumerator /
IObserver part which relates to a D range.
On Saturday, 8 March 2014 at 11:23:17 UTC, Russel Winder wrote:
I guess D could be said to have actors already using spawn and
the
message queue.
In std.concurrency, the documentation states that: Right now,
only in-process threads are supported and referenced by a more
specialized handle
Do there exist any GDL bindings for D? Google tells me no, but
surely someone must have used the library before in D.
On Saturday, 8 March 2014 at 13:21:50 UTC, Jeroen Bollen wrote:
Do there exist any GDL bindings for D? Google tells me no, but
surely someone must have used the library before in D.
And to avoid confusion, I mean the GDL as in the Gnome Docking
Library.
Recently Vladimir Panteleev has ported the DMD Source Guide from
the old wiki to the new one[1], and updated it with up-to-date
information. I've added a DMD Hacking Tips Tricks section[2],
which should help people new to the codebase to start hacking on
DMD-FE. I've only added a few tips
Thanks both to you and Vladimir for your effort! Some of those
tips could have saved me a lot of time if read earlier :)
Few years ago I had read that Walter had add some print
instruction to Phobos, that allow to do print without importing
std.stdio; It was needed to debugging phobos.
Maybe it's not proper thread, but maybe someone of D hackers
remember it, because I can't remember how it was done.
Thanks for the information! I plan on playing around with the
compiler soon, and the more information the merrier.
On Sat, Mar 08, 2014 at 10:38:50AM +0100, Timon Gehr wrote:
On 03/08/2014 02:09 AM, H. S. Teoh wrote:
On Sat, Mar 08, 2014 at 01:14:29AM +0100, Timon Gehr wrote:
On 03/07/2014 02:37 AM, H. S. Teoh wrote:
Unfortunately, input ranges are somewhat tedious to write -- nice
foreach loops have to
Sure, I'd love to see CSP in D as well. I think that Go's
advantage is simplicity. If you want to try the same code on more
system threads, all you need to do is increase GOMAXPROCS. With
vibe.d it requires some work. It's not a lot of work but it isn't
as easy as with Go.
OTOH, D + vibe.d give
On 3/8/14, 12:14 AM, Dmitry Olshansky wrote:
08-Mar-2014 12:09, Dmitry Olshansky пишет:
08-Mar-2014 05:23, Andrei Alexandrescu пишет:
On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
On Friday, 7 March 2014 at 20:43:45 UTC, Vladimir Panteleev
On 3/8/14, 12:09 AM, Dmitry Olshansky wrote:
08-Mar-2014 05:23, Andrei Alexandrescu пишет:
On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
On Friday, 7 March 2014 at 20:43:45 UTC, Vladimir Panteleev wrote:
No, it doesn't.
import
On 3/8/14, Suliman everm...@live.ru wrote:
Few years ago I had read that Walter had add some print
instruction to Phobos, that allow to do print without importing
std.stdio; It was needed to debugging phobos.
Maybe it's not proper thread, but maybe someone of D hackers
remember it, because I
08-Mar-2014 19:32, Andrei Alexandrescu пишет:
On 3/8/14, 12:09 AM, Dmitry Olshansky wrote:
08-Mar-2014 05:23, Andrei Alexandrescu пишет:
On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
On Friday, 7 March 2014 at 20:43:45 UTC, Vladimir
On Saturday, 8 March 2014 at 15:33:34 UTC, Andrei Alexandrescu
wrote:
Why? Couldn't the grapheme 'compare true with the character?
I.e. the byGrapheme iteration normalizes on the fly.
Grapheme segmentation and normalization are distinct Unicode
algorithms:
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding
fiber based scheduling?
By the way is there a way to make use of vibe.d in something like
a local mode? I mean some in-memory mode without going through
TCP.
Thanks,
08-Mar-2014 19:33, Andrei Alexandrescu пишет:
On 3/8/14, 12:14 AM, Dmitry Olshansky wrote:
08-Mar-2014 12:09, Dmitry Olshansky пишет:
08-Mar-2014 05:23, Andrei Alexandrescu пишет:
On 3/7/14, 1:58 PM, Vladimir Panteleev wrote:
On Friday, 7 March 2014 at 21:56:45 UTC, Eyrk wrote:
On Friday, 7
On Saturday, 8 March 2014 at 16:00:38 UTC, Vladimir Panteleev
wrote:
On Saturday, 8 March 2014 at 15:33:34 UTC, Andrei Alexandrescu
wrote:
Why? Couldn't the grapheme 'compare true with the character?
I.e. the byGrapheme iteration normalizes on the fly.
Grapheme segmentation and normalization
On Saturday, 8 March 2014 at 15:56:08 UTC, Dmitry Olshansky wrote:
The following should work as is though:
s.byGrapheme.canFind(Grapheme(é))
Doesn't work here. Not sure why.
Grapheme(165, 3, 0, 33554432, [101, 0, 0, 1, 3, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0], 2) // last byGrapheme
vs.
On Saturday, 8 March 2014 at 16:01:00 UTC, Bienlein wrote:
On Monday, 3 March 2014 at 14:27:53 UTC, Sönke Ludwig wrote:
Just out of curiosity, what did you miss in vibe.d regarding
fiber based scheduling?
By the way is there a way to make use of vibe.d in something
like a local mode? I mean
On 3/8/14, 3:22 AM, Russel Winder wrote:
Dataflow is though where Big Data is going. There are commercial
offerings in the JVM space and they are making huge profits on
licencing, simply because the frameworks work.
Do you have a couple of relevant links describing dataflow?
Andrei
On 3/8/14, 8:08 AM, Dmitry Olshansky wrote:
08-Mar-2014 19:33, Andrei Alexandrescu пишет:
I.e. the
byGrapheme iteration normalizes on the fly.
Oh crap, please no. It's not only _Slow_ but it's also horribly
complicated (even in off-line, eager version). + there are 4
normalizations, of which
On Saturday, 8 March 2014 at 12:13:07 UTC, logicchains wrote:
On Saturday, 8 March 2014 at 11:23:17 UTC, Russel Winder wrote:
I guess D could be said to have actors already using spawn and
the
message queue.
In std.concurrency, the documentation states that: Right now,
only in-process
On Sat, 2014-03-08 at 08:53 -0800, Andrei Alexandrescu wrote:
On 3/8/14, 3:22 AM, Russel Winder wrote:
Dataflow is though where Big Data is going. There are commercial
offerings in the JVM space and they are making huge profits on
licencing, simply because the frameworks work.
Do you
On Saturday, 8 March 2014 at 00:22:05 UTC, Walter Bright wrote:
Andrei suggests that this change would destroy D by breaking
too much existing code. He might be right. Can we afford the
risk that he is right?
Perhaps not. But I think the current approach is totally broken,
it's just also
On Friday, 7 March 2014 at 20:27:38 UTC, H. S. Teoh wrote:
s.indexOf(a); // for slicing
s.byCodepoint.countUntil(a);// count code points
s.byGrapheme.countUntil(a); // count graphemes
(BTW, byGrapheme is currently missing in the std.uni
On 3/8/2014 11:21 PM, Suliman wrote:
Few years ago I had read that Walter had add some print instruction to
Phobos, that allow to do print without importing std.stdio; It was
needed to debugging phobos.
Maybe it's not proper thread, but maybe someone of D hackers remember
it, because I can't
On Saturday, 8 March 2014 at 13:25:32 UTC, Andrej Mitrovic wrote:
Recently Vladimir Panteleev has ported the DMD Source Guide
from the old wiki to the new one[1], and updated it with
up-to-date information. I've added a DMD Hacking Tips
Tricks section[2], which should help people new to the
On Saturday, 8 March 2014 at 13:25:32 UTC, Andrej Mitrovic wrote:
Recently Vladimir Panteleev has ported the DMD Source Guide
from the old wiki to the new one[1], and updated it with
up-to-date information. I've added a DMD Hacking Tips
Tricks section[2], which should help people new to the
On 3/8/14, 9:33 AM, Sean Kelly wrote:
On Saturday, 8 March 2014 at 00:22:05 UTC, Walter Bright wrote:
Andrei suggests that this change would destroy D by breaking too much
existing code. He might be right. Can we afford the risk that he is
right?
Perhaps not. But I think the current approach
I'll admit that I'm probably not the best person to make
suggestions here. As a back-end programmer, a large portion of my
work is dealing with text streams of various types. And the data
I work with is in any number of encodings and none can be assumed
to be in English. But literally all of
On Saturday, 8 March 2014 at 20:05:36 UTC, Andrei Alexandrescu
wrote:
Searching for characters in strings would be difficult to deem
inappropriate.
The notion of character exists only in certain writing systems.
It is thus a flawed practice, and I think it should not be
encouraged, as it
On 3/8/14, 12:26 PM, Sean Kelly wrote:
But you're right. I was being dramatic when I called it utterly broken.
It's simply not useful to me as-is. The solution for me is fairly simple
though if inelegant--cast the string to an array of ubyte.
Ain't nobody know nothing about
On Sat, Mar 08, 2014 at 08:38:40PM +, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 20:05:36 UTC, Andrei Alexandrescu
wrote:
Searching for characters in strings would be difficult to deem
inappropriate.
The notion of character exists only in certain writing systems. It
is thus
On 3/8/14, 12:38 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 20:05:36 UTC, Andrei Alexandrescu wrote:
1. All algorithms would by default operate on strings at char/wchar
level (i.e. code unit). That would cause the usual issues and
confusions I was aware of from C++. Certain
On 3/8/14, Asman01 jck...@gmail.com wrote:
[1]: I've been looking at trying to hook the DMD frontend up to
LLVM (www.llvm.org)
Uhm, haven't you heard of the LDC project? http://wiki.dlang.org/LDC
On 3/8/14, Asman01 jck...@gmail.com wrote:
Also, where is root/async.c actually used?
In mars.c, take a look at the #if ASYNCREAD section.
On 3/8/2014 9:44 AM, Luís Marques l...@luismarques.eu wrote:
(BTW, byGrapheme is currently missing in the std.uni docs)
https://github.com/D-Programming-Language/phobos/pull/1985
On Saturday, 8 March 2014 at 20:50:49 UTC, Andrei Alexandrescu
wrote:
On 3/8/14, 12:38 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 20:05:36 UTC, Andrei Alexandrescu
wrote:
That sounds quite like C++ plus ICU. It doesn't strike me as
the
golden standard for Unicode integration.
On 3/8/14, Asman01 jck...@gmail.com wrote:
I don't understand this part converted to UTF-8 when necessary
in [1].
See Module::parse() in module.c, it converts all non-UTF-8 formats to
UTF-8 when reading a file.
Actually thinking about this, this has to be extremely inefficient.
Hopefully once
On 3/8/2014 12:09 AM, Dmitry Olshansky wrote:
Becasue Graphemes do not auto-magically convert to dchar and back? After all
they are just small strings.
std.uni.Grapheme is a struct, and that struct contains a string of arbitrary
length.
I don't know if that is the right design or not, or if
On Saturday, 8 March 2014 at 21:07:52 UTC, Andrej Mitrovic wrote:
On 3/8/14, Asman01 jck...@gmail.com wrote:
[1]: I've been looking at trying to hook the DMD frontend up to
LLVM (www.llvm.org)
Uhm, haven't you heard of the LDC project?
http://wiki.dlang.org/LDC
He was quoting an ancient
On Saturday, 8 March 2014 at 21:09:14 UTC, Andrej Mitrovic wrote:
On 3/8/14, Asman01 jck...@gmail.com wrote:
Also, where is root/async.c actually used?
In mars.c, take a look at the #if ASYNCREAD section.
Thanks. I will check out.
On Saturday, 8 March 2014 at 20:52:40 UTC, H. S. Teoh wrote:
Or more to the point, do you know of any experience that you
can share
about code that attempts to process these sorts of strings on a
per
character basis? My suspicion is that any code that operates on
such
strings, if they have
On Saturday, 8 March 2014 at 21:16:30 UTC, Andrej Mitrovic wrote:
On 3/8/14, Asman01 jck...@gmail.com wrote:
I don't understand this part converted to UTF-8 when
necessary
in [1].
See Module::parse() in module.c, it converts all non-UTF-8
formats to
UTF-8 when reading a file.
Actually
On 03/08/2014 10:16 PM, Andrej Mitrovic wrote:
On 3/8/14, Asman01 jck...@gmail.com wrote:
I don't understand this part converted to UTF-8 when necessary
in [1].
See Module::parse() in module.c, it converts all non-UTF-8 formats to
UTF-8 when reading a file.
Actually thinking about this, this
On Saturday, 8 March 2014 at 20:50:49 UTC, Andrei Alexandrescu
wrote:
Pretty much everyone using ICU hates it.
I think the biggest problem with ICU is documentation. It can
take a long time to figure out how to do something if you've
never done it before. Also, the C interface in ICU
On 3/8/14, Timon Gehr timon.g...@gmx.ch wrote:
How many actual D source files are not UTF-8?
No idea. Maybe some Windows tools use UTF-16, although I can't think
of any. VS uses UTF-8 right?
08-Mar-2014 20:43, Vladimir Panteleev пишет:
On Saturday, 8 March 2014 at 15:56:08 UTC, Dmitry Olshansky wrote:
The following should work as is though:
s.byGrapheme.canFind(Grapheme(é))
Doesn't work here. Not sure why.
Grapheme(165, 3, 0, 33554432, [101, 0, 0, 1, 3, 0, 0, 0, 0, 0, 0, 0,
09-Mar-2014 01:15, Walter Bright пишет:
On 3/8/2014 12:09 AM, Dmitry Olshansky wrote:
Becasue Graphemes do not auto-magically convert to dchar and back?
After all
they are just small strings.
std.uni.Grapheme is a struct, and that struct contains a string of
arbitrary length.
I don't know if
On Saturday, 8 March 2014 at 22:42:20 UTC, Dmitry Olshansky wrote:
Sounds like a bug, file it before we derailed.
https://d.puremagic.com/issues/show_bug.cgi?id=12324
W dniu 2014-03-08 02:09, H. S. Teoh pisze:
Having a way to auto-generate input range boilerplate, though, would be
really, *really* nice. Coroutine-style code would be ideal.
https://github.com/pszturmaj/dgenerators
1. implement decode() as an algorithm for string types,
Decode is an incredibly generic name. What about byGlyph similar
to byLine?
This would kill D. I am not exaggerating.
I don't know about kill but it certainly feels awfully similar to
the Python 2/3 spit over strings and Unicode which still doesn't
seem to be resolved.
On 3/8/2014 5:58 PM, Piotr Szturmaj wrote:
W dniu 2014-03-08 02:09, H. S. Teoh pisze:
Having a way to auto-generate input range boilerplate, though, would be
really, *really* nice. Coroutine-style code would be ideal.
https://github.com/pszturmaj/dgenerators
Yea, there is that approach,
On 3/8/14, 1:15 PM, Walter Bright wrote:
On 3/8/2014 12:09 AM, Dmitry Olshansky wrote:
Becasue Graphemes do not auto-magically convert to dchar and back?
After all
they are just small strings.
std.uni.Grapheme is a struct, and that struct contains a string of
arbitrary length.
I don't know
On 3/8/14, 1:13 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 20:50:49 UTC, Andrei Alexandrescu wrote:
On 3/8/14, 12:38 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 20:05:36 UTC, Andrei Alexandrescu wrote:
That sounds quite like C++ plus ICU. It doesn't strike me as
On Saturday, 8 March 2014 at 23:59:15 UTC, Andrei Alexandrescu
wrote:
My only claim is that recognizing and iterating strings by code
point is better than doing things by the octet.
Considering or disregarding the disadvantages of this choice?
1. Eliminating dangerous constructs, such as
On 3/8/14, 4:42 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 23:59:15 UTC, Andrei Alexandrescu wrote:
My only claim is that recognizing and iterating strings by code point
is better than doing things by the octet.
Considering or disregarding the disadvantages of this choice?
On Sunday, 9 March 2014 at 01:23:27 UTC, Andrei Alexandrescu
wrote:
On 3/8/14, 4:42 PM, Vladimir Panteleev wrote:
On Saturday, 8 March 2014 at 23:59:15 UTC, Andrei Alexandrescu
wrote:
My only claim is that recognizing and iterating strings by
code point
is better than doing things by the
On 2014-03-08 23:50:43 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Graphemes do not appear to have a 1:1 mapping with dchars, and any
attempt to do so would likely be a giant mistake.
I think they may be comparable to dchar.
Dchar, aka code points, are much clearly
On 3/8/14, 6:14 PM, Vladimir Panteleev wrote:
On Sunday, 9 March 2014 at 01:23:27 UTC, Andrei Alexandrescu wrote:
On 3/8/14, 4:42 PM, Vladimir Panteleev wrote:
My point there is that there's no useless or duplicated code that
would be thrown away. A better design would indeed make for better
On Saturday, 8 March 2014 at 23:23:21 UTC, Nick Sabalausky wrote:
3. Give up on maximum performance (fiber-based coroutine range)
I think that's what I would go for. yield with co-routines could
be a quick and dirty way to create an InputRange at some
performance cost. Then writing the
On Sunday, 9 March 2014 at 03:26:40 UTC, Andrei Alexandrescu
wrote:
And it's not like people aren't talking. In contrast, D has
been (and often rightly) criticized in the past for things like
floating point performance and garbage collection. No evidence
we are having an acute performance
std.json broke backward compatibility, starting with
https://github.com/D-Programming-Language/phobos/commit/1958c95666b0241d669d282806e4f724fbb37caf.
There's even no notice in the changelog of the breakage, which is quite
obvious by inspecting the diff.
This is a serious matter because it
On Sunday, 9 March 2014 at 03:58:31 UTC, Andrei Alexandrescu
wrote:
std.json broke backward compatibility, starting with
https://github.com/D-Programming-Language/phobos/commit/1958c95666b0241d669d282806e4f724fbb37caf.
Pull request link with discussion:
On 3/8/14, 7:53 PM, Vladimir Panteleev wrote:
From my POV, I could say I see consensus, with just you defending a
decision you made a while ago :) But I'd prefer a constructive discussion.
What exactly is the consensus? From your wiki page I see One of the
proposals in the thread is to
On Sunday, 9 March 2014 at 04:18:15 UTC, Andrei Alexandrescu
wrote:
What exactly is the consensus? From your wiki page I see One
of the proposals in the thread is to switch the iteration type
of string ranges from dchar to the string's character type.
I can tell you straight out: That will
On Sunday, 9 March 2014 at 01:23:27 UTC, Andrei Alexandrescu
wrote:
I was thinking of these too:
1. Revisit std.encoding and perhaps confer legitimacy to the
character types defined there. The implementation in
std.encoding is wanting, but I think the idea is sound.
Essentially give more
On 3/8/14, 8:24 PM, Vladimir Panteleev wrote:
On Sunday, 9 March 2014 at 04:18:15 UTC, Andrei Alexandrescu wrote:
What exactly is the consensus? From your wiki page I see One of the
proposals in the thread is to switch the iteration type of string
ranges from dchar to the string's character
On 2/8/14, 8:48 AM, Andrej Mitrovic wrote:
These are all blocked until we get a go-ahead from WA with the
enhancements and reviews of a couple of fixes. There will be more as I
find them, but this is it for now.
For both Walter Andrei:
[Enhancement] Track column numbers, add '-columns' to
A small test program. This could be a base for a bug
report/enhancement request, but I am not yet sure:
import std.range: iota;
import std.array: array;
import std.typecons: Nullable;
alias Foo = int[5];
Nullable!Foo bar1() {
Foo r = 5.iota.array;
return typeof(return)(r); // OK
}
It probably expects int[5] instead of int[], couldn't convert and
reported wrong error message.
Kagamin:
It probably expects int[5] instead of int[], couldn't convert
and reported wrong error message.
OK, I will report the diagnostic bug. But do you also see space
for a (distinct) ER?
Bye,
bearophile
Can someone tell me what's wrong with this code?
http://dpaste.dzfl.pl/9ff4271f866c
I'm trying to send an immutable instance of a class to another
thread using the send and receive functions in std.concurrency.
I've already searched and found someone talking about std.variant
being bugged. Has
http://rosettacode.org/wiki/Factorial#D
to whomever is maintaining these:
Need to change all ints to longs in this example to get the
displayed results since the 15! result requires more than 32 bits.
import std.container: find, equal, empty;
import std.container : SList;
struct c
{
int idx;
string name;
}
c[] clist = [ {1, name1}, {2, name2}, { 3, name3 } ];
// c* clist = [ {1, name1}, {2, name2}, { 3, name3 } ];
int
main()
{
// Case-insensitive find of a string
After changing to longs, I made some test loops, and on release
build dmd, pc, these are the relative times I measured for the
different versions of factorial in that example. So the
iterative wins, and the functional style results in 4x penalty in
this case.
duration factorial (hnsecs)=98
On Saturday, 8 March 2014 at 17:53:03 UTC, Dicebot wrote:
On Saturday, 8 March 2014 at 16:36:56 UTC, Martin wrote:
Can someone tell me what's wrong with this code?
http://dpaste.dzfl.pl/9ff4271f866c
I'm trying to send an immutable instance of a class to another
thread using the send and
Hi,
I'm interesting in implementing a non-blocking queue. My thought is
to use a fixed-size array, and increment back of the queue with a
integer. I was thinking I could make this non-blocking via an atomic
increment operation before assigning the pushed value onto the queue.
So, my
Hi !
I just wondered if this code is valid:
void main() {
auto p = my_allocate();
// ...
my_free(p);
}
extern(System):
void *my_allocate();
void my_free(void *);
Where my_allocate and my_free are in the external dll. Main
question is: is this code transparent to GC? Will not it try to
The GC will only scan through and try to ECG memory that it owns.
So that's safe.
Thanks !
On Saturday, 8 March 2014 at 19:02:26 UTC, Shammah Chancellor
wrote:
Hi,
I'm interesting in implementing a non-blocking queue. My
thought is to use a fixed-size array, and increment back of the
queue with a integer. I was thinking I could make this
non-blocking via an atomic increment
On 2014-03-08 19:58:01 +, Martin said:
On Saturday, 8 March 2014 at 19:02:26 UTC, Shammah Chancellor wrote:
Hi,
I'm interesting in implementing a non-blocking queue. My thought is
to use a fixed-size array, and increment back of the queue with a
integer. I was thinking I could make
On Saturday, 8 March 2014 at 21:12:42 UTC, Shammah Chancellor
wrote:
On 2014-03-08 19:58:01 +, Martin said:
On Saturday, 8 March 2014 at 19:02:26 UTC, Shammah Chancellor
wrote:
Hi,
I'm interesting in implementing a non-blocking queue. My
thought is to use a fixed-size array, and
Jay Norwood:
http://rosettacode.org/wiki/Factorial#D
to whomever is maintaining these:
Need to change all ints to longs in this example to get the
displayed results since the 15! result requires more than 32
bits.
I am maintaining the D entries, I have fixed that factorial code,
thank
1 - 100 of 132 matches
Mail list logo
