Re: std.data.json formal review
On 12-Aug-2015 00:21, Sönke Ludwig wrote: Am 11.08.2015 um 20:15 schrieb Dmitry Olshansky: On 11-Aug-2015 20:30, deadalnix wrote: Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. +1 Also most JS engines use nan-boxing to fit type tag along with the payload in 8 bytes total. At least the _fast_ path of std.data.json should take advantage of similar techniques. But the array field already needs 16 bytes on 64-bit systems anyway. We could surely abuse some bits there to at least not use up more for the type tag, but before we go that far, we should first tackle some other questions, such as the allocation strategy of JSONValues during parsing, the Location field and BigInt/Decimal support. Pointer to array should work for all fields > 8 bytes. Depending on the ratio frequency of value vs frequency of array (which is at least an ~5-10 in any practical scenario) it would make things both more compact and faster. Maybe we should first have a vote about whether BigInt/Decimal should be supported or not, because that would at least solve some of the controversial tradeoffs. I didn't have a use for those personally, but at least we had the real-world issue in vibe.d's implementation that a ulong wasn't exactly representable. Well I've stated why I think BigInt should be optional. The reason is C++ parsers don't even bother with anything beyond ULong/double, nor would any e.g. Node.js stuff bother with things beyond double. Lastly we don't have BigFloat so supporting BigInt but not BigFloat is kinda half-way. So please make it an option. And again add an extra indirection (that is BigInt*) for BigInt field in a union because they are extremely rare. My view generally still is that the DOM representation is something for convenient manipulation of small chunks of JSON, so that performance is not a priority, but feature completeness is. I'm confused - there must be some struct that represents a useful value. And more importantly - is JSONValue going to be converted to jsvar? If not - I'm fine. Otherwise whatever inefficiency present in JSONValue would be accumulated by this conversion process. -- Dmitry Olshansky
Re: D fund
On 12/08/2015 4:18 a.m., Tofu Ninja wrote: On Tuesday, 11 August 2015 at 14:26:45 UTC, Nick Sabalausky wrote: On 08/10/2015 01:10 PM, Tofu Ninja wrote: Would be great if D could have full time paid devs working on it. Totally. That would be a dream job @_@ I know right, where can I apply? And I'm here saying, hey get me partnership on livecoding.tv. I only have to earn a few hundred a week and you would have me :) Most likely a full time streamer. Imagine the promotion we would get to new developers alone. Must make it worth it.
Re: D for Game Development
On 8/11/2015 12:57 AM, Benjamin Thaut wrote: Also the front end transition from C++ to D hits me hard also. It's going to hit everyone hard who works on the front end.
Re: Where the F*** is phobos on OSX nowadays ?
On Tuesday, 11 August 2015 at 05:40:01 UTC, Brad Anderson wrote: On Tuesday, 11 August 2015 at 04:51:03 UTC, deadalnix wrote: And why does it keep moving ? Why isn't it in some place where linker will find it ? Is that really worth it to have every build system to have to jump through hoops to find it, and to break it on a regular basis ? The problem, as usual, is Apple just breaking things willy nilly. https://issues.dlang.org/show_bug.cgi?id=14801 Say what you will about Microsoft but at least with them you don't have to fix a handful of new bugs with every minor OS or IDE upgrade. Slow clap...
Re: std.data.json formal review
On Tuesday, 11 August 2015 at 21:06:24 UTC, Sönke Ludwig wrote: See http://s-ludwig.github.io/std_data_json/stdx/data/json/value/JSONValue.payload.html The question whether each field is "really" needed obviously depends on the application. However, the biggest type is BigInt that, form a quick look, contains a dynamic array + a bool field, so it's not as compact as it could be, but also not really large. There is also an additional Location field that may sometimes be important for good error messages and the like and sometimes may be totally unneeded. Urg. Looks like BigInt should steal a bit somewhere instead of having a bool like this. That is not really your lib's fault, but that's quite an heavy cost. Consider this, if the struct fit into 2 registers, it will be passed around as such rather than in memory. That is a significant difference. For BigInt itself, and, by proxy, for the JSON library. Putting the BigInt thing aside, it seems like the biggest field in there is an array of JSONValues or a string. For the string, you can artificially limit the length by 3 bits to stick a tag. That still give absurdly large strings. For the JSONValue case, the alignment on the pointer is such as you can steal 3 bits from there. Or as for string, the length can be used. It seems very realizable to me to have the JSONValue struct fit into 2 registers, granted the tag fit in 3 bits (8 different types). I can help with that if you want to. However, my goal when implementing this has never been to make the DOM representation as efficient as possible. The simple reason is that a DOM representation is inherently inefficient when compared to operating on the structure using either the pull parser or using a deserializer that directly converts into a static D type. IMO these should be advertised instead of trying to milk a dead cow (in terms of performance). Indeed. Still, JSON nodes should be as lightweight as possible. 2/ As far as I can see, the element are discriminated using typeid. An enum is preferable as the compiler would know values ahead of time and optimize based on this. It also allow use of things like final switch. Using a tagged union like structure is definitely what I'd like to have, too. However, the main goal was to build the DOM type upon a generic algebraic type instead of using a home-brew tagged union. The reason is that it automatically makes different DOM types with a similar structure interoperable (JSON/BSON/TOML/...). That is a great point that I haven't considered. I'd go the other way around about it: providing a compatible typeid based struct from the enum tagged one for compatibility. It can even be alias this so the transition is transparent. The transformation is not bijective, so that'd be great to get the most restrictive form (the enum) and fallback on the least restrictive one (alias this) when wanted. Now Phobos unfortunately only has Algebraic, which not only doesn't have a type enum, but is currently also really bad at keeping static type information when forwarding function calls or operators. The only options were basically to resort to Algebraic for now, but have something that works, or to first implement an alternative algebraic type and get it accepted into Phobos, which would delay the whole process nearly indefinitely. That's fine. Done is better than perfect. Still API changes tend to be problematic, so we need to nail that part at least, and an enum with fallback on typeid based solution seems like the best option. Or do you perhaps mean the JSON -> deserialize -> manipulate -> serialize -> JSON approach? That definitely is not a "loser strategy"*, but yes, it is limited to applications where you have a partially fixed schema. However, arguably most applications fall into that category. Yes.
Re: Where the F*** is phobos on OSX nowadays ?
Not at all, I am using dvm and I like it. But OTOH it makes things sometimes wierd. My common habit is to do something like this: dmd somefile && ./somefile. But without dvm I use latest (current installed vesion of dmd) but with dvm I use last setup vesion. And often I do not know which version of dmd I am using. Jacob Carlborg via Digitalmars-d napsal Út, srp 11, 2015 v 11∶04 : On 2015-08-11 10:01, John Colvin wrote: well if you're sane, then you had homebrew install it to /usr/local/lib/ and /usr/local/include/d2/ If you're sane you'll be using DVM ;) -- /Jacob Carlborg
Re: std.data.json formal review
On Tuesday, 11 August 2015 at 21:27:48 UTC, Sönke Ludwig wrote: That is not going to cut it. I've been working with these for ages. This is the very kind of scenarios where dynamically typed languages are way more convenient. I've used both quite extensively and this is clear cut: you don't want what you call the strongly typed version of things. I've done it in many languages, including in java for instance. jsvar interface remove the problematic parts of JS (use ~ instead of + for concat strings and do not implement the opDispatch part of the API). I just said that jsvar should be supported (even in its full glory), so why is that not going to cut it? Also, in theory, Algebraic already does more or less exactly what you propose (forwards operators, but skips opDispatch and JS-like string operators). Ok, then maybe there was a misunderstanding on my part. My understanding was that there was a Node coming from the parser, and that the node could be wrapped in some facility providing a jsvar like API. My position is that it is preferable to have whatever DOM node be jsvar like out of the box rather than having to wrap it into something to get that.
Re: std.data.json formal review
Am 04.08.2015 um 19:14 schrieb deadalnix: On Tuesday, 4 August 2015 at 13:10:11 UTC, Sönke Ludwig wrote: This is how it used to be in the vibe.data.json module. I consider that to be a mistake now for multiple reasons, at least on this abstraction level. My proposal would be to have a clean, "strongly typed" JSONValue and a generic jsvar like struct on top of that, which is defined independently, and could for example work on a BSONValue, too. The usage would simply be "var value = parseJSONValue(...);". That is not going to cut it. I've been working with these for ages. This is the very kind of scenarios where dynamically typed languages are way more convenient. I've used both quite extensively and this is clear cut: you don't want what you call the strongly typed version of things. I've done it in many languages, including in java for instance. jsvar interface remove the problematic parts of JS (use ~ instead of + for concat strings and do not implement the opDispatch part of the API). I just said that jsvar should be supported (even in its full glory), so why is that not going to cut it? Also, in theory, Algebraic already does more or less exactly what you propose (forwards operators, but skips opDispatch and JS-like string operators).
Re: std.data.json formal review
Am 11.08.2015 um 20:15 schrieb Dmitry Olshansky: On 11-Aug-2015 20:30, deadalnix wrote: Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. +1 Also most JS engines use nan-boxing to fit type tag along with the payload in 8 bytes total. At least the _fast_ path of std.data.json should take advantage of similar techniques. But the array field already needs 16 bytes on 64-bit systems anyway. We could surely abuse some bits there to at least not use up more for the type tag, but before we go that far, we should first tackle some other questions, such as the allocation strategy of JSONValues during parsing, the Location field and BigInt/Decimal support. Maybe we should first have a vote about whether BigInt/Decimal should be supported or not, because that would at least solve some of the controversial tradeoffs. I didn't have a use for those personally, but at least we had the real-world issue in vibe.d's implementation that a ulong wasn't exactly representable. My view generally still is that the DOM representation is something for convenient manipulation of small chunks of JSON, so that performance is not a priority, but feature completeness is.
Re: std.data.json formal review
Am 11.08.2015 um 19:30 schrieb deadalnix: Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. See http://s-ludwig.github.io/std_data_json/stdx/data/json/value/JSONValue.payload.html The question whether each field is "really" needed obviously depends on the application. However, the biggest type is BigInt that, form a quick look, contains a dynamic array + a bool field, so it's not as compact as it could be, but also not really large. There is also an additional Location field that may sometimes be important for good error messages and the like and sometimes may be totally unneeded. However, my goal when implementing this has never been to make the DOM representation as efficient as possible. The simple reason is that a DOM representation is inherently inefficient when compared to operating on the structure using either the pull parser or using a deserializer that directly converts into a static D type. IMO these should be advertised instead of trying to milk a dead cow (in terms of performance). 2/ As far as I can see, the element are discriminated using typeid. An enum is preferable as the compiler would know values ahead of time and optimize based on this. It also allow use of things like final switch. Using a tagged union like structure is definitely what I'd like to have, too. However, the main goal was to build the DOM type upon a generic algebraic type instead of using a home-brew tagged union. The reason is that it automatically makes different DOM types with a similar structure interoperable (JSON/BSON/TOML/...). Now Phobos unfortunately only has Algebraic, which not only doesn't have a type enum, but is currently also really bad at keeping static type information when forwarding function calls or operators. The only options were basically to resort to Algebraic for now, but have something that works, or to first implement an alternative algebraic type and get it accepted into Phobos, which would delay the whole process nearly indefinitely. 3/ Going from the untyped world to the typed world and provide an API to get back to the untyped word is a loser strategy. That sounds true intuitively, but also from my experience manipulating JSON in various languages. The Nodes produced by this lib need to be "manipulatable" as the unstructured values they represent. It isn't really clear to me what you mean by this. What exactly about JSONValue can't be manipulated like the "unstructured values [it] represent[s]"? Or do you perhaps mean the JSON -> deserialize -> manipulate -> serialize -> JSON approach? That definitely is not a "loser strategy"*, but yes, it is limited to applications where you have a partially fixed schema. However, arguably most applications fall into that category. * OT: My personal observation is that sadly the overall tone in the community has generally become a lot less friendly over the last months. I'm a bit worried about where this may lead in the long term.
Re: Where the F*** is phobos on OSX nowadays ?
On 2015-08-11 10:01, John Colvin wrote: well if you're sane, then you had homebrew install it to /usr/local/lib/ and /usr/local/include/d2/ If you're sane you'll be using DVM ;) -- /Jacob Carlborg
Re: std.data.json formal review
On 11-Aug-2015 20:30, deadalnix wrote: On Tuesday, 11 August 2015 at 17:08:39 UTC, Atila Neves wrote: On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote: Start of the two week process, folks. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ Atila I forgot to give warnings that the two week period was about to be up, and was unsure from comments if this would be ready for voting, so let's give it another two days unless there are objections. Atila Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. +1 Also most JS engines use nan-boxing to fit type tag along with the payload in 8 bytes total. At least the _fast_ path of std.data.json should take advantage of similar techniques. 2/ As far as I can see, the element are discriminated using typeid. An enum is preferable as the compiler would know values ahead of time and optimize based on this. It also allow use of things like final switch. 3/ Going from the untyped world to the typed world and provide an API to get back to the untyped word is a loser strategy. That sounds true intuitively, but also from my experience manipulating JSON in various languages. The Nodes produced by this lib need to be "manipulatable" as the unstructured values they represent. -- Dmitry Olshansky
Re: Binary file grammar
On Tuesday, 11 August 2015 at 13:40:52 UTC, wobbles wrote: On Tuesday, 11 August 2015 at 07:51:39 UTC, Atila Neves wrote: On Monday, 10 August 2015 at 12:29:43 UTC, wobbles wrote: I have to read a binary file. I can use std.stdio.File.rawRead to do this (and it's even typesafe, awesome!!) [...] https://github.com/atilaneves/cerealed If that doesn't do what you need, I've done something wrong. Atila Yep, this seems to do the job! I'll investigate tonight, and pester you later :D Pester away! That's what I get for putting it out there. :P Atila
Re: std.data.json formal review
On Tuesday, 11 August 2015 at 17:08:39 UTC, Atila Neves wrote: On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote: Start of the two week process, folks. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ Atila I forgot to give warnings that the two week period was about to be up, and was unsure from comments if this would be ready for voting, so let's give it another two days unless there are objections. Atila Ok some actionable items. 1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse. 2/ As far as I can see, the element are discriminated using typeid. An enum is preferable as the compiler would know values ahead of time and optimize based on this. It also allow use of things like final switch. 3/ Going from the untyped world to the typed world and provide an API to get back to the untyped word is a loser strategy. That sounds true intuitively, but also from my experience manipulating JSON in various languages. The Nodes produced by this lib need to be "manipulatable" as the unstructured values they represent.
Re: std.data.json formal review
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote: Start of the two week process, folks. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ Atila I forgot to give warnings that the two week period was about to be up, and was unsure from comments if this would be ready for voting, so let's give it another two days unless there are objections. Atila
Re: D fund
On Tuesday, 11 August 2015 at 14:26:45 UTC, Nick Sabalausky wrote: On 08/10/2015 01:10 PM, Tofu Ninja wrote: Would be great if D could have full time paid devs working on it. Totally. That would be a dream job @_@ I know right, where can I apply?
Re: Where the F*** is phobos on OSX nowadays ?
On Tuesday, 11 August 2015 at 16:12:12 UTC, Sebastiaan Koppe wrote: On Tuesday, 11 August 2015 at 08:01:53 UTC, John Colvin wrote: On Tuesday, 11 August 2015 at 04:51:03 UTC, deadalnix wrote: And why does it keep moving ? Why isn't it in some place where linker will find it ? Is that really worth it to have every build system to have to jump through hoops to find it, and to break it on a regular basis ? well if you're sane, then you had homebrew install it to /usr/local/lib/ and /usr/local/include/d2/ :p Does homebrew install to those folders by default? yes
Re: Where the F*** is phobos on OSX nowadays ?
On Tuesday, 11 August 2015 at 08:01:53 UTC, John Colvin wrote: On Tuesday, 11 August 2015 at 04:51:03 UTC, deadalnix wrote: And why does it keep moving ? Why isn't it in some place where linker will find it ? Is that really worth it to have every build system to have to jump through hoops to find it, and to break it on a regular basis ? well if you're sane, then you had homebrew install it to /usr/local/lib/ and /usr/local/include/d2/ :p Does homebrew install to those folders by default?
Re: Suggestion: arrays.
On Tuesday, 11 August 2015 at 09:08:57 UTC, John Colvin wrote:
2 choices:
1) break people's code and documentation by renaming .dup on
static arrays
2) have 2 equivalent names for the same thing
Neither is likely to happen.
If you want it for your own code:
T[] dyn(T, size_t n)(T[n] a)
{
return a.dup;
}
The OP could also make it a property to make it even more
similar. Perhaps the least amount of work would be if alias
worked on functions (I don't see anything in the docs about that).
The broader issue that it is very easy to mix up static and
dynamic arrays remains.
Re: D fund
On 08/10/2015 01:10 PM, Tofu Ninja wrote: Would be great if D could have full time paid devs working on it. Totally. That would be a dream job @_@
Re: Binary file grammar
On Tuesday, 11 August 2015 at 07:51:39 UTC, Atila Neves wrote: On Monday, 10 August 2015 at 12:29:43 UTC, wobbles wrote: I have to read a binary file. I can use std.stdio.File.rawRead to do this (and it's even typesafe, awesome!!) [...] https://github.com/atilaneves/cerealed If that doesn't do what you need, I've done something wrong. Atila Yep, this seems to do the job! I'll investigate tonight, and pester you later :D
Re: D fund
On 11/08/2015 4:58 a.m., vladde wrote: On Monday, 10 August 2015 at 01:34:24 UTC, Walter Bright wrote: On 8/9/2015 6:52 AM, Andrei Alexandrescu wrote: There will be a possibility with the D Language Foundation, hopefully by the end of this year. -- Andrei Looking forward to it. We can also use the foundation to sell some D swag so that people will get something for their donation. After all, nothing is cooler than wearing a D t-shirt to a C++/Java/Go/Rust convention! Will the swag feature http://dlangcomicstrips.tumblr.com/ ? Yeah who is making them? I'd love to add them as part of my stream!
Re: D fund
On Mon, 10 Aug 2015 16:58:13 +, vladde wrote: > Will the swag feature http://dlangcomicstrips.tumblr.com/ ? you told them about our little secret! how dare you?!. p.s. no, i'm not the author. signature.asc Description: PGP signature
Re: Binary file grammar
On Tue, 11 Aug 2015 07:51:37 +, Atila Neves wrote: > On Monday, 10 August 2015 at 12:29:43 UTC, wobbles wrote: >> I have to read a binary file. >> I can use std.stdio.File.rawRead to do this (and it's even typesafe, >> awesome!!) >> >> [...] > > https://github.com/atilaneves/cerealed > > If that doesn't do what you need, I've done something wrong. a strange thing: i myself used only cerealed, but somehow keep thinking that it was orange, and speaking about orange. i should setup autoreplacement in my nntp client... signature.asc Description: PGP signature
Re: D for Game Development
On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote: On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: [...] …[insert your language here] has a long way to go… :) Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack. Yes, it is not a good fit for D. Although, I find the Pony-lang approach interesting, but that is an actor language so it should not be compared to D, but to vibe.d. Pony uses a per heap GC, a cross actor GC, and actor collection (collecting the whole actor and heap when the actor cannot receive more messages). Each actor (fiber in D) does not have a stack, the stack is per thread so I believe you "yield" when the stack has been unwound, they only use C-ABI when calling C functions. But they also have an advanced pointer type system that can distinguish between at least 6 different reference-aliasing situations (or was it 12?). https://www.youtube.com/watch?v=KvLjy8w1G_U Anyway, it is refreshing. Maybe D can pick up some ideas from Pony.
Re: Suggestion: arrays.
On Tuesday, 11 August 2015 at 08:59:50 UTC, DLearner wrote:
From dlang:
Static array properties are:
...
.dup Create a dynamic array of the same size and copy the
contents of the array into it.
.idup Create a dynamic array of the same size and copy the
contents of the array into it. The copy is typed as being
immutable.
...
Dynamic array properties are:
...
.dup Create a dynamic array of the same size and copy the
contents of the array into it.
.idup Create a dynamic array of the same size and copy the
contents of the array into it. The copy is typed as being
immutable. D 2.0 only
...
<<<
The problem:
'dup' is an abbreviation of 'duplicate'.
However, for static arrays, result is not a true duplicate of
the source.
But, for dynamic arrays, result is a true duplicate.
So the same abbreviation produces two different effects.
Bugsource?
Suggested solution:
For static arrays, replace '.dup' with '.dyn' (and similarly
for 'idup').
Use of 'dyn' would also add clarity.
2 choices:
1) break people's code and documentation by renaming .dup on
static arrays
2) have 2 equivalent names for the same thing
Neither is likely to happen.
If you want it for your own code:
T[] dyn(T, size_t n)(T[n] a)
{
return a.dup;
}
Suggestion: arrays.
From dlang: Static array properties are: ... .dup Create a dynamic array of the same size and copy the contents of the array into it. .idup Create a dynamic array of the same size and copy the contents of the array into it. The copy is typed as being immutable. ... Dynamic array properties are: ... .dup Create a dynamic array of the same size and copy the contents of the array into it. .idup Create a dynamic array of the same size and copy the contents of the array into it. The copy is typed as being immutable. D 2.0 only ... <<< The problem: 'dup' is an abbreviation of 'duplicate'. However, for static arrays, result is not a true duplicate of the source. But, for dynamic arrays, result is a true duplicate. So the same abbreviation produces two different effects. Bugsource? Suggested solution: For static arrays, replace '.dup' with '.dyn' (and similarly for 'idup'). Use of 'dyn' would also add clarity.
Re: Where the F*** is phobos on OSX nowadays ?
On Tuesday, 11 August 2015 at 04:51:03 UTC, deadalnix wrote: And why does it keep moving ? Why isn't it in some place where linker will find it ? Is that really worth it to have every build system to have to jump through hoops to find it, and to break it on a regular basis ? well if you're sane, then you had homebrew install it to /usr/local/lib/ and /usr/local/include/d2/ :p
Re: D for Game Development
On Monday, 10 August 2015 at 05:23:20 UTC, Walter Bright wrote: On 8/9/2015 9:26 PM, Tofu Ninja wrote: On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote: On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote: On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d I agree, and now we ship a Phobos DLL, resolving that issue. Really? Where is it? (I can't see it in the distribution). Should be in the bin directory. There is no Phobos dll, only Phobos lib. There's linux/lib32/libphobos2.so, for example. But that is linux. You can't say "phobos dll" because everyone then expects dlls to work on windows, which still isn't the case. Its correct that we have a shared library version of phobos on linux, but a shared library version of phobos on windows is still in the future. I'm currently working on it, but there are so many issues with the language design, the export keyword, the module level visibility system the unittests etc etc that its going to take some more time. Also the front end transition from C++ to D hits me hard also.
Re: Binary file grammar
On Monday, 10 August 2015 at 12:29:43 UTC, wobbles wrote: I have to read a binary file. I can use std.stdio.File.rawRead to do this (and it's even typesafe, awesome!!) [...] https://github.com/atilaneves/cerealed If that doesn't do what you need, I've done something wrong. Atila
Re: D for Game Development
On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote: …[insert your language here] has a long way to go… :) Yes, the real culprit is getting really good IDE support, and for that one need to write a high quality analyzer that can provide more information than a compiler. As far as the language goes, I'd prefer a minimalistic core language backed up with a normalizing and caching solver. I don't really think fast initial compile time is all that important, if he compiler caches intermediate results intelligently I think one can get decent compilation speeds still.
Re: D for Game Development
On Sun, Aug 9, 2015 at 12:33 AM, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote: > >> If the libraries were shared, this would reduce linking time, which in >> various >> benchmarks I've done is where most small projects spend the majority of >> their >> time doing. But no one has as of yet come up with a feasibly >> implementable idea >> to do that. >> > > We ship Phobos as a shared library on Linux, OSX and FreeBSD. > on OSX I only see libphobos2.a (including dmd 2.068)
