Re: Dscience
On Friday, 2 March 2012 at 12:27:06 UTC, bioinfornatics wrote: Dear, I have do a D 2 port to my dscience project: https://gitorious.org/dscience/dscience Any help are welcome I'm willing to help but I've got a couple of other things I need to get out the door first. But I will take a look and see if there is some low-hanging fruit that I can work on. Paul
quickbar
quickbar-20120313-b.rar Description: Binary data
Re: quickbar
On 3/13/2012 3:06 AM, negerns wrote: I'm so sorry for that :( my bad! I hope it could be delete...
std.log review suspended
The extended review period for std.log has ended [1], and Jose, the author of the proposed module, has requested some extra time to incorporate the suggestions made during the review without ending up with a butchered design. Thus, the review process has been suspended as to not block the queue for too long. This also means that review can start on the next proposal immediately. From the records, std.uuid would be next – are we good to go, Johannes? Other suggestions? On a related note, I created a Trello card to keep track of review manager volunteers. So, if you are interested, please add yourself to it so that the next review can start smoothly (»Phobos Review Queue« board, request access at the Phobos ML). As always, thanks to everybody who participated, David [1] Or will end in a few hours, depending on how you interpret the messed-up date I had given in the announcement. Since this is not a vote anyway, I also didn't specify a time zone, so…
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 06:43, H. S. Teoh wrote: On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote: Consider the toHash() function for struct key types: http://dlang.org/hash-map.html And of course the others: const hash_t toHash(); const bool opEquals(ref const KeyType s); const int opCmp(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them Ah, I see the just add a new attribute thing is coming back to bite you. ;-) It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). I'm wary of the idea of automatically-imposed attributes on a special set of functions... seems a bit arbitrary, and arbitrary things don't tend to stand the test of time. OTOH I can see the value of this. Forcing all toHash's to be pure nothrow @safe makes is much easier to, for example, implement AA's purely in object_.d (which I'm trying to do :-P). You don't have to worry about somebody defining a toHash that does strange things. Same thing with opEquals, etc.. It also lets you freely annotate stuff that calls these functions as pure, nothrow, @safe, etc., without having to dig through every function in druntime and phobos to mark all of them. Here's an alternative (and perhaps totally insane) idea: what if, instead of needing to mark functions as pure, nothrow, etc., etc., we ASSUME all functions are pure, nothrow, and @safe unless they're explicitly declared otherwise? IOW, let all D code be pure, nothrow, and @safe by default, and if you want non-pure, or throwing code, or unsafe code, then you annotate the function as impure, throwing, or @system. It goes along with D's general philosophy of safe-by-default, unsafe-if-you-want-to. No. Too late in the design process. I have 20k+ lines of code that rely on the opposite behavior. Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user. No, that has API design issues. You can silently break a guarantee you made previously. T -- - Alex
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 07:04, Alex Rønne Petersen wrote: On 12-03-2012 06:43, H. S. Teoh wrote: On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote: Consider the toHash() function for struct key types: http://dlang.org/hash-map.html And of course the others: const hash_t toHash(); const bool opEquals(ref const KeyType s); const int opCmp(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them Ah, I see the just add a new attribute thing is coming back to bite you. ;-) It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). I'm wary of the idea of automatically-imposed attributes on a special set of functions... seems a bit arbitrary, and arbitrary things don't tend to stand the test of time. OTOH I can see the value of this. Forcing all toHash's to be pure nothrow @safe makes is much easier to, for example, implement AA's purely in object_.d (which I'm trying to do :-P). You don't have to worry about somebody defining a toHash that does strange things. Same thing with opEquals, etc.. It also lets you freely annotate stuff that calls these functions as pure, nothrow, @safe, etc., without having to dig through every function in druntime and phobos to mark all of them. Here's an alternative (and perhaps totally insane) idea: what if, instead of needing to mark functions as pure, nothrow, etc., etc., we ASSUME all functions are pure, nothrow, and @safe unless they're explicitly declared otherwise? IOW, let all D code be pure, nothrow, and @safe by default, and if you want non-pure, or throwing code, or unsafe code, then you annotate the function as impure, throwing, or @system. It goes along with D's general philosophy of safe-by-default, unsafe-if-you-want-to. No. Too late in the design process. I have 20k+ lines of code that rely on the opposite behavior. I should point out that I *do* think the idea is good (i.e. if you want the bad things, that's what you have to declare), but it's just too late now. Also, there might be issues with const and the likes - should the system assume const or immutable or inout or...? Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user. No, that has API design issues. You can silently break a guarantee you made previously. T -- - Alex
Re: Breaking backwards compatiblity
On Mon, Mar 12, 2012 at 01:36:06AM -0400, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.510.1331520028.4860.digitalmar...@puremagic.com... [...] Personally, I found discrete math to be the easiest class I took since kindergarten (*Both* of the times they made me take discrete math. Ugh. God that got boring.) It was almost entirely the sorts of things that any average coder already understands intuitively. Like DeMorgan's: I hadn't known the name DeMorgan, but just from growing up writing if statements I had already grokked how it worked and how to use it. No doubt in my mind that *all* of us here have grokked it (even any of us who might not know it by name) *and* many of the coworkers I've had who I'd normally classify as incompetent VB-loving imbiciles. It's not that I didn't already know most of the stuff intuitively, I found that, in retrospect, having to learn it formally helped to solidify my mental grasp of it, and to be able to analyse it abstractly without being tied to intuition. This later developed into the ability to reason about other stuff in the same way, so you could *derive* new stuff yourself in similar ways. Then there was Pidgeonhole principle, which was basically just obvious corollaries to preschool-level spacial relations. Etc. All pretty much BASIC-level stuff. Oh raally?! Just wait till you learn how the pigeonhole principle allows you to do arithmetic with infinite quantities... ;-) (And before you shoot me down with infinite quantities are not practical in programming, I'd like to say that certain non-finite arithmetic systems actually have real-life consequences in finite computations. Look up Hydra game sometime. Or Goldstein sequences if you're into that sorta thing.) [...] However, I also found that most big-name colleges are geared toward producing researchers rather than programmers in the industry. The colleges I've seen seemed to have an identity crisis in that regard: Sometimes they acted like their role was teaching theory, sometimes they acted like their role was job training/placement, and all the time they were incompetent at both. In my experience, I found that the quality of a course depends a LOT on the attitude and teaching ability of the professor. I've had courses which were like mind-openers every other class, where you just go wow, *that* is one heck of a cool algorithm!. Unfortunately, (1) most professors can't teach; (2) they're not *paid* to teach (they're paid to do research), so they regard it as a tedious chore imposed upon them that takes away their time for research. This makes them hate teaching, and so most courses suck. [...] I once made the mistake of signing up for a class that claimed to be part of the CS department and was titled Optimization Techniques. I thought it was obvious what it was and that it would be a great class for me to take. Turned out to be a class that, realistically, belonged in the Math dept and had nothing to do with efficient software, even in theory. Wasn't even in the ballpark of Big-O, etc. It was linear algebra with large numbers of variables. Aahahahahaha... must've been high-dimensional polytope optimization stuff, I'll bet. That stuff *does* have its uses... but yeah, that was a really dumb course title. Another dumb course title that I've encountered was along the lines of computational theory where 95% of the course talks about *uncomputable* problems. You'd think they would've named it *un*computational theory. :-P I'm sure it would be great material for the right person, but it wasn't remotely what I expected given the name and department of the course. (Actually, similar thing with my High School class of Business Law - Turned out to have *nothing* to do with business whatsoever. Never understood why they didn't just call the class Law or Civic Law.) Kinda felt baited and switched both times. [...] That's why I always took the effort read course descriptions VERY carefully before I sign up. It's like the fine print in contracts. You skip over it at your own peril. (Though, that didn't stop me from taking Number Theory. Or Set Theory. Both of which went wayy over my head for the most part.) T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Re: Breaking backwards compatiblity
On Mon, Mar 12, 2012 at 01:48:46AM -0400, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.517.1331521772.4860.digitalmar...@puremagic.com... On Sun, Mar 11, 2012 at 11:38:12PM +0100, deadalnix wrote: I think a better solution is including expected performances in the user stories and add them in the testing suite. Dev can enjoy a powerful machine without risking to get a resource monster as a final executable. Even better, have some way of running your program with artificially reduced speed resources, so that you can (sortof) see how your program degrades with lower-powered systems. Perhaps run the program inside a VM or emulator? I don't think such things would ever truly work, except maybe in isolated cases. It's an issue of dogfooding. But then these eat your cake and then still have it strategies ultimately mean that you're *not* actually doing the dogfooding, just kinda pretending to. Instead, you'd be eating steak seven days a week, occasionally do a half-bite of dogfooding, and immediately wash it down with...I dunno, name some fancy expensive drink, I don't know my wines ;) [...] Nah, it's like ordering extra large triple steak burger with double-extra cheese, extra bacon, sausage on the side, extra large french fries swimming in grease, and _diet_ coke to go with it. T -- Blunt statements really don't have a point.
Re: Feq questions about the D language
On Sunday, March 11, 2012 21:33:23 Andrei Alexandrescu wrote: At any rate, the comparison is rigged because C++ is much more mature and invested in. It _is_ rigged, but if a programmer is used to more mature languages where they don't run into compiler bugs, and they try out a new one where they _do_ run into compiler bugs, that's going to give a very negative impression. I don't know that there's much of anything that we can do about that though - other than fix bugs (especially the more important ones) as fast as we can. That's just the way it goes with a less mature language. We'll reach that level of stability eventually though, and we _have_ been making great strides with the huge number of bugs which have been fixed of late. - Jonathan M Davis
Re: Multiple return values...
On 03/12/2012 05:01 AM, Robert Jacques wrote:
On Sun, 11 Mar 2012 21:49:52 -0500, Mantis mail.mantis...@gmail.com
wrote:
12.03.2012 4:00, Robert Jacques пишет:
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical, but it is certainly there.
void main(){
auto a = foo(); // MRV/struct return
bar(a.x); // defined in a different compilation unit
}
struct return has to write out the whole struct on the stack because of
layout guarantees, probably making the optimized struct return calling
convention somewhat slower for this case. The same does not hold for
MRV.
The layout of the struct only has to exist _when_ the address is
taken. Before that, the compiler/language/optimizer is free to (and
does) do whatever it want. Besides, in your example only the address
of a field is taken, the compiler will optimize away all the other
pieces a (dead variable elimination).
That's the point of discussion. Fields of structure may not be optimized
away, because they are not independent variables. In D you have
unchecked pointer-to-pointer casts, and results of these casts should
depend on target architecture, not on optimizer implementation. At
particular, if such optimizations are allowed, some C API will no longer
be accessible from D.
Unused fields of a structure are optimized away _today_. Unless a piece
of code takes the address of the struct, all of the fields are treated
as independent variables.
The only point I was trying to make is that the 'unless' part does not
apply to MRV.
Re: toHash = pure, nothrow, const, @safe
On Sunday, 11 March 2012 at 23:54:10 UTC, Walter Bright wrote: Consider the toHash() function for struct key types: http://dlang.org/hash-map.html And of course the others: const hash_t toHash(); const bool opEquals(ref const KeyType s); const int opCmp(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). A pattern is emerging. Why not analyze it a bit and somehow try to find a common ground? Then we can generalize it to a single annotation.
Re: toHash = pure, nothrow, const, @safe
On Monday, 12 March 2012 at 07:18:06 UTC, so wrote: A pattern is emerging. Why not analyze it a bit and somehow try to find a common ground? Then we can generalize it to a single annotation. @mask(wat) const|pure|nothrow|safe @wat hash_t toHash() @wat bool opEquals(ref const KeyType s) @wat int opCmp(ref const KeyType s)
Re: toHash = pure, nothrow, const, @safe
On Mon, 12 Mar 2012 07:04:52 +0100, Alex Rønne Petersen xtzgzo...@gmail.com wrote: Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user. No, that has API design issues. You can silently break a guarantee you made previously. What's wrong with auto-inference. Inferred attributes are only strengthening guarantees.
Re: toHash = pure, nothrow, const, @safe
On 12 March 2012 21:08, Martin Nowak d...@dawgfoto.de wrote: On Mon, 12 Mar 2012 07:04:52 +0100, Alex Rønne Petersen xtzgzo...@gmail.com wrote: Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user. No, that has API design issues. You can silently break a guarantee you made previously. What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. One problem I can think of is relying on the auto-inference can create fragile code. You make a change in one place without concentrating and suddenly a completely different part of your code breaks, because it's expecting pure, or @safe code and you have done something to prevent the inference. I don't know how much of a problem that could be, but its one I can think of. -- James Miller
Re: toHash = pure, nothrow, const, @safe
So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). How about complete inference instead of a hack?
Re: Multiple return values...
On 12 March 2012 04:44, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: On 3/11/12 6:30 PM, Manu wrote: D should define an MRV ABI which is precisely the ABI for passing multiple args TO a function, but in reverse, for any given architecture. This also has the lovely side effect of guaranteeing correct argument placement for chain-called functions. I'm quoting this because it is the tersest and clearest expression of the actual request. It's a nice feature to have, but so are many others. I don't know what it would cost to implement (my guess is: high), and how large the benefits would be in various projects. Is this basically like saying it'll never happen? There is already a pending pull request implementing the syntax, that addresses half of the feature straight up.. codegen can come later, I agreed earlier that it is of lesser importance. You don't see the immediate value in a convenient MRV syntax? It would improve code clarity in many places, and allow the code to also be more efficient down the road. D seems rather feature-complete. What many other major features are on the cards if I may ask?
Re: Multiple return values...
On 12 March 2012 04:00, Robert Jacques sandf...@jhu.edu wrote:
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical, but it is certainly there.
void main(){
auto a = foo(); // MRV/struct return
bar(a.x); // defined in a different compilation unit
}
struct return has to write out the whole struct on the stack because of
layout guarantees, probably making the optimized struct return calling
convention somewhat slower for this case. The same does not hold for MRV.
The layout of the struct only has to exist _when_ the address is taken.
Before that, the compiler/language/optimizer is free to (and does) do
whatever it want. Besides, in your example only the address of a field is
taken, the compiler will optimize away all the other pieces a (dead
variable elimination).
No, it can't. That's the point. It must preserve the struct in case you
fiddle with the pointer. Taking the pointer is explicit in this case, but
if you passed anything in the struct to another function by ref, you've
setup the same scenario.
Wait, ARM?! That's really cool. However, as far as I know, D on ARM is very
experimental. Having an experimental compiler not eak out every last cycle
is not something that should be unexpected.
That said, I'm not sure what point you were trying to make, aside from
backend quality-of-implementation issues. I think bringing these issues up
is important, but they are tangent to the language changes you're asking
for.
This is using GCC's backend which is not really experimental, it has
decades of field use. The point here is that we are seeing the effect of
the C ABI applied directly to this problem, and it's completely un-workable.
I'm trying to show that D needs to declare something of an ABI promise when
applied to this problem if it is to be a useful+efficient feature. Again, C
can't express this problem, and we won't get any value from of the C ABI to
make this contruct efficient, but a very simple and efficient solution does
exist.
Why should D place this constraint on future compilers? D currently only
specifies the ABI for x86. I'm fairly sure it would follow the best
practices for each of the other architecture, but none of them have been
established yet.
Constraint? Perhaps you mean 'liberation'...
The x86 ABI is not a *best* practise by a long shot. It is only banking on
a traditional x86 trick for small structs.
I'm was giving you an example that seemed to satisfy your complaints. An
no, actually it can't return in those registers at zero cost. There is a
reason why we don't use all the registers to both pass and return
arguments: we need some registers free to work on them both before and
after the call.
D should define an MRV ABI which is precisely the ABI for passing multiple
args TO a function, but in reverse, for any given architecture. .. I've
never said anything about using ALL the registers, I say to use all the
ARGUMENT registers.
On x64, that is 4 GPR regs, and 4 XMM regs.
I know Go has MRV. What does its ABI look like? What does ARM prefer? I'd
recommend citing some papers or a compiler or something. Otherwise, it
looks like you're ignoring the wisdom of the masses or simply ignorant.
I don't have a Go toolchain, do you wanna run my tests above?
Are you suggesting I have no idea what I'm talking about with respect to
efficient calling conventions? The very fastest way is to return in the
registers designed for the job. This is true for x64, ARM, everything. What
to do when you exceed the argument register limit is a question for each
architecture, but I maintain it should behave exactly as it does when
calling a function, this way you create the possibility of super-efficient
chain-calls.
LLVM has support for MRV how I describe:
The biggest change in LLVM 2.3 is Multiple Return Value (MRV) support. MRVs
allow LLVM IR to directly represent functions that return multiple values
without having to pass them by reference in the LLVM IR. This allows a
front-end to generate more efficient code, *as MRVs are generally returned
in registers if a target supports them*. See the LLVM IR
Referencehttp://llvm.org/releases/2.3/docs/LangRef.html#i_getresult
for
more details.
MRVs are fully supported in the LLVM IR, but are not yet fully supported in
on all targets. However, it is generally safe to return up to 2 values from
a function: most targets should be able to handle at least that. MRV
support is a critical requirement for X86-64 ABI support, as X86-64
requires the ability to return multiple registers from functions, and we
use MRVs to accomplish this *in a direct way*.
In this case, if we have the expression defined in the language (the other
guys have convinced me we do, via tuples), it's conceivable the front end
could present it
Re: toHash = pure, nothrow, const, @safe
Am Mon, 12 Mar 2012 07:06:33 +0100 schrieb Alex Rønne Petersen xtzgzo...@gmail.com: I should point out that I *do* think the idea is good (i.e. if you want the bad things, that's what you have to declare), but it's just too late now. Also, there might be issues with const and the likes - should the system assume const or immutable or inout or...? @safe pure nothrow as default could have worked better than manually setting it, I agree. @safe can be set at module level, so it is less of an issue to make it the default in your code. The problem with those attributes is not that pure is used more often than impure or nothrow more often than throws, but that they need to be set transitive in function calls. And even though the attributes do no harm to the user of the function (unlike immutable) they can easily be forgotten or left away, because it is tedious to type them. -- Marco
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-11 20:55, Nick Sabalausky wrote: Mobile sites have traditionally required less-fancy implementations, so it's not unreasonable to think that some sites would use their mobile version *as* their low-tech fallback version. That's becoming less and less true these days, of course. But looking at http://m.drdobbs.com/ I have a strong feeling that was originally created for things like AvantGo (ie, on PalmOS) which really were very limited: no JS, no nested tables, very low resolution, often not even any color, very low memory, etc. Not that anything about what they're doing really makes a whole lot of sense anyway, though. Actually, on some sites I use the mobile version, on the desktop. Just because it's so much more clean and not as verbose. -- /Jacob Carlborg
Re: toHash = pure, nothrow, const, @safe
On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature.
Re: Has Tomasz's (h3r3tic's) OpenGL font rendering code been ported to D2?
On 2012-03-11 23:36, Chad J wrote: No, just getting the font onto the screen at all. And I want to: - Be able to size the font smoothly. (No bitmap fonts!) - Draw glyphs for higher unicode codepoints. (No texture[128]!) - Have kerning/hinting. (Freetype makes it possible, but does not do it for you.) - Have anti-aliasing and maybe even subpixel accuracy. Tomasz's code does all of this. Freetype is very low-level. Freetype does not make OpenGL calls. You give it a font and a codepoint and it gives you a small grayscale bitmap and a slew of metrics for it. Then it's up to you to figure out where to put it and how to get it onto the screen. If this were trivial, Tomasz (and others who have written on the topic, too) would not have written 5-10 pages of text plus a bunch of D files full of code. It's just not that easy. It's all in the original link. It's actually really weird that there isn't much library code out there to render text in OpenGL. There are a bunch of tutorials that do it wrong and maybe a few library thingies that I can't use for various reasons. I did some font rendering in C# using FreeType and OpenGL for a simple game. I can't remembering it being that hard. -- /Jacob Carlborg
Re: Multiple return values...
12.03.2012 6:01, Robert Jacques пишет: On Sun, 11 Mar 2012 21:49:52 -0500, Mantis mail.mantis...@gmail.com wrote: [...] That's the point of discussion. Fields of structure may not be optimized away, because they are not independent variables. In D you have unchecked pointer-to-pointer casts, and results of these casts should depend on target architecture, not on optimizer implementation. At particular, if such optimizations are allowed, some C API will no longer be accessible from D. Unused fields of a structure are optimized away _today_. Unless a piece of code takes the address of the struct, all of the fields are treated as independent variables. I can't confirm: http://pastebin.com/YgBULGfe Prints 42\n3.14\n, compiled with dmd -release on windows x86. How exactly did you find out that such optimization is performed?
Re: toHash = pure, nothrow, const, @safe
One problem I can think of is relying on the auto-inference can create
fragile code. You make a change in one place without concentrating and
suddenly a completely different part of your code breaks, because it's
expecting pure, or @safe code and you have done something to prevent
the inference. I don't know how much of a problem that could be, but
its one I can think of.
--
James Miller
That sounds intentionally.
Say you have a struct with a getHash method.
struct Key
{
hash_t getHash() /* inferred pure */
{
}
}
Say you have an Set that requires a pure opHash.
void insert(Key key) pure
{
immutable hash = key.toHash();
}
Now if you change the implementation of Key.getHash
then maybe it can no longer be inserted into that Set.
If OTOH your set.insert were inferred pure itself, then
the impureness would escalate to the set.insert(key) caller.
It's about the same logic that would makes nothrow more useful.
You can omit it most of the times but always have the
possibility to enforce it, e.g. at a much higher level.
Re: How about colors and terminal graphics in std.format?
On 2012-03-12 03:16, Chad J wrote: I remember doing colored terminal output in Python. It was pretty nifty, and allows for some slick CLI design. I think D can do better by putting it in the standard library. I was thinking something along the lines of this: http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html I figure it would probably be easy to get some of the basics down. More advanced stuff would probably involve messing with terminfo or term.h. Windows' (terribly bad) command prompt can have some of these capabilities implemented too, but in a roundabout way because Windows defines API functions that need to be called to affect terminal graphics and coloring. I figure that would require the help of the I/O routines if I were to work on that. If there's interest, I might take a stab at it. So, would this sort of thing make it in? I think it would nice to have, but not in std.format. std.terminal or similar would be better. -- /Jacob Carlborg
Re: toHash = pure, nothrow, const, @safe
That sounds intentionally.
Say you have a struct with a getHash method.
struct Key
{
hash_t getHash() /* inferred pure */
{
}
}
Say you have an Set that requires a pure opHash.
void insert(Key key) pure
{
immutable hash = key.toHash();
}
Now if you change the implementation of Key.getHash
then maybe it can no longer be inserted into that Set.
If OTOH your set.insert were inferred pure itself, then
the impureness would escalate to the set.insert(key) caller.
It's about the same logic that would makes nothrow more useful.
You can omit it most of the times but always have the
possibility to enforce it, e.g. at a much higher level.
My point was more about distant code breaking. Its more to do with
unexpected behavior than code correctness in this case. As i said, I
could be worrying about nothing though.
--
James Miller
Re: EBNF grammar for D?
On 11/03/2012 16:49, Philippe Sigaud wrote: Hello, I'm looking for a D grammar in (E)BNF form. Did any of you write something like that or do you think I can use the grammar parts on dlang.org? I remember different threads on this subject and saw the docs being updated regularly on github, but my google-fu is weak today. Rainer Schuetze pulled all the grammar out of the docs and fixed them up a while back as part of his work on Visual D. Its not in straight EBNF and it may not be 100% up to date, but it may be a good place to start. http://www.dsource.org/projects/visuald/wiki/GrammarComparison I hope that is of some use! A...
Re: Multiple return values...
So, function with MRV is basically the function that returns
Tuple where one can specify return convention?
---
auto fun()
{
return(Windows) tuple(1, 2.0f);
}
(int x, float y) = fun();
---
Re: toHash = pure, nothrow, const, @safe
Le 12/03/2012 00:54, Walter Bright a écrit : Consider the toHash() function for struct key types: http://dlang.org/hash-map.html And of course the others: const hash_t toHash(); const bool opEquals(ref const KeyType s); const int opCmp(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). I don't really see the point. For Objects, we inherit from Object, which can define theses. For struct, we have inference, so most of the time attributes will correct. const pure nothrow @safe are something we want, but is it something we want to enforce ?
Re: Breaking backwards compatiblity
Am Sun, 11 Mar 2012 04:12:12 -0400 schrieb Nick Sabalausky a@a.a: I think it's a shame that companies hand out high-end hardware to their developers like it was candy. There's no doubt in my mind that's significantly contributed to the amount of bloatware out there. But what if the developers themselves use bloated software, like Eclipse or slow compilation processes, like big C++ programs. It is a net productivity increase. But yeah, I sometimes think about keeping some old notebook around to test on it - not to use it for development. Actually, sometimes you may want to debug your code with a very large data set. So you end up on the other side of the extreme: Your computer has too little RAM to run some real world application of your software. As for the article: The situation with automatic updates was worse than now - Adobe, Apple and the others have learned and added the option to disable most of the background processing. The developments in the web sector are interesting under that aspect. High quality videos and several scripting/VM languages make most older computers useless for tabbed browsing :D -- Marco
Re: toHash = pure, nothrow, const, @safe
On 12/03/12 00:55, Alex Rønne Petersen wrote: On 12-03-2012 00:54, Walter Bright wrote: Consider the toHash() function for struct key types: http://dlang.org/hash-map.html And of course the others: const hash_t toHash(); const bool opEquals(ref const KeyType s); const int opCmp(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted A 2. it's just plain annoying to annotate them Maybe we need @nice or something, to mean pure nothrow @safe. It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and That was sounding reasonable, but... @safe (if not already marked as @trusted). ...this part is a bit scary. It sounds as though the semantics are a bit fuzzy. There is no way to make a function as 'impure' or 'does_throw'. But you can annotate with @system. It may be a hack, but you know, those have special semantics/meanings in the first place, so is it really that bad? Agreed, they are in some sense virtual functions. But how would you declare those functions. With pure nothrow @safe, or with pure nothrow @trusted ? Consider also that contract blocks are now implicitly const, etc. But the clutter problem isn't restricted to those specific functions. One issue with pure, nothrow is that they have no inverse, so you cannot simply write pure: nothrow: at the top of the file and use 'pure nothrow' by default. The underlying problem is that, when spelt out in full, those annotations uglify the code.
Re: Breaking backwards compatiblity
I searched every inch of Opera's options screens and never found *any* mention or reference to any Disable AutoUpdate Derek ddparn...@bigpond.com wrote in message news:op.wazmllu534mv3i@red-beast... I found it in a minute. First I tried opera help and it directed me to details about auto-update, which showed how to disable it. It is in the normal UI place for such stuff. Tools - Preferences - Advanced - Security - Auto-Update. Am Sat, 10 Mar 2012 23:44:20 -0500 schrieb Nick Sabalausky a@a.a: They stuck it under Security? No wonder I couldn't find it. That's like putting blue under shapes. :/ So much for every inch ...and false accusations. You made my day! ;) -- Marco
Re: Review of Jose Armando Garcia Sancio's std.log
On Mon, 12 Mar 2012 01:26:54 -0400, Jose Armando Garcia jsan...@gmail.com wrote: On Wed, Mar 7, 2012 at 6:39 AM, Steven Schveighoffer schvei...@yahoo.com wrote: On Wed, 07 Mar 2012 07:09:17 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: What is wrong with import std.log; log.info(cool); alternatively: log_info(cool); linfo(cool); lginfo(cool); There are so many choices besides just info. We should use something else. Lets flip the question. Why are you against: import log = std.log; I'm against having a requirement (or at least a strong suggestion) to import std.log in a certain way other than import std.log. There are a couple problems with this: 1. Almost all code examples in modules use import modulename; They don't have some documentation that says you should probably import modulename by import modulename = modulename. For an example of this, see http://www.dsource.org/projects/tango/docs/stable/tango.io.Path.html 2. With no guarantees that everyone will use log as the symbol (or even use the symbol), you potentially have several files using std.log under different symbols. For example, someone might prefer logger or lg. This just makes things more confusing than is necessary. I'm not actually against using this technique, I'm just against making it standard practice. I feel using a naming scheme which eliminates having to use this trick to be able to keep your existing names and/or use these common names as members would foster more uniform code and usage. That's all. Yes, this is a form of bikeshedding, but it's one of those things that will be difficult to change later. Even just changing the names of the functions which log to something less common, like I stated above, could be worth a lot. I won't vote against the lib if this is my only objection, but I do think it's important. If others don't, well, I guess we'll see what happens. I likely will be using import log = std.log whenever I use it. -Steve
Re: Review of Jose Armando Garcia Sancio's std.log
On Mon, 12 Mar 2012 01:05:33 -0400, Jose Armando Garcia jsan...@gmail.com wrote: On Sun, Mar 11, 2012 at 3:28 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I thought more about the point made about mixing throwing and logging levels. I agree that it's awkward to e.g. log to critical without throwing etc. I personally think in that case you really want the error log, but hey, point taken. I thought about this a lot too and right now I think that if we want to remove asserting from fatal and remove throwing from critical then we should just remove those log levels completely. To me they don't add any additional value. The whole point of having them in the first place was because of their assert and throw semantic. This is fine, since we can always add more levels later if a need arises. -Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky a@a.a wrote: You know what I think it is (without actually looking at the code): I think they tried to do some highly misguided and even more poorly implemented hack (which they no-doubt thought was clever) for dealing with *cough* old *cough* browsers by inserting a meta redirect to a hardcoded URL, and then used JS to disable the meta redirect. If that's the case, I don't know how the fuck they managed to convince themselves that make one drop of sense. It could be that they don't care to cater to people who hate JS. There aren't that many of you. You may want to consider -- if you on principle don't view pages with information because the pages contain JS, you are the one missing out on the information. If you worked for my company, and you didn't like JS, you'd have a tough (actually impossible) time using the web application we have for tracking things. -Steve
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 10:40, Walter Bright wrote: On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? -- - Alex
Re: Review of Jose Armando Garcia Sancio's std.log
On Mar 12, 2012, at 7:28 AM, Andrei Alexandrescu wrote: On 3/11/12 4:49 PM, David Nadlinger wrote: Unfortunately, the discussion has ground to a halt again, so consider this a friendly reminder that there is still one day left until the end of the review period. David I thought more about the point made about mixing throwing and logging levels. I agree that it's awkward to e.g. log to critical without throwing etc. I personally think in that case you really want the error log, but hey, point taken. Here's a suggestion: * Don't throw from the critical log and don't abort from the fatal log. * Define the logging functions such that logging an exception will log its toString() and then throw the exception. * Regarding static import log = std.log, I suggest we keep course. Works? +1 (I particularly like the idea of logging an exception rather than logging a message and a separate exception to throw, which may contain a different message.) Geoff
Re: Arbitrary abbreviations in phobos considered ridiculous
On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Insert obligatory link: http://drdobbs.com/184401197
Very insightful article.
Interesting point to make about D, however. It's really *difficult* to
make related non-member non-friend functions, since all functions inside
the same module as a type are friends. In order to follow the
recommendations, D non-member non-friend functions must go in another
*module*.
I don't necessarily agree with the argument, because it's a
fully-objective view of something that is very subjective.
For instance:
class A
{
private int a;
}
class B
{
private int b;
}
void nonMemberBFunction(B b)
{
b.b = 5;
}
Not only is nonMemberBFunction potentially dependent on B's
implementation, but it's also potentially dependent (by Scott's rules) on
A's implementation. Therefore, A has less encapsulation.
But any sane person can see that nonMemberBFunction does not access A.
Since everything to be examined/updated when updating A's implementation
is in the same file (and that implementation is readily available), I
think you should not count non-member functions that don't *access* the
class in question against the encapsulation factor. Yes, this makes
things more reliant on convention (i.e. denote in documentation somehow
what functions access private data), but since you can't turn friends off
without extreme practices, I don't think you have any other sane choices.
In D, interestingly, making things member functions is not any different
than making them non-members, it seems. In fact, I'd argue it's *more*
appropriate in D to make things member functions, since it serves as
implicit documentation that it likely accesses only the class members. I
wonder what Scott would say about that?
-Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On Sun, 11 Mar 2012 00:18:31 -0500, Daniel Murphy yebbl...@nospamgmail.com wrote: Nick Sabalausky a@a.a wrote in message news:jjh9uh$1vto$1...@digitalmars.com... My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs. Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source? That's not really it... The problem is that vtables contain every virtual function of a class - and if you instantiate a template function with a new type, it would require a new vtable entry. Therefore you need to know how every template function in every derived class is instantiated before you can build the base class vtable. This doesn't work with D's compilation model. You could do it if the vtable was a hash instead of an array (or at least the template portion was). But that's just asking for horrible performance, and I don't think it's worth it. But I think it is possible... -Steve
Re: toHash = pure, nothrow, const, @safe
Le 12/03/2012 13:51, Alex Rønne Petersen a écrit : On 12-03-2012 10:40, Walter Bright wrote: On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem.
Re: toHash = pure, nothrow, const, @safe
On Sun, 11 Mar 2012 19:54:09 -0400, Walter Bright newshou...@digitalmars.com wrote: Consider the toHash() function for struct key types: http://dlang.org/hash-map.html And of course the others: const hash_t toHash(); const bool opEquals(ref const KeyType s); const int opCmp(ref const KeyType s); They need to be, as well as const, pure nothrow @safe. The problem is: 1. a lot of code must be retrofitted 2. it's just plain annoying to annotate them It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones. So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). What about a new attribute @type (or better name?) that means this function is part of the TypeInfo interface, and has an equivalent xFuncname in TypeInfo_Struct. Then it implicitly inherits all the attributes of that xFuncname (not necessarily defined by the compiler). Then, we can have several benefits: 1. This triggers the compiler to complain if we don't correctly define the function (as specified in TypeInfo_Struct). In other words, it allows the developer to specify I want this function to go into TypeInfo. 2. It potentially allows additional interface hooks without compiler modification. For example, you could add xfoo in TypeInfo_Struct, and then every struct you define @type foo() would get a hook there. 3. As you wanted, it eliminates having to duplicate all the attributes. The one large drawback is, you need to annotate all existing functions. We could potentially assume that @type is specified on the functions that currently enjoy automatic inclusion in the TypeInfo_Struct instance. I'd recommend at some point eliminating this hack though. -Steve
Re: Has Tomasz's (h3r3tic's) OpenGL font rendering code been ported to D2?
On Sunday, 11 March 2012 at 22:39:46 UTC, Chad J wrote: On 03/11/2012 04:24 AM, Kiith-Sa wrote: Thanks for the link! I don't have time to go over it right now, but that looks promising. I took a shot at porting Tomasz's code a while ago, but I never got it to compile. At least your code /compiles/, so even if it's integrated into other stuff, at least I might stand a better chance. Btw, also a fan of Raptor and Tyrian. Good taste dude. ;) I just remembered I also wrote a tool for this as a project at university (in Java, because I had to) last year: http://gitorious.org/fmapper It spits out a texture or a set of textures with tightly packed glyphs of specified font with specified parameters, and a text file containing offsets and texture coords of glyphs. There is an example C++/OpenGL program on how to load the textures and draw fonts. Only supports the basic multilingual plane, though. If you're only using a fixed number of font sizes, you can generate textures for them with this. It's not as flexible, but probably easier than writing your own code based on FreeType. Note that it's not maintained - I hate Java - but it should work.
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 14:16, deadalnix wrote: Le 12/03/2012 13:51, Alex Rønne Petersen a écrit : On 12-03-2012 10:40, Walter Bright wrote: On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem. But people might be relying on your API that just so happens to be pure, but then suddenly isn't! -- - Alex
Re: toHash = pure, nothrow, const, @safe
On Mon, 12 Mar 2012 10:40:16 +0100, Walter Bright newshou...@digitalmars.com wrote: On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. A @safe pure nothrow const might be used as @system. That means someone using a declaration may have a different view than someone providing the implementation. Those interface boundaries are also a good place for by-hand annotations to provide explicit API guarantees and enforce a correct implementation. Though another issue with inference is that it would require a depth-first-order for the semantic passes. I also hope we still don't mangle inferred attributes.
Re: toHash = pure, nothrow, const, @safe
Walter: toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). I have read the other answers of this thread, and I don't like some of them. In this case I think this programmer convenience doesn't justify adding one more special case to D purity. So for me it's a -1. Bye, bearophile
Calling D from C
I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7
Re: Calling D from C
On 12-03-2012 15:53, Chris W. wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 Are you remembering to initialize the runtime, attach your thread, etc... Also, you can't call D functions directly from C code. You have to go through an extern (C) wrapper that then calls the D function. -- - Alex
Re: How about colors and terminal graphics in std.format?
On Mon, Mar 12, 2012 at 10:51:08AM +0100, Jacob Carlborg wrote: On 2012-03-12 03:16, Chad J wrote: I remember doing colored terminal output in Python. It was pretty nifty, and allows for some slick CLI design. I think D can do better by putting it in the standard library. I was thinking something along the lines of this: http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html I figure it would probably be easy to get some of the basics down. More advanced stuff would probably involve messing with terminfo or term.h. Windows' (terribly bad) command prompt can have some of these capabilities implemented too, but in a roundabout way because Windows defines API functions that need to be called to affect terminal graphics and coloring. I figure that would require the help of the I/O routines if I were to work on that. If there's interest, I might take a stab at it. So, would this sort of thing make it in? I think it would nice to have, but not in std.format. std.terminal or similar would be better. [...] +1. It's better not to pollute std.format with stuff that, strictly speaking, isn't related to formatting per se, but is tied to a particular output medium. This is proven by the fact that the translation of color escapes only makes sense w.r.t. a particular terminal, so you'll get garbage if you call std.format on the string, save it to file, say, then load it later and output it to a possibly different terminal type. So what you *really* want is to translate these escape sequences *at output time*, not at string formatting time. If we do it that way, we can have the nicer behaviour that these escapes will work on any terminal and can be freely moved around from terminal to terminal, because they are only interpreted at the instant when they are actually being output to that terminal. T -- All problems are easy in retrospect.
Re: Calling D from C
On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve
Re: Calling D from C
On Monday, 12 March 2012 at 15:00:31 UTC, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve Yes, I am using extern (C) and in my C main function I call gc_init(); thread_attachThis(); This works fine for primitive types such as int + int calculations. But anything more sophisticated renders a Bus error. I am sure it is just some little detail I have forgotten.
Re: Calling D from C
On 12-03-2012 16:09, Chris W. wrote: On Monday, 12 March 2012 at 15:00:31 UTC, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve Yes, I am using extern (C) and in my C main function I call gc_init(); thread_attachThis(); This works fine for primitive types such as int + int calculations. But anything more sophisticated renders a Bus error. I am sure it is just some little detail I have forgotten. Don't forget to call this: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L33 Documented here: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L101 -- - Alex
Re: Calling D from C
On Monday, 12 March 2012 at 15:17:32 UTC, Alex Rønne Petersen wrote: On 12-03-2012 16:09, Chris W. wrote: On Monday, 12 March 2012 at 15:00:31 UTC, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve Yes, I am using extern (C) and in my C main function I call gc_init(); thread_attachThis(); This works fine for primitive types such as int + int calculations. But anything more sophisticated renders a Bus error. I am sure it is just some little detail I have forgotten. Don't forget to call this: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L33 Documented here: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L101 Thanks a million, calling rt_init(); in my C code did the trick. Now I can perform string operations etc. I knew it was just a tiny little detail.
Re: Calling D from C
On 12-03-2012 16:36, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 11:17:31 -0400, Alex Rønne Petersen xtzgzo...@gmail.com wrote: On 12-03-2012 16:09, Chris W. wrote: On Monday, 12 March 2012 at 15:00:31 UTC, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve Yes, I am using extern (C) and in my C main function I call gc_init(); thread_attachThis(); This works fine for primitive types such as int + int calculations. But anything more sophisticated renders a Bus error. I am sure it is just some little detail I have forgotten. Don't forget to call this: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L33 Documented here: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L101 More appropriate: http://dlang.org/phobos/core_runtime.html#initialize But that's effectively an extern (D) function. That's why I linked to rt_init. And actually, I think this should do everything necessary. No need to call gc_init and thread_attachThis(). -Steve -- - Alex
Re: Calling D from C
On Mon, 12 Mar 2012 11:17:31 -0400, Alex Rønne Petersen xtzgzo...@gmail.com wrote: On 12-03-2012 16:09, Chris W. wrote: On Monday, 12 March 2012 at 15:00:31 UTC, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve Yes, I am using extern (C) and in my C main function I call gc_init(); thread_attachThis(); This works fine for primitive types such as int + int calculations. But anything more sophisticated renders a Bus error. I am sure it is just some little detail I have forgotten. Don't forget to call this: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L33 Documented here: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L101 More appropriate: http://dlang.org/phobos/core_runtime.html#initialize And actually, I think this should do everything necessary. No need to call gc_init and thread_attachThis(). -Steve
Re: Calling D from C
On Mon, 12 Mar 2012 11:36:45 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Mon, 12 Mar 2012 11:17:31 -0400, Alex Rønne Petersen xtzgzo...@gmail.com wrote: On 12-03-2012 16:09, Chris W. wrote: On Monday, 12 March 2012 at 15:00:31 UTC, Steven Schveighoffer wrote: On Mon, 12 Mar 2012 10:53:09 -0400, Chris W. wend...@cd.ie wrote: I have a problem when calling D functions from C. While I can perform simple arithmetic operations (i.e. the calculation is performed in D and returned to C), I experience problems when trying to perform string/char operations or call functions from the D standard library (e.g. writefln()). The usual error message I get is either Bus error or Segmentation fault. I haven't been able to find the reason for this. The programs compile and link, however, when run, they terminate with Bus error whenever a D function is performed within the D code, e.g. something like char[] s2 = s.dup; (s is a char* passed from C). Any hint or help would be appreciated. I am using Mac OS X, 10.6.7 If C is running your application startup, you must initialize D's runtime from your C main routine. -Steve Yes, I am using extern (C) and in my C main function I call gc_init(); thread_attachThis(); This works fine for primitive types such as int + int calculations. But anything more sophisticated renders a Bus error. I am sure it is just some little detail I have forgotten. Don't forget to call this: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L33 Documented here: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L101 More appropriate: http://dlang.org/phobos/core_runtime.html#initialize And actually, I think this should do everything necessary. No need to call gc_init and thread_attachThis(). Hm... just realized you can't do this, since it's a D function :D But yeah, all it does is call rt_init, so you should be good. -Steve
Re: Multiple return values...
On 12 March 2012 01:37, Andrew Wiley wiley.andre...@gmail.com wrote:
On Sun, Mar 11, 2012 at 7:44 PM, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can /
will be doing this on x86-64, as other compilers have already done. Manu was
arguing that MRV were somehow special and had mystical optimization
potential. That's simply not true.
Here's some tests for you:
// first test that the argument registers allocate as expected...
int gprtest(int x, int y, int z)
{
return x+y+z;
}
Perfect, ints pass in register sequence, return in r0, no memory access
add r0, r0, r1
add r0, r0, r2
bx lr
float fptest(float x, float y, float z)
{
return x+y+z;
}
Same for floats
fadds s0, s0, s1
fadds s0, s0, s2
bx lr
// Some MRV tests...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Simple case, 2 ints
FAIL, stores the 2 arguments it received in regs straight to output struct
pointer supplied
stmia r0, {r1, r2}
bx lr
auto mrv2(int x, float y, byte z)
{
return Tuple!(int, float, byte)(x, y, z);
}
Different typed things
EPIC FAIL
stmfd sp!, {r4, r5}
mov ip, #0
sub sp, sp, #24
mov r4, r2
str ip, [sp, #12]
str ip, [sp, #20]
ldr r2, .L27
add ip, sp, #24
mov r3, r0
mov r5, r1
str r2, [sp, #16] @ float
ldmdb ip, {r0, r1, r2}
stmia r3, {r0, r1, r2}
fsts s0, [r3, #4]
stmia sp, {r0, r1, r2}
str r5, [r3, #0]
strb r4, [r3, #8]
mov r0, r3
add sp, sp, #24
ldmfd sp!, {r4, r5}
bx lr
auto range(int *p)
{
return p[0..1];
}
Range
SURPRISE FAIL, even a range is returned as a struct! O_O
mov r2, #1
str r2, [r0, #0]
str r1, [r0, #4]
bx lr
So the D ABI is a complete shambles on ARM!
Unsurprisingly, it all just follows the return struct by-val ABI, which is
to write it to the stack unconditionally. And sadly, it even thinks the
internal types like range+delegate are just a struct by-val, and completely
ruins those!
Let's try again with x86...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Returns in eax/edx as expected
movl 4(%esp), %eax
movl 8(%esp), %edx
auto mrv2(int x, float y, int z)
{
return Tuple!(int, float, int)(x, y, z);
}
FAIL! All written to a struct rather than returning in eax,edx,st0 .. This
is C ABI baggage, D can do better.
movl 4(%esp), %eax
movl 8(%esp), %edx
movl %edx, (%eax)
movl 12(%esp), %edx
movl %edx, 4(%eax)
movl 16(%esp), %edx
movl %edx, 8(%eax)
ret $4
auto range(int *p)
{
return p[0..1];
}
Obviously, the small struct optimisation allows this to work properly
movl $1, %eax
movl 4(%esp), %edx
ret
All that said, x86 isn't a good test case, since all args are ALWAYS passed
on the stack. x64 would be a much better test since it actually has arg
registers, but I'm on windows, so no x64 for me...
I assume this is with GDC? Pretty sure GDC doesn't match D's official
ABI anyway because Iain didn't want to try to push D ABI support into
GCC along with GDC.
You're probably still right, but be aware that GDC is a bit different here.
Well, this is taken off the D ABI documentation.
The extern (C) and extern (D) calling convention matches the C calling
convention used by the supported C compiler on the host system. Except
that the extern (D) calling convention for Windows x86 is described
here.
Examining it in a literal sense, I can say that GDC is compliant with
the spec (except on x86 Windows, which it uses stdcall rather than the
calling convention described on the page).
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: Multiple return values...
On 12 March 2012 00:44, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can /
will be doing this on x86-64, as other compilers have already done. Manu was
arguing that MRV were somehow special and had mystical optimization
potential. That's simply not true.
Here's some tests for you:
// first test that the argument registers allocate as expected...
int gprtest(int x, int y, int z)
{
return x+y+z;
}
Perfect, ints pass in register sequence, return in r0, no memory access
add r0, r0, r1
add r0, r0, r2
bx lr
float fptest(float x, float y, float z)
{
return x+y+z;
}
Same for floats
fadds s0, s0, s1
fadds s0, s0, s2
bx lr
// Some MRV tests...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Simple case, 2 ints
FAIL, stores the 2 arguments it received in regs straight to output struct
pointer supplied
stmia r0, {r1, r2}
bx lr
auto mrv2(int x, float y, byte z)
{
return Tuple!(int, float, byte)(x, y, z);
}
Different typed things
EPIC FAIL
stmfd sp!, {r4, r5}
mov ip, #0
sub sp, sp, #24
mov r4, r2
str ip, [sp, #12]
str ip, [sp, #20]
ldr r2, .L27
add ip, sp, #24
mov r3, r0
mov r5, r1
str r2, [sp, #16] @ float
ldmdb ip, {r0, r1, r2}
stmia r3, {r0, r1, r2}
fsts s0, [r3, #4]
stmia sp, {r0, r1, r2}
str r5, [r3, #0]
strb r4, [r3, #8]
mov r0, r3
add sp, sp, #24
ldmfd sp!, {r4, r5}
bx lr
auto range(int *p)
{
return p[0..1];
}
Range
SURPRISE FAIL, even a range is returned as a struct! O_O
mov r2, #1
str r2, [r0, #0]
str r1, [r0, #4]
bx lr
So the D ABI is a complete shambles on ARM!
Unsurprisingly, it all just follows the return struct by-val ABI, which is
to write it to the stack unconditionally. And sadly, it even thinks the
internal types like range+delegate are just a struct by-val, and completely
ruins those!
Let's try again with x86...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Returns in eax/edx as expected
movl 4(%esp), %eax
movl 8(%esp), %edx
auto mrv2(int x, float y, int z)
{
return Tuple!(int, float, int)(x, y, z);
}
FAIL! All written to a struct rather than returning in eax,edx,st0 .. This
is C ABI baggage, D can do better.
movl 4(%esp), %eax
movl 8(%esp), %edx
movl %edx, (%eax)
movl 12(%esp), %edx
movl %edx, 4(%eax)
movl 16(%esp), %edx
movl %edx, 8(%eax)
ret $4
auto range(int *p)
{
return p[0..1];
}
Obviously, the small struct optimisation allows this to work properly
movl $1, %eax
movl 4(%esp), %edx
ret
All that said, x86 isn't a good test case, since all args are ALWAYS passed
on the stack. x64 would be a much better test since it actually has arg
registers, but I'm on windows, so no x64 for me...
What compiler flags are you using here? For x86, I would have thought
that small structs ( 8 bytes) would be passed back in registers...
only speculating though - will need to see what codegen is being built
from the D code provided to be sure.
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: Calling D from C
On 12/03/2012 15:38, Steven Schveighoffer wrote: snip http://dlang.org/phobos/core_runtime.html#initialize And actually, I think this should do everything necessary. No need to call gc_init and thread_attachThis(). Hm... just realized you can't do this, since it's a D function :D Why can't this be dealt with using an extern (C) wrapper function in the D code? Stewart.
Re: Multiple return values...
On 12 March 2012 19:03, Iain Buclaw ibuc...@ubuntu.com wrote:
On 12 March 2012 00:44, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can
/
will be doing this on x86-64, as other compilers have already done.
Manu was
arguing that MRV were somehow special and had mystical optimization
potential. That's simply not true.
Here's some tests for you:
// first test that the argument registers allocate as expected...
int gprtest(int x, int y, int z)
{
return x+y+z;
}
Perfect, ints pass in register sequence, return in r0, no memory
access
add r0, r0, r1
add r0, r0, r2
bx lr
float fptest(float x, float y, float z)
{
return x+y+z;
}
Same for floats
fadds s0, s0, s1
fadds s0, s0, s2
bx lr
// Some MRV tests...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Simple case, 2 ints
FAIL, stores the 2 arguments it received in regs straight to output
struct
pointer supplied
stmia r0, {r1, r2}
bx lr
auto mrv2(int x, float y, byte z)
{
return Tuple!(int, float, byte)(x, y, z);
}
Different typed things
EPIC FAIL
stmfd sp!, {r4, r5}
mov ip, #0
sub sp, sp, #24
mov r4, r2
str ip, [sp, #12]
str ip, [sp, #20]
ldr r2, .L27
add ip, sp, #24
mov r3, r0
mov r5, r1
str r2, [sp, #16] @ float
ldmdb ip, {r0, r1, r2}
stmia r3, {r0, r1, r2}
fsts s0, [r3, #4]
stmia sp, {r0, r1, r2}
str r5, [r3, #0]
strb r4, [r3, #8]
mov r0, r3
add sp, sp, #24
ldmfd sp!, {r4, r5}
bx lr
auto range(int *p)
{
return p[0..1];
}
Range
SURPRISE FAIL, even a range is returned as a struct! O_O
mov r2, #1
str r2, [r0, #0]
str r1, [r0, #4]
bx lr
So the D ABI is a complete shambles on ARM!
Unsurprisingly, it all just follows the return struct by-val ABI, which
is
to write it to the stack unconditionally. And sadly, it even thinks the
internal types like range+delegate are just a struct by-val, and
completely
ruins those!
Let's try again with x86...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Returns in eax/edx as expected
movl 4(%esp), %eax
movl 8(%esp), %edx
auto mrv2(int x, float y, int z)
{
return Tuple!(int, float, int)(x, y, z);
}
FAIL! All written to a struct rather than returning in eax,edx,st0 ..
This
is C ABI baggage, D can do better.
movl 4(%esp), %eax
movl 8(%esp), %edx
movl %edx, (%eax)
movl 12(%esp), %edx
movl %edx, 4(%eax)
movl 16(%esp), %edx
movl %edx, 8(%eax)
ret $4
auto range(int *p)
{
return p[0..1];
}
Obviously, the small struct optimisation allows this to work properly
movl $1, %eax
movl 4(%esp), %edx
ret
All that said, x86 isn't a good test case, since all args are ALWAYS
passed
on the stack. x64 would be a much better test since it actually has arg
registers, but I'm on windows, so no x64 for me...
What compiler flags are you using here? For x86, I would have thought
that small structs ( 8 bytes) would be passed back in registers...
only speculating though - will need to see what codegen is being built
from the D code provided to be sure.
-S -O2 -msse2
And as expected, 8byte structs were returned packed in registers from my
examples above. That's a traditional x86 ABI hack which conveniently allows
delegates+ranges to work well on x86, but as you can see, they're proper
broken on other architectures.
Re: Calling D from C
On Mar 12, 2012, at 9:54 AM, Stewart Gordon smjg_1...@yahoo.com wrote: On 12/03/2012 15:38, Steven Schveighoffer wrote: snip http://dlang.org/phobos/core_runtime.html#initialize And actually, I think this should do everything necessary. No need to call gc_init and thread_attachThis(). Hm... just realized you can't do this, since it's a D function :D Why can't this be dealt with using an extern (C) wrapper function in the D code? D function names are mangled based on the name of the module they're defined in. For the runtime code, it's easier to wrap extern C calls with D functions.
Re: toHash = pure, nothrow, const, @safe
On Monday, March 12, 2012 09:14:17 Martin Nowak wrote: So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted). How about complete inference instead of a hack? Because that requires having all of the source code. The fact that we have .di files prevents that. You'd have to be able to guarantee that you can always see the whole source (including the source of anything that the functions call) in order for attribute inferrence to work. The only reason that we can do it with templates is because we _do_ always have their source, and the fact that non- templated functions must have the attributes in their signatures makes it so that the templated functions don't need their source in order to determine their own attributes. The fact that we can't guarantee that all of the source is available when compiling a particular module seriously hampers any attempts at general attribute inference. - Jonathan M Davis
Re: toHash = pure, nothrow, const, @safe
On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote: On 12-03-2012 14:16, deadalnix wrote: Le 12/03/2012 13:51, Alex Rønne Petersen a écrit : On 12-03-2012 10:40, Walter Bright wrote: On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem. But people might be relying on your API that just so happens to be pure, but then suddenly isn't! True, but without out, pure, @safe, and nothrow are essentially useless with templates, because far too many templates depend on their arguments for whether they can be pure, @safe, and/or nothrow or not. It's attribute inference for templates that made it possible to use something stuff like std.range and std.algorithm in pure functions. Without that, it couldn't be done (at least not without some nasty casting). Attribute inference is necessary for templates. Now, that _does_ introduce the possibility of a template being to be pure and then not being able to be pure thanks to a change that's made to it or something that it uses, and that makes impossible for any code using it to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. In both cases, I believe that the best solution that we have is to unit test stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the arguments support it, and then those tests can guarantee that it stays that way in spite of any code changes, since they'll fail if the changes break that. - Jonathan M Davis
Re: Calling D from C
On Mon, 12 Mar 2012 12:54:25 -0400, Stewart Gordon smjg_1...@yahoo.com wrote: On 12/03/2012 15:38, Steven Schveighoffer wrote: snip http://dlang.org/phobos/core_runtime.html#initialize And actually, I think this should do everything necessary. No need to call gc_init and thread_attachThis(). Hm... just realized you can't do this, since it's a D function :D Why can't this be dealt with using an extern (C) wrapper function in the D code? All it does is call the extern(C) rt_init. It was my bad, if you are in D-land, it's definitely better to use Runtime.initialize, but from C, the best bet is rt_init. -Steve
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 18:38, Jonathan M Davis wrote: On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote: On 12-03-2012 14:16, deadalnix wrote: Le 12/03/2012 13:51, Alex Rønne Petersen a écrit : On 12-03-2012 10:40, Walter Bright wrote: On 3/12/2012 1:08 AM, Martin Nowak wrote: What's wrong with auto-inference. Inferred attributes are only strengthening guarantees. Auto-inference is currently done for lambdas and template functions - why? - because the function's implementation is guaranteed to be visible to the compiler. For other functions, not so, and so the attributes must be part of the function signature. Isn't auto-inference for templates a Bad Thing (TM) since it may give API guarantees that you can end up silently breaking? As long as you can explicitly specify that too, and that you get a compile time error when you fail to provide what is explicitly stated, this isn't a problem. But people might be relying on your API that just so happens to be pure, but then suddenly isn't! True, but without out, pure, @safe, and nothrow are essentially useless with templates, because far too many templates depend on their arguments for whether they can be pure, @safe, and/or nothrow or not. It's attribute inference for templates that made it possible to use something stuff like std.range and std.algorithm in pure functions. Without that, it couldn't be done (at least not without some nasty casting). Attribute inference is necessary for templates. Now, that _does_ introduce the possibility of a template being to be pure and then not being able to be pure thanks to a change that's made to it or something that it uses, and that makes impossible for any code using it to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. That could be solved with a @ctfe attribute or something, no? Like, if the function has @ctfe, go through all possible CTFE paths (excluding !__ctfe paths of course) and make sure they are CTFEable. In both cases, I believe that the best solution that we have is to unit test stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the arguments support it, and then those tests can guarantee that it stays that way in spite of any code changes, since they'll fail if the changes break that. - Jonathan M Davis -- - Alex
Re: Multiple return values...
On 12 March 2012 17:22, Manu turkey...@gmail.com wrote:
On 12 March 2012 19:03, Iain Buclaw ibuc...@ubuntu.com wrote:
On 12 March 2012 00:44, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can
/
will be doing this on x86-64, as other compilers have already done.
Manu was
arguing that MRV were somehow special and had mystical optimization
potential. That's simply not true.
Here's some tests for you:
// first test that the argument registers allocate as expected...
int gprtest(int x, int y, int z)
{
return x+y+z;
}
Perfect, ints pass in register sequence, return in r0, no memory
access
add r0, r0, r1
add r0, r0, r2
bx lr
float fptest(float x, float y, float z)
{
return x+y+z;
}
Same for floats
fadds s0, s0, s1
fadds s0, s0, s2
bx lr
// Some MRV tests...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Simple case, 2 ints
FAIL, stores the 2 arguments it received in regs straight to output
struct
pointer supplied
stmia r0, {r1, r2}
bx lr
auto mrv2(int x, float y, byte z)
{
return Tuple!(int, float, byte)(x, y, z);
}
Different typed things
EPIC FAIL
stmfd sp!, {r4, r5}
mov ip, #0
sub sp, sp, #24
mov r4, r2
str ip, [sp, #12]
str ip, [sp, #20]
ldr r2, .L27
add ip, sp, #24
mov r3, r0
mov r5, r1
str r2, [sp, #16] @ float
ldmdb ip, {r0, r1, r2}
stmia r3, {r0, r1, r2}
fsts s0, [r3, #4]
stmia sp, {r0, r1, r2}
str r5, [r3, #0]
strb r4, [r3, #8]
mov r0, r3
add sp, sp, #24
ldmfd sp!, {r4, r5}
bx lr
auto range(int *p)
{
return p[0..1];
}
Range
SURPRISE FAIL, even a range is returned as a struct! O_O
mov r2, #1
str r2, [r0, #0]
str r1, [r0, #4]
bx lr
So the D ABI is a complete shambles on ARM!
Unsurprisingly, it all just follows the return struct by-val ABI, which
is
to write it to the stack unconditionally. And sadly, it even thinks the
internal types like range+delegate are just a struct by-val, and
completely
ruins those!
Let's try again with x86...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Returns in eax/edx as expected
movl 4(%esp), %eax
movl 8(%esp), %edx
auto mrv2(int x, float y, int z)
{
return Tuple!(int, float, int)(x, y, z);
}
FAIL! All written to a struct rather than returning in eax,edx,st0 ..
This
is C ABI baggage, D can do better.
movl 4(%esp), %eax
movl 8(%esp), %edx
movl %edx, (%eax)
movl 12(%esp), %edx
movl %edx, 4(%eax)
movl 16(%esp), %edx
movl %edx, 8(%eax)
ret $4
auto range(int *p)
{
return p[0..1];
}
Obviously, the small struct optimisation allows this to work properly
movl $1, %eax
movl 4(%esp), %edx
ret
All that said, x86 isn't a good test case, since all args are ALWAYS
passed
on the stack. x64 would be a much better test since it actually has arg
registers, but I'm on windows, so no x64 for me...
What compiler flags are you using here? For x86, I would have thought
that small structs ( 8 bytes) would be passed back in registers...
only speculating though - will need to see what codegen is being built
from the D code provided to be sure.
-S -O2 -msse2
And as expected, 8byte structs were returned packed in registers from my
examples above. That's a traditional x86 ABI hack which conveniently allows
delegates+ranges to work well on x86, but as you can see, they're proper
broken on other architectures.
OK, -msse2 is not an ARM target option. :~)
Looking around, the Procedure Call Standard for the ARM Architecture
specifically says (section 5.4: Result Return):
A Composite Type not larger than 4 bytes is returned in R0.
A Composite Type larger than 4 bytes ... is stored in memory at an
address passed as an extra argument when the function was called ...
Feel free to correct me if that document is slightly out of date.
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: Multiple return values...
On 12 March 2012 17:49, Iain Buclaw ibuc...@ubuntu.com wrote:
On 12 March 2012 17:22, Manu turkey...@gmail.com wrote:
On 12 March 2012 19:03, Iain Buclaw ibuc...@ubuntu.com wrote:
On 12 March 2012 00:44, Manu turkey...@gmail.com wrote:
On 12 March 2012 00:58, Robert Jacques sandf...@jhu.edu wrote:
That's an argument for using the right register for the job. And we can
/
will be doing this on x86-64, as other compilers have already done.
Manu was
arguing that MRV were somehow special and had mystical optimization
potential. That's simply not true.
Here's some tests for you:
// first test that the argument registers allocate as expected...
int gprtest(int x, int y, int z)
{
return x+y+z;
}
Perfect, ints pass in register sequence, return in r0, no memory
access
add r0, r0, r1
add r0, r0, r2
bx lr
float fptest(float x, float y, float z)
{
return x+y+z;
}
Same for floats
fadds s0, s0, s1
fadds s0, s0, s2
bx lr
// Some MRV tests...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Simple case, 2 ints
FAIL, stores the 2 arguments it received in regs straight to output
struct
pointer supplied
stmia r0, {r1, r2}
bx lr
auto mrv2(int x, float y, byte z)
{
return Tuple!(int, float, byte)(x, y, z);
}
Different typed things
EPIC FAIL
stmfd sp!, {r4, r5}
mov ip, #0
sub sp, sp, #24
mov r4, r2
str ip, [sp, #12]
str ip, [sp, #20]
ldr r2, .L27
add ip, sp, #24
mov r3, r0
mov r5, r1
str r2, [sp, #16] @ float
ldmdb ip, {r0, r1, r2}
stmia r3, {r0, r1, r2}
fsts s0, [r3, #4]
stmia sp, {r0, r1, r2}
str r5, [r3, #0]
strb r4, [r3, #8]
mov r0, r3
add sp, sp, #24
ldmfd sp!, {r4, r5}
bx lr
auto range(int *p)
{
return p[0..1];
}
Range
SURPRISE FAIL, even a range is returned as a struct! O_O
mov r2, #1
str r2, [r0, #0]
str r1, [r0, #4]
bx lr
So the D ABI is a complete shambles on ARM!
Unsurprisingly, it all just follows the return struct by-val ABI, which
is
to write it to the stack unconditionally. And sadly, it even thinks the
internal types like range+delegate are just a struct by-val, and
completely
ruins those!
Let's try again with x86...
auto mrv1(int x, int z)
{
return Tuple!(int, int)(x, z);
}
Returns in eax/edx as expected
movl 4(%esp), %eax
movl 8(%esp), %edx
auto mrv2(int x, float y, int z)
{
return Tuple!(int, float, int)(x, y, z);
}
FAIL! All written to a struct rather than returning in eax,edx,st0 ..
This
is C ABI baggage, D can do better.
movl 4(%esp), %eax
movl 8(%esp), %edx
movl %edx, (%eax)
movl 12(%esp), %edx
movl %edx, 4(%eax)
movl 16(%esp), %edx
movl %edx, 8(%eax)
ret $4
auto range(int *p)
{
return p[0..1];
}
Obviously, the small struct optimisation allows this to work properly
movl $1, %eax
movl 4(%esp), %edx
ret
All that said, x86 isn't a good test case, since all args are ALWAYS
passed
on the stack. x64 would be a much better test since it actually has arg
registers, but I'm on windows, so no x64 for me...
What compiler flags are you using here? For x86, I would have thought
that small structs ( 8 bytes) would be passed back in registers...
only speculating though - will need to see what codegen is being built
from the D code provided to be sure.
-S -O2 -msse2
And as expected, 8byte structs were returned packed in registers from my
examples above. That's a traditional x86 ABI hack which conveniently allows
delegates+ranges to work well on x86, but as you can see, they're proper
broken on other architectures.
OK, -msse2 is not an ARM target option. :~)
Looking around, the Procedure Call Standard for the ARM Architecture
specifically says (section 5.4: Result Return):
A Composite Type not larger than 4 bytes is returned in R0.
A Composite Type larger than 4 bytes ... is stored in memory at an
address passed as an extra argument when the function was called ...
Feel free to correct me if that document is slightly out of date.
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Link:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: toHash = pure, nothrow, const, @safe
On Monday, March 12, 2012 18:44:06 Alex Rønne Petersen wrote: Now, that _does_ introduce the possibility of a template being to be pure and then not being able to be pure thanks to a change that's made to it or something that it uses, and that makes impossible for any code using it to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. That could be solved with a @ctfe attribute or something, no? Like, if the function has @ctfe, go through all possible CTFE paths (excluding !__ctfe paths of course) and make sure they are CTFEable. 1. That goes completely against how CTFE was designed in that part of the idea was that you _wouldn't_ have to annotate it. 2. I don't really know how feasible that would be. At minimum, the fact that CTFE works with classes now would probably render it completely infeasible for classes, since they're polymorphic, and the compiler can't possibly know all of the possible types that could be passed to the function. Templates would screw it over too for the exact same reasons that they can have issues with pure, @safe, and nothrow. It may or may not be feasible without classes or templates being involved. So, no, I don't think that @ctfe would really work. And while I agree that the situation isn't exactly ideal, I don't really see a way around it. Unit tests _do_ catch it for you though. The only thing that they can't catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. - Jonathan M Davis
Re: [OT] Hanlon's Razor (Was: Optimize away immediately-called delegate literals?)
On Sun, Mar 11, 2012 at 03:03:39AM -0400, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.455.1331448575.4860.digitalmar...@puremagic.com... Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte Pardon me veering offtopic at one of your taglines yet again, but I have to say, this is one that I've believed very strongly in for years. It's practically a mantra of mine, a big part of my own personal philosophy. I've never heard it attributed to Napoleon, though. I always knew it as Hanlon's Razor, somewhat of a corollary to Occam's Razor. [...] I guess my sources aren't that reliable. I just copy-n-pasted that quote from somebody else's sig. :-) T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
Re: Multiple return values...
On 12 March 2012 19:49, Iain Buclaw ibuc...@ubuntu.com wrote: OK, -msse2 is not an ARM target option. :~) Oh sorry, I thought you were asking about the x86 codegen ;) I used -S -O2 -float-abi=hard Looking around, the Procedure Call Standard for the ARM Architecture specifically says (section 5.4: Result Return): A Composite Type not larger than 4 bytes is returned in R0. A Composite Type larger than 4 bytes ... is stored in memory at an address passed as an extra argument when the function was called ... Indeed, x86 is the only architecture I know which has this magic 8byte packing. Every other architecture will be just as bad as ARM by the standard C ABI. Something needs to be done about delegates and ranges at the very least, it would seen GDC just see's these as 8 byte structs being passed around by value, and only x86 has a hack to improve this. Does GDC understand MRV internally? I know LLVM does at least, but I couldn't find info about GDC. Feel free to correct me if that document is slightly out of date. Document? :)
Re: toHash = pure, nothrow, const, @safe
On Mon, Mar 12, 2012 at 01:55:33PM -0400, Jonathan M Davis wrote: [...] So, no, I don't think that @ctfe would really work. And while I agree that the situation isn't exactly ideal, I don't really see a way around it. Unit tests _do_ catch it for you though. The only thing that they can't catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. [...] Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. T -- Ruby is essentially Perl minus Wall.
Re: toHash = pure, nothrow, const, @safe
On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote: Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. D doesn't make writing unit tests easy, since there's an intrinsic amount of effort required to write them, just like there is with any code, but it takes away all of the extraneous effort in having to set up a unit test framework and the like. And by removing pretty much anything from the effort which is not actually required, it makes writing unit testing about as easy as it can be. I believe that Walter likes to say that it takes away your excuse _not_ to write them because of how easy it is to write unit tests in D. - Jonathan M Davis
Re: toHash = pure, nothrow, const, @safe
On Mon, Mar 12, 2012 at 02:10:23PM -0400, Jonathan M Davis wrote: On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote: Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. D doesn't make writing unit tests easy, since there's an intrinsic amount of effort required to write them, just like there is with any code, but it takes away all of the extraneous effort in having to set up a unit test framework and the like. And by removing pretty much anything from the effort which is not actually required, it makes writing unit testing about as easy as it can be. I would argue that D *does* make unit tests easier to write, in that you can write them in straight D code inline (as opposed to some testing frameworks that require external stuff like Expect, Python, intermixed with native code), so you don't need to put what you're writing on hold while you go off and write unittests. You can just insert a unittest block after the function/class/etc immediately while the code is still fresh in your mind. I often find myself writing unittests simultaneously with real code, since while writing the code I see a possible boundary condition to test for, and immediately put that in a unittest to ensure I don't forget about it later. This improves the quality of both the code and the unittests. I believe that Walter likes to say that it takes away your excuse _not_ to write them because of how easy it is to write unit tests in D. [...] Yep. They're so easy to write in D that I'd be embarrassed to *not* write them. T -- Famous last words: I *think* this will work...
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 19:04, H. S. Teoh wrote: On Mon, Mar 12, 2012 at 01:55:33PM -0400, Jonathan M Davis wrote: [...] So, no, I don't think that @ctfe would really work. And while I agree that the situation isn't exactly ideal, I don't really see a way around it. Unit tests _do_ catch it for you though. The only thing that they can't catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. [...] Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. T I stopped writing inline unit tests in larger code bases. If I do that, I have to maintain a separate build configuration just for test execution, which is not practical. Furthermore, I want to test my code in debug and release mode, which... goes against having a test configuration. So, I've ended up moving all unit tests to a separate executable that links in all my libraries and runs their tests in debug/release mode. Works much better. I don't feel that unittest in D was really thought through properly for large projects targeting actual end users... -- - Alex
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 18:55, Jonathan M Davis wrote: On Monday, March 12, 2012 18:44:06 Alex Rønne Petersen wrote: Now, that _does_ introduce the possibility of a template being to be pure and then not being able to be pure thanks to a change that's made to it or something that it uses, and that makes impossible for any code using it to be pure. CTFE has the same problem. It's fairly easy to have a function which is CTFEable cease to be CTFEable thanks to a change to it, and no one notices. We've had issues with this in the past. That could be solved with a @ctfe attribute or something, no? Like, if the function has @ctfe, go through all possible CTFE paths (excluding !__ctfe paths of course) and make sure they are CTFEable. 1. That goes completely against how CTFE was designed in that part of the idea was that you _wouldn't_ have to annotate it. Though, rarely, functions written with runtime execution in mind actually Just Work in CTFE. You usually have to change code or special-case things for it to work. In my experience, anyway... 2. I don't really know how feasible that would be. At minimum, the fact that CTFE works with classes now would probably render it completely infeasible for classes, since they're polymorphic, and the compiler can't possibly know all of the possible types that could be passed to the function. Templates would screw it over too for the exact same reasons that they can have issues with pure, @safe, and nothrow. It may or may not be feasible without classes or templates being involved. I hadn't thought of classes at all. In practice, it's impossible then. So, no, I don't think that @ctfe would really work. And while I agree that the situation isn't exactly ideal, I don't really see a way around it. Unit tests _do_ catch it for you though. The only thing that they can't catch is whether the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_ arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable with _a_ set of arguments, it will generally be the fault of the arguments when such a function fails to be pure, nothrow, @safe, and/or CTFEable as expected. If the unit tests don't hit all of the possible static if-else blocks and all of the possible code paths for CTFE, it could still be a problem, but that just means that the unit tests aren't thorough enough, and more thorough unit tests will fix the problem, as tedious as it may be to do that. - Jonathan M Davis -- - Alex
Re: Breaking backwards compatiblity
Marco Leise marco.le...@gmx.de wrote in message news:20120312124959.2ef8e...@marco-leise.homedns.org... I searched every inch of Opera's options screens and never found *any* mention or reference to any Disable AutoUpdate Derek ddparn...@bigpond.com wrote in message news:op.wazmllu534mv3i@red-beast... I found it in a minute. First I tried opera help and it directed me to details about auto-update, which showed how to disable it. It is in the normal UI place for such stuff. Tools - Preferences - Advanced - Security - Auto-Update. Am Sat, 10 Mar 2012 23:44:20 -0500 schrieb Nick Sabalausky a@a.a: They stuck it under Security? No wonder I couldn't find it. That's like putting blue under shapes. :/ So much for every inch ...and false accusations. You made my day! ;) Yup. You've got me there! (I had thought that I had, but I'm not sure if that works for or against me ;) )
Re: toHash = pure, nothrow, const, @safe
On Mon, Mar 12, 2012 at 07:41:39PM +0100, Alex Rønne Petersen wrote: On 12-03-2012 19:04, H. S. Teoh wrote: [...] Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. [...] I stopped writing inline unit tests in larger code bases. If I do that, I have to maintain a separate build configuration just for test execution, which is not practical. Furthermore, I want to test my code in debug and release mode, which... goes against having a test configuration. [...] Hmm. Sounds like what you want is not really unittests, but global program startup self-checks. In my mind, unittests is for running specific checks against specific functions, classes/structs inside a module. I frequently write lots of unittests that instantiates all sorts of templates never used by the real program, contrived data objects, etc., that may potentially have long running times, or creates files in the working directory or other stuff like that. IOW, stuff that are not suitable to be used for release builds at all. It's really more of a way of forcing the program to refuse to start during development when a code change breaks the system, so that the developer notices the breakage immediately. Definitely not for the end-user. If I wanted release-build self-consistency checking, then yeah, I'd use a different framework than unittests. As for build configuration, I've given up on make a decade ago for something saner, which can handle complicated build options properly. But that belongs to another topic. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: toHash = pure, nothrow, const, @safe
On 3/12/2012 11:04 AM, H. S. Teoh wrote: Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. That's exactly how it was intended! It seems like such a small feature, really just a syntactic convenience, but what a difference it makes.
Re: toHash = pure, nothrow, const, @safe
On 12-03-2012 20:08, H. S. Teoh wrote: On Mon, Mar 12, 2012 at 07:41:39PM +0100, Alex Rønne Petersen wrote: On 12-03-2012 19:04, H. S. Teoh wrote: [...] Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. [...] I stopped writing inline unit tests in larger code bases. If I do that, I have to maintain a separate build configuration just for test execution, which is not practical. Furthermore, I want to test my code in debug and release mode, which... goes against having a test configuration. [...] Hmm. Sounds like what you want is not really unittests, but global program startup self-checks. In my mind, unittests is for running specific checks against specific functions, classes/structs inside a That's what I do. I simply moved my unittest blocks to a separate executable. module. I frequently write lots of unittests that instantiates all sorts of templates never used by the real program, contrived data objects, etc., that may potentially have long running times, or creates files in the working directory or other stuff like that. IOW, stuff that are not You never know if some code that seems to work fine in debug mode breaks in release mode then (until your user runs into a bug). This is why I want full coverage in all configurations. suitable to be used for release builds at all. It's really more of a way of forcing the program to refuse to start during development when a code change breaks the system, so that the developer notices the breakage immediately. Definitely not for the end-user. Right. That's why my tests are in a separate executable from the actual program. If I wanted release-build self-consistency checking, then yeah, I'd use a different framework than unittests. IMHO unittest works fine for both debug and release, just not inline. As for build configuration, I've given up on make a decade ago for something saner, which can handle complicated build options properly. But that belongs to another topic. I used to use Make for this project, then switched to Waf. It's an amazing build tool. T -- - Alex
Re: Breaking backwards compatiblity
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.531.1331533449.4860.digitalmar...@puremagic.com... On Mon, Mar 12, 2012 at 01:36:06AM -0400, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.510.1331520028.4860.digitalmar...@puremagic.com... [...] Personally, I found discrete math to be the easiest class I took since kindergarten (*Both* of the times they made me take discrete math. Ugh. God that got boring.) It was almost entirely the sorts of things that any average coder already understands intuitively. Like DeMorgan's: I hadn't known the name DeMorgan, but just from growing up writing if statements I had already grokked how it worked and how to use it. No doubt in my mind that *all* of us here have grokked it (even any of us who might not know it by name) *and* many of the coworkers I've had who I'd normally classify as incompetent VB-loving imbiciles. It's not that I didn't already know most of the stuff intuitively, Didn't mean to imply that you didn't, of course. Then there was Pidgeonhole principle, which was basically just obvious corollaries to preschool-level spacial relations. Etc. All pretty much BASIC-level stuff. Oh raally?! Just wait till you learn how the pigeonhole principle allows you to do arithmetic with infinite quantities... ;-) Well, the discrete math courses offered at the places I went to didn't take things that far. Just explained the principle itself. (And before you shoot me down with infinite quantities are not practical in programming, I'd like to say that certain non-finite arithmetic systems actually have real-life consequences in finite computations. Look up Hydra game sometime. Or Goldstein sequences if you're into that sorta thing.) Yea, I don't doubt that. While no game programmer, for example, would be caught dead having their code crunching calculus computations, there are some computations done in games that are obtained in the first place by doing some calculus (mostly physics, IIRC). Not exactly the same thing, but I get that applicablity of theory isn't limited to what the computer is actually calculating. [...] However, I also found that most big-name colleges are geared toward producing researchers rather than programmers in the industry. The colleges I've seen seemed to have an identity crisis in that regard: Sometimes they acted like their role was teaching theory, sometimes they acted like their role was job training/placement, and all the time they were incompetent at both. In my experience, I found that the quality of a course depends a LOT on the attitude and teaching ability of the professor. I've had courses which were like mind-openers every other class, where you just go wow, *that* is one heck of a cool algorithm!. Yea, I *have* had some good instructors. Not many. But some. Unfortunately, (1) most professors can't teach; (2) they're not *paid* to teach (they're paid to do research), so they regard it as a tedious chore imposed upon them that takes away their time for research. This makes them hate teaching, and so most courses suck. #1 I definitely agree with. #2 I don't doubt for at least some colleges, although I'm uncertain how applicable it is to public party schools like BGSU. There didn't seem to be much research going on there as far as I could tell, but I could be wrong though. [...] I once made the mistake of signing up for a class that claimed to be part of the CS department and was titled Optimization Techniques. I thought it was obvious what it was and that it would be a great class for me to take. Turned out to be a class that, realistically, belonged in the Math dept and had nothing to do with efficient software, even in theory. Wasn't even in the ballpark of Big-O, etc. It was linear algebra with large numbers of variables. Aahahahahaha... must've been high-dimensional polytope optimization stuff, I'll bet. Sounds about right. I think the term linear programming was tossed around a bit, which I do remember from high school to be an application of linear algebra rather than software. That stuff *does* have its uses... Yea, I never doubted that. Just not what I was expected. Really caught me offguard. but yeah, that was a really dumb course title. Another dumb course title that I've encountered was along the lines of computational theory where 95% of the course talks about *uncomputable* problems. You'd think they would've named it *un*computational theory. :-P Yea that is kinda funny. I'm sure it would be great material for the right person, but it wasn't remotely what I expected given the name and department of the course. (Actually, similar thing with my High School class of Business Law - Turned out to have *nothing* to do with business whatsoever. Never understood why they didn't just call the class Law or Civic Law.) Kinda felt baited and switched both times.
Re: Multiple return values...
On 12 March 2012 17:59, Manu turkey...@gmail.com wrote: On 12 March 2012 19:49, Iain Buclaw ibuc...@ubuntu.com wrote: OK, -msse2 is not an ARM target option. :~) Oh sorry, I thought you were asking about the x86 codegen ;) I used -S -O2 -float-abi=hard Looking around, the Procedure Call Standard for the ARM Architecture specifically says (section 5.4: Result Return): A Composite Type not larger than 4 bytes is returned in R0. A Composite Type larger than 4 bytes ... is stored in memory at an address passed as an extra argument when the function was called ... Indeed, x86 is the only architecture I know which has this magic 8byte packing. Every other architecture will be just as bad as ARM by the standard C ABI. Something needs to be done about delegates and ranges at the very least, it would seen GDC just see's these as 8 byte structs being passed around by value, and only x86 has a hack to improve this. Does GDC understand MRV internally? I know LLVM does at least, but I couldn't find info about GDC. It does not. Feel free to correct me if that document is slightly out of date. Document? :) Link: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Arbitrary abbreviations in phobos considered ridiculous
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.wa1432xjeav7ka@localhost.localdomain... On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky a@a.a wrote: You know what I think it is (without actually looking at the code): I think they tried to do some highly misguided and even more poorly implemented hack (which they no-doubt thought was clever) for dealing with *cough* old *cough* browsers by inserting a meta redirect to a hardcoded URL, and then used JS to disable the meta redirect. If that's the case, I don't know how the fuck they managed to convince themselves that make one drop of sense. It could be that they don't care to cater to people who hate JS. There aren't that many of you. There are enough. And it's beside the point anyway. Things that don't need JS sholdn't be using JS anyway, regardless of whether you hate it or have enough brain damage to think it's the greatest thing since the transistor.
Re: Arbitrary abbreviations in phobos considered ridiculous
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.wa1432xjeav7ka@localhost.localdomain... You may want to consider -- if you on principle don't view pages with information because the pages contain JS, you are the one missing out on the information. And it's not on principle, I just find it not usually worth bothering. I'd rather just move on to something else that's actually well designed. Problem though is when content gets *tied* to such moronic things. Even if 99% of people don't hate JS, these uses of it *are* still moronic bullshit.
Re: Arbitrary abbreviations in phobos considered ridiculous
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.wa16bibneav7ka@localhost.localdomain... On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Insert obligatory link: http://drdobbs.com/184401197 Very insightful article. Interesting point to make about D, however. It's really *difficult* to make related non-member non-friend functions, since all functions inside the same module as a type are friends. Geez, I *still* keep forgetting about that. And I'm not sure I've ever really found it particularly useful. I'd be happy to see that go away in D3. Acually, I'd argue in favor of changing private to module (much like how we have the package access specifier) and then adding a more traditional private. I doubt any of this will ever actually happen. But, oh well, one can dream.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Mon, 12 Mar 2012 15:27:30 -0400, Nick Sabalausky a@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.wa1432xjeav7ka@localhost.localdomain... On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky a@a.a wrote: You know what I think it is (without actually looking at the code): I think they tried to do some highly misguided and even more poorly implemented hack (which they no-doubt thought was clever) for dealing with *cough* old *cough* browsers by inserting a meta redirect to a hardcoded URL, and then used JS to disable the meta redirect. If that's the case, I don't know how the fuck they managed to convince themselves that make one drop of sense. It could be that they don't care to cater to people who hate JS. There aren't that many of you. There are enough. Apparently not. http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/ I'm perfectly willing to give up on 1-2% of Internet users who have JS disabled. And it's beside the point anyway. Things that don't need JS sholdn't be using JS anyway, regardless of whether you hate it or have enough brain damage to think it's the greatest thing since the transistor. No, it *is* the point. As a web developer, javascript is used by the vast majority of users, so I assume it can be used. If you don't like that, I guess that's too bad for you, you may go find content elsewhere. It's not worth my time to cater to you. It's like saying you think cell phones are evil, and refuse to get one. But then complain that there are no pay phones for you to use, and demand businesses install pay phones in case people like you want to use them. That being said, I found it quite funny that wikipedia last year blacked out itself using javascript. I just so happened to want to quote something from wikipedia, and noticed the site came up, then had a black page put over it. I just disabled javascript, and could happily use the site, posting the link (of course, I had to mention it would only work tomorrow when the blackout ended). -Steve
Re: toHash = pure, nothrow, const, @safe
On 2012-03-12 19:41, Alex Rønne Petersen wrote: I stopped writing inline unit tests in larger code bases. If I do that, I have to maintain a separate build configuration just for test execution, which is not practical. Furthermore, I want to test my code in debug and release mode, which... goes against having a test configuration. I don't inline my unit test either. So, I've ended up moving all unit tests to a separate executable that links in all my libraries and runs their tests in debug/release mode. Works much better. I don't feel that unittest in D was really thought through properly for large projects targeting actual end users... I agree. I've also started to do more high level testing of some of my command line tools using Cucumber and Aruba. But these test are written in Ruby because of Cucumber and Aruba. http://cukes.info/ https://github.com/cucumber/aruba -- /Jacob Carlborg
Re: Multiple return values...
On Mon, 12 Mar 2012 02:15:55 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/12/2012 05:01 AM, Robert Jacques wrote:
On Sun, 11 Mar 2012 21:49:52 -0500, Mantis mail.mantis...@gmail.com
wrote:
12.03.2012 4:00, Robert Jacques пишет:
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch
wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical, but it is certainly there.
void main(){
auto a = foo(); // MRV/struct return
bar(a.x); // defined in a different compilation unit
}
struct return has to write out the whole struct on the stack because of
layout guarantees, probably making the optimized struct return calling
convention somewhat slower for this case. The same does not hold for
MRV.
The layout of the struct only has to exist _when_ the address is
taken. Before that, the compiler/language/optimizer is free to (and
does) do whatever it want. Besides, in your example only the address
of a field is taken, the compiler will optimize away all the other
pieces a (dead variable elimination).
That's the point of discussion. Fields of structure may not be optimized
away, because they are not independent variables. In D you have
unchecked pointer-to-pointer casts, and results of these casts should
depend on target architecture, not on optimizer implementation. At
particular, if such optimizations are allowed, some C API will no longer
be accessible from D.
Unused fields of a structure are optimized away _today_. Unless a piece
of code takes the address of the struct, all of the fields are treated
as independent variables.
The only point I was trying to make is that the 'unless' part does not
apply to MRV.
True. But the principal argument is that MRV implemented via structs is somehow
less efficient than 'real' MRV. MRV structs would never have their address
taken and thus the 'unless' clause never happens.
Re: toHash = pure, nothrow, const, @safe
That could be solved with a @ctfe attribute or something, no? Like, if the function has @ctfe, go through all possible CTFE paths (excluding !__ctfe paths of course) and make sure they are CTFEable. Everything that's pure should be CTFEable which doesn't imply that you can turn every CTFEable function into a pure one.
Re: Multiple return values...
On Mon, 12 Mar 2012 04:46:45 -0500, Mantis mail.mantis...@gmail.com wrote: 12.03.2012 6:01, Robert Jacques пишет: On Sun, 11 Mar 2012 21:49:52 -0500, Mantis mail.mantis...@gmail.com wrote: [...] That's the point of discussion. Fields of structure may not be optimized away, because they are not independent variables. In D you have unchecked pointer-to-pointer casts, and results of these casts should depend on target architecture, not on optimizer implementation. At particular, if such optimizations are allowed, some C API will no longer be accessible from D. Unused fields of a structure are optimized away _today_. Unless a piece of code takes the address of the struct, all of the fields are treated as independent variables. I can't confirm: http://pastebin.com/YgBULGfe Prints 42\n3.14\n, compiled with dmd -release on windows x86. How exactly did you find out that such optimization is performed? We are referring to values on the stack; unless inlined, the returning function always has to return all values for both structs and MRV. So, by 'optimized away' I'm referring to the ability of the optimizer to not keep values around, if that's more efficient. So to test it, you'd probably want to include enough operations for the optimizer not want to do this. Second, taking the address of a field might be tripping the optimizer up, so try looking at the stack directly. I honestly don't know if DMD does this particular optimization as the x86 stack is cheap and out of order chips (i.e. x86) thrive on independent assignments, but it's a big and very visible feature of NVCC, a GPU C/C++ compiler.
http://dlang.org/language-reference.html is down
See subject.
Re: toHash = pure, nothrow, const, @safe
On Monday, March 12, 2012 21:36:21 Martin Nowak wrote: That could be solved with a @ctfe attribute or something, no? Like, if the function has @ctfe, go through all possible CTFE paths (excluding !__ctfe paths of course) and make sure they are CTFEable. Everything that's pure should be CTFEable which doesn't imply that you can turn every CTFEable function into a pure one. I don't think that that's quite true. pure doesn't imply @safe, so you could do pointer arithmetic and stuff and the like - which I'm pretty sure CTFE won't allow. And, of course, if you mark a C function as pure or subvert pure through casts, then pure _definitely_ doesn't imply CTFEability. - Jonathan M Davis
Re: toHash = pure, nothrow, const, @safe
On Monday, March 12, 2012 11:25:41 H. S. Teoh wrote: On Mon, Mar 12, 2012 at 02:10:23PM -0400, Jonathan M Davis wrote: On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote: Tangential note: writing unit tests may be tedious, but D's inline unittest syntax has alleviated a large part of that tedium. So much so that I find myself writing as much code in unittests as real code. Which is a good thing, because in the past I'd always been too lazy to write any unittests at all. D doesn't make writing unit tests easy, since there's an intrinsic amount of effort required to write them, just like there is with any code, but it takes away all of the extraneous effort in having to set up a unit test framework and the like. And by removing pretty much anything from the effort which is not actually required, it makes writing unit testing about as easy as it can be. I would argue that D *does* make unit tests easier to write, in that you can write them in straight D code inline (as opposed to some testing frameworks that require external stuff like Expect, Python, intermixed with native code), so you don't need to put what you're writing on hold while you go off and write unittests. You can just insert a unittest block after the function/class/etc immediately while the code is still fresh in your mind. I often find myself writing unittests simultaneously with real code, since while writing the code I see a possible boundary condition to test for, and immediately put that in a unittest to ensure I don't forget about it later. This improves the quality of both the code and the unittests. I didn't say that D doesn't make writing unit tests easier. I just said that it doesn't make them _easy_. They're as much work as writing any code is. But by making them easier, D makes them about as easy to write as they can be. Regardless, built-in unit testing is a fantastic feature. - Jonathan m Davis
Nevermind (Was: http://dlang.org/language-reference.html is down)
I still had meta redirects disabled from when I was reading that Dr Dobbs article.
Re: toHash = pure, nothrow, const, @safe
On 03/12/2012 09:46 PM, Jonathan M Davis wrote: On Monday, March 12, 2012 21:36:21 Martin Nowak wrote: That could be solved with a @ctfe attribute or something, no? Like, if the function has @ctfe, go through all possible CTFE paths (excluding !__ctfe paths of course) and make sure they are CTFEable. Everything that's pure should be CTFEable which doesn't imply that you can turn every CTFEable function into a pure one. I don't think that that's quite true. pure doesn't imply @safe, so you could do pointer arithmetic and stuff and the like - which I'm pretty sure CTFE won't allow. And, of course, if you mark a C function as pure or subvert pure through casts, then pure _definitely_ doesn't imply CTFEability. - Jonathan M Davis CTFE allows quite some pointer arithmetic, but makes sure it is actually safe.
Re: toHash = pure, nothrow, const, @safe
Because that requires having all of the source code. The fact that we have .di files prevents that. It doesn't require all source code. It just means that without source code nothing can be inferred and the attributes fall back to what has been annotated by hand. It could be used to annotated functions at the API level and have the compiler check that transitively. It should behave like implicit conversion to pure nothrow ... if the compiler hasn't found them inapplicable. On the downside it has some implications for the compilation model because functions would need to be analyzed transitively. But then again we already do this for CTFE.
Re: Arbitrary abbreviations in phobos considered ridiculous
It could be that they don't care to cater to people who hate JS. There aren't that many of you. There are enough. Apparently not. http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/ I'm perfectly willing to give up on 1-2% of Internet users who have JS disabled. I use NoScript, so by default my JS is disabled for 99% of the sites I go to. That means you'll give up on me? Hmm :( And it's beside the point anyway. Things that don't need JS sholdn't be using JS anyway, regardless of whether you hate it or have enough brain damage to think it's the greatest thing since the transistor. No, it *is* the point. As a web developer, javascript is used by the vast majority of users, so I assume it can be used. If you don't like that, I guess that's too bad for you, you may go find content elsewhere. It's not worth my time to cater to you. Unfortunately I need to disagree with you there. JS although is nice sometimes, I find more often a pain in the butt rather than a help. NoScript shows on quite a few sites that they have some 10 or 20 sites they reference JS scripts from, which doesn't make sense. half of those sites tend to be statistic gathering sites, which I don't particularly trust. Actually I don't trust a lot of sites. Plus I'm a little more anal about what does and does not run on my computer; Last think I need when I open a Page is it loads ten or twenty extra things I don't care about, takes up resources I don't want to give up, uses more memory, and for a tiny convenience, or trying to make it more an 'application' experience rather than a web Page. In my mind, JS should be used to help you where HTML and CSS cannot go. Checking inputs for a form post, some menus, etc. I have refused to go to some sites that require you to disable NoScript or Adblocker Plus; I'm willing to allow access past those features it for my one or two visits but I refuse to disable/remove it. I just feel safer that way. I wonder if I didn't have it, how many gigs I would be waiting and using for ads and other useless crap. It's like saying you think cell phones are evil, and refuse to get one. But then complain that there are no pay phones for you to use, and demand businesses install pay phones in case people like you want to use them. Maybe... I consider myself simple and practical; I use features and items that serve their purpose (Usually specific). I enjoy a simple cell phone, no bells, no whistles. Give me access to dialing a number, hold a small list of names and numbers I dial recently or enter in, time and date. That's all I ever want. Instead they are pushing cell phones that are actually mini-computers (Android and smart phones); Nothing wrong with that I guess, but I just want a phone, nothing special. In the same regard you can compare that people could refuse to use a phone booth unless it has a computer hooked up, internet access, use it to check email and browse while you talk, or doesn't allow you to send text messages and enter a quarter to send it, and doesn't have a camera you can snap a picture of yourself to show how good or drunk you are to your friends.
Re: Nevermind (Was: http://dlang.org/language-reference.html is down)
On Mon, Mar 12, 2012 at 04:45:39PM -0400, Nick Sabalausky wrote: I still had meta redirects disabled from when I was reading that Dr Dobbs article. [...] Somebody should invent per-site meta redirect enabling... :-P In fact, most browser options should be configurable per site/domain/etc.. (I think Opera goes pretty far with this, though not as far as it could have.) T -- To provoke is to call someone stupid; to argue is to call each other stupid.
Re: Multiple return values...
On Mon, 12 Mar 2012 04:25:54 -0500, Manu turkey...@gmail.com wrote:
On 12 March 2012 04:00, Robert Jacques sandf...@jhu.edu wrote:
On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr timon.g...@gmx.ch wrote:
On 03/11/2012 11:58 PM, Robert Jacques wrote:
Manu was arguing that MRV were somehow special and had mystical
optimization potential. That's simply not true.
Not exactly mystical, but it is certainly there.
void main(){
auto a = foo(); // MRV/struct return
bar(a.x); // defined in a different compilation unit
}
struct return has to write out the whole struct on the stack because of
layout guarantees, probably making the optimized struct return calling
convention somewhat slower for this case. The same does not hold for MRV.
The layout of the struct only has to exist _when_ the address is taken.
Before that, the compiler/language/optimizer is free to (and does) do
whatever it want. Besides, in your example only the address of a field is
taken, the compiler will optimize away all the other pieces a (dead
variable elimination).
No, it can't. That's the point. It must preserve the struct in case you
fiddle with the pointer. Taking the pointer is explicit in this case, but
if you passed anything in the struct to another function by ref, you've
setup the same scenario.
Okay, to be clear about things, once a struct is returned the optimizer can do
anything to it wants. Certain compilers are extremely aggressive about this
because on their hardware it matters. C and C++ compilers do this today, so
yes, compilers can.
Wait, ARM?! That's really cool. However, as far as I know, D on ARM is very
experimental. Having an experimental compiler not eak out every last cycle
is not something that should be unexpected.
That said, I'm not sure what point you were trying to make, aside from
backend quality-of-implementation issues. I think bringing these issues up
is important, but they are tangent to the language changes you're asking
for.
This is using GCC's backend which is not really experimental, it has
decades of field use. The point here is that we are seeing the effect of
the C ABI applied directly to this problem, and it's completely un-workable.
I'm trying to show that D needs to declare something of an ABI promise when
applied to this problem if it is to be a useful+efficient feature. Again, C
can't express this problem, and we won't get any value from of the C ABI to
make this contruct efficient, but a very simple and efficient solution does
exist.
GCC is very large collection of things and its backend has a general reputation
of being second place to the commercial vendors by a decent margin (25+%) and I
think also to LLVM. I was more referring to GDC's mapping to the GCC arm
backend and the associated runtime issues, etc.
As for a simple and efficient solution existing: show me and academic paper or
compiler that gets it right. Then show me the study on a large codebase that
its actually more efficient. Then we will listen. Until then, I'm liable to
trust existing wisdom.
Why should D place this constraint on future compilers? D currently only
specifies the ABI for x86. I'm fairly sure it would follow the best
practices for each of the other architecture, but none of them have been
established yet.
Constraint? Perhaps you mean 'liberation'...
The x86 ABI is not a *best* practise by a long shot. It is only banking on
a traditional x86 trick for small structs.
Let us assume for a moment that the x86 design is good for x86, but terrible
for ARM and vice versa. Why should either backend do something subpar for the
other. Generating code for a IOE CPU vs OOE CPU vs a stack machine vs a
register machine are all very different operations and the backend should have
the liberation to do whatever is best.
I'm was giving you an example that seemed to satisfy your complaints. An
no, actually it can't return in those registers at zero cost. There is a
reason why we don't use all the registers to both pass and return
arguments: we need some registers free to work on them both before and
after the call.
D should define an MRV ABI which is precisely the ABI for passing multiple
args TO a function, but in reverse, for any given architecture. .. I've
never said anything about using ALL the registers, I say to use all the
ARGUMENT registers.
On x64, that is 4 GPR regs, and 4 XMM regs.
The point is that increasing the number of return registers isn't free and that
simply matching the best number of argument registers is not, ipso facto ideal.
I know Go has MRV. What does its ABI look like? What does ARM prefer? I'd
recommend citing some papers or a compiler or something. Otherwise, it
looks like you're ignoring the wisdom of the masses or simply ignorant.
I don't have a Go toolchain, do you wanna run my tests above?
Are you suggesting I have no idea what I'm talking about with respect to
efficient calling conventions? The very fastest way is to return in
Re: Multiple return values...
Is this basically like saying it'll never happen? There is already a pending pull request implementing the syntax, that addresses half of the feature straight up.. codegen can come later, I agreed earlier that it is of lesser importance. You don't see the immediate value in a convenient MRV syntax? It would improve code clarity in many places, and allow the code to also be more efficient down the road. The tuple unpacking feature has nothing to do with MRV. Please don't conflate them, it creates a lot of confusion. Using registers to full extend look really nice but there are some reasons MRV is not going to happen any time soon. - Departing from platform ABI's will put us on an isle where we need our own compiler backends, debuggers and maybe even linkers and OSes. - Your favorite compiler should be great at inlining so chained function calls could have ZERO overhead passing return values. - It is not very efficient to combine MRV with tuples that have a contiguous memory layout. Instead of in-place NRVO this would be 'callee stack-registers-caller stack'.
Re: Breaking backwards compatiblity
On Mon, Mar 12, 2012 at 03:15:32PM -0400, Nick Sabalausky wrote: H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.531.1331533449.4860.digitalmar...@puremagic.com... [...] (And before you shoot me down with infinite quantities are not practical in programming, I'd like to say that certain non-finite arithmetic systems actually have real-life consequences in finite computations. Look up Hydra game sometime. Or Goldstein sequences if you're into that sorta thing.) Argh. Epic fail on my part, it's *Goodstein* sequence, not Goldstein. Yea, I don't doubt that. While no game programmer, for example, would be caught dead having their code crunching calculus computations, there are some computations done in games that are obtained in the first place by doing some calculus (mostly physics, IIRC). Not exactly the same thing, but I get that applicablity of theory isn't limited to what the computer is actually calculating. I think the bottom line is that a lot of this stuff needs someone who can explain and teach it in an engaging, interesting way. It's not that the subject matter itself is boring or stupid, but that the teacher failed at his job and so his students find the subject boring and stupid. [...] Our course descriptions didn't have much fine print. Just one short vaguely-worded paragraph. I probably could have asked around and gotten a syllubus from previous semesters, but I didn't learn advanced student tricks like that until a few years into college. ;) Plus, that's other concerns, like scheduling and requirements. I found that a lot of my course selections had to be dictated more by scheduling and availability than much anything else. I guess I was lucky then. There were a couple o' useless mandatory courses I had to take, but for the most part, I got to choose what I wanted. (And then my geeky side took over and I filled up most of my electives with math courses... sigh...) T -- Some days you win; most days you lose.
Re: D support in Thrift needs your reviews!
On Monday, 12 March 2012 at 05:44:10 UTC, Martin Nowak wrote: I did recently tried it out because I wanted to test some async Fiber kqueue stuff. It did fail to compile though because of conflicting selective imports. You probably want to avoid those until the remaining issues are sorted out. Ouch, no idea how that happened – before the 2.058 release, I tested it regularly against the old import implementation, my own fix for bug 314, the then-trunk including Christian's 314 fixes, and I even tested most revisions during the »let's back this out shortly before the release« fiasko, but I must have somehow missed the actual release when doing so. In any case, I pushed a fix to the Thrift JIRA and the GitHub repo [1], but was only able to test on OS X, so let me know if it still breaks for you. - Compile-time Thrift IDL parsing: I probably forgot to lex floating point literals. https://gist.github.com/2019921#gistcomment-90654 Nice! I hope I'll miraculously find myself with a free afternoon during the next week or so, can't wait to play around with it. Also, I'm thinking about rewriting the codegen completely in CTFE (i.e. producing a big string to be mixed in instead of using templates with string mixins only where required), because this would allow running the generator separately (and caching the output in a regular .d file) for faster build times… - A HashSet implementation in Phobos it could generate code against; currently, a void[0]-AA-based hack is used. I've been meaning to look into adding something to std.container for ages now, but with me being swamped in work and the container design being »in flux« (e.g. allocators)… Yup, at some point we should stick a not yet ready allocator design into std.experimental before it inhibits even more development. Andrei? ;) The void[0][Key] is a good trick, I always used empty structs. I expose a (minimalistic) thrift.util.HashSet wrapper, though, to avoid too much confusion on the user side (and besides, an empty struct is probably cleaner anyway). David [1] https://github.com/klickverbot/thrift
Re: Review of Jose Armando Garcia Sancio's std.log
On Mon, Mar 12, 2012 at 1:11 PM, Robert Jacques sandf...@jhu.edu wrote: On Mon, 12 Mar 2012 00:15:14 -0500, Jose Armando Garcia jsan...@gmail.com wrote: On Wed, Mar 7, 2012 at 7:16 AM, Robert Jacques sandf...@jhu.edu wrote: On Tue, 06 Mar 2012 21:22:21 -0600, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 3/6/12 6:05 PM, Geoffrey Biggs wrote: That approach means that if I actually do have a fatal error, I can't mark it as such. Use log.fatal for those. Andrei But fatal Logs a fatal severity message. Fatal log messages terminate the application after the message is persisted. Fatal log message cannot be disable at compile time or at run time. The point is that he want to log a fatal message and then terminate in a custom manner. I don't see a problem with convince functions that log and error and then throw, but not having the option to not throw is an unnecessary limitation. Okay. Let me say this one last time. If you don't want to assert or throw don't use fatal and critical. I think we are done beating a dead horse. Maybe it is not clear from the documentation but the only reason why fatal and critical exist is because of their assert and throw semantic. This is also the reason why you can't disable them. I understand that to a person that has not read the documentation is may not be clear to them that fatal(message) asserts and critical(message) throws. Knowing this observation maybe we can remove these severities and make the behavior more obvious by adding the tempalte logAndThrow. Thanks, -Jose There is a strong impression that a 'fatal' error and an 'error' will appear differently in the log file. So long as fatal is anything more than log an error, flush and throw, there will be people wanting to separate the fatal log level from fatal log and throw command. I think the logAndThrow will clear up this confusion. Okay. Let me try to wipe something up soonish but it may take me some time given my current schedule.
