Re: Functional vs simple code
Stuff Actually now I realise what the conflict is between the two, a + b * b would give the wrong answer when applied to the whole array in the manner I was thinking by doing a + a * a for the first value.
Re: how to call std_stdio_static_this from a dynamically loaded shared library (osx)
On 2012-10-03 02:55, timotheecour wrote: How do I call std_stdio_static_this() in std.stdio from a dynamically loaded shared library (osx) ? I need to do this in my scenario: 1) main program is launched 2) dynamic library is created 3) dynamic library is loaded and a function from it is called 4) everything works fine until a writeln(0) is called from a function inside the dynamic lib, at which point it crashes. But by calling std_stdio_static_this2 (see below) BEFORE any call to writeln (and similar functions), everything works fine. Dynamic libraries are not properly working, see this thread: http://forum.dlang.org/thread/k3vfm9$1tq$1...@digitalmars.com And this post: http://forum.dlang.org/thread/k3vfm9$1tq$1...@digitalmars.com?page=3#post-k4219f:24uft:241:40digitalmars.com -- /Jacob Carlborg
Re: how to call std_stdio_static_this from a dynamically loaded shared library (osx)
Thanks for the links. Ya, I did see those threads and I understand there are limitations with dynamic load shared libraries, however, your answer is not very helpful. We shouldn't have to wait until they get 100% support to start using them (who knows when that happens); some applications just require them (eg writing matlab mex files). In the meantime, the workaround I described above seems to adequately address the IO problem in shared libraries, it's just that it requires hacking inside std.stdio. So I'm just wondering whether I should: * pull those changes back in phobos * or if there's an alternative way of doing this Thanks!
Re: how to call std_stdio_static_this from a dynamically loaded shared library (osx)
On 2012-10-03 08:56, timotheecour wrote: Thanks for the links. Ya, I did see those threads and I understand there are limitations with dynamic load shared libraries, however, your answer is not very helpful. We shouldn't have to wait until they get 100% support to start using them (who knows when that happens); some applications just require them (eg writing matlab mex files). Yeah, it may not have been so helpful, sorry. In the meantime, the workaround I described above seems to adequately address the IO problem in shared libraries, it's just that it requires hacking inside std.stdio. So I'm just wondering whether I should: * pull those changes back in phobos * or if there's an alternative way of doing this Module constructors if one of the things that don't work properly. I don't know exactly how this works in std.stdio I would need to study the code. If I recall correctly std.stdio uses some kind of hack to avoid circular dependencies that can otherwise occur if two modules, both having module constructors, import each other. -- /Jacob Carlborg
Question about anonymous delegates.
I found something what I don't understand. Here is a simplifed code with comments: http://dpaste.dzfl.pl/a914d11a I creating anonymous delegates, whose function is to modify their parameter. Their parameters are different class references. I pass these class references to anonymous delegates, but the delegates obtain only the last passed class reference. Thanks for your answers.
Re: Question about anonymous delegates.
On 10/03/2012 03:53 PM, Sharp wrote:
I found something what I don't understand.
Here is a simplifed code with comments:
http://dpaste.dzfl.pl/a914d11a
I creating anonymous delegates, whose function is to modify their
parameter. Their parameters are different class references.
I pass these class references to anonymous delegates, but the delegates
obtain only the last passed class reference.
Thanks for your answers.
class Num {
int a;
}
void main(){
auto nums = new Num[10];
alias void delegate() Func;
auto funcs = new Func[10];
// workaround for
http://d.puremagic.com/issues/show_bug.cgi?id=2043 ahead:
for(int i = 0; i 10; ++i) (){
Num num = nums[i] = new Num();
int i=i; // fix for bug in your code
funcs[i] = {num.a = i;};
}();
foreach(num; nums) {
assert(num.a == 0);
}
foreach(func; funcs) {
func();
}
foreach(i, num; nums) {
assert(num.a == i);
}
}
Re: how to call std_stdio_static_this from a dynamically loaded shared library (osx)
Module constructors if one of the things that don't work
properly. I don't know exactly how this works in std.stdio I
would need to study the code. If I recall correctly std.stdio
uses some kind of hack to avoid circular dependencies that can
otherwise occur if two modules, both having module
constructors, import each other.
Yes, that hack consists in :
1) defining extern(C) void std_stdio_static_this() instead of
static this()
2) defining an auxiliary module std.stdiobase who will call it at
module construction:
module std.stdiobase;
extern(C) void std_stdio_static_this();
shared static this(){
std_stdio_static_this();
}
I'm still puzzled as to why modifying the code inside
std_stdio_static_this (say with assert(0)) doesn't have any
effect (hence the need for the templated version I'm using).
Another workaround (besides adding std_stdio_static_this2) would
be to make the field File.p non-private so that my
std_stdio_static_this2 could be defined outside std.stdio. Any
suggestion?
Re: how to call std_stdio_static_this from a dynamically loaded shared library (osx)
On 2012-10-03 20:23, timotheecour wrote:
Yes, that hack consists in :
1) defining extern(C) void std_stdio_static_this() instead of static this()
2) defining an auxiliary module std.stdiobase who will call it at module
construction:
module std.stdiobase;
extern(C) void std_stdio_static_this();
shared static this(){
std_stdio_static_this();
}
I'm still puzzled as to why modifying the code inside
std_stdio_static_this (say with assert(0)) doesn't have any effect
(hence the need for the templated version I'm using).
Another workaround (besides adding std_stdio_static_this2) would be to
make the field File.p non-private so that my std_stdio_static_this2
could be defined outside std.stdio. Any suggestion?
What happens if you just call std_stdio_static_this the first you do
in your main function?
Usually these kinds of problems are solved by using lazy initialization.
In this case that would mean converting stdin, stdout and stderr
to functions.
https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L2357
Something like this:
private __gshared
{
File _stdin;
File _stdout;
File _stderr;
File.Impl stdinImpl;
File.Impl stdoutImpl;
File.Impl stderrImpl;
}
@property File stdin ()
{
if (!_stdin.p)
_stdin.p = stdinImpl;
return _stdin;
}
The same for stdout and stderr. But this may not be good for
performance reasons. I don't know how good the compiler is at optimizing
these kind of functions.
--
/Jacob Carlborg
Re: how to call std_stdio_static_this from a dynamically loaded shared library (osx)
What happens if you just call std_stdio_static_this the first
you do in your main function?
In my case I can't: I don't have control over the main function
(it could be written in C for example).
@property File stdin ()
{
if (!_stdin.p)
_stdin.p = stdinImpl;
return _stdin;
}
I guess you also want to add inside the if(): stdinImpl.handle =
core.stdc.stdio.stdin;, etc.
The same for stdout and stderr. But this may not be good
for performance reasons. I don't know how good the compiler is
at optimizing these kind of functions.
I doubt the compiler can do much optimizing here, since the if
won't always be true, but probably IO is slow enough compared to
a branch so it might not matter.
That being said, templatizing std_stdio_static_this as above
would avoid branching at every single call to writeXX functions.
Would there be any disadvantage?
Also, I grepped for static_this, it appears this hack is only
used in 2 places:
* std.stdio (=stdiobase)
* std.process (=processinit)
So the same template trick could be used in those 2 places.
Re: Metaprogramming: check for ref
On Sunday, 30 September 2012 at 21:34:36 UTC, Andrej Mitrovic
wrote:
On 9/30/12, jerro a...@a.com wrote:
I think this should work:
template returnsRef(alias f)
{
enum bool returnsRef = is(typeof(
{
ParameterTypeTuple!f param;
auto ptr = f(param);
}));
}
Yep. We should add this to Phobos imo.
Was pull request fired for this? I'd like to subscribe to get
noticed when this will be in the phobos. If not, would you mind
if I add one?
Question about memoize
I've pasted a code sample here with a comment of what should be printed out: http://dpaste.dzfl.pl/02cfc280 memoize is taken straight from std.functional, I just added a writeln so I could see more about what was going on. slowFuncString should only be calculated twice with the input given: Once for Test1 and once for Test2 but it's being calculated every time. The same answer will probably answer both of these questions but: 1) Why does p = null when the tuple of Test2 is in the memo AA? 2) How does memoize appear to be adding more than one of the same key to the memo AA? Thanks.
