On 02/26/2014 06:58 AM, bearophile wrote:

> Updated the site

> http://rosettacode.org/wiki/Rendezvous#D

Thanks for posting the problem to begin with. I've learned a lot.

Ali

On Wednesday, 26 February 2014 at 14:54:05 UTC, Ali Çehreli wrote:
> On 02/26/2014 03:24 AM, bearophile wrote:
>
> > Ali Çehreli:
> >
> >> Improve at will! :p
> >
> > I will mostly just uniform its formatting to all the other
> Rosettacode
> > entries, shorten the lines to 72 chars, etc.
> >
> >
> >>                 synchronized {
> >>                     // Switch to the next printer
> >>                     printers = printers[1..$];
> >>                 }
> >
> > This doesn't work:
> >
> > printers.popFront();
>
> I've noticed that too. ;) And I am not sure why the slicing syntax works because the 'printers' member is still shared then.

It fails to deduce argument types due to popFront() taking its argument by ref.
That's actually good it caught that, because I don't think that slicing should be allowed either.

> > It it a good idea to define Printer.print like this to remove
> that cast?
> >
> > void print(string line) shared
>
> I had that at one point but then I could not convince myself that Printer.print should be a shared member function. How do we know at design time that every Printer would be shared? I thought that Printer should be as simple as possible and that shared should be handled by a higher-level code. Then the code became ugly like that. :)

Indeed it shouldn't really be shared in this case, since it's used exclusively in the terms of lock-based synchronization. Ideally, it could be made entirely private to RendezvoudPrinter.
But the transitivity of "shared" keyword still forces us to apply casts.

It has little to do with experience. The whole 'shared' concept being incomplete in the language is a shame. Hopefully things will get better in the near future.

As for slicing syntax for shared arrays, personally I think it should be disallowed, just like operators for shared scalars. But that would mean that calling front() would be illegal too, thus forcing the cast on the whole array when it's safe to do so... Oh, there is still much to discuss on this matter.

Stanislav Blinov:

> The whole 'shared' concept being incomplete in the language is a shame. Hopefully things will get better in the near future.
>
> As for slicing syntax for shared arrays, personally I think it should be disallowed, just like operators for shared scalars. But that would mean that calling front() would be illegal too, thus forcing the cast on the whole array when it's safe to do so... Oh, there is still much to discuss on this matter.

I am not seeing much discussion on such topics in the near future. It's one of the most significant bugs of D (bigger than the unimplemented "scope").

This is why Andrei lately is not fond of large discussions about little enhancement requests in the main D newsgroup: there are plenty of significant parts still unfinished.

Bye,
bearophile

Thank you for posting the code. However, I think there might be a subtle bug with my synchronization on bools, but I need to comtemplate on it some more to be sure :)

On Wednesday, 26 February 2014 at 15:52:24 UTC, bearophile wrote:
> Stanislav Blinov:

>> Oh, there is still much to discuss on this matter.
>
> I am not seeing much discussion on such topics in the near future. It's one of the most significant bugs of D (bigger than the unimplemented "scope").
>
> This is why Andrei lately is not fond of large discussions about little enhancement requests in the main D newsgroup: there are plenty of significant parts still unfinished.

He has recently stated that this should be a focus this year: http://forum.dlang.org/post/ldnv5g$1osi$1@digitalmars.com.  I'm hoping to get some time this weekend to get to that wiki page business...

On Tuesday, 12 February 2013 at 01:07:35 UTC, bearophile wrote:
>
> In practice at the moment I am maintaining all the D entries of Rosettacode.
>

I modified the Hamming numbers code in a personal exercise.
It now uses considerably less memory but is slower.

I've posted the code here in case it is of use: http://dpaste.dzfl.pl/3990023e5577

For a single n, n = 350_000_000:
Alternative version 2: 13.4s and ~5480 MB of ram
My code: 21s and ~74 MB of ram

Regards.

safety0ff:

> I modified the Hamming numbers code in a personal exercise.
> It now uses considerably less memory but is slower.
>
> I've posted the code here in case it is of use: http://dpaste.dzfl.pl/3990023e5577
>
> For a single n, n = 350_000_000:
> Alternative version 2: 13.4s and ~5480 MB of ram
> My code: 21s and ~74 MB of ram

I have added your version, with small changes and improvements.


I suggest to not put attributes like this:


    static struct Candidate
    {
        typeof(Hamming.ln) ln;
        typeof(Hamming.e) e;
        pure nothrow:
        void increment(size_t n)
        {
            e[n] += 1;
            ln += lnprimes[n];
        }
        const:
        bool opEquals(T)(in ref T y) {
            // return this.e == y.e; // slow
            return !((this.e[0] ^ y.e[0]) | (this.e[1] ^ y.e[1]) | (this.e[2] ^ y.e[2]));
        }
        int opCmp(T)(in ref T y) {
            return ln > y.ln ? 1 : (ln < y.ln ? -1 : 0);
        }
    }

Bye,
bearophile

On Tuesday, 12 February 2013 at 01:07:35 UTC, bearophile wrote:
>
> In practice at the moment I am maintaining all the D entries of Rosettacode.
>

Here's a candidate for http://rosettacode.org/wiki/Extensible_prime_generator#D in case it is preferred to the existing entry:
http://dpaste.dzfl.pl/43735da3f1d1

safety0ff:

> Here's a candidate for http://rosettacode.org/wiki/Extensible_prime_generator#D in case it is preferred to the existing entry:
> http://dpaste.dzfl.pl/43735da3f1d1

I was away. I have added your nice code with some small changes as an alternative faster version. I think you have compiled your code without -wi, so I have added a "goto default;" inside the third switch case of the sieveOne function.

Bye,
bearophile