Re: What library functionality would you most like to see in D?
Brad Roberts wrote: On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote: On 8/1/11 7:51 PM, Brad Roberts wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Python has something and as far as I can tell people are fine with that. Andrei It has something _in the base library_? It has wrappers for all/most of the popular libraries? The standard distributions install some combination of those? I don't use python so I'm ill equipped to discuss, but my guess is that it's not the first but rather the last. It only has a wrapper for the Tkinter (from Tcl/Tk). I don't think a lot of people use it for serious stuff, it's kinda ancient. A lot of people use the Qt bindings though - these are not in the standard library.
Re: What library functionality would you most like to see in D?
On 2011-08-02 19:58, Jimmy Cao wrote: You're right, it's probably not that important. I guess it's most important that a cross-platform GUI library can simply be easily installed and set up (with some sort of D package manager). I think that would make most sense. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On 2011-08-02 21:48, Walter Bright wrote: On 8/1/2011 5:51 PM, Brad Roberts wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. Also, remember, we did try to endorse a standard gui library for D a while back. It was a disaster on every front. Yes, that was very unfortunate that basically when you announced DWT (the old one) as the standard GUI library the development stopped. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On 2011-08-02 21:57, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:j18dfe$20rj$1...@digitalmars.com... Windows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X version. These are the platforms that SWT supports: Windows 32/64bit Windows CE Linux 32/64bit and PPC64 Solaris 10 x86 and Sparc HPUX IA64_32 AIX PPC/64 Mac OS X 32/64bit It does Solaris, HPUX, and AIX, but not BSD?? I'm just listing was officially supported with binary releases. I don't see a reason why GTK on BSD wouldn't work. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On 2011-08-02 22:01, Nick Sabalausky wrote: Alex Rønne Petersenxtzgzo...@gmail.com wrote in message news:j19d45$pt5$1...@digitalmars.com... On 02-08-2011 18:44, Jacob Carlborg wrote: Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar. Perhaps a curses binding of some sort? Maybe for linux, but it should be cross-platform and therefore use the Win API for that stuff on Windows. (For some bizarre reason, ANSI display support was removed from approx Win2k onward.) Actually when I think about it I've written a simple library like that in C++ for a school project. I wonder if I still have it somewhere. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On Aug 3, 11 13:53, Lutger Blijdestijn wrote: Jimmy Cao wrote: 2011/8/2 sos...@so.so On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not! If a GUI library were included in Phobos, that would make D a much better competitor against C#. That's why I hope such an inclusion would be possible in the future. I see why it might not be possible, though. I really doubt that. You don't get to really compete with C# until D runs on .NET and perhaps even until microsoft adopts it. I don't think a standard gui lib will make any difference. There was a D.net (which seems no longer updated), and when D runs on .NET, the language can use all .NET libraries like WinForms and WPF immediately, and there's no need to have another GUI lib. (And why D needs to compete against C#?)
Re: std.path review: second update
On Mon, 01 Aug 2011 18:18:39 -0400, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:j16pv5$id8$3...@digitalmars.com... Folks, please state your preferences in terms of function names. I'll try to put personal bias aside and compose a naming scheme that is both internally consistent and consistent with the majority opinion. I'm happy either way with Sep/Ext or Separator/Extension. I guess my preference would be for the shorter versions. They're perfectly clear (who isn't familiar with the ext abbreviation for extension?) and they're easier to spell. And one-line file/path manipulations are less likely to grow too far past the 80-char mark. But if we kept the long ones, I wouldn't complain. If I rename setExtension() and defaultExtension() to setExt() and defaultExt(), I feel like extension() should also be renamed to ext() for consistency's sake. I would *really* dislike that, hence my resistance to the shorter names. and also with regards to making non-property functions verbs (e.g. absolutePath and relativePath). I'd be happy to change it, but I'm at loss for good alternatives. I seem to remember you suggesting makeAbsolute and makeRelative, but not being 100% happy with them yourself. Any other suggestions? I agree with function names should be verbs as a general guideline, but I don't think it should be taken so strictly that it gets forced on in situations (like this one) where it just doesn't work quite as well. Despite not being verbs, absolutePath/relativePath are perfectly clear and much more descriptive than makeAbsolute/makeRelative (Make an absolute or relative what?). And then makeAbsolutePath/makeRelativePath is just starting to get verbose. I actually preferred the names from my original proposal: toAbsolute and toRelative. But someone (can't remember who) pointed out that toSomething functions by convention convert between types, and they're probably right. I think this is one case where it's just not worthwhile to force the function names should be verbs guideline. That seems to be the general consensus. I'll keep the names as they are. -Lars
Re: What does C++ do better than D? - StackOverflow.com
Don Wrote: Completely agree. Right now, we don't *want* to attract anybody who expects a finished product. We shouldn't advertise as if we do. Well, there's not such thing as a finished product. Things either rock or suck. If something doesn't work, it sucks, but that's manageable with advertisement: Americans think what you say them to think. They can't even use tabs for code formatting.
Re: std.path review: second update
On Wednesday 03 August 2011 08:35:10 Lars T. Kyllingstad wrote: On Mon, 01 Aug 2011 18:18:39 -0400, Nick Sabalausky wrote: Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:j16pv5$id8$3...@digitalmars.com... Folks, please state your preferences in terms of function names. I'll try to put personal bias aside and compose a naming scheme that is both internally consistent and consistent with the majority opinion. I'm happy either way with Sep/Ext or Separator/Extension. I guess my preference would be for the shorter versions. They're perfectly clear (who isn't familiar with the ext abbreviation for extension?) and they're easier to spell. And one-line file/path manipulations are less likely to grow too far past the 80-char mark. But if we kept the long ones, I wouldn't complain. If I rename setExtension() and defaultExtension() to setExt() and defaultExt(), I feel like extension() should also be renamed to ext() for consistency's sake. I would *really* dislike that, hence my resistance to the shorter names. Well, it _is_ somewhat less consistent that way, but I think that gain in having shorter function names makes it worth it. So, I'd stick with extension but shorten all of the others to Ext. It _is_ consistent insomuch as all of the functions which have more than one word in them shorten it to Ext. The only odd man out is the one which is only one word, and I think that the reason why it was different would be fairly obvious to anyone using std.path. So, yes. You have less consistency with setExt, defaultExt, and extension, but I definitely think that the benefits make it worth it. and also with regards to making non-property functions verbs (e.g. absolutePath and relativePath). I'd be happy to change it, but I'm at loss for good alternatives. I seem to remember you suggesting makeAbsolute and makeRelative, but not being 100% happy with them yourself. Any other suggestions? I agree with function names should be verbs as a general guideline, but I don't think it should be taken so strictly that it gets forced on in situations (like this one) where it just doesn't work quite as well. Despite not being verbs, absolutePath/relativePath are perfectly clear and much more descriptive than makeAbsolute/makeRelative (Make an absolute or relative what?). And then makeAbsolutePath/makeRelativePath is just starting to get verbose. I actually preferred the names from my original proposal: toAbsolute and toRelative. But someone (can't remember who) pointed out that toSomething functions by convention convert between types, and they're probably right. I think this is one case where it's just not worthwhile to force the function names should be verbs guideline. That seems to be the general consensus. I'll keep the names as they are. I'd argue that it's worth it for absolutePath and relativePath (I see no problem with makeAbsolute and makeRelative), and since Absolute and Relative aren't types and can't cause confusion in that regard, I don't really mind toAbsolute and toRelative either, but it does seem that not everyone agrees on that point. - Jonathan M Davis
Re: What does C++ do better than D? - StackOverflow.com
On Wednesday 03 August 2011 04:52:51 Kagamin wrote: Don Wrote: Completely agree. Right now, we don't *want* to attract anybody who expects a finished product. We shouldn't advertise as if we do. Well, there's not such thing as a finished product. Things either rock or suck. If something doesn't work, it sucks, but that's manageable with advertisement: Americans think what you say them to think. They can't even use tabs for code formatting. There's a difference between a programming language which has reached an appropriate level of maturity that people can use it without fear of running into compiler bugs or issues with the spec and a language which is frozen. No, D will likely never be frozen. It will continue to evolve. We may very well end up making D3 at some point. But until dmd and Phobos are at the point that it's unlikely that you're going to run into bugs in them (like you'd expect with C++, Java, python, etc.), then D isn't really mature enough for mainstream use, and a lot of people who try it out will get turned off by it. We're approaching the point where we'll have that kind of stability, but we're not there yet. And it's important that we recognize that fact. - Jonathan M Davis
Lion-compatibilty emergency release, or put warning on download page?
As you might know, the current druntime release contains a GC bug which causes hard to track down crashes due to premature garbage collection in combination with the OS X Lion ASLR, which is enabled by default on all systems now. The problem is well understood, and a fix has already been merged into master (https://github.com/D-Programming-Language/druntime/pull/43). Given that there are already three people who have independently hit the issue (Magnus Hetland just raised the topic on D.learn again) and the elusive nature of the bug, is this severe enough to warrant an emergency bugfix release? Or would it be possible to put a warning on the download page, suggesting to use Git master for applications deployed to Lion? Thanks, David
From a C++/JS benchmark
The benchmark info: http://chadaustin.me/2011/01/digging-into-javascript-performance/ The code, in C++, JS, Java, C#: https://github.com/chadaustin/Web-Benchmarks/ The C++/JS/Java code runs on a single core. D2 version translated from the C# version (the C++ version uses struct inheritance!): http://ideone.com/kf1tz Bye, bearophile
Re: What library functionality would you most like to see in D?
There's pdcurses which apparently works on Windows. It's public domain. I'm not sure if this is the one that supports ASCII escape codes though. And I haven't tested it. Home: http://pdcurses.sourceforge.net/ Binaries: http://gnuwin32.sourceforge.net/packages/pdcurses.htm
Re: Lion-compatibilty emergency release, or put warning on download page?
On Aug 3, 2011, at 8:06 AM, David Nadlinger wrote: As you might know, the current druntime release contains a GC bug which causes hard to track down crashes due to premature garbage collection in combination with the OS X Lion ASLR, which is enabled by default on all systems now. The problem is well understood, and a fix has already been merged into master (https://github.com/D-Programming-Language/druntime/pull/43). Given that there are already three people who have independently hit the issue (Magnus Hetland just raised the topic on D.learn again) and the elusive nature of the bug, is this severe enough to warrant an emergency bugfix release? Or would it be possible to put a warning on the download page, suggesting to use Git master for applications deployed to Lion? Is this fix alone sufficient for the test suite to pass on Lion? I blew away my Lion partition a while back and haven't had a chance to re-create and test.
Re: What does C++ do better than D? - StackOverflow.com
Jonathan M Davis Wrote: There's a difference between a programming language which has reached an appropriate level of maturity that people can use it without fear of running into compiler bugs or issues with the spec and a language which is frozen. Maybe, they just enjoy running into mature language design bugs? No, D will likely never be frozen. It will continue to evolve. So do C, C++, C#, Python... some motions in java domain... Even HTML does it.
Re: What does C++ do better than D? - StackOverflow.com
Jonathan M Davis Wrote: There's a difference between a programming language which has reached an appropriate level of maturity that people can use it without fear of running into compiler bugs or issues with the spec and a language which is frozen. Maybe, they just enjoy running into mature language design bugs? No, D will likely never be frozen. It will continue to evolve. So do C, C++, C#, Python... some motions in java domain... Even HTML does it. I wasn't saying that they don't. They do (though C and C++ are notoriously slow about evolving). My point is that most programmers don't really expect a compiler to have bugs. Yes, like every other piece of software, even mature compilers have bugs, but with mature compilers, people generally either don't run into them or don't notice them (especially if they're subtle bugs). So, your average programmer is _not_ going to be happy with a compiler like dmd where you can run into bugs quite easily. And there is a very big difference between having a compiler which is constantly improving but which still has bugs which are easy to run into and a compiler which is constantly improving but where you rarely hit bugs in it when using it. C, C++. C#, Python, etc. are all mature enough that bugs in their compilers and standard libraries are going to be comparatively rare for most programmers. D is not at that point yet. _That_ is the point that we need to reach to really consider D to be a finished product. It's getting there, and it will continue to evolve even once it's reached that point, but until it does reach that point, D will be a unacceptable to many programmers simply due to the quality of implementation issues. - Jonathan M Davis
Object/document database
I'm not sure this is the right place to post this. I apologize in advance. Can Orage be used as an object/document database? If not, are there any plans to add support to it. And also, is there anyone working on an object/document database for D or bindings to existing projects? Thank you.
Re: From a C++/JS benchmark
03.08.2011 18:20, bearophile: The benchmark info: http://chadaustin.me/2011/01/digging-into-javascript-performance/ The code, in C++, JS, Java, C#: https://github.com/chadaustin/Web-Benchmarks/ The C++/JS/Java code runs on a single core. D2 version translated from the C# version (the C++ version uses struct inheritance!): http://ideone.com/kf1tz Bye, bearophile Compilers: C++: cl /O2 /Oi /Ot /Oy /GT /GL and link /STACK:1024 Java: Oracle Java 1.6 with hm... Oracle default settings C#: Csc /optimize+ D2: dmd -O -noboundscheck -inline -release Type column: working scalar type Other columns: vertices per second (inaccuracy is about 1%) by language (tests from bearophile's message, C++ test is skinning_test_no_simd.cpp). System: Windows XP, Core 2 Duo E6850 --- Type |C++ |Java| C# | D2 --- float | 31_400_000 | 17_000_000 | 14_700_000 |168_000 double | 32_300_000 | 16_000_000 | 14_100_000 |166_000 real| 32_300_000 | no real | no real |203_000 int | 29_100_000 | 14_600_000 | 14_100_000 | 16_500_000 long| 29_100_000 | 6_600_000 | 4_400_000 | 5_800_000 --- JavaScript vs C++ speed is at the first link of original bearophile's post and JS is about 10-20 temes slower than C++. Looks like a spiteful joke... In other words: WTF?! JavaScript is about 10 times faster than D in floating point calculations!? Please, tell me that I'm mistaken.
Re: From a C++/JS benchmark
I believe that long in this case is 32 bits in C++, and 64-bits in the remaining languages, hence the same result for int and long in C++. Try with long long maybe? :) -- Ziad 2011/8/3 Denis Shelomovskij verylonglogin@gmail.com 03.08.2011 18:20, bearophile: The benchmark info: http://chadaustin.me/2011/01/**digging-into-javascript-**performance/http://chadaustin.me/2011/01/digging-into-javascript-performance/ The code, in C++, JS, Java, C#: https://github.com/chadaustin/**Web-Benchmarks/https://github.com/chadaustin/Web-Benchmarks/ The C++/JS/Java code runs on a single core. D2 version translated from the C# version (the C++ version uses struct inheritance!): http://ideone.com/kf1tz Bye, bearophile Compilers: C++: cl /O2 /Oi /Ot /Oy /GT /GL and link /STACK:1024 Java: Oracle Java 1.6 with hm... Oracle default settings C#: Csc /optimize+ D2: dmd -O -noboundscheck -inline -release Type column: working scalar type Other columns: vertices per second (inaccuracy is about 1%) by language (tests from bearophile's message, C++ test is skinning_test_no_simd.cpp). System: Windows XP, Core 2 Duo E6850 --**- Type |C++ |Java| C# | D2 --**- float | 31_400_000 | 17_000_000 | 14_700_000 |168_000 double | 32_300_000 | 16_000_000 | 14_100_000 |166_000 real| 32_300_000 | no real | no real |203_000 int | 29_100_000 | 14_600_000 | 14_100_000 | 16_500_000 long| 29_100_000 | 6_600_000 | 4_400_000 | 5_800_000 --**- JavaScript vs C++ speed is at the first link of original bearophile's post and JS is about 10-20 temes slower than C++. Looks like a spiteful joke... In other words: WTF?! JavaScript is about 10 times faster than D in floating point calculations!? Please, tell me that I'm mistaken.
Re: From a C++/JS benchmark
03.08.2011 22:15, Ziad Hatahet: I believe that long in this case is 32 bits in C++, and 64-bits in the remaining languages, hence the same result for int and long in C++. Try with long long maybe? :) -- Ziad 2011/8/3 Denis Shelomovskij verylonglogin@gmail.com mailto:verylonglogin@gmail.com 03.08.2011 18:20, bearophile: The benchmark info: http://chadaustin.me/2011/01/__digging-into-javascript-__performance/ http://chadaustin.me/2011/01/digging-into-javascript-performance/ The code, in C++, JS, Java, C#: https://github.com/chadaustin/__Web-Benchmarks/ https://github.com/chadaustin/Web-Benchmarks/ The C++/JS/Java code runs on a single core. D2 version translated from the C# version (the C++ version uses struct inheritance!): http://ideone.com/kf1tz Bye, bearophile Compilers: C++: cl /O2 /Oi /Ot /Oy /GT /GL and link /STACK:1024 Java: Oracle Java 1.6 with hm... Oracle default settings C#: Csc /optimize+ D2: dmd -O -noboundscheck -inline -release Type column: working scalar type Other columns: vertices per second (inaccuracy is about 1%) by language (tests from bearophile's message, C++ test is skinning_test_no_simd.cpp). System: Windows XP, Core 2 Duo E6850 --__- Type |C++ |Java| C# | D2 --__- float | 31_400_000 | 17_000_000 | 14_700_000 |168_000 double | 32_300_000 | 16_000_000 | 14_100_000 |166_000 real| 32_300_000 | no real | no real |203_000 int | 29_100_000 | 14_600_000 | 14_100_000 | 16_500_000 long| 29_100_000 | 6_600_000 | 4_400_000 | 5_800_000 --__- JavaScript vs C++ speed is at the first link of original bearophile's post and JS is about 10-20 temes slower than C++. Looks like a spiteful joke... In other words: WTF?! JavaScript is about 10 times faster than D in floating point calculations!? Please, tell me that I'm mistaken. Good! This is my first blunder (it's so easy to complitely forget illogical (for me) language design). So, corrected last row: Type |C++ |Java| C# | D2 - long| 5_500_000 | 6_600_000 | 4_400_000 | 5_800_000 Java is the fastest long language :)
Re: From a C++/JS benchmark
On 8/3/11 9:48 PM, Adam D. Ruppe wrote: System: Windows XP, Core 2 Duo E6850 Is this Windows XP 32 bit or 64 bit? That will probably make a difference on the longs I'd expect. It doesn't, long is 32-bit wide on Windows x86_64 too (LLP64). David
Re: From a C++/JS benchmark
System: Windows XP, Core 2 Duo E6850 Is this Windows XP 32 bit or 64 bit? That will probably make a difference on the longs I'd expect.
Re: From a C++/JS benchmark
03.08.2011 22:48, Adam D. Ruppe пишет: System: Windows XP, Core 2 Duo E6850 Is this Windows XP 32 bit or 64 bit? That will probably make a difference on the longs I'd expect. I meant Windows XP 32 bit (5.1 (Build 2600: Service Pack 3)) (according to what is Windows XP in wikipedia)
Re: From a C++/JS benchmark
Denis Shelomovskij: (tests from bearophile's message, C++ test is skinning_test_no_simd.cpp). For a more realistic test I suggest you to time the C++ version that uses the intrinsics too (only for float). Looks like a spiteful joke... In other words: WTF?! JavaScript is about 10 times faster than D in floating point calculations!? Please, tell me that I'm mistaken. Languages aren't slow or fast, their implementations produce assembly that's more or less efficient. A D1 version fit for LDC V1 with Tango: http://codepad.org/ewDy31UH Vertices (millions), Linux 32 bit: C++ no simd: 29.5 D:27.6 LDC based on DMD v1.057 and llvm 2.6, ldc -O3 -release -inline G++ V4.3.3, -s -O3 -mfpmath=sse -ffast-math -msse3 It's a bit slower than the C++ version, but for most people that's an acceptable difference (and maybe porting the C++ code to D instead of the C# one and using a more modern LLVM you reduce that loss a bit). Bye, bearophile
Re: What library functionality would you most like to see in D?
This is interesting: http://openil.sourceforge.net/ In particular that news post from 2010. Apparently the author might consider changing the license if there's interest in it.
DMD with older versions of Linux
Dreamhost doesn't provide an updated glibc in my vps server. Is it possible to run dmd on somewhat outdated linux distributions? I tried running dmd from the distribution but got: ./dmd: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./dmd) The instaled versions are: $ ldd --version ldd (GNU libc) 2.7 $ uname -a Linux ps54363 2.6.33.7-vs2.3.0.36.30.4 #23 SMP Tue Sep 28 05:47:35 PDT 2010 x86_64 GNU/Linux If it's not possible to run the standard DMD package, could I build it from source using those versions? Thank you
Re: DMD with older versions of Linux
On 8/4/11 2:05 AM, Adam Davis wrote: If it's not possible to run the standard DMD package, could I build it from source using those versions? I don't know it off hand, but just try running »make -f posix.mak« in the src/ directory and you'll see (add »MODEL=64« for x86_64). David
Re: From a C++/JS benchmark
Looks like a spiteful joke... In other words: WTF?! JavaScript is about 10 times faster than D in floating point calculations!? Please, tell me that I'm mistaken. I'm afraid not. dmd's backend isn't good at floating point calculations.
Re: DMD with older versions of Linux
Dreamhost doesn't provide an updated glibc in my vps server. Is it possible to run dmd on somewhat outdated linux distributions? I tried running dmd from the distribution but got: ./dmd: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./dmd) The instaled versions are: $ ldd --version ldd (GNU libc) 2.7 $ uname -a Linux ps54363 2.6.33.7-vs2.3.0.36.30.4 #23 SMP Tue Sep 28 05:47:35 PDT 2010 x86_64 GNU/Linux If it's not possible to run the standard DMD package, could I build it from source using those versions? I built it from source on Fedora 9 so that I could use some of my helper programs at work. I had more problems getting git set up properly to grab the latest stuff than building dmd. Building dmd worked just fine. If you use the zip file from the latest release, it should be quite easy. - Jonathan M Davis
Re: From a C++/JS benchmark
Trass3r: I'm afraid not. dmd's backend isn't good at floating point calculations. Studying a bit the asm it's not hard to find the cause, because this benchmark is quite pure (synthetic, despite I think it comes from real-world code). This is what G++ generates from the C++ code without intrinsics (the version that uses SIMD intrinsics has a similar look but it's shorter): movl (%eax), %edx movss 4(%eax), %xmm0 movl 8(%eax), %ecx leal (%edx,%edx,2), %edx sall $4, %edx addl %ebx, %edx testl %ecx, %ecx movss 12(%edx), %xmm1 movss 20(%edx), %xmm7 movss (%edx), %xmm5 mulss %xmm0, %xmm1 mulss %xmm0, %xmm7 movss 4(%edx), %xmm6 movss 8(%edx), %xmm4 movss %xmm1, (%esp) mulss %xmm0, %xmm5 movss 28(%edx), %xmm1 movss %xmm7, 4(%esp) mulss %xmm0, %xmm6 movss 32(%edx), %xmm7 mulss %xmm0, %xmm1 movss 16(%edx), %xmm3 mulss %xmm0, %xmm7 movss 24(%edx), %xmm2 movss %xmm1, 16(%esp) mulss %xmm0, %xmm4 movss 36(%edx), %xmm1 movss %xmm7, 8(%esp) mulss %xmm0, %xmm3 movss 40(%edx), %xmm7 mulss %xmm0, %xmm2 mulss %xmm0, %xmm1 mulss %xmm0, %xmm7 mulss 44(%edx), %xmm0 leal 12(%eax), %edx movss %xmm7, 12(%esp) movss %xmm0, 20(%esp) This is what DMD generates for the same (or quite similar) piece of code: movsd mov EAX,068h[ESP] imul EDX,EAX,030h add EDX,018h[ESP] fld float ptr [EDX] fmul float ptr 06Ch[ESP] fstp float ptr 038h[ESP] fld float ptr 4[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 03Ch[ESP] fld float ptr 8[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 040h[ESP] fld float ptr 0Ch[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 044h[ESP] fld float ptr 010h[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 048h[ESP] fld float ptr 014h[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 04Ch[ESP] fld float ptr 018h[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 050h[ESP] fld float ptr 01Ch[EDX] mov CL,070h[ESP] xor CL,1 fmul float ptr 06Ch[ESP] fstp float ptr 054h[ESP] fld float ptr 020h[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 058h[ESP] fld float ptr 024h[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 05Ch[ESP] fld float ptr 028h[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 060h[ESP] fld float ptr 02Ch[EDX] fmul float ptr 06Ch[ESP] fstp float ptr 064h[ESP] I think DMD back-end already contains logic to use xmm registers as true registers (not as a floating point stack or temporary holes where to push and pull FP values), so I suspect it doesn't take too much work to modify it to emit FP asm with a single optimization: just keep the values inside registers. In my uninformed opinion all other FP optimizations are almost insignificant compared to this one :-) Bye, bearophile
Re: From a C++/JS benchmark
C++: Skinned vertices per second: 4866 C++ no SIMD: Skinned vertices per second: 4242 D dmd: Skinned vertices per second: 159046 D gdc: Skinned vertices per second: 2345 Compilers: gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) g++ -s -O3 -mfpmath=sse -ffast-math -march=native DMD64 D Compiler v2.054 dmd -O -noboundscheck -inline -release dver.d gcc version 4.6.1 20110627 (gdc 0.30, using dmd 2.054) (GCC) gdc -s -O3 -mfpmath=sse -ffast-math -march=native dver.d Ubuntu 11.04 x64 Core2 Duo E6300
Re: From a C++/JS benchmark
C++: Skinned vertices per second: 4866 C++ no SIMD: Skinned vertices per second: 4242 D dmd: Skinned vertices per second: 159046 D gdc: Skinned vertices per second: 2345 D ldc: Skinned vertices per second: 3791 ldc2 -O3 -release -enable-inlining dver.d
Re: From a C++/JS benchmark
Trass3r: C++ no SIMD: Skinned vertices per second: 4242 ... D gdc: Skinned vertices per second: 2345 Are you able and willing to show me the asm produced by gdc? There's a problem there. Bye, bearophile
Re: Object/document database
On Wed, 03 Aug 2011 21:46:45 +0300, Jonathan Hanselman jhansel...@thisisnotmyrealemail.com wrote: Can Orage be used as an object/document database? If not, are there any plans to add support to it. I can't find anything on the web about Orage, an object/document database. And also, is there anyone working on an object/document database for D or bindings to existing projects? What about SQLite? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Fixing enum names in Phobos
On Sunday 31 July 2011 19:30:20 Jonathan M Davis wrote: Okay. Per the current naming conventions in Phobos, enum values are supposed to be camelcased just like any other variable. The enum _type_ is pascal cased just like any other user-defined type, but the values are camelcased. A number of the older parts of Phobos do not follow this convention. Ideally, this would be fixed so that Phobos can be more consistent, and for the most part, those in this newsgroup have agreed that they'd prefer to have Phobos fixed to be more consistent and put up with the temporary code breakage rather than have it permanently inconsistent. The question is whether it's worth it in this case. The enums that I'm aware of in Phobos which are not properly camelcased are: std.compiler.Vendor: DigitalMars (and the recently added GNU, LLVM, and Unknown). std.mmfile.MmFile.Mode: Read, ReadWriteNew, ReadWrite, ReadCopyOnWrite std.JSON_TYPE: STRING, INTEGER, FLOAT, OBJECT, ARRAY, TRUE, FALSE, NULL std.socket.AddressFamily: UNSPEC, UNIX, INET, IPX, APPLETALK std.socket.SocketType: STREAM, DGRAM, RAW, RDM, SEQPACKET std.socket.ProtocolType: IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, IPV6 std.socket.SocketShutdown: RECEIVE, SEND, BOTH std.socket.SocketFlags: NONE, OOB, PEEK, DONTROUTE std.socket.SocketOptionLevel: SOCKET, IP, ICMP, IGMP, GGP, TCP, PUP, UDP, IDP, IPV6 std.socket.OptionLevel: DEBUG, BROADCAST, REUSEADDR, LINGER, OOBINLINE, SNDBUF, RCVBUF, DONTROUTE, SENDTIMEO, RCVTIMEO, TCP_NODELAY, IPV6_UNICAST_HOPS, IPV6_MULTICAST_IF, IPV6_MULTICAST_LOOP, IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP std.stream.BOM: UTF8, UTF16LE, UTF16BE, UTF32LE, UTF32BE std.system.Endian: BigEndian, LittleEndian std.traits.ParameterStorageClass: NONE, SCOPE, OUT, REF, LAZY std.traits.FunctionAttribute: NONE, PURE, NOTHROW, REF, PROPERTY, TRUSTED, SAFE std.traits.Variadic: NO, C, D, TYPESAFE std.xml.DecodeMode: NONE, LOOSE, STRICT std.xml.TagType: START, END, EMPTY So, the question is. Which, if any, should we fix to be camelcased? It will break code to fix any of these. We can't really go through a clean deprecation process on these without outright replacing the enum types themselves, which would have a nasty cascading effect through everything that uses them. The spellchecker will catch the changes easily, and so fixing any code that uses them will be easy, but it will still be annoying. So, is this temporary breakage worth the gain in consistency? And if so, for which ones? Or should we just leave them as-is? So, does anyone actually have an opinion on this? Should we fix the names or not? One person has said that they're in favor of fixing the enum names, and pretty much everything else in this thread has been on what to do about renaming the ones which are keywords when properly camelcased. If we're going to fix these enum names, we need to do it sooner rather than later. And I'd prefer some level of community buy-in before making breaking changes like that. At the moment, it looks like this post has been mostly ignored. Do you not care either way? - Jonathan M Davis
Re: DMD with older versions of Linux
On 8/3/2011 5:05 PM, Adam Davis wrote: If it's not possible to run the standard DMD package, could I build it from source using those versions? Sure. D doesn't have any dependency on the semantics of the newer glib.
DWT2 now looks working on Windows (except Text widget doesn't support UTF-8)
About month ago I fixed some DWT2 bugs, but DWT maintainers just have no time to pull changes to the main repo. Changes are in my (denis_sh) commits descriptions: https://bitbucket.org/denis_sh/patching-dwt2 Short changes description: 1. DWT2 now works on Linux32 with Phobos/D2 as bad as with Tango/D1 (not worse): lots of segfaults when printing and text editing and other bugs. 2. It looks working stable on Windows except Text widget sill doesn't support UTF-8 (yes, StyledText and it's friend now support it). 3. It now have compilable and right snippets.
Re: Convert string to wchar.
On 2011-08-02 19:51, Jonathan M Davis wrote: I tried to convert a string into a wchar, but that didn't compile because of this template constraint: https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L17 70 Is there a way to convert a string into a wchar? Does that even make sense? What do you want it to do, convert the first code point to a wchar and throw if there's more than one character in the string? That's like asking whether you can covert between a container of ints and an int. I would never expect std.conv.to to support that. Not to mention, you shouldn't normally be using char or wchar by themselves, because they might not be valid code points. Normally, only dchar should be used when representing an individual character. If you want this, I'd suggest that you simply do something like cast(wchar)str.front What you're asking for is inherently unsafe as far as unicode goes. - Jonathan M Davis I'm working on a serialization library and I intend to support as many types as possible. So if someone serializes a single wchar I need to be able to deserialize it. Since the serialized data is represented by a string, in this case, I need to convert a string containing a single character to a wchar when deserializing. Yes, convert the first code point to a wchar and then throw if there's more the one character in the string. -- /Jacob Carlborg
Re: Convert string to wchar.
On Wednesday 03 August 2011 08:29:09 Jacob Carlborg wrote: On 2011-08-02 19:51, Jonathan M Davis wrote: I tried to convert a string into a wchar, but that didn't compile because of this template constraint: https://github.com/D-Programming-Language/phobos/blob/master/std/conv. d#L17 70 Is there a way to convert a string into a wchar? Does that even make sense? What do you want it to do, convert the first code point to a wchar and throw if there's more than one character in the string? That's like asking whether you can covert between a container of ints and an int. I would never expect std.conv.to to support that. Not to mention, you shouldn't normally be using char or wchar by themselves, because they might not be valid code points. Normally, only dchar should be used when representing an individual character. If you want this, I'd suggest that you simply do something like cast(wchar)str.front What you're asking for is inherently unsafe as far as unicode goes. - Jonathan M Davis I'm working on a serialization library and I intend to support as many types as possible. So if someone serializes a single wchar I need to be able to deserialize it. Since the serialized data is represented by a string, in this case, I need to convert a string containing a single character to a wchar when deserializing. Yes, convert the first code point to a wchar and then throw if there's more the one character in the string. Well, while it's understandable that you have to cover pretty every possible case of converting to and from a string with what you're doing, I don't think that it's at all reasonable to have std.conv.to convert a string to any character type, let alone one other than dchar. It's almost always a horrible idea and should _not_ be encouraged. So, I'd advise you to just find a way to deal with it appropriately in your own code. I think that it would be a very bad idea for std.conv.to or anything else in Phobos to support such a conversion. - Jonathan M Davis
Re: NaCl stable ABI
On 2/08/11 2:24 AM, Adam Ruppe wrote: From what I can tell, it's Google's alternative to Flash; they want to make crappy games on it. Consider that the first thing they ported to it, again, just like their javascript nonsense, was Quake. (I think Google loves Javascript too much to let it go anyway.) The API has a lot of graphics and audio stuff too which reinforces this. The games industry has been crying out for something like NaCl for a long time. It is exactly what we want: - Ability to launch games within browser without a plugin download - Platform independent ABI - No f*cking Javascript (performance will never match C++) - Safe (no need for end users to worry) JavaScript for high-quality games is a non-starter. It's too slow. You simply cannot do high performance numeric code in Javascript (http://chadaustin.me/2011/01/digging-into-javascript-performance/). Writing C++ code to run outside of the browser is a pain, and inconvenient for the user. First, you have to write your code to handle all the different platforms, which is a huge burden. Once you've done that, you need to convince users to download and install your game. It would be much more convenient to just have users go a website and be done with it. If D were usable in NaCl that would be a huge selling point for the language.
Re: Convert string to wchar.
On Wed, 03 Aug 2011 08:29:09 +0200, Jacob Carlborg d...@me.com wrote:
Yes, convert the first code point to a wchar and then throw if there's
more the one character in the string.
Not tested, and I might be wrong, but 'to!' should work between dchar and
wchar, no?
wchar to_wchar(string s) {
auto c = s.front;
s.popFront();
assert (s.empty);
return to!wchar(c);
}
Re: Convert string to wchar.
On Wednesday 03 August 2011 09:34:53 Pelle wrote:
On Wed, 03 Aug 2011 08:29:09 +0200, Jacob Carlborg d...@me.com wrote:
Yes, convert the first code point to a wchar and then throw if there's
more the one character in the string.
Not tested, and I might be wrong, but 'to!' should work between dchar and
wchar, no?
wchar to_wchar(string s) {
auto c = s.front;
s.popFront();
assert (s.empty);
return to!wchar(c);
}
It's debatable as to whether std.conv.to should be able to convert between
code units like that (you _really_ shouldn't ever be using char or wchar
outside of arrays or other ranges), but it does appear to compile, for better
or worse.
- Jonathan M Davis
Re: Convert string to wchar.
On Wednesday 03 August 2011 01:02:02 Jonathan M Davis wrote:
On Wednesday 03 August 2011 09:34:53 Pelle wrote:
On Wed, 03 Aug 2011 08:29:09 +0200, Jacob Carlborg d...@me.com wrote:
Yes, convert the first code point to a wchar and then throw if
there's
more the one character in the string.
Not tested, and I might be wrong, but 'to!' should work between dchar
and
wchar, no?
wchar to_wchar(string s) {
auto c = s.front;
s.popFront();
assert (s.empty);
return to!wchar(c);
}
It's debatable as to whether std.conv.to should be able to convert between
code units like that (you _really_ shouldn't ever be using char or wchar
outside of arrays or other ranges), but it does appear to compile, for
better or worse.
It looks like the conversion works as long as the character in question will
fit in the character type that you're converting to. If it doesn't fit, then it
throws. So, it's as safe as such a conversion can be (though it still isn't
generally a good idea to use individual chars or wchars in code).
- Jonathan M Davis
Immutable member functions and private members
I have a struct with a private member that is only ever accessed through
a single property method - even from within the struct.
As this property fills the value on the first access, it cannot be
immutable, and as such, none of the many methods accessing this property
can be immutable methods.
This is according to specification, but I thought that since the single
write to the property is done at one, and only one, access point, that
it would be safe?
I could fill this value in the constructor, but it's a bit slow, so I'd
rather do it only if needed.
And is there any potential performance optimizations done by the
compiler, or is it only for safety?
Is there a way to hack around this, and more importantly, is it safe to
do so, or will I open Pandora's box?
Small example:
int len(const char[] c) {
return c.length;
}
struct S {
private immutable(char)[] _v;
@property immutable(char[]) v() { // Cannot be immutable method
if(!_v)
_v = init; /* or from external function */
return _v;
}
@property int a() { // and so this cannot be immutable method
return len(v); /* notice the property function v that might
modify _v */
}
}
void main() {
S s;
s.a;
}
Re: Immutable member functions and private members
On Wednesday 03 August 2011 10:37:58 simendsjo wrote:
I have a struct with a private member that is only ever accessed through
a single property method - even from within the struct.
As this property fills the value on the first access, it cannot be
immutable, and as such, none of the many methods accessing this property
can be immutable methods.
This is according to specification, but I thought that since the single
write to the property is done at one, and only one, access point, that
it would be safe?
I could fill this value in the constructor, but it's a bit slow, so I'd
rather do it only if needed.
And is there any potential performance optimizations done by the
compiler, or is it only for safety?
Is there a way to hack around this, and more importantly, is it safe to
do so, or will I open Pandora's box?
Small example:
int len(const char[] c) {
return c.length;
}
struct S {
private immutable(char)[] _v;
@property immutable(char[]) v() { // Cannot be immutable method
if(!_v)
_v = init; /* or from external function */
return _v;
}
@property int a() { // and so this cannot be immutable method
return len(v); /* notice the property function v that might
modify _v */
}
}
void main() {
S s;
s.a;
}
You're basically looking for logical const - albeit a subset which would be
much easier to implement were we to implement it (that is, a lazy initialized
const or immutable member variable). D has no support for logical const. Even
worse, you're looking for logical immutable (which makes no sense at all
beyond perhaps lazy initialization and probably doesn't even make sense
there).
The thing is that immutable methods are pointless unless you make the struct
immutable (if you want to be able to call them with both a mutable and
immutable instance of the struct, then you need the functions to be const, not
immutable). And if you make the struct immutable, the compiler is free to put
it in read-only memory if it so chooses, at which point setting _anything_ in
the struct after the constructor has run is likely to blow up. So, even if you
can get around the issue via casts and get both lazy initialization and
immutable methods, there's a good chance that it'll blow up at some point (as
in segfault or worse).
If you were trying to do this with const, you might get away with it (though
you'd be stepping outside of the type lsystem by casting away const and then
altering anything - it's undefined behavior). But with immutable, there's no
way that this is a good idea.
Lazy initialization with const or immutable member variables just is _not_ a
good idea in D. D provides no type-safe way to do this. You must break the
type system by casting away const or immutable to even attempt it.
Convievably, in the case of const, the language could be extended to allow for
lazy initialization of member variables, but there's no way that it could do
that with immutable (because the variable could conceivably be put in read-
only memory), and even if it were done, it would likely have to be a D3
feature. Syntactically, it would probably be something like this:
lazy int v = initFunc();
and then when v was first accessed, initFunc would be called and v set to that
value. But that could be ugly and inefficient to implement even if it's
theoretically possible, so I wouldn't bet on anything like that making it into
the language. Regardless, it wouldn't be until D3. For now, D doesn't support
any kind of logical const.
http://stackoverflow.com/questions/4219600/logical-const-in-d
- Jonathan M Davis
Re: Immutable member functions and private members
On 03.08.2011 10:52, Jonathan M Davis wrote:
On Wednesday 03 August 2011 10:37:58 simendsjo wrote:
I have a struct with a private member that is only ever accessed through
a single property method - even from within the struct.
As this property fills the value on the first access, it cannot be
immutable, and as such, none of the many methods accessing this property
can be immutable methods.
This is according to specification, but I thought that since the single
write to the property is done at one, and only one, access point, that
it would be safe?
I could fill this value in the constructor, but it's a bit slow, so I'd
rather do it only if needed.
And is there any potential performance optimizations done by the
compiler, or is it only for safety?
Is there a way to hack around this, and more importantly, is it safe to
do so, or will I open Pandora's box?
Small example:
int len(const char[] c) {
return c.length;
}
struct S {
private immutable(char)[] _v;
@property immutable(char[]) v() { // Cannot be immutable method
if(!_v)
_v = init; /* or from external function */
return _v;
}
@property int a() { // and so this cannot be immutable method
return len(v); /* notice the property function v that might
modify _v */
}
}
void main() {
S s;
s.a;
}
You're basically looking for logical const - albeit a subset which would be
much easier to implement were we to implement it (that is, a lazy initialized
const or immutable member variable). D has no support for logical const. Even
worse, you're looking for logical immutable (which makes no sense at all
beyond perhaps lazy initialization and probably doesn't even make sense
there).
The thing is that immutable methods are pointless unless you make the struct
immutable (if you want to be able to call them with both a mutable and
immutable instance of the struct, then you need the functions to be const, not
immutable). And if you make the struct immutable, the compiler is free to put
it in read-only memory if it so chooses, at which point setting _anything_ in
the struct after the constructor has run is likely to blow up. So, even if you
can get around the issue via casts and get both lazy initialization and
immutable methods, there's a good chance that it'll blow up at some point (as
in segfault or worse).
If you were trying to do this with const, you might get away with it (though
you'd be stepping outside of the type lsystem by casting away const and then
altering anything - it's undefined behavior). But with immutable, there's no
way that this is a good idea.
Lazy initialization with const or immutable member variables just is _not_ a
good idea in D. D provides no type-safe way to do this. You must break the
type system by casting away const or immutable to even attempt it.
Convievably, in the case of const, the language could be extended to allow for
lazy initialization of member variables, but there's no way that it could do
that with immutable (because the variable could conceivably be put in read-
only memory), and even if it were done, it would likely have to be a D3
feature. Syntactically, it would probably be something like this:
lazy int v = initFunc();
and then when v was first accessed, initFunc would be called and v set to that
value. But that could be ugly and inefficient to implement even if it's
theoretically possible, so I wouldn't bet on anything like that making it into
the language. Regardless, it wouldn't be until D3. For now, D doesn't support
any kind of logical const.
http://stackoverflow.com/questions/4219600/logical-const-in-d
- Jonathan M Davis
Thanks!
I'm not really sure the compiler could put my struct in ROM.
My lazy parameter is immutable(char)[], so the compiler should see that
I have a non-immutable reference.
The entire struct is immutable without this lazy variable though.
It only has two handles for passing to external functions.
I really would like to always use it only as immutable s = S(123). It
makes no sense for it to be mutable at all.
Below is an exact example of what I want to do.
If I move the handle2 calculation to the ctor and use const methods, I
still cannot call the methods using a const variable though.. Bug?
const s = S(100);
s.a; // function t.S.a () immutable is not callable using argument type
It says immutable when it should say const..?
immutable s = S(100);
s.a; // works on both const and immutable
import std.conv, std.exception;
// external expensive function
extern(System) char[] getHandle2(const int handle) {
return to!(char[])(handle);
}
// other external functions taking string handle instead of int
extern(System) int extFunc1(string handle2) {
return to!int(handle2);
}
struct S {
immutable int handle;
private immutable(char)[] _handle2;
this(int handle) {
this.handle = handle;
}
@property immutable(char[]) handle2() {
Re: Immutable member functions and private members
On Wednesday 03 August 2011 11:44:27 simendsjo wrote:
On 03.08.2011 10:52, Jonathan M Davis wrote:
On Wednesday 03 August 2011 10:37:58 simendsjo wrote:
I have a struct with a private member that is only ever accessed
through
a single property method - even from within the struct.
As this property fills the value on the first access, it cannot be
immutable, and as such, none of the many methods accessing this
property
can be immutable methods.
This is according to specification, but I thought that since the
single
write to the property is done at one, and only one, access point, that
it would be safe?
I could fill this value in the constructor, but it's a bit slow, so
I'd
rather do it only if needed.
And is there any potential performance optimizations done by the
compiler, or is it only for safety?
Is there a way to hack around this, and more importantly, is it safe
to
do so, or will I open Pandora's box?
Small example:
int len(const char[] c) {
return c.length;
}
struct S {
private immutable(char)[] _v;
@property immutable(char[]) v() { // Cannot be immutable
method
if(!_v)
_v = init; /* or from external function
*/
return _v;
}
@property int a() { // and so this cannot be immutable
method
return len(v); /* notice the property function v
that might
modify _v */
}
}
void main() {
S s;
s.a;
}
You're basically looking for logical const - albeit a subset which would
be much easier to implement were we to implement it (that is, a lazy
initialized const or immutable member variable). D has no support for
logical const. Even worse, you're looking for logical immutable (which
makes no sense at all beyond perhaps lazy initialization and probably
doesn't even make sense there).
The thing is that immutable methods are pointless unless you make the
struct immutable (if you want to be able to call them with both a
mutable and immutable instance of the struct, then you need the
functions to be const, not immutable). And if you make the struct
immutable, the compiler is free to put it in read-only memory if it so
chooses, at which point setting _anything_ in the struct after the
constructor has run is likely to blow up. So, even if you can get
around the issue via casts and get both lazy initialization and
immutable methods, there's a good chance that it'll blow up at some
point (as in segfault or worse).
If you were trying to do this with const, you might get away with it
(though you'd be stepping outside of the type lsystem by casting away
const and then altering anything - it's undefined behavior). But with
immutable, there's no way that this is a good idea.
Lazy initialization with const or immutable member variables just is
_not_ a good idea in D. D provides no type-safe way to do this. You
must break the type system by casting away const or immutable to even
attempt it. Convievably, in the case of const, the language could be
extended to allow for lazy initialization of member variables, but
there's no way that it could do that with immutable (because the
variable could conceivably be put in read- only memory), and even if it
were done, it would likely have to be a D3 feature. Syntactically, it
would probably be something like this:
lazy int v = initFunc();
and then when v was first accessed, initFunc would be called and v set
to that value. But that could be ugly and inefficient to implement even
if it's theoretically possible, so I wouldn't bet on anything like that
making it into the language. Regardless, it wouldn't be until D3. For
now, D doesn't support any kind of logical const.
http://stackoverflow.com/questions/4219600/logical-const-in-d
- Jonathan M Davis
Thanks!
I'm not really sure the compiler could put my struct in ROM.
My lazy parameter is immutable(char)[], so the compiler should see that
I have a non-immutable reference.
The entire struct is immutable without this lazy variable though.
It only has two handles for passing to external functions.
I really would like to always use it only as immutable s = S(123). It
makes no sense for it to be mutable at all.
Below is an exact example of what I want to do.
If I move the handle2 calculation to the ctor and use const methods, I
still cannot call the methods using a const variable though.. Bug?
const s = S(100);
s.a; // function t.S.a () immutable is not callable using argument type
It says immutable when it should say const..?
immutable s = S(100);
s.a; // works on both const and immutable
If a variable is const, you should only be able to call const functions on it.
If it's immutable, you can
Re: Immutable member functions and private members
On 03.08.2011 11:44, simendsjo wrote:
On 03.08.2011 10:52, Jonathan M Davis wrote:
On Wednesday 03 August 2011 10:37:58 simendsjo wrote:
I have a struct with a private member that is only ever accessed through
a single property method - even from within the struct.
As this property fills the value on the first access, it cannot be
immutable, and as such, none of the many methods accessing this property
can be immutable methods.
This is according to specification, but I thought that since the single
write to the property is done at one, and only one, access point, that
it would be safe?
I could fill this value in the constructor, but it's a bit slow, so I'd
rather do it only if needed.
And is there any potential performance optimizations done by the
compiler, or is it only for safety?
Is there a way to hack around this, and more importantly, is it safe to
do so, or will I open Pandora's box?
Small example:
int len(const char[] c) {
return c.length;
}
struct S {
private immutable(char)[] _v;
@property immutable(char[]) v() { // Cannot be immutable method
if(!_v)
_v = init; /* or from external function */
return _v;
}
@property int a() { // and so this cannot be immutable method
return len(v); /* notice the property function v that might
modify _v */
}
}
void main() {
S s;
s.a;
}
You're basically looking for logical const - albeit a subset which
would be
much easier to implement were we to implement it (that is, a lazy
initialized
const or immutable member variable). D has no support for logical
const. Even
worse, you're looking for logical immutable (which makes no sense at all
beyond perhaps lazy initialization and probably doesn't even make sense
there).
The thing is that immutable methods are pointless unless you make the
struct
immutable (if you want to be able to call them with both a mutable and
immutable instance of the struct, then you need the functions to be
const, not
immutable). And if you make the struct immutable, the compiler is free
to put
it in read-only memory if it so chooses, at which point setting
_anything_ in
the struct after the constructor has run is likely to blow up. So,
even if you
can get around the issue via casts and get both lazy initialization and
immutable methods, there's a good chance that it'll blow up at some
point (as
in segfault or worse).
If you were trying to do this with const, you might get away with it
(though
you'd be stepping outside of the type lsystem by casting away const
and then
altering anything - it's undefined behavior). But with immutable,
there's no
way that this is a good idea.
Lazy initialization with const or immutable member variables just is
_not_ a
good idea in D. D provides no type-safe way to do this. You must break
the
type system by casting away const or immutable to even attempt it.
Convievably, in the case of const, the language could be extended to
allow for
lazy initialization of member variables, but there's no way that it
could do
that with immutable (because the variable could conceivably be put in
read-
only memory), and even if it were done, it would likely have to be a D3
feature. Syntactically, it would probably be something like this:
lazy int v = initFunc();
and then when v was first accessed, initFunc would be called and v set
to that
value. But that could be ugly and inefficient to implement even if it's
theoretically possible, so I wouldn't bet on anything like that making
it into
the language. Regardless, it wouldn't be until D3. For now, D doesn't
support
any kind of logical const.
http://stackoverflow.com/questions/4219600/logical-const-in-d
- Jonathan M Davis
Thanks!
I'm not really sure the compiler could put my struct in ROM.
My lazy parameter is immutable(char)[], so the compiler should see that
I have a non-immutable reference.
The entire struct is immutable without this lazy variable though.
It only has two handles for passing to external functions.
I really would like to always use it only as immutable s = S(123). It
makes no sense for it to be mutable at all.
Below is an exact example of what I want to do.
If I move the handle2 calculation to the ctor and use const methods, I
still cannot call the methods using a const variable though.. Bug?
const s = S(100);
s.a; // function t.S.a () immutable is not callable using argument type
It says immutable when it should say const..?
immutable s = S(100);
s.a; // works on both const and immutable
import std.conv, std.exception;
// external expensive function
extern(System) char[] getHandle2(const int handle) {
return to!(char[])(handle);
}
// other external functions taking string handle instead of int
extern(System) int extFunc1(string handle2) {
return to!int(handle2);
}
struct S {
immutable int handle;
private immutable(char)[] _handle2;
this(int handle) {
this.handle = handle;
}
@property immutable(char[]) handle2() {
if(!_handle2) {
auto buf = getHandle2(handle);
_handle2 = assumeUnique(buf);
}
return _handle2;
}
@property int
Re: Immutable member functions and private members
On 03.08.2011 12:01, Jonathan M Davis wrote:
On Wednesday 03 August 2011 11:44:27 simendsjo wrote:
On 03.08.2011 10:52, Jonathan M Davis wrote:
On Wednesday 03 August 2011 10:37:58 simendsjo wrote:
I have a struct with a private member that is only ever accessed
through
a single property method - even from within the struct.
As this property fills the value on the first access, it cannot be
immutable, and as such, none of the many methods accessing this
property
can be immutable methods.
This is according to specification, but I thought that since the
single
write to the property is done at one, and only one, access point, that
it would be safe?
I could fill this value in the constructor, but it's a bit slow, so
I'd
rather do it only if needed.
And is there any potential performance optimizations done by the
compiler, or is it only for safety?
Is there a way to hack around this, and more importantly, is it safe
to
do so, or will I open Pandora's box?
Small example:
int len(const char[] c) {
return c.length;
}
struct S {
private immutable(char)[] _v;
@property immutable(char[]) v() { // Cannot be immutable
method
if(!_v)
_v = init; /* or from external function
*/
return _v;
}
@property int a() { // and so this cannot be immutable
method
return len(v); /* notice the property function v
that might
modify _v */
}
}
void main() {
S s;
s.a;
}
You're basically looking for logical const - albeit a subset which would
be much easier to implement were we to implement it (that is, a lazy
initialized const or immutable member variable). D has no support for
logical const. Even worse, you're looking for logical immutable (which
makes no sense at all beyond perhaps lazy initialization and probably
doesn't even make sense there).
The thing is that immutable methods are pointless unless you make the
struct immutable (if you want to be able to call them with both a
mutable and immutable instance of the struct, then you need the
functions to be const, not immutable). And if you make the struct
immutable, the compiler is free to put it in read-only memory if it so
chooses, at which point setting _anything_ in the struct after the
constructor has run is likely to blow up. So, even if you can get
around the issue via casts and get both lazy initialization and
immutable methods, there's a good chance that it'll blow up at some
point (as in segfault or worse).
If you were trying to do this with const, you might get away with it
(though you'd be stepping outside of the type lsystem by casting away
const and then altering anything - it's undefined behavior). But with
immutable, there's no way that this is a good idea.
Lazy initialization with const or immutable member variables just is
_not_ a good idea in D. D provides no type-safe way to do this. You
must break the type system by casting away const or immutable to even
attempt it. Convievably, in the case of const, the language could be
extended to allow for lazy initialization of member variables, but
there's no way that it could do that with immutable (because the
variable could conceivably be put in read- only memory), and even if it
were done, it would likely have to be a D3 feature. Syntactically, it
would probably be something like this:
lazy int v = initFunc();
and then when v was first accessed, initFunc would be called and v set
to that value. But that could be ugly and inefficient to implement even
if it's theoretically possible, so I wouldn't bet on anything like that
making it into the language. Regardless, it wouldn't be until D3. For
now, D doesn't support any kind of logical const.
http://stackoverflow.com/questions/4219600/logical-const-in-d
- Jonathan M Davis
Thanks!
I'm not really sure the compiler could put my struct in ROM.
My lazy parameter is immutable(char)[], so the compiler should see that
I have a non-immutable reference.
The entire struct is immutable without this lazy variable though.
It only has two handles for passing to external functions.
I really would like to always use it only as immutable s = S(123). It
makes no sense for it to be mutable at all.
Below is an exact example of what I want to do.
If I move the handle2 calculation to the ctor and use const methods, I
still cannot call the methods using a const variable though.. Bug?
const s = S(100);
s.a; // function t.S.a () immutable is not callable using argument type
It says immutable when it should say const..?
immutable s = S(100);
s.a; // works on both const and immutable
If a variable is const, you should only be able to call const functions on it.
If it's immutable, you can call either const or immutable functions. If it's
mutable, then you can call either const or non-const, non-immutable functions.
If it's complaining about being unable to call a function on an immutable
variable when
gives an empty string, while .idup gives null
void main() {
assert(is(typeof() == typeof(.idup))); // both is immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
Re: Convert string to wchar.
On 2011-08-03 08:38, Jonathan M Davis wrote: On Wednesday 03 August 2011 08:29:09 Jacob Carlborg wrote: On 2011-08-02 19:51, Jonathan M Davis wrote: I tried to convert a string into a wchar, but that didn't compile because of this template constraint: https://github.com/D-Programming-Language/phobos/blob/master/std/conv. d#L17 70 Is there a way to convert a string into a wchar? Does that even make sense? What do you want it to do, convert the first code point to a wchar and throw if there's more than one character in the string? That's like asking whether you can covert between a container of ints and an int. I would never expect std.conv.to to support that. Not to mention, you shouldn't normally be using char or wchar by themselves, because they might not be valid code points. Normally, only dchar should be used when representing an individual character. If you want this, I'd suggest that you simply do something like cast(wchar)str.front What you're asking for is inherently unsafe as far as unicode goes. - Jonathan M Davis I'm working on a serialization library and I intend to support as many types as possible. So if someone serializes a single wchar I need to be able to deserialize it. Since the serialized data is represented by a string, in this case, I need to convert a string containing a single character to a wchar when deserializing. Yes, convert the first code point to a wchar and then throw if there's more the one character in the string. Well, while it's understandable that you have to cover pretty every possible case of converting to and from a string with what you're doing, I don't think that it's at all reasonable to have std.conv.to convert a string to any character type, let alone one other than dchar. It's almost always a horrible idea and should _not_ be encouraged. So, I'd advise you to just find a way to deal with it appropriately in your own code. I think that it would be a very bad idea for std.conv.to or anything else in Phobos to support such a conversion. - Jonathan M Davis Ok, fair enough. -- /Jacob Carlborg
Re: Convert string to wchar.
On 2011-08-03 09:34, Pelle wrote:
On Wed, 03 Aug 2011 08:29:09 +0200, Jacob Carlborg d...@me.com wrote:
Yes, convert the first code point to a wchar and then throw if there's
more the one character in the string.
Not tested, and I might be wrong, but 'to!' should work between dchar
and wchar, no?
wchar to_wchar(string s) {
auto c = s.front;
s.popFront();
assert (s.empty);
return to!wchar(c);
}
Ok, thanks.
--
/Jacob Carlborg
Re: gives an empty string, while .idup gives null
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on strings :-)
Bye,
bearophile
GG bug? (OS X Lion, DMD 2.054)
I upgraded from OS X Snow Leopard to Lion recently (on a 32-bit iMac),
and when I tried to run my D code afterward, I suddenly ran into all
kinds of interesting problems (lots of failed assertions in my tests,
and bus errors in my actual runs...). Still cleaning stuff up, but I've
isolated at least one thing that seems to be a bug, and that wasn't
there before I upgraded.
Now, I upgraded from DMD 2.052 to 2.054 before doing any extensive
debugging, so I'm not 100% sure this specific problem was there in
2.052 as well, but I *think* so (i.e., making the switch to Lion the
triggering factor).
Anyway, here's some code:
import std.exception, core.memory;
class Foo {
bool bar;
}
void main() {
auto f = new Foo;
f.bar = true;
//GC.collect();
enforce(f.bar);
}
Works well, unless you uncomment the GC call, in which case a bus error
occurs (at least for me). Seems the collector is a bit over-eager...?
--
Magnus Lie Hetland
http://hetland.org
Re: GG bug? (OS X Lion, DMD 2.054)
Note that an explicit call to GC.collect isn't necessary. Whenever collection occurs, the collectors seems rather indiscriminate, collecting things it shouldn't, resulting in bus errors. When I disable the GC, my code runs just fine. (My production code, that is. There are still mysterious, probably Lion-related, bugs in my test suite...) -- Magnus Lie Hetland http://hetland.org
Re: gives an empty string, while .idup gives null
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this difference.
So... Is it a bug?
Re: GG bug? (OS X Lion, DMD 2.054)
On 8/3/11 4:07 PM, Magnus Lie Hetland wrote: I upgraded from OS X Snow Leopard to Lion recently (on a 32-bit iMac), and when I tried to run my D code afterward, I suddenly ran into all kinds of interesting problems (lots of failed assertions in my tests, and bus errors in my actual runs...). This seems to be exactly same problem I reported to the NG some days ago. It is caused by ASLR being enabled for 32bit applications on Lion too, and kennytm is to be credited for tracking this down to a fixed stack bottom in the druntime code: https://github.com/D-Programming-Language/druntime/pull/43. The fix has already been merged into master, please use that for OS X development until the next DMD release. David
Re: gives an empty string, while .idup gives null
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this difference.
So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
Re: NaCl stable ABI
Peter Alexander wrote: If D were usable in NaCl that would be a huge selling point for the language. Well, let's set aside my personal things and see how this might be done. Based on what I've read so far, it actually sounds easy enough, codegen wise. It might be possible to drop gdc into their hacked up gcc backend and have it work with minimal effort. Or, changing dmd's backend to emit code for it might not be hard either. It looks like it'd just have to align jumps, which should be as simple as padding labels with some nops. The bigger difficulty I suspect will be porting the runtime... but, since it builds on C in a lot of places, that might be simple too. I can't find more details on what's needed to happen to the compilers, but I'm really thinking it won't be very difficult to make it happen.
Re: gives an empty string, while .idup gives null
On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this difference.
So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
I don't know if it's a bug or not. The string _was_ duped. assert(s == )
passes. So, as far as equality goes, they're equal, and they don't point to
the same memory. Now, you'd think that the new string would be just empty
rather than null, but whether it's a bug or not depends exactly on what dup
and idup are supposed to do with regards to null. It's probably just a side
effect of how dup and idup are implemented rather than it being planned one way
or the other. I don't know if it matters or not though. In general, I don't
like the conflation of null and empty, but is this particular case, you _do_
get a string which is equal to the original and which doesn't point to the
same memory. So, I don't know whether this should be considered a bug or not.
It depends on what dup and idup are ultimately supposed to do.
- Jonathan M Davis
Re: Hexadecimal string to integer
On 3/08/2011 2:32, Johann MacDonagh wrote: On 8/2/2011 8:17 PM, Stijn Herreman wrote: std.conv does not support conversion from a hexadecimal string to an integer. Is there a technical reason for this limitation? This is the best I could do, can it be improved still? int i = to!int(parse!float(0x1ap0)); parse!int(1a, 16); I tried multiple combinations but not that one, thanks.
Re: gives an empty string, while .idup gives null
On 03.08.2011 18:18, Jonathan M Davis wrote:
On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this difference.
So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
I don't know if it's a bug or not. The string _was_ duped. assert(s == )
passes. So, as far as equality goes, they're equal, and they don't point to
the same memory. Now, you'd think that the new string would be just empty
rather than null, but whether it's a bug or not depends exactly on what dup
and idup are supposed to do with regards to null. It's probably just a side
effect of how dup and idup are implemented rather than it being planned one way
or the other. I don't know if it matters or not though. In general, I don't
like the conflation of null and empty, but is this particular case, you _do_
get a string which is equal to the original and which doesn't point to the
same memory. So, I don't know whether this should be considered a bug or not.
It depends on what dup and idup are ultimately supposed to do.
- Jonathan M Davis
I would think it's a bug, but strings doesn't quite behave as regular
references anyway...
But why should dup/idup change the semantics of the array?
void main() {
// A null string or empty string works as expected
string s1;
assert(s1 is null);
assert(s1.ptr is null);
assert(s1 == ); // We can check for empty even if it's
null, and it's equal to
assert(s1.length== 0); // ...and length even if it's null
s1 = ;
assert(s1 !is null);
assert(s1.ptr !is null);
assert(s1.length== 0);
assert(s1 == );
// the same applies to null mutable arrays
char[] s2;
assert(s2 is null);
assert(s2.ptr is null);
assert(s2 == );
assert(s2.length== 0);
// but with .dup/.idup things is different!
s2 = .dup;
//assert(s2 !is null); // fails
//assert(s2.ptr !is null); // fails
assert(s2.length== 0); // but... s2 is null..?
assert(s2 == );
assert(s2 == s1);
}
Weird timing issue with Thread.sleep
Take a look at this:
import std.stdio;
import core.thread;
void main()
{
foreach (x; 0 .. 1000)
{
Thread.sleep(dur!(usecs)(999));
writeln(x);
}
foreach (x; 0 .. 1000)
{
Thread.sleep(dur!(usecs)(1000));
writeln(x);
}
}
Compile and run it. The first foreach loop ends in an instant, while
the second one takes much much longer to finish, which is puzzling
since I've only increased the sleep while for a single microsecond.
What's going on?
Re: Weird timing issue with Thread.sleep
s/sleep while/sleep value
Re: gives an empty string, while .idup gives null
On 03.08.2011 18:18, Jonathan M Davis wrote:
On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this difference.
So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
I don't know if it's a bug or not. The string _was_ duped. assert(s ==
) passes. So, as far as equality goes, they're equal, and they don't
point to the same memory. Now, you'd think that the new string would be
just empty rather than null, but whether it's a bug or not depends
exactly on what dup and idup are supposed to do with regards to null.
It's probably just a side effect of how dup and idup are implemented
rather than it being planned one way or the other. I don't know if it
matters or not though. In general, I don't like the conflation of null
and empty, but is this particular case, you _do_ get a string which is
equal to the original and which doesn't point to the same memory. So, I
don't know whether this should be considered a bug or not. It depends on
what dup and idup are ultimately supposed to do.
- Jonathan M Davis
I would think it's a bug, but strings doesn't quite behave as regular
references anyway...
But why should dup/idup change the semantics of the array?
void main() {
// A null string or empty string works as expected
string s1;
assert(s1 is null);
assert(s1.ptr is null);
assert(s1 == ); // We can check for empty even if it's
null, and it's equal to
assert(s1.length == 0); // ...and length even if it's null
s1 = ;
assert(s1 !is null);
assert(s1.ptr !is null);
assert(s1.length == 0);
assert(s1 == );
// the same applies to null mutable arrays
char[] s2;
assert(s2 is null);
assert(s2.ptr is null);
assert(s2 == );
assert(s2.length == 0);
// but with .dup/.idup things is different!
s2 = .dup;
//assert(s2 !is null); // fails
//assert(s2.ptr !is null); // fails
assert(s2.length == 0); // but... s2 is null..?
assert(s2 == );
assert(s2 == s1);
}
If you look at the spec ( http://d-programming-language.org/arrays.html ), it
says:
dup: Create a dynamic array of the same size and copy the contents of the
array into it.
idup: Create a dynamic array of the same size and copy the contents of the
array into it. The copy is typed as being immutable. D 2.0 only
This is _exactly_ what dup and idup are doing. You get a new array with the
exact same size and contents. null doesn't factor into it at all. So, per the
spec, there's no bug here at all. dup and idup promise _nothing_ with regards
to null.
It may be that it would be better if dup and idup returned an array which was
null if the original was null, and that would also be within the spec, but
what dup and idup do at the moment _does_ follow the spec.
So, feel free to file a bug report on it. Maybe it'll get changed, but the
current behavior follows the spec. And given how arrays don't generally treat
empty and null as being different, I wouldn't really expect an array to stay
null if you do _anything_ to it other than simply pass it around or check its
value. In this case, you're creating a new array, and D just doesn't generally
care about null vs empty when it comes to arrays. I wouldn't argue that that's
a good thing (because I don't really think that it is), but because of that,
you can't really expect much to treat null and empty as being different. And
in this particular case, it's not only debatable as to whether it matters, but
the current behavior is completely within the spec.
- Jonathan M Davis
Re: gives an empty string, while .idup gives null
On Wed, 03 Aug 2011 06:35:08 -0400, simendsjo simend...@gmail.com wrote:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
An empty string manifest constant (i.e. string literal) still must have a
valid pointer, because it's mandated that the string have a zero byte
appended to it. This is so you can pass it to C functions which expect
null-terminated strings.
So essentially, there is a '\0' in memory, and points to that character
with a length of 0
However, idup calls a runtime function which *purposely* asks to make a
copy. However, it's *NOT* required to copy the 'zero after the string'
part.
The implementation, knowing that a null array is equivalent to an empty
array, is going to return null to avoid the performance penalty of
allocating a block that won't be used. If you append, it will simply
allocate a block as needed.
I see no reason the runtime should waste cycles or a perfectly good
16-byte buffer to give you an empty array.
Definitely functions as designed, not a bug. If you would like different
behavior, you are going to have to have a really really good use case to
get this changed.
-Steve
Re: Weird timing issue with Thread.sleep
On Wed, 03 Aug 2011 13:14:50 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
Take a look at this:
import std.stdio;
import core.thread;
void main()
{
foreach (x; 0 .. 1000)
{
Thread.sleep(dur!(usecs)(999));
writeln(x);
}
foreach (x; 0 .. 1000)
{
Thread.sleep(dur!(usecs)(1000));
writeln(x);
}
}
Compile and run it. The first foreach loop ends in an instant, while
the second one takes much much longer to finish, which is puzzling
since I've only increased the sleep while for a single microsecond.
What's going on?
I can only imagine that the cause is the implementation is using an OS
function that only supports millisecond sleep resolution. So essentially
it's like sleeping for 0 or 1 millisecond. However, without knowing your
OS, it's hard to say what's going on. On my linux install, the timing
seems equivalent.
-Steve
Re: Weird timing issue with Thread.sleep
That could be the reason. I'm testing on Windows. I was using sleep() as a quick hack around slowing down the framerate of an OpenGL display. There are better way to do this but I didn't have time to find a proper solution yet.
Re: Weird timing issue with Thread.sleep
On 2011-08-03 19:42, Andrej Mitrovic wrote: That could be the reason. I'm testing on Windows. I was using sleep() as a quick hack around slowing down the framerate of an OpenGL display. There are better way to do this but I didn't have time to find a proper solution yet. Why would you want to slow down framerate? -- /Jacob Carlborg
Re: gives an empty string, while .idup gives null
On 03.08.2011 19:15, Jonathan M Davis wrote:
On 03.08.2011 18:18, Jonathan M Davis wrote:
On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this difference.
So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
I don't know if it's a bug or not. The string _was_ duped. assert(s ==
) passes. So, as far as equality goes, they're equal, and they don't
point to the same memory. Now, you'd think that the new string would be
just empty rather than null, but whether it's a bug or not depends
exactly on what dup and idup are supposed to do with regards to null.
It's probably just a side effect of how dup and idup are implemented
rather than it being planned one way or the other. I don't know if it
matters or not though. In general, I don't like the conflation of null
and empty, but is this particular case, you _do_ get a string which is
equal to the original and which doesn't point to the same memory. So, I
don't know whether this should be considered a bug or not. It depends on
what dup and idup are ultimately supposed to do.
- Jonathan M Davis
I would think it's a bug, but strings doesn't quite behave as regular
references anyway...
But why should dup/idup change the semantics of the array?
void main() {
// A null string or empty string works as expected
string s1;
assert(s1 is null);
assert(s1.ptr is null);
assert(s1 == ); // We can check for empty even if it's
null, and it's equal to
assert(s1.length == 0); // ...and length even if it's null
s1 = ;
assert(s1 !is null);
assert(s1.ptr !is null);
assert(s1.length == 0);
assert(s1 == );
// the same applies to null mutable arrays
char[] s2;
assert(s2 is null);
assert(s2.ptr is null);
assert(s2 == );
assert(s2.length == 0);
// but with .dup/.idup things is different!
s2 = .dup;
//assert(s2 !is null); // fails
//assert(s2.ptr !is null); // fails
assert(s2.length == 0); // but... s2 is null..?
assert(s2 == );
assert(s2 == s1);
}
If you look at the spec ( http://d-programming-language.org/arrays.html ), it
says:
dup: Create a dynamic array of the same size and copy the contents of the
array into it.
idup: Create a dynamic array of the same size and copy the contents of the
array into it. The copy is typed as being immutable. D 2.0 only
This is _exactly_ what dup and idup are doing. You get a new array with the
exact same size and contents. null doesn't factor into it at all. So, per the
spec, there's no bug here at all. dup and idup promise _nothing_ with regards
to null.
It may be that it would be better if dup and idup returned an array which was
null if the original was null, and that would also be within the spec, but
what dup and idup do at the moment _does_ follow the spec.
So, feel free to file a bug report on it. Maybe it'll get changed, but the
current behavior follows the spec. And given how arrays don't generally treat
empty and null as being different, I wouldn't really expect an array to stay
null if you do _anything_ to it other than simply pass it around or check its
value. In this case, you're creating a new array, and D just doesn't generally
care about null vs empty when it comes to arrays. I wouldn't argue that that's
a good thing (because I don't really think that it is), but because of that,
you can't really expect much to treat null and empty as being different. And
in this particular case, it's not only debatable as to whether it matters, but
the current behavior is completely within the spec.
- Jonathan M Davis
Schveighoffer also states it is as designed.
But it really doesn't behave as one (at least I) would expect.
So in essence (as bearophile says), is null should not be used on arrays.
I was bitten by a bug because of this, and used intead of .idup to
avoid this, but given D doesn't distinguish between empty and null
arrays, this doesn't feel very safe now..
In the code in question I have a lazy initialized string. The problem is
that I would see if it has been initialized, but an empty string is also
a valid value. Because I shouldn't check for null, I now have to add
another field to the struct to see if the array has been initialized.
This feels like a really suboptimal solution.
Re: Weird timing issue with Thread.sleep
On 8/3/11, Jacob Carlborg d...@me.com wrote:
Why would you want to slow down framerate?
Because the examples were written in the 90s and CPUs and graphic
cards are so fast these days that the old code runs at an enormous
framerate.
Anyway, after a bit of googling I've found a solution:
enum float FPS = 60.0;
auto t_prev = Clock.currSystemTick();
while (!done)
{
auto t = Clock.currSystemTick();
if ((t - t_prev).usecs (1_000_000.0 / FPS))
{
t_prev = t;
DrawGLScene();
}
SwapBuffers(hDC);
}
I can also use currAppTick() which is similar.
I'm using enum float instead of just enum FPS because creeping
integer truncation bugs lurk into my code all the time. i.e. I end up
having an expression like var1 / var evaluate to an integer instead
of a float because a variable was declared as an integer.
Here's what I mean:
enum FPS = 60;
void main()
{
auto fraction = (1 / FPS); // woops, actually returns 0
}
Using enum float FPS = 60; fixes this. It's a very subtle thing and
easily introducable as a bug.
Re: Weird timing issue with Thread.sleep
On Wed, 03 Aug 2011 13:42:34 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: That could be the reason. I'm testing on Windows. Windows only supports millisecond resolution. A valid solution to this is probably to have anything 0 and 1 ms sleep for at least 1ms. Or maybe it can round up to the next ms. For now, you can simply sleep for 1ms. -Steve
Re: gives an empty string, while .idup gives null
On Wed, 03 Aug 2011 06:35:08 -0400, simendsjo simend...@gmail.com wrote:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
An empty string manifest constant (i.e. string literal) still must have a
valid pointer, because it's mandated that the string have a zero byte
appended to it. This is so you can pass it to C functions which expect
null-terminated strings.
So essentially, there is a '\0' in memory, and points to that character
with a length of 0
However, idup calls a runtime function which *purposely* asks to make a
copy. However, it's *NOT* required to copy the 'zero after the string'
part.
The implementation, knowing that a null array is equivalent to an empty
array, is going to return null to avoid the performance penalty of
allocating a block that won't be used. If you append, it will simply
allocate a block as needed.
I see no reason the runtime should waste cycles or a perfectly good
16-byte buffer to give you an empty array.
Definitely functions as designed, not a bug. If you would like different
behavior, you are going to have to have a really really good use case to
get this changed.
Given that if you really wanted the duped string to be empty instead of null,
it wouldn't be very hard to write a wrapper function for dup which did that,
I'd be _very_ surprised if you could find a use case where dup should allocate
for an empty string.
I don't generally like the fact that D tends to conflate null and empty, but
you're creating a new array here. It's not at all surprising if it ends up
null if it has no elements in it. In general though, you need to be fairly
careful about where you rely on the difference between empty and null. If any
kind of memory allocation occurs to an array and its length is 0, it's pretty
much free game as to whether it's empty or null.
- Jonathan M Davis
Re: gives an empty string, while .idup gives null
On 03.08.2011 19:15, Jonathan M Davis wrote:
On 03.08.2011 18:18, Jonathan M Davis wrote:
On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a
difference between null and empty, and avoiding this is not
necessarily easy or even wanted.
I couldn't find anything in the specification stating this
difference. So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
I don't know if it's a bug or not. The string _was_ duped. assert(s ==
) passes. So, as far as equality goes, they're equal, and they don't
point to the same memory. Now, you'd think that the new string would be
just empty rather than null, but whether it's a bug or not depends
exactly on what dup and idup are supposed to do with regards to null.
It's probably just a side effect of how dup and idup are implemented
rather than it being planned one way or the other. I don't know if it
matters or not though. In general, I don't like the conflation of null
and empty, but is this particular case, you _do_ get a string which is
equal to the original and which doesn't point to the same memory. So, I
don't know whether this should be considered a bug or not. It depends
on what dup and idup are ultimately supposed to do.
- Jonathan M Davis
I would think it's a bug, but strings doesn't quite behave as regular
references anyway...
But why should dup/idup change the semantics of the array?
void main() {
// A null string or empty string works as expected
string s1;
assert(s1 is null);
assert(s1.ptr is null);
assert(s1 == ); // We can check for empty even if it's
null, and it's equal to
assert(s1.length == 0); // ...and length even if it's null
s1 = ;
assert(s1 !is null);
assert(s1.ptr !is null);
assert(s1.length == 0);
assert(s1 == );
// the same applies to null mutable arrays
char[] s2;
assert(s2 is null);
assert(s2.ptr is null);
assert(s2 == );
assert(s2.length == 0);
// but with .dup/.idup things is different!
s2 = .dup;
//assert(s2 !is null); // fails
//assert(s2.ptr !is null); // fails
assert(s2.length == 0); // but... s2 is null..?
assert(s2 == );
assert(s2 == s1);
}
If you look at the spec ( http://d-programming-language.org/arrays.html
), it says:
dup: Create a dynamic array of the same size and copy the contents of
the array into it.
idup: Create a dynamic array of the same size and copy the contents of
the array into it. The copy is typed as being immutable. D 2.0 only
This is _exactly_ what dup and idup are doing. You get a new array with
the exact same size and contents. null doesn't factor into it at all.
So, per the spec, there's no bug here at all. dup and idup promise
_nothing_ with regards to null.
It may be that it would be better if dup and idup returned an array which
was null if the original was null, and that would also be within the
spec, but what dup and idup do at the moment _does_ follow the spec.
So, feel free to file a bug report on it. Maybe it'll get changed, but
the current behavior follows the spec. And given how arrays don't
generally treat empty and null as being different, I wouldn't really
expect an array to stay null if you do _anything_ to it other than
simply pass it around or check its value. In this case, you're creating
a new array, and D just doesn't generally care about null vs empty when
it comes to arrays. I wouldn't argue that that's a good thing (because I
don't really think that it is), but because of that, you can't really
expect much to treat null and empty as being different. And in this
particular case, it's not only debatable as to whether it matters, but
the current behavior is completely within the spec.
- Jonathan M Davis
Schveighoffer also states it is as designed.
But it really doesn't behave as one (at least I) would expect.
So in essence (as bearophile says), is null should not be used on arrays.
I was bitten by a bug because of this, and used intead of .idup to
avoid this, but given D doesn't distinguish between empty and null
arrays, this doesn't feel very safe now..
In the code in question I have a lazy initialized string. The problem is
that I would see if it has been initialized, but an empty string is also
a valid value. Because I shouldn't check for null, I now have to add
another field to
Re: gives an empty string, while .idup gives null
On Wed, 03 Aug 2011 14:26:54 -0400, simendsjo simend...@gmail.com wrote:
Schveighoffer also states it is as designed.
But it really doesn't behave as one (at least I) would expect.
So in essence (as bearophile says), is null should not be used on
arrays.
I was bitten by a bug because of this, and used intead of .idup to
avoid this, but given D doesn't distinguish between empty and null
arrays, this doesn't feel very safe now..
I would recommend against depending on the difference between null and
not-null-but-empty arrays. But in any case, .idup is mainly pointless,
there is never a need to idup a string, since it's already immutable (and
therefore can be passed wherever you need it).
In the code in question I have a lazy initialized string. The problem is
that I would see if it has been initialized, but an empty string is also
a valid value. Because I shouldn't check for null, I now have to add
another field to the struct to see if the array has been initialized.
This feels like a really suboptimal solution.
Where is it that you need to use idup? I think you may be using that
without need (or if you are using code that violates immutability, that
code is incorrect), but I don't know what your code looks like so I might
be wrong.
In any case, there may be a better way to do what you want, without the
extra field.
At the very least, here is a function that can help you:
myIdup(string s)
{
return s.length == 0 ? : s.idup;
}
Note that this kind of thing *ONLY* works for strings, because string
literals are not null. For normal arrays, I wouldn't expect this to work.
-Steve
Re: gives an empty string, while .idup gives null
On 03.08.2011 22:26, simendsjo wrote:
On 03.08.2011 19:15, Jonathan M Davis wrote:
On 03.08.2011 18:18, Jonathan M Davis wrote:
On Thursday 04 August 2011 00:27:12 Mike Parker wrote:
On 8/3/2011 11:23 PM, simendsjo wrote:
On 03.08.2011 15:49, bearophile wrote:
simendsjo:
void main() {
assert(is(typeof() == typeof(.idup))); // both is
immutable(char)[]
assert( !is null);
assert(.idup !is null); // fails - s is null. Why?
}
I think someone has even suggested to statically forbid is
null on
strings :-)
Bye,
bearophile
How should I test for null if not with is null? There is a
difference
between null and empty, and avoiding this is not necessarily easy or
even wanted.
I couldn't find anything in the specification stating this
difference.
So... Is it a bug?
This is apparently a bug. Somehow, the idup is clobbering the
pointer.
You can see it more clearly here:
void main()
{
assert(.ptr);
auto s = .idup;
assert(s.ptr); // boom!
}
I don't know if it's a bug or not. The string _was_ duped. assert(s ==
) passes. So, as far as equality goes, they're equal, and they don't
point to the same memory. Now, you'd think that the new string
would be
just empty rather than null, but whether it's a bug or not depends
exactly on what dup and idup are supposed to do with regards to null.
It's probably just a side effect of how dup and idup are implemented
rather than it being planned one way or the other. I don't know if it
matters or not though. In general, I don't like the conflation of null
and empty, but is this particular case, you _do_ get a string which is
equal to the original and which doesn't point to the same memory.
So, I
don't know whether this should be considered a bug or not. It
depends on
what dup and idup are ultimately supposed to do.
- Jonathan M Davis
I would think it's a bug, but strings doesn't quite behave as regular
references anyway...
But why should dup/idup change the semantics of the array?
void main() {
// A null string or empty string works as expected
string s1;
assert(s1 is null);
assert(s1.ptr is null);
assert(s1 == ); // We can check for empty even if it's
null, and it's equal to
assert(s1.length == 0); // ...and length even if it's null
s1 = ;
assert(s1 !is null);
assert(s1.ptr !is null);
assert(s1.length == 0);
assert(s1 == );
// the same applies to null mutable arrays
char[] s2;
assert(s2 is null);
assert(s2.ptr is null);
assert(s2 == );
assert(s2.length == 0);
// but with .dup/.idup things is different!
s2 = .dup;
//assert(s2 !is null); // fails
//assert(s2.ptr !is null); // fails
assert(s2.length == 0); // but... s2 is null..?
assert(s2 == );
assert(s2 == s1);
}
If you look at the spec (
http://d-programming-language.org/arrays.html ), it
says:
dup: Create a dynamic array of the same size and copy the contents
of the
array into it.
idup: Create a dynamic array of the same size and copy the
contents of the
array into it. The copy is typed as being immutable. D 2.0 only
This is _exactly_ what dup and idup are doing. You get a new array
with the
exact same size and contents. null doesn't factor into it at all. So,
per the
spec, there's no bug here at all. dup and idup promise _nothing_ with
regards
to null.
It may be that it would be better if dup and idup returned an array
which was
null if the original was null, and that would also be within the
spec, but
what dup and idup do at the moment _does_ follow the spec.
So, feel free to file a bug report on it. Maybe it'll get changed,
but the
current behavior follows the spec. And given how arrays don't
generally treat
empty and null as being different, I wouldn't really expect an array
to stay
null if you do _anything_ to it other than simply pass it around or
check its
value. In this case, you're creating a new array, and D just doesn't
generally
care about null vs empty when it comes to arrays. I wouldn't argue
that that's
a good thing (because I don't really think that it is), but because
of that,
you can't really expect much to treat null and empty as being
different. And
in this particular case, it's not only debatable as to whether it
matters, but
the current behavior is completely within the spec.
- Jonathan M Davis
Schveighoffer also states it is as designed.
But it really doesn't behave as one (at least I) would expect.
So in essence (as bearophile says), is null should not be used on
arrays.
I was bitten by a bug because of this, and used intead of .idup
to avoid this, but given D doesn't distinguish between empty and null
arrays, this doesn't feel very safe now..
In the code in question I have a lazy initialized string. The problem
is that I would see if it has been initialized, but an empty string is
also a valid value. Because I shouldn't check for null, I now have to
add another field to the struct to see if the array has been
initialized. This feels like a really suboptimal solution.
length works even for null arrays and returns 0.
Re: Weird timing issue with Thread.sleep
On 8/3/11, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
if ((t - t_prev).usecs (1_000_000.0 / FPS))
{
t_prev = t;
DrawGLScene();
}
SwapBuffers(hDC);
My mistake here, SwapBuffers belongs inside the if body, there's an
unrelated keyboard bug that made me push it there but I've found
what's causing it. Anyway this is offtopic.
Re: NaCl stable ABI
Peter Alexander peter.alexander...@gmail.com wrote in message news:j1asck$81d$1...@digitalmars.com... The games industry has been crying out for something like NaCl for a long time. It is exactly what we want: - Ability to launch games within browser without a plugin download - Platform independent ABI - No f*cking Javascript (performance will never match C++) - Safe (no need for end users to worry) JavaScript for high-quality games is a non-starter. It's too slow. Browser for high-quality games is a non-starter. What idiot would rather play a game inside a damn browser? You could have all the speed in the world, and the browser would still be completely unsuitable for anything beyond dinky little popcap-style shit. We've had Quake playable in the browser for awhile now: and who the hell actually plays it that way? And who actually wants to? It's nothing but a Gee whiz, look what we can do in a browser! dick-measuring contest. The whole premise of games in a browser is idiotic. What is needed is 0install and an OS-level security model that's actually good, or something along those lines. None of this Google-mentality pretending the browser is a platform bullshit. The browser is a complete strawman here; cramming games into it is solving the wrong issue. It's exactly the old web-app trend all over again: People thought web-based stuff made deployment easier (in a few different ways: not all of which were actually true) and thought that it was safe/secure (which, frankly, has never really been true). So instead of *soving those issues* by putting their focus on improving deployment of *real* apps (via something like 0install) and pushing for improved OS security models (via something like selinux maybe? Seriously how much push is actualyl behind that? Not nearly enough), the morons started cramming apps into the browser (well, that and Valve's Steam abomination) and consequently fucked up computing while *still* not solving half the issues they thought they were solving anyway. If the games industry is crying out for faster in-browser computing, then what they're asking for is a faster horse. But it figures: I mean this is the stupid motherfuck industry that's spent the last ten years completely ignoring who they're *supposed* to be (***VIDEOGAME*** developers) and instead running around as a bunch of goddamn graphics-whore, storytime, Pixar/Hollywood wannabe, IP-fellatiatng, fucking posers. Especially the absolutely disgraceful graphics-whore and Pixar/Hollywood wannabe parts. Those two in particular can't be over-emphasized.
Re: NaCl stable ABI
Nick Sabalausky a@a.a wrote in message news:j1cb3a$2qe7$1...@digitalmars.com... I mean this is the stupid motherfuck industry that's spent the last ten years completely ignoring who they're *supposed* to be (***VIDEOGAME*** developers) and instead running around as a bunch of goddamn graphics-whore, storytime, Pixar/Hollywood wannabe, IP-fellatiatng, fucking posers. Especially the absolutely disgraceful graphics-whore and Pixar/Hollywood wannabe parts. Those two in particular can't be over-emphasized. Oh, and how could I forget the other major evidence of the industry's asinine mentality: Seriously, this indistry is holding onto DRM and closed-platforms about 10x harder than the *music* industry, for fuck's sake. And the long-hated music industry has never done region coding - another thing the so-called videogame industry (really the hollywood-wannabe industry, like I said) is keeping a deathgrip on.
Re: NaCl stable ABI
I liked QLive before they forced 30 second commercials on server joins for non-subscribers. :( It was cool being able to casually browse to other tabs, then going back to qlive and finding a game. UT for example had an integrated IRC client, but people preferred using mIRC and having a ut://123.123.123.123 protocol they can just click on to join a game. Don't forget having to minimize all the time to chat to someone on MSN while playing a game. So there are some benefits to having a browser based interface for a game, imo.
Re: NaCl stable ABI
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.2097.1312408853.14074.digitalmars-d-le...@puremagic.com... I liked QLive before they forced 30 second commercials on server joins for non-subscribers. :( It was cool being able to casually browse to other tabs, then going back to qlive and finding a game. UT for example had an integrated IRC client, but people preferred using mIRC and having a ut://123.123.123.123 protocol they can just click on to join a game. Don't forget having to minimize all the time to chat to someone on MSN while playing a game. So there are some benefits to having a browser based interface for a game, imo. There is nothing you've mentioned that can't be (better) fixed without cramming everything into a browser.
[Issue 5239] optimizer misreports an used before set error
http://d.puremagic.com/issues/show_bug.cgi?id=5239
--- Comment #1 from Brad Roberts bra...@puremagic.com 2011-08-03 00:06:43 PDT
---
Part of the test case for bug 6293 triggers this bug when built with -O. See
runnable/xtet46.d, test6293(). The buggy part is hidden behind version(none).
class C6293 {
C6293 token;
}
void f6293(in C6293[] a) pure {
auto x0 = a[0].token;
assert(x0 is a[0].token.token.token);
assert(x0 is (x0).token);
version(none) {
auto p1 = x0 + 1;
assert(x0 is (p1 - 1).token);
}
int c = 0;
assert(x0 is a[c].token);
}
void test6293() {
auto x = new C6293;
x.token = x;
f6293([x]);
}
See also:
https://github.com/D-Programming-Language/dmd/pull/243
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6432] New: Compilation doesn't terminate on a recursive mixin error
http://d.puremagic.com/issues/show_bug.cgi?id=6432
Summary: Compilation doesn't terminate on a recursive mixin
error
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha samu...@voliacable.com 2011-08-03 02:40:28
PDT ---
mixin template Foo(A...)
{
mixin Foo!(Bar, A);
}
mixin Foo!();
test.d(5): Error: undefined identifier Bar
test.d(5): Error: undefined identifier Bar
test.d(5): Error: undefined identifier Bar
...
The error will be printed repeatedly until the maximum recursion depth is
reached.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6365] AutoTupleDeclaration
http://d.puremagic.com/issues/show_bug.cgi?id=6365 --- Comment #28 from bearophile_h...@eml.cc 2011-08-03 04:35:25 PDT --- See also the discussion here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=141640 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5660] yield syntax sugar
http://d.puremagic.com/issues/show_bug.cgi?id=5660
--- Comment #2 from bearophile_h...@eml.cc 2011-08-03 04:48:48 PDT ---
More programming in D shows me that syntax sugar like this one will be very
useful to me:
yield(int) foo() {
yield(1);
}
So, is it possible to automatically convert such kind of code into a Range
(istead of opApply and fibers)?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5660] yield syntax sugar
http://d.puremagic.com/issues/show_bug.cgi?id=5660
--- Comment #3 from bearophile_h...@eml.cc 2011-08-03 05:08:13 PDT ---
Just as an example, this is Python2.6 code:
def process((i, j), a, b):
if i == 0: yield (a, j)
if j == 0: yield (i, b)
if i == a: yield (0, j)
if j == b: yield (i, 0)
if j != b: yield (i + j - b, b) if (b i + j) else (0, i + j)
if i != a: yield (a, i + j - a) if (a i + j) else (i + j, 0)
And this is how ShedSkin compiles it to C++ (a bit edited):
class __gen_process : public __itertuple2int, int * {
public:
tuple2int, int *__2, *__3;
int a, b, i, j;
int __last_yield;
__gen_process(tuple2int, int *__2,int a,int b) {
this-__2 = __2;
this-a = a;
this-b = b;
__last_yield = -1;
}
tuple2int, int * __get_next() {
switch(__last_yield) {
case 0: goto __after_yield_0;
case 1: goto __after_yield_1;
case 2: goto __after_yield_2;
case 3: goto __after_yield_3;
case 4: goto __after_yield_4;
case 5: goto __after_yield_5;
default: break;
}
if ((i==0)) {
__last_yield = 0;
__result = (new tuple2int, int(2,a,j));
return __result;
__after_yield_0:;
}
if ((j==0)) {
__last_yield = 1;
__result = (new tuple2int, int(2,i,b));
return __result;
__after_yield_1:;
}
if ((i==a)) {
__last_yield = 2;
__result = (new tuple2int, int(2,0,j));
return __result;
__after_yield_2:;
}
if ((j==b)) {
__last_yield = 3;
__result = (new tuple2int, int(2,i,0));
return __result;
__after_yield_3:;
}
if ((j!=b)) {
__last_yield = 4;
__result = (((b(i+j)))?((new tuple2int, int(2,((i+j)-b),b))):((new
tuple2int, int(2,0,(i+j);
return __result;
__after_yield_4:;
}
if ((i!=a)) {
__last_yield = 5;
__result = (((a(i+j)))?((new tuple2int, int(2,a,((i+j)-a:((new
tuple2int, int(2,(i+j),0;
return __result;
__after_yield_5:;
}
__stop_iteration = true;
}
};
__itertuple2int, int * *process(tuple2int, int *__2, int a, int b) {
return new __gen_process(__2,a,b);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6433] New: Meta-Bug AA type propagation
http://d.puremagic.com/issues/show_bug.cgi?id=6433 Summary: Meta-Bug AA type propagation Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2011-08-03 05:44:10 PDT --- Bug case to gather issues related to type propagation of internal associative arrays to instances of AssociativeArray!(Key, Value). Type properties are erroneously taken from the template instance. .init, .stringof, .mangleof, .offsetof, .alignof issue 3962, issue 5683, issue 5029 AssocArrayLiteralExp can't handle type propagation. issue 5675 Deprecated delete aa[key] segfaults on x86_64. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5364] optimizer kills high dword of -1
http://d.puremagic.com/issues/show_bug.cgi?id=5364 --- Comment #3 from Ellery Newcomer ellery-newco...@utulsa.edu 2011-08-03 05:52:39 PDT --- I am still seeing this behavior on DMD32 2.054, Fedora 14 64 bit. I don't have internet access at home, so I can't test against DMD from git master. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6434] New: opDispatch must be considered before alias this.
http://d.puremagic.com/issues/show_bug.cgi?id=6434
Summary: opDispatch must be considered before alias this.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: g...@boloneum.com
--- Comment #0 from Gor Gyolchanyan g...@boloneum.com 2011-08-03 06:14:26 PDT
---
When a class or struct has an opDispatch and an alias this, the alias this is
considered first and a member access gives no such property error:
struct A
{
Variant i;
alias i this;
void opDispatch(string name)()
{
}
}
unittest
{
A a;
a.weird; // no property 'weird' for type 'VariantN!(maxSize)'
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6355] Template constructor cannot initialize non-mutable field
http://d.puremagic.com/issues/show_bug.cgi?id=6355 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||simend...@gmail.com --- Comment #3 from yebblies yebbl...@gmail.com 2011-08-04 00:37:22 EST --- *** Issue 6427 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6427] Templated ctor cannot set immutable member variables
http://d.puremagic.com/issues/show_bug.cgi?id=6427 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #3 from yebblies yebbl...@gmail.com 2011-08-04 00:37:22 EST --- *** This issue has been marked as a duplicate of issue 6355 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6233] Compiler lists wrong module in an expression error
http://d.puremagic.com/issues/show_bug.cgi?id=6233
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Severity|normal |major
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-08-03
09:32:16 PDT ---
Simplified test case:
foo.d:
import bar;
void main()
{
return TRUE;
}
bar.d:
enum TRUE = 1;
$ rdmd foo.d:
bar.d(1): Error: long has no effect in expression (1)
I'm raising the priority because it's extremely infuriating getting an error
message that points to a completely different module, making this bug hard to
track.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5790] Error: variable result used before set when -release -inline -O
http://d.puremagic.com/issues/show_bug.cgi?id=5790 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2011-08-03 09:58:41 PDT --- This is possibly related to: http://d.puremagic.com/issues/show_bug.cgi?id=5239 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6435] New: Regression (2.054) Cannot append to a string member of a struct in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=6435
Summary: Regression (2.054) Cannot append to a string member of
a struct in CTFE
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha samu...@voliacable.com 2011-08-03 11:19:10
PDT ---
struct S
{
string bar;
}
int foo()
{
S s;
s.bar = one; // compiles if this is commented out
s.bar ~= two;
return 0;
}
auto x = foo();
void main()
{
}
Error: s.bar ~= two cannot be evaluated at compile time
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5239] optimizer misreports an used before set error
http://d.puremagic.com/issues/show_bug.cgi?id=5239 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-08-03 17:13:21 PDT --- https://github.com/D-Programming-Language/dmd/commit/847abf5348b39b6b483cd11280b04d8590f722e5 https://github.com/D-Programming-Language/dmd/commit/12a19326129398af62da52dff86b9cf9f381d7dd -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3512] dchar iteration over string in CTFE fails
http://d.puremagic.com/issues/show_bug.cgi?id=3512 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2011-08-03 17:14:29 PDT --- https://github.com/D-Programming-Language/dmd/commit/9318dc44c3e9aa75907966b9fd122c0cc6700891 https://github.com/D-Programming-Language/dmd/commit/571661646ca420aa4c3fb348e86e35ed8faae624 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4021] [CTFE] AA rehash
http://d.puremagic.com/issues/show_bug.cgi?id=4021 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-08-03 17:15:06 PDT --- https://github.com/D-Programming-Language/dmd/commit/9318dc44c3e9aa75907966b9fd122c0cc6700891 https://github.com/D-Programming-Language/dmd/commit/571661646ca420aa4c3fb348e86e35ed8faae624 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6418] [CTFE] Cannot call a struct member function with name 'length'.
http://d.puremagic.com/issues/show_bug.cgi?id=6418 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2011-08-03 17:15:34 PDT --- https://github.com/D-Programming-Language/dmd/commit/9318dc44c3e9aa75907966b9fd122c0cc6700891 https://github.com/D-Programming-Language/dmd/commit/571661646ca420aa4c3fb348e86e35ed8faae624 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4375] Require explicit braces when 'else' is ambiguous
http://d.puremagic.com/issues/show_bug.cgi?id=4375
--- Comment #17 from bearophile_h...@eml.cc 2011-08-03 18:59:30 PDT ---
I've being hit by a dangling else bug in D, traslating this Python code:
def foo(sol):
global best
if is_solution(sol[-1]):
if best or len(sol) len(best):
best = list(sol)
else:
for next in alternatives(sol[-1]):
if next not in sol:
foo(sol + [next])
to the wrong D code:
void foo(Pair[] sol) {
if (isSolution(sol[$-1]))
if (!best.length || sol.length best.length)
best = sol.dup;
else
foreach (next; alternatives(sol[$-1]))
if (!canFind(sol, next))
foo(sol ~ [next]);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5728] rol in core.bitop
http://d.puremagic.com/issues/show_bug.cgi?id=5728 Adam D. Ruppe destructiona...@gmail.com changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #2 from Adam D. Ruppe destructiona...@gmail.com 2011-08-03 19:18:02 PDT --- I just want to say that dmd commit is fantastic. We got a little embarrassed by that in a discussion a couple weeks ago! Re bearophiles request: it probably doesn't need an intrinsic since the optimzation should let a plain library function do it just as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
