Re: Digger 1.0
On Friday, 19 September 2014 at 01:36:54 UTC, Vladimir Panteleev wrote: Windows binaries: https://github.com/CyberShadow/Digger/releases/tag/1.0 Yet another release ruined by a DMD -inline wrong-code bug :( Reuploaded new .zip file without -inline.
Re: 438-byte Hello, world Win32 EXE in D
On Tuesday, 9 September 2014 at 20:07:33 UTC, Trass3r wrote: And how do ldc and gdc do? =) LDC doesn't do very well. It generates more verbose code, even with -Oz. I'll try GDC next. In other news, I switched from makefiles to a dedicated build tool, as their limitations were becoming constraining.
DMD v2.066.1-rc2
The second release candidate for v2.066.1 is now available for testing. Binaries may be obtained at http://wiki.dlang.org/Beta_Testing/. Happy testing.
Re: DMD v2.066.1-rc2
Andrew Edwards: The second release candidate for v2.066.1 is now available for testing. Binaries may be obtained at http://wiki.dlang.org/Beta_Testing/. Happy testing. In the site there is a link named DMD v2.067.0-b1. Perhaps it should be named DMD v2.067.0-a1 because it's an alpha version. Bye, bearophile
OpenSimplex Noise ported to D
Some of you may have noticed this article posted to /r/programming: http://uniblock.tumblr.com/post/97868843242/noise. I ported the algorithm to D and uploaded it here: https://github.com/Hackerpilot/OpenSimplexNoise-D
Re: RFC: reference counted Throwable
On 9/19/2014 10:32 PM, Ola Fosheim Grostad wrote: On Saturday, 20 September 2014 at 05:24:11 UTC, Walter Bright wrote: D can have ref counted objects, but it will not work with a compiler switch to switch them back and forth. They'll have to coexist peacefully with GC objects. If you don't expose the refcount, write libraries as if you have only RC, and don't expose destructors then you probably can. Just turn inc/dec into dummies. This doesn't address any of the 3 concerns.
Re: Signal flare: vibed.org throwing 500 errors
On Saturday, 20 September 2014 at 04:11:01 UTC, Tim Keating wrote: Okay, this is weird. This is only happening for me using Google Chrome on OS X 10.9. I can hit the site with Safari and Firefox just fine. I thought maybe I had some malicious infected extension or something (I was seeing some activity there in the network trace in the Chrome developer tools), so I disabled all my extensions. Still happening. And the error page looks very clearly like the output from the errorOut function in server.d. Which suggests to me that I'm getting to the server and it's legitimately sending me a 500 error. But there's no attached debugging information (debug_msg appears to be blank). Scratching my head at this point. TK Works with Chrome 37 on Linux.
Re: RFC: reference counted Throwable
On 9/19/2014 10:46 PM, Andrei Alexandrescu wrote: 2. To deal with (1), existing ARC systems allow escapes from it. This has severe implications for memory safety. Rust's entire type system appears to be designed around trying to deal with this, and AFAIK they're the only ones who have tried. C++ shared_ptr and ObjectiveC's ARC are not memory safe. They are not. Not not not, and they don't even try. :-) That's fine. You can't have everything. You're willing to dispense with memory safety? 3. ARC objects require an embedded count. This means they cannot be mixed with non-ARC objects. This is fundamentally DIFFERENT from how GC behaves, and we cannot pretend or wish this away or add a compiler switch to make it go away. In nogc mode, everything is ARC so I'm not getting this. Not even ARC languages try to make everything ARC - because it is BLOATED and SLOW. Not C++, not ObjectiveC, not Rust. D can have ref counted objects, but it will not work with a compiler switch to switch them back and forth. They'll have to coexist peacefully with GC objects. We need to figure out a design. All I'm saying is we must not bring prejudice to the table. And a very basic point is: there will be a way to COMPLETELY disable the GC. That is a must. It doesn't have to be disabled. Just don't call it. The GC is not a bridge troll that is going to pop up and extract a toll even if you aren't allocating with it.
Re: Library Typedefs are fundamentally broken
Am Fri, 19 Sep 2014 08:02:30 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: On 9/18/14, 11:45 PM, Marco Leise wrote: We should probably revert to having real typedefs. Should not. Ok, but don't ask me to use alias ALfloat = std.typecons.Typedef!(float, yummyCookie23); when it could be typedef ALfloat = float; ! :) I find myself not using Typedef either. Instead I use wrapper structs with alias this, because they fit the shoe much better by introducing a unique symbol in a straight forward way :) Rationale Typedef is not flexible enough to cover all use cases. This is better done with a language solution. What's missing? Andrei That was more of a pun on the original deprecation rationale: typedef is not flexible enough to cover all use cases. This is better done with a library solution. Frankly though it seems like templates are the improper tool to create new unique symbols when at the same time we more or less depend on templates only being instantiated once for the same arguments. -- Marco
Re: RFC: reference counted Throwable
Am 20.09.2014 06:43, schrieb Andrei Alexandrescu: On 9/19/14, 7:20 PM, Walter Bright wrote: On 9/19/2014 6:48 PM, Andrei Alexandrescu wrote: On 9/19/14, 6:18 PM, Walter Bright wrote: Having a compiler switch to change the behavior of every module in incompatible ways would be a disastrous balkanization. It has to be done in such a way that the ARC and the existing exceptions can coexist. Could you please elaborate why the disaster? -- Andrei 1. Every library for D will have to come in two versions. One which works, and the other is likely untested. This will divide the D community in half. I understand where you're coming from. And you're right that we're looking at an important change - as big as -m64 vs. -m32 or porting to a new platform. It's big. But it's needed, soon. And it would be, it seems to me, a mistake to approach this big change as a small change that we can sneak in. This judgment - that RC vs. GC would balkanize the community - has become a prejudice that is worth revisiting. Just trotting it out again won't do. 2. RC and GC engender different styles of programming. The idea that one can successfully switch between them with merely a compiler switch is a fantasy. You cannot write non-trivial programs that function well and pay no attention to how memory management is done. I think we're at a point where we owe it to ourselves to consider realizing the fantasy. Andrei This is one of the reasons why the Objective-C GC failed. Mixing Frameworks compiled with both modes never worked properly. -- Paulo
Re: Library Typedefs are fundamentally broken
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote: [snip] Um, why not use __FILE__ / __LINE__ (as default values for template parameters) as cookies?
Re: Voting: std.logger
Am Fri, 19 Sep 2014 15:12:34 + schrieb Robert burner Schadek rburn...@gmail.com: PRs are most welcome Ok, I'm working on it. From the looks of it I will iterate a bit on the code and create one massive pull request with a lot of smaller commits to make it comprehensible. -- Marco
Re: Library Typedefs are fundamentally broken
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei
Alexandrescu wrote:
This is wrong but probably not worth fighting. Consider:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them
magically distinct would be surprising and would require
explanation. It's as if someone writes:
struct Point { int x, y; }
alias A = Point;
and then later in the same module
alias B = Point;
But Typedef is not some generic symbol. It is library type
specifically introduced as `typedef` keyword replacement and
advertised as such. I expect it to work as close to `typedef` as
possible being the most priority. Otherwise it is simply useless.
I.e. Typedef is fail. Won't use.
Typedef is win. Feel free to not use.
Thanks for permitting, this is exactly what I will do.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 06:01:19 UTC, Walter Bright wrote: This doesn't address any of the 3 concerns. 1. RC efficiency is architecture dependent. E.g. TSX is coming even if there is a bug in lower end CPUs. Suggest making performance oriented prototypes on different architectures before concluding. 2. As long as you have a RC pointer to an obj on the stack you can switch to regular references. No magic involved for the easy case, just semantic analysis. 3. True, but you can keep the refcount at a negative offset for new-based allocations. Besides it only affects those who do @nogc and they should know what they are doing.
Re: Voting: std.logger
On Friday, 19 September 2014 at 11:48:28 UTC, Marco Leise wrote: By the way, does anyone else use std.experimental.logger yet? Dicebot? No, I provide purely management service here, aggregating reviews/opinions of other community members.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 02:26:49 UTC, Walter Bright wrote: On 9/19/2014 7:04 PM, Vladimir Panteleev wrote: On Saturday, 20 September 2014 at 01:19:05 UTC, Walter Bright wrote: Having a compiler switch to change the behavior of every module in incompatible ways would be a disastrous balkanization. Don't -version, -debug etc. have this problem anyway? I submit that it is a poor practice to write code that way. Anyway, if you change the name mangling, then you'll get link errors instead of mysterious crashes. It has to be done in such a way that the ARC and the existing exceptions can coexist. How? Good question. It's a challenge. But it has to be done, or D will divide in half and both halves will fail. We've had this discussion numerous times before - throw the magic compiler switch and D becomes an ARC system and everything is wonderful. It cannot work. ARC and GC are not equivalent. I am fully with Walter here. Only way to do it in acceptable way is to make both reference counted exceptions and current ones co-exist. Anything else means that we will need to distribute 4 builds of Phobos - debug-nogc, debug-gc, release-nogc, release-gc. Guess you can smell exponential explosion here as well as I do.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 04:53:32 UTC, Andrei Alexandrescu wrote: On 9/19/14, 8:30 PM, ketmar via Digitalmars-d wrote: On Fri, 19 Sep 2014 08:32:38 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: First, there must be some compiler flag -nogc or something, which please, no compiler switches! it's partly ok for -release, it's not very good for -version and it's awful to add another one which completely alters the way something works. as much as i want to make throwables nogc, it's better to change nothing than to add such switch. Changing nothing is not an option. Ideas? -- Andrei I have been thinking about something like `ARC` interface and `ARCException : Throwable, ARC` with all the automatic ref inc/dec calls you have mentioned added for any class that implements `ARC` interface.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 07:29:52 UTC, Dicebot wrote: I have been thinking about something like `ARC` interface and `ARCException : Throwable, ARC` with all the automatic ref inc/dec calls you have mentioned added for any class that implements `ARC` interface. ..and yes, I'd expect it to be the default one used by Phobos (possibly with some backing pool allocator). It isn't critical for GC-enabled applications to use GC-based exceptions but contrary is true.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 06:28:11 UTC, Paulo Pinto wrote: This is one of the reasons why the Objective-C GC failed. Mixing Frameworks compiled with both modes never worked properly. Yeah, mixing is bad unless you template eveything. But in pure nogc it would work. Except, I think most pure nogc projects want to eliminate rtti/exceptions too...
Re: Escaping the Tyranny of the GC: std.rcstring, first blood
On Friday, 19 September 2014 at 15:09:41 UTC, Andrei Alexandrescu wrote: It does affect management, i.e. you don't know when to free the buffer if slices are unaccounted for. So the design of slices are affected as much as that of the buffer. I see where you are going at. A bit hard to imagine how it fits the big picture when going bottom-up though but I trust you on this :) I agree that pipeline approach does not work that well for complex programs in general but strings seem to be best match to it - either you want read-only access or a pipe-line, everything else feels inefficient as amount of write operations gets out of control. Every single attempt to do something clever with shared CoW strings in C++ I have met was a total failure. What were the issues? Usually it went that way: 1) Get basic implementation, become shocked how slow it is because of redundant reference increments/decrements and thread safety 2) Add speed-up hacks to avoid reference count amending when considered unnecessary 3) Get hit by a snowball of synchronization / double-free issues and abandon the idea completely after months of debugging. Of course those weren't teams of rock-star programmers but at the same time more stupid approach with making extra copies and putting extra effort into defining strict linear ownership chain seemed to work much better. That is why I wonder - what kind of applications really need the rcstring as opposed to some generic rcarray? I started with rcstring because (a) it's easier to lift off the ground - no worries about construction/destruction of elements etc. and (b) it's frequent enough to warrant some good testing. Of course there'll be an rcarray!T as well. Thanks for explanation :) Well, I am curious how will it turn out but a bit skeptical right now.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 07:35:47 UTC, Ola Fosheim Grostad wrote: Except, I think most pure nogc projects want to eliminate rtti/exceptions too... It should be possible to do on top of plain @nogc Phobos by simply hooking into druntime _d_throw function and providing some own domain-specific handler instead. Of course it doesn't help if exceptions are used to indicate casual data processing signals but it is something else to be fixed in Phobos :)
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 06:28:11 UTC, Paulo Pinto wrote: This is one of the reasons why the Objective-C GC failed. Mixing Frameworks compiled with both modes never worked properly. -- Paulo Yes this was a huge failure to take into account. Linking code where Throwable inherits from Object with code where Throwable inherits from RCObject... :( If making the GC completely optional is a must, then error handling shouldn't rely on it at all, no? What about completely switching exception handling to RC ? Would it have an impact on memory safety since exeption handling mecanism is somehow magical code generated by the compiler ?
Re: RFC: reference counted Throwable
On 9/20/2014 1:43 PM, Andrei Alexandrescu wrote: On 9/19/14, 7:20 PM, Walter Bright wrote: On 9/19/2014 6:48 PM, Andrei Alexandrescu wrote: On 9/19/14, 6:18 PM, Walter Bright wrote: Having a compiler switch to change the behavior of every module in incompatible ways would be a disastrous balkanization. It has to be done in such a way that the ARC and the existing exceptions can coexist. Could you please elaborate why the disaster? -- Andrei 1. Every library for D will have to come in two versions. One which works, and the other is likely untested. This will divide the D community in half. I understand where you're coming from. And you're right that we're looking at an important change - as big as -m64 vs. -m32 or porting to a new platform. It's big. But it's needed, soon. And it would be, it seems to me, a mistake to approach this big change as a small change that we can sneak in. This judgment - that RC vs. GC would balkanize the community - has become a prejudice that is worth revisiting. Just trotting it out again won't do. Unless I'm missing something, Walter is referring specifically to the -nogc switch (or any such switch) and not to the concept of RC vs GC in general. And on that I am in strong agreement, FWIW. Recall back during the D1/D2, Phobos/Tango period, library maintainers had to either choose which D version and library to support (D1/Phobos, D1/Tango, D2/Phobos) or come up with a means of supporting all of them. Wrapper modules and mixins were a workable (though terribly annoying) solution for some cases, but not all. It was a nasty mess. I don't know yet what the ultimate impact of a -nogc switch would be on library maintenance, but I have a strong suspicion that simple wrapper modules and mixins wouldn't be enough to maintain compatibility. If there is even the slightest possibility that library maintainers will find themselves in that same situation of having to choose a or b because maintaining both is too troublesome to bother, then all the implications need to be hashed out beforehand. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: RFC: reference counted Throwable
19-Sep-2014 19:32, Andrei Alexandrescu пишет: As discussed, having exception objects being GC-allocated is clearly a large liability that we need to address. They prevent otherwise careful functions from being @nogc so they affect even apps that otherwise would be okay with a little litter here and there. The Throwable hierarchy is somewhat separate from everything else, which makes it a great starting point for investigating an automated reference count approach. Here's what I'm thinking. First, there must be some compiler flag -nogc or something, which triggers the RC exceptions. All modules of an application must be compiled with this flag if it is to work (such that one module can throw an exception caught by the other). Of course a lot of refinement needs to be added here (what happens if one tries to link modules built with and without -nogc, allowing people to detect the flag programmatically by using version(nogc) etc). If -nogc is passed, the compiler severs the inheritance relationship between Throwable and Object, making it impossible to convert a Throwable to an Object. From then henceforth, Throwable and Object form a two-rooted forest. (In all likelihood we'll later add an RCObject root that Throwable inherits.) Whenever a reference to a Throwable is copied about, passed to functions, the compiler inserts appropriately calls to e.g. incRef and decRef. (Compiler may assume they cancel each other for optimization purposes.) Implementation of these is up to the runtime library. Null checking may be left to either the compiler or the library (in the latter case, the functions must be nonmember). However it seems the compiler may have an advantage because it can elide some of these checks. Once we get this going, we should accumulate good experience that we can later apply to generalizing this approach to more objects. Also, if things go well we may as well define _always_ (whether GC or not) Throwable to be reference counted; seems like a good fit for all programs. All good, it wasn't a good idea to have GC-ed exceptions in the first place (It's a truly rare thing to have cycles of exceptions). It doesn' t matter GC or @nogc - this must go. Speaking of RC-ed Throwable - why adding a switch? Just make a transition in 2 steps - all exceptions inherit from RCObject (but stay essentially GC-ed), then hack compiler to perform ARC on RCObject descendants (maybe even with GC.malloc/GC.free for starters, i.e. the same heap). Then we can mess with custom allocation of these. I can understand a transitory switch, say -exception-ongc for the minority of folks that indeed DO rely on exceptions being GC and not counted. -- Dmitry Olshansky
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 05:46:44 UTC, Andrei Alexandrescu wrote: D can have ref counted objects, but it will not work with a compiler switch to switch them back and forth. They'll have to coexist peacefully with GC objects. We need to figure out a design. All I'm saying is we must not bring prejudice to the table. And a very basic point is: there will be a way to COMPLETELY disable the GC. That is a must. The ref counted objects still need to be considered as roots for the GC. This limits how much completely can be achieved.
Re: RFC: reference counted Throwable
On Friday, 19 September 2014 at 22:14:08 UTC, Andrei Alexandrescu wrote: On 9/19/14, 12:42 PM, Jacob Carlborg wrote: On 2014-09-19 17:32, Andrei Alexandrescu wrote: Whenever a reference to a Throwable is copied about, passed to functions, the compiler inserts appropriately calls to e.g. incRef and decRef. (Compiler may assume they cancel each other for optimization purposes.) Implementation of these is up to the runtime library. Are you suggesting we implement ARC? Yes. -- Andrei I don't think ARC is needed. library RC + borrowing + uniqueness/moving = WIN
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 08:20:47 UTC, Marc Schütz wrote: On Friday, 19 September 2014 at 22:14:08 UTC, Andrei Alexandrescu wrote: On 9/19/14, 12:42 PM, Jacob Carlborg wrote: On 2014-09-19 17:32, Andrei Alexandrescu wrote: Whenever a reference to a Throwable is copied about, passed to functions, the compiler inserts appropriately calls to e.g. incRef and decRef. (Compiler may assume they cancel each other for optimization purposes.) Implementation of these is up to the runtime library. Are you suggesting we implement ARC? Yes. -- Andrei I don't think ARC is needed. library RC + borrowing + uniqueness/moving = WIN You can't do polymorphic entity RC (like exceptions) without at least some help from compiler because language currently does not provide tools for lifetime control of classes. At least _some_ form of ARC is necessary.
Re: [Semi OT] Language for Game Development talk
He also proposes of removing most or all implicit type
conversions in his language, like bool-int.
D allows code like:
bool foo() { return true; }
void bar(int x) {}
void main() {
bar(foo());
}
In past, removing implicit conversions from D forced you to write:
bar(cast(int)foo());
That is not much safer than having implicit conversions because
cast() is a sharp powerful tool. In D programs the usage of
cast() should be minimized as much as possible.
But if we keep disallowing implicit conversions, but we introduce
a second kind of static cast that only work if the conversion is
lossless, then we have code like (currently this is allowed in D
because the int() syntax rides on the implicit conversions. So
the semantic is a little different):
bar(int(foo()));
You also need suffixes to express most types with literals (like
10u8 for an ubyte, or 'c'd for a dchar), to code in a more handy
way.
Perhaps this new situation (no implicit conversions, plus two
kinds of casts, and few extra literals) is safer than the current
D situation (and I think no C code gains a new working meaning in
this new situation).
Bye,
bearophile
Re: RFC: reference counted Throwable
On 9/20/2014 12:17 AM, Ola Fosheim Grostad wrote: On Saturday, 20 September 2014 at 06:01:19 UTC, Walter Bright wrote: This doesn't address any of the 3 concerns. 1. RC efficiency is architecture dependent. Please show me the efficient assembler for the x86. E.g. TSX is coming even if there is a bug in lower end CPUs. Suggest making performance oriented prototypes on different architectures before concluding. I'd love to see it. 2. As long as you have a RC pointer to an obj on the stack you can switch to regular references. No magic involved for the easy case, just semantic analysis. As soon as you pass a reference to a function, that all goes out the window. There's a reason why Rust has invested so much effort in the notion of a borrowed pointer. 3. True, but you can keep the refcount at a negative offset for new-based allocations. Besides it only affects those who do @nogc and they should know what they are doing. If this is so simple, why doesn't everyone do it?
Re: RFC: reference counted Throwable
I'm quite a noobie in memory models but from position of user of D language I have some ideas about syntax of switching between memory models. I think that having everywhere declarations using wrapper structs (like RefCounted) is not very user-friendly. But still we need some way to say to compiler how we want to do memory management. I have read tutorial about Rust language. It looks not very clear for me, but I like the idea that type of memory management is included in variable declaration. Intead of wrapper struct like scoped!A or RefCounted!A we could declare variables with annotations (attributes in D) to say what memory model we want to use. Compiler should understand this annotation and create some code for memory management. I thing it's possible to declare some interface (maybe struct with compile-time duck typing) to support some user-defined memory models or modifications of basic (implemented in a language) memory models. Why I am saying about annotations? Because we can annotate some function, class or just block at the module scope that should use some sort of memory management and compiler will create corresponding code. In that case we don't need to put wrapper struct around all variables that use ref counting. We just annotate some function or class declaration as ref-counted and that's it! It's just a concept of what I like to see in the language design of D in future)) Of course there are a lot of problems in a practice. Also I think that we shouldn't impose some way of memory model to programmer and let him choose his approach but syntax should be simple and clear as much as it could be. Also some defaults should be for most common cases and for *novice* users of D. Waiting for critic or thoughts!!!))
Re: RFC: reference counted Throwable
Also it's interesting waht is the correspondence between memory management, memory model and allocators? I know that std.allocator is in development. I guess that it should be considered in complex.
Re: [Semi OT] Language for Game Development talk
On Saturday, 20 September 2014 at 08:38:49 UTC, bearophile wrote: Perhaps this new situation (no implicit conversions, plus two kinds of casts, and few extra literals) is safer than the current D situation (and I think no C code gains a new working meaning in this new situation). He want go-semantics. It also means that literals are untyped until bound, so you can do high precision calculations at compile time. I would also like to see these explicit conversions (and find hacks like alias this somewhat annoying). I also think arithmetics on ubytes should be done as ubytes etc to allow SIMD vectorization. Go semantics is described well here: http://blog.golang.org/constants
Re: [Semi OT] Language for Game Development talk
On Saturday, 20 September 2014 at 08:46:34 UTC, Ola Fosheim Grostad wrote: I also think arithmetics on ubytes should be done as ubytes etc to allow SIMD vectorization. Array operations do use SIMD. The code for this is in druntime. https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 08:32:55 UTC, Dicebot wrote: On Saturday, 20 September 2014 at 08:20:47 UTC, Marc Schütz wrote: I don't think ARC is needed. library RC + borrowing + uniqueness/moving = WIN You can't do polymorphic entity RC (like exceptions) without at least some help from compiler because language currently does not provide tools for lifetime control of classes. At least _some_ form of ARC is necessary. I think we can, using templated alias this. We're not there yet, but it's probably feasable, seeing that Igor Stepanov already implemented multiple alias this [1]. With that and maybe a little opDispatch magic, it should be possible to making wrappers that are implicitly convertible to wrappers of parents of their inner types. Granted, for exceptions there's more needed: There needs to be support for throwing and catching these wrappers, and for catching wrappers of derived types, too. But note that throw/catch itself doesn't involve copying, it's a moving operation, which might make it easier. [1] https://github.com/D-Programming-Language/dmd/pull/3998
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 09:05:15 UTC, ponce wrote: On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote: Please chime in with thoughts. Coudln't we throw value types instead? (like in C++) But how would you chain them? And they have to implement Throwable's interface.
Re: [Semi OT] Language for Game Development talk
Brian Schott: Array operations do use SIMD. Array ops aren't used often in most normal D code. Most usages of SIMD should come from auto-vectorization and core.simd (but perhaps core.simd design was not discussed and improved enough, and the implicit upcasting semantics of C could hurt auto-vectorization). Bye, bearophile
Re: RFC: reference counted Throwable
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote: Please chime in with thoughts. Coudln't we throw value types instead? (like in C++)
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 09:05:24 UTC, Marc Schütz wrote: On Saturday, 20 September 2014 at 08:32:55 UTC, Dicebot wrote: On Saturday, 20 September 2014 at 08:20:47 UTC, Marc Schütz wrote: I don't think ARC is needed. library RC + borrowing + uniqueness/moving = WIN You can't do polymorphic entity RC (like exceptions) without at least some help from compiler because language currently does not provide tools for lifetime control of classes. At least _some_ form of ARC is necessary. I think we can, using templated alias this. We're not there yet, but it's probably feasable, seeing that Igor Stepanov already implemented multiple alias this [1]. With that and maybe a little opDispatch magic, it should be possible to making wrappers that are implicitly convertible to wrappers of parents of their inner types. Granted, for exceptions there's more needed: There needs to be support for throwing and catching these wrappers, and for catching wrappers of derived types, too. But note that throw/catch itself doesn't involve copying, it's a moving operation, which might make it easier. [1] https://github.com/D-Programming-Language/dmd/pull/3998 Yeah but implicitly convertible to what? If you convert it to `Throwable` your reference counting facilities are circumvented resulting in dangling exception reference at point where `Throwable` gets caught. Special casing catching such wrappers to still preserve original ref-counted type while pretending to be Throwable at call site sounds like a terrible hack, much worse than any sort of ARC complexity.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 09:05:24 UTC, Marc Schütz wrote: On Saturday, 20 September 2014 at 08:32:55 UTC, Dicebot wrote: On Saturday, 20 September 2014 at 08:20:47 UTC, Marc Schütz wrote: I don't think ARC is needed. library RC + borrowing + uniqueness/moving = WIN You can't do polymorphic entity RC (like exceptions) without at least some help from compiler because language currently does not provide tools for lifetime control of classes. At least _some_ form of ARC is necessary. I think we can, using templated alias this. We're not there yet, but it's probably feasable, seeing that Igor Stepanov already implemented multiple alias this [1]. With that and maybe a little opDispatch magic, it should be possible to making wrappers that are implicitly convertible to wrappers of parents of their inner types. Granted, for exceptions there's more needed: There needs to be support for throwing and catching these wrappers, and for catching wrappers of derived types, too. But note that throw/catch itself doesn't involve copying, it's a moving operation, which might make it easier. [1] https://github.com/D-Programming-Language/dmd/pull/3998 Thinking further about it, we don't need templated `alias this`, because we can just have one `alias this` that returns `scope!this(T)` (this needs to be there anyway to be safe). It would automatically behave like a normal class with regard to polymorphy. What's still needed then is a little magic to actually be able to throw and catch the wrapper.
Re: Once in a while, you got to stop complaining and say thank you.
Btw was there any specific commit / release that reduced memory concumption or it was a gradual improvement? No idea. One could use Digger to generate a graph of SDC build times over time like in the DConf talk.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 08:39:41 UTC, Walter Bright wrote: E.g. TSX is coming even if there is a bug in lower end CPUs. Suggest making performance oriented prototypes on different architectures before concluding. I'd love to see it. A 128 bit CAS instruction is at about 19-25 cycles, but a transaction on the other hand can by using xbegin/xend cover both refcounting, locking and rollback of multiple objects so you need cooperation from code gen. Basically all changes between xbegin/xend are kept in cache and written to memory upon success. On failure you have a slower fallback. I don't know what that leads to in amortized cost reduction, but 30-70% might be possible if it is done right. As soon as you pass a reference to a function, that all goes out the window. There's a reason why Rust has invested so much effort in the notion of a borrowed pointer. The pure @nogc crowd care less about safety, but you should be able to track this using dataflow? 3. True, but you can keep the refcount at a negative offset for new-based allocations. Besides it only affects those who do @nogc and they should know what they are doing. If this is so simple, why doesn't everyone do it? Never said performance and thread safe RC was easy. It is probably difficult to get below 10 cycles for inc/dec pairs even with excellent code gen...? And probably closer to 40 cycles for regular code gen. Just guessing.
Re: Voting: std.logger
Seeing how MultiLogger passes on the payload to its child
loggers by ref, I tried to make it const, so that no Logger
implementation can correct any of the values and spoil it
for the others in the list.
Then I noticed, that isn't possible because the payloads
contain indirections and one logger takes payloads apart into
separate variables (FileLogger) while others build payloads
from separate variables. Catch 22. You cannot have:
protected void beginLogMsg(string file, int line, string funcName,
string prettyFuncName, string moduleName, LogLevel logLevel,
Tid threadId, SysTime timestamp, Logger logger)
@trusted
{
static if (isLoggingActive)
{
header = LogEntry(file, line, funcName, prettyFuncName,
moduleName, logLevel, threadId, timestamp, null, logger);
}
}
and
override void writeLogMsg(const ref LogEntry payload)
{
this.beginLogMsg(payload.file, payload.line, payload.funcName,
payload.prettyFuncName, payload.moduleName, payload.logLevel,
payload.threadId, payload.timestamp, payload.logger);
…
}
.
Also I wonder if Tid is the correct information to pass in.
It is actually just an MBox from std.concurrency. The real
thread handle is the Thread, which also contains its name,
which might be more useful for logging. What do you think?
--
Marco
Re: Voting: std.logger
On Saturday, 20 September 2014 at 10:24:30 UTC, Marco Leise wrote: Also I wonder if Tid is the correct information to pass in. It is actually just an MBox from std.concurrency. The real thread handle is the Thread, which also contains its name, which might be more useful for logging. What do you think? See also https://github.com/D-Programming-Language/phobos/pull/2482 For std.log I think Tid more useful because it clearly denotes execution context while thread ID is more of an implementation detail (considering message-passing is promoted as a standard D thing)
Re: [Semi OT] Language for Game Development talk
Am 20.09.2014 01:47, schrieb Max Klyga: Jonathan Blow just recorded a talk about the needs and ideas for a programming language for game developer. https://www.youtube.com/watch?v=TH9VCN6UkyQ This talk mentions D quite a lot of times. D is mentioned as the most probable to be adopted if it were possible for frictionless interaction with existing codebase. An interesting talk if you want to look at language design from game developer perspective. Many of his wishes have been answered in Algol68(1973), Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 (1990), but the industry at large decided to go elsewhere instead. Which in the end boils down to this: Although the first edition of KR described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. -- Dennis Ritche on history of C. Already in 1979 it was clear that C without syntax analysis tooling wasn't a good idea. This of course, also had an impact in C++ and Objective-C. -- Paulo
Re: [Semi OT] Language for Game Development talk
On Saturday, 20 September 2014 at 09:09:56 UTC, bearophile wrote: Brian Schott: Array operations do use SIMD. Array ops aren't used often in most normal D code. Most usages of SIMD should come from auto-vectorization and core.simd (but perhaps core.simd design was not discussed and improved enough, and the implicit upcasting semantics of C could hurt auto-vectorization). Yes, I was thinking of auto vectorization/masking. Handcrafted simd is nice too, but I feel it is better done in a way the backend can understand. You might also want the compiler to generate fallback paths for older cpus...
Re: [Semi OT] Language for Game Development talk
Am 20.09.2014 04:25, schrieb po: He actually talks about Andre around 40' ;0 As a fellow game dev: I don't agree with him about RAII, I find it useful He seems to miss the point that it is possible to write general purpose RAII templated classes, since he keeps on talking about specific implementations for each type of resources. He kind of has a point about exceptions, I'm not big on them Exceptions in most programming languages that have them are a good idea. Exceptions in C++ are a broken concept. Having to cope with C semantics, ability to disable them and mixing code bases is what leads to the pain of writing exception safe code in C++. I get the impression his C++ knowledge is about the level of C++ with classes, ie very low. At the end he states having only read KR C, with everything else being learning on the job, it seems. He claims using std:: inherently causes slow compilation, my experience says otherwise. Back when I was stil working with C++ at day job, doing a make world in a code base with Tools.h++ would cost a few hours. And we were using ClearMake optimized build infrastructure. You can have fast builds, but it requires knowledge of the whole architecture and coding for the build system, e.g. separating modules into real libraries. He goes on about freeing free'd memory, this is never something that would happen in modern C++, so he is basically proposing an inferior language design. At one point he says you can't see the contents of std::vector in a debugger. What? This is trivial and has worked in every version of Visual Studio for the last 5+ years. It also surprised me. Visual Studio has the best developer experience in terms of visualizing C++ data structures. I do agree the build systems used with C++ are idiotic IMO, C++'s complexity is largely because of the stupid headers and all the mind numbing crap associated with it. That and the lack of any reflection. I wonder if modules in C++17 will already be too late. By then, when looking at C++ project, it might be pre-C++98, C++11, C++14, C++17 with the accumulated set of semantics, differences and styles each standard revision brings to the table. -- Paulo
Re: [Semi OT] Language for Game Development talk
On Saturday, 20 September 2014 at 11:11:23 UTC, Paulo Pinto wrote: Many of his wishes have been answered in Algol68(1973), Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 (1990), but the industry at large decided to go elsewhere instead. I didn't get that impression. Seems like he wants to cover existing practices in a more time saving package, then add some neat stuff: - automatic region allocator per object - ctfe including executing external programs - uda + static reflection - debugging tools for freeing shared memory (without rc/tracing) - go style literals + type system? - swift style nullable Seems he wants a streamlined nogc/nothrow version of D with a dedicated syntax for his field. D could probably be modified to fit pretty well.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 09:19:21 UTC, Dicebot wrote:
On Saturday, 20 September 2014 at 09:05:24 UTC, Marc Schütz
wrote:
On Saturday, 20 September 2014 at 08:32:55 UTC, Dicebot wrote:
On Saturday, 20 September 2014 at 08:20:47 UTC, Marc Schütz
wrote:
I don't think ARC is needed.
library RC + borrowing + uniqueness/moving = WIN
You can't do polymorphic entity RC (like exceptions) without
at least some help from compiler because language currently
does not provide tools for lifetime control of classes. At
least _some_ form of ARC is necessary.
I think we can, using templated alias this. We're not there
yet, but it's probably feasable, seeing that Igor Stepanov
already implemented multiple alias this [1]. With that and
maybe a little opDispatch magic, it should be possible to
making wrappers that are implicitly convertible to wrappers of
parents of their inner types.
Granted, for exceptions there's more needed: There needs to be
support for throwing and catching these wrappers, and for
catching wrappers of derived types, too. But note that
throw/catch itself doesn't involve copying, it's a moving
operation, which might make it easier.
[1] https://github.com/D-Programming-Language/dmd/pull/3998
Yeah but implicitly convertible to what? If you convert it to
`Throwable` your reference counting facilities are circumvented
resulting in dangling exception reference at point where
`Throwable` gets caught.
As I said, throw/catch is at its core a moving operation. For
classes this isn't important (they are references), but for an RC
wrapper it would be, so we could specify that.
Move-constructing from an lvalue in the context of D can be seen
as a three-step process:
1) create a temporary, initialize with T.init
2) bit-swap the variable with the temporary
3) destroy the variable
It can be seen that the value that is to be moved (the RC
wrapper) must be non-const (only at the head, it may still be
tail-const).
Now, any generic RC type that wants to be implicitly convertible
to its payload type must do this via borrowing in order to be
safe (see my proposal at [1]). Using const-borrowing, we can
guarantee that the wrapper will not be thrown (or moved, in
general) as long as borrowed references to its payload exist:
struct RC(T) {
// ...
T _payload;
scope!(const this) borrow() {
return _payload;
}
alias borrow this;
}
This already solves avoiding dangling references to the
exception: No references can be left behind when the exception is
thrown, and the wrapper will not be destroyed, but moved, thus
not releasing the exception's memory.
The second part is really just some way to transport the
wrapper via the exception mechanism, including support for
catching wrappers of derived exception types.
Special casing catching such wrappers to still preserve
original ref-counted type while pretending to be Throwable at
call site sounds like a terrible hack, much worse than any sort
of ARC complexity.
IMO it would only a hack _if_ they were indeed special cased. I'm
sure we can find a more generic mechanism that would allow this
to be implemented cleanly. Note that the other requirements I
described above (borrowing, move semantics) are also things that
just happen to be usable here: they are desirable in general,
exceptions are just one possible application.
[1] http://wiki.dlang.org/User:Schuetzm/scope
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 04:48:33 UTC, Andrei Alexandrescu wrote: I basically agree with Walter on this one, no switch please, it's maintenance nightmare for library devs. Why is it a maintenance nightmare? Sorry, let's defer this, I might have overstated the negative side-effects before carefully considering methods to mitigate the impact. My proposal would be to permanently use ARC for Throwable, no flags. How about other objects? Throwable is but the first step, and a good one to inform larger designs. We can't force RC on all objects on all applications. I was viewing everything from a totally different perspective: Normally what prevents an API to be nogc is exceptions, even _emplace_ falls victim of this, in my line of reasoning I was counting on the ripple effect to get us quite far, the remaining issues could be fixed by refining the API to make it possible to avoid allocations if desired. However, since you had a different goal in mind, your solution starts making more sense to me, it's also very easy to flip a switch and benchmark individual applications, maybe people from both camps will be surprised at the results. What does the GC bring to exceptions that makes it sufficiently invaluable to warrant two parallel implementations? It can't be about performance, since _thrown_ exceptions are already in the slow path... Backwards compatibility? Conversion from Throwable to Object. Andrei The conversion could allocate on the GC, which would be functionally backwards compatible and if the performance degradation is a concern the code could be updated to avoid the superfluous allocation by staying in the RCObject hierarchy. Daniel
Re: Signal flare: vibed.org throwing 500 errors
Am 20.09.2014 06:11, schrieb Tim Keating: Okay, this is weird. This is only happening for me using Google Chrome on OS X 10.9. I can hit the site with Safari and Firefox just fine. I thought maybe I had some malicious infected extension or something (I was seeing some activity there in the network trace in the Chrome developer tools), so I disabled all my extensions. Still happening. And the error page looks very clearly like the output from the errorOut function in server.d. Which suggests to me that I'm getting to the server and it's legitimately sending me a 500 error. But there's no attached debugging information (debug_msg appears to be blank). Scratching my head at this point. TK Works for me with Chrome 37 on OS X 10.9.2. I've enabled some more debugging output, so hopefully it will output something useful next time. BTW, it's also theoretically possible that the site was simply down for a few seconds. The gateway proxy currently still returns a 500 error instead of 502 in that case. There have been some RangeViolation errors in the log (without call trace unfortunately), which have caused the site to get restarted.
Re: RFC: reference counted Throwable
Andrei Alexandrescu: Are you suggesting we implement ARC? Yes. -- Andrei I think it's better first to design implement a first version of memory ownership management, and then later add a reference counting scheme. Bye, bearophile
Re: RFC: reference counted Throwable
On 2014-09-19 17:32, Andrei Alexandrescu wrote: Whenever a reference to a Throwable is copied about, passed to functions, the compiler inserts appropriately calls to e.g. incRef and decRef. (Compiler may assume they cancel each other for optimization purposes. Assuming this would eventually be implemented for regular classes, it would be nice if it could be made compatible with Objective-C ARC [1]. [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html -- /Jacob Carlborg
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 11:50:28 UTC, Marc Schütz wrote:
On Saturday, 20 September 2014 at 09:19:21 UTC, Dicebot wrote:
Yeah but implicitly convertible to what? If you convert it to
`Throwable` your reference counting facilities are
circumvented resulting in dangling exception reference at
point where `Throwable` gets caught.
As I said, throw/catch is at its core a moving operation. For
classes this isn't important (they are references), but for an
RC wrapper it would be, so we could specify that.
Move-constructing from an lvalue in the context of D can be
seen as a three-step process:
1) create a temporary, initialize with T.init
2) bit-swap the variable with the temporary
3) destroy the variable
It can be seen that the value that is to be moved (the RC
wrapper) must be non-const (only at the head, it may still be
tail-const).
Now, any generic RC type that wants to be implicitly
convertible to its payload type must do this via borrowing in
order to be safe (see my proposal at [1]). Using
const-borrowing, we can guarantee that the wrapper will not be
thrown (or moved, in general) as long as borrowed references to
its payload exist:
struct RC(T) {
// ...
T _payload;
scope!(const this) borrow() {
return _payload;
}
alias borrow this;
}
This already solves avoiding dangling references to the
exception: No references can be left behind when the exception
is thrown, and the wrapper will not be destroyed, but moved,
thus not releasing the exception's memory.
The second part is really just some way to transport the
wrapper via the exception mechanism, including support for
catching wrappers of derived exception types.
Special casing catching such wrappers to still preserve
original ref-counted type while pretending to be Throwable at
call site sounds like a terrible hack, much worse than any
sort of ARC complexity.
IMO it would only a hack _if_ they were indeed special cased.
I'm sure we can find a more generic mechanism that would allow
this to be implemented cleanly. Note that the other
requirements I described above (borrowing, move semantics) are
also things that just happen to be usable here: they are
desirable in general, exceptions are just one possible
application.
[1] http://wiki.dlang.org/User:Schuetzm/scope
The mechanism might simply be to allow anything to be thrown that
a) supports moving, e.g. provides a method `release()` that
returns a unique expression (this requires moving and uniqueness
to be specified first, which is a good idea anyway), and
b) is implicitly convertible to Throwable.
What are the worst parts of D?
There was a recent video[1] by Jonathan Blow about what he would want in a programming language designed specifically for game development. Go, Rust, and D were mentioned and his reason for not wanting to use D is is that it is too much like C++ although he does not really go into it much and it was a very small part of the video it still brings up some questions. What I am curious is what are the worst parts of D? What sort of things would be done differently if we could start over or if we were designing a D3? I am not asking to try and bash D but because it is helpful to know what's bad as well as good. I will start off... GC by default is a big sore point that everyone brings up is expressions are pretty wonky Libraries could definitely be split up better What do you think are the worst parts of D? [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 08:42:51 UTC, Uranuz wrote: I'm quite a noobie in memory models but from position of user of D language I have some ideas about syntax of switching between memory models. I think that having everywhere declarations using wrapper structs (like RefCounted) is not very user-friendly. But still we need some way to say to compiler how we want to do memory management. I have read tutorial about Rust language. It looks not very clear for me, but I like the idea that type of memory management is included in variable declaration. Intead of wrapper struct like scoped!A or RefCounted!A we could declare variables with annotations (attributes in D) to say what memory model we want to use. Compiler should understand this annotation and create some code for memory management. I thing it's possible to declare some interface (maybe struct with compile-time duck typing) to support some user-defined memory models or modifications of basic (implemented in a language) memory models. Why I am saying about annotations? Because we can annotate some function, class or just block at the module scope that should use some sort of memory management and compiler will create corresponding code. In that case we don't need to put wrapper struct around all variables that use ref counting. We just annotate some function or class declaration as ref-counted and that's it! It's just a concept of what I like to see in the language design of D in future)) Of course there are a lot of problems in a practice. Also I think that we shouldn't impose some way of memory model to programmer and let him choose his approach but syntax should be simple and clear as much as it could be. Also some defaults should be for most common cases and for *novice* users of D. Waiting for critic or thoughts!!!)) You are right that there is an intricate relationship between the various types of memory (better: ownership) management, allocators, ref-counting, uniqueness, moving etc, as you write in your other post. They interact in very specific ways. For this reason I don't think it is feasible or desirable to set the type of memory management from the outside, the types in question need to know how their innards work. In the same vein, if your code uses a specific memory management strategy, it has to be written in a way conforming to it. Walter has already stated that: you cannot simply slap an attribute onto your code saying please do reference counting, and expect it to work, especially not efficiently. I think we can get a lot further if we work out said relationships, and create good general purpose wrapper types that implement the different strategies accordingly. I believe, borrowing is crucial to this, which is why I made a proposal about it [1], which also deals with the other related topics. You do have a point about a simple, accessible syntax being important. Still, I don't see a big difference between @annotations and RC!T wrappers in this regard (except that the former could apply to entire sections of code, which is not a good idea IMO). And I think with auto/scope/const type deduction, code is quite pleasant to read. [1] http://wiki.dlang.org/User:Schuetzm/scope
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? 1. The whining in the forums. 2. Lacks focus on a dedicated application area. 3. No strategy for getting more people on board. 4. No visible roadmap. 5. Too much focus on retaining C semantics (go does a bit better) 6. Inconsistencies and hacks (too many low hanging fruits) 7. More hacks are being added rather than removing existing ones. 8. Not enough performance oriented process. 9. It's mysteriously addictive and annoying at the same time. 10. It's contagious and now I'm in bed with a cold.
Re: What are the worst parts of D?
On 21/09/2014 12:39 a.m., Tofu Ninja wrote: GC by default is a big sore point that everyone brings up I like having a GC by default. But we really need to think of it as a last resort sort of thing. is expressions are pretty wonky Ehh yeah, D3 we could I spose. Libraries could definitely be split up better We can still fix that in D2. Just as a note, we do want AST macros for D3. Which will be awesome! Stuff like linq from c# could be done as a library.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 12:27:23 UTC, Jacob Carlborg wrote: Assuming this would eventually be implemented for regular classes, it would be nice if it could be made compatible with Objective-C ARC [1]. [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html Isn't Objective-C ARC known to be terribly efficient?
Re: Voting: std.logger
Ok, then here are my thread-safety changes for std.logger: https://github.com/burner/logger/pull/19 -- Marco
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 13:31:06 UTC, Rikki Cattermole wrote: Just as a note, we do want AST macros for D3. Which will be awesome! What kind of macros? Generic AST macros probably make source to source translation just as difficult as string mixins, don't they? Some simple term-rewriting is probably cleaner?
Re: Library Typedefs are fundamentally broken
Am Sat, 20 Sep 2014 06:32:38 + schrieb Vladimir Panteleev vladi...@thecybershadow.net: On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote: [snip] Um, why not use __FILE__ / __LINE__ (as default values for template parameters) as cookies? It has this nasty imperfection that it breaks as soon as you define two Typedefs on the same line. Which noone ever does except maybe for an obfuscated coding scenario, but still it raises my OCD level. -- Marco
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 13:30:24 UTC, Ola Fosheim Grostad wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? 1. The whining in the forums. 2. Lacks focus on a dedicated application area. 3. No strategy for getting more people on board. 4. No visible roadmap. Not really a problem with the language. Just problems. 5. Too much focus on retaining C semantics (go does a bit better) 6. Inconsistencies and hacks (too many low hanging fruits) 7. More hacks are being added rather than removing existing ones. Definitely can agree, I think it has to do with the sentiment that it is too much like C++ 8. Not enough performance oriented process. Not sure what you are saying, are you saying there is not a big enough focus on performance? 9. It's mysteriously addictive and annoying at the same time. Is that a problem? 10. It's contagious and now I'm in bed with a cold. :
Re: RFC: reference counted Throwable
How often do you store an exception reference anyway that escapes a catch block? I think all this talk is overkill to solve a non-problem in 99% of practice. Correct me if I'm wrong, but aren't *all* exceptions in a particular thread generally unreferenced at the end of a catch() block, unless the programmer explicitly escaped that reference? If so, we don't need refcounting! Here's my solution: 1) Throwables are allocated in a separate thread-local memory pool than most other objects. The @nogc version just aborts the program if this pool ever runs out of memory. The gc version can do a collection cycle and grow the size if necessary. (Though if you need a lot of Throwable objects alive at once, I question wtf is up with your code...) 2) class Throwable adds a method, gcClone, which copies it to the regular GC heap for those cases when you do want to store it or pass it between threads or whatever. 3) A function, @system void clearExceptions() is added. You may manually call this when you are done handling exceptions in this thread. 4) Might also have @safe void prepareExceptions() which pre-allocates the pool. This could also be done automatically or on demand or whatever. Advantages: * Throwables are still GC managed as far as most code is concerned. The only time you need caution is if you call the new @system function to free the pool... and even then, you just make sure you don't escape those references before you do. * If you want to avoid the GC, just manually clear your exceptions from time to time. * Allocating/deallocating from this specialized memory pool is prolly faster than any other scheme anyway. * No language changes required, this is all library stuff. Disadvantages: * There's a few manual steps to get all the benefit. (We could insert a call to clearExceptions at the end of catch blocks automatically, but without a static check to ensure the objects actually haven't escaped, this would break memory safety. But a manual call isn't that big of a deal) * If you do it wrong, you'll be annoyed. * ??? I really think this is a win. I've done a proof of concept before by hacking _d_newclass to use the pool based on the TypeInfo passed in, gives a speedup in all the simple cases I tried. But since that hack still uses new, it wouldn't pass the @nogc test. However, a library function like emplace could be @nogc and do the same thing. Since @nogc is an addition to the function, you'll be modifying it anyway, so changing throw new to whatever the new lib function is called can be done at the same time. It is the catch code that have to worry about freeing the pool and even then, only if you want to avoid the GC. Normal code can just let the pool be collected when it is collected. I think I'll write a little module we can play with.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 14:31:36 UTC, Adam D. Ruppe wrote: How often do you store an exception reference anyway that escapes a catch block? I think all this talk is overkill to solve a non-problem in 99% of practice. Pretty much any time you do fibers + async I/O : to emulate blocking API one needs to catch and store exceptions from I/O routines so that later those can be re-thrown from resumed fiber context.
Re: RFC: reference counted Throwable
Am 20.09.2014 15:40, schrieb Ola Fosheim Grostad: On Saturday, 20 September 2014 at 12:27:23 UTC, Jacob Carlborg wrote: Assuming this would eventually be implemented for regular classes, it would be nice if it could be made compatible with Objective-C ARC [1]. [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html Isn't Objective-C ARC known to be terribly efficient? It requires compiler support, though. - Place retain/release at each place expected by Cocoa programming conventions, as if manually written - Do a second pass with data-flow analysis to remove retain/release pairs that don't escape current scope. If you have an Apple account search for: Transitioning to ARC Release Notes, ARC Memory Management Programming Guide for Core Foundation - Cocoa conventions and allocators WWDC 2012: Adopting Automatic Reference Counting - Overral description WWDC 2012: What's New in LLVM - Some slides about ARC Optimizer -- Paulo
Re: Lieutenant needed: build and release process
On Tuesday, 9 September 2014 at 15:58:45 UTC, Andrew Edwards wrote: On 9/8/14, 10:30 AM, Andrei Alexandrescu wrote: Andrew Edwards has done a great job with the recent release, but needs to step down because he's busy with other pursuits. We need a release lieutenant who would carry us through the release process. Please tender your application by replying to this. Thanks, Andrei Follow these steps to prepare your build environment: 1. Install VirtualBox: https://www.virtualbox.org/wiki/Downloads 2. Install Vagrant: https://www.vagrantup.com/downloads.html 3. Clone installer: git clone --recursive https://github.com/D-Programming-Language/installer.git Note 1: MartinNowak already prepared boxes for FreeBSD and Debian which are directly imported through the build script. However, you must prepare your own OSX and Windows 7 boxes. Instructions for preparing doing so are located here: OSX = https://gist.github.com/MartinNowak/8156507 Windows7 = https://gist.github.com/MartinNowak/8270666 Steps for building are outlined here: http://wiki.dlang.org/Simplified_Release_Process_Proposal Tracking is done here: http://wiki.dlang.org/Beta_Testing Trying this right now, got through Win7 box setup but where one is supposed to get InstallESD.dmg mentioned in installation instructions?
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? Oh another bad part of D is the attribute names with some being positive(pure) and some being negative(@nogc) and some of them not having an @ on them.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 14:33:40 UTC, Paulo Pinto wrote: Am 20.09.2014 15:40, schrieb Ola Fosheim Grostad: On Saturday, 20 September 2014 at 12:27:23 UTC, Jacob Carlborg wrote: Assuming this would eventually be implemented for regular classes, it would be nice if it could be made compatible with Objective-C ARC [1]. [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html Isn't Objective-C ARC known to be terribly efficient? I'm really sorry, but that was a very confusing typo on my part. I meant INefficient! :-) It requires compiler support, though. :-) Yes, but I was more talking about the representation in memory based on reading the source code that can be found in the repository. I read it the last time ARC was discussed… But, I am not 100% sure what code Apple actually ships.
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 14:22:32 UTC, Tofu Ninja wrote: Not really a problem with the language. Just problems. It is kind of interlinked in a world that keeps moving forward. I found myself agreeing (or at least empathising) with a lot of what Jonathan Blow said. Of course, since his presentation was laid-back the people on reddit kind of attacked him and who knows, maybe he lost inspiration. He did at least respond on twitter. And his language project probably depends on his next game Witness (which sounds cool) to succeed. Anyway, I think he got the right take on it, reach out to other devs in his own sector and ask them about their practice, then tailor a language with little syntactical overhead for that use scenario. Of course, it won't fly if he doesn't manage to attract people who are more into the semantics of computer languages, but I root for him anyway. I like his attitude. On a related note I also read somewhere that Carmack is looking at GC for the gameplay data. Basically only a heap scanning, but compacting GC, that can run per frame. Seems the game logic usually fits in 5MB, so it might work. Definitely can agree, I think it has to do with the sentiment that it is too much like C++ Yes, I think Jonathan got that part right. I guess also that any kind of unique traits that feels like inventions will be eagerly picked up and hold up as good ideas by enthusiasts. Even if they are just special cases of more general constructs or variations of existing concepts posing under a new name. Perhaps an important aspect of the sociology of computer languages. (Lispers tend to be terribly proud of their language of choice :) 8. Not enough performance oriented process. Not sure what you are saying, are you saying there is not a big enough focus on performance? I think there is too much focus on features both in language and library. I'd personally prefer smaller and more benchmark focused. It is better to be very good at something limited, IMO. I also think that the big win in the coming years come for the language that most successfully can make elegant low overhead access to SIMD instructions without having to resort to intrinsics. I have no idea what the syntax would be, but that seems to be the most promising area of language design in terms of performance IMO.
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 14:33:21 UTC, Dicebot wrote: Pretty much any time you do fibers + async I/O : to emulate blocking API one needs to catch and store exceptions from I/O routines so that later those can be re-thrown from resumed fiber context. Ah, indeed, and that could have a great many of them alive at once. Blargh, it'd need a real allocator to handle freeing them out of order. Nevertheless though, I still think the lifetime management there is simple enough for the user-programmer that freeing it manually isn't a big hassle and not worth making major changes to the language over.
Re: RFC: reference counted Throwable
On 2014-09-20 16:33, Paulo Pinto wrote: It requires compiler support, though. The first thing I asked in this thread was Are you suggesting we implement ARC? and the answer was Yes [1]. So it looks like Andrei already wants to implement ARC. My definition of ARC is that the compiler inserts the calls to retain/release (or whatever you call them). [1] http://forum.dlang.org/thread/lvhiam$1pno$1...@digitalmars.com#post-lvi0ve:2429il:241:40digitalmars.com -- /Jacob Carlborg
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 15:05:38 UTC, Adam D. Ruppe wrote: On Saturday, 20 September 2014 at 14:33:21 UTC, Dicebot wrote: Pretty much any time you do fibers + async I/O : to emulate blocking API one needs to catch and store exceptions from I/O routines so that later those can be re-thrown from resumed fiber context. Ah, indeed, and that could have a great many of them alive at once. Blargh, it'd need a real allocator to handle freeing them out of order. Nevertheless though, I still think the lifetime management there is simple enough for the user-programmer that freeing it manually isn't a big hassle and not worth making major changes to the language over. I don't follow. Lifetime is totally unknown there and completely up to actual application logic - from the point of view of the caller of something like `readFile()` it just a normal allocated exception that doesn't need any explicit management. Requiring any kind of manual handling would be a huge breaking change.
Re: Lieutenant needed: build and release process
On 2014-09-20 16:44, Dicebot wrote: Trying this right now, got through Win7 box setup but where one is supposed to get InstallESD.dmg mentioned in installation instructions? As the instructions say, from the Install Mac OS X Mountain Lion.app bundle. This bundle is downloaded from the Mac App Store. For Mavericks it's located in Install OS X Mavericks.app/Contents/SharedSupport/InstallESD.dmg. If you download it form the app store it's will be placed in /Applications. BTW you should only do this on a Mac. Technically it's possible to do on another platform. -- /Jacob Carlborg
Re: Library Typedefs are fundamentally broken
On 9/19/14, 11:32 PM, Vladimir Panteleev wrote: On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote: [snip] Um, why not use __FILE__ / __LINE__ (as default values for template parameters) as cookies? We could, but that would be surprising. I'd say things are good as they are. -- Andrei
Re: Lieutenant needed: build and release process
On Saturday, 20 September 2014 at 15:16:20 UTC, Jacob Carlborg wrote: BTW you should only do this on a Mac. Technically it's possible to do on another platform. Ah I see. Guess this is the point where I should say Thanks, no, I am not going to volunteer. Can do linux-only releases if anyone is interested ;)
Re: Escaping the Tyranny of the GC: std.rcstring, first blood
On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote: Andrei I'm testing your RCstring right now in my code to see how much memory it will save and speed it will gain. I want to use RCString in place of string as a key in my AAs. Any proposals for a suitable implementation of size_t toHash() @trusted pure nothrow for RCString? I'm guessing there are two cases here; one for the SSO-case an one for the other. The other should be similar to size_t toHash(string) @trusted pure nothrow right?
Re: Library Typedefs are fundamentally broken
On 9/19/14, 11:50 PM, Dicebot wrote:
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei Alexandrescu wrote:
This is wrong but probably not worth fighting. Consider:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them magically
distinct would be surprising and would require explanation. It's as if
someone writes:
struct Point { int x, y; }
alias A = Point;
and then later in the same module
alias B = Point;
But Typedef is not some generic symbol. It is library type specifically
introduced as `typedef` keyword replacement and advertised as such. I
expect it to work as close to `typedef` as possible being the most
priority. Otherwise it is simply useless.
No. -- Andrei
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 09:09:38 UTC, Marc Schütz wrote:
On Saturday, 20 September 2014 at 09:05:15 UTC, ponce wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei
Alexandrescu wrote:
Please chime in with thoughts.
Coudln't we throw value types instead? (like in C++)
But how would you chain them?
Owning pointer to next exception.
And they have to implement Throwable's interface.
One of their member would. Speculative design:
struct ValueException
{
Unique!ValueException next;
Unique!Throwable content;
}
Language would change to throw structs and catch them (without
matching).
At the end of a catch bloc, its destructor is called.
This breaks polymorphic catch so it need sugar unfortunately.
Re: Library Typedefs are fundamentally broken
On 9/19/14, 11:36 PM, Marco Leise wrote: Am Fri, 19 Sep 2014 08:02:30 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: On 9/18/14, 11:45 PM, Marco Leise wrote: We should probably revert to having real typedefs. Should not. Ok, but don't ask me to use alias ALfloat = std.typecons.Typedef!(float, yummyCookie23); when it could be typedef ALfloat = float; ! :) I think this is an entirely palatable idiom: alias ALfloat = std.typecons.Typedef!(float, ALfloat); Andrei
Re: Escaping the Tyranny of the GC: std.rcstring, first blood
On 9/20/14, 12:42 AM, Dicebot wrote: On Friday, 19 September 2014 at 15:09:41 UTC, Andrei Alexandrescu wrote: as amount of write operations gets out of control. Every single attempt to do something clever with shared CoW strings in C++ I have met was a total failure. What were the issues? Usually it went that way: 1) Get basic implementation, become shocked how slow it is because of redundant reference increments/decrements and thread safety 2) Add speed-up hacks to avoid reference count amending when considered unnecessary 3) Get hit by a snowball of synchronization / double-free issues and abandon the idea completely after months of debugging. I understand. RC strings will work just fine. Compared to interlocked approaches we're looking at a 5x improvement in RC speed for the most part because we can dispense with most interlocking. -- Andrei
Re: What are the worst parts of D?
Jonathan Blow has expressed himself about D before… http://www.kotaku.com.au/2012/05/most-popular-video-games-are-dumb-can-we-stop-apologising-for-them-now/ It could be incidental, of course.
Re: Escaping the Tyranny of the GC: std.rcstring, first blood
On Saturday, 20 September 2014 at 15:21:18 UTC, Nordlöw wrote:
for RCString? I'm guessing there are two cases here;
I'm guessing
size_t toHash() const @trusted pure nothrow
{
import core.internal.hash : hashOf;
if (isSmall)
{
return this.small.hashOf;
}
else
{
return this.large[].hashOf;
}
}
Will
this.large[].hashOf
do unneccessary GC-allocations? -vgc says nothing.
I'm compiling as
dmd -vcolumns -debug -g -gs -vgc -unittest -wi -main
rcstring.d -o rcstring.out
Re: Library Typedefs are fundamentally broken
On Saturday, 20 September 2014 at 15:26:37 UTC, Andrei Alexandrescu wrote: But Typedef is not some generic symbol. It is library type specifically introduced as `typedef` keyword replacement and advertised as such. I expect it to work as close to `typedef` as possible being the most priority. Otherwise it is simply useless. No. -- Andrei I don't really care what you think. There is a simple fact - there is not a single use case I am going to use existing implementation instead of rolling one of my own. Call me a pervert but when standard library type can't be used for something it was initially proposed for it does smell like a failure.
Re: RFC: reference counted Throwable
On 9/19/14, 11:15 PM, Walter Bright wrote: On 9/19/2014 10:46 PM, Andrei Alexandrescu wrote: 2. To deal with (1), existing ARC systems allow escapes from it. This has severe implications for memory safety. Rust's entire type system appears to be designed around trying to deal with this, and AFAIK they're the only ones who have tried. C++ shared_ptr and ObjectiveC's ARC are not memory safe. They are not. Not not not, and they don't even try. :-) That's fine. You can't have everything. You're willing to dispense with memory safety? No. 3. ARC objects require an embedded count. This means they cannot be mixed with non-ARC objects. This is fundamentally DIFFERENT from how GC behaves, and we cannot pretend or wish this away or add a compiler switch to make it go away. In nogc mode, everything is ARC so I'm not getting this. Not even ARC languages try to make everything ARC - because it is BLOATED and SLOW. Not C++, not ObjectiveC, not Rust. Agreed. D can have ref counted objects, but it will not work with a compiler switch to switch them back and forth. They'll have to coexist peacefully with GC objects. We need to figure out a design. All I'm saying is we must not bring prejudice to the table. And a very basic point is: there will be a way to COMPLETELY disable the GC. That is a must. It doesn't have to be disabled. Just don't call it. The GC is not a bridge troll that is going to pop up and extract a toll even if you aren't allocating with it. Well obviously there's a hierarchy of desirability: 1. Using the GC inadvertently causes a compile-time error. 2. Using the GC inadvertently causes a link-time error. 3. Using the GC inadvertently causes a run-time error. 4. Using the GC inadvertently goes undetected. I disagree that (4) is good for everyone. Andrei
Re: Library Typedefs are fundamentally broken
On 09/20/2014 06:52 AM, Andrei Alexandrescu wrote:
On 9/19/14, 8:14 PM, Timon Gehr wrote:
To substantiate: It does the wrong thing (same typedef for same base
type) by default and doing the right thing (emulating nominal typing)
may require quite some effort in general (e.g. concatenate the mangled
names of all enclosing template instantiations) while remaining
non-modular (those cookie strings are global identifiers).
This is wrong
Well, how?
but probably not worth fighting.
Then don't bring it up. :o)
Consider:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical.
I don't see the relevance, but the definition of Typedef is also
important to decide whether they are identical, not just language rules.
Making them magically distinct ...
(Straw man.)
Human-readable cookies are exactly the solution: distinct human-readable
moniker that distinguish the types.
alias A = Typedef!(float, dollar);
alias B = Typedef!(float, euro);
...
This doesn't compile. This, IMHO more _ugly_, code compiles:
import std.typecons;
alias A = Typedef!(float, float.init, dollar);
alias B = Typedef!(float, float.init, euro);
// (different issue:
void main(){
A dollars=2;
B euros=2*dollars;
}//)
They will be distinct to the human and compiler alone.
...
Library A:
alias A = Typedef!(int, -1, handle);
Library B:
alias B = Typedef!(int, -1, handle);
// ---
template Fun(S,T)/+if(...)+/{
alias Hun=Typedef!(S,S.init,hun);
// (BTW: what do I do if S or T has no default initializer?)
alias Gun=Typedef!(T,T.init,gun);
// ...
}
Now e.g. Fun!(int,double).Hun is compatible with Fun!(int,string).Hun.
This was my argument. IMO this state of affairs is ugly. Disagree that
this makes the cookie parameter an 'ugly wart', but don't call the
argument factually wrong without substantiation, please.
...
Your argument has been destroyed.
...
My argument hasn't been considered. To destroy its relevance without
consideration would need a very compelling case for the beauty of the
cookie parameter, which I haven't seen yet, and it is hard for me to
imagine it being made without addressing the above issues. And besides,
it is probably highly subjective. Apparently you find the cookie
parameter to be pretty because it seems to work for the dollar/euro
example (after fixing), while I have a different set of expectations.
(BTW: Note that I am not arguing for bringing back built-in typedef.)
Re: RFC: reference counted Throwable
On 9/20/14, 12:46 AM, Olivier Pisano wrote: If making the GC completely optional is a must, then error handling shouldn't rely on it at all, no? What about completely switching exception handling to RC ? Would it have an impact on memory safety since exeption handling mecanism is somehow magical code generated by the compiler ? The more I think of it the more sensible this is. Exceptions are unlikely to create cycles, not copied extensively, and are generally short lived. So an RC scheme backed by malloc/free seems to be most appropriate. There would be breakage, though: Throwable would not be convertible to Object. I wonder what the impact in the real world that would cause. Andrei
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 15:12:45 UTC, Dicebot wrote: Requiring any kind of manual handling would be a huge breaking change. I'm not talking about *requiring* it; I want it to be a garbage collected object that 1) allocating it never triggers a collection cycle (so it is a @nogc allocation) and 2) you're allowed to explicitly free it if you want to, but if you don't, the gc will get around to it eventually. We have #2 already: delete (though I'd like it to not be something which is allegedly deprecated). #1 is fairly easy too: just offer a new @nogc allocation function which creates garbage but does not garbage collect. This could be a new function or the new keyword could be modified to suppress collection when allocating Throwable or whatever. Maybe I'm missing something though.
Re: RFC: reference counted Throwable
On 9/20/14, 12:48 AM, Mike Parker wrote: I don't know yet what the ultimate impact of a -nogc switch would be on library maintenance, but I have a strong suspicion that simple wrapper modules and mixins wouldn't be enough to maintain compatibility. If there is even the slightest possibility that library maintainers will find themselves in that same situation of having to choose a or b because maintaining both is too troublesome to bother, then all the implications need to be hashed out beforehand. We need to explore that. A possibility is to support coexistence and then have the option to use a tool statically pinpoint the uses of GC. -- Andrei
Re: RFC: reference counted Throwable
On 9/20/14, 1:20 AM, Marc Schütz schue...@gmx.net wrote: On Friday, 19 September 2014 at 22:14:08 UTC, Andrei Alexandrescu wrote: On 9/19/14, 12:42 PM, Jacob Carlborg wrote: On 2014-09-19 17:32, Andrei Alexandrescu wrote: Whenever a reference to a Throwable is copied about, passed to functions, the compiler inserts appropriately calls to e.g. incRef and decRef. (Compiler may assume they cancel each other for optimization purposes.) Implementation of these is up to the runtime library. Are you suggesting we implement ARC? Yes. -- Andrei I don't think ARC is needed. library RC + borrowing + uniqueness/moving = WIN s/WIN/Rust/
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 15:28:10 UTC, ponce wrote:
On Saturday, 20 September 2014 at 09:09:38 UTC, Marc Schütz
wrote:
On Saturday, 20 September 2014 at 09:05:15 UTC, ponce wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei
Alexandrescu wrote:
Please chime in with thoughts.
Coudln't we throw value types instead? (like in C++)
But how would you chain them?
Owning pointer to next exception.
And they have to implement Throwable's interface.
One of their member would. Speculative design:
struct ValueException
{
Unique!ValueException next;
Unique!Throwable content;
}
Language would change to throw structs and catch them (without
matching).
At the end of a catch bloc, its destructor is called.
This breaks polymorphic catch so it need sugar unfortunately.
Ah, now I see, you just want a wrapper that contains a Throwable.
I thought you wanted to throw _any_ value types, like in C++.
Re: RFC: reference counted Throwable
On 9/20/14, 12:48 AM, Mike Parker wrote: I don't know yet what the ultimate impact of a -nogc switch would be on library maintenance, but I have a strong suspicion that simple wrapper modules and mixins wouldn't be enough to maintain compatibility. If there is even the slightest possibility that library maintainers will find themselves in that same situation of having to choose a or b because maintaining both is too troublesome to bother, then all the implications need to be hashed out beforehand. Agreed. -- Andrei
Re: Library Typedefs are fundamentally broken
On Sat, 20 Sep 2014 08:25:17 -0700 Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: I think this is an entirely palatable idiom: alias ALfloat = std.typecons.Typedef!(float, ALfloat); this is ugly. even if we remove std.typecons. it's still ugly. making such core feature ugly is the right way to marginalize it. what? all this uglyness only for simple typedef? screw it, i'll go with simple `alias ALfloat = float;`! oh, wait... this gives me nothing and i already messed some declarations... ah, screw it, will use `float` then! the whole thing with aliasing Typedef is broken. yes, it's smart to use library for this (see, our language is THAT powerful!), but it's uuugly. the same thing as with octal literals: we have 0b, we have 0x, yet it's very smart to banish octals to phobos and use octal!660 instead of logical 0o660. phew. but i know: octal literals are handy, so they will never make their way to mainline. typedef construct is handy, so... signature.asc Description: PGP signature
Re: RFC: reference counted Throwable
On 9/20/14, 1:46 AM, Uranuz wrote: Also it's interesting waht is the correspondence between memory management, memory model and allocators? I know that std.allocator is in development. I guess that it should be considered in complex. 1. Memory management: when are calls to allocation and deallocation primitives made? 2. Allocators: what are the allocation and deallocation primitives, and how are they implemented? 3. Memory model: how is memory effected by programs? (of interest for compiler implementers and thread safety) There is occasional confusion among the three. I myself was in the woods for a while thinking that allocators should do memory management. Andrei
Re: RFC: reference counted Throwable
On Saturday, 20 September 2014 at 16:15:45 UTC, Andrei Alexandrescu wrote: We need to explore that. A possibility is to support coexistence and then have the option to use a tool statically pinpoint the uses of GC. -- Andrei What, *exactly*, does uses of GC mean? In other words, what specifically makes GC.malloc evil that must be avoided at any cost while C malloc (+ GC.addRange most likely) is an acceptable replacement? A few things that come to mind are: 1) Obviously, GC.malloc can trigger a collection. But this can be easily disabled. 2) The GC lock? I don't know how malloc handles this though. 3) Is GC.free substantially different than C's free? 4) Programmers don't typically explicitly free GC memory... but we could. 5) Bookkeeping overhead? I know malloc has some too though, is this really a dealbreaker? 6) Public relations. ...that's all I can think of. What am I missing? Which one of these is actually causing the problem that we're supposed to be fixing here?
Re: Library Typedefs are fundamentally broken
Timon Gehr: alias A = Typedef!(float, dollar); alias B = Typedef!(float, euro); ... This doesn't compile. This, IMHO more _ugly_, code compiles: import std.typecons; alias A = Typedef!(float, float.init, dollar); alias B = Typedef!(float, float.init, euro); See: https://d.puremagic.com/issues/show_bug.cgi?id=11828 Some other open issues/ERs: https://issues.dlang.org/buglist.cgi?f1=short_desco1=casesubstringquery_format=advancedresolution=---v1=Typedef Bye, bearophile
Re: What are the worst parts of D?
I watched Jonathan's talk last night, it was really good. I really like the idea that he wants to make a community designed, platform independent, game specific language. It's too bad he doesn't really want to give D more of chance but for what he's looking for, it'd really need to be designed from the ground up, as he was saying. Also being that he's slowly rejecting C++, then I can see D not making sense since D's slogan is pretty much A better C++!; which is accurate but may not be the best marketing scheme. Also D is a general purpose language, so I guess it really wouldn't fit his bill. Though he mentioned Go and Rust a lot, personally I wouldn't really back those languages either, at least not for games. Rust maybe if it ever hits version 1.0 I'll take another look at it. I'm definitely all for the setup he was describing though: all you need is an IDE/text editor and the compiler. I feel like D definitely has the potential to be able to meet that setup someday; I'm just not sure if that setup would be a screw over or not to people of other fields. The platform independent thing would be a HUGE plus! Something D isn't too, too far from, but definitely not there at least of yet. Overall I'd say D has some significant issues: - The documentation is awful. If there's a problem you don't know the answer to, the only three real options are pray that the docs are correct/up to date, go ask someone who possibly does know, or magic. - Bugs. D is like Costco, expect for bugs, and all the bugs are free. - More of a suggestion than a problem: Someone needs to do an O'reilly book series for D; but only after the first two problems I listed are at least suppressed a bit. - Very few native D libraries, and also for C/other libraries almost all D bindings are maintained by usually only one person. Usually very skilled people, but the work load for library development and maintenance would probably thrive best with more people doing more. (The community is probably just too small at the moment) I'm sure there was more, but it's just not coming to me at the moment. I'm definitely interested in Jon's theoretical language but I don't think it's gonna take away from D for me. Overall though, I absolutely love D! There's just ALOT of work to be done. :)
Re: Library Typedefs are fundamentally broken
ketmar: but i know: octal literals are handy, so they will never make their way to mainline. typedef construct is handy, so... A well working Typedef/typedef (named newtype in Haskell, where it's a built-in) is more commonly useful than octal literals. Bye, bearophile
Re: RFC: reference counted Throwable
On 9/20/14, 2:05 AM, ponce wrote: On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote: Please chime in with thoughts. Coudln't we throw value types instead? (like in C++) My knee-jerk reaction is we shouldn't. If considered, that would need to be well argued. We've derived good benefits from using polymorphic exceptions. -- Andrei
Re: RFC: reference counted Throwable
On 9/20/14, 5:17 AM, bearophile wrote: Andrei Alexandrescu: Are you suggesting we implement ARC? Yes. -- Andrei I think it's better first to design implement a first version of memory ownership management, and then later add a reference counting scheme. That's not quite informative. -- Andrei
Re: RFC: reference counted Throwable
On 9/20/14, 7:31 AM, Adam D. Ruppe wrote: How often do you store an exception reference anyway that escapes a catch block? I think all this talk is overkill to solve a non-problem in 99% of practice. Correct me if I'm wrong, but aren't *all* exceptions in a particular thread generally unreferenced at the end of a catch() block, unless the programmer explicitly escaped that reference? If so, we don't need refcounting! Here's my solution: [snip] Thanks. I personally favor RC based on malloc to this. It'll be safer and simpler to use. -- Andrei
