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).
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: Java > Scala
On 12/6/11, Adam Wilson 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: 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: 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/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
On Tue, 06 Dec 2011 19:15:26 -0500, Jonathan M Davis 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: 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 Pankrath 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: 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 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: 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 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: 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: 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 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
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
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.
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: 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
Re: ow Integers Should Work
On Wed, 07 Dec 2011 04:11:40 +1100, 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: 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: Java > Scala
On Tue, 06 Dec 2011 00:48:44 -0800, Andrej Mitrovic wrote: On 12/6/11, Jacob Carlborg 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: Java > Scala
On Tue, 06 Dec 2011 01:31:45 -0800, Andrej Mitrovic wrote: On 12/6/11, Adam Wilson 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: Haxe (From: Java > Scala -> new thread: GUI for D)
"Nick Sabalausky" wrote in message
news:jblhn8$1vis$1...@digitalmars.com...
> "Adrian" 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.
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!@!!!
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: 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
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 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/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: Haxe (From: Java > Scala -> new thread: GUI for D)
"Adrian" 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! >> : >> >> 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: Immutable Message Passing
On 12/5/11 11:55 PM, Andrew Wiley wrote: On Sun, Dec 4, 2011 at 9:12 PM, Andrei Alexandrescu 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: 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 wrote: > On 6 December 2011 10:27, Manu 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
On 6 December 2011 10:27, Manu 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
> > 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: Java > Scala
On 12/6/11, Adam Wilson 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: 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..<
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: 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. > : > > 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: Java > Scala
On 12/6/11, Jacob Carlborg 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: 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. .<
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
