Re: d support in codeblocks
Am 28.03.2010 23:54, schrieb Bernard Helyer: On 29/03/10 08:24, Matthias Pleh wrote: Hey all, as I already posted in D.ide newsgroup, I am working on an improvement for D support in the codeblocks IDE. Now I've made a patch and posted it in the codeblocks forum: http://forums.codeblocks.org/index.php/topic,12246.0.html It would be cool, If there are some D user, whow can try out and test this patch. What should be done: - check out the newest sourcecode of codeblocks http://svn.berlios.de/svnroot/repos/codeblocks/trunk - apply the patch mentioned above - test the D features and report any bug, comments and wishes in the same thread as the patch. (remember, this patch is only a start!) - and of course feel free to send new patches yourself!! greets nocide Hey cool! Does it support D2? yep! Just try it out and report any bugs!
Re: DMDScript now under Boost license
I think it would be pretty great if you could add functions, etc., to the scripting language with a simple one liner: mixin makeAccessibleFromScript!(scriptEngine, foo); Or something similar. The template there could mix in a wrapper function for whatever foo() happens to be, and register it with the scripting engine all in one call. Then, to call a function defined in script, you should be able to just do callScriptFunction(name, args...);, but this is optional; I say getting D functions accessible from the script with ease is more important. Anyway, you take that and the dmdscript and package them together as an D extender library. To use it, you just import the script module, mixin the template to extend it, and boom, done. Perhaps down the line, a magic function could even look for @scriptable attributes* and add them automatically. But no need immediately. * I'll say again, I'd love to have user defined attributes accessible from __traits for just this kind of thing. On 3/29/10, Walter Bright newshou...@digitalmars.com wrote: strtr wrote: Walter Bright Wrote: http://www.digitalmars.com/dscript/index.html Would it be possible to have some sort of scripting as part of D? What did you have in mind?
Re: DMDScript now under Boost license
On 29/03/10 18:41, Adam Ruppe wrote: I think it would be pretty great if you could add functions, etc., to the scripting language with a simple one liner: mixin makeAccessibleFromScript!(scriptEngine, foo); You can do with with MiniD, LuaD, PyD, Monster, and possibly others to allow you to script in minid, lua, python an monster (I think there's something for ruby out there too). I haven't played with dmdscript, but I'd guess there's a simple way to expose D functions to it. Or something similar. The template there could mix in a wrapper function for whatever foo() happens to be, and register it with the scripting engine all in one call. Then, to call a function defined in script, you should be able to just do callScriptFunction(name, args...);, but this is optional; I say getting D functions accessible from the script with ease is more important. All of the above languages/wrappers have some way of doing this, with various degrees of simplicity/ease. Anyway, you take that and the dmdscript and package them together as an D extender library. To use it, you just import the script module, mixin the template to extend it, and boom, done. I don't think this is a good idea, unless a decent policy for what is included can be figured out. That said, I believe there's an old version of dmd packaged with projects that work with it. Perhaps down the line, a magic function could even look for @scriptable attributes* and add them automatically. But no need immediately. * I'll say again, I'd love to have user defined attributes accessible from __traits for just this kind of thing. I'm pretty sure user defined attributes aren't in for D2, it looks like it'll be D3 or later if/when we get them.
Re: d support in codeblocks
On Sun, 28 Mar 2010 16:24:30 -0300, Matthias Pleh matthias.p...@gmx.at wrote: Hey all, as I already posted in D.ide newsgroup, I am working on an improvement for D support in the codeblocks IDE. Now I've made a patch and posted it in the codeblocks forum: http://forums.codeblocks.org/index.php/topic,12246.0.html It would be cool, If there are some D user, whow can try out and test this patch. What should be done: - check out the newest sourcecode of codeblocks http://svn.berlios.de/svnroot/repos/codeblocks/trunk - apply the patch mentioned above - test the D features and report any bug, comments and wishes in the same thread as the patch. (remember, this patch is only a start!) - and of course feel free to send new patches yourself!! greets nocide This looks like a great start. However, I'm not sure which patches I should apply. The thread has couple of patches by 'bernard' but I can't seem to find the main patches by nocide. I'm probably blind, but could you point out where the links should be located? Thanks.
Re: DMDScript now under Boost license
On 29/03/10 19:30, Adam D. Ruppe wrote: On Mon, Mar 29, 2010 at 06:49:35PM +0100, Robert Clipsham wrote: I haven't played with dmdscript, but I'd guess there's a simple way to expose D functions to it. It isn't terribly complex, but it is a bit wordy. The docs are here: http://www.digitalmars.com/dscript/extending.html You have to make your function in a certain convention, then register it using a struct and a function. The function convention gives you the most access to the script environment, but it is a pain to write all your functions that way. You could always write a nice wrapper function/template which automatically does all that guff for you :) If you do, I'm sure Walter wouldn't mind adding it into dmdscript providing you license it appropriately :) I'm pretty sure user defined attributes aren't in for D2, it looks like it'll be D3 or later if/when we get them. Indeed. But everyone on this group needs /some/ wish feature to bring up at every opportunity, right? :-P Agreed :) Guess I need to go and sit in a corner until I think of a feature, then I can come back to the group a true D user :P
Re: DMDScript now under Boost license
On Mon, Mar 29, 2010 at 07:45:39PM +0100, Robert Clipsham wrote: You could always write a nice wrapper function/template which automatically does all that guff for you :) If you do, I'm sure Walter wouldn't mind adding it into dmdscript providing you license it appropriately :) Yup, that's what I'm thinking about in these messages. The one problem point might be dmdscript is D1 IIRC. I'll have to grab the updated source and see what I can make of it. Agreed :) Guess I need to go and sit in a corner until I think of a feature, then I can come back to the group a true D user :P Make sure it is something that's been done to death and only marginally useful anyway for big bonus points! -- Adam D. Ruppe http://arsdnet.net
Re: DMDScript now under Boost license
On 29/03/10 20:07, Adam D. Ruppe wrote: On Mon, Mar 29, 2010 at 07:45:39PM +0100, Robert Clipsham wrote: You could always write a nice wrapper function/template which automatically does all that guff for you :) If you do, I'm sure Walter wouldn't mind adding it into dmdscript providing you license it appropriately :) Yup, that's what I'm thinking about in these messages. The one problem point might be dmdscript is D1 IIRC. I'll have to grab the updated source and see what I can make of it. I seem to recall it is, and a fairly old D1 at that... You could always update it and send a patch Walter's way, see if he accepts it :) Agreed :) Guess I need to go and sit in a corner until I think of a feature, then I can come back to the group a true D user :P Make sure it is something that's been done to death and only marginally useful anyway for big bonus points! Hmm, I'll definitely be wanting the bonus points... This is gonna need some thinking!
Re: d support in codeblocks
Am 29.03.2010 18:51, schrieb Robert Jacques: On Sun, 28 Mar 2010 16:24:30 -0300, Matthias Pleh matthias.p...@gmx.at wrote: Hey all, as I already posted in D.ide newsgroup, I am working on an improvement for D support in the codeblocks IDE. Now I've made a patch and posted it in the codeblocks forum: http://forums.codeblocks.org/index.php/topic,12246.0.html It would be cool, If there are some D user, whow can try out and test this patch. What should be done: - check out the newest sourcecode of codeblocks http://svn.berlios.de/svnroot/repos/codeblocks/trunk - apply the patch mentioned above - test the D features and report any bug, comments and wishes in the same thread as the patch. (remember, this patch is only a start!) - and of course feel free to send new patches yourself!! greets nocide This looks like a great start. However, I'm not sure which patches I should apply. The thread has couple of patches by 'bernard' but I can't seem to find the main patches by nocide. I'm probably blind, but could you point out where the links should be located? Thanks. Hello Robert, you have to log in to see the attached files. So just register and login :) Ther are 2 files attached in the 1.post. * d_win_v2.patch * d_nix_v2.patch - for *nix (it's really the same, just *nix lineendings) If you have further questions, don't hesistate to ask again! greets nocide
Re: DMDScript now under Boost license
Walter Bright Wrote: strtr wrote: Walter Bright Wrote: http://www.digitalmars.com/dscript/index.html Would it be possible to have some sort of scripting as part of D? What did you have in mind? Scripting in de form of a dialect/subset of D in the std/language. I don't know enough about scripting to say anything specific/useful. It's just that if scripting were part of D, I would have used it already where the possibilities mentioned by Robert Clipsham just look that much bigger a step. And being part of the language/community simply instils trust.
Re: DMDScript now under Boost license
strtr wrote: Scripting in de form of a dialect/subset of D in the std/language. I don't know enough about scripting to say anything specific/useful. It's just that if scripting were part of D, I would have used it already where the possibilities mentioned by Robert Clipsham just look that much bigger a step. And being part of the language/community simply instils trust. I thought about that a lot, but CTFE seems to fill that gap well enough.
Re: DMDScript now under Boost license
Walter Bright Wrote: strtr wrote: Scripting in de form of a dialect/subset of D in the std/language. I don't know enough about scripting to say anything specific/useful. It's just that if scripting were part of D, I would have used it already where the possibilities mentioned by Robert Clipsham just look that much bigger a step. And being part of the language/community simply instils trust. I thought about that a lot, but CTFE seems to fill that gap well enough. I don't think CTFE fills the gap of RTFE. I need the scripting for my users and they can't compile the program :) Maybe you are talking about another gap. Now, choosing a scripting language feels like a stab in the dark and I can't put it off forever :)
Re: DMDScript now under Boost license
Walter Bright: I thought about that a lot, but CTFE seems to fill that gap well enough. CTFE works at compile-time, while people add scripting languages like Python, JavaScript, Groovy, Jpython, Jruby, etc, to run-time C/C++/Java code for other purposes. For example games are often written in C++ and Lua. For example Firefox is C++ and JavaScript, ecc. You can't write one million of lines of D CTFE code to script a 3D videogame. So unless you leave the compiler beside the running program, and you allow to dynamically interpret and run D code at runtime, the purposes are very different. So I think embedding/extending D2 with a scripting/dynamic language (like MiniD o Python with Pyd) will be useful for some future D projects. But I don't want it built-in, people will find ways to attach it as they do to C/C++/Java. You have to focus in building a good D language. What I think I'd like in D is something like this, but I think there's no need to use JavaScript for this, it can be used just D code: https://developer.mozilla.org/en/Treehydra Bye, bearophile
Re: D is dead, so now where it the money going?
JamesKan wrote: Andrei wants some (he just wants money, huh). Walter? Shut it down. Count the people engaged in this whatever it is, and if a few select capitalize on its failure, then, who are you? There is no money in D. None. Nada. Religions are not for profit. It's OK to worship, whoever stupid people want to. If TDPL goes to press, there is something VERY wrong (and there is). All the money goes into buying food for the troll.
Re: literals
Walter Bright wrote: Don wrote: (1) Converting a floating point literal into a double literal is usually not lossless. 0.5f, 0.5, and 0.5L are all exactly the same number, since they are exactly representable. But 0.1 is not the same as 0.1L. It depends. The D compiler internally stores all floating point constants, regardless of type, in full 80 bit precision. Constant folding and CTFE are all carried out in 80 bit precision regardless of type. The only time it is actually truncated to the shorter formats is when writing it out to the object file. The central idea is that more precision == better. If your floating point algorithm breaks if precision increases, then the algorithm is a bad one. The only time I've seen code that relied on roundoff errors is in test suites that specifically tested for it. There's some oddities. //enum A = 1.0e400; // Error: number is not representable enum B = 1.0e200 * 1e200; // yes it is! enum C = 1.0e400L; static assert(B==C); So there's a bit of schizophrenia about whether the 'L' suffix changes which values are representable, or whether it is just a type marker. I think we should tighten things up a little bit, but I don't think it's a big deal.
Re: literals
On 29-mar-10, at 10:29, Don wrote:
Walter Bright wrote:
Don wrote:
(1) Converting a floating point literal into a double literal is
usually not lossless.
0.5f, 0.5, and 0.5L are all exactly the same number, since they
are exactly representable.
But 0.1 is not the same as 0.1L.
It depends. The D compiler internally stores all floating point
constants, regardless of type, in full 80 bit precision. Constant
folding and CTFE are all carried out in 80 bit precision regardless
of type. The only time it is actually truncated to the shorter
formats is when writing it out to the object file.
The central idea is that more precision == better. If your floating
point algorithm breaks if precision increases, then the algorithm
is a bad one.
The only time I've seen code that relied on roundoff errors is in
test suites that specifically tested for it.
There's some oddities.
//enum A = 1.0e400; // Error: number is not representable
enum B = 1.0e200 * 1e200; // yes it is!
enum C = 1.0e400L;
static assert(B==C);
So there's a bit of schizophrenia about whether the 'L' suffix
changes which values are representable, or whether it is just a type
marker.
I think we should tighten things up a little bit, but I don't think
it's a big deal.
good to have the numerics expert look into this.
Yes I think the situation is really quite ok, for example (now having
some doubts) I just checked (to be sure the correct thing would
happens as I thought) and
T mult1(T)(T x){
return 1.01*x;
}
assert(mult1(1.0f)==1.0f,float);
assert(mult1(1.0)==1.0,double);
assert(mult1(1.0L)==1.0L*1.01L,real);
:)
Re: literals
On Sun, 28 Mar 2010 15:09:35 -0400, so s...@so.do wrote:
On Sun, 28 Mar 2010 23:46:55 +0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
What you are asking for is a template instantiation that depends on
instantiating itself. How about a function like this?
void foo(int x);
T inv(T)(T m) {
foo(m);
return 1.0/m;
}
How do you know what type to use for T? It's simple when you make inv
a one-liner, there is only one thing to look at. But as you start
making the function more complex, then it's impossible to tell what the
user actually wants. In this instance, T must be implicitly
convertable to int, but also must be a floating point type. Clearly
there is an error here, but where is it? This is called ambiguity, and
to avoid it, the compiler makes a decision, right or wrong, based on
the literal used to call the function. It expects you, the user, to
help out when it doesn't make the right one. I don't think it's too
much to ask. It's simply a tradeoff between being an all-powerful
oracle-like compiler and being a simple-to-write compiler.
I don't think a language/compiler should make premature decisions when
an ambiguity happens,
What is warning or error mechanism for then?
It has to make a decision on literals, or else you can't use them without
casting. I'd hate to write code for a compiler that requires you to cast
every literal.
In your case, we have a rule at hand, and you broke it. That should
require an explicit cast,
Also, when you have a framework, you would have the T version of the
foo right? I guess i am missing something here.
What you are missing is it's easy to look at a simple example and conclude
that a compiler should have enough intelligence to understand what you
meant in that simple example. However, you must also look at more complex
cases and figure out if the rule holds for those as well. I think in your
simple one-liner, it is obvious to a person that inv only compiles for
floating point types. However, you want it to work for the literal 5,
right? So you want the compiler to use the code of the function to deduce
what the type of 5 is, knowing that the function should compile for
floating point types. It just isn't a workable general solution. Code
can be very complex, and to require the compiler to understand the
semantic meaning of the code in this way is not how the D compiler is
built. It is *told* how to compile something, and then checks that what
you told it to do makes sense. It doesn't figure stuff out for itself in
anything bigger than a single statement. D is supposed to be a
context-free grammar.
What the compiler sees when deciding to instantiate is this:
T inv(T)(T m) {...}
And it makes a decision.
I am perfectly fine with that.
I am confused. I thought this was your problem? That it wasn't taking
the body of the function into account when deciding the type of T?
If you have a problem with writing inv(5.0) instead of inv(5), then
maybe D just isn't for you.
-Steve
I am not sure what you mean really? You mean the other way around? i
want :
inv(5.0f), inv(5.0d), inv(5.0L)
or
T x; inv(x); // where T is floating point type.
This works today, no (except for the d is redundant)? I guess I don't
really understand what you are looking for...
-Steve
Re: More precise GC
On Sun, 28 Mar 2010 23:30:32 -0400, Robert Jacques sandf...@jhu.edu wrote: On Sun, 28 Mar 2010 16:16:41 -0300, Steven Schveighoffer schvei...@yahoo.com wrote: The current GC has a simple type info if you will -- contains pointers or doesn't contain pointers. It doesn't mean we cannot add to that. In fact, I think dsimcha has provided a way to have precise scanning for heap-allocated types. I don't think a reasonably precise GC is out of the question. However, it may be too much to require the GC to do semantic analysis of enums for unions. Not impossible, but probably not worth the effort and restrictions necessary. Also, don't forget that classes have a bunch of runtime type info. But the GC doesn't use/need this info (except to call the destructors). At least the mark/sweep portion doesn't. -Steve
Re: literals
On 29-mar-10, at 12:57, Steven Schveighoffer wrote: On Sun, 28 Mar 2010 15:09:35 -0400, so s...@so.do wrote: On Sun, 28 Mar 2010 23:46:55 +0400, Steven Schveighoffer schvei...@yahoo.com wrote: [...] I am not sure what you mean really? You mean the other way around? i want : inv(5.0f), inv(5.0d), inv(5.0L) or T x; inv(x); // where T is floating point type. This works today, no (except for the d is redundant)? I guess I don't really understand what you are looking for... I guess I am not alone then :)
Bugzilla votes
I've taken a look at the votes in Bugzilla, and I've seen the bug reports that ask for a more tidy module system are among most voted ones, it's not just a pet peeve of mine: Entry number 1: Bug 314: [module] Static, renamed, and selective imports are always public, 30 votes Entry number 3: Bug 313: [module] Fully qualified names bypass private imports, 15 votes Entry number 36: Bug 1297: [module] Static modules, aka enforcing static import., 3 votes Total 48 points for just three bugs! I think there are 252 bugs voted, 168 of them have 1 vote. 521 votes in total. So those three bugs cover more than 9% of all votes. I hope Walter will take a look at fixing all the semantics of modules, that at the moment has holes like Swiss cheese. Bye, bearophile
Re: Bugzilla votes
On 29/03/10 12:43, bearophile wrote: I've taken a look at the votes in Bugzilla, and I've seen the bug reports that ask for a more tidy module system are among most voted ones, it's not just a pet peeve of mine: Entry number 1: Bug 314: [module] Static, renamed, and selective imports are always public, 30 votes Entry number 3: Bug 313: [module] Fully qualified names bypass private imports, 15 votes Entry number 36: Bug 1297: [module] Static modules, aka enforcing static import., 3 votes Total 48 points for just three bugs! I think there are 252 bugs voted, 168 of them have 1 vote. 521 votes in total. So those three bugs cover more than 9% of all votes. I hope Walter will take a look at fixing all the semantics of modules, that at the moment has holes like Swiss cheese. Bye, bearophile I should note both #313 and #314 are both fixed (or at least partially fixed) in ldc, so unless Walter has some unspoken objections to the current patches it shouldn't be too much effort to fix it in dmd. I believe he did raise some issues with it, but I think they have been fixed since, I'm not 100% on this though.
Re: literals
This works today, no (except for the d is redundant)? I guess I don't
really understand what you are looking for...
-Steve
Could you please write the equivalent D code for generic inv function?
I guess it would be
T inv(T)(T m) {
return 1 / m;
}
Right? With a glance, It is perfectly what i want!
Now lets apply C derived language (D is one of them as we all know) rules
here and analyze what is happening.
Q - what is 1 ?
A - 1 is an int, which means, signed int, also in D it is 32 bit
signed it, in C bit count is implementation defined, of course D way much
better.
Q - what happens when i call inv(5.0f)
A - return float(1) / 5.0f
Anything wrong with questions and answers here?
What i am asking is why it have to be this way.
In return 1 / float, why 1 is assumed as an integer, and consequently
casted to float.
In math [real numbers] [integers] [natural numbers}, why 1 is an
integer? and especially why 1 is an 32 bit integer?
T foo(T)(T k) {
return k + 3;
}
General answer will be like, above code should fricking work, without my
explicit cast! And you are right, That is perfectly fine with me! :)
I again ask, for this code to work, Is it necessary 3 be a 32bit
integer, or a native type at all?
--
You are right, inv is a dumb function, we need a real world example.
Say we have a function with 2 overloads, which might be the reasons of
precision, performance...
float foo(float m) {}
double foo(double m) {}
Now we need to call this within a generic code.
void test(T)(T m) {
return m * foo(0.3);
}
Since 0.3 is a double, double version will be called, so we should use
foo(cast(T)0.3), right?
When the function foo is a popular one, what am i going to do? anything
other than casting at each occurrence?
with functions like foo, code becomes like...
void test2(T)(T m) {
T n = foo1(cast(T)0.3) / foo2(cast(T)9);
...
}
And everyone thinks that he is writing generic code...
Thanks!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Network in phobos
On Sun, Mar 28, 2010 at 12:37:14PM -0700, Igor Lesik wrote:
IMHO, such oversimplified approach is not very useful.
Depends on your needs. A lot of time, I just want to quickly whip
something together that fetches something, and I don't care how long
it takes*. It's the kind of thing I'd use the nc program on the linux
command line to do, but right there in the D.
* If I do care how long it takes, I'll just fork() the whole program and
let the child to it. I'm thinking about making a generic background!(delegate)
template that can do this automatically, but D2 should have threads that work
just as well soon anyway.
One example is I needed something very simple that speaks SMTP. I wrote
it in my fancier network library, and it was a fair amount of code that
was a bit overcomplicated.
With this kind of thing, it is a fairly brief list of writefln and readln
lines.
Yes, it would be so nice to have a good network library, but many things
have to be considered in order to cook decent library. One important
aspect is support for asynchronous calls; for example TCP/UDP stuff
in Boost is placed in to ASIO package.
In my fancier library http://arsdnet.net/dcode/netman.d, which needs some
work still to finish, but is usable, all write and read calls go to a buffer.
By the way, everything in my dcode directory there is free for the taking
if anyone wants it.
Anyway, you do something like this:
class MyConnection : Connection {
override void onDataReceived() {
auto a = read(); // gets the buffer of new data
write(some data); // puts that in the outgoing buffer. not
// actually written until the function returns
changeReadPosition(pos); // discards [0..pos] of the internal
// buffer, so the next time you get
// called, you deal with leftover info.
// good for handling incomplete requests
}
}
The incoming and outgoing buffers aren't actually put on the network until
the next call to NetworkManager.proceed(). So your main has to look something
like this:
void main() {
auto netman = new NetworkManager;
netman.connect(site.com, 80);
while(netman.proceed()) { }
}
The nice thing about the network manager class is it does incoming connections
too:
void main() {
auto netman = new NetworkManager;
netman.listen(80);
while(netman.proceed() { }
}
And each incoming connection is a particular specialization of the Connection
class (which you create in a delegate, not shown here), which handles all the
work. netman.proceed() calls select() on all its sockets, then calls the
appropriate handler based on what happens: onDataReceived, onDisconnect, etc.
The downside is my read() and write() functions are very simple, and kinda
suck, and every call is async, so even if you don't care about speed, you
have to code it with all your functions returning instantly.
The various functions and ranges in the stdio File are much easier to work
with for lots of things.
Ideally, what I think would be nice is having File available for when you
want it, and then being able to attach it to a NetworkManager kind of thing
which adds async calls to the interface.
Or something like that. Maybe the one size can't really fit all, but I'd like
to have both options available somehow.
As long as you use only socket API there is no problem to write generic
code for Linux and Windows. Windows socket API even has select() function.
Cool. Most my code is just simple socket stuff, so it should be easy to
port then.
--
Adam D. Ruppe
http://arsdnet.net
Re: literals
On Mon, 29 Mar 2010 09:20:56 -0400, so s...@so.do wrote:
You are right, inv is a dumb function, we need a real world example.
Say we have a function with 2 overloads, which might be the reasons of
precision, performance...
float foo(float m) {}
double foo(double m) {}
Now we need to call this within a generic code.
void test(T)(T m) {
return m * foo(0.3);
}
Since 0.3 is a double, double version will be called, so we should use
foo(cast(T)0.3), right?
When the function foo is a popular one, what am i going to do? anything
other than casting at each occurrence?
with functions like foo, code becomes like...
void test2(T)(T m) {
T n = foo1(cast(T)0.3) / foo2(cast(T)9);
...
}
OK, I see the issue now. The syntax for declaring that a literal is the
type of T is too verbose. This is different than what I thought you
wanted.
I agree this isn't the best situation. It's good that it is possible, but
we should strive to find a better way.
Sorry for the noise from misunderstanding.
As for the better way, one possibility is using C++-style value type
constructors:
float(0.3)
This provides a way to have T be a user-defined type as well (define
static opCall or a constructor)
So the test function would look like this:
void test(T)(T m) {
{
return m * foo(T(0.3));
}
It would be nice to say in this function, assume numeric literals are of
type T, but that might be too specific a solution (could only apply to
builtin types). I don't think it's feasible for the compiler to infer
what type it should use.
-Steve
Re: D is dead, so now where it the money going?
JamesKan Wrote: Andrei wants some (he just wants money, huh). Walter? Shut it down. Count the people engaged in this whatever it is, and if a few select capitalize on its failure, then, who are you? There is no money in D. None. Nada. Religions are not for profit. It's OK to worship, whoever stupid people want to. If TDPL goes to press, there is something VERY wrong (and there is). All the money has gone to build a large volcano complex where Walter can sit all day stroking a white cat and plotting the downfall of C++... -=mike=-
Re: literals
It would be nice to say in this function, assume numeric literals are of type T, but that might be too specific a solution (could only apply to builtin types). I don't think it's feasible for the compiler to infer what type it should use. -Steve It would be nice indeed! My proposalish idea was exactly for this problem, that removing default literal rule, and treating every implicit constant (constant without literal) as a generic type. I don't think it will ever happen even if i was able to provide full parsing framework, since C is a strong opponent :) Thanks! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: literals
What i am asking is why it have to be this way.
In return 1 / float, why 1 is assumed as an integer, and
consequently casted to float.
In math [real numbers] [integers] [natural numbers}, why 1 is an
integer? and especially why 1 is an 32 bit integer?
T foo(T)(T k) {
return k + 3;
}
General answer will be like, above code should fricking work,
without my explicit cast! And you are right, That is perfectly fine
with me! :)
I again ask, for this code to work, Is it necessary 3 be a 32bit
integer, or a native type at all?
well as you said in mathematics a Natural number is also an Integer
which is also a Rational which is also a Real.
One could say that you have an injection, an implicit cast from
Natural to Integer to Rational to Real.
By the way maybe you fear that the implicit cast is done at runtime,
or has some hidden cost, but that is not the case, for literals it is
done at compile time.
In reality (and also in mathematics if you use cyclic groups, or
approximate numbers) the situation becomes a lot more murky, but in
the end not much changes.
On 29-mar-10, at 15:47, so wrote:
It would be nice to say in this function, assume numeric literals
are of type T, but that might be too specific a solution (could
only apply to builtin types). I don't think it's feasible for the
compiler to infer what type it should use.
-Steve
It would be nice indeed!
My proposalish idea was exactly for this problem,
that removing default literal rule, and treating every implicit
constant (constant without literal) as a generic type.
I don't think it will ever happen even if i was able to provide full
parsing framework, since C is a strong opponent :)
The example you give cannot be solved easily and efficiently (find the
type to use in a function) without some kind of inference based on the
return type, annotations, or Hindley Milner style type inference.
annotation don't scale, using inference based on the return type is
very difficult and not doable in general, few languages do it (aldor
for example did it), Hindley Milner is incompatible with C.
Please note that (possibly due to my C background) I like to put some
type annotations, in my (limited) experience that pays off also with
ML style languages, otherwise when you have ambiguity small errors can
change the called functions and give surprising results.
Fawzi
Re: More precise GC
On Mon, 29 Mar 2010 08:09:09 -0300, Steven Schveighoffer schvei...@yahoo.com wrote: On Sun, 28 Mar 2010 23:30:32 -0400, Robert Jacques sandf...@jhu.edu wrote: On Sun, 28 Mar 2010 16:16:41 -0300, Steven Schveighoffer schvei...@yahoo.com wrote: The current GC has a simple type info if you will -- contains pointers or doesn't contain pointers. It doesn't mean we cannot add to that. In fact, I think dsimcha has provided a way to have precise scanning for heap-allocated types. I don't think a reasonably precise GC is out of the question. However, it may be too much to require the GC to do semantic analysis of enums for unions. Not impossible, but probably not worth the effort and restrictions necessary. Also, don't forget that classes have a bunch of runtime type info. But the GC doesn't use/need this info (except to call the destructors). At least the mark/sweep portion doesn't. -Steve Sorry, my comment was more for a D in general than the GC. GC's in general don't know or need anything beyond a pointer mask and whether to finalize or not.
Re: literals
The example you give cannot be solved easily and efficiently (find the type to use in a function) without some kind of inference based on the return type, annotations, or Hindley Milner style type inference. annotation don't scale, using inference based on the return type is very difficult and not doable in general, few languages do it (aldor for example did it), Hindley Milner is incompatible with C. Please note that (possibly due to my C background) I like to put some type annotations, in my (limited) experience that pays off also with ML style languages, otherwise when you have ambiguity small errors can change the called functions and give surprising results. Fawzi Finally i am able to explain it with 2 words, Hindley Milner :) I want credit too! i also found it independently! Thanks for the explanation, i don't really like non-system, non-generic languages, non-D like languages. Especially when a language has dumb reasons for not providing an utility. (Java operator overloading case) D is the best choice for me by miles and i can learn to live with casts as i did in C++. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: D is dead, so now where it the money going?
Mike James wrote: All the money has gone to build a large volcano complex where Walter can sit all day stroking a white cat and plotting the downfall of C++... Eeexcellhhhnt!! twirls mustache
Re: D is dead, so now where it the money going?
Walter Bright newshou...@digitalmars.com wrote: Mike James wrote: All the money has gone to build a large volcano complex where Walter can sit all day stroking a white cat and plotting the downfall of C++... Eeexcellhhhnt!! twirls mustache You've grown a mustache? Perfect! Finally there's hope for D!* *http://www.alenz.org/mirror/khason/why-microsoft-can-blow-off-with-c.html -- Simen
shouldn't phobos finally use some complete windows bindings (from the bindings project)?
Much stuff is missing.
Re: literals
On 29-mar-10, at 16:57, so wrote: The example you give cannot be solved easily and efficiently (find the type to use in a function) without some kind of inference based on the return type, annotations, or Hindley Milner style type inference. annotation don't scale, using inference based on the return type is very difficult and not doable in general, few languages do it (aldor for example did it), Hindley Milner is incompatible with C. Please note that (possibly due to my C background) I like to put some type annotations, in my (limited) experience that pays off also with ML style languages, otherwise when you have ambiguity small errors can change the called functions and give surprising results. Fawzi Finally i am able to explain it with 2 words, Hindley Milner :) I want credit too! i also found it independently! ehm actually Hindley Milner is not enough for what you requested, it can find types of functions, but integers are still separated from floats. It can't cope well with incompatible overloads or conversions (they have type a-b)... what you want is really return type based inference something that is hard, as said as far as I know only aldor did that Thanks for the explanation, i don't really like non-system, non- generic languages, non-D like languages. Especially when a language has dumb reasons for not providing an utility. (Java operator overloading case) D is the best choice for me by miles and i can learn to live with casts as i did in C++. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[OT] Who lives in the by area?
I just graduated from collage (Yeah!) and got a job (Ye-ha!) in the San Francisco bay area where I've spent just over 24hr ever (urk...). Anyone from the area have any advice? Places to avoid, things to look into or watch out for? That sort of thing. (Offline responses also welcome at: benjamin at precisionsoftware us ) -- ... IXOYE
Re: Implicit enum conversions are a stupid PITA
Andrei Alexandrescu wrote:
On 03/28/2010 03:44 AM, Lutger wrote:
(...)
I like this idea of implementing a flag type and tried to work something
out. Instead of implementing the overloads, it is also possible to
generate an enum via CTFE inside a struct and forward with alias this,
what do you think? I have tried this syntax, seems to work ok:
alias Flags!q{ do_nothing,
walk_dog,
cook_breakfast,
deliver_newspaper,
visit_miss_kerbopple,
wash_covers } Todo;
It does allow this though, but perhaps that can fixed:
Todo todo = Todo.walk_dog;
todo |= 4;
With such a type, it is easy to add some small convenience features, such
as
an enumToString, define property .max and implement a range that iterates
over all flags set or possible values.
I think it will take some time to settle the competition between
template parses everything approach and language parses most approach.
For what it's worth, Walter and I were talking three years ago about a
new alias feature:
template Flags(new alias Names...) { ... }
new alias means that you may pass to Flags symbols that haven't been
defined. With that feature in place, Flags could be used like this:
alias Flags!(do_nothing,
walk_dog,
cook_breakfast,
deliver_newspaper,
visit_miss_kerbopple,
wash_covers)
Todo;
No muss, no fuss, no need to stringize anything. Flags could get to the
names of the alias parameters by using Names[i].stringof.
Well that's not in the language yet :o).
Andrei
That would be nice, perhaps it's possible for a backwards-compatible 2.x
release to work something out. As bearophile said Ruby has some nice things
for metaprogramming that help with this, borrowed from lisp of course. I do
think Ruby's strong metaprogramming helped RoR become popular.
In the meantime I tried to hack Flags together and got stuck on this thing:
auto myTodoList = Todo.do_nothing;
Now myTodoList is of type uint (or whatever), not so nice - it's inconsistent
with regular named enums. It messed up making a range for iterating over the
flags set, which I thought was a nice addition.
Anyway, here is my attempt so far, please forgive me it is not so elegant:
import std.conv;
string genFlags(string names, string type = uint)
{
string result = enum : ~ type ~ { ;
int bits = 1;
size_t pos;
// skip leading whitespace
while( ++pos names.length names[pos] == ' ') { }
size_t prev = pos;
bool hasInitializer = false;
while ( pos names.length)
{
if (names[pos] == '=')
hasInitializer = true;
else if (names[pos] == ',')
{
result ~= names[prev..pos];
if (!hasInitializer)
{
result ~= = ~ std.conv.to!string(bits);
bits = 1;
}
else
hasInitializer = false;
result ~= ',';
//skip whitespace
while( ++pos names.length names[pos] == ' ') { }
prev = pos;
}
pos++;
}
// concat the last flag
if (hasInitializer)
return result ~ names[prev..pos] ~ };
return result ~ names[prev..pos] ~ = ~ std.conv.to!string(bits) ~
};
}
struct Flags(string members, T = uint)
{
static assert( is(T : ulong), Wrong underlying type of Flags: must be
integral not ~ T.stringof );
mixin( genFlags(members) );
alias typeof(this) FlagsType;
T value;
alias value this;
this(T value)
{
this.value = value;
}
void opAssign(T value)
{
this.value = value;
}
pure bool opBinaryRight(string op, E)(E lhs) const
if ( op == in )
{
return cast(bool)(lhs this);
}
}
unittest
{
alias Flags!q{ do_nothing, walk_dog, cook_breakfast, deliver_newspaper,
visit_miss_kerbopple, morning_task = walk_dog | cook_breakfast,
wash_covers } Todo;
Todo list1 = Todo.do_nothing;
assert( list1 == 1 );
list1 |= Todo.wash_covers | Todo.walk_dog;
assert(list1 == Todo.do_nothing | Todo.wash_covers | Todo.walk_dog);
assert(Todo.do_nothing in list1);
Todo list2 = Todo.cook_breakfast | Todo.wash_covers;
assert( list1 list2 == Todo.do_nothing | Todo.cook_breakfast);
list1 = list2;
assert(list1 == Todo.do_nothing | Todo.wash_covers | Todo.walk_dog);
assert( Todo.morning_task == Todo.walk_dog | Todo.cook_breakfast );
auto list3 = Todo.deliver_newspaper;
assert(Todo.deliver_newspaper in list3, can't infer type properly); /*
bug */
}
Re: [OT] Who lives in the by area?
BCS Wrote: I just graduated from collage (Yeah!) and got a job (Ye-ha!) in the San Francisco bay area where I've spent just over 24hr ever (urk...). Anyone from the area have any advice? Places to avoid, things to look into or watch out for? That sort of thing. (Offline responses also welcome at: benjamin at precisionsoftware us ) -- ... IXOYE Avoid Blue Oyster bar, if you are not one of those. Other than that, you'll be just fine.
Re: Implicit enum conversions are a stupid PITA
Lutger wrote:
...
struct Flags(string members, T = uint)
{
static assert( is(T : ulong), Wrong underlying type of Flags: must be
integral not ~ T.stringof );
mixin( genFlags(members) );
I screwed up of course, this must be:
mixin( genFlags(members, T.stringof) );
alias typeof(this) FlagsType;
T value;
alias value this;
this(T value)
{
this.value = value;
}
void opAssign(T value)
{
this.value = value;
}
pure bool opBinaryRight(string op, E)(E lhs) const
if ( op == in )
{
return cast(bool)(lhs this);
}
}
...
Re: Implicit enum conversions are a stupid PITA
Lutger wrote:
...
unittest
{
alias Flags!q{ do_nothing, walk_dog, cook_breakfast, deliver_newspaper,
visit_miss_kerbopple, morning_task = walk_dog | cook_breakfast,
wash_covers } Todo;
Todo list1 = Todo.do_nothing;
assert( list1 == 1 );
list1 |= Todo.wash_covers | Todo.walk_dog;
assert(list1 == Todo.do_nothing | Todo.wash_covers | Todo.walk_dog);
assert(Todo.do_nothing in list1);
Todo list2 = Todo.cook_breakfast | Todo.wash_covers;
assert( list1 list2 == Todo.do_nothing | Todo.cook_breakfast);
list1 = list2;
assert(list1 == Todo.do_nothing | Todo.wash_covers | Todo.walk_dog);
assert( Todo.morning_task == Todo.walk_dog | Todo.cook_breakfast );
auto list3 = Todo.deliver_newspaper;
assert(Todo.deliver_newspaper in list3, can't infer type properly);
/*
bug */
}
^
oops, this one is totally messed up and needs to go to precedence school.
This should be better:
unittest
{
alias Flags!q{ do_nothing, walk_dog, cook_breakfast, deliver_newspaper,
visit_miss_kerbopple, morning_task = walk_dog |
cook_breakfast, wash_covers } Todo;
Todo list1 = Todo.do_nothing;
assert( list1 == 1 );
list1 |= Todo.wash_covers | Todo.walk_dog;
assert(list1 == (Todo.do_nothing | Todo.wash_covers | Todo.walk_dog) );
assert(Todo.do_nothing in list1);
Todo list2 = Todo.cook_breakfast | Todo.wash_covers;
assert( (list1 list2) == Todo.wash_covers );
list1 = list2;
assert(list1 == (Todo.cook_breakfast | Todo.wash_covers) );
assert( Todo.morning_task == (Todo.walk_dog | Todo.cook_breakfast) );
auto list3 = Todo.deliver_newspaper;
/* bug */
assert(Todo.deliver_newspaper in list3, can't infer type properly);
}
Re: D is dead, so now where it the money going?
Hello Walter, I know a guy who got pasted enough in an online forum[...] got pasted? -- ... IXOYE
Re: D is dead, so now where it the money going?
BCS wrote: Hello Walter, I know a guy who got pasted enough in an online forum[...] got pasted? It's an old expression for bombing an area to bits.
Re: [OT] Who lives in the by area?
I just graduated from collage (Yeah!) and got a job (Ye-ha!) in the San Francisco bay area where I've spent just over 24hr ever (urk...). Anyone from the area have any advice? Places to avoid, things to look into or watch out for? That sort of thing. Be careful in the Bay, naughty sharks sometimes attack surfers.
Re: [OT] Who lives in the by area?
BCS wrote: I just graduated from collage (Yeah!) and got a job (Ye-ha!) in the San Francisco bay area where I've spent just over 24hr ever (urk...). Anyone from the area have any advice? Places to avoid, things to look into or watch out for? That sort of thing. (Offline responses also welcome at: benjamin at precisionsoftware us ) As the local ACCU group, we meet in Mountain View every second Wednesday, which has already heard a brief introduction to D: http://accu-usa.org/ Perhaps it's time to start the Bay Area D Interest Group: The Bay Diggers :D Ali
Re: [OT] Who lives in the by area?
On Mon, Mar 29, 2010 at 12:44 PM, BCS n...@anon.com wrote: I just graduated from collage (Yeah!) Classic. What's next, decoupage? photomontage? and got a job (Ye-ha!) Sincere congrats. --bb
Re: [OT] Who lives in the by area?
Hello Ali, BCS wrote: I just graduated from collage (Yeah!) and got a job (Ye-ha!) in the San Francisco bay area where I've spent just over 24hr ever (urk...). Anyone from the area have any advice? Places to avoid, things to look into or watch out for? That sort of thing. (Offline responses also welcome at: benjamin at precisionsoftware us ) As the local ACCU group, we meet in Mountain View every second Wednesday, which has already heard a brief introduction to D: http://accu-usa.org/ Perhaps it's time to start the Bay Area D Interest Group: The Bay Diggers :D Cool, I'll keep that in mind. BTW I can't seem to find what ACCU stands for. -- ... IXOYE
Slow documentation solution??
The line script src=http://www.gmodules.com/ig/ifr?url=http://www.google.com/ig/modules/translatemypage.xml up_source_language=enw=160h=60title=border=output=js/script in most of the documentation files appears to be slowing loading, and not doing anything useful. With it in the files, even using local files looking up anything is painfully slow. When removed things appear to speed up and nothing seems to be lost. What is it's function? Does removing it cause any problems (that I just haven't noticed yet)?
Re: Slow documentation solution??
Charles Hixson wrote: The line script src=http://www.gmodules.com/ig/ifr?url=http://www.google.com/ig/modules/translatemypage.xml up_source_language=enw=160h=60title=border=output=js/script in most of the documentation files appears to be slowing loading, and not doing anything useful. With it in the files, even using local files looking up anything is painfully slow. When removed things appear to speed up and nothing seems to be lost. What is it's function? Does removing it cause any problems (that I just haven't noticed yet)? It's for Google's translation tool. I have the same problem and set Firefox to Work Offline under the File menu so that I don't lose time. I agree with you that it must be removed from the locally installed pages. Please enter a bug at http://d.puremagic.com/issues/ On a related note, I use ddoc to generate my Turkish D site as well (ddili.org). My Makefile does automatically remove Google Translate tool for local test access during development. Ali
Re: initializing immutable structs
Thanks for the help. assumeUnique only works on arrays, so it wasn't a solution
for me but it did point me in the right direction.
I'm using a struct that contains a dynamic array as a member of another struct:
-
Struct S {
int a;
int[] b;
}
Struct P {
int c;
S s;
}
-
I was trying to do this:
-
immutable S s1 = { a:234, b: [1] };
immutable P p1 = { c:100, s:s1);
-
This is illegal since s1 is not the same type (immutable S) as the parameter
(mutable S).
But this doesn't work:
-
immutable P p1 = { c:100, s:'some constructor that returns s1');
-
because the constructor is not constant, nor is it CTFE.
What did work:
-
immutable S s1 = { a:234, b: [1] };
immutable P p1 = { c:100, s:cast(S) s1);
-
Casting the immuatable as mutable so it can be assigned to another immutable
variable.
However, having solved the problem, it has been such a hassle to have a mutable
array that I'm looking into changing the design to make the array immutable.
I'm running some timing tests to see what the performance tradeoff is.
Again, thanks
Paul
Simen kjaeraas Wrote:
On Fri, 26 Mar 2010 06:35:29 +0100, Paul D. Anderson
paul.d.removethis.ander...@comcast.andthis.net wrote:
I want to initialize an immutable struct but I'm encountering two
difficulties and I can't find the answer in the documentation. (Wouldn't
it be nice if someone wrote a book?)
You mean like this?
http://www.amazon.com/dp/0321635361
The primary difficulty is that I can't use a static initializer but need
to use a constructor instead. But the constructor isn't allowed as it's
non-constant expression. How do I declare the struct variable and
initialize it separately?
If your constructor is not CTFE-able, you're basically out of luck. The
following kinda works, but will probably not survive optimizations, and is
a horrible hack to break the type system:
struct S {
int n;
this( int n ) {
this.n = n;
}
}
immutable S s = S( 4 );
void main( ) {
void* v = cast( void* )s;
( *cast( S* )v ) = S( 4 );
}
The second difficulty is that when I declare it immutable I get a can't
implicitly convert an expression of type X to to immutable X error. I
tried an explicit cast and that didn't work.
This is indeed correct. D has a three-part const system, with both mutable
and immutable implicitly castable to const, but nothing castable to
immutable or mutable.
Immutable basically means 'will never change'. Hence, assigning something
that can change (mutable) or something that might change (const) to an
immutable variable will not work.
If you have created a mutable or const struct and want to convert it to
immutable, make sure there are no references to it, and use
std.contract's AssumeUnique
http://www.digitalmars.com/d/2.0/phobos/std_contracts.html#assumeUnique
Conversion of POD structs (no pointer or class members) to immutable
should be painless, as they are pure value types and can be safely copied.
I'm reasonably certain that this is a common idiom. I'm just trying to
declare some constants to use later. What am I missing?
Thanks,
Paul
1st Difficulty -- I can't
--
Simen
Re: binary function interception
Trass3r wrote: Just found that wonderful Detours package from Microsoft: http://research.microsoft.com/en-us/projects/detours/ Is there something like this for Linux, maybe even written in/available for D? Not sure. But you can't probably do exciting things like that. Have a look at ptrace http://linux.die.net/man/2/ptrace
[Issue 2609] No documentation generated for destructor
http://d.puremagic.com/issues/show_bug.cgi?id=2609 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-03-29 11:38:07 PDT --- The documentation for those functions should not be part of their interface presented to the user. That's why doc isn't generated for them. It was a deliberate choice, not a bug. I'll mark it as an enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2609] No documentation generated for destructor
http://d.puremagic.com/issues/show_bug.cgi?id=2609 --- Comment #4 from Don clugd...@yahoo.com.au 2010-03-29 13:08:33 PDT --- (In reply to comment #3) The documentation for those functions should not be part of their interface presented to the user. That's why doc isn't generated for them. It was a deliberate choice, not a bug. I'll mark it as an enhancement request. I think that's a reasonable decision, but the spec should state that doc isn't generated for them. Eg, after: If there is no documentation comment for a declaration, that declaration may not appear in the output. To ensure it does appear in the output, put an empty declaration comment for it. + Declarations which are not an explicit part of the interface do not have documentation generated for them. These include: + invariant + postblit + destructor + static constructors and destructors + class info, type info, and module info -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4026] New: Local Documentation access too slow
http://d.puremagic.com/issues/show_bug.cgi?id=4026 Summary: Local Documentation access too slow Product: D Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: charleshi...@earthlink.net --- Comment #0 from Charles Hixson charleshi...@earthlink.net 2010-03-29 14:06:49 PDT --- The line script src=http://www.gmodules.com/ig/ifr?url=http://www.google.com/ig/modules/translatemypage.xml up_source_language=enw=160h=60title=border=output=js/script in most of the documentation files appears to be slowing loading, and not doing anything useful. With it in the files, even using local files looking up anything is painfully slow. When removed things appear to speed up and nothing seems to be lost. AFAIKT removing this from local copies of the documentation is desireable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4027] New: Nested function's bug in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4027
Summary: Nested function's bug in CTFE
Product: D
Version: 2.041
Platform: x86
URL: http://dusers.dip.jp/modules/forum/index.php?topic_id=
59#post_id222
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO zan77...@nifty.com 2010-03-29 14:19:25 PDT ---
(This bug was posted to the Japanese community site. I translate this report.)
This code doesn't work!
---
auto f(string s)
{
return { return s; };
}
void main()
{
static immutable s = f(aaa)();
static assert(s == aaa);// Error: static assert (null == aaa) is false
}
---
The function fails regardless of the argument when execute the following codes
in CTFE:
---
auto f(string s)
{
return { assert(s); };
}
---
You can take the following measures to avoid this problem:
---
auto f(string s)
{
auto _s = s;
return { assert(_s); };
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3987] [gdb] Invalid DWARF output for function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3987 --- Comment #5 from Robert Clipsham rob...@octarineparrot.com 2010-03-29 15:29:47 PDT --- Created an attachment (id=593) Patch for bug 3987 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3987] [gdb] Invalid DWARF output for function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3987 Robert Clipsham rob...@octarineparrot.com changed: What|Removed |Added Keywords||patch --- Comment #6 from Robert Clipsham rob...@octarineparrot.com 2010-03-29 15:30:18 PDT --- I've attached a patch that seems to fix this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250
http://d.puremagic.com/issues/show_bug.cgi?id=1079 --- Comment #19 from Robert Clipsham rob...@octarineparrot.com 2010-03-29 15:43:36 PDT --- Could people having this issue when using -gc try the patch for bug #3987, which seems to fix a lot of issues with gdb. If you are only getting the problem with -g, it is not a bug, you should use -gc until gdb supports the D extensions to dwarf. If it doesn't fix it for you and you can provide a test case, I might be able to fix that issue too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4028] New: delegates with differing default arguments lead to same template instantiation
http://d.puremagic.com/issues/show_bug.cgi?id=4028
Summary: delegates with differing default arguments lead to
same template instantiation
Product: D
Version: 1.057
Platform: Other
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2010-03-29 16:02:30 PDT ---
Look at these two delegates:
void delegate(int x = 123) D_A;
void delegate(int x) D_B;
They have the same type, but they behave differently. E.g. you can call D_A(),
but not D_B().
They lead to the same template instantiation:
void foo(T)(T del) {
}
foo(D_A) and foo(D_B) will be the same template instantiations.
This is a bug, because foo(D_B) will think that del has a default parameter,
which is obviously not the case. dmd should instantiate two different templates
for it. Maybe make delegates with different default args have different types.
Here's a test case, which demonstrates how this can lead to trouble in real
world programs. The code is ripped out from a scripting wrapper, which tries to
support default arguments. (The reason why doMethod is templated on a delegate
and not on the class/method is to drastically reduce the number of template
instantiations.)
import std.stdio;
template ParameterTupleOf( Fn )
{
static if( is( Fn Params == function ) )
alias Params ParameterTupleOf;
else static if( is( Fn Params == delegate ) )
alias ParameterTupleOf!(Params) ParameterTupleOf;
else static if( is( Fn Params == Params* ) )
alias ParameterTupleOf!(Params) ParameterTupleOf;
else
static assert( false, Argument has no parameters. );
}
int requiredArgCount(alias Fn)() {
alias ParameterTupleOf!(typeof(Fn)) Params;
Params p;
static if (is(typeof(Fn(
return 0;
foreach (int idx, x; p) {
static if (is(typeof(Fn(p[0..idx+1]
return idx+1;
}
assert(false);
}
class Foo {
void moo1() {}
void moo2(short x) {}
void moo3(int x = 123) {}
void moo4(int x) {}
}
void doMethod(T)(T del, char[] name, char[] expect) {
writefln(method %s, required arg count: got %s, expected %s, name,
requiredArgCount!(del)(), expect);
}
void method(Class, char[] name)(char[] expect) {
auto fn = mixin(Class. ~ name);
doMethod(fn, name, expect);
}
void main() {
//just to prove that the other code works
method!(Foo, moo1)(0);
method!(Foo, moo2)(1);
//here starts the problem
//moo3 instantiates doMethod!(void delegate(int x = 123))
method!(Foo, moo3)(0);
//moo4 _should_ instantiate doMethod!(void delegate(int x))
//but it really insantiates the same as moo3:
// doMethod!(void delegate(int x = 123))
//this is obviously wrong!
//doMethod() will think that moo4 has a default argument, when it
//really hasn't (you can see that in the runtime output of this program)
method!(Foo, moo4)(1);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3541] Add -oq to dmd (use fully qualified module name as object filename)
http://d.puremagic.com/issues/show_bug.cgi?id=3541 --- Comment #4 from nfx...@gmail.com 2010-03-29 16:17:40 PDT --- What do I have to do to make dmd support -oq ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250
http://d.puremagic.com/issues/show_bug.cgi?id=1079 Ellery Newcomer ellery-newco...@utulsa.edu changed: What|Removed |Added CC||ellery-newco...@utulsa.edu --- Comment #20 from Ellery Newcomer ellery-newco...@utulsa.edu 2010-03-29 16:38:58 PDT --- (In reply to comment #19) Could people having this issue when using -gc try the patch for bug #3987, which seems to fix a lot of issues with gdb. If you are only getting the problem with -g, it is not a bug, you should use -gc until gdb supports the D extensions to dwarf. If it doesn't fix it for you and you can provide a test case, I might be able to fix that issue too. I'm getting a Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x3dbf [in module /home/ellery/dxl/bin/dxl] If you feel like wading through my mongo example, here it is: http://personal.utulsa.edu/~ellery-newcomer/dxl.zip http://personal.utulsa.edu/~ellery-newcomer/dmdz.d http://personal.utulsa.edu/~ellery-newcomer/test1.xls build dmdz, then use it to build dxl.zip, then run dxl/bin/dxl test1.xls out.xls Oh, and you need to checkout dmd v1 from repo, as dxl.zip requires changeset 420 to compile. That or fiddle with dxl/read/biff/BOFRecord.d; I think there's only one line of code that needs to be messed with. There, I didn't make it too easy for you, did I? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250
http://d.puremagic.com/issues/show_bug.cgi?id=1079 --- Comment #21 from Robert Clipsham rob...@octarineparrot.com 2010-03-29 16:44:08 PDT --- I'm working on another patch now, another project had a similar issue, which is fixed with my new (incomplete) patch. I'll let you know when I've uploaded it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3987] [gdb] Invalid DWARF output for function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3987 Robert Clipsham rob...@octarineparrot.com changed: What|Removed |Added Keywords|patch | --- Comment #7 from Robert Clipsham rob...@octarineparrot.com 2010-03-30 02:03:55 BST --- The patch I created works for a selection of cases, and fixes the bug mentioned in the bug report, however there are a lot of extremely related issues which it doesn't fix. I've written a preliminary patch which does fix the other issues, unfortunately it causes the debug info output to be incorrect, so it needs more work. The current patch removes the DW_AT_type from the pointer, but to function properly it should remove the DW_AT_type from the function. This is rather difficult to do, as the function does not know its parent type, so cannot know if it is a function pointer and therefore needs to leave out the DW_AT_type. The current patch I'm working on adds another argument to dwarf_typidx() to specify it, it seems a bit hacky though. If anyone has a better idea of how to check if the function's parent type is a pointer, please let me know :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4009] OPTLINK ruins the day yet again
http://d.puremagic.com/issues/show_bug.cgi?id=4009 --- Comment #1 from nfx...@gmail.com 2010-03-29 18:18:20 PDT --- Funny thing: if I name _exactly_ the same file x2.d, OPTLINK doesn't crash! copy x.d x2.d dmd x.d -g -- OPTLINK crashes dmd x2.d -g -- OPTLINK doesn't crash Let me repeat: this bug is not reproduceable if you change the filename. Makes me wonder what the flying fuck is going on. (Maybe I should mention that I did this under wine on Linux, but I also had someone reproduce the crash on a real Windows.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3911] Associative array in CTFE crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=3911
--- Comment #1 from Don clugd...@yahoo.com.au 2010-03-29 21:04:14 PDT ---
This fixes the ICE:
expression.c line 7181.
if (!type)
{
error(forward reference to inferred return type of function call %s,
toChars());
type = Type::terror;
+return new ErrorExp();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4012] [CTFE][ICE] auto template function, forward reference error
http://d.puremagic.com/issues/show_bug.cgi?id=4012 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Don clugd...@yahoo.com.au 2010-03-29 21:05:56 PDT --- *** This issue has been marked as a duplicate of issue 3911 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3911] Associative array in CTFE crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=3911 --- Comment #2 from Don clugd...@yahoo.com.au 2010-03-29 21:05:56 PDT --- *** Issue 4012 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
