Re: [OT?] C compiler written form scratch in D
On 9 Dec 2014 07:00, Stefan Koch via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 8 December 2014 at 21:04:17 UTC, John wrote: On Monday, 8 December 2014 at 19:35:54 UTC, Stefan Koch wrote: think of them as beta quality! You may have to either pause when you need to cough and sneeze or just edit that out. I am interested in this topic but the horrible quality of audio video made me puke. Sorry. I will shoot the next videos when I am healthy again. I thought about writing the code beforehand, and then just go through and explain it. What do you think of that ? @ibuclaw You did not misshear, I really said that :( . I was referring I to the fact, that I do not parse uppercase letters atm. Probably should edit out such non-sense. Yah, my next question would have been: How do you intend to have a self hosted C compiler handwritten in pure D? :)
Re: [OT?] C compiler written form scratch in D
On 9 Dec 2014 00:50, deadalnix via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote: I want to do a C backend first. Building an LLVM Backand out of that is a small step. There is already a very popular C to C compiler out there. It is called cat, and come out of the box with any UNIX like system. Just so happens to be compatible for D to D compilation too. This tool is awesome!¿?¡
Re: [OT?] C compiler written form scratch in D
On Tuesday, 9 December 2014 at 08:10:14 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 9 Dec 2014 00:50, deadalnix via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote: I want to do a C backend first. Building an LLVM Backand out of that is a small step. There is already a very popular C to C compiler out there. It is called cat, and come out of the box with any UNIX like system. Just so happens to be compatible for D to D compilation too. This tool is awesome!¿?¡ cat is the fastest transcompiler I have ever seen!
Re: [OT?] C compiler written form scratch in D
On 2014-12-09 00:45:41 +, deadalnix said: On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote: I want to do a C backend first. Building an LLVM Backand out of that is a small step. There is already a very popular C to C compiler out there. It is called cat, and come out of the box with any UNIX like system. Any link? I tried to google it but it's such a generic word etc. no luck. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: [OT?] C compiler written form scratch in D
On 2014-12-07 19:13:41 +, Stefan Koch said: I'd like to announce that I am going to be writing a C-compiler in D. Without flex or bison or anything like that. Just pure handwritten D. Hi, how about using PEG for parsing etc.? IMO that would be a very good showcase for the power of PEG And D. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: [OT?] C compiler written form scratch in D
On Tuesday, 9 December 2014 at 10:54:22 UTC, Robert M. Münch wrote: On 2014-12-09 00:45:41 +, deadalnix said: On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote: Any link? I tried to google it but it's such a generic word etc. no luck. http://linux.die.net/man/1/cat It was a joke. Could also say notepad on Windows.
Re: [OT?] C compiler written form scratch in D
On Tuesday, 9 December 2014 at 10:55:24 UTC, Robert M. Münch wrote: On 2014-12-07 19:13:41 +, Stefan Koch said: I'd like to announce that I am going to be writing a C-compiler in D. Without flex or bison or anything like that. Just pure handwritten D. Hi, how about using PEG for parsing etc.? IMO that would be a very good showcase for the power of PEG And D. -- Robert M. Münch http://www.saphirion.com smarter | better | faster I will use a handwritten recursive decent parser. Since that is what I deem the easiest thing to do.
Re: [OT?] C compiler written form scratch in D
On Tuesday, 9 December 2014 at 10:54:22 UTC, Robert M. Münch wrote: On 2014-12-09 00:45:41 +, deadalnix said: On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote: I want to do a C backend first. Building an LLVM Backand out of that is a small step. There is already a very popular C to C compiler out there. It is called cat, and come out of the box with any UNIX like system. Any link? I tried to google it but it's such a generic word etc. no luck. -- Robert M. Münch http://www.saphirion.com smarter | better | faster That was a joke. http://unixhelp.ed.ac.uk/CGI/man-cgi?cat
Re: forum.dlang.org is now using DCaptcha
Hijacking this thread. Captcha is still not working on https :(
Re: D3
On Tuesday, 9 December 2014 at 05:04:35 UTC, Jeremy DeHaan wrote: On Tuesday, 9 December 2014 at 03:52:01 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 21:08:03 + Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Major version numbers are actually in the letter so we should go to E1. there was E language too: http://en.wikipedia.org/wiki/Amiga_E with only 26 letters it's hard to be original. i'm voting for using Japan or Chineese hieroglyphs, as there are plenty of them. For Japanese it would be ディ which is pronounced the same as the name of the letter D. For Chinese it would be 帝 which pronounces the same as 'D' and means Emperor. An interesting coincidence is that Walter also created the game Empire :-) source: I'm Chinese
Re: DIP69: problem with scope grammar - need a new keyword
On 8 December 2014 at 19:45, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: I thought I could make this work, but it's a problem. There are two meanings for scope when attached to a function: T func() scope; // the 'this' pointer is 'scope' scope T func(); // the function returns a 'scope' T I have some ideas, but don't particularly like any of them. But I don't want to bias things, so what ideas do you guys have? The solution is obvious; function should return scope(T) ;)
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: i can remember that too, but i prefer to have the things that i can logically deduce. i can deduce `usize`: ah, it's size. and it's unsigned. D tends to add 'u' for unsigned types and naming 'size' as 'size' is logical. so it must be 'usize'. hit! Size is unsigned for being positive. Why emphasize it again? 'u' prefix is for general purpose integers, size_t is a special purpose type for specific case of representing sizes, similar types are time_t, off_t and hash_t in a sense that representation can change, but purpose will remain the same.
Re: Any SIMD experts?
On Monday, 8 December 2014 at 16:44:37 UTC, Martin Nowak wrote: actually slowed down some GC benchmarks by 3%. The branch predictor had more trouble with the single branch because that resulted in a fifty-fifty chance. There is some correlation Consider rewriting the code to use non-branching comparison, i.e. use the condition test result directly in an expression or cmov.
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 08:26:18 + Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: i can remember that too, but i prefer to have the things that i can logically deduce. i can deduce `usize`: ah, it's size. and it's unsigned. D tends to add 'u' for unsigned types and naming 'size' as 'size' is logical. so it must be 'usize'. hit! Size is unsigned for being positive. Why emphasize it again? to stop people think that they can safely subtract one size from another. that 'u' will remind them. signature.asc Description: PGP signature
Re: D3
On Tue, 09 Dec 2014 08:15:00 + Puming via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 05:04:35 UTC, Jeremy DeHaan wrote: On Tuesday, 9 December 2014 at 03:52:01 UTC, ketmar via Digitalmars-d wrote: On Mon, 08 Dec 2014 21:08:03 + Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Major version numbers are actually in the letter so we should go to E1. there was E language too: http://en.wikipedia.org/wiki/Amiga_E with only 26 letters it's hard to be original. i'm voting for using Japan or Chineese hieroglyphs, as there are plenty of them. For Japanese it would be ディ which is pronounced the same as the name of the letter D. For Chinese it would be 帝 which pronounces the same as 'D' and means Emperor. i like that! signature.asc Description: PGP signature
Re: Do everything in Java…
On Monday, 8 December 2014 at 16:04:31 UTC, H. S. Teoh via Digitalmars-d wrote: On Mon, Dec 08, 2014 at 11:22:45AM +, Chris via Digitalmars-d wrote: [...] What I gather from all the posts about code reviews and testing is that it's a solid mess out there, and the bigger the company the bigger the mess. I'm pretty much the only guy who works on the code at the moment and sometimes feel a bit bad about failing to update this or that (unit) test (simply because I lack the time). On the other hand the code and the programs are constantly being tested in the real world and are very stable. Sounds like you're actually in a pretty good state, compared with the rest of the industry out there! :-P Well, I don't have to meet deadlines all the time and deal with customers who've been promised by someone in the management that you can turn straw into gold. I don't need feature X until tomorrow (or yesterday), but can think about a proper implementation first. Thankfully we have someone on the team who can test the software immediately and thoroughly before we give it out (or use it internally). This might be due to the fact, that I unit test a lot during development (code a little, test a little). It is also down to the fact that the D compiler often helps me and warns me immediately. It's not so easy to get away with dodgy code in D. Yeah, D does fix a lot of the flaws with C/C++ that allow you to shoot yourself in the foot and then erase all evidence of it. While D does have its own share of dark corners, it's generally very pleasant to work with, and does encourage good coding style. D does have dark corners, but only if you care to go there, and sooner or later (rather sooner than later) your house of cards will collapse, because the dodgy code is often found out by the proper code. I've always had to rewrite any dodgy, highly unsafe code I introduced to save a nanosecond - and the dodgy code is usually due to some interaction with C! Regarding the working hours, it is hard to measure efficiency in working hours when it comes to software development. Sometimes a major improvement takes only one or two hours of highly concentrated work (after which the brain is wrecked). Sometimes a stupid little problem takes a whole day to sort out. And let's not forget that programmers often tend to think about how to solve a certain problem after work. I often found it more efficient to shut down the computer and go home than to keep on trying to find a bug when I'm already tired and annoyed. The next morning (with a fresh head) I often spot the bug immediately. Or I think of the right solution on my way home. Mere working hours don't count. Yep. I have experienced this many times. Sometimes repeatedly trying to attack a problem eventually gets to a point where my brain is just overwhelmed and cannot make any further progress, but when I take a walk and relax for a few minutes, my subconscious brain clears up and suddenly the solution pops into my head seemingly out of nowhere. I've had occasions where I wake up in the middle of the night with the solution in my head -- at least once, I actually got up at 6am and drove to work just to implement what I became convinced was the fix, and found that it in fact was, whereas many hours of intense concentration the day before got me nowhere. T
Re: D3
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Well, the name of D is D not D(n), so there should be no problem in case they want to sue Walter. But really, it had to be JavaScript of all languages! At least it's not PHP.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Monday, 8 December 2014 at 21:20:20 UTC, Andrei Alexandrescu wrote: On 12/4/14 8:37 PM, Robert burner Schadek wrote: That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ _loggerinfo.d and then describe the import constraint in the documentation. Perhaps that might improve error messages. I fear of things that could happen if a circular import via mixin fails. Andrei How long is a line of your terminal? On a more serious note: I proposed _loggerinfo.d to counteract that and this file could be the place to store all logger configuration anybody invents. This way we would have a canonical place for all configuration concerning the logger.
Re: Do everything in Java…
On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote: […] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available. GDC is tied to the GCC release program I guess, so gdc can only be updated when there is a new GCC release. I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, so I tend to use that by default to get something fast that is more or less up-to-date with DMD. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Do everything in Java…
On Tue, 09 Dec 2014 11:09:44 + Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote: […] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available. GDC is tied to the GCC release program I guess nope. it's just lack of developers. I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, to the extent that i can't build git head. ;-) signature.asc Description: PGP signature
Re: D3
On Tuesday, 9 December 2014 at 10:49:13 UTC, Chris wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Well, the name of D is D not D(n), so there should be no problem in case they want to sue Walter. But really, it had to be JavaScript of all languages! At least it's not PHP. I prefer PHP, at least it's an explicit hack on sight.
Re: Do everything in Java…
On Tue, 2014-12-09 at 13:22 +0200, ketmar via Digitalmars-d wrote: On Tue, 09 Dec 2014 11:09:44 + Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: […] GDC is tied to the GCC release program I guess nope. it's just lack of developers. Too much effort expended on DMD I guess ;-) I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, to the extent that i can't build git head. ;-) Works fine for me, I just built it 15 mins ago. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D3
On Tuesday, 9 December 2014 at 11:23:28 UTC, uri wrote: On Tuesday, 9 December 2014 at 10:49:13 UTC, Chris wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Well, the name of D is D not D(n), so there should be no problem in case they want to sue Walter. But really, it had to be JavaScript of all languages! At least it's not PHP. I prefer PHP, at least it's an explicit hack on sight. I've had to work with both at the same time. Jesus, I wonder how many years that took off my natural life :-)
Re: Do everything in Java…
On Tue, 09 Dec 2014 11:34:34 + Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, to the extent that i can't build git head. ;-) Works fine for me, I just built it 15 mins ago. to be honest i tried that month or two ago. it failed somewhere in the middle with some error message and i deleted it. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via Digitalmars-d wrote: Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. i bet that woobooAAARGH will be even easier to recognize than size_t. as there is no other types in D with _t suffix, you have to remember that anyway, so it doesn't really matter which one to remember. ;-) brb aliasing
Re: Any SIMD experts?
On Monday, 8 December 2014 at 22:10:09 UTC, Martin Nowak wrote:
On 12/08/2014 06:05 PM, John Colvin wrote:
Well gcc gives me:
Tried that with dmd, it gave me.
bug.d(5): Error: incompatible types for ((a) = (l)):
'__vector(ulong[4])' and '__vector(ulong[4])'
bug.d(5): Error: incompatible types for ((a) (h)):
'__vector(ulong[4])' and '__vector(ulong[4])'
Yours looks better.
It's unfortunate it can't work it out automatically like gcc can.
Anyway, you can write it out manually:
auto foo(ulong2 a, ulong2 l, ulong h)
{
static long2 shift = long.min; //-2^63
long2 aS = cast(long2)(a - shift);
long2 lS = cast(long2)(l - shift);
long2 hS = cast(long2)(h - shift);
return (hS aS) (lS aS);
}
but that doesn't actually compile, the compiler just sits in
semantic3 forever (see
https://issues.dlang.org/show_bug.cgi?id=13841)
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. I've just used it. It *is* part of phobos, albeit hidden.
Re: DIP69 - Implement scope for escape proof references
On 08/12/2014 15:53, Steven Schveighoffer wrote: scope ref int foo(ref int x); will do it. So: int x; foo(x) += 1; will compile? Yes, because foo's argument is not scope, it can be returned.
Invalid reference in a wikipedia - D related article
I was writing some things when I suddently realized that the wikipedia page http://en.wikipedia.org/wiki/Const_%28computer_programming%29 hyperlinks an invalid article: Here A Const, There A Const http://www.digitalmars.com/d/const.html I let someone more aware fix it.
Re: Do everything in Java…
On Tue, Dec 09, 2014 at 11:09:44AM +, Russel Winder via Digitalmars-d wrote: On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote: […] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available. GDC is tied to the GCC release program I guess, so gdc can only be updated when there is a new GCC release. I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, so I tend to use that by default to get something fast that is more or less up-to-date with DMD. [...] I used to compile gdc from source, but unfortunately, the gcc build scripts are so very temperamental and sensitive... the slightest environment variable set wrong in your system, and you're up for unending hours of hair-pulling frustration trying to figure out what went wrong given only an error message that almost always has nothing whatsoever to do with the real problem, which has already happened half an hour earlier. This is especially so if you attempt to build with a gcc version that isn't the latest development version, which is inevitably incompatible with my current system's gcc version, which means I have to install it in a custom path, which is often a source of trouble because anytime you change the default settings, you've to be prepared for lots of things exploding in your face unless you know exactly what you're doing (and I don't). T -- You have to expect the unexpected. -- RL
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 13:34:24 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. I've just used it. It *is* part of phobos, albeit hidden. ok, we have one man using it. ;-) signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 13:34:24 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 03:48:17 UTC, ketmar via Digitalmars-d wrote: http://dlang.org/phobos/std_stdint.html ah, nobody uses that, and it's not even documented. a forgotten leftover. I've just used it. It *is* part of phobos, albeit hidden. p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. signature.asc Description: PGP signature
Re: Redesign of dlang.org
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote: Hello, I've been D enthusiast for couple of years now (but I do not participate much in discussions here, although I read forums almost daily), and I keep telling people about D and how awesome it is. But, all this time D's official website somehow archaic look kept troubling me. It reminds me of early 2000's design and I really cannot associate this design with modern or elegant, what D really is. I think that we must invest time and energy improving the website's look and feel as that is what people first coming to D will see. We need to strive for wow and not meh as a first impression. So I have started this thread to see if there is a chance for complete redesign of dlang.org. I have also tried to design something myself (although I'm not a designer) and this is what I came up with: http://krcko.net/dlang.org/dlang-home-draft1.png I'm not entirely satisfied with it but I believe that it looks better (or at least more modern) than the current design. So, what do you guys think? -- Aleksandar What's up with this new website design ? Drafts looked good.
Re: Do everything in Java…
08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет: On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d wrote: [...] As with any of these situation the convoluted hardcoded for a specific processor code, especially assembly language will always win. I don't care about that, I care about the fastest comprehensible code that is portable simply by compilation or execution. Based on this, Java does well, so does some Groovy perhaps surprisingly, also Scala. C++ does well especially with TBB (though as an API it leaves a lot to be desired). D is OK but only using ldc2 or gdc, dmd sucks. [...] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available. -- Dmitry Olshansky
Re: Any SIMD experts?
On Tuesday, 9 December 2014 at 12:36:29 UTC, John Colvin wrote:
On Monday, 8 December 2014 at 22:10:09 UTC, Martin Nowak wrote:
On 12/08/2014 06:05 PM, John Colvin wrote:
Well gcc gives me:
Tried that with dmd, it gave me.
bug.d(5): Error: incompatible types for ((a) = (l)):
'__vector(ulong[4])' and '__vector(ulong[4])'
bug.d(5): Error: incompatible types for ((a) (h)):
'__vector(ulong[4])' and '__vector(ulong[4])'
Yours looks better.
It's unfortunate it can't work it out automatically like gcc
can.
Anyway, you can write it out manually:
auto foo(ulong2 a, ulong2 l, ulong h)
{
static long2 shift = long.min; //-2^63
long2 aS = cast(long2)(a - shift);
long2 lS = cast(long2)(l - shift);
long2 hS = cast(long2)(h - shift);
return (hS aS) (lS aS);
}
but that doesn't actually compile, the compiler just sits in
semantic3 forever (see
https://issues.dlang.org/show_bug.cgi?id=13841)
which of course Kenji already has a pull for, less than 3 hours
later :)
Re: DIP69 - Implement scope for escape proof references
On 12/9/14 9:23 AM, Nick Treleaven wrote: On 08/12/2014 15:53, Steven Schveighoffer wrote: scope ref int foo(ref int x); will do it. So: int x; foo(x) += 1; will compile? Yes, because foo's argument is not scope, it can be returned. But I thought if you take a reference from the stack, it's inferred as scope? I feel like there's a missing link somewhere if the scope is missing from the parameter. Will ref just automatically bind to any scoped reference? What about this: auto y = x; foo(*y) += 1; -Steve
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d wrote: p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. I'm doing lots of pointer arithmetic so i've used uintptr_t in various places.
Can we make Throwable an interface?
Then we could use interfaces as tags for exceptions and catch using one of many interfaces an exception has. Consider DIP33: http://wiki.dlang.org/DIP33 The 2 problems it had were: 1. enums are hard to extend for std lib, and absolutely impossible by 3rd party libraries. 2. Single hierarchy has some appeal but it doesn't allow to catch on similar classes that do not inherit from the same base class. Basically there are many ways to view similarities of excpetions and single hierarchy fails to address that. If we were to replace each class with a base interface and every Kind enum with an interface (inhereting from one or more base interfaces) then we can actually address both of these points. To druntime experts - is it hard to change Throwable to be an interface? What exactly EH system needs of Throwable? -- Dmitry Olshansky
Re: problem with size_t and an easy solution
On Tuesday, 9 December 2014 at 03:14:23 UTC, ketmar via Digitalmars-d wrote: somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. A well-designed language allows to recover from errors with good probability and thus give simultaneous useful error reports for multiple parts of the program. Sure, you always need the first error message, but having other useful error messages is a benefit as long as the probability of recovery is high enough.
Re: Do everything in Java…
On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет: On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d wrote: [...] As with any of these situation the convoluted hardcoded for a specific processor code, especially assembly language will always win. I don't care about that, I care about the fastest comprehensible code that is portable simply by compilation or execution. Based on this, Java does well, so does some Groovy perhaps surprisingly, also Scala. C++ does well especially with TBB (though as an API it leaves a lot to be desired). D is OK but only using ldc2 or gdc, dmd sucks. [...] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. [...] Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved. T -- Fact is stranger than fiction.
Re: Can we make Throwable an interface?
All the stack tracing stuff is wired through Throwable, so some duplication may need to occur if it were changed to an interface.
Re: Can we make Throwable an interface?
On Tue, Dec 09, 2014 at 08:06:32PM +0300, Dmitry Olshansky via Digitalmars-d wrote: Then we could use interfaces as tags for exceptions and catch using one of many interfaces an exception has. Consider DIP33: http://wiki.dlang.org/DIP33 The 2 problems it had were: 1. enums are hard to extend for std lib, and absolutely impossible by 3rd party libraries. 2. Single hierarchy has some appeal but it doesn't allow to catch on similar classes that do not inherit from the same base class. Basically there are many ways to view similarities of excpetions and single hierarchy fails to address that. If we were to replace each class with a base interface and every Kind enum with an interface (inhereting from one or more base interfaces) then we can actually address both of these points. [...] I like this idea! It would also address the current messy situation with OS-specific exceptions (e.g., ErrnoException or WindowsException, or whatever it's called) vs. semantically-oriented logical exceptions (FileNotFoundException, NoAccessException, etc.). OS-specific exceptions are necessary to capture OS-specific information, but user code generally wants to catch according to more semantic / logical criteria. For example, dirEntries may fail due to permission failure, but the user is generally not interested in OS-specific error codes like errno or Windows error numbers; what is more interesting is was this failure caused by permission error?. This problem cannot be satisfactorily resolved with a single Exception hierarchy, but it *can* be resolved by using interfaces instead of base classes. We could then have a WindowsException and a PosixErrnoException (for example), and have subclasses also implement a NoAccessException interface. Thus you have a class hierarchy based on implementation details (e.g., PosixErrorException stores errno, and WindowsException stores Windows error codes), but also an interface hierarchy based on logical categorizations of exceptions. T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Re: problem with size_t and an easy solution
D devs are quite willing to improve error messages, they have improved many of them. I'm not trying to call anyone lazy ;) Sometimes though, the bugs I imagine I would submit seem like they would lead to a wild goose chase more than a solution. Don't forget to mention DustMite. I'll definitely check this out. somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. I don't think I would call this nonsense. MSVC for example, often emits multiple errors correctly. I haven't checked this with MSVC, but I imagine an unidentified identifier could be a case where this is possible. Also, many intellisense systems are able to recover after multiple errors and continue parsing a file. I suppose the rest of the errors could be generated on a second pass though. For example, if the first error was an unidentified identifier, the compiler could then re-parse the file and report all instances of that identifier's usage. D compiler is fast enough to stop that horrible now you have 100500 errors reported, enjoy practice. On the other hand, this sounds a lot like failed template instantiations in old versions of MSVC ;) the second thing that i want to have is compiler explaining why it rejected some templates. i.e. what constrains failed. those messages about can't instantiate are among the most noisy and cryptic ones. Yep.
Re: DIP69 - Implement scope for escape proof references
On 09/12/2014 16:25, Steven Schveighoffer wrote: But I thought if you take a reference from the stack, it's inferred as scope? I feel like there's a missing link somewhere if the scope is missing from the parameter. I think (with this DIP) values on the stack can safely be passed as a ref parameter, which is a bit more flexible than a scope parameter. Will ref just automatically bind to any scoped reference? What about this: (for reference:) int x; scope ref int foo(ref int x); auto y = x; foo(*y) += 1; y gets inferred as scope, but *y is not scope, so it should work.
Re: Invalid reference in a wikipedia - D related article
On 12/09/2014 04:34 PM, BBaz wrote: I was writing some things when I suddently realized that the wikipedia page http://en.wikipedia.org/wiki/Const_%28computer_programming%29 hyperlinks an invalid article: Here A Const, There A Const http://www.digitalmars.com/d/const.html I let someone more aware fix it. Looks like it was removed in this commit:; https://github.com/D-Programming-Language/dlang.org/commit/995e538cea03d32764326f8cb45143f2dbe28194 -- Mike Wey
Re: Can we make Throwable an interface?
09-Dec-2014 21:00, Sean Kelly пишет: All the stack tracing stuff is wired through Throwable, so some duplication may need to occur if it were changed to an interface. Do yYou mean that interface can't contain the code for tracing so we'd have to duplicate it in Error and/or Exception? But interfaces can contain final methods just fine and tracing seems like something not overridable nor public, how the whole problem area looks like? -- Dmitry Olshansky
Re: Can we make Throwable an interface?
09-Dec-2014 21:05, H. S. Teoh via Digitalmars-d пишет: 1. enums are hard to extend for std lib, and absolutely impossible by 3rd party libraries. 2. Single hierarchy has some appeal but it doesn't allow to catch on similar classes that do not inherit from the same base class. Basically there are many ways to view similarities of excpetions and single hierarchy fails to address that. If we were to replace each class with a base interface and every Kind enum with an interface (inhereting from one or more base interfaces) then we can actually address both of these points. [...] I like this idea! [snip] For example, dirEntries may fail due to permission failure, but the user is generally not interested in OS-specific error codes like errno or Windows error numbers; what is more interesting is was this failure caused by permission error?. This problem cannot be satisfactorily resolved with a single Exception hierarchy, but it *can* be resolved by using interfaces instead of base classes. We could then have a WindowsException and a PosixErrnoException (for example), and have subclasses also implement a NoAccessException interface. Thus you have a class hierarchy based on implementation details (e.g., PosixErrorException stores errno, and WindowsException stores Windows error codes), but also an interface hierarchy based on logical categorizations of exceptions. That's exactly what I aim to do. The question is how hard it's do in runtime and if there are any critical assumptions that prevent this. -- Dmitry Olshansky
Re: Do everything in Java…
09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет: On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет: On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d wrote: [...] As with any of these situation the convoluted hardcoded for a specific processor code, especially assembly language will always win. I don't care about that, I care about the fastest comprehensible code that is portable simply by compilation or execution. Based on this, Java does well, so does some Groovy perhaps surprisingly, also Scala. C++ does well especially with TBB (though as an API it leaves a lot to be desired). D is OK but only using ldc2 or gdc, dmd sucks. [...] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. [...] Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved. std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates. Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining. -- Dmitry Olshansky
Re: Do everything in Java…
On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет: On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет: [...] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. [...] Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved. std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates. Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining. [...] Hmm. Would it help to change isWhite into a template function? T -- It only takes one twig to burn down a forest.
Re: Do everything in Java…
On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет: On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет: [...] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. [...] Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved. std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates. Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining. [...] Hmm. Would it help to change isWhite into a template function? That can't be the answer for everything. Iain
Re: Do everything in Java…
09-Dec-2014 22:18, Iain Buclaw via Digitalmars-d пишет: On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет: On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет: [...] Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. [...] Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved. std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates. Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining. [...] Hmm. Would it help to change isWhite into a template function? That can't be the answer for everything. As someone (ab)using empty template idiom, I agree, we need a better solution. -- Dmitry Olshansky
Re: DIP69 - Implement scope for escape proof references
On Monday, 8 December 2014 at 23:00:05 UTC, deadalnix wrote: This is inherently about ownership. I have a proposal about this. Scope is about using things without ownership. Both are linked but different beast. Not really different. The activation record (stack frame) is conceptually an object. Scoped objects are owned by the activation record. You have the same problem when handing out references to parts of composite objects. When propagating references down a call chain you can keep track of the associated call-depth, when the call-depth associated with the reference is greater than 0, then it safe to return the reference from a function. Right?
Re: Do everything in Java…
On Tue, Dec 09, 2014 at 10:22:13PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 09-Dec-2014 22:18, Iain Buclaw via Digitalmars-d пишет: On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote: 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет: On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: [...] And that's not nearly enough. Also both LDC GDC often can't inline many functions from phobos due to separate compilation. [...] Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved. std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates. Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining. [...] Hmm. Would it help to change isWhite into a template function? That can't be the answer for everything. As someone (ab)using empty template idiom, I agree, we need a better solution. [...] I don't see what's the problem with making it an empty template. It eliminates dead code in your executable if you never call that function, it enables attribute inference, and it allows inlining. The only major incompatibility I can see is the ability to ship closed-source libraries, but in that case, inlining is already out of the question anyway, so it's a non-issue. Or am I missing something obvious? T -- IBM = I Blame Microsoft
Re: Do everything in Java…
On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via Digitalmars-d wrote: As someone (ab)using empty template idiom, I agree, we need a better solution. [...] I don't see what's the problem with making it an empty template. It eliminates dead code in your executable if you never call that function, it enables attribute inference, and it allows inlining. The only major incompatibility I can see is the ability to ship closed-source libraries, but in that case, inlining is already out of the question anyway, so it's a non-issue. Or am I missing something obvious? Considering the optimizer don't know what a template is, and do the inlining, I'm not sure why everybody think the 2 are that linked.
Re: Do everything in Java…
On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via Digitalmars-d wrote: I don't see what's the problem with making it an empty template. It eliminates dead code in your executable if you never call that function, it enables attribute inference, and it allows inlining. The only major incompatibility I can see is the ability to ship closed-source libraries, but in that case, inlining is already out of the question anyway, so it's a non-issue. Or am I missing something obvious? Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken = not really a solution.
Re: DIP69 - Implement scope for escape proof references
On Tuesday, 9 December 2014 at 19:39:31 UTC, Ola Fosheim Grøstad wrote: On Monday, 8 December 2014 at 23:00:05 UTC, deadalnix wrote: This is inherently about ownership. I have a proposal about this. Scope is about using things without ownership. Both are linked but different beast. Not really different. The activation record (stack frame) is conceptually an object. Scoped objects are owned by the activation record. You have the same problem when handing out references to parts of composite objects. When propagating references down a call chain you can keep track of the associated call-depth, when the call-depth associated with the reference is greater than 0, then it safe to return the reference from a function. Right? That why i say they are linked. I don't think your way of stating it contradict what I said. scope allow for manipulation of data without owning them. Whatever the owner is (be it the stack frame or anything else) doesn't really matter here.
Re: DIP69 - Implement scope for escape proof references
On 12/8/2014 3:14 PM, Dicebot wrote:
On Monday, 8 December 2014 at 21:12:47 UTC, Walter Bright wrote:
On 12/8/2014 12:54 PM, Dicebot wrote:
struct ByLine
{
scope string front();
// ...
}
auto byLine(File file)
{
return ByLine(file);
}
scope /* ref */ string foo(scope /* ref */ string input)
{
return input[1..$];
}
void main()
{
auto r = file.byLine.map!foo;
string s = r.front; // this should not compile
string s = r.front.dup; // this should compile
// how foo signature should look like for this to work?
}
front() should return a 'scope ref string'.
That seems to contradict your other statement:
A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.
Just make it a 'ref' parameter.
Please check `foo()` once more - it needs to accept scope (ref) to be able to
accept ByLine.front as an argument. And it also needs to pass it down the call
chain - but returning `input` by reference is illegal according to
abovementioned rule.
It can still be passed down as a 'ref' parameter.
Re: D3
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Powers of two are magic.
Re: problem with size_t and an easy solution
On 12/10/2014 1:55 AM, Gary Willoughby wrote: On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d wrote: p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. I'm doing lots of pointer arithmetic so i've used uintptr_t in various places. So you should be importing core.stdc.stdint directly. Pretend that std.stdint doesn't exist.
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 17:28:15 + Ivan Kazmenko via Digitalmars-d digitalmars-d@puremagic.com wrote: A well-designed language allows to recover from errors with good probability if compiler can recover from error, it should not report the error at all -- 'cause it can fix the code for me. that is absolutely nonsense, you *CAN'T* recover from invalid code. that is the fact. fact: Earth is not a sphere. fact: you can't automatically recover from invalid code. that habit of try to compile as much as we can originates in the times when running a compiler was very costly process, so it's better to have some invalid error messages than runing the compiler again after each error found and fixed. hey, it's time to stop doing that! the epoch of punch cards and teletypes are over! it's time to stop trying to recover from irrecoverable states. there is *nothing* valuable in a stupid list of compilation errors most of which are invalid and others will become invalid after you fix the first one. build faster compiler. cache AST's. but stop vomiting alphanumeric noise just because... well... we doing this from 70ths! signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 16:55:22 + Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 December 2014 at 16:10:10 UTC, ketmar via Digitalmars-d wrote: p.s. just out of curiousity: why do you need it? D int types has well-defined size, so i can't see any sense in using C leftover. I'm doing lots of pointer arithmetic so i've used uintptr_t in various places. ah, that one type. i was always wonder why it's missing in object.d[i]. but as `usize` is guaranteed to be big enough to hold the pointer and `alias` doesn't create any new type, why don't just use `usize`/`size_t`? signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
On Tue, 09 Dec 2014 18:08:48 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: somehow Walter can't accept that after emiting the first error compiler is in undefined state, and trying to pretend that it is in well-defined state or guess what well-defined state must be is a nonsense. I don't think I would call this nonsense. MSVC for example, often emits multiple errors correctly. I haven't checked this with MSVC, but I imagine an unidentified identifier could be a case where this is possible. Also, many intellisense systems are able to recover after multiple errors and continue parsing a file. so let intellisense-like systems do the guesswork. i don't trust a compiler that tries to guess what i mean instead of reporting the error and stop right there. i.e. i once tried PL/1 compiler which was able to guess what lone `IF` means. and now i don't want the compiler to do *ANY* guesswork. it's ok for support tools, but compiler should not claim that it can recover from invalid code, 'cause invalid code is... well... invalid and irrecoverable without manual human fixing. and if it is recoverable, why do i have to do any manual fixing at all? if compiler is so smart, he should fix the code and go on. see, you *CAN'T* recover from such error. even in D you can catch Error, but program state is already undefined. in the case of compiler the state of the compiler itself is defined, but input data is trashed. i can't see any sense in trying to figure out something sane from trashed input. let the user fix the input instead of guessing. signature.asc Description: PGP signature
Re: problem with size_t and an easy solution
so let intellisense-like systems do the guesswork. i don't trust a compiler that tries to guess what i mean instead of reporting the error and stop right there. i.e. i once tried PL/1 compiler which was able to guess what lone `IF` means. and now i don't want the compiler to do *ANY* guesswork. I probably should have started my own thread ;) Anyways, this video is a couple of years old, but this is how Clang does what I'm talking about, around 16:00 minutes in. http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys
Re: problem with size_t and an easy solution
On Wed, 10 Dec 2014 03:00:56 + bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote: so let intellisense-like systems do the guesswork. i don't trust a compiler that tries to guess what i mean instead of reporting the error and stop right there. i.e. i once tried PL/1 compiler which was able to guess what lone `IF` means. and now i don't want the compiler to do *ANY* guesswork. I probably should have started my own thread ;) ah, no, this thread is fine too. ;-) this thread is not strictly about size_t, it's about inconsistencies and legacies in D. Anyways, this video is a couple of years old, but this is how Clang does what I'm talking about, around 16:00 minutes in. http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys as i can understand from my limited english hearing skills ;-), this is about guessing identifiers, right? another feature i found useless. i even patched my DMD to stop suggesting me that BS, it's so annoying. i want command-line argument to stop DMD doing that! signature.asc Description: PGP signature
Re: DIP69 - Implement scope for escape proof references
On 12/8/2014 3:34 PM, bearophile wrote: If that topic is outside the scope of this discussion, then I have opened an ER on it: https://issues.dlang.org/show_bug.cgi?id=13838 1. You can always start a new thread here. 2. Thanks for filing the E.R. 3. When filing such, please check the [Hardware] settings. You have it set to [x86][Windows]. I reset them to [All][All].
Re: DIP69 - Implement scope for escape proof references
On Tuesday, 9 December 2014 at 22:24:51 UTC, Walter Bright wrote: front() should return a 'scope ref string'. That seems to contradict your other statement: A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'. Just make it a 'ref' parameter. Please check `foo()` once more - it needs to accept scope (ref) to be able to accept ByLine.front as an argument. And it also needs to pass it down the call chain - but returning `input` by reference is illegal according to abovementioned rule. It can still be passed down as a 'ref' parameter. But as far as I understand the spec it will result it this code failing too: auto r = [aaa, bbb, ccc].map!foo; // should compile but will fail because foo returns scope ref: string s = r.front; What I mean is that in current proposal it is impossible to transfer scope information down the call chain - either function always returns scope ref or never. Which implies the necessity of something like `auto scope`...
Re: DIP69 - Implement scope for escape proof references
On 12/8/2014 3:21 PM, deadalnix wrote: On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote: A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'. It can safely be returned if you consider its lifetime as the intersection of the lifetime of the function's parameter. The only purpose to a 'scope ref' parameter is to say it isn't being returned. 'ref' itself does not escape in any way other than by returning.
Very short anonymous survey
Hello all, If I could have a minute of your time for a short anonymous survey regarding D libraries and tools, I'd really appreciate it. http://goo.gl/forms/lMrHRr335C This is explained further in the link above, but for context: I'm a developer working on a library for D that I need for an application I'd like to write in D. I need the community's opinion of paying for builds of open source software, as my library requires extra work to build and cannot be built with just dub. I want to make it as easy as possible for others to use the library, but providing/maintaining builds for different compilers and platforms is time-consuming and costly. Thanks for your time!
Re: D Meetup in SF?
On 2014-12-08 16:06:45 +, Martin Nowak said: On 12/05/2014 09:15 AM, Shammah Chancellor wrote: I didn't notice a D meetup group in SF. Is anyone else in here interested in doing something like this once a month? We could have a video cast over to the Berlin meetup :). That would be really awesome. We really need to get this stuff going. I think meetups are a great way to evangelize. -S.
Re: DIP69 - Implement scope for escape proof references
On Wednesday, 10 December 2014 at 05:23:29 UTC, Walter Bright wrote: On 12/8/2014 3:21 PM, deadalnix wrote: On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote: A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'. It can safely be returned if you consider its lifetime as the intersection of the lifetime of the function's parameter. The only purpose to a 'scope ref' parameter is to say it isn't being returned. 'ref' itself does not escape in any way other than by returning. That is a completely useless feature. Also, you want to have scope return for container like thing.
Re: @property usage
On 12/9/2014 4:31 PM, Nicholas Londey wrote: Does @property ever make sense for a free floating function? I would have thought no but was recently asked to add it if using the function with uniform call syntax. I use it from time-to-time. I assume you think of properties as belonging to objects and not just something that is useful with UFCS. Keep in mind that free-floating functions belong to modules and modules (usually) belong to packages. These are units of encapsulation above classes structs. There could be (and has been in these forums) lengthy debate about what constitutes a property and what doesn't, but whether or not a function belongs to a class or struct shouldn't enter into it, IMO.
Re: @property usage
On Tuesday, 9 December 2014 at 07:31:21 UTC, Nicholas Londey wrote: as this can break some invalid code (the code where people using properties as functions) Does @property ever make sense for a free floating function? I would have thought no but was recently asked to add it if using the function with uniform call syntax. https://github.com/D-Programming-Language/dub/pull/455#discussion_r21430311 After a quick grep I see phobos uses quite a few free floating @property...
Re: Derelict / SDL error
On Monday, 8 December 2014 at 21:01:40 UTC, Paul wrote: On Monday, 8 December 2014 at 17:48:55 UTC, Jack wrote: I'm running ArchLinux 64-bit on Vbox and tested out the code. There haven't been any problems. Have you tried updating whatever tools you're using?(dmd, dub, etc) Might've been an outdated piece of software that's been making the fuss. Thanks for that. I've just tried the code on a different machine (latest Lubuntu on a 32 bit laptop, latest SDL, dmd and current dub binary) and it has exactly the same problem. Can't think what the problem might be other than something wrong with the way I've compiled SDL...?? The only 'warning' during compilation of SDL is about dbus not being used so I installed all the related *dev files I could find (and recompiled after each) but despite dbus now being flagged as 'used' it was to no avail. Thinking...
Re: How do i use std.functional.binaryFun?
On Tuesday, 9 December 2014 at 01:17:47 UTC, anonymous wrote: Looks like a compiler bug. Filed: https://issues.dlang.org/show_bug.cgi?id=13843
Re: Derelict / SDL error
On Tuesday, 9 December 2014 at 10:19:38 UTC, Paul wrote: On Monday, 8 December 2014 at 21:01:40 UTC, Paul wrote: On Monday, 8 December 2014 at 17:48:55 UTC, Jack wrote: I'm running ArchLinux 64-bit on Vbox and tested out the code. There haven't been any problems. Have you tried updating whatever tools you're using?(dmd, dub, etc) Might've been an outdated piece of software that's been making the fuss. Thanks for that. I've just tried the code on a different machine (latest Lubuntu on a 32 bit laptop, latest SDL, dmd and current dub binary) and it has exactly the same problem. Can't think what the problem might be other than something wrong with the way I've compiled SDL...?? The only 'warning' during compilation of SDL is about dbus not being used so I installed all the related *dev files I could find (and recompiled after each) but despite dbus now being flagged as 'used' it was to no avail. Thinking... Can't really think of anything that can solve your problem. Only time I had a seg fault is calling a method from an uninitialized class. You can try to get a debugger and/or a gui that comes with it(personally I use gdb with ddd) to find something out. Sorry but this is all the suggestions I can give to you, I'm not really an expert in Derelict or Libraries or something.
Garbage collector collects live objects
Hi, I experience very strange problem: GC somehow collects live objects. I found it because i got segfaults. After debugging and tracing i found this is because of accessing not allocated memory. I did the following checks: - added to some class invariant check for access to suspicious members with assertion assert(GC.addrOf(cast(void*)x) !is null); where it fails DETERMINISTICALLY at some point - printing address of allocated classes where i observe the following pattern - ctor check check check - dtor check (fails) could anybody advice me with something? I got really frustrated by this strange behaviour which i can not fix right now. key observations: - it is deterministically behaviour (what gets me even more confused cause GC collections as far as i know runs from time to time) - i do not play with pointers optimisation like hiding its in ints or floats. - i operate with large uniformly distributed (video) data in memory where pointer like patterns may occur. but this is not the case cause (1) it brings at worst long living objects (2) input sequence constant but allocated pointers each run different.
Re: Garbage collector collects live objects
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote: Hi, I experience very strange problem: GC somehow collects live objects. I found it because i got segfaults. After debugging and tracing i found this is because of accessing not allocated memory. I did the following checks: - added to some class invariant check for access to suspicious members with assertion assert(GC.addrOf(cast(void*)x) !is null); where it fails DETERMINISTICALLY at some point - printing address of allocated classes where i observe the following pattern - ctor check check check - dtor check (fails) could anybody advice me with something? I got really frustrated by this strange behaviour which i can not fix right now. key observations: - it is deterministically behaviour (what gets me even more confused cause GC collections as far as i know runs from time to time) - i do not play with pointers optimisation like hiding its in ints or floats. - i operate with large uniformly distributed (video) data in memory where pointer like patterns may occur. but this is not the case cause (1) it brings at worst long living objects (2) input sequence constant but allocated pointers each run different. A random guess, since you haven't posted any code, are you accessing GC resources inside a destructor? If so, that is not guaranteed to work. A class destructor, or a destructor of a struct that is contained inside a class, can only be used to destroy NON-GC resources. If you want more help, you need to post some code. Something that minimally causes the issue would be good. -Steve
Re: Garbage collector collects live objects
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and
tracing i found
this is because of accessing not allocated memory.
I did the following checks:
- added to some class invariant check for access to suspicious
members
with assertion
assert(GC.addrOf(cast(void*)x) !is null);
where it fails DETERMINISTICALLY at some point
- printing address of allocated classes where i observe the
following
pattern
- ctor
check
check
check
- dtor
check (fails)
could anybody advice me with something? I got really
frustrated by this
strange behaviour which i can not fix right now.
key observations:
- it is deterministically behaviour (what gets me even more
confused
cause GC collections as far as i know runs from time to time)
- i do not play with pointers optimisation like hiding its in
ints or
floats.
- i operate with large uniformly distributed (video) data in
memory
where pointer like patterns may occur. but this is not the
case cause
(1) it brings at worst long living objects (2) input sequence
constant
but allocated pointers each run different.
A random guess, since you haven't posted any code, are you
accessing GC resources inside a destructor? If so, that is not
guaranteed to work. A class destructor, or a destructor of a
struct that is contained inside a class, can only be used to
destroy NON-GC resources.
If you want more help, you need to post some code. Something
that minimally causes the issue would be good.
-Steve
No, there is no accessing GC resources in dtors.
the only usage of dtor in one class is
~this()
{
_file.close();
}
where _file is of type std.file.File
i'll try to extract problem to any observable source code but all
my previous attempts lead to problem being diminish.
Why does std.container.BinaryHeap use RefCounted?
std.container.BinrayHeap (http://dlang.org/library/std/container/BinaryHeap.html) implements a binary heap on top of a) a given random access range or b) another container that supports random access. Regardless of it's underlying data structure type, it wraps its store in RefCounted, but I don't see why this is necessary. In case b) the container itself uses reference counting, so holding a simple reference to a container should be enough. In case a) the given range might use ref counting under the hood, see b). Or not, than it is probably relying on the GC, and no reference count is needed.
Re: Derelict / SDL error
On Tuesday, 9 December 2014 at 13:34:56 UTC, Jack wrote: Can't really think of anything that can solve your problem. Only time I had a seg fault is calling a method from an uninitialized class. You can try to get a debugger and/or a gui that comes with it(personally I use gdb with ddd) to find something out. Sorry but this is all the suggestions I can give to you, I'm not really an expert in Derelict or Libraries or something. I don't fancy introduing another layer of complexity in a debugger at present! I wonder if it's the .bmp that's causing the problem. I can't quite figure how to get Derelict SDL_Image into my project at present (dub doesn't fetch it if I add import derelict.sdl.image; ) otherwise I'd try a png or something. Can't really see it being that anyway but worth a try I suppose. Thanks for trying anway. :D
Re: Derelict / SDL error
On 12/10/2014 12:19 AM, Paul wrote: I don't fancy introduing another layer of complexity in a debugger at present! I wonder if it's the .bmp that's causing the problem. I can't quite figure how to get Derelict SDL_Image into my project at present (dub doesn't fetch it if I add import derelict.sdl.image; ) otherwise I'd try a png or something. Can't really see it being that anyway but worth a try I suppose. dub doesn't know anything about DerelictSDL2Image (and even if it did, just importing it isn't going to tell dub about it -- you would need to add it to your dub.json as a dependency). That's because DerelictSDL2Image is not an independent package. It's part of DerelictSDL2. You need to call DerelictSDL2Image.load() to load the SDL2_image shared library, then you can use it.
Re: Derelict / SDL error
On Tuesday, 9 December 2014 at 15:40:00 UTC, Mike Parker wrote:
On 12/10/2014 12:19 AM, Paul wrote:
dub doesn't know anything about DerelictSDL2Image (and even if
it did, just importing it isn't going to tell dub about it --
you would need to add it to your dub.json as a dependency).
That's because DerelictSDL2Image is not an independent package.
It's part of DerelictSDL2. You need to call
DerelictSDL2Image.load() to load the SDL2_image shared library,
then you can use it.
I realise both of those, but I can't find the relevant package
name, I thought it might be like this..
dependencies: {
derelict-sdl2:~1.0.0,
derelict-gl3:=1.0.0,
derelict-sdl2-image:=1.0.0
}
I've tried several variations but no joy.
Re: Derelict / SDL error
On Tuesday, 9 December 2014 at 15:48:32 UTC, Paul wrote:
On Tuesday, 9 December 2014 at 15:40:00 UTC, Mike Parker wrote:
On 12/10/2014 12:19 AM, Paul wrote:
dub doesn't know anything about DerelictSDL2Image (and even if
it did, just importing it isn't going to tell dub about it --
you would need to add it to your dub.json as a dependency).
That's because DerelictSDL2Image is not an independent
package. It's part of DerelictSDL2. You need to call
DerelictSDL2Image.load() to load the SDL2_image shared
library, then you can use it.
I realise both of those, but I can't find the relevant package
name, I thought it might be like this..
dependencies: {
derelict-sdl2:~1.0.0,
derelict-gl3:=1.0.0,
derelict-sdl2-image:=1.0.0
}
I've tried several variations but no joy.
Whoa, I read that wrong - I'm sure I tried just adding
DerelictSDL2Image.load() to my program an it didnt work. Trying
again.
Re: Garbage collector collects live objects
On 12/9/14 9:52 AM, Ruslan Mullakhmetov wrote:
No, there is no accessing GC resources in dtors.
the only usage of dtor in one class is
~this()
{
_file.close();
}
where _file is of type std.file.File
That should work I think.
i'll try to extract problem to any observable source code but all my
previous attempts lead to problem being diminish.
Have you tried dustmite? https://github.com/CyberShadow/DustMite
-Steve
Re: Derelict / SDL error
On Tuesday, 9 December 2014 at 15:53:11 UTC, Paul wrote:
Whoa, I read that wrong - I'm sure I tried just adding
DerelictSDL2Image.load() to my program an it didnt work. Trying
again.
The top of my app.d looks like this:
import derelict.sdl2.sdl;
import std.stdio;
import std.conv;
void main()
{
scope(exit) {
SDL_Quit();
}
DerelictSDL2.load();
DerelictSDL2Image.load();
When I run dub that last line gives me:
source/app.d(15): Error: undefined identifier DerelictSDL2Image
The deps in dub.json are:
dependencies: {
derelict-sdl2:~1.0.0,
derelict-gl3:=1.0.0
}
Thanks for perseversing with my density.
Re: Garbage collector collects live objects
It may happen if only reference to an object is stored in memory block marked as data-only (using ubyte[] for a buffer is probably most common reason I have encountered)
Re: Garbage collector collects live objects
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and
tracing i found
this is because of accessing not allocated memory.
I did the following checks:
- added to some class invariant check for access to suspicious
members
with assertion
assert(GC.addrOf(cast(void*)x) !is null);
where it fails DETERMINISTICALLY at some point
- printing address of allocated classes where i observe the
following
pattern
- ctor
check
check
check
- dtor
check (fails)
could anybody advice me with something? I got really
frustrated by this
strange behaviour which i can not fix right now.
key observations:
- it is deterministically behaviour (what gets me even more
confused
cause GC collections as far as i know runs from time to time)
- i do not play with pointers optimisation like hiding its in
ints or
floats.
- i operate with large uniformly distributed (video) data in
memory
where pointer like patterns may occur. but this is not the
case cause
(1) it brings at worst long living objects (2) input sequence
constant
but allocated pointers each run different.
A random guess, since you haven't posted any code, are you
accessing GC resources inside a destructor? If so, that is not
guaranteed to work. A class destructor, or a destructor of a
struct that is contained inside a class, can only be used to
destroy NON-GC resources.
If you want more help, you need to post some code. Something
that minimally causes the issue would be good.
-Steve
No, there is no accessing GC resources in dtors.
the only usage of dtor in one class is
~this()
{
_file.close();
}
where _file is of type std.file.File
i'll try to extract problem to any observable source code but all
my previous attempts lead to problem being diminish.
that file can be already finalized. please remember that `~this()` is
more a finalizer than destructor, and it's called on *dead* object.
here this means that any other object in your object (including
structs) can be already finalized at the time GC decides to call your
finalizer.
just avoid destructors unless you *really* need that. in your case
simply let GC finalize your File, don't try to help GC. this is not C++
(or any other language without GC) and destructors aren't destructing
anything at all. destructors must clean up the things that GC cannot
(malloc()'ed memory, for example), and nothing else.
signature.asc
Description: PGP signature
Re: Garbage collector collects live objects
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and
tracing i found
this is because of accessing not allocated memory.
I did the following checks:
- added to some class invariant check for access to suspicious
members
with assertion
assert(GC.addrOf(cast(void*)x) !is null);
where it fails DETERMINISTICALLY at some point
- printing address of allocated classes where i observe the
following
pattern
- ctor
check
check
check
- dtor
check (fails)
could anybody advice me with something? I got really
frustrated by this
strange behaviour which i can not fix right now.
key observations:
- it is deterministically behaviour (what gets me even more
confused
cause GC collections as far as i know runs from time to time)
- i do not play with pointers optimisation like hiding its in
ints or
floats.
- i operate with large uniformly distributed (video) data in
memory
where pointer like patterns may occur. but this is not the
case cause
(1) it brings at worst long living objects (2) input sequence
constant
but allocated pointers each run different.
A random guess, since you haven't posted any code, are you
accessing GC resources inside a destructor? If so, that is not
guaranteed to work. A class destructor, or a destructor of a
struct that is contained inside a class, can only be used to
destroy NON-GC resources.
If you want more help, you need to post some code. Something
that minimally causes the issue would be good.
-Steve
No, there is no accessing GC resources in dtors.
the only usage of dtor in one class is
~this()
{
_file.close();
}
where _file is of type std.file.File
i'll try to extract problem to any observable source code but all
my previous attempts lead to problem being diminish.
that file can be already finalized. please remember that `~this()` is
more a finalizer than destructor, and it's called on *dead* object.
here this means that any other object in your object (including
structs) can be already finalized at the time GC decides to call your
finalizer.
File is specially designed (although it's not perfect) to be able to
close in the GC. Its ref-counted payload is placed on the C heap to
allow access during finalization.
That being said, you actually don't need to write the above in the class
finalizer, _file's destructor will automatically be called.
just avoid destructors unless you *really* need that. in your case
simply let GC finalize your File, don't try to help GC. this is not C++
(or any other language without GC) and destructors aren't destructing
anything at all. destructors must clean up the things that GC cannot
(malloc()'ed memory, for example), and nothing else.
Good advice ;)
I would say other than library writers, nobody should ever write a class
dtor.
-Steve
Re: Garbage collector collects live objects
On Tuesday, 9 December 2014 at 16:53:02 UTC, Steven Schveighoffer
wrote:
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven
Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and
tracing i found
this is because of accessing not allocated memory.
I did the following checks:
- added to some class invariant check for access to
suspicious
members
with assertion
assert(GC.addrOf(cast(void*)x) !is null);
where it fails DETERMINISTICALLY at some point
- printing address of allocated classes where i observe the
following
pattern
- ctor
check
check
check
- dtor
check (fails)
could anybody advice me with something? I got really
frustrated by this
strange behaviour which i can not fix right now.
key observations:
- it is deterministically behaviour (what gets me even more
confused
cause GC collections as far as i know runs from time to
time)
- i do not play with pointers optimisation like hiding its
in
ints or
floats.
- i operate with large uniformly distributed (video) data in
memory
where pointer like patterns may occur. but this is not the
case cause
(1) it brings at worst long living objects (2) input
sequence
constant
but allocated pointers each run different.
A random guess, since you haven't posted any code, are you
accessing GC resources inside a destructor? If so, that is
not
guaranteed to work. A class destructor, or a destructor of a
struct that is contained inside a class, can only be used to
destroy NON-GC resources.
If you want more help, you need to post some code. Something
that minimally causes the issue would be good.
-Steve
No, there is no accessing GC resources in dtors.
the only usage of dtor in one class is
~this()
{
_file.close();
}
where _file is of type std.file.File
i'll try to extract problem to any observable source code but
all
my previous attempts lead to problem being diminish.
that file can be already finalized. please remember that
`~this()` is
more a finalizer than destructor, and it's called on *dead*
object.
here this means that any other object in your object (including
structs) can be already finalized at the time GC decides to
call your
finalizer.
File is specially designed (although it's not perfect) to be
able to close in the GC. Its ref-counted payload is placed on
the C heap to allow access during finalization.
That being said, you actually don't need to write the above in
the class finalizer, _file's destructor will automatically be
called.
just avoid destructors unless you *really* need that. in
your case
simply let GC finalize your File, don't try to help GC. this
is not C++
(or any other language without GC) and destructors aren't
destructing
anything at all. destructors must clean up the things that
GC cannot
(malloc()'ed memory, for example), and nothing else.
Good advice ;)
I would say other than library writers, nobody should ever
write a class dtor.
-Steve
thanks, I got it: either C++ or D dtors are minefield =)
but i still have no clue how to overcome GC =(
Re: Garbage collector collects live objects
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote: It may happen if only reference to an object is stored in memory block marked as data-only (using ubyte[] for a buffer is probably most common reason I have encountered) Thanks for interesting hypothesis, but that's not the issue. innocent though collected objects are living in D array MyClass[] which are living in assoc array as value. i checked attributes for GC block holding this array: ``` FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR ``` I really doubting about NO_INTERIOR. can anybody confirm me that is's working with array slicing which i heavily use? also i found that block size is quite small pre array: [100A2FD00, 100A2F700, 100A33B80, 100A33500, 100A3FE80, 100A3F980, 100A3F400, 100A72600, 100A7DF80, 100A7DA80, 100A7D500] array ptr: 100A72580 root: 100A72580:128 attr: FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR [100985A00] keys: [1] as: 1 au: 100A2FD00 [100985A00] keys: [1] as: 1 au: 100A2F700 [100985A00] keys: [1] as: 1 au: 100A33B80 /pre array holds 11 64bit pointers but it's block size is only 128 bytes 11 * 64 = 704 bytes. what's wrong with this arithmetics?
Can someone explain why this outputs garbage values?
I'm trying to work with some c functions that make use of varargs
and I'm trying to push my d varargs to c varargs.
http://dpaste.dzfl.pl/ad08a6197963
Code:
___
import core.vararg;
import std.string : toStringz;
import std.c.stdio;
char[256] buffer;
void print(string format, ...)
{
char* dest = buffer.ptr;
snprintf(dest, 256UL, toStringz(fmt), _argptr);
printf(dest);
}
void main(string[] args)
{
print(%d, %d, %d\n, 1, 2, 3);
}
___
Output: -1080890848, 1073915632, 3
Re: Can someone explain why this outputs garbage values?
On Tuesday, 9 December 2014 at 19:44:42 UTC, Dustin wrote: snprintf(dest, 256UL, toStringz(fmt), _argptr); To forward varargs in C, you need to use a different function: vsnprintf instead of snprintf. (The new v at the beginning means varargs). I don't think that's completely compatible with D's varargs though, the type C expects is va_list, it might be on core.vararg, I'm not sure.
Re: Garbage collector collects live objects
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote: On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote: It may happen if only reference to an object is stored in memory block marked as data-only (using ubyte[] for a buffer is probably most common reason I have encountered) Thanks for interesting hypothesis, but that's not the issue. innocent though collected objects are living in D array MyClass[] which are living in assoc array as value. i checked attributes for GC block holding this array: ``` FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR ``` That does not sound right at all. No block should ever have both FINALIZE (reserved for objects only) and APPENDABLE (reserved for arrays only). I really doubting about NO_INTERIOR. can anybody confirm me that is's working with array slicing which i heavily use? also i found that block size is quite small pre array: [100A2FD00, 100A2F700, 100A33B80, 100A33500, 100A3FE80, 100A3F980, 100A3F400, 100A72600, 100A7DF80, 100A7DA80, 100A7D500] array ptr: 100A72580 root: 100A72580:128 attr: FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR [100985A00] keys: [1] as: 1 au: 100A2FD00 [100985A00] keys: [1] as: 1 au: 100A2F700 [100985A00] keys: [1] as: 1 au: 100A33B80 /pre array holds 11 64bit pointers but it's block size is only 128 bytes 11 * 64 = 704 bytes. what's wrong with this arithmetics? I think there is something you are missing, or something is very corrupt. Can you show the code that prints this? -Steve
Re: Can someone explain why this outputs garbage values?
Also, the reason why the special function is needed is that the argptr is just a pointer to the arguments. If you pass that to printf, how does it know that there's varargs on the other end instead of just being another pointer whose numeric value it is supposed to print out?
Re: Garbage collector collects live objects
On Tuesday, 9 December 2014 at 19:56:30 UTC, Steven Schveighoffer wrote: On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote: On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote: i checked attributes for GC block holding this array: FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR That does not sound right at all. No block should ever have both FINALIZE (reserved for objects only) and APPENDABLE (reserved for arrays only). also i found that block size is quite small pre array: [100A2FD00, 100A2F700, 100A33B80, 100A33500, 100A3FE80, 100A3F980, 100A3F400, 100A72600, 100A7DF80, 100A7DA80, 100A7D500] array ptr: 100A72580 root: 100A72580:128 attr: FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR [100985A00] keys: [1] as: 1 au: 100A2FD00 [100985A00] keys: [1] as: 1 au: 100A2F700 [100985A00] keys: [1] as: 1 au: 100A33B80 /pre array holds 11 64bit pointers but it's block size is only 128 bytes 11 * 64 = 704 bytes. what's wrong with this arithmetics? I think there is something you are missing, or something is very corrupt. Can you show the code that prints this? -Steve here the piece of code i used to output this value http://pastebin.com/cQf9Nghp StreamIndex is ubyte AccessUnit is some class
Re: Garbage collector collects live objects
On 12/9/14 3:18 PM, Ali Çehreli wrote: On 12/09/2014 11:56 AM, Steven Schveighoffer wrote: i checked attributes for GC block holding this array: ``` FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR ``` That does not sound right at all. No block should ever have both FINALIZE (reserved for objects only) and APPENDABLE (reserved for arrays only). FINALIZE and APPENDABLE together sounds like an array that holds class objects. I think I get it as I write this: Do we mean that the array should always hold class references and the class objects should live on other blocks? If so, the memory block for the objects can be marked as FINALIZE? Yes, that's exactly right. A class is never allocated inline inside another object or an array. What block should be APPENDABLE? The array of class references can be APPENDABLE. Of course, this may be all in the documentation but I can't understand it. ;) Here is what is says for FINALIZE: Finalize the data in this block on collect. (I will study that part a little more. :p) http://dlang.org/phobos/core_memory.html#.GC.BlkAttr.FINALIZE In truth, the code expects the block then to have a ClassInfo pointer at the beginning of the block. See here: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L1225 -Steve
Re: Garbage collector collects live objects
On 12/9/14 3:24 PM, Ruslan Mullakhmetov wrote: On Tuesday, 9 December 2014 at 19:56:30 UTC, Steven Schveighoffer wrote: On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote: On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote: i checked attributes for GC block holding this array: FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR That does not sound right at all. No block should ever have both FINALIZE (reserved for objects only) and APPENDABLE (reserved for arrays only). here the piece of code i used to output this value http://pastebin.com/cQf9Nghp I literally had to compile this for myself before I saw the error: if(bi k) = if(bi k) Though that doesn't explain all the issues you reported. I'm curious what the output is after that though... -Steve
Re: Can someone explain why this outputs garbage values?
On Tuesday, 9 December 2014 at 20:24:18 UTC, Adam D. Ruppe wrote:
Also, the reason why the special function is needed is that the
argptr is just a pointer to the arguments. If you pass that to
printf, how does it know that there's varargs on the other end
instead of just being another pointer whose numeric value it is
supposed to print out?
I got it to work with vsnprintf with the following code:
___
import core.vararg;
import std.string : toStringz;
import std.c.stdio : printf;
char[256] buffer;
extern(C) void vsnprintf(char* s, ulong n, const(char*) format,
va_list arg);
void print(string fmt, ...)
{
char* dest = buffer.ptr;
va_list list;
va_start(list, fmt);
vsnprintf(dest, 256UL, toStringz(fmt), list);
printf(dest);
}
void main(string[] args)
{
print(%d, %d, %d\n, 1, 2, 3);
}
___
I did have to declare my own function prototype because importing
vsnprintf from std.c.stdio produced the following error:
test.d(13): Error: function core.stdc.stdio._vsnprintf (char* s,
ulong n, const(char*) format, __va_list_tag* arg) is not callable
using argument types (char*, ulong, immutable(char)*, char*)
It works fine with my own function declaration though...
(I'm using LDC on Win64)
How to share modules when using -shared?
I'm trying to build components that I can dynamically link and keep running into an issue with sharing modules between the host and the pluggable components. Assuming a layout like this: host.d -- loads components at runtime a.d -- a module that builds to `a.so` b.d -- a module that builds to `b.so` common.d If a.d and b.d both import common.d, all is well. If host.d imports common.d as well, I get this at runtime: Fatal Error while loading 'a.so': The module 'common' is already defined in 'host'. Test session with sources here: http://pastebin.com/LxsqHhJm Some of this can be worked around by having host.d use its own extern definitions, but how does this work with interfaces? My tests thus far have resulted in object invariant failures.
Re: Garbage collector collects live objects
On Tue, 09 Dec 2014 17:18:44 + Ruslan Mullakhmetov via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: thanks, I got it: either C++ or D dtors are minefield =) and in D this is filed *made* of mines. ;-) but i still have no clue how to overcome GC =( why do you want to fight with GC? most of the time GC is your friend. are you trying to have predictable finalization? you don't have to fight with GC in this case too, there are alot of other methods. wrapper structs, `scoped!`, `RefCounted` and so on. you can have weak references too (this is a hack, but it should work until we got compacting (or precise?) GC ;-). signature.asc Description: PGP signature
