Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote: This is going to sound really stupid... but do people actually use exceptions regularly? I'd say exception are exceptional in most code. That being said, unless the compiler can PROVE that no exception is gonna be thrown, you are stuck with having to generate a code path for unwinding that decrement the refcount. It means that you'll have code bloat (not that bad IMO, unless you are embeded) but more importantly, it means that most increment/decrement can't be optimized away in the regular path, as you must get the expected count in the unwinding path. Moreover, as you get some work to do on the unwind path, it becomes impossible to do various optimizations like tail calls. I think Walter is right when he says that switft dropped exception because of ARC. I've never used one. When I encounter code that does, I just find it really annoying to debug. I've never 'gotten' exceptions. I'm not sure why error codes are insufficient, other than the obvious fact that they hog the one sacred return value. Return error code have usually been an usability disaster for the simple reason that the do nothing behavior is to ignore the error. The second major problem is that you usually have no idea how where the error check is done, forcing the programmer to bubble up the error where it is meaningful to handle it. I'll agree though that this can't be changed at this point in the game. You say that's a terminal case? Generating code to properly implement a decrement chain during unwind impacts on the non-exceptional code path? Yes as you can't remove increment/decrement pairs as there are 2 decrement path (so there is pair). I agree. I would suggest if ARC were proven possible, we would like, switch. I'd like to see ARC support in D, but I do not think it makes sense as a default. 3. Memory safety is a requirement for any ARC proposal for D. Swift ignores memory safety concerns. What makes RC implicitly unsafe? Without ownership, one can leak reference to RCed object that the RC system do not see.
Re: Memory safety depends entirely on GC ?
On Monday, 23 February 2015 at 15:35:52 UTC, Ola Fosheim Grøstad wrote: If you do excessive refcounting (ARC) and care about performance you actually need to let the implementor of C decide where the RC_counter is embedded... C providing facility to be refcountable do not equate with C's user want refcounting. It means that if C's user want it to be refcounted, it is gonna be faster.
Re: Dgame revived
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.
Re: Memory safety depends entirely on GC ?
On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu
wrote:
That's not feasible. Code that assumes the class object will
live forever can simply do things that are not allowed to code
that must assume the object will go away at some determined
point. Consider this which I just posted:
class Widget
{
private char name[1024];
char[] getName() { return name[]; }
...
}
The typechecker must WHILE COMPILING WIDGET, NOT ITS CLIENT
know whether getName() is okay or not.
Let's use that exemple.
Well I don't know of another way.
I'm not sure if this is dishonest, but proposal has been made in
this newgroup, by various person,s including myself.
Let's get around the major concept.
name is owned by the widget instance (let's call it w). That
means its lifetime is the same as w's lifetime.
w's owner will provide its lifetime. If w's owner is the GC, then
its lifetime is infinite. if w's owner is some refounting system,
its lifetime is defined by when the refcounting system will
destroy it.
getName here assumes the lifetime of the object is infinite.
That's ok. It means you won't be able to call it when it is owned
by a RC system. If you want to be able to do so, you'll ned have
a way to specify the lifetime of the returned slice. For instance
:
class Widget {
private char name[1024];
scope(char[]) getName() scope { return name[]; }
...
}
In this case, you can call the method when w is owned by a RC
system, as it is now explicit to the caller that the lifetime of
what is returned and the compiler can ensure the slice do not
exceed its lifetime (ie w's lifetime).
This require to be able to express lifetime and preferably
ownership as well. So far, what I feel from you and Walter is the
will to not go into that direction and instead created a myriad
of hacks for various special cases. I do think this is wrong
headed and generally not the way forward. Languages should
provide the most generic and powerful tool so that interesting
schemes can be implemented on top of it.
Re: Stackless resumable functions
ahem. seems that you are right, and i outsmarted myself yet again. seems that my head is too small to keep three different task unmessed (forum discussion, plus two of my projects). sorry. If it's any consolation, I did accidentally use a C++ constructor in my first example.. I better sleep with one eye opened tonight ;)
Re: const member function
On Monday, February 23, 2015 09:12:33 rumbu via Digitalmars-d-learn wrote: On Saturday, 21 February 2015 at 15:26:28 UTC, ketmar wrote: On Sat, 21 Feb 2015 08:27:13 +, rumbu wrote: My question was not how I do this, I know already. My question was if there is another way to safely call a non-const instance function on a const object. is there a way to been safely hit by a truck? I thought if there is some language construct similar to @trusted for @safe, applicable to const member functions. You can be safely hit by a truck if I tell you that there is no truck around :) No. That wouldn't work at all because of immutable. A const method can be called on an immutable variable just as well as it can be called on a const or mutable one. In addition to that, Walter Bright feels very strongly that const should provide actual compiler guarantees, and when you have something like C++'s mutable which gives you a backdoor on const, the compiler can't really guarantee much of anything. @trusted has similar problems in that the programmer can screw it up and mark stuff as @trusted which makes the calling code unsafe, but that would be an actual bug in the program, whereas C++s mutable isn't a bug. Mutating const is perfectly acceptle in C++. It just doesn't work unless you tell the compiler to let you do it anyway, and the behavior is well-defined, whereas doing anything like casting away const and mutating a variable in D is undefined behavior, because the compiler is free to rely on const variables not changing so long as it can guarantee that a mutable reference to the same data can't have mutated that data. And yes, on some level, that sucks, because stuff like caching doesn't work with const, but it does mean that you can rely on const actually being const, which does provide other benefits. It does take some getting used to though. Regardless, the fact that we have immutable pretty much forces the issue - especially when you consider that the compiler can choose to put immutable variables in read-only-memory if it thinks that makes sense. - Jonathan M Davis
Re: Mac Apps That Use Garbage Collection Must Move to ARC
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. -- /Jacob Carlborg
Deprecation process documented?
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. -- /Jacob Carlborg
Re: Stackless resumable functions
On Tue, 24 Feb 2015 03:22:10 +, bitwise wrote: I think you're getting confused between stackless and stackful resumable functions. ahem. seems that you are right, and i outsmarted myself yet again. seems that my head is too small to keep three different task unmessed (forum discussion, plus two of my projects). sorry. signature.asc Description: PGP signature
Re: Is this a bug in dmd 2.067 for struct initializers?
On Sunday, February 22, 2015 17:45:48 Ali Çehreli via Digitalmars-d-learn wrote: On 02/22/2015 03:17 PM, Martin Nowak wrote: On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with static this() approach and it works. You should use shared static this to initialize immutable variables. Is that because they are not thread-local? If so, initializing the same variable in multiple 'static this()' blocks would indeed be a race condition. Very important... Yeah. It really should be illegal to initialize immutable variables in non-shared static constructors. https://issues.dlang.org/show_bug.cgi?id=4923 - Jonathan M Davis
Re: A Refcounted Array Type
On Monday, February 23, 2015 15:28:21 Andrei Alexandrescu via Digitalmars-d wrote: On 2/23/15 2:15 PM, Walter Bright wrote: This is pretty straightforward. [snip] The code builds if you slap a @safe: at the top. There is one bug in the compiler: delete must not be allowed in @safe code. The destructor must be @trusted. And delete is supposed to have been deprecated ages ago, but yeah, it _definitely_ shouldn't be considered @safe. - Jonathan M Davis
Re: Stackless resumable functions
you don't need to. if you really need to do that, you're doing
something
This makes no sense to me. A usage example may be helpful.
resumable functions are not iterators. it's a slightly
perversed flow
control method. iteration/generation is one of the use cases.
So how do you explain enumerators in C#, or generators in visual
c++?
and, by the way, yielding is a two-way communication channel.
http://www.boost.org/doc/libs/1_57_0/libs/coroutine/doc/html/index.html
[quote]
Coroutine
Asymmetric coroutine
Symmetric coroutine
[/quote]
you seem to stuck with iteration/generation idea, but this is
not the way resumable functions should be seen.
Not sure what to say to this..
mimicking delegates allows to use resumable function in any
code that expects delegate.
If you can come up with even one example(with code) where it
would make
sense to accept both coroutines and delegates, I will be very
surprised.
In any case, I have revised my design. Generator(T) was
redundant, so I removed it. Below is something that I think is
well formed enough for me to start digging through the compiler
for specifics.
interface MethodRange(T)
{
@property T front();
void popFront();
@property bool empty();
int opApply(int delegate(T) dg);
}
class __ResumeableMethod(T, METHOD_TYPE, CONTEXT_TYPE) :
MethodRange!T
{
// method locals and passed args
CONTEXT_TYPE* context;
// -initially contains method entry point
// -once executed, contains the resume address
// -when finished, contains null
void *fptr;
// object reference for instance methods
void *obj;
T value;
this(CONTEXT_TYPE* context, void *fptr, void *obj) {
this.context = context;
this.fptr = fptr;
this.obj = obj;
invoke(context, value);
}
private T invoke(CONTEXT_TYPE *context, T *yielded_value) {
fptr(context);
fptr = context-return_address;
if(fptr)
*yielded_value = context-yielded_value;
}
@property override T front() {
assert(!this.empty);
return value;
}
override void popFront() {
assert(!this.empty);
invoke(context, value);
}
@property override bool empty() {
return fptr == null;
}
int opApply(int delegate(T) dg)
{
while(!this.empty)
{
if(dg(this.front))
return 1;
}
return 0;
}
}
MethodRange!int myResumableMethod()
{
for(int i = 0; i 10; ++i)
yield i;
}
// the compiler would automatically transform the above
// method into something like the one below
MethodRange!int myResumableMethod()
{
void __method(__ContextFor__method *ctx)
{
for(ctx-i = 0; i 10; ++i)
{
ctx-yielded_value = i;
ctx-return_address = return_pos;
return;
return_pos:
}
ctx-return_address = null;
}
return new __ResumeableMethod!int(new __ContextFor__method,
__method, null);
}
// usage
void main()
{
foreach(num; myResumableMethod())
writeln(num);
// or
MethodRange!int[] methods;
auto mr = myResumableMethod();
if(!mr.empty)
methods ~= mr;
for(int i = 0; i methods.length; )
{
auto mr = methods[i];
int status = mr.front;
// handle item status..
mr.popFront();
if(mr.empty)
methods.remove(i);
else
++i;
}
}
Re: Let's Play Code Golf
On Monday, 23 February 2015 at 20:21:20 UTC, Charles wrote:
My solution (150 characters, 15 points):
void main(){import std.stdio;int t,n;readf(
%d,t);while(t--){readf( %d,n);real
a=0,i=0;for(;in;i++)a+=(i%2?-1:1)/(i+i+1);writefln(%.15f,a);}}
Link to problem site:
https://www.hackerrank.com/challenges/leibniz
Anyone care to do better? :)
126:
void main(){import std.stdio;real n,a;for(readln;a=0,readf(
%f,n);writefln(%.15f,a))while(--n=0)a+=(n%2?-1:1)/(n+n+1);}
[Issue 4650] Static data that must be scanned by the GC should be grouped
https://issues.dlang.org/show_bug.cgi?id=4650 --- Comment #8 from Rainer Schuetze r.sagita...@gmx.de --- Nice, so this is just moving strings/floats to a section that is not scanned at all? Or is it really grouping all the static data too? It's currently just strings and floats. I hope other const/immutable data can be moved, too. --
Re: Dgame revived
On Monday, 23 February 2015 at 16:03:47 UTC, Namespace wrote: load will pull in 1.1 functions only, nothing more. reload will load in whatever is supported by the current context. So if your context only supports 2.1, only functions up to 2.1 will be loaded. One of the earlier posts showed what needs to be done on Mac to get a 3.x context. In SDL, that means the following: ``` SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_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); Yes, that was my suggestion. But now where you confirm it, I'll add it. Added 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.
[Issue 14201] fatal error LNK1235: corrupt or invalid COFF symbol table
https://issues.dlang.org/show_bug.cgi?id=14201 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a1347b8ee62597ffe8714fef379d05334f6a4c70 Merge pull request #4443 from etcimon/coff-fix-cast Number high part right shift - Fix Issue 14201 --
Re: Dgame revived
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. Could you try it and say if it helps?
Re: A Refcounted Array Type
On 2/23/15 2:15 PM, Walter Bright wrote: This is pretty straightforward. [snip] The code builds if you slap a @safe: at the top. There is one bug in the compiler: delete must not be allowed in @safe code. The destructor must be @trusted. Understanding that this code (sans delete) is @safe (and the contribution of DIP25 to that) is of paramount importance. Making it possible to define @safe structs that are still able to return reference to their internals is crucial. It paves the way for truly safe reference counted classes. Andrei
[Issue 14199] [REG2.067a] Dwarf Error: mangled line number section
https://issues.dlang.org/show_bug.cgi?id=14199 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull CC||c...@dawg.eu --- Comment #2 from Martin Nowak c...@dawg.eu --- Thanks for reducing this. https://github.com/D-Programming-Language/dmd/pull/ --
