"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9bu8h$1oi8$1@digitaldaemon.com...
> In article <c9a37n$282p$1@digitaldaemon.com>, Ivan Senji says...
> >
> >Now for some stupid questions:
> >How do i use it?
>
> Well, I only included source files. Guess I should have included a lib you
can
> link against, but it's early days.
>
>
> >I got it working by including al of the files in bigint_files in my project (i am using DIDE), is it the right way?
>
> No. It *should* be as simple as "import etc.bigint;". That works for me.
The
> supporting modules are supposed to be "behind the scenes" (though actually
still
> individually importable if you really want to).
>
> The way I build it is as follows:
>
> (1) Separately compile each source file, using the -I compiler switch so
that
> the compiler knows where to start looking for the etc tree.
>
> (2) Compile your own source file(s), again with -I to tell it where to
find the
> bigint files.
>
> (3) Link all of those files together.
>
> I agree that this is messy. I think I should probably get some pre-built
libs
> together after the project is moved to dsource.

I'll try this! By the way i have to say i like your big integers a lot, they
work
GREAT :)

> >I also got an error message about exceptions being
> >in two packages or something like that.
>
> I think it's possible that without the -I switch, the compiler may not be
able
> to find some things. I can only guess that that's the problem.
>
> If you want, I could always post the complete set of command lines emitted
by my
> build process. You might not necessarily want to copy that (as I keep
debug objs
> separately from release objs) but it might help us figure out what the
problem
> is.
>
> >and there were two
> >deprecated C-style casts.
>
> Feel free to ditch them. After dsource, you'll be able to fix that for
everyone,
> but for now, if you give the file and line numbers, I can fix it in my mastercopy.
>
>
>
> >When i finally got it to work i tried:
> >
> >import std.c.stdio;
> >import etc.bigint;
> >
> >int main(char[][] args)
> >{
> >    Int n= new Int("123456");
> >
> >    printf("n = %.*s",n.toString);
> >}
> >
> >and it prints:
> >n = 23456
>
> You are correct. It's a bug. I just reproduced it. I will fix it and add
that
> one to the unit tests. Will let you know when it's done.
>
>
>
> >i tried it with acouple of numbers and i never get the first digit.
>
> My apologies. It worked once upon a time. I must assume I subsequently
broke it.
> Most things are unit tested to prevent that from happening. I can't
imagine how
> I was so stupid as to let that one slip by.
>
> Will get back to you when it's fixed.
>
> Arcane Jill.
>
>
>

>>import std.c.stdio;
>>import etc.bigint;
>>
>>int main(char[][] args)
>>{
>>    Int n= new Int("123456");
>>
>>    printf("n = %.*s",n.toString);
>>}
>>
>>and it prints:
>>n = 23456

I have now fixed this embarrassing bug and uploaded the new version to the same place. I have also added that particular example to the unit tests, so it should never happen again.

My apologies
Arcane Jill

In article <pan.2004.05.30.07.23.32.756180@demmegod.com>, DemmeGod says...
>
>Why not write a makefile, or better yet a Scons SConstruct file?
>
>John

Ahem. Embarrassing confession time...

Because I can't write makefiles. And I don't know what a Scons SConstruct file is.

See - although I can /use/ makefiles, I always seem to get them wrong when I try to hand craft them, no matter how many times I read through the man page. I'm spoilt on Windows GUIs now.

I made myself a custom build utility. You see, in D, EVERYTHING we need to know about what files to compile and link is contained within the ".d" files themselves. My tool starts at the file containing main(), recurses through all imports, discovers all dependencies, figures out what to build and what not to build, and then executes the commands to achieve that. Then it links them all together. The advantage of this system is that to add a module to the build process, or to remove a module from the build process, all I have to do is ... well ... nothing. If there's an import statement referring to it in a file reachable from main, then it's in, otherwise it's not. No makefile. All I need is a configuration file telling it what version symbols to define (and even that's optional if I want the default of none at all).

Advantages for me are ease of use, plus not having to write a makefile. (And not having to tweak it every time I add or remove a file).

Disadvantages are that it's not-standard. Although I could let other people have a bash at using my home made DMake thingy, most people don't like non-standard builders. Not only that, but my cunning scheme will only work for D. As soon as any C files try to get in on the act, it will all fall over.

But...

If any makefile experts out there would like to help me out by building a makefile for me, I certainly wouldn't say no for the assistance. The commands emitted by my builder (when everything is out of date) are listed below. These are for a debug build. For a release build, change "Debug" to "Release" and "-debug -g -inline -unittest" to "-release -O" throughout. I should add that the below trace uses *my* directory structure and so won't work for anyone else. Also, this just links all the files together, including "main.d" (the first one compiled) which is *NOT* part of the lib, it's just there so that there's a main() and I can make an executable.

I actually don't know how to make a D library. The manual is very clear about about how to make executables, and lists command line switches for the D compiler, but there's a lot less information about the D linker. As you can see from the below trace, I've been using dmd itself to invoke the linker indirectly.

So, er, help anyone?

Objectives:
(1) make a makefile that will work for everyone, and
(2) tell me how to make a D library instead of an executable.

=====================================================
THE OUTPUT OF JILL'S BUILD PROCESS
(building "main.d" linked to all of the bigint files)
(These lines will wrap. Hope you can untangle them)
=====================================================

# This directory is not part of the released package
cd X:\D\Modules\etc\bigint_test

# And nor is this file
C:\dmd\bin\dmd -c .\main.d  -debug -g -inline -unittest -IX:\D\Modules
-od.\Debug

# But from here on, it's all bigint stuff
C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint.d  -debug -g -inline -unittest
-IX:\D\Modules -odX:\D\Modules\etc\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\bigint.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\prime.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\factorial.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\exception.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\multiply.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\radix.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\modexp.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\prime.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\lowlevel.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\modinv.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -c X:\D\Modules\etc\bigint_files\gcd.d  -debug -g -inline -unittest -IX:\D\Modules -odX:\D\Modules\etc\bigint_files\Debug

C:\dmd\bin\dmd -g X:\D\Modules\etc\bigint_files\Debug\exception.obj X:\D\Modules\etc\bigint_files\Debug\lowlevel.obj X:\D\Modules\etc\bigint_files\Debug\multiply.obj X:\D\Modules\etc\bigint_files\Debug\radix.obj X:\D\Modules\etc\bigint_files\Debug\bigint.obj X:\D\Modules\etc\bigint_files\Debug\gcd.obj X:\D\Modules\etc\bigint_files\Debug\modinv.obj X:\D\Modules\etc\bigint_files\Debug\modexp.obj X:\D\Modules\etc\Debug\prime.obj X:\D\Modules\etc\bigint_files\Debug\prime.obj X:\D\Modules\etc\bigint_files\Debug\factorial.obj X:\D\Modules\etc\Debug\bigint.obj .\Debug\main.obj   -ofbigint_test.exe | tail -n+4

move bigint_test.exe Debug\bigint_test.exe

move bigint_test.map Debug\bigint_test.map

Arcane Jill wrote:
> In article <pan.2004.05.30.07.23.32.756180@demmegod.com>, DemmeGod says...
> 
>>Why not write a makefile, or better yet a Scons SConstruct file?
>>
>>John
> 
> 
> Ahem. Embarrassing confession time...
> 
> Because I can't write makefiles. And I don't know what a Scons SConstruct file
> is.

Here's a SConstruct. (SCons is hosted at <http://www.scons.org>)

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.

    import os
    from glob import glob

    env = Environment(ENV=os.environ)
    env.Append(DFLAGS=Split('''
            -debug -g -inline -unittest
        ''')
    )
    env.Append(DPATH='#') # appends the directory containing SConstruct to the path

    SRC = (
        glob('etc/*.d') +
        glob('etc/bigint_files/*.d')
    )

    bigint = env.Program('bigint', SRC)
    install = env.Install('#/Debug', bigint)

 -- andy

In article <c99pq0$1r32$2@digitaldaemon.com>, J Anderson wrote:
> You do know you can go:
> 
> Int a = a();

You probably meant:

Int a = Int();

-A

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:c9cu9v$1pu$1@digitaldaemon.com...
> In article <pan.2004.05.30.07.23.32.756180@demmegod.com>, DemmeGod says...
> ...
> I actually don't know how to make a D library. The manual is very clear
about
> ...

I didn't know also but i looked at what DIDE does and a minute later i have
a library:
So here it is:

C:\dmd\bin\dmd.exe -O -inline -release -c  -I. -I.. -odE:\DLANGU~1\BIGINT~1
    "E:\D language\bigintlib\bigint.d"
    "E:\D language\bigintlib\exception.d"
    "E:\D language\bigintlib\factorial.d"
    "E:\D language\bigintlib\gcd.d"
    "E:\D language\bigintlib\lowlevel.d"
    "E:\D language\bigintlib\modexp.d"
    "E:\D language\bigintlib\modinv.d"
    "E:\D language\bigintlib\multiply.d"
    "E:\D language\bigintlib\prime.d"
    "E:\D language\bigintlib\radix.d"
    "E:\D language\bigintlib\squareroot.d"

C:\dmd\bin\..\..\dm\bin\lib.exe -c bigintlib
    "E:\DLANGU~1\BIGINT~1\bigint.obj"
    "E:\DLANGU~1\BIGINT~1\exception.obj"
    "E:\DLANGU~1\BIGINT~1\factorial.obj"
    "E:\DLANGU~1\BIGINT~1\gcd.obj"
    "E:\DLANGU~1\BIGINT~1\lowlevel.obj"
    "E:\DLANGU~1\BIGINT~1\modexp.obj"
    "E:\DLANGU~1\BIGINT~1\modinv.obj"
    "E:\DLANGU~1\BIGINT~1\multiply.obj"
    "E:\DLANGU~1\BIGINT~1\prime.obj"
    "E:\DLANGU~1\BIGINT~1\radix.obj"
    "E:\DLANGU~1\BIGINT~1\squareroot.obj"

All i have to do is import etc.bigint; and link with bigintlib.lib and it works. The paths is something you will have to change!

Antti Sykäri wrote:

>In article <c99pq0$1r32$2@digitaldaemon.com>, J Anderson wrote:
>  
>
>>You do know you can go:
>>
>>Int a = a();
>>    
>>
>
>You probably meant:
>
>Int a = Int();
>
>-A
>  
>
Or that as well ;)

-- 
-Anderson: http://badmama.com.au/~anderson/

Arcane Jill wrote:

> In article <pan.2004.05.30.07.23.32.756180@demmegod.com>, DemmeGod says...
> 
>>Why not write a makefile, or better yet a Scons SConstruct file?
>>
>>John
> 
> 
> Ahem. Embarrassing confession time...
> 
> Because I can't write makefiles. And I don't know what a Scons SConstruct file
> is.

Below follows a main.aap that can build and install bigint. A-A-P can be
found at www.a-a-p.org and do the same things as SCons in a less cryptic syntax (IMHO).


And to everyone; just because I wonder: I see that a lot of people use SCons; apart from the fact that you heard about it first (most likely), what makes SCons a better choice than A-A-P?

To just build:
> aap

To install:
> aap install

BTW, had to add the -d switch as there were C-style casts in the version of bigint that I downloaded. Everything behind '#' is comments.

main.aap
----------------------
:import d

# All variables can be set at the command line, e.g. :
# > aap PREFIX=/myroot
DEBUG = yes
DDEBUG = -debug
DFLAGS += -inline -unittest -d

LIBDIR = bigintlib # or any other dir you want to put it in (default is lib)
PREFIX = mylibroot # default is /usr/local

Source = etc/*.d
         etc/bigint_files/*.d

:lib bigint : $Source
-----------------------

Lars Ivar Igesund

Lars Ivar Igesund wrote:
> And to everyone; just because I wonder: I see that a lot of people use SCons; apart from the fact that you heard about it first (most likely), what makes SCons a better choice than A-A-P?

I like that SCons is an API as opposed to a language.  This has the effect of obliviating the distinction between using and extending SCons.

The fact that SCons is Python, a language I am very much a fan of, doesn't hurt things either. ;)

 -- andy

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 ;-)

Andy Friesen wrote:
> Lars Ivar Igesund wrote:
> 
>> And to everyone; just because I wonder: I see that a lot of people use SCons; apart from the fact that you heard about it first (most likely), what makes SCons a better choice than A-A-P?
> 
> 
> I like that SCons is an API as opposed to a language.  This has the effect of obliviating the distinction between using and extending SCons.
> 
> The fact that SCons is Python, a language I am very much a fan of, doesn't hurt things either. ;)
> 
>  -- andy