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
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.
A typical use case is to find the maximum of a range (there is
an example of this in the documentation at
http://dlang.org/phobos/std_algorithm.html#reduce). If you don't
know the highest possible value of elements, then you couldn't
come up with an appropriate seed for this case.
Fixing unse
While fiddling with this I came across something that seems odd
in the behaviour of reduce and wondered if it's intended. It
rather limits the usefulness of reduce with UFCS to "a + b" and
"a - b".
Reduce works correctly when provided with a seed argument:
reduce!"a + b + 2"(0, [1,1,1]).write
On Wednesday, 3 October 2012 at 01:21:38 UTC, ixid wrote:
If it were (range, seed) then there would be no problem:
[1,1,1].reduce!"a + b + 2"(0).writeln; // == 9
My thoughts exactly.
On Tuesday, 2 October 2012 at 22:13:10 UTC, Timon Gehr wrote:
On 10/03/2012 12:11 AM, Timon Gehr wrote:
...
$ cat ixidbench.d
module main;
import std.stdio, std.algorithm, std.range, std.datetime;
enum MAX = 10_000_000_000UL;
void main() {
StopWatch sw;
sw.start;
auto sum1 = MAX.
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
Do you know if here the problem is in Phobos or if I'm asking
Phobos to do something too much hard?
import std.algorithm: map, reduce;
import std.range: zip;
struct S {}
alias bool function(S) F;
F foo(T)(T) {
return p => true;
}
F bar(F r1, F r2) {
return p => true;
}
F spam(S[] ps) {
On Tuesday, 2 October 2012 at 22:13:10 UTC, Timon Gehr wrote:
On 10/03/2012 12:11 AM, Timon Gehr wrote:
...
$ cat ixidbench.d
module main;
import std.stdio, std.algorithm, std.range, std.datetime;
enum MAX = 10_000_000_000UL;
void main() {
StopWatch sw;
sw.start;
auto sum1 = MAX.
On 10/03/2012 12:11 AM, Timon Gehr wrote:
...
$ cat ixidbench.d
module main;
import std.stdio, std.algorithm, std.range, std.datetime;
enum MAX = 10_000_000_000UL;
void main() {
StopWatch sw;
sw.start;
auto sum1 = MAX.iota.map!(x => x * x).reduce!"a + b";
sw.stop;
sw
On 10/02/2012 10:48 PM, ixid wrote:
Without optimization the range and algorithm method takes about 10 times
as long as the simple code below it, with no array bounds checking and
optimization it takes six times as long. Why is the difference so huge?
I'd expect a moderate overhead but that's a b
On Tuesday, 2 October 2012 at 20:48:31 UTC, ixid wrote:
Without optimization the range and algorithm method takes about
10 times as long as the simple code below it, with no array
bounds checking and optimization it takes six times as long.
Why is the difference so huge? I'd expect a moderate o
Without optimization the range and algorithm method takes about
10 times as long as the simple code below it, with no array
bounds checking and optimization it takes six times as long. Why
is the difference so huge? I'd expect a moderate overhead but
that's a big difference.
module main;
impo
On Tuesday, 2 October 2012 at 09:48:00 UTC, Andrej Mitrovic wrote:
I'm sorry, I was completely wrong about STDAPI being extern(C).
I saw
EXTERN_C and immediately thought this was the calling
convention, it's
not:
#define STDAPI EXTERN_C HRESULT STDAPICALLTYPE
#define STDAPICAL
On 10/2/12, Jesse Phillips wrote:
> Thank you, making these changes did do the trick
As mentioned in the other thread I was wrong, it's extern(Windows),
but implib produced an import lib which didn't quite work. coffimplib
does the trick though.
On 10/2/12, Jesse Phillips wrote:
> I've made the changes needed to get past the linker error
I'm sorry, I was completely wrong about STDAPI being extern(C). I saw
EXTERN_C and immediately thought this was the calling convention, it's
not:
#define STDAPI EXTERN_C HRESULT STDAPIC
I haven't tried to use DMD 2.060 yet, will see if i've got time
later.
I'm trying to debug the Mac OS X port of DWT. Almost as soon as a DWT
application starts to process events I receive a segmentation fault. The
error happens in the "objc_msgSend" C function when calling an
Objective-C method. GDB backtrace:
http://pastebin.com/0fmUmPQ1
The source code of DWT
18 matches
Mail list logo
