Re: receiveOnly behavior
On 05/05/11 01.31, Sean Kelly wrote:
On May 4, 2011, at 2:05 PM, jdrewsen wrote:
import std.concurrency;
void main(string[] args) {
receiveOnly!bool();
}
This simple program results in segmentation fault. I know i does not spawn a
thread to receive anything from but is this the expected behavior?
This was a known issue when calling receive() in the main thread before ever
calling thisTid(). Doing so seemed rather unlikely, but fixing this was a
trivial code change so I've just done so. Expect your sample to not segfault
in the next release.
Thank you.
/Jonas
D auto-tester
In case not everyone knows about this, Brad Roberts conceived, implemented, set up and maintains an automated tester that watches github for checkins, and when there's something new it does a complete build of dmd and phobos, then runs the test suite on it, and posts the results: http://d.puremagic.com/test-results/ I think it's awesome.
Re: D auto-tester
I too think it's awesome. Just some quick thoughts; * Could some kind of benchmarking be integrated to track performance aspects, especially find regressions? Perhaps a bit high on the utility/work-scale? * Is the script available for running offline, on some local machine, I.E. verifying different distro:s, etc? * 1280x1024 is too small for seeing the results. Could the view perhaps be made slightly more compact? (Especially since OSX64 and Win64 might be interesting targets in the near future?) * What is "Linux 32/64" vs. "64/32"? In any case, great stuff. 2011/5/5 Walter Bright : > In case not everyone knows about this, Brad Roberts conceived, implemented, > set up and maintains an automated tester that watches github for checkins, > and when there's something new it does a complete build of dmd and phobos, > then runs the test suite on it, and posts the results: > > http://d.puremagic.com/test-results/ > > I think it's awesome. >
Re: D auto-tester
Am 05.05.2011 22:15, schrieb Ulrik Mikaelsson:
> I too think it's awesome.
>
> Just some quick thoughts;
> * Could some kind of benchmarking be integrated to track performance
> aspects, especially find regressions? Perhaps a bit high on the
> utility/work-scale?
> * Is the script available for running offline, on some local machine,
> I.E. verifying different distro:s, etc?
> * 1280x1024 is too small for seeing the results. Could the view
> perhaps be made slightly more compact? (Especially since OSX64 and
> Win64 might be interesting targets in the near future?)
> * What is "Linux 32/64" vs. "64/32"?
>
I *guess* Linux 32/64 means "32bit dmd generating 64bit binaries" and
"Linux 64/32" means "64bit dmd generating 32bit binaries".
Also note "Linux 64/64" ("64bit dmd generating 64bit binaries).
Seems like we get a native 64bit compiler for Linux. Awesome!
(But note that this is just my interpretation, maybe I'm wrong).
> In any case, great stuff.
I agree :)
>
> 2011/5/5 Walter Bright :
>> In case not everyone knows about this, Brad Roberts conceived, implemented,
>> set up and maintains an automated tester that watches github for checkins,
>> and when there's something new it does a complete build of dmd and phobos,
>> then runs the test suite on it, and posts the results:
>>
>> http://d.puremagic.com/test-results/
>>
>> I think it's awesome.
>>
Re: D auto-tester
On 05/05/2011 21:15, Ulrik Mikaelsson wrote: I too think it's awesome. Just some quick thoughts; * Could some kind of benchmarking be integrated to track performance aspects, especially find regressions? Perhaps a bit high on the utility/work-scale? Yes, this wouldn't be of much use though, as little work is done on the backend, and it only tracks dmd right now. It could perhaps be forked in a performance branch if someone were interested in that. * Is the script available for running offline, on some local machine, I.E. verifying different distro:s, etc? Yes, it's on github I believe, see the test/ directory of dmd. The server/client stuff is also available elsewhere I believe. * 1280x1024 is too small for seeing the results. Could the view perhaps be made slightly more compact? (Especially since OSX64 and Win64 might be interesting targets in the near future?) There was a recent discussion about this, there are plans to create a much cleaner and more compact view. * What is "Linux 32/64" vs. "64/32"? 32 bit dmd creating 64 bit binaries, 64 bit dmd creating 32 bit binaries. I believe you get a description if you hover over them. -- Robert http://octarineparrot.com/
Re: D auto-tester
On Thu, 5 May 2011, Ulrik Mikaelsson wrote: > Just some quick thoughts; > * Could some kind of benchmarking be integrated to track performance > aspects, especially find regressions? Perhaps a bit high on the > utility/work-scale? Could? Yes. Am I going to? Not likely. If someone else does, it could be incorporated. > * Is the script available for running offline, on some local machine, > I.E. verifying different distro:s, etc? There's a link to the scripts at the bottom of the page. They're hosted on github. I've often got parts that aren't yet checked in but nothing that's particularly central to the testing. > * 1280x1024 is too small for seeing the results. Could the view > perhaps be made slightly more compact? (Especially since OSX64 and > Win64 might be interesting targets in the near future?) See answers from the others. But in general, sorry. I'm catering to the people who are doing the primary development, and most have nice large and wide screens. > * What is "Linux 32/64" vs. "64/32"? As indicated already, hover over each of the titles for a longer description of the build. Later, Brad
Re: D auto-tester
Awesome stuff! One small comments. Have you thought about displaying it as a table? A lot of words are duplicated hence wasting precious display space. The table can look as follows: Linux x86 ... compileunittest ... dmd 00:00 druntime phobos ... Hopefully that displays correctly... -Jose On Thu, May 5, 2011 at 6:21 PM, Brad Roberts wrote: > On Thu, 5 May 2011, Ulrik Mikaelsson wrote: > >> Just some quick thoughts; >> * Could some kind of benchmarking be integrated to track performance >> aspects, especially find regressions? Perhaps a bit high on the >> utility/work-scale? > > Could? Yes. > Am I going to? Not likely. If someone else does, it could be > incorporated. > >> * Is the script available for running offline, on some local machine, >> I.E. verifying different distro:s, etc? > > There's a link to the scripts at the bottom of the page. They're hosted > on github. I've often got parts that aren't yet checked in but nothing > that's particularly central to the testing. > >> * 1280x1024 is too small for seeing the results. Could the view >> perhaps be made slightly more compact? (Especially since OSX64 and >> Win64 might be interesting targets in the near future?) > > See answers from the others. But in general, sorry. I'm catering to the > people who are doing the primary development, and most have nice large and > wide screens. > >> * What is "Linux 32/64" vs. "64/32"? > > As indicated already, hover over each of the titles for a longer > description of the build. > > Later, > Brad > >
Re: Ceylon language
Currying is well established name as well, especially for people coming from a functional programming background. (Cristi Cobzarenco) Profile: http://www.google.com/profiles/cristi.cobzarenco On 4 May 2011 23:40, bearophile wrote: > Lutger Blijdestijn: > > > partial application is getting a new function out of an existing one > where > > one of the arguments is fixed / bound. More or less what std.functional > > curry does, confusingly. > > [...] > > A simple and good explanation. > Regarding the name of std.functional.curry(), since some time I have > suggested to rename it "partial". > > Bye, > bearophile >
Re: Ceylon language
On 2011-05-06 00:54:34 +0300, Cristi Cobzarenco said: Currying is well established name as well, especially for people coming from a functional programming background. Current implementation does not curry the function, it partialy applies it. Currying is converting a function that takes multiple arguments to a function that takes first argument and returns a function that takes the second argument and do on. Curry ((a, b) -> c) -> a -> b -> c Uncurry (a -> b -> c) -> (a, b) -> c (Cristi Cobzarenco) Profile: http://www.google.com/profiles/cristi.cobzarenco On 4 May 2011 23:40, bearophile wrote: Lutger Blijdestijn: > partial application is getting a new function out of an existing one where > one of the arguments is fixed / bound. More or less what std.functional > curry does, confusingly. > [...] A simple and good explanation. Regarding the name of std.functional.curry(), since some time I have suggested to rename it "partial". Bye, bearophile
C++ static analysis
Through Reddit I've seen another document that shows common little bugs in
C/C++ code found by a static analysis tool. The bugs shown seem to be real,
from real software:
http://www.slideshare.net/Andrey_Karpov/add2011-en
>From the slides I have selected seven of the bugs, here translated to D2:
enum uint FLAG1 = 0b001;
void main() {
int x = 1000;
int y = 1;
if (!y & x) {} //#1
uint flags;
if (flags && FLAG1) {} //#2
if (y == 0 || 10 || y) {} //#3
int i;
for (i = 0; i < 10; i++)
for (i = 1; i < 5; i++) {} //#4
if (x || x) {} //#5
if (x) y = 1; else y = 1; //#6
auto z = x * y ? 10 : 20; //#7
}
Notes about the bugs:
- In #1 the programmer meant to write if(!(y & x)). This is often a bug.
- In #2 the programmer probably meant to use & instead of && to intersect the
flags.
- In #3 the boolean condition is always true, and y is ignored.
- In #4 there are two nested loops with the same index variable.
- In #5 the two conditions in or are the exactly the same. When this happens,
it's probably a bug.
- In #6 the two branches of the if are exactly the same. When this happens,
it's probably a bug.
- In #7 the programmer may have misunderstood the precedence levels between ?:
operator and the * (mult) operator.
Notes about D2:
- Bug #1 is common, easy to catch statically, so I think it's worth catching by
D2 language (we have discussed this bug in past too, but the catching code is
not present yet). I think D2 may require parentheses here.
- Regarding #2, that static analysis tool catches it too, it seems, but I don't
know how to catch it, or if it's worth catching. But it's probably a not so
uncommon bug.
- #3 is an example of always true or always false boolean expression (that's
not 0/1 or true/false). It's a case that asks for considerations similar of #5
ones.
- Bug #4 is probably easy to find, but in D is less common, because you usually
use foreach, or for with local index variable (that D doesn't allow you to
redefine). Once in a while that kind of code is correct, maybe.
- Bug #5 and #6 are similar. Simular redundancies often are bugs. But I don't
know if D2 wants to actually turn this correct code into a real compile-time
error. But it's worth thinking more about it.
- Bug #7 is easy to catch, and the fix is to ask for more parentheses. But I
think it's not a so common bug.
So:
- I suggest to change D2 to catch #1 statically.
- I encourage you to think more about what to do with bugs #3, #5, #6 (there is
another related bug, with class/struct members assignments,
http://d.puremagic.com/issues/show_bug.cgi?id=3878 ).
- Maybe think about fixing #7 too. ?: operators are a rich source of bugs
anyway.
Bye,
bearophile
Re: D auto-tester
On 2011-05-05 23:21, Brad Roberts wrote: On Thu, 5 May 2011, Ulrik Mikaelsson wrote: Just some quick thoughts; * Could some kind of benchmarking be integrated to track performance aspects, especially find regressions? Perhaps a bit high on the utility/work-scale? Could? Yes. Am I going to? Not likely. If someone else does, it could be incorporated. * Is the script available for running offline, on some local machine, I.E. verifying different distro:s, etc? There's a link to the scripts at the bottom of the page. They're hosted on github. I've often got parts that aren't yet checked in but nothing that's particularly central to the testing. * 1280x1024 is too small for seeing the results. Could the view perhaps be made slightly more compact? (Especially since OSX64 and Win64 might be interesting targets in the near future?) See answers from the others. But in general, sorry. I'm catering to the people who are doing the primary development, and most have nice large and wide screens. I have a display with a 1680x1050 resolution, it fills up the whole screen, no more room for additional platforms without scrolling. Still too small? * What is "Linux 32/64" vs. "64/32"? As indicated already, hover over each of the titles for a longer description of the build. Later, Brad -- /Jacob Carlborg
