Re: An exegesis of Walter's reference counted slice
On Tue, Feb 24, 2015 at 09:13:42PM +, weaselcat via Digitalmars-d wrote: On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote: [...] Yep, that's exactly why D has ruined my life, I just can't go back to that C++ garbage anymore. Working with C++ after using D does leave one feeling... disillusioned. That's putting it rather mildly. :-P Some time ago I revisited one of my old C++ programs, hoping to optimize performance a bit by using a hash table to cache the results of certain expensive computations. I was somewhat elated that *finally* after all these years hash tables finally made it into the C++ standard... For all their warts, D's AA's have left me confident that this would be a small change... Boy was I wrong. Everything from the horrible syntax to built-in structs *not* being supported as hash keys by default, to needing to write my own hash function, *and* having to pass it around all over the place, etc.., ... after several hours of fighting with the language for something that would be just a couple dozen lines of code in D at the most, I threw up my hands and ditched the whole idea. C++11 feels a lot like too little, too late to me. I'd rather rewrite the whole thing in D and spare myself the pain. For all of its current flaws, D is still way ahead of C++ in terms of usability. I've stopped caring about C++ and have not bothered to find out what C++14 (or is it C++15 now?) has in store -- if past experience is anything to go by, it will just be another too little, too late. T -- How are you doing? Doing what?
Re: An exegesis of Walter's reference counted slice
On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote:
On Tue, Feb 24, 2015 at 08:21:53PM +, ketmar via
Digitalmars-d wrote:
On Tue, 24 Feb 2015 20:11:17 +, weaselcat wrote:
On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei
Alexandrescu wrote:
On 2/24/15 12:03 PM, weaselcat wrote:
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei
Alexandrescu
wrote:
...
Off-topic, sorry Are we still going to get a Trusted
block, or
just going to use trusted lambdas?(They're kind of ugly
TBH)
We're going to lambdas. Ugliness is a feature.
Stroustrup would be proud ;)
yet he made the whole language ugly, instead of making only
ugly
things ugly. ;-)
Actually, it's worse than that. He made things that shouldn't
be ugly,
ugly, and things that *don't* look ugly are outright wrong.
For example, naked pointers have built-in, convenient syntax.
They are
also extremely dangerous, and almost all C++ code containing raw
pointers have bugs one way or another.
For-loops have very nice syntax... except that unless you're
writing the
most inane, trivial loops, your code probably has bugs --
off-by-1
errors, wrong loop conditions, etc..
Calling malloc/free is also easy... and your program probably
has memory
leak bugs too. Not to mention type-safety bugs if you're not
careful
about what you cast that void* into. But hey, writing:
// Woohoo, bare pointer! Let's dance!
void *p = malloc(1234);
sure looks prettier than:
// Repeat after me: Don't repeat yourself... don't repeat
// yourself... don't repeat yourself...
MyType *p = (MyType *)malloc(sizeof(MyType));
Well, new/delete is prettier (as far as C++ goes anyway)... But
wait,
you still have memory leaks. Augh...
And what about cleaning up resources after you're done with
them?
void func() {
Resource *res = acquireResource();
doStuff(res);
freeResource(res);
}
Easy, right? Yeah, except that doStuff throws exceptions, so
you have
resource leakage. Solution? Write a long convoluted wrapper
class with a
dtor that cleans up. And a copy ctor that makes sure
initializing one
resource from another works correctly. And operator=() to make
sure
assignments work correctly. Oh but wait, your ctor is not
exception-safe, so better rewrite *that* to use RAII too. Which
means
more copy ctors, more operator=()... oh wait, your copy ctor is
not
const-correct so it doesn't get called when you have a const
object.
Yeah, and your operator=() too. And ...
After it's all said and done, what used to be a 3-line function
has
exploded into a monstrosity who knows how many lines long, with
arcane
incantations of auto_ptr, shared_ptr, and all that fancy
stuff that
no newbie ever has the hope of parsing, let alone understanding.
http://bartoszmilewski.com/2013/09/19/edward-chands/
Favorite quote:
C++ has become an extremely complex language. There are
countless ways of doing the same thing — almost all of them
either plain wrong, dangerous, unmaintainable, or all of the
above. The problem is that most code compiles and even runs.
The
mistakes and shortcomings are discovered much later, often
after
the product has been released.
Yep, that's exactly why D has ruined my life, I just can't go
back to
that C++ garbage anymore.
T
Almost all those warts are caused by the C compatibility and
affect also D to certain extent.
Any language that tries to achieve copy-paste compatibility with
C will suffer from it.
--
Paulo
Re: Memory safety depends entirely on GC ?
On Tuesday, 24 February 2015 at 20:53:24 UTC, Walter Bright wrote: On 2/24/2015 10:00 AM, Andrei Alexandrescu wrote: I also owe you apologies for not acknowledging that work. I find the proposal too complicated for what it provides and that's the short and long of it. It's easy to make a large and complex language addition to support any sensible abstraction. That doesn't make it automatically good. My criticisms of it centered around: 1. confusion about whether it was a storage class or a type qualifier. 2. I agree with Andrei that any annotation system can be made to work - but this one (as are most annotation systems) also struck me as wordy, tedious, and aesthetically unappealing. I just can't see myself throwing it up on a slide and trying to sell it to the audience as cool. 3. In line with (2), I want a system that relies much more on inference. We've made good progress with the existing annotations being inferred. 4. I didn't see how one could, for example, have an array of pointers: int*[] pointers; and then fill that array with pointers of varying ownership annotations. 5. The (4) homogeneity requirement would mean that templated types would get new instantiations every time they are used with a different ownership. This could lead to massive code bloat. 6. The 'return ref' scheme, which you have expressed distaste for, was one that required the fewest instances of the user having to add an annotation. It turned out that upgrading Phobos to this required only a handful of annotations. 7. 'return ref' makes memory safe ref counted types possible, finally, in D, without needing to upend the language or legacy code. And as the example I posted showed, they are straightforward to write. Only time and experience will tell if this will be successful, but it looks promising and I hope you'll be willing to give it a chance. Thanks for summarizing your reasons. I knew that you were unhappy with 1 - 3); I wasn't aware of 4) and 5). I can't get into detail now, as it's already late at night here, but I'll try thinking about it tomorrow. FWIW, Zach just wrote in another thread that he will have his own proposal ready soon, based on DIP25, with `scope` being a storage class. Let's see how this goes.
Re: An exegesis of Walter's reference counted slice
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote: ... Off-topic, sorry Are we still going to get a Trusted block, or just going to use trusted lambdas?(They're kind of ugly TBH) But I was bummed that e.g. I found no way to call emplace() @safe-ly. I assumed emplace would infer @safe?
Re: An exegesis of Walter's reference counted slice
On Tue, 24 Feb 2015 12:03:36 -0800, Andrei Alexandrescu wrote: On 2/24/15 11:55 AM, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... Could you please add a detailed issue about this? Thanks. -- Andrei here's the fixed code: http://dpaste.dzfl.pl/5f7dfe237d1e btw, you have a bug in your implementation: (cast(E*) malloc(a.length * uint.sizeof))[0 .. a.length])(); should be: (cast(E*) malloc(a.length * E.sizeof))[0 .. a.length])(); sorry, i'm bad in explanations, let the code speak for itself. signature.asc Description: PGP signature
Re: What is the state of D with Android/iOS
On Tuesday, 24 February 2015 at 19:34:15 UTC, Joakim wrote: On Tuesday, 24 February 2015 at 17:55:59 UTC, Rishub Nagpal wrote: On Tuesday, 24 February 2015 at 17:15:28 UTC, Joakim wrote: If you simply want to call a D library within an Android/iOS app, that's possible, though there are still some rough edges. Specifically, there is still some work to be done with certain floating-point operations on iOS (http://forum.dlang.org/post/m2mw4tab0w@comcast.net) and while Android/x86 will work fine (http://wiki.dlang.org/Build_DMD_for_Android), Android/ARM doesn't currently support TLS. That lack of TLS support means you'd have to run a slightly patched druntime and I'm fairly certain phobos wouldn't work. Could any of these patches be used as a basis to remedy it? https://groups.google.com/forum/#!topic/0xlab-devel/aSOcm3c9PFk https://bugs.kde.org/show_bug.cgi?id=302709 Could you in theory recompile Android to support TLS and then try to compile an executable for Android/ARM ? Sorry, the way I wrote that may have been confusing: I meant that ldc doesn't currently support any form of TLS for Android/ARM. Native TLS is not supported on Android/bionic for any architecture, whether x86 or ARM. I worked around this on x86 by removing the SHF_TLS and STT_TLS flags from the ELF objects and using pthread_setspecific/pthread_getspecific instead (more details on the dmd PR: https://github.com/D-Programming-Language/dmd/pull/3643), which is basically how Walter implemented TLS on OS X/Mach-O years ago, as OS X didn't support native TLS till 10.7 and their TLV APIs are still undocumented. I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme. It appears that Dan did something similar with his patched llvm for iOS. As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for. Better to patch llvm to support the same TLS scheme used for Android/x86. Interesting. A few others and I were talking about getting Android/ARM to function with LDC today. I'll be sure to keep up to date with your work!
Re: Is D's TimSort correct?
On 02/24/2015 11:20 AM, ketmar wrote: On Tue, 24 Feb 2015 10:47:19 -0800, Ali Çehreli wrote: Some implementation out there are buggy: http://www.reddit.com/r/programming/comments/2wze7z/ proving_that_androids_javas_and_pythons_sorting/ Ali p.s. and yes, `TimSortImpl` is broken. Thanks. Posted: https://issues.dlang.org/show_bug.cgi?id=14223 Ali
Re: Memory safety depends entirely on GC ?
On Tuesday, 24 February 2015 at 21:03:38 UTC, Walter Bright wrote: On 2/24/2015 11:12 AM, bearophile wrote: I don't like the look of the annotations of DIP25. I'd like DIP25 removed from D language and replaced by a more principled solution. Sometimes a heavier solution can be simpler to understand (and it can be actually safe). So far, DIP25 has been called by various posters unprincipled, hackish, and stupid, without supporting rationale. I do think this comes from looking at the larger picture. In isolation, DIP25 is not that bad. It solve a class of problems properly, which is already something. Where I think most people find it hacky, unprincipled, or whatever is when looking at the larger picture. It seems obvious at this point that DIP25 is not the alpha and omega of the problem (this very thread is an example of this). For instance, DIP25 do not do anything for classes to be safely reference counted. People are - legitimately - afraid that a set of DIP25 like solution will be adopted for each of these problems. When looking at the total cost of the set of solution, compared to a more complex, more principled solution, it seems that this is not the way forward. In that sense, DIP25 seems like a hack to make reference counting work rather than the addition of a basic language feature that add a new dimension of expressiveness to the language. A bit like Rvalue references in C++ have been added to support std::move and std::forward instead of being a generally useful basic block to build upon. Note the thread A Refcounted Array Type thread, which uses DIP25 to implement a memory safe ref counted container. It is simple and requires exactly one annotation. It seems pretty straightforward to me, and so far nobody has shown any holes in it, or has even commented on the principle of it. (complaints about bounds checking, delete, etc., are off-topic) I still have to review it in details, but I'm sure this is good or at least fixable in a way that make it good. Yet, as mentioned, the problem do not come with DIP25 in isolation. DIP25 does its job well. It just does a too limited job, and it seems that DIP25 and DIP25 like solution for other jobs, will ultimately lead to a more complex situation than where the 'too complex' solutions would lead us.
Re: An exegesis of Walter's reference counted slice
On 2/24/15 11:55 AM, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... Could you please add a detailed issue about this? Thanks. -- Andrei
Float to string with more digits?
Is there a more accurate way to do a float and or double to string than... to!string(float); As that seems to limit itself to 6 digits.
Re: An exegesis of Walter's reference counted slice
On Tue, 24 Feb 2015 11:40:34 -0800, Andrei Alexandrescu wrote:
3. opIndex (here's the magic) is the most interesting part of the
proposal. It disallows unsafe use such as:
@safe ref int fun()
{
auto a = RCArray!int([1, 2, 3]);
return a[1];
}
this is the important part for those who are too lazy to read DIP25 (like
me). thank you.
signature.asc
Description: PGP signature
Re: An exegesis of Walter's reference counted slice
On Tue, 24 Feb 2015 14:55:14 -0500, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. heh. yes, i hit this in my `iv.steam.PartialStream` implementation. those occasional crashes was nasty. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... actually, it's safe to add GC roots and regions that contains no GC references. it's a little slowdown, as GC must scan that area, but nothing bad happens. yet you are right, there should be some method to distinguish gc- agnostic types. and compiler should be able to infer that... signature.asc Description: PGP signature
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/24/2015 5:28 AM, Wyatt wrote: On Tuesday, 24 February 2015 at 09:53:19 UTC, Walter Bright wrote: D has to be competitive in the most demanding environments. But isn't that exactly the point? Garbage collected D is NOT competitive in demanding environments. Write barriers are not the answer.
Re: Is D's TimSort correct?
On Tue, 24 Feb 2015 11:48:37 -0800, Ali Ãehreli wrote: I was going to suggest dmd's code coverage tool but I've just witnessed the problem first-hand: Uninstantiated template code is not visible to the coverage analyser! :-o yes. i don't think that this is a bug, though: coverage analyser analyses only actually existing code, and non-instantiated template is inexisting. ;-) and forcing compiler to instantiate all possible template variants is both impractical and not even possible, i think. yet symbolic checker like KeY can be very handy here, i think. it can prove that some instantiations are effectively the same, for example. signature.asc Description: PGP signature
Re: An exegesis of Walter's reference counted slice
On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote: http://bartoszmilewski.com/2013/09/19/edward-chands/ I'm not generally one to read comments on blogs, but the replies to that blog are jawdropping. I have to assume most of these people are either new to C++ or are being forced to write these replies at gunpoint. Yep, that's exactly why D has ruined my life, I just can't go back to that C++ garbage anymore. Working with C++ after using D does leave one feeling... disillusioned.
[Issue 14223] New: TimSort algorithm is incorrect
https://issues.dlang.org/show_bug.cgi?id=14223 Issue ID: 14223 Summary: TimSort algorithm is incorrect Product: D Version: future Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: acehr...@yahoo.com The following article describes and proposes a fix for a common bug in the TimSort algorithm: http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/ ketmar agrees that Phobos's version of TimSort has the same bug: http://forum.dlang.org/thread/mcigvq$11p0$1...@digitalmars.com#post-mciit8:242dvo:24102:40digitalmars.com Ali --
Re: Memory safety depends entirely on GC ?
On 2/24/2015 10:00 AM, Andrei Alexandrescu wrote: I also owe you apologies for not acknowledging that work. I find the proposal too complicated for what it provides and that's the short and long of it. It's easy to make a large and complex language addition to support any sensible abstraction. That doesn't make it automatically good. My criticisms of it centered around: 1. confusion about whether it was a storage class or a type qualifier. 2. I agree with Andrei that any annotation system can be made to work - but this one (as are most annotation systems) also struck me as wordy, tedious, and aesthetically unappealing. I just can't see myself throwing it up on a slide and trying to sell it to the audience as cool. 3. In line with (2), I want a system that relies much more on inference. We've made good progress with the existing annotations being inferred. 4. I didn't see how one could, for example, have an array of pointers: int*[] pointers; and then fill that array with pointers of varying ownership annotations. 5. The (4) homogeneity requirement would mean that templated types would get new instantiations every time they are used with a different ownership. This could lead to massive code bloat. 6. The 'return ref' scheme, which you have expressed distaste for, was one that required the fewest instances of the user having to add an annotation. It turned out that upgrading Phobos to this required only a handful of annotations. 7. 'return ref' makes memory safe ref counted types possible, finally, in D, without needing to upend the language or legacy code. And as the example I posted showed, they are straightforward to write. Only time and experience will tell if this will be successful, but it looks promising and I hope you'll be willing to give it a chance.
Re: Float to string with more digits?
On Tuesday, 24 February 2015 at 20:08:55 UTC, Justin Whear wrote: On Tue, 24 Feb 2015 20:04:04 +, Almighty Bob wrote: Is there a more accurate way to do a float and or double to string than... to!string(float); As that seems to limit itself to 6 digits. Use std.string.format or std.format.formattedWrite. std.format contains a description of the various format specifiers. You'll probably want something like %.12f, which formats a floating point number with 12 digits of precision. that did it, thanks, :)
Re: An exegesis of Walter's reference counted slice
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote: I modified Walter's sample code to this: http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array and the reference count, and also uses @trusted minimally. I inserted assert()s here and there to clarify the workings. Nothing big except for the careful use of @trusted. Doesn't look like it follows the philosophy behind @trusted. Conceptually, you should be able to insert exceptions everywhere outside the called @trusted function and retain memory safety. The way the code is written you have to move outside the @trusted function to prove memory safety.
Re: Memory safety depends entirely on GC ?
On 2/24/2015 11:12 AM, bearophile wrote: I don't like the look of the annotations of DIP25. I'd like DIP25 removed from D language and replaced by a more principled solution. Sometimes a heavier solution can be simpler to understand (and it can be actually safe). So far, DIP25 has been called by various posters unprincipled, hackish, and stupid, without supporting rationale. Note the thread A Refcounted Array Type thread, which uses DIP25 to implement a memory safe ref counted container. It is simple and requires exactly one annotation. It seems pretty straightforward to me, and so far nobody has shown any holes in it, or has even commented on the principle of it. (complaints about bounds checking, delete, etc., are off-topic)
Re: Memory safety depends entirely on GC ?
On Tuesday, 24 February 2015 at 19:20:37 UTC, Andrei Alexandrescu wrote: Compared to what ? There is no comparison involved. The proposal is too complicated for what it does. -- Andrei There is always a comparison involved. Comparison options includes: - Not solving some of the issues we have and call it a day. - Add simpler solution dedicated to each of these problems. The problems we are talking about are: - safe RC - fast GC by using type qualifier guarantee. - less reliance on GC by producing less garbage. - enforcing type qualifier constraint. - enabling more code to be @nogc (especially exception) - being able to delegate the memory management policy to the user. - immutable and shared building. - manipulating object of limited lifetime (DIP25 solve this partially). - `unique` message passing . - safe parallelism on graph of object instead of only value types. - lock on graph of objects (shared containers). Now it is clear that we can come up with simpler solution for some of these problem than whatever all encompassing solution would be. It is also clear that is is not possible to get a set of simpler solution that is, as a whole, simpler than an all encompassing solution. That means that some of the above mentioned point must be acknowledged as not going to be fixed. It is also to be noted that these above mentioned problems are not orthogonal. For instance, getting various GC optimizations in that take advantage of type qualifiers guarantee require that these guarantee are enforced. To get these constraints enforced, you need to be able to build immutable and/or shared in a way that don't break these constraints, and so on.
Re: What is the state of D with Android/iOS
On Tuesday, 24 February 2015 at 17:55:59 UTC, Rishub Nagpal wrote: On Tuesday, 24 February 2015 at 17:15:28 UTC, Joakim wrote: If you simply want to call a D library within an Android/iOS app, that's possible, though there are still some rough edges. Specifically, there is still some work to be done with certain floating-point operations on iOS (http://forum.dlang.org/post/m2mw4tab0w@comcast.net) and while Android/x86 will work fine (http://wiki.dlang.org/Build_DMD_for_Android), Android/ARM doesn't currently support TLS. That lack of TLS support means you'd have to run a slightly patched druntime and I'm fairly certain phobos wouldn't work. Could any of these patches be used as a basis to remedy it? https://groups.google.com/forum/#!topic/0xlab-devel/aSOcm3c9PFk https://bugs.kde.org/show_bug.cgi?id=302709 Could you in theory recompile Android to support TLS and then try to compile an executable for Android/ARM ? Sorry, the way I wrote that may have been confusing: I meant that ldc doesn't currently support any form of TLS for Android/ARM. Native TLS is not supported on Android/bionic for any architecture, whether x86 or ARM. I worked around this on x86 by removing the SHF_TLS and STT_TLS flags from the ELF objects and using pthread_setspecific/pthread_getspecific instead (more details on the dmd PR: https://github.com/D-Programming-Language/dmd/pull/3643), which is basically how Walter implemented TLS on OS X/Mach-O years ago, as OS X didn't support native TLS till 10.7 and their TLV APIs are still undocumented. I need to patch llvm in a similar way to that dmd PR, so that Android/ARM can use the same scheme. It appears that Dan did something similar with his patched llvm for iOS. As for your linked Android patches, that might be possible but would be pointless unless you are only deploying to a device you patched the OS for. Better to patch llvm to support the same TLS scheme used for Android/x86.
Re: Is D's TimSort correct?
On 02/24/2015 11:15 AM, ketmar wrote:
and it's interesting what complications templates can bring. testing
templates is relatively hard now, 'cause programmer must ensure that
every path is instantiated (i'm constantly hitting by the bugs in my
templates due to missing some codepathes).
I was going to suggest dmd's code coverage tool but I've just witnessed
the problem first-hand: Uninstantiated template code is not visible to
the coverage analyser! :-o
Here is the program, where the code inside 'static if' is not covered
(because argument 'a' is char):
T foo(T)(T v)
{
static if (T.sizeof == 4) {
++v;
}
return v;
}
void main()
{
int a = foo('a');
}
$ dmd deneme.d -cov
$ ./deneme
$ tail --lines=14 deneme.lst
|T foo(T)(T v)
|{
|static if (T.sizeof == 4) {
|++v;
|}
|
1|return v;
|}
|
|void main()
|{
1|int a = foo('a');
|}
deneme.d is 100% covered
Yay! 100% covered. WAT? :p
Ali
Re: An exegesis of Walter's reference counted slice
On 2/24/15 2:40 PM, Andrei Alexandrescu wrote: I modified Walter's sample code to this: http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array and the reference count, and also uses @trusted minimally. I inserted assert()s here and there to clarify the workings. Nothing big except for the careful use of @trusted. I'll use this as a basis of some exegesis. 1. The code is a bit more complicated than it should. Overall this is not a biggie; regular D users are not supposed to write reference counted slices casually. But I was bummed that e.g. I found no way to call emplace() @safe-ly. I have no problem with underlying complexity of primitive types. Using Objective-C objects is just fine without understanding the implementation. Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. For example, an array of class references could potentially result in those references being collected before the array is gone. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... 2. Michel's point (https://issues.dlang.org/show_bug.cgi?id=14221) reveals the largest issue with RC/GC integration. We need to find a fix for it if we want to have the GC lift cycles. I think a system of making sure a piece of data is always destroyed in the same thread it was created (unless of course, the thread is gone, in which case it doesn't matter), should be fine. -Steve
Re: An exegesis of Walter's reference counted slice
On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote: On 2/24/15 12:03 PM, weaselcat wrote: On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote: ... Off-topic, sorry Are we still going to get a Trusted block, or just going to use trusted lambdas?(They're kind of ugly TBH) We're going to lambdas. Ugliness is a feature. Stroustrup would be proud ;)
Re: Float to string with more digits?
On Tue, Feb 24, 2015 at 08:04:04PM +, Almighty Bob via Digitalmars-d-learn
wrote:
Is there a more accurate way to do a float and or double to string
than...
to!string(float);
As that seems to limit itself to 6 digits.
What about std.format.format(%.12f, myFloat)?
Or, if you like:
string floatToString(F)(F f)
if (isFloatingPoint!F)
{
// Extract as many digits as are available for this
// type.
return std.format.format(%.*f, F.dig, f);
}
T
--
If you want to solve a problem, you need to address its root cause, not just
its symptoms. Otherwise it's like treating cancer with Tylenol...
Re: An exegesis of Walter's reference counted slice
On Tue, 24 Feb 2015 20:11:17 +, weaselcat wrote: On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote: On 2/24/15 12:03 PM, weaselcat wrote: On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote: ... Off-topic, sorry Are we still going to get a Trusted block, or just going to use trusted lambdas?(They're kind of ugly TBH) We're going to lambdas. Ugliness is a feature. Stroustrup would be proud ;) yet he made the whole language ugly, instead of making only ugly things ugly. ;-) signature.asc Description: PGP signature
Re: A Refcounted Array Type
On 2/24/2015 6:56 AM, Steven Schveighoffer wrote: Actually, RCArray can never be allocated on GC, or you may corrupt memory. count may be non-null, and point at invalid memory when the dtor is called. Just set count to null after the delete. Only safe way to do this is to C malloc/free the count. And yes, at that point, you need atomics. No, RCArray is not intended for shared access between threads. Shared containers and local containers are different enough that they merit being different types with different implementations altogether. Trying to just slap 'shared' on a container isn't going to work.
The Big Picture
Several of us (deadalnix, Zach the Mystic, myself, probably others) have been putting forward some ideas related to memory management that involve ownership. A recent discussion made me realize that, while there were more or less concrete proposals for specific parts, there was no explanation of how they're all supposed to work together. I believe this may have led to significant misunderstandings. In the following, I want to summarize my understanding of The Big Picture (which is probably not far from deadalnix's and Zach's ideas). Please note that this is not a proposal, even the exact semantics of the described concepts are not really important for this post. Problem Statement = There are many different strategies for managing resources like memory, file handles, OpenGL objects, etc. The most important ones are: a) manual management (e.g. new/delete, malloc()/free(), open()/close()) b) unique/owned wrappers: there is only one reference to the resource; when that reference goes out of scope, the resource can be released c) reference counting: there can be more than one reference; when the last one is dropped, the resource is released d) (tracing) garbage collection: this is mostly used for memory resources D already provides several mechanisms to implement these strategies, but relies a lot on garbage collection. To improve that situation (which is part of the Vision for the near future [1]), we'd like to provide ways to use other strategies in a SAFE and EFFICIENT manner. Requirements It's clear that we have to work with the existing language (although still allowing some changes to it, ideally non-breaking ones), and that we as a project have only limited resources. Therefore, any demands we want to make against a possible solution must be weighed against the costs of satisfying them. However, it is a good idea to start with requirements from an ideal solution, and see what can realistically be implemented. Here's my wishlist: 1) Compatibility There's a huge amount of existing code. An ideal solution should not only not break existing code, but also allow existing code to take advantage of the new features with as little change as possible. 2) Safety/Correctness The compiler must statically disallow uses of a resource that are unsafe or incorrect for the chosen management strategy. Ideally, this applies not only to @safe-ty, but also to other kinds of correctness, like preventing access to a closed file handle. 3) Efficiency Lack of performance is probably the most frequent reason for avoiding the GC. Therefore, our dream solution should not introduce unnecessary performance penalties itself. Just like template functions are expected to perform as well as hand-written specialized code, an RC wrapper, for example, should perform as well as hand-written (but tedious and potentially unsafe) manual reference counting. 4) Implementable in a Library The language should provide the tools necessary to implement as much as possible in the standard library or in application code. 5) Composability Most code, especially in libraries, shouldn't have to care about the underlying resource management strategy of the data it processes, nor should it impose a particular strategy on the user. Resource management strategy should be the responsibility of the client code. This principle should be followed to the greatest possible extent. Especially in light of point 4), this will make it possible to use user-defined RC implementations together with the standard library and other libraries. 6) Additional uses A good feature is applicable outside of the use case it was introduced for. This is all the more important, the more fundamental a change to the language is, so that it can pull its own weight. Proposed Solution = Most resource management problems are best described in terms of ownership. Therefore, it is natural to take the solution from the vast amount of research and practical experimentation that has been done in this field. Two things are proposed: A) A way to limit the lifetime of resource handles (mostly references/pointers, but could be other things like file handles) to a particular lexical scope (the `scope` keyword is already designated for that purpose), as well as providing a compiler-checkable escape hatch (`scope!identifier` in my suggestion [2], `return ref` in DIP25). B) A way to bind ownership of a resource to a variable and ensure that this variable is the only (non-ephemeral) handle/reference to that resource. The uniqueness property can be exploited to provide many interesting guarantees. The details of implementation and exact semantics of these two features are not important for the big picture. Let's call them SCOPE and UNIQUE from now on. Evaluation == Let's see how we fare: 1) Compatibility Both new features are add-ons to the
Re: Float to string with more digits?
On Tue, 24 Feb 2015 20:04:04 +, Almighty Bob wrote: Is there a more accurate way to do a float and or double to string than... to!string(float); As that seems to limit itself to 6 digits. Use std.string.format or std.format.formattedWrite. std.format contains a description of the various format specifiers. You'll probably want something like %.12f, which formats a floating point number with 12 digits of precision.
Re: An exegesis of Walter's reference counted slice
Andrei Alexandrescu wrote:
I modified Walter's sample code to this:
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array
and the reference count, and also uses @trusted minimally. I inserted
assert()s here and there to clarify the workings. Nothing big except for
the careful use of @trusted.
I'll use this as a basis of some exegesis.
1. The code is a bit more complicated than it should. Overall this is
not a biggie; regular D users are not supposed to write reference
counted slices casually. But I was bummed that e.g. I found no way to
call emplace() @safe-ly.
2. Michel's point (https://issues.dlang.org/show_bug.cgi?id=14221)
reveals the largest issue with RC/GC integration. We need to find a fix
for it if we want to have the GC lift cycles.
3. opIndex (here's the magic) is the most interesting part of the
proposal. It disallows unsafe use such as:
@safe ref int fun()
{
auto a = RCArray!int([1, 2, 3]);
return a[1];
}
Nice. I'd go as far as saying that barring implementation bugs, with
DIP25 in tow, and after we fix 14221, it's impossible to get an invalid
memory access with RCArray in @safe code. This (we offer a way to design
@safe arrays and more generally structs that are @safe) is interesting
and important.
That said there is a rub. The part that deallocates memory in the
destructor must be @trusted. That is fine, but the trustworthiness of
that code depends on the return attribute in opIndex. Furthermore, if
the author of RCSlice forgets to put return there, the compiler won't
help - it just allows wrong code like fun() above to compile and run
(causing dangling pointer use).
So: does DIP25 allow safe slices? Looks that way, though a proof would
be nice. Does it allow other safe interesting structs that own data?
Very likely. Does it allow really sophisticated ownership schemes? We
need to explore that. Does it protect against bugs in implementations of
safe ownership schemes that explicitly release memory? Not too well. I
think the prevalent idiom will be to accompany such artifacts with
unittests that make sure unsafe uses (such as fun() above) do not compile.
Andrei
Is there any plan to allow safe conversions to T[] (in restricted
circumstances, of course)?
Re: An exegesis of Walter's reference counted slice
On Tue, 24 Feb 2015 21:13:42 +, weaselcat wrote: Working with C++ after using D does leave one feeling... disillusioned. that's why i'm not even considering c++ for writing new code anymore. either D, or good old C, if D is not appropriate. actually, i haven't written a line of c++ for several years now. and i wrote almost no new C code for years too -- thanks to seampless interop between D and C. signature.asc Description: PGP signature
Re: An exegesis of Walter's reference counted slice
On 2/24/15 12:03 PM, weaselcat wrote: On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote: ... Off-topic, sorry Are we still going to get a Trusted block, or just going to use trusted lambdas?(They're kind of ugly TBH) We're going to lambdas. Ugliness is a feature. But I was bummed that e.g. I found no way to call emplace() @safe-ly. I assumed emplace would infer @safe? It currently doesn't properly, probably because it uses T* instead of ref T. Andrei
Re: An exegesis of Walter's reference counted slice
On Tue, Feb 24, 2015 at 08:21:53PM +, ketmar via Digitalmars-d wrote:
On Tue, 24 Feb 2015 20:11:17 +, weaselcat wrote:
On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote:
On 2/24/15 12:03 PM, weaselcat wrote:
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
wrote:
...
Off-topic, sorry Are we still going to get a Trusted block, or
just going to use trusted lambdas?(They're kind of ugly TBH)
We're going to lambdas. Ugliness is a feature.
Stroustrup would be proud ;)
yet he made the whole language ugly, instead of making only ugly
things ugly. ;-)
Actually, it's worse than that. He made things that shouldn't be ugly,
ugly, and things that *don't* look ugly are outright wrong.
For example, naked pointers have built-in, convenient syntax. They are
also extremely dangerous, and almost all C++ code containing raw
pointers have bugs one way or another.
For-loops have very nice syntax... except that unless you're writing the
most inane, trivial loops, your code probably has bugs -- off-by-1
errors, wrong loop conditions, etc..
Calling malloc/free is also easy... and your program probably has memory
leak bugs too. Not to mention type-safety bugs if you're not careful
about what you cast that void* into. But hey, writing:
// Woohoo, bare pointer! Let's dance!
void *p = malloc(1234);
sure looks prettier than:
// Repeat after me: Don't repeat yourself... don't repeat
// yourself... don't repeat yourself...
MyType *p = (MyType *)malloc(sizeof(MyType));
Well, new/delete is prettier (as far as C++ goes anyway)... But wait,
you still have memory leaks. Augh...
And what about cleaning up resources after you're done with them?
void func() {
Resource *res = acquireResource();
doStuff(res);
freeResource(res);
}
Easy, right? Yeah, except that doStuff throws exceptions, so you have
resource leakage. Solution? Write a long convoluted wrapper class with a
dtor that cleans up. And a copy ctor that makes sure initializing one
resource from another works correctly. And operator=() to make sure
assignments work correctly. Oh but wait, your ctor is not
exception-safe, so better rewrite *that* to use RAII too. Which means
more copy ctors, more operator=()... oh wait, your copy ctor is not
const-correct so it doesn't get called when you have a const object.
Yeah, and your operator=() too. And ...
After it's all said and done, what used to be a 3-line function has
exploded into a monstrosity who knows how many lines long, with arcane
incantations of auto_ptr, shared_ptr, and all that fancy stuff that
no newbie ever has the hope of parsing, let alone understanding.
http://bartoszmilewski.com/2013/09/19/edward-chands/
Favorite quote:
C++ has become an extremely complex language. There are
countless ways of doing the same thing — almost all of them
either plain wrong, dangerous, unmaintainable, or all of the
above. The problem is that most code compiles and even runs. The
mistakes and shortcomings are discovered much later, often after
the product has been released.
Yep, that's exactly why D has ruined my life, I just can't go back to
that C++ garbage anymore.
T
--
Don't throw out the baby with the bathwater. Use your hands...
[Issue 14223] TimSort algorithm is incorrect
https://issues.dlang.org/show_bug.cgi?id=14223
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--- Comment #1 from Ketmar Dark ket...@ketmar.no-ip.org ---
a possible patch:
fixes TimSort implementation, according to
http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/
diff --git a/std/algorithm/sorting.d b/std/algorithm/sorting.d
index a71eb47..f40e957 100644
--- a/std/algorithm/sorting.d
+++ b/std/algorithm/sorting.d
@@ -1230,21 +1230,21 @@ private template TimSortImpl(alias pred, R)
while (stackLen 1)
{
immutable run3 = stackLen - 1;
-immutable run2 = stackLen - 2;
+auto run2 = stackLen - 2;
immutable run1 = stackLen - 3;
-if (stackLen = 3 stack[run1].length = stack[run2].length
+ stack[run3].length)
+immutable run0 = stackLen - 4;
+if ((stackLen = 3 stack[run1].length = stack[run2].length
+ stack[run3].length) ||
+(stackLen = 4 stack[run0].length = stack[run2].length
+ stack[run1].length))
{
-immutable at = stack[run1].length = stack[run3].length
-? run1 : run2;
-mergeAt(range, stack[0 .. stackLen], at, minGallop, temp);
---stackLen;
+if (stack[run1].length stack[run3].length)
+--run2;
}
-else if (stack[run2].length = stack[run3].length)
+else if (stackLen 2 || stack[run2].length
stack[run3].length)
{
-mergeAt(range, stack[0 .. stackLen], run2, minGallop,
temp);
---stackLen;
+break; // invariant is established
}
-else break;
+mergeAt(range, stack[0 .. stackLen], run2, minGallop, temp);
+--stackLen;
}
}
i haven't analyzed the code, though, and didn't run any unittests besides the
simplest ones, so i can't guarantee that i did it right.
so hereby i sommon someone more knowledgeable to properly check it.
--
An exegesis of Walter's reference counted slice
I modified Walter's sample code to this:
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array
and the reference count, and also uses @trusted minimally. I inserted
assert()s here and there to clarify the workings. Nothing big except for
the careful use of @trusted.
I'll use this as a basis of some exegesis.
1. The code is a bit more complicated than it should. Overall this is
not a biggie; regular D users are not supposed to write reference
counted slices casually. But I was bummed that e.g. I found no way to
call emplace() @safe-ly.
2. Michel's point (https://issues.dlang.org/show_bug.cgi?id=14221)
reveals the largest issue with RC/GC integration. We need to find a fix
for it if we want to have the GC lift cycles.
3. opIndex (here's the magic) is the most interesting part of the
proposal. It disallows unsafe use such as:
@safe ref int fun()
{
auto a = RCArray!int([1, 2, 3]);
return a[1];
}
Nice. I'd go as far as saying that barring implementation bugs, with
DIP25 in tow, and after we fix 14221, it's impossible to get an invalid
memory access with RCArray in @safe code. This (we offer a way to design
@safe arrays and more generally structs that are @safe) is interesting
and important.
That said there is a rub. The part that deallocates memory in the
destructor must be @trusted. That is fine, but the trustworthiness of
that code depends on the return attribute in opIndex. Furthermore, if
the author of RCSlice forgets to put return there, the compiler won't
help - it just allows wrong code like fun() above to compile and run
(causing dangling pointer use).
So: does DIP25 allow safe slices? Looks that way, though a proof would
be nice. Does it allow other safe interesting structs that own data?
Very likely. Does it allow really sophisticated ownership schemes? We
need to explore that. Does it protect against bugs in implementations of
safe ownership schemes that explicitly release memory? Not too well. I
think the prevalent idiom will be to accompany such artifacts with
unittests that make sure unsafe uses (such as fun() above) do not compile.
Andrei
Re: Float to string with more digits?
Just to clarify what i needed was... %.8g or %.7e Significant digits, or fixed width scientific form. I needed more significant digits. %.8f controls how many digits to print after the decimal point, which is not the same thing.
Re: An exegesis of Walter's reference counted slice
On 2/24/2015 11:55 AM, Steven Schveighoffer wrote: Note, you need to GC.addRange all the elements if the type has references, or else you cannot have GC pointers in the array. Yes. I deliberately left that out in order to keep attention focused on the use of 'return ref'. Ironically, if those elements are references, but are reference counted references, then you wouldn't need to addRange. An interesting problem... Correct, but (aside from the performance hit) it wouldn't be a bug to scan them unnecessarily in the GC. One way is to have a scheme whereby, with introspection, a type can be determined to be ref counted. Then, using static if, doing the addRange would only be necessary if: 1. the element type contained indirections 2. those indirections were not ref counted I think a system of making sure a piece of data is always destroyed in the same thread it was created (unless of course, the thread is gone, in which case it doesn't matter), should be fine. Yup, and I believe this is an orthogonal issue.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 24 February 2015 at 07:53:52 UTC, Jacob Carlborg wrote: On 2015-02-23 21:30, Walter Bright wrote: Count me among those. In Java, write barriers make sense because Java uses the GC for everything. Pretty much every indirection is a GC reference. This is not at all true with D code. But since the compiler can't know that, it has to insert write barriers for all those dereferences regardless. The alternative would be to have two kind of pointers, one for GC allocated data and one for other kind of data. But I know you don't like that either. We kind of already have this, class references and regular pointers. But that would tie classes to the GC. I suspect it would be a terrible performance hit. It would be nice to have some numbers backing this up. This the approach taken by Active Oberon and Modula-3. Pointers are GC by default, but can be declared as untraced pointers in code considered @system like in D. -- Paulo
Re: Dgame revived
On Tuesday, 24 February 2015 at 09:07:19 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 00:53:49 UTC, Mike Parker wrote: On 2/24/2015 8:18 AM, Gan wrote: Doesn't work. Still gives the same OpenGL too low error. I think you need to place the lines SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE); SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG); before window creation. Yes. All SDL_GL_SetAttributes must be called before window creation for them to have any effect. I thought that was already understood. You sound a little rude. :D I thought that must precede the GLContext. That made the most sense to me. I will change it. ;) It semms there is a problem with ma DUB package: Branch ~beta: Got JSON of type undefined, expected object. Branch ~tune: Got JSON of type undefined, expected object. I deleted these branches, drafted a new tag and tried to trigger a manual update, but nothing happens.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
I suspect it would be a terrible performance hit. It would be nice to have some numbers backing this up. This the approach taken by Active Oberon and Modula-3. Pointers are GC by default, but can be declared as untraced pointers in code considered @system like in D. Do they have concurrent gc and emit barriers for each write to a default pointer? Do they have precise scanning and don't scan the untraced pointers? Are the meaningful performance comparisons between the two pointer types that would enable us to estimate how costly emitting those barriers in D would be?
Re: Dgame revived
On Tuesday, 24 February 2015 at 09:56:56 UTC, Gan wrote: On Tuesday, 24 February 2015 at 09:24:17 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 09:07:19 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 00:53:49 UTC, Mike Parker wrote: On 2/24/2015 8:18 AM, Gan wrote: Doesn't work. Still gives the same OpenGL too low error. I think you need to place the lines SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE); SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG); before window creation. Yes. All SDL_GL_SetAttributes must be called before window creation for them to have any effect. I thought that was already understood. You sound a little rude. :D I thought that must precede the GLContext. That made the most sense to me. I will change it. ;) It semms there is a problem with ma DUB package: Branch ~beta: Got JSON of type undefined, expected object. Branch ~tune: Got JSON of type undefined, expected object. I deleted these branches, drafted a new tag and tried to trigger a manual update, but nothing happens. I had to force dub to upgrade in order for it to pull the latest code from the master branch. But on the plus side it runs. On the downside it still only displays a blank white screen for Mac users. Yeah, that is really strange. For all tutorials? I have already started on the weekend to begin Dgame 0.5 and revise the whole. So that's at least a glimmer of hope.
Re: D GC theory
On Tuesday, 24 February 2015 at 00:30:43 UTC, ketmar wrote: On Mon, 23 Feb 2015 21:11:22 +, Sativa wrote: How hard would it be to modify D's GC to do the following two things: 1. Scan the heap in the BG on another thread/cpu for compactification. needs read/write barriers added to generated code. a major slowdown for ALL memory access. Only modifications of pointers, which introduce new cross-block dependencies (so that GC knows to recheck the new dependency). Other memory access goes without slowdown.
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 18 February 2015 at 16:18:10 UTC, Elie Morisse wrote: BTW I just pushed support for function template instantiation. So lately thanks to a bit of free time there has been quite a lot of new features implemented: overloaded operators, function templates, and groundwork for class value types (they were added to the AST as a new semi-hackish kind of type, they make mapping any C++ type possible but they can't be used directly from D code yet). Operators should make std::map usable, so I'm going to resume testing further STL types. Just so others know, coding of Calypso continues and more of the STL is working now. Currently these C++ files can be mapped and used from a D program with Calypso: bitset deque foreach list map set stack string vector vstring -- just a vector of strings, but at least using classes in combination is working. Not all functions in these files work, but a significant portion do in most cases above. Iterators are still not working due to class value support being incomplete, but hopefully it will be working soon. Thanks to Elie for moving forward with this. Coding continues :) Thanks, Kelly
Re: Calypso: Direct and full interfacing to C++
On Tuesday, 24 February 2015 at 08:39:39 UTC, Kelly wrote: due to class value support being incomplete What about using that trick: recognize C++ classes and represent them internally as structs with altered mangling - at least it frees you from messing with D classes.
Re: A Refcounted Array Type
On Monday, February 23, 2015 23:02:03 Walter Bright via Digitalmars-d wrote:
On 2/23/2015 9:59 PM, Jonathan M Davis via Digitalmars-d wrote:
And delete is supposed to have been deprecated ages ago, but yeah, it
_definitely_ shouldn't be considered @safe.
Managing memory always is going to be unsafe. The idea is to encapsulate that,
which RCArray shows how to do.
That's fine. The issue is that delete is considered @safe by the compiler,
not with the idea of RCArray. This code shouldn't compile:
void main() @safe
{
auto i = new int(5);
delete i;
}
and it does. Of course, delete is supposed to have been deprecated, but no
one has gotten around to doing it. So, maybe that's why no one made it so
that it was treated correctly with regards to @safe.
- Jonathan M Davis
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:16:00 UTC, Ulrich Küttler
wrote:
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why... :(
The counter is shared amount all copies of the array.
Ah yes, what an idiot ! Thanks !
Re: A Refcounted Array Type
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
This is pretty straightforward. More could be done:
1. small array optimization
2. support for ranges as constructor args
3. present a range interface
4. support for malloc/free instead of GC
5. bounds checking
6. the array[] and the count could be allocated together
7. array[] could be just a pointer
but the basic idea is there, I didn't want to hide it behind
all the other flesh a professional type would have.
Note the return in opIndex(). This is DIP25 at work!
Compile:
dmd rcarray -unittest -main -dip25
===
struct RCArray(E) {
this(E[] a)
{
array = a.dup;
start = 0;
end = a.length;
count = new int;
*count = 1;
}
~this()
{
if (count --*count == 0)
delete array;
}
this(this)
{
if (count)
++*count;
}
size_t length()
{
return end - start;
}
ref E opIndex(size_t i) return // here's the magic
{
return array[start + i];
}
RCArray opSlice(size_t lwr, size_t upr)
{
RCArray result = this;
result.start = start + lwr;
result.end = start + upr;
return result;
}
private:
E[] array;
size_t start, end;
int* count;
}
unittest
{
static int[3] s = [7, 6, 4];
auto r = RCArray!int(s);
assert(r.length == 3);
assert(r[0] == 7);
assert(r[1] == 6);
assert(r[2] == 4);
assert(*r.count == 1);
{
auto r2 = r;
assert(r2[0] == 7);
assert(r2[1] == 6);
assert(r2[2] == 4);
assert(*r.count == 2);
r[1] = 3;
assert(r2[0] == 7);
assert(r2[1] == 3);
assert(r2[2] == 4);
}
assert(*r.count == 1);
auto r3 = r[1 .. 3];
r[2] = 9;
assert(r3[0] == 3);
assert(r3[1] == 9);
/+
ref int test(ref RCArray!int rr)
{
return rr[1]; // this gives error
}
+/
}
Thanks for the example.
I think we need more practical stuff like this compiled somewhere
on the homepage, especially when a new feature is introduced, to
answer questions like: What is it? When should I use it? And how
do I implement it? Saves a lot of time and the frustration of
finding out later that there _is_ such a feature, only I never
heard of it until now.
Re: DlangUI
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote: Hello! I would like to announce my project, DlangUI library - cross-platform GUI for D. https://github.com/buggins/dlangui License: Boost License 1.0 Native library written in D (not a wrapper to other GUI library) - easy to extend. Best regards, Vadim coolreader@gmail.com WARNING! Breaking change in dlangui! Pull request to use package.d instead of dlangui/all.d is integrated. If you are using dlangui in your project, please change import dlangui.all; to import dlangui; in order to fix build.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/24/2015 1:30 AM, Tobias Pankrath wrote: Are the meaningful performance comparisons between the two pointer types that would enable us to estimate how costly emitting those barriers in D would be? Even 10% makes it a no-go. Even 1%. D has to be competitive in the most demanding environments. If you've got a server farm, 1% speedup means 1% fewer servers, and that can add up to millions of dollars.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/23/2015 11:53 PM, Jacob Carlborg wrote: On 2015-02-23 21:30, Walter Bright wrote: Count me among those. In Java, write barriers make sense because Java uses the GC for everything. Pretty much every indirection is a GC reference. This is not at all true with D code. But since the compiler can't know that, it has to insert write barriers for all those dereferences regardless. The alternative would be to have two kind of pointers, one for GC allocated data and one for other kind of data. But I know you don't like that either. That kinda defeats much of the point to having a GC. I suspect it would be a terrible performance hit. It would be nice to have some numbers backing this up. I've seen enough benchmarks that purport to show that Java is just as fast as C++, as long as only primitive types are being used and not pointers. I've done enough benchmarks to know that inserting even one extra instruction in a tight loop has significant consequences. If you don't believe that, feel free to try it and see. D is not going to have competitive performance with systems programming languages if write barriers are added.
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright wrote: On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote: The issue is that delete is considered @safe by the compiler, I thought more people would be interested in how to do a memory safe reference counted container. This is really interesting ! Thought as a beginner, I am wondering why the counter need to be a pointer ?
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why... :(
The counter is shared amount all copies of the array.
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d
wrote:
The issue is that delete is considered @safe by the
compiler,
I thought more people would be interested in how to do a
memory safe reference counted container.
This is really interesting ! Thought as a beginner, I am
wondering why the counter need to be a pointer ?
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why... :(
It's more effective if you figure it out on your own.
But maybe this is a bit more clear?
https://github.com/Dgame/m3/blob/master/SmartPointer.d#L106
How to use Fiber?
There is a int[] ,how to use the Fiber execute it ?
Such as :
import std.stdio;
import core.thread;
class DerivedFiber : Fiber
{
this()
{
super( run );
}
private :
void run()
{
printf( Derived fiber running.\n );
faa();
}
}
int[] v;
void ftread()
{
DerivedFiber work = new DerivedFiber();
writeln( will call );
work.call();
writeln( stop call );
}
void faa()
{
writeln( start );
//Fiber.yield();
writeln( start yield );
foreach(c;v)
{
writeln( current n is ,c );
}
}
void main()
{
int n=1;
while(n=10_001)
{
v~=n;
n+=5000;
}
printf( Execution returned to calling context.\n );
ftread();
}
-end
I dont's think it's a good work.
How about you?
Thank you.
Re: Dgame revived
On Tuesday, 24 February 2015 at 00:53:49 UTC, Mike Parker wrote: On 2/24/2015 8:18 AM, Gan wrote: Doesn't work. Still gives the same OpenGL too low error. I think you need to place the lines SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE); SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG); before window creation. Yes. All SDL_GL_SetAttributes must be called before window creation for them to have any effect. I thought that was already understood. You sound a little rude. :D I thought that must precede the GLContext. That made the most sense to me. I will change it. ;)
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/24/2015 1:50 AM, Walter Bright wrote: On 2/23/2015 11:53 PM, Jacob Carlborg wrote: On 2015-02-23 21:30, Walter Bright wrote: I suspect it would be a terrible performance hit. It would be nice to have some numbers backing this up. I've seen enough benchmarks that purport to show that Java is just as fast as C++, as long as only primitive types are being used and not pointers. Let me put it another way. You don't believe me about the performance hit. My experience with people who don't believe me is they won't believe any benchmarks I produce, either. They'll say I didn't do the benchmark right, it is not representative, the data is cherry-picked, nobody would write code that way, etc. I quit writing benchmarks for public consumption for that reason years ago. It shouldn't be hard for you to put together a benchmark you can believe in.
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d
wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be interested in how to do a
memory safe reference counted container.
This is really interesting ! Thought as a beginner, I am
wondering why the counter need to be a pointer ?
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why... :(
Re: A Refcounted Array Type
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be interested in how to do a
memory safe reference counted container.
This is really interesting ! Thought as a beginner, I am
wondering why the counter need to be a pointer ?
That's why:
this(this)
{
if (count)
++*count;
}
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2015-02-22 21:48, Walter Bright wrote: And I suspect that ARC is why they don't have exceptions. Objective-C still has both ARC and exceptions. Although the documentation [1] says that ARC is not exception safe by default, but it does have a flag to enable it -fobjc-arc-exceptions. [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions -- /Jacob Carlborg
Re: Deprecation process documented?
On Tuesday, February 24, 2015 08:49:55 Jacob Carlborg via Digitalmars-d-learn wrote: Is the deprecation process used for Phobos and druntime code documented somewhere? I.e. how long after a deprecation is a symbols removed and so on. No, it's not documented. I really should put it up on the wiki. The current process is that if the replacement for the symbol is being introduced at the same time, the old symbol will be marked as deprecated for a release (so that it's possible for code to build on both the latest release and on master without getting deprecation messages with either). If there is no replacement, or the replacement already exists, then that's not necessary. After that, the symbol is deprecated but documented for about a year. Then it's undocumented but remains there and deprecated for about another year, and then it finally gets removed entirely. Release dates tend to screw with how consistent the timing is (since the release dates generally haven't been consistent or even necessarily frequent), and sometimes we adjust it depending on the particular circumstances of a symbol. And of course, we've been trying to deprecate stuff rarely for a while now, so there isn't much going through the deprecation process at the moment. But that's approximately what we've been doing with the deprecation process for a while now. If anything sits in a particular stage of the deprecation cycle for longer than that, it's typically either because I didn't get around to moving it along when I was supposed to or because someone else deprecated it and didn't mark it the way that I normally mark them, in which case, I sometimes miss those. - Jonathan M Davis
Re: A Refcounted Array Type
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote: The issue is that delete is considered @safe by the compiler, I thought more people would be interested in how to do a memory safe reference counted container.
Re: Dgame revived
On Tuesday, 24 February 2015 at 09:24:17 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 09:07:19 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 00:53:49 UTC, Mike Parker wrote: On 2/24/2015 8:18 AM, Gan wrote: Doesn't work. Still gives the same OpenGL too low error. I think you need to place the lines SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE); SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG); before window creation. Yes. All SDL_GL_SetAttributes must be called before window creation for them to have any effect. I thought that was already understood. You sound a little rude. :D I thought that must precede the GLContext. That made the most sense to me. I will change it. ;) It semms there is a problem with ma DUB package: Branch ~beta: Got JSON of type undefined, expected object. Branch ~tune: Got JSON of type undefined, expected object. I deleted these branches, drafted a new tag and tried to trigger a manual update, but nothing happens. I had to force dub to upgrade in order for it to pull the latest code from the master branch. But on the plus side it runs. On the downside it still only displays a blank white screen for Mac users.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 2/23/2015 11:57 PM, Jacob Carlborg wrote: On 2015-02-22 21:48, Walter Bright wrote: And I suspect that ARC is why they don't have exceptions. Objective-C still has both ARC and exceptions. Although the documentation [1] says that ARC is not exception safe by default, but it does have a flag to enable it -fobjc-arc-exceptions. [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions From your reference: Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option. Note severe runtime and code size penalties. Just what I said.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 24 February 2015 at 09:30:33 UTC, Tobias Pankrath wrote: I suspect it would be a terrible performance hit. It would be nice to have some numbers backing this up. This the approach taken by Active Oberon and Modula-3. Pointers are GC by default, but can be declared as untraced pointers in code considered @system like in D. Do they have concurrent gc and emit barriers for each write to a default pointer? Do they have precise scanning and don't scan the untraced pointers? Are the meaningful performance comparisons between the two pointer types that would enable us to estimate how costly emitting those barriers in D would be? Both Active Oberon and Modula-3 support threading at language level, so multi-threading is a presence on their runtimes. The latest documentation available for Active Oberon is from 2002. http://e-collection.library.ethz.ch/view/eth:26082 Originally it was a concurrent mark-and-sweep GC, with stop the world phase for collection. Other algorithms are discussed on the paper. Sadly ETHZ is done with Oberon as their startup failed to pick up steam in the industry (selling Component Pascal, an evolution of Oberon-2). As for Modula-3, due to the way the the whole DEC, Olivetti, Compaq, HP process went, it isn't easy to find much documentation online. I had a few books. The latest implementation had a concurrent incremental generational GC. https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html 2002 is also around the same time that Modula-3 developed was stopped. Dylan, which I just remembered while writing this, used the MPS collector. http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ismm2002.html Sadly the industry went JVM/CLR instead, and only now we are getting back to native systems programming with GC languages. If those languages had been picked up by the industry instead of JVM/CLR, the situation could be quite different. As always, it is a matter where the money for research gets pumped into. -- Paulo
Re: Mac Apps That Use Garbage Collection Must Move to ARC
The latest implementation had a concurrent incremental generational GC. https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html According to this they never had a concurrent or incremental GC on x86.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 24 February 2015 at 11:08:59 UTC, Tobias Pankrath wrote: The latest implementation had a concurrent incremental generational GC. https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html According to this they never had a concurrent or incremental GC on x86. Sorry about the caps, couldn't find a better way to emphasis. Not sure where you found out the information about x86, or why it should matter. The current collector is, by default, INCREMENTAL and GENERATIONAL. The interruptions of service should be very small, and the overall performance should be better than with the previous collectors. Note that the new optional BACKGROUND collection THREAD is not on by default; this may change in the future. I take this to understand that the latest collector was incremental, with the ability to work concurrently when the background collection was enabled, on some CPU architecture, regardless which one. Modula-3 died when its team kept changing hands between DEC, Olivetti, Compaq and HP. It hardly had any new development since 2000, its GC would surely look differently if development hadn't stopped and maybe even be quite good on x86. -- Paulo
Re: Struct inheritance
On Tuesday, 24 February 2015 at 12:16:43 UTC, Tobias Pankrath
wrote:
On Tuesday, 24 February 2015 at 12:05:51 UTC, amber wrote:
Hi,
Is it possible in D to have inheritance using value types,
i.e. structs?
No runtime polymorphism, but a kind of sub typing via alias
this.
struct S { void foo() { writeln(S.foo); }
struct T { S s; alias s this; }
T t;
t.foo(); // prints S.foo
Also I don't quite understand how copy ctors work in D. Do I
need to implement opAssign(S other) {}, or this(this) {} and
what's the difference between these two?
If available, opAssign will be used in an assignment like x = y;
You're custom opAssign can take arbitrary parameter types, so
typeof(y) does not have to be typeof(x).
postblit is used for copy construction. This could be
assignment if no opAssign is provided (not sure about this),
but also e.g. passing parameter by value or returning from a
functions
Thank you Tobias I get it now.
/amber
Re: Memory safety depends entirely on GC ?
On Tuesday, 24 February 2015 at 02:35:41 UTC, deadalnix wrote: For each of these issues, solution are proposed. What I (and I think Mark would agree) propose would solve them all. Yes this is more complex than any of the solution proposed for each of these. But this is way simpler, and enable way more than having a unique, simpler solution for each of these problems. Indeed I agree. But judging by Andrei's response above, I'm longer so sure he is actually aware of what we proposed.
Re: how to stop a variable from being optimized out
On Tuesday, 24 February 2015 at 06:48:26 UTC, ketmar wrote: but why do you need this? just use `atomicLoad` to get shared variable value, it will do the right caching. Nice! Thanks. Tested atomicLoad and it is slightly faster for my non blocking queue.
Re: DlangIDE
On Friday, 6 February 2015 at 14:03:07 UTC, Vadim Lopatin wrote:
Hello,
I'm working on cross-platform D language IDE - DlangIDE.
It's written in D using DlangUI based GUI.
Project on GitHub: https://github.com/buggins/dlangide
Project update:
Smart autoindents implemented for D source code editors.
So far, can be configured only manually in settings file:
~/.dlangide/settings.json:
{
editors: {
textEditor: {
useSpacesForTabs: true,
tabSize: 4,
smartIndents: true,
smartIndentsAfterPaste: true
}
},
interface: {
theme: theme_default,
language: en
}
}
Best regards,
Vadim
Re: Struct inheritance
On Tuesday, 24 February 2015 at 12:05:51 UTC, amber wrote:
Hi,
Is it possible in D to have inheritance using value types, i.e.
structs?
No runtime polymorphism, but a kind of sub typing via alias this.
struct S { void foo() { writeln(S.foo); }
struct T { S s; alias s this; }
T t;
t.foo(); // prints S.foo
Also I don't quite understand how copy ctors work in D. Do I
need to implement opAssign(S other) {}, or this(this) {} and
what's the difference between these two?
If available, opAssign will be used in an assignment like x = y;
You're custom opAssign can take arbitrary parameter types, so
typeof(y) does not have to be typeof(x).
postblit is used for copy construction. This could be assignment
if no opAssign is provided (not sure about this), but also e.g.
passing parameter by value or returning from a function.
[Issue 4650] Static data that must be scanned by the GC should be grouped
https://issues.dlang.org/show_bug.cgi?id=4650 --- Comment #9 from Rainer Schuetze r.sagita...@gmx.de --- Actually the patch needs https://github.com/D-Programming-Language/druntime/pull/1180 (and https://github.com/D-Programming-Language/dmd/pull/4445 for Win64) to have any effect. --
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo Pinto wrote: Sorry about the caps, couldn't find a better way to emphasis. Not sure where you found out the information about x86, or why it should matter. I found an (apparently older) version of the documentation earlier that looked exactly the same, so I didn't mind to read your link carefully enough. The current collector is, by default, INCREMENTAL and GENERATIONAL. The interruptions of service should be very small, and the overall performance should be better than with the previous collectors. Yes, however from your page now: Now @M3novm is the default. And if you follow the link: @M3novm implies @M3noincremental and @M3nogenerational. Maybe, that's an documentation error. This was the place where the other version mentioned that x86 is not supported. While I like that you constantly remind us about achievements of older programming languages, you'll often do it with a that problem was solved in Language X 20 years ago-attitude, but almost never elaborate how that solution could be applied to D. When taking a closer look, I often find that those languages solved an similar but different problem and the solution do not apply to D at all. For example the last time in the discussion on separate compilation, templates and object files you blamed the C tool chain and pointed to pascal/delphi. But they didn't solved the problem, because they didn't faced it in the first place, because they didn't had the template and meta-programming capabilities of D. At the problem at hand: I don't see how Module3's distinction between system and default pointer types or the lessons they learned help in any way to improve the current D GC.
Re: A Refcounted Array Type
Does DIP25 means we can turn resources into RC types and be done
with non-deterministic destructor calls by the GC, without using
RefCounted or Unique?
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
This is pretty straightforward. More could be done:
1. small array optimization
2. support for ranges as constructor args
3. present a range interface
4. support for malloc/free instead of GC
5. bounds checking
6. the array[] and the count could be allocated together
7. array[] could be just a pointer
but the basic idea is there, I didn't want to hide it behind
all the other flesh a professional type would have.
Note the return in opIndex(). This is DIP25 at work!
Compile:
dmd rcarray -unittest -main -dip25
===
struct RCArray(E) {
this(E[] a)
{
array = a.dup;
start = 0;
end = a.length;
count = new int;
*count = 1;
}
~this()
{
if (count --*count == 0)
delete array;
}
this(this)
{
if (count)
++*count;
}
size_t length()
{
return end - start;
}
ref E opIndex(size_t i) return // here's the magic
{
return array[start + i];
}
RCArray opSlice(size_t lwr, size_t upr)
{
RCArray result = this;
result.start = start + lwr;
result.end = start + upr;
return result;
}
private:
E[] array;
size_t start, end;
int* count;
}
unittest
{
static int[3] s = [7, 6, 4];
auto r = RCArray!int(s);
assert(r.length == 3);
assert(r[0] == 7);
assert(r[1] == 6);
assert(r[2] == 4);
assert(*r.count == 1);
{
auto r2 = r;
assert(r2[0] == 7);
assert(r2[1] == 6);
assert(r2[2] == 4);
assert(*r.count == 2);
r[1] = 3;
assert(r2[0] == 7);
assert(r2[1] == 3);
assert(r2[2] == 4);
}
assert(*r.count == 1);
auto r3 = r[1 .. 3];
r[2] = 9;
assert(r3[0] == 3);
assert(r3[1] == 9);
/+
ref int test(ref RCArray!int rr)
{
return rr[1]; // this gives error
}
+/
}
Struct inheritance
Hi,
Is it possible in D to have inheritance using value types, i.e.
structs?
Also I don't quite understand how copy ctors work in D. Do I need
to implement opAssign(S other) {}, or this(this) {} and what's
the difference between these two?
Thanks,
Amber
Re: Memory safety depends entirely on GC ?
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu wrote: On 2/23/15 6:56 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: These two points have undesirable consequences: All consumers such objects need to be aware of the exact type, which includes the management strategy (RC, Unique, GC). But this is a violation of the principle of separation of concerns: a consumer shouldn't need to have information about the management strategy, it should work equally with `RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it doesn't take ownership of the resource. Well I don't know of another way. Ok, I wrote my reply assuming that you are aware of the various proposals deadalnix, myself and several other people have made in the past, some of them quite specific. But now that I think of it, I don't remember that you were ever directly referring to it in any of your posts. Maybe you just missed it? As one example, here is what I originally suggested: http://wiki.dlang.org/User:Schuetzm/scope It's not completely up to date, during discussions I gained many useful new insights to simplify it and make things more consistent. It's also part of a bigger picture (deadalnix's ideas about ownership play an important role, too), which unfortunately isn't easy to recognize, because this page has become quite large und unwieldy. I should make a post explaining this. In general, this and related proposals tend to limit themselves on memory management (as witnessed by the importance that `ref` and `@safe` play in them). This is too narrow IMO. A well thought-out solution can be equally applicable to the broader field of resource management. Looking forward to your insights. See above. I had the impression that you were aware of the proposals, but for some reason were opposed to them. Maybe that's not the case?
fwiw quora thread on facebook/D
https://www.quora.com/Why-is-Facebook-supporting-development-of-the-D-programming-language/answer/Laeeth-Isharc Quora has the vices of every democratic platform, but does seem to reach people, and a different set to demographic of hacker news and the like.
[Issue 14220] New: Bad codegen for optimized std.conv.text in combination with concatenation
https://issues.dlang.org/show_bug.cgi?id=14220
Issue ID: 14220
Summary: Bad codegen for optimized std.conv.text in combination
with concatenation
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
module test;
import std.conv;
void main()
{
string s = err: ~ text(14);
}
Compiling this on win64 with:
dmd -g -m64 -release -inline -O test.d
generates a crashing program. The error seems to disappear if one of -release
,-inline and -O is removed. It also does not happen without the concatenation.
--
Re: Dgame revived
On Tuesday, 24 February 2015 at 10:01:11 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 09:56:56 UTC, Gan wrote: On Tuesday, 24 February 2015 at 09:24:17 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 09:07:19 UTC, Namespace wrote: On Tuesday, 24 February 2015 at 00:53:49 UTC, Mike Parker wrote: On 2/24/2015 8:18 AM, Gan wrote: Doesn't work. Still gives the same OpenGL too low error. I think you need to place the lines SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE); SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG); before window creation. Yes. All SDL_GL_SetAttributes must be called before window creation for them to have any effect. I thought that was already understood. You sound a little rude. :D I thought that must precede the GLContext. That made the most sense to me. I will change it. ;) It semms there is a problem with ma DUB package: Branch ~beta: Got JSON of type undefined, expected object. Branch ~tune: Got JSON of type undefined, expected object. I deleted these branches, drafted a new tag and tried to trigger a manual update, but nothing happens. I had to force dub to upgrade in order for it to pull the latest code from the master branch. But on the plus side it runs. On the downside it still only displays a blank white screen for Mac users. Yeah, that is really strange. For all tutorials? I have already started on the weekend to begin Dgame 0.5 and revise the whole. So that's at least a glimmer of hope. Try commenting out this line: SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_FORWARD_COMPATIBLE_FLAG) According to the opengl.org wiki this flag should not be used except in GL 3.0 and was made redundant in GL 3.1. The code snippet above is trying to set MAJOR.MINOR as GL 3.3. I just had an issue on Linux with a blank screen. Commenting out this line resolved the issue. Cheers, stew
Vector swizzling a-la GPU shaders in D
I was playing with D for a several weeks and came up with a swizzling implementation for a vector class. The feature is common for languages like GLSL or HLSL. One of the use cases is a vector cross product with only two GPU instructions. Here is the idea: http://pastebin.com/Hvntey0s Here is the full source of the vector: http://pastebin.com/AnJKXBry The code allows you to write something like const foo = bar.yyzx where bar is a vector and .yyzx constructs a new one from it. This is not a production code. I believe one could make it much better. But the idea seems to be interesting in the area of inner DSLs for D.
Re: D GC theory
On Tuesday, 24 February 2015 at 14:45:17 UTC, Marc Schütz wrote: It's possible to (ab)use the MMU as a write barrier. Uhm... The throughput for L/SFENCE is 5 cycles and SFENCE 33 cycles... The cost of a page miss is 1000 cycles + overhead for copying. And that's assuming that you have enough memory and that the TLB isn't affected...
Re: Vector swizzling a-la GPU shaders in D
On Tuesday, 24 February 2015 at 15:38:55 UTC, Denis 'GeneralGDA' Gladkiy wrote: I was playing with D for a several weeks and came up with a swizzling implementation for a vector class. The feature is common for languages like GLSL or HLSL. One of the use cases is a vector cross product with only two GPU instructions. Here is the idea: http://pastebin.com/Hvntey0s Here is the full source of the vector: http://pastebin.com/AnJKXBry The code allows you to write something like const foo = bar.yyzx where bar is a vector and .yyzx constructs a new one from it. This is not a production code. I believe one could make it much better. But the idea seems to be interesting in the area of inner DSLs for D. I'm sorry this is nothing new. https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L390 https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/vector.d#L297
Re: Stackless resumable functions
@ketmar You know you may be kinda right about reusability though... I am not as familiar with await as I am with coroutines, but I think the principal is similar. The Visual Studio team seems to have chosen to tackle stackless resumable routines and await at the same time, so there may be some reusability there. I couldn't say for sure though. In any case, I don't think it would be hard to refactor my suggested implementation under the covers to facilitate something like await without hurting the user-facing functionality.
Re: let (x,y) = ...
Nick Treleaven, el 19 de February a las 17:25 me escribiste: On 19/02/2015 17:00, Nick Treleaven wrote: Alternatively std.typetuple.TypeTuple can be used instead of let not for ranges and arrays though Yes, but `tuple` overloads could be added for those. Or not - the length isn't known at compile-time. Tuple already supports construction from a static array: int a, b; TypeTuple!(a, b) = Tuple!(int, int)([3, 4]); I'm hacking std.typecons so this does work: TypeTuple!(a, b) = [4, 5].tuple; Why not to integrate this let to phobos, that seems to be a lot of syntactic noise compared to : let (a, b) = [4, 5]; -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- You can try the best you can If you try the best you can The best you can is good enough
Re: A Refcounted Array Type
On 2/24/15 8:17 AM, Michel Fortin wrote: On 2015-02-23 22:15:46 +, Walter Bright said: int* count; [...] if (count --*count == 0) [...] Careful! This isn't memory safe and you have to thank the GC for it. If you ever use RCArray as a member variable in a class, the RCArray destructor is going to be called from a random thread when the class destructor is run. If some thread has a stack reference to the array you have a race. You have to use an atomic counter unless you can prove the RCArray struct will never be put in a GC-managed context. It is rather sad that the language has no way to enforce such a restriction, and also that @safe cannot detect that this is a problem here. Actually, RCArray can never be allocated on GC, or you may corrupt memory. count may be non-null, and point at invalid memory when the dtor is called. Only safe way to do this is to C malloc/free the count. And yes, at that point, you need atomics. -Steve
Re: D GC theory
On Monday, 23 February 2015 at 21:11:23 UTC, Sativa wrote: 1. Scan the heap in the BG on another thread/cpu for compactification. You need to a precise GC to do this, because you need to know what is a pointer. Otherwise if you have two variables, say a size_t and a pointer that contain the same raw value, on compacting you could overwrite the size_t despite it just being a number and not a pointer. Also you need to ban certain pointer shenanigans (like xor fun stuff), though the current GC doesn't work when those are in use anyway, so I guess it's not too bad.
Re: What is the state of D with Android/iOS
On 25/02/2015 2:44 a.m., Rishub Nagpal wrote: Is D currently mature enough to create binaries for android/iOS? I've been researching this, but most posts predate 2013, and I wanted to know what was the current status. D bindings for the JNI is certainly possible, so by extension it should be possible to call D libraries with Android's NDK, correct? Is is possible to write android apps purely in D similar to mono for android? http://developer.xamarin.com/guides/android/getting_started/hello,android/hello,android_quickstart/ On the note of D - Java / Java - D bindings. I have done a bit of work on my fork of djvm https://github.com/rikkimax/djvm/blob/master/source/wrappers/java/lang/String.d Fields and static fields should also work at this time. But it is a long way off production.
Re: D GC theory
On Tuesday, 24 February 2015 at 08:39:02 UTC, Kagamin wrote: On Tuesday, 24 February 2015 at 00:30:43 UTC, ketmar wrote: On Mon, 23 Feb 2015 21:11:22 +, Sativa wrote: How hard would it be to modify D's GC to do the following two things: 1. Scan the heap in the BG on another thread/cpu for compactification. needs read/write barriers added to generated code. a major slowdown for ALL memory access. Only modifications of pointers, which introduce new cross-block dependencies (so that GC knows to recheck the new dependency). Other memory access goes without slowdown. But this type of thinking is the reason why the current GC is in the state it is. The compiler knows which pointers are free and which ones are bound. Bound pointers are pointers that are not assigned freely by the user. e.g., a pointer to an array who's address never is arbitrarily set by the user is bound. The compiler knows where and how the pointer is assigned. Most pointers are this way. Bound pointers are pointers the GC can easily clean up because it knows when and how they are used. In this way, if all pointers of a program were bound, the GC can work in the background and never pause the state to clean up. (essentially the compiler would need to insert special code) most pointers are bound pointers. Free pointers are more difficult as they can, say, be randomly initiated and point to anywhere on the heap and have to be looked in a locked way. (to prevent them changing in the middle of some GC operation) But if one distinguishes bound and free pointers(Easily done with a bit in the pointers) and has the compiler keep track of when free pointers are used(by having a dirty bit when they are written to), then one can more easily scan the heap in the background. In fact, one could potentially get away from all synching issues by doing the following: When ever free pointers are used a simple spin lock is used. The spin lock checks a flag in the free pointers table that signals that a pointer is being changed by the code. When this is true, the free pointers table is in a state of flux and can't be relied on. In the mean time, the GC can build up information about the heap for the bound pointers. It can figure out what needs to be changed, setup buffering(which can be done using bits in the pointer), etc all in the background because the bound pointers are stable and deterministically change. When the free pointers table's dirty flag is unset it means that the free pointers are not changing in the program and the GC can lock the table using another flag. When the flag is set the spin lock kicks in and pauses the program while the GC is working on the free pointers table. (or to be more efficient, the program can yield to some other background task code) By having multiple tables of free pointers one can reduce the overhead. The GC looks at on a piece at a time and locks on a fraction of the code at any point in time. The compiler can distribute the locks vs pages in an optimized way through profiling.
Re: A Refcounted Array Type
On 2/23/15 6:05 PM, Walter Bright wrote: On 2/23/2015 5:41 PM, weaselcat wrote: On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote: ref E opIndex(size_t i) return // here's the magic exactly what is this doing? I don't see this explained in DIP25 at all. The 'this' is passed by reference. So the 'return' is really 'return ref this', the rest is explained by DIP25. We should amend DIP25 to explain that this is handled like a parameter. -- Andrei
Concurrency in D
There is a int[] ,how to use the Fiber execute it ?
Such as :
import std.stdio;
import core.thread;
class DerivedFiber : Fiber
{
this()
{
super( run );
}
private :
void run()
{
printf( Derived fiber running.\n );
faa();
}
}
int[] v;
void ftread()
{
DerivedFiber work = new DerivedFiber();
writeln( will call );
work.call();
writeln( stop call );
}
void faa()
{
writeln( start );
//Fiber.yield();
writeln( start yield );
foreach(c;v)
{
writeln( current n is ,b(c) );
}
}
void b(int n)
{
...//do someting for n
}
void main()
{
int n=1;
while(n=10_001)
{
v~=n;
n+=5000;
}
printf( Execution returned to calling context.\n );
ftread();
}
-end
I dont's think it's a good work.
How about you?
Thank you.
[Issue 14220] Bad codegen for optimized std.conv.text in combination with concatenation
https://issues.dlang.org/show_bug.cgi?id=14220 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- According to git-bisect this has been introduced with https://github.com/D-Programming-Language/dmd/pull/4408, so it is not in dmd 2.067 beta2. --
Re: Dutch D Meetup
On Monday, 23 February 2015 at 22:20:50 UTC, Arjan wrote: On Monday, 23 February 2015 at 21:07:04 UTC, George Sapkin wrote: Seems like there are some local meetups starting across the globe, but no Dutch one so far. Are there any D users from the Netherlands that would want to meetup and share their D stories? Cheers. I would surely come. Though have not really anything to share yet. I might be interested in something like this, but I also don't have any exciting stories to share to be honest...
Re: Memory safety depends entirely on GC ?
On Tuesday, 24 February 2015 at 12:44:54 UTC, Marc Schütz wrote: On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu wrote: On 2/23/15 6:56 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: These two points have undesirable consequences: All consumers such objects need to be aware of the exact type, which includes the management strategy (RC, Unique, GC). But this is a violation of the principle of separation of concerns: a consumer shouldn't need to have information about the management strategy, it should work equally with `RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it doesn't take ownership of the resource. Well I don't know of another way. Ok, I wrote my reply assuming that you are aware of the various proposals deadalnix, myself and several other people have made in the past, some of them quite specific. But now that I think of it, I don't remember that you were ever directly referring to it in any of your posts. Maybe you just missed it? As one example, here is what I originally suggested: http://wiki.dlang.org/User:Schuetzm/scope It's not completely up to date, during discussions I gained many useful new insights to simplify it and make things more consistent. It's also part of a bigger picture (deadalnix's ideas about ownership play an important role, too), which unfortunately isn't easy to recognize, because this page has become quite large und unwieldy. I should make a post explaining this. I'm working on my own idea now. I make scope transitive, because it's both memory safe and simple to implement, but doing so may cause some things which are actually safe to be considered unsafe (but then you could just use @system blocks or @trusted lambdas to correct this). Also, I don't think `scope` needs to be part of the type. I'm about 90 percent sure, 10 percent unsure that my system will work. I'll have it soon enough. It needs DIP25 to be expanded to all reference types (not just `ref`), requires my own DIP71, http://wiki.dlang.org/DIP71 for total safety, and possibly one or two more additions for a reliable ownership. The only real cost is added complexity to function signatures (a la DIP25), which can and should be inferred in most cases, assuming we aren't crippled by an ancient and subpar linking mechanism which requires all this manual marking of signatures all the time. Stay tuned, sir!
What is the state of D with Android/iOS
Is D currently mature enough to create binaries for android/iOS? I've been researching this, but most posts predate 2013, and I wanted to know what was the current status. D bindings for the JNI is certainly possible, so by extension it should be possible to call D libraries with Android's NDK, correct? Is is possible to write android apps purely in D similar to mono for android? http://developer.xamarin.com/guides/android/getting_started/hello,android/hello,android_quickstart/
Re: D GC theory
On Tuesday, 24 February 2015 at 00:30:43 UTC, ketmar wrote: On Mon, 23 Feb 2015 21:11:22 +, Sativa wrote: How hard would it be to modify D's GC to do the following two things: 1. Scan the heap in the BG on another thread/cpu for compactification. needs read/write barriers added to generated code. a major slowdown for ALL memory access. It's possible to (ab)use the MMU as a write barrier. Sociomantic's GC implementation does this by forking and running the scan in the child, then communicating information back about what can be freed. Video: http://dconf.org/talks/lucarella.html IIRC, at the end the speaker was asked about performance overhead of the COW that is involved, but he couldn't give any numbers.
Re: A Refcounted Array Type
On 2015-02-23 22:15:46 +, Walter Bright said: int* count; [...] if (count --*count == 0) [...] Careful! This isn't memory safe and you have to thank the GC for it. If you ever use RCArray as a member variable in a class, the RCArray destructor is going to be called from a random thread when the class destructor is run. If some thread has a stack reference to the array you have a race. You have to use an atomic counter unless you can prove the RCArray struct will never be put in a GC-managed context. It is rather sad that the language has no way to enforce such a restriction, and also that @safe cannot detect that this is a problem here. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 24 February 2015 at 13:07:38 UTC, Tobias Pankrath wrote: On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo Pinto wrote: Sorry about the caps, couldn't find a better way to emphasis. Not sure where you found out the information about x86, or why it should matter. I found an (apparently older) version of the documentation earlier that looked exactly the same, so I didn't mind to read your link carefully enough. The current collector is, by default, INCREMENTAL and GENERATIONAL. The interruptions of service should be very small, and the overall performance should be better than with the previous collectors. Yes, however from your page now: Now @M3novm is the default. And if you follow the link: @M3novm implies @M3noincremental and @M3nogenerational. Maybe, that's an documentation error. This was the place where the other version mentioned that x86 is not supported. While I like that you constantly remind us about achievements of older programming languages, you'll often do it with a that problem was solved in Language X 20 years ago-attitude, but almost never elaborate how that solution could be applied to D. When taking a closer look, I often find that those languages solved an similar but different problem and the solution do not apply to D at all. For example the last time in the discussion on separate compilation, templates and object files you blamed the C tool chain and pointed to pascal/delphi. But they didn't solved the problem, because they didn't faced it in the first place, because they didn't had the template and meta-programming capabilities of D. Yes I agree with you, it is just that I would like to see a language like D being adopted at large, so as a language geek that has spent too much time in language research during the compiler design classes, I like to pull this information out of the attic. When knowledge goes away people get other understanding of the reality, for example, many young developers think C was the very first systems programming language, which isn't the case given the research going on outside ATT. I am well aware that those solutions don't cover 100% D's use cases, but maybe they have enough juice to provide ideas in D context. It is always a matter of research and funding for the said ideas. If I was at academia, applying these ideas to improve D would be a good source for papers and thesis. As such, I cannot do much more than throw them over the wall and see if they can inspire someone. At the problem at hand: I don't see how Module3's distinction between system and default pointer types or the lessons they learned help in any way to improve the current D GC. It helps reduce the pressure in the GC allocated memory, and also allows for giving pointers straight to external code. Maybe given the type of implicit allocations in D vs Modula-3, it doesn't help. But yeah, too much noise from a D dabbler I guess. -- Paulo
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 24 February 2015 at 09:53:19 UTC, Walter Bright wrote: D has to be competitive in the most demanding environments. But isn't that exactly the point? Garbage collected D is NOT competitive in demanding environments. -Wyatt
Re: A Refcounted Array Type
On 2/24/15 3:14 AM, ponce wrote: Does DIP25 means we can turn resources into RC types and be done with non-deterministic destructor calls by the GC, without using RefCounted or Unique? That's what we're aiming for. -- Andrei
