bearophile wrote:
After the last posts about patches, I can write something myself about this
topic :-) I am far from being an expert of big software projects, but I think I
am now able to understand some things of the D project.
I like D, it's an alive project, but from what I've seen D so fa
On Tue, 13 Apr 2010 19:29:24 -0400, Steven Schveighoffer
wrote:
Given that structs have become extremely powerful, and with the advent
of opDispatch, would it be possible to deprecate supporting COM via D
interfaces in favor of a library solution?
There are some crappy drawbacks for havi
On Tue, 13 Apr 2010 19:29:24 -0400, Steven Schveighoffer
wrote:
Given that structs have become extremely powerful, and with the advent
of opDispatch, would it be possible to deprecate supporting COM via D
interfaces in favor of a library solution?
There are some crappy drawbacks for havi
On Fri, 09 Apr 2010 12:08:54 -0700, Walter Bright wrote:
> Michael Rynn wrote:
>> In playing around trying to understand and make a better AA, I have
>> updated again the dsource/projects/aa/trunk/druntime/aaA.d, this time
>> to be a single linked list version.
>
> I don't understand, the latest
On Tue, 13 Apr 2010 19:47:13 -0400, Jason House
wrote:
Steven Schveighoffer Wrote:
On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
wrote:
> I'm currently writing a library in D2 which uses intensively
interfaces
> and i meet a problem by overloading the opEquals Operator.
>
> In
Steven Schveighoffer Wrote:
> On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
> wrote:
>
> > I'm currently writing a library in D2 which uses intensively interfaces
> > and i meet a problem by overloading the opEquals Operator.
> >
> > In some of my implementations i want to compare an
Andrej Mitrovic Wrote:
> Personally, I would prefer the left and right brace to stay on the same
> line as the function definition, and maybe add an elipsis between them
> so I can tell that function is folded just by looking at the code.
That's a bit like how Zeus does it's folding:
http
Hello Ezneh,
I think it's not really serious but these examples are pretty true ...
SO Andrei, Walter, have you got some beard for now ?
Last time any one check Walter, didn't. OTOH the last time thoses links came
up was when Walter mentioned doing the evil genus things with a mustache
so wh
On Tue, 13 Apr 2010 19:13:31 -0400, Steven Schveighoffer
wrote:
I confirmed with 2.043 that this is a bug. I'll file with a test case.
http://d.puremagic.com/issues/show_bug.cgi?id=4088
Given that structs have become extremely powerful, and with the advent of
opDispatch, would it be possible to deprecate supporting COM via D
interfaces in favor of a library solution?
There are some crappy drawbacks for having interface be dual-purposed:
- Although 99.9% of interfaces are ac
On Tue, 13 Apr 2010 19:16:21 -0400, Steven Schveighoffer
wrote:
On Tue, 13 Apr 2010 17:27:20 -0400, Christoph Mueller
wrote:
If you are using D2, there is a workaround:
interface I
{
final bool opEquals(I other)
{
Object me = cast(Object)this;
Object they = cast(Object)other;
return equ
On Tue, 13 Apr 2010 17:27:20 -0400, Christoph Mueller
wrote:
If you are using D2, there is a workaround:
interface I
{
final bool opEquals(I other)
{
Object me = cast(Object)this;
Object they = cast(Object)other;
return equals(me, they);
}
}
But it would be nice if the compiler did this aut
On Tue, 13 Apr 2010 18:14:55 -0400, Kagamin wrote:
Steven Schveighoffer Wrote:
Any good reason? No.
But the stated reason is usually that interfaces don't necessarily have
to
be Objects, they can be COM objects, which 1) has no bearing in some
OSes,
and 2) does anyone use this feature?
On Tue, 13 Apr 2010 18:04:04 -0400, Ali Çehreli wrote:
Christoph Mueller is asking the exact problem that I've been having. :)
Steven Schveighoffer wrote:
> If you are using D2, there is a workaround:
>
> interface I
> {
>final bool opEquals(I other)
>{
> Object me = cast
Steven Schveighoffer Wrote:
> Any good reason? No.
>
> But the stated reason is usually that interfaces don't necessarily have to
> be Objects, they can be COM objects, which 1) has no bearing in some OSes,
> and 2) does anyone use this feature?
Which feature? Interfaces? COM? upcasting? or
Christoph Mueller is asking the exact problem that I've been having. :)
Steven Schveighoffer wrote:
> If you are using D2, there is a workaround:
>
> interface I
> {
>final bool opEquals(I other)
>{
> Object me = cast(Object)this;
> Object they = cast(Object)other;
> re
> 1) I've seen that the Node struct inside std.range.SListRange is not a
> static struct, is it a small bug?
Bug 4087. Currently it's not a bug.
> 2) In that List(T) I've used the Range protocol. But I've had to
> add a reset() function too. Isn't it useful for foreach() to call
> a function sim
If you are using D2, there is a workaround:
interface I
{
final bool opEquals(I other)
{
Object me = cast(Object)this;
Object they = cast(Object)other;
return equals(me, they);
}
}
But it would be nice if the compiler did this automatically. There are
other things that suck because interfaces ar
On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
wrote:
I'm currently writing a library in D2 which uses intensively interfaces
and i meet a problem by overloading the opEquals Operator.
In some of my implementations i want to compare an object through an
interface of another instan
Erm, guess that Fantom was the FAN programming language.
bearophile was gentle enough to tell us about this language.
However, impressive work.
I also like freepascal. Here the OS/CPU support really shines.
Bjoern
On 13/04/2010 18:42, sclytrack wrote:
WARNING: Do not read if you don't have the
I'm currently writing a library in D2 which uses intensively interfaces
and i meet a problem by overloading the opEquals Operator.
In some of my implementations i want to compare an object through an
interface of another instance
Unfortanetly, the opEquals Operator uses only Object parameters
Steven Schveighoffer wrote:
> In my opinion? Yes, slower compilers that make code easier to write are
> better. I don't spend lots of time compiling, I spend it writing code.
> And I don't need to babysit the compiler, it goes off and does its thing.
>
> Performance is only important in the end
Nick Sabalausky Wrote:
> So, it would be like this mockup (top is sun-style, bottom is multi-line):
>
> http://www.semitwist.com/download/goodFoldingMore.png
>
Scintilla's folding is line-based: each line is assigned a fold level and
folder hides lines according to these levels (kinda simple py
BCS Wrote:
> I'm not even half joking (maybe a third). This is not a solvable problem.
> That said, I think just flat out avoiding any official stance on formatting
> would be better than what is there.
Indeed. I don't think it should be solved, either. I just don't think the
style guide sh
"maXmo" wrote in message
news:hq1k6n$2om...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> Ahh, I see. No, that's not what I was talking about. This is a mockup of
>> the
>> way I've been wanting it:
>>
>> http://www.semitwist.com/download/goodFolding.png
>>
>> Putting it on the line with the
Hi there, this topic isn't really interesting imo but maybe ...
I wanted to ask Andrei and Walter (and anyone who wants to give me a response)
about those few links :
http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx
http://www.alenz.or
maXmo wrote:
> Nick Sabalausky Wrote:
>
>> Ahh, I see. No, that's not what I was talking about. This is a mockup of the
>> way I've been wanting it:
>>
>> http://www.semitwist.com/download/goodFolding.png
>>
>> Putting it on the line with the "{" seem ridiculous, ugly and just plain
>> sloppy to
On Tue, 13 Apr 2010 13:37:13 -0400, Jérôme M. Berger
wrote:
Steven Schveighoffer wrote:
Jérôme M. Berger Wrote:
Steven Schveighoffer wrote:
When we're talking about the difference between O(1) and O(lgn), I'll
take accuracy over speed in my compiler any day.
And when we're talkin
sclytrack Wrote:
> Fantom programming language. They don't like to be too verbose.
> Link to the examples.
>
> http://fantom.org/doc/examples/index.html
Interesting. Looks like they did a lot.
Steven Schveighoffer wrote:
> using your highbit function, which is very neat BTW
>
Thanks, but I can't claim credit for it. It's a classical algorithm
which comes up regularly in programming discussions and newsgroups...
> uint maxor(uint mina, uint maxa, uint minb, uint maxb)
> {
>
Steven Schveighoffer wrote:
> Steven Schveighoffer Wrote:
>
>> I'll have to double check, I thought I copied your code verbatim (I did
>> switch around the arguments to be minA, maxA, minB, maxB to fit my test
>> harness, and I changed the uint_32_t to uint). I'll check tomorrow at work
>> whe
Fawzi Mohamed wrote:
>
> On 13-apr-10, at 12:02, Don wrote:
>> It's been part of DMD2 for a while now. It allows you to do things like:
>>
>> ubyte lowbits(int x)
>> {
>>return x & 7;
>> }
>>
>> without an explicit cast. The compiler knows that x&7 can safely fit
>> inside a single byte. Wher
Steven Schveighoffer wrote:
> Jérôme M. Berger Wrote:
>
>> Steven Schveighoffer wrote:
>>> When we're talking about the difference between O(1) and O(lgn), I'll
>>> take accuracy over speed in my compiler any day.
>> And when we're talking about the difference between 10s and 55s for
>> a min
WARNING: Do not read if you don't have the time.
Some links to freepascal package not really relevant to D.
These packages appear to be a bit new in freepascal.
There are two links at the bottom of the link
FPC shared library
FPC packages
http://wiki.freepascal.org/Lazarus/FPC_Libraries
-
Don wrote:
Adam D. Ruppe wrote:
On Tue, Apr 13, 2010 at 11:10:24AM -0400, Clemens wrote:
That's strange. Looking at src/backend/cod4.c, function cdbscan, in
the dmd sources, bsr seems to be implemented in terms of the bsr
opcode [1] (which I guess is the reason it's an intrinsic in the
first
Adam D. Ruppe wrote:
On Tue, Apr 13, 2010 at 11:10:24AM -0400, Clemens wrote:
That's strange. Looking at src/backend/cod4.c, function cdbscan, in the dmd
sources, bsr seems to be implemented in terms of the bsr opcode [1] (which I
guess is the reason it's an intrinsic in the first place). I wo
On Tue, Apr 13, 2010 at 11:10:24AM -0400, Clemens wrote:
> That's strange. Looking at src/backend/cod4.c, function cdbscan, in the dmd
> sources, bsr seems to be implemented in terms of the bsr opcode [1] (which I
> guess is the reason it's an intrinsic in the first place). I would have
> expect
On Tue, Apr 13, 2010 at 10:52:14AM -0400, Steven Schveighoffer wrote:
> Just a note, this code should be runnable in C++, because the compiler is
> written in C++. Is bsr available there?
I just assumed since it was in D that it was probably
in DMC too, but I can't find it in the docs, so maybe
Adam Ruppe Wrote:
> Jerome's highbit function is the same as std.intrinsic.bsr. I wonder
> which is faster?
>
> I ran a test, and for 100 million iterations (1..1000), the
> intrinsic beat out his function be a mere 300 milliseconds on my box.
> - highbit ran in an average of 1897 ms and bsr
Steven Schveighoffer:
> I never would have thought of doing a binary search for the high bit, it
> is definitely a novel idea to me :)
You can learn something from this page (it can also be useful for the
translation to C++):
http://graphics.stanford.edu/~seander/bithacks.html
Bye,
bearophile
On Tue, 13 Apr 2010 09:56:34 -0400, Adam Ruppe
wrote:
Jerome's highbit function is the same as std.intrinsic.bsr. I wonder
which is faster?
Just a note, this code should be runnable in C++, because the compiler is
written in C++. Is bsr available there?
Recompiling with -inline -O -re
Jerome's highbit function is the same as std.intrinsic.bsr. I wonder
which is faster?
I ran a test, and for 100 million iterations (1..1000), the
intrinsic beat out his function be a mere 300 milliseconds on my box.
- highbit ran in an average of 1897 ms and bsr did the same in an
average if 1
Steven Schveighoffer wrote:
On Mon, 12 Apr 2010 22:37:00 -0400, Steven Schveighoffer
wrote:
Jérôme M. Berger Wrote:
Steven Schveighoffer wrote:
> Fails for test case:
>
> minA = 4, maxA = 4, minB = 4, maxB = 6 (outputs 7, accurate result
is 6).
>
Nope, outputs 6. Note that I've run
On Tue, 13 Apr 2010 06:13:37 -0400, Steven Schveighoffer
wrote:
Don't forget, opApply is just a function, you can use it as such :)
Oh, and don't forget to always make opApply take a scope delegate!
Otherwise, it allocates the calling function's frame on the heap (in D2 at
least).
-S
On Mon, 12 Apr 2010 22:37:00 -0400, Steven Schveighoffer
wrote:
Jérôme M. Berger Wrote:
Steven Schveighoffer wrote:
> Fails for test case:
>
> minA = 4, maxA = 4, minB = 4, maxB = 6 (outputs 7, accurate result is
6).
>
Nope, outputs 6. Note that I've run an exhaustive search fo
Nick Sabalausky Wrote:
> Ahh, I see. No, that's not what I was talking about. This is a mockup of the
> way I've been wanting it:
>
> http://www.semitwist.com/download/goodFolding.png
>
> Putting it on the line with the "{" seem ridiculous, ugly and just plain
> sloppy to me. (IMO).
>
1. How
On 13-apr-10, at 12:01, bearophile wrote:
Fawzi Mohamed:
I guess that I am missing something obvious, so I don't see the
reason
for range propagation, but maybe I am not the only one, so thanks for
an explanation...
Range propagation can improve the situation a little, so it's not
bad. B
On 13-apr-10, at 12:02, Don wrote:
Fawzi Mohamed wrote:
On 12-apr-10, at 21:40, Steven Schveighoffer wrote:
On Mon, 12 Apr 2010 13:45:14 -0400, Jérôme M. Berger fr> wrote:
Steven Schveighoffer wrote:
J�r�me M. Berger Wrote:
J�r�me M. Berger wrote:
OK, I found a solution that is optima
bearophile Wrote:
> I have not written this as enhancement request on Bugzilla because while I
> have a clear (small) problem, I think my possible solution is bad (see at the
> bottom).
>
[snip]
> To allow both the foreach version with and without index I have to duplicate
> the body of the op
Fawzi Mohamed:
> I guess that I am missing something obvious, so I don't see the reason
> for range propagation, but maybe I am not the only one, so thanks for
> an explanation...
Range propagation can improve the situation a little, so it's not bad. But it
can't replace proper integral overf
Fawzi Mohamed wrote:
On 12-apr-10, at 21:40, Steven Schveighoffer wrote:
On Mon, 12 Apr 2010 13:45:14 -0400, Jérôme M. Berger
wrote:
Steven Schveighoffer wrote:
J�r�me M. Berger Wrote:
J�r�me M. Berger wrote:
OK, I found a solution that is optimal in over 99% of the cases
(99.195%
On 12-apr-10, at 21:40, Steven Schveighoffer wrote:
On Mon, 12 Apr 2010 13:45:14 -0400, Jérôme M. Berger
wrote:
Steven Schveighoffer wrote:
J�r�me M. Berger Wrote:
J�r�me M. Berger wrote:
OK, I found a solution that is optimal in over 99% of the cases
(99.195% to be precise), w
Some musings about vectorizations.
The benchmarks of the Shootout site sometimes are useful, because they are well
chosen to cover a wide variety of computations and kinds of common kernels.
One of those benchmarks is the n-body, this is one of the faster
implementations, in C:
http://shootout.a
I have not written this as enhancement request on Bugzilla because while I have
a clear (small) problem, I think my possible solution is bad (see at the
bottom).
This is how I can use opApply() to create a lazy generator of the first
Fibonacci numbers, inside opApply there can be a good amount
Inside std.range there is a template struct that implements the chain:
struct ChainImpl(R...) {
plus a tiny helper function 'chain' that's usually the one used in the user
code:
Chain!(R) chain(R...)(R input) {
static if (input.length > 1)
return Chain!(R)(input);
else
r
On 2010-04-12 11:09, "Jérôme M. Berger" wrote:
Chris Mueller wrote:
On what OS? On linux, you can do:
time foo
to get the run time for program foo, including elapsed clock time,
time spent in the program itself and time spent in the kernel on
behalf of the program (for I/O, mallocs, etc);
"Nick Sabalausky" wrote in message
news:hq142v$1hh...@digitalmars.com...
> "maXmo" wrote in message
> news:hq0qrq$13p...@digitalmars.com...
>> I had exactly same reason: old folding works only for sun style, my
>> folding treats sun and ms style equally.
>> See: http://i42.tinypic.com/2qjx1mf.
57 matches
Mail list logo
