Re: New homepage design of d-p-l.org is now live. eom
Andrei Alexandrescu Wrote: http://d-p-l.org Andrei http://www.d-programming-language.org/phobos/index.html Google translation tool bar is missing
Re: Release: MinGW GCC 4.6.1 GDC 1.070/2,.055
On 06-12-2011 02:46, Trass3r wrote: Why is D1 still the default? Because this is the first release where I felt D2 was capable of being the default and I forgot about it until writing the post. It also requires some reworking of the changes that enable dual compilers. but why is there a zip version anyway? I posted with a zip extension in the original post, so rather than letting everyone get an 404 error, I just uploaded a zip file. I see. btw, is there something like gdmd for Windoze too? That would be very helpful, indeed! I don't feel like rewriting all of my makefiles to use GDC's parameter syntax. ;) - Alex
Re: D Addin for MonoDevelop on Linux
On 06-12-2011 07:06, alex wrote: 1) Code completion can be enabled via adding phobos library paths etc. to the compiler configuration(s). There's a tutorial how to do this in the 'Getting Started' section of the project site. That did the trick, thanks! 2) You can add per-project (both linker and compiler) parameters. Extra include paths and library references, of course. Oh wow, completely missed the relevant section in project options. Oops! 3) Yes. Great! - Alex
Re: D Addin for MonoDevelop on Linux
On 05-12-2011 20:35, alex wrote:
Hi everyone,
I just want to announce the first alpha release of Mono-D.
FYI, Mono-D is a MonoDevelop AddIn which provides code completion/refactoring
features and project management for D.
So, you'll be able to enjoy comfort-features also on non-windows systems!
Just check out http://mono-d.sourceforge.net
Please feel free to leave comments/critics etc. on that blog!
Hm, it doesn't seem like the add-in uses smart indentation. For example:
void main()
{hit enter
doesn't indent as it normally would in e.g. the C# add-in. Is this a bug
or just not supported yet?
- Alex
Re: D Addin for MonoDevelop on Linux
Sorry, but it's not implemented yet.
Re: D Addin for MonoDevelop on Linux
Good work. Tested on Ubuntu 64bit with Monodevelop 2.8 compiled from source. Works fine and it's very responsive (code completion is too responsive!) Bug: syntax highlight for test works but not for `test` alex Wrote: Hi everyone, I just want to announce the first alpha release of Mono-D. FYI, Mono-D is a MonoDevelop AddIn which provides code completion/refactoring features and project management for D. So, you'll be able to enjoy comfort-features also on non-windows systems! Just check out http://mono-d.sourceforge.net Please feel free to leave comments/critics etc. on that blog!
Re: New homepage design of d-p-l.org is now live. eom
On 12/6/11 12:19 AM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:jbka3d$2r2m$2...@digitalmars.com... http://d-p-l.org Nice, but a little reminder that the See Example links are still totally broken without JS. Should be easy to fix. May want to just simply them all shown by default when JS is off (and with the See/Hide Example links hidden, since they'd be useless). Not being an expert, I open the floor to pull requests. Also, the [your code here] link is really goofy. You're using JS to pop up a dialog box with instructions. Just make it a n ordinary page link to a small separate page, so: 1. People will be be able to select/copy/paste the text (esp the text digitalmars.D) 2. You can include links (for instance, to http://digitalmars.com/NewsGroup.html ) 3. Seriously, required JS just to show a few words of text? I know JS alert boxes are trivial, but so are new pages. I like the new homepage overall, but these little things (esp on a homepage) can make a site seem very unprofessional. There's so little content to display, I found the dialog most appropriate. Of course that doesn't work for people without JS. Andrei
Re: New homepage design of d-p-l.org is now live. eom
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:jblir0$20cv$3...@digitalmars.com... On 12/6/11 12:19 AM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:jbka3d$2r2m$2...@digitalmars.com... http://d-p-l.org Nice, but a little reminder that the See Example links are still totally broken without JS. Should be easy to fix. May want to just simply them all shown by default when JS is off (and with the See/Hide Example links hidden, since they'd be useless). Not being an expert, I open the floor to pull requests. Fair enough, I'll see what I can do...
Re: New homepage design of d-p-l.org is now live. eom
Nick Sabalausky a@a.a wrote in message news:jblp89$2blv$1...@digitalmars.com... Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:jblir0$20cv$3...@digitalmars.com... On 12/6/11 12:19 AM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:jbka3d$2r2m$2...@digitalmars.com... http://d-p-l.org Nice, but a little reminder that the See Example links are still totally broken without JS. Should be easy to fix. May want to just simply them all shown by default when JS is off (and with the See/Hide Example links hidden, since they'd be useless). Not being an expert, I open the floor to pull requests. Fair enough, I'll see what I can do... https://github.com/D-Programming-Language/d-programming-language.org/pull/38
Re: The current status of D?
Don:
Right. But it's hard to come up with high-priority language issues these days.
The old ones have been fixed. g.
There are several things that I'd like to see fixed/improved in D still. In
particular there are two holes from C language that have no place in D, I mean
code like:
x = x++;
Or code like (bar and baz are not pure):
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
You can't remove all undefined behaviours from D, but they must be reduced and
minimized, because D tries to lead to correct and deterministic programs.
A solution is to define the behaviour in those situations (and pay a bit of
performance in some cases), an alternative is to statically forbid some kinds
of code (and pay a bit of flexibility. C lints essentially forbid code like
x=x++;), or a mix of the two solutions. (Forbidding something is not so bad
because I've seen bad C code that mutates some variables inside a single
expression, and it's code that is not easy to understand and it's not easy to
translate to other languages).
Bye,
bearophile
Re: Java Scala
On 12/6/11, Jacob Carlborg d...@me.com wrote: Doesn't sound very effective. I don't know what that bubbling is all about. You can easily intercept a signal to a child window via std.signals, in Qt this would be installing an event filter of some sort. So sink/bubble seems unnecessary. The library is far from being efficient. It recreates a main window memory buffer on each paint message from the OS (IOW very often), also unless I'm mistaken the widgets themselves don't have a backbuffer so the library assumes their paint routines are not expensive. But that's fixable. I don't know why HTML was used, although that's just an alternative front-end to the library as far as I can tell. It does seem like this library died pretty quickly, I don't recall of any projects that used it. Anyway, I don't know if Adam wants to work on a native or non-native GUI, for native ones in pure-D (not a wrapper over existing GUIs) he can look at DFL or something else from here: http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries But the library is modular enough and could be used as a starting point, imo.
Re: Haxe (From: Java Scala - new thread: GUI for D)
Am 05.12.2011 18:56, schrieb Nick Sabalausky: In that project, Haxe's ability to compile the same code, in the same language, down to both server-side (PHP) and client-side (Flash8) has been an *enormous* benefit. Just that one ability alone, even without the fact that Haxe beats the snot of out both AS2 and PHP. I also use a slightly-hacked version of the HaxeIgniter framework (could be better, but it's not bad and it gets the job done). That said, I have been chomping at the bit to switch to D (and Adam's clever web framework) for my server-side code. I've pretty much managed to convince my client to eventually let us switch to a host that allows native-compiled CGI. The only problem now is that that would rule out the possibility of sharing code between both server and client - Which is *NOT* something I want to give up... That is exactly my point. HaXe' s ability to share the same code on client and server side is one of it's killer features. Together with a increasing number of target languages it fits almost everywhere. Currently I use the following setup for my development: - a web and database server written in pascal (Delphi) - all server modules written in haXe/neko - client - server communication via haXe - GUI client modules written either in Delphi with a small neko layer for the communication, or in haXe/Javascript in an embedded browser. shameless plug: So to that end, you mentioned Java and C# targets are coming to Haxe? Well, so is D... :) HaxeD: http://www.dsource.org/projects/haxed interesting - the last time I looked, I thought the project is abandoned. It's not at a usable point just yet, but the basics are in place, and at this point it's mostly just a matter of continuing to translate each of the different types of statements, expressions, declarations, etc. Details of the current status are on that homepage. (Haxe's macro system is a low priority for me right now though, unless someone else wants to work on that). Why did I write the whole thing from scratch in D as a separate tool, instead of just adding D support to the official Haxe codebase? Ehh, possibly-questionable reasons: 1. Because I looked at Haxe's source and decided I didn't feel like figuring out OCaml before getting started :/ yes OCaml is another beast. My idea was to take the source of Hugh Sandersons C++ target and adopt it to D. For me, D is a much more logical target for haXe, because many of the language features fit better together. The problem I see with your solution is, that haXe evolves very fast and a D target written in OCaml would benefit from this, whereas a target written in D is always behind. The last few months I am looking at D as a replacement for Delphi at least at the server side (which would be a major task rewriting the database server), but I am twisted at the moment, because I am not sure if D is mature enough ( and/or me good enough to master if not).
Re: The current status of D?
On 12/06/2011 09:37 AM, bearophile wrote:
Don:
Right. But it's hard to come up with high-priority language issues these days. The old
ones have been fixed.g.
There are several things that I'd like to see fixed/improved in D still. In
particular there are two holes from C language that have no place in D, I mean
code like:
x = x++;
Or code like (bar and baz are not pure):
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
I think ',' in parameter lists are already sequence points.
You can't remove all undefined behaviours from D, but they must be reduced and
minimized, because D tries to lead to correct and deterministic programs.
A solution is to define the behaviour in those situations (and pay a bit of
performance in some cases), an alternative is to statically forbid some kinds
of code (and pay a bit of flexibility. C lints essentially forbid code like
x=x++;), or a mix of the two solutions. (Forbidding something is not so bad
because I've seen bad C code that mutates some variables inside a single
expression, and it's code that is not easy to understand and it's not easy to
translate to other languages).
Bye,
bearophile
Re: Java Scala
On 12/6/11, Adam Wilson flybo...@gmail.com wrote: No worries, had to ask. Thanks for the link though, it looks promising. :-) Listen, if you ever need help I'm in #d, nickname drey_. I think we talked before. It's never a bad idea to exchange ideas, so I'll be there.
Re: ow Integers Should Work
Manu: but I don't believe I'm alone.. the rest of the gamedev community will find D soon enough if the language gets it right... I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games. I agree, it certainly didn't seem to be a major consideration early on, but I don't think any decisions yet made prohibit it from being well suited. If as you say, there is some focus to generate interest from the game community, it would be really nice to have a few binary GDC cross compiler distributions available (for windows, linux users never have problems building the toolchain themselves). ARM/PPC, maybe MIPS toolchains hosted somewhere on the website might really help encourage some people get started, and I'd love to spend some time on the standard libraries for these platforms. If you're suggesting the reason for trapping overflow's is specifically to CATCH bugs like this, then maybe make is a compiler flag when building a debug binary? (ie. assert on integer overflow). Right. I think D2/D3 has also a bit of hope to replace some of the purposes of Ada language. Walter maybe didn't think of it when he designed D, but D shares some design purposes with Ada. Walter past work in aeronautical engineering leads naturally to a language that shares some of the purposes of Ada. For such purposes correctness and reliability are of the highest importance, this also means full type safety (implicit type conversions = bad) and number safety (integral overflows = bad). Defining something like a MISRA-D (a strict and safe subset of D similar to MISRA-C) is an option, and maybe it will produce a less butchered language. I appreciate the attention to floating point detail made in D, and this isn't incompatible with gamedev, but making standard ints compromise basic hardware implementation just won't fly. Compile time flag maybe to enable integer exceptions perhaps, or a special mode like you say...
Re: ow Integers Should Work
On 6 December 2011 10:27, Manu turkey...@gmail.com wrote: Manu: but I don't believe I'm alone.. the rest of the gamedev community will find D soon enough if the language gets it right... I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games. I agree, it certainly didn't seem to be a major consideration early on, but I don't think any decisions yet made prohibit it from being well suited. If as you say, there is some focus to generate interest from the game community, it would be really nice to have a few binary GDC cross compiler distributions available (for windows, linux users never have problems building the toolchain themselves). ARM/PPC, maybe MIPS toolchains hosted somewhere on the website might really help encourage some people get started, and I'd love to spend some time on the standard libraries for these platforms. If you ping me on IRC to get this moving, could put some time into setting up a toolchain for such purposes over the weekend. ie: such as a sript to set-up cross compiling from the current host to target B. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: ow Integers Should Work
Cheers, I'll do that! I've still had nothing but trouble getting cygwin to build the mips toolchain we were experimenting with. I don't know enough about GCC and making it work _. Although ideally a binary distribution would probably want to be mingw/msys based. On 6 December 2011 14:23, Iain Buclaw ibuc...@ubuntu.com wrote: On 6 December 2011 10:27, Manu turkey...@gmail.com wrote: Manu: but I don't believe I'm alone.. the rest of the gamedev community will find D soon enough if the language gets it right... I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games. I agree, it certainly didn't seem to be a major consideration early on, but I don't think any decisions yet made prohibit it from being well suited. If as you say, there is some focus to generate interest from the game community, it would be really nice to have a few binary GDC cross compiler distributions available (for windows, linux users never have problems building the toolchain themselves). ARM/PPC, maybe MIPS toolchains hosted somewhere on the website might really help encourage some people get started, and I'd love to spend some time on the standard libraries for these platforms. If you ping me on IRC to get this moving, could put some time into setting up a toolchain for such purposes over the weekend. ie: such as a sript to set-up cross compiling from the current host to target B. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Immutable Message Passing
On 12/5/11 11:55 PM, Andrew Wiley wrote: On Sun, Dec 4, 2011 at 9:12 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 12/4/11 4:32 PM, Andrew Wiley wrote: In that case, no object copying is occurring, and I have message passing for immutable objects working, although my current solution is basically to check whether the object is immutable, and if so, memcpy the reference. That breaks immutability, but only for the reference, and I don't think there's any alternative unless we get tail const/immutable into the language. I'm guessing this is too hackish to get merged into std.variant? We need to have Variant cope with that. Please submit a bug report. Done: http://d.puremagic.com/issues/show_bug.cgi?id=7069 Andrew Great, thanks. I'll look into it when I'll have a chance. Andrei
Re: Haxe (From: Java Scala - new thread: GUI for D)
Adrian adrian.remove-nos...@veith-system.de wrote in message news:jbkkpf$cut$1...@digitalmars.com... Am 05.12.2011 18:56, schrieb Nick Sabalausky: In that project, Haxe's ability to compile the same code, in the same language, down to both server-side (PHP) and client-side (Flash8) has been an *enormous* benefit. Just that one ability alone, even without the fact that Haxe beats the snot of out both AS2 and PHP. I also use a slightly-hacked version of the HaxeIgniter framework (could be better, but it's not bad and it gets the job done). That said, I have been chomping at the bit to switch to D (and Adam's clever web framework) for my server-side code. I've pretty much managed to convince my client to eventually let us switch to a host that allows native-compiled CGI. The only problem now is that that would rule out the possibility of sharing code between both server and client - Which is *NOT* something I want to give up... That is exactly my point. HaXe' s ability to share the same code on client and server side is one of it's killer features. Absolutely! shameless plug: So to that end, you mentioned Java and C# targets are coming to Haxe? Well, so is D... :) HaxeD: http://www.dsource.org/projects/haxed interesting - the last time I looked, I thought the project is abandoned. Nah, I'm pretty hell-bent on getting this working[1]. It's just that sometimes real-world gets in the way. But I plan to use this for my main real-world project, so that's helping keep the priority up. [1] ...Unless I could get Dax (ie, D - Haxe) working before finishing HaxeD, which I would have preferred, but that's definitely not going to happen: I've decided to put Dax on indefinite hold b/c it's a *much* more difficult problem: partly because D's features are more-or-less a superset of Haxe's, and partly b/c Dax is currently based on DDMD which has proven to be an unsustainable approach to accessing DMD from D. Why did I write the whole thing from scratch in D as a separate tool, instead of just adding D support to the official Haxe codebase? Ehh, possibly-questionable reasons: 1. Because I looked at Haxe's source and decided I didn't feel like figuring out OCaml before getting started :/ yes OCaml is another beast. My idea was to take the source of Hugh Sandersons C++ target and adopt it to D. For me, D is a much more logical target for haXe, because many of the language features fit better together. The problem I see with your solution is, that haXe evolves very fast and a D target written in OCaml would benefit from this, whereas a target written in D is always behind. Yea, that is definitely the downside of my approach. OTOH, Haxe still doesn't evolve as fast as, say, D. And I'm optimistic that once I have it 100% working, updates shouldn't be too difficult. Most of the changes in each Haxe release are either in the std lib, neko-related, or bug-fixes, none of which would be applicable to HaxeD (as far as the std lib, HaxeD will have a copy of the std lib that may add some #if d directives where applicable, and those would need to get merged wih each Haxe release, but that shouldn't be too hard). The last few months I am looking at D as a replacement for Delphi at least at the server side (which would be a major task rewriting the database server), but I am twisted at the moment, because I am not sure if D is mature enough ( and/or me good enough to master if not). Personally, I think it is. FWIW.
Re: ow Integers Should Work
On 12/6/11 1:20 AM, Walter Bright wrote: On 12/5/2011 10:52 PM, Don wrote: On 06.12.2011 05:15, Walter Bright wrote: On 12/5/2011 8:10 PM, bearophile wrote: This is not about integers but yeah, I'd like the better str- float conversions of Python in D too. Do you have any test data that they actually are better in Python (apart from just being better specified)? Bug 5229 is an example. I have five papers on this topic. Most recent is the excellent: Florian Loitsch, Printing FP numbers quickly and accurately with integers (2010) Right now, we rely on C's standard library. Often, it's deficient. We should roll our own, like we did with the math routines, and make sure the D standard reflects the modern thinking on it. (Python's implementation currently uses David Gay's dtoa.c) Translating dtoa.c to D and making sure it works during compilation sounds like a great project. People who want to help D in any way, please take notice :o). Andrei
Re: ow Integers Should Work
On 12/6/11 1:16 AM, Walter Bright wrote: On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote: On 12/5/11 10:15 PM, Walter Bright wrote: On 12/5/2011 8:10 PM, bearophile wrote: This is not about integers but yeah, I'd like the better str- float conversions of Python in D too. Do you have any test data that they actually are better in Python (apart from just being better specified)? I can tell Google's double-conversion routines (http://goo.gl/RU5g4) are faster than sprintf/sscanf, in addition to being better specified. We use them at Facebook. Darn, licensing problems: Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. http://www.opensource.org/licenses/bsd-license.php This is a general issue. Can it be overcome by distributing the text in the HTML documentation included with the download? Andrei
Re: ow Integers Should Work
On 12/6/2011 9:11 AM, Andrei Alexandrescu wrote: On 12/6/11 1:16 AM, Walter Bright wrote: On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote: On 12/5/11 10:15 PM, Walter Bright wrote: Darn, licensing problems: Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. http://www.opensource.org/licenses/bsd-license.php This is a general issue. Can it be overcome by distributing the text in the HTML documentation included with the download? Every customer who builds a program with D will have to have that notice somewhere in it. It's the old Tango problem.
Re: ow Integers Should Work
On 12/6/2011 9:14 AM, Andrei Alexandrescu wrote: Translating dtoa.c to D and making sure it works during compilation sounds like a great project. People who want to help D in any way, please take notice :o). Sadly, despite dtoa.c's wide use, there doesn't appear to be a test suite for it. I suppose we could email David Gay and ask.
Re: ow Integers Should Work
On 12/6/11 6:14 PM, Andrei Alexandrescu wrote: On 12/6/11 1:20 AM, Walter Bright wrote: (Python's implementation currently uses David Gay's dtoa.c) Translating dtoa.c to D and making sure it works during compilation sounds like a great project. People who want to help D in any way, please take notice :o). Isn't there the same licensing problem with David Gay's code as well? »provided that this entire notice is included […] in all copies of the supporting documentation for such software.« David
SCons support for D
SCons is a Python-based build tool to replace Make and much of the Autotools functionality. It has D support as part of the core. This support is though in need of development. The new Mercurial/BitBucket infrastructure for developing SCons (replacing the old Subversion/Tigris set up) is now in place, a new release 2.1.0 has been declared and everything is open for business leading to a 2.2.0 release. I got my changes to support DMD 2 into this release :-) However, support for GDC, LDC, etc. is almost certainly still sadly lacking, and indeed the support for DMD almost certainly needs a severe refactoring and most likely a rewrite. Rather than people having to work on a clone of SCons in order to work on the tool, I have created a separate Mercurial repository (https://bitbucket.org/russel/scons_dmd_new) as a development version of just the tool. When a new version of this separate tool is declared I create a pull request for the SCons mainline to get the new version in the next version of SCons. Is anyone else other than me interested in using SCons as a build tool with D code? If there is, perhaps we can collaborate in some way to progress SCons support for all the various realizations of D? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.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: Haxe (From: Java Scala - new thread: GUI for D)
Nick Sabalausky a@a.a wrote in message news:jblhn8$1vis$1...@digitalmars.com... Adrian adrian.remove-nos...@veith-system.de wrote in message news:jbkkpf$cut$1...@digitalmars.com... Am 05.12.2011 18:56, schrieb Nick Sabalausky: Why did I write the whole thing from scratch in D as a separate tool, instead of just adding D support to the official Haxe codebase? Ehh, possibly-questionable reasons: 1. Because I looked at Haxe's source and decided I didn't feel like figuring out OCaml before getting started :/ yes OCaml is another beast. My idea was to take the source of Hugh Sandersons C++ target and adopt it to D. For me, D is a much more logical target for haXe, because many of the language features fit better together. The problem I see with your solution is, that haXe evolves very fast and a D target written in OCaml would benefit from this, whereas a target written in D is always behind. Yea, that is definitely the downside of my approach. OTOH, Haxe still doesn't evolve as fast as, say, D. And I'm optimistic that once I have it 100% working, updates shouldn't be too difficult. Most of the changes in each Haxe release are either in the std lib, neko-related, or bug-fixes, none of which would be applicable to HaxeD (as far as the std lib, HaxeD will have a copy of the std lib that may add some #if d directives where applicable, and those would need to get merged wih each Haxe release, but that shouldn't be too hard). There is another upside to my approach, though: It gives me the ability to add optional features without Cannasse's approval. Sometimes he can be...(how can I say this diplomatically?)...a bit stubborn in refusing to even consider or discuss reasonable requests. He seems to like his Denied Because I Said So stamp ;). Couple off the top of my head examples: http://code.google.com/p/haxe/issues/detail?id=106 Forum thread links have JS that screws up open link in new tab/window http://code.google.com/p/haxe/issues/detail?id=105 Assigning from a Dynamic silently subverts type system and corrupts var. Note that first one, #106, is NOT my usual X requires JS complaint. This is something that breaks standard browser behavior *with* JS on, and is a trivial fix with no downside (at least none that he was willing to actually share). Of course, that's just unrelated website stuff, but... That #105 in particular is pretty nasty. Haxe supports static typing and also has a Dynamic type. But take a look at this: var dyn:Dynamic = foo; var i:Int; // Statically-typed **INTEGER**!! i = dyn; Guess what? Not only does the compiler accept that, but there is no runtime-check either. My *statically-typed integer* now contains a *string* (foo)!! Yes, seriously. And with *no* explicit casts or unsafe or anything. Of course, the fun doesn't stop there: dyn = 5; i = dyn; i += 10; // Looks like integer addition trace(i); // Wheee!!! Output: 510 Granted, one could argue that you should be able to this without any run-time baggage if you chose to (for instance, if you *know* that dyn is really an Int). But Haxe ALREADY has Unsafe Cast which DOES EXACTLY THAT!: // From the official docs on Unsafe Cast: // ...the cast call will not result in any runtime check, // but will allow you to loose one type. i = cast dyn; After I explained all of that to commenters #1 and #3, Cannasse pulled out his Denied stamp along with a message that clearly misunderstood much of the issue. /rant So anyway, with my own Haxe implementation, I can just add an optional -sane switch to enable either a runtime or compile-time check...And nobody can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!!
Re: Java Scala
On Tue, 06 Dec 2011 01:31:45 -0800, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 12/6/11, Adam Wilson flybo...@gmail.com wrote: No worries, had to ask. Thanks for the link though, it looks promising. :-) Listen, if you ever need help I'm in #d, nickname drey_. I think we talked before. It's never a bad idea to exchange ideas, so I'll be there. I do believe that we have talked. I go by LightBender in #d. That sounds like a plan. The project is currently in the idea stage and I want to know what other developers think. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Java Scala
On Tue, 06 Dec 2011 00:48:44 -0800, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 12/6/11, Jacob Carlborg d...@me.com wrote: Doesn't sound very effective. I don't know what that bubbling is all about. You can easily intercept a signal to a child window via std.signals, in Qt this would be installing an event filter of some sort. So sink/bubble seems unnecessary. The library is far from being efficient. It recreates a main window memory buffer on each paint message from the OS (IOW very often), also unless I'm mistaken the widgets themselves don't have a backbuffer so the library assumes their paint routines are not expensive. But that's fixable. I don't know why HTML was used, although that's just an alternative front-end to the library as far as I can tell. It does seem like this library died pretty quickly, I don't recall of any projects that used it. Anyway, I don't know if Adam wants to work on a native or non-native GUI, for native ones in pure-D (not a wrapper over existing GUIs) he can look at DFL or something else from here: http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries But the library is modular enough and could be used as a starting point, imo. The use of HTML is a bit contrived I think. HTML is a Document Markup Language and was primarily intended to format research papers for transmission and viewing over the early internet. To build a good UI, you need a much more expressive design language. My goal for the project is what you would term non-native in that it does not make use of the OS widgets; however the plan is to provide native looking skins for the widgets. I'd like to design something that interfaces with the machine at a lower level than widgets. On Windows I am targeting Direct2D, on Linux, OpenGL is the best candidate, and on OSX, well OpenGL might work but OSX has a lot of options to explore, and I don't have access to a Mac. (Anybody know how to get OSX working on VirtualBox?) That wiki link is fantastic, I had no idea there were that many GUI projects going for D! Although it looks like the only ones that did what I'd like to do are dead (Rae and Harmonia)... Guess it's time to give it another shot. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: ow Integers Should Work
On Wed, 07 Dec 2011 04:11:40 +1100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 12/6/11 1:16 AM, Walter Bright wrote: On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote: On 12/5/11 10:15 PM, Walter Bright wrote: On 12/5/2011 8:10 PM, bearophile wrote: This is not about integers but yeah, I'd like the better str- float conversions of Python in D too. Do you have any test data that they actually are better in Python (apart from just being better specified)? I can tell Google's double-conversion routines (http://goo.gl/RU5g4) are faster than sprintf/sscanf, in addition to being better specified. We use them at Facebook. Darn, licensing problems: Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. http://www.opensource.org/licenses/bsd-license.php This is a general issue. Can it be overcome by distributing the text in the HTML documentation included with the download? It's the binary form phrase that's a problem. Does it mean executable form rather than text form, or digital rather than hardcopy form? -- Derek Parnell Melbourne, Australia
Re: SCons support for D
Is anyone else other than me interested in using SCons as a build tool with D code? If there is, perhaps we can collaborate in some way to progress SCons support for all the various realizations of D? I am interested. SCons is my build tool of choice (for C/C++),a lthough I also use fbuild (see on github) sometimes. I am not very good at Python, but I could give a helping hand if needed. I will ask you on the bitbucket site
std.json dynamic initialization of JSONValue
I posted this on D.learn, but got no responses. I'm hoping it's because
I'm asking the wrong crowd.
I'm finding std.json extremely well written, with one glaring exception.
I can't seem to figure out how to do this:
JSONValue root = JSONValue(null, JSON_TYPE.OBJECT);
root.object[first_object] = JSONValue(null, JSON_TYPE.OBJECT);
root.object[first_string] = JSONValue(first_string, JSON_TYPE.STRING);
which would decode to:
{first_object:{},first_string:first_string}
What I end up having to do is:
JSONValue root;
root.type = JSON_TYPE.OBJECT;
root.object[first_object] = JSONValue();
root.object[first_object].type = JSON_TYPE.OBJECT;
root.object[first_string] = JSON_Value();
root.object[first_string].type = JSON_TYPE.STRING;
root.object[first_string].str = first_string;
That just feels like I'm doing it wrong. Is there a way to dynamically
initialize a JSONValue struct? If I try to intialize the JSONValue
object with anything other than simply null, or empty string, I either
get a compile error or a segfault at run-time.
root.object[first_object] = JSONValue(null, JSON_TYPE.OBJECT);
compile error:
Error: overlapping initialization for integer
root.object[first_string] = JSONValue(first_string);
run-time segfault.
Any ideas?
Re: std.json dynamic initialization of JSONValue
I could swear I replied in the other group... must have gotten lost in the
series of tubes.
Anyway, I think std.json is easiest to use with a little template wrapper
instead
of making JSONValues directly.
Try this on for size:
=
import std.json;
import std.conv;
import std.traits;
JSONValue toJsonValue(T)(T a) {
JSONValue val;
static if(is(T == typeof(null))) {
val.type = JSON_TYPE.NULL;
} else static if(is(T == JSONValue)) {
val = a;
} else static if(isIntegral!(T)) {
val.type = JSON_TYPE.INTEGER;
val.integer = to!long(a);
} else static if(isFloatingPoint!(T)) {
val.type = JSON_TYPE.FLOAT;
val.floating = to!real(a);
} else static if(is(T == bool)) {
if(a == true)
val.type = JSON_TYPE.TRUE;
if(a == false)
val.type = JSON_TYPE.FALSE;
} else static if(isSomeString!(T)) {
val.type = JSON_TYPE.STRING;
val.str = to!string(a);
} else static if(isAssociativeArray!(T)) {
val.type = JSON_TYPE.OBJECT;
foreach(k, v; a) {
val.object[to!string(k)] = toJsonValue(v);
}
} else static if(isArray!(T)) {
val.type = JSON_TYPE.ARRAY;
val.array.length = a.length;
foreach(i, v; a) {
val.array[i] = toJsonValue(v);
}
} else static if(is(T == struct)) { // also can do all members of a
struct...
val.type = JSON_TYPE.OBJECT;
foreach(i, member; a.tupleof) {
string name = a.tupleof[i].stringof[2..$];
static if(a.tupleof[i].stringof[2] != '_')
val.object[name] = toJsonValue!(typeof(member),
R)(member, formatToStringAs, api);
}
} else { /* our catch all is to just do strings */
val.type = JSON_TYPE.STRING;
val.str = to!string(a);
}
return val;
}
string toJson(T)(T a) {
auto v = toJsonValue(a);
return toJSON(v);
}
/* usage example */
import std.stdio;
void main() {
writeln(toJson([message: Hello, world!]));
}
==
Then, you can either use toJsonValue() to fill in an object similar
to what you were doing before, or use toJson() to skip right
to having a string from a struct, an associative array, or many
other D types.
Re: std.json dynamic initialization of JSONValue
Adam D. Ruppe Wrote: val.object[name] = toJsonValue!(typeof(member), R)(member, formatToStringAs, api); Whoops, that should have been val.object[name] = toJsonValue(member); (I copy pasted this out of my web.d module, which can add a toString() method to the json too, so it's a little more complicated. And probably useless.)
Re: std.json dynamic initialization of JSONValue
On 12/06/2011 02:42 PM, Adam D. Ruppe wrote:
I could swear I replied in the other group... must have gotten lost in the
series of tubes.
Anyway, I think std.json is easiest to use with a little template wrapper
instead
of making JSONValues directly.
Try this on for size:
=
import std.json;
import std.conv;
import std.traits;
JSONValue toJsonValue(T)(T a) {
JSONValue val;
static if(is(T == typeof(null))) {
val.type = JSON_TYPE.NULL;
} else static if(is(T == JSONValue)) {
val = a;
} else static if(isIntegral!(T)) {
val.type = JSON_TYPE.INTEGER;
val.integer = to!long(a);
} else static if(isFloatingPoint!(T)) {
val.type = JSON_TYPE.FLOAT;
val.floating = to!real(a);
} else static if(is(T == bool)) {
if(a == true)
val.type = JSON_TYPE.TRUE;
if(a == false)
val.type = JSON_TYPE.FALSE;
} else static if(isSomeString!(T)) {
val.type = JSON_TYPE.STRING;
val.str = to!string(a);
} else static if(isAssociativeArray!(T)) {
val.type = JSON_TYPE.OBJECT;
foreach(k, v; a) {
val.object[to!string(k)] = toJsonValue(v);
}
} else static if(isArray!(T)) {
val.type = JSON_TYPE.ARRAY;
val.array.length = a.length;
foreach(i, v; a) {
val.array[i] = toJsonValue(v);
}
} else static if(is(T == struct)) { // also can do all members of a
struct...
val.type = JSON_TYPE.OBJECT;
foreach(i, member; a.tupleof) {
string name = a.tupleof[i].stringof[2..$];
static if(a.tupleof[i].stringof[2] != '_')
val.object[name] = toJsonValue!(typeof(member),
R)(member, formatToStringAs, api);
}
} else { /* our catch all is to just do strings */
val.type = JSON_TYPE.STRING;
val.str = to!string(a);
}
return val;
}
string toJson(T)(T a) {
auto v = toJsonValue(a);
return toJSON(v);
}
/* usage example */
import std.stdio;
void main() {
writeln(toJson([message: Hello, world!]));
}
==
Then, you can either use toJsonValue() to fill in an object similar
to what you were doing before, or use toJson() to skip right
to having a string from a struct, an associative array, or many
other D types.
I like it. Any reason something like this doesn't already exist in std.json?
-Kai Meyer
Re: std.json dynamic initialization of JSONValue
Kai Meyer Wrote: I like it. Any reason something like this doesn't already exist in std.json? I think it's just that nobody has done updates to std.json for a while, but I don't really know.
Re: std.json dynamic initialization of JSONValue
On Tuesday, December 06, 2011 18:26:39 Adam D. Ruppe wrote: Kai Meyer Wrote: I like it. Any reason something like this doesn't already exist in std.json? I think it's just that nobody has done updates to std.json for a while, but I don't really know. I believe that Robert Jacques has a revised version of std.json that he intends to put up for review, but it relies on changes that he's made to std.variant which also need be reviewed. - Jonathan M Davis
Re: rt_finalize WTFs?
I have an updated and win32-compilable version of CDGC in a branch. It's missing some features from the current GC though (it's based on the Tango GC which has remained relatively static for the past years while druntime's GC has improved). Sent from my iPhone On Dec 5, 2011, at 3:39 PM, Trass3r u...@known.com wrote: On 05/12/2011 01:46, dsimcha wrote: I'm at my traditional passtime of trying to speed up D's garbage collector again Have you thought about pushing for the inclusion of CDGC at all/working on the tweaks needed to make it the main GC? So true, it's been rotting in that branch.
Re: is d-runtime non-gc safe?
No. Message-passing allocates a block of memory to transport the message. Even with a free-list there may be an occasional allocation. I could look into using an array instead of a linked list, but that would mean memmoves. In receive. Sent from my iPhone On Dec 5, 2011, at 12:40 PM, Tobias Pankrath tob...@pankrath.net wrote: Right - thanks for the hint! That would leave the following rules for real-time audio code in D: [snip] What's about message passing? Is message passing hard real time ready?
Re: is d-runtime non-gc safe?
On 12/6/11 8:11 PM, Sean Kelly wrote: No. Message-passing allocates a block of memory to transport the message. Even with a free-list there may be an occasional allocation. I could look into using an array instead of a linked list, but that would mean memmoves. In receive. Sent from my iPhone On Dec 5, 2011, at 12:40 PM, Tobias Pankrathtob...@pankrath.net wrote: Right - thanks for the hint! That would leave the following rules for real-time audio code in D: [snip] What's about message passing? Is message passing hard real time ready? A circular fixed-size list is possible with blocking on full list. There would be no allocation. Andrei
Re: std.json dynamic initialization of JSONValue
On Tue, 06 Dec 2011 19:15:26 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: On Tuesday, December 06, 2011 18:26:39 Adam D. Ruppe wrote: Kai Meyer Wrote: I like it. Any reason something like this doesn't already exist in std.json? I think it's just that nobody has done updates to std.json for a while, but I don't really know. I believe that Robert Jacques has a revised version of std.json that he intends to put up for review, but it relies on changes that he's made to std.variant which also need be reviewed. - Jonathan M Davis Correct. Andrei suggested that since JSONValue is a tagged union, it should really use std.Variant.Algebraic as its representation, which necessitated fixing both Variant and Algebraic so that was possible. The code and documentation links are below if you'd like to try it out/comment on it. The only thing unintuitive in my revision from your use case is creating an empty JSON object or array: JSON.Value myObject = JSON.Value[string].init; JSON.Value myArray = JSON.Value[].init; Since this is undocumented :( I think I'm going to add some aliases (JSON.Object_init, JSON.Array_init) to simplify things for people. https://jshare.johnshopkins.edu/rjacque2/public_html/json2.mht https://jshare.johnshopkins.edu/rjacque2/public_html/variant.mht https://jshare.johnshopkins.edu/rjacque2/public_html/json2.d https://jshare.johnshopkins.edu/rjacque2/public_html/variant.d
Re: ow Integers Should Work
On 12/06/2011 09:49 AM, Walter Bright wrote: On 12/6/2011 9:14 AM, Andrei Alexandrescu wrote: Translating dtoa.c to D and making sure it works during compilation sounds like a great project. People who want to help D in any way, please take notice :o). Sadly, despite dtoa.c's wide use, there doesn't appear to be a test suite for it. I suppose we could email David Gay and ask. Fuzz test it? Feed it and the clone random data (after a archive of selected values) until they give different results or you get sick of waiting.
Re: std.json dynamic initialization of JSONValue
Robert Jacques; I like your modules a lot. I'm sure it will be a bit of a pain to integrate it into my existing codebase, but they look like it'd be worth it!
Re: ow Integers Should Work
On 12/05/2011 11:20 PM, Don wrote: On 06.12.2011 05:21, bcs wrote: On 12/05/2011 08:37 AM, Don wrote: On 05.12.2011 14:31, bearophile wrote: Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support): http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642 Bye, bearophile Not very convincing, since he proposes a change to existing architectures, and seems completely unaware of the overflow flag. I think he's looking at it form the language theory standpoint. As such, architectures has nothing to do with it (the architectures to be targeted has yet to be defined at that point)and getting access to the overflow flag would require exposing it natively in the language. It's not that he hasn't specified an architecture. It's a proposal which does not work on _any_ existing architectures! It's pure fantasy. Well you can do it on x86. The fact the it doesn't provied hardware traps is irrelevant. You might need to add a lot of branches but you can get the semantics he is asking for. That said, there is another interesting (but independent) question of can it be done efficiently? You might have a very good question there, but that isn't the question regehr is considering. And he talks about NaN, when he means infinity. Floating point overflow never results in a NaN. You have a point there. He doesn't seem to know anything about saturating integer arithmetic, which exists in hardware (even x86 machines have supported a couple of operations since 1996). Useless. Again, he's not interested in the hardware implementation, he's only interested in the defined semantics of the language, the things you can count on regardless of that instruction set you are using. The fact the x86 has saturating integer operations is moot because C doesn't have a type the end up using them.
Re: Java Scala
On 12/6/11, Adam Wilson flybo...@gmail.com wrote: My goal for the project is what you would term non-native in that it does not make use of the OS widgets; however the plan is to provide native looking skins for the widgets. That's what the theming API is for on Windows. OSX might have something similar. Harmonia uses the theming API, for OSX/Linux you can take a look at Qt and how they skin their widgets.
Re: The current status of D?
int z = 0;
int foo(int x, int y) { return x + y; }
int bar(int x) { z++; return x * x + z; }
int baz(int x) { z--; return 2 * x + z; }
int main() {
int w = foo(bar(5), baz(3));
return w;
}
See also:
http://en.wikipedia.org/wiki/Sequence_point
I think ',' in parameter lists are already sequence points.
They aren't, but a function call is a sequence point, so bar is guaranteed to
be called before baz.
Re: ow Integers Should Work
On 07.12.2011 05:11, bcs wrote: On 12/05/2011 11:20 PM, Don wrote: On 06.12.2011 05:21, bcs wrote: On 12/05/2011 08:37 AM, Don wrote: On 05.12.2011 14:31, bearophile wrote: Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support): http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642 Bye, bearophile Not very convincing, since he proposes a change to existing architectures, and seems completely unaware of the overflow flag. I think he's looking at it form the language theory standpoint. As such, architectures has nothing to do with it (the architectures to be targeted has yet to be defined at that point)and getting access to the overflow flag would require exposing it natively in the language. It's not that he hasn't specified an architecture. It's a proposal which does not work on _any_ existing architectures! It's pure fantasy. Well you can do it on x86. The fact the it doesn't provied hardware traps is irrelevant. You might need to add a lot of branches but you can get the semantics he is asking for. That said, there is another interesting (but independent) question of can it be done efficiently? You might have a very good question there, but that isn't the question regehr is considering. And he talks about NaN, when he means infinity. Floating point overflow never results in a NaN. You have a point there. He doesn't seem to know anything about saturating integer arithmetic, which exists in hardware (even x86 machines have supported a couple of operations since 1996). Useless. Again, he's not interested in the hardware implementation, he's only interested in the defined semantics of the language, the things you can count on regardless of that instruction set you are using. The fact the x86 has saturating integer operations is moot because C doesn't have a type the end up using them. He's talking about system languages. A system language has to have a close relationship to the architecture. By contrast, if you don't care about performance, it's easy -- just use BigInts for everything. Problem solved. Looks like I have to put it more bluntly: I don't think he knows what he's talking about. (On this particular topic).
Is D associative array thread safe, and will it relocate memory when add or delete a value?
Is D associative array thread safe, and will it relocate memory when add or delete a value? Where I can find the implemention.
[Issue 7045] AssertError in std.regex on line 1573
http://d.puremagic.com/issues/show_bug.cgi?id=7045 --- Comment #4 from Trass3r mrmoc...@gmx.de 2011-12-06 03:14:54 PST --- btw, isn't this a regression? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7045] AssertError in std.regex on line 1573
http://d.puremagic.com/issues/show_bug.cgi?id=7045 --- Comment #5 from Trass3r mrmoc...@gmx.de 2011-12-06 04:06:55 PST --- Seems like it was fixed in the meantime. http://www.mail-archive.com/digitalmars-d@puremagic.com/msg70809.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7070] New: can't assign null to Variant
http://d.puremagic.com/issues/show_bug.cgi?id=7070
Summary: can't assign null to Variant
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r mrmoc...@gmx.de 2011-12-06 04:19:43 PST ---
If it isn't supposed to work anymore, just close the report.
import std.variant;
void main()
{
Variant v;
v = null;
}
$ dmd test.d
/std/traits.d(1755): Error: static assert argument is not a class or
interface
/std/traits.d(1818):instantiated from here:
BaseTypeTuple!(typeof(null))
/std/traits.d(1933):instantiated from here:
BaseClassesTuple!(typeof(null))
/std/traits.d(2230):instantiated from here:
TransitiveBaseTypeTuple!(typeof(null))
/std/variant.d(255):instantiated from here:
ImplicitConversionTargets!(typeof(null))
/std/variant.d(543):instantiated from here: handler!(typeof(null))
test.d(6):instantiated from here: opAssign!(typeof(null))
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7071] New: final: shouldn't affect variables
http://d.puremagic.com/issues/show_bug.cgi?id=7071
Summary: final: shouldn't affect variables
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: minor
Priority: P3
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir Panteleev thecybersha...@gmail.com 2011-12-06
05:22:08 PST ---
This code works in D1:
class C
{
final:
string s;
}
In D2 it results in:
Error: variable test_final.C.s final cannot be applied to variable
Since it works in D1, I assume it's an unintentional regression?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7071] final: shouldn't affect variables
http://d.puremagic.com/issues/show_bug.cgi?id=7071 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords|rejects-valid | Severity|minor |enhancement --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com 2011-12-06 05:30:56 PST --- I was told that final has meaning for variables in D1, so I'm changing this to an enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7072] New: [2.057 Beta] Assertion failure: '0' on line 145 in file 'mtype.c'
http://d.puremagic.com/issues/show_bug.cgi?id=7072 Summary: [2.057 Beta] Assertion failure: '0' on line 145 in file 'mtype.c' Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Keywords: ice-on-valid-code Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha dsim...@yahoo.com 2011-12-06 06:26:07 PST --- I get this error message when trying to build SciD with 2.057 beta. Assertion failure: '0' on line 145 in file 'mtype.c' This doesn't happen with 2.056. I haven't had a chance to reduce this yet, but I will try tonight if the assertion failure isn't enough of a hint. (I don't imagine reducing this one will be easy.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7073] New: Parsing of class-returning varargs function inside module ctor fails
http://d.puremagic.com/issues/show_bug.cgi?id=7073
Summary: Parsing of class-returning varargs function inside
module ctor fails
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: xtzgzo...@gmail.com
--- Comment #0 from Alex R�nne Petersen xtzgzo...@gmail.com 2011-12-06
06:47:21 PST ---
Code:
class A
{
}
static this()
{
A foo(A[] a ...)
{
return new A();
}
}
Errors:
test.d(7): found 'foo' when expecting ';' following statement
test.d(11): found '}' when expecting ';' following statement
test.d(12): found 'EOF' when expecting '}' following compound statement
Removing the ... makes it parse correctly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7073] Parsing of class-returning varargs function inside module ctor fails
http://d.puremagic.com/issues/show_bug.cgi?id=7073
--- Comment #1 from Alex R�nne Petersen xtzgzo...@gmail.com 2011-12-06
07:07:37 PST ---
(In reply to comment #0)
Code:
class A
{
}
static this()
{
A foo(A[] a ...)
{
return new A();
}
}
Errors:
test.d(7): found 'foo' when expecting ';' following statement
test.d(11): found '}' when expecting ';' following statement
test.d(12): found 'EOF' when expecting '}' following compound statement
Removing the ... makes it parse correctly.
Also fails with this simpler example:
static this()
{
string f(int[] arr...)
{
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
http://d.puremagic.com/issues/show_bug.cgi?id=7067 --- Comment #4 from Andrei Alexandrescu and...@metalanguage.com 2011-12-06 07:53:28 PST --- Turn random generators into final classes? We have backward compatibility to worry about. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
http://d.puremagic.com/issues/show_bug.cgi?id=7067 --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com 2011-12-06 08:04:49 PST --- The disadvantages of breaking backwards compatibility need to be considered on a case-by-case basis. I think that turning RNGs into reference types has the potential to be a relatively low-impact change, while also having a good chance of revealing broken code. The typical usage of std.random does not involve using the RNG types directly, and rather using the implicit thread-local RNG. An example of affected code: Random r; // ... use r I think that generally allowing such code is a mistake, because it's not clear that the RNG is not seeded. auto r = Random(42); We can implement this for backwards compatibility using static opCall (which shall be scheduled for deprecation). The biggest problem is intentional usage of value semantics (it would transparently turn into reference semantics). Perhaps there's something we could do with the help of opAssign? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
http://d.puremagic.com/issues/show_bug.cgi?id=7067 --- Comment #6 from bearophile_h...@eml.cc 2011-12-06 09:49:20 PST --- (In reply to comment #5) The biggest problem is intentional usage of value semantics (it would transparently turn into reference semantics). I suggest to ignore such cases, they are probably uncommon, and add a warning note to the changelog. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7074] New: std.concurrency.receive segfaults when called from new thread
http://d.puremagic.com/issues/show_bug.cgi?id=7074
Summary: std.concurrency.receive segfaults when called from new
thread
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: c...@klickverbot.at
--- Comment #0 from klickverbot c...@klickverbot.at 2011-12-06 12:25:18 PST
---
Not sure if this is expected:
---
import core.thread;
import std.concurrency;
void main() {
(new Thread({receive((bool b){});})).start();
}
---
crashes using Phobos c83edad (2.057 beta), because the mbox of the newly
created thread has not been initialized yet (it is for the main thread in a
shared static constructor, and by spawn() for threads created by it).
Workaround: Force initialization of mbox by calling std.concurrency.thisTid on
the new thread first.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7040] Phobos must use version/else version blocks for proper documentation generation
http://d.puremagic.com/issues/show_bug.cgi?id=7040 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||FIXED --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-12-06 12:42:15 PST --- Fixed. https://github.com/D-Programming-Language/phobos/commit/9f9028829ce8d47826226497ce7b8e46f9168a7b -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7072] [2.057 Beta] Assertion failure: '0' on line 145 in file 'mtype.c'
http://d.puremagic.com/issues/show_bug.cgi?id=7072 --- Comment #1 from David Simcha dsim...@yahoo.com 2011-12-06 15:56:46 PST --- I didn't realize the significance of this until I looked at the source code to mtype.c, but there's actually a line before the assertion failure line. The full error message is: ty = 41 Assertion failure: '0' on line 145 in file 'mtype.c' -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7069] Variant Doesn't Handle Const or Immutable Contents
http://d.puremagic.com/issues/show_bug.cgi?id=7069 Rob Jacques sandf...@jhu.edu changed: What|Removed |Added CC||sandf...@jhu.edu --- Comment #1 from Rob Jacques sandf...@jhu.edu 2011-12-06 16:32:22 PST --- I've added this to my test suite for improving variant. It causes compile-time errors in my current code base, but I will work on a fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6969] Forward reference on template class triangle
http://d.puremagic.com/issues/show_bug.cgi?id=6969 --- Comment #2 from Nick Sabalausky cbkbbej...@mailinator.com 2011-12-06 16:57:34 PST --- I'm not very familiar with DMD's internals wrt semantics, but from what I can tell so far, the problem may have to do with a certain section near the end of TemplateInstance::semantic(Scope *sc, Expressions *fargs): ... /* The problem is when to parse the initializer for a variable. * Perhaps VarDeclaration::semantic() should do it like it does * for initializers inside a function. */ //if (sc-parent-isFuncDeclaration()) /* BUG 782: this has problems if the classes this depends on * are forward referenced. Find a way to defer semantic() * on this template. */ semantic2(sc2); ... That call to semantic2 is the call stack when the has forward references error is thrown. Note that this occurs before tryMain() reaches semantic2. Do to my inexperience with DMD's internals, I have no idea if there's some reason that call to semantic2 is supposed to be there. And I don't understand what those comments are trying to say. But if I comment out that semantic2 call, the test case passes. However, I don't know whether that breaks anything else. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6969] Forward reference on template class triangle
http://d.puremagic.com/issues/show_bug.cgi?id=6969 --- Comment #3 from Nick Sabalausky cbkbbej...@mailinator.com 2011-12-06 16:59:05 PST --- *Ahem*: That call to semantic2 is *IN* the call stack... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7072] [2.057 Beta] Assertion failure: '0' on line 145 in file 'mtype.c'
http://d.puremagic.com/issues/show_bug.cgi?id=7072
--- Comment #2 from David Simcha dsim...@yahoo.com 2011-12-06 17:33:24 PST ---
Unbelievably simple test case after about 1.5 hours of recursively reducing
SciD code:
struct S
{
this(A)(A args) { }
}
void main() {
auto s = S( null );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7035] Please use instead broken documentation
http://d.puremagic.com/issues/show_bug.cgi?id=7035 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-12-06 20:00:33 PST --- What are you talking about? All of these look correct in the online documentation, and they look fine when I generate them on my machine. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7035] Please use instead broken documentation
http://d.puremagic.com/issues/show_bug.cgi?id=7035 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2011-12-06 20:08:24 PST --- Ah. I guess that you mean in the zip file. You need to be more specific. Not only did you not specificy _which_ documentation had the issue, but you didn't really say way it is. From previous bugs, I knew what you meant, but what's described in the bug is not sufficient to determine what's wrong - particularly when there isn't actually anything wrong with the documentation that I looked at. It looks like Walter hasn't updated whatever ddoc file he uses for generating the documentation for the zip file to include all of the macros that std.ddoc in d-programming-language.org has. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7075] New: Struct class comparison should check opAssign for class
http://d.puremagic.com/issues/show_bug.cgi?id=7075
Summary: Struct class comparison should check opAssign for
class
Product: D
Version: D2
Platform: Other
OS/Version: Other
Status: NEW
Severity: normal
Priority: P2
Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: jesse.k.phillip...@gmail.com
--- Comment #0 from Jesse Phillips jesse.k.phillip...@gmail.com 2011-12-06
20:32:40 PST ---
The table states that classes do not overload the assignment operator. However
this code compiles:
class A {
int a;
string b;
float c;
void opAssign(B b) {
a = b.a;
}
}
class B {
int a;
}
void main()
{
auto a = new A();
a.a = 5;
auto b = new B();
b.a = 10;
a = b;
assert(a.a == 10);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7075] Struct class comparison should check opAssign for class
http://d.puremagic.com/issues/show_bug.cgi?id=7075 Jesse Phillips jesse.k.phillip...@gmail.com changed: What|Removed |Added CC||jesse.k.phillip...@gmail.co ||m --- Comment #1 from Jesse Phillips jesse.k.phillip...@gmail.com 2011-12-06 20:36:26 PST --- Forgot the pages: http://www.d-programming-language.org/struct and this one only mentions struct: http://www.d-programming-language.org/operatoroverloading.html#Assignment -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7076] New: _d_throwc silently continues execution on failure
http://d.puremagic.com/issues/show_bug.cgi?id=7076 Summary: _d_throwc silently continues execution on failure Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: d...@dawgfoto.de --- Comment #0 from d...@dawgfoto.de 2011-12-06 20:40:50 PST --- Created an attachment (id=1051) Proposed _d_throwc change In cases where no EH table was found the program should abort. Four reasons for such a failure. - throwing exceptions across language border - call to _d_throwc with frame pointer that has no EH entry - corrupted/non-present EH tables - entry points without handler (druntime wraps one around _Dmain) Not sure if this also applies to Windows. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7072] [2.057 Beta] Assertion failure: '0' on line 145 in file 'mtype.c'
http://d.puremagic.com/issues/show_bug.cgi?id=7072 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2011-12-06 20:54:20 PST --- Thanks for your hard work, David. I found the problem, and am testing the fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7001] std.path.baseName and isValidFilename wrong documentation
http://d.puremagic.com/issues/show_bug.cgi?id=7001 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2011-12-06 21:05:51 PST --- And how does isValidFilename not validate directory names? There's no really zero difference between a file and a directory as far as paths go except anything to the left of the rightmost directory separator must be a directory or drive. I believe that both std.path and std.file have a tendancy to use the term file even when it applies to directories - which is fairly typical in such documentation, I believe - though in some cases it can be confusing. Already, as far Posix is concerned, what you'd typically refer to as a file would be a regular file rather than a file. In any case, baseName is arguably correct as-is, though it certainly wouldn't hurt to add or directory to it, and I don't see what's incorrect about isValidFilename. It validates a file or directory name. The only complaint in that regard that I can think of that you might be making is the fact that something like dir/ would return false for it, and since directory separators are invalid in both directory and file names, I don't see that as a problem. So, unless you have another argument that I can't think of, I don't know what your issue with isValidFilename could be. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7072] [2.057 Beta] Assertion failure: '0' on line 145 in file 'mtype.c'
http://d.puremagic.com/issues/show_bug.cgi?id=7072 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-12-06 21:09:06 PST --- https://github.com/D-Programming-Language/dmd/commit/0a20f8f170cbcbf3f3fd6971b339e8d82d311a1c -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7001] std.path.baseName and isValidFilename wrong documentation
http://d.puremagic.com/issues/show_bug.cgi?id=7001 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-12-06 23:00:04 PST --- (In reply to comment #2) and since directory separators are invalid in both directory and file names Why are they invalid in directory names? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7001] std.path.baseName and isValidFilename wrong documentation
http://d.puremagic.com/issues/show_bug.cgi?id=7001 --- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2011-12-06 23:14:01 PST --- If you have /dir or dir/, the name of the directory is dir, not /dir, or dir/. It is illegal on Posix systems to have a directory name with / in it, just like it's illegal on Windows systems to have a directory name with \ in it. A _path_ can have the directory separator for the current OS in it, but not a file or directory name, and isValidFilename is checking file _names_, not paths. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
