www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - A little of coordination for Rosettacode

reply "bearophile" <bearophileHUGS lycos.com> writes:
Is the Fwend user of Rosettacode (or some other interested 
person) around here? I have written partial D implementations for 
three tasks, maybe a little of coordination will speedup the work:

http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation
http://rosettacode.org/wiki/Universal_Turing_machine
http://rosettacode.org/wiki/RCRPG

Bye,
bearophile
Feb 04 2013
next sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 5-2-2013 0:55, bearophile wrote:
 Is the Fwend user of Rosettacode (or some other interested person) around
here? I have written partial D implementations
for three tasks, maybe a little of coordination will speedup the work:

 http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation
 http://rosettacode.org/wiki/Universal_Turing_machine
 http://rosettacode.org/wiki/RCRPG
I'll give it a shot if you like. The RCRPG I'd like to try first. By the way, I think 'Qznc' may want to have a look at 'The dining philosophers': http://rosettacode.org/wiki/Dining_philosophers
Feb 05 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 I'll give it a shot if you like. The RCRPG I'd like to try 
 first.
I have already partially written those: Partial translation of rcrpg-Python: http://codepad.org/SflrKqbT Partial translation of permutations_rank_of_a_permutation-Python: http://codepad.org/El9SQwOE Plus a better Perl implementation of the uniform() on BigInts: http://codepad.org/LGcMpk2f Partial translation of the universal_turing_machine-Ruby: http://codepad.org/nUXLzAg2 Bye, bearophile
Feb 05 2013
next sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 5-2-2013 21:10, bearophile wrote:

How do we avoid working on the same thing?

 Partial translation of rcrpg-Python:
 http://codepad.org/SflrKqbT

 Partial translation of permutations_rank_of_a_permutation-Python:
 http://codepad.org/El9SQwOE
The 2 above, I could try.
 Plus a better Perl implementation of the uniform() on BigInts:
 http://codepad.org/LGcMpk2f
My perl is too rusty.
 Partial translation of the universal_turing_machine-Ruby:
 http://codepad.org/nUXLzAg2
I'd have to first read up on the subject.
 Bye,
 bearophile
Feb 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 How do we avoid working on the same thing?
With a little coordination :-)
 Partial translation of rcrpg-Python:
 http://codepad.org/SflrKqbT

 Partial translation of 
 permutations_rank_of_a_permutation-Python:
 http://codepad.org/El9SQwOE
The 2 above, I could try.
 Plus a better Perl implementation of the uniform() on BigInts:
 http://codepad.org/LGcMpk2f
My perl is too rusty.
That perl is meant as a part of permutations_rank_of_a_permutation. Feel free to search for other good algorithms to implement uniform(BigInt,BigInt) much better than me. If this code comes out good enough, it must be added to Phobos (and it's meant to be designed better than the Java uniform generator for its bigintegers, because it doesn't give a correct range).
 Partial translation of the universal_turing_machine-Ruby:
 http://codepad.org/nUXLzAg2
I'd have to first read up on the subject.
It's a simple task, just to implement an universal Turing machine. It's a matter of finding a balance between the too much high level Ruby version and a too much C-like version. In D a simple way to implement a tape is with two dynamic arrays, one represents all the cells on the right to the starting position, and the other array is used "inverted", to represent all the cells on the left of the right position. There are faster solutions, but this is enough for the purposes of Rosettacode. Bye, bearophile
Feb 05 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 5-2-2013 23:44, bearophile wrote:
 Jos van Uden:
 Partial translation of the universal_turing_machine-Ruby:
 http://codepad.org/nUXLzAg2
I'd have to first read up on the subject.
It's a simple task, just to implement an universal Turing machine. It's a matter of finding a balance between the too much high level Ruby version and a too much C-like version. In D a simple way to implement a tape is with two dynamic arrays, one represents all the cells on the right to the starting position, and the other array is used "inverted", to represent all the cells on the left of the right position. There are faster solutions, but this is enough for the purposes of Rosettacode.
The Universal Turing Machine is working. I've only tested with the given tables. I'll try some more tomorrow. I couldn't get the AA's to nest the way they do in Ruby, so I had to do it differently. This task seemed like a good candidate for using an invariant, but the loop in the run method already checks the state on every iteration, so I'm not sure what you could check except to see if all the fields have been initialized perhaps. It was a fun task. http://dpaste.dzfl.pl/3caa52e7
Feb 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 The Universal Turing Machine is working.
There are many different ways to solve this Task in D. You can write a very strongly typed Ada-like program, or a weakly typed Ruby-like program. Both have advantages and disadvantages (as years pass I am leaning more toward a stronger static typing, despite I like Python). Your version is more toward the weakly typed end of the spectrum (but not as much as Ruby). I am now reading your code. - - - - - - - - - - This is bad: void move(in int dir) { final switch(dir) { case UTM.left: left(); break; case UTM.right: right(); break; case UTM.stay: stay(); break; } } "final switche" was introduced in D to increase safety making the code more strongly typed, but there you are relying on a DMD bug, and that piece of code is the opposite of safe. A correct D compiler must refuse your code: http://d.puremagic.com/issues/show_bug.cgi?id=5713 I have rewritten it like this: void move(in int dir) { switch(dir) { case UTM.left: left(); break; case UTM.right: right(); break; case UTM.stay: stay(); break; default: assert(0); } } If you want to write a stronger typed code you can give a name to that enum, and then it's a good idea to use a final switch. But then the associative array "rules" must have Tuples (or structs) as values. - - - - - - - - - -
 I couldn't get the AA's to nest the way they do in Ruby, so
 I had to do it differently.
I will take a look at this later. Maybe it's a known AA bug. - - - - - - - - - -
 This task seemed like a good candidate for using an invariant,
 but the loop in the run method already checks the state on
 every iteration, so I'm not sure what you could check except
 to see if all the fields have been initialized perhaps.
Seems good to do, but maybe a pre-condition is enough. - - - - - - - - - - Instead of using toString() maybe it's better to add a printTape, and let run() return nothing. I have also converted UTM to a struct, because for this little program it doesn't need to be a class (and there is no need of new). - - - - - - - - - - I am not so fond of the D idiom of using general Exceptions, I'd like to use a bit more variety of Phobos-defined exceptions. But in this little program I think using two basic Exception is acceptable. - - - - - - - - - - The two casts in your code are bad, generally in D you don't cast to mutable or to immutable, because it's dangerous and unclean. So I will (try to) remove them: this(ref TuringMachine tm) { this.tm = cast(immutable)tm; this.head = TapeHead(this.tm); } void run() { if (this.halted) throw new Exception("Machine already halted."); auto state = cast()this.tm.initialState; - - - - - - - - - - Maybe later I'll write more comments. Bye, bearophile
Feb 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 Instead of using toString() maybe it's better to add a 
 printTape, and let run() return nothing. I have also converted 
 UTM to a struct, because for this little program it doesn't 
 need to be a class (and there is no need of new).
I meant the opposite, sorry: printTape() ==> toString() Bye, bearophile
Feb 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
A first revision, do you like the toString?

http://codepad.org/qhH2XpMx

- - - - - - - - - - -

The modified code contains still an enum that gets converted to 
char and then to int. I am not going to write code like that in 
my own "production code" :-)

- - - - - - - - - - -

To improve this type soup a bit I suggest to introduce one or 
more alias for the types of states, etc, like:

alias State = char;

and then use it/them.


static struct TuringMachine {
     char[] symbols;
     char blank;
     char initialState;
     char[] haltStates, runningStates;
     char[][string] rules;
     char[] input;
}

static struct TapeHead {
     const char[] symbols;
     const char blank;
     char[] tape;
     size_t index;
...

- - - - - - - - - - -

Bye,
bearophile
Feb 15 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 16-2-2013 3:34, bearophile wrote:
 A first revision, do you like the toString?

 http://codepad.org/qhH2XpMx
It's fine, but we need another write at the end of run otherwise the final state doesn't get written.
 The modified code contains still an enum that gets converted to char and then
to int.
I am not going to write code like that in my own "production code" :-)
 - - - - - - - - - - -

 To improve this type soup a bit I suggest to introduce one or more alias for
the types of states, etc, like:

 alias State = char;
Good idea. I'll change that. I'm still not happy with the TuringMachine creation although it looks more organized than before. I'm thinking about putting the definitions in xml, then have a parser create an immutable TuringMachine that we can then pass to UTM. That would also take care of the nested AA problem. The rules object can then have a tuple or a struct. BTW, the reason I used a class is that it forces you to instantiate through the constructor. If you use a class and write: (new UTM().run()); // fails at compile time If you use a struct and write: UTM().run(); // fails at runtime
Feb 16 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 It's fine, but we need another write at the end of run 
 otherwise the final state doesn't get written.
OK. Feel free to fix the code: http://codepad.org/MvpSET1I Writing good enough code is an iterative process... And this code will probably need few more iterations.
 I'm thinking about putting the definitions in xml,
Please no :-) Especially in a such small program.
 BTW, the reason I used a class is that it forces you to 
 instantiate through the constructor.

 If you use a class and write:

 (new UTM().run()); // fails at compile time

 If you use a struct and write:

 UTM().run(); // fails at runtime
OK, feel free to change back the code to a final class. We'll try to find a better solution in successive iterations. Bye, bearophile
Feb 16 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 BTW, the reason I used a class is that it forces you to 
 instantiate through the constructor.
One possible solution: http://codepad.org/9PO8hpI7 Bye, bearophile
Feb 16 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 16-2-2013 14:04, bearophile wrote:
 Jos van Uden:

 BTW, the reason I used a class is that it forces you to instantiate through
the constructor.
One possible solution: http://codepad.org/9PO8hpI7
Initializing the struct that way didn't work because I changed the AA back to nested. This is what I have now (incorperated part of your suggestions): http://codepad.org/wjaSgppT
Feb 16 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 This is what I have now (incorperated part of your suggestions):

 http://codepad.org/wjaSgppT
It looks good. It's not a strongly typed code (because states are just chars), and it's not much flexible because UTM is not templated on Symbol and State, but for this task it's OK. Some small changes: http://codepad.org/r4NkxTcn Before putting it in Rosettacode the UTM constructor needs a pre-condition that verifies the full correctness of all its inputs. Then do you want to put it in Rosettacode yourself? Bye, bearophile
Feb 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
By the way, with this little program I have found two new 
compiler bugs, I will put it in Bugzilla later.

Bye,
bearophile
Feb 16 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 with this little program I have found two new compiler bugs, I 
 will put it in Bugzilla later.
http://d.puremagic.com/issues/show_bug.cgi?id=9520 http://d.puremagic.com/issues/show_bug.cgi?id=9521 Bye, bearophile
Feb 16 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
The version you have put in Rosettacode is good, I have just 
added some missing tests at the beginning of the UTM constructor.

Annotations like this are reminders of DMD bugs/limits that 
hopefully we'll be fixed/lifeted:
foreach (/*const*/ s, const rule; aa) {


While this annotation:
alias State = char; // Typedef?

means that in a stronger typed entry maybe State should be (but 
we have also to benchmark if this doesn't decrease the program 
performance for a successive bigger Busy Beaver machine):
alias State = Typedef!char;


This little program is pedagogically very good at showing the 
difference between weak and strong static typing. In a strongly 
static typed version all (or most) of those run-time tests are 
not needed.

Bye,
bearophile
Feb 16 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 16-2-2013 18:23, bearophile wrote:
 The version you have put in Rosettacode is good, I have just added some
missing tests at the beginning
  of the UTM constructor.
I added that precondition reluctantly, that's why its short :-). I really feel that input validation should be done elsewhere. I was thinking about adding a factory method to the UTM that accepts a string array, parses and validates it, and returns a fully initialized immutable TuringMachine. It would still be a lot of ugly code though. That stronger typing can reduce the need for input checking is something I find interesting. I'll have a look at the Ada code.
 (but we have also to benchmark if this doesn't decrease the program
performance for a
  successive bigger Busy Beaver machine):
On the other hand, if we have stronger typing we may not have to do the rather expensive checks that are currently in the loop.
Feb 16 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 I added that precondition reluctantly, that's why its short 
 :-). I really feel that
 input validation should be done elsewhere.
A full validation needs to be done somewhere :-)
 I was thinking about adding a factory method to the UTM that 
 accepts a string array,
 parses and validates it, and returns a fully initialized 
 immutable TuringMachine.
 It would still be a lot of ugly code though.
Probably in D there are better solutions.
 That stronger typing can reduce the need for input checking is 
 something I find interesting.
It's interesting :-) A strong typing has some disadvantages (the code is more fussy, the program usually gets a little less easy to read and a little longer, etc.), but it has some advantages too. Languages like Ada, Haskell and ATS enjoy such strong typing to avoid many bugs and many run-time errors. In some Rosettacode Tasks I have put two different solutions, one less and one more strongly typed: http://rosettacode.org/wiki/Hidato#D http://rosettacode.org/wiki/Matrix_multiplication#D There are languages like ATS (http://www.ats-lang.org/ ) able to catch statically many problems otherwise found at run-time in lesser languages. Well written ATS programs are also fast as C programs, so there is no loss in performance. On the other hand writing ATS code is not easy.
 I'll have a look at the Ada code.
Ada code is very readable (far more than C++). But compared to D you have to write too much code.
 (but we have also to benchmark if this doesn't decrease the 
 program performance for a
 successive bigger Busy Beaver machine):
On the other hand, if we have stronger typing we may not have to do the rather expensive checks that are currently in the loop.
Right :-) Onward to the next Rosetta tasks :-) Bye, bearophile
Feb 16 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
There is a way to make the D code faster: prepending a cell in 
left() is a slow operation:

void right() pure nothrow {
     this.position++;
     if (this.position == this.tape.length)
         this.tape ~= this.blank;
}

void left() pure nothrow {
     if (this.position == 0)
         this.tape = this.blank ~ this.tape;
     else
         this.position--;
}


If you want to make the code faster (useful for a larger Busy 
Beaver simulation), you keep two tapes as two dynamic arrays. One 
tape represents the items on the right of the origin and the 
other tape on the left of the origin. So the position becomes a 
signed integer and both left() and right() use a fast append 
operation.

Bye,
bearophile
Feb 16 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 16-2-2013 19:55, bearophile wrote:
 There is a way to make the D code faster: prepending a cell in left() is a
slow operation:

 void right() pure nothrow {
      this.position++;
      if (this.position == this.tape.length)
          this.tape ~= this.blank;
 }

 void left() pure nothrow {
      if (this.position == 0)
          this.tape = this.blank ~ this.tape;
      else
          this.position--;
 }


 If you want to make the code faster (useful for a larger Busy Beaver
simulation), you keep two tapes as two dynamic arrays. One tape represents the
items on the right of the origin and the other tape on the left of the origin.
So the position becomes a signed integer and both left() and right() use a fast
append operation.
Yes, that was your original suggestion, but I didn't quite understand it, so I went with the Ruby solution. You would reverse the left array when printing, is that correct?
Feb 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 Yes, that was your original suggestion, but I didn't quite 
 understand it,
When you don't understand something I say, please ask for more info :-)
 You would reverse the left array when printing, is that correct?
Right, the second half of the tape keeps the cells in reverse order. Bye, bearophile
Feb 16 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 16-2-2013 21:23, bearophile wrote:
 Jos van Uden:

 Yes, that was your original suggestion, but I didn't quite understand it,
When you don't understand something I say, please ask for more info :-)
 You would reverse the left array when printing, is that correct?
Right, the second half of the tape keeps the cells in reverse order.
I've split the tape in left and right. It does make the code a bit harder to understand and debug. A linkedlist would have been more elegant, but slower I guess. The stress test that was posted on the talk page, I've also added. Our UTM produces the correct result but with redundant blanks on both sides. 0111111222222220 ^ http://codepad.org/2SK611Wd
Feb 17 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 I've split the tape in left and right. It does make the code a 
 bit harder to understand and debug.
You have used three tapes and a unsigned position, while I think a signed position and two tapes is enough: static struct TapeHead { immutable Symbol blank; Symbol[] tape, left, right; size_t position; The code becoming a little longer and a little less easy to understand was expected. But is it worth doing it for this Rosettacode Task? I think it's not worth making the code more complex. With the tm3 the new code prints the last two states: 0111111222222220 ^ 0111111222222220 ^ While the older code prints something different and probably more correct: 0111111222222220 ^ 0111111222222220 ^
 A linkedlist would have been more elegant, but slower I guess.
On modern CPUs 99% of the times linked lists are the wrong data structure to use. They have low data density and incur in high cache misses. Benchmarks shows that in some cases arrays need to be preferred even when deletions in the middle are not so common. Linked lists are better when you have to insert and remove many items randomly in the middle of the sequence and you don't have to transverse all the sequence often. This double condition is not so common.
 The stress test that was posted on the talk page, I've also 
 added.
Good. It's better to add it to the precedent version of the UTM.
 Our UTM produces the correct result but with redundant blanks on
 both sides.

 0111111222222220
  ^
A Turning Machine is supposed to have a tape that is infinite in both directions, so when you print the tape you trim the blanks away at both ends. So a better printing is: ...11111122222222... Or: Incrementer: ...111... ^ ...111... ^ ...111... ^ ...1110... ^ ...1111... ^ Bye, bearophile
Feb 17 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 so when you print the tape you trim the blanks away at both 
 ends.
A wrong trimming code: string toString() const { // Blank-stripped tape. const t2 = tape .find!(c => c != blank)() .retro() .find!(c => c != blank)() .retro(); return format("...%(%)...", t2.empty ? [blank] : t2) ~ '\n' ~ format("%" ~ text(position + 4) ~ "s", "^") ~ '\n'; } It gives: Busy beaver machine (3-state, 2-symbol): ...0... ^ ...1... ^ The second line should show the cell up to the head position: Busy beaver machine (3-state, 2-symbol): ...0... ^ ...10... ^ There are many ways to improve this program, like trimming away the blanks correctly, but I think the code is acceptable now: http://rosettacode.org/wiki/Universal_Turing_machine#D Bye, bearophile
Feb 17 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 5 February 2013 at 20:10:37 UTC, bearophile wrote:
 Jos van Uden:

 I'll give it a shot if you like. The RCRPG I'd like to try 
 first.
I have already partially written those: Partial translation of rcrpg-Python: http://codepad.org/SflrKqbT Partial translation of permutations_rank_of_a_permutation-Python: http://codepad.org/El9SQwOE Plus a better Perl implementation of the uniform() on BigInts: http://codepad.org/LGcMpk2f Partial translation of the universal_turing_machine-Ruby: http://codepad.org/nUXLzAg2 Bye, bearophile
codepad.org doesn't work at all here. Maybe you should use dpaste (or pastebin for other languages) instead ?
Feb 09 2013
next sibling parent Jos van Uden <usenet fwend.com> writes:
On 9-2-2013 23:14, SomeDude wrote:
  
 codepad.org doesn't work at all here. Maybe you should use dpaste (or pastebin
for other languages) instead ?
It's not working for me either. It's probably a temporary problem. It worked fine before.
Feb 09 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
SomeDude:

...
 Partial translation of rcrpg-Python:
 http://codepad.org/SflrKqbT

 Partial translation of 
 permutations_rank_of_a_permutation-Python:
 http://codepad.org/El9SQwOE
 Plus a better Perl implementation of the uniform() on BigInts:
 http://codepad.org/LGcMpk2f

 Partial translation of the universal_turing_machine-Ruby:
 http://codepad.org/nUXLzAg2

 Bye,
 bearophile
codepad.org doesn't work at all here. Maybe you should use dpaste (or pastebin for other languages) instead ?
Links in the same order: http://dpaste.dzfl.pl/10eff346 http://dpaste.dzfl.pl/bfde8010 http://dpaste.dzfl.pl/3a172308 http://dpaste.dzfl.pl/22b7a931 Bye, bearophile
Feb 09 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 10-2-2013 1:57, bearophile wrote:
 ...
 Partial translation of rcrpg-Python:
 http://codepad.org/SflrKqbT
I have the rcrpg working, but I want to test it some more. I'm not very happy with the alias function, it accepts just about any input, it can put the program in an invalid state. There was a bug by the way in the Python code, that slowed me down a bit. As for the "getattr", I've hacked a CTFE loop together that writes out if statements. I'm not sure how robust it is. We can always go for a handwritten "if else" or switch block. http://dpaste.dzfl.pl/5e6b824e
Feb 11 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 I have the rcrpg working, but I want to test it some more.
Good. Adding a bit of unittesting is acceptable, I think.
 I'm not very happy
 with the alias function, it accepts just about any input, it 
 can put the program in an invalid state.
I presume this is a design bug shared with the original Python code. You have also fixed a translation bug of mine with remove(). I don't like that function. In past I did another mistake (in another program), forgetting to assign its result back to the array.
 There was a bug by the way in the Python code, that slowed me 
 down a bit.
D static type system asks for more coding work, but it has caught very quickly that bug of this line of Python code: tokens[0] = aliases[tokens[0]] Dynamic typing has some advantages and in some cases it's handy, but it has some disadvantages too. On the other hand I think that Python code was not well tested; Python unittesting is able to catch most of similar bugs. I think we should fix the Python entry too (or at least add a note in the Talk page).
 As for the "getattr", I've hacked a CTFE loop together that 
 writes out if statements. I'm not sure how robust it is.
I think in normal D code you don't catch Throwable, but maybe in this case it's OK.
 http://dpaste.dzfl.pl/5e6b824e
The D code has lot of imports because Python has a ton of built-in things. I have shortened the lines to about 72 chars max, and reformatted the code a bit. If you like it and you have a Rosettacode account, you can put it there yourself (otherwise I'll do it myself). If later you find bugs or you want to change something, there's always the possibility to modify it on the site. http://dpaste.dzfl.pl/6778053f In practice at the moment I am maintaining all the D entries of Rosettacode. I keep the coding style uniform, but sometimes I change some parts of such style on purpose to show different ways to use D, or specific things. Several Rosettacode solutions have more than one D entry, like when there is a very short and high-level entry and a longer and low level entry that's faster. Bye, bearophile
Feb 11 2013
parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
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.
Jul 30 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 31 2014
prev sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
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
Aug 07 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Aug 14 2014
prev sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 5-2-2013 20:45, Jos van Uden wrote:
  
 By the way, I think 'Qznc' may want to have a look at 'The dining
 philosophers':

 http://rosettacode.org/wiki/Dining_philosophers
Feb 15 2013
parent reply "qznc" <qznc go.to> writes:
On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden wrote:
 On 5-2-2013 20:45, Jos van Uden wrote:
 
 By the way, I think 'Qznc' may want to have a look at 'The 
 dining
 philosophers':

 http://rosettacode.org/wiki/Dining_philosophers
Am I the new rosetta concurency guy? :) I should find the time to solve it this weekend.
Feb 15 2013
parent reply "qznc" <qznc go.to> writes:
On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
 On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden 
 wrote:
 On 5-2-2013 20:45, Jos van Uden wrote:
 
 By the way, I think 'Qznc' may want to have a look at 'The 
 dining
 philosophers':

 http://rosettacode.org/wiki/Dining_philosophers
I should find the time to solve it this weekend.
Wow, my kid let me do some hacking right now and it was simpler than expected. Posted a solution already.
Feb 15 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 16 February 2013 at 07:58:56 UTC, qznc wrote:
 On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
 On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden 
 wrote:
 On 5-2-2013 20:45, Jos van Uden wrote:
 
 By the way, I think 'Qznc' may want to have a look at 'The 
 dining
 philosophers':

 http://rosettacode.org/wiki/Dining_philosophers
I should find the time to solve it this weekend.
Wow, my kid let me do some hacking right now and it was simpler than expected. Posted a solution already.
Hum... //---- Mutex[5] forks = new Mutex(); //---- This will allocate a single Mutex, and place the same reference in all five entries of forks. In a word: There is actually only one fork. The philosophers can still dine, because a single thread is allowed to lock the same resource twice, making the problem trivial. Basically, they are dual wielding the fork ;) The correct line of code should be: //---- Mutex[5] forks; foreach(ref fork; forks) fork = new Mutex(); //---- Or some variation thereof of course. The code still works with this change. I'm reporting it instead of correcting it directly, so as to better explain how and why.
Feb 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:

 I'm reporting it instead of correcting it directly, so as to 
 better explain how and why.
Thank you, some bugs are interesting. I will change the code. Bye, bearophile
Feb 16 2013
parent reply Jos van Uden <usenet fwend.com> writes:
The chirality of the given output on Langtons ant  doesn't match what
the code produces. (That's because somebody changed it a while ago).
See also the talk page.

http://rosettacode.org/wiki/Langton%27s_ant#D
Feb 19 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 The chirality of the given output on Langtons ant  doesn't 
 match what the code produces.
OK. I have changed the first entry. Bye, bearophile
Feb 19 2013
parent reply Jos van Uden <usenet fwend.com> writes:
Somebody added an incorrect notice to the D entry for Dijkstra's algorithm.
http://rosettacode.org/mw/index.php?title=Dijkstra%27s_algorithm&diff=next&oldid=147068
Feb 22 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 Somebody added an incorrect notice to the D entry for 
 Dijkstra's algorithm.
The task requires a directed graph: 1. Implement a version of Dijkstra's algorithm that computes a shortest path from a start vertex to an end vertex in a directed graph. So I have fixed the graph. Bye, bearophile
Feb 22 2013
prev sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 16-2-2013 8:58, qznc wrote:
 On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
 On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden wrote:
 On 5-2-2013 20:45, Jos van Uden wrote:

 By the way, I think 'Qznc' may want to have a look at 'The dining
 philosophers':

 http://rosettacode.org/wiki/Dining_philosophers
I should find the time to solve it this weekend.
Wow, my kid let me do some hacking right now and it was simpler than expected. Posted a solution already.
Wow, that was quick. Thanks!
Feb 16 2013
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Saturday, 16 February 2013 at 11:30:00 UTC, Jos van Uden wrote:
 On 16-2-2013 8:58, qznc wrote:
 On Saturday, 16 February 2013 at 06:58:01 UTC, qznc wrote:
 On Saturday, 16 February 2013 at 02:23:42 UTC, Jos van Uden 
 wrote:
 On 5-2-2013 20:45, Jos van Uden wrote:

 By the way, I think 'Qznc' may want to have a look at 'The 
 dining
 philosophers':

 http://rosettacode.org/wiki/Dining_philosophers
I should find the time to solve it this weekend.
Wow, my kid let me do some hacking right now and it was simpler than expected. Posted a solution already.
Wow, that was quick. Thanks!
The current D code for Dining philosophers does not compile with dmd v2.063.2, the error message being dining.d(34): Error: cannot uniquely infer foreach argument types The code looks OK to me (but I'm a D newbie) so I wonder if someone could explain the inference issue. Where should an annotation be added to allow this to compile? 1 import std.stdio, std.algorithm, std.string, std.parallelism, 2 core.sync.mutex; 3 4 void eat(in uint i, in string name, Mutex[] forks) { 5 writeln(name, " is hungry."); 6 7 immutable j = (i + 1) % forks.length; 8 9 // Take forks i and j. The lower one first to prevent deadlock. 10 auto fork1 = forks[min(i, j)]; 11 auto fork2 = forks[max(i, j)]; 12 13 fork1.lock(); 14 scope(exit) fork1.unlock(); 15 16 fork2.lock(); 17 scope(exit) fork2.unlock(); 18 19 writeln(name, " is eating."); 20 writeln(name, " is full."); 21 } 22 23 void think(in string name) { 24 writeln(name, " is thinking."); 25 } 26 27 void main() { 28 const philosophers = "Aristotle Kant Spinoza Marx Russell".split(); 29 Mutex[philosophers.length] forks; 30 foreach (ref fork; forks) 31 fork = new Mutex(); 32 33 defaultPoolThreads = forks.length; 34 foreach (uint i, philo; taskPool.parallel(philosophers)) { 35 foreach (_; 0 .. 100) { 36 eat(i, philo, forks); 37 think(philo); 38 } 39 } 40 } BTW, I like the coding style being used in the rosetta examples and TDPL much better than the library style. -- Brian
Jun 22 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Brian Rogoff:

 The current D code for Dining philosophers does not compile 
 with dmd v2.063.2, the error message being

 dining.d(34): Error: cannot uniquely infer foreach argument 
 types
I try to keep the D entries on Rosettacode updated, but every dmd release breaks tons of code, and Rosettacode has almost one thousand D programs (many tasks have two or more D entries, to show different solutions or different coding style, or to show code with different tradeoffs, etc), so you find some broken programs. I don't know what's changed in taskPool.parallel, I will investigate later. Or you can investigate yourself if you want.
 BTW, I like the coding style being used in the rosetta examples 
 and TDPL much better than the library style.
I try to keep the D code on Rosettacode with a quite uniform style. It follows the dstyle, the main difference is the opening brace that's in Egyptian style, but such brace style is required only in Phobos, while the dstyle does not require the Phobos style for all D code, it's in "Additional Requirements for Phobos": http://dlang.org/dstyle.html Later, bearophile
Jun 22 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/22/2013 11:53 AM, Brian Rogoff wrote:

 The current D code for Dining philosophers does not compile with dmd
 v2.063.2, the error message being

 dining.d(34): Error: cannot uniquely infer foreach argument types
The code compiles under 32-bit (e.g. with the -m32 compiler switch) where size_t is an alias of uint.
       4    void eat(in uint i, in string name, Mutex[] forks) {
1) Replace that uint with size_t: void eat(in size_t i, in string name, Mutex[] forks) {
      34      foreach (uint i, philo; taskPool.parallel(philosophers)) {
2) Remove that uint: foreach (i, philo; taskPool.parallel(philosophers)) { Ali
Jun 22 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ali Çehreli:

 The code compiles under 32-bit (e.g. with the -m32 compiler 
 switch) where size_t is an alias of uint.
Oh, I see. I compile most of the code on a 32 bit system. I asked Walter to warn d programmers against such mistakes, and Walter closed it down. Someone else has opened the ER again... Bye, bearophile
Jun 22 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 I asked Walter to warn d programmers against such mistakes, and 
 Walter closed it down. Someone else has opened the ER again...
I meant this: http://d.puremagic.com/issues/show_bug.cgi?id=5063 In the meantime I have fixed the Rosettacode entry. Bye, bearophile
Jun 22 2013
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Saturday, 22 June 2013 at 21:27:01 UTC, bearophile wrote:
 Ali Çehreli:

 The code compiles under 32-bit (e.g. with the -m32 compiler 
 switch) where size_t is an alias of uint.
Thanks, Ali! I'm always compiling on 64 bit systems; I'll add the 32 bit switch to my diagnostic approach now.
 Oh, I see. I compile most of the code on a 32 bit system.

 I asked Walter to warn d programmers against such mistakes, and 
 Walter closed it down. Someone else has opened the ER again...
In general, I think implicit conversions of any kind are a misfeature, but better error messages would be enough for me here. At least in Scala, you need to bring the conversion into scope yourself, or have it accidentally imported... Thanks for your help. -- Brian
Jun 23 2013
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 22 Jun 2013 23:27:00 +0200
schrieb "bearophile" <bearophileHUGS lycos.com>:

 Ali =C3=87ehreli:
=20
 The code compiles under 32-bit (e.g. with the -m32 compiler=20
 switch) where size_t is an alias of uint.
=20 Oh, I see. I compile most of the code on a 32 bit system. =20 I asked Walter to warn d programmers against such mistakes, and=20 Walter closed it down. Someone else has opened the ER again...
That would be me. Let's see where it goes. =20
 Bye,
 bearophile
--=20 Marco
Jul 03 2013
prev sibling next sibling parent reply "ixid" <nuaccount gmail.com> writes:
On Monday, 4 February 2013 at 23:55:25 UTC, bearophile wrote:
 Is the Fwend user of Rosettacode (or some other interested 
 person) around here? I have written partial D implementations 
 for three tasks, maybe a little of coordination will speedup 
 the work:

 http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation
 http://rosettacode.org/wiki/Universal_Turing_machine
 http://rosettacode.org/wiki/RCRPG

 Bye,
 bearophile
If you're posting code on Rosetta code you are presenting that code as idiomatic. Doesn't that require some discussion of what is idiomatic D? You tend to use the superfluous parens which the properties discussion would suggest are becoming more idiomatic not to use. You also use 'in' a lot in function inputs while others have argued against it. This is not an attack on your code at all, but maybe there should be some discussion of and consensus on what is idiomatic.
Feb 12 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 If you're posting code on Rosetta code you are presenting that 
 code as idiomatic.
The D code on Rosettacode has some stylistic uniformity, and I think in most cases it follows the dstyle (http://dlang.org/dstyle.html ), but that code is not meant to be "production code" (lot of people in other languages don't add unittests, etc). So it is not idiomatic, and it's not meant to be. If you go on Rosettacode you can't expect to see code similar to Phobos code. There is also variability: some D entries of Rosettacode have unittests and are written in a readable style, other entries try to be short simple, and other entries are very strongly typed and longer, other entries look almost as C, and so on. This is done on purpose, to show various kinds of D coding. None of those ways is the only idiomatic one.
 You tend to use the superfluous parens which the properties 
 discussion would suggest are becoming more idiomatic not to use.
-property was supposed to become the standard semantics of the D language. So I have written code that way. Later things are changing. Now I am waiting to see what's coming out of the property discussion. If the final decision is that those parentheses aren't needed nor idiomatic, I/we will (slowly) remove the parentheses from the entries.
 You also use 'in' a lot in function inputs while others have 
 argued against it.
"in" is currently not good if you are writing a long term large library, or a larger program you want to use for lot of time, etc, because it assumes some type system semantics that is not yet implemented. But for the purposes of Rosettacode using "in" is good, because it's short, readable, and if/when scope will break some entries, I/we will fix them.
 This is not an attack on your code at all, but maybe there 
 should be some discussion of and consensus on what is idiomatic.
One problem of Rosettacode is that it's not so good to discuss. GitHub offers better means to discuss on the code. What other things do you want to discuss about? Bye, bearophile
Feb 12 2013
parent reply "ixid" <nuaccount gmail.com> writes:
 What other things do you want to discuss about?
I mean some level of D community discussion of the language as a whole as to what is an idiomatic style, perhaps after the current issues are settled, not anything specific about your code. There are areas like complex UFCS statements where it would help to have agreed, suggested ways of formatting.
Feb 12 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 I mean some level of D community discussion of the language as 
 a whole as to what is an idiomatic style, perhaps after the 
 current issues are settled, not anything specific about your 
 code.
Such discussion seems better in the main D newsgroup. But it also seems a good way to waste time with hundreds of posts that produce nothing of value :-)
 There are areas like complex UFCS statements where it would 
 help to have agreed, suggested ways of formatting.
I think this is currently a good way to format that kind of chains, this is inspired by similar F# formatting: auto r = fooSomething() .barSomething!pred1() .bazSomething() .spamSomething!fun2(); In some cases on Rosettacode I have followed that formatting pattern. Bye, bearophile
Feb 12 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
If some of you has a little of time to review code, I have 
converted the very fast C memory mapped version of "Ordered 
words" to D:

http://rosettacode.org/wiki/Ordered_words#Mmap

http://rosettacode.org/wiki/Ordered_words#Memory_Mapped_Version

The C version contains several pointers that get juggled around, 
even with a negative index:

if (s[0] < s[-1]) r = 0;

So the C entry is rather bug-prone (and it doesn't compile on GCC 
Windows). The D entry is portable, and uses mostly slices and 
(non-negative) array indexes.


The D findWord function is fiddly still:

const(char)[] findWord(const char[] s) pure nothrow  safe {
     size_t wordEnd = 0;
     while (wordEnd < s.length && s[wordEnd] != '\n'
            && s[wordEnd] != '\r')
         wordEnd++;
     return s[0 .. wordEnd];
}


I think a takeWhile (similar to a Python itertools function) is 
able to replace it:

return s.takeWhile!(c => !"\n\r".canFind(c));


Using the current Phobos (but a benchmark shows with DMD it's 
slower):

const(char)[] findWord(const char[] s) pure /*nothrow*/  safe {
     immutable wordEnd = s.countUntil!q{a == '\n' || a == '\r'}();
     return s[0 .. wordEnd >= 0 ? wordEnd : $];
}

Bye,
bearophile
Feb 13 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
You have recently added:

http://rosettacode.org/wiki/Parse_command-line_arguments#D
http://rosettacode.org/wiki/Old_Russian_measure_of_length#D
http://rosettacode.org/wiki/Truth_table#D

But maybe there is one more Task you have recently added that I 
have missed.

Bye,
bearophile
Feb 25 2013
next sibling parent Jos van Uden <usenet fwend.com> writes:
On 25-2-2013 22:54, bearophile wrote:
 You have recently added:

 http://rosettacode.org/wiki/Parse_command-line_arguments#D
 http://rosettacode.org/wiki/Old_Russian_measure_of_length#D
 http://rosettacode.org/wiki/Truth_table#D
Yes.
 But maybe there is one more Task you have recently added that I have missed.
You can always click on "contribs" to get a better overview.
Feb 25 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 http://rosettacode.org/wiki/Truth_table#D
Some changes: http://codepad.org/PEZWmrHG But it's not good enough yet :-) Maybe there are ways to produce a D version closed to the Go one. Bye, bearophile
Feb 25 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 26-2-2013 5:19, bearophile wrote:
 http://rosettacode.org/wiki/Truth_table#D
Some changes: http://codepad.org/PEZWmrHG But it's not good enough yet :-) Maybe there are ways to produce a D version closed to the Go one.
I would have prefered to write: bool xor(in bool A, in bool B) pure nothrow return A != B; } But I couldn't figure out how to expand the boolean array to an argument list. The Go example uses runtime reflection, I believe. Nice touch with the map, I still think in loops :)
Feb 25 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 But I couldn't figure out how to expand the boolean array to
 an argument list.
I wrote a version, it's more statically type safe, but the code is quite hairy, and the foreach(i) generates too many templates if the predicate has many bool arguments: http://codepad.org/9Ar1pmMc Are you able to improve it?
 The Go example uses runtime reflection, I believe.
I'd like a bit more reflection in D, to avoid a similar jungle of templates :-) I think Rosettacode is currently down. Bye, bearophile
Feb 26 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 But I couldn't figure out how to expand the boolean array to
 an argument list.
With functions like this my last version will become simpler, and it's equally statically type safe: bool xor(in bool[2] args) pure nothrow { return b[0] != b[1]; } Bye, bearophile
Feb 26 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 With functions like this my last version will become simpler, 
 and it's equally statically type safe:

 bool xor(in bool[2] args) pure nothrow {
     return b[0] != b[1];
 }
This third version is much simpler and it seems good enough for Rosettacode: http://codepad.org/YJjb1t91 Bye, bearophile
Feb 26 2013
next sibling parent "Jos van Uden" <usernet fwend.com> writes:
On Tuesday, 26 February 2013 at 14:10:04 UTC, bearophile wrote:
 With functions like this my last version will become simpler, 
 and it's equally statically type safe:

 bool xor(in bool[2] args) pure nothrow {
    return b[0] != b[1];
 }
This third version is much simpler and it seems good enough for Rosettacode: http://codepad.org/YJjb1t91
Yes, it's much nicer than the heavily templated one. We may be able to update it if/when std.reflection comes through. I'd prefer the more conventional notation (i & (1 << j)) != 0, rather than the double negative.
Feb 26 2013
prev sibling parent reply FG <home fgda.pl> writes:
On 2013-02-26 15:10, bearophile wrote:
 This third version is much simpler and it seems good enough for
 Rosettacode:

 http://codepad.org/YJjb1t91
Nice. Myself I'd add bits.reverse; after the N.iota.map..., because I'm more used to a truth table where the left-most operands iterate the slowest.
Feb 27 2013
parent reply FG <home fgda.pl> writes:
On 2013-02-27 12:47, FG wrote:
 On 2013-02-26 15:10, bearophile wrote:
 This third version is much simpler and it seems good enough for
 Rosettacode:

 http://codepad.org/YJjb1t91
Nice. Myself I'd add bits.reverse; after the N.iota.map..., because I'm more used to a truth table where the left-most operands iterate the slowest.
or, without reverse, but perhaps not very clear: N.iota.map!(j => !!(i & (1 << (N - j - 1)))).copy(bits[]);
Feb 27 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
FG:

 or, without reverse, but perhaps not very clear:
 N.iota.map!(j => !!(i & (1 << (N - j - 1)))).copy(bits[]);
OK, improved in Rosettacode. Bye, bearophile
Feb 27 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
A possible idea is to translate this last Python version to D:

http://rosettacode.org/wiki/Hamming_numbers#Cyclic_generator_method_.232.

- - - - - - - - - - - -

Another idea is to add a D version of Merge Sort that works with 
just a Input Range (like a single linked list, as a SList):
http://rosettacode.org/wiki/Merge_sort

Slicing the input range in two is probably possible. But what's 
the result of such function? Just an array created with an 
Appender? It can't be the same type of the input, because it is 
just a input range, so it doesn't need to have a put(). Maybe a 
given sink that is an output range? Or maybe a sink created 
inside given its type as template argument?

Bye,
bearophile
Feb 27 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Now and then this thread becomes very useful for some 
coordination and discussion.

Regarding this Task:
http://rosettacode.org/wiki/Take_notes_on_the_command_line#D

Fwend has recently modified it with this note:

the file only needs to be created before append; filename can be 
written as one word in English, no need for camel case)<
Sorry, I didn't know "filename" a single English word :-) http://dictionary.cambridge.org/dictionary/business-english/filename?q=filename Regarding the other problem, the last part of the Task says:
If NOTES.TXT doesn't already exist in the current directory then 
a new NOTES.TXT file should be created.<
If no text file exists in the directory and I run the current program with no arguments, it generates no file to me. So I think the current program is wrong. That's why I added a File(fileName, "w");. What do you think? Bye, bearophile
Mar 04 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 4-3-2013 23:04, bearophile wrote:
 Now and then this thread becomes very useful for some coordination and
discussion.

 Regarding this Task:
 http://rosettacode.org/wiki/Take_notes_on_the_command_line#D

 Fwend has recently modified it with this note:

 the file only needs to be created before append; filename can be written as
one word in English, no need for camel case)<
Sorry, I didn't know "filename" a single English word :-) http://dictionary.cambridge.org/dictionary/business-english/filename?q=filename Regarding the other problem, the last part of the Task says:
 If NOTES.TXT doesn't already exist in the current directory then a new
NOTES.TXT file should be created.<
If no text file exists in the directory and I run the current program with no arguments, it generates no file to me. So I think the current program is wrong. That's why I added a File(fileName, "w");. What do you think?
It depends on how you interpret it. The task describes two actions: display and append. The question is: does the last sentence refer to the append action or to both display and append. I choose to think it refers to the append action because that makes more sense. As for http://rosettacode.org/wiki/Simple_database You removed the struct that I used to encapsulate the functions. Aren't these functions now exposed to other modules? I wanted them to only be callable from main. The input validation relies on that. At first I had declared them all private, but then I thought it would be convenient to put a struct around them and declare it private. Maybe there's a better way.
Mar 04 2013
next sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 5-3-2013 0:57, Jos van Uden wrote:
 On 4-3-2013 23:04, bearophile wrote:
 Now and then this thread becomes very useful for some coordination and
discussion.

 Regarding this Task:
 http://rosettacode.org/wiki/Take_notes_on_the_command_line#D

 Fwend has recently modified it with this note:

 the file only needs to be created before append; filename can be written as
one word in English, no need for camel case)<
Sorry, I didn't know "filename" a single English word :-) http://dictionary.cambridge.org/dictionary/business-english/filename?q=filename Regarding the other problem, the last part of the Task says:
 If NOTES.TXT doesn't already exist in the current directory then a new
NOTES.TXT file should be created.<
If no text file exists in the directory and I run the current program with no arguments, it generates no file to me. So I think the current program is wrong. That's why I added a File(fileName, "w");. What do you think?
It depends on how you interpret it. The task describes two actions: display and append. The question is: does the last sentence refer to the append action or to both display and append. I choose to think it refers to the append action because that makes more sense. As for http://rosettacode.org/wiki/Simple_database You removed the struct that I used to encapsulate the functions. Aren't these functions now exposed to other modules? I wanted them to only be callable from main. The input validation relies on that. At first I had declared them all private, but then I thought it would be convenient to put a struct around them and declare it private. Maybe there's a better way.
Another consideration, I just remembered, was that it avoided creating global variables.
Mar 04 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 Another consideration, I just remembered, was that it avoided
 creating global variables.
Right, that's important, but every rule should be followed with a grain of salt. First of all in this program there are no global variables, just a global immutable, filename. Global immutables cause far less troubles than global variables. (In my opinion hard-coding the file name like that is not nice, but for this little program it's acceptable). And second, this is a very small program. What's bad in a 100_000 lines long program is sometimes acceptable in a 73 cloc lines long program... Bye, bearophile
Mar 04 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 It depends on how you interpret it. The task describes two 
 actions:
 display and append. The question is: does the last sentence 
 refer to
 the append action or to both display and append. I choose to 
 think it
 refers to the append action because that makes more sense.
OK. - - - - - - - - - - - -
 As for http://rosettacode.org/wiki/Simple_database

 You removed the struct that I used to encapsulate the functions.

 Aren't these functions now exposed to other modules? I wanted
 them to only be callable from main. The input validation relies
 on that.

 At first I had declared them all private, but then I thought it
 would be convenient to put a struct around them and declare it
 private. Maybe there's a better way.
D isn't a pure OOP language, it thankfully supports free functions. Generally structs and classes shouldn't be used if they are not useful (this is well known in the Python community). A struct with just static methods is essentially a namespace. In D modules are namespaces, so there is less need to wrap static functions in a struct. In this case of the Simple database Task I think this is not a module to be imported, because it has a main. It's a complete program (like other hundreds of D Tasks in Rosettacode) and it's not meant to be imported. So I think wrapping everything in a struct in this case is useless, it just increases the indenting. Do you agree? - - - - - - - - - - - - Extra note: in Rosettacode there are also few tasks meant as modules to be imported and used. They have the main wrapped like this: version (task_name_main) { void main() { } } Unfortunately in D there is no built-in way to make a module that has a main() when it's compiled as "main module" (or when it's compiled as stand alone) and masks its main() when it's imported by another module. This is done in Python with the "if __name__ == __main__:" idiom. Some people say that a similar idiom is ugly, but it's far better to have such not nice looking but standard idiom, than having nothing and using a nonstandard version() like that. Bye, bearophile
Mar 04 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 5-3-2013 1:20, bearophile wrote:
 Jos van Uden:

 It depends on how you interpret it. The task describes two actions:
 display and append. The question is: does the last sentence refer to
 the append action or to both display and append. I choose to think it
 refers to the append action because that makes more sense.
OK. - - - - - - - - - - - -
 As for http://rosettacode.org/wiki/Simple_database

 You removed the struct that I used to encapsulate the functions.

 Aren't these functions now exposed to other modules? I wanted
 them to only be callable from main. The input validation relies
 on that.

 At first I had declared them all private, but then I thought it
 would be convenient to put a struct around them and declare it
 private. Maybe there's a better way.
D isn't a pure OOP language, it thankfully supports free functions. Generally structs and classes shouldn't be used if they are not useful (this is well known in the Python community). A struct with just static methods is essentially a namespace. In D modules are namespaces, so there is less need to wrap static functions in a struct. In this case of the Simple database Task I think this is not a module to be imported, because it has a main. It's a complete program (like other hundreds of D Tasks in Rosettacode) and it's not meant to be imported. So I think wrapping everything in a struct in this case is useless, it just increases the indenting. Do you agree?
I'm not attached to the struct, but it doesn't feel right to have these functions publicly accessible. It's a matter of good coding practice. If I import a module these functions are exposed.
Mar 04 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 but it doesn't feel right to have these
 functions publicly accessible. It's a matter of good coding 
 practice.

 If I import a module these functions are exposed.
I think you can't import this module, because it has a main(). But if you fear that, then I've added "private" to all global identifiers: http://rosettacode.org/wiki/Simple_database#D Bye, bearophile
Mar 04 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 But if you fear that, then I've added "private" to all global 
 identifiers:
 http://rosettacode.org/wiki/Simple_database#D
I have removed "private" again, because it's bad to program compromises. This is a complete program, it's not a module, and it's not imported. No need for private things. Bye, bearophile
Mar 04 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 5-3-2013 2:05, bearophile wrote:
 But if you fear that, then I've added "private" to all global identifiers:
 http://rosettacode.org/wiki/Simple_database#D
I have removed "private" again, because it's bad to program compromises. This is a complete program, it's not a module, and it's not imported. No need for private things.
// this shouldn't happen test.d import simdb; void fun() { auto db = load(); // etc store(db); }
Mar 05 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 5-3-2013 11:45, Jos van Uden wrote:
 On 5-3-2013 2:05, bearophile wrote:
 But if you fear that, then I've added "private" to all global identifiers:
 http://rosettacode.org/wiki/Simple_database#D
I have removed "private" again, because it's bad to program compromises. This is a complete program, it's not a module, and it's not imported. No need for private things.
// this shouldn't happen test.d import simdb; void fun() { auto db = load(); // etc store(db); }
That can't happen. I really mean: test.d void fun() { auto db = load(); // etc store(db); } simdb.d import test; fun();
Mar 05 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 // this shouldn't happen

 test.d

 import simdb;
If I try to compile something like that my dmd gives me a duplicated main error, or something similar.
 I really mean:

 test.d
  void fun() {
      auto db = load();
      // etc
      store(db);
 }

 simdb.d

 import test;

 fun();
Do you mean that the load and store functions are "private" and should only be called by other functions in the module? (If this is true, then it's enough to mark as module-private those two functions). Bye, bearophile
Mar 05 2013
parent "Jos van Uden" <usenet fwend.com> writes:
On Tuesday, 5 March 2013 at 13:12:49 UTC, bearophile wrote:
 Jos van Uden:

 // this shouldn't happen

 test.d

 import simdb;
If I try to compile something like that my dmd gives me a duplicated main error, or something similar.
Sorry, that was a wrong example.
 I really mean:

 test.d
 void fun() {
     auto db = load();
     // etc
     store(db);
 }

 simdb.d

 import test;

 fun();
Do you mean that the load and store functions are "private" and should only be called by other functions in the module? (If this is true, then it's enough to mark as module-private those two functions).
Yes, but I think it would be best to put a private modifier around the entire code, except main. private { ... }
Mar 05 2013
prev sibling next sibling parent reply "ixid" <nuaccount gmail.com> writes:
I was just looking at the Rosetta code for prime decomposition 
and it seems bugged to me, wanted to make sure as you seem to be 
the one coordinating these things:

http://rosettacode.org/wiki/Prime_decomposition#D

This will potentially return a 1 in the list of primes which is a 
bug as 1 isn't prime.
Mar 19 2013
next sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Tuesday, 19 March 2013 at 15:55:19 UTC, ixid wrote:
 I was just looking at the Rosetta code for prime decomposition 
 and it seems bugged to me, wanted to make sure as you seem to 
 be the one coordinating these things:

 http://rosettacode.org/wiki/Prime_decomposition#D

 This will potentially return a 1 in the list of primes which is 
 a bug as 1 isn't prime.
You're right. I think the right code for decompose is this: T[] decompose(T)(T n) /*pure nothrow*/ { T[] res; for (T i = 2; n % i == 0;) { res ~= i; n /= i; } for (T i = 3; n != 1; i += 2) { // ----- Changed condition while (n % i == 0) { res ~= i; n /= i; } } // ----- Removed concat here return res; }
Mar 19 2013
parent "ixid" <nuaccount gmail.com> writes:
On Tuesday, 19 March 2013 at 16:47:43 UTC, Andrea Fontana wrote:
 On Tuesday, 19 March 2013 at 15:55:19 UTC, ixid wrote:
 I was just looking at the Rosetta code for prime decomposition 
 and it seems bugged to me, wanted to make sure as you seem to 
 be the one coordinating these things:

 http://rosettacode.org/wiki/Prime_decomposition#D

 This will potentially return a 1 in the list of primes which 
 is a bug as 1 isn't prime.
You're right. I think the right code for decompose is this: T[] decompose(T)(T n) /*pure nothrow*/ { T[] res; for (T i = 2; n % i == 0;) { res ~= i; n /= i; } for (T i = 3; n != 1; i += 2) { // ----- Changed condition while (n % i == 0) { res ~= i; n /= i; } } // ----- Removed concat here return res; }
T[] primeDecomposition2(T)(T n) /*pure nothrow*/ { T[] res; for (T i = 2; n % i == 0;) { res ~= i; n /= i; } for (T i = 3; n >= i * i; i += 2) { while (n % i == 0) { res ~= i; n /= i; } } if(n != 1) res ~= n; return res; } I think this is quite a lot faster, otherwise for numbers that are the products of a small and larger prime it will waste a lot of time reaching the larger prime's value.
Mar 19 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 http://rosettacode.org/wiki/Prime_decomposition#D

 This will potentially return a 1 in the list of primes which is 
 a bug as 1 isn't prime.
From Python code, hopefully more correct and much faster: http://codepad.org/N4A7kxE1 Bye, bearophile
Mar 19 2013
parent reply "ixid" <nuaccount gmail.com> writes:
On Tuesday, 19 March 2013 at 17:18:01 UTC, bearophile wrote:
 ixid:

 http://rosettacode.org/wiki/Prime_decomposition#D

 This will potentially return a 1 in the list of primes which 
 is a bug as 1 isn't prime.
From Python code, hopefully more correct and much faster: http://codepad.org/N4A7kxE1 Bye, bearophile
This method seems to be a lot slower than just adding an if statement while giving the same answers (after sorting). For me it took 1.5 seconds to decompose 2 to 100,000 compared to 150ms for the method I posted above. Can you find an error in my method or shall I post that? I'll add a cast(T) 1 to the if statement so it can deal with big ints too.
Mar 19 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 Can you find an error in my method or shall I post that?
Small changes on your version: http://codepad.org/E9KHKvAi
 I'll add a cast(T) 1 to the if statement so
 it can deal with big ints too.
There's no need for that. Bye, bearophile
Mar 19 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 Small changes on your version:
 http://codepad.org/E9KHKvAi
It's now on Rosettacode. I have added more changes to make it able to deal with immutable input. Bye, bearophile
Mar 19 2013
parent reply "ixid" <nuaccount gmail.com> writes:
On Tuesday, 19 March 2013 at 18:53:21 UTC, bearophile wrote:
 Small changes on your version:
 http://codepad.org/E9KHKvAi
It's now on Rosettacode. I have added more changes to make it able to deal with immutable input. Bye, bearophile
Another issue to consider as the question I was attempting ended up requiring this, I wasn't aware of it when I made the original post: The prime factorization of 1 is an empty set, so surely to be correct it should return [] when given 1 and not throw an exception. This also suggests a possible modification to [].reduce!"a * b" as mathematically the product of the empty set is defined as 1.
Mar 20 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 The prime factorization of 1 is an empty set, so surely to be 
 correct it should return [] when given 1 and not throw an 
 exception.
The Task says that the input can't be 1, so the input 1 needs to be a pre-condition violation:
Write a function which returns an array or collection which 
contains the prime decomposition of a given number, n, greater 
than 1<
 This also suggests a possible modification to [].reduce!"a * b" 
 as mathematically the product of the empty set is defined as 1.
reduce() is a general function, so it's not supposed to know that. Python reduce does the same:
 reduce(lambda a, b: a * b, [])
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: reduce() of empty sequence with no initial value If you want that, then you have to use: reduce!"a * b"(1, items) And some time from now: items.reduce!"a * b"(1) If we add a product() function to Phobos similar to sum() (http://d.puremagic.com/issues/show_bug.cgi?id=4725 ) then I agree that for empty ranges it will need to return the multiplicative identity element. Bye, bearophile
Mar 20 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Some comments about the recently created "Vampire number" task in 
Rosettacode:

The version I have modified:
http://rosettacode.org/mw/index.php?title=Vampire_number&diff=154069&oldid=154068


Fwend has reverted most of my changes:
http://rosettacode.org/wiki/Vampire_number#D

------------

The rationale for some of my changes:

- main at the bottom. Giving a predicable order to the parts of 
the program is good. This how all the other entries are made.
- Removal of "if (auto factors = ...)": coding standards suggest 
to avoid mixing conditional tests with actions. Keeping code more 
tidy is safer.
- Removal of complex for loops "for (long n, count; n < long.max 
&& count < 25; n++)": it's better to keep the loop semantics 
simpler. It's better for both the optimization and for the 
readability and keeping the code in time.
- Adding immutable/const to the foreach loop variable "foreach 
(n; [...])": D currently gives a warning if you try to mutate it. 
In future D will allow you to mutate it, but it's only a copy, as 
in Python. This is potentially confusion. Marking it as 
const/immutable should become a standard D coding convention to 
avoid troubles. It's not useless.
- "immutable q = k / i;" instead of "long q = k / i;" all 
variables in a D program that don't need to mutate should be 
annotated with const/immutable. This gives more optimization to 
the compiler, helps avoid bugs of unwanted mutation later, and 
makes code simpler to understand, because when you read code you 
are sure something is not changing. It's explained here, among 
other places: 
http://blog.knatten.org/2011/11/11/disempower-every-variable/
- "if (digits.length % 2)" instead of "if (digits.length & 1)": 
for the compiler they are exactly the same, because the value is 
unsigned. And using a modulus is more clear here. We are 
discussing about parity, not about bits.
- "immutable f1 = getDigits(pair[0]);" instead of "auto f1 = 
getDigits(pair[0]);": as before, f1 doesn't need to change, so it 
should be immutable (I have used const, but immutable is better, 
because getDigits is now pure).
- Annotations like "pairs ~= [i, q]; // Heap-allocated pair.": 
they are useful because that little 2 items array is allocated on 
the heap. It's good to remember us an important inefficiency in 
the code. If you use a 2-tuple such inefficiency vanishes. 
Someday hopefully this significant inefficiency of array literals 
will be removed, and the comment will be removed.
- "// Unnecessary cast. Array concat allocates a new array." + 
"if (!(cast(long[])(f1 ~ f2)).sort().equal(digits))" instead of " 
if(!equal(digits, (f1 ~ f2).sort()))": f1 and f2 are immutable, 
and currently if you concatenate them you get an immutable array, 
that you can't sort. I agree the cast is bad here, so I have to 
use dup instead. In future this problem will be hopefully 
removed, so the code will be fixed and the comment removed. 
RosettaCode is not just a show of D code, it's also a place to 
help us improve D language itself. So hundreds of D entries in 
Rosettacode have annotations like that, that help us remember 
limits or bugs or problems in the D language. I have removed tens 
of similar annotations when D bugs get fixed. They are useful for 
the development od D.


(Here I have listed only the things that I think should be 
reverted. There are other things in my version of the problem 
that are more like personal style preferences that I have not 
listed here, that are used in most or all the other D entries.)

Bye,
bearophile
Mar 24 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 - Removal of "if (auto factors = ...)": coding standards 
 suggest to avoid mixing conditional tests with actions. Keeping 
 code more tidy is safer.
Also in D testing array emptiness like that is generally dangerous. The idiomatic and correct way to do it in D is to use empty. Because in general arrays with zero length can be true: Another thing: the problem asks to return the results for 16758243290880, 24959017348650, 14593825548650, while your version of the program doesn't even show the last numbers. This is bad. The Python entry shows all three of them. Bye, bearophile
Mar 24 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
A new version of "Vampire number", do you like it?

http://codepad.org/DaVxWpoA

Bye,
bearophile
Mar 24 2013
prev sibling parent reply Jos van Uden <usenet fwend.com> writes:
On 24-3-2013 21:02, bearophile wrote:
 Some comments about the recently created "Vampire number" task in Rosettacode:

 The version I have modified:
 http://rosettacode.org/mw/index.php?title=Vampire_number&diff=154069&oldid=154068


 Fwend has reverted most of my changes:
 http://rosettacode.org/wiki/Vampire_number#D

 ------------

 The rationale for some of my changes:

 - main at the bottom. Giving a predicable order to the parts of the program is
good.
Either way is fine with me.
  This how all the other entries are made.
 - Removal of "if (auto factors = ...)": coding standards suggest to avoid
mixing conditional tests with actions. Keeping code more tidy is safer.
I think it's convenient, it checks for null or empty, I don't find it confusing at all.
 - Removal of complex for loops "for (long n, count; n < long.max && count <
25; n++)": it's better to keep the loop semantics simpler.
 It's better for both the optimization and for the readability and keeping the
code in time.
I agree that complex for loops should be avoided. I don't think this loop is complex though, it's very simple. (...) With regards to immutablity: I do find it useful, but it creates an anormous amount of code clutter. So I use it only where it's really important. For instance we have f1 and f2, they are declared const, and then only two lines later the constness has to be cast away again. I find that a bit over the top.
 - "if (digits.length % 2)" instead of "if (digits.length & 1)": for the
compiler they are exactly the same, because
  the value is unsigned. And using a modulus is more clear here. We are
discussing about parity, not about bits.
That is a matter of opinion. If I see "% 2", my first thought is: we're checking for even... then I realize the "== 0" is missing.
 - Annotations like "pairs ~= [i, q]; // Heap-allocated pair.":
The annotation got accidentally deleted, sorry.
 Another thing: the problem asks to return the results for 16758243290880,
24959017348650, 14593825548650,
while your version of the program doesn't even show the last numbers. This is
bad. The Python entry shows
all three of them.
Actually the task says: "Check if the following numbers are Vampire numbers and, if so, print them and their fangs". So you should only print it, if it is a Vampire number. I wrote the task myself, so I should know.
 A new version of "Vampire number", do you like it?
 http://codepad.org/DaVxWpoA
It's fine with me. I'm glad we got rid of the ugly cast.
Mar 24 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 I think it's convenient, it checks for null or empty, I don't 
 find it confusing at all.
I agree it's shorter and it looks handy. But one of its problems is that in D there are arrays with length zero that aren't null: import std.stdio; int[] foo() { auto a = [1]; return a[0..0]; } void main() { if (auto data = foo()) { writeln("here"); } } In the vampire code this doesn't happen because you return null (that is represented by two zero words), but in general unlike Python in D the safe and idiomatic way to test for array emptiness is to use std.array.empty. Otherwise you risk having problems.
 With regards to immutablity: I do find it useful, but it 
 creates an anormous amount of
 code clutter. So I use it only where it's really important. For 
 instance we have f1 and
 f2, they are declared const, and then only two lines later the 
 constness has to be cast
 away again. I find that a bit over the top.
f1 and f2 can be declared immutable, because they don't need to change. The later cast was a mistake of mine, I am sorry. In real-world D code in a situation like that I do as you have done, making f1 and f2 mutable. But on Rosettacode I think it's important to underline the current problems in the D language itself. In an hypothetical future version of D if you cancat two immutable arrays you should get something that is typed as immutable, but is implicitly castable to mutable :-) I will think a bit more about this. Maybe I will just make f1 and f2 mutable, it's the cleanest solution.
 - "if (digits.length % 2)" instead of "if (digits.length & 
 1)": for the compiler they are exactly the same, because
 the value is unsigned. And using a modulus is more clear here. 
 We are discussing about parity, not about bits.
That is a matter of opinion. If I see "% 2", my first thought is: we're checking for even... then I realize the "== 0" is missing.
I will add the == 0 too then.
 I wrote the task myself, so I should know.
Ah :-) I didn't know. OK. So it's the Python entry to be wrong and yours is correct.
 It's fine with me. I'm glad we got rid of the ugly cast.
I agree, that cast in D was a bug of mine. (I try to fix mistakes in your code, but once in a while my code introduces other bugs/problems. In such cases on GitHub you can annotate code, but on mediawiki you have to just "fix" the code. It wasn't designed for code.) Later I will change the code on Rosettacode. Bye, bearophile
Mar 24 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 In the vampire code this doesn't happen because you return null 
 (that is represented by two zero words), but in general unlike 
 Python in D the safe and idiomatic way to test for array 
 emptiness is to use std.array.empty. Otherwise you risk having 
 problems.
I have just opened a thread in the main D newsgroup about this: http://forum.dlang.org/thread/bwgnbflygowctlisistg forum.dlang.org Bye, bearophile
Mar 24 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
This task has just a Tango entry:
http://rosettacode.org/wiki/Concurrent_computing


So I am writing a Phobos version. This seems to work as requested:


import std.stdio, std.random, std.parallelism, core.thread, 
core.time;

void main() {
     foreach (m; ["Enjoy", "Rosetta", "Code"])
         task!((s) {
             Thread.sleep(uniform(0, 1000).dur!"msecs");
             s.writeln;
         })(m).executeInNewThread;
}



I have also tried with a parallel foreach, the syntax is cleaner, 
but to me it always print the strings in the given order (so it's 
not doing what the task requires), do you know why?


import std.stdio, std.random, std.parallelism, core.thread, 
core.time;

void main() {
     foreach (s; ["Enjoy", "Rosetta", "Code"].parallel(1)) {
         Thread.sleep(uniform(0, 1000).dur!"msecs"); // Can't use 
UFCS.
         s.writeln;
     }
}


Bye,
bearophile
Mar 26 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 27-3-2013 0:20, bearophile wrote:
 This task has just a Tango entry:
 http://rosettacode.org/wiki/Concurrent_computing


 So I am writing a Phobos version. This seems to work as requested:


 import std.stdio, std.random, std.parallelism, core.thread, core.time;

 void main() {
      foreach (m; ["Enjoy", "Rosetta", "Code"])
          task!((s) {
              Thread.sleep(uniform(0, 1000).dur!"msecs");
              s.writeln;
          })(m).executeInNewThread;
 }



 I have also tried with a parallel foreach, the syntax is cleaner, but to me it
always print the strings in the given order (so it's not doing what the task
requires), do you know why?


 import std.stdio, std.random, std.parallelism, core.thread, core.time;

 void main() {
      foreach (s; ["Enjoy", "Rosetta", "Code"].parallel(1)) {
          Thread.sleep(uniform(0, 1000).dur!"msecs"); // Can't use UFCS.
          s.writeln;
      }
 }
Output on my system: C:\test Rosetta Enjoy Code C:\test Code Enjoy Rosetta C:\test Enjoy Rosetta Code C:\test Enjoy Code Rosetta C:\test Code Enjoy Rosetta
Mar 27 2013
next sibling parent Jos van Uden <usenet fwend.com> writes:
On 27-3-2013 15:17, Jos van Uden wrote:
 On 27-3-2013 0:20, bearophile wrote:
 This task has just a Tango entry:
 http://rosettacode.org/wiki/Concurrent_computing


 So I am writing a Phobos version. This seems to work as requested:


 import std.stdio, std.random, std.parallelism, core.thread, core.time;

 void main() {
      foreach (m; ["Enjoy", "Rosetta", "Code"])
          task!((s) {
              Thread.sleep(uniform(0, 1000).dur!"msecs");
              s.writeln;
          })(m).executeInNewThread;
 }



 I have also tried with a parallel foreach, the syntax is cleaner, but to me it
always print the strings in the given order (so it's not doing what the task
requires), do you know why?


 import std.stdio, std.random, std.parallelism, core.thread, core.time;

 void main() {
      foreach (s; ["Enjoy", "Rosetta", "Code"].parallel(1)) {
          Thread.sleep(uniform(0, 1000).dur!"msecs"); // Can't use UFCS.
          s.writeln;
      }
 }
(...) my system:
DMD32 D Compiler v2.062 win7 64 bits, i7 2600
Mar 27 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 Output on my system:


 C:\test
 Rosetta
 Enjoy
 Code

 C:\test
 Code
 Enjoy
 Rosetta
Thank you for your test, I will replace the Rosettacode one with the nicer version. I don't know why the second doesn't work correctly on my system, while the first works. Bye, bearophile
Mar 27 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
I you want to take a look, I've seen that my translation of the 
Python entry was tagged as wrong:

http://rosettacode.org/wiki/Set_puzzle#Alternative_Version

Bye,
bearophile
Apr 05 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 5-4-2013 14:23, bearophile wrote:
 I you want to take a look, I've seen that my translation of the Python entry
was tagged as wrong:

 http://rosettacode.org/wiki/Set_puzzle#Alternative_Version
Ledrug tagged it. The output says: striped open open. That shouldn't happen.
Apr 05 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 That shouldn't happen.
Do you know why that shouldn't happen? :-) Bye, bearophile
Apr 05 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 http://rosettacode.org/wiki/Set_puzzle#Alternative_Version
Ledrug tagged it. The output says: striped open open. That shouldn't happen.
I don't know what's wrong, and why, so I've killed that alternative version... Bye, bearophile
Apr 06 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Maybe there is a way to translate this Haskell version to D with 
bigints:

http://rosettacode.org/wiki/Find_largest_left_truncatable_prime_in_a_given_base#Haskell

Unrelated: now I have a kind of efficient longest common 
subsequence algorithm with O(n) memory usage. Maybe there is some 
interest for it in Phobos.

Bye,
bearophile
Apr 18 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Some of the last ones that are undone still:

http://rosettacode.org/wiki/Birthday_problem
http://rosettacode.org/wiki/Suffix_tree
http://rosettacode.org/wiki/Deming%27s_Funnel

Bye,
bearophile
Jun 13 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
There is also one D entry in need to be fixed (with Phobos):

http://rosettacode.org/wiki/Distributed_programming#D

Bye,
bearophile
Jun 14 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 14 June 2013 at 22:17:16 UTC, bearophile wrote:
 http://rosettacode.org/wiki/Distributed_programming#D
It kinda sounds like the description calls for something like what web.d does: server: import arsd.web; class Foo : ApiProvider { export string hello(string name) { return "hello, " ~ name; } export int add(int a, int b) { return a + b; } } mixin FancyMain!Foo; client: import arsd.curl; import std.stdio; void main() { writeln(curl("http://example.com/server/hello?name=me")); } or javascript client: Foo.hello("me").get(alert); // will pop up "hello, me" or php client: $api = new Foo("http://example.com/server/"); echo $api->add(10, 20)->getSync(); // prints 30 (the code for this is generated automatically by web.d. I also wrote a bash [!] script to call arbitrary web.d functions remotely but have not actually done the same for D itself yet! The reason is for all my use cases, I can just call the D function without going through the http middle man because all the D is part of the same executable program. Interestingly, the D one would probably use a code generator like javascript rather than opDispatch like the bash and php examples do because the code generator could give more type safety.) This is a generic protocol, can handle many things at once, and uses pretty natural data structures. (The returned values can be almost anything, but the arguments must be all types that can be converted from strings or arrays of strings.) This actual example here uses several thousand lines of library code but if you think it would fit the description, I'm sure I can do a basic demo in far fewer lines using nothing but phobos.
Jun 14 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 This actual example here uses several thousand lines of library 
 code but if you think it would fit the description, I'm sure I 
 can do a basic demo in far fewer lines using nothing but phobos.
I think Rosettacode accepts code that uses libraries that are free. Take a look at the many Python entries for this task. So if you think this task can be implemented quickly using web.d, then use it :-) In some tasks I have appreciated solving the problems from the ground up, but in this task I think it's better to be lazy. Bye, bearophile
Jun 14 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 14 June 2013 at 22:44:40 UTC, bearophile wrote:
 So if you think this task can be implemented quickly using
 web.d, then use it :-)
I just think it is really cool that D can do that kind of thing, so a brief implementation might be good to show people how it is done. I'll see about slapping something together over the weekend and posting it here.
Jun 14 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 I'll see about slapping something together over the weekend and 
 posting it here.
If you use a library, please also give the link to the library, so I can create a nearly empty page on Rosettacode about it. It's kind of needed. Bye, bearophile
Jun 14 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I made a network server/client that needs no library except 
Phobos. Came in a little under 500 lines but is quite generic:

http://arsdnet.net/dcode/server.d

The top of the file shows the usage program, then comes the code 
that could go in a library.

Basically you define an interface with a bunch of functions. The 
server writes a class that implements that interface and then 
mixes in the helper code that does the network talking. The 
network protocol is very basic, it just serializes the arguments 
and return values with function and sequence numbers to know what 
to call. The serializer only handles basic types, arrays, and 
some structs, it isn't much code.

On the client side, that class is automatically generated. It 
doesn't completely implement the interface though, because the 
functions are all async callbacks instead of return values.

Run it without arguments to be the server. Any arguments will 
cause it to be a client and connect to local host to run the 
example.
Jun 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 I made a network server/client that needs no library except 
 Phobos. Came in a little under 500 lines but is quite generic:
Normal Rosettacode entries are under 40-100 lines. Many entries are about 10-20 lines long. There are are few entries (in C or Ada) that reach 500 lines, but I think they miss the point of Rosettacode, where code is meant to illustrate, it's not a place for heavy implementations. That's why I suggested to just call a library... What do you suggest to do? Bye, bearophile
Jun 16 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 16 June 2013 at 23:06:40 UTC, bearophile wrote:
 Normal Rosettacode entries are under 40-100 lines. Many entries 
 are about 10-20 lines long.
I think that biases it toward giant standard libraries. I've joked before that we could just say: import rosettacode; mixin Distributed!(); and win the code golf every time! :P But this asks for something pretty generic and the Go version for instance uses a rpc package that looks pretty similar to what I did here. The only reason their thing is short is because it is in the stdlib. (I betcha Go's stdlib implementation is longer than 500 lines too!)
 What do you suggest to do?
We could break the file into two parts, and link to one. Just as I feared though, the structs don't work because mixing in their name doesn't get the right import either. This is one disappointing limitation of string mixins that I've hit before too, when doing default arguments in web.d. It works for basic types but not for enums because while I can get the string representation, I can't get the actual type anymore. It would be great if we could describe a very specific type in a string mixin that the compiler knows, even if the imports aren't necessarily there. If I remove the struct example, it works with separate modules, so let's try that for now until I can think of a solution to the general problem here. code: http://arsdnet.net/dcode/rpc-example.d library: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/rpc.d
Jun 16 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 and win the code golf every time! :P
Some Rosettacode D entries are a bit compressed, but that site is not for code golfing. It's just preferred to not write long programs, for several reasonable reasons.
 code:
 http://arsdnet.net/dcode/rpc-example.d

 library:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/rpc.d
I have reformatted your code a little for the D standard of Rosettacode (72 columns max, etc): http://codepad.org/lAxAJwoG With your code I have found a dmd compiler bug, are you able and willing to further reduce this? import std.conv: to; import std.traits: ParameterTypeTuple; mixin template NetworkServer(Interface) { void callByNumber(int functionNumber, int sequenceNumber, const(ubyte)[] buffer) { string callCode() { string code; foreach(memIdx, member; __traits(allMembers, Interface)) { code ~= "\t\tcase " ~ to!string(memIdx + 1) ~ ":\n"; alias mem = PassThrough!(__traits(getMember, Interface, member)); foreach(i, arg; ParameterTypeTuple!mem) { auto istr = to!string(i); code ~= "\t\t\t" ~ arg.stringof ~ " arg" ~ istr ~ ";\n"; code ~= "\t\t\tbuffer = deserializeInto(buffer, arg" ~ istr ~ ");\n"; } code ~= "\t\tbreak;\n"; } return code; } switch(functionNumber) { mixin(callCode()); } } } template PassThrough(alias a) { alias PassThrough = a; } void deserializeInto(T)(inout(ubyte)[] buffer, ref T s) { s.length = 1; } mixin template NetworkClient(Interface) { private static void createClass() {} mixin(createClass()); } interface ExampleNetworkFunctions { void sayHello(in string); } class ExampleServer : ExampleNetworkFunctions { override void sayHello(in string) {} mixin NetworkServer!ExampleNetworkFunctions; } void main() {} Bye, bearophile
Jun 17 2013
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-06-18, 05:00, bearophile wrote:

 With your code I have found a dmd compiler bug, are you able and willing  
 to further reduce this?
Tried this with 2.063.2, and there are three errors in the code - deserializeInto should return its buffer, the switch on line 19 needs a default: case, and deserializeInto tries to modify its non-buffer argument (which in this case is a const string. None of these seem to be a compiler bug. -- Simen
Jun 18 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Simen Kjaeraas:

 Tried this with 2.063.2, and there are three errors in the code 
 - deserializeInto
 should return its buffer, the switch on line 19 needs a 
 default: case, and
 deserializeInto tries to modify its non-buffer argument (which 
 in this case is a
 const string. None of these seem to be a compiler bug.
I have introduced the first two errors in the reduction process. The third is the one that triggers a crash of my DMD version. I am keeping my compiler updated, I have compiled it yesterday, and it crashes after giving the error: test.d(28): Error: cannot modify const expression s Now I don't know if it's a problem of just my compiler, or if it's a normal compiler bug. Bye, bearophile
Jun 18 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 18 June 2013 at 09:22:05 UTC, bearophile wrote:
 third is the one that triggers a crash of my DMD version. I am 
 keeping my compiler updated, I have compiled it yesterday, and 
 it crashes after giving the error:

 test.d(28): Error: cannot modify const expression s

 Now I don't know if it's a problem of just my compiler, or if 
 it's a normal compiler bug.
Hmm, on my compiler it just fails to compile test11.d(32): Error: cannot modify const expression s test11.d(26): Error: template instance test11.deserializeInto!(const(immutable(char)[])) error instantiating which is actually expected because it is referring to this function: override void sayHello(in string) {} and the ParameterTypeTuple there will return a fully const type because of the "in", so assigning to it won't work without a cast. I can't reproduce the compiler crash you saw though.
Jun 18 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 I can't reproduce the compiler crash you saw though.
Thank you. Then it's somehow just my compiler... Bye, bearophile
Jun 18 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 code:
 http://arsdnet.net/dcode/rpc-example.d

 library:
 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/rpc.d
It's online: http://rosettacode.org/wiki/Distributed_programming#D Bye, bearophile
Jun 23 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
This entry has stopped working since lot of time:
http://rosettacode.org/wiki/MD5/Implementation#D

This is an improved version, but help is welcome:
http://codepad.org/g4RBio8E

Bye,
bearophile
Jul 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 http://codepad.org/g4RBio8E
this line: .replace("TT", "0x" ~ text(T(n), 16)); Needs to be: .replace("TT", "0x" ~ to!string(T(n), 16)); But the code in that link is all wrong because it needs all the code from std.md5 to work. And even then I don't know where Decode() is. Bye, bearophile
Jul 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 But the code in that link is all wrong because it needs all the 
 code from std.md5 to work.
 And even then I don't know where Decode() is.
OK, the code now works :-) Bye, bearophile
Jul 16 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 OK, the code now works :-)
And the results are a bit hilarious: ...>md5_implementation5_dmd md5 digest("") = D41D8CD98F00B204E9800998ECF8427E zmd5 digest("") = D41D8CD98F00B204E9800998ECF8427E Test performance / message size 200MBytes digest(data) = F083432AB71F6177A8EC2CA5157F7B83 std.md5: 16.59 M/sec ( 12.05 secs) digest(data) = F083432AB71F6177A8EC2CA5157F7B83 zmd5 : 81.90 M/sec ( 2.44 secs) ...>md5_implementation5_ldc md5 digest("") = D41D8CD98F00B204E9800998ECF8427E zmd5 digest("") = D41D8CD98F00B204E9800998ECF8427E Test performance / message size 200MBytes digest(data) = F083432AB71F6177A8EC2CA5157F7B83 std.md5: 112.36 M/sec ( 1.78 secs) digest(data) = F083432AB71F6177A8EC2CA5157F7B83 zmd5 : 98.18 M/sec ( 2.04 secs) The zmd5 version is generated asm with a small part in D. LDC2 compiles the standard D version even better... :-) Bye, bearophile
Jul 16 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Now this D entry works again:
http://rosettacode.org/wiki/S-Expressions#D

Probably it can be written without explicit indexes, only using 
txt.front, txt.popFrontN, txt.find, etc. Do you want to produce 
such modified version?


This simple task shows well why a parser combinators like Parsec 
is better:
http://rosettacode.org/wiki/S-Expressions#Haskell

Bye,
bearophile
Jul 21 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
This D entry uses Tango, but it should also show a version for 
Phobos:

http://rosettacode.org/wiki/Rosetta_Code/Count_examples#D

Bye,
bearophile
Jul 25 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 This D entry uses Tango, but it should also show a version for 
 Phobos:

 http://rosettacode.org/wiki/Rosetta_Code/Count_examples#D
Two versions The Mathematica solution is short: TaskList = Flatten[ Import["http://rosettacode.org/wiki/Category:Programming_Tasks", "Data"][[1, 1]]]; Print["Task \"", StringReplace[#, "_" -> " "], "\" has ", Length Select[Import["http://rosettacode.org/wiki/" <> #, "Data"][[1,2]], StringFreeQ[#, __ ~~ "Programming Task" | __ ~~ "Omit"]& ], " example(s)"]& ~Map~ StringReplace[TaskList, " " -> "_"] This Perl solution is compact: use v5.10; use Mojo::UserAgent; my $site = "http://rosettacode.org"; my $list_url = "/mw/api.php?action=query&list=categorymembers&cmtitle=Category:Programming_Tasks&cmlimit=500&format=xml"; my $ua = Mojo::UserAgent->new; $ua->get("$site$list_url")->res->dom->find('cm')->each(sub { (my $slug = $_->{title}) =~ tr/ /_/; my $count = $ua->get("$site/wiki/$slug")->res->dom->find("#toc .toclevel-1")->size; say "$_->{title}: $count examples"; }); The F# solution performs downloads concurrently and it's said to be fast: #r "System.Xml.Linq.dll" let uri1 = "http://www.rosettacode.org/w/api.php?action=query&list=categorymembers&cmtitle=Category:Programming_Tasks&cmlimit=500&format=xml" let uri2 task = sprintf "http://www.rosettacode.org/w/index.php?title=%s&action=raw" task [|for xml in (System.Xml.Linq.XDocument.Load uri1).Root.Descendants() do for attrib in xml.Attributes() do if attrib.Name.LocalName = "title" then yield async { let uri = uri2 (attrib.Value.Replace(" ", "_") |> System.Web.HttpUtility.UrlEncode) use client = new System.Net.WebClient() let! html = client.AsyncDownloadString(System.Uri uri) let sols' = html.Split([|"{{header|"|], System.StringSplitOptions.None).Length - 1 lock stdout (fun () -> printfn "%s: %d examples" attrib.Value sols') return sols' }|] |> Async.Parallel |> Async.RunSynchronously |> fun xs -> printfn "Total: %d examples" (Seq.sum xs) Bye, bearophile
Jul 25 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
I have added a D entry for the "Go Fish" game:

http://rosettacode.org/wiki/Go_Fish#D

I don't know the Go Fish game, so I am not sure this code is 
correct. Is some of you able and willing to test its play a bit?

(This D entry is very Python-style because it's a translation of 
the Python entry, so it's not very strongly typed. Generally in D 
I prefer stronger typing, but in this case I think it's 
acceptable).

Bye,
bearophile
Aug 30 2013
next sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
the entry :
http://rosettacode.org/wiki/File_IO
is wrong because as stated by the asignment : "In this task, the job is to
create a file called "output.txt", and place in it the contents of the file
"input.txt", *via an intermediate variable.**"*
*
*
there is no intermediate variable; I don't know if this is the right place
to post but you seem to do a lot of work for rosetta...


2013/8/31 bearophile <bearophileHUGS lycos.com>

 I have added a D entry for the "Go Fish" game:

 http://rosettacode.org/wiki/**Go_Fish#D<http://rosettacode.org/wiki/Go_Fish#D>

 I don't know the Go Fish game, so I am not sure this code is correct. Is
 some of you able and willing to test its play a bit?

 (This D entry is very Python-style because it's a translation of the
 Python entry, so it's not very strongly typed. Generally in D I prefer
 stronger typing, but in this case I think it's acceptable).

 Bye,
 bearophile
Aug 30 2013
parent reply Jos van Uden <usenet fwend.com> writes:
On 31-8-2013 4:08, maarten van damme wrote:
 the entry :
 http://rosettacode.org/wiki/File_IO
 is wrong because as stated by the asignment : "In this task, the job is to
create a file called "output.txt", and place in it the contents of the file
"input.txt", /via an intermediate variable.//"/
 /
 /
 there is no intermediate variable; I don't know if this is the right place to
post but you seem to do a lot of work for rosetta...
It's an old task (from 2007). The task description was changed after the D entries were made. http://rosettacode.org/mw/index.php?title=File_IO&diff=25166&oldid=21823 So it needs to be updated. Perhaps you will do the honors? :)
Aug 30 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Jos van Uden:

 It's an old task (from 2007). The task description was changed 
 after the D entries were made.
Yes, there are about 63 Rosettacode tasks that I have not yet updated: accumulator_factory.d address_of_a_variable.d animation.d boolean_values.d call_a_function_in_a_shared_library.d collections.d concurrent_computing.d create_an_object_at_a_given_address.d create_a_file.d date_format.d delete_a_file.d distributed_programming.d echo_server.d environment_variables.d execute_a_system_command.d execute_snusp.d file_io.d first_class_functions_use_numbers_analogously.d flow_control_structures.d formal_power_series.d fractal_tree2.d globally_replace_text_in_several_files.d hello_world_graphical.d http.d image_noise.d include_a_file.d input_loop.d json.d literals_floating_point.d literals_string.d memory_layout_of_a_data_structure.d metered_concurrency.d multiple_distinct_objects.d mutex.d object_serialization.d opengl.d parallel_calculations1.d pointers_and_references.d pragmatic_directives.d quine.d rc_24_game.d rename_a_file.d rosetta_code_count_examples.d scripted_main.d secure_temporary_file.d shell_one_liner.d simple_windowed_application.d singleton.d sockets.d synchronous_concurrency.d system_time.d test_a_function.d user_input_text.d variables.d variable_size_get.d variable_size_set.d walk_a_directory_non_recursively.d walk_a_directory_recursively.d window_creation.d xml_dom_serialization.d xml_input.d xml_output.d xml_xpath.d Bye, bearophile
Aug 31 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 31 August 2013 at 01:42:43 UTC, bearophile wrote:
 I have added a D entry for the "Go Fish" game:
hmm there's too much text output, it makes following the game hard, and seeing what the computer drew means you can cheat! But I think it plays correctly, I was able to finish a game. -- Speaking of card games, did you know Windows comes with a cards.dll that can draw a set of playing cards? It is used for built in games like Solitare. And you can use it too! Here's an example of how: http://arsdnet.net/dcode/wincards.d See the main function at the bottom of the file. The main() depends on (the newer version of) my simpledisplay.d and color.d (also shows how to use some of the input event improvements I've made over the last couple weeks!) https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff The sample program puts two cards on the screen and lets you drag them around with the mouse. Only works on MS Windows.
Aug 30 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
This D1 entry needs an update:
http://rosettacode.org/wiki/Metered_concurrency#D

Is someone willing to update it?


import std.stdio, core.thread, std.c.time;

class Semaphore {
     private int lockCnt, maxCnt;

     this(in int count) {
         maxCnt = lockCnt = count;
     }

     void acquire() {
         if (lockCnt < 0 || maxCnt <= 0)
             throw new Exception("Negative Lock or Zero init. 
Lock");
         while(lockCnt == 0)
             Thread.getThis.yield; // Let other threads release 
lock.
         synchronized lockCnt--;
     }

     void release() {
         synchronized
             if (lockCnt < maxCnt)
                 lockCnt++;
             else
                 throw new Exception("Release lock before 
acquire");
     }

     int getCnt() {
         synchronized return lockCnt;
     }
}

class Worker : Thread {
     private static int id = 0;
     private Semaphore lock;
     private int myId;

     this (Semaphore l) {
         super();
         lock = l;
         myId = id++;
     }

     int run() {
         lock.acquire;
         writefln("Worker %d got a lock(%d left).", myId, 
lock.getCnt);
         msleep(2_000); // Wait 2.0 seconds.
         lock.release;
         writefln("Worker %d released a lock(%d left).",
                  myId, lock.getCnt);
         return 0;
     }
}

void main() {
     Worker[10] crew;
     Semaphore lock = new Semaphore(4);

     foreach (ref c; crew)
         (c = new Worker(lock)).start;
     foreach (ref c; crew)
         c.wait;
}


Bye,
bearophile
Nov 25 2013
prev sibling next sibling parent reply "qznc" <qznc web.de> writes:
I just made some scripts [0] to download and compile all D 
examples from Rosettacode. From 186 of 716 examples fail to 
compile [1]. Some for trivial reasons like not wrapped into a 
main function or a missing import. Some require SDL or Tango or 
other third-party libraries.

My ultimate goal was to use this for regression testing dmd. 
Anyways if people try code examples they should compile out of 
the box for good PR.

If you are looking for a low-barrier way to support D a little, 
feel free to check out the fail list [1] and fix some. :)

[0] 
https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
[1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694
Jan 15 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
qznc:

 I just made some scripts [0] to download and compile all D 
 examples from Rosettacode. From 186 of 716 examples fail to 
 compile [1]. Some for trivial reasons like not wrapped into a 
 main function or a missing import. Some require SDL or Tango or 
 other third-party libraries.

 My ultimate goal was to use this for regression testing dmd. 
 Anyways if people try code examples they should compile out of 
 the box for good PR.

 If you are looking for a low-barrier way to support D a little, 
 feel free to check out the fail list [1] and fix some. :)

 [0] 
 https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
 [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694
I am using similar scripts written in Python since years. Currently there are around 760-770 D programs in Rosettacode. What version of the D compiler are you using? I am assuming Rosettacode to be compilable with the latest "bleeding edge" compiler. So if you use the latest released compiler some of the entries will not compile. Such entries should not be "fixed" at all. Your list of failing to compile just say "fail", but there are several reasons for a program to fail. Some programs need a "modulename_main" version to be compiled, because D lacks a built-in way to tell apart the main module of a program from the other modules. (In Python you use the "if __name__ == '__main__':" for this purpose). Some programs don't compile because require Tango. I have not removed them all because some Tango programmer has written them and I guess such person doesn't like to see their work removed from the pages. Some entries don't compile because they are not yet updated, or dmd has had some regressions. Thankfully Kenji usually fixes such regressions in just few days when I find them. Bye, bearophile
Jan 15 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
 [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694
Regarding Task names that start with a number, like rosettacode_24_game_solve_00.d, I usually prefix them with "rc_". Bye, bearophile
Jan 15 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 [0] 
 https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
 [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694
Another reason for some of your entries to not compile seems to be that you have missed that some entries need other entries to compile, so "rc_24_game_solve.d" needs "permutations2.d" and "arithmetic_rational.d", and then compiles and runs fine. (I number 1 2 3 ... the tasks that have more than one D solution). Bye, bearophile
Jan 15 2014
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/15/14 4:18 PM, bearophile wrote:

 What version of the D compiler are you using? I am assuming Rosettacode to be
compilable with the
 latest "bleeding edge" compiler. So if you use the latest released compiler
some of the entries will
 not compile. Such entries should not be "fixed" at all.
I think this is a mistake. They should compile with a released compiler. They also likely form a potentially interesting set of regression tests that someone ought to volunteer to test beta's against.
Jan 15 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Brad Roberts:

 I think this is a mistake.  They should compile with a released 
 compiler.
Why? And why do you think that outweighs the several advantages of having entries compilable only with the latest beta compiler? (Currently there are 40-50 entries that don't compile with the released dmd 2.064.)
 They also likely form a potentially interesting set of 
 regression tests that someone ought to volunteer to test beta's 
 against.
Rosettacode site has many different purposes; I also use those programs to test the dmd compiler for regressions. But to do this effectively you have to use the latest compiler changes. Also, how can you update manually on the site tens of entries all at once when a new compiler comes out? Bye, bearophile
Jan 15 2014
parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/15/14 4:42 PM, bearophile wrote:
 Brad Roberts:

 I think this is a mistake.  They should compile with a released compiler.
Why? And why do you think that outweighs the several advantages of having entries compilable only with the latest beta compiler? (Currently there are 40-50 entries that don't compile with the released dmd 2.064.)
Requiring that users of the code in resottacode be using bleeding edge, unreleased, compilers is a disservice to those users. Typical users will not and should not need to use anything other than a released compiler.
 They also likely form a potentially interesting set of regression tests that
someone ought to
 volunteer to test beta's against.
Rosettacode site has many different purposes; I also use those programs to test the dmd compiler for regressions. But to do this effectively you have to use the latest compiler changes. Also, how can you update manually on the site tens of entries all at once when a new compiler comes out?
The point is you shouldn't have to, unless the code is taking advantage of broken behavior. Any changes that 'have' to be made due to a compiler release need to be carefully examined as probable regressions in the compiler.
Jan 15 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Brad Roberts:

 Requiring that users of the code in resottacode be using 
 bleeding edge, unreleased, compilers is a disservice to those 
 users.  Typical users will not and should not need to use 
 anything other than a released compiler.
Some of the rosettacode usages/purposes are: - Trying new compiler features to see if they work correctly; - Try the new compiler features to learn to use them effectively; - To test the compiler betas to see if they have "regressions" if you try to use the new features. - To show "good" (== short, fast, elegant, clean) D code, thanks to some nicer recently introduced compiler improvements; So do you want to throw away those purposes? Also keep in mind that if you throw away those purposes, I will lose some of my desire to work on Rosettacode, so you will have a less good and less updated rosettacode site. And I have found probably more than 300 dmd bugs/regressions thanks to those beta-related purposes. If you throw away those purposes you will lose a significant amount of my future bug reports. Are those prices low enough for you?
 The point is you shouldn't have to, unless the code is taking 
 advantage of broken behavior.  Any changes that 'have' to be 
 made due to a compiler release need to be carefully examined as 
 probable regressions in the compiler.
One of the points of improving a compiler is offering new features that are advantageous to use. If you don't want to use them it often means they are a failure. In many other cases the dmd compiler rejects older code that was wrong, because it becomes more tight. Rosettacode tasks are usually short. If you don't try new compiler features in such little programs that have no production-level significance, then you will never try them in production code, and you will probably use just C-like code. Being a little compiler-bold in those tasks is acceptable. Bye, bearophile
Jan 15 2014
parent reply "qznc" <qznc web.de> writes:
On Thursday, 16 January 2014 at 01:11:23 UTC, bearophile wrote:
 - To test the compiler betas to see if they have "regressions" 
 if you try to use the new features.
This sounds somewhat paradox to me. How can a new feature have a regression? A "regression" means it has worked before, but new feature did not exist before. Maybe the question is about "before"? In my understanding "before" is "latest release", whereas "current" is "beta release" or "git HEAD". Do you mean "before" as something like "commit deadbeef~4" whereas "current" is "commit deadbeef"? I see nothing wrong with using code from Rosettacode to try out new features. It is weird though, if people want to test an example, you have to tell them to compile dmd from git. In practice the difference between the uses is not that important I think, because the sheer number of code snippets and release frequency means that most examples can be compiled with the latest release no matter what bearophile does. ;) Btw are your scripts public, bearophile?
Jan 15 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
qznc:

 This sounds somewhat paradox to me. How can a new feature have 
 a regression? A "regression" means it has worked before, but 
 new feature did not exist before.
"Regressions" on older betas; or to see if using the new features breaks other apparently unrelated parts of old code.
 In practice the difference between the uses is not that 
 important I think, because the sheer number of code snippets 
 and release frequency means that most examples can be compiled 
 with the latest release no matter what bearophile does. ;)
Right. The percentage of future compilable entries is small, usually much less than 5%. And this was even more true in past, when the frequency of D releases was higher.
 Btw are your scripts public, bearophile?
They are the common kind of little scripts that you prefer to rewrite on your own. Bye, bearophile
Jan 16 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
qznc:

 [0] 
 https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
 [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694
Few of the tasks of your list were never updated to D2/Phobos, and they should be updated. Among the ones that are updated, I have found five that don't compile on dmd 2.065 because of compiler changes and one (I think already reported) regression in std.array.array: arithmetic_evaluation.d balanced_ternary.d combinations_with_repetitions1.d k_means_plus_plus_clustering.d names_to_numbers.d or number_names.d I will try to fix them (and probably I will leave the one with a regression untouched). Bye, bearophile
Jan 15 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
 arithmetic_evaluation.d
 balanced_ternary.d
 combinations_with_repetitions1.d
 k_means_plus_plus_clustering.d
 names_to_numbers.d or number_names.d
I have "fixed" them. This is the problem in array, already in Bugzilla, I think it's a kind of regression: import std.array: array; immutable foo = [""].array; void main() {} The problem with inout in balanced_ternary.d was caused by inout semantics that keeps subtly changing every month. I don't know the causes of such micro-regressions. Bye, bearophile
Jan 15 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Is someone willing to write a D entry for this?

http://rosettacode.org/wiki/Rendezvous

Bye,
bearophile
Feb 25 2014
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 02/25/2014 03:48 PM, bearophile wrote:
 Is someone willing to write a D entry for this?

 http://rosettacode.org/wiki/Rendezvous

 Bye,
 bearophile
I think the following satisfies the requirements. Improve at will! :p import std.stdio; import std.exception; import std.array; import std.concurrency; import std.datetime; import core.thread; class OutOfInk : Exception { this() { super("Out of ink."); } } struct Printer { string id; size_t ink; void print(string line) { enforce(ink != 0, new OutOfInk); writefln("%s: %s", id, line); --ink; } } struct PrinterRendezvous { Printer[] printers; void print(string[] lines) shared { Exception savedException; while (true) { if (lines.empty) { break; } if (printers.empty) { // No more printers to try assert(savedException !is null); throw savedException; } try { synchronized { (cast(Printer)printers.front).print(lines.front); } lines.popFront(); // Increase the chance of interleaved output Thread.sleep(10.msecs); } catch (OutOfInk exc) { savedException = exc; synchronized { // Switch to the next printer printers = printers[1..$]; } } } } } void humptyDumptyTask(ref shared(PrinterRendezvous) rendezvous) { auto humptyDumpty = [ "Humpty Dumpty sat on a wall.", "Humpty Dumpty had a great fall.", "All the king's horses and all the king's men,", "Couldn't put Humpty together again.", ]; rendezvous.print(humptyDumpty); } void motherGooseTask(ref shared(PrinterRendezvous) rendezvous) { auto motherGoose = [ "Old Mother Goose,", "When she wanted to wander,", "Would ride through the air,", "On a very fine gander.", "Jack's mother came in,", "And caught the goose soon,", "And mounting its back,", "Flew up to the moon.", ]; rendezvous.print(motherGoose); } void main() { auto rendezvous = shared(PrinterRendezvous)([ Printer("main", 5), Printer("reserve", 5) ]); spawn(&humptyDumptyTask, rendezvous); spawn(&motherGooseTask, rendezvous); } Sample output: main: Humpty Dumpty sat on a wall. main: Old Mother Goose, main: Humpty Dumpty had a great fall. main: When she wanted to wander, main: All the king's horses and all the king's men, reserve: Would ride through the air, reserve: Couldn't put Humpty together again. reserve: On a very fine gander. reserve: Jack's mother came in, reserve: And caught the goose soon, deneme.OutOfInk deneme.d([...]): Out of ink. Ali
Feb 25 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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();
     void print(string line)
     {
         enforce(ink != 0, new OutOfInk);
         writefln("%s: %s", id, line);
         --ink;
     }
 }

 struct PrinterRendezvous
 ...
             try {
                 synchronized {
                     
 (cast(Printer)printers.front).print(lines.front);
                 }
It it a good idea to define Printer.print like this to remove that cast? void print(string line) shared Bye, bearophile
Feb 26 2014
next sibling parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Wednesday, 26 February 2014 at 11:24:58 UTC, bearophile wrote:
 Ali Çehreli:
                synchronized {
                    // Switch to the next printer
                    printers = printers[1..$];
                }
This doesn't work: printers.popFront();
Yes, because typeof(printers) == shared. I'm wondering why front() works.
            try {
                synchronized {
                    
 (cast(Printer)printers.front).print(lines.front);
                }
It it a good idea to define Printer.print like this to remove that cast? void print(string line) shared
No it is not, because the implementation of print() would be invalid then: void print(string line) shared { enforce(ink != 0, new OutOfInk); // ink != 0 is not valid code writefln("%s: %s", id, line); --ink; // --ink is not valid code } By declaring the method "shared" you promise that any acess to shared data in this method is safe. Using naked operators on shared scalar variables will eventually be disallowed, you'll have to explicitly use atomic operations. You'd also have to synchronize access to id member, because it is public. Although "immutable" means "implicitly shared", id being public means that potentionally one thread could be performing assigment to it while another one reads from it. Slices are two machine words, so atomicity of reads/writes is not implicitly guaranteed. The cast in this case is safe and better approach because all access to "printers" is synchronized. If/when https://d.puremagic.com/issues/show_bug.cgi?id=12133 and the corresponding pull is accepted, the cast could be replaced with printers.assumeLocal.front.print(lines.front); which states the intent even more clearly, IMO.
Feb 26 2014
parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
I forgot to note that both synchronized {} blocks should also be 
synchronizing on the same mutex. Right now it's two different 
critical sections, so a race is still possible, i.e. while one 
thread is printing the other may be removing the first printer. 
Run the code several times and you'll no doubt stumble upon it.

The mutex could be emulated with a shared bool and 
std.atomic.cas(). That would get rid of synchronized{} blocks and 
would potentionally be faster.
Feb 26 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Stanislav Blinov:

 You'd also have to synchronize access to id member,
 I forgot to note that both synchronized {} blocks should also 
 be synchronizing on the same mutex.
 The mutex could be emulated with a shared bool and 
 std.atomic.cas(). That would get rid of synchronized{} blocks 
 and would potentionally be faster.
This is the current D entry: http://rosettacode.org/wiki/Rendezvous#D If you have bug fixes, or improvements, it's better to do them right there. Of if you don't want to register on that site, you can put the modified version in dpaste, and I'll upload it on Rosettacode. Bye, bearophile
Feb 26 2014
parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Wednesday, 26 February 2014 at 12:58:26 UTC, bearophile wrote:

 If you have bug fixes, or improvements, it's better to do them 
 right there. Of if you don't want to register on that site, you 
 can put the modified version in dpaste, and I'll upload it on 
 Rosettacode.
Here are some improvements: http://dpaste.dzfl.pl/6430488f3d07 The changes are minimal just to accomodate for simple synchronization primitive. Full-blown Mutex version would be a little more involved, and somewhat ugly, at least until the upcoming migration of Mutex et al. to 'shared' takes place.
Feb 26 2014
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 02/26/2014 04:46 AM, Stanislav Blinov wrote:

 I forgot to note that both synchronized {} blocks should also be
 synchronizing on the same mutex.
Oh, that's a good one! :)
 Run the code several times and you'll no doubt stumble upon it.
But I had inserted that Sleep() in there. Isn't that the solution for all multi-threading problems? :p Ali
Feb 26 2014
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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.
     void print(string line)
     {
         enforce(ink != 0, new OutOfInk);
         writefln("%s: %s", id, line);
         --ink;
     }
 }

 struct PrinterRendezvous
 ...
             try {
                 synchronized {
 (cast(Printer)printers.front).print(lines.front);
                 }
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. :) I need more experience. :-/
 Bye,
 bearophile
Ali
Feb 26 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ali Çehreli:

 And I am not sure why the slicing syntax works because the 
 'printers' member is still shared then.
Probably it's a known D implementation fault meant to be eventually fixed. ------------- Stanislav Blinov:
 Here are some improvements:
 http://dpaste.dzfl.pl/6430488f3d07
Updated the site with your code (in that the "View history" shows both your names): http://rosettacode.org/wiki/Rendezvous#D Bye, bearophile
Feb 26 2014
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Feb 26 2014
prev sibling parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
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.
Feb 26 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Feb 26 2014
parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
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...
Feb 26 2014