Re: Will the D GC be awesome?

[Jacob Carlborg]

On 2012-10-09 00:44, Ben Davis wrote:


In fairness to Java, it does share the inner char array between strings
when you request a substring. (Inside the String class you'll find a
reference to a char array, and 'start' and 'count' ints.) The String
object itself though (which is small and wraps the char array reference)
is allocated new each time. Java's GC is rather good though, so it
totally gets away with it.


The Java GC is far superior than the one in D. But in D it's possible to 
write a parser that doesn't allocate during processing, it just need 
some pre-allocation before starting. This is all due to the array 
slicing, which I think is pretty cool. The XML parser in Tango is an 
example of this:


http://dotnot.org/blog/archives/2008/02/24/xml-benchmarks-tango-ups-the-ante/

http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/

https://github.com/SiegeLord/Tango-D2

http://www.dsource.org/projects/tango/docs/current/tango.text.xml.PullParser.html

--
/Jacob Carlborg

Re: Avoiding some template bloat?

[Philippe Sigaud]

On Tue, Oct 9, 2012 at 12:13 AM, bearophile  wrote:
> Maybe someone someday will want to implement two Phobos printing functions
> usable like this:
>
> writecfln!"%d %s"(10, "hello");
> writecf!"%d %s"(10, "hello");
>
> They accept a format string as template argument (format strings are often
> compile-time constants and sometimes they are computable on the fly at
> compile-time), verifies at compile time (calling another CTFE function in
> its template constraint) that the format string matches with the type tuple
> of the arguments, and then just call writefln()/writef() with the format
> string and arguments.

IIRC, I did that as an example in my template tutorial:

https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf?raw=true

(section 32, on page 167)

Code in

https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/templates_examples.tex#L2000

and below.

Re: Struct polymorphism?

[Era Scarecrow]

On Sunday, 7 October 2012 at 10:04:57 UTC, Era Scarecrow wrote:
What are the possibilities of struct polymorphism? What would 
be the issues with it? What if we wanted to use it in a limited 
sense?


Currently I'm experimenting with it since classes are too bulky 
for what I need, yet I really need some type of 
behavior/dynamic polymorphism. So far I have a working model. 
It takes the following limitations:


 A question of efficiency comes up. If at compile-time we can 
confirm only a couple branches/possibilities, then only those are 
considered during run-time. During optimization is that code just 
inlined to where it is called rather than the jump to opDispatch? 
Seems like it should if it's small enough, especially if there's 
only 1 possibility.



 Now I guess a question out there for you all. Who would be 
interested in an implementation and how would you use it? Does it 
seem like a good idea? How many levels would you want to use? 
One? Several levels allowing class-like inheritance?

Re: Preliminary submission - std.rational and std.typelist

[Arlen]

On Mon, Oct 8, 2012 at 4:37 PM, bearophile  wrote:
> Arlen:
>
>
>> Yes, std.math.abs and std.numeric.gcd are very easy to implement for
>> BigInt,
>
>
> Don doesn't agree regarding the gcd. To compute the gcd efficiently on large
> numbers you need not easy algorithms.
>
> See:
> http://d.puremagic.com/issues/show_bug.cgi?id=7102
>
> Bye,
> bearophile


gcd() is very easy to implement:

BigInt _gcd(BigInt a, BigInt b)
{
  enforce(a >= 0 && b >=0);
  while (b != 0) {
auto t = b;
b = a % b;
a = t;
  }
  return a;
}

It's not going to be the fastest or the most efficient, but it does
produce correct results, and that's the most important thing when
implementing mathematical functions IMO.  You can always improve the
performance later.  Implementing pow(), on the other hand, is very
difficult and complex.

Re: Will the D GC be awesome?

[Era Scarecrow]

On Thursday, 4 October 2012 at 05:33:21 UTC, Walter Bright wrote:

On 10/3/2012 2:26 PM, DypthroposTheImposter wrote:

* OpCmp returning an int is fugly I r sad


How else would you return a 3 state value?


 Via enums.

 enum CmpValues { lessThan = -1, equal = 0, greaterThan = 1}

 But then again, the enum is convertible to int :P. I think ints 
(or size_t) are just fine and do their job.

Re: core.simd woes

[David Nadlinger]

On Monday, 8 October 2012 at 21:36:08 UTC, F i L wrote:

Iain Buclaw wrote:

float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];

===>
   movss   -16(%rbp), %xmm0
   movss   -12(%rbp), %xmm1


Nice, not even DMD can do this yet. Can these changes be pushed 
upstream?


No, the actual codegen is compilers-specific (and apparently 
wrong in the case of GDC, if this is the actual piece of code 
emitted for the code snippet).



On a side note, I understand GDC doesn't support the 
core.simd.__simd(...) command, and I'm sure you have good 
reasons for this. However, it would still be nice if:


a) this interface was supported through function-wrappers, or..
b) DMD/LDC could find common ground with GDC in SIMD 
instructions


LDC won't support core.simd.__simd in the forseeable future 
either. The reason is that it is a) untyped and b) highly 
x86-specific, both of which make it hard to integrate with LLVM 
– __simd is really just a glorified inline assembly expression 
(hm, this makes me think, maybe it could be implemented quite 
easily in terms of a transformation to LLVM inline assembly 
expressions…).


Is core.simd designed to really never be used and Manu's 
std.simd is really the starting place for libraries? (I believe 
I remember him mentioning that)


With all due respect to Walter, core.simd isn't really "designed" 
much at all, or at least this isn't visible in its current state 
– it rather seems like a quick hack to get some basic SIMD code 
working with DMD (but beware of ICEs).


Walter, if you are following this thread, do you have any plans 
for SIMD on non-x86 platforms?


David

Re: core.simd woes

[Iain Buclaw]

On 9 October 2012 00:38, F i L  wrote:
> Iain Buclaw wrote:
>>
>> I'm refusing to implement any intrinsic that is tied to a specific
>> architecture.
>
>
> I see. So the __builtin_ia32_***() functions in gcc.builtins are
> architecture agnostic? I couldn't find much documentation about them on the
> web. Do you have any references you could pass on?
>
> I guess it makes sense to just make std.simd the lib everyone uses for a
> "base-line" support of SIMD and let DMD do what it wants with it's core.simd
> lib. It sounds like gcc.builtins is just a layer above core.simd anyways.
> Although now it seems that DMD's std.simd will need a bunch of 'static if
> (architectureX) { ... }' for every GDC builtin... wounder if later that
> shouldn't be moved to (and standerized) a 'core.builtins' module or
> something.
>
> Thanks for the explanation.

gcc.builtins does something different depending on architecure, and
target cpu flags.  All I do is take what gcc backend gives to the
frontend, and hash it out to D.  What I meant is that I won't
implement a frontend intrinsic that...

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: core.simd woes

[F i L]

Iain Buclaw wrote:
I'm refusing to implement any intrinsic that is tied to a 
specific architecture.


I see. So the __builtin_ia32_***() functions in gcc.builtins are 
architecture agnostic? I couldn't find much documentation about 
them on the web. Do you have any references you could pass on?


I guess it makes sense to just make std.simd the lib everyone 
uses for a "base-line" support of SIMD and let DMD do what it 
wants with it's core.simd lib. It sounds like gcc.builtins is 
just a layer above core.simd anyways. Although now it seems that 
DMD's std.simd will need a bunch of 'static if (architectureX) { 
... }' for every GDC builtin... wounder if later that shouldn't 
be moved to (and standerized) a 'core.builtins' module or 
something.


Thanks for the explanation.

Re: core.simd woes

[David Nadlinger]

On Monday, 8 October 2012 at 20:23:50 UTC, Iain Buclaw wrote:

float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];

===>
movss   -16(%rbp), %xmm0
movss   -12(%rbp), %xmm1


The obligatory "me too" post:

LDC turns

---
import core.simd;

struct T {
float a, b, c, d;
ubyte[100] passOnStack;
}

void test(T t) {
receiver([t.a, t.b, t.c, t.d]);
}

void receiver(float4 f);
---

into

---
 <_D4test4testFS4test1TZv>:
   0:   50  push   rax
   1:   0f 28 44 24 10  movaps xmm0,XMMWORD PTR [rsp+0x10]
   6:   e8 00 00 00 00  call   b 
<_D4test4testFS4test1TZv+0xb>

   b:   58  poprax
   c:   c3  ret
---

(the struct is just there so that the values are actually on the 
stack, and receiver just so that the optimizer doesn't eat 
everything for breakfast).


David

Re: Will the D GC be awesome?

[Ben Davis]

On 06/10/2012 04:03, Chad J wrote:

Try to do array slicing in Java or C#.  You probably won't be able to do
it.  You'll get string /copies/ and this will incur heap allocations in
the GC heap.  Those languages /need/ good garbage collection to be
performant because they abuse the poor GC heavily.


In fairness to Java, it does share the inner char array between strings 
when you request a substring. (Inside the String class you'll find a 
reference to a char array, and 'start' and 'count' ints.) The String 
object itself though (which is small and wraps the char array reference) 
is allocated new each time. Java's GC is rather good though, so it 
totally gets away with it.

Re: Avoiding some template bloat?

[bearophile]

(if necessary slicing the fixed sized matrix into a dynamic 
array of dynamic arrays).


It's not hard to convert a fixed sized matrix into this run-time 
value that requires no templating on the sizes and requires no 
slicing and no heap allocations inside the template function that 
performs just the compile-time tests:


struct Mat2D(T) {
T* ptr;
size_t nrows, ncols;
// + indexing methods
}

Using something like that the matrix multiplication function I've 
shown becomes just a shell that calls a function that accepts two 
Mat2D and is templated only on T.


Bye,
bearophile

Re: Struct polymorphism?

[Era Scarecrow]

  Error: function expected before (), not 
'this.polyBase.opDispatch!("orig")'


  I think this is a compiler bug. It complains about calling
opDispatch, however it doesn't complain if you explicitly call
'this'. Should adding 'this' be required? I am using the
-property switch so it's a little more strict, but that doesn't
seem to change the results. I can't just start adding 'this' to
all my function as outside normal functions/variables won't ever
be seen.

struct S {
  Something polyBase;
  alias polyBase this;  //opDispatch

  string callsOrig() {
return orig;//works but misleading
return orig();  //breaks
return orig(1); //breaks too
return this.orig(); //works
  }
}

struct Something {
  auto ref opDispatch(string fun, Args ...)(auto ref Args args)
@property;
}

  My experiments concentrating on this part rather than with
arguments, those will come later when this works.

Re: DMD 2.060

[Ben Davis]

On 07/10/2012 11:39, Walter Bright wrote:

On 10/7/2012 3:12 AM, Alex Rønne Petersen wrote:

On 07-10-2012 11:11, Russel Winder wrote:

Any news on the "regressions" relating to threads in the 2.059 → 2.060
change? Is a 2.061 with fixes pending?


I'm still not clear on what these regressions are?



A list of relevant bugzilla entries would be illuminating.


Not sure I can come up with a list, but here's one that affects me:

http://d.puremagic.com/issues/show_bug.cgi?id=8621

Avoiding some template bloat?

[bearophile]

Maybe someone someday will want to implement two Phobos printing 
functions usable like this:


writecfln!"%d %s"(10, "hello");
writecf!"%d %s"(10, "hello");

They accept a format string as template argument (format strings 
are often compile-time constants and sometimes they are 
computable on the fly at compile-time), verifies at compile time 
(calling another CTFE function in its template constraint) that 
the format string matches with the type tuple of the arguments, 
and then just call writefln()/writef() with the format string and 
arguments.


This variable-length-templated function avoids format string 
errors at run-time. This in my opinion means taking advantage of 
the static typing of D to avoid some bugs. In my opinion it's 
silly to use a language with static typing, unlike Python, and 
then _not_ use such static knowledge where it's usable and useful.


Using "%s" everywhere in writefln/writef is an option, but it's 
not always usable, like when you want to use the advanced new 
formatting syntax for arrays.


writecfln() and writecf() just call writefln/writef, so they are 
very light, in the binary they just call another function. But if 
there are many different format strings you get many similar 
useless little functions in the binary (maybe inlined).


Is it possible for the D compiler to avoid the (small amount of?) 
template bloat caused by writecfln/writecf? Is it useful to 
introduce some kind of annotation to tell the compiler to 
avoid/remove any bloat for similar functions turning them 
essentially into just compile-time tests for writefln/writef? Or 
is it enough to rely on the inliner of the compiler?


Beside writecfln()/writecf() I have other use cases for such 
ideas. When I write certain kind of matrix code that use 
fixed-sized 2D matrices, they enforce the correct sizes at 
compile-time, but then they just call functions that use run-time 
sized arrays, to avoid template bloat (if necessary slicing the 
fixed sized matrix into a dynamic array of dynamic arrays). In 
this case too I'd like to minimize or remove template bloat and 
just have compile-time tests on data that is then managed with 
run-time sizes (so it's not actually templated on the size of the 
matrix).


Here you see a little example, regarding matrix multiplication 
(here it doesn't call another function with run-time sizes, so 
this is really templated):



template TMMul(M1, M2) { // helper
alias Unqual!(typeof(M1[0][0]))[M2[0].length][M1.length] 
TMMul;

}

void matrixMul(T, T2, size_t k, size_t m, size_t n)
  (in ref T[m][k] A, in ref T[n][m] B,
   ref T2[n][k] result) pure nothrow
if (is(T2 == Unqual!T)) {
T2[m] aux;
foreach (j; 0 .. n) {
foreach (k, row; B)
aux[k] = row[j];
foreach (i, ai; A)
result[i][j] = dotProduct(ai, aux);
}
}


A third use case for such need is a poor's man "homemade" 
management of integer-indexed dependent types. In such cases you 
use the compile-time known sizes and values to enforce 
compile-time sanity constraints, but then you use normal run-time 
not-templated functions to avoid useless template bloat. This 
means the compile-time values are meant to be used just by the 
type system to verify things, but the functions are not actually 
templated. Similar ghost types and other types that vanish are 
commonly used in functional languages, like OCaML. Avoiding any 
template bloat when you do such things is kind of needed, unless 
you want to produce large binaries that do little at run time.


Bye,
bearophile

Re: Preliminary submission - std.rational and std.typelist

[bearophile]

Arlen:

Yes, std.math.abs and std.numeric.gcd are very easy to 
implement for BigInt,


Don doesn't agree regarding the gcd. To compute the gcd 
efficiently on large numbers you need not easy algorithms.


See:
http://d.puremagic.com/issues/show_bug.cgi?id=7102

Bye,
bearophile

Re: core.simd woes

[Iain Buclaw]

On 8 October 2012 22:34, Manu  wrote:
> On 9 October 2012 00:30, Iain Buclaw  wrote:
>>
>> On 8 October 2012 22:18, F i L  wrote:
>> > Iain Buclaw wrote:
>> >>
>> >> I fixed them again.
>> >>
>> >>
>> >>
>> >> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
>> >>
>> >>
>> >> float a = 1, b = 2, c = 3, d = 4;
>> >> float4 f = [a,b,c,d];
>> >>
>> >> ===>
>> >> movss   -16(%rbp), %xmm0
>> >> movss   -12(%rbp), %xmm1
>> >
>> >
>> > Nice, not even DMD can do this yet. Can these changes be pushed
>> > upstream?
>> >
>> > On a side note, I understand GDC doesn't support the
>> > core.simd.__simd(...)
>> > command, and I'm sure you have good reasons for this. However, it would
>> > still be nice if:
>> >
>> > a) this interface was supported through function-wrappers, or..
>> > b) DMD/LDC could find common ground with GDC in SIMD instructions
>> >
>> > I just think this sort of difference should be worked out early on. If
>> > this
>> > simply can't or won't be changed, would you mind giving a short
>> > explanation
>> > as to why? (Please forgive if you've explained this already before). Is
>> > core.simd designed to really never be used and Manu's std.simd is really
>> > the
>> > starting place for libraries? (I believe I remember him mentioning that)
>> >
>>
>> I'm refusing to implement any intrinsic that is tied to a specific
>> architecture.
>
>
> GCC offers perfectly good intrinsics anyway. And they're superior to the DMD
> intrinsics too.
>

Provided that a) the architecture provides them, and b) you have the
right -march/-mtune flags turned on.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: core.simd woes

[Manu]

On 9 October 2012 00:30, Iain Buclaw  wrote:

> On 8 October 2012 22:18, F i L  wrote:
> > Iain Buclaw wrote:
> >>
> >> I fixed them again.
> >>
> >>
> >>
> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
> >>
> >>
> >> float a = 1, b = 2, c = 3, d = 4;
> >> float4 f = [a,b,c,d];
> >>
> >> ===>
> >> movss   -16(%rbp), %xmm0
> >> movss   -12(%rbp), %xmm1
> >
> >
> > Nice, not even DMD can do this yet. Can these changes be pushed upstream?
> >
> > On a side note, I understand GDC doesn't support the
> core.simd.__simd(...)
> > command, and I'm sure you have good reasons for this. However, it would
> > still be nice if:
> >
> > a) this interface was supported through function-wrappers, or..
> > b) DMD/LDC could find common ground with GDC in SIMD instructions
> >
> > I just think this sort of difference should be worked out early on. If
> this
> > simply can't or won't be changed, would you mind giving a short
> explanation
> > as to why? (Please forgive if you've explained this already before). Is
> > core.simd designed to really never be used and Manu's std.simd is really
> the
> > starting place for libraries? (I believe I remember him mentioning that)
> >
>
> I'm refusing to implement any intrinsic that is tied to a specific
> architecture.
>

GCC offers perfectly good intrinsics anyway. And they're superior to the
DMD intrinsics too.

Re: core.simd woes

[Manu]

On 9 October 2012 00:29, Iain Buclaw  wrote:

> On 8 October 2012 22:18, Manu  wrote:
> > On 8 October 2012 23:05, Iain Buclaw  wrote:
> >>
> >> On 7 October 2012 13:12, Manu  wrote:
> >> > On 5 October 2012 14:46, Iain Buclaw  wrote:
> >> >>
> >> >> On 5 October 2012 11:28, Manu  wrote:
> >> >> > On 3 October 2012 16:40, Iain Buclaw  wrote:
> >> >> >>
> >> >> >> On 3 October 2012 02:31, jerro  wrote:
> >> >> >> >> import core.simd, std.stdio;
> >> >> >> >>
> >> >> >> >> void main()
> >> >> >> >> {
> >> >> >> >>   float4 a = 1, b = 2;
> >> >> >> >>   writeln((a + b).array); // WORKS: [3, 3, 3, 3]
> >> >> >> >>
> >> >> >> >>   float4 c = [1, 2, 3, 4]; // ERROR: "Stored value type does
> >> >> >> >>// not match pointer operand type!"
> >> >> >> >>// [..a bunch of LLVM error code..]
> >> >> >> >>
> >> >> >> >>   float4 c = 0, d = 1;
> >> >> >> >>   c.array[0] = 4;
> >> >> >> >>   c.ptr[1] = 4;
> >> >> >> >>   writeln((c + d).array); // WRONG: [1, 1, 1, 1]
> >> >> >> >> }
> >> >> >> >
> >> >> >> >
> >> >> >> > Oh, that doesn't work for me either. I never tried to use those,
> >> >> >> > so I
> >> >> >> > didn't
> >> >> >> > notice that before. This code gives me internal compiler errors
> >> >> >> > with
> >> >> >> > GDC
> >> >> >> > and
> >> >> >> > DMD too (with "float4 c = [1, 2, 3, 4]" commented out). I'm
> using
> >> >> >> > DMD
> >> >> >> > 2.060
> >> >> >> > and a recent versions of GDC and LDC on 64 bit Linux.
> >> >> >>
> >> >> >> Then don't just talk about it, raise a bug - otherwise how do you
> >> >> >> expect it to get fixed!  ( http://www.gdcproject.org/bugzilla )
> >> >> >>
> >> >> >> I've made a note of the error you get with `__vector(float[4]) c =
> >> >> >> [1,2,3,4];' - That is because vector expressions implementation is
> >> >> >> very basic at the moment.  Look forward to hear from all your
> >> >> >> experiences so we can make vector support rock solid in GDC. ;-)
> >> >> >
> >> >> >
> >> >> > I didn't realise vector literals like that were supported properly
> in
> >> >> > the
> >> >> > front end yet?
> >> >> > Do they work at all? What does the code generated look like?
> >> >>
> >> >> They get passed to the backend as of 2.060 - so looks like the
> >> >> semantic passes now allow them.
> >> >>
> >> >> I've just recently added backend support in GDC -
> >> >>
> >> >>
> >> >>
> https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
> >> >>
> >> >> The codegen looks like so:
> >> >>
> >> >> float4 a = 2;
> >> >> float4 b = [1,2,3,4];
> >> >>
> >> >> ==>
> >> >> vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> >> >> vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
> >> >>
> >> >> ==>
> >> >> movaps  .LC0, %xmm0
> >> >> movaps  %xmm0, -24(%ebp)
> >> >> movaps  .LC1, %xmm0
> >> >> movaps  %xmm0, -40(%ebp)
> >> >>
> >> >> .align 16
> >> >> .LC0:
> >> >> .long   1073741824
> >> >> .long   1073741824
> >> >> .long   1073741824
> >> >> .long   1073741824
> >> >> .align 16
> >> >> .LC1:
> >> >> .long   1065353216
> >> >> .long   1073741824
> >> >> .long   1077936128
> >> >> .long   1082130432
> >> >
> >> >
> >> > Perfect!
> >> > I can get on with my unittests :P
> >>
> >> I fixed them again.
> >>
> >>
> >>
> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
> >>
> >>
> >> float a = 1, b = 2, c = 3, d = 4;
> >> float4 f = [a,b,c,d];
> >>
> >> ===>
> >> movss   -16(%rbp), %xmm0
> >> movss   -12(%rbp), %xmm1
> >
> >
> > Errr, that's not fixed...?
> > movss is not the opcode you're looking for.
> > Surely that should produce a single movaps...
>
> I didn't say I compiled with optimisations - only -march=native.  =)
>

Either way, that code is wrong. The prior code was correct (albeit with the
redundant store, which I presume would have gone away with optimisation
enabled)

Re: core.simd woes

[Manu]

On 9 October 2012 00:29, Iain Buclaw  wrote:

> On 8 October 2012 22:18, Manu  wrote:
> > On 8 October 2012 23:05, Iain Buclaw  wrote:
> >>
> >> On 7 October 2012 13:12, Manu  wrote:
> >> > On 5 October 2012 14:46, Iain Buclaw  wrote:
> >> >>
> >> >> On 5 October 2012 11:28, Manu  wrote:
> >> >> > On 3 October 2012 16:40, Iain Buclaw  wrote:
> >> >> >>
> >> >> >> On 3 October 2012 02:31, jerro  wrote:
> >> >> >> >> import core.simd, std.stdio;
> >> >> >> >>
> >> >> >> >> void main()
> >> >> >> >> {
> >> >> >> >>   float4 a = 1, b = 2;
> >> >> >> >>   writeln((a + b).array); // WORKS: [3, 3, 3, 3]
> >> >> >> >>
> >> >> >> >>   float4 c = [1, 2, 3, 4]; // ERROR: "Stored value type does
> >> >> >> >>// not match pointer operand type!"
> >> >> >> >>// [..a bunch of LLVM error code..]
> >> >> >> >>
> >> >> >> >>   float4 c = 0, d = 1;
> >> >> >> >>   c.array[0] = 4;
> >> >> >> >>   c.ptr[1] = 4;
> >> >> >> >>   writeln((c + d).array); // WRONG: [1, 1, 1, 1]
> >> >> >> >> }
> >> >> >> >
> >> >> >> >
> >> >> >> > Oh, that doesn't work for me either. I never tried to use those,
> >> >> >> > so I
> >> >> >> > didn't
> >> >> >> > notice that before. This code gives me internal compiler errors
> >> >> >> > with
> >> >> >> > GDC
> >> >> >> > and
> >> >> >> > DMD too (with "float4 c = [1, 2, 3, 4]" commented out). I'm
> using
> >> >> >> > DMD
> >> >> >> > 2.060
> >> >> >> > and a recent versions of GDC and LDC on 64 bit Linux.
> >> >> >>
> >> >> >> Then don't just talk about it, raise a bug - otherwise how do you
> >> >> >> expect it to get fixed!  ( http://www.gdcproject.org/bugzilla )
> >> >> >>
> >> >> >> I've made a note of the error you get with `__vector(float[4]) c =
> >> >> >> [1,2,3,4];' - That is because vector expressions implementation is
> >> >> >> very basic at the moment.  Look forward to hear from all your
> >> >> >> experiences so we can make vector support rock solid in GDC. ;-)
> >> >> >
> >> >> >
> >> >> > I didn't realise vector literals like that were supported properly
> in
> >> >> > the
> >> >> > front end yet?
> >> >> > Do they work at all? What does the code generated look like?
> >> >>
> >> >> They get passed to the backend as of 2.060 - so looks like the
> >> >> semantic passes now allow them.
> >> >>
> >> >> I've just recently added backend support in GDC -
> >> >>
> >> >>
> >> >>
> https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
> >> >>
> >> >> The codegen looks like so:
> >> >>
> >> >> float4 a = 2;
> >> >> float4 b = [1,2,3,4];
> >> >>
> >> >> ==>
> >> >> vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> >> >> vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
> >> >>
> >> >> ==>
> >> >> movaps  .LC0, %xmm0
> >> >> movaps  %xmm0, -24(%ebp)
> >> >> movaps  .LC1, %xmm0
> >> >> movaps  %xmm0, -40(%ebp)
> >> >>
> >> >> .align 16
> >> >> .LC0:
> >> >> .long   1073741824
> >> >> .long   1073741824
> >> >> .long   1073741824
> >> >> .long   1073741824
> >> >> .align 16
> >> >> .LC1:
> >> >> .long   1065353216
> >> >> .long   1073741824
> >> >> .long   1077936128
> >> >> .long   1082130432
> >> >
> >> >
> >> > Perfect!
> >> > I can get on with my unittests :P
> >>
> >> I fixed them again.
> >>
> >>
> >>
> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
> >>
> >>
> >> float a = 1, b = 2, c = 3, d = 4;
> >> float4 f = [a,b,c,d];
> >>
> >> ===>
> >> movss   -16(%rbp), %xmm0
> >> movss   -12(%rbp), %xmm1
> >
> >
> > Errr, that's not fixed...?
> > movss is not the opcode you're looking for.
> > Surely that should produce a single movaps...
>
> I didn't say I compiled with optimisations - only -march=native.  =)
>

Either way, that code is wrong. The prior code was correct (albeit with the
redundant store, which I presume would have gone away with optimisation
enabled)

Re: core.simd woes

[Iain Buclaw]

On 8 October 2012 22:18, F i L  wrote:
> Iain Buclaw wrote:
>>
>> I fixed them again.
>>
>>
>> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
>>
>>
>> float a = 1, b = 2, c = 3, d = 4;
>> float4 f = [a,b,c,d];
>>
>> ===>
>> movss   -16(%rbp), %xmm0
>> movss   -12(%rbp), %xmm1
>
>
> Nice, not even DMD can do this yet. Can these changes be pushed upstream?
>
> On a side note, I understand GDC doesn't support the core.simd.__simd(...)
> command, and I'm sure you have good reasons for this. However, it would
> still be nice if:
>
> a) this interface was supported through function-wrappers, or..
> b) DMD/LDC could find common ground with GDC in SIMD instructions
>
> I just think this sort of difference should be worked out early on. If this
> simply can't or won't be changed, would you mind giving a short explanation
> as to why? (Please forgive if you've explained this already before). Is
> core.simd designed to really never be used and Manu's std.simd is really the
> starting place for libraries? (I believe I remember him mentioning that)
>

I'm refusing to implement any intrinsic that is tied to a specific architecture.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: core.simd woes

[Manu]

On 9 October 2012 00:18, F i L  wrote:

> Iain Buclaw wrote:
>
>> I fixed them again.
>>
>> https://github.com/D-**Programming-GDC/GDC/commit/**
>> 9402516e0b07031e841a15849f5dc9**4ae81dccdc#L4R1201
>>
>>
>> float a = 1, b = 2, c = 3, d = 4;
>> float4 f = [a,b,c,d];
>>
>> ===>
>> movss   -16(%rbp), %xmm0
>> movss   -12(%rbp), %xmm1
>>
>
> Nice, not even DMD can do this yet. Can these changes be pushed upstream?
>
> On a side note, I understand GDC doesn't support the core.simd.__simd(...)
> command, and I'm sure you have good reasons for this. However, it would
> still be nice if:
>
> a) this interface was supported through function-wrappers, or..
> b) DMD/LDC could find common ground with GDC in SIMD instructions
>
> I just think this sort of difference should be worked out early on. If
> this simply can't or won't be changed, would you mind giving a short
> explanation as to why? (Please forgive if you've explained this already
> before). Is core.simd designed to really never be used and Manu's std.simd
> is really the starting place for libraries? (I believe I remember him
> mentioning that)
>

core.simd just provides what the compiler provides in it's most primal
state. As far as I'm concerned, it's just not meant to be used directly
except by library authors.
It's possible that a uniform suite of names could be made to wrap all the
compiler-specific names (ldc is different again), but that would just get
wrapped a second time one level higher. Hardly seems worth the effort.

Re: core.simd woes

[Iain Buclaw]

On 8 October 2012 22:18, Manu  wrote:
> On 8 October 2012 23:05, Iain Buclaw  wrote:
>>
>> On 7 October 2012 13:12, Manu  wrote:
>> > On 5 October 2012 14:46, Iain Buclaw  wrote:
>> >>
>> >> On 5 October 2012 11:28, Manu  wrote:
>> >> > On 3 October 2012 16:40, Iain Buclaw  wrote:
>> >> >>
>> >> >> On 3 October 2012 02:31, jerro  wrote:
>> >> >> >> import core.simd, std.stdio;
>> >> >> >>
>> >> >> >> void main()
>> >> >> >> {
>> >> >> >>   float4 a = 1, b = 2;
>> >> >> >>   writeln((a + b).array); // WORKS: [3, 3, 3, 3]
>> >> >> >>
>> >> >> >>   float4 c = [1, 2, 3, 4]; // ERROR: "Stored value type does
>> >> >> >>// not match pointer operand type!"
>> >> >> >>// [..a bunch of LLVM error code..]
>> >> >> >>
>> >> >> >>   float4 c = 0, d = 1;
>> >> >> >>   c.array[0] = 4;
>> >> >> >>   c.ptr[1] = 4;
>> >> >> >>   writeln((c + d).array); // WRONG: [1, 1, 1, 1]
>> >> >> >> }
>> >> >> >
>> >> >> >
>> >> >> > Oh, that doesn't work for me either. I never tried to use those,
>> >> >> > so I
>> >> >> > didn't
>> >> >> > notice that before. This code gives me internal compiler errors
>> >> >> > with
>> >> >> > GDC
>> >> >> > and
>> >> >> > DMD too (with "float4 c = [1, 2, 3, 4]" commented out). I'm using
>> >> >> > DMD
>> >> >> > 2.060
>> >> >> > and a recent versions of GDC and LDC on 64 bit Linux.
>> >> >>
>> >> >> Then don't just talk about it, raise a bug - otherwise how do you
>> >> >> expect it to get fixed!  ( http://www.gdcproject.org/bugzilla )
>> >> >>
>> >> >> I've made a note of the error you get with `__vector(float[4]) c =
>> >> >> [1,2,3,4];' - That is because vector expressions implementation is
>> >> >> very basic at the moment.  Look forward to hear from all your
>> >> >> experiences so we can make vector support rock solid in GDC. ;-)
>> >> >
>> >> >
>> >> > I didn't realise vector literals like that were supported properly in
>> >> > the
>> >> > front end yet?
>> >> > Do they work at all? What does the code generated look like?
>> >>
>> >> They get passed to the backend as of 2.060 - so looks like the
>> >> semantic passes now allow them.
>> >>
>> >> I've just recently added backend support in GDC -
>> >>
>> >>
>> >> https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
>> >>
>> >> The codegen looks like so:
>> >>
>> >> float4 a = 2;
>> >> float4 b = [1,2,3,4];
>> >>
>> >> ==>
>> >> vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
>> >> vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
>> >>
>> >> ==>
>> >> movaps  .LC0, %xmm0
>> >> movaps  %xmm0, -24(%ebp)
>> >> movaps  .LC1, %xmm0
>> >> movaps  %xmm0, -40(%ebp)
>> >>
>> >> .align 16
>> >> .LC0:
>> >> .long   1073741824
>> >> .long   1073741824
>> >> .long   1073741824
>> >> .long   1073741824
>> >> .align 16
>> >> .LC1:
>> >> .long   1065353216
>> >> .long   1073741824
>> >> .long   1077936128
>> >> .long   1082130432
>> >
>> >
>> > Perfect!
>> > I can get on with my unittests :P
>>
>> I fixed them again.
>>
>>
>> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
>>
>>
>> float a = 1, b = 2, c = 3, d = 4;
>> float4 f = [a,b,c,d];
>>
>> ===>
>> movss   -16(%rbp), %xmm0
>> movss   -12(%rbp), %xmm1
>
>
> Errr, that's not fixed...?
> movss is not the opcode you're looking for.
> Surely that should produce a single movaps...

I didn't say I compiled with optimisations - only -march=native.  =)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: What is the case against a struct post-blit default constructor?

[F i L]

+1 to all of that.

If the only issue is performance, I think the best solution is 
just to Document with a warning against using default 
constructors in performance critical structs.

Re: core.simd woes

[F i L]

Iain Buclaw wrote:

I fixed them again.

https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201


float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];

===>
movss   -16(%rbp), %xmm0
movss   -12(%rbp), %xmm1


Nice, not even DMD can do this yet. Can these changes be pushed 
upstream?


On a side note, I understand GDC doesn't support the 
core.simd.__simd(...) command, and I'm sure you have good reasons 
for this. However, it would still be nice if:


a) this interface was supported through function-wrappers, or..
b) DMD/LDC could find common ground with GDC in SIMD instructions

I just think this sort of difference should be worked out early 
on. If this simply can't or won't be changed, would you mind 
giving a short explanation as to why? (Please forgive if you've 
explained this already before). Is core.simd designed to really 
never be used and Manu's std.simd is really the starting place 
for libraries? (I believe I remember him mentioning that)

Re: core.simd woes

[Manu]

On 8 October 2012 23:05, Iain Buclaw  wrote:

> On 7 October 2012 13:12, Manu  wrote:
> > On 5 October 2012 14:46, Iain Buclaw  wrote:
> >>
> >> On 5 October 2012 11:28, Manu  wrote:
> >> > On 3 October 2012 16:40, Iain Buclaw  wrote:
> >> >>
> >> >> On 3 October 2012 02:31, jerro  wrote:
> >> >> >> import core.simd, std.stdio;
> >> >> >>
> >> >> >> void main()
> >> >> >> {
> >> >> >>   float4 a = 1, b = 2;
> >> >> >>   writeln((a + b).array); // WORKS: [3, 3, 3, 3]
> >> >> >>
> >> >> >>   float4 c = [1, 2, 3, 4]; // ERROR: "Stored value type does
> >> >> >>// not match pointer operand type!"
> >> >> >>// [..a bunch of LLVM error code..]
> >> >> >>
> >> >> >>   float4 c = 0, d = 1;
> >> >> >>   c.array[0] = 4;
> >> >> >>   c.ptr[1] = 4;
> >> >> >>   writeln((c + d).array); // WRONG: [1, 1, 1, 1]
> >> >> >> }
> >> >> >
> >> >> >
> >> >> > Oh, that doesn't work for me either. I never tried to use those,
> so I
> >> >> > didn't
> >> >> > notice that before. This code gives me internal compiler errors
> with
> >> >> > GDC
> >> >> > and
> >> >> > DMD too (with "float4 c = [1, 2, 3, 4]" commented out). I'm using
> DMD
> >> >> > 2.060
> >> >> > and a recent versions of GDC and LDC on 64 bit Linux.
> >> >>
> >> >> Then don't just talk about it, raise a bug - otherwise how do you
> >> >> expect it to get fixed!  ( http://www.gdcproject.org/bugzilla )
> >> >>
> >> >> I've made a note of the error you get with `__vector(float[4]) c =
> >> >> [1,2,3,4];' - That is because vector expressions implementation is
> >> >> very basic at the moment.  Look forward to hear from all your
> >> >> experiences so we can make vector support rock solid in GDC. ;-)
> >> >
> >> >
> >> > I didn't realise vector literals like that were supported properly in
> >> > the
> >> > front end yet?
> >> > Do they work at all? What does the code generated look like?
> >>
> >> They get passed to the backend as of 2.060 - so looks like the
> >> semantic passes now allow them.
> >>
> >> I've just recently added backend support in GDC -
> >>
> >>
> https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
> >>
> >> The codegen looks like so:
> >>
> >> float4 a = 2;
> >> float4 b = [1,2,3,4];
> >>
> >> ==>
> >> vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> >> vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
> >>
> >> ==>
> >> movaps  .LC0, %xmm0
> >> movaps  %xmm0, -24(%ebp)
> >> movaps  .LC1, %xmm0
> >> movaps  %xmm0, -40(%ebp)
> >>
> >> .align 16
> >> .LC0:
> >> .long   1073741824
> >> .long   1073741824
> >> .long   1073741824
> >> .long   1073741824
> >> .align 16
> >> .LC1:
> >> .long   1065353216
> >> .long   1073741824
> >> .long   1077936128
> >> .long   1082130432
> >
> >
> > Perfect!
> > I can get on with my unittests :P
>
> I fixed them again.
>
>
> https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201
>
>
> float a = 1, b = 2, c = 3, d = 4;
> float4 f = [a,b,c,d];
>
> ===>
> movss   -16(%rbp), %xmm0
> movss   -12(%rbp), %xmm1
>

Errr, that's not fixed...?
movss is not the opcode you're looking for.
Surely that should produce a single movaps...

Re: Preliminary submission - std.rational and std.typelist

[Ellery Newcomer]

On 10/08/2012 07:56 AM, Aziz K. wrote:


Incidentally, I would very much need a BigFloat class/struct, written in
D and independent of any C library.
I'm trying to write one myself, but it seems to be rather tricky. Could
this be implemented in a short amount of time by someone with more
knowledge about this topic?



Wasn't Paul D. Anderson working on a BigFloat?

Re: [OT] Re: Windows DLLs and TLS

[Rainer Schuetze]

On 10/8/2012 8:13 PM, Denis Shelomovskij wrote:

08.10.2012 21:47, Rainer Schuetze пишет:

Implicite TLS for dynamically loaded DLLs is
not supported by XP or Sever 2003, so druntime contains a fix to
simulate it. (The workaround has the drawback that the DLL cannot be
unloaded anymore.)

I'm just speculating, maybe something goes wrong with the tls_index
variable, reading TLS variables would then access data from another DLL.

Is your code doing callbacks into the host application in static
initializers? With the XP workaround, the runtime initialization
"impersonates" all threads that exist before loading the DLL, by
switching the TLS-pointer array of the current thread, and that might be
unexpected in a callback (but not doing this might produce even more
unexpected results).


Here you are! Just want to mention that I'm currently managed to publish
my (continuation of your) TLS fix I did half a year before. It will
finally solve this XP/Sever 2003 problem. It is available here but isn't
finished now (fill be in few days):
https://github.com/denis-sh/hooking/tree/master/tlsfixer


Will this fix both issues (not being able to unload and that imperfect 
simulation of DLL_THREAD_ATTACH for existing threads)? That would be 
very cool.




I hope you aren't against it is based on your work?



Sure, no problem. It's boost licensed, isn't it? ;-)

Re: core.simd woes

[Iain Buclaw]

On 7 October 2012 13:12, Manu  wrote:
> On 5 October 2012 14:46, Iain Buclaw  wrote:
>>
>> On 5 October 2012 11:28, Manu  wrote:
>> > On 3 October 2012 16:40, Iain Buclaw  wrote:
>> >>
>> >> On 3 October 2012 02:31, jerro  wrote:
>> >> >> import core.simd, std.stdio;
>> >> >>
>> >> >> void main()
>> >> >> {
>> >> >>   float4 a = 1, b = 2;
>> >> >>   writeln((a + b).array); // WORKS: [3, 3, 3, 3]
>> >> >>
>> >> >>   float4 c = [1, 2, 3, 4]; // ERROR: "Stored value type does
>> >> >>// not match pointer operand type!"
>> >> >>// [..a bunch of LLVM error code..]
>> >> >>
>> >> >>   float4 c = 0, d = 1;
>> >> >>   c.array[0] = 4;
>> >> >>   c.ptr[1] = 4;
>> >> >>   writeln((c + d).array); // WRONG: [1, 1, 1, 1]
>> >> >> }
>> >> >
>> >> >
>> >> > Oh, that doesn't work for me either. I never tried to use those, so I
>> >> > didn't
>> >> > notice that before. This code gives me internal compiler errors with
>> >> > GDC
>> >> > and
>> >> > DMD too (with "float4 c = [1, 2, 3, 4]" commented out). I'm using DMD
>> >> > 2.060
>> >> > and a recent versions of GDC and LDC on 64 bit Linux.
>> >>
>> >> Then don't just talk about it, raise a bug - otherwise how do you
>> >> expect it to get fixed!  ( http://www.gdcproject.org/bugzilla )
>> >>
>> >> I've made a note of the error you get with `__vector(float[4]) c =
>> >> [1,2,3,4];' - That is because vector expressions implementation is
>> >> very basic at the moment.  Look forward to hear from all your
>> >> experiences so we can make vector support rock solid in GDC. ;-)
>> >
>> >
>> > I didn't realise vector literals like that were supported properly in
>> > the
>> > front end yet?
>> > Do they work at all? What does the code generated look like?
>>
>> They get passed to the backend as of 2.060 - so looks like the
>> semantic passes now allow them.
>>
>> I've just recently added backend support in GDC -
>>
>> https://github.com/D-Programming-GDC/GDC/commit/7ada3d95b8af1b271d82f1ec5208f0b689eb143c#L1R1194
>>
>> The codegen looks like so:
>>
>> float4 a = 2;
>> float4 b = [1,2,3,4];
>>
>> ==>
>> vector(4) float a = { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
>> vector(4) float b = { 1.0e+0, 2.0e+0, 3.0e+0, 4.0e+0 };
>>
>> ==>
>> movaps  .LC0, %xmm0
>> movaps  %xmm0, -24(%ebp)
>> movaps  .LC1, %xmm0
>> movaps  %xmm0, -40(%ebp)
>>
>> .align 16
>> .LC0:
>> .long   1073741824
>> .long   1073741824
>> .long   1073741824
>> .long   1073741824
>> .align 16
>> .LC1:
>> .long   1065353216
>> .long   1073741824
>> .long   1077936128
>> .long   1082130432
>
>
> Perfect!
> I can get on with my unittests :P

I fixed them again.

https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201


float a = 1, b = 2, c = 3, d = 4;
float4 f = [a,b,c,d];

===>
movss   -16(%rbp), %xmm0
movss   -12(%rbp), %xmm1


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Windows DLLs and TLS

[Denis Shelomovskij]

08.10.2012 23:06, Jakob Ovrum пишет:

On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij wrote:

As I said, give us a runnable failing test suite.


I am working on it, but as I said, it's proving very difficult to
replicate outside the XChat environment. I'll try to produce a reduced
plugin though.



As you are running Windows 7 the only reason I see is this nasty trap:
http://d.puremagic.com/issues/show_bug.cgi?id=8130

Are you aware of it?


I am using a .def file, and my exported functions are being called.
That's how I can tell that TLS is not working properly in the first place.


To reduce called stuff try not to call D runtime initializers as it 
isn't required to set up TLS on Windows 6.x (as in test libs from my 
post in this thread).


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Windows DLLs and TLS

[Jakob Ovrum]

On Monday, 8 October 2012 at 19:19:58 UTC, Denis Shelomovskij 
wrote:

As I said, give us a runnable failing test suite.


I am working on it, but as I said, it's proving very difficult to 
replicate outside the XChat environment. I'll try to produce a 
reduced plugin though.




As you are running Windows 7 the only reason I see is this 
nasty trap:

http://d.puremagic.com/issues/show_bug.cgi?id=8130

Are you aware of it?


I am using a .def file, and my exported functions are being 
called. That's how I can tell that TLS is not working properly in 
the first place.

Re: Windows DLLs and TLS

[Denis Shelomovskij]

08.10.2012 22:35, Jakob Ovrum пишет:

On Monday, 8 October 2012 at 18:05:31 UTC, Rainer Schuetze wrote:

What OS are you running? Implicite TLS for dynamically loaded DLLs is
not supported by XP or Sever 2003, so druntime contains a fix to
simulate it. (The workaround has the drawback that the DLL cannot be
unloaded anymore.)

I'm just speculating, maybe something goes wrong with the tls_index
variable, reading TLS variables would then access data from another DLL.

Is your code doing callbacks into the host application in static
initializers? With the XP workaround, the runtime initialization
"impersonates" all threads that exist before loading the DLL, by
switching the TLS-pointer array of the current thread, and that might
be unexpected in a callback (but not doing this might produce even
more unexpected results).


I'm running Windows 7, and I'm not using any static initializers either :(



As I said, give us a runnable failing test suite.

As you are running Windows 7 the only reason I see is this nasty trap:
http://d.puremagic.com/issues/show_bug.cgi?id=8130

Are you aware of it?

--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Windows DLLs and TLS

[Jakob Ovrum]

On Monday, 8 October 2012 at 18:05:31 UTC, Rainer Schuetze wrote:
What OS are you running? Implicite TLS for dynamically loaded 
DLLs is not supported by XP or Sever 2003, so druntime contains 
a fix to simulate it. (The workaround has the drawback that the 
DLL cannot be unloaded anymore.)


I'm just speculating, maybe something goes wrong with the 
tls_index variable, reading TLS variables would then access 
data from another DLL.


Is your code doing callbacks into the host application in 
static initializers? With the XP workaround, the runtime 
initialization "impersonates" all threads that exist before 
loading the DLL, by switching the TLS-pointer array of the 
current thread, and that might be unexpected in a callback (but 
not doing this might produce even more unexpected results).


I'm running Windows 7, and I'm not using any static initializers 
either :(

Re: Windows DLLs and TLS

[Jakob Ovrum]

On Monday, 8 October 2012 at 17:20:03 UTC, Regan Heath wrote:

Could XChat be loading your dll using:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

and the flag DONT_RESOLVE_DLL_REFERENCES, or similar.

To debug, I would write a debug file using *C* IO functions 
from DllMain, check it loads/runs/outputs to the file from your 
dummy C host application, then try again with XChat and see 
what you get.


You could also alter the dummy C host application to call 
LoadLibraryEx and pass DONT_RESOLVE_DLL_REFERENCES and see what 
happens.


R


Upon loading the application, which is when plugins are loaded, 
DLL_PROCESS_ATTACH is invoked once. Subsequently, 
DLL_THREAD_ATTACH is invoked 4 times. Then after about a second, 
still during startup, DLL_THREAD_DETACH is invoked twice. 
DLL_PROCESS_DETACH is then invoked once when closing the 
application.


XChat uses gmodule - part of glib - to load plugins. I looked at 
gmodule's Windows implementation, and it uses LoadLibraryW.


Despite finding all this, I still tried modifying the dummy host 
to use LoadLibraryEx out of curiosity. An access violation occurs 
in some druntime exception handling code as soon as I call into 
the plugin's init function.

[OT] Re: Windows DLLs and TLS

[Denis Shelomovskij]

08.10.2012 21:47, Rainer Schuetze пишет:

Implicite TLS for dynamically loaded DLLs is
not supported by XP or Sever 2003, so druntime contains a fix to
simulate it. (The workaround has the drawback that the DLL cannot be
unloaded anymore.)

I'm just speculating, maybe something goes wrong with the tls_index
variable, reading TLS variables would then access data from another DLL.

Is your code doing callbacks into the host application in static
initializers? With the XP workaround, the runtime initialization
"impersonates" all threads that exist before loading the DLL, by
switching the TLS-pointer array of the current thread, and that might be
unexpected in a callback (but not doing this might produce even more
unexpected results).


Here you are! Just want to mention that I'm currently managed to publish 
my (continuation of your) TLS fix I did half a year before. It will 
finally solve this XP/Sever 2003 problem. It is available here but isn't 
finished now (fill be in few days):

https://github.com/denis-sh/hooking/tree/master/tlsfixer

I hope you aren't against it is based on your work?


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: The sorry state of the D stack?

[Brad Anderson]

On Sun, Oct 7, 2012 at 10:39 AM, jerro  wrote:

> Isn't part of the problem that no one can get ahold of the person who
>>> runs it? At least, that's what I remember being discussed previously.
>>> It was my understanding that that's why we've never been able to get
>>> dsource cleaned up or really changed at all.
>>>
>>>
>> No, I think he'd just been busy. I've seen him around here a few times
>> lately.
>>
>
> Are you sure about that? There is a guy named Brad Anderson posting here,
> but he doesn't seem to be the Brad Anderson that dsource.org is
> registered to.
>

Yeah, I'm not the same guy as the Brad Anderson who runs dsource. Someone
may want to email him directly.

Regards,
Doppelganger

Re: Windows DLLs and TLS

[Denis Shelomovskij]

08.10.2012 15:26, Jakob Ovrum пишет:

I have a bug in one of my programs that I find particularly hard to reduce.

I am writing a Windows DLL plugin for the IRC chat client HexChat (aka
XChat). Problem is, all TLS variables, regardless of type, appear to be
initialized to complete rubbish values. Reading them does not cause an
access violation or anything, but the initial values are garbage. I am
initializing the runtime using the helpers found in core.sys.windows.dll
[1].

I wrote a dummy host application in C mimicking the loading behaviour of
HexChat - the TLS variables are initialized correctly in this case, even
though the DLL file is exactly the same.

What is it that a host application can do to break the TLS of a D plugin
it loads?

[1] http://pastebin.com/rg9uUQMe



What OS do you use? This problem should be related to Windows XP/Server 
2003.


Does you dummy host application in C use implicit TLS?

Do C and D DLLs attached to this post behave differently for you 
regarding to TLS initialisation (load and call `getTLSIndex` and 
`getTLSVarValue`)?


I'll try to help but I need full test suit to see where is the 
difference between C and D DLLs.


--
Денис В. Шеломовский
Denis V. Shelomovskij


DLL tests.7z
Description: application/7z-compressed

Re: Windows DLLs and TLS

[Rainer Schuetze]

On 10/8/2012 1:26 PM, Jakob Ovrum wrote:

I have a bug in one of my programs that I find particularly hard to reduce.

I am writing a Windows DLL plugin for the IRC chat client HexChat (aka
XChat). Problem is, all TLS variables, regardless of type, appear to be
initialized to complete rubbish values. Reading them does not cause an
access violation or anything, but the initial values are garbage. I am
initializing the runtime using the helpers found in core.sys.windows.dll
[1].

I wrote a dummy host application in C mimicking the loading behaviour of
HexChat - the TLS variables are initialized correctly in this case, even
though the DLL file is exactly the same.

What is it that a host application can do to break the TLS of a D plugin
it loads?

[1] http://pastebin.com/rg9uUQMe




What OS are you running? Implicite TLS for dynamically loaded DLLs is 
not supported by XP or Sever 2003, so druntime contains a fix to 
simulate it. (The workaround has the drawback that the DLL cannot be 
unloaded anymore.)


I'm just speculating, maybe something goes wrong with the tls_index 
variable, reading TLS variables would then access data from another DLL.


Is your code doing callbacks into the host application in static 
initializers? With the XP workaround, the runtime initialization 
"impersonates" all threads that exist before loading the DLL, by 
switching the TLS-pointer array of the current thread, and that might be 
unexpected in a callback (but not doing this might produce even more 
unexpected results).

Re: Windows DLLs and TLS

[Regan Heath]

It is also (apparently) possible to load a DLL without using LoadLibrary:
http://www.codeproject.com/Tips/430684/Loading-Win32-DLLs-manually-without-LoadLibrary

Lets hope XChat is not doing anything quite that crazy..

R

Re: Windows DLLs and TLS

[Regan Heath]

On Mon, 08 Oct 2012 12:26:29 +0100, Jakob Ovrum   
wrote:


I have a bug in one of my programs that I find particularly hard to  
reduce.


I am writing a Windows DLL plugin for the IRC chat client HexChat (aka  
XChat). Problem is, all TLS variables, regardless of type, appear to be  
initialized to complete rubbish values. Reading them does not cause an  
access violation or anything, but the initial values are garbage. I am  
initializing the runtime using the helpers found in core.sys.windows.dll  
[1].


I wrote a dummy host application in C mimicking the loading behaviour of  
HexChat - the TLS variables are initialized correctly in this case, even  
though the DLL file is exactly the same.


What is it that a host application can do to break the TLS of a D plugin  
it loads?


[1] http://pastebin.com/rg9uUQMe


Could XChat be loading your dll using:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

and the flag DONT_RESOLVE_DLL_REFERENCES, or similar.

To debug, I would write a debug file using *C* IO functions from DllMain,  
check it loads/runs/outputs to the file from your dummy C host  
application, then try again with XChat and see what you get.


You could also alter the dummy C host application to call LoadLibraryEx  
and pass DONT_RESOLVE_DLL_REFERENCES and see what happens.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

What is the case against a struct post-blit default constructor?

[Malte Skarupke]

So this has been brought up many times 
(http://www.digitalmars.com/d/archives/digitalmars/D/Struct_no-arg_constructor_173172.html 
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Default_constructor_for_structs_20997.html 
http://www.digitalmars.com/d/archives/digitalmars/D/struct_and_default_constructor_150016.html)


However there was never a good answer.

I would like a struct default constructor. My expected behavior 
for it is that the struct gets initialized to .init, then my 
destructor gets called so that I can do additional things if I 
want.
This destructor always gets called when my struct is created 
without arguments.


So for example

struct S
{
this()
{
assert(bar == 10);
foo = [5].ptr;
}
int * foo;
int bar = 10;
}
S s;
assert(*s.foo == 5);

Possible cases against it:
- "It would be slower than just initializing to .init." My 
proposed solution: Make the default constructor optional. If I 
have a struct that doesn't define a default constructor, it is 
just intialized to .init. So I can have the speed if I want to. 
Also always run it post-blit (blitted from .init). Meaning I only 
need to use it for things that can only be initialized at runtime.
- "There already is a solution in @disable this(); static 
opCall() {...}." This is hacky and working against the language. 
It also makes it so that you can not allocate your struct on the 
heap.
- "Structs should be simple." I haven't heard this argument, but 
I could imagine someone making it. I think structs should not be 
simple. They are much too useful for that. Also them having copy 
constructors and opAssign indicates that structs aren't expected 
to be simple.
- "There would be a way around it by doing S s = S.init;" I don't 
think that's a problem. If users want to shoot themselves in the 
foot, let em. The important part is that they have to go out of 
their way to do it. You could also handle that case in the copy 
constructor or assignment operator. (which is an improvement to 
the current behavior where you have to handle that case in every 
single member function, see for example std.typecons.RefCounted)



So I really can't think of a reason for why you wouldn't want 
this. Yet this discussion has happened several times already. 
There is clear demand for it and very good reasons, such as those 
mentioned in all the linked discussions.


So why is this being rejected?

Cheers,
Malte

Re: SQL working [ was Re: The sorry state of the D stack? ]

[BLM768]

I've been thinking about writing an interface inspired by 
ActiveRecord. It would probably be relatively simple and 
lightweight, but it should be enough for simple REST 
applications, and the interface would (hopefully) be extremely 
nice to use.
Of course, with all the other projects I want to do, I'm not sure 
how long this will live :).

Re: Preliminary submission - std.rational and std.typelist

[Arlen]

On Mon, Oct 8, 2012 at 2:08 AM, Simen Kjaeraas  wrote:
> On 2012-44-08 06:10, Arlen  wrote:
>
>>
>> 1.  To convert a BigInt to floating-point one needs to convert it to
>> the built-in integer types first.  If you go beyond the limits of the
>> built-in types (long), then what's the point?  You might as well be
>> using int or long.
>
>
> I thought (part of) the point of Rational was to use it when it would
> be more fitting than floating-point. If it's only there to be converted
> to floating-point, I don't know what it's there for.
>

Some computations with rational numbers produce irrational numbers,
and to store irrational numbers you need real numbers.  What do we do
in those cases?

> As for a workaround, right-shift num and den to reasonable values
> (which fit in a long), divide to get a float, and multiply by
> 2.0^^(log2(num)-log2(den)). Oughta work.
>
>
>
>> 2.  The functions in std.math don't support BigInt, and most likely
>> never will.  Even if they did, you would still need multi-precision
>> floating point to store the irrational numbers.  If you decided to use
>> the built-in types, then again what's the point?  You might as well go
>> with int or long.
>
>
> The only function you use from std.math is abs, right? That should be
> fairly easy to implement for BigInt.
>
> It'd mean you'd have to specialize a bit for BigInt, though (just
> create your own abs function that calls the correct one).
>

Yes, std.math.abs and std.numeric.gcd are very easy to implement for
BigInt, but I'm not talking about those.  I'm talking about things
like std.math.pow(), and std.math.log().

Re: Windows DLLs and TLS

[Jakob Ovrum]

On Monday, 8 October 2012 at 15:52:12 UTC, Paulo Pinto wrote:

Sorry, just thought it might be helpful.


No, I'm sorry, I shouldn't have replied in the tone that I did.

I truly appreciate the help.

Re: Windows DLLs and TLS

[Paulo Pinto]

On Monday, 8 October 2012 at 12:00:00 UTC, Jakob Ovrum wrote:

On Monday, 8 October 2012 at 11:55:24 UTC, Paulo Pinto wrote:

On Monday, 8 October 2012 at 11:44:28 UTC, Jakob Ovrum wrote:
I have a bug in one of my programs that I find particularly 
hard to reduce.


I am writing a Windows DLL plugin for the IRC chat client 
HexChat (aka XChat). Problem is, all TLS variables, 
regardless of type, appear to be initialized to complete 
rubbish values. Reading them does not cause an access 
violation or anything, but the initial values are garbage. I 
am initializing the runtime using the helpers found in 
core.sys.windows.dll [1].


I wrote a dummy host application in C mimicking the loading 
behaviour of HexChat - the TLS variables are initialized 
correctly in this case, even though the DLL file is exactly 
the same.


What is it that a host application can do to break the TLS of 
a D plugin it loads?


[1] http://pastebin.com/rg9uUQMe


Did you already went through this howto?

http://dlang.org/dll.html


Of course. I've written many DLLs before, and again, TLS works 
in the exact same DLL when a different host program is used, 
hence why it's so difficult to reduce.


Besides, there's nothing relevant in that article.


Sorry, just thought it might be helpful.

Re: Preliminary submission - std.rational and std.typelist

[Aziz K.]

On Mon, 08 Oct 2012 09:28:37 +0200, H. S. Teoh   
wrote:



I'd like to chime in to state that I'd love to have Rational support
BigInt. If necessary, use an arbitrary-width floating point format for
floating point conversions (BigFloat?).



Incidentally, I would very much need a BigFloat class/struct, written in D  
and independent of any C library.
I'm trying to write one myself, but it seems to be rather tricky. Could  
this be implemented in a short amount of time by someone with more  
knowledge about this topic?


--
My D Compiler: http://code.google.com/p/dil

Re: Running test suites under Windows 7

[Regan Heath]

On Sat, 06 Oct 2012 13:05:32 +0100, Walter Bright  
 wrote:



On 10/6/2012 2:25 AM, Paulo Pinto wrote:

On the other
hand it can lead to such scenarios if the applications are not properly  
coded to

work with file locking mechanisms.


Both Optlink and Windows link fail with this :-)

(The error code Optlink gets from Windows when it tries to create the  
EXE file is something along the lines of the EXE file is in use by  
another application.)


It's odd that these fail because many/most virus scanners are written  
using file system filter drivers which operate in the IO stack, blocking  
CreateFile/open to scan the file, meaning most user processes don't even  
notice them (except for a very brief pause on CreateFile/open).


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Windows DLLs and TLS

[Jakob Ovrum]

On Monday, 8 October 2012 at 11:55:24 UTC, Paulo Pinto wrote:

On Monday, 8 October 2012 at 11:44:28 UTC, Jakob Ovrum wrote:
I have a bug in one of my programs that I find particularly 
hard to reduce.


I am writing a Windows DLL plugin for the IRC chat client 
HexChat (aka XChat). Problem is, all TLS variables, regardless 
of type, appear to be initialized to complete rubbish values. 
Reading them does not cause an access violation or anything, 
but the initial values are garbage. I am initializing the 
runtime using the helpers found in core.sys.windows.dll [1].


I wrote a dummy host application in C mimicking the loading 
behaviour of HexChat - the TLS variables are initialized 
correctly in this case, even though the DLL file is exactly 
the same.


What is it that a host application can do to break the TLS of 
a D plugin it loads?


[1] http://pastebin.com/rg9uUQMe


Did you already went through this howto?

http://dlang.org/dll.html


Of course. I've written many DLLs before, and again, TLS works in 
the exact same DLL when a different host program is used, hence 
why it's so difficult to reduce.


Besides, there's nothing relevant in that article.

Re: Windows DLLs and TLS

[Paulo Pinto]

On Monday, 8 October 2012 at 11:44:28 UTC, Jakob Ovrum wrote:
I have a bug in one of my programs that I find particularly 
hard to reduce.


I am writing a Windows DLL plugin for the IRC chat client 
HexChat (aka XChat). Problem is, all TLS variables, regardless 
of type, appear to be initialized to complete rubbish values. 
Reading them does not cause an access violation or anything, 
but the initial values are garbage. I am initializing the 
runtime using the helpers found in core.sys.windows.dll [1].


I wrote a dummy host application in C mimicking the loading 
behaviour of HexChat - the TLS variables are initialized 
correctly in this case, even though the DLL file is exactly the 
same.


What is it that a host application can do to break the TLS of a 
D plugin it loads?


[1] http://pastebin.com/rg9uUQMe


Did you already went through this howto?

http://dlang.org/dll.html

Re: SQL working [ was Re: The sorry state of the D stack? ]

[Paulo Pinto]

On Monday, 8 October 2012 at 10:26:35 UTC, denizzzka wrote:

On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:

On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:

On 10/07/2012 10:55 AM, Russel Winder wrote:
Why only PostgreSQL. Shouldn't it also work with MySQL, 
Oracle, DB2,

PervasiveSQL, SQLite3, etc.?


I don't have sufficient experience with SQL to be able to 
really make a judgement here, but is there a case for a 
std.sql or std.db that would provide a uniform D interface 
to the arbitrary DB of choice?


Each database engine has a unique distinguishing features 
that make this engine interesting. (for example, different 
implementations of transactions - SQL standard does not 
describe the SQL transactions precisely enough)


There are plenty of existing interfaces to base D's design on, 
just a few of them:


Perl - DBI
Python - DB API
C, C++ - ODBC (there is an UNIX variant of it)
C++ - OLE DB (Although Windows specific)
Java - JDBC
.NET - Data Providers
Ruby - DBI
TCL - TDBC
Go - database package
Delphi - Data Access
Haskell - HaskellDB (HDBC)



So, I do not know is it possible to make a universal 
interface. And why it may need in real life?



At least in the enterprise world, we tend to write 
applications in a DB independent way.


One reason is to be able to deploy the applications without 
forcing the customers to invest in new DB engines, thus 
reaching a broader client base.


Sometimes inside the same organization different business 
units have different DB engines running (even different 
versions of the same DB).


Finally, to minimize costs when management decides for 
whatever reason, to change the DB licenses being used.


--
Paulo


For this to work you need to implement an independent way to 
create queries that would work on all database engines the same 
way. I believe that this problem is in principle much more 
complicated than it would have been implemented interfaces to 
databases in separate libs.


Sure. That is why on top of a DB driver layer, usually you have 
some kind of SQL adaptation layer.


On the TCL/C abstraction layer we implemented for a product 
during the 1999-2001 timeframe, we used standard SQL '92 for all 
data queries, regardless of hand-written or generated from our 
TCL ORM.


Then there was a translation layer that transformed SQL '92 into 
DB specific SQL, before giving it to the corresponding driver.


The only two parts of the application that had DB specific code 
were the SQL transformation layer, and the .so/.dll with the DB 
specific driver.


With the added benefit that any DB fully SQL '92 compliant did 
not need any adaptations in the transformation layer.



--
Paulo

Windows DLLs and TLS

[Jakob Ovrum]

I have a bug in one of my programs that I find particularly hard 
to reduce.


I am writing a Windows DLL plugin for the IRC chat client HexChat 
(aka XChat). Problem is, all TLS variables, regardless of type, 
appear to be initialized to complete rubbish values. Reading them 
does not cause an access violation or anything, but the initial 
values are garbage. I am initializing the runtime using the 
helpers found in core.sys.windows.dll [1].


I wrote a dummy host application in C mimicking the loading 
behaviour of HexChat - the TLS variables are initialized 
correctly in this case, even though the DLL file is exactly the 
same.


What is it that a host application can do to break the TLS of a D 
plugin it loads?


[1] http://pastebin.com/rg9uUQMe

Re: DMD 2.060

[Aziz K.]

On Sun, 07 Oct 2012 12:39:59 +0200, Walter Bright  
 wrote:



A list of relevant bugzilla entries would be illuminating.



There's a regression in 2.060 which affects my project. Was first reported  
here:


http://d.puremagic.com/issues/show_bug.cgi?id=4192

The corresponding fix:

http://dsource.org/projects/dmd/changeset/498

--
My D Compiler: http://code.google.com/p/dil

Re: RFC: DConf 2013

[Iain Buclaw]

On 7 October 2012 22:41, mist  wrote:
> On Monday, 1 October 2012 at 16:25:12 UTC, Andrei Alexandrescu wrote:
>>
>> The project is not live, it will be within a few days. In the spirit of
>> having the community actively participate, I'm making this as transparent as
>> it gets. Please comment:
>>
>> http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a
>>
>> Your feedback and suggestions are welcome.
>>
>>
>> Thanks,
>>
>> Andrei
>
>
> How about any special online materials for backers that can't really attend?
> :)
> ( Those Europe-to-USA tickets do not tolerate poor students :( )

I could probably give minimal aid to one or two students living round
Brighton UK - or the general Sussex/Kent/London area. ;-)


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: object states

[Henning Pohl]

On Monday, 8 October 2012 at 08:53:39 UTC, simendsjo wrote:

You can create a wrapper struct that includes an invariant:

import std.stdio;

struct Image
{
int width;

void doSomething()
{
}

void modifiesWidth()
{
--width;
}
}

void func(Image img)
{
struct ImgWrapper
{
Image* img;
this(ref Image img)
{
this.img = &img;
}

invariant()
{
assert(img.width == 512);
}

void opDispatch(string s)()
{
mixin("img."~s~"();");
}
}

auto wrapper = ImgWrapper(img);
wrapper.doSomething();
wrapper.modifiesWidth(); // assertion failure
}

void main()
{
Image img = { 512 };
func(img);
}


There is a difference between invariants and what I call states. 
States clear things up when you actually need to do a runtime 
check and when not. Invariants are always checked, because you 
don't care about performance in debug mode. A Number is 
positive already and will stay positive while you can access it. 
De facto you cannot change a Number to a negative 
number.

Re: SpanMode uses incorrect terminology (breadth)

[Mehrdad]

On Tuesday, 18 September 2012 at 15:19:08 UTC, Andrei 
Alexandrescu wrote:

On 9/18/12 10:25 AM, David Piepgrass wrote:
Actually I prefer breadth-first search when searching the file 
system. When I search an entire volume, inevitably the 
(depth-first) search gets stuck in a few giant, deep 
directories like the source code of Mono or some other cave of 
source code, you know, something 12 directories deep with 
100,000 files in it. A breadth-first search would be more 
likely to find the thing I'm looking for BEFORE going 
spelunking in these 12-deep caves.


Yes, that was my intent too.

Andrei




I just wanted to point out, BFS is generally a pretty BAD idea 
for searching a file system.


You instead probably want to implement DFS, and then alter it 
slightly to use iterative deepening instead of doing plain 
breadth-first search.


That way you won't be keeping open a million OS file handles.

Re: SQL working [ was Re: The sorry state of the D stack? ]

[denizzzka]

On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:

On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:

On 10/07/2012 10:55 AM, Russel Winder wrote:
Why only PostgreSQL. Shouldn't it also work with MySQL, 
Oracle, DB2,

PervasiveSQL, SQLite3, etc.?


I don't have sufficient experience with SQL to be able to 
really make a judgement here, but is there a case for a 
std.sql or std.db that would provide a uniform D interface to 
the arbitrary DB of choice?


Each database engine has a unique distinguishing features that 
make this engine interesting. (for example, different 
implementations of transactions - SQL standard does not 
describe the SQL transactions precisely enough)


There are plenty of existing interfaces to base D's design on, 
just a few of them:


Perl - DBI
Python - DB API
C, C++ - ODBC (there is an UNIX variant of it)
C++ - OLE DB (Although Windows specific)
Java - JDBC
.NET - Data Providers
Ruby - DBI
TCL - TDBC
Go - database package
Delphi - Data Access
Haskell - HaskellDB (HDBC)



So, I do not know is it possible to make a universal 
interface. And why it may need in real life?



At least in the enterprise world, we tend to write applications 
in a DB independent way.


One reason is to be able to deploy the applications without 
forcing the customers to invest in new DB engines, thus 
reaching a broader client base.


Sometimes inside the same organization different business units 
have different DB engines running (even different versions of 
the same DB).


Finally, to minimize costs when management decides for whatever 
reason, to change the DB licenses being used.


--
Paulo


For this to work you need to implement an independent way to 
create queries that would work on all database engines the same 
way. I believe that this problem is in principle much more 
complicated than it would have been implemented interfaces to 
databases in separate libs.

Re: SQL working [ was Re: The sorry state of the D stack? ]

[simendsjo]

On Sunday, 7 October 2012 at 22:08:45 UTC, Nick Sabalausky wrote:
Not necessarily: Steve Teale's "mysqln" is a native D MySQL 
driver that
connects to the DB server directly and bypasses MySQL's 
official client
lib entirely. Teale has inexplicably disappeared off the face 
of the
internet, but Vibe.d has adapted the lib for use with Vibe.d, 
and

this guy has also made some updates:
https://github.com/simendsjo/mysqln/tree/misc-cleanups

I'm using that with Vibe.d and it seems to be working pretty 
well.


(I'm not sure if the simendsjo version or the Vibe.d version is 
more

up-to-date, though.)


The important updates (compile on x64) is incorporated in vibe.
The other updates in my repo is just code cleanups, but it's a 
WIP, and I don't think I'll finish it unless I need to use 
MySQL+D.

Re: object states

[simendsjo]

On Sunday, 7 October 2012 at 20:46:09 UTC, Henning Pohl wrote:

On Sunday, 7 October 2012 at 20:18:15 UTC, Ali Çehreli wrote:

Sounds good.

Thanks.

You haven't mentioned the invariant keyword, so perhaps you 
are not aware of that feature?


 http://dlang.org/class.html#Invariant

 http://dlang.org/dbc.html

Although the docs seem to favor classes, invariant is 
available for structs as well.


Ali
How would you resolve the issue I wrote in my first post using 
invariants? You cannot add/remove checks from invariants while 
using the object. That's what I made different. But there are 
still some limits given by the language. Look at point 7 for 
instance.


The problem about contract programming in general is you cannot 
use it in public library code. Distinction between logic and 
user input is a very important thing, we really need to improve 
this. You may have noticed that I did not make use of either 
assert or enforce. I didn't want to specify this.


You can create a wrapper struct that includes an invariant:

import std.stdio;

struct Image
{
int width;

void doSomething()
{
}

void modifiesWidth()
{
--width;
}
}

void func(Image img)
{
struct ImgWrapper
{
Image* img;
this(ref Image img)
{
this.img = &img;
}

invariant()
{
assert(img.width == 512);
}

void opDispatch(string s)()
{
mixin("img."~s~"();");
}
}

auto wrapper = ImgWrapper(img);
wrapper.doSomething();
wrapper.modifiesWidth(); // assertion failure
}

void main()
{
Image img = { 512 };
func(img);
}

Re: Feature request: extending comma operator's functionality

[Don Clugston]

On 05/10/12 18:58, H. S. Teoh wrote:

On Fri, Oct 05, 2012 at 05:23:40PM +0200, Don Clugston wrote:
[...]

My feeling is that  do{}while() is a fairly useless concept, and
this is part of the reason.
In my experience genuine do-while loops are extremely rare, and it
only takes a slight change to the loop to force a different
structure to be used.
Conditional loops which don't follow the while(){...} pattern
normally follow the loop-and-a-half pattern, also known as
begin-while-repeat (I think that's the name Knuth used). I'll call
it 'super do':

super do {
foo();
while(cond);
bar();
}

which in D is better modelled by:

for (;;)
{
foo();
if (!cond) break;
bar();
}


This isn't "super do", it's just "loop", the way nature intended. ;-)
I've always been an advocate of this construct:

loop {
// initial part of loop body
} while(cond) { // exit point
// trailing part of loop body
}



Looks OK, except that the scopes look wrong. I would hope than a 
variable declared in the initial part of the body is also visible in the 
trailing part. The {} don't work properly.
Regardless of the syntax, I think it is _the_ fundamental loop 
construct, and I've always found it odd that most languages don't 
include it. I first found encountered it in Forth, and have missed it 
ever since.



To some extent, D (and C/C++)'s for-loops exhibit a similar structure:

for (X; Y; Z) {}

The trailing part of the loop body corresponds with Z; the condition
corresponds with Y.


Yes. C got 'for' loops right.


To avoid the introduction of a new keyword, we may fuse the do-loop and
the while-loop together:

do {
...
} while (cond) {
...
}

The current do-loop is simply a special case of this construct where the
second {...} is replaced with a ;, and the while-loop is a special case
of this construct where the initial part of the loop is elided.

I argue that this generalized construct is much more useful than the
do-loop or while-loop individually, plus it doesn't break any existing
code.


I agree that it's more useful. But that code was legal until a couple of 
releases ago, because a trailing ; was not required on do-while loops.


do { xxx; } while(cond) { yyy; }

means:
do {
  xxx;
}
while(cond);
yyy;

Even without that, it puts a huge significance on that semicolon. So I 
don't think that works. How about:


do {  ...  do while (cond);  ... }

?
This is technically already legal too, although 'do while(cond);' is 
currently either a no-op, or an infinite loop.

Re: Preliminary submission - std.rational and std.typelist

[H. S. Teoh]

On Sun, Oct 07, 2012 at 01:15:50PM +0400, Dmitry Olshansky wrote:
[...]
> Just define method with this signature:
> void toString(scope void delegate(const(char)[]) sink)
> 
> And bingo! It's used in all of formatting stuff like write(f)(ln),
> format, formattedWrite etc.
> 
> e.g. before posting I played with this:
> 
> import std.stdio, std.format;
> 
> struct A{
>   int k;
>   void toString(scope void delegate(const(char)[]) sink)
>   {
>   formattedWrite(sink, "[%d]", k);
>   }
> }
> 
> void main(){
>   A a = A(90);
>   writeln(a);
> }
[...]

+1. This is much more powerful and useful, not to mention more efficient
in many cases (by avoiding the need to create multiple string buffers),
than the current toString(). I like this.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is
it too much that I expect him to teach me??? -- RL

Re: Preliminary submission - std.rational and std.typelist

[H. S. Teoh]

On Mon, Oct 08, 2012 at 09:08:57AM +0200, Simen Kjaeraas wrote:
> On 2012-44-08 06:10, Arlen  wrote:
> 
> >On Sat, Oct 6, 2012 at 1:32 PM, Dmitry Olshansky
> > wrote:
> >>
> >>Cool, does it work with BigInt?
> >>
> >
> >No it doesn't work with BigInt, but I did look into it today briefly.
> >There are issues with BigInt that I'm not sure what to do about:
> >
> >1.  To convert a BigInt to floating-point one needs to convert it to
> >the built-in integer types first.  If you go beyond the limits of the
> >built-in types (long), then what's the point?  You might as well be
> >using int or long.
> 
> I thought (part of) the point of Rational was to use it when it would
> be more fitting than floating-point. If it's only there to be
> converted to floating-point, I don't know what it's there for.

I'd like to chime in to state that I'd love to have Rational support
BigInt. If necessary, use an arbitrary-width floating point format for
floating point conversions (BigFloat?).


[...]
> It'd mean you'd have to specialize a bit for BigInt, though (just
> create your own abs function that calls the correct one).
> 
> Another option: lobby for BigInt support in std.math. :p

+1.


> Also, irrational numbers? How'd you get those in a *Rational* library? :p
[...]

Ironically enough, if Rational supports BigInt, then it makes it
possible to implement a representation of quadratic irrationals in a
straightforward way (by storing them in the form a+b*sqrt(r) where a and
b are Rationals and r is a square-free Rational). The reason BigInt is
necessary is that while these things are closed under field operations,
any non-trivial work with them tends to overflow built-in integer types
very quickly.

BigInt becomes even more necessary if you want to represent quadratic
irrationals of *two* distinct square roots, which can be represented as
a+b*sqrt(r)+c*sqrt(s)+d*sqrt(rs), where a,b,c,d are Rationals and r,s
are square-free Rationals. Believe it or not, these little monsters are
also closed under field operations. But they also overflow built-in
integers *very* fast. With BigInt support, however, you can do *exact*
arithmetic with these irrational numbers, something very useful for
applications in computational geometry, where the lack of exact
arithmetic makes many problems intractible or prone to wrong results.


T

-- 
I'm still trying to find a pun for "punishment"...

Re: SQL working [ was Re: The sorry state of the D stack? ]

[Paulo Pinto]

On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:

On 10/07/2012 10:55 AM, Russel Winder wrote:
Why only PostgreSQL. Shouldn't it also work with MySQL, 
Oracle, DB2,

PervasiveSQL, SQLite3, etc.?


I don't have sufficient experience with SQL to be able to 
really make a judgement here, but is there a case for a 
std.sql or std.db that would provide a uniform D interface to 
the arbitrary DB of choice?


Each database engine has a unique distinguishing features that 
make this engine interesting. (for example, different 
implementations of transactions - SQL standard does not 
describe the SQL transactions precisely enough)


There are plenty of existing interfaces to base D's design on, 
just a few of them:


Perl - DBI
Python - DB API
C, C++ - ODBC (there is an UNIX variant of it)
C++ - OLE DB (Although Windows specific)
Java - JDBC
.NET - Data Providers
Ruby - DBI
TCL - TDBC
Go - database package
Delphi - Data Access
Haskell - HaskellDB (HDBC)



So, I do not know is it possible to make a universal interface. 
And why it may need in real life?



At least in the enterprise world, we tend to write applications 
in a DB independent way.


One reason is to be able to deploy the applications without 
forcing the customers to invest in new DB engines, thus reaching 
a broader client base.


Sometimes inside the same organization different business units 
have different DB engines running (even different versions of the 
same DB).


Finally, to minimize costs when management decides for whatever 
reason, to change the DB licenses being used.


--
Paulo

Re: SQL working [ was Re: The sorry state of the D stack? ]

[Jacob Carlborg]

On 2012-10-07 18:54, Joseph Rushton Wakeling wrote:

On 10/07/2012 10:55 AM, Russel Winder wrote:

Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
PervasiveSQL, SQLite3, etc.?


I don't have sufficient experience with SQL to be able to really make a
judgement here, but is there a case for a std.sql or std.db that would
provide a uniform D interface to the arbitrary DB of choice?


I think that a uniform database interface with support for different 
database drivers, a DSL, an ORM wrapper and a couple of database drivers 
would be too much to have in Phobos.


--
/Jacob Carlborg

Re: Preliminary submission - std.rational and std.typelist

[Simen Kjaeraas]

On 2012-44-08 06:10, Arlen  wrote:

On Sat, Oct 6, 2012 at 1:32 PM, Dmitry Olshansky   
wrote:


Cool, does it work with BigInt?



No it doesn't work with BigInt, but I did look into it today briefly.
There are issues with BigInt that I'm not sure what to do about:

1.  To convert a BigInt to floating-point one needs to convert it to
the built-in integer types first.  If you go beyond the limits of the
built-in types (long), then what's the point?  You might as well be
using int or long.


I thought (part of) the point of Rational was to use it when it would
be more fitting than floating-point. If it's only there to be converted
to floating-point, I don't know what it's there for.

As for a workaround, right-shift num and den to reasonable values
(which fit in a long), divide to get a float, and multiply by
2.0^^(log2(num)-log2(den)). Oughta work.



2.  The functions in std.math don't support BigInt, and most likely
never will.  Even if they did, you would still need multi-precision
floating point to store the irrational numbers.  If you decided to use
the built-in types, then again what's the point?  You might as well go
with int or long.


The only function you use from std.math is abs, right? That should be
fairly easy to implement for BigInt.

It'd mean you'd have to specialize a bit for BigInt, though (just
create your own abs function that calls the correct one).

Another option: lobby for BigInt support in std.math. :p


Also, irrational numbers? How'd you get those in a *Rational* library? :p


--
Simen

Re: SQL working [ was Re: The sorry state of the D stack? ]

[Jacob Carlborg]

On 2012-10-07 21:53, denizzzka wrote:


So, I do not know is it possible to make a universal interface. And why
it may need in real life?


ActiveRecord provides a universal interface for all databases. But you 
can't do all things with a fancy DSL. Sometimes you need to drop down to 
raw SQL if you want to execute some weird SQL function or similar.


--
/Jacob Carlborg