Stephan Wienczny wrote:
> IMHO such tools have to be easy to use. I don't want to have to write too complicated code I'd have to debug later. If I wanted that I could use a bash scipt.
> AFAIK I don't want to extend the abilities of my building tool I want to use it ;-)

I agree on all points except the last.  Guess who added D support to SCons. ;)

Python is easily my favourite language for getting stuff done fast; SCons lets me leverage that while still describing what to do, as opposed to how it ought to be done. (automatic dependancy checking etc)

 -- andy

Would you be referring to the bug I posted on SF: http://sourceforge.net/tracker/index.php?func=detail&aid=952905&group_id=30337&atid=398971

that I don't think _anybody_ has even read?

On Sun, 30 May 2004 08:43:49 -0700, Andy Friesen wrote:

> This is ever so slightly different in that all the .obj files get dumped in with the source, but that's because I'm a gimp and need to update the SCons tool to be better.

private import etc.bigint;

int main (char args[][]) {
Int i = new Int("730750818665451459101842416358141509827966271488");
char [] v = i.toString();
printf ("%.*s %.*s = ",v,v);
v = (i*i).toString();
printf ("%.*s\n",v);
return 0;
}

730750818665451459101842416358141509827966271488 730750818665451459101842416358141509827966271488 = Error: AssertError Failure etc/bigint_files/lowlevel.d(50)

looks problematic...
hope ye' can figure it out...

Andy Friesen wrote:

> Stephan Wienczny wrote:
> 
>> IMHO such tools have to be easy to use. I don't want to have to write too complicated code I'd have to debug later. If I wanted that I could use a bash scipt.
>> AFAIK I don't want to extend the abilities of my building tool I want to use it ;-)
> 
> 
> I agree on all points except the last.  Guess who added D support to SCons. ;)

Yeah :) I wasn't really asking you :)

> Python is easily my favourite language for getting stuff done fast; SCons lets me leverage that while still describing what to do, as opposed to how it ought to be done. (automatic dependancy checking etc)
> 
>  -- andy

IMO, Python is not a good argument here. A-A-P is implemented in Python, and is fairly easy extendable through modules. Also, Python code can be used directly in the recipes, either on a statement-per-statement basis, or in larger blocks.

Lars Ivar Igesund

In article <c9dtp8$1bf3$1@digitaldaemon.com>, hellcatv@hotmail.com says...
>
>private import etc.bigint;
>
>int main (char args[][]) {
>Int i = new Int("730750818665451459101842416358141509827966271488");
>char [] v = i.toString();
>printf ("%.*s %.*s = ",v,v);
>v = (i*i).toString();
>printf ("%.*s\n",v);
>return 0;

Wow. Well, I guess that's what asserts are FOR. In C++ the code would have carried on and got the wrong answer. (Nice one, Walter!)

Anyway, I have reproduced it. I will let you know when I've fixed it. Hopefully sometime today.

Jill

PS. I can make libraries now, so hopefully the next release will be easier to get going.

In article <c9eosp$2k30$1@digitaldaemon.com>, Arcane Jill says...

>Anyway, I have reproduced it. I will let you know when I've fixed it. Hopefully sometime today.

Fixed. New version online, same place. (Looking forward to moving to dsource
though.)

Jill

Andy Friesen wrote:

> Guess who added D support to SCons. ;)

BTW, Andy, can you add this little patch on dmd.py?

In the win32 case, modify the:
env['DLINKCOM'] = '$DLINK -of$TARGET $SOURCES $DFLAGS $DLINKFLAGS $_DLINKLIBFLAGS'

to

env['DLINKCOM'] = '$DLINK -of$TARGET $SOURCES $DFLAGS $DLINKFLAGS $_DLINKLIBFLAGS'

In this way Scons can build DLL on windows using the env.Program builder ( I know, a little crap... but it works ;-)

---
Paolo Invernizzi

Paolo Invernizzi wrote:

Ooopss!

to

-of${TARGET.base}


> to
> 
> env['DLINKCOM'] = '$DLINK -of$TARGET $SOURCES $DFLAGS $DLINKFLAGS $_DLINKLIBFLAGS'

In article <c9et6g$2pt4$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <c9eosp$2k30$1@digitaldaemon.com>, Arcane Jill says...
>
>>Anyway, I have reproduced it. I will let you know when I've fixed it. Hopefully sometime today.
>
>Fixed. New version online, same place. (Looking forward to moving to dsource
>though.)
>
>Jill
>
>
I'd like to mention that you have a compiler error on non x86 machines:
etc/bigint_files/multiply.d(299): declaration bigintSquareClassic.xi is already
defined
basically you need to move uint xi into the version() { tag.

Also: you fixed the test case I posted, but this one isn't fixed (same failure):

import etc.bigint;
int main (char args[][]) {
Int i = new
Int("1557113549234358496979015513794451750344390547442359561355264");
Int j = new Int ("18446744073709551616");

char [] v = i.toString();
char [] u = j.toString();
printf ("%.*s %.*s = ",v,u);
v = (i*j).toString();
printf ("%.*s\n",v);
return 0;
}

In article <c9g1a3$1ab1$1@digitaldaemon.com>, hellcatv@hotmail.com says...
>
>Also: you fixed the test case I posted, but this one isn't fixed (same failure):
>

Will fix tonight.

I should be able to move everything to dsource soon too, but I'll keep a most-fixed version on my website anyway, at least for a time. I'll also add in those big rationals one we're on dsource.

Arcane Jill


PS. TEMPORARY WORKAROUND - I suspect that if you build with version(DisableKaratsuba) the problem may go away. Disallowing the more complex (but possibly faster) Karatsuba multiplication algorithm forces the lib to use classical long-multiplication, which is much simpler, and unlikely to be buggy. (But obviously I will fix the bug anyway).