D hits Slashdot
http://tech.slashdot.org/article.pl?sid=09/02/22/1346256 :)
Re: D hits Slashdot
Daniel de Kok wrote: http://tech.slashdot.org/article.pl?sid=09/02/22/1346256 :) I wonder if /that/ will do something to the TPCI... :)
Re: Just one more thing...
== Quote from Walter Bright (newshou...@digitalmars.com)'s article Michel Fortin wrote: Is 10.5 really binary incompatible with 10.4 ? It is compatible, unless you're using a new API or new linker features which weren't available in 10.4. Development on Mac OS X works by choosing a target SDK and a deployment target version. Unless you want to use new APIs from 10.5, you should use the MacOSX10.4u.sdk SDK. It's hard to see what that might be. dmd uses nothing but the generic linker commands, in fact, it uses gcc to do the link. It also doesn't use any but the basic api functions like read() and write(). You'll be affected pretty much no matter what you use. Changes between OS versions have included: * the libc and dynamic linker bootstrap process. Basically, crt.o changed, and you can't compile with the new crt.o and run on an old OS. * UNIX compliance. Some functions changed for UNIX compliance, so now libc includes _read and _read$UNIX2003 for example. If you build with UNIX compliance on (which is the default), then you'll magically link to the _read$UNIX2003 symbol, which doesn't exist on older OS versions. You can get backwards compatibility, but you have to ask for it with the SDK and min-version settings. -- Greg Parker gpar...@apple.com Runtime Wrangler
Re: Just one more thing...
Greg Parker wrote: You'll be affected pretty much no matter what you use. Changes between OS versions have included: * the libc and dynamic linker bootstrap process. Basically, crt.o changed, and you can't compile with the new crt.o and run on an old OS. * UNIX compliance. Some functions changed for UNIX compliance, so now libc includes _read and _read$UNIX2003 for example. If you build with UNIX compliance on (which is the default), then you'll magically link to the _read$UNIX2003 symbol, which doesn't exist on older OS versions. You can get backwards compatibility, but you have to ask for it with the SDK and min-version settings. Thanks, I think I've got the makefile set up for that now, though I don't have an old mac to test it on.
XOmB on reddit
http://www.reddit.com/r/programming/comments/7zahz/xomb_bare_bones_a_minimal_64_bit_os_written_in/
Is implicit string literal concatenation a good thing?
Find the bug: static string[] KEYWORDS = [ abstract, alias, align, asm, assert, auto, body, bool, break, byte, case, cast, catch, cdouble, cent, cfloat, char, class, const, continue, creal, dchar, debug, default, delegate, delete, deprecated, do, double, else, enum, export, extern, false, final, finally, float, for, foreach, foreach_reverse, function, goto, idouble, if, ifloat, import, in, inout, int, interface, invariant, ireal, is, lazy, long, mixin, module, new, null, out, override, package, pragma, private, private:, protected, protected:, public, public:, real, return, scope, short, static, struct, super, switch, synchronized, template, this, throw, true, try, typedef, typeid, typeof, ubyte, ucent, uint ulong, union, unittest, ushort, version, void, volatile, wchar, while, with, ~this ]; There is a comma missing : uint ulong
Re: Old problem with performance
Bill Baxter пишет: On Sun, Feb 22, 2009 at 1:02 AM, Weed resume...@mail.ru wrote: Bill Baxter пишет: 2009/2/21 Weed resume...@mail.ru: Weed пишет: Bill Baxter пишет: Why don't you just show us the class in the way you would like to write it in C++, and we'll show you how to write it in D, or finally agree with you that it's not possible. But as long as you continue to be hand-wavy about common base classes we're at a bit of an impasse. So far everyone thinks D can do what you want it to do based on your vague descriptions. As I said, you can write everything using goto and if. ...But why you do not like the original example of this thread? Please post again. I don't seem to recall any detailed example. --bb http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=83506 You should use a struct there! Your code does not show you doing anything that would even remotely suggest using a class is worthwhile. You're doing value operations on value types. That's what structs are for. Why? What if I have not substantiated the fact that c1 is a class I should use there a structure? Used in D a model of placement classes only in heap have a rule if you made the class and trying to pass it by value is somewhere in your code, there is a design error?
Re: Old problem with performance
Bill Baxter wrote: On Sun, Feb 22, 2009 at 5:10 AM, Denis Koroskin2kor...@gmail.com wrote: On Sat, 21 Feb 2009 21:49:46 +0300, Bill Baxterwbax...@gmail.com wrote: On Sun, Feb 22, 2009 at 1:02 AM, Weedresume...@mail.ru wrote: Bill Baxter пишет: 2009/2/21 Weedresume...@mail.ru: Weed пишет: Bill Baxter пишет: Why don't you just show us the class in the way you would like to write it in C++, and we'll show you how to write it in D, or finally agree with you that it's not possible. But as long as you continue to be hand-wavy about common base classes we're at a bit of an impasse. So far everyone thinks D can do what you want it to do based on your vague descriptions. As I said, you can write everything using goto and if. ...But why you do not like the original example of this thread? Please post again. I don't seem to recall any detailed example. --bb http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=83506 You should use a struct there! Your code does not show you doing anything that would even remotely suggest using a class is worthwhile. You're doing value operations on value types. That's what structs are for. --bb That's what *everyone* tells him! I am vaguely open to the possibility that he has a point. FLENS uses inheritance, for instance. But I don't recall what the intent of that inheritance was in FLENS, exactly. I more or less ported it to D without that, though, so I guess I didn't find it to be essential. See this: http://flens.cvs.sourceforge.net/viewvc/flens/FLENS/matvec/densevector.h?revision=1.36view=markup Versus this: http://www.dsource.org/projects/multiarray/browser/trunk/multiarray/dflat/DenseVector.d Weed, if you want to make a real argument, that would be a good place to start. Investigate why and how FLENS uses inheritance. --bb From a quick look at the flens DenseVector class: it inherits from a Vector Interface which only declares the destructor as virtual. My educated guess is that this interface has a similar purpose to the struct interfaces feature discussed here before - similar to C++ concepts. I don't see any polymorphism here - the functions aren't virtual.
Re: primitive vector types (permutation syntax)
I think that the following would work reasonably well: allow the [] operator for arrays to take comma separated lists of indices. So the OpenCL like statement: v.xyzw = v2.wzyx; will be written as: v[0,1,2,3] = v2[3,2,1,0]; Would this be ok? This is a general extension of the array slicing, and it might be possible to permute with a combination of slices and indices like this (i.e. v[0..3, 6, 5, 7.. len]). Is permutation operations something that Walter would be willing to add? As said by someone else in this thread, there need to be a way to specify that static arrays are passed by value, so can the ref keyword be paired with the oposite byval or something similar. And also, functions need to be able to return static arrays which is not possible at the moment. Note that the support should be general and work with any array type (so that you can get YMM support whenever that makes it into the future chips). / Mattias
Re: primitive vector types (permutation syntax)
On Sun, 22 Feb 2009 14:02:53 +0300, Mattias Holm hannibal.h...@gmail.com wrote: I think that the following would work reasonably well: allow the [] operator for arrays to take comma separated lists of indices. So the OpenCL like statement: v.xyzw = v2.wzyx; will be written as: v[0,1,2,3] = v2[3,2,1,0]; Would this be ok? This is a general extension of the array slicing, and it might be possible to permute with a combination of slices and indices like this (i.e. v[0..3, 6, 5, 7.. len]). Is permutation operations something that Walter would be willing to add? As said by someone else in this thread, there need to be a way to specify that static arrays are passed by value, so can the ref keyword be paired with the oposite byval or something similar. And also, functions need to be able to return static arrays which is not possible at the moment. Note that the support should be general and work with any array type (so that you can get YMM support whenever that makes it into the future chips). / Mattias How would you implement it for user-defined types?
Implicit string literal concatenation will die [Was: Is implicit string literal concatenation a good thing?]
Frank Benoit Wrote: static string[] KEYWORDS = [ abstract, alias, align, asm, assert, auto, body, bool, break, byte, case, ... with, ~this ]; There is a comma missing : uint ulong In such situations I often let the language split my string for me, it reduces noise: auto keywords = abstract alias align asm assert auto body bool break byte case cast catch cdouble cent cfloat char class const continue creal dchar debug default delegate delete deprecated do double else enum export extern false final finally float for foreach foreach_reverse function goto idouble if ifloat import in inout int interface invariant ireal is lazy long mixin module new null out override package pragma private private: protected protected: public public: real return scope short static struct super switch synchronized template this throw true try typedef typeid typeof ubyte ucent uint ulong union unittest ushort version void volatile wchar while with ~this.split(); You can also put one keyword for each line, or put them in better formatted columns. If the strings may have spaces too inside then, then I put each string in a different line, and then split according to the lines with std.string.splitlines() (or str.splitlines() in Python). Implicit string literal concatenation is a bug-prone anti-feature that is a relic of C language that doesn't have a nice string concatenation syntax. In D (and Python, etc) it's bad. Months ago I have suggested to remove it and turn adjacent string literals into a syntax error (to solve the back-compatibility with ported C/C++ code). Brad Roberts: In D, it's only marginally so, but not completely useless. It can still be used to break a really long string literal into parts. In such situations you can put a ~ at the end of each part. Explicit is better than implicit :-) Bye, bearophile
Re: primitive vector types
Andrei Alexandrescu: The conundrum is that a type system can't say that T[N] has some semantics for N = Nmax and some other semantics for N Nmax. So we need to pick one, and probably picking the value semantics is the right thing to do. Well, I think the type system can be extended to manage that: the programmer may specify an optional compiler command line argument like: -ms 128 Now all structs/static arrays more than 128 bytes long are passed by reference :-) Alternative solution, less extreme: instead of changing the value/ref pass semantics, when you add such optional command line argument the compiler gives you a compilation warning (or even error, if you want) everywhere you try to pass by value struct or static array more than 128 bytes long. Bye, bearophile
Re: Is implicit string literal concatenation a good thing?
Brad Roberts wrote: Back in c and c++, with it's pre-processor, merging adjacent string literals is very handy. In D, it's only marginally so, but not completely useless. It can still be used to break a really long string literal into parts. There's other string boundary tokens in D which might well provide viable alternatives. In C and C++, there is no way to catenate strings at compile time. The only way to catenate strings is with strcat. That places the additional burden on programmers that they have to include string.h. For that reason, it makes sense to catenate adjacent string literals. In D, there's a compile time catenation operator that doesn't require libraries. So the catenation by association saves you only one character. I'd say that's useless.
Re: primitive vector types (permutation syntax)
Denis Koroskin wrote:
On Sun, 22 Feb 2009 14:02:53 +0300, Mattias Holm
hannibal.h...@gmail.com wrote:
I think that the following would work reasonably well:
allow the [] operator for arrays to take comma separated lists of
indices.
So the OpenCL like statement:
v.xyzw = v2.wzyx;
will be written as:
v[0,1,2,3] = v2[3,2,1,0];
How would you implement it for user-defined types?
T[] opIndex(int[] indices) { ... }
void opIndexAssign(int[] indices, T[] values) { ... }
Re: primitive vector types (permutation syntax)
On Sun, 22 Feb 2009 16:51:10 +0300, Christopher Wright dhase...@gmail.com
wrote:
Denis Koroskin wrote:
On Sun, 22 Feb 2009 14:02:53 +0300, Mattias Holm
hannibal.h...@gmail.com wrote:
I think that the following would work reasonably well:
allow the [] operator for arrays to take comma separated lists of
indices.
So the OpenCL like statement:
v.xyzw = v2.wzyx;
will be written as:
v[0,1,2,3] = v2[3,2,1,0];
How would you implement it for user-defined types?
T[] opIndex(int[] indices) { ... }
void opIndexAssign(int[] indices, T[] values) { ... }
How about ranges included - v[0..3, 6, 5, 7..len] ?
Re: Is implicit string literal concatenation a good thing?
Sun, 22 Feb 2009 10:21:20 +0100, Frank Benoit wrote: Find the bug: static string[] KEYWORDS = [ abstract, alias, align, asm, assert, auto, body, bool, break, byte, case, cast, catch, cdouble, cent, cfloat, char, class, const, continue, creal, dchar, debug, default, delegate, delete, deprecated, do, double, else, enum, export, extern, false, final, finally, float, for, foreach, foreach_reverse, function, goto, idouble, if, ifloat, import, in, inout, int, interface, invariant, ireal, is, lazy, long, mixin, module, new, null, out, override, package, pragma, private, private:, protected, protected:, public, public:, real, return, scope, short, static, struct, super, switch, synchronized, template, this, throw, true, try, typedef, typeid, typeof, ubyte, ucent, uint ulong, union, unittest, ushort, version, void, volatile, wchar, while, with, ~this ]; There is a comma missing : uint ulong I agree this feature is dangerous and useless in D.
std.bind documentation sucks hard
At first sight I thought I had become stupid. Reading the page once through left me with absolutely no notion on how or to what one should or could use bind. (And that coming from someone who actually has studied the STL hard (albeit 10 years ago)). I can only imagine how much the average D-newcomer gets out of the page. First of all, the function bind itself is impossible to find simply by scanning the page. It also isn't in the Jump List at the top. Turns out it is hidden behind a scary line starting with typeof(new BoundFunc...)... stuff. (Yes, I understand it has to be there, but the word bind itself *has* to be findable by eyeballing the page down from the top. So put the word bind, e.g. in a mini-heading or whatever right before that line!) There are no examples. Yes, there are commands in example-style boxes, but they aren't examples, since all we have is the bare command invocation. An example (heh, even this post has one) of what I mean: - bind(foo, _0, _1) // will yield a delegate accepting two parameters - bind(foo, _1, _0) // will yield a delegate accepting two parameters - bind(bar, _0, _1, _2, _0) // will yield a delegate accepting three parameters What does this tell the _new_ reader?? Another example is const DynArg!(2) _2; What do I use it for, and where. And how do I use it? One would also expect that at the start of the page there is some text explaining the concept itself, where one should use bind, and for what benefit. The fact that nobody has yet pointed out the blatant typo in the long example that I pasted above, only serves to show that most readers try to read and understand the page, and give up. And the page has been there for over 2 years. It is not impossible to write good D doc pages, for example std.signals does a much better job. Or std.getopt. And before any smarta** says well, georg, why don't you fix it, I have to remind that currently I hardly have the time to read these NGs. But even then, for every few hours of reading, I at least try to give a meaningful contribution in exchange. Another smarta** might say that it says References: boost so read that. Well, one could say this about every single doc page on the site. Anyhow, if Tomasz Stachowiak (whom I'm not attacking with this post!) is unavailable, then I wish somebody who actually uses bind, could submit a better version. Even a little improvement would be most welcome. PS: with the newest developments in D2, bind is suddenly becoming an essential part of the new kind of D programming that is currently becoming possible!
Re: Is implicit string literal concatenation a good thing?
On Sun, Feb 22, 2009 at 11:12 PM, Denis Koroskin 2kor...@gmail.com wrote: On Sun, 22 Feb 2009 16:50:51 +0300, Christopher Wright dhase...@gmail.com wrote: Brad Roberts wrote: Back in c and c++, with it's pre-processor, merging adjacent string literals is very handy. In D, it's only marginally so, but not completely useless. It can still be used to break a really long string literal into parts. There's other string boundary tokens in D which might well provide viable alternatives. In C and C++, there is no way to catenate strings at compile time. The only way to catenate strings is with strcat. That places the additional burden on programmers that they have to include string.h. For that reason, it makes sense to catenate adjacent string literals. In D, there's a compile time catenation operator that doesn't require libraries. So the catenation by association saves you only one character. I'd say that's useless. I agree. I use this feature pretty frequently to break up long strings. I think I didn't use ~ for that because it makes me think an allocation might happen when it doesn't need to. But after seeing the discussion here I'd be happy to switch to using a~b as long as it's guaranteed by the language that such strings will be concatenated at compile time. (I think the is the case now, right?) --bb
Re: Is implicit string literal concatenation a good thing?
On Sun, Feb 22, 2009 at 12:51 PM, Bill Baxter wbax...@gmail.com wrote: I use this feature pretty frequently to break up long strings. I think I didn't use ~ for that because it makes me think an allocation might happen when it doesn't need to. But after seeing the discussion here I'd be happy to switch to using a~b as long as it's guaranteed by the language that such strings will be concatenated at compile time. (I think the is the case now, right?) Of course, it does it as a matter of constant folding, just like 3 + 4.
Re: Is implicit string literal concatenation a good thing?
Bill Baxter wrote: On Sun, Feb 22, 2009 at 11:12 PM, Denis Koroskin 2kor...@gmail.com wrote: On Sun, 22 Feb 2009 16:50:51 +0300, Christopher Wright dhase...@gmail.com wrote: Brad Roberts wrote: Back in c and c++, with it's pre-processor, merging adjacent string literals is very handy. In D, it's only marginally so, but not completely useless. It can still be used to break a really long string literal into parts. There's other string boundary tokens in D which might well provide viable alternatives. In C and C++, there is no way to catenate strings at compile time. The only way to catenate strings is with strcat. That places the additional burden on programmers that they have to include string.h. For that reason, it makes sense to catenate adjacent string literals. In D, there's a compile time catenation operator that doesn't require libraries. So the catenation by association saves you only one character. I'd say that's useless. I agree. I use this feature pretty frequently to break up long strings. I think I didn't use ~ for that because it makes me think an allocation might happen when it doesn't need to. But after seeing the discussion here I'd be happy to switch to using a~b as long as it's guaranteed by the language that such strings will be concatenated at compile time. (I think the is the case now, right?) Yes, and because of CTFE, even complicated applications of ~ frequently don't involve any allocation. So your intuition was wrong! Implicit concatentation was probably one of the things which led to your false impression. So it may be bad in that respect, as well as bug-breeding. --bb
The new std.bind
Georg Wrede wrote: At first sight I thought I had become stupid. Reading the page once through left me with absolutely no notion on how or to what one should or could use bind. (And that coming from someone who actually has studied the STL hard (albeit 10 years ago)). I can only imagine how much the average D-newcomer gets out of the page. [snip] PS: with the newest developments in D2, bind is suddenly becoming an essential part of the new kind of D programming that is currently becoming possible! Yah, I agree, std.bind is terribly outdated. Recent progress of D makes std.bind look like a curious silex tool. It's due for a complete rewrite. I don't have much time for that at the moment, but let's reframe this as an opportunity. Several people offered to tender their help to Phobos. Are there any takers for a new std.bind design? To avoid wasting work, let's discuss an interface first before doing any implementation. I have something in mind, but I don't want to bias anyone. So, I'm renaming this thread and launching a design contest for the new std.bind. First step: how should the interface look like? Andrei
Re: Is implicit string literal concatenation a good thing?
On Mon, Feb 23, 2009 at 3:42 AM, Don nos...@nospam.com wrote: Bill Baxter wrote: On Sun, Feb 22, 2009 at 11:12 PM, Denis Koroskin 2kor...@gmail.com wrote: On Sun, 22 Feb 2009 16:50:51 +0300, Christopher Wright dhase...@gmail.com wrote: Brad Roberts wrote: Back in c and c++, with it's pre-processor, merging adjacent string literals is very handy. In D, it's only marginally so, but not completely useless. It can still be used to break a really long string literal into parts. There's other string boundary tokens in D which might well provide viable alternatives. In C and C++, there is no way to catenate strings at compile time. The only way to catenate strings is with strcat. That places the additional burden on programmers that they have to include string.h. For that reason, it makes sense to catenate adjacent string literals. In D, there's a compile time catenation operator that doesn't require libraries. So the catenation by association saves you only one character. I'd say that's useless. I agree. I use this feature pretty frequently to break up long strings. I think I didn't use ~ for that because it makes me think an allocation might happen when it doesn't need to. But after seeing the discussion here I'd be happy to switch to using a~b as long as it's guaranteed by the language that such strings will be concatenated at compile time. (I think the is the case now, right?) Yes, and because of CTFE, even complicated applications of ~ frequently don't involve any allocation. So your intuition was wrong! Implicit concatentation was probably one of the things which led to your false impression. So it may be bad in that respect, as well as bug-breeding. Well, like I said, I vaguely recalled that DMD would eliminate the alloc. But is it in the spec? Some other compiler might not implement that optimization. Or I might change from foo~bar to foo~runTimeVar at some point and not notice that I'd introduced an allocation because of that. So the benefit of foo bar there was that I could be absolutely sure, since it's in the spec, that it concatenates the strings at compile time. But I agree it's something that could be gotten rid of. --bb
Re: primitive vector types
Mattias Holm wrote: And then we can easily immagine some extra nice features to have with respect to operators: vec ^ vec2; // 3d cross product for float vectors, for int vectors xor Has this been discussed before? Given that the wedge product is a defined operation on vectors (a^b is a bivector in the common plane of a b with area |a||b|sin θ)—related to, but very distinct from, the cross product—I’d call this a BAD operator overload. (B.T.W., I am starting work on a Geometric Algebra library which will implement all these products.) —Joel Salomon
Re: Is implicit string literal concatenation a good thing?
Hello Bill, I use this feature pretty frequently to break up long strings. I think I didn't use ~ for that because it makes me think an allocation might happen when it doesn't need to. yah, the WILL-happen-at-compiletime bit is nice But after seeing the discussion here I'd be happy to switch to using a~b as long as it's guaranteed by the language that such strings will be concatenated at compile time. (I think the is the case now, right?) same here. --bb
Re: Is implicit string literal concatenation a good thing?
Hello Jarrett, On Sun, Feb 22, 2009 at 12:51 PM, Bill Baxter wbax...@gmail.com wrote: I use this feature pretty frequently to break up long strings. I think I didn't use ~ for that because it makes me think an allocation might happen when it doesn't need to. But after seeing the discussion here I'd be happy to switch to using a~b as long as it's guaranteed by the language that such strings will be concatenated at compile time. (I think the is the case now, right?) Of course, it does it as a matter of constant folding, just like 3 + 4. IIRC DMD doesn't always do the constant folding (Decent has a post processed view that shows this in some cases) For instance, IIRC it only does left most so this: char[] foo = foo; char[] bar = foo ~ bar ~ baz doesn't get folded. And even if DMD were to start doing that one, there is no requirement that another compiler also do it.
Re: std.bind documentation sucks hard
Georg Wrede wrote: Another smarta** might say that it says References: boost so read that. Well, one could say this about every single doc page on the site. Well, I'll be that smarta** then. I've mostly implemented Bind for fun and I hate writing docs. I'm not sure if I actually use it in more than two(?) places in all of my projects and there was very little interest in it except the Phobos inclusion. Thus spending a few days writing docs that are already there (see the smarta** reference) was the last thing I wanted to do. Anyhow, if Tomasz Stachowiak (whom I'm not attacking with this post!) is unavailable, then I wish somebody who actually uses bind, could submit a better version. Even a little improvement would be most welcome. PS: with the newest developments in D2, bind is suddenly becoming an essential part of the new kind of D programming that is currently becoming possible! I'm not even sure what kind of improvements it needs except the docs since I don't really use it myself and I'm stuck with D1 anyway... -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: Is implicit string literal concatenation a good thing?
BCS:
IIRC DMD doesn't always do the constant folding (Decent has a post processed
view that shows this in some cases) For instance, IIRC it only does left
most so this:
char[] foo = foo;
char[] bar = foo ~ bar ~ baz
doesn't get folded. And even if DMD were to start doing that one, there is
no requirement that another compiler also do it.
If there are guarantees that abc def are folded at compile time, then the
same guarantees can be specified for abc ~ def. I can't see a problem.
I have also compiled this code with DMD:
void main() {
string foo = foo;
string bar = foo ~ bar ~ baz;
}
Resulting asm, no optimizations:
L0: pushEBP
mov EBP,ESP
mov EDX,FLAT:_DATA[0Ch]
mov EAX,FLAT:_DATA[08h]
pushdword ptr FLAT:_DATA[01Ch]
pushdword ptr FLAT:_DATA[018h]
pushdword ptr FLAT:_DATA[02Ch]
pushdword ptr FLAT:_DATA[028h]
pushEDX
pushEAX
push3
mov ECX,offset FLAT:_D11TypeInfo_Aa6__initZ
pushECX
callnear ptr __d_arraycatnT
xor EAX,EAX
add ESP,020h
pop EBP
ret
Resulting asm, with optimizations:
L0: sub ESP,0Ch
mov EAX,offset FLAT:_D11TypeInfo_Aa6__initZ
pushdword ptr FLAT:_DATA[01Ch]
pushdword ptr FLAT:_DATA[018h]
pushdword ptr FLAT:_DATA[02Ch]
pushdword ptr FLAT:_DATA[028h]
pushdword ptr FLAT:_DATA[0Ch]
pushdword ptr FLAT:_DATA[08h]
push3
pushEAX
callnear ptr __d_arraycatnT
add ESP,020h
add ESP,0Ch
xor EAX,EAX
ret
I can see just one arraycatn, so the two string literals are folded at compile
time, I think.
Bye,
bearophile
Re: primitive vector types (permutation syntax)
Mattias Holm: I think that the following would work reasonably well: allow the [] operator for arrays to take comma separated lists of indices. So the OpenCL like statement: v.xyzw = v2.wzyx; will be written as: v[0,1,2,3] = v2[3,2,1,0]; Be careful, I think a syntax like: v[0, 1] v[0, 1, 2, 3] Is better left to index in 2D and 4D arrays. nD arrays can be quite important in a language like D. So the following may be better and more compatible with the future: v[0; 1; 2; 3] = v2[3; 2; 1; 0]; Or: v[(0,1,2,3)] = v2[(3,2,1,0)]; Or: v[[0,1,2,3]] = v2[[3,2,1,0]]; Bye, bearophile
Re: primitive vector types (permutation syntax)
bearophile wrote:
Mattias Holm:
I think that the following would work reasonably well:
allow the [] operator for arrays to take comma separated lists of
indices.
So the OpenCL like statement:
v.xyzw = v2.wzyx;
will be written as:
v[0,1,2,3] = v2[3,2,1,0];
Be careful, I think a syntax like:
v[0, 1]
v[0, 1, 2, 3]
Is better left to index in 2D and 4D arrays.
nD arrays can be quite important in a language like D.
So the following may be better and more compatible with the future:
v[0; 1; 2; 3] = v2[3; 2; 1; 0];
Or:
v[(0,1,2,3)] = v2[(3,2,1,0)];
Or:
v[[0,1,2,3]] = v2[[3,2,1,0]];
Bye,
bearophile
Swizzling a vector and multidimensional access are orthogonal on account
of vectors having only one dimension [1].
struct FloatTuple(size_t n); // exercise to the reader :P
struct vec4f
{
union
{
float[4] data;
struct { float w, x, y, z; }
}
float opIndex(size_t i) { return data[i]; }
float opIndexAssign(float v, size_t i) { return data[i] = v; }
FloatTuple!(2) opIndex(size_t i, size_t j)
{
return FloatTuple!(2)(data[i],data[j]);
}
FloatTuple!(2) opIndexAssign(FloatTuple!(2) vs, size_t i, size_t j)
{
data[i] = vs.data[0];
data[j] = vs.data[1];
return vs;
}
// and so on for 3 and 4 argument versions.
}
Personally, I think something like this is a better idea:
struct vec4f
{
...
FloatTuple!(PermSpec.length) perm(string PermSpec)()
{
FloatTuple!(PermSpec.length) vs;
foreach( i ; Range!(PermSpec.length) )
vs.data[i] = mixin(`this.`~PermSpec[i]);
return vs;
}
}
void main()
{
vec4f a, b;
a = ...;
b = a.perm!(xyzw);
}
-- Daniel
[1] By this I mean they're a 1D data type; vec4f represents a 4D vector
but in terms of implementation, it has only one dimension: the index of
data.
Re: Is implicit string literal concatenation a good thing?
On Mon, 23 Feb 2009 04:18:35 +0300, bearophile bearophileh...@lycos.com wrote:
BCS:
IIRC DMD doesn't always do the constant folding (Decent has a post
processed
view that shows this in some cases) For instance, IIRC it only does left
most so this:
char[] foo = foo;
char[] bar = foo ~ bar ~ baz
doesn't get folded. And even if DMD were to start doing that one, there
is
no requirement that another compiler also do it.
If there are guarantees that abc def are folded at compile time,
then the same guarantees can be specified for abc ~ def. I can't see
a problem.
I have also compiled this code with DMD:
void main() {
string foo = foo;
string bar = foo ~ bar ~ baz;
}
Won't work. Imaging foo is a user-defined type with custom opCat:
auto bar = foo ~ 123 ~ 456;
compare to:
std::cout 123 456;
Re: Is implicit string literal concatenation a good thing?
Denis Koroskin:
bearophile:
void main() {
string foo = foo;
string bar = foo ~ bar ~ baz;
}
Won't work. Imaging foo is a user-defined type with custom opCat:
auto bar = foo ~ 123 ~ 456;
compare to:
std::cout 123 456;
In this thread I was talking about the concat of true strings, not of generic
objects:
auto bar = foo ~ (123 ~ 456);
Are you saying that the concat operation of
123 ~ 456
has a different (invisible) operator precedence of:
123 456 ?
If this is true, then the ~ isn't a fully drop-in replacement for the automatic
concat of strings as done in C...
Bye,
bearophile
gdb support (was Memory allocation failed)
Walter Bright wrote: Jason House wrote: Walter Bright Wrote: Jason House wrote: Apparently, setting an array length to -1 will cause this issue. It's unfortunate to not have a stack trace in the error output, or a functional gdb to capture it! I really hope gdb compatiblity will be fixed :( What's wrong with gdb? See my issue 2575 in bugzilla. I worked with a gdb developer to diagnose the issue immediately prior to submitting the bug report. IIRC, gdb can't determine where the code is because some kind of top level offset is missing. Reading my bug report should be more helpful than my memory. thanks I see you did post questions to the bugzilla report, and I did provide a response with what details I could deduce without a gdb dev helping me. Do you have enough information to work through the issue? Given how I currently have a program currently behaves differently with or without the -release flag, I'm extra motivated to get gdb working...
Re: Is implicit string literal concatenation a good thing?
bearophile wrote:
Denis Koroskin:
bearophile:
void main() {
string foo = foo;
string bar = foo ~ bar ~ baz;
}
Won't work. Imaging foo is a user-defined type with custom opCat:
auto bar = foo ~ 123 ~ 456;
compare to:
std::cout 123 456;
In this thread I was talking about the concat of true strings, not of generic
objects:
auto bar = foo ~ (123 ~ 456);
Are you saying that the concat operation of
123 ~ 456
has a different (invisible) operator precedence of:
123 456 ?
If this is true, then the ~ isn't a fully drop-in replacement for the automatic
concat of strings as done in C...
Bye,
bearophile
123 456 has the higher precedence
Re: Is implicit string literal concatenation a good thing?
On Sun, Feb 22, 2009 at 9:29 PM, bearophile bearophileh...@lycos.com wrote: Are you saying that the concat operation of 123 ~ 456 has a different (invisible) operator precedence of: 123 456 ? If this is true, then the ~ isn't a fully drop-in replacement for the automatic concat of strings as done in C... Currently that's the case. But it's simply unspecified in the language specification, and there's no reason why the compiler can't turn: a = foo ~ bar ~ baz; into: a = foo ~ barbaz; FWIW the MiniD compiler does this already. It's just that DMD currently does concatenation constant folding in a simple manner that makes this kind of folding invisible to it. But when all the operands of the concatenations are strings - like when building up strings to be mixed-in, or in static/const variable initializers - then everything will obviously be folded at compile time.
Generic functions to convert to void* and from void*
Hello,
I'm trying to build function which have the hability to convert a type to
void* and from void*.
I must use ref in the toPtr function because of this :
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.D.learnartnum=15600
Do you think that what I done is correct ?
/* - CODE - */
/***
* Convert a value to a void*
* Params:
* val =
* Returns:
*/
void* toPtr(T)(ref T val)
{
void* p ;
static if ( is( T b : Type ) )
{
p = new T ;
p = val ;
}
else
{
p = val ;
}
return p ;
}
/***
* Convert a void* to his value
* Params:
* ptr =
* Returns:
*/
T fromPtr(T)(void* ptr)
{
return *(cast(T*)ptr) ;
}
/* --- END CODE */
Thanks in advance,
TSalm
Re: Generic functions to convert to void* and from void*
I'm trying to build function which have the hability to convert a type
to void* and from void*.
I must use ref in the toPtr function because of this :
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.D.learnartnum=15600
Do you think that what I done is correct ?
/* - CODE - */
/***
* Convert a value to a void*
* Params:
* val =
* Returns:
*/
void* toPtr(T)(ref T val)
{
void* p ;
static if ( is( T b : Type ) )
{
p = new T ;
p = val ;
}
else
{
p = val ;
}
return p ;
}
/***
* Convert a void* to his value
* Params:
* ptr =
* Returns:
*/
T fromPtr(T)(void* ptr)
{
return *(cast(T*)ptr) ;
}
/* --- END CODE */
I've forget to say that toPtr can't be call with constants.
Re: Generic functions to convert to void* and from void*
TSalm wrote:
I'm trying to build function which have the hability to convert a type
to void* and from void*.
First of all, I have to ask: have you looked at std.variant /
tango.core.Variant?
I must use ref in the toPtr function because of this :
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.D.learnartnum=15600
Do you think that what I done is correct ?
/* - CODE - */
/***
* Convert a value to a void*
* Params:
* val =
* Returns:
*/
void* toPtr(T)(ref T val)
{
void* p ;
static if ( is( T b : Type ) )
What is this test doing? You're checking to see if T can be implicitly
cast to Type... but Type isn't defined. And what is 'b' doing there?
{
p = new T ;
p = val ;
You never use the freshly-allocated T. You assign it to p and then
immediately overwrite it with val.
}
else
{
p = val ;
}
return p ;
}
So the function is basically doing this:
T fromPtr(T)(ref T val)
{
return val;
}
/***
* Convert a void* to his value
* Params:
* ptr =
* Returns:
*/
T fromPtr(T)(void* ptr)
{
return *(cast(T*)ptr) ;
}
/* --- END CODE */
I've forget to say that toPtr can't be call with constants.
I get the distinct impression that you're seriously over-thinking this.
Both of these functions could be rewritten as casts. Aside from that,
you've given no context for me to have any idea what you're trying to
accomplish here.
-- Daniel
parsing parameters
is there any reason to allow BasicType AnonymousDeclarator = AssignExpression as a parameter? As far as I know, it's gibberish (but, then, I don't know very far).
[Issue 2642] ClassInfo.init contains zeroes
http://d.puremagic.com/issues/show_bug.cgi?id=2642 dhase...@gmail.com changed: What|Removed |Added Summary|.init contains zeroes |ClassInfo.init contains ||zeroes --- Comment #8 from dhase...@gmail.com 2009-02-22 08:09 --- It wasn't clear to me that this is talking about ClassInfo.init rather than Type.init. Non-nullable types do nothing for this problem. Class initialization consists of three stages: 1. allocate appropriate size 2. memcpy ClassInfo.init to allocated space 3. run constructor With or without explicit initialization requirements, you could put that initialization in the constructors. That is going to be slower than copying bytes in some circumstances. Of course, if there's only a few fields to set, since the allocator already zeroes out allocated memory, that's less work. In any case, it will be convenient to have ClassInfo.init, for doing various There Be Dragons things. --
[Issue 2682] const struct initialized with struct literal recreates value on stack when used
http://d.puremagic.com/issues/show_bug.cgi?id=2682 s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #1 from s...@iname.com 2009-02-22 09:08 --- This reminds me of bug 2414 ... related? --
[Issue 2683] New: Cannot implement interface methods by alias
http://d.puremagic.com/issues/show_bug.cgi?id=2683
Summary: Cannot implement interface methods by alias
Product: D
Version: 1.039
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: dhase...@gmail.com
interface IFoo
{
void foo();
}
class Foo : IFoo
{
void bar() {}
alias bar foo;
}
// class iface_alias.Foo interface function IFoo.foo isn't implemented
This is a problem for me because I want to implement methods with a template,
but my choices for that template are a string mixin or a template mixin, and
with a template mixin, I have to alias the template to the desired method.
String mixins don't work for this; for example, if the return type is a
templated class, string mixins will fail (see #1748). Or if the return type is
a public alias to a private type. I'm not aware of a workaround for this
(anything that requires manual coding aside from the template is not a valid
workaround).
--
[Issue 2451] Cannot add a Variant to associative array
http://d.puremagic.com/issues/show_bug.cgi?id=2451
--- Comment #1 from and...@metalanguage.com 2009-02-22 09:39 ---
(In reply to comment #0)
import std.variant;
void main()
{
Variant[string] a;
Variant v = 1;
a[wut?] = v;
}
core.exception.arrayboundsexcept...@test(23): Array index out of bounds
Key type is irrelevant.
I reduced this further:
struct Wyda
{
void opAssign(Wyda) {assert(this !is null);}
}
void main()
{
Wyda[int] a;
a[4] = Wyda();
}
The assert will fail! Hash tables for value types that define opAssign seem to
have a problem.
--
[Issue 2684] New: Associative arrays have wrong opIndex signatures
http://d.puremagic.com/issues/show_bug.cgi?id=2684
Summary: Associative arrays have wrong opIndex signatures
Product: D
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: and...@metalanguage.com
void main()
{
int[string] x;
char[] y;
if (y in x){}
int z = x[y];
}
The last two lines do not compile. However it makes of course sense to look up
for a char[] or const(char)[] in a hash keyed by immutable(char)[]. Only the
operator that inserts stuff into the hash should force the type
immutable(char)[].
Bottom line: if the type of the key is K, any type K1 that allows comparison
for equality and less-than with K should be accepted for lookup.
--
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259 s...@iname.com changed: What|Removed |Added CC||o.da...@gmx.de --- Comment #2 from s...@iname.com 2009-02-22 11:45 --- *** Bug 2205 has been marked as a duplicate of this bug. *** --
[Issue 2205] Warning on comparison between signed and unsigned
http://d.puremagic.com/issues/show_bug.cgi?id=2205 s...@iname.com changed: What|Removed |Added Status|NEW |RESOLVED Keywords|diagnostic |accepts-invalid Resolution||DUPLICATE --- Comment #2 from s...@iname.com 2009-02-22 11:45 --- I've just checked, and by spec it's supposed to be an error. *** This bug has been marked as a duplicate of 259 *** --
[Issue 2683] Cannot implement interface methods by alias
http://d.puremagic.com/issues/show_bug.cgi?id=2683 dhase...@gmail.com changed: What|Removed |Added Version|1.039 |1.00 --- Comment #1 from dhase...@gmail.com 2009-02-22 18:22 --- ClassDeclaration::findFunc goes through the class's vtbl, and aliases don't make it into the vtbl. It doesn't matter if I force the function to be virtual by overriding it. I can duplicate this on dmd 1.00. --
[Issue 2683] Cannot implement interface methods by alias
http://d.puremagic.com/issues/show_bug.cgi?id=2683 s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #2 from s...@iname.com 2009-02-22 20:09 --- This is a generalisation of issue 2565/issue 502. --
[Issue 1970] Templated interfaces not matched
http://d.puremagic.com/issues/show_bug.cgi?id=1970 dhase...@gmail.com changed: What|Removed |Added CC||dhase...@gmail.com --- Comment #2 from dhase...@gmail.com 2009-02-22 20:25 --- This is related to #1715, I think -- at the very least, this would be a workaround for #1715 and #1714 if it worked. --
