Re: ctrl+c and destructors
On Oct 2, 2013, at 5:25 PM, Walter Bright newshou...@digitalmars.com wrote: On 10/2/2013 10:10 AM, Sean Kelly wrote: If there's one notion I'd like to terminate with prejudice, it's the notion that a running program can recover from bugs in itself. I worked on a system whose design was specifically built around trapping and recovering from segfaults (great design, and sadly, patented). Things like this are one of the primary reasons to use a systems programming language. So while I agree in the general sense, I don't think it's appropriate for the language to make a hard and fast assertion here. I think we should choose a reasonable, safe default, but make it overridable. That's pretty much the design philosophy of Druntime. D being a systems programming language, you can pursue whatever design you like with it, including bad designs :-) Although I haven't seen the system you describe, I'm very skeptical that it found the solution to the problem of a program successfully continuing after it has crashed due to program bugs. I remain firmly convinced that that is an utterly wrong and doomed approach to the problem of reliability. It isn't a program bug in this case though. This is essentially an object database that lazily maps in chunks of the data store on demand. The objects are then used directly from mapped memory without any intermediate loading thanks to some dirty tricks played to guarantee vtbl placement in application memory across releases. Ridiculously fast and it allows large databases to be used efficiently. This backs an accounting system used by large trading firms. In any case, my point remains that some features like this can be part of a good design in rare cases. So systems languages shouldn't flat out prevent them, but rather put an experts only label on there somewhere.
Re: ctrl+c and destructors
On Oct 2, 2013, at 6:15 PM, Adam D. Ruppe destructiona...@gmail.com wrote: On Thursday, 3 October 2013 at 00:25:26 UTC, Walter Bright wrote: Although I haven't seen the system you describe, I'm very skeptical that it found the solution to the problem of a program successfully continuing after it has crashed due to program bugs. I remain firmly convinced that that is an utterly wrong and doomed approach to the problem of reliability. Segfaults aren't necessarily bugs... though I'm not sure if a userspace handler can do much about it. But from a kernel perspective, they can be generated by page faults too, which can be successfully handled by loading the requested memory block (e.g. from a swap file) and then retrying the operation, or copying the page into a writable location and mapping that in; hardware assisted copy-on-write. I've never tried to do this in a unix program so I don't know how much you can do, but presumably Sean's example did something along these lines, so it would be by design rather than bugs. This exactly. It goes a bit beyond what Posix allows in signal handlers, but it works just fine on this particular system.
Re: std.d.lexer : voting thread
On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote: After brief discussion with Brian and gathering data from the review thread, I have decided to start voting for `std.d.lexer` inclusion into Phobos. - All relevant information can be found here: http://wiki.dlang.org/Review/std.d.lexer (it includes link to post-review change set and some clarifications by Brian) Review thread is here: http://forum.dlang.org/post/jsnhlcbulwyjuqcqo...@forum.dlang.org - Instructions for voters The goal of the vote is to allow the Review Manager to decided if the community agrees on the inclusion of the submission. Place further discussion of the library in the official review thread. If replying to an opinion stated during a vote, copy all relevant context and post in the official review thread. If you would like to see the proposed module included into Phobos Vote Yes If one condition must be met Vote Yes explicitly stating it is under a condition and what condition. You may specify an improvement you'd like to see, but be sure to state it is not a condition/showstopper. Otherwise Vote No A brief reason should be provided though details on what needs improvement should be placed in the official review thread. (c) wiki.dlang.org/Review/Process - If you need to ask any last moment questions before making your decision, please do it in last review thread (linked in beginning of this post). Voting will last until the next weekend (Oct 12 23:59 GMT +0) Thanks for your attention. Yes :)
Re: Bug 6186
02.10.2013 23:03, Benjamin Thaut пишет: Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time! -- Денис В. Шеломовский Denis V. Shelomovskij
Re: ctrl+c and destructors
On 10/2/2013 8:04 PM, Sean Kelly wrote: It isn't a program bug in this case though. This is essentially an object database that lazily maps in chunks of the data store on demand. The objects are then used directly from mapped memory without any intermediate loading thanks to some dirty tricks played to guarantee vtbl placement in application memory across releases. Ridiculously fast and it allows large databases to be used efficiently. This backs an accounting system used by large trading firms. Sorry, I misunderstood.
Re: Bug 6186
On Thursday, 3 October 2013 at 06:25:04 UTC, Denis Shelomovskij wrote: 02.10.2013 23:03, Benjamin Thaut пишет: Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time! Don't think I'll ever stop. Post a bug - fix within hours. Look at github notifications - several pulls by Kenji.
Re: std.d.lexer : voting thread
Yes!
Re: ctrl+c and destructors
On Wednesday, 2 October 2013 at 02:30:42 UTC, Walter Bright wrote: Right. A null pointer dereference is a logic bug in your program, and hence the program needs to stop immediately, not execute cleanup code. If there's one notion I'd like to terminate with prejudice, it's the notion that a running program can recover from bugs in itself. That famous prejudice of yours :). As always, it depends. The application can't recover but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely.
Re: std.d.lexer : voting thread
On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote: After brief discussion with Brian and gathering data from the review thread, I have decided to start voting for `std.d.lexer` inclusion into Phobos. - All relevant information can be found here: http://wiki.dlang.org/Review/std.d.lexer (it includes link to post-review change set and some clarifications by Brian) Review thread is here: http://forum.dlang.org/post/jsnhlcbulwyjuqcqo...@forum.dlang.org - Instructions for voters The goal of the vote is to allow the Review Manager to decided if the community agrees on the inclusion of the submission. Place further discussion of the library in the official review thread. If replying to an opinion stated during a vote, copy all relevant context and post in the official review thread. If you would like to see the proposed module included into Phobos Vote Yes If one condition must be met Vote Yes explicitly stating it is under a condition and what condition. You may specify an improvement you'd like to see, but be sure to state it is not a condition/showstopper. Otherwise Vote No A brief reason should be provided though details on what needs improvement should be placed in the official review thread. (c) wiki.dlang.org/Review/Process - If you need to ask any last moment questions before making your decision, please do it in last review thread (linked in beginning of this post). Voting will last until the next weekend (Oct 12 23:59 GMT +0) Thanks for your attention. Yes.
Re: std.d.lexer : voting thread
Yes
Re: Can we please kill the hyphenator already?
On Tuesday, 1 October 2013 at 21:30:59 UTC, Andrei Alexandrescu wrote: Hyphenation rox. When reading hyphenated text one has to first read the start of the word on the right side of the text then go to the left side to find the end of the word. That doesn't sound good.
Re: Can we please kill the hyphenator already?
The printed text can save a fraction of paper with hyphenation, but digital text already saves 100% of paper. That can be solved by adding a stylesheet for print media (it has to be different anyway): http://www.w3.org/TR/2008/REC-CSS2-20080411/media.html
Re: std.rational -- update and progress towards review
On 02/10/13 19:37, H. S. Teoh wrote:
* Because std.rational doesn't just want to work with built-in
integer types it can't rely on the existing isIntegral.
TBH, I found isIntegral rather counterintuitive. I thought it would
evaluate to true with BigInt, but it doesn't. If I had my way, I'd
propose renaming isIntegral to isBuiltInIntegral, and David's
isIntegerLike to isIntegral.
It's a fair thought, but at this point I guess we have to consider whether
people may be using isIntegral specifically to check for built-in integer type.
(I seem to remember someone -- Bearophile? -- filed an enhancement request for
isIntegral to expand its scope to include BigInts, but searching D bugzilla now
I can't find it. Maybe it was just a forum discussion.)
Maybe we could have a bit of discussion here in the forum on all of the
proposed additions to std.traits, then once that decision is made, put
up std.rational for the actual official review?
That's what I was hoping for -- get all the what goes where decisions out of
the way first, then there's less to worry about in the official review.
Since Rational is a templated type, no function attributes are needed.
The compiler should be able to infer the appropriate attributes.
Unless, of course, you find a case where it makes sense to constrict any
future changes in implementation (e.g., guarantee that gcd is always
pure -- but even that is questionable since gcd's purity would depend on
the purity of operations on the type it is being instantiated for, so
even in this case I'd say keep it unmarked and let attribute inference
do its job).
Ahh, OK. I don't feel 100% on what the compiler can infer attribute-wise
compared to what needs to be explicitly written.
The remaining open issues
https://github.com/WebDrake/Rational/issues?state=open are all
design-related. Apart from those raised by my above queries, the
major one is how rationals should relate to floating-point numbers --
e.g. there is currently no opCmp for floating-point, meaning this:
assert(rational(10, 1) == 10);
... will work, but this:
assert(rational(10, 1) == 10.0);
... will fail to compile. It's not entirely obvious how to resolve
this as floating-point vs. rational comparisons risk accidentally
creating huge temporary BigInt-based rationals ... :-(
Does addition/subtraction with floating point work correctly? If so, the
user should simply write:
assert(abs(rational(10,1) - 10.0) EPSILON);
Well, yes, obviously one can use this formalism. On that note, approxEqual
won't work with rationals, e.g.:
auto r1 = rational(10);
assert(approxEqual(r1, 10.0));
fails with error message:
/opt/dmd/include/d2/std/math.d(5689): Error: function std.math.fabs (real
x) is not callable using argument types (Rational!int)
/opt/dmd/include/d2/std/math.d(5696): Error: incompatible types for ((lhs)
- (rhs)): 'Rational!int' and 'double'
/opt/dmd/include/d2/std/math.d(5697): Error: incompatible types for ((lhs)
- (rhs)): 'Rational!int' and 'double'
/opt/dmd/include/d2/std/math.d(5707): Error: template instance
std.math.approxEqual!(Rational!int, double, double) error instantiating
rational.d(57):instantiated from here: approxEqual!(Rational!int,
double)
rational.d(57): Error: template instance
std.math.approxEqual!(Rational!int, double) error instantiating
(Ignore the line number, it's a temporary unittest I knocked up just to try this
out just now and is not in the repo.)
You can do approxEqual(cast(real) r1, float1), however.
We should definitely not convert floats to Rational just so they can be
compared, because floats are inexact by definition, whereas Rationals
are always exact. For example, rational(2,10) != 0.2f, because 0.2f has
no exact representation in any binary floating-point format. But if you
support rational(10,1) == 10.0, then people will expect that
rational(2,10) == 0.2 should also work, but it *can't* work. We should
not sweep these issues under the rug, but force the user to come to
terms with the nature of floating-point numbers.
Well, the point is that anyone who knows anything about floating point knows
that comparisons of the form float1 == float2 or float1 == int1 are dangerous
because tiny rounding errors can result in the floating-point number being ever
so slightly off. But you're not _banned_ from making the comparison; the code
won't fail to compile.
So, it feels bad that there isn't an opCmp for floating-point, even though I can
see logical reasons for that. After all, it's one thing that you can't
guarantee an opEquals, another that you can't do something like
auto r1 = rational(2, 3);
assert(r1 0.8);
OTOH, one compromise might be to allow implicit conversion of Rationals
to floating-point via alias this:
struct Rational(T) {
...
@property real toReal() { return this.convertToReal(); }
C++ - D converter mentioned in AMA
Andrei's AMA has interesting answer: One of the main D(md) contributors, Daniel Murphy is working on automatic conversion tool that eventually will convert DMD's C++ codebase to D. Is this tool already available? Are there any guidelines about how to code in C++ to ease the conversion preocess (or even make it possible). I would be VERY interested in such a tool when the time comes so in the mean time I could slowly fix existing C++ codebase for future conversion.
Re: std.rational -- update and progress towards review
On 02/10/13 20:27, Jacob Carlborg wrote: A pull request shouldn't be made until the review is done and the module has been voted for acceptance. See: http://wiki.dlang.org/Review/Process Usually you'll have a fork of Phobos with the changes/new module. Then post here, something like: Request for review of std.module name. Ahh, OK -- thanks for clarifying. But either way, what I meant is: the module needs to be provided for review in a way that is diff-able against current Phobos, no?
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 10:52:42 UTC, simendsjo wrote: On Thursday, 3 October 2013 at 10:42:32 UTC, Szymon Gatner wrote: Andrei's AMA has interesting answer: One of the main D(md) contributors, Daniel Murphy is working on automatic conversion tool that eventually will convert DMD's C++ codebase to D. Is this tool already available? Are there any guidelines about how to code in C++ to ease the conversion preocess (or even make it possible). I would be VERY interested in such a tool when the time comes so in the mean time I could slowly fix existing C++ codebase for future conversion. I think Daniel Murphys tool is aimed directly at the DMD codebase. It probably has plenty of hacks to solve the problem. There are plenty of pull-requests to ease the conversion, so I don't think this is a tool that works for other projects out of the box. The code can be found here: https://github.com/yebblies/dmd VisualD includes a generic tool to automatically convert C++ to D. I haven't tried it myself, but you can find some information here: http://www.dsource.org/projects/visuald/wiki/Tour/CppConversion There are also a couple of tools for header files: * https://github.com/jacob-carlborg/dstep?source=cc * http://dlang.org/htod.html
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 10:42:32 UTC, Szymon Gatner wrote: Andrei's AMA has interesting answer: One of the main D(md) contributors, Daniel Murphy is working on automatic conversion tool that eventually will convert DMD's C++ codebase to D. Is this tool already available? Are there any guidelines about how to code in C++ to ease the conversion preocess (or even make it possible). I would be VERY interested in such a tool when the time comes so in the mean time I could slowly fix existing C++ codebase for future conversion. I think Daniel Murphys tool is aimed directly at the DMD codebase. It probably has plenty of hacks to solve the problem. There are plenty of pull-requests to ease the conversion, so I don't think this is a tool that works for other projects out of the box. The code can be found here: https://github.com/yebblies/dmd VisualD includes a generic tool to automatically convert C++ to D. I haven't tried it myself, but you can find some information here: http://www.dsource.org/projects/visuald/wiki/Tour/CppConversion
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 10:54:47 UTC, simendsjo wrote: There are also a couple of tools for header files: * https://github.com/jacob-carlborg/dstep?source=cc * http://dlang.org/htod.html AFAIK, those are for C/ObjC, not C++
Re: std.d.lexer : voting thread
Yes. ( I have not found any rules that prohibit review manager from voting :) )
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 10:57:24 UTC, Dicebot wrote: On Thursday, 3 October 2013 at 10:54:47 UTC, simendsjo wrote: There are also a couple of tools for header files: * https://github.com/jacob-carlborg/dstep?source=cc * http://dlang.org/htod.html AFAIK, those are for C/ObjC, not C++ Ah, you're probably right. Another link then :) http://dlang.org/cpp_interface.html
Re: std.rational -- update and progress towards review
On Thursday, 3 October 2013 at 10:51:22 UTC, Joseph Rushton Wakeling wrote: Ahh, OK -- thanks for clarifying. But either way, what I meant is: the module needs to be provided for review in a way that is diff-able against current Phobos, no? Yes. Common approach is to fork phobos in private repository and integrate proposed code there so that it will be available for easy review. Doing actual pull request will only distract Phobos devs and it not really needed.
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 10:52:42 UTC, simendsjo wrote: On Thursday, 3 October 2013 at 10:42:32 UTC, Szymon Gatner wrote: Andrei's AMA has interesting answer: One of the main D(md) contributors, Daniel Murphy is working on automatic conversion tool that eventually will convert DMD's C++ codebase to D. Is this tool already available? Are there any guidelines about how to code in C++ to ease the conversion preocess (or even make it possible). I would be VERY interested in such a tool when the time comes so in the mean time I could slowly fix existing C++ codebase for future conversion. I think Daniel Murphys tool is aimed directly at the DMD codebase. It probably has plenty of hacks to solve the problem. There are plenty of pull-requests to ease the conversion, so I don't think this is a tool that works for other projects out of the box. The code can be found here: https://github.com/yebblies/dmd VisualD includes a generic tool to automatically convert C++ to D. I haven't tried it myself, but you can find some information here: http://www.dsource.org/projects/visuald/wiki/Tour/CppConversion Thanks, I actually have VisualD installed but didn't know about that functionality tho looking at the docs it is pretty limited especially when it comes to templates :( Sorry to hear about Daniel's tool. Maybe some day...
Re: std.rational -- update and progress towards review
On 03/10/13 13:00, Dicebot wrote: Yes. Common approach is to fork phobos in private repository and integrate proposed code there so that it will be available for easy review. Doing actual pull request will only distract Phobos devs and it not really needed. As the one who'd be managing the review process, do you have any preferences for how I handle the issues I raised above? Do you think it'd be better to parcel the potentially broadly useful code out across different Phobos modules as suggested or let the review process decide what goes where?
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 11:08:29 UTC, Szymon Gatner wrote: Thanks, I actually have VisualD installed but didn't know about that functionality tho looking at the docs it is pretty limited especially when it comes to templates :( Sorry to hear about Daniel's tool. Maybe some day... Expecting such tool to just work is very unrealistic. C++ is very complex language and some behavior just can't be mapped to D directly. For example, one issue with current DMD source translation is that in C++ you can split class implementation among different translation units. Not in D. Of course, libclang helps a lot with such tools (you don't need to write full C++ front-end on your own anymore!) but the complexity of translation is very high and you need to manually recheck it anyway so this does not seem like a feasible _generic_ tool, only something that can be adopted for specific projects.
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 11:23:25 UTC, Dicebot wrote: On Thursday, 3 October 2013 at 11:08:29 UTC, Szymon Gatner wrote: Thanks, I actually have VisualD installed but didn't know about that functionality tho looking at the docs it is pretty limited especially when it comes to templates :( Sorry to hear about Daniel's tool. Maybe some day... Expecting such tool to just work is very unrealistic. C++ is very complex language and some behavior just can't be mapped to D directly. For example, one issue with current DMD source translation is that in C++ you can split class implementation among different translation units. Not in D. Of course, libclang helps a lot with such tools (you don't need to write full C++ front-end on your own anymore!) but the complexity of translation is very high and you need to manually recheck it anyway so this does not seem like a feasible _generic_ tool, only something that can be adopted for specific projects. I fully realize that and actually I was really surprised that such a tool is in production considering amount of code in DMD. OTOH if it can work for DMD then in theory it should be possible to (to some degree) reuse it on other codebase *if* it conforms to certain coding rules/standard right?
Re: std.rational -- update and progress towards review
On Thursday, 3 October 2013 at 11:14:26 UTC, Joseph Rushton Wakeling wrote: As the one who'd be managing the review process, do you have any preferences for how I handle the issues I raised above? Do you think it'd be better to parcel the potentially broadly useful code out across different Phobos modules as suggested or let the review process decide what goes where? My role as review manager does not matter here. Responsibility of review manager is to collect opinions and information from community, he does not have any authority of his own. Remembering std.serialization discussion though, it felt like people are more in favor of merging generic functionality into matching modules instead of keeping everything self-contained. You can also just do pull requests for smaller parts without any review if they are decoupled from std.rational - but be warned that waiting until those are reviewed and merged by Phobos devs may take a considerable time ;) In the end it is your own judgment. There are no strict rules and it is always good to see a module with personality behind ;)
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 11:29:38 UTC, Szymon Gatner wrote: On Thursday, 3 October 2013 at 11:23:25 UTC, Dicebot wrote: On Thursday, 3 October 2013 at 11:08:29 UTC, Szymon Gatner wrote: Thanks, I actually have VisualD installed but didn't know about that functionality tho looking at the docs it is pretty limited especially when it comes to templates :( Sorry to hear about Daniel's tool. Maybe some day... Expecting such tool to just work is very unrealistic. C++ is very complex language and some behavior just can't be mapped to D directly. For example, one issue with current DMD source translation is that in C++ you can split class implementation among different translation units. Not in D. Of course, libclang helps a lot with such tools (you don't need to write full C++ front-end on your own anymore!) but the complexity of translation is very high and you need to manually recheck it anyway so this does not seem like a feasible _generic_ tool, only something that can be adopted for specific projects. I fully realize that and actually I was really surprised that such a tool is in production considering amount of code in DMD. OTOH if it can work for DMD then in theory it should be possible to (to some degree) reuse it on other codebase *if* it conforms to certain coding rules/standard right? An official reply from Daniel ;) https://github.com/D-Programming-Language/dmd/pull/1980#issuecomment-19539800
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 11:31:51 UTC, Tourist wrote: On Thursday, 3 October 2013 at 11:29:38 UTC, Szymon Gatner wrote: On Thursday, 3 October 2013 at 11:23:25 UTC, Dicebot wrote: On Thursday, 3 October 2013 at 11:08:29 UTC, Szymon Gatner wrote: Thanks, I actually have VisualD installed but didn't know about that functionality tho looking at the docs it is pretty limited especially when it comes to templates :( Sorry to hear about Daniel's tool. Maybe some day... Expecting such tool to just work is very unrealistic. C++ is very complex language and some behavior just can't be mapped to D directly. For example, one issue with current DMD source translation is that in C++ you can split class implementation among different translation units. Not in D. Of course, libclang helps a lot with such tools (you don't need to write full C++ front-end on your own anymore!) but the complexity of translation is very high and you need to manually recheck it anyway so this does not seem like a feasible _generic_ tool, only something that can be adopted for specific projects. I fully realize that and actually I was really surprised that such a tool is in production considering amount of code in DMD. OTOH if it can work for DMD then in theory it should be possible to (to some degree) reuse it on other codebase *if* it conforms to certain coding rules/standard right? An official reply from Daniel ;) https://github.com/D-Programming-Language/dmd/pull/1980#issuecomment-19539800 It's been self-hosting for two months..? Perhaps DMD 2.065 will be written in D! :)
Re: C++ - D converter mentioned in AMA
On 2013-10-03 12:54, simendsjo wrote: * https://github.com/jacob-carlborg/dstep?source=cc OT: what does ?source=cc do? -- /Jacob Carlborg
Re: std.rational -- update and progress towards review
On 2013-10-03 13:31, Dicebot wrote: Remembering std.serialization discussion though, it felt like people are more in favor of merging generic functionality into matching modules instead of keeping everything self-contained. I got the opposite feeling. That it's generally better for utility functions, that could be useful for the rest of Phobos, be kept private. Then we can later extract those functions if they're considered useful. The more public API the harder it will become to get the changes accepted. All the bikeshedding about where to put the functions and what to name them. -- /Jacob Carlborg
Re: C++ - D converter mentioned in AMA
On 2013-10-03 13:01, simendsjo wrote: Ah, you're probably right. Another link then :) http://dlang.org/cpp_interface.html And it's only for creating bindings for headers. -- /Jacob Carlborg
Re: ctrl+c and destructors
On Thursday, 3 October 2013 at 08:02:17 UTC, Max Samukha wrote: On Wednesday, 2 October 2013 at 02:30:42 UTC, Walter Bright wrote: Right. A null pointer dereference is a logic bug in your program, and hence the program needs to stop immediately, not execute cleanup code. If there's one notion I'd like to terminate with prejudice, it's the notion that a running program can recover from bugs in itself. That famous prejudice of yours :). As always, it depends. The application can't recover but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely. This. I agree that in a purist sense, a broken program is broken, end of. However, in the real world it's a balance of risk.
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 11:49:42 UTC, Jacob Carlborg wrote: On 2013-10-03 12:54, simendsjo wrote: * https://github.com/jacob-carlborg/dstep?source=cc OT: what does ?source=cc do? Hmm. No idea. I just searched for the github repo and copied the link.
Re: std.rational -- update and progress towards review
On 03/10/13 13:31, Dicebot wrote: My role as review manager does not matter here. Responsibility of review manager is to collect opinions and information from community, he does not have any authority of his own. It's not about your opinions of the code per se, so much as about your experience of what is likely to provide a smooth review process that is less likely to end in rejection for trivial rather than major reasons (meaning a second round of review and therefore more work for you). Remembering std.serialization discussion though, it felt like people are more in favor of merging generic functionality into matching modules instead of keeping everything self-contained. You can also just do pull requests for smaller parts without any review if they are decoupled from std.rational - but be warned that waiting until those are reviewed and merged by Phobos devs may take a considerable time ;) Yes, that's my fear. :-( In the end it is your own judgment. There are no strict rules and it is always good to see a module with personality behind ;) I think I will follow Jacob's suggestion to make private all that is not _essential_ to have in public, with the scope to pull these out into broader Phobos later. That should allow the essentials of std.rational to go forward without disturbing anything else, and then its generically useful stuff can be parcelled out later without delaying the module itself. And of course if there is consensus during the review process that certain things _should_ be made public and moved elsewhere, I'll do that.
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 11:31:51 UTC, Tourist wrote: An official reply from Daniel ;) https://github.com/D-Programming-Language/dmd/pull/1980#issuecomment-19539800 Still, there is some hope :P
Re: Anyone used LLVM-D with Dub?
On Thursday, 3 October 2013 at 00:37:39 UTC, Alan wrote: On Wednesday, 2 October 2013 at 18:43:06 UTC, Moritz Maxeiner wrote: Could you give me a minimal example I can use to reproduce the error you've encountered? Also, you can always open an issue at llvm-d's github repo, that's the easiest way to report problems about llvm-d (other than mailing me). I just put the package in the dependencies and import it in my code then it does that, haven't even used any functions yet. (When building of course) Since it seems you overlooked it, I'll ask again: Could you please provide a minimal working example that reproduces your error? Simply telling me to add it to the dependencies doesn't cut it, because there are a lot of possible options for dub package.json files, that you may or may not have used, or I might use when trying to reproduce the error myself, resulting in differences so that I might not be able to reproduce your error. I'll try to reproduce the error myself, but since code.dlang.org (and with it, the documentation for dub package.json files I've always used) seems to be offline, that might take a while.
Re: review queue: next?
On Wednesday, 2 October 2013 at 15:46:06 UTC, Jesse Phillips wrote: On Wednesday, 2 October 2013 at 15:07:43 UTC, ilya-stromberg wrote: On Sunday, 29 September 2013 at 15:11:26 UTC, Dicebot wrote: On Sunday, 29 September 2013 at 14:58:17 UTC, ilya-stromberg wrote: It looks like we finished review of std.d.lexer. Do you have any plans to start review for Robert Schadek's std.logger? Brian has made several quick fixes/modifications and I am expecting that either second review or final voting will take pretty soon. That is why I did not move forward with other review queue proposals. Right now I am awaiting Brians mail with some details regarding outcome of first review, something will happen as soon as it will arrive. I guess std.logger will be the very next one. OK, I see. May I ask: who can vote? Only old community members or everybody? Any additional conditions? All can vote. Voting may include one condition for acceptance or a brief explanation of why it is rejected. Discussion of opinion should not be in the voting thread. What happens if I vote Yes with condition, but module developer will not satisfy the condition? My vote will be calculated as No, as Yes, or will not calculated at all? In which term module developer should satisfy the condition if he wants to do this? Before merge pull request to the Phobos?
Re: review queue: next?
On Thursday, 3 October 2013 at 14:13:58 UTC, ilya-stromberg wrote: What happens if I vote Yes with condition, but module developer will not satisfy the condition? My vote will be calculated as No, as Yes, or will not calculated at all? In which term module developer should satisfy the condition if he wants to do this? Before merge pull request to the Phobos? Initially it will be counted as No vote. Then, if clear Yes vote count is not enough to get the module into Phobos, Yes, but votes will be evaluated. If those can make the difference, module author will be given the opportunity to satisfy the condition(s) and turn this vote into clear Yes without any additional formal review and/or voting. If those do not make the difference, proposal is simply marked as rejected.
Re: std.rational -- update and progress towards review
On Thursday, 3 October 2013 at 11:47:50 UTC, Jacob Carlborg wrote: On 2013-10-03 13:31, Dicebot wrote: Remembering std.serialization discussion though, it felt like people are more in favor of merging generic functionality into matching modules instead of keeping everything self-contained. I got the opposite feeling. That it's generally better for utility functions, that could be useful for the rest of Phobos, be kept private. Then we can later extract those functions if they're considered useful. The more public API the harder it will become to get the changes accepted. All the bikeshedding about where to put the functions and what to name them. That is a bit frustrating part - we (reviewers) kind of want stuff cleanly separated between modules for further re-usage but at the same time we will make your life hell when reviewing how exactly this stuff needs to be incorporated :P
Re: std.rational -- update and progress towards review
On Thursday, 3 October 2013 at 12:16:51 UTC, Joseph Rushton Wakeling wrote: It's not about your opinions of the code per se, so much as about your experience of what is likely to provide a smooth review process ... Experience? :D I have not yet finished a single complete review process. If you look for experienced advice, ping some guys from that list in the bottom : http://wiki.dlang.org/Review_Queue :P
Re: review queue: next?
On Thursday, 3 October 2013 at 14:43:55 UTC, ilya-stromberg wrote: OK, I see. How many conditions I can add? Only one, a few related (for example, documentation issues), or unlimited? One very specific issue at most. Everything else should go as No. http://wiki.dlang.org/Review/Process#Voting
Re: review queue: next?
On Thursday, 3 October 2013 at 14:23:42 UTC, Dicebot wrote: On Thursday, 3 October 2013 at 14:13:58 UTC, ilya-stromberg wrote: What happens if I vote Yes with condition, but module developer will not satisfy the condition? My vote will be calculated as No, as Yes, or will not calculated at all? In which term module developer should satisfy the condition if he wants to do this? Before merge pull request to the Phobos? Initially it will be counted as No vote. Then, if clear Yes vote count is not enough to get the module into Phobos, Yes, but votes will be evaluated. If those can make the difference, module author will be given the opportunity to satisfy the condition(s) and turn this vote into clear Yes without any additional formal review and/or voting. If those do not make the difference, proposal is simply marked as rejected. OK, I see. How many conditions I can add? Only one, a few related (for example, documentation issues), or unlimited?
mixin module template - undefined identifier
I have some found some irregular behavior when using mixins with
template and modules. If a aggregation is defined in the same module it
is found. If the aggregation is defined in another module it fails. And
I wonder if this is be design. For comparison see the code below.
// file: moduleA.d
module A;
public int func(T)() {
return mixin(T.stringof ~ .fun());
}
struct Bar {
static int fun() {
return 2;
}
}
unittest {
static assert(func!Bar() == 2);
}
// file: moduleB.d
import A;
struct Foo {
static int fun() {
return 1;
}
}
void main() {
assert(func!Foo() == 1);
}
dmd moduleA.d moduleB.d -ofmix -unittest
moduleA.d(4): Error: undefined identifier Foo
moduleB.d(10): Error: template instance A.func!(Foo) error instantiating
Re: mixin module template - undefined identifier
On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:
// file: moduleA.d
module A;
public int func(T)() {
return mixin(T.stringof ~ .fun());
}
[…]
dmd moduleA.d moduleB.d -ofmix -unittest
moduleA.d(4): Error: undefined identifier Foo
moduleB.d(10): Error: template instance A.func!(Foo) error
instantiating
Yes, this is indeed very much by design – A does not import B, so
there is no reason why the name Foo should exist in A.
To access the template parameter, just use it directly in the
mixin (as in »mixin(T.fun())«). I'm aware that the situation
where you actually stumbled over this is probably a bit more
complex, but in my experience an equivalent rewrite can almost
always be performed quite easily once you have wrapped your head
around the concept.
Oh, and for those of you keeping track, this is another example
supporting my stance that using stringof for code generation is
(almost) always a bad idea. The fact that experienced D coders
seem to run into this trap quite frequently, judging from the
fact that is by far not the first NG thread on this topic, seems
to suggest that we should address this with a big red warning in
the documentation, probably where string mixins are discussed.
(The recently merged pull request warning about .stringof use is
a first step, albeit it does so for a different reason.)
David
Re: Move VisualD to github/d-programming-language ?
On 24.09.2013 21:31, Andrei Alexandrescu wrote: On 9/24/13 11:19 AM, Rainer Schuetze wrote: On 24.09.2013 19:16, Andrei Alexandrescu wrote: On 9/22/13 7:05 AM, Rainer Schuetze wrote: Do you mean that I should add the documentation to the dlang.org repository? It's currently part of the visuald repository, and it could also be referred to by the makefile in dlang.org, but that might mean that people building that will also have to clone the visuald repository. I preapprove any pages that refer exclusively to Visual D in the dlang.org repo. I trust you to design and write them within the site look and feel, and to organize them in directories appropriately. Sorry for the silence, I've been traveling for the last week. Here's a pull request for dlang.org; https://github.com/D-Programming-Language/dlang.org/pull/389
Re: Anyone used LLVM-D with Dub?
On Thursday, 3 October 2013 at 00:37:39 UTC, Alan wrote: I just put the package in the dependencies and import it in my code then it does that, haven't even used any functions yet. (When building of course) Now that code.dlang.org is reachable again I was able to reproduce your error with a dub init project that had llvm-d added to the dependencies. Interestingly enough, building llvm-d into a static library and linking a default app.d against that works, yet using the same modules in the same order and compiling them with that same app.d directly into an application triggers the issue you encountered. Quite frankly, I do not know why that is, because going over the relevant source files has not lead me to any incorrect code, which leaves me with only two possible explanations: 1) I've unknowningly done something in my code that isn't actually allowed and that for some reason gets ignored when compiling as a libarary. 2) A compiler bug that happens when trying to compile multiple modules at the same time. I do not know which one it is, but it may be time to ask one of the compiler devs about it, as it is possible you may indeed have found a compiler bug - and if it is not a bug they may be able to tell us what I (in that case) did wrong.
Re: std.d.lexer : voting thread
On Thursday, 3 October 2013 at 11:04:26 UTC, Dicebot wrote: Yes. ( I have not found any rules that prohibit review manager from voting :) ) I'd love to say yes, since I've been dreaming of the day when we finally have a lexer... but I decided to put my yes under the condition that it can lex itself using ctfe. My first attempt with adding a import(__FILE__) unittest failed with v2.063.2: Error: memcpy cannot be interpreted at compile time, because it has no available source code lexer.d(1966): called from here: move(lex) lexer.d(454):called from here: r.this(lexerSource(range), config) Maybe this is this fixed in HEAD though?
Re: mixin module template - undefined identifier
On 10/03/2013 08:10 PM, David Nadlinger wrote: On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote: dmd moduleA.d moduleB.d -ofmix -unittest moduleA.d(4): Error: undefined identifier Foo moduleB.d(10): Error: template instance A.func!(Foo) error instantiating Yes, this is indeed very much by design – A does not import B, so there is no reason why the name Foo should exist in A. Yes, it does not exists in the module but func is a template and I was under the impression symbols would be seen when instantiated. I mean the error starts with A.func!(Foo) error instantiating. To access the template parameter, just use it directly in the mixin (as in »mixin(T.fun())«). I'm aware that the situation where you actually stumbled over this is probably a bit more complex, but in my experience an equivalent rewrite can almost always be performed quite easily once you have wrapped your head around the concept. Not as easy to fix this as I have a library that generates me sqlite code at compile time which I than mixin to have as good as handwritten code. I just found it odd that it works if I instantiate the template from the same module.
Re: std.rational -- update and progress towards review
On 2013-10-03 16:36, Dicebot wrote: That is a bit frustrating part - we (reviewers) kind of want stuff cleanly separated between modules for further re-usage but at the same time we will make your life hell when reviewing how exactly this stuff needs to be incorporated :P Every time I asked that some functionality should be place somewhere else because it's generally useable I just got a No, we keep here, private, for now. We don't have a good public API for it. -- /Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On 09/10/2013 04:25 PM, Walter Bright wrote:
On 9/9/2013 11:35 AM, Russel Winder wrote:
C++11 has revitalized C++ in ways that are only just showing themselves.
That's true.
This is a threat to D gaining traction.
I'm less sure about that. I think it presents an opportunity for us.
Driving the C++ resurgence is:
1. demand for high performance computing
2. turning back towards native languages
3. recognition of the value of functional-style programming techniques
4. recognition of the value of safety, encapsulation, etc.
But regarding the latter two points, I don't buy that the new C++
delivers. The classic is a oneliner Andrei wrote:
void fun() noexcept { throw so sue me; }
noexcept means the function doesn't throw any exceptions. But it doesn't
check! The above code compiles, and then fails at runtime. The
opportunity for D is to deliver what C++ has promised.
Well that's almost completely useless.
About like static typing if the compiler didn't actually check it.
Re: Anyone used LLVM-D with Dub?
On 10/03/2013 01:20 PM, Moritz Maxeiner wrote: On Thursday, 3 October 2013 at 00:37:39 UTC, Alan wrote: I just put the package in the dependencies and import it in my code then it does that, haven't even used any functions yet. (When building of course) Now that code.dlang.org is reachable again I was able to reproduce your error with a dub init project that had llvm-d added to the dependencies. Interestingly enough, building llvm-d into a static library and linking a default app.d against that works, yet using the same modules in the same order and compiling them with that same app.d directly into an application triggers the issue you encountered. Quite frankly, I do not know why that is, because going over the relevant source files has not lead me to any incorrect code, which leaves me with only two possible explanations: 1) I've unknowningly done something in my code that isn't actually allowed and that for some reason gets ignored when compiling as a libarary. 2) A compiler bug that happens when trying to compile multiple modules at the same time. I do not know which one it is, but it may be time to ask one of the compiler devs about it, as it is possible you may indeed have found a compiler bug - and if it is not a bug they may be able to tell us what I (in that case) did wrong. Don't you dare fix this when I'm almost done with my (shitty) llvm-ir code generator. I will be sad.
Re: C++ - D converter mentioned in AMA
On Thursday, 3 October 2013 at 10:42:32 UTC, Szymon Gatner wrote: Andrei's AMA has interesting answer: One of the main D(md) contributors, Daniel Murphy is working on automatic conversion tool that eventually will convert DMD's C++ codebase to D. Is this tool already available? Are there any guidelines about how to code in C++ to ease the conversion preocess (or even make it possible). I would be VERY interested in such a tool when the time comes so in the mean time I could slowly fix existing C++ codebase for future conversion. 1st of all, Daniel Murphy vel yebblies rox. 2nd, I was the one who responded at Andrei's AMA thread :p 3rd, Andrei's response is the killer one, http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/ccjusx7
Re: std.d.lexer : voting thread
On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote: After brief discussion with Brian and gathering data from the review thread, I have decided to start voting for `std.d.lexer` inclusion into Phobos. - [...] Thanks for your attention. Yes. (Btw, someone got benchmarks of std.d.lexer? I remember that Brain was benchmarking his module quite a lot in order to catch up with DMD's lexer but I can't find links in IRC logs. I wonder if he achieved his goal in this regard)
Re: Move VisualD to github/d-programming-language ?
On 9/10/13, Walter Bright newshou...@digitalmars.com wrote: noexcept means the function doesn't throw any exceptions. But it doesn't check! The above code compiles, and then fails at runtime. The opportunity for D is to deliver what C++ has promised. I wish we called it 'noexcept' as well instead of 'nothrow', because Throwables and Errors are still allowed to escape. When you're interfacing with other languages (e.g. passing a callback), you have to make sure *no* exceptions escape in the C callback. Marking the callback with nothrow only gets us one step close to that.
Re: std.d.lexer : voting thread
On Thursday, 3 October 2013 at 19:07:03 UTC, nazriel wrote: (Btw, someone got benchmarks of std.d.lexer? I remember that Brain was benchmarking his module quite a lot in order to catch up with DMD's lexer but I can't find links in IRC logs. I wonder if he achieved his goal in this regard) The most recent set of timings that I have can be found here: https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times4.png They're a bit old at this point, but not much has changed in the lexer internals. I can try running another set of benchmarks soon. (The hardest part is hacking DMD to just do the lexing) The times on the X-axis are milliseconds.
Re: std.d.lexer : voting thread
On Thursday, 3 October 2013 at 19:07:03 UTC, nazriel wrote: On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote: ... Please keep btws in separate thread :)
Re: std.d.lexer : voting thread
On Wednesday, 2 October 2013 at 14:41:56 UTC, Dicebot wrote: If you need to ask any last moment questions before making your decision, please do it in last review thread (linked in beginning of this post). Voting will last until the next weekend (Oct 12 23:59 GMT +0) Thanks for your attention. I sadly have to vote no in the current state. It is really needed to be able to reuse the same pool of identifier across several lexing (otherwize tooling around this lexer won't be able to manage mixins properly unless rolling its own identifier pool on top of the lexer's). This require the interface to change, so can't be introduced in a latter version without major breakage. I'd vote yes if above condition is met or to integrate current module as experimental (not in std).
std.d.lexer performance (WAS: std.d.lexer : voting thread)
On 10/3/13 12:47 PM, Brian Schott wrote: On Thursday, 3 October 2013 at 19:07:03 UTC, nazriel wrote: (Btw, someone got benchmarks of std.d.lexer? I remember that Brain was benchmarking his module quite a lot in order to catch up with DMD's lexer but I can't find links in IRC logs. I wonder if he achieved his goal in this regard) The most recent set of timings that I have can be found here: https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times4.png They're a bit old at this point, but not much has changed in the lexer internals. I can try running another set of benchmarks soon. (The hardest part is hacking DMD to just do the lexing) The times on the X-axis are milliseconds. I see we're considerably behind dmd. If improving performance would come at the price of changing the API, it may be sensible to hold off adoption for a bit. Andrei
Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)
On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu wrote: On 10/3/13 12:47 PM, Brian Schott wrote: On Thursday, 3 October 2013 at 19:07:03 UTC, nazriel wrote: (Btw, someone got benchmarks of std.d.lexer? I remember that Brain was benchmarking his module quite a lot in order to catch up with DMD's lexer but I can't find links in IRC logs. I wonder if he achieved his goal in this regard) The most recent set of timings that I have can be found here: https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times4.png They're a bit old at this point, but not much has changed in the lexer internals. I can try running another set of benchmarks soon. (The hardest part is hacking DMD to just do the lexing) The times on the X-axis are milliseconds. I see we're considerably behind dmd. If improving performance would come at the price of changing the API, it may be sensible to hold off adoption for a bit. Andrei Considerably? They look very similar to me. dmd is just slightly winning.
Re: std.rational -- update and progress towards review
On Thursday, 3 October 2013 at 18:42:30 UTC, Jacob Carlborg wrote: On 2013-10-03 16:36, Dicebot wrote: That is a bit frustrating part - we (reviewers) kind of want stuff cleanly separated between modules for further re-usage but at the same time we will make your life hell when reviewing how exactly this stuff needs to be incorporated :P Every time I asked that some functionality should be place somewhere else because it's generally useable I just got a No, we keep here, private, for now. We don't have a good public API for it. I guess I need to re-read the very first thread then :)
Re: Anyone used LLVM-D with Dub?
On Thursday, 3 October 2013 at 18:46:02 UTC, 1100110 wrote: On 10/03/2013 01:20 PM, Moritz Maxeiner wrote: On Thursday, 3 October 2013 at 00:37:39 UTC, Alan wrote: I just put the package in the dependencies and import it in my code then it does that, haven't even used any functions yet. (When building of course) Now that code.dlang.org is reachable again I was able to reproduce your error with a dub init project that had llvm-d added to the dependencies. Interestingly enough, building llvm-d into a static library and linking a default app.d against that works, yet using the same modules in the same order and compiling them with that same app.d directly into an application triggers the issue you encountered. Quite frankly, I do not know why that is, because going over the relevant source files has not lead me to any incorrect code, which leaves me with only two possible explanations: 1) I've unknowningly done something in my code that isn't actually allowed and that for some reason gets ignored when compiling as a libarary. 2) A compiler bug that happens when trying to compile multiple modules at the same time. I do not know which one it is, but it may be time to ask one of the compiler devs about it, as it is possible you may indeed have found a compiler bug - and if it is not a bug they may be able to tell us what I (in that case) did wrong. Don't you dare fix this when I'm almost done with my (shitty) llvm-ir code generator. I will be sad. Why would you need to create a llvm-ir code generator? You can use llvm-d the way it's described in the repo, at least. Or deimos-llvm.
Re: ctrl+c and destructors
On 10/3/2013 1:02 AM, Max Samukha wrote: That famous prejudice of yours :). Not just me, and I didn't invent it. It's a prejudice used by experienced engineers who build things that, if they fail, kill people. That prejudice is relearned, over and over, by bitter experience. As always, it depends. The application can't recover but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely. You've got a badly designed program if it relies on that to recover user data.
Re: Anyone used LLVM-D with Dub?
On Wednesday, 2 October 2013 at 02:22:42 UTC, Alan wrote: Hello! I'm working on a project and I was going to use LLVM with the LLVM-D wrapper which has it's own Dub package and everything https://github.com/Calrama/llvm-d I've installed the package with Dub, added it to my packages/builds dependencies. When I build however I get an error: Linking... /usr/bin/ld: error: /home/apott/projects/Hyphen/temp.o: multiple definition of '_D4llvm1d2ir10basicblock10BasicBlock16removeFromParentMFZv' /usr/bin/ld: /home/apott/projects/Hyphen/temp.o: previous definition here /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir8constant8Constant6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir11globalvalue11GlobalValue6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir12llvmfunction8Function6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir9constants10UndefValue6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' collect2: error: ld returned 1 exit status --- errorlevel 1 Error: Link command failed with exit code 1 I want to know if anyone here has any experience witht his by any chance? The source of the problem? Is it a bug? Thanks for any suggestions. The errors are now fixed in llvm-d master. They were very silly typos I overlooked repeatedly. Shame on me.
Re: ctrl+c and destructors
On Thursday, 3 October 2013 at 20:54:00 UTC, Walter Bright wrote: On 10/3/2013 1:02 AM, Max Samukha wrote: That famous prejudice of yours :). Not just me, and I didn't invent it. It's a prejudice used by experienced engineers who build things that, if they fail, kill people. That prejudice is relearned, over and over, by bitter experience. Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. You can't put every use case into the same bag... As always, it depends. The application can't recover but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely. You've got a badly designed program if it relies on that to recover user data.
Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)
On 10/3/13 1:15 PM, Brad Anderson wrote: On Thursday, 3 October 2013 at 20:11:02 UTC, Andrei Alexandrescu wrote: On 10/3/13 12:47 PM, Brian Schott wrote: On Thursday, 3 October 2013 at 19:07:03 UTC, nazriel wrote: (Btw, someone got benchmarks of std.d.lexer? I remember that Brain was benchmarking his module quite a lot in order to catch up with DMD's lexer but I can't find links in IRC logs. I wonder if he achieved his goal in this regard) The most recent set of timings that I have can be found here: https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times4.png They're a bit old at this point, but not much has changed in the lexer internals. I can try running another set of benchmarks soon. (The hardest part is hacking DMD to just do the lexing) The times on the X-axis are milliseconds. I see we're considerably behind dmd. If improving performance would come at the price of changing the API, it may be sensible to hold off adoption for a bit. Andrei Considerably? They look very similar to me. dmd is just slightly winning. To me 10% is considerable. Andrei
Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)
Please express your opinion in a clear Yes, No or Yes, if form. I can't really interpret discussions into voting results. Of course, you and Walter also have veto votes in addition but it needs to be said explicitly.
Re: ctrl+c and destructors
On Thu, Oct 03, 2013 at 11:15:11PM +0200, nazriel wrote: On Thursday, 3 October 2013 at 20:54:00 UTC, Walter Bright wrote: On 10/3/2013 1:02 AM, Max Samukha wrote: That famous prejudice of yours :). Not just me, and I didn't invent it. It's a prejudice used by experienced engineers who build things that, if they fail, kill people. That prejudice is relearned, over and over, by bitter experience. Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. Run the plugin in a sandbox. T -- INTEL = Only half of intelligence.
Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)
On 10/3/13 3:03 PM, Dicebot wrote: Please express your opinion in a clear Yes, No or Yes, if form. I can't really interpret discussions into voting results. Of course, you and Walter also have veto votes in addition but it needs to be said explicitly. That's why I renamed the thread! I didn't vote. Andrei
Re: review queue: next?
On Thursday, 3 October 2013 at 14:43:55 UTC, ilya-stromberg wrote: On Thursday, 3 October 2013 at 14:23:42 UTC, Dicebot wrote: On Thursday, 3 October 2013 at 14:13:58 UTC, ilya-stromberg wrote: What happens if I vote Yes with condition, but module developer will not satisfy the condition? My vote will be calculated as No, as Yes, or will not calculated at all? In which term module developer should satisfy the condition if he wants to do this? Before merge pull request to the Phobos? Initially it will be counted as No vote. Then, if clear Yes vote count is not enough to get the module into Phobos, Yes, but votes will be evaluated. If those can make the difference, module author will be given the opportunity to satisfy the condition(s) and turn this vote into clear Yes without any additional formal review and/or voting. If those do not make the difference, proposal is simply marked as rejected. OK, I see. How many conditions I can add? Only one, a few related (for example, documentation issues), or unlimited? The goal is to make it as quick as possible to get the submission into Phobos. If there is one item which you consider strong about should prevent the inclusion then it allows the Review Manager to switch your vote to a yes when that is resolved. But it also has the benefit that the maintainer could put it at the top of his list of improvements even if it is accepted. If you have more than one, tracking the state of the vote is too challenging. Similarly if it is not specific than there is no way for a Review Manager can't judge when it matches your opinion. You could say something like Yes if Documentation is improved by, changing ___ and ___. This is a blocker. Note you could list hundreds of conditions, but the Review Manager can choose to (and recommended to) just take that as No and the maintainer would have no obligation to response.
Inline assembly and CTFE
As of DMD 2.063.2 it looks to me like inline assembly language
blocks are not usable in compile-time code. For example, the
following code
void main() {
enum a = abc();
}
ulong abc() {
asm { mov RAX,1; }
return 1;
}
will produce the error Error: asm statements cannot be
interpreted at compile time.
Are there plans to eventually support the use of asm blocks in
CTFE?
If it were possible then I could use such a function in a static
if test. What I am looking to do is use a function that calls
CPUID (etc.) in a static if statement to determine which code to
generate, somewhat like the following.
bool isAVXPossible() { asm { ... use CPUID, etc. ... } }
void foo() {
static if(isAVXPossible()) {
asm { ... generate AVX version ... }
else {
asm { ... generate non AVX version ... }
}
}
I cannot use version(D_SIMD) because I need some more specificity
in the versioning. Similarly, version(X86) and version(X86_64)
are convenient but I would like to be more exact. Also, I tried
the functionality in core.cpuid but it also seems only able to
execute at run-time. When trying to use it in a static if
statement I get the error Error: static variable xfeatures
cannot be read at compile time.
Any ideas on how to implement isAVXPossible() and its related
functionality without using a runtime test are appreciated.
Thanks
Joseph
Re: std.d.lexer performance (WAS: std.d.lexer : voting thread)
On Thursday, 3 October 2013 at 22:18:13 UTC, Andrei Alexandrescu wrote: On 10/3/13 3:03 PM, Dicebot wrote: Please express your opinion in a clear Yes, No or Yes, if form. I can't really interpret discussions into voting results. Of course, you and Walter also have veto votes in addition but it needs to be said explicitly. That's why I renamed the thread! I didn't vote. Andrei I mean I will be forced to ignore your opinion in current form when making voting summary and I will feel very uneasy about it :) (damn, that review manager thingy gets much more stressful by the end!)
Re: Inline assembly and CTFE
On Thursday, 3 October 2013 at 22:25:27 UTC, Joseph Cassman wrote: Are there plans to eventually support the use of asm blocks in CTFE? No. Any ideas on how to implement isAVXPossible() and its related functionality without using a runtime test are appreciated. What would you even want the function to return in the first place? The CPU features you can use obviously depend on the specific CPU the executable will run on, so the answer can't generally by known at compile time. Do you want to base your decision on the CPU of the build host? Or are you looking for an efficient way to implement the runtime check? David
Re: ctrl+c and destructors
On 10/3/2013 2:15 PM, nazriel wrote: Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. How does the music player know the fault is in the plugin and it could be safely continued? It doesn't. It cannot. With a shared address space, it could be anywhere. You can't put every use case into the same bag... I doubt the users would be pleased if continuing running the program resulted in further corruption of the system, including the user's data. Yes, and I've used music players that did that. It sux having to rebuild the music database from backups every time. It doesn't make me think kindly of the player's developers. A properly designed system with user-supplied plugins that needed to recover from plugin failure would put those plugins in a separate process space, so when they crash they cannot affect the rest of the system. Any other scheme is just a bad design, although it may be convenient from a developer cost standpoint to write it that way. And lastly, such badly designed plugin systems are rich vectors for people to insert malware into your system. See ActiveX for an example.
Re: Inline assembly and CTFE
On Thursday, 3 October 2013 at 22:30:24 UTC, David Nadlinger wrote: On Thursday, 3 October 2013 at 22:25:27 UTC, Joseph Cassman wrote: Are there plans to eventually support the use of asm blocks in CTFE? No. Any ideas on how to implement isAVXPossible() and its related functionality without using a runtime test are appreciated. What would you even want the function to return in the first place? The CPU features you can use obviously depend on the specific CPU the executable will run on, so the answer can't generally by known at compile time. Do you want to base your decision on the CPU of the build host? Or are you looking for an efficient way to implement the runtime check? David And if decision is based on build host it makes much more sense to incorporate check into the build process and supply results to main program in a form of manual version. At least in that way it will be perfectly clear that this is intended behavior.
Re: Inline assembly and CTFE
On 10/3/2013 3:25 PM, Joseph Cassman wrote:
As of DMD 2.063.2 it looks to me like inline assembly language blocks are not
usable in compile-time code. For example, the following code
void main() {
enum a = abc();
}
ulong abc() {
asm { mov RAX,1; }
return 1;
}
will produce the error Error: asm statements cannot be interpreted at compile
time.
Are there plans to eventually support the use of asm blocks in CTFE?
No. Simulating a CPU is way, way beyond its charter.
If it were possible then I could use such a function in a static if test. What I
am looking to do is use a function that calls CPUID (etc.) in a static if
statement to determine which code to generate, somewhat like the following.
bool isAVXPossible() { asm { ... use CPUID, etc. ... } }
void foo() {
static if(isAVXPossible()) {
asm { ... generate AVX version ... }
else {
asm { ... generate non AVX version ... }
}
}
I cannot use version(D_SIMD) because I need some more specificity in the
versioning. Similarly, version(X86) and version(X86_64) are convenient but I
would like to be more exact. Also, I tried the functionality in core.cpuid but
it also seems only able to execute at run-time. When trying to use it in a
static if statement I get the error Error: static variable xfeatures cannot be
read at compile time.
Any ideas on how to implement isAVXPossible() and its related functionality
without using a runtime test are appreciated.
But you don't want a compile time test for that! You want a runtime test, as it
should depend on what machine the program is running under, which may not at all
be the same one it compiled on.
Re: Inline assembly and CTFE
With LLVM it's possibly to fully remove interpreter from compiler and use JIT.
Re: ctrl+c and destructors
On 04.10.2013 00:38, Walter Bright wrote: On 10/3/2013 2:15 PM, nazriel wrote: Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. How does the music player know the fault is in the plugin and it could be safely continued? It doesn't. It cannot. With a shared address space, it could be anywhere. You can't put every use case into the same bag... I doubt the users would be pleased if continuing running the program resulted in further corruption of the system, including the user's data. Yes, and I've used music players that did that. It sux having to rebuild the music database from backups every time. It doesn't make me think kindly of the player's developers. A properly designed system with user-supplied plugins that needed to recover from plugin failure would put those plugins in a separate process space, so when they crash they cannot affect the rest of the system. Any other scheme is just a bad design, although it may be convenient from a developer cost standpoint to write it that way. And lastly, such badly designed plugin systems are rich vectors for people to insert malware into your system. See ActiveX for an example. This is actually one of the reasons Go guys are so opinated against dynamic linking. I used to complain about it on gonuts forums, but eventually came to realize, that I was a bit spoiled by dynamic loading for plugins and the old UNIX model of processes for plugins is what makes more sense from the security point of view. And it is the trend we are seeing nowadays with the integration of micro-kernel techniques in mainstream OSs. Gatekeeper in Mac OS X/iOS, user space drivers in Windows, FF and Chrome plugin APIs, ... Plugins as dynamic libraries open the door for great customizations, but they open the door for possible instability of the host application and security exploits. -- Paulo
Re: Inline assembly and CTFE
On Thursday, 3 October 2013 at 23:02:18 UTC, Temtaime wrote: With LLVM it's possibly to fully remove interpreter from compiler and use JIT. I don't see how this is relevant to the discussion here, i.e. whether there are plans to support inline assembler in CTFE. David
Re: std.d.lexer : voting thread
On Thursday, 3 October 2013 at 19:47:28 UTC, Brian Schott wrote: The most recent set of timings that I have can be found here: https://raw.github.com/Hackerpilot/hackerpilot.github.com/master/experimental/std_lexer/images/times4.png How exactly were these figures obtained? Based on the graphs, I'd guess that you measured execution time of a complete program (as LDC, which has a slightly higher startup overhead in druntime, overtakes GDC for larger inputs). If that's the case, DMD might be at an unfair advantage for this benchmark as it doesn't need to run all the druntime startup code – which is not a lot, but still. And indeed, its advantage seems to shrink for large inputs, although I don't want to imply that this could be the only reason. David
Re: ctrl+c and destructors
On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote: On 10/3/2013 2:15 PM, nazriel wrote: Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. How does the music player know the fault is in the plugin and it could be safely continued? Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user. A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong. A media player won't kill anyone. A properly designed system with user-supplied plugins that needed to recover from plugin failure would put those plugins in a separate process space, so when they crash they cannot affect the rest of the system. Any other scheme is just a bad design, although it may be convenient from a developer cost standpoint to write it that way. Yes. Anything is a cost benefit tradeoff. The cost of developing a sandboxing solution is way higher than doing some recovery that will fail in 1% of the case in a way that won't kill anyone. And unless phobos get a sandboxing solution builtin, the argument will stand.
Re: C++ - D converter mentioned in AMA
On 10/03/2013 12:52 PM, simendsjo wrote: I think Daniel Murphys tool is aimed directly at the DMD codebase. That's it's key feature, any attempt to first come up with a generic tool would be doomed to fail. Also DMD's code base uses only a limited subset of C++ which makes it more amenable to automatic translation.
Re: Inline assembly and CTFE
Dicebot: And if decision is based on build host it makes much more sense to incorporate check into the build process and supply results to main program in a form of manual version. At least in that way it will be perfectly clear that this is intended behavior. Static CPU introspection could be handy sometimes, if you want to run the code in the same system you have used to compile the code, and avoid run-time CPU tests. Bye, bearophile
Re: ctrl+c and destructors
On Thursday, 3 October 2013 at 23:18:32 UTC, deadalnix wrote: And unless phobos get a sandboxing solution builtin, the argument will stand. pipeProcess is an ok starting point. (Though when I tried to use it recently, the fact that it didn't support async i/o on Windows meant I had to roll my own anyway...) but if you spawned the plugin as a process and then just sent/received messages through the pipes it isn't too hard to make an application out of it, especially with an rpc library too.
Re: ctrl+c and destructors
On Friday, October 04, 2013 01:18:31 deadalnix wrote: On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote: On 10/3/2013 2:15 PM, nazriel wrote: Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. How does the music player know the fault is in the plugin and it could be safely continued? Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user. A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong. A media player won't kill anyone. Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken. - Jonathan M Davis
Re: ctrl+c and destructors
On 04.10.2013 01:49, Jonathan M Davis wrote: On Friday, October 04, 2013 01:18:31 deadalnix wrote: On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote: On 10/3/2013 2:15 PM, nazriel wrote: Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. How does the music player know the fault is in the plugin and it could be safely continued? Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user. A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong. A media player won't kill anyone. Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken. - Jonathan M Davis Fully agree. We only got in the sore point of today's industry quality because people got used to have broken applications. Noone is happy driving a car that kind of works, shoes with shoelaces that will only work in nights of full moon, Quality should be always a concern, not only when people lives are at stake. -- Paulo
Re: ctrl+c and destructors
On 10/3/2013 4:49 PM, Jonathan M Davis wrote: Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken. Exactly. Note that memory corruption can also result in corruption of user data, as I mentioned, and it can ALSO result in corruption of your system. The music player can read and write files, right? Kaboom. I was just talking to Andrei earlier about the bad old MSDOS programming days. There, if you had an errant pointer, it didn't seg fault. It would scramble the operating system tables, and having YOUR HARD DISK SCRAMBLED was a not uncommon experience. Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die.
Re: ctrl+c and destructors
On Thu, Oct 03, 2013 at 07:49:16PM -0400, Jonathan M Davis wrote: On Friday, October 04, 2013 01:18:31 deadalnix wrote: On Thursday, 3 October 2013 at 22:38:18 UTC, Walter Bright wrote: On 10/3/2013 2:15 PM, nazriel wrote: Music player (as example) do not kill people if they fail. Aborting whole music player just because Visualisation plugin had access violation is pointless. How does the music player know the fault is in the plugin and it could be safely continued? Because a music player can ALWAYS safely continue. Worst case scenario, if behave erratically and is killed by user. A car firmware kill people if they behave erratically. The right choice is to kill it if anything look wrong. A media player won't kill anyone. Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken. [...] Reminds me of a GUI app I tried years ago, that suffered from some kind of memory corruption bug. Every now and then it would segfault due to hitting the corruption... one time, it *didn't* segfault, but continued merrily on and corrupted all of my data -- worth many hours of work -- all without showing any signs of problems, and then out of habit I saved the file I was working on, and it barged ahead and wrote garbage all over my last good copy of the data. :-( Now, I don't think it had segfault recovery, but even without, it was already bad enough. I don't think I ever want to find out what that program would've done if it came *with* segfault recovery... (think about all those times it crashed *before* the bad data got saved into the file.) T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
Re: Inline assembly and CTFE
On Thursday, 3 October 2013 at 23:21:56 UTC, bearophile wrote: Static CPU introspection could be handy sometimes, if you want to run the code in the same system you have used to compile the code, and avoid run-time CPU tests. The reason why this wouldn't be particularly useful with DMD right now is that its backend doesn't make use of any non-generic instructions by default, and as such it is lacking the command line flags, … to control what CPU to target. And the cases where just optimizing for the host CPU by default is a good idea are rather rare – we LDC guys learned that the hard way when we accidentally had the equivalent of -march=native for GCC enabled by default without anybody knowing. David
Re: ctrl+c and destructors
On Thu, Oct 03, 2013 at 05:04:02PM -0700, Walter Bright wrote: On 10/3/2013 4:49 PM, Jonathan M Davis wrote: Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken. Exactly. Note that memory corruption can also result in corruption of user data, as I mentioned, and it can ALSO result in corruption of your system. The music player can read and write files, right? Kaboom. I was just talking to Andrei earlier about the bad old MSDOS programming days. There, if you had an errant pointer, it didn't seg fault. It would scramble the operating system tables, and having YOUR HARD DISK SCRAMBLED was a not uncommon experience. Ah yes, those were the days when you *always* kept a full backup of a fully-working snapshot of your OS and dev environment on a separate floppy, so that when your program inevitably crashed / destroyed the OS, you could power off and reboot from the good copy (and promptly make another copy thereafter, in order to not also destroy the last good disk!). Hitting reset / power cycling several times an hour was pretty common, since the most trivial of bugs easily caused the system to hang, or get stuck in graphics mode with no way to (easily) switch it back, or lock up the keyboard somehow, or do any number of other erratic things. Write to a wrong memory address (e.g., dereference a wrong pointer), and boom, you just broke DOS in a subtle way that only shows up the next time you write to a file. Write to another wrong memory address, and boom, one of DOS's core routines got overwritten, now disk I/O doesn't work, or DOS just hangs and won't respond to anything. Jump to an invalid func ptr with the wrong value, and boom, you just entered the DOS FORMAT routine. Bye bye sweet data, it was nice knowing you. Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die. Heh, my Perl script actually picked a vaguely relevant signature line on its own this time, without manual intervention. :-P T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Re: ctrl+c and destructors
On Oct 3, 2013, at 4:49 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken. I'm inclined to agree. However, in this case the user will need some method to remove the broken plugin or the app will be perpetually broken. It wouldn't surprise me if the original motivation for trying to withstand failures was a bad decision motivated by something like this, and at some point it was erroneously considered a feature. I'd prefer to be notified that a crash was likely caused by a bad plugin and given the option to restart in safe mode, though.
Re: Anyone used LLVM-D with Dub?
On Thursday, 3 October 2013 at 21:18:33 UTC, Moritz Maxeiner wrote: On Wednesday, 2 October 2013 at 02:22:42 UTC, Alan wrote: Hello! I'm working on a project and I was going to use LLVM with the LLVM-D wrapper which has it's own Dub package and everything https://github.com/Calrama/llvm-d I've installed the package with Dub, added it to my packages/builds dependencies. When I build however I get an error: Linking... /usr/bin/ld: error: /home/apott/projects/Hyphen/temp.o: multiple definition of '_D4llvm1d2ir10basicblock10BasicBlock16removeFromParentMFZv' /usr/bin/ld: /home/apott/projects/Hyphen/temp.o: previous definition here /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir8constant8Constant6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir11globalvalue11GlobalValue6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir12llvmfunction8Function6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' /home/apott/projects/Hyphen/temp.o:../../.dub/packages/llvm-d-master/llvm/d/ir/globalvariable.d:function _D4llvm1d2ir9constants10UndefValue6__vtblZ: error: undefined reference to '_D4llvm1d2ir8constant8Constant27replaceUsesOfWithOnConstantMFC4llvm1d2ir5value5ValueC4llvm1d2ir5value5ValueC4llvm1d2ir3use3UseZv' collect2: error: ld returned 1 exit status --- errorlevel 1 Error: Link command failed with exit code 1 I want to know if anyone here has any experience witht his by any chance? The source of the problem? Is it a bug? Thanks for any suggestions. The errors are now fixed in llvm-d master. They were very silly typos I overlooked repeatedly. Shame on me. Awesome! Thanks a lot everyone who responded, and thanks for fixing it mate!
Re: Inline assembly and CTFE
On Thursday, 3 October 2013 at 22:40:14 UTC, Walter Bright wrote: Are there plans to eventually support the use of asm blocks in CTFE? No. Simulating a CPU is way, way beyond its charter. Good to know. Thanks. But you don't want a compile time test for that! You want a runtime test, as it should depend on what machine the program is running under, which may not at all be the same one it compiled on. Thanks for the other two comments along these lines as well. Of course a build script tends to take care of such considerations, I was looking for a way to do it as much in D as possible. And yes, it was for the idea of building and running on the same processor type. Appreciate the input. Joseph
Re: ctrl+c and destructors
On 10/4/13, Walter Bright newshou...@digitalmars.com wrote: Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die. Then why did you introduce the Error exception type into the language in the first place? I mean why would you let exceptions propagate up the call stack if the state of the program is seriously compromised? Why not just call the system's exit() function? If nobody up the call stack could do anything useful, then there's no point in walking up the call stack. And yet we have Error that does exactly that. What I'm saying is the act of throwing an Error itself is an act of continuing program execution after a serious failure. And here you are arguing against it.
Re: Inline assembly and CTFE
On Thursday, 3 October 2013 at 22:30:24 UTC, David Nadlinger wrote: What would you even want the function to return in the first place? The CPU features you can use obviously depend on the specific CPU the executable will run on, so the answer can't generally by known at compile time. Do you want to base your decision on the CPU of the build host? Or are you looking for an efficient way to implement the runtime check? David Good questions. Yeah, the answer can't be generally known at compile time. But can be interesting in the specific case (i.e. when I can control both the build machine and the one it will eventually run on). The function in the example is a flag similar to core.cpuid.avx (http://dlang.org/phobos/core_cpuid.html#.avx). Was mainly looking for some feedback on the plans for the scope of CTFE in regards to assembly language. Thanks for the input. Joseph
Re: Anyone used LLVM-D with Dub?
On 10/03/2013 03:37 PM, Moritz Maxeiner wrote: On Thursday, 3 October 2013 at 18:46:02 UTC, 1100110 wrote: On 10/03/2013 01:20 PM, Moritz Maxeiner wrote: On Thursday, 3 October 2013 at 00:37:39 UTC, Alan wrote: I just put the package in the dependencies and import it in my code then it does that, haven't even used any functions yet. (When building of course) Now that code.dlang.org is reachable again I was able to reproduce your error with a dub init project that had llvm-d added to the dependencies. Interestingly enough, building llvm-d into a static library and linking a default app.d against that works, yet using the same modules in the same order and compiling them with that same app.d directly into an application triggers the issue you encountered. Quite frankly, I do not know why that is, because going over the relevant source files has not lead me to any incorrect code, which leaves me with only two possible explanations: 1) I've unknowningly done something in my code that isn't actually allowed and that for some reason gets ignored when compiling as a libarary. 2) A compiler bug that happens when trying to compile multiple modules at the same time. I do not know which one it is, but it may be time to ask one of the compiler devs about it, as it is possible you may indeed have found a compiler bug - and if it is not a bug they may be able to tell us what I (in that case) did wrong. Don't you dare fix this when I'm almost done with my (shitty) llvm-ir code generator. I will be sad. Why would you need to create a llvm-ir code generator? You can use llvm-d the way it's described in the repo, at least. Or deimos-llvm. had issues with 'em. Decided it would be easier to write my own than to figure out my problems. shrugs. It's a learning excercise. I was mostly joking. =P
Re: ctrl+c and destructors
On Friday, October 04, 2013 02:55:36 Andrej Mitrovic wrote: On 10/4/13, Walter Bright newshou...@digitalmars.com wrote: Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die. Then why did you introduce the Error exception type into the language in the first place? I mean why would you let exceptions propagate up the call stack if the state of the program is seriously compromised? Why not just call the system's exit() function? If nobody up the call stack could do anything useful, then there's no point in walking up the call stack. And yet we have Error that does exactly that. What I'm saying is the act of throwing an Error itself is an act of continuing program execution after a serious failure. And here you are arguing against it. I've actually been wondering about that too. The only case I can think of where catching an Error and continuing _might_ make sense would be with OutOfMemoryError if you caught it right after it was thrown and then did something differently based on the fact that you'd run out of memory. But pretty much all other Errors are outright programming bugs, and all you really need is the stacktrace. Unwinding the stack (even with skipping destructors, finally blocks, etc.) seems extraneous at that point. - Jonathan M Davis
Re: mixin module template - undefined identifier
2013/10/4 Robert Schadek realbur...@gmx.de
On 10/03/2013 08:10 PM, David Nadlinger wrote:
On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:
dmd moduleA.d moduleB.d -ofmix -unittest
moduleA.d(4): Error: undefined identifier Foo
moduleB.d(10): Error: template instance A.func!(Foo) error instantiating
Yes, this is indeed very much by design – A does not import B, so
there is no reason why the name Foo should exist in A.
Yes, it does not exists in the module but func is a template and I was
under the impression symbols would be seen when instantiated. I mean the
error starts with A.func!(Foo) error instantiating.
To access the template parameter, just use it directly in the mixin
(as in »mixin(T.fun())«). I'm aware that the situation where you
actually stumbled over this is probably a bit more complex, but in my
experience an equivalent rewrite can almost always be performed quite
easily once you have wrapped your head around the concept.
Not as easy to fix this as I have a library that generates me sqlite
code at compile time which I than mixin to have as good as handwritten
code. I just found it odd that it works if I instantiate the template
from the same module.
Using built-in 'stringof' property for code generation won't work in
general. Instead:
public int func(T)() {
return mixin(T ~ .fun());
}
Kenji Hara
Re: ctrl+c and destructors
On 10/3/2013 5:55 PM, Andrej Mitrovic wrote: On 10/4/13, Walter Bright newshou...@digitalmars.com wrote: Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die. Then why did you introduce the Error exception type into the language in the first place? I mean why would you let exceptions propagate up the call stack if the state of the program is seriously compromised? Why not just call the system's exit() function? If nobody up the call stack could do anything useful, then there's no point in walking up the call stack. And yet we have Error that does exactly that. What I'm saying is the act of throwing an Error itself is an act of continuing program execution after a serious failure. And here you are arguing against it. Error exceptions are not necessarily program bugs. They are non-recoverable errors, which is not the same thing.
Re: mixin module template - undefined identifier
On Thursday, 3 October 2013 at 18:39:48 UTC, Robert Schadek wrote: Yes, it does not exists in the module but func is a template and I was under the impression symbols would be seen when instantiated. No. D doesn't have something like C++'s ADL where the template arguments lead to additional names being introduced into the scope of the template body. This is by design. I mean the error starts with A.func!(Foo) error instantiating. Sorry, I don't quite get what you mean here. The error is just a follow-up to the previous one, as the inability to look up Foo caused an error while instantiating that template. Not as easy to fix this as I have a library that generates me sqlite code at compile time which I than mixin to have as good as handwritten code. I just found it odd that it works if I instantiate the template from the same module. Maybe you can elaborate a bit on how the problem occurs in that context? As I said, I've found that usually it is possible to come up with a design at least as pretty (or even prettier) but doesn't rely on stringof trickery if one just stares at the problem long enough. ;) David
Re: std.d.lexer : voting thread
On 10/02/2013 04:41 PM, Dicebot wrote: After brief discussion with Brian and gathering data from the review thread, I have decided to start voting for `std.d.lexer` inclusion into Phobos. I also have to vote with no for now. My biggest concern is that the lexer incorporates a string pool, something that isn't strictly part of lexing. IMO this is a major design flaw and possible performance/memory issue. It is buried into the API because byToken takes const(byte)[], i.e. mutable data, but each Token carries a string value, so it always requires a copy. For stream oriented lexing, e.g. token highlighting, no string pool is required at all. Instead the value type of Token should be something like take(input.save, lengthOfToken). Why was the Tok!=, Tok!default idea turned down. This leaves us with undesirable names like Tok.shiftRightAssign, Tok.default_. There are a few smaller issues that haven't yet been addressed, but of course this can be done during the merge code review. Adding it as experimental module would be a good idea.
