Re: dmd 1.064 and 2.049 release
Walter Bright wrote: Aldo Nunez wrote: I filed bug report 4897. http://ftp.digitalmars.com/link.8.00.8.zip Looks good. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Vibrant 1.5
ponce: > Vibrant has been open source'd (again): > http://bitbucket.org/ponce/vibrant Very good. I have seen 2D vectors implemented something like ten times in D code, so I think it's time to stop this. They need to go in the standard library: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec2.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec3.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vec4.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/vectorop.d Useful math, fast too: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/common.d http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/rounding.d Half floats, I don't know if they are better than user defined floats of Phobos2: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/half.d Quaternions: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/quat.d A color module is useful: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/misc/colors.d Python std lib has colorsys: http://docs.python.org/library/colorsys.html More useful general matrix code: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/mat4.d Some very basic geometry code fit for a std.geometry module: http://bitbucket.org/ponce/vibrant/src/tip/trunk/common2/math/math2d.d I think all those things (maybe with a little more docs, improvements, unittests, contracts) are fit to be added to Phobos, because: - they are basic things that are commonly useful; - they aren't a lot of code; - they will be useful ten years from now too, they will not become obsolete; - I have seen them implemented in user D code several times; - Some of them are present in my dlibs1 and I have used them several times. Advanced modules for computational geometry, colorimetry, statistics, etc, are beyond the scope of Phobos2. But short, simple to use, frequently useful functions are fit for the standard library. So I think there are modules that should be added to Phobos: std.geometry std.color std.quaternions std.halffloats std.vectors std.combinatorics (or std.comb) for permutations, combiantions, subsets, and few more. Plus more code for std.math and std.array (for the matrix code) and std.numerics. Eventually I'd like to write a basic std.combinatorics module for Phobos2. Bye, bearophile
Re: Vibrant 1.5
Vibrant has been open source'd (again): http://bitbucket.org/ponce/vibrant
Re: dmd 1.064 and 2.049 release
Don: > Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top > priority. There will be no apology for fixing bugs like 3996, 4681, and > 4009. . I see. On the other hand little design bugs are important too because despite they now look temporary, they risk becoming permanent, I have some past experience on this. This is why I am using all the chances I have to put them under attention. So far only two of the ones I have listed have being discussed and only one of them was fixed (the one about a|b>c). Unrelated: in Bugzilla I have few small Phobos patches. If no one finds time or interest in them, then I may eventually desire to apply those patches myself. Bye, bearophile
Re: dmd 1.064 and 2.049 release
bearophile wrote: Walter Bright: This is primarily a bug fix release. I was away. Thank you for all the work. For the close future I suggest to focus a bit more on fixing language/design corner cases, instead of just on normal dmd/Phobos/druntime bugs (as done in this release). Sorry bearophile, regressions and wrong-code bugs will ALWAYS have top priority. There will be no apology for fixing bugs like 3996, 4681, and 4009. .
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-20 04:23:38 -0400, Jacob Carlborg said: On 2010-09-18 16:36, Michel Fortin wrote: Though I might decide on something else later. I'm thinking about mangling the argument types in the selector to make it work better with overloading. What about two methods that take the same number of parameters and of the same types but have two distinct selectors in Objective-C, like insertSublayer:below: and insertSublayer:above: in the CALayer class in the QuartzCore framework. Should those be translated to insertSublayerBelow or insertSublayer_below_ or something like that? Or have you planed a syntax that will solve this some other way? There is no automatic conversion from a selector to a D method name: you specify the method name (as usual) and you specify the selector (if you care about the selector, like in bindings). If you have a script that automatically creates bindings, then that script is the one that must figure out what method name to use for what selector. Because of this, there is no need for the D method name to be related to the selector. When you call a method, the method name is used to find the method declaration; and the declaration contains the selector to use. Calling undeclared methods is unsupported (unlike in Objective-C). -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.064 and 2.049 release
Walter Bright:
> This is primarily a bug fix release.
I was away. Thank you for all the work.
For the close future I suggest to focus a bit more on fixing language/design
corner cases, instead of just on normal dmd/Phobos/druntime bugs (as done in
this release).
The Changelog of 2.049 says:
Bugzilla 4603: array(iota(1, 0)) error.
But it's not closed, here time ago I have explained why:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=115725
See also:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=117461
---
Regarding bug 3554/3957:
http://d.puremagic.com/issues/show_bug.cgi?id=3554
It doesn't seem fixed in dmd 2.049. This program:
/// Return a random number in [0, 10 $(LPAREN)
void foo() {}
void main() {}
Generates an html that doesn't show the closing left parenthesis:
...
Return a random number in [0, 10
...
So if I am not mistaken I may reopen bug 3554.
Bye,
bearophile
Re: D/Objective-C: hit a dead end, start anew
On 2010-09-18 16:36, Michel Fortin wrote: On 2010-09-18 06:10:53 -0400, Jacob Carlborg said: Ok, now I'm not sure I understand. If you don't specify a selector for a declared method, how will the selector look like? In your example above, if you don't specify the selector how will it be something like: getObject:: ? Exactly. Note that this is a valid selector name. Though I might decide on something else later. I'm thinking about mangling the argument types in the selector to make it work better with overloading. What about two methods that take the same number of parameters and of the same types but have two distinct selectors in Objective-C, like insertSublayer:below: and insertSublayer:above: in the CALayer class in the QuartzCore framework. Should those be translated to insertSublayerBelow or insertSublayer_below_ or something like that? Or have you planed a syntax that will solve this some other way? -- /Jacob Carlborg
