Andrei Alexandrescu:
> This looks promising. We could adopt it for Phobos.
Oh, sorry, you have posted it already :-)
Bye,
bearophile
On Sunday 12 December 2010 23:20:36 bearophile wrote:
> I was away for few days and then partially busy for several more days, I am
> sorry and I will try to get up to date.
>
> Gary Whatmore:
> > Guys, I made several sockpuppet reddit accounts to mod down the two guys
> > criticising this thread.
Found through Reddit, it may be useful for Phobos:
http://volnitsky.com/project/str_search/
A possible partial D2 translation:
const(char)* volnitsky(string haystack, string needle) {
enum size_t wSize = ushort.sizeof;
enum size_t hSize = 64 * 1024;
immutable char* S = haystack.ptr;
I was away for few days and then partially busy for several more days, I am
sorry and I will try to get up to date.
Gary Whatmore:
> Guys, I made several sockpuppet reddit accounts to mod down the two guys
> criticising this thread.<
That's worse than desiring to add some examples of D code to
On 12/12/10 11:01 PM, Robert Jacques wrote:
On Sun, 12 Dec 2010 23:11:03 -0500, Andrei Alexandrescu
wrote:
This looks promising. We could adopt it for Phobos.
http://www.reddit.com/r/programming/comments/ekfct/efficient_substring_search_not_a_boyermoore/
The code has no license though...
On Sun, 12 Dec 2010 23:11:03 -0500, Andrei Alexandrescu
wrote:
This looks promising. We could adopt it for Phobos.
http://www.reddit.com/r/programming/comments/ekfct/efficient_substring_search_not_a_boyermoore/
The code has no license though...
Andrei
Have you e-mailed the author? Leoni
Andrei Alexandrescu Wrote:
> On 12/12/10 5:06 PM, Simen kjaeraas wrote:
> > If no-one else has stepped up, I'm willing to have a look.
>
> That would be a great help to the community. I did look at that code and
> nothing jumped at me. But then I didn't have enough time to profile it
> properly
Ye that's better:
Sorting with Array.opIndex: 2859
Sorting with pointers: 1765
38.2651 percent faster
And it only took 2 seconds. With profile it takes a full minute.
On 12/13/10, Craig Black wrote:
> Try it without -profile. That tends to slow everything down to a halt.
>
> -Craig
>
> "Andrej
Simen kjaeraas Wrote:
> Jason House wrote:
>
> > I wish I had your problems. I ported a sizable set of C++ code to D2 and
> > discovered D2 with dmd was 50x slower than C++ with gcc! I've been to
> > busy/disappointed to track down the bug(s) causing such a slowdown. If
> > anyone is suffi
Try it without -profile. That tends to slow everything down to a halt.
-Craig
"Andrej Mitrovic" wrote in message
news:mailman.948.1292198993.21107.digitalmar...@puremagic.com...
My crappy old Pentium 4 has gone totally mad:
Sorting with Array.opIndex: 45080
Sorting with pointers: 45608
4.09
On 12/12/10 9:50 PM, Hemanth Kapila wrote:
Hi,
Thanks for sharing the doc.
I changed one of the "cool things" from threading to operator
overloading.
May I know the reason behind the change? Is it that you intend to pick
different "3 cool things" at different talks? or do you think ope
This looks promising. We could adopt it for Phobos.
http://www.reddit.com/r/programming/comments/ekfct/efficient_substring_search_not_a_boyermoore/
The code has no license though...
Andrei
Hi,
Thanks for sharing the doc.
> I changed one of the "cool things" from threading to operator overloading.
May I know the reason behind the change? Is it that you intend to pick
different "3 cool things" at different talks? or do you think operator
overloading is 'cooler' than concurrency?
On 12/12/10 8:56 PM, Gary Whatmore wrote:
Simen kjaeraas Wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Compared to the talk at Google, I changed one of the "cool things" from
threading to operator overloading. Didn't manage to talk about that -
there were a million questions - alth
Ary Borenszweig wrote:
> D should provide a yield keyword that basically
> rewrites the body of the method into the first code.
Don't need to change the language for that.
=
string yield(string what) {
return `if(auto result = dg(`~what~`)) return result;`;
}
class Foo
{
uint arra
If the problem is not inlining, then why does the same code in C++ does not
suffer from this performance limitation (when compiled with Visual C++
2008)?
#include
#include
#include
template
T min(T a, T b) { return a < b ? a : b; }
template
T max(T a, T b) { return a > b ? a : b; }
inlin
Simen kjaeraas Wrote:
> Walter Bright wrote:
>
> > Andrei Alexandrescu wrote:
> >> Compared to the talk at Google, I changed one of the "cool things" from
> >> threading to operator overloading. Didn't manage to talk about that -
> >> there were a million questions - although I think it's a
On 12/12/2010 02:03 PM, Adam D. Ruppe wrote:
foobar wrote:
D basically re-writes foreach with opApply into the ruby version
which is why Ruby is *BETTER*
You missed the point: there is no "Ruby version". They are the
same thing.
foreach to me is a redundant obfuscation
How can it be redund
On 12/12/10 5:06 PM, Simen kjaeraas wrote:
Jason House wrote:
Craig Black Wrote:
> One more thing - to clarify, Craig, are you implying that it's
acceptable
> for performance to be within 20%? If not, there are tweaks on the
> algorithmic side we can do to improve sorting.
20% slower would
On Sun, Dec 12, 2010 at 2:13 PM, BLS wrote:
>
> Last question is about : operator()
>
> f.i.bool operator()(HWND const a, const HWND b) const
>
> Klickverbot suggests to use the SWIG's %rename. But how that would look
> like in practice ?
>
> Beside, I guess this is what opImplicitCast shoul
My crappy old Pentium 4 has gone totally mad:
Sorting with Array.opIndex: 45080
Sorting with pointers: 45608
4.092e+16 percent faster (??)
Compiled with dmd -profile -O -release -inline -noboundscheck
On 12/13/10, Iain Buclaw wrote:
> == Quote from Craig Black (craigbla...@cox.net)'s article
>>
== Quote from Craig Black (craigbla...@cox.net)'s article
> The following program illustrates the problems with inlining in the dmd
> compiler. Perhaps with some more work I can reduce it to a smaller test
> case. I was playing around with a simple Array template, and noticed that
> similar C++ c
Jason House wrote:
Craig Black Wrote:
> One more thing - to clarify, Craig, are you implying that it's
acceptable
> for performance to be within 20%? If not, there are tweaks on the
> algorithmic side we can do to improve sorting.
20% slower would be acceptable if I didn't have to do my ow
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
I wish I had your problems. I ported a sizable set of C++ code to D2 and
discovered D2 with dmd was 50x slower than C++ with gcc! I've been to
busy/disappointed to track down the bug(s) causing such a slowdown. If
anyone is sufficien
The following program illustrates the problems with inlining in the dmd
compiler. Perhaps with some more work I can reduce it to a smaller test
case. I was playing around with a simple Array template, and noticed that
similar C++ code performs much better. This is due, at least in part, to
o
Andrei Alexandrescu Wrote:
[snip]
> Control flow inside the delegate can be addressed through a slightly
> more complicated lowering (the kind foreach already does). Probably
> break and continue should not be accepted because generally you can't
> expect all user-defined constructs to do iter
Andrei Alexandrescu wrote:
And one consequence of that is that contrary to what has been said, this
would *not* allow foreach to be implemented as a library function.
I can appreciate the difficulty of getting the delegate's flow control
to be
handled as expected, but I think going ahead wi
Hello,
maybe the template resolver can provide some kind of buffer where
the constrains can emit their messages to.
If finally a match is found the buffer can be discarded. If not the
messages can be printed.
So we only get messages for failed template instantiations.
Am 11.12.2010 1
On 12/12/10 2:50 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ie341e$br...@digitalmars.com...
On 12/12/10 6:44 AM, Jacob Carlborg wrote:
[snip]
Conclusion:
D needs a better and nicer looking syntax for passing delegates to
functions.
Suggestion:
If a function takes
"Andrei Alexandrescu" wrote in message
news:ie341e$br...@digitalmars.com...
> On 12/12/10 6:44 AM, Jacob Carlborg wrote:
> [snip]
>> Conclusion:
>>
>> D needs a better and nicer looking syntax for passing delegates to
>> functions.
>>
>> Suggestion:
>>
>> If a function takes a delegate as its las
"Simen kjaeraas" wrote in message
news:op.vnl77cjyvxi...@biotronic-pc.lan...
> Nick Sabalausky wrote:
>
>>> void myfun(void delegate(string) lol) {
>>>lol("say it ");
>>> }
>>>
>>> void main() {
>>>myfun = (string what) {
>>>assert(0, what ~ " lol");
>>>};
On Sun, 12 Dec 2010 12:23:03 -0600
Andrei Alexandrescu wrote:
> Going now
> back to D, we can imagine the following lowering:
>
> fun (a, b ; c) stmt
>
> =>
>
> fun(c, (a, b) { stmt })
It seems to me that lowering is analog to redefine "shallow" syntax (in fact,
syntactic sugar) into a de
Hi, this is my first attempt to use SWIG for D2, So in case that my
questions are stupid simple.. Sorry.
questions are included in swig file wincore.i
/* wincore.i */
%module(directors="1") wincore
%{
#include "wincore.h"
%}
%include "std_string.i"
%include
/* turn on director wrapping for C
Adam D. Ruppe Wrote:
> foobar wrote:
> > D basically re-writes foreach with opApply into the ruby version
> which is why Ruby is *BETTER*
>
> You missed the point: there is no "Ruby version". They are the
> same thing.
>
By "ruby version" I meant the syntax. I agreed already that they are
imple
Walter Bright wrote:
Andrei Alexandrescu wrote:
Compared to the talk at Google, I changed one of the "cool things" from
threading to operator overloading. Didn't manage to talk about that -
there were a million questions - although I think it's a great topic.
http://erdani.com/tdpl/2010-1
On Sun, 12 Dec 2010 19:34:10 +0100, Nick Sabalausky wrote:
"Simen kjaeraas" wrote in message
news:op.vnl1katxvxi...@biotronic-pc.lan...
so wrote:
If we take a look at the very first code example from the talk it
looks
like this:
account.people.each do |person|
puts person.name
end
Looks like someone did:
http://www.reddit.com/r/programming/comments/eklq0/andrei_alexandrescus_talk_at_accu_silicon_valley/
On 12/12/10, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Compared to the talk at Google, I changed one of the "cool things" from
>> threading to operator overloadi
Andrei Alexandrescu wrote:
fun (a, b ; c) stmt
=>
fun(c, (a, b) { stmt })
This could and should be generalized for more parameters, which I'm sure
is very useful:
fun (a, b ; c, d) stmt
=>
fun(c, d, (a, b) { stmt })
Of course "fun" could be actually "obj.method".
With this we have a
Andrei Alexandrescu wrote:
Compared to the talk at Google, I changed one of the "cool things" from
threading to operator overloading. Didn't manage to talk about that -
there were a million questions - although I think it's a great topic.
http://erdani.com/tdpl/2010-12-08-ACCU.pdf
Anyone ca
Nick Sabalausky wrote:
void myfun(void delegate(string) lol) {
lol("say it ");
}
void main() {
myfun = (string what) {
assert(0, what ~ " lol");
};
}
I'm sure that's going to disappear when D's properties get implemented as
intended.
I'm not. Co
On 12/12/10 12:36 PM, Nick Sabalausky wrote:
"Adam D. Ruppe" wrote in message
news:ie2sv2$2th...@digitalmars.com...
We already have a D block syntax!
=
void myfun(void delegate() lol) {
lol();
}
void main() {
myfun = {
assert(0, "lol");
};
}
=
Nick Sabalausky wrote:
> And FWIW, it looks like operator-overload-abuse to me.
Probably because that's what it is :)
"Nick Sabalausky" wrote in message
news:ie34p4$dg...@digitalmars.com...
> "Adam D. Ruppe" wrote in message
> news:ie2sv2$2th...@digitalmars.com...
>> We already have a D block syntax!
>>
>> =
>>
>> void myfun(void delegate() lol) {
>>lol();
>> }
>>
>> void main() {
>>myfun =
"Adam D. Ruppe" wrote in message
news:ie2sv2$2th...@digitalmars.com...
> We already have a D block syntax!
>
> =
>
> void myfun(void delegate() lol) {
>lol();
> }
>
> void main() {
>myfun = {
>assert(0, "lol");
>};
> }
>
> ==
>
> Totally compiles. :
Andrei Alexandrescu wrote:
> On 12/12/10 6:44 AM, Jacob Carlborg wrote:
> [snip]
>> Conclusion:
>>
>> D needs a better and nicer looking syntax for passing delegates to
>> functions.
>>
>> Suggestion:
>>
>> If a function takes a delegate as its last parameter allow the delegate
>> literal to be pa
Compared to the talk at Google, I changed one of the "cool things" from
threading to operator overloading. Didn't manage to talk about that -
there were a million questions - although I think it's a great topic.
http://erdani.com/tdpl/2010-12-08-ACCU.pdf
Andrei
"Simen kjaeraas" wrote in message
news:op.vnl1katxvxi...@biotronic-pc.lan...
> so wrote:
>
>>> If we take a look at the very first code example from the talk it looks
>>> like this:
>>>
>>> account.people.each do |person|
>>> puts person.name
>>> end
>>>
>>> You could translate this in two
"Jacob Carlborg" wrote in message
news:ie2g72$1sf...@digitalmars.com...
> On 2010-12-11 18:21, Andrei Alexandrescu wrote:
>> On 12/11/10 11:05 AM, so wrote:
>>> Not to hijack this one but on the other thread i asked why this is
>>> needed.
>>> I am not here asking for syntax or commanding phobos
On 12/12/10 6:44 AM, Jacob Carlborg wrote:
[snip]
Conclusion:
D needs a better and nicer looking syntax for passing delegates to
functions.
Suggestion:
If a function takes a delegate as its last parameter allow the delegate
literal to be passed outside the parameter list, after the function
ca
Lutger Blijdestijn wrote:
> You can't compare freach to code blocks [..] whereas code block
syntax is available to every function in ruby.
Meh, foreach covers the majority of its use anyway, and
plain delegate syntax works just as well for the rest of it.
I can't get worked up over typing parenthe
On 12/12/2010 02:04 AM, Christopher Nicholson-Sauls wrote:
> On 12/11/10 22:41, Matthias Walter wrote:
>> Hi all,
>>
>> I wrote a ByToken tokenizer that models Range, i.e. it can be used in a
>> foreach loop to read from a std.stdio.File. For it to work one has to
>> supply it with a delegate, taki
Steven Schveighoffer Wrote:
> I think 100-nsecs is a good choice for tick resolution.
My concern is millisecond is a SI unit, but hectonanosecond isn't, so I don't
think, it's a good choice: it's hardly comprehensible.
> It gives a very generous range for working
> with, plus is fine-grained
foobar wrote:
> D basically re-writes foreach with opApply into the ruby version
which is why Ruby is *BETTER*
You missed the point: there is no "Ruby version". They are the
same thing.
> foreach to me is a redundant obfuscation
How can it be redundant? It's got the same elements the same
number
On Sun, 12 Dec 2010 16:29:29 + (UTC)
"Adam D. Ruppe" wrote:
> so wrote:
> > Am i alone thinking D one better here?
>
> No, I find foreach to be significantly better than the ruby
> blocks too. I recently argued on the gentoo forums that
> they are virtually equivalent too:
> http://forums.ge
Adam D. Ruppe wrote:
> so wrote:
>> Am i alone thinking D one better here?
>
> No, I find foreach to be significantly better than the ruby
> blocks too. I recently argued on the gentoo forums that
> they are virtually equivalent too:
> http://forums.gentoo.org/viewtopic-p-6500059.html#6500059
>
so wrote:
If we take a look at the very first code example from the talk it looks
like this:
account.people.each do |person|
puts person.name
end
You could translate this in two ways when translating into D.
First way:
foreach (person ; account.people)
writeln(person.name);
Am
On 2010-12-12 11:09:24 -0500, so said:
Normally, yes, I'd agree. But in this case, it's merely a port of the
C++ source code, so all algorithms are identical. The only change I did
initially was to use ranges, but even after replacing those with
mixins, the performance was equally as bad.
Adam D. Ruppe Wrote:
> so wrote:
> > Am i alone thinking D one better here?
>
> No, I find foreach to be significantly better than the ruby
> blocks too. I recently argued on the gentoo forums that
> they are virtually equivalent too:
> http://forums.gentoo.org/viewtopic-p-6500059.html#6500059
>
On 12/12/2010 06:15 AM, Dmitry Olshansky wrote:
> On 12.12.2010 7:25, Matthias Walter wrote:
>> Hi all,
>>
>> there was a discussion in 2006 but w/o a result, and I didn't find any
>> bugs about implicitely casting functions to delegates. It seems to be
>> impossible as long as function-pointer cal
so wrote:
> Am i alone thinking D one better here?
No, I find foreach to be significantly better than the ruby
blocks too. I recently argued on the gentoo forums that
they are virtually equivalent too:
http://forums.gentoo.org/viewtopic-p-6500059.html#6500059
opApply is implemented with a delegat
If we take a look at the very first code example from the talk it looks
like this:
account.people.each do |person|
puts person.name
end
You could translate this in two ways when translating into D.
First way:
foreach (person ; account.people)
writeln(person.name);
Am i alone think
We already have a D block syntax!
=
void myfun(void delegate() lol) {
lol();
}
void main() {
myfun = {
assert(0, "lol");
};
}
==
Totally compiles. :-P
It works with delegate arguments too!
void myfun(void delegate(string) lol) {
Normally, yes, I'd agree. But in this case, it's merely a port of the
C++ source code, so all algorithms are identical. The only change I did
initially was to use ranges, but even after replacing those with mixins,
the performance was equally as bad. There's also no memory allocations,
so t
Walter Bright Wrote:
> Jason House wrote:
> > I wish I had your problems. I ported a sizable set of C++ code to D2 and
> > discovered D2 with dmd was 50x slower than C++ with gcc! I've been to
> > busy/disappointed to track down the bug(s) causing such a slowdown. If
> > anyone
> > is sufficientl
Lutger Blijdestijn wrote:
Simen kjaeraas wrote:
Ary Borenszweig wrote:
Code is read many more times than it is written and so it is of huge
important that code is as readable as possible. Of course this is a
subjective matter, but I don't understand why some people think
__traits
or __gs
spir wrote:
On Sun, 12 Dec 2010 04:00:36 +0100
"Simen kjaeraas" wrote:
So likely, idup on an empty string returns an array with null ptr and
0 length, while "" is 'allocated' in the data segment, and thus given a
ptr value.
.dup & .idup should not change a string's truth value. For sure, _
Jacob Carlborg wrote:
...
>
> If we have a look at the next code example from the talk there is no
> clear and natural way to translate it into D, first the Ruby code:
>
> class PeopleController < ActionController::Base
> before_filter :authenticate
>
> def index
> @people =
I agree with Jacob Carlborg regarding the problem. It would indeed be nice to
have better delegates syntax. But, why are we trying so hard to force the same
syntax that's used for 'regular' function calls? I'm unconvinced that the
suggestions provided are clearer to either the programmer or the
On 2010-12-11 18:21, Andrei Alexandrescu wrote:
On 12/11/10 11:05 AM, so wrote:
Not to hijack this one but on the other thread i asked why this is
needed.
I am not here asking for syntax or commanding phobos team to implement
something, I just want to know about technical limitations and license
On 12.12.2010 7:25, Matthias Walter wrote:
Hi all,
there was a discussion in 2006 but w/o a result, and I didn't find any
bugs about implicitely casting functions to delegates. It seems to be
impossible as long as function-pointer calls work differently than
delegate calls in the ABI. Will this
Simen kjaeraas wrote:
> Ary Borenszweig wrote:
>> Code is read many more times than it is written and so it is of huge
>> important that code is as readable as possible. Of course this is a
>> subjective matter, but I don't understand why some people think __traits
>> or __gshared are ok.
>
> __
== Quote from Jordi (jo...@rovira.cat)'s article
> On 12/08/2010 09:18 PM, Jordi wrote:
> > On 12/08/2010 06:13 AM, Iain Buclaw wrote:
> >> == Quote from Robert Clipsham (rob...@octarineparrot.com)'s article
> >>> On 06/12/10 18:27, dsimcha wrote:
> Apparently LDC2 is being actively worked on
Hello,
After the thread on "String to boolean inconsistency", here is a little
comparison. I think it speaks by itself.
unittest {
auto form = "%s %s %s %s %s %s";
int[] a0;
int[] a1 = [];
writefln(form,
a0?true:false, a1?true:false,
a0 == null,
On Sun, 12 Dec 2010 04:00:36 +0100
"Simen kjaeraas" wrote:
> So likely, idup on an empty string returns an array with null ptr and
> 0 length, while "" is 'allocated' in the data segment, and thus given a
> ptr value.
.dup & .idup should not change a string's truth value. For sure, _this_ is a
On Sun, 12 Dec 2010 03:47:02 +0100
Andrej Mitrovic wrote:
> The first one should fail since the string has length 0. If you use an
> .idup you would get the correct results:
>
> void main()
> {
> string s = "".idup;
> assert(s); // fails
> assert(s != null); // ok
> }
>
> So I guess it's a bu
On 12/08/2010 09:18 PM, Jordi wrote:
On 12/08/2010 06:13 AM, Iain Buclaw wrote:
== Quote from Robert Clipsham (rob...@octarineparrot.com)'s article
On 06/12/10 18:27, dsimcha wrote:
Apparently LDC2 is being actively worked on
(http://bitbucket.org/prokhin_alexey/ldc2/) and is up to date with
t
76 matches
Mail list logo
