Re: Today's programming challenge - How's your Range-Fu ?
On Monday, 20 April 2015 at 03:39:54 UTC, ketmar wrote: On Mon, 20 Apr 2015 01:27:36 +, Nick B wrote: Perhaps Unicode needs to be rebuild from the ground up ? alas, it's too late. now we'll live with that "unicode" crap for many years. Perhaps. or perhaps not. This community got together under Walter and Andrei leadership to building a new programming language, on the pillars of the old. Perhaps a new Unicode standard, could start that way as well ?
Re: druntime unit test failures on FreeBSD
On Monday, April 20, 2015 04:36:35 Joakim via Digitalmars-d wrote: > On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote: > > LOL. Well, I just switched to FreeBSD from Linux so that I > > could take proper > > advantage of ZFS, so I may be stuck looking random problems > > that pop up on > > FreeBSD - though this is consistent enough that I'd expect to > > see it on the > > autotester, so I'm quite confused. > > There was a random deadlock issue on FreeBSD a little while back, > could be related to that: > > https://issues.dlang.org/show_bug.cgi?id=13416 Hmmm. Maybe it's core-related. I have 6 cores with hyperthreading on my machine - so, effectively 12 - which is more than the autotester has according to that bug report, though if you're running yours in VM, I would assume that it has fewer cores, and you're still seeing the problem. - Jonathan M Davis
Re: druntime unit test failures on FreeBSD
On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote: LOL. Well, I just switched to FreeBSD from Linux so that I could take proper advantage of ZFS, so I may be stuck looking random problems that pop up on FreeBSD - though this is consistent enough that I'd expect to see it on the autotester, so I'm quite confused. There was a random deadlock issue on FreeBSD a little while back, could be related to that: https://issues.dlang.org/show_bug.cgi?id=13416
Re: 64bit linking on Windows without Visual Studio
On Monday, 20 April 2015 at 04:05:21 UTC, Jeremiah DeHaan wrote: Hey all, While browsing the other day I stumbled across a linker called polink (part of the Pelles C suite). After only a few tries I got a working 64bit Hello World executable to be produced using it. The terms of service is incredibly permissive, and it looks like we can use it how ever we want (though this would need confirmation). I'm wondering if this could be a possible replacement for needing to install Visual Studio along side the D compiler. Thoughts? There are three aspects of Visual Studio used for D's Win64 support: the Microsoft C compiler to compile a few C files in COFF64 format, the Microsoft COFF64 linker, and the Microsoft C library in COFF64 format. Replacing only one will not get you very far.
Re: 64bit linking on Windows without Visual Studio
On Mon, 20 Apr 2015 04:05:19 +, Jeremiah DeHaan wrote: > Hey all, > > While browsing the other day I stumbled across a linker called polink > (part of the Pelles C suite). After only a few tries I got a working > 64bit Hello World executable to be produced using it. The terms of > service is incredibly permissive, and it looks like we can use it how > ever we want (though this would need confirmation). I'm wondering if > this could be a possible replacement for needing to install Visual > Studio along side the D compiler. > > Thoughts? i think that even if it can't be distributed with DMD, it would be great to write about it in Wiki, so we can direct people there. signature.asc Description: PGP signature
64bit linking on Windows without Visual Studio
Hey all, While browsing the other day I stumbled across a linker called polink (part of the Pelles C suite). After only a few tries I got a working 64bit Hello World executable to be produced using it. The terms of service is incredibly permissive, and it looks like we can use it how ever we want (though this would need confirmation). I'm wondering if this could be a possible replacement for needing to install Visual Studio along side the D compiler. Thoughts?
Re: Today's programming challenge - How's your Range-Fu ?
On Mon, 20 Apr 2015 01:27:36 +, Nick B wrote: > Perhaps Unicode needs to be rebuild from the ground up ? alas, it's too late. now we'll live with that "unicode" crap for many years. signature.asc Description: PGP signature
Re: druntime unit test failures on FreeBSD
On Sunday, April 19, 2015 08:18:55 Joakim via Digitalmars-d wrote: > I dusted off the old FreeBSD VM I had lying around and tried it > out. For me, it hangs in core.thread on FreeBSD 9.1 i386 from a > couple years ago when I try to run the druntime unit tests with > dmd/druntime HEAD. At least most of the time, I just tried it > again and it returned and passed once, out of ten times. Lovely. That certainly begs the question as to what the autotester boxes are doing differently then, since they're not seeing the problem. It wouldn't surprise me in the least if they're runnig an older version of FreeBSD, but you're clearly running one that's far from up-to-date. :| LOL. Well, I just switched to FreeBSD from Linux so that I could take proper advantage of ZFS, so I may be stuck looking random problems that pop up on FreeBSD - though this is consistent enough that I'd expect to see it on the autotester, so I'm quite confused. - Jonathan M Davis
Re: I need dmd2's Arm platform compile.
On Sunday, April 19, 2015 18:45:25 Brian via Digitalmars-d wrote: > I need to use DMD compilation arm or arm64 version, don't know > DMD now support for the arm. > > I think it is very important to the arm of a structure, such as > rust/go is good enough to support the architecture. > > I hope we can improve in arm. dmd only supports x86 and x86_64, and I wouldn't expect that to change, given the backend that it uses and how much work it would be to add additional platforms. If you want support for other plaftorms, you're going to have to look at ldc or gdc. I know that work has been done to support ARM there, but I don't know what its current state is. - Jonathan M Davis
Re: Today's programming challenge - How's your Range-Fu ?
On Sunday, 19 April 2015 at 19:58:28 UTC, ketmar wrote: On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: it's not crazy, it's just broken in all possible ways: http://file.bestmx.net/ee/articles/uni_vs_code.pdf Ketmar Great link, and a really good arguement about the problems with Unicode. Quote from 'Instead of Conclusion' Yes. This is the root of Unicode misdesign. They mixed up two mutually exclusive approaches. They blended badly two different abstraction levels: the textual level which corresponds to a language idea and the graphical level which does not care of a language, yet cares of writing direction, subscripts, superscripts and so on. In other words we need two different Unicodes built on these two opposite principles, instead of the one built on an insane mix of controversial axioms. end quote. Perhaps Unicode needs to be rebuild from the ground up ?
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 13:03:22 UTC, ANtlord wrote: On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with "[hackathon]". (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear. I can't speak for Andrei, but I think this is more of a casual "do some work on something valuable to D" session rather than a formal hackathon. I think everyone will be working remotely.
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 19:38:14 UTC, Gary Willoughby wrote: Also the tools repository needs work to build too. This is because of the `if(arr)` warnings. I think there are pull requests waiting[2] but until they are merged a few of the tools are broken which breaks the whole build. Dustmite also needs to be amended upstream[3]. Waiting on definitive yes/no regarding the compiler change and code breakage from Walter/Andrei.
Re: Today's programming challenge - How's your Range-Fu ?
On Sunday, 19 April 2015 at 19:58:28 UTC, ketmar wrote: On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: é might be obvious, but Unicode isn't just for writing European prose. it is also to insert pictures of the animals into text. There's other uses for unicode? 🐧
Re: Today's programming challenge - How's your Range-Fu ?
On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: > é might be obvious, but Unicode isn't just for writing European prose. it is also to insert pictures of the animals into text. > Unicode is a nightmarish system in some ways, but considering how > incredibly difficult the problem it solves is, it's actually not too > crazy. it's not crazy, it's just broken in all possible ways: http://file.bestmx.net/ee/articles/uni_vs_code.pdf signature.asc Description: PGP signature
Re: [hackathon] One week left to the first D Hackathon!
On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with "[hackathon]". (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei This sounds awesome! I'm going to give the website and phobos documentation a pass making corrections and adding examples, beefing up, etc. So i'll trawl bugzilla looking for low hanging fruit/easy stuff to get my feet wet. I've run into a few problems[1] with building the website and documentation. DMD, druntime and phobos all build easily but dlang.org sources are a pain. I wonder if anyone has built the website recently from scratch to make sure it all works? Also the tools repository needs work to build too. This is because of the `if(arr)` warnings. I think there are pull requests waiting[2] but until they are merged a few of the tools are broken which breaks the whole build. Dustmite also needs to be amended upstream[3]. [1]: http://forum.dlang.org/thread/wwktjyurctmdffmfe...@forum.dlang.org [2]: https://github.com/D-Programming-Language/tools/pull/166/files [3]: https://github.com/CyberShadow/DustMite
I need dmd2's Arm platform compile.
I need to use DMD compilation arm or arm64 version, don't know DMD now support for the arm. I think it is very important to the arm of a structure, such as rust/go is good enough to support the architecture. I hope we can improve in arm.
Re: Request for testers: GDC-5.1 Release Candidate branched
On Sunday, 19 April 2015 at 12:04:19 UTC, Stefan Frijters wrote: On Sunday, 19 April 2015 at 07:13:16 UTC, Iain Buclaw wrote: Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added "goto" support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes "section", "weak" and "alias" - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain. I don't have too much to report (which is a good thing in this case): I did a fresh install from source, following [1], and I didn't encounter any problems. I was already compiling my code with an earlier GDC version that used the 2.066.1 front-end (which is required for my code) because it gives me a 2.5x speed increase for my code execution (in my Linux VM at least), so I love the new release already :-D Cheers, Stefan [1] http://wiki.dlang.org/GDC/Installation/Generic thank you for work, i like it :) but, this version support android?
Re: I have made a discovery
On 2015-04-19 11:57, w0rp wrote: I'm not sure how that will end up looking in the end, but I am reminded of Objective C again, where allocation and construction are explicitly separated. // Enough time in Wonderland makes this seem perfectly natural. MyClass* foo = [[MyClass alloc] initWithNumber:3]; And in Swift they removed then need to call "alloc". -- /Jacob Carlborg
Re: Request for testers: GDC-5.1 Release Candidate branched
On 19 April 2015 at 13:52, Iain Buclaw wrote: > On 19 April 2015 at 13:50, Iain Buclaw wrote: >> On 19 April 2015 at 09:13, Iain Buclaw wrote: >>> >>> Last feature I am working on getting in is runtime exception chaining >>> support. If anyone has any grand ideas, they'd be more than welcome. >>> >> >> First attempt: >> https://github.com/D-Programming-GDC/GDC/compare/master...ibuclaw:eh_chaining >> >> Can someone have a review? In particular, I'd like to know when and >> when not to chain Exception and/or Error objects together. >> > > For instance, if a new exception is thrown inside a catch handler, > what then? If a caught exception is thrown, what then? > Ah ha! After some pretty intense studying, looks like libunwind gives enough information for us to distinguosh which thrown objects should be stringed together. All what I think is needed is for gdc to emit some __begin_catch call which builds and returns the constructed Exception object to be passed to user-land. Regards Iain.
Re: Any D plugins for recent Xcode?
On 2015-04-19 00:28:14 +, Michel Fortin said: On 2015-04-18 20:18:56 +, Dan Olson said: Yeah, I was hoping somone might have done the same for Xcode 6. I've never poked at how Xcode plugins works, maybe somehow it can be upgraded. I have gotten the impression that the Xcode plugin API changes often and is undocumented, making it hard to maintain something non-Apple. It's undocumented API, and they sometime change it although not that much. Xcode 4 broke the plugin and I didn't put much effort into figuring out what was wrong. Feel free to fork and fix it if you want, the code is on Github. https://github.com/michelf/d-for-xcode/ I just realized, I have some unpushed changes on my computer that aren't on Github. I probably never pushed them because it didn't work well enough, but it might be closer to something that works. If someone want to sort things out, I pushed those to a separate branch "xcode-4-work". -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: [hackathon] One week left to the first D Hackathon!
On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with "[hackathon]". (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear.
Re: Request for testers: GDC-5.1 Release Candidate branched
On Sunday, 19 April 2015 at 07:13:16 UTC, Iain Buclaw wrote: Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added "goto" support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes "section", "weak" and "alias" - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain. I don't have too much to report (which is a good thing in this case): I did a fresh install from source, following [1], and I didn't encounter any problems. I was already compiling my code with an earlier GDC version that used the 2.066.1 front-end (which is required for my code) because it gives me a 2.5x speed increase for my code execution (in my Linux VM at least), so I love the new release already :-D Cheers, Stefan [1] http://wiki.dlang.org/GDC/Installation/Generic
Re: I have made a discovery
On 19/04/2015 11:48 p.m., Adam D. Ruppe wrote: On Sunday, 19 April 2015 at 02:50:59 UTC, Rikki Cattermole wrote: So I went with closest I thought it was to make the point. I don't understand what the point is... is it just syntax? I was just toying with different syntax's regarding allocation. Atleast to me, none of them really fit.
Re: Request for testers: GDC-5.1 Release Candidate branched
On 19 April 2015 at 13:50, Iain Buclaw wrote: > On 19 April 2015 at 09:13, Iain Buclaw wrote: >> >> Last feature I am working on getting in is runtime exception chaining >> support. If anyone has any grand ideas, they'd be more than welcome. >> > > First attempt: > https://github.com/D-Programming-GDC/GDC/compare/master...ibuclaw:eh_chaining > > Can someone have a review? In particular, I'd like to know when and > when not to chain Exception and/or Error objects together. > For instance, if a new exception is thrown inside a catch handler, what then? If a caught exception is thrown, what then? Regards Iain.
Re: I have made a discovery
On Sunday, 19 April 2015 at 02:50:59 UTC, Rikki Cattermole wrote: So I went with closest I thought it was to make the point. I don't understand what the point is... is it just syntax?
Re: Request for testers: GDC-5.1 Release Candidate branched
On 19 April 2015 at 09:13, Iain Buclaw wrote: > > Last feature I am working on getting in is runtime exception chaining > support. If anyone has any grand ideas, they'd be more than welcome. > First attempt: https://github.com/D-Programming-GDC/GDC/compare/master...ibuclaw:eh_chaining Can someone have a review? In particular, I'd like to know when and when not to chain Exception and/or Error objects together. Regards Iain.
Re: I have made a discovery
On Sunday, 19 April 2015 at 09:57:52 UTC, w0rp wrote: The interesting thing about this is that 'throw new ExceptionType(...)' could be reference counted. The downside of What's wrong with just putting exceptions in a dedicated memory area like C++?
Re: Any D plugins for recent Xcode?
On 2015-04-19 02:28, Michel Fortin wrote: It's undocumented API, and they sometime change it although not that much. Xcode 4 broke the plugin and I didn't put much effort into figuring out what was wrong. Feel free to fork and fix it if you want, the code is on Github. https://github.com/michelf/d-for-xcode/ Xcode 4 was a big change compared to Xcode 3. Hopefully there aren't that many changes in later versions. There are many other plugins that work with Xcode 6 that one can look at. There's even a package manager for Xcode plugins [1], which is a good starting point to find other plugins. [1] http://alcatraz.io/ -- /Jacob Carlborg
Re: I have made a discovery
The interesting thing about this is that 'throw new ExceptionType(...)' could be reference counted. The downside of not getting rid of the 'new' overloading at some point is that it can make the operator do surprising and unexpected things, so the rationale for getting rid of it is similar to the rationale behind disallowing overloading of '&&' and '||'. What I found more interesting is that class constructors themselves can be marked @nogc, which I never thought to do before. So whatever syntax we end up with for 'allocate with this other allocator and call this constructor' could take advantage of that. I'm not sure how that will end up looking in the end, but I am reminded of Objective C again, where allocation and construction are explicitly separated. // Enough time in Wonderland makes this seem perfectly natural. MyClass* foo = [[MyClass alloc] initWithNumber:3];
Re: Today's programming challenge - How's your Range-Fu ?
On Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: U0065+U0301 rather than U00e9. Because of legacy systems, and because they would rather have the ISO-8509 code pages be 1:1 mappings, rather than 1:n mappings, they introduced code points they really would rather do without. That's probably right. It is in fact a major feat to have the world adopt a new standard wholesale, but there are also difficult "semiotic" issues when you encode symbols and different languages view symbols differently (e.g. is "ä" an "a" or do you have two unique letters in the alphabet?) Take "å", it can represent a unit (ångström) or a letter with a circle above it, or a unique letter in the alphabet. The letter "æ" can be seen as a combination of "ae" or a unique letter. And we can expect languages, signs and practices to evolve over time too. How can you normalize encodings without normalizing writing practice and natural language development? That would be beyond the mandate of a unicode standard organization...
Re: Any D plugins for recent Xcode?
On 2015-04-18 22:18, Dan Olson wrote: Another approach is to use different IDE that can supports iOS dev (download, debug). Not sure what is available, but these folks setup Eclipse for Java iOS dev. Xamarin [1] seems to have pretty good support for iOS development. They collaborating with Microsoft to make C# (.Net) the first choice for developing cross-platform mobile applications. Their IDE is based on (or the new) MonoDevelop, which a D plugin already exists for, Mono-D [2]. I've look at a couple of their talks and it looks really good. Although I still prefer to use Xcode. [1] http://xamarin.com/ [2] https://github.com/aBothe/Mono-D -- /Jacob Carlborg
Re: Today's programming challenge - How's your Range-Fu ?
On 19/04/15 10:51, Abdulhaq wrote: MiOn Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: On 18/04/15 21:40, Walter Bright wrote: Also, notice that some letters can only be achieved using multiple code points. Hebrew diacritics, for example, do not, typically, have a composite form. My name fully spelled (which you rarely would do), שַׁחַר, cannot be represented with less than 6 code points, despite having only three letters. Yes Arabic is similar too Actually, the Arab presentation forms serve a slightly different purpose. In Hebrew, the presentation forms are mostly for Bibilical text, where certain decorations are usually done. For Arabic, the main reason for the presentation forms is shaping. Almost every Arabic letter can be written in up to four different forms (alone, start of word, middle of word and end of word). This means that Arabic has 28 letters, but over 100 different shapes for those letters. These days, when the font can do the shaping, the 28 letters suffice. During the DOS days, you needed to actually store those glyphs somewhere, which means that you needed to allocate a number to them. In Hebrew, some letters also have a final form. Since the numbers are so significantly smaller, however, (22 letters, 5 of which have final forms), Hebrew keyboards actually have all 27 letters on them. Going strictly by the "Unicode way", one would be expected to spell שלום with U05DE as the last letter, and let the shaping engine figure out that it should use the final form (or add a ZWNJ). Since all Hebrew code charts contained a final form Mem, however, you actually spell it with U05DD in the end, and it is considered a distinct letter. Shachar
Re: if(arr) now a warning
On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote: On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote: I think it's worth changing this. if (arr) translating to if (arr.length == 0) Is immediately obvious for anyone coming from at least a Python background. I have implemented my own hashmaps in a similar way. For my maps, the length is stored in the map so it can be retrieved in O(1) time, and cast(bool) results in map.length == 0. (This extends also to empty sets.) If we need a deprecation path, we can do it. We just warn about if (arr) for a while, so you are told to use if(arr.length == 0) or if (arr.ptr is null) for a while, then we change the behaviour in another release. I agree with the change, because the current behavior is error-prone. However, I'd just as soon leave if(arr) as illegal so that there's no confusion over it later. Just because one set of folks think that if(arr) is clearly equivalant to if(arr.length != 0) doesn't mean another set of folks will - especially if it's based on what other languages are up to. For instance, while python folks might think that it would be intuitive if if(arr) were equivalent to if(arr.length != 0), the C folks would think that the current behavior of it being equivalent to if(arr is null) would be more intuitive, since they're used to thinking of arrays as pointers. By simply forcing folks to be explicit and say if(arr.length != 0) or if(arr is null), we avoid the problem entirely. - Jonathan M Davis Unfortunately it also disables this very useful idiom: if(auto name = getName()) I.e. declaration and conditional in one.
Re: nginx module bindings
On 2015-04-19 01:03, Shammah Chancellor wrote: I included the -I flag for the location of those included headers. It seems as if maybe it is not including anything. With that said, I am using clan release_34, because I cannot build 32 on MacOS X. Is there a build script you can inspect to see if it does anything magic? These [1] are the versions that are tested by Travis on OS X. You can always download pre-compiled versions of libclang here [2]. libclang can be placed in any of the standard search paths or in the same directory as the binary. [1] https://github.com/jacob-carlborg/dstep/blob/master/test.d#L321-L327 [2] http://llvm.org/releases/index.html -- /Jacob Carlborg
Re: Any D plugins for recent Xcode?
On Saturday, 18 April 2015 at 20:18:56 UTC, Dan Olson wrote: Yeah, I was hoping somone might have done the same for Xcode 6. I've never poked at how Xcode plugins works, maybe somehow it can be upgraded. I have gotten the impression that the Xcode plugin API changes often and is undocumented, making it hard to maintain something non-Apple. http://www.joelonsoftware.com/articles/fog000339.html
Re: I have made a discovery
On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote: Consider also the coming addition to the language for class reference counting methods opAddRef and opRelease. Since it's classes we are talking about, wouldn't that mean we need to do a virtual function call each time a class reference gets assigned or goes out of scope(and twice when it gets reassigned)?
Re: Why is object.opEquals not defined as pure?
On Sunday, April 19, 2015 08:03:09 Muahmmad Adel via Digitalmars-d wrote:
> The following method definition is not possible because
> object.opEquals is not defined as pure.
>
> private pure ushort GetTypeHexadecimalValue(TypeInfo myType)
> {
> if (myType == typeid(byte))
> return 0x01;
> // some similar lines for other different basic types
>
> throw new Exception("Unknown type passed");
> }
>
> What is the reason behind this? is opEquals modifying any global
> or object member variables?
If it were pure, then _every_ class' opEquals would have to be pure. The
same goes with const, @safe, and nothrow. And while some of those attributes
work for most implementations, they don't work for all - especially when
stuff like caching or lazy initialization gets involved. opEquals, opCmp,
toString, and toHash all have this problem. After much discussion on this in
the past, it was decided to remove all 4 of those functions from Object,
forcing base classes to implement them. Unlike in Java or C#, we have proper
templates, so there's really no need to use Object to call those functions,
and it should work to not have them on Object at all.
The problem is that that change hasn't been implemented yet. It was agreed
upon, and some work has been done towards it, but it's nowhere near
complete (e.g. the work required to templatize the free function opEquals
which calls opEquals on class instances has been blocked by compiler bugs).
So, we really haven't done what needs to be done to get this problem solved,
and until we do, the attribute situation on Object's built-in functions is a
bit of a mess.
The associated issues in bugzilla:
https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772
- Jonathan M Davis
Re: druntime unit test failures on FreeBSD
On Sunday, 19 April 2015 at 07:36:13 UTC, Jonathan M Davis wrote: I am consistently seeing this when I try and run druntime's unit tests on FreeBSD for either 2.067 or master: 0.000s PASS release64 object 0.000s PASS release64 core.atomic 0.008s PASS release64 core.bitop 0.000s PASS release64 core.checkedint 0.000s PASS release64 core.demangle 0.000s PASS release64 core.exception 0.000s PASS release64 core.math 0.000s PASS release64 core.memory posix.mak:230: recipe for target 'obj/64/core/thread' failed gmake: *** [obj/64/core/thread] Illegal instruction gmake: *** Deleting file 'obj/64/core/thread' 2.066 works fine, so I assume that something was introduced since then, but clearly the autotesters are working for FreeBSD, so I have to wonder whether I have an environmental problem with my machine or whether I've just done something differently from the autotesters and am hitting a problem in either the compiler or in druntime that's a general problem that the autotester doesn't hit for whatever reason. I'm running the latest 64-bit PC-BSD. I have no idea what the autotesters are running. Is anyone else seeing anything like this? I dusted off the old FreeBSD VM I had lying around and tried it out. For me, it hangs in core.thread on FreeBSD 9.1 i386 from a couple years ago when I try to run the druntime unit tests with dmd/druntime HEAD. At least most of the time, I just tried it again and it returned and passed once, out of ten times.
Re: DIP76: Autodecode Should Not Throw
On Monday, April 06, 2015 20:16:19 Walter Bright via Digitalmars-d wrote: > http://wiki.dlang.org/DIP76 I am fully in favor of this. Most code really doesn't care about invalid unicode, and if it does, it can check explicitly. Using the replacement character is much cleaner and follows the Unicode standard. And in my experience, if I run into invalid Unicode, I generally have to process it regardless, forcing me to do something like use the replacement character anyway. The fact that std.utf.decode throws just becomes an annoyance. About the only real downside to this that I can think of is that if you're writing a new string algorithm, and you botch it such that it mangles the Unicode, right now, you'd quickly get exceptions, whereas with this change, you wouldn't. But if you're testing your string-based code with Unicode rather than just ASCII, then that should still get caught. Regardless, I think that this is the way to go. - Jonathan M Davis
Re: if(arr) now a warning
On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote: > I think it's worth changing this. > > if (arr) > > translating to > > if (arr.length == 0) > > Is immediately obvious for anyone coming from at least a Python > background. I have implemented my own hashmaps in a similar way. > For my maps, the length is stored in the map so it can be > retrieved in O(1) time, and cast(bool) results in map.length == > 0. (This extends also to empty sets.) > > If we need a deprecation path, we can do it. We just warn about > if (arr) for a while, so you are told to use if(arr.length == 0) > or if (arr.ptr is null) for a while, then we change the behaviour > in another release. I agree with the change, because the current behavior is error-prone. However, I'd just as soon leave if(arr) as illegal so that there's no confusion over it later. Just because one set of folks think that if(arr) is clearly equivalant to if(arr.length != 0) doesn't mean another set of folks will - especially if it's based on what other languages are up to. For instance, while python folks might think that it would be intuitive if if(arr) were equivalent to if(arr.length != 0), the C folks would think that the current behavior of it being equivalent to if(arr is null) would be more intuitive, since they're used to thinking of arrays as pointers. By simply forcing folks to be explicit and say if(arr.length != 0) or if(arr is null), we avoid the problem entirely. - Jonathan M Davis
Why is object.opEquals not defined as pure?
The following method definition is not possible because
object.opEquals is not defined as pure.
private pure ushort GetTypeHexadecimalValue(TypeInfo myType)
{
if (myType == typeid(byte))
return 0x01;
// some similar lines for other different basic types
throw new Exception("Unknown type passed");
}
What is the reason behind this? is opEquals modifying any global
or object member variables?
Re: Today's programming challenge - How's your Range-Fu ?
MiOn Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: On 18/04/15 21:40, Walter Bright wrote: I'm not arguing against the existence of the Unicode standard, I'm saying I can't figure any justification for standardizing different encodings of the same thing. A lot of areas in Unicode are due to pre-Unicode legacy. I'm guessing here, but looking at the code points, é (U00e9 - Latin small letter E with acute), which comes from Latin-1, which is designed to follow ISO-8859-1. U0301 (Combining acute accent) comes from "Combining diacritical marks". The way I understand things, Unicode would really prefer to use U0065+U0301 rather than U00e9. Because of legacy systems, and because they would rather have the ISO-8509 code pages be 1:1 mappings, rather than 1:n mappings, they introduced code points they really would rather do without. This also explains the "presentation forms" code pages (e.g. http://www.unicode.org/charts/PDF/UFB00.pdf). These were intended to be glyphs, rather than code points. Due to legacy reasons, it was not possible to simply discard them. They received code points, with a warning not to use these code points directly. Also, notice that some letters can only be achieved using multiple code points. Hebrew diacritics, for example, do not, typically, have a composite form. My name fully spelled (which you rarely would do), שַׁחַר, cannot be represented with less than 6 code points, despite having only three letters. The last paragraph isn't strictly true. You can use UFB2C + U05B7 for the first letter instead of U05E9 + U05C2 + U05B7. You would be using the presentation form which, as pointed above, is only there for legacy. Shachar or shall I say שחר Yes Arabic is similar too
Re: Today's programming challenge - How's your Range-Fu ?
On Saturday, 18 April 2015 at 17:50:12 UTC, Walter Bright wrote: On 4/18/2015 4:35 AM, Jacob Carlborg wrote: \u0301 is the "combining acute accent" [1]. [1] http://www.fileformat.info/info/unicode/char/0301/index.htm I won't deny what the spec says, but it doesn't make any sense to have two different representations of eacute, and I don't know why anyone would use the two code point version. é might be obvious, but Unicode isn't just for writing European prose. Uses for combining characters includes (but is *nowhere* near to limited to) mathematical notation, where the combinatorial explosion of possible combinations that still belong to one grapheme cluster (character is a familiar but misleading word when talking about Unicode) would trivially become an insanely (more atoms than in the universe levels of) large number of characters. Unicode is a nightmarish system in some ways, but considering how incredibly difficult the problem it solves is, it's actually not too crazy.
druntime unit test failures on FreeBSD
I am consistently seeing this when I try and run druntime's unit tests on FreeBSD for either 2.067 or master: 0.000s PASS release64 object 0.000s PASS release64 core.atomic 0.008s PASS release64 core.bitop 0.000s PASS release64 core.checkedint 0.000s PASS release64 core.demangle 0.000s PASS release64 core.exception 0.000s PASS release64 core.math 0.000s PASS release64 core.memory posix.mak:230: recipe for target 'obj/64/core/thread' failed gmake: *** [obj/64/core/thread] Illegal instruction gmake: *** Deleting file 'obj/64/core/thread' 2.066 works fine, so I assume that something was introduced since then, but clearly the autotesters are working for FreeBSD, so I have to wonder whether I have an environmental problem with my machine or whether I've just done something differently from the autotesters and am hitting a problem in either the compiler or in druntime that's a general problem that the autotester doesn't hit for whatever reason. I'm running the latest 64-bit PC-BSD. I have no idea what the autotesters are running. Is anyone else seeing anything like this? - Jonathan M Davis
Re: Today's programming challenge - How's your Range-Fu ?
On Saturday, 18 April 2015 at 16:01:20 UTC, Andrei Alexandrescu
wrote:
On 4/18/15 4:35 AM, Jacob Carlborg wrote:
On 2015-04-18 12:27, Walter Bright wrote:
That doesn't make sense to me, because the umlauts and the
accented e
all have Unicode code point assignments.
This code snippet demonstrates the problem:
import std.stdio;
void main ()
{
dstring a = "e\u0301";
dstring b = "é";
assert(a != b);
assert(a.length == 2);
assert(b.length == 1);
writefln(a, " ", b);
}
If you run the above code all asserts should pass. If your
system
correctly supports Unicode (works on OS X 10.10) the two
printed
characters should look exactly the same.
\u0301 is the "combining acute accent" [1].
[1] http://www.fileformat.info/info/unicode/char/0301/index.htm
Isn't this solved commonly with a normalization pass? We should
have a normalizeUTF() that can be inserted in a pipeline. Then
the rest of Phobos doesn't need to mind these combining
characters. -- Andrei
Normalisation can allow some simplifications, sometimes, but
knowing whether it will or not requires a lot of a priori
knowledge about the input as well as the normalisation form.
Request for testers: GDC-5.1 Release Candidate branched
Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added "goto" support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes "section", "weak" and "alias" - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain.
Re: SDC needs you -- redux
On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu wrote: Cool, thanks! Looking forward to tips from Go users about which tools are most appreciated and appropriate for a D incarnation. -- Andrei gofmt -r 'foo -> bar' - accurate, context-sensitive renaming without need for any external tool.
