May 30, 2004
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
May 30, 2004
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.

May 31, 2004
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...


May 31, 2004
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
May 31, 2004
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.


May 31, 2004
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


May 31, 2004
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
May 31, 2004
Paolo Invernizzi wrote:

Ooopss!

to

-of${TARGET.base}


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

May 31, 2004
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;
}


June 01, 2004
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).