Started: Formal Review of std.serialization
Please discuss on official thread: http://forum.dlang.org/post/adyanbsdsxsfdpvoo...@forum.dlang.org This library is authored by Jacob Carlborg and has been around through the D1/Tango days.
Don's talk's video to be online soon
I'm experiencing trouble uploading the video of Don's talk, please bear with me. It will be available either later today or tomorrow morning. Sorry, Andrei
Re: Don's talk's video to be online soon
On Monday, 10 June 2013 at 18:59:22 UTC, Andrei Alexandrescu wrote: I'm experiencing trouble uploading the video of Don's talk, please bear with me. It will be available either later today or tomorrow morning. Sorry, Andrei Big thumbs up for your work :+1:
Re: Don's talk's video to be online soon
On Mon, 10 Jun 2013 14:59:22 -0400 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I'm experiencing trouble uploading the video of Don's talk, Too much awesomeness for the internet to handle?
Re: Don's talk's video to be online soon
On Monday, June 10, 2013 17:57:47 Nick Sabalausky wrote: On Mon, 10 Jun 2013 14:59:22 -0400 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I'm experiencing trouble uploading the video of Don's talk, Too much awesomeness for the internet to handle? Well, it _was_ a pretty awesome talk - probably my favorite. - Jonathan M Davis
Re: Don's talk's video to be online soon
On Monday, 10 June 2013 at 18:59:22 UTC, Andrei Alexandrescu wrote: I'm experiencing trouble uploading the video of Don's talk, please bear with me. It will be available either later today or tomorrow morning. Sorry, Andrei Will there be video for Andrew Edwards?
Re: Don's talk's video to be online soon
On Mon, 10 Jun 2013 19:19:20 -0400, Anthony Goins neonto...@gmail.com wrote: Will there be video for Andrew Edwards? IIRC, Andrew specifically requested not to be videotaped. I'm having trouble finding the link where that was stated. A shame too, he did a good job! -Steve
Re: Don's talk's video to be online soon
On 6/11/13, Steven Schveighoffer schvei...@yahoo.com wrote: On Mon, 10 Jun 2013 19:19:20 -0400, Anthony Goins neonto...@gmail.com wrote: Will there be video for Andrew Edwards? IIRC, Andrew specifically requested not to be videotaped. I'm having trouble finding the link where that was stated. A shame too, he did a good job! What about the slides, will they be available? Otherwise a couple of brief sentences on what he was talking about would be cool (unless those are secret too :p)
Re: Don's talk's video to be online soon
On 6/10/2013 4:19 PM, Anthony Goins wrote: Will there be video for Andrew Edwards? Andrew declined to have it videotaped, so no.
Re: Don's talk's video to be online soon
On 6/10/13 7:19 PM, Anthony Goins wrote: On Monday, 10 June 2013 at 18:59:22 UTC, Andrei Alexandrescu wrote: I'm experiencing trouble uploading the video of Don's talk, please bear with me. It will be available either later today or tomorrow morning. Sorry, Andrei Will there be video for Andrew Edwards? Andrew requested that his talk isn't recorded. Andrei
Re: Don's talk's video to be online soon
On 6/10/13 5:02 PM, Andrei Alexandrescu wrote: On 6/10/13 7:19 PM, Anthony Goins wrote: On Monday, 10 June 2013 at 18:59:22 UTC, Andrei Alexandrescu wrote: I'm experiencing trouble uploading the video of Don's talk, please bear with me. It will be available either later today or tomorrow morning. Sorry, Andrei Will there be video for Andrew Edwards? Andrew requested that his talk isn't recorded. Andrei Really? That's the one talk I wasn't in the room for and wanted to see. Sigh.
Re: LDC 0.11.0 has been released!
On Sunday, 9 June 2013 at 16:32:55 UTC, Andrei Alexandrescu wrote: Any ETA for 0.12.0 built with 2.063's frontend? Not really – if I don't get a first beta of the next version out in the next few days, it will unfortunately take *much* longer (exams mid/end August, need to prepare). Currently working on removing some the most intrusive LLVM-specific changes from the code base, though. We should have worked on reducing that legacy technical debt anyway, as is costing us at every new frontend merge, but there is some funky business going on with CTFE in 2.063 pretty much holding up any further work. David
Re: Installing vibe via DUB
On Sun, 2013-06-09 at 18:37 -0700, Jonathan M Davis wrote: […] I believe that this is the correct place to ask: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ […] I am in the camp of forum hater which I know means 50% of people hate me, but… if stuff doesn't arrive in my email it doesn't exist. I am assuming that although VibeNews behaves as an NNTP newsgroup as well as a classic Web-based forum, it doesn't support SMTP mail interaction. Perhaps this could be an evolution? Perhaps then the infrastructure could be used for all D activity as a dog fooding activity? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: DMD 2.063 produces broken binaries
Andrei Alexandrescu seewebsiteforem...@erdani.org writes: On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH to make sure there's no stray reference to an old libphobos.a dir. LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry
Re: Phobos Review Queue
On 2013-06-08 02:11, Jesse Phillips wrote: I had contacted Jacob (std.serialize), but he said that he wouldn't be available this week so I haven't made an announcement. I'm available now. -- /Jacob Carlborg
Re: Member function pointers
On 2013-06-08 01:21, Manu wrote: So from my dconf talk, I detailed a nasty hack to handle member function pointers in D. My approach is not portable, so I'd like to see an expression formalised in D, so this sort of interaction with C++ is possible, and also it may be useful in D code directly. I'm thinking something like this... Keen to hear thoughts. My approach was this: void function(T _this, ...args...); Explicit 'this' pointer; only works with ABI's that pass 'this' as the first integer argument. What I suggest is: void function(T this, ...args...); Note, I use keyword 'this' as the first argument. This is the key that distinguishes the expression as a member-function pointer rather than a typical function pointer. Calls through this function pointer would know to use the method calling convention rather than the static function calling convention. For 'extern(C++) void function(T this)', that would be to use the C++ 'thiscall' convention. I think this makes good sense, because other than the choice of calling convention, it really is just a 'function' in every other way. Can't we just say that a delegate declared as extern(C++) is a member function? Or do you want to use member functions without connecting to C++ as well? -- /Jacob Carlborg
Re: about with statement
On 2013-06-09 20:09, deadalnix wrote:
switch(foobar) with(FoobarEnum) {
// ...
}
That is golden !
I agree, that's basically the only case I've used with for.
--
/Jacob Carlborg
Re: std.compress
On 2013-06-10 05:40, bearophile wrote: The ldc2 compiler has this switch: -check-printf-calls - Validate printf call format strings against arguments Cool, I didn't know that. -- /Jacob Carlborg
Re: std.compress
On 2013-06-10 04:33, Andrei Alexandrescu wrote:
Guys, they're function local vars. A comment would suffice.
That doesn't mean the names should be less understandable. We're writing
open source here. I think most names should be named as if they were
part of the public API.
It also depends on in what context they are used. Example, in DMD there
are a lot of functions containing probably more the 500 lines of code
with variable names with only one letter, declared at the top of the
function. If you instead have a function with only five or ten lines of
code it could be ok:
private void foo (ProductInformation pi) { // five lines of code }
I would think the above would be ok. But it should definitely not be
used in documentation/examples as I see it is now.
BTW, I hate using comments for that. Comments should basically only be
used for writing API documentation. Most times, if you want to add a
comment your code is probably not clear enough.
--
/Jacob Carlborg
Re: Member function pointers
On 10 June 2013 16:50, Jacob Carlborg d...@me.com wrote: On 2013-06-08 01:21, Manu wrote: So from my dconf talk, I detailed a nasty hack to handle member function pointers in D. My approach is not portable, so I'd like to see an expression formalised in D, so this sort of interaction with C++ is possible, and also it may be useful in D code directly. I'm thinking something like this... Keen to hear thoughts. My approach was this: void function(T _this, ...args...); Explicit 'this' pointer; only works with ABI's that pass 'this' as the first integer argument. What I suggest is: void function(T this, ...args...); Note, I use keyword 'this' as the first argument. This is the key that distinguishes the expression as a member-function pointer rather than a typical function pointer. Calls through this function pointer would know to use the method calling convention rather than the static function calling convention. For 'extern(C++) void function(T this)', that would be to use the C++ 'thiscall' convention. I think this makes good sense, because other than the choice of calling convention, it really is just a 'function' in every other way. Can't we just say that a delegate declared as extern(C++) is a member function? That seems pretty awkward to me. Basically a hack. A function pointer is not a delegate, so I don't see why that should be used to describe one. Also, extern(C++) delegates are useful too in their own right Or do you want to use member functions without connecting to C++ as well? I haven't needed to yet... but that doesn't mean it might not be useful. It would probably be used in D for tight binding with other systems. AngelScript binds to native code with member function pointers... just off the top of my head.
Re: std.compress
On 6/10/2013 12:13 AM, Jacob Carlborg wrote: Most times, if you want to add a comment your code is probably not clear enough. There's no way to put the why in code.
Re: std.compress
On Monday, 10 June 2013 at 07:13:49 UTC, Jacob Carlborg wrote: On 2013-06-10 04:33, Andrei Alexandrescu wrote: Guys, they're function local vars. A comment would suffice. That doesn't mean the names should be less understandable. We're writing open source here. I think most names should be named as if they were part of the public API. I object to your use of the name API. Please use the more understandable Application Programming Interface in future. :-) /joke The point is that there is value in terseness. That's what abbreviations are for. If you are to refer to Application Programming Interface multiple times then it can make text more understandable to abbreviate it (as you have). Reducing the size of identifiers allows the reader to more clearly see the meaning of the text. The same is true in code. Compare: solution = (-firstCoefficient + squareRoot(secondCoefficient * secondCoefficient - 4 * firstCoefficient * thirdCoefficient) / (2 * firstCoefficient); to // a, b, c - coefficients // x - solution x = (-b + sqrt(b*b - 4*a*c)) / (2 * a);
Re: Member function pointers
On 2013-06-10 09:23, Manu wrote: That seems pretty awkward to me. Basically a hack. A function pointer is not a delegate, so I don't see why that should be used to describe one. It depends on how you look at it. In D a delegate is a function pointer with a context pointer. In C++ a pointer to a member function is basically the same, the context pointer is just passed separately. Also, extern(C++) delegates are useful too in their own right To do what? As far as I know C++ doesn't have anything corresponding to a D delegate. I haven't needed to yet... but that doesn't mean it might not be useful. It would probably be used in D for tight binding with other systems. AngelScript binds to native code with member function pointers... just off the top of my head. Actually I don't see why you can't use a delegate for this. The only difference is that it won't be virtual. -- /Jacob Carlborg
Re: std.compress
On 2013-06-10 09:35, Walter Bright wrote: There's no way to put the why in code. That's why I said Most times and not always. As with everything, there are exceptions. -- /Jacob Carlborg
Re: std.compress
On 2013-06-10 09:57, Peter Alexander wrote: I object to your use of the name API. Please use the more understandable Application Programming Interface in future. :-) /joke Some are abbreviations are commonly know. In the programming world API is one of them. FTP and HTTP are other examples. I would say that di and si are not. The point is that there is value in terseness. That's what abbreviations are for. If you are to refer to Application Programming Interface multiple times then it can make text more understandable to abbreviate it (as you have). Reducing the size of identifiers allows the reader to more clearly see the meaning of the text. The same is true in code. Compare: solution = (-firstCoefficient + squareRoot(secondCoefficient * secondCoefficient - 4 * firstCoefficient * thirdCoefficient) / (2 * firstCoefficient); to // a, b, c - coefficients // x - solution x = (-b + sqrt(b*b - 4*a*c)) / (2 * a); If that code is in its own function, I would say it's ok. If that piece of code is mixed in a function with over 500 lines of code and the variables are declared at the top, I would say it's very bad style. -- /Jacob Carlborg
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 06:41:39 UTC, Jerry wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org writes: On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH to make sure there's no stray reference to an old libphobos.a dir. LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry I can't reproduce this anywhere. What's the output for these: gcc --version ldd --version Also, check for any stray installations or config files: find /usr /etc /opt /home/$(whoami) -name \*phobos\* -o -name \*druntime\* -o -name dmd\* 2/dev/null Be warned that will take a while (a few minutes on my machine). Also, and I know this sounds stupidly simple, but have to tried re-downloading?
Re: builtin sort
On Saturday, 8 June 2013 at 22:51:06 UTC, bearophile wrote: Peter Williams: Rather than deprecate it why not fix it? Shouldn't have to import std.algorithm just to sort an array. Generally you want to keep the compiler (all its layers) as simpler as possible, to make it simpler to compile, debug and develop. A sort is implementable very well in library code. Other things, like tuples with a good syntax maybe can't be implemented well in library code, so they should be in the compiler :) I suggest to kill the built-in sort ASAP. Bye, bearophile I agree. Do people have the same opinion on the builtin reverse? I don't remember whether there was a discussion about this. I suggest to kill that as well. sort and reverse are perfectly well implemented in the standard library rather than builtin. Is anyone actually on this? I could try to dig into it, I guess I could start looking for spurious places in phobos and druntime where these builtin functions are used and replace them with the library ones. If we deprecate it in the end we don't want to see it being used anywhere in the standard implementations. Stephan
Re: builtin sort
I have opened this issue: http://d.puremagic.com/issues/show_bug.cgi?id=10318 Bye, bearophile
Re: implicit template constraint notation
Timothee Cour:
A)
I'd like to simplify notation of template function declarations
involving
only single-argument boolean template constraints as follows:
example:
A1: 'auto myfunction ( isSomeString a, isInputRange b) {...}'
would be rewritten by compiler as:
A2: 'auto myfunction(T0,T1) (T0 a, T1 b) if(isSomeString!T1 a
isInputRange!T b) {...}'
IMO, A1 is less verbose and clearer than A2.
Obviously, more complex template constraints would still
require the full
syntax, but I'd argue this case is the most common.
See:
http://forum.dlang.org/thread/xaganckgcdkfcmjam...@forum.dlang.org
B)
Secondly, ddoc doesn't generate template constraints or does so
very
inconsistently :
in http://dlang.org/phobos/std_algorithm.html we have:
template map(fun...) if (fun.length = 1);
but all other template constraints are omitted, eg:
void fill(Range, Value)(Range range, Value filler); // template
constraint
omitted.
Using the notation proposed in A, wherever applicable, would
make documentation clear.
That sounds like a bug report for bugzilla.
Bye,
bearophile
Re: Downgrading ranges
On Sunday, 9 June 2013 at 12:19:47 UTC, Lars T. Kyllingstad wrote:
A recent pull request discussion got me thinking: The ability
to downgrade a range to a less featureful one -- wrapping a
random access range in an input range, say -- can be very
useful sometimes, particularly for testing. The pull request
in question was Walter's LZ77 module,
[...]
One solution which has come up in the aforementioned pull request
discussion (thanks to Daniel Murphy) is to downcast the result of
std.range.inputRangeObject() to the desired interface.
Intf!(ElementEncodingType!R) downgrade(alias Intf, R)(R rng)
{
return inputRangeObject(rng);
}
auto someInputRange = downgrade!InputRange(someRandAccRange);
Maybe this is good enough for testing purposes?
Re: about with statement
Am Sun, 09 Jun 2013 16:48:39 -0700
schrieb Ali Çehreli acehr...@yahoo.com:
switch(foobar) with(FoobarEnum) {
// ...
}
That is golden !
+1000 :o)
To me, 'with' is useful only in that _case_.
Pun intended?
I even remember someone being surprised that it had other uses
than this one, but I couldn't find the post.
switch(foobar : FoobarEnum) {} ? :p
--
Marco
Re: Member function pointers
On 10 June 2013 18:04, Jacob Carlborg d...@me.com wrote: On 2013-06-10 09:23, Manu wrote: That seems pretty awkward to me. Basically a hack. A function pointer is not a delegate, so I don't see why that should be used to describe one. It depends on how you look at it. In D a delegate is a function pointer with a context pointer. In C++ a pointer to a member function is basically the same, the context pointer is just passed separately. A function pointer is a pointer. A delegate is a pointer to a function and a context pointer, ie, 2 pointers. A pointer to a method is just a pointer to a function, but it's a special function which receives a 'this' argument with a special calling convention. It's definitely useful to be able to express a 'thiscall' function pointer. Also, extern(C++) delegates are useful too in their own right To do what? As far as I know C++ doesn't have anything corresponding to a D delegate. C++ has FastDelegate, which I use to interact with D delegates all the time! ;) extern(C++) delegate is required to specify the appropriate calling convention, otherwise it's just a delegate like usual. I haven't needed to yet... but that doesn't mean it might not be useful. It would probably be used in D for tight binding with other systems. AngelScript binds to native code with member function pointers... just off the top of my head. Actually I don't see why you can't use a delegate for this. The only difference is that it won't be virtual. I'm just trying to show that sometimes you don't want a delegate, you just want a function pointer. delegate's contain the function pointer I'm after, so I can access it indirectly, but it's just not so useful. It's not typed (is void*), and you can't call through it.
Re: builtin sort
On 2013-06-10 11:03, Stephan Schiffels wrote: I agree. Do people have the same opinion on the builtin reverse? I don't remember whether there was a discussion about this. I suggest to kill that as well. sort and reverse are perfectly well implemented in the standard library rather than builtin. reverse is implemented with the stupid name retro. Is anyone actually on this? I could try to dig into it, I guess I could start looking for spurious places in phobos and druntime where these builtin functions are used and replace them with the library ones. If we deprecate it in the end we don't want to see it being used anywhere in the standard implementations. Perhaps start with modifying the compiler to indicate the sort and reverse functions are deprecated. Then it will be easier to find in Phobos and druntime. Also, if used in druntime they need to be reimplemented there. -- /Jacob Carlborg
Re: builtin sort
Jacob Carlborg: reverse is implemented with the stupid name retro. Nope. retro is a lazy range that yields in reverse direction. The Phobos in-place reverse for arrays is named reverse. But unlike the built-in reverse returns void. Perhaps start with modifying the compiler to indicate the sort and reverse functions are deprecated. The first step for Issue 10318 is indeed a warning for usage of the built-in sort. Bye, bearophile
Re: Member function pointers
On 2013-06-10 11:45, Manu wrote:
A function pointer is a pointer. A delegate is a pointer to a function
and a context pointer, ie, 2 pointers.
A pointer to a method is just a pointer to a function, but it's a
special function which receives a 'this' argument with a special calling
convention.
It's definitely useful to be able to express a 'thiscall' function pointer.
It's not very useful without the context pointer, i.e. this.
Also, extern(C++) delegates are useful too in their own right
To do what? As far as I know C++ doesn't have anything corresponding
to a D delegate.
C++ has FastDelegate, which I use to interact with D delegates all the
time! ;)
I didn't know about that. Is that something that is in the language or
standard library?
extern(C++) delegate is required to specify the appropriate calling
convention, otherwise it's just a delegate like usual.
I see.
I'm just trying to show that sometimes you don't want a delegate, you
just want a function pointer.
Then use a function pointer.
delegate's contain the function pointer I'm after, so I can access it
indirectly, but it's just not so useful. It's not typed (is void*), and
you can't call through it.
The function pointer of a delegate is typed, it's the context pointer
that is void*.
Sorry, I'm just trying to understand what you're doing, what problems
you have. You can compose and decompose delegates using its built-in
properties ptr and funcptr.
You can do something like:
class Foo
{
int i;
void a () { writeln(Foo.a i=, i); }
void b () { writeln(Foo.b i=, i); }
}
void main ()
{
auto f1 = new Foo;
f1.i = 3;
auto dg = f1.a;
dg();
auto f2 = new Foo;
f2.i = 4;
dg.ptr = cast(void*) f2;
dg();
dg.funcptr = Foo.b;
dg();
}
The only thing that doesn't work with the above is if I change the
context pointer to a subclass of Foo which overrides the method I want
to call. It will still call the method in Foo unless I change funcptr.
--
/Jacob Carlborg
Re: Member function pointers
On 2013-06-10 08:04:43 +, Jacob Carlborg d...@me.com said: On 2013-06-10 09:23, Manu wrote: That seems pretty awkward to me. Basically a hack. A function pointer is not a delegate, so I don't see why that should be used to describe one. It depends on how you look at it. In D a delegate is a function pointer with a context pointer. In C++ a pointer to a member function is basically the same, the context pointer is just passed separately. But a true member function pointer is also parametrized on the type of this, unlike a delegate, letting you change the object pointer in a type-safe manner. (And implementation-wise, C++ function pointers can be really complicated beasts in order to support virtual calling and multiple/virtual inheritance. sizeof can even change depending on the type of this. That's not what you want in D.) I haven't needed to yet... but that doesn't mean it might not be useful. It would probably be used in D for tight binding with other systems. AngelScript binds to native code with member function pointers... just off the top of my head. Actually I don't see why you can't use a delegate for this. The only difference is that it won't be virtual. Type-safety. I mean, you can do this if you want: auto funcptr = Object.toString; auto object = new Object; // now call our function using object string delegate() deleg; deleg.ptr = cast(void*)object; deleg.funcptr = funcptr; but this is not type-safe: the funcptr type (string function()) is actually wrong (it'll only work if called from a delegate) and the object pointer the in the delegate is a void*. All Manu is asking is that funcptr is of a correct type so you can call it directly by supplying this as an argument, like this: funcptr(object); The problem is that this correct type for the function pointer does not exist currently. Calling a member function uses a different ABI, so the type needs to know somehow its a pointer to a member function (and that its first parameter is this), otherwise the generated code at the call site will be all wrong. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: Member function pointers
On 10 June 2013 21:35, Jacob Carlborg d...@me.com wrote:
On 2013-06-10 11:45, Manu wrote:
A function pointer is a pointer. A delegate is a pointer to a function
and a context pointer, ie, 2 pointers.
A pointer to a method is just a pointer to a function, but it's a
special function which receives a 'this' argument with a special calling
convention.
It's definitely useful to be able to express a 'thiscall' function
pointer.
It's not very useful without the context pointer, i.e. this.
You supply 'this' at the time of calling. Read my OP.
Also, extern(C++) delegates are useful too in their own right
To do what? As far as I know C++ doesn't have anything corresponding
to a D delegate.
C++ has FastDelegate, which I use to interact with D delegates all the
time! ;)
I didn't know about that. Is that something that is in the language or
standard library?
It's Don's work of art. It's also how I came to find out about D in the
first place ;)
extern(C++) delegate is required to specify the appropriate calling
convention, otherwise it's just a delegate like usual.
I see.
I'm just trying to show that sometimes you don't want a delegate, you
just want a function pointer.
Then use a function pointer.
There's no way to specify to use the 'thiscall' calling convention.
What I propose is a syntax that would describe a member function pointer,
and imply the appropriate calling convention.
delegate's contain the function pointer I'm after, so I can access it
indirectly, but it's just not so useful. It's not typed (is void*), and
you can't call through it.
The function pointer of a delegate is typed, it's the context pointer that
is void*.
Sorry, I'm just trying to understand what you're doing, what problems you
have. You can compose and decompose delegates using its built-in properties
ptr and funcptr.
You can do something like:
class Foo
{
int i;
void a () { writeln(Foo.a i=, i); }
void b () { writeln(Foo.b i=, i); }
}
void main ()
{
auto f1 = new Foo;
f1.i = 3;
auto dg = f1.a;
dg();
auto f2 = new Foo;
f2.i = 4;
dg.ptr = cast(void*) f2;
dg();
dg.funcptr = Foo.b;
dg();
}
The only thing that doesn't work with the above is if I change the context
pointer to a subclass of Foo which overrides the method I want to call. It
will still call the method in Foo unless I change funcptr.
I wouldn't say that doesn't work, I'd say that works perfectly. A delegate
is just a 'this' and function pair. If you change 'this', there's no reason
the function should change.
funcptr pretends to be typed, but the type is just wrong. In your example,
the type is 'void function()', it should be 'void function(Foo this)'.
So it's actually a lie. You can't call it. I'm not sure why it's typed at
all... just a crash waiting to happen.
So what I'm suggesting is a syntax to express a member function pointer,
and then it could be properly typed.
Re: Member function pointers
On 2013-06-10 14:36, Manu wrote: You supply 'this' at the time of calling. Read my OP. Yes, exactly. It needs this. It's the same thing as a delegate. It's just that with the delegate the context pointer and function pointer is combined. A function pointer (member or free) is useless if it's not called. It's Don's work of art. It's also how I came to find out about D in the first place ;) I see. There's no way to specify to use the 'thiscall' calling convention. What I propose is a syntax that would describe a member function pointer, and imply the appropriate calling convention. Right. I suggested a different syntax, but you want to reserve that syntax for something that match a library implementation, that's not even in the standard. It's like saying I want int[] to match MyIntArray implemented in C++. funcptr pretends to be typed, but the type is just wrong. In your example, the type is 'void function()', it should be 'void function(Foo this)'. void function() is part of the complete type. It becomes complete with the context pointer. So it's actually a lie. You can't call it. I'm not sure why it's typed at all... just a crash waiting to happen. You can put a free function in a delegate and call it through the delegate. I guess you don't want that to be possible either. So what I'm suggesting is a syntax to express a member function pointer, and then it could be properly typed. I don't think there's anything wrong with supporting C++ member function pointers but I don't think we need to add new syntax for it. -- /Jacob Carlborg
Re: Member function pointers
On 2013-06-10 14:32, Michel Fortin wrote: Type-safety. I mean, you can do this if you want: auto funcptr = Object.toString; auto object = new Object; // now call our function using object string delegate() deleg; deleg.ptr = cast(void*)object; deleg.funcptr = funcptr; but this is not type-safe: the funcptr type (string function()) is actually wrong (it'll only work if called from a delegate) and the object pointer the in the delegate is a void*. All Manu is asking is that funcptr is of a correct type so you can call it directly by supplying this as an argument, like this: funcptr(object); The problem is that this correct type for the function pointer does not exist currently. Calling a member function uses a different ABI, so the type needs to know somehow its a pointer to a member function (and that its first parameter is this), otherwise the generated code at the call site will be all wrong. Then he's asking for (more) type safe delegates and support for C++ member function pointers. -- /Jacob Carlborg
Re: Member function pointers
08-Jun-2013 03:21, Manu пишет:
So from my dconf talk, I detailed a nasty hack to handle member function
pointers in D.
My approach is not portable, so I'd like to see an expression formalised
in D, so this sort of interaction with C++ is possible, and also it may
be useful in D code directly.
I'm thinking something like this... Keen to hear thoughts.
My approach was this:
void function(T _this, ...args...);
Explicit 'this' pointer; only works with ABI's that pass 'this' as the
first integer argument.
I decided to see how convenient can be a solution to auto-generate a
thunk function that has exactly this signutre. In ABIs where this is
passed as first parameters that shouldn't be much of overhead.
Here is my first try, it needs to handle overload sets but that could be
added. Second point is perfect forwarding (there is forward in
std.typecons, avoided for now). It may as well depend on compiler bugs
but it looks nice and clean :)
module mem_fun;
import std.traits, std.stdio;
template memThunk(string call, T, U...)
if(is(T == class))
{
auto memThunk(T self, U args)
{
return mixin(self. ~ call~(args));
}
}
struct memberFunc(T)
if(is(T == class))
{
static @property auto opDispatch(string fn)()
{
alias FnType = typeof(mixin(T.~fn));
return memThunk!(fn, T, ParameterTypeTuple!FnType);
}
}
class A{
void foo(int k)
{
writefln(Quack %d!\n, k);
}
}
unittest
{
void function (A, int) fun = memberFunc!A.foo;
A a = new A();
fun(a, 45); //prints Quack 45!
}
P.S. Having a way to express this-call calling convention explicitly
could be very useful still especially taking into account recent
enhancements to the extern(C++) support.
--
Dmitry Olshansky
Re: Member function pointers
On Monday, 10 June 2013 at 12:53:34 UTC, Jacob Carlborg wrote: On 2013-06-10 14:36, Manu wrote: funcptr pretends to be typed, but the type is just wrong. In your example, the type is 'void function()', it should be 'void function(Foo this)'. void function() is part of the complete type. It becomes complete with the context pointer. I wouldn't say so. The fact that you pass context has nothing to do with determining type. For example, you can pass A class instead of B to B method, but B method would still keep its original type. So yes, there is a type problem in language when function taking some parameter is declared as having no such parameter. This is a serious hole in type system.
Re: about with statement
On Sunday, 9 June 2013 at 10:11:25 UTC, khurshid wrote:
D language have like Pascal/Delphi with statement, which
very useful for writing readable code.
http://dlang.org/statement.html#WithStatement
Maybe I'm wrong, but, I never saw where using this statement
in phobos source codes, what problem using this statement?
Regards,
Khurshid.
Am I the only one that found this useful?
Is there a better way?
with (specificModule)
{
result = ufcsChain.ambiguousFunction.link3();
}
Re: about with statement
09.06.2013 14:11, khurshid пишет: D language have like Pascal/Delphi with statement, which very useful for writing readable code. http://dlang.org/statement.html#WithStatement Maybe I'm wrong, but, I never saw where using this statement in phobos source codes, what problem using this statement? Note, that for now you can't instantiate templates in with statement, see Issue 6196 [1]. [1] http://d.puremagic.com/issues/show_bug.cgi?id=6196 -- Денис В. Шеломовский Denis V. Shelomovskij
Re: DMD 2.063 produces broken binaries
On 6/10/13 2:41 AM, Jerry wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org writes: On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH to make sure there's no stray reference to an old libphobos.a dir. LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry Appreciate the work. (BTW nice to see you again, recall we talked at that NLP conference a while back.) Let's focus on Ubuntu/64 because that's what I have on my end too. 1. Which Ubuntu version are you using? 2. Can you compile and run hello, world in C? 3. If you replace the D call to writeln() with a call to printf(), does that work? 4. If you make any other calls into the stdlib aside from I/O, do they work? 5. Does gdb reveal anything interesting? Andrei
Re: Member function pointers
On 10 June 2013 22:53, Jacob Carlborg d...@me.com wrote: On 2013-06-10 14:36, Manu wrote: You supply 'this' at the time of calling. Read my OP. Yes, exactly. It needs this. It's the same thing as a delegate. It's just that with the delegate the context pointer and function pointer is combined. A function pointer (member or free) is useless if it's not called. It's Don's work of art. It's also how I came to find out about D in the first place ;) I see. There's no way to specify to use the 'thiscall' calling convention. What I propose is a syntax that would describe a member function pointer, and imply the appropriate calling convention. Right. I suggested a different syntax, but you want to reserve that syntax for something that match a library implementation, that's not even in the standard. It's like saying I want int[] to match MyIntArray implemented in C++. No, I'm not talking about delegates. I'm not talking about FastDelegate (that was an aside when you commented that C++ has no concept of delegate). I'm just talking about function pointers. Not sure where you get this analogy from? funcptr pretends to be typed, but the type is just wrong. In your example, the type is 'void function()', it should be 'void function(Foo this)'. void function() is part of the complete type. It becomes complete with the context pointer. The context pointer type is not present in the type. So the function can't be used/called. It also doesn't know how to call it. What's the calling convention for 'void function()'? cdecl? So it's actually a lie. You can't call it. I'm not sure why it's typed at all... just a crash waiting to happen. You can put a free function in a delegate and call it through the delegate. I guess you don't want that to be possible either. A free function? Like a static function? You can assign it, but it'll crash. Free functions are cdecl, methods are thiscall. If you know the ABI and it receives 'this' as the first integer argument, you can fabricate a compatible signature and it won't crash, but it's not portable. This is my whole point about the type-safety. If we create an expression to describe a method pointer, then we can actually do it safely and portably. So what I'm suggesting is a syntax to express a member function pointer, and then it could be properly typed. I don't think there's anything wrong with supporting C++ member function pointers but I don't think we need to add new syntax for it. I'm not suggesting supporting 'C++ member function pointers', they are completely bat-shit crazy. I'm suggesting a distinctly D way. They will be useful when interfacing C++, and also on their own, and unlike C++, they won't be totally mental.
Re: Member function pointers
On 10 June 2013 22:56, Jacob Carlborg d...@me.com wrote: On 2013-06-10 14:32, Michel Fortin wrote: Type-safety. I mean, you can do this if you want: auto funcptr = Object.toString; auto object = new Object; // now call our function using object string delegate() deleg; deleg.ptr = cast(void*)object; deleg.funcptr = funcptr; but this is not type-safe: the funcptr type (string function()) is actually wrong (it'll only work if called from a delegate) and the object pointer the in the delegate is a void*. All Manu is asking is that funcptr is of a correct type so you can call it directly by supplying this as an argument, like this: funcptr(object); The problem is that this correct type for the function pointer does not exist currently. Calling a member function uses a different ABI, so the type needs to know somehow its a pointer to a member function (and that its first parameter is this), otherwise the generated code at the call site will be all wrong. Then he's asking for (more) type safe delegates and support for C++ member function pointers. I'm really not asking for delegates (although they could become more typesafe given my suggestion), just a member function pointer. And not C++ style as you say, my suggestion is much simpler than that, and would fit nicely in D.
Re: Member function pointers
On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote: I think this makes good sense, because other than the choice of calling convention, it really is just a 'function' in every other way. Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer. David
Re: Member function pointers
On Monday, 10 June 2013 at 13:45:37 UTC, Manu wrote: What's the calling convention for 'void function()'? cdecl? Walter's very own calling convention. It is supposed to match cdecl everywhere but x86, but has the argument order reversed. On x86, it's a custom one that's similar to stdcall in some ways. David
Re: Member function pointers
On 10 June 2013 23:49, David Nadlinger c...@klickverbot.at wrote: On Monday, 10 June 2013 at 13:45:37 UTC, Manu wrote: What's the calling convention for 'void function()'? cdecl? Walter's very own calling convention. It is supposed to match cdecl everywhere but x86, but has the argument order reversed. On x86, it's a custom one that's similar to stdcall in some ways. Indeed. I presume 'extern(C) void function()' is cdecl though? Likewise 'extern(C++) void function(T this)' would be 'thiscall', and 'void function(T this)' would be whatever D's method calling convention happens to be.
Re: Member function pointers
On 10 June 2013 23:46, David Nadlinger c...@klickverbot.at wrote: On Friday, 7 June 2013 at 23:22:03 UTC, Manu wrote: I think this makes good sense, because other than the choice of calling convention, it really is just a 'function' in every other way. Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer. That would also do the business. Do you think that's less intrusive? It feels a little hacky though. 'DThisCall' isn't really 'extern' so to speak. I like my suggestion a lot more. Little details like, what would you name the 'this' argument? You'll end up with conventions like 'void function(T _this)', and that's a bit untrue because there isn't an argument named '_this', it's called 'this' inside the method.
Re: Member function pointers
On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote: On 10 June 2013 23:46, David Nadlinger c...@klickverbot.at Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer. That would also do the business. Do you think that's less intrusive? Less intrusive in the way that it is a minimal addition to the language itself (we already have several calling conventions), whereas your suggestion would require adding a special case to the grammar. That's not to say I don't like your proposal, though. I just wanted to put the option on the table to be sure we are getting somewhere with this, even if some people might be opposed to the grammar change. This issue has been bugging me for quite some time as well. It feels a little hacky though. 'DThisCall' isn't really 'extern' so to speak. extern(D) exists today – extern(xyz) should really be called abi(xyz), callingconv(xyz) or something like that instead. David
Re: Member function pointers
On 11 June 2013 00:28, Michel Fortin michel.for...@michelf.ca wrote: On 2013-06-10 14:11:31 +, David Nadlinger c...@klickverbot.at said: On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote: On 10 June 2013 23:46, David Nadlinger c...@klickverbot.at Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer. That would also do the business. Do you think that's less intrusive? Less intrusive in the way that it is a minimal addition to the language itself (we already have several calling conventions), whereas your suggestion would require adding a special case to the grammar. That's not to say I don't like your proposal, though. I just wanted to put the option on the table to be sure we are getting somewhere with this, even if some people might be opposed to the grammar change. This issue has been bugging me for quite some time as well. It's inelegant, but it could work. I just find it sad that we have to use a different calling convention for member functions. I mean, it'd be much more elegant be if a member function could simply be called from a void function(Object) by supplying this as the first argument? Wouldn't it be better to adapt the ABI to fit the language rather than adapt the language to fit the ABI? The ABI is the better part of half a century old...
Re: Member function pointers
On 2013-06-10 14:11:31 +, David Nadlinger c...@klickverbot.at said: On Monday, 10 June 2013 at 14:04:29 UTC, Manu wrote: On 10 June 2013 23:46, David Nadlinger c...@klickverbot.at Another less intrusive option would be to just add extern(CppThisCall) and extern(DThisCall) or something along the lines, which would be specified to pass the first parameter as if it was a this pointer. That would also do the business. Do you think that's less intrusive? Less intrusive in the way that it is a minimal addition to the language itself (we already have several calling conventions), whereas your suggestion would require adding a special case to the grammar. That's not to say I don't like your proposal, though. I just wanted to put the option on the table to be sure we are getting somewhere with this, even if some people might be opposed to the grammar change. This issue has been bugging me for quite some time as well. It's inelegant, but it could work. I just find it sad that we have to use a different calling convention for member functions. I mean, it'd be much more elegant be if a member function could simply be called from a void function(Object) by supplying this as the first argument? Wouldn't it be better to adapt the ABI to fit the language rather than adapt the language to fit the ABI? -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: Member function pointers
On 2013-06-10 15:47, Manu wrote: I'm really not asking for delegates (although they could become more typesafe given my suggestion), just a member function pointer. And not C++ style as you say, my suggestion is much simpler than that, and would fit nicely in D. I give up, I don't understand what you want. -- /Jacob Carlborg
Re: builtin sort
On Monday, 10 June 2013 at 11:10:06 UTC, Jacob Carlborg wrote: On 2013-06-10 11:03, Stephan Schiffels wrote: I agree. Do people have the same opinion on the builtin reverse? I don't remember whether there was a discussion about this. I suggest to kill that as well. sort and reverse are perfectly well implemented in the standard library rather than builtin. reverse is implemented with the stupid name retro. That's not correct, it's called reverse and is a builtin property of dynamic arrays, see bearophiles answer... retro is lazy! Is anyone actually on this? I could try to dig into it, I guess I could start looking for spurious places in phobos and druntime where these builtin functions are used and replace them with the library ones. If we deprecate it in the end we don't want to see it being used anywhere in the standard implementations. Perhaps start with modifying the compiler to indicate the sort and reverse functions are deprecated. Then it will be easier to find in Phobos and druntime. Also, if used in druntime they need to be reimplemented there. Right, I thought so, too. Indeed, bearophiles issue addresses this in this order. I will try this on a local branch first and possibly open a pull request to start a more concrete discussion on this... Stephan
Re: std.compress
On 6/10/13 3:13 AM, Jacob Carlborg wrote:
On 2013-06-10 04:33, Andrei Alexandrescu wrote:
Guys, they're function local vars. A comment would suffice.
That doesn't mean the names should be less understandable. We're writing
open source here. I think most names should be named as if they were
part of the public API.
That's an exaggeration. There are plenty of obscure details that help
implementers but would be unnecessary to publish with the API.
It also depends on in what context they are used. Example, in DMD there
are a lot of functions containing probably more the 500 lines of code
with variable names with only one letter, declared at the top of the
function. If you instead have a function with only five or ten lines of
code it could be ok:
private void foo (ProductInformation pi) { // five lines of code }
I would think the above would be ok. But it should definitely not be
used in documentation/examples as I see it is now.
BTW, I hate using comments for that. Comments should basically only be
used for writing API documentation. Most times, if you want to add a
comment your code is probably not clear enough.
A lot of scientific code would be worse off if it used long variable
names. Oftentimes it uses tau or gamma or even a or k with an
explanatory comment at the top.
Andrei
Re: DMD 2.063 produces broken binaries
On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote:
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out.
This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I
try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln(Hi);
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd
junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
The gdb backtrace is somewhere in __libc_start_main, before
main() is
run.
I assume I'm not in the majority, but I literally can't compile
and run
anything.
Any help would be appreciated
Thanks
Jerry
Can you upload somewhere your broken binary?
x86_64 EFL binary would be great!
Re: builtin sort
On 6/10/13 7:10 AM, Jacob Carlborg wrote: On 2013-06-10 11:03, Stephan Schiffels wrote: I agree. Do people have the same opinion on the builtin reverse? I don't remember whether there was a discussion about this. I suggest to kill that as well. sort and reverse are perfectly well implemented in the standard library rather than builtin. reverse is implemented with the stupid name retro. std.algorithm.reverse reverses a range in place: http://dlang.org/phobos/std_algorithm.html#reverse std.range.retro iterates a range in retrograde order without modifying it: http://dlang.org/phobos/std_range.html#.retro Andrei
Re: builtin sort
On Saturday, 8 June 2013 at 08:30:54 UTC, Stephan Schiffels wrote:
Hi,
I know it has been discussed previously to deprecate the
builtin sort. I don't know the status of this, but I observed
the following problem.
With dmd, druntime and phobos all on 2.063, this program runs
successfully on a mac:
#!/usr/bin/env rdmd
import std.stdio;
void main() {
int[] a = [5, 4, 3, 2, 1];
a.sort;
writeln(a);
}
But it fails on linux, with the line:
/nfs/users/nfs_s/ss27/Software/dlang/phobos/generated/linux/release/64/libphobos2.a(qsort_4c4_2cc.o):
In function `_adSort':
src/rt/qsort.d:(.text._adSort+0x47): undefined reference to
`qsort_r'
collect2: ld returned 1 exit status
--- errorlevel 1
When I change a.sort - a.sort() and add import
std.algorithm everything works fine.
Does this mean that the builtin sort on Linux is broken with
2.063?
Stephan
Maybe it is related to
https://github.com/D-Programming-Language/druntime/pull/427
Re: Member function pointers
On 11 June 2013 00:43, Jacob Carlborg d...@me.com wrote: On 2013-06-10 15:47, Manu wrote: I'm really not asking for delegates (although they could become more typesafe given my suggestion), just a member function pointer. And not C++ style as you say, my suggestion is much simpler than that, and would fit nicely in D. I give up, I don't understand what you want. ...a member function pointer syntax. It's not that complex. My suggestion is: void function(T this) funcptr; This is a function pointer (not a delegate), but using keyword 'this' gives the critical detail to the compiler that it's a member function pointer, and to use the appropriate calling convention when making calls through this pointer. UFCS makes it awesome.
Re: Member function pointers
On Monday, 10 June 2013 at 14:43:50 UTC, Jacob Carlborg wrote:
On 2013-06-10 15:47, Manu wrote:
I'm really not asking for delegates (although they could
become more
typesafe given my suggestion), just a member function pointer.
And not
C++ style as you say, my suggestion is much simpler than that,
and would
fit nicely in D.
I give up, I don't understand what you want.
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
memberFun(a);
---
David
On random numbers and ranges
Hello all,
Anyone looking at D bugzilla or Phobos pull requests recently will see that I've
been filing a number of bug reports and fixes against std.random.RandomSample.
(I have Diggory to thank for this -- during the course of a discussion on
D.learn I noticed an error when attempting to sample file.byLine, and that in
turn led to some careful re-examination of the whole RandomSample struct.)
Now, the good news is that it's unlikely that the issues reported will have
bitten anyone using randomSample as intended. However, the issues that have
arisen seem interesting to discuss in a broader context of random number
generation and its relation to ranges.
These are thoughts I've been mulling over for some time, and it seems like an
opportune moment to share them, with RandomSample providing a concrete
illustration. There's also some concrete application: I am not sure how to
proceed on certain issues I've identified, and would like feedback and advice.
So.
Let's begin by defining the concept of a Random Range: that is, a range where
popFront() makes use of a source of randomness. This can be a pseudo-random
number generator or a source of true randomness such as /dev/random.
This immediately leads to a situation different from other range objects. For
example, it means that the concept of a save() method is different and maybe
meaningless: we can save the current state of the range, but the forward motion
of different saved copies will diverge because of the randomness in popFront().
(Caveat: in the event that the source of randomness is a pseudo-random number
generator, it's technically possible to also save the state of the RNG.
However, this has other issues that make it undesirable, related to statistical
safety within the program. This has been discussed before on the list.)
That might ultimately be boring -- a conclusion that Random Ranges can't be
Forward Ranges. What I find more compelling is something different: many Random
Ranges also have a unique challenge that the initial value of front() cannot be
determined until it is accessed for the first time.
To see why, consider the case of RandomSample and its corresponding bug 8314.
The original version of RandomSample determined the initial value of front() in
the constructor. This meant that if you read from the same sample multiple
times, the first value would always be identical, destroying the statistical
independence of the samples.
What I realized recently is that this has knock-on effects elsewhere. For
example, for popFront() to work correctly, the value of front() must be
initialized. In the case of RandomSample, calling popFront() before front() can
result in a statistical anomaly -- sampling (n-1) items with even probability
from a range of length (N-1) -- whereas what it _should_ be is sampling (n-1)
items from the remains of the input range after the first item has been
selected.
There may also be other methods or properties that depend on the initialization
of front() -- for example, RandomSample's index() method assumes that the first
sample point has already been chosen.
At the same time, there are methods one would definitely want _not_ to affect
the initialization of front(). For example, RandomSample has the .length
property. If calling .length would in turn trigger initialization of front(),
you could have code like this:
auto sample = randomSample(iota(100), 5);
enforce(sample.length == 5); // --- if it initializes the value of
// .front, it will fix the first sample point
foreach(s; sample)
writeln(s);
writeln();
foreach(s; sample) // --- and if front is initialized by the call to
writeln(s); // .length, it means this second extraction of the
// sample will have an identical first point to the
// previous one, which destroys statistical
// independence. Cf. Issue 8314.
The simple fix here is for the programmer to recognize what methods require
initialization of front(), to check inside those methods for some boolean switch
that indicates initialization, and depending on that switch call some
initialization function. In RandomSample we have:
@property auto ref front()
{
assert(!empty);
// The first sample point must be determined here to avoid
// having it always correspond to the first element of the
// input. The rest of the sample points are determined each
// time we call popFront().
if(_first)
{
// We can save ourselves a random variate by checking right
// at the beginning if we should use Algorithm A.
if((_alphaInverse * _toSelect) _available)
{
_algorithmA = true;
}
else
{
_Vprime = newVprime(_toSelect);
_algorithmA = false;
}
Re: about with statement
On 06/10/2013 02:43 AM, Marco Leise wrote:
Am Sun, 09 Jun 2013 16:48:39 -0700
schrieb Ali Çehreli acehr...@yahoo.com:
switch(foobar) with(FoobarEnum) {
// ...
}
To me, 'with' is useful only in that _case_.
Pun intended?
Ha ha! :) No, I missed that one.
Ali
Formal Review of std.serialization
Today we start the formal review of std.serialization (Orange). This library is authored by Jacob Carlborg and has been around through the D1/Tango days. Please take some time in the next 2 weeks to provide feedback on the library. Some things to know (from http://forum.dlang.org/thread/kinpnv$ven$1...@digitalmars.com) * The most important packages are: orange.serialization and orange.serialization.archives * Trailing whitespace and tabs will be fixed when/if the package gets accepted And the author had some requests for specific things: * I'm using some utility functions located in the util and core packages, what should we do about those, where to put them? * The unit tests are located in its own package, I'm not very happy about putting the unit tests in the same module as the rest of the code, i.e. the serialization module. What are the options? These test are quite high level. They test the whole Serializer class and not individual functions. * If this get accepted should I do a sub-tree merge (or what it's called) to keep the history intact? Source: https://github.com/jacob-carlborg/orange Docs: https://dl.dropboxusercontent.com/u/18386187/orange_docs/Serializer.html (For those not familiar with CandyDoc, There is a Package tab to view the tree of modules)
Re: std.process - POSIX specific callback
On Fri, 07 Jun 2013 01:59:22 -0400, Lars T. Kyllingstad pub...@kyllingen.net wrote: On Thursday, 6 June 2013 at 17:32:25 UTC, nazriel wrote: I am aware that std.process is generalized but I doubt such useful functionality which is usable on various Posixen is more disturbing than Windows-only suprpressConsole https://github.com/D-Programming-Language/phobos/blob/master/std/process.d#L954 I think there is a huge difference between a simple flag and the ability to execute arbitrary code on one OS but not on another. (When set, suppressConsole actually *eliminates* a difference in the default behaviour of the two OS families.) First, suppressConsole is a simple flag, basically passed through to the CreateProcess function, so even though it's Windows-specific, so is the behavior we are suppressing. Consider that when you specify suppressConsole on Posix, the flag works! No console window is created :) But what to do with arbitrary run this code between fork and exec on windows? It's not possible. It doesn't belong in the generalized API. But I was mistaken. Config is an enum not struct, so yeah, not worth changing it only for sake of posix callback. So maybe module level variable? module std.process; // ... void delegate() posixPostFork = null; // ... Global state? Don't want to go there... I agree that the global state is a bad idea, ideally you want to specify PER CALL what happens on a fork/exec, not PER THREAD (or PER PROCESS). But I think we need some way to hook this. To give up all the niceties of std.process just so you can hook the fork/exec sequence seems overly burdensome. What I am thinking of is possibly to expose the OS-specific spawnProcess implementation as an object with the API defined by it, similar to how writeln simply forwards to stdout.writeln. We could have spawnProcess simply forward to posixProcessImpl.spawnProcess (or windowsProcessImpl.spawnProcess on windows) Then if someone wants to actually take advantage of OS-specific features, they can call on the appropriate object. It shouldn't compile where it's not implemented (e.g. windows spawnProcess shouldn't be callable on Linux). Does this make sense? I think it can be done without breaking any code. May be a lot of boilerplate :) -Steve
Re: Member function pointers
On 2013-06-10 17:36, Manu wrote: My suggestion is: void function(T this) funcptr; This is a function pointer (not a delegate), but using keyword 'this' gives the critical detail to the compiler that it's a member function pointer, and to use the appropriate calling convention when making calls through this pointer. UFCS makes it awesome. What I don't understand is what this give you that a delegate doesn't. You need the this pointer to call the function pointer anyway. With a delegate it's bundled. -- /Jacob Carlborg
Re: builtin sort
On 2013-06-10 17:15, Andrei Alexandrescu wrote: std.algorithm.reverse reverses a range in place: http://dlang.org/phobos/std_algorithm.html#reverse std.range.retro iterates a range in retrograde order without modifying it: http://dlang.org/phobos/std_range.html#.retro Right, my bad. -- /Jacob Carlborg
Re: Member function pointers
On 2013-06-10 17:40, David Nadlinger wrote:
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
memberFun(a);
---
Why is this better than a delegate?
--
/Jacob Carlborg
Re: Member function pointers
On 11 June 2013 02:26, Jacob Carlborg d...@me.com wrote:
On 2013-06-10 17:40, David Nadlinger wrote:
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
memberFun(a);
---
Why is this better than a delegate?
It's not 'better', it's different.
Re: about with statement
On Sun, 09 Jun 2013 14:09:31 -0400, deadalnix deadal...@gmail.com wrote:
On Sunday, 9 June 2013 at 10:22:22 UTC, Jonathan M Davis wrote:
On Sunday, June 09, 2013 12:11:23 khurshid wrote:
D language have like Pascal/Delphi with statement, which very
useful for writing readable code.
http://dlang.org/statement.html#WithStatement
Maybe I'm wrong, but, I never saw where using this statement in
phobos source codes, what problem using this statement?
I'm not aware of any problems with it, but there's also rarely any
reason to
use it. In most cases, it doesn't really add anything to the code, and
I'd
argue that it would make code harder to read, because it hides where the
variables are coming from. I don't think that we'd really lose anything
if we
didn't have it, but it's there if you want to use it, and it's not
going away.
- Jonathan M Davis
switch(foobar) with(FoobarEnum) {
// ...
}
That is golden !
This is gold plated.
Assuming typeof(foobar) == FoobarEnum, any place FoobarEnum is expected,
you should not have to specify FoobarEnum.
The above should not be necessary.
-Steve
Re: Member function pointers
On 11 June 2013 02:28, Jacob Carlborg d...@me.com wrote: On 2013-06-10 17:36, Manu wrote: My suggestion is: void function(T this) funcptr; This is a function pointer (not a delegate), but using keyword 'this' gives the critical detail to the compiler that it's a member function pointer, and to use the appropriate calling convention when making calls through this pointer. UFCS makes it awesome. What I don't understand is what this give you that a delegate doesn't. You need the this pointer to call the function pointer anyway. With a delegate it's bundled. It's just a pointer, 'this' is associated at the call site. And it's strongly typed. If you don't want a bundle, why be forced to use a bundled type? Consider this, why would you ever want an int* when you can have an int[]? We could remove the syntax for int*, and make it only accessible via int[].ptr... and make: is(typeof(int[].ptr) == size_t)? :)
Re: Member function pointers
On 2013-06-10 18:34, Manu wrote:
On 11 June 2013 02:26, Jacob Carlborg d...@me.com mailto:d...@me.com
wrote:
On 2013-06-10 17:40, David Nadlinger wrote:
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
memberFun(a);
---
Why is this better than a delegate?
It's not 'better', it's different.
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
void delegate () dg;
dg.funcptr = memberFun;
dg.ptr = cast(void*) a;
dg();
The details can be hidden in a function call. Sure, a delegate could be
type safe but still don't see the point.
--
/Jacob Carlborg
Re: Member function pointers
Am 10.06.2013 18:28, schrieb Jacob Carlborg: On 2013-06-10 17:36, Manu wrote: My suggestion is: void function(T this) funcptr; This is a function pointer (not a delegate), but using keyword 'this' gives the critical detail to the compiler that it's a member function pointer, and to use the appropriate calling convention when making calls through this pointer. UFCS makes it awesome. What I don't understand is what this give you that a delegate doesn't. You need the this pointer to call the function pointer anyway. With a delegate it's bundled. maybe he just don't need one to handle the this ptr because he wants to call several/hundrets of member-functions?
Re: Member function pointers
On 2013-06-10 18:38, dennis luehring wrote: maybe he just don't need one to handle the this ptr because he wants to call several/hundrets of member-functions? How does he call a pointer to a member function without the this pointer? -- /Jacob Carlborg
Re: DMD 2.063 produces broken binaries
John Colvin john.loughran.col...@gmail.com writes: On Monday, 10 June 2013 at 06:41:39 UTC, Jerry wrote: LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry I can't reproduce this anywhere. What's the output for these: gcc --version ldd --version jlquinn@wyvern:~/dmd2/src/dmd$ gcc --version gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jlquinn@wyvern:~/dmd2/src/dmd$ ldd --version ldd (Ubuntu EGLIBC 2.15-0ubuntu20.1) 2.15 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. Also, check for any stray installations or config files: find /usr /etc /opt /home/$(whoami) -name \*phobos\* -o -name \*druntime\* -o -name dmd\* 2/dev/null I ran and verified that there's no stray phobos or druntime libraries. Be warned that will take a while (a few minutes on my machine). Also, and I know this sounds stupidly simple, but have to tried re-downloading? Already tried it. I also get a segfault on my Debian x86_64 machine. I've straced the dmd compile and it is using the correct libraries. Compressed, the binary is 175K. Is that OK to attach to the open bug? Jerry
Re: Member function pointers
On 11 June 2013 02:43, Jacob Carlborg d...@me.com wrote:
On 2013-06-10 18:34, Manu wrote:
On 11 June 2013 02:26, Jacob Carlborg d...@me.com mailto:d...@me.com
wrote:
On 2013-06-10 17:40, David Nadlinger wrote:
Let me try to summarize it in code:
---
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
memberFun(a);
---
Why is this better than a delegate?
It's not 'better', it's different.
class A { void foo(); }
auto memberFun = (A.foo).funcptr;
auto a = new A;
void delegate () dg;
dg.funcptr = memberFun;
dg.ptr = cast(void*) a;
dg();
The details can be hidden in a function call. Sure, a delegate could be
type safe but still don't see the point.
You can see how much work that is right? And it's still not typesafe.
It's totally a hack.
Re: DMD 2.063 produces broken binaries
Andrei Alexandrescu seewebsiteforem...@erdani.org writes:
On 6/10/13 2:41 AM, Jerry wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org writes:
On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote:
On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote:
On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote:
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d
binary/home/jlquinn/dmd2/linux/bin64/dmd
version v2.063
[snip]
I've done a clean room attempt at reproducing the bug, was unable
to. Jerry, anything you can think of that's unusual with your
installation?
Forgot to mention - details at
http://d.puremagic.com/issues/show_bug.cgi?id=10274
One thought that comes to mind - you may want to double-check
LD_LIBRARY_PATH
to make sure there's no stray reference to an old libphobos.a dir.
LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian
testing machine as well as my Ubuntu one. I'm pretty confused.
Jerry
Appreciate the work. (BTW nice to see you again, recall we talked at that NLP
conference a while back.)
I do recall. I'm glad you ended up someplace you enjoy. That was a fun
conference.
Let's focus on Ubuntu/64 because that's what I have on my end too.
1. Which Ubuntu version are you using?
I'm running 12.10 x86_64.
2. Can you compile and run hello, world in C?
That works fine.
3. If you replace the D call to writeln() with a call to printf(), does that
work?
No, same problem. BTW, it's segfaulting in _d_dso_registry() before
main() gets run.
4. If you make any other calls into the stdlib aside from I/O, do they
work?
It doesn't matter. The following program segfaults:
void main() {}
5. Does gdb reveal anything interesting?
Unfortunately there's no debugging symbols in _d_dso_registry(). I
assume the compiler is writing asm directly.
Jerry
Re: Member function pointers
On Mon, 10 Jun 2013 12:45:12 -0400, Jacob Carlborg d...@me.com wrote:
On 2013-06-10 18:38, dennis luehring wrote:
maybe he just don't need one to handle the this ptr because he wants to
call several/hundrets of member-functions?
How does he call a pointer to a member function without the this
pointer?
Like this:
void callRandomMember(C[] objs, memberPointerToCMethod p)
{
objs[random(0, objs.length)].p();
}
Essentially, you bind at call time to form a delegate. But the member
function pointer's 'this' must be strongly typed.
-Steve
reddit discussion on replacing Python in 0install
Hi folks, There's an interesting discussion going on at Reddit about choosing a replacement language for 0install: http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/ I've tried to do a bit of D advocacy there, but there's more to be done. :) If you have a few moments to dispel some D myths, and contribute constructively to the discussion, please take a look! Best, Graham
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 16:52:51 UTC, Jerry wrote:
No, same problem. BTW, it's segfaulting in _d_dso_registry()
before
main() gets run.
4. If you make any other calls into the stdlib aside from I/O,
do they
work?
It doesn't matter. The following program segfaults:
void main() {}
5. Does gdb reveal anything interesting?
Unfortunately there's no debugging symbols in
_d_dso_registry(). I
assume the compiler is writing asm directly.
Jerry
I got a similar issue when upgrading to 2.063 on arch linux, so I
feel this may be relevant to the current problem. Heres the
backtrace for me.
#0 0x77286f54 in _d_arrayappendcd () from
/usr/lib/libphobos2.so.0.63
#1 0x7721f5c4 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#2 0x772781a2 in _aApplycd1 () from
/usr/lib/libphobos2.so.0.63
#3 0x7721f566 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#4 0x77278626 in _aApplycd2 () from
/usr/lib/libphobos2.so.0.63
#5 0x7721f4b5 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#6 0x771b4f15 in std.encoding.EncodingScheme.register()
() from /usr/lib/libphobos2.so.0.63
#7 0x771b543a in
std.encoding.EncodingSchemeASCII._sharedStaticCtor9() ()
from /usr/lib/libphobos2.so.0.63
#8 0x771bb351 in std.encoding.__modsharedctor() () from
/usr/lib/libphobos2.so.0.63
#9 0x77288c54 in rt.minfo.ModuleGroup.runCtors() () from
/usr/lib/libphobos2.so.0.63
#10 0x77288196 in rt.minfo.ModuleGroup.runCtors() () from
/usr/lib/libphobos2.so.0.63
#11 0x772884dd in rt.minfo.rt_moduleCtor() () from
/usr/lib/libphobos2.so.0.63
#12 0x772891ca in rt.sections_linux.DSO.opApply() () from
/usr/lib/libphobos2.so.0.63
#13 0x772884ae in rt_moduleCtor () from
/usr/lib/libphobos2.so.0.63
#14 0x772818ad in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#15 0x772813cd in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#16 0x77281387 in _d_run_main () from
/usr/lib/libphobos2.so.0.63
#17 0x772811d4 in main () from /usr/lib/libphobos2.so.0.63
#18 0x7653ca15 in __libc_start_main () from
/usr/lib/libc.so.6
#19 0x0043f9d9 in _start ()
Unfortunately, no debugging symbols for phobos.
program was compiled with dmd (2.063) using the following flags:
-g -debug -unittest
stub out your gc without hacking on druntime
I decided to boil going without gc down to one simple move: put
this code into a file called nogc.d and then add it to your dmd
command line:
===
import core.stdc.stdio;
import core.stdc.stdlib;
extern(C):
void* gc_malloc() {
fprintf(stderr, GC allocations are disabled\nProgram
terminated\n);
asm { hlt; }
assert(0);
}
// druntime calls these, but we can just stub them out
void gc_init() { }
void gc_addRange() { }
void gc_term() { }
// druntime makes some classes too. we'll malloc them. This
technically
// leaks but since it is startup code I'm pretty sure it doesn't
matter.
// this also makes new class available to user code, but remember
to free your classes and call the destructor:
/*
void free(Object object) {
auto dtor = cast(void function(Object o))
object.classinfo.destructor;
if(dtor)
dtor(object);
free(cast(void*) object);
}
*/
extern(C) Object _d_newclass(const ClassInfo ci) {
void* memory = malloc(ci.init.length);
if(memory is null) {
fprintf(stderr, Out of memory to allocate
class\n);
asm { hlt; }
assert(0);
}
(cast(byte*) memory)[0 .. ci.init.length] = ci.init[];
return cast(Object) memory;
}
===
You shouldn't have to modify your code nor druntime/phobos
(though you'll probably find them being killed by hidden
allocations!), unlike the minimal D stuff I've been talking about
the last few weeks which replaces them entirely.
The reason it works is the gc functions come from a library file.
.lib functions are overridden by functions with the same name in
an object file.
So this redefines crucial gc functions, and then the linker uses
them instead of the ones druntime provides.Thereby stubbing out
the garbage collector in this individual exe. I tried it on both
Windows and Linux and it seemed to work as I expected.
The resulting executable is slightly smaller too, since the
linker can dump more functions that are never called by the stubs:
$ dmd test2.d
You have mail in /var/spool/mail/me
$ ls -lh test2
-rwxr-xr-x 1 me users 683K 2013-06-10 15:06 test2
$ dmd test2.d nogc.d
$ ls -lh test2
-rwxr-xr-x 1 me users 626K 2013-06-10 15:06 test2
(test2.d is just a random program that does writeln(ctor) and
writeln(dtor) on a few classes to see when/if they are still
running, nothing special there)
On IRC someone suggested an even simpler solution to me too: set
a breakpoint at gc_malloc in your debugger. Then you can see
where it is called and continue/stop at any time.
I found a hidden allocation in druntime using this instantly and
already filed to bugzilla. If you are on an AMD processor you'll
probably see it too if you try to run a program
http://d.puremagic.com/issues/show_bug.cgi?id=10323
so you won't get far with nogc.d! But if you fix that up and try
again I was able to get my test to run.
Re: about with statement
On Mon, 10 Jun 2013 15:33:44 +0200
Anthony Goins neonto...@gmail.com wrote:
Am I the only one that found this useful?
Is there a better way?
with (specificModule)
{
result = ufcsChain.ambiguousFunction.link3();
}
Ooh, that's another good one!
Re: about with statement
On Sunday, 9 June 2013 at 10:11:25 UTC, khurshid wrote: D language have like Pascal/Delphi with statement, which very useful for writing readable code. http://dlang.org/statement.html#WithStatement Maybe I'm wrong, but, I never saw where using this statement in phobos source codes, what problem using this statement? Regards, Khurshid. You're right but the with statment in Pascal/Delphi is deprecated. While it was usefull in a simple branch, it was error-prone. In D the scope() statement can be used to overcome the old Pascal pattern: with whatIcreate try finally free. quote from Delphi XE4 release (technical pdf): 4. OTHER LANGUAGE CHANGES Besides string type changes and objects memory management, there are other current or expected changes in the new Delphi ARM compiler that you can easily start to adopt: Sooner or later, the with statement is going to be deprecated and removed from the Delphi language. You can easily start removing it now from your code, and most Delphi developer will agree this is a good idea anyway, given some of the hidden pitfalls of this keyword.
Re: Installing vibe via DUB
On Monday, June 10, 2013 07:32:53 Russel Winder wrote: On Sun, 2013-06-09 at 18:37 -0700, Jonathan M Davis wrote: […] I believe that this is the correct place to ask: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ […] I am in the camp of forum hater which I know means 50% of people hate me, but… if stuff doesn't arrive in my email it doesn't exist. I am assuming that although VibeNews behaves as an NNTP newsgroup as well as a classic Web-based forum, it doesn't support SMTP mail interaction. Perhaps this could be an evolution? Perhaps then the infrastructure could be used for all D activity as a dog fooding activity? You'll have to take that up with the rejectedsoftware folks. It's their forum. The main D forums are set up to use newsgroups as their backend while allowing users to also interact via a web forum and e-mail, but AFAIK, they are unique in that regard. So, I wouldn't expect anyone else to be doing that unless they used the same software - which the rejectdsoftware folks could do, but it's up to them. On a related note, I believe that Vladimir was looking making the main D forums' software use vibe.d, but I don't know where he is with that. - Jonathan M Davis
Re: std.process - POSIX specific callback
On Monday, 10 June 2013 at 16:20:53 UTC, Steven Schveighoffer wrote: But I think we need some way to hook this. To give up all the niceties of std.process just so you can hook the fork/exec sequence seems overly burdensome. But with the pthread_atfork() solution you don't have to. Call that function before you call spawnProcess() or any of the other std.process functions, and it should Just Work (TM). The nice thing here is that it is already part of the POSIX standard, and thus should be available on all relevant systems, and we don't have to adapt our cross-platform API at all.
Re: std.process - POSIX specific callback
On Mon, 10 Jun 2013 16:05:15 -0400, Lars T. Kyllingstad pub...@kyllingen.net wrote: On Monday, 10 June 2013 at 16:20:53 UTC, Steven Schveighoffer wrote: But I think we need some way to hook this. To give up all the niceties of std.process just so you can hook the fork/exec sequence seems overly burdensome. But with the pthread_atfork() solution you don't have to. Call that function before you call spawnProcess() or any of the other std.process functions, and it should Just Work (TM). The nice thing here is that it is already part of the POSIX standard, and thus should be available on all relevant systems, and we don't have to adapt our cross-platform API at all. This is not a good solution. It deals with the idea that when forking, only the calling thread is alive, all other threads are dead, and one of those dead threads may hold a lock. Also note that the function pointers are function pointers, not delegates. The idea is that prior to fork, you lock all mutexes you want to be unlocked. Then after fork is called, you unlock those mutexes (thus ensuring no dead threads hold the locks). I don't think it makes for a very good generalized solution to I want to run this arbitrary code. Also, according to SO, it doesn't even do what it means to do, since the newly created process thread can't unlock the mutexes: http://stackoverflow.com/questions/2620313/how-to-use-pthread-atfork-and-pthread-once-to-reinitialize-mutexes-in-child Not only that, but it seems to be permanent -- there is no unregister pthread_atfork call. So this has to be a one-time *process-wide* and permanent solution. If you wanted to run code for this specific call to spawnProcess, and not others, then you are SOL. And finally, if your ultimate purpose is to call exec right after fork (as it is in the general case), you are penalized by having to wait for some mutex to be unlocked in order to fork. -Steve
Re: Member function pointers
On Mon, 10 Jun 2013 14:53:33 +0200, Jacob Carlborg d...@me.com wrote: On 2013-06-10 14:36, Manu wrote: funcptr pretends to be typed, but the type is just wrong. In your example, the type is 'void function()', it should be 'void function(Foo this)'. void function() is part of the complete type. It becomes complete with the context pointer. This is utter horseshit. Not that it's part of the complete type, nor even that it becomes complete with the context pointer (though that is highly dubious at best), but the type of funcptr. It's a disgrace, simple as that. It should either be typeless, or it should take a void* as its first argument. void* means 'magic ahead', so it would be kinda ok. -- Simen
Re: Member function pointers
On Monday, 10 June 2013 at 20:31:32 UTC, Simen Kjaeraas wrote: or it should take a void* as its first argument. void* means 'magic ahead', so it would be kinda ok. This would encourage people to try something like dg.funcptr(dg.ptr, ...), which is not correct ABI-wise. David
Re: reddit discussion on replacing Python in 0install
On Monday, 10 June 2013 at 18:25:05 UTC, Graham Fawcett wrote: Hi folks, There's an interesting discussion going on at Reddit about choosing a replacement language for 0install: http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/ I've tried to do a bit of D advocacy there, but there's more to be done. :) If you have a few moments to dispel some D myths, and contribute constructively to the discussion, please take a look! Best, Graham I don't know how to make this test on Windows (current OS). But he uses this to test that failure to print hello correctly indicates failure. ./hello 1 /dev/null; echo Exit status: $? And Rust is the only one to pass in his list (ATS, C#, Go, Haskell, OCaml, Python)
Re: reddit discussion on replacing Python in 0install
Graham Fawcett: http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/ I was about to link that Reddit thread here myself :-) The original article proposes to translate to your language this little piece of Python+libs and measure its speed, safety in presence of errors, etc: #!/usr/bin/env python import os, sys, json envname = os.path.basename(sys.argv[0]) args = json.loads(os.environ[0install-runenv- + envname]) os.execv(args[0], args + sys.argv[1:]) Later he proposes other means to measure a language quality. Overall the comparison is quite interesting, despite several methodological problems. Bye, bearophile
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 18:50:21 UTC, Brandon wrote:
On Monday, 10 June 2013 at 16:52:51 UTC, Jerry wrote:
No, same problem. BTW, it's segfaulting in _d_dso_registry()
before
main() gets run.
4. If you make any other calls into the stdlib aside from
I/O, do they
work?
It doesn't matter. The following program segfaults:
void main() {}
5. Does gdb reveal anything interesting?
Unfortunately there's no debugging symbols in
_d_dso_registry(). I
assume the compiler is writing asm directly.
Jerry
I got a similar issue when upgrading to 2.063 on arch linux, so
I feel this may be relevant to the current problem. Heres the
backtrace for me.
#0 0x77286f54 in _d_arrayappendcd () from
/usr/lib/libphobos2.so.0.63
#1 0x7721f5c4 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#2 0x772781a2 in _aApplycd1 () from
/usr/lib/libphobos2.so.0.63
#3 0x7721f566 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#4 0x77278626 in _aApplycd2 () from
/usr/lib/libphobos2.so.0.63
#5 0x7721f4b5 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#6 0x771b4f15 in
std.encoding.EncodingScheme.register() () from
/usr/lib/libphobos2.so.0.63
#7 0x771b543a in
std.encoding.EncodingSchemeASCII._sharedStaticCtor9() ()
from /usr/lib/libphobos2.so.0.63
#8 0x771bb351 in std.encoding.__modsharedctor() ()
from /usr/lib/libphobos2.so.0.63
#9 0x77288c54 in rt.minfo.ModuleGroup.runCtors() ()
from /usr/lib/libphobos2.so.0.63
#10 0x77288196 in rt.minfo.ModuleGroup.runCtors() ()
from /usr/lib/libphobos2.so.0.63
#11 0x772884dd in rt.minfo.rt_moduleCtor() () from
/usr/lib/libphobos2.so.0.63
#12 0x772891ca in rt.sections_linux.DSO.opApply() ()
from /usr/lib/libphobos2.so.0.63
#13 0x772884ae in rt_moduleCtor () from
/usr/lib/libphobos2.so.0.63
#14 0x772818ad in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#15 0x772813cd in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#16 0x77281387 in _d_run_main () from
/usr/lib/libphobos2.so.0.63
#17 0x772811d4 in main () from
/usr/lib/libphobos2.so.0.63
#18 0x7653ca15 in __libc_start_main () from
/usr/lib/libc.so.6
#19 0x0043f9d9 in _start ()
Unfortunately, no debugging symbols for phobos.
program was compiled with dmd (2.063) using the following
flags: -g -debug -unittest
I suspected it may be the problem with shared libraries.
Can you try compiling that hello world with static libphobos?
Or can you attach your segfaulting binary?
Re: DMD 2.063 produces broken binaries
On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default.
Re: implicit template constraint notation
On Mon, Jun 10, 2013 at 2:19 AM, bearophile bearophileh...@lycos.comwrote:
Timothee Cour:
A)
I'd like to simplify notation of template function declarations involving
only single-argument boolean template constraints as follows:
example:
A1: 'auto myfunction ( isSomeString a, isInputRange b) {...}'
would be rewritten by compiler as:
A2: 'auto myfunction(T0,T1) (T0 a, T1 b) if(isSomeString!T1 a
isInputRange!T b) {...}'
IMO, A1 is less verbose and clearer than A2.
Obviously, more complex template constraints would still require the full
syntax, but I'd argue this case is the most common.
See:
http://forum.dlang.org/thread/**xaganckgcdkfcmjamogh@forum.**dlang.orghttp://forum.dlang.org/thread/xaganckgcdkfcmjam...@forum.dlang.org
ah, great! So I guess it must indeed be a good idea!
from the link:
If you have two or more types, they must be the same (if you don't want
this, you have to use the normal longer syntax)
In what I suggest, the restriction is much weaker so it'd be more generally
applicable: for example, 'auto myfunction ( isSomeString a, isInputRange
b)' would work in what I suggest but not with the proposal in the link. I
don't think it adds any confusion.
Should I draft a DIP?
I'd like to get more feedback before though.
I'll also reply on the above link (CppNow 2013) for your second proposal
from cppnow (i think variant does already that).
B)
Secondly, ddoc doesn't generate template constraints or does so very
inconsistently :
in
http://dlang.org/phobos/std_**algorithm.htmlhttp://dlang.org/phobos/std_algorithm.htmlwe
have:
template map(fun...) if (fun.length = 1);
but all other template constraints are omitted, eg:
void fill(Range, Value)(Range range, Value filler); // template constraint
omitted.
Using the notation proposed in A, wherever applicable, would make
documentation clear.
That sounds like a bug report for bugzilla.
just filed: http://d.puremagic.com/issues/show_bug.cgi?id=10325
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first.
Re: Formal Review of std.serialization
A quick first look for now: In general I think that you should clone phobos and merge orange into std.serialize in order for us to see how it really fits into phobos. As such I think it feels more like a RFC than formal review because it couldn't possible go into phobos in its current state even if we ignored all comments from the this list. Now for something more constructive :) * I'm using some utility functions located in the util and core packages, what should we do about those, where to put them? The core package only have the core.Attribute module which defines a meta attribute which is a new concept in phobos. I guess that should either be removed or we should spawn a discussion about if we want such a thing or not. Is it possible to do without it? The util package util.use.d : I think the Use struct feels a bit like abusing the 'in' operator to work around D not supporting blocks or something else that would provide the desired syntax. Personally I think it should go. util.traits.d : Most of them should go to std.traits or use something from std.traits instead if possible util.reflection.d : Should probably be part if std.traits as well since there are already some reflection code in there. I guess std.traits should make use of the new package.d thing to split up the module into several files. util.ctfe.d : Wouldn't now where to put it. util.collection.array : should probably go into std.exception It seems all the module filenames are camel cased. They should be all lowercase. The _.d modules should probably be renamed to package.d now. * The unit tests are located in its own package, I'm not very happy about putting the unit tests in the same module as the rest of the code, i.e. the serialization module. What are the options? These test are quite high level. They test the whole Serializer class and not individual functions. IMHO I think the tests would fit nicely into the package itself. Close to the code it tests. https://dl.dropboxusercontent.com/u/18386187/orange_docs/Serializer.html Could you provide the docs formatted as it would be in dlang.org since only that way it is also possible to review formatting. Keep up the good work. I for one are really looking forward to finally getting this thing in. /Jonas
Re: DMD 2.063 produces broken binaries
On 6/10/2013 2:56 PM, Walter Bright wrote: On 6/10/2013 2:38 PM, nazriel wrote: On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first. linking with -g -debug -unittest will statically link, it will not link with the .so One way to be sure - delete all the libphobos2.so files. All of them, then try again.
Re: DMD 2.063 produces broken binaries
On 6/10/2013 2:38 PM, nazriel wrote: On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first. linking with -g -debug -unittest will statically link, it will not link with the .so
Re: implicit template constraint notation
Timothee Cour: ah, great! So I guess it must indeed be a good idea! I don't know. It's a cute idea, but I think it doesn't add a lot of value. What are its advantages in D beside reducing a little the amount of code? In what I suggest, the restriction is much weaker so it'd be more generally applicable: for example, 'auto myfunction ( isSomeString a, isInputRange b)' would work in what I suggest but not with the proposal in the link. I don't think it adds any confusion. myfunction(isSomeString a, isInputRange b) should work. The restriction was different, about code like: myfunction2(isInputRange a, isInputRange b) And then trying to instantiate myfunction2 with two types (for a and b) that are both input ranges but are two different types. Should I draft a DIP? Feel free, but be prepared to not see lot of people interested in it. I'd like to get more feedback before though. Right. Andrei is expert on this topic. just filed: http://d.puremagic.com/issues/show_bug.cgi?id=10325 I have added a note. It's good to help as much as possible the person that will write the patch :-) Bye, bearophile
Re: reddit discussion on replacing Python in 0install
On Monday, 10 June 2013 at 20:51:16 UTC, Jesse Phillips wrote:
On Monday, 10 June 2013 at 18:25:05 UTC, Graham Fawcett wrote:
Hi folks,
There's an interesting discussion going on at Reddit about
choosing a replacement language for 0install:
http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/
I've tried to do a bit of D advocacy there, but there's more
to be done. :) If you have a few moments to dispel some D
myths, and contribute constructively to the discussion, please
take a look!
Best,
Graham
I don't know how to make this test on Windows (current OS). But
he uses this to test that failure to print hello correctly
indicates failure.
./hello 1 /dev/null; echo Exit status: $?
And Rust is the only one to pass in his list (ATS, C#, Go,
Haskell, OCaml, Python)
If you want to know what happens on my linux box
1 module hellotest;
2
3 import std.stdio;
4
5 void main()
6 {
7 writeln(hello world.);
8 }
anthony@LinuxGen12:~/projects/temp$ ./hellotest
hello world.
anthony@LinuxGen12:~/projects/temp$ ./hellotest 1/dev/null; echo
status : $?
status : 0
anthony@LinuxGen12:~/projects/temp$
Re: DMD 2.063 produces broken binaries
Walter Bright newshou...@digitalmars.com writes: On 6/10/2013 2:56 PM, Walter Bright wrote: On 6/10/2013 2:38 PM, nazriel wrote: On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 His code appears to die after main() is in progress. OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first. linking with -g -debug -unittest will statically link, it will not link with the .so Yes, strace on dmd shows that I'm linking with libphobos2.a. ... [pid 23169] open(/home/jlquinn/dmd2/linux/bin64/../lib64/libphobos2.a, O_RDONLY|O_CLOEXEC) = 11
