Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-09-29 23:26, David Nadlinger wrote: Only the x64 variant of SEH is zero-cost. On x86, exception handlers must be installed into a linked list in the function prologue, which takes a few pushes/movs and popped off again in the epilogue. David Ok, I see. -- /Jacob Carlborg
John Chapman (Juno), calling for John Chapman (not spam)
This will sound like spam for a bit... I'm looking to get in contact with John Chapman, he is the creator of the Juno Class libraries way back in 2006. His last known commit was in 2008. The best I have found isn't helpful: Author: John John@0c92f239-eb13-0410-ac4f-b6215be077db 2006-05-17 02:13:28 It may be that this John Chapman is still lurking these board, and may be the same who has posted back in Jun 2012 http://www.digitalmars.com/d/archives/digitalmars/D/SetTimer_function_not_found_169224.html#N169231 Please, if you know you are the John Chapman I'm looking for, or have heard of his whereabouts/contact information please send me an email, my contact information is much easier to find or reply to this thread. I wish to get a hold of John Chapman because he has a license https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/juno/licence.txt Which changes the second paragraph of the Boost License as quoted below: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. I am looking to get permission to license under Boost such that it would be compatible with Phobos and allow for possible inclusion of some parts. I will also make the public statement that my contributions can be licensed under Boost.
XChat/HexChat plugin bindings
Very small announcement, but I just put up bindings for the XChat plugin interface, including an example with VisualD project files. It's a nice little real-world test of DLLs on Windows written in D. Both the bindings and example should work on other platforms too, but I haven't been able to test it. Maybe someone will find it interesting. https://github.com/JakobOvrum/xchatd
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/29/2012 9:08 AM, Andrej Mitrovic wrote: What needs to be taken into account is that D will inevitably be able to link with many C++ libraries, some of which will have exceptions turned on. We now have SWIG with good but limited support of C++ wrapping, dstep will probably get C++ support, and my own (unreleased) dgen is a C++ wrapper generator too (it's starting to show signs of life, so far 2 C++ libraries were successfully automatically wrapped, pugixml and taglib). Also, consider that in C++ you can throw any type, such as an int. There is no credible way to make this work reasonably in D, as exceptions are all derived from Exception.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 10/1/12, Walter Bright newshou...@digitalmars.com wrote: Also, consider that in C++ you can throw any type, such as an int. There is no credible way to make this work reasonably in D, as exceptions are all derived from Exception. Is that a bug or a feature? :)
Re: Rust and D
Looking at Rust's concurrency model, it does have some great ideas. I wonder what would happen if D used thread-local heaps... As far as syntax goes, the shared keyword could be used to distinguish between the heap types. I'm not sure how all this would work with new, but I'm sure someone can think of a clean syntax. In all, it's an intriguing idea, and it could fit with D's current concurrency model extremely well. I can definitely see this breaking code, but not much more than the switch to TLS globals did. It might be something to consider eventually.
Re: dynamic library building and loading
On Saturday, 29 September 2012 at 16:09:14 UTC, Jacob Carlborg wrote: There's no point in doing that. But what I'm saying is if you know beforehand the libraries you will use you can get quite far with static libraries. There are plenty of cases where you have to use a dynamically loaded lib even if you know before hand what will be loaded. I think you understand this if I read your posts correctly. In my case I have a pre-existing C++ app that is designed to load user defined C++ plugins. I wanted to interface D to one of my own C++ plugins, but I apparently cannot do it reliably because of initialization issues with the GC and possibly some other obscure items. If I can figure out what needs to be done to resolve the problem in enough detail, then maybe I can hack the runtime source and roll out a solution. The GC always seems to pop up as a source of problems. For long term solution, the GC should be made 100% optional (in practice as opposed to in theory), the standard library ought to be made to work with or wothout a GC (or simply without), and the GC itself should be easily replaceable with alternate versions. I think this idea has already been discussed elsewhere, and is on the TODO list (I hope!). --rt
Re: dynamic library building and loading
On Friday, 28 September 2012 at 21:26:47 UTC, Iain Buclaw wrote: The way I intend to address it is to have each module handle it's own gshared/thread data and pass the information to the D runtime during the module construction stage (.ctor) - there is already something done this way for _Dmodule_ref - so it may end up being that two new fields will be tacked onto it; void[] tlsdata, void[] gsharedata; I re-built libgphobos and libgdruntime with -fPIC and I can now successfully create dynamically loaded D libs. I have successfully linked a dynamic D lib to a C++ app, executing some test code successfully. I have not yet tried to dlopen a dynamic D lib from C++, but I will try maybe tomorrow. My simple dynamic lib test seems to run fine, but I understand that there may be problems, such as the GC failing to work properly, and perhaps more can/will go wrong as per Jacob's post http://forum.dlang.org/post/k4219f$uft$1...@digitalmars.com Any idea when/if you will get around to implementing a fix? Wish I could help but I've only just started looking at the source code, so whatever I try to fix will probably cause more harm than good for a while (but it's a start). --rt
Re: Dangling if
On Friday, 28 September 2012 at 17:40:17 UTC, Andrej Mitrovic
wrote:
On 9/28/12, Bernard Helyer b.hel...@gmail.com wrote:
By the time the compiler even has a concept of an 'if
statement'
or a 'block' the whitespace is long gone. Not to say you
couldn't change the lexing model to detect such things,
but it's not a simple as you make it sound.
I see, so it's an implementation limitation. I guess we'll have
to
resort to that dlint tool which will have to be built.
Personally, EVEN when I'm doing a 1 line if, I *still* wrap it in
a block. EG:
if(a == 0)
a = 1;
or
if(a == 0) a = 1;
Becomes:
if(a == 0)
{a = 1;}
or
if(a == 0) {a = 1;}
It might look iffy at first, but very quickly feels natural. It
may look like it requires (god forbid) useless typing, but when
that 1 liner becomes a 2 liner, it saves your life.
It has saved mine more than once actually!
I've done the dangling if bug often. One day I said no-more!.
I've addopted the above format, and it has not happened to me
since.
Further more, thanks to D's ban on if();, you can litterally
never fail with this format. I warmly recommend it to every one.
Re: Dangling if
On Sunday, September 30, 2012 11:42:40 monarch_dodra wrote: Personally, EVEN when I'm doing a 1 line if, I *still* wrap it in a block. EG: To each their own. Personally, it drives me nuts to have braces when they're completely unnecessary. I use braces only when the condition or body is more than one line long. And I don't think that I've _ever_ run into a dangling else problem (if nothing else, because I'd always use braces in cases where it could happen). But everyone seems to run into different problems. Further more, thanks to D's ban on if();, you can litterally never fail with this format. That is definitely one of D's better design choices. - Jonathan M Davis
Re: Getting started with D - Phobos documentation sucks
On 30-Sep-12 06:17, Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 17:20:48 UTC, Dmitry Olshansky wrote: Agreed. What's needed to make it a reality ? Need to integrate my helper program into the website build process. Program here: http://arsdnet.net/d-web-site/improveddoc.d libs needed https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff dom.d and characterencodings.d When I tried this earlier, I couldn't even get the basic website to build on my box from github. I think it needs github phobos too but meh, I moved on to something else and never got back to it. But if the website makefile built and ran that program across the html it generates, it should be set. I'll give it a whirl. The current auto generated _index_ at the top is intolerable. It won't surprise me if this alone has attributed to having say 20% less newcomers. Not to mention some cool functions that just got lost in this noise :) -- Dmitry Olshansky
Re: dynamic library building and loading
On 2012-09-30 08:41, Rob T wrote: There are plenty of cases where you have to use a dynamically loaded lib even if you know before hand what will be loaded. I think you understand this if I read your posts correctly. In my case I have a pre-existing C++ app that is designed to load user defined C++ plugins. I wanted to interface D to one of my own C++ plugins, but I apparently cannot do it reliably because of initialization issues with the GC and possibly some other obscure items. But now we're back at plugins. I think this part of the discussion is starting to run in circles and become quite pointless. I think most of us know that we need to support all types of libraries. Static and dynamic, both for link time and runtime. If I can figure out what needs to be done to resolve the problem in enough detail, then maybe I can hack the runtime source and roll out a solution. You can have a look at the work done by Martin Nowak: https://github.com/dawgfoto/druntime/commits/SharedRuntime He has a couple of other useful branches as well, for example: https://github.com/dawgfoto/druntime/commits/dmain2Refactoring On Mac OS X there's also the problem with TLS. There is no native support for TLS in Mac OS X prior to Lion (10.7). DMD has rolled its own implementation that needs to be adapted to support dynamic libraries. The GC always seems to pop up as a source of problems. For long term solution, the GC should be made 100% optional (in practice as opposed to in theory), the standard library ought to be made to work with or wothout a GC (or simply without), and the GC itself should be easily replaceable with alternate versions. I think this idea has already been discussed elsewhere, and is on the TODO list (I hope!). You can replace the GC at link time. Here's an example of a stubbed implemented of the GC: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub This is for Tango but the druntime is based on the Tango runtime so I would guess most of this would be the same. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 04:17, Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 17:20:48 UTC, Dmitry Olshansky wrote: Agreed. What's needed to make it a reality ? Need to integrate my helper program into the website build process. Is it just me that thinks that having a tool that fixes the generated documentation is ridiculous. The compiler should be modified to generate the documentation we want to have. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On Sunday, September 30, 2012 13:02:15 Jacob Carlborg wrote: On 2012-09-30 04:17, Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 17:20:48 UTC, Dmitry Olshansky wrote: Agreed. What's needed to make it a reality ? Need to integrate my helper program into the website build process. Is it just me that thinks that having a tool that fixes the generated documentation is ridiculous. The compiler should be modified to generate the documentation we want to have. That's what I've always thought. The main problem IMHO is how the links are generated, making it impossible to have links to symbols with the same name in the same module even if they're in different scopes (e.g. a free function and one in a class). And that's definitely not the sort of thing that an external tool should be fixing. - Jonathan M Davis
Re: Getting started with D - Phobos documentation sucks
While we're speaking about docs improvement, I believe there is one more thing that could use a fix - clickable identifiers. I don't know how much of an effort it would require, so consider it a wishlist, but for stuff like: static @property @safe TickDuration currAppTick(); TickDuration should be a clickable link leading to core.time.TickDuration class docs. Example: http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/Icon.html#paintIcon(java.awt.Component, java.awt.Graphics, int, int) notice how Component and Graphics are clickable so you can instantly jump to their relevant declarations. This feature along with the abovementioned improvements would probably make the documentation a useful and intuitive tool.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 11:22:02 UTC, Jonathan M Davis wrote: The main problem IMHO is how the links are generated, making it impossible to have links to symbols with the same name in the same module Yeah, I did a pull request to dmd to add a new macro to fix this, but I also included a change to the escaping rules and the powers that be weren't convinced of them (though they should be, ddoc is virtually unusable for documenting html and also for outputting other document formats without it or something like it). Anyway though I need to separate out my ddoc fixes into individual pull requests and I haven't gotten around to it yet. Maybe I'll try to fit it in today. After we allow a DDOC_PSYMBOL macro, we update std.ddoc to use it for the anchors and then we're set. Though, it still doesn't account for overloaded functions... but meh it's a *lot* better than we have now.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 10:08:17 UTC, Dmitry Olshansky wrote: I'll give it a whirl. cool. BTW search the code for the word HACK. There's one that rewrites css links to be absolute and one that adds some inline style. Those are there so I can test it from a different domain that doesn't have the whole website available. Probably safe to leave them there, but surely cleaner to comment that out before committing to the real thing.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 11:01:50 UTC, Jacob Carlborg wrote: Is it just me that thinks that having a tool that fixes the generated documentation is ridiculous. The compiler should be modified to generate the documentation we want to have. Eh, maybe. I just find doing fancier things inside the compiler to be a pain in the butt. Basically D C++. And it is harder to get code into dmd than it is to just do your own thing. But really what matters is that we get something that doesn't suck results wise. We could always change the ddoc implementation later.
Re: Rust and D
On 28-09-2012 19:42, Froglegs wrote: The Rust website says this: Generic typesyes, only simple, non-turing-complete substitution After seeing that I just assumed the language was worthless and ignored it.. is there something more to this? Let me just clarify to everyone that Rust *does* have macros, which is certainly better than nothing at all: https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 13:48:41 UTC, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 11:01:50 UTC, Jacob Carlborg wrote: Is it just me that thinks that having a tool that fixes the generated documentation is ridiculous. The compiler should be modified to generate the documentation we want to have. Eh, maybe. I just find doing fancier things inside the compiler to be a pain in the butt. Basically D C++. And it is harder to get code into dmd than it is to just do your own thing. But really what matters is that we get something that doesn't suck results wise. We could always change the ddoc implementation later. Which is why the doc generation utility should be a separate tool and not built directly into the compiler. I understand Walter's desire to have batteries included with D (doc generation, unit-testing, profiling, ...) but that does not mean they should be welded in. The DMD distribution could just as well provide a set of auxiliary _standalone_ utilities for that. DMD already has JSON output. Can't that be standardized and used with a separate ddoc utility written in D?
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 17:00, foobar wrote: Which is why the doc generation utility should be a separate tool and not built directly into the compiler. I understand Walter's desire to have batteries included with D (doc generation, unit-testing, profiling, ...) but that does not mean they should be welded in. The DMD distribution could just as well provide a set of auxiliary _standalone_ utilities for that. And we're back at the fact that we need a compiler library. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 15:49, Adam D. Ruppe wrote: Eh, maybe. I just find doing fancier things inside the compiler to be a pain in the butt. Basically D C++. And it is harder to get code into dmd than it is to just do your own thing. But really what matters is that we get something that doesn't suck results wise. We could always change the ddoc implementation later. That might be true but it's this kind of attitude that makes the source code a big mess and software suck. It's always we fix this later, well later is never going to happen. It's always patch on workaround on fix on patch, and so on. What's wrong with hey, lets fix this the right way for a change. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 15:31:30 UTC, Jacob Carlborg wrote: And we're back at the fact that we need a compiler library. Not necessarily... the ddoc comments are available in the compiler's json output (use -X and -D together in dmd). It doesn't do syntax highlighting and could offer a lot more info than it does now... but it does give enough to approximate your own ddoc. I'm using the json output for dpldocs.info version two: http://dpldocs.info/search/search?searchTerm=std.regex
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 15:36:50 UTC, Jacob Carlborg wrote: What's wrong with hey, lets fix this the right way for a change. If you want to write the code, feel free.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 15:41:46 UTC, Adam D. Ruppe wrote: If you want to write the code, feel free. I'm sorry, this probably came across as rude, but the answer for why not do it the right way is simply that the right way takes time and I don't feel like putting it in. Apparently not very many other people do either, since we've had the status quo for a long time now. A quick helper app can be slapped together in a fraction of the time of a more proper fix.
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 17:37, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 15:31:30 UTC, Jacob Carlborg wrote: And we're back at the fact that we need a compiler library. Not necessarily... the ddoc comments are available in the compiler's json output (use -X and -D together in dmd). It doesn't do syntax highlighting and could offer a lot more info than it does now... but it does give enough to approximate your own ddoc. I'm using the json output for dpldocs.info version two: http://dpldocs.info/search/search?searchTerm=std.regex If think the whole idea of the JSON output is a workaround for not having the compiler available as a library. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 17:53, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 15:41:46 UTC, Adam D. Ruppe wrote: If you want to write the code, feel free. I'm sorry, this probably came across as rude, but the answer for why not do it the right way is simply that the right way takes time and I don't feel like putting it in. Apparently not very many other people do either, since we've had the status quo for a long time now. A quick helper app can be slapped together in a fraction of the time of a more proper fix. Yeah I know. I would like to fix it but I think the DMD code base is quite horrible and just a big mess. I've tried several times to fix small bugs or tried to do some other modifications. But every time I fail because I have no idea what I'm doing and the DMD code base is far from easy to work. -- /Jacob Carlborg
Re: Idea: Introduce zero-terminated string specifier
If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way.
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 18:31:00 UTC, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. +1 We don't need to preserve C's design errors regarding strings and vectors. -- Paulo
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 17:27:43 UTC, Jacob Carlborg wrote: I would like to fix it but I think the DMD code base is quite horrible and just a big mess. What hurts me most in doing it is just that it is C++... I know my way around the compiler reasonably well. Not great but good enough to get by... but doing new code is just such a pain. Little things like no auto, forward declarations, weak sauce arrays and strings. Ugh, it just isn't D. And then dmd has its own rules that trip me up. Aren't supposed to use dynamic_cast, can't use tabs, just all kinds of style things that grind me.
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 18:31:00 UTC, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. That's what to!string already does.
Re: Idea: Introduce zero-terminated string specifier
On Saturday, 29 September 2012 at 02:07:38 UTC, Andrej Mitrovic wrote: I've noticed I'm having to do a lot of to!string calls when I want to call the versatile writef() function. So I was thinking, why not introduce a special zero-terminated string specifier which would both alleviate the need to call to!string and would probably save on needless memory allocation. If all we want to do is print something, why waste time duplicating a string? I just checked and std.conv.to always allocates a copy, even when constness doesn't require it. It should not reallocate when constness doesn't change, or is a safe conversion (e.g. immutable - const). A discussion on a related topic (formatting of C strings results in unexpected behavior) is here: http://d.puremagic.com/issues/show_bug.cgi?id=8384
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 18:58:11 UTC, Paulo Pinto wrote: +1 We don't need to preserve C's design errors regarding strings and vectors. The problem is that, unsurprisingly, most C APIs (not just libc, but also most C libraries and OS APIs) use zero-terminated strings. The philosophy of ignoring the existence of C strings throughout all of D makes working with such APIs needlessly verbose (and sometimes annoying, as D code will compile and produce unexpected results).
Re: Getting started with D - Phobos documentation sucks
On 9/30/12 11:53 AM, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 15:41:46 UTC, Adam D. Ruppe wrote: If you want to write the code, feel free. I'm sorry, this probably came across as rude, but the answer for why not do it the right way is simply that the right way takes time and I don't feel like putting it in. Apparently not very many other people do either, since we've had the status quo for a long time now. A quick helper app can be slapped together in a fraction of the time of a more proper fix. I don't think the comeback was rude because many great improvements to D came exactly this way - pull requests followed through by talented and interested contributors. On the other hand, if I were to criticize anything, Adam has a lot of great work brought to the proof-of-concept stage but not finalized. It would be great if we had some more finalized things. Andrei
Re: Idea: Introduce zero-terminated string specifier
On 9/30/12, deadalnix deadal...@gmail.com wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. What does that have to do with writef()? You can call to!string, but that's beside the point. The point was getting rid of this verbosity when using C APIs.
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 19:58:16 UTC, Vladimir Panteleev wrote: On Sunday, 30 September 2012 at 18:31:00 UTC, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. That's what to!string already does. I aggere you... a href=http://www.tercumesirketi.com/;Tercüme/a || a href=http://www.tercumesirketi.com/;Tercüme Büroları/a
Re: Dangling if
monarch_dodra wrote:
Personally, EVEN when I'm doing a 1 line if, I *still* wrap it
in a block. EG:
if(a == 0)
a = 1;
or
if(a == 0) a = 1;
Becomes:
if(a == 0)
{a = 1;}
or
if(a == 0) {a = 1;}
It might look iffy at first, but very quickly feels natural. It
may look like it requires (god forbid) useless typing, but
when that 1 liner becomes a 2 liner, it saves your life.
It has saved mine more than once actually!
I've done the dangling if bug often. One day I said no-more!.
I've addopted the above format, and it has not happened to me
since.
Further more, thanks to D's ban on if();, you can litterally
never fail with this format. I warmly recommend it to every one.
This is exactly why I think the '{}' brackets should be a
requirement and not the '()' brackets:
if a == b { doSomething(); }
if a == b
{ doSomething(); }
if a == b
{
doSomething();
doSomethingElse();
}
I know this will never happen in D, but it's how it should be,
IMO.
Re: dynamic library building and loading
On Sunday, 30 September 2012 at 10:57:24 UTC, Jacob Carlborg wrote: On 2012-09-30 08:41, Rob T wrote: I think most of us know that we need to support all types of libraries. Static and dynamic, both for link time and runtime. OK we're all in agreement on this point. You can have a look at the work done by Martin Nowak: https://github.com/dawgfoto/druntime/commits/SharedRuntime It seems that an attempt to make the runtime shared is well under way. Did anything get into the main dmd branch or has the effort been stalled or ...? I've only recently been learning what's going on with D and why it is what it is, so a breif history lesson may be needed once in a while. You can replace the GC at link time. Here's an example of a stubbed implemented of the GC: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub I will look at this too. Thanks for the pointers. --rt
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 20:24:17 UTC, Andrei Alexandrescu wrote: It would be great if we had some more finalized things. A problem I've been having ever since I started doing professional programming is that my focus time is a lot less than it used to be. I used to be able to sit down and spend a full month on one single thing, very few distractions as the monday return to work was /not/ inevitable... But recently that time has been limited to only three days, if I'm lucky, before something comes up and takes my attention away. And after I switch focus to something else, I often don't come back to the other thing for quite a long time. It is pushed down to the bottom of an ever growing list. So if it isn't finished in just a few days, it means I probably won't finish it for at least many months, and there's not a great deal I can do about that in the short term, at least not without spending 14 hours a day every day doing nothing but code, and blargh.
It seems pure ain't so pure after all
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all along);
readln();
}
Re: It seems pure ain't so pure after all
On 01-10-2012 07:40, Tommi wrote:
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all along);
readln();
}
This is a corner case.
__ctfe is there to allow special-cased CTFE code when absolutely
necessary. By necessity, this separates a function into two worlds:
compile time and run time.
As far as purity goes, pow2 *is* pure. It just does something different
depending on whether you run it at compile time or run time. I don't see
this as a problem in practice.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Very strange problem with comparing floating point numbers
The second one uses fstp twice, then fld twice. I don't know, maybe this could be a bug. You're right the lack of one fst/fld in the first case is a bug. x87 floating point registers are 80 bit. This: fstpdword [ebp-0CH] Converts the value in ST0 to single precision float and stores it to memory (and pops ST0). When it is later loaded with fld, it is not the same as before storing since some precision is lost (because the D code compares floats and not reals, this is the correct behavior). In the first example, this storing and loading only happens for the first function call. For the second call the value is returned in ST0 and stays in x87 registers until it is compared with fucompp so it is not truncated as the result of the first function call was. That's why the compared values are not equal.
Re: Struct assignment, possible DMD bug?
On Saturday, 29 September 2012 at 23:02:08 UTC, Timon Gehr wrote: On 09/30/2012 12:51 AM, Ali Çehreli wrote: Disclaimer: I assume that D's rules are the same as C and C++ here. C and C++ do not have struct literals and if I am not mistaken, constructor invocation is a sequence point. S(4, s.a, 6) is a struct literal here, not a constructor call (because structure S doesn't define any constructors). C has compound literals which is close to D struct literals. Besides, this does not make any sense, what is the relevant part of the standard? The standard states for assign expression (in $6.15.6) that the side effect of updating the stored value is sequenced after the value computations of the left and the rights operands. The evaluations of the operands are unsequenced. This means that a compiler can evaluate either first and the second operand, or the second and the first. In any case it can store value only after evaluations of both operands which means that value 4 cannot be assigned to s.a when S(4, s.a, 6) is evaluated. Actually, it is a bug.
Re: liittle question about reduce
On Saturday, 29 September 2012 at 23:07:30 UTC, Timon Gehr wrote: On 09/30/2012 01:04 AM, bioinfornatics wrote: hi, int[] list = [ 0, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]; why this do not works ? list.reduce!( (a,b) = a + b )( 0 ); // sum all elements but by this way that is ok: reduce!( (a,b) = a + b )( 0, list ); // sum all elements Because of the parameter order. 0.reduce!((a,b)=a+b)(list); // works Yeah... UFCS sometimes doesn't lend itself all that well to certain functions. This because UFCS was invented later in D's life cycle. It would have been better if reduce's range was defined as the first argument, rather than the last. This is especially true, because you don't have to specify the seed: reduce!( (a,b) = a + b )( list ); //OK reduce!( (a,b) = a + b )( 0, list ); //OK This reads very odly to me. I know this is not a case of default argument, but I don't like the change of usual behavior. I'd have expected this as valid syntax: reduce!( (a,b) = a + b )( list, 0 ); //Should be the valid syntax. Too late to change it now I guess! (unless we create a duplicate function called accumulate or something, but won't happen). Anywhoo, if you don't specify the seed (which you don't have to here), then you can just use: int[] list = [ 0, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]; list.reduce!( (a,b) = a + b )(); // sum all elements If you wanted the sum of the 10 first integrals, this also works: iota(0,10).reduce!a+b().writeln(); I really like the trailing writeln() :D UFCS is BY FAR one of the things I enjoy the most in D (not the most important feature, but the most enjoyable)
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic wrote: Dissasembly: __Dmain:; Function begin, communal enter 12, 0 ; _ C8, 000C, 00 call_D4test8getFloatFNdZf ; 0004 _ E8, (rel) ... Can I tell DMD to produce the assembly, or what did you do to get that?
Re: Very strange problem with comparing floating point numbers
On 09/30/2012 04:06 AM, Tommi wrote: On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic wrote: Dissasembly: __Dmain:; Function begin, communal enter 12, 0 ; _ C8, 000C, 00 call _D4test8getFloatFNdZf ; 0004 _ E8, (rel) ... Can I tell DMD to produce the assembly, or what did you do to get that? For a foo.d, after compiling the program and generating foo.o, the two options on Linux that I know of: 1) obj2asm that comes with dmd: $ obj2asm foo.o foo.asm 2) objdump that comes with at least my Linux distribution: $ objdump -d foo.o foo.asm Ali
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov wrote: // Tell me about this sutation, may be it is a bug? [SNIP] // all of this fails!!! assert (a.length == a.length); // This is really shocking assert (a.length == a3.length); [SNIP] This is just a fact of life regarding how floating point types work. Here is a well documented explanation. It pertains to C++, but applies. http://www.parashift.com/c++-faq/floating-point-arith2.html As a rule of thumb, NEVER use opEqual with floating point types aniways. You need to use some sort of comparison with leway for error, such as std.math.approxEqual.
Metaprogramming: check for ref
How can I: 1) check if function returns by ref 2) check if function parameters are ref ..outside of function body. Is parsing typeof(func).stringof only valid option?
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra wrote: On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov wrote: // Tell me about this sutation, may be it is a bug? [SNIP] // all of this fails!!! assert (a.length == a.length); // This is really shocking assert (a.length == a3.length); [SNIP] This is just a fact of life regarding how floating point types work. Here is a well documented explanation. It pertains to C++, but applies. http://www.parashift.com/c++-faq/floating-point-arith2.html As a rule of thumb, NEVER use opEqual with floating point types aniways. You need to use some sort of comparison with leway for error, such as std.math.approxEqual. Floating point types are trouble enough without these optimization failures. There are many unsolved problems, things like approxEqual are far from answering them. Whatever the justifications they come up with, a.len == a.len failure is IMO unacceptable, an opEqual like this must not fail. A suggestion: do what i do and have this in your config files. alias real evil;
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 18:31:17 UTC, so wrote: On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra wrote: On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov wrote: // Tell me about this sutation, may be it is a bug? [SNIP] // all of this fails!!! assert (a.length == a.length); // This is really shocking assert (a.length == a3.length); [SNIP] This is just a fact of life regarding how floating point types work. Here is a well documented explanation. It pertains to C++, but applies. http://www.parashift.com/c++-faq/floating-point-arith2.html As a rule of thumb, NEVER use opEqual with floating point types aniways. You need to use some sort of comparison with leway for error, such as std.math.approxEqual. Floating point types are trouble enough without these optimization failures. There are many unsolved problems, things like approxEqual are far from answering them. Whatever the justifications they come up with, a.len == a.len failure is IMO unacceptable, an opEqual like this must not fail. A suggestion: do what i do and have this in your config files. alias real evil; I don't really agree with that. floating point operations are just inexact, regardless of optimizations. That's how they work, period. Either you can work with inexact results, and you use them, or you can't, and don't. Banks don't use floating point types for exactly this reason. You have to know what you are getting into before you begin. The real troubles really only start when you start using floating point type, but you expect exact results.
Re: Very strange problem with comparing floating point numbers
On 9/30/12, Tommi tommitiss...@hotmail.com wrote: On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic wrote: Dissasembly: __Dmain:; Function begin, communal enter 12, 0 ; _ C8, 000C, 00 call_D4test8getFloatFNdZf ; 0004 _ E8, (rel) ... Can I tell DMD to produce the assembly, or what did you do to get that? I use objconv (can run on win32 only methinks) on an .obj file on win32 via a batch file: objconv -fnasm %~nx1 %~n1_disasm.asm %~n1_disasm.asm http://www.agner.org/optimize/objconv.zip
Re: Metaprogramming: check for ref
On 9/30/12, mist n...@none.none wrote: How can I: 1) check if function returns by ref 2) check if function parameters are ref ..outside of function body. Is parsing typeof(func).stringof only valid option? See ParameterStorageClassTuple in std.traits http://dlang.org/phobos/std_traits.html I'm not sure about the return type though. Maybe the template should be improved to add return type into account.
Re: Very strange problem with comparing floating point numbers
I don't really agree with that. floating point operations are just inexact, regardless of optimizations. That's how they work, period. It is true that they are inexact, but inexact and non-deterministic are not the same thing. Floating point operations are deterministic. Doing the same operation twice on the same machine with the same rounding mode and parameters will give you the same result. This should also be true when you do those operations using D, and using == on the two results should return true.
Re: Metaprogramming: check for ref
Thanks! Unfortunately, return type issue is more important in my case. I'll check if implementation from ParameterStorageClassTuple can be adapted for return types though. On Sunday, 30 September 2012 at 20:37:14 UTC, Andrej Mitrovic wrote: On 9/30/12, mist n...@none.none wrote: How can I: 1) check if function returns by ref 2) check if function parameters are ref ..outside of function body. Is parsing typeof(func).stringof only valid option? See ParameterStorageClassTuple in std.traits http://dlang.org/phobos/std_traits.html I'm not sure about the return type though. Maybe the template should be improved to add return type into account.
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 20:47:41 UTC, jerro wrote: I don't really agree with that. floating point operations are just inexact, regardless of optimizations. That's how they work, period. It is true that they are inexact, but inexact and non-deterministic are not the same thing. Floating point operations are deterministic. Technically (AFAIK), IEEE754 does need require reproducibility, ergo determinism. You can open an ER requesting the ability to specify the FP behavior want (like rounding behavior), the way vstudio does it.
Re: Metaprogramming: check for ref
On Sunday, 30 September 2012 at 20:51:54 UTC, mist wrote:
Thanks!
Unfortunately, return type issue is more important in my case.
I'll check if implementation from ParameterStorageClassTuple
can be adapted for return types though.
I think this should work:
template returnsRef(alias f)
{
enum bool returnsRef = is(typeof(
{
ParameterTypeTuple!f param;
auto ptr = f(param);
}));
}
Re: Metaprogramming: check for ref
On 9/30/12, jerro a...@a.com wrote:
I think this should work:
template returnsRef(alias f)
{
enum bool returnsRef = is(typeof(
{
ParameterTypeTuple!f param;
auto ptr = f(param);
}));
}
Yep. We should add this to Phobos imo.
Re: Very strange problem with comparing floating point numbers
Technically (AFAIK), IEEE754 does need require reproducibility, ergo determinism. It actually requires more than that: Algebraic operations covered by IEEE 754, namely + , - , * , / , square root and Binary - Decimal Conversion with rare exceptions, must be Correctly Rounded to the precision of the operationâs destination unless the programmer has specified a rounding other than the default. If it does not Overflow, a correctly rounded operationâs error cannot exceed half the gap between adjacent floating-point numbers astride the operationâs ideal ( unrounded ) result. Half-way cases are rounded to Nearest Even, which means that the neighbor with last digit 0 is chosen. I don't know if implementation conform exactly to IEEE 754, but I doubt there is any commonly used implementation that isn't deterministic.
WIC and Direct X
Anyone having experience in using WIC? How can I render, let's say a png file on disk, to the screen?
Re: Metaprogramming: check for ref
Thanks!
On Sunday, 30 September 2012 at 21:20:40 UTC, jerro wrote:
On Sunday, 30 September 2012 at 20:51:54 UTC, mist wrote:
Thanks!
Unfortunately, return type issue is more important in my case.
I'll check if implementation from ParameterStorageClassTuple
can be adapted for return types though.
I think this should work:
template returnsRef(alias f)
{
enum bool returnsRef = is(typeof(
{
ParameterTypeTuple!f param;
auto ptr = f(param);
}));
}
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 06:20:56 UTC, jerro wrote: The second one uses fstp twice, then fld twice. I don't know, maybe this could be a bug. You're right the lack of one fst/fld in the first case is a bug. x87 floating point registers are 80 bit. This: fstpdword [ebp-0CH] Converts the value in ST0 to single precision float and stores it to memory (and pops ST0). When it is later loaded with fld, it is not the same as before storing since some precision is lost (because the D code compares floats and not reals, this is the correct behavior). In the first example, this storing and loading only happens for the first function call. For the second call the value is returned in ST0 and stays in x87 registers until it is compared with fucompp so it is not truncated as the result of the first function call was. That's why the compared values are not equal. Can you or anyone report this bug? I don't know how to do this.
Troubleshooting Linker error (Symbol Undefined)
I'm trying to identify what change has resulted in getting the error: Error 42: Symbol Undefined _VarCmp@16 I was doing my not so routine updates for the Juno Class Libraries. This symbol is the VARIANT compare function provided by oleaut32.lib on Windows. It is a very nice function and has been used in Juno for some time. I tracked down the most recent working commit and compiler. The only signature changed made was const parameters (reverting this did not help). All other changes were needed in one form or another to compile in the newer dmd versions. Using the last known working compiler I attempted a reduced test to see if I can narrow it down as a compiler/linker bug/change. What I ended up with was a test case which exhibited the same behavior on this known working compiler (2.057/2.058). http://dpaste.dzfl.pl/233d037d This is not intended to run, I've changed the VARIANT definition to reduce dependencies. Hopefully it is the same size, but I did not make much effort. I've tried different export types, and using pointers instead of ref. This obviously won't link in Linux, but otherwise any suggestions?
Re: Very strange problem with comparing floating point numbers
On Monday, 1 October 2012 at 04:10:25 UTC, Ivan Agafonov wrote: On Sunday, 30 September 2012 at 06:20:56 UTC, jerro wrote: The second one uses fstp twice, then fld twice. I don't know, maybe this could be a bug. You're right the lack of one fst/fld in the first case is a bug. x87 floating point registers are 80 bit. This: fstpdword [ebp-0CH] Converts the value in ST0 to single precision float and stores it to memory (and pops ST0). When it is later loaded with fld, it is not the same as before storing since some precision is lost (because the D code compares floats and not reals, this is the correct behavior). In the first example, this storing and loading only happens for the first function call. For the second call the value is returned in ST0 and stays in x87 registers until it is compared with fucompp so it is not truncated as the result of the first function call was. That's why the compared values are not equal. Can you or anyone report this bug? I don't know how to do this. I'm not really sure that this is a bug anymore. Apparently c++ does this like this too (http://www.parashift.com/c++-faq/floating-point-arith2.html). I do think it would be more useful if the result of floating point comparison would be defined in a cases like this, but for floating point operation in general it makes sense to keep intermediate results in registers. So I don't know whether introducing a special case for this is worth it. If you care about this, you should probably make a thread on digitalmars.D, where more people will see it and comment on it.
Re: Windows MinGW and DMD
On Friday, 28 September 2012 at 18:10:36 UTC, David wrote: So I want to make the compilation of my little game work on Windows, I set up MinGW with Msys and ran the makefile, after a few fixes compilation worked, the problem is linking fails hard. I need a few external libraries in C like glfw3 and openssl, latter I installed with `mingw-get install msys-libopenssl` and I compiled glfw3 with the makfile and gcc. Now how can I link this all together? I have .a static libs (which are .lib libs, after renaming?) and .o files from gcc (I have a few C files) and .obj files from dmd. I hope you can help me out, because I have no idea how that kind of stuff works on Windows and I heared it's a real mess with OMF and COFF. Thanks. IIRC, MinGW uses the COFF format, which is the same format used by the Microsoft tools. The DMD toolchain currently is OMF only. You might be able to use coff2omf without any extra steps[1], but I'm not sure what version of COFF MinGW uses. I would really recommend using DerelictGLFW3 in this case and just build glfw3 as a shared lib. But I don't know of any similar binding for OpenSSL. [1] http://www.digitalmars.com/ctg/coff2omf.html
Re: Troubleshooting Linker error (Symbol Undefined)
On 10/1/12, Jesse Phillips jessekphillip...@gmail.com wrote: Error 42: Symbol Undefined _VarCmp@16 P.S. as soon as pointers are involved you don't need the full type info of such a parameter to debug linker errors, so you can cut down on code when reducing. For example if you had to match this C function but are getting linker errors: extern C void test(SomeType*); You can prototype this in D as: extern(C) void test(void*); You will still get the same linker error, but you won't have to insert the definition of SomeType.
[Issue 8739] New: DDoc outputs wrong parameter name in delegate parameter list
http://d.puremagic.com/issues/show_bug.cgi?id=8739
Summary: DDoc outputs wrong parameter name in delegate
parameter list
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jakobov...@gmail.com
--- Comment #0 from Jakob Ovrum jakobov...@gmail.com 2012-09-29 22:58:02 PDT
---
The following code:
void delegate(int a) dg;
/// Test - this works
void delegate(int b) dg2;
/// Test - this doesn't
void delegate(int c)[] dg3;
/// Another test - this doesn't either
void delegate(int d)* dg4;
void main() {}
Produces the following DDoc output for the symbol 'dg2':
void delegate(int b) dg2;
Test - this works
void delegate(int a)[] dg3;
Test - this doesn't
void delegate(int a)* dg4;
Another test - this doesn't either
Notice how the name of the first parameter is wrong when the delegate is part
of a composite type (dg3 and dg4). It does not happen when the variable is of
plain delegate type (as is the case of dg2). It seems to happen even in cases
when dg is in an imported module.
I don't know if this is a regression - if it is, it's not a recent one. I
tested on versions 2.060, 2.059, 2.058 and 2.057; they all exhibit the exact
same problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8739] DDoc outputs wrong parameter name in delegate parameter list
http://d.puremagic.com/issues/show_bug.cgi?id=8739 --- Comment #1 from Jakob Ovrum jakobov...@gmail.com 2012-09-29 22:59:39 PDT --- (In reply to comment #0) Produces the following DDoc output for the symbol 'dg2': Ignore this, I meant it produces the following output for the four symbols. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8128] unittest blocks should be allowed in interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=8128 --- Comment #4 from github-bugzi...@puremagic.com 2012-09-29 23:41:40 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d0115da0d9d328015855018c085b638c098f2665 Fix test for issue 8128. https://github.com/D-Programming-Language/dmd/commit/53527bbece7655ac8a00a1ad776395a19a55b161 Merge pull request #1154 from 9rnsr/fix8128test Fix test for issue 8128. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8356] Disabled postblit ignored on return statement
http://d.puremagic.com/issues/show_bug.cgi?id=8356 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8740] New: Temporary structs inside of array literals are destroyed and not copied in initialization of array
http://d.puremagic.com/issues/show_bug.cgi?id=8740
Summary: Temporary structs inside of array literals are
destroyed and not copied in initialization of array
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com
--- Comment #0 from Dmitry Olshansky dmitry.o...@gmail.com 2012-09-30
07:32:49 PDT ---
See subject. Which is wrong and is unlike e.g. array append.
Synposis:
version (msg) import std.stdio;
void main()
{
struct Int
{
int* payload;
this(int k)
{
payload = new int;
*payload = k;
version(msg) writeln(created: , k);
}
this(this)
{
int* np = new int;
*np = *payload;
payload = np;
version(msg) writeln(dupped: , *payload);
}
~this()
{
version(msg) writeln(destroyed: , *payload);
*payload = 0; //'destroy' it
}
@property int getPayload(){ return *payload; }
alias getPayload this;
}
//this destroys but not copies
Int[] arr = [Int(1), Int(4), Int(5)];
assert(arr[0] == 0); //passes while shouldn't (expected == 1)
assert(arr[1] == 0); //ditto with 4
assert(arr[2] == 0); //ditto with 5
//this one does create/copy/destroy
Int[] arr2;
arr2 ~= [Int(1), Int(4), Int(5)]; // this copies things over unlike first
case
assert(arr2[0] == 1);
assert(arr2[1] == 4);
assert(arr2[2] == 5);
}
Clearly Int[] arr = [...]; doesn't copy each element in turn, as is evident if
version=msg is specified:
created: 1
created: 4
created: 5
destroyed: 5
destroyed: 4
destroyed: 1
created: 1
created: 4
created: 5
dupped: 1
dupped: 4
dupped: 5
destroyed: 5
destroyed: 4
destroyed: 1
I argue that ideally the first and the 2nd version should just move temporaries
and never destroy them in the first place.
But minimally compiler should copy(dup) them in both cases if it can't figure
out how to move.
Compiler: DMD 2.061 as of git commit caf289137881ec290166afa72bc787bfbd6bd970
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4821] std.array.insert on string[]
http://d.puremagic.com/issues/show_bug.cgi?id=4821 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8741] New: [CTFE] Incorrect static array assign results in constructor
http://d.puremagic.com/issues/show_bug.cgi?id=8741
Summary: [CTFE] Incorrect static array assign results in
constructor
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: peter.alexander...@gmail.com
--- Comment #0 from Peter Alexander peter.alexander...@gmail.com 2012-09-30
16:42:16 PDT ---
struct Vec2
{
this(float x)
{
m[0] = x;
m[1] = x;
}
float[2] m;
static Vec2 zeroes = Vec2(0);
}
void main()
{
import std.stdio;
writeln(Vec2.zeroes);
}
Output is:
Vec2([0, nan])
http://dpaste.dzfl.pl/77058efc
Using two parameters for the constructor makes the bug go away:
http://dpaste.dzfl.pl/7ea20ba0
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
