Re: dmd 1.048 and 2.033 releases
MIURA Masahiro wrote: Uncomment the line 6, and gdb is now unable to list code: Please post to bugzilla.
Re: dmd 1.048 and 2.033 releases
Walter Bright wrote: Please post to bugzilla. Done! http://d.puremagic.com/issues/show_bug.cgi?id=3368
Re: dmd 1.048 and 2.033 releases
Nick Sabalausky wrote: Nick Sabalausky a...@a.a wrote in message news:hadst9$58...@digitalmars.com... Walter Bright newshou...@digitalmars.com wrote in message news:hadqcs$30n...@digitalmars.com... BCS wrote: Hello Walter, #ponce wrote: I think it's disabled in debug mode to keep the compilation time low. That, and the optimizer tends to scramble the relationship between source and assembler, making source debugging next to impossible. How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file? It seems even easier to just compile with -0. It isn't. *Very* typical workflow: [stuff] None of those are particularly good options, and I don't see any other possibilities. ...Plus it's just plain unintuitive. It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them.
Re: DMD svn and contract inheritance
Robert Clipsham wrote: Leandro Lucarella wrote: Thanks for finally taking this way, Walter =) http://www.dsource.org/projects/dmd/timeline Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for Nightly builds and maybe even post the results to the D newsgroups/IRC channels. If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you. I think that'd be fantastic. It'd be helpful if you could at least get dstress to run after the main releases. The dstress test page from LDC doesn't seem to operate any more. http://www.incasoftware.de/~kamm/ldc/tests/index.html I'd really like to see the results for the latest DMD, almost all of the ERROR (segfault/ICE) bugs should be fixed now. Walter doesn't necessarily ever have to look at it, but it'd be good as a pre-release check. There are quite a few incorrect dstress tests. I've been making tickets for them as I find them.
Re: dmd 1.048 and 2.033 releases
Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround.
Re: DMD svn and contract inheritance
Walter Bright wrote: Jason House wrote: With small commits to dmd, it should be trivial to know what small change in dmd caused a user observable change in behavior. The problem is, one doesn't know if it is a problem with the change or if it is a problem with the user code. To determine that requires working with and understanding the user code. It's just impractical for me to do that with a large base of code like that. But you don't have to take the stance that no regressions may occur (for this very reason). I think automated builds + tests can be useful in different ways: - the authors of the code can be notified and look at the problem. Some will care and help you spot bugs earlier or may fix their own code earlier. This is at no cost to you. Eventually, this task can perhaps be delegated completely? - when a lot of stuff breaks, it is an indicator at least. - while you may need a lot of investment to determine all problems, at least some category of problems you may recognize quickly.
Re: dmd 1.048 and 2.033 releases
Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance.
Re: dmd 1.048 and 2.033 releases
Stewart Gordon Wrote: What is @ going to be used for generally? (What is the essential difference between an attribute that's an @word and one that's a simple keyword before or after the type?) Annotations can be user-defined and can contain data.
Re: DMD svn and contract inheritance
Don wrote: I think that'd be fantastic. It'd be helpful if you could at least get dstress to run after the main releases. The dstress test page from LDC doesn't seem to operate any more. http://www.incasoftware.de/~kamm/ldc/tests/index.html This page gets updated manually by Christian as he feels fit. For more up to date pages, see: http://ldc.octarineparrot.com/x86-32/web/ http://ldc.octarineparrot.com/x86-64/web/ For x86-32 and x86-64 respectively (these aren't completely automated yet, they require me to run a command to generate them every now and again... I'll sort this out when I get it set up for dmd). They still compare to dmd 1.045 as ldc still uses the 1.045 front end (I believe there were some regressions from 1.046+, not sure on the current status of this). I'd really like to see the results for the latest DMD, almost all of the ERROR (segfault/ICE) bugs should be fixed now. This will get run when I set it up :) Walter doesn't necessarily ever have to look at it, but it'd be good as a pre-release check. Agreed. There are quite a few incorrect dstress tests. I've been making tickets for them as I find them. I believe Christian is the maintainer for the dstress project on dsource, he should be able to give you commit access if you have patches.
Re: DMD svn and contract inheritance
Walter Bright wrote: Then please go ahead and set it up. What exactly would you like setting up? Currently I'm thinking: * Automated builds of dmd 1 and 2 * Automated builds of druntime, phobos and tango * Automated DStress runs * Automated dmd test suite runs (if you're willing to provide me access to the test suite) * Automated builds of more popular projects from dsource (with permission from the maintainers obviously) Is there anything else you want? I also need to know how you would like results to be reported. Would you like them to sit on a web page with an RSS feed, email the results to a specified list of email addresses, post to the nextgroups, post to IRC?
Re: dmd 1.048 and 2.033 releases
Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O
Re: DMD svn and contract inheritance
Robert Clipsham wrote: Walter Bright wrote: Then please go ahead and set it up. What exactly would you like setting up? Currently I'm thinking: * Automated builds of dmd 1 and 2 * Automated builds of druntime, phobos and tango * Automated DStress runs * Automated dmd test suite runs (if you're willing to provide me access to the test suite) * Automated builds of more popular projects from dsource (with permission from the maintainers obviously) Is there anything else you want? I also need to know how you would like results to be reported. Would you like them to sit on a web page with an RSS feed, email the results to a specified list of email addresses, post to the nextgroups, post to IRC? I suggest setting it up to email the maintainers of the packages being compiled any problems with compiling them.
Re: dmd 1.048 and 2.033 releases
On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger.
Re: dmd 1.048 and 2.033 releases
Jarrett Billingsley wrote: On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger. As I understand, -0 just enables flow analysis (which is slow and thus shouldn't be run normally), not full optimization.
Re: dmd 1.048 and 2.033 releases
On Wed, 07 Oct 2009 00:54:22 +0400, grauzone n...@example.net wrote: Jarrett Billingsley wrote: On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger. As I understand, -0 just enables flow analysis (which is slow and thus shouldn't be run normally), not full optimization. No, -O means optimize. It's just much easier to check code flow when an executable is optimized, that's it.
Re: dmd 1.048 and 2.033 releases
Denis Koroskin wrote: On Wed, 07 Oct 2009 00:54:22 +0400, grauzone n...@example.net wrote: Jarrett Billingsley wrote: On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger. As I understand, -0 just enables flow analysis (which is slow and thus shouldn't be run normally), not full optimization. No, -O means optimize. It's just much easier to check code flow when an executable is optimized, that's it. And I thought it was a zero... never mind, then.
Re: dmd 1.048 and 2.033 releases
Walter Bright: The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. On GCC if you want a safer compilation you add things like -Wall -Wextra, etc. In D the default is better to be safe (just like you add -release to remove some safeties), so with flow analysis activated. If someone needs a faster but less safe compilation, then such person may add a flag to disable flow analysis, like -noflow. Bye, bearophile
Re: dmd 1.048 and 2.033 releases
Walter Bright Wrote: Jason House wrote: Which gdb should this release work with? I seem to have misplaced my patched gdb. The standard gdb 6.8 can show backtraces but can't list code, even if the code is linked in libraries from C++. If you're using the standard gdb, try compiling with -gc. I'm using whatever gdb came with Ubuntu. My mini dmd test omitted that... Oops It turns out the issue with my larger project was that g++ -g -O3 generates really, really bad debug info. So bad that it's practically unusable. Removing -O3 did wonders...
Re: Multiple subtyping with alias this and nested classes
Yigal Chripun wrote: On 06/10/2009 02:15, Andrei Alexandrescu wrote: Yigal Chripun wrote: I think 'alias this' is a powerful feature. Given the constraints like easy for the compiler writer to implement and we have many other things to do, I doubt traits or something like that will be or needs to be in the language. Alias this is powerful black magic. being powerful doesn't make it any less dark. So how does this work? Alias this was meant very clearly for allowing subtyping. Conversely, using it for subtyping is precisely how it was meant to be used. How exactly did you decide it was a hack or black magic or whatever? Andrei D already has syntax for sub-typing reference types and alias this introduces a completely different syntax doing the same for value types which is bad human interface IMO. Inheritance is a bit more than just subtyping, for example it entails the prefix property (otherwise it wouldn't be very practical). That's why D only allows single inheritance of state; multiple inheritance of state causes more problems than it solves. That's also why alias this is a very flexible complement to inheritance - it offers subtyping without requiring the prefix property and leaves layout to the discretion of the user. it also mixes two concepts - sub-typing and opImplicitCast (as i recall, this is done by alias this to a function) opImplicitCast hasn't been implemented and probably alias this will render it unnecessary. I don't see a dangerous conflation. we discussed this in the past already and IIRC you agreed with me about implementing compile time inheritance for structs which I feel is much cleaner and more consistent with the existing syntax of interfaces. Maybe there's a misunderstanding. Inheritance of interfaces for structs (which is different from what alias this helps with) was something that Walter and I considered interesting to pursue for simplifying concept checking. However, recent developments clarified that that's not enough (I even deleted the related enhancement requests from bugzilla). Currently I'm considering a reflection-based concept checking, but it's too crude an idea to discuss it at the moment. Andrei
Re: Multiple subtyping with alias this and nested classes
On Tue, 06 Oct 2009 00:52:42 +0200, Yigal Chripun yigal...@gmail.com
wrote:
I see you want to discuss the details of the renaming mechanism, while I
just talked about the general idea itself until now.
Yes, I understand the idea and am trying to imagine it in the context
of D.
we have two cases: regular and mixins.
for case a it's simple, the class itself lists the renames:
Interface A {
void foo();
}
Interface B {
void foo();
}
class C : A, B {
alias A.foo func1; // or similar syntax to mark the renaming
alias B.foo func2; // ditto
override void func1() {...} // C.func1 overrides A.foo
override void func2() {...} // C.func2 overrides B.foo
}
Ok, that looks good.
case 2, mixins:
I think some sort of annotations by the programmer is needed.
class C : A, B {
alias A.foo func1; // or similar syntax to mark the renaming
alias B.foo func2; // ditto
// hypothetical syntax to connect mixins to interfaces
// the compiler will apply the rename rules of this class assuming that
// any references to foo in ImplA are A.foo and will be renamed to
// func1 in C
// if the mixin explicitly specifies the interface (e.g B.foo) than the
// compiler already knows what to map this to.
mixin ImplA A;
mixin ImplB B;
}
This exact syntax won't work but I see your point.
btw, this all can be done in a much simpler way with (hygienic) AST Macros.
Sadly (or for the better), we are not going to have macros in the near
future.
I don't think I want non virtual MI in D since it is more trouble than it's
worth. but *if* we discuss this, I think my suggested semantics are
simpler. The syntax probably can be much better but that's a secondary
issue IMO.
It's unrelated to virtual MI. See Sergey Gromov's post. We are
discussing this only because it's a real world problem that has no
decent solution in D.
I said *non* virtual MI above..
But virtual inheritance is C++'s way to resolve the diamond problem. I
don't think it is related to our discussion in any way.
This gets more and more complicated - Like I said before, I feel that
renaming has easier to understand semantics.
As an exercise, I'm working on a mixin that will allow to subtype a
class and rename/override its virtual functions like this:
class FlippingBlipper
{
mixin Subclass!(Flipper,
nameCollision, foo) flipper;
this() { flipper.construct(...); }
void foo() { ... }
}
Save for some bugs in the compiler, it should work reasonably well. Or
maybe not.
I think 'alias this' is a powerful feature.
Given the constraints like easy for the compiler writer to implement
and we have many other things to do, I doubt traits or something
like that will be or needs to be in the language.
Alias this is powerful black magic. being powerful doesn't make it any
less dark.
Could you explain why it is dark?
Re: I wrote some D today and it's completely blowing my mind. Ever
downs Wrote: Don't know why you bother with Reddit, Walter. Going by a lot of the replies there, its a case of pearls before swine. Cheers -- Justin Johansson Swine are smart. Indeed. I like this comment: Of course, but they'll have to look at the function signature to see that. If you're reading code to find a bug, it won't be immediately obvious what's going on. In the worst case you'll need to recursively inspect all function signatures used by each function. One of Walter's goals was to make certain classes of bugs more difficult to occur -- a laudable one. Unfortunately this feature makes things harder to reason about.
Re: I wrote some D today and it's completely blowing my mind. Ever
Lazy arguments are half-lambdas.
void some_function(int x, lazy int y);
void some_function(int x, int delegate() y);
some_function(x, y++);
some_function(x, (){ y++ });
Though typesavers will complain a lot.
Re: I wrote some D today and it's completely blowing my mind. Ever
Kagamin Wrote:
Lazy arguments are half-lambdas.
void some_function(int x, lazy int y);
void some_function(int x, int delegate() y);
some_function(x, y++);
some_function(x, (){ y++ });
Though typesavers will complain a lot.
Often when the Marxes arrived at restaurants, there would be a long wait for a
table.
Just tell the maître d' who we are, his wife would nag.
(In his pre-moustache days, he was rarely recognized in public.)
Groucho would say, OK, OK. Good evening, sir.
My name is Jones. This is Mrs. Jones, and here are all the little Joneses.
Now his wife would be furious and insist that he tell the maître d' the truth.
Oh, all right, said Groucho. My name is Smith. This is Mrs. Smith, and here
are all the little Smiths.
smallAbove quotation from http://en.wikipedia.org/wiki/Groucho_Marx and
reproduced here under Creative Commons Attribution-ShareAlike 3.0 Unported
License
http://creativecommons.org/licenses/by-sa/3.0//small
JJ/
Re: I wrote some D today and it's completely blowing my mind. Ever
Walter Bright Wrote: digited wrote: Walter Bright Wrote: D isn't meant as a language to enlighten people, it isn't a religion, it's a language meant to get things done with. Amen that holy true! All hail D! o_O now THAT is a provocation!
misaligned read handling on various processors
Consider:
struct A {
char a;
align(1) int b;
}
Accesses to b will be rather slow because it's a misaligned read. My
question is, how exactly is that handled on various processors? I seem
to recall various anecdotes (including that misaligned reads on Intel
cause a trap that does the needed double reading, shifting, and
masking), but Google search has surprisingly little on the matter.
Thanks,
Andrei
Re: misaligned read handling on various processors
Andrei Alexandrescu wrote:
Consider:
struct A {
char a;
align(1) int b;
}
Accesses to b will be rather slow because it's a misaligned read. My
question is, how exactly is that handled on various processors? I seem
to recall various anecdotes (including that misaligned reads on Intel
cause a trap that does the needed double reading, shifting, and
masking), but Google search has surprisingly little on the matter.
Not on Intel. IIRC the trapping happens on Sparc. Misalignment on x86
doesn't hurt much at all, except for doubles and reals.
For the case you mention there'll probably be no misalignment penalty at
all, the latency gets hidden in the early stages of the pipeline.
Although there may be a penalty if you cross a cache line boundary.
Re: misaligned read handling on various processors
Don wrote:
Andrei Alexandrescu wrote:
Consider:
struct A {
char a;
align(1) int b;
}
Accesses to b will be rather slow because it's a misaligned read. My
question is, how exactly is that handled on various processors? I seem
to recall various anecdotes (including that misaligned reads on Intel
cause a trap that does the needed double reading, shifting, and
masking), but Google search has surprisingly little on the matter.
Not on Intel. IIRC the trapping happens on Sparc. Misalignment on x86
doesn't hurt much at all, except for doubles and reals.
For the case you mention there'll probably be no misalignment penalty at
all, the latency gets hidden in the early stages of the pipeline.
Although there may be a penalty if you cross a cache line boundary.
Thanks! Are there some online docs that discuss that in detail?
Andrei
Eliminate class allocators and deallocators?
Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. What do you think? Andrei
Re: Eliminate class allocators and deallocators?
On Tue, Oct 6, 2009 at 12:01 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. ..How? Without a custom allocator to do even a simple placement new, how would you handle such a thing in the library?
Re: Eliminate class allocators and deallocators?
On Tue, 06 Oct 2009 20:01:01 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. What do you think? Andrei I think it's okay, but I have a few points to discuss: - Is it worth a keyword (delete) just as a shortcut for obj.__dtor();? - I believe __ctor and __dtor (and __traits, too) are ugly reserved identifiers. - It's often useful to distinguish between dtor being called by user and a dtor being called by a GC. In the latter case you can't dereference any reference since they might be invalid. - How about object.d provides an IDisposable (or something like this) interface which defines a void dispose(bool finalizing); and we get rid of ~this/__dtor entirely? - obj.__ctor() is mostly used as a placement new. A new placement new mechanism would allow drop that identifier, too. - D has 2 placement new mechanisms for a struct, that are absolutely the same (but different in syntax): Foo foo1 = void; Foo foo2 = void; foo1 = Foo(); // indirect foo2.__ctor();// direct The latter one could also be used for class initialization, but not the former one. You once announced an idea of dropping the 'new' keyword altogether and make the former case also valid for classes. What's about it now? - Could you elaborate on a much better way to handle custom allocation of classes ... in the standard library? An example would be very appreciated.
Re: Eliminate class allocators and deallocators?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. What do you think? Andrei Please give at least a little more detail. I think it's an absolute must that advanced users who really want to do manual memory management in D (even if they want to only do it selectively and without kludges like using two completely separate heaps) be able to do so. I can't really comment until I know at least roughly what a standard lib solution might look like.
D marketplace
I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed?
Re: D marketplace
Walter Bright Wrote: Is this something needed? At the moment I don't see a lot of business D-related. But if you build it they may come, maybe slowly (in a year or two). If in a couple years from now you see that newsgroup keeps being dead, you can delete it. So I don't see harm in trying. Bye, bearophile
Re: misaligned read handling on various processors
== Quote from Don (nos...@nospam.com)'s article
Andrei Alexandrescu wrote:
Consider:
struct A {
char a;
align(1) int b;
}
Accesses to b will be rather slow because it's a misaligned read. My
question is, how exactly is that handled on various processors? I seem
to recall various anecdotes (including that misaligned reads on Intel
cause a trap that does the needed double reading, shifting, and
masking), but Google search has surprisingly little on the matter.
Not on Intel. IIRC the trapping happens on Sparc. Misalignment on x86
doesn't hurt much at all, except for doubles and reals.
For the case you mention there'll probably be no misalignment penalty at
all, the latency gets hidden in the early stages of the pipeline.
Although there may be a penalty if you cross a cache line boundary.
By default, an unaligned read on SPARC will cause a bus error. The trap is
enabled via a compiler switch, and as one might expect is ridiculously slow.
I believe unaligned ops are nearly as fast as aligned ops on x86, as you say.
Re: D marketplace
Walter Bright newshou...@digitalmars.com wrote in message news:hag41h$21l...@digitalmars.com... I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? Isn't that what basically what D.announcements is?
Re: D marketplace
Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hag41h$21l...@digitalmars.com... I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? Isn't that what basically what D.announcements is? There's some overlap, but I think they serve entirely different purposes. D.announce is for any announcements of interest to D programmers, D.marketplace is for commercial things - products and services to buy and sell. Think of it like the 'classified' section of the newspaper.
Re: D marketplace
== Quote from Walter Bright (newshou...@digitalmars.com)'s article I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? Can't hurt. Part of what holds D back is that its community is so diffuse, since it doesn't have a real niche yet that concentrates a lot of users. These forums are about the only place other than random coffee shops in Seattle where you hear much about D on the technical side. Hopefully a D.marketplace newsgroup would do the same thing on the $$ side.
Re: D marketplace
dsimcha wrote: Can't hurt. Part of what holds D back is that its community is so diffuse, since it doesn't have a real niche yet that concentrates a lot of users. These forums are about the only place other than random coffee shops in Seattle where you hear much about D on the technical side. Hopefully a D.marketplace newsgroup would do the same thing on the $$ side. I think it's important to encourage the commercial side of D. It can only help.
Re: D marketplace
On 2009-10-06 14:58:59 -0400, Walter Bright newshou...@digitalmars.com said: I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? Looks like an excellent idea. Someone contacted me for something Mac and D-related a little while ago. I got found from a Google search that found my Mac oriented D projects on my website. I guess having a newsgroup for this can only help. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Eliminate class allocators and deallocators?
What exactly is your suggestion? It seems that you mean that: delete obj; should call a destructor but not call delete() or notify the GC that the memory is free. You're saying that there is a problem, but you're not telling us what's wrong. Why the hell do you want to destroy an object without recycling its memory? Why does the inability to do so cause a problem? It seems like a performance hack to me -- you've got an object that isn't valid anymore, but you want to hang on to the memory for some other purpose. And you could override new() and delete(), but you don't want to incur the performance penalty of calling the runtime to fetch the deallocator. The only remaining use that I see is a way to reset a shared object without explicitly passing around a reference to the new version of the object. This seems potentially dangerous, and nothing I want for default behavior.
Re: misaligned read handling on various processors
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:hafmb2$15l...@digitalmars.com...
Don wrote:
Andrei Alexandrescu wrote:
Consider:
struct A {
char a;
align(1) int b;
}
Accesses to b will be rather slow because it's a misaligned read. My
question is, how exactly is that handled on various processors? I seem
to recall various anecdotes (including that misaligned reads on Intel
cause a trap that does the needed double reading, shifting, and
masking), but Google search has surprisingly little on the matter.
Not on Intel. IIRC the trapping happens on Sparc. Misalignment on x86
doesn't hurt much at all, except for doubles and reals.
For the case you mention there'll probably be no misalignment penalty at
all, the latency gets hidden in the early stages of the pipeline.
Although there may be a penalty if you cross a cache line boundary.
Thanks! Are there some online docs that discuss that in detail?
http://www.intel.com/products/processor/manuals/
Check the optimization manual at the bottom. Chapter 3.6.3
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF
chapter 5.2
http://www.agner.org/optimize/optimizing_assembly.pdf
chapter : optimizing memory access
Re: Eliminate class allocators and deallocators?
Christopher Wright wrote: What exactly is your suggestion? It seems that you mean that: delete obj; should call a destructor but not call delete() or notify the GC that the memory is free. That is correct. In particular, an object remains usable after delete. You're saying that there is a problem, but you're not telling us what's wrong. Why the hell do you want to destroy an object without recycling its memory? Why does the inability to do so cause a problem? The matter has been discussed quite a bit around here and in other places. I'm not having as much time as I'd want to explain things. In short, destroying without freeing memory avoids dangling references and preserves memory safety without impacting on other resources. It seems like a performance hack to me -- you've got an object that isn't valid anymore, but you want to hang on to the memory for some other purpose. And you could override new() and delete(), but you don't want to incur the performance penalty of calling the runtime to fetch the deallocator. It's a safety hack, not a performance hack. The only remaining use that I see is a way to reset a shared object without explicitly passing around a reference to the new version of the object. This seems potentially dangerous, and nothing I want for default behavior. Well incidentally at least as of now delete obj puts null in obj... Andrei
Re: Eliminate class allocators and deallocators?
Andrei Alexandrescu, el 6 de octubre a las 11:01 me escribiste: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. I don't think it is a good idea (GC-wise) to say that in the specs. I think the GC implementor should be free to decide if a delete really free the memory or not. Some collectors can do this very naturally (like the current one) and some others don't (like allocators that uses pointer-bump allocation). I think the language should divide destruction and deallocation, but I don't think is a good idea not to notify the GC at all when delete is used. I think the GC should be able to do whatever it feels is good for him (so the user should not rely either on the memory being actually freed or otherwise). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- If you don't know what direction you should take You don't know where you are
Re: Eliminate class allocators and deallocators?
Andrei Alexandrescu, el 6 de octubre a las 19:26 me escribiste: Christopher Wright wrote: What exactly is your suggestion? It seems that you mean that: delete obj; should call a destructor but not call delete() or notify the GC that the memory is free. That is correct. In particular, an object remains usable after delete. Why would you do that? What is the rationale to not notify the GC? You're saying that there is a problem, but you're not telling us what's wrong. Why the hell do you want to destroy an object without recycling its memory? Why does the inability to do so cause a problem? The matter has been discussed quite a bit around here and in other places. I'm not having as much time as I'd want to explain things. In short, destroying without freeing memory avoids dangling references and preserves memory safety without impacting on other resources. But D is a system programming language. If you wrote delete x; the language should assume you know what you're doing. If you only want to deinitialize an object, you can write a .destroy() method for example, and call that. I think delete have a strong established semantic to change it now, and without any gain. It seems like a performance hack to me -- you've got an object that isn't valid anymore, but you want to hang on to the memory for some other purpose. And you could override new() and delete(), but you don't want to incur the performance penalty of calling the runtime to fetch the deallocator. It's a safety hack, not a performance hack. But you shouldn't provide safety where the programmer is not expecting it. delete is for *manual* memory management. It makes no sense to guarantee that the memory is *not* freed. It makes sense not guaranteeing that it will actually be freed either. I think that's a good idea actually, because it gives more flexibility to the GC implementation. The only remaining use that I see is a way to reset a shared object without explicitly passing around a reference to the new version of the object. This seems potentially dangerous, and nothing I want for default behavior. Well incidentally at least as of now delete obj puts null in obj... That's nice :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Never let a fool kiss you, or let a kiss fool you
Re: Eliminate class allocators and deallocators?
Leandro Lucarella wrote: Andrei Alexandrescu, el 6 de octubre a las 11:01 me escribiste: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. I don't think it is a good idea (GC-wise) to say that in the specs. I think the GC implementor should be free to decide if a delete really free the memory or not. Some collectors can do this very naturally (like the current one) and some others don't (like allocators that uses pointer-bump allocation). I think the language should divide destruction and deallocation, but I don't think is a good idea not to notify the GC at all when delete is used. I think the GC should be able to do whatever it feels is good for him (so the user should not rely either on the memory being actually freed or otherwise). I agree insofar as a GC could be tipped by the compiler that no live reference of the object exists after delete. Andrei
Re: Eliminate class allocators and deallocators?
Leandro Lucarella wrote: Andrei Alexandrescu, el 6 de octubre a las 19:26 me escribiste: Christopher Wright wrote: What exactly is your suggestion? It seems that you mean that: delete obj; should call a destructor but not call delete() or notify the GC that the memory is free. That is correct. In particular, an object remains usable after delete. Why would you do that? What is the rationale to not notify the GC? Because there may be other live references to the object. You're saying that there is a problem, but you're not telling us what's wrong. Why the hell do you want to destroy an object without recycling its memory? Why does the inability to do so cause a problem? The matter has been discussed quite a bit around here and in other places. I'm not having as much time as I'd want to explain things. In short, destroying without freeing memory avoids dangling references and preserves memory safety without impacting on other resources. But D is a system programming language. Well it is but there are quite a few more things at stake. First, it is a reality that it is often desirable to distinguish between calling the destructor and reclaiming memory. D's current delete continues the bad tradition started by C++ of conflating the two. If you wrote delete x; the language should assume you know what you're doing. I think delete should be present in SafeD and if you want manual memory management you should build on malloc and free. If you only want to deinitialize an object, you can write a .destroy() method for example, and call that. I think delete have a strong established semantic to change it now, and without any gain. It has a thoroughly broken and undesired semantics. It would be a step forward to divorce it of that. In fact i'd love to simply make delete disappear as a keyword and make it a function. It seems like a performance hack to me -- you've got an object that isn't valid anymore, but you want to hang on to the memory for some other purpose. And you could override new() and delete(), but you don't want to incur the performance penalty of calling the runtime to fetch the deallocator. It's a safety hack, not a performance hack. But you shouldn't provide safety where the programmer is not expecting it. delete is for *manual* memory management. It makes no sense to guarantee that the memory is *not* freed. It makes sense not guaranteeing that it will actually be freed either. I think that's a good idea actually, because it gives more flexibility to the GC implementation. I think we should move away from the idea that delete is for manual memory management. We should leave that to the likes of malloc and free alone. The only remaining use that I see is a way to reset a shared object without explicitly passing around a reference to the new version of the object. This seems potentially dangerous, and nothing I want for default behavior. Well incidentally at least as of now delete obj puts null in obj... That's nice :) I think it's a false sense of security. C++ beginners keep on suggesting that feature and C++ pundits keep on explaining them that it's ungainful. Andrei
Re: Eliminate class allocators and deallocators?
Andrei Alexandrescu, el 6 de octubre a las 21:36 me escribiste: I don't think it is a good idea (GC-wise) to say that in the specs. I think the GC implementor should be free to decide if a delete really free the memory or not. Some collectors can do this very naturally (like the current one) and some others don't (like allocators that uses pointer-bump allocation). I think the language should divide destruction and deallocation, but I don't think is a good idea not to notify the GC at all when delete is used. I think the GC should be able to do whatever it feels is good for him (so the user should not rely either on the memory being actually freed or otherwise). I agree insofar as a GC could be tipped by the compiler that no live reference of the object exists after delete. Great! For example, this would let me protect the object pages (if it's a large object that uses one or more full pages) when they are freed so the program segfaults as soon as a deleted object is used when it shouldn't. That could be a nice debugging feature :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hey you, with you ear against the wall Waiting for someone to call out Would you touch me?
Re: D marketplace
Walter Bright wrote: There's some overlap, but I think they serve entirely different purposes. D.announce is for any announcements of interest to D programmers, D.marketplace is for commercial things - products and services to buy and sell. Think of it like the 'classified' section of the newspaper. Overlap is what causes categories to loose there importance. The categories should clearly draw the line in either definition, quantity of content, or both. Currently we have D for all kinds of things: D language. Dmd compiler. Ideas. Blog posts. Announcements has such low traffic that a split is not really necessary at the moment. The newsgroups could possibly be restructured though for example: D lang. (language spec proposals) D compilers. (dmd, gdc, ldc others) D dev tools. (debugger, ide others) D gui tool kit. (or maybe all non standard libraries?). D bugs. D annoucements. D standard libs (old dtl + phobos tango talk). D OT (the kind of coffee lounge. must remain of interest to d programmers. for example: the sort of posts berophile finds on the development of other languages). I don't know anything of the implementation of news groups. Is it at all easy to just move posts in the same way as can be done through a web message board forum?
Re: D marketplace
Tim Matthews wrote: I don't know anything of the implementation of news groups. Is it at all easy to just move posts in the same way as can be done through a web message board forum? It would be very hard to move them.
Re: D marketplace
On 10/6/09 12:58 PM, Walter Bright wrote: I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? What about something a little more than a news group? I'd be willing to offer up some development time.
Re: D marketplace
Stanley Steel wrote: On 10/6/09 12:58 PM, Walter Bright wrote: I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? What about something a little more than a news group? I'd be willing to offer up some development time. I thought a n.g. would be easy to manage, and we can see how things go with it before spending a lot of effort.
Re: D marketplace
On 10/6/09 11:01 PM, Walter Bright wrote: Stanley Steel wrote: On 10/6/09 12:58 PM, Walter Bright wrote: I'm considering setting up another D newsgroup called D.marketplace. In it, you can essentially post advertisements for your D products, hang out a shingle offering your D consulting services, post want ads for D programmers, anything business oriented that's related to D. Is this something needed? What about something a little more than a news group? I'd be willing to offer up some development time. I thought a n.g. would be easy to manage, and we can see how things go with it before spending a lot of effort. Sounds good. If you change you mind, let me know.
Re: Eliminate class allocators and deallocators?
Andrei Alexandrescu wrote: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. What do you think? Andrei Do you trust the D GC to be good enough to always free everything you've allocated, without error? If your answer was 'ye- maaybe ... no actually', please rethink this.
Re: Eliminate class allocators and deallocators?
downs wrote: Andrei Alexandrescu wrote: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. What do you think? Andrei Do you trust the D GC to be good enough to always free everything you've allocated, without error? If your answer was 'ye- maaybe ... no actually', please rethink this. People will always be able to call functions in the garbage collector manually. The discussion on class allocators and deallocators has nothing to do with that. Andrei
Re: Eliminate class allocators and deallocators?
Andrei Alexandrescu wrote: downs wrote: Andrei Alexandrescu wrote: Hello, D currently allows defining class allocators and deallocators. They have a number of problems that make them unsuitable for D 2.0. The most obvious issue is that D 2.0 will _not_ conflate destruction with deallocation anymore: invoking delete against an object will call ~this() against it but will not recycle its memory. In contrast, class deallocators are designed around the idea that invoking delete calls the destructor and also deallocates memory. So I'm thinking of removing at least class deallocators from the language. Class allocators may be marginally and occasionally useful if the user takes the matter of deallocation in her own hands. A much better way to handle custom allocation of classes would be in the standard library. What do you think? Andrei Do you trust the D GC to be good enough to always free everything you've allocated, without error? If your answer was 'ye- maaybe ... no actually', please rethink this. People will always be able to call functions in the garbage collector manually. The discussion on class allocators and deallocators has nothing to do with that. Andrei So you can still deallocate a class by hand, only it's not called delete anymore?
Changing the preferred imagebase (dmd)?
Is it possible to change the created exe's imagebase with dmd?
Re: Using OpenGL (custom port)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Butler wrote: Is there a difference between a pointer to a D array and an int* in C? How do I convert between the two? Am I even looking in the right place? Thanks for any help! -Dave Butler There's nothing wrong with your int array. What's GetLastError tell you? According to the spec you can just pass null as the attrs anyway to get a default, try that. Only other thing I can suggest is maybe you've got the calling convention of PFNWGLCREATECONTEXTATTRIBSARBPROC wrong. But you only need to declare it in an extern (windows) block. Just out of curiosity where did you get the c headers for opengl 3? My card doesn't support it unfortunately so I've not bothered getting hold of it so far. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKy4fbT9LetA9XoXwRAkUiAKCi/APnNEJDDVYx0jv6vyo03ji86wCfTXns Sa178i0Ry3U+tD1o2awy8d8= =t3Cb -END PGP SIGNATURE-
Re: Using OpenGL (custom port)
I got it working, it did turn out to be a slight error in the type declaration. I had this: typedef HGLRC function (HDC hDC, HGLRC hShareContext, in int *attribList) PFNWGLCREATECONTEXTATTRIBSARBPROC; And it needed to be: typedef extern (Windows) ...everything else... Whoops. But I can now successfully create a 3.0 context. Yay! You can get the latest extension headers for OpenGL from http://www.opengl.org/registry/#headers (glext.h, wglext.h, glxext.h). You should only need two of them, depending on the platform (I think) and just use the standard, old-timey gl.h from your system. glext.h is huge, but pretty easy to convert if you have a regex search/replace tool. div0 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Butler wrote: Is there a difference between a pointer to a D array and an int* in C? How do I convert between the two? Am I even looking in the right place? Thanks for any help! -Dave Butler There's nothing wrong with your int array. What's GetLastError tell you? According to the spec you can just pass null as the attrs anyway to get a default, try that. Only other thing I can suggest is maybe you've got the calling convention of PFNWGLCREATECONTEXTATTRIBSARBPROC wrong. But you only need to declare it in an extern (windows) block. Just out of curiosity where did you get the c headers for opengl 3? My card doesn't support it unfortunately so I've not bothered getting hold of it so far. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKy4fbT9LetA9XoXwRAkUiAKCi/APnNEJDDVYx0jv6vyo03ji86wCfTXns Sa178i0Ry3U+tD1o2awy8d8= =t3Cb -END PGP SIGNATURE-
[Issue 3368] New: GDB 6.8 cannot list code (sometimes)
http://d.puremagic.com/issues/show_bug.cgi?id=3368
Summary: GDB 6.8 cannot list code (sometimes)
Product: D
Version: 2.033
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: echocham...@gmail.com
--- Comment #0 from MIURA Masahiro echocham...@gmail.com 2009-10-05 23:24:58
PDT ---
cut here
% cat -n foo.d
1 import std.stdio;
2
3 void main()
4 {
5 *(cast(ubyte*)0) = 0; // intentional SEGV
6 // writefln(hello);
7 }
% dmd -gc foo.d; /usr/bin/gdb --quiet ./foo
(gdb) run
Starting program: /home/miura/work/foo
[Thread debugging using libthread_db enabled]
[New Thread 0xb7dde6f0 (LWP 12300)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dde6f0 (LWP 12300)]
0x08049239 in _Dmain () at foo.d:5
5 *(cast(ubyte*)0) = 0; // intentional SEGV
(gdb) list
1 import std.stdio;
2
3 void main()
4 {
5 *(cast(ubyte*)0) = 0; // intentional SEGV
6 // writefln(hello);
7 }
(gdb) backtrace
#0 0x08049239 in _Dmain () at foo.d:5
#1 0x08049514 in _D2rt6dmain24mainUiPPaZi7runMainMFZv ()
#2 0x0804931d in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#3 0x08049556 in _D2rt6dmain24mainUiPPaZi6runAllMFZv ()
#4 0x0804931d in _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#5 0x080492c8 in main ()
(gdb)
cut here
Uncomment the line 6, and gdb is now unable to list code:
cut here
% dmd -gc foo.d; /usr/bin/gdb --quiet ./foo
(gdb) run
Starting program: /home/miura/work/foo
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d696f0 (LWP 12311)]
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
(gdb) list
1 // Written in the D programming language.
2
3 /**
4 Standard I/O functions that extend $(B std.c.stdio). $(B std.c.stdio)
5 is $(D_PARAM public)ally imported when importing $(B std.stdio).
6
7 Macros:
8 WIKI=Phobos/StdStdio
9
10 Copyright: Copyright Digital Mars 2007 - 2009.
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
(gdb) backtrace
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
Dwarf Error: Cannot find DIE at 0x846 referenced from DIE at 0x165 [in module
/home/miura/work/foo]
(gdb)
cut here
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.
http://d.puremagic.com/issues/show_bug.cgi?id=2773
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #8 from Don clugd...@yahoo.com.au 2009-10-06 00:17:14 PDT ---
An even simpler test case shows something interesting: it happens only when
there's an array assignment of 0, followed by another use of the same variable.
An array assignment to 0 is an OPmemset operation in the backend.
int* get() { return null; }
void main(){
int* p = get();
p[0..3] = 0; // must be = 0!! Doesn't happen with any other number.
p[0] = 7;
}
ANALYSIS:
This is an OPmemset fight! In the optimisation loop, there's a localize step
which rearranges the assignment, and there's a canonicalize step which sets it
back the way it was before
cgelem.c, elmemxxx() line 702 replaces ((e op= v) op e2) with ((e op=v), (e op
e2))
ie, (p = get()), p) memset 0. --- ((p = get()), p memset 0.
glocal.c, local_exp() replaces
p = get(); p memset 0; --- (p = get(), p) memset 0
So it just keeps going round in circles.
The fight can be broken up by changing cgelem.c elmemxxx() line 701
to avoid doing the first replacement:
-if (e1-Eoper == OPcomma || OTassign(e1-Eoper))
+if (e1-Eoper == OPcomma)
This probably isn't correct, there may be somewhere this particular
canonicalisation is important. But without the DMC test suite, I can't tell.
(Note that the comments in the code only refer to the OPcomma transformation,
not the assignment one, so I presume the assignment was a later addition).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3357] ICE(cod1.c) using 'in' with a static char array as AA key
http://d.puremagic.com/issues/show_bug.cgi?id=3357
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
Summary|ICE with aa that use static |ICE(cod1.c) using 'in' with
|char array as key |a static char array as AA
||key
--- Comment #5 from Don clugd...@yahoo.com.au 2009-10-06 00:26:37 PDT ---
Same cause as bug 1934. The patch I used for IndexExp::toElem() also needs to
be applied to InExp::toElem().
Index: e2ir.c
===
--- e2ir.c(revision 75)
+++ e2ir.c(working copy)
@@ -2391,6 +2391,13 @@
key-Enumbytes = key-E1-Enumbytes;
assert(key-Enumbytes);
}
+else if (tybasic(key-Ety) == TYarray taa-index-ty==Tsarray)
+{// e2-elem() turns string literals into a TYarray, so the
+// length is lost. Restore it.
+key = el_una(OPstrpar, TYstruct, key);
+assert(e1-type-size() == taa-index-size());
+key-Enumbytes = taa-index-size();
+}
Symbol *s = taa-aaGetSymbol(In, 0);
keyti = taa-index-getInternalTypeInfo(NULL)-toElem(irs);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1934] ICE(e2ir.c) using static array as AA key
http://d.puremagic.com/issues/show_bug.cgi?id=1934 --- Comment #5 from Don clugd...@yahoo.com.au 2009-10-06 00:28:16 PDT --- The patch for bug 3357 should be applied at the same time, it's the other half of the same issue (the fix needs to be applied to opIn() as well as opIndex()). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3367] Regression: struct initialization no longer supports ctor overloads
http://d.puremagic.com/issues/show_bug.cgi?id=3367 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Summary|Regression: assignment at |Regression: struct |declaration no longer |initialization no longer |supports opAssign or ctor |supports ctor overloads |overloads | --- Comment #1 from Don clugd...@yahoo.com.au 2009-10-06 01:14:23 PDT --- My fault. This is a consquence of the fix to bug 2702. Previously it used to accept any old garbage inside a struct initializer; now it only accepts static opCall. It should definitely allow constructors as well. Based on my reading of the spec, the fact that opAssign used to work seems to have been a bug: assignment is defined as copying the contents of one object over another, already initialized, type (struct.html) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 814] lazy argument + variadic arguments = segfault
http://d.puremagic.com/issues/show_bug.cgi?id=814 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:12:02 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1168] Passing a .stringof of an expression as a template value parameter results in the string of the type
http://d.puremagic.com/issues/show_bug.cgi?id=1168 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:12:29 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1571] Segfault(class.c) const on function parameters not carried through to .di file
http://d.puremagic.com/issues/show_bug.cgi?id=1571 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:12:56 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2469] ICE(cod1.c) arbitrary struct accepted as struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=2469 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:14:23 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2697] Cast of float function return to ulong or uint gives bogus value
http://d.puremagic.com/issues/show_bug.cgi?id=2697 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:14:47 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1731] forward reference of function type alias resets calling convention
http://d.puremagic.com/issues/show_bug.cgi?id=1731 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:13:17 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 718] ICE(cgcod.c) with int /= cast(creal)
http://d.puremagic.com/issues/show_bug.cgi?id=718 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:11:38 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #14 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:10:59 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2202] Error getting type of non-static member of a class
http://d.puremagic.com/issues/show_bug.cgi?id=2202 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:13:59 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2839] ICE(cgcs.c) with int /= imaginary
http://d.puremagic.com/issues/show_bug.cgi?id=2839 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:15:44 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2905] [PATCH] Faster +-*/ involving a floating-pointing literal
http://d.puremagic.com/issues/show_bug.cgi?id=2905 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:16:07 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3049] ICE(cod4.c) or segfault: Array operation on void[] array
http://d.puremagic.com/issues/show_bug.cgi?id=3049 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:16:33 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3059] Nonsensical complex op= should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=3059 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:16:56 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3160] ICE(cgcod.c 1511-D1) or bad code-D2 returning string from void main
http://d.puremagic.com/issues/show_bug.cgi?id=3160 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:17:15 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1253] array initializers as expressions are not allowed in const arrays
http://d.puremagic.com/issues/show_bug.cgi?id=1253 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:19:51 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3305] Segfault(expression.c) with recursive struct template alias expressions
http://d.puremagic.com/issues/show_bug.cgi?id=3305 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:18:14 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3336] ICE(glue.c) declaring AA with tuple key, only with -g
http://d.puremagic.com/issues/show_bug.cgi?id=3336 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:18:55 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3304] Segfault using 'is' with a pointer enum.
http://d.puremagic.com/issues/show_bug.cgi?id=3304 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:17:43 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2702] Struct initialisation silently inserts deadly casts
http://d.puremagic.com/issues/show_bug.cgi?id=2702 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:15:10 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3353] storage class of a member function is propagated to default arguments
http://d.puremagic.com/issues/show_bug.cgi?id=3353 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:19:18 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3335] minor warning cleanups
http://d.puremagic.com/issues/show_bug.cgi?id=3335 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:18:34 PDT --- Fixed dmd 1.048 and 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3333] std.conv.to!(string, const int) error: cannot modify const
http://d.puremagic.com/issues/show_bug.cgi?id= Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:22:49 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3132] std.string.split should be templated on mutable/const/immutable
http://d.puremagic.com/issues/show_bug.cgi?id=3132 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:21:16 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2998] ICE(expression.c) with floating point enum
http://d.puremagic.com/issues/show_bug.cgi?id=2998 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:20:50 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3288] conv.d : using to with const int or long fails to compile.
http://d.puremagic.com/issues/show_bug.cgi?id=3288 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:22:05 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3300] std.string.toupper and tolower should be (const(char)[]), not string
http://d.puremagic.com/issues/show_bug.cgi?id=3300 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:22:31 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3173] ICE(mtype.c) on wrong code (double to long to int conversion)
http://d.puremagic.com/issues/show_bug.cgi?id=3173 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:21:38 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3340] std.string.split(S1 s, S2 delim) still doesn't work for char[].
http://d.puremagic.com/issues/show_bug.cgi?id=3340 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-10-06 02:23:14 PDT --- Fixed dmd 2.033 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3367] Regression: struct initialization no longer supports ctor overloads
http://d.puremagic.com/issues/show_bug.cgi?id=3367 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3369] New: std.conv.to!(float/double/real) doesn't work w/ infinity.
http://d.puremagic.com/issues/show_bug.cgi?id=3369
Summary: std.conv.to!(float/double/real) doesn't work w/
infinity.
Product: D
Version: 2.033
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha dsim...@yahoo.com 2009-10-06 14:11:11 PDT ---
import std.conv, std.stdio;
void main() {
writeln(to!float(inf));
}
Results in the following runtime error:
std.conv.ConvError: Can't convert value `inf' of type const(char)[] to type
float
If I change to -inf or try to convert to double or real instead of float,
nothing changes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
