Re: Visual D 0.3.37 released
On 03.11.2013 01:34, TheFlyingFiddle wrote: First of all i would like to thank you for making this wonderfull plugin. It was the existance of this pluggin that made me even consider learning D. This release however broke my setup. Whenever i tried to step into code while debugging it would crash visual studio. I fixed this by changing the debugger to Visual Studio (x86 mixed mode) i'm not sure if i used this debugger in previous versions (i may have) but i had never changed the used debugger until today. For more information i am using Visual Studio 2012 Ultimate. The application was in DMD 2064 beta 4 (x86 mode). I tried to reproduce (within VS2012 Shell) but could not produce any crashes. Do you have updates for VS 2012 installed? Did you switch back to the old engine by enabling native Edit and Continue (watches don't work with the new engine? Does it happen with a standard hello-world program, or does it have to be more involved? If you have a repro case please submit a bug report: http://d.puremagic.com/issues/enter_bug.cgi?product=D
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote:
Greetings,
many of you may notice lack of (up-to-date and working) DirectX
bindings, one may also seen my activity on d.learn sub forum.
so let me announce yet another bindings for DirectX which one
may fork right now from github!
https://github.com/evilrat666/directx-d
please be careful though, as it is only in alpha stage and
missing some stuff. current version is June 2010 SDK, but i
update it(to win8 sdk version) once i had win8 machine(i'm
still don't have a PC at home).
also, there is no d3d9 and d3d10 stuff as i consider it
outdated now, but i would appreciate pull requests for them
anyway :)
Hi,
Good work.
While porting header to D you can use:
alias int _D3D_SHADER_INPUT_FLAGS
enum : _D3D_SHADER_INPUT_FLAGS
{
D3D_SIF_USERPACKED= 1,
// others...
}
instead of:
enum _D3D_SHADER_INPUT_FLAGS
{
D3D_SIF_USERPACKED= 1,
// others...
}
That way using the enum won't force to use a namespace.
Re: DirectX bindings
On Sunday, 3 November 2013 at 08:42:52 UTC, ponce wrote:
Hi,
Good work.
While porting header to D you can use:
alias int _D3D_SHADER_INPUT_FLAGS
enum : _D3D_SHADER_INPUT_FLAGS
{
D3D_SIF_USERPACKED= 1,
// others...
}
instead of:
enum _D3D_SHADER_INPUT_FLAGS
{
D3D_SIF_USERPACKED= 1,
// others...
}
That way using the enum won't force to use a namespace.
thanks for notice, i'll need to try it first on something bigger
than simple example first.
most likely i had been doing this by default if i were work with
real C++ DirectX projects, unfortunately i only used OpenGL until
now :(
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On Sunday, 3 November 2013 at 05:08:40 UTC, Andrej Mitrovic wrote: (...) DChip[1] is a direct D2 port of the C library without no API changes. (...) Nothing I have the need for, but very cool nontheless. It would be interesting if you wrote about your experience on porting a C codebase this size.
Re: Programming in D book is about 95% translated
On 03/11/13 02:30, Kelet wrote: On Saturday, 2 November 2013 at 00:03:51 UTC, Ali Çehreli wrote: I have continued with the translation of the book. There are 36 of the 727 pages still to be translated. (However, I still need to write the UDA chapter.) In addition to many corrections and additions throughout the book, there are the following chapters translated: * Tuples * More Templates * More Functions * Mixins * More Ranges As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html No Kindle or Lulu versions yet. Ali Thanks for all your hard work, Ali. I believe having a set of up to date references, tutorials, and books are paramount to the further adoption and success of D as a programming language. +1 -- Jordi Sayol
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/3/13, simendsjo simend...@gmail.com wrote: Nothing I have the need for, but very cool nontheless. It would be interesting if you wrote about your experience on porting a C codebase this size. Nothing much new compared to the last time I ported C, which I wrote about here: http://forum.dlang.org/thread/mailman.1069.1308629671.14074.digitalmars-d-annou...@puremagic.com?page=2#post-mailman.1084.1308684922.14074.digitalmars-d-announce:40puremagic.com Of course I know much more now than I did back then. Maybe you meant like a blog post? I'll add it to my todo list. :)
Re: Programming in D book is about 95% translated
On 11/01/2013 08:03 PM, Ali Çehreli wrote: I have continued with the translation of the book. There are 36 of the 727 pages still to be translated. (However, I still need to write the UDA chapter.) In addition to many corrections and additions throughout the book, there are the following chapters translated: * Tuples * More Templates * More Functions * Mixins * More Ranges As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html No Kindle or Lulu versions yet. Ali Thanks a lot! I wouldn't have considered D language without this book.
Re: Visual D 0.3.37 released
On Sunday, 3 November 2013 at 08:07:41 UTC, Rainer Schuetze wrote: I tried to reproduce (within VS2012 Shell) but could not produce any crashes. Do you have updates for VS 2012 installed? Did you switch back to the old engine by enabling native Edit and Continue (watches don't work with the new engine? Does it happen with a standard hello-world program, or does it have to be more involved? If you have a repro case please submit a bug report: http://d.puremagic.com/issues/enter_bug.cgi?product=D I'm now unable to recreate the bugg. It vanished after an automatic windows update. So i'm guessing that the problem was in my visual studio setup rather then in the Visual D pluggin.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On 11/3/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: without no API changes. I meant without any API changes.
Re: Programming in D book is about 95% translated
On Saturday, 2 November 2013 at 22:45:13 UTC, Ali Çehreli wrote: I spent considerable amount of time on those names. Like you, I am not happy with Inverse. :) I wanted to say struct Negate and function negate(). But ! is the negation operator. I like opposite better but the Wikipedia article calls it additive inverse so inverse is still acceptable, I guess? :) http://en.wikipedia.org/wiki/Operators_in_C_and_C++ Well, if you don't want to change it now that the chapter has been released, don't worry -- it's not wrong per se, just somewhat unintuitive to my native English ear. I think that Negative and negative() (not Negation) would be fine. Bear in mind that ! is the _logical_ negation operator; without the qualifier, the word doesn't have the same meaning. The negative of x is just -x. The trouble with inverse (for me) is that its colloquial meaning is the multiplicative inverse, while in a strict mathematical sense it is too general -- you can have an inverse of _any_ function, so the term always needs to be qualified as the inverse of ... (whether of addition, multiplication, some other choice of function). But this may be my fussing too much. ;-)
Re: Programming in D book is about 95% translated
On Sunday, 3 November 2013 at 21:21:04 UTC, Joseph Rushton Wakeling wrote: On Saturday, 2 November 2013 at 22:45:13 UTC, Ali Çehreli wrote: I spent considerable amount of time on those names. Like you, I am not happy with Inverse. :) I'm not a native English speaker, but FWIW I would have chosen: http://en.wiktionary.org/wiki/numeric_complement
Re: Programming in D book is about 95% translated
On Sunday, 3 November 2013 at 22:42:37 UTC, Tove wrote: I'm not a native English speaker, but FWIW I would have chosen: http://en.wiktionary.org/wiki/numeric_complement I knew there was another term out there somewhere :-)
Re: D meetup in Minnesota
On Friday, 1 November 2013 at 20:02:10 UTC, Jack Pope wrote: We are now up to 17 in the group. I should schedule a meetup. Perhaps initially something short, say library linking tips. Then, we can banter about topics/speakers for later. Vladimir, what dates are you in town and will noon or evening work? Maybe you could present your DConf material? Hi, I'll be around Minneapolis (in Eagan) for all of November, with the possible exception of one week (TBD if/when) during which I might take a dip down to LA. The biggest limiting factor is that I can't drive here. So, if someone could pick me up, practically any time I'm here is fine for me. Otherwise we'll need to find a day that works for everyone. I could redo my DConf talk if you're interested, although I don't think I'd have much to add since May. Or, I could talk about memory management in D: garbage collection, structure and history of the D GC, related tools, best practices, and latest developments. Some of this was covered by the two DConf GC presentations. What will the format and duration of the meetup be? A presentation in an auditorium somewhere, or like a dinner/gathering?
Re: Programming in D book is about 95% translated
On 11/03/2013 03:19 PM, Joseph Rushton Wakeling wrote: On Sunday, 3 November 2013 at 22:42:37 UTC, Tove wrote: I'm not a native English speaker, but FWIW I would have chosen: http://en.wiktionary.org/wiki/numeric_complement I knew there was another term out there somewhere :-) Thanks all, I've settled with the pedantically incorrect Negative and negative() but I added a note saying that it is more accurate to say numeric complement: http://code.google.com/p/ddili/source/detail?r=649 Tove, I added you just as Tove in the acknowledgments section. Please e-mail me your last name at acehr...@yahoo.cm if you want me to add it. Thank you, Ali
Re: Programming in D book is about 95% translated
On Mon, Nov 4, 2013 at 6:41 AM, Ali Çehreli acehr...@yahoo.com wrote: Thanks all, I've settled with the pedantically incorrect Negative and negative() but I added a note saying that it is more accurate to say numeric complement: :) That is the name I was secretly voting for. Any chance of you providing a limited edition printed version? Perhaps with the authors name missing from the cover? :D -Rory
Re: D Programmer Jobs at Sociomantic Labs
On 11/2/13 10:29 PM, Era Scarecrow wrote: On Saturday, 2 November 2013 at 19:50:48 UTC, Andrei Alexandrescu wrote: As I made public recently, Facebook is investigating serious use of D, and significant precedents have been already created. There would be no better way to argue ramping up pursuit of D (including hosting of DConf 2014) than demonstrating that talented engineers are applying to Facebook because it's offering such an opportunity. I am pretty sure this is the case for other employers as well. Hmmm then I wonder if they would hire me. I'm not big on facebook (using the site), but I wouldn't mind a job and helping the community at the same time. Anyone interested send me a resume and I'll hook you in. Andrei
Re: D Programmer Jobs at Sociomantic Labs
On Sunday, 3 November 2013 at 05:29:45 UTC, Era Scarecrow wrote: On Saturday, 2 November 2013 at 19:50:48 UTC, Andrei Alexandrescu wrote: As I made public recently, Facebook is investigating serious use of D, and significant precedents have been already created. There would be no better way to argue ramping up pursuit of D (including hosting of DConf 2014) than demonstrating that talented engineers are applying to Facebook because it's offering such an opportunity. I am pretty sure this is the case for other employers as well. Hmmm then I wonder if they would hire me. I'm not big on facebook (using the site), but I wouldn't mind a job and helping the community at the same time. You won't know if you don't try ;)
Re: D parsing
On Sun, Nov 3, 2013 at 2:45 AM, Timothee Cour thelastmamm...@gmail.comwrote: 1) The main issue I see with pegged is PEG grammars don't support left recursion, so for example will fail on foo[1].bar(2).fun(). Unless there's a plan to accomodate those, I sense a dead end. One can eliminate left recursion but this has issues. Indeed. Eliminating left-recursion can be done, but it might disrupt the parse tree. There is no discarding the fact that PEG are intrinsically made to go with top-down recursive parsers. 2) There is some material on extending PEG to support those, eg Left Recursion in Parsing Expression Grammars, or code https://github.com/orlandohill/peg-left-recursion but I don't know how well they work in practice. I'll have a look, thanks. The idea seems similar to what I wanted to do, with a growing seed. 3) Finally, a parser should be as fast as possible; I'm not sure how well pegged performs compared to dmd frontend. Oh, for D it works (it's even the biggest grammar I know), but it's too slow to be of practical interest. But that just means the generated parser is not top-notch, which is reasonable: I'm not a parsing pro, just a guy doing this during his free time :) Other promising options are using lemon, a LALR(1) parser generator. My current plan is to write different engines, and letting either the user select them at compile-time, or to have the parser decide which one to use, depending on the grammar. I'm pretty sure the 'Type 3' parts of a grammar (regular expressions) could be bone by using std.regex, for example. I guess I'll have to write a CT-compatible LALR(1) engine... Growler: I'm using it for parsing C and Markup in two different projects. I've also just started working on an Octave (well ok, Matlab) M-file parser. It will probably never see the light of day but with Pegged is great fun to play with. Please don't lose interest in it !! OK guys, I'm hearing you. Thanks for the nice words growler! I tried to have Pegged simple to use, compared to other generator I know and I'm pleased to see it seems to work. If you have new grammars, you can send them to me, I'll put them in the examples. Yes. Probably the most significant D project at this time. Andrei That's nothing compared to vide.d! But I guess it indeed demonstrates what can be done with the generative capabilities of D. Thanks for the kind words.
Re: wrap/unwrap vs Go-style duck typing
On 31/10/13 05:35, Jonathan M Davis wrote: On Saturday, October 26, 2013 08:09:13 Andrei Alexandrescu wrote: Also, is it correct that Linux dynamic library support is really starting with this release? There was some before but not quite usable. It was there in 2.063, but we explicitly decided not to announce it due to how alpha it was. So, it makes some sense to say that it's new in this release, though I don't know how ready it is even now. How ready is it vis-à-vis other compilers? I remember reading that the dynamic library support was DMD-only.
Re: Undefined reference to _d_throw
On 11/02/2013 10:08 PM, Jacob Carlborg wrote: On 2013-11-02 21:12, Steve Teale wrote: CodeBlocks is supervising the compilation. I had added the libraries to its recipe in the wrong order: pthread m phobos2 The opposite way round it links OK, bu there's still something strange going on. When I try to run it, it fails with: ./compo: error while loading shared libraries: libphobos2.so.0.2: cannot open shared object file: No such file or directory This is true, there is no such file. In /usr/lib/i386-linux-gnu there's only libphobos2.so - a real file - which in my understanding should be a link to an actual shared library file. Is there a working shared Phobos library in 2.063, or is this a .deb file error. If I have /usr/lib/i386-linux-gnu/libphobos.a instead of phobos2, the program links and at least attempts to run. It may crash later, but that's my fault. This is not just a CodeBlocks thing. I made a simple makefile instead that links the libraries in the right order. That links, but also fails with the missing Phobos shared library error. Shared libraries are quite a new thing in D. I'm pretty sure it's supposed to link with the static library by default. Usually you can force linking with a static library by doing -L-l:/path/to/staticlibrary.a. Note the colon in the beginning of the path. Although I don't know if you can do that with Phobos. It seems like CodeBlocks is doing something strange here. You could try putting: :libphobos2.a in the list of libraries for CodeBlocks, as it doesn't require the full path. -- Mike Wey
Re: D Programmer Jobs at Sociomantic Labs
On Sunday, 3 November 2013 at 06:01:28 UTC, Andrei Alexandrescu wrote: Anyone interested send me a resume and I'll hook you in. Andrei I'm not of the calibre Facebook is looking for but i had to exclaim that is fantastically generous of you Andrei. I'm lucky in that i've been using D fulltime in my work since May and loving every minute of it. (Porting several database daemons from C to D, it's amazing how much less code there is in D!).
Re: D Programmer Jobs at Sociomantic Labs
On Sunday, 3 November 2013 at 11:47:13 UTC, Gary Willoughby wrote: On Sunday, 3 November 2013 at 06:01:28 UTC, Andrei Alexandrescu wrote: Anyone interested send me a resume and I'll hook you in. Andrei I'm not of the calibre Facebook is looking for but i had to exclaim that is fantastically generous of you Andrei. How do you know that? You might surprise yourself. I'm lucky in that i've been using D fulltime in my work since May and loving every minute of it. (Porting several database daemons from C to D, it's amazing how much less code there is in D!). Craig
Re: D Programmer Jobs at Sociomantic Labs
On Friday, 1 November 2013 at 17:38:01 UTC, Marenz wrote: Hey D Programmers, so, we at Sociomantic Labs are once again (or still) looking for D-Developers in Berlin. And lots of them. Currently still D1, but the process to change to D2 is initiated. You can read more about it here: https://www.sociomantic.com/jobs/d-software-developer/#.UnPl4Xh385Y You can contact me anytime if you have specific questions. You can find me in the IRC #d channel as Marenz, M4renz or Suprano or you just send me an email. cheers, --Mathias Want to add my 5 cents as someone who has joined the Sociomantic team only half an year ago. Initially my motivation was mostly C++ frustration outrage but I was pleasantly surprised by work environment here, which is very open-minded and task-focused, something you don't expect considering all the Germany cliches :) Perfection is achievable, of course, but it feels really nice to learn from some of active D contributors directly. And being D expert is not really necessary, as Don has mentioned in his DConf talk, converting guys from other languages is a routine :)
Re: std.allocator ready for some abuse
Hi, Andrei. I cannot compile the allocator. allocator.d(799): Error: undefined identifier returned At 499 line: returned alignedReallocate(b, newSize, alignment); Ur mistake?
Re: Undefined reference to _d_throw
On 02/11/13 21:12, Steve Teale wrote: The opposite way round it links OK, bu there's still something strange going on. When I try to run it, it fails with: ./compo: error while loading shared libraries: libphobos2.so.0.2: cannot open shared object file: No such file or directory This is true, there is no such file. In /usr/lib/i386-linux-gnu there's only libphobos2.so - a real file - which in my understanding should be a link to an actual shared library file. Is there a working shared Phobos library in 2.063, or is this a .deb file error. If I have /usr/lib/i386-linux-gnu/libphobos.a instead of phobos2, the program links and at least attempts to run. It may crash later, but that's my fault. This is not just a CodeBlocks thing. I made a simple makefile instead that links the libraries in the right order. That links, but also fails with the missing Phobos shared library error. Yes, this is a .deb error for 2.063.2, which will be fixed on next release. There are fixed deb packages for the current version at http://d-apt.sourceforge.net/ -- Jordi Sayol
Re: D Programmer Jobs at Sociomantic Labs
On Sunday, 3 November 2013 at 11:47:13 UTC, Gary Willoughby wrote: On Sunday, 3 November 2013 at 06:01:28 UTC, Andrei Alexandrescu wrote: Anyone interested send me a resume and I'll hook you in. Andrei I'm not of the calibre Facebook is looking for but i had to exclaim that is fantastically generous of you Andrei. I'm lucky in that i've been using D fulltime in my work since May and loving every minute of it. (Porting several database daemons from C to D, it's amazing how much less code there is in D!). I usually notice that people who lack doubt tends to do worse than the ones with doubt in their skills.
Re: std.allocator ready for some abuse
On 11/3/13 4:14 AM, Temtaime wrote: Hi, Andrei. I cannot compile the allocator. allocator.d(799): Error: undefined identifier returned At 499 line: returned alignedReallocate(b, newSize, alignment); Ur mistake? Yes, mine. I don't have access to Windows so I expect a bunch of typos in the Windows-specific code. Fixed and pushed this one. Thanks, Andrei
Initialization vs Assignment
Hi,
Most of the time my D code has been high-level, so I had never
considered the following issue. Imagine you have a struct A as a
member of a class/struct X (here a struct, to ensure the dtor is
called):
struct A
{
int v;
this(int v)
{
this.v = v*2;
}
~this()
{
writefln(~A(%d), v);
}
}
struct X
{
A a;
this(int v)
{
a = A(v);
writeln(-);
}
}
void main()
{
X x = X(42);
}
Output:
~A(0)
-
~A(84)
That is, because we don't have C++'s colon initialization syntax,
we are paying the cost of initializing (and then destroying) X.a
before we assign to it with a = A(v) in X's ctor. This seems to
be the case even with @disable A.this(), which here does not seem
to do anything (does not prevent the default/implicit
initialization of X.a, before it is assigned A(v) ).
If C++ distinguishes between initialization and assignment to
avoid this issue, is there a reason why D can avoid making the
distinction? That is a performance issue. How about correctness?
For instance:
struct A
{
void* mem;
@disable this();
this(int v)
{
mem = malloc(v);
}
~this()
{
free(mem);
}
}
Now we can't have an A as a member of X? (it would free a null
pointer)
How have you solved these cases? Do you change it to a PIMPL?
What if that's not desirable? What if you don't want to break
encapsulation / cleanliness too much? Etc. Is there a good
general solution for this issue?
Re: Initialization vs Assignment
It's fixed in 2.064 :-) http://dpaste.dzfl.pl/c292229f Application output: - ~A(84)
Re: Initialization vs Assignment
Now we can't have an A as a member of X? (it would free a null pointer) Actually, there is nothing wrong with calling free on a null pointer. From the C 89 standard: The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs.
Re: Initialization vs Assignment
2013/11/4 l...@luismarques.eu@puremagic.com \Luís.Marques
Hi,
Most of the time my D code has been high-level, so I had never considered
the following issue. Imagine you have a struct A as a member of a
class/struct X (here a struct, to ensure the dtor is called):
struct A
{
int v;
this(int v)
{
this.v = v*2;
}
~this()
{
writefln(~A(%d), v);
}
}
struct X
{
A a;
this(int v)
{
a = A(v);
writeln(-);
}
}
void main()
{
X x = X(42);
}
Output:
~A(0)
-
~A(84)
That is, because we don't have C++'s colon initialization syntax, we are
paying the cost of initializing (and then destroying) X.a before we assign
to it with a = A(v) in X's ctor. This seems to be the case even with
@disable A.this(), which here does not seem to do anything (does not
prevent the default/implicit initialization of X.a, before it is assigned
A(v) ).
If C++ distinguishes between initialization and assignment to avoid this
issue, is there a reason why D can avoid making the distinction? That is a
performance issue. How about correctness? For instance:
struct A
{
void* mem;
@disable this();
this(int v)
{
mem = malloc(v);
}
~this()
{
free(mem);
}
}
Now we can't have an A as a member of X? (it would free a null pointer)
How have you solved these cases? Do you change it to a PIMPL? What if
that's not desirable? What if you don't want to break encapsulation /
cleanliness too much? Etc. Is there a good general solution for this issue?
The issue is timely fixed in 2.064.
http://d.puremagic.com/issues/show_bug.cgi?id=9665
https://github.com/D-Programming-Language/dlang.org/pull/404
Therefore with 2.064, the first test case will output following:
-
~A(84)
Kenji Hara
Re: Initialization vs Assignment
On Sunday, 3 November 2013 at 16:01:44 UTC, jerro wrote: Now we can't have an A as a member of X? (it would free a null pointer) Actually, there is nothing wrong with calling free on a null pointer. From the C 89 standard: The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Oops, right, not the best example. But you get the motivating idea :-)
Re: Initialization vs Assignment
On Sunday, 3 November 2013 at 16:08:26 UTC, Kenji Hara wrote: The issue is timely fixed in 2.064. http://d.puremagic.com/issues/show_bug.cgi?id=9665 https://github.com/D-Programming-Language/dlang.org/pull/404 Therefore with 2.064, the first test case will output following: - ~A(84) Kenji Hara This is really weird. Not the first time that it happens to me. I swear that I'm not reading the pull requests and coming up with made up questions, hah :-) I guess it's a good sign of bug fixing speed!
Re: Initialization vs Assignment
On Sunday, 3 November 2013 at 15:38:30 UTC, Luís Marques wrote:
Hi,
Most of the time my D code has been high-level, so I had never
considered the following issue. Imagine you have a struct A as
a member of a class/struct X (here a struct, to ensure the dtor
is called):
struct A
{
int v;
this(int v)
{
this.v = v*2;
}
~this()
{
writefln(~A(%d), v);
}
}
struct X
{
A a;
this(int v)
{
a = A(v);
writeln(-);
}
}
void main()
{
X x = X(42);
}
Output:
~A(0)
-
~A(84)
That is, because we don't have C++'s colon initialization
syntax, we are paying the cost of initializing (and then
destroying) X.a before we assign to it with a = A(v) in X's
ctor. This seems to be the case even with @disable A.this(),
which here does not seem to do anything (does not prevent the
default/implicit initialization of X.a, before it is assigned
A(v) ).
If C++ distinguishes between initialization and assignment to
avoid this issue, is there a reason why D can avoid making the
distinction? That is a performance issue. How about
correctness? For instance:
struct A
{
void* mem;
@disable this();
this(int v)
{
mem = malloc(v);
}
~this()
{
free(mem);
}
}
Now we can't have an A as a member of X? (it would free a null
pointer)
How have you solved these cases? Do you change it to a PIMPL?
What if that's not desirable? What if you don't want to break
encapsulation / cleanliness too much? Etc. Is there a good
general solution for this issue?
for actual version of dmd, you can use this trick :)
struct A
{
int v;
void opAssign(int v) {
this.v = v;
}
static int opCall(int v) {
return v * 2;
}
~this()
{
writefln(~A(%d), v);
}
}
Re: D parsing
On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud philippe.sig...@gmail.comwrote: On Sun, Nov 3, 2013 at 2:45 AM, Timothee Cour thelastmamm...@gmail.comwrote: 1) The main issue I see with pegged is PEG grammars don't support left recursion, so for example will fail on foo[1].bar(2).fun(). Unless there's a plan to accomodate those, I sense a dead end. One can eliminate left recursion but this has issues. Indeed. Eliminating left-recursion can be done, but it might disrupt the parse tree. There is no discarding the fact that PEG are intrinsically made to go with top-down recursive parsers. 2) There is some material on extending PEG to support those, eg Left Recursion in Parsing Expression Grammars, or code https://github.com/orlandohill/peg-left-recursion but I don't know how well they work in practice. I'll have a look, thanks. The idea seems similar to what I wanted to do, with a growing seed. Great, please let us know how that works. 3) Finally, a parser should be as fast as possible; I'm not sure how well pegged performs compared to dmd frontend. Oh, for D it works (it's even the biggest grammar I know), but it's too slow to be of practical interest. But that just means the generated parser is not top-notch, which is reasonable: I'm not a parsing pro, just a guy doing this during his free time :) Other promising options are using lemon, a LALR(1) parser generator. My current plan is to write different engines, and letting either the user select them at compile-time, or to have the parser decide which one to use, depending on the grammar. I'm pretty sure the 'Type 3' parts of a grammar (regular expressions) could be bone by using std.regex, for example. even lexing can't be done with regex, eg nesting comments : /+ ... +/ Also, although it may seem cleaner at first to combine lexing and parsing in 1 big grammar (as done in pegged), it usually is faster do feed a (separate) lexer output into parser. I guess I'll have to write a CT-compatible LALR(1) engine... Growler: I'm using it for parsing C and Markup in two different projects. I've also just started working on an Octave (well ok, Matlab) M-file parser. It will probably never see the light of day but with Pegged is great fun to play with. Please don't lose interest in it !! OK guys, I'm hearing you. Thanks for the nice words growler! I tried to have Pegged simple to use, compared to other generator I know and I'm pleased to see it seems to work. If you have new grammars, you can send them to me, I'll put them in the examples. Yes. Probably the most significant D project at this time. Andrei That's nothing compared to vide.d! But I guess it indeed demonstrates what can be done with the generative capabilities of D. Thanks for the kind words.
Re: D parsing
On 11/03/2013 09:13 AM, Philippe Sigaud wrote: Oh, for D it works (it's even the biggest grammar I know), but it's too slow to be of practical interest. But that just means the generated parser is not top-notch, which is reasonable: I'm not a parsing pro, just a guy doing this during his free time :) Other promising options are using lemon, a LALR(1) parser generator. My current plan is to write different engines, and letting either the user select them at compile-time, or to have the parser decide which one to use, depending on the grammar. I'm pretty sure the 'Type 3' parts of a grammar (regular expressions) could be bone by using std.regex, for example. I guess I'll have to write a CT-compatible LALR(1) engine... D does not fit into LALR(1), you need glr. Another idea would be to make the engine a template argument, and than combine multiple parser!(engines). And even allow hand written stuff. This way you could use ll(1) for the ll(1) parts and the crazy hand written black magic for the hard parts.
What functions can be called on a shared struct that's implicitly castable to immutable?
Consider:
module foo;
struct S {
immutable(int)[] arr;
void fuzz() const pure {
}
}
void bar(S s) {
s.fuzz();
}
void main() {
shared S s;
bar(s); // a
s.fuzz(); // b
}
In this case, the line marked 'a' works perfectly - it compiles and does
what I'd expect it to.
However,the line marked 'b' does not compile - non-shared const method
foo.S.fuzz is not callable using a shared mutable object .
The reason for this is that fuzz takes the 'this' pointer by reference,
and so risks that another thread corrupt the internal state while it's
working.
Seeing as line 'a' works, it seems safe for line 'b' to make a copy
behind the scenes (structs in D are defined to have cheap copying, I
seem to recall) and call fuzz on that copy - the type system claims that
the call to fuzz cannot possibly change the state of the struct on which
it is called.
With the state of 'shared' as it is, I'm unsure if this is a change that
should be done - it seems perhaps better to wait for a true overhaul of
the feature.
Where I specifically found a need for this is in attempting to fix bug
11188[1]. While I have found a workaround, it's needed per function, and
I'm pretty sure it'll break some specific other cases.
[1]: http://d.puremagic.com/issues/show_bug.cgi?id=11188
--
Simen
Re: D parsing
On Sun, Nov 3, 2013 at 12:46 PM, Robert Schadek realbur...@gmx.de wrote: On 11/03/2013 09:13 AM, Philippe Sigaud wrote: Oh, for D it works (it's even the biggest grammar I know), but it's too slow to be of practical interest. But that just means the generated parser is not top-notch, which is reasonable: I'm not a parsing pro, just a guy doing this during his free time :) Other promising options are using lemon, a LALR(1) parser generator. My current plan is to write different engines, and letting either the user select them at compile-time, or to have the parser decide which one to use, depending on the grammar. I'm pretty sure the 'Type 3' parts of a grammar (regular expressions) could be bone by using std.regex, for example. I guess I'll have to write a CT-compatible LALR(1) engine... D does not fit into LALR(1), you need glr. how about dparser (nothing to do with D btw): http://dparser.sourceforge.net/ the grammar for C looks quite compact and clean: http://dparser.sourceforge.net/d/tests/ansic.test.g Another idea would be to make the engine a template argument, and than combine multiple parser!(engines). And even allow hand written stuff. This way you could use ll(1) for the ll(1) parts and the crazy hand written black magic for the hard parts. Sure, but that'd be a 2nd priority after having at least one (partially) automatically generated parser for D.
Re: D parsing
On Sat, Nov 2, 2013 at 1:19 AM, Philippe Sigaud philippe.sig...@gmail.comwrote: Note that Pegged has no problem with the official C grammar or the officiel XML specification... how do you handle left recursion in C ? eg: a[0][1] etc?
Re: D parsing
On Mon, Nov 4, 2013 at 1:58 AM, Timothee Cour thelastmamm...@gmail.comwrote: On Sat, Nov 2, 2013 at 1:19 AM, Philippe Sigaud philippe.sig...@gmail.com wrote: Note that Pegged has no problem with the official C grammar or the officiel XML specification... how do you handle left recursion in C ? eg: a[0][1] etc? I don't remember. Maybe the grammar I use has no left-recursion? I don't remember whether I sued the official C grammar or one created for PEGs by someone else. I know I tested it on many different programs, with no problem.
Re: D parsing
On Sun, Nov 3, 2013 at 7:08 PM, Timothee Cour thelastmamm...@gmail.comwrote: On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud philippe.sig...@gmail.com wrote: My current plan is to write different engines, and letting either the user select them at compile-time, or to have the parser decide which one to use, depending on the grammar. I'm pretty sure the 'Type 3' parts of a grammar (regular expressions) could be bone by using std.regex, for example. even lexing can't be done with regex, eg nesting comments : /+ ... +/ Also, although it may seem cleaner at first to combine lexing and parsing in 1 big grammar (as done in pegged), it usually is faster do feed a (separate) lexer output into parser. Lexing, yes. I was imprecise: even in a context-free grammar, some rules are regular and could use std.regex (the ct part) as the underlying engine, just for that rule.
Re: D parsing
I *used* the grammar, obviously. Suing could be an option to disallow left-recursion, but let's explore other ways for now. On Mon, Nov 4, 2013 at 6:46 AM, Philippe Sigaud philippe.sig...@gmail.comwrote: On Mon, Nov 4, 2013 at 1:58 AM, Timothee Cour thelastmamm...@gmail.comwrote: On Sat, Nov 2, 2013 at 1:19 AM, Philippe Sigaud philippe.sig...@gmail.com wrote: Note that Pegged has no problem with the official C grammar or the officiel XML specification... how do you handle left recursion in C ? eg: a[0][1] etc? I don't remember. Maybe the grammar I use has no left-recursion? I don't remember whether I sued the official C grammar or one created for PEGs by someone else. I know I tested it on many different programs, with no problem.
Re: D parsing
On Mon, Nov 4, 2013 at 1:55 AM, Timothee Cour thelastmamm...@gmail.comwrote: I guess I'll have to write a CT-compatible LALR(1) engine... D does not fit into LALR(1), you need glr. Well, too bad. GLR is also on my plate, but I fear its cubic behavior (IIRC, it degrades gracefully, though). Do you know what part of the D grammar makes it non-LALR(1)?
Re: What functions can be called on a shared struct that's implicitly castable to immutable?
On Sunday, 3 November 2013 at 21:55:22 UTC, Simen Kjærås wrote:
Consider:
module foo;
struct S {
immutable(int)[] arr;
void fuzz() const pure {
}
}
void bar(S s) {
s.fuzz();
}
void main() {
shared S s;
bar(s); // a
s.fuzz(); // b
}
In this case, the line marked 'a' works perfectly - it compiles
and does what I'd expect it to.
However,the line marked 'b' does not compile - non-shared
const method foo.S.fuzz is not callable using a shared mutable
object .
It is because a imply a pass b value, when b a pass by reference.
State of OpenGL bindings
Hi, all. If I wanted to create an OpenGL project in D, what would be supported by current bindings? Are the bindings out-of-date compared to the C library versions or are they the same? Thank you. -- Atenciosamente / Sincerely, Guilherme Prá Vieira http://www.linkedin.com/in/n2liquid http://www.linkedin.com/in/n2liquid http://www.linkedin.com/in/n2liquid
Copy elision by spec
I was quite surprised to see that the following program compiles
just fine with DMD:
struct S
{
@disable this(this);
int n;
}
S createS(int i)
{
S s;
s.n = i;
return s;
}
void main(string[] args)
{
auto foo = createS(1);
foo = createS(2);
}
I already knew that the compiler was allowed to elide copies on
return from functions, but I thought this was an optimisation,
and not part of the language proper. I would have expected the
compiler to complain that createS() can't return an S since S's
postblit constructor is disabled.
My question is therefore, is this by design? Can I rely on this
to work in the future, and on all compilers? If this is the
case, it really should be added to the spec. (Or maybe it's
there already, but I couldn't find it.)
Lars
Re: Copy elision by spec
On Monday, 4 November 2013 at 07:02:26 UTC, Lars T. Kyllingstad wrote: My question is therefore, is this by design? Can I rely on this to work in the future, and on all compilers? If this is the case, it really should be added to the spec. (Or maybe it's there already, but I couldn't find it.) Lars Funny you should ask: http://d.puremagic.com/issues/show_bug.cgi?id=11287 According to the conversation, NRVO is supposed to be part of the spec, and you should expect it to work.
Re: State of OpenGL bindings
On 2013-11-04 07:31, Guilherme Vieira wrote: Hi, all. If I wanted to create an OpenGL project in D, what would be supported by current bindings? Are the bindings out-of-date compared to the C library versions or are they the same? I would recommend using Derelict. It contains bindings for 1.1 to 4.3, as far as I can see. Derelict is usually in a very good shape. https://github.com/DerelictOrg/DerelictGL3 Use via dub: http://code.dlang.org/packages/derelict-gl3 -- /Jacob Carlborg
Re: State of OpenGL bindings
On 11/4/2013 4:30 PM, Jacob Carlborg wrote: On 2013-11-04 07:31, Guilherme Vieira wrote: Hi, all. If I wanted to create an OpenGL project in D, what would be supported by current bindings? Are the bindings out-of-date compared to the C library versions or are they the same? I would recommend using Derelict. It contains bindings for 1.1 to 4.3, as far as I can see. Derelict is usually in a very good shape. https://github.com/DerelictOrg/DerelictGL3 Use via dub: http://code.dlang.org/packages/derelict-gl3 Re being out-of-date: DerelictGL3 has support for up to version 4.3. Support for 4.4 is on the TODO list.
Re: Associative Array: reasonable limits?
03-Nov-2013 02:37, Charles Hixson пишет: I'm contemplating an associative array that will eventually grow to be an estimated 64KB in size, assuming it's about half full. It would then be holding around 90,000 entries. Is this reasonable, or should I go with a sorted array, and do binary searches? I estimate that binary searches would average around 15 accesses/hit, but that's still a lot faster than disk access. The array would be nearly full, so there would be less wasted space, but, of course, insertions would become quite expensive. (Deletions aren't expected.) In either case the keys would be fixed length character arrays, and the values would also be simple structs without reference types (so the garbage collector could pretty much ignore things). 90k elements is a small AA. It would work just fine with any sane hash function (e.g. the built-in one). At around 10M+ elements it may be worth to consider space saving techniques. That said on x64 100M+ is perfectly OK, on 32bit I'd advise against it but only because of GC. FWIW I'm expecting this array to be around the entire time the program is running, but it would probably be rolled out most of the time, as frequently accessed items would be pulled into a much smaller structure, and if I go with the array rather than the hash table I may only do updates as a batch. (Since it's linear with the size of the array, but essentially ignores the number of items being added.) My temptation is to go with the hash table...but I'm not sure of the underlying mechanics. Think of it as a sparse array that has holes and takes around ~2-4 times the size of normal array. It's not only because of holes but because a slot is a bit bigger. In return lookups/inserts/deletions are cheap O(1) with high probability. -- Dmitry Olshansky
Type-specific overloads in Phobos
Hello all, There are various generic functions in Phobos that can benefit from type-specific overloads. For example, in std.math and std.numeric, functions that deal with integers may benefit from having specialized implementations to work with BigInt. Question: what's the appropriate location for these overloads? In the same module as their type, or in the same module as the function they're overloading? What are the implications for correct inferring of what function to use, or useful aliases (e.g. alias abs = std.math.abs)? Thanks best wishes, -- Joe
Re: Type-specific overloads in Phobos
03-Nov-2013 13:07, Joseph Rushton Wakeling пишет: Hello all, There are various generic functions in Phobos that can benefit from type-specific overloads. For example, in std.math and std.numeric, functions that deal with integers may benefit from having specialized implementations to work with BigInt. Question: what's the appropriate location for these overloads? In the same module as their type, Yes, it's the only path that scales. or in the same module as the function they're overloading? Hardly scales - by the end of day they shouldn't be all imported by std.math. Plus it's BigInt business to do some dirty internal work to speed up common algorithms. What are the implications for correct inferring of what function to use, or useful aliases (e.g. alias abs = std.math.abs)? Technically as long as the types are different there is no hijacking going on (w/o aliases). The moment you add an alias it's as if you declare it in your module, so it would fail to match on BigInt because of anti-hijacking. //this should work though: alias abs = std.math.abs; alias abs = std.bigint.abs; Thanks best wishes, -- Joe -- Dmitry Olshansky
Re: Type-specific overloads in Phobos
On 03/11/13 10:18, Dmitry Olshansky wrote: //this should work though: alias abs = std.math.abs; alias abs = std.bigint.abs; Yea, which makes sense -- any code that needs both should _know_ it needs both. Actually, abs itself is not really a problem here as std.math.abs should work for just about any integer-like type, the real places where this will matter are stuff like greatest common divisor or least common multiple ... I had some concern about generic numerical code that doesn't know the type it's operating on, but on the other hand such code probably shouldn't be calling a specific implementation of (e.g.) abs, gdc or whatever.
Re: Figuring out the returntype opDipatch
On 2013-11-03 03:15, TheFlyingFiddle wrote:
In the IReflectionable interface:
interface IReflectionable
{
final P funcPtr(P)(string fun) if (is(P == delegate))
{
//Using mangeling for overloads and type safety
auto ptr = delPtr_impl(mangle!P(fun));
P del;
del.ptr = cast(typeof(del.ptr))ptr[0];
del.funcptr = cast(typeof(del.funcptr))ptr[1];
return del;
}
final P funcPtr(P)(string fun) if (is(P == function))
{
//Using mangeling for overloads and type safety
auto ptr = funcPtr_impl(mangle!(P)(fun));
return cast(P)ptr;
}
final ?? opDispatch(string name, Params...)(Params params)
{
alias ?? delegate(Params) del_type;
auto del = funcPtr!(del_type)(name);
static if(?? == void)
del(params);
else
return del(params);
}
protected Tuple!(void*, void*) delPtr_impl(string s);
protected void* funcPtr_impl(string s);
}
What i'm interested in is determining what type ?? should be. Variant
works but if possible i would like to avoid it. This would require me to
know about the code at the invokation site. (So i'm guessing it might
not be possible)
I have the same problem as well. I haven't figured out the best way to
solve this yet.
--
/Jacob Carlborg
Re: Linker error regarding importing and unit tests. Is this a bug?
On Friday, 1 November 2013 at 16:24:09 UTC, Gary Willoughby wrote:
On Friday, 1 November 2013 at 15:32:54 UTC, Daniel Davidson
wrote:
An alternative is to move the import statements in test1.d out
of the unittest block, which becomes a function, to file
scope. Then if you have multiple unittests in test1.d all are
covered and the symbols are available.
...
version(unittest) {
import methods;
}
unittest
{
import std.stdio;
writeln(test1 unit test);
S s;
assert(s.x.nothing());
}
Thanks
Dan
Ah right, if the unit tests are transformed into a function
then is this a problem with the scoped import rules? It seems
really odd, as the compiler seems to strip out the imports
within the unit test block when that module is imported into
another. This doesn't seem to affect the standard library only
user modules.
Any one else got any input to this?
Re: [challenge] Lazy flatten/avoiding type forward reference with map
On 10/31/2013 10:19 PM, Ali Çehreli wrote:
...
Y Combinator? (No, I have not solved it yet. :) )
http://rosettacode.org/wiki/Y_combinator#D
Ali
Oh my god, my eyes!
auto y(S,T...)(S delegate(T) delegate(S delegate(T)) f){
struct F{ S delegate(T) delegate(F) f; alias f this; }
return (x=x(x))(F(x=f((T v)=x(x)(v;
}
Re: How to iterate using foreach on a class?
Am Fri, 01 Nov 2013 08:50:19 -0700 schrieb Ali Çehreli acehr...@yahoo.com: On 11/01/2013 08:32 AM, Dmitry Olshansky wrote: In short we have 2 ways: 1) Ranges 2) opApply As another shameless plug, those foreach methods are included in this chapter: http://ddili.org/ders/d.en/foreach_opapply.html Ali I just saw a small mistake on that page: .popFront() must move to the element that is one before the end (skips the back element) popFront should be popBack.
Current size of GC memory
Is there a way to find out how much memory the GC used currently?
Re: How to iterate using foreach on a class?
On Friday, 1 November 2013 at 12:37:20 UTC, simendsjo wrote:
On Friday, 1 November 2013 at 11:41:52 UTC, Jonathan M Davis
wrote:
On Friday, November 01, 2013 12:30:10 Gary Willoughby wrote:
I have a class which contains an array as a core collection of
data. I want to pass an instance of this class to a foreach
loop
and iterate through the enclosed array. How do i do this? I've
asked this before and got an answer but i can't find anything
now.
In general, if you want to make something work with foreach,
you either make
it a range, or you give it an opSlice which returns a range
(another
alternative would be define opApply, but in general, code
should be using the
range primitives rather than opApply). Given that you're
looking to iterate an
array, and you presumably don't want the array to be consumed
when iterating,
the simplest would be to simply declare an opSlice on the
class returns the
array. e.g.
class C
{
int[] foo;
auto opSlice() { return foo; }
}
Then when you use the class in a foreach loop, it'll be
sliced, and the return
value of opSlice (the array in this case) will then be
iterated over.
- Jonathan M Davis
So we basically have 4 ways..?
1) popFront + front
2) opSlice
3) alias this
4) opApply
How about having a nested struct implementing a range interface +
a method (@property) returning it + alias this on the property?
http://dpaste.dzfl.pl/230061d2
Re: Current size of GC memory
On Sunday, 3 November 2013 at 13:05:08 UTC, Namespace wrote: Is there a way to find out how much memory the GC used currently? Does not seem to be possible. Would have been nice.
Re: parse int error
On Wednesday, 30 October 2013 at 18:19:13 UTC, Ali Çehreli wrote:
On 10/29/2013 06:02 PM, Peter Eisenhower wrote:
I am confused as to why I cannot pass the return of the tag
attribute
directly into the parse int.
// This works
string s = xml.tag.attr[key];
int key = parse!int(s);
// Compile error on these
int key = parse!int(xml.tag.attr[key]);
int key = parse!int(cast(string) cml.tag.attr[key]);
A trivial wrapper makes it convenient:
import std.xml;
import std.conv;
T getAttr(T)(DocumentParser xml, string attrName)
{
string s = xml.tag.attr[attrName];
T attr = parse!T(s);
return attr;
}
unittest
{
auto xml = new DocumentParser(`test key=1/test`);
auto key = xml.getAttr!int(key);
assert(key == 1);
}
void main()
{}
Ali
Thanks
Public template types
Sometimes I have to make a template type argument visible inside
the instantiated type:
struct Foo(T_) {
alias T = T_;
}
void main() {
Foo!int f;
static assert(is(f.T == int));
}
A little of syntax sugar could do the same, avoiding the need for
a new name as T_:
struct Foo(public T) {}
Do you like?
Bye,
bearophile
Re: [OT] Generating ddili.org with ddoc
On 11/02/2013 01:34 AM, Philippe Sigaud wrote: Any limitation you hit with Ddoc? One annoyance is with parentheses in code sections. Ddoc allows using ddoc macros even in code section and I like it because I can highlight parts of code by a macro. However, that means that unbalanced parentheses in code sections cause trouble. For example (if I remember correctly), even a string like 1) blah in a code section causes formatting issues. So, one has to use the equivalents of the following macros: OPEN_PAREN = #40; CLOSE_PAREN = #41; COMMA = #44; DOLLAR = #36; if you could find the time to translate the turkish page, that would be great! http://code.google.com/p/ddili/source/browse/trunk/README Ali
Re: [OT] Generating ddili.org with ddoc
On Mon, Nov 4, 2013 at 6:05 AM, Ali Çehreli acehr...@yahoo.com wrote: On 11/02/2013 01:34 AM, Philippe Sigaud wrote: Any limitation you hit with Ddoc? One annoyance is with parentheses in code sections. Ddoc allows using ddoc macros even in code section and I like it because I can highlight parts of code by a macro. Yeah, I saw that in your code. I didn't know that could be done. However, that means that unbalanced parentheses in code sections cause trouble. For example (if I remember correctly), even a string like 1) blah in a code section causes formatting issues. So, one has to use the equivalents of the following macros: OPEN_PAREN = #40; CLOSE_PAREN = #41; COMMA = #44; DOLLAR = #36; I saw these and wondered what they were for. Why comma and dollar? if you could find the time to translate the turkish page, that would be great! http://code.google.com/p/ddili/source/browse/trunk/README Ah, thanks you, Ali. I now realize I got only a small part of it.
Re: Current size of GC memory
On 03.11.2013 19:53, Namespace wrote: On Sunday, 3 November 2013 at 13:05:08 UTC, Namespace wrote: Is there a way to find out how much memory the GC used currently? Does not seem to be possible. Would have been nice. There is an unofficial function gc_stats here: https://github.com/D-Programming-Language/druntime/blob/master/src/gc/proxy.d#L276
Re: [OT] Generating ddili.org with ddoc
On 11/03/2013 09:44 PM, Philippe Sigaud wrote: COMMA = #44; DOLLAR = #36; I saw these and wondered what they were for. Why comma and dollar? Actual comma inside a macro is taken as argument separator. From src/ders/d.en/operator_overloading.d: $(ROW3 slice to some elements, opSlice, collection[i$(VIRGUL) j]) (Note: VIRGUL is COMMA) If I used actual comma, j] would be taken as an unused extra parameter to ROW3. Dollar sign appears in dlang forum links. The only occurrence so far has been inside the Turkish translation of David Nadlinger's purity article, src/makale/saflik.d: $(LINK2 http://forum.dlang.org/thread/i7bp8o$(DOLAR)6po$(DOLAR)1...@digitalmars.com, son değişikleri de getirmiş olan tartışma) Otherwise, the $ character would be parsed as the beginning of a macro. (Perhaps there is some sort of escaping but I just used the DOLAR macro. :-/) Ali
[Issue 11423] Error: new can only create structs, dynamic arrays or class objects, not _error_'s
http://d.puremagic.com/issues/show_bug.cgi?id=11423 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||diagnostic, pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-11-03 00:08:59 PDT --- https://github.com/D-Programming-Language/dmd/pull/2710 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11424] Regression (2.064 git-head) typedef on structs isn't caught
http://d.puremagic.com/issues/show_bug.cgi?id=11424 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||accepts-invalid, pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-11-03 00:27:46 PDT --- The regression has been caused by fixing bug 11145. https://github.com/D-Programming-Language/dmd/pull/2711 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11423] Error: new can only create structs, dynamic arrays or class objects, not _error_'s
http://d.puremagic.com/issues/show_bug.cgi?id=11423 --- Comment #2 from github-bugzi...@puremagic.com 2013-11-03 00:48:31 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8121cf8ed5cb41d6905a0ac3169c3f397e58dab5 fix Issue 11423 - Error: new can only create structs, dynamic arrays or class objects, not _error_'s https://github.com/D-Programming-Language/dmd/commit/dc6628429ed8af254f80c86845d9237ebf5daf00 Merge pull request #2710 from 9rnsr/fix11423 Issue 11423 - Error: new can only create structs, dynamic arrays or class objects, not _error_'s -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11423] Error: new can only create structs, dynamic arrays or class objects, not _error_'s
http://d.puremagic.com/issues/show_bug.cgi?id=11423 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11426] New: Reinterpret element-wise array initializing should be rejeted
http://d.puremagic.com/issues/show_bug.cgi?id=11426
Summary: Reinterpret element-wise array initializing should be
rejeted
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2013-11-03 01:08:08 PST ---
This is a regression issue from 2.061.
void main()
{
uint[] udarr;
uint[1] usarr;
int[1] arr1; arr1 = udarr; // Error, OK
int[1] arr2; arr2 = usarr; // Error, OK
int[1] arr3 = udarr;// accepted, BAD!
int[1] arr4 = usarr;// accepted, BAD!
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
--- Comment #16 from Kenji Hara k.hara...@gmail.com 2013-11-03 01:18:36 PST
---
(In reply to comment #15)
(In reply to comment #10)
uint[] udarr;
uint[1] usarr;
int[1] arr1 = udarr; //OK
int[1] arr2 = usarr; //OK
Mmm...I think this is a bug. Because following code is also accepted in
compilation, and will cause runtime exception!
void main()
{
int[4] sa;
ulong[4] sa2 = sa;
}
I opened bug 11426. It is a regression issue from 2.061.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11426] Reinterpret element-wise array initializing should be rejeted
http://d.puremagic.com/issues/show_bug.cgi?id=11426 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-11-03 01:15:46 PST --- https://github.com/D-Programming-Language/dmd/pull/2712 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11427] New: anonymous unions break structs in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11427
Summary: anonymous unions break structs in @safe code
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2013-11-03 01:52:10
PST ---
Compile this code
///
struct S
{
union
{
ubyte a;
int x;
}
void[] arr;
}
int foo() @safe
{
S s1 = S();
S s2;
return 0;
}
with dmd -c test.d fails with
test.d(14): Error: variable test.foo.s2 unions containing pointers are not
allowed in @safe functions
Please note that the first variable s1 is ok!
This is also triggered in std.format with this code:
import std.format;
import std.array;
void foo()
{
FormatSpec!char spec = FormatSpec!char();
auto s = appender!string;
formattedWrite(s, %s, hello);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11377] if add -inline option. dmd source file in assertion failed.
http://d.puremagic.com/issues/show_bug.cgi?id=11377 --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-11-03 01:19:29 PST --- On Windows -m32, the issue reproduces with 2.063, but it does not occur with 2.064beta4. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11427] anonymous unions break structs in @safe code
http://d.puremagic.com/issues/show_bug.cgi?id=11427 --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2013-11-03 01:32:10 PST --- Hmmm, something wrong with bugzilla? My comment replaced the description, and the initial description is now moved into the first comment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10750] Strict aliasing semantics
http://d.puremagic.com/issues/show_bug.cgi?id=10750
--- Comment #3 from Johannes Pfau johannesp...@gmail.com 2013-11-03 02:13:39
PST ---
@bearophile:
To further expand on this:
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html
says:
type-punning is allowed, provided the memory is accessed through the union
type. [...] access by taking the address, casting the resulting pointer and
dereferencing the result has undefined behavior, even if the cast uses a union
type, e.g.:
@David
What would a safe cast with strict pointer aliasing look like?
First some background information on how aliasing is implemented in gcc
(alias.c): Every type is assigned an alias set. The alias set is only a unique
id + a flattened list of the uids of all 'member types'. For example, this
struct:
--
struct B
{
char member;
}
struct A
{
int member1, float member2;
B member3;
}
--
will generate this alias set:
uid=1, children={2(int),3(float),4(char)}
Then for code like this:
--
A instance;
instance.member1 = 0;
A copy = a;
--
The compiler now inspects the line instance.member1 = 0; and assigns alias set
2(int) to it. Line 3 has alias set 1(B). When gcc now schedules instructions it
checks if set 2 conflicts with set 1 by checking: (set1 == set2 || set1 in
set2.children || set2 in set1.children). If they don't conflict gcc reorders
instructions.
This explains the problems with type punning:
--
int a = 3;//alias set 0(int), children = {}
int b = a;//alias set 0(int), children = {}
*(cast(float*)a) = 3.0f; //alias set 1(float), children = {}
--
as you can see these types don't conflict and gcc may reorder line 2 and 3.
Access through unions now solves this problem as the alias set for a union
would include both {float, int} as children.
But as for as I understand these strict alising rules make it impossible to
safely cast from one pointer type to another. Only _access_ through unions will
work.
As an example:
--
T* safeCast(T, U)(U* input)
{
union wrap
{
U inp;
T outp;
}
return (cast(wrap*)input).outp;
}
void withFloat(float* f)
{
*f = 0.1f;
}
int b;
void withInt(int* i)
{
b = *i;
}
void main()
{
int x = 0;
auto asFloat = (safeCast!float(x));
withFloat(asFloat)
withInt(i);
}
--
now with optimizations (inlining)
union wrap
{
int inp;
float outp;
}
int b;
void main()
{
int x = 0;//alias set: int
auto asFloat = ((cast(wrap*)x).outp) //alias set: wrap (but noop)
*asFloat = 0.1f; //alias set: float
b = x;//alias set: int
}
I know from unfortunate experienc, that gcc may even completely discard the
auto asFloat line. But even if it didn't, *asFloat = 0.1f; and b = x; can
be reordered according to strict aliasing rules. If auto asFloat is
discarded, even int x = 0; and *asFloat = 0.1f; may be reordered.
So to summarize this: I don't know how you could make a safe cast from T* to U*
assuming strict aliasing rules. Unions are only safe if all access goes through
unions, but that is not possible when dealing with 3rd party functions. (Assume
you can't change withFloat, withInt).
We had problems with this in GDC right now on ARM (std.algorithm.find uses
cast(ubyte[])string which internally translates to invalid pointer aliasing)
and as a result we'll now have to disable strict aliasing in the GCC backend.
I think type based aliasing, even if it may provide some optimization benefits,
is in general a horrible idea.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10750] Strict aliasing semantics
http://d.puremagic.com/issues/show_bug.cgi?id=10750 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #4 from Iain Buclaw ibuc...@ubuntu.com 2013-11-03 03:17:17 PST --- (In reply to comment #3) We had problems with this in GDC right now on ARM (std.algorithm.find uses cast(ubyte[])string which internally translates to invalid pointer aliasing) and as a result we'll now have to disable strict aliasing in the GCC backend. Which is a shame, because dynamic arrays are perhaps the one type in D that should instead benefit from strict aliasing rules... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11428] New: A simple std.array.array call at compile-time refused
http://d.puremagic.com/issues/show_bug.cgi?id=11428
Summary: A simple std.array.array call at compile-time refused
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-11-03 03:31:19 PST ---
I think this should work, I don't know if this is a regression:
import std.array: array;
const r1 = [].array; // Error
void main() {
const r2 = [].array; // OK
}
dmd 2.064beta4 gives:
...\dmd2\src\phobos\std\array.d(44): Error: returning a pointer to a local
stack variable
...\dmd2\src\phobos\std\array.d(48):called from here:
trustedGetAddr(result[i])
...\dmd2\src\phobos\std\array.d(48):called from here:
emplace(trustedGetAddr(result[i]), e)
test.d(2):called from here: array([])
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10750] Strict aliasing semantics
http://d.puremagic.com/issues/show_bug.cgi?id=10750 --- Comment #5 from Iain Buclaw ibuc...@ubuntu.com 2013-11-03 03:43:06 PST --- (In reply to comment #4) (In reply to comment #3) We had problems with this in GDC right now on ARM (std.algorithm.find uses cast(ubyte[])string which internally translates to invalid pointer aliasing) and as a result we'll now have to disable strict aliasing in the GCC backend. Which is a shame, because dynamic arrays are perhaps the one type in D that should instead benefit from strict aliasing rules... Alternatively, we can just define better aliasing rules that better suit D. ie: - Permit type-punning when accessing through a union. - Determine aliasing rules of dynamic arrays from the elem type, instead of treating it as aliasing the overall structure. This might actually be the better solution for us - shall I send you a patch? :o) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11428] A simple std.array.array call at compile-time refused
http://d.puremagic.com/issues/show_bug.cgi?id=11428
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2013-11-03 06:30:19 PST ---
It's not a regression, because array was not CTFE-able prior to 2.064. I say
CTFE, because you are declaring a global static. This also recreates the issue:
//
import std.array: array;
void main()
{
enum r1 = [].array; // KO
static const r2 = [].array; // KO
}
//
The issue seems to only happen if the element type is a string. I can't
reproduce with other types. Further more, it only happens if the string is a
literal. EG:
//
void main()
{
static const string r = ;
static const r1 = r.array; // OK
static const r2 = [1].array; // OK
static const r2 = [].array; // ERROR
}
//
Here is a reduced case.
//
T[] arr(T)(T[] input)
{
static T* getAddr(ref T t)
{
return t; //Error: returning a pointer to a local stack variable
}
getAddr(input[0]);
return input;
}
void main()
{
static const string r = ;
static const r1 = r.arr; // OK
static const r2 = [1].arr; // OK
static const r3 = [].arr; // ERROR
}
//
I can't really make any sense of this on my end. Maybe Don has an idea?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11429] New: Deprecate walkLength?
http://d.puremagic.com/issues/show_bug.cgi?id=11429
Summary: Deprecate walkLength?
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-11-03 06:39:25 PST ---
This is an alternative to issue 8467.
If issue 8467 is refused, then I suggest to just deprecate walkLength, and
leave only count(), because it can replace walkLength (if count lacks the
.length shortcut optimization, it should be added):
import std.algorithm: count, map;
void main() {
assert([0, 0, 1].map!(x = x).count == 3);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11392] dirEntries segfaults (fails in 2.064 beta 4, works in 2.063.2)
http://d.puremagic.com/issues/show_bug.cgi?id=11392 --- Comment #11 from github-bugzi...@puremagic.com 2013-11-03 06:37:12 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/fe9a3537ea2d208f3d5e37f6a2ea6e50f00aadd2 fix Issue 11392 - dirEntries segfaults https://github.com/D-Programming-Language/phobos/commit/2a0d3d63954ed31d585708a41394e46115f9007d Merge pull request #1680 from WalterBright/fix11392 fix Issue 11392 - dirEntries segfaults -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11404] ICE on using TypeTuple for AA values
http://d.puremagic.com/issues/show_bug.cgi?id=11404 --- Comment #3 from github-bugzi...@puremagic.com 2013-11-03 07:15:29 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a22e95e0e8f666001f8a67a61f231f94fca71217 fix Issue 11404 - ICE on using TypeTuple for AA values https://github.com/D-Programming-Language/dmd/commit/4047a61792e5226bea796ce36db26af0aa919494 Merge pull request #2707 from 9rnsr/fix11404 Issue 11404 - ICE on using TypeTuple for AA values -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11404] ICE on using TypeTuple for AA values
http://d.puremagic.com/issues/show_bug.cgi?id=11404 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11424] Regression (2.064 git-head) typedef on structs isn't caught
http://d.puremagic.com/issues/show_bug.cgi?id=11424 --- Comment #3 from github-bugzi...@puremagic.com 2013-11-03 07:19:46 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/2a2fa477d09d5c7416ad98cb5615235d4c519efc fix Issue 11424 - typedef on structs isn't caught It should be caught even if the typedef keyword usage is meaningless. https://github.com/D-Programming-Language/dmd/commit/05686c7184571fc931f8f79d859da219800d3e41 Merge pull request #2711 from 9rnsr/fix11424 [REG2.064a] Issue 11424 - typedef on structs isn't caught -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10015] Segfault on forward referencing a variable of templated struct
http://d.puremagic.com/issues/show_bug.cgi?id=10015 --- Comment #2 from github-bugzi...@puremagic.com 2013-11-03 07:28:36 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5bb812cf4f3abad8345739729df929efccc4989c fix Issue 10015 - Segfault on forward referencing a variable of templated struct https://github.com/D-Programming-Language/dmd/commit/d40a8096b158fb957be982a8c6f6d4cd868086ec Merge pull request #2708 from 9rnsr/fix10015 Issue 10015 - Segfault on forward referencing a variable of templated struct -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11424] Regression (2.064 git-head) typedef on structs isn't caught
http://d.puremagic.com/issues/show_bug.cgi?id=11424 Andrej Mitrovic andrej.mitrov...@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 10015] Segfault on forward referencing a variable of templated struct
http://d.puremagic.com/issues/show_bug.cgi?id=10015 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11226] Problems with typeof(null) and const
http://d.puremagic.com/issues/show_bug.cgi?id=11226 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11226] Problems with typeof(null) and const
http://d.puremagic.com/issues/show_bug.cgi?id=11226 --- Comment #3 from github-bugzi...@puremagic.com 2013-11-03 07:32:05 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/068f4e55d611054a8c6f80e8479884ce1d1b1c4c fix Issue 11226 - Problems with typeof(null) and const https://github.com/D-Programming-Language/dmd/commit/fec22e29d835977551fe808bfc63d1f73e6ae832 Merge pull request #2703 from 9rnsr/fix11226 Issue 11226 - Problems with typeof(null) and const -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11430] New: A simpler overload for std.file.slurp
http://d.puremagic.com/issues/show_bug.cgi?id=11430 Summary: A simpler overload for std.file.slurp Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2013-11-03 07:33:34 PST --- I think it could be handy to add another overload of the std.file.slurp template function. Currently (dmd 2.064) this is its usage syntax (using UFCS for the file name), that essentially states the types two times: const arr1 = data.txt.slurp!(int, int)(%d, %d); If the user wants to state them only once (more DRY) then slurp could also accept: const arr2 = data.txt.slurp!%d, %d; This is not a replacement for the precedent syntax because the formatting syntax is less precise (%d %f can only take an int and a double, so with this syntax you can't specify a long and a real), but in many common cases I think it's enough and it's simpler. (In theory the API of slurp could even change, returning a lazy range, useful for larger files.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11424] Regression (2.064 git-head) typedef on structs isn't caught
http://d.puremagic.com/issues/show_bug.cgi?id=11424 --- Comment #4 from github-bugzi...@puremagic.com 2013-11-03 07:50:54 PST --- Commit pushed to 2.064 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/7762f03709b8ceb0950f02d47cf4e703bdbabc6b Merge pull request #2711 from 9rnsr/fix11424 [REG2.064a] Issue 11424 - typedef on structs isn't caught -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10259] ICE on invalid compile-time class instantiation
http://d.puremagic.com/issues/show_bug.cgi?id=10259 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com 2013-11-04 03:18:52 EST --- This bug doesn't seem to ice any more, on win32. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11291] Disallow mutation of a const variable
http://d.puremagic.com/issues/show_bug.cgi?id=11291 --- Comment #3 from github-bugzi...@puremagic.com 2013-11-03 08:26:50 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d826696f214166a07371c4401e3a1d6e27bd5082 fix Issue 11291 - Disallow mutation of a const variable https://github.com/D-Programming-Language/dmd/commit/1c0f7a2c7cc4943076d5bd5d30c31dc19fd7ef0b Merge pull request #2678 from 9rnsr/fix11291 Issue 11291 - Disallow mutation of a const variable -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5747] cannot cast away shared if opCast defined
http://d.puremagic.com/issues/show_bug.cgi?id=5747
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #4 from monarchdo...@gmail.com 2013-11-03 08:31:45 PST ---
Just hit this. IMO, this is a bug: The presence of an opCast should not prevent
qualification-cast, which don't actually change the type. In particular, the
problem is that *even* trying to hand write it, it's not possible:
//
import std.traits;
struct S
{
int* p; //prevent implicit cast
T opCast(T:bool)() pure const
{
return false;
}
T opCast(T)() const
if (is(Unqual!T == S))
{
return this; //This fails
return cast(T) this; //This overflows
}
}
void main()
{
immutable(S) s;
auto b = cast(S)(s); //How to do this?
}
//
IMO, a cast to the *same* type (but different quals) should always be defined
by the compiler, even if another opCast is defined, unless the use explicitly
overrides *that* opCast.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11291] Disallow mutation of a const variable
http://d.puremagic.com/issues/show_bug.cgi?id=11291 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11431] New: std.file.slurp with Windows newlines
http://d.puremagic.com/issues/show_bug.cgi?id=11431
Summary: std.file.slurp with Windows newlines
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-11-03 08:35:57 PST ---
If I create a simple data.txt file containing this, with Windows newlines:
10
20
30
And I try to read it with slurp:
import std.file: slurp;
void main() {
slurp!(int)(data.txt, %d);
}
I get a stack trace:
object.Exception@...\dmd2\src\phobos\std\file.d(2992): Trailing characters at
the end of line: `
'
-
0x00413C36 in pure @safe void std.exception.bailOut(immutable(char)[], uint,
const(char[]))
...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11432] New: formattedRead and slurp %s format code miss tab as whitespace
http://d.puremagic.com/issues/show_bug.cgi?id=11432
Summary: formattedRead and slurp %s format code miss tab as
whitespace
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-11-03 09:12:46 PST ---
This is a C program, note the string s that contains three fields, each
separated by a single tab:
#include stdio.h
#include stdlib.h
int main() {
char* s = red\t10\t20;
char t[20];
int a, b;
sscanf(s, %s %d %d, t, a, b);
printf(%s%d%d\n, t, a, b);
return 0;
}
It prints the output I expect:
red1020
The syntax of scanf says regarding the %s code:
http://www.mkssoftware.com/docs/man3/scanf.3.asp
s
A character string is expected; the corresponding argument should be a
character pointer pointing to an array of characters large enough to accept the
string and a terminating \0, which is added automatically. A white-space
character terminates the input field. The conversion specifier hS is
equivalent.
I think this is a similar D program:
import std.format, std.stdio;
void main() {
string s = red\t10\t20;
string t;
int a, b;
formattedRead(s, %s %d %d, t, a, b);
writef(%s%d%d\n, t, a, b);
}
But it prints:
red10 2000
As you see the tab is considered part of the first string field. This causes me
troubles when I use slurp as shown below.
If I have this data.txt text file with Unix-style newlines, and where the
string is separated by the integer with just 1 tab character:
red 10
blue20
(So the whole file is: red\t10\nblue\t20).
If I run this code:
import std.file: slurp;
void main() {
slurp!(string, int)(data.txt, %s %d);
}
I get a stacktrace (dmd 2.064beta4):
std.conv.ConvException@...\dmd2\src\phobos\std\conv.d(2009): Unexpected end of
input when converting from type char[] to type int
0x0040E269 in pure @safe int std.conv.parse!(int, char[]).parse(ref char[]) at
C:\dmd2\src\phobos\std\conv.d(2010)
...
To avoid the stack trace I have to put a tab between the two formattings:
import std.file: slurp;
void main() {
slurp!(string, int)(data.txt, %s\t%d);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11426] Reinterpret element-wise array initializing should be rejeted
http://d.puremagic.com/issues/show_bug.cgi?id=11426 --- Comment #2 from github-bugzi...@puremagic.com 2013-11-03 10:53:47 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0a36934cc7fef35092887747f78ed1d3f599b179 fix Issue 11426 - Reinterpret element-wise array initializing should be rejected https://github.com/D-Programming-Language/dmd/commit/21a6e3eb242c9823b46a78e5e18a23f7b6064ab1 Merge pull request #2712 from 9rnsr/fix11426 [REG2.061] Issue 11426 - Reinterpret element-wise array initializing should be rejeted -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
