I'm a hobby programmer - I write programs for fun and recreation. Usually they are truly simple things. And I've found D very expressive in that regard - I'd say I spend a lot less time programming the same quantity of program in D than in Java or C++.

But libraries in D - these things do me in. I mean, when programming in C++ any library is going to have its own little "how to install - cannot possibly fail" recipe in a small text file. It's quick and painless - type "make && make install" and you're set. You just include the relevant header file (which is already in the include path due to make install) and you're laughing.

I honestly cannot figure out how to use DTL/MinTL. Maybe I am unbelievably dumb - but a word of warning: If I can't figure this out; if this language becomes popular with completely new programmers (and it might be more attractive to them because it's a simpler language than for example C++) then this is going to become hell.

My question is simply: How am I supposed to build and install DTL/MinTL?

Everybody seems to have a different layout. DTLs makefile is riddled with SYNSOFT_ROOT (of which I have none), and obviously assumes that I've got things sorted in some specific order. MinTL hasn't got anything to help me at all. dmake (more hardcoded paths and general nausea from trying to figure out how to actually make it resolve paths, as in my case it was determined not to read sc.ini no matter what I did) just built 4-5 object files and linked it into my app, but when compiling with -unittest I got link errors (which to me are generally fairly greek).

Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is linked list. It shouldn't be this complicated.

I recall an old "Plug 'n' Play" joke: In D, it's more like "Plug 'n' Pray". At least for me. But I am quite possibly unbelievably dumb.

Cheers,
Sigbjørn Lund Olsen

Sigbjørn Lund Olsen wrote:

> I'm a hobby programmer - I write programs for fun and recreation. Usually they are truly simple things. And I've found D very expressive in that regard - I'd say I spend a lot less time programming the same quantity of program in D than in Java or C++.
> 
> But libraries in D - these things do me in. I mean, when programming in C++ any library is going to have its own little "how to install - cannot possibly fail" recipe in a small text file. It's quick and painless - type "make && make install" and you're set. You just include the relevant header file (which is already in the include path due to make install) and you're laughing.
> 
> I honestly cannot figure out how to use DTL/MinTL. Maybe I am unbelievably dumb - but a word of warning: If I can't figure this out; if this language becomes popular with completely new programmers (and it might be more attractive to them because it's a simpler language than for example C++) then this is going to become hell.
> 
> My question is simply: How am I supposed to build and install DTL/MinTL?
> 
> Everybody seems to have a different layout. DTLs makefile is riddled
> with SYNSOFT_ROOT (of which I have none), and obviously assumes that
> I've got things sorted in some specific order. MinTL hasn't got anything
> to help me at all. dmake (more hardcoded paths and general nausea from
> trying to figure out how to actually make it resolve paths, as in my
> case it was determined not to read sc.ini no matter what I did) just
> built 4-5 object files and linked it into my app, but when compiling
> with -unittest I got link errors (which to me are generally fairly greek).
> 
> Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is linked list. It shouldn't be this complicated.
> 
> I recall an old "Plug 'n' Play" joke: In D, it's more like "Plug 'n' Pray". At least for me. But I am quite possibly unbelievably dumb.
> 
> Cheers,
> Sigbjørn Lund Olsen

Near the end of the MinTL doc there is a section about "installing". What
you do is add the containers you want plus the following: mintl/share.d
mintl/seq.d (and it looks like mintl/array.d). So for example if the file
mytest.d has
 import mintl.list;
 int main() {
  List!(int) list;
  list.add(10,20,30);
  return 0;
 }
then it can be compiles with
dmd mytest.d mintl/list.d mintl/share.d mintl/seq.d mintl/array.d
The array.d is needed because of unittests - I should try to move those
unittests elsewhere so that the dependencies are kept simple. The reason
there isn't a makefile to make a library is that the lib would just contain
a few exception classes - everything else is a template. I'll look into it,
though, since it would be nice to trim down that list of stuff you need to
type to get it to compile.

If you get link errors like
undefined reference to `_Class_5mintl5share25IndexOutOfBoundsException'
then put mintl/share.d on the compilation list. It should be pretty easy to
pick the module that is missing since it is mangled to "5mintl5share".
Building with unittests might include more. Ignore any linker warnings
about sizes of things being different - I get those all the time. They make
me nervous but it doesn't seem to matter.

I'll move that section about installing to the top of the doc so it is easier to find. Plus I notice that it leaves out mintl/array.d so I'll figure out what to do about that.

good luck!
-Ben

> The reason
> there isn't a makefile to make a library is that the lib would just
> contain a few exception classes - everything else is a template. I'll look
> into it, though, since it would be nice to trim down that list of stuff
> you need to type to get it to compile.

done.

> I'll move that section about installing to the top of the doc so it is easier to find.

done.

Ben Hinkle wrote:
> 
>>The reason
>>there isn't a makefile to make a library is that the lib would just
>>contain a few exception classes - everything else is a template. I'll look
>>into it, though, since it would be nice to trim down that list of stuff
>>you need to type to get it to compile.
> 
> done.

Thanks. However:

E:\Programs\dmd\src\mintl>make -f win32.mak
make: *** No rule to make target `array.obj', needed by `mintl.lib'.  Stop.

You may want to add that one should be using DM make and not GNU make.

Cheers,
Sigbjørn Lund Olsen

Sigbjørn Lund Olsen wrote:

> Ben Hinkle wrote:
> 
>>
>>> The reason
>>> there isn't a makefile to make a library is that the lib would just
>>> contain a few exception classes - everything else is a template. I'll look
>>> into it, though, since it would be nice to trim down that list of stuff
>>> you need to type to get it to compile.
>>
>>
>> done.
> 
> 
> Thanks. However:
> 
> E:\Programs\dmd\src\mintl>make -f win32.mak
> make: *** No rule to make target `array.obj', needed by `mintl.lib'.  Stop.
> 
> You may want to add that one should be using DM make and not GNU make.
> 
> Cheers,
> Sigbjørn Lund Olsen

I really must have the lowest IQ on the planet. I really, really, cannot figure out how to make it import the correct source files in any logical manner. I don't want to move my source to my mintl directories, nor do I want to move the mintl sources to my project directory - maybe I'm funny that way, but I don't have to do that when I use GCC, and I don't think it ought to be necessary to do it when I'm using DMD. In the end I did this:

G:\docs\dev\ozip\ozip\lib\rle>dmd ac.d E:\programs\dmd\src\import\mintl\slist.d
E:\programs\dmd\src\import\mintl\seq.d E:\programs\dmd\src\import\mintl\array.d
E:\programs\dmd\src\import\mintl\share.d mintl.lib -unittest
E:\Programs\dmd\bin\..\..\dm\bin\link.exe ac+slist+seq+array+share,,,mintl.lib+u
ser32+kernel32/noi;

Now I don't think that looks very pretty. There's something to the idea that for example you have an "include" (or say, an "import") directory somewhere under DMD_ROOT, and when you do "#include GL/glx.h" or "import mintl.slist.d" then the compiler automagically has a look there. I thought this was a bit of the idea with modules/packages mapping to files/folders anyway. Have I completely missed out on how I'm supposed to do this? Or is it simply not possible?

*sigh*

Cheers,
Sigbjørn Lund Olsen

Sigbjørn Lund Olsen wrote:

FYI:

import mintl.list;
int main ()
{
	List!(ubyte) res_list;
	res_list.add(10,20,30);
	return 0;
}

gives:

Error: Illegal item in mintl.share.add

Changing the ubyte to int makes it run nicely.

Cheers,
Sigbjørn Lund Olsen

Sigbjørn Lund Olsen wrote:

> Sigbjørn Lund Olsen wrote:
> 
>> Ben Hinkle wrote:
>> 
>>>
>>>> The reason
>>>> there isn't a makefile to make a library is that the lib would just
>>>> contain a few exception classes - everything else is a template. I'll
>>>> look
>>>> into it, though, since it would be nice to trim down that list of stuff
>>>> you need to type to get it to compile.
>>>
>>>
>>> done.
>> 
>> 
>> Thanks. However:
>> 
>> E:\Programs\dmd\src\mintl>make -f win32.mak
>> make: *** No rule to make target `array.obj', needed by `mintl.lib'.
>> Stop.
>> 
>> You may want to add that one should be using DM make and not GNU make.
>> 
>> Cheers,
>> Sigbjørn Lund Olsen
> 
> I really must have the lowest IQ on the planet. I really, really, cannot figure out how to make it import the correct source files in any logical manner. I don't want to move my source to my mintl directories, nor do I want to move the mintl sources to my project directory - maybe I'm funny that way, but I don't have to do that when I use GCC, and I don't think it ought to be necessary to do it when I'm using DMD. In the end I did this:
> 
> G:\docs\dev\ozip\ozip\lib\rle>dmd ac.d
> E:\programs\dmd\src\import\mintl\slist.d
> E:\programs\dmd\src\import\mintl\seq.d
> E:\programs\dmd\src\import\mintl\array.d
> E:\programs\dmd\src\import\mintl\share.d mintl.lib -unittest
> E:\Programs\dmd\bin\..\..\dm\bin\link.exe
> ac+slist+seq+array+share,,,mintl.lib+u
> ser32+kernel32/noi;
> 
> Now I don't think that looks very pretty. There's something to the idea that for example you have an "include" (or say, an "import") directory somewhere under DMD_ROOT, and when you do "#include GL/glx.h" or "import mintl.slist.d" then the compiler automagically has a look there. I thought this was a bit of the idea with modules/packages mapping to files/folders anyway. Have I completely missed out on how I'm supposed to do this? Or is it simply not possible?
> 
> *sigh*
> 
> Cheers,
> Sigbjørn Lund Olsen

yeah - I agree that is a pain. Any time you want to use a template with any asserts in it you have to spell it out on the dmd command line. At least that's the way it seems to me. One can use the -I option to add a path to the import lookup path but that doesn't handle template instantiations. Maybe we can get Walter's attention and he can think of something simpler. Here is an example:

file foo1.d:
module foo1;
struct Foo(V) {
  invariant{ assert(true); }
}

file foo2.d
module foo2;
import foo1;
int main() {
  Foo!(int) x;
  return 0;
}

compile with "dmd foo2.d" and you'll get an undefined ref to _assert_4foo1. If you take the assert out it works ok. If you compile with -release then it is also ok. A similar linking problem seems to happen when using mintl in the vararg mixin function add(). See the D.bugs list where I found with experimenting that the order of declarations fixes some linking bugs. I was also getting behavior that was hard to reproduce or didn't reproduce on win32 or linux. In general I've been quite frustrated trying to get complex mixin and module dependencies to link. It seems to be worse in dmd-102 but that is just a gut feeling. Anyway, any help reproducing linking problems would be appreciated because I think your experience will be typical.

-Ben

-Ben

Sigbjørn Lund Olsen wrote:

> Sigbjørn Lund Olsen wrote:
> 
> FYI:
> 
> import mintl.list;
> int main ()
> {
> List!(ubyte) res_list;
> res_list.add(10,20,30);
> return 0;
> }
> 
> gives:
> 
> Error: Illegal item in mintl.share.add
> 
> Changing the ubyte to int makes it run nicely.
> 
> Cheers,
> Sigbjørn Lund Olsen

ahh - that's going to be a pain. Since add() is vararg it doesn't know
10,20,30 need to be ubytes instead of ints. I'll try putting some extra
smarts in add() to look for int and try casting to the target type.
Probably that would make sense for other types with implicit conversions.
The work-around is to use
 res_list.add(cast(ubyte)10,cast(ubyte)20,cast(ubyte)30);
or
 res_list ~= 10;
 res_list ~= 20;
 res_list ~= 30;
both very ugly, I know.

On Sun, 17 Oct 2004 16:42:21 -0400, Ben Hinkle <bhinkle4@juno.com> wrote:
> Sigbjørn Lund Olsen wrote:
>
>> Sigbjørn Lund Olsen wrote:
>>
>> FYI:
>>
>> import mintl.list;
>> int main ()
>> {
>> List!(ubyte) res_list;
>> res_list.add(10,20,30);
>> return 0;
>> }
>>
>> gives:
>>
>> Error: Illegal item in mintl.share.add
>>
>> Changing the ubyte to int makes it run nicely.
>>
>> Cheers,
>> Sigbjørn Lund Olsen
>
> ahh - that's going to be a pain. Since add() is vararg it doesn't know
> 10,20,30 need to be ubytes instead of ints. I'll try putting some extra
> smarts in add() to look for int and try casting to the target type.
> Probably that would make sense for other types with implicit conversions.
> The work-around is to use
>  res_list.add(cast(ubyte)10,cast(ubyte)20,cast(ubyte)30);
> or
>  res_list ~= 10;
>  res_list ~= 20;
>  res_list ~= 30;
> both very ugly, I know.

Can you change the signature of add to:

void add(T one, ...)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Sun, 17 Oct 2004 09:13:50 -0400, Ben Hinkle wrote:

> Sigbjørn Lund Olsen wrote:
> 
>> I'm a hobby programmer - I write programs for fun and recreation. Usually they are truly simple things. And I've found D very expressive in that regard - I'd say I spend a lot less time programming the same quantity of program in D than in Java or C++.
>> 
>> But libraries in D - these things do me in. I mean, when programming in C++ any library is going to have its own little "how to install - cannot possibly fail" recipe in a small text file. It's quick and painless - type "make && make install" and you're set. You just include the relevant header file (which is already in the include path due to make install) and you're laughing.
>> 
>> I honestly cannot figure out how to use DTL/MinTL. Maybe I am unbelievably dumb - but a word of warning: If I can't figure this out; if this language becomes popular with completely new programmers (and it might be more attractive to them because it's a simpler language than for example C++) then this is going to become hell.
>> 
>> My question is simply: How am I supposed to build and install DTL/MinTL?
>> 
>> Everybody seems to have a different layout. DTLs makefile is riddled
>> with SYNSOFT_ROOT (of which I have none), and obviously assumes that
>> I've got things sorted in some specific order. MinTL hasn't got anything
>> to help me at all. dmake (more hardcoded paths and general nausea from
>> trying to figure out how to actually make it resolve paths, as in my
>> case it was determined not to read sc.ini no matter what I did) just
>> built 4-5 object files and linked it into my app, but when compiling
>> with -unittest I got link errors (which to me are generally fairly greek).
>> 
>> Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is linked list. It shouldn't be this complicated.
>> 
>> I recall an old "Plug 'n' Play" joke: In D, it's more like "Plug 'n' Pray". At least for me. But I am quite possibly unbelievably dumb.
>> 
>> Cheers,
>> Sigbjørn Lund Olsen
> 
> Near the end of the MinTL doc there is a section about "installing". What
> you do is add the containers you want plus the following: mintl/share.d
> mintl/seq.d (and it looks like mintl/array.d). So for example if the file
> mytest.d has
>  import mintl.list;
>  int main() {
>   List!(int) list;
>   list.add(10,20,30);
>   return 0;
>  }
> then it can be compiles with
> dmd mytest.d mintl/list.d mintl/share.d mintl/seq.d mintl/array.d
> The array.d is needed because of unittests - I should try to move those
> unittests elsewhere so that the dependencies are kept simple. The reason
> there isn't a makefile to make a library is that the lib would just contain
> a few exception classes - everything else is a template. I'll look into it,
> though, since it would be nice to trim down that list of stuff you need to
> type to get it to compile.
> 
> If you get link errors like
> undefined reference to `_Class_5mintl5share25IndexOutOfBoundsException'
> then put mintl/share.d on the compilation list. It should be pretty easy to
> pick the module that is missing since it is mangled to "5mintl5share".
> Building with unittests might include more. Ignore any linker warnings
> about sizes of things being different - I get those all the time. They make
> me nervous but it doesn't seem to matter.
> 
> I'll move that section about installing to the top of the doc so it is easier to find. Plus I notice that it leaves out mintl/array.d so I'll figure out what to do about that.
> 
> good luck!
> -Ben

I tried to compile this too. But the linkage failed.

C:\dparnell\D_Proj\mintl>dmd test.d mintl/list.d mintl/share.d mintl/seq.d
mintl/array.d
C:\DPARNELL\DMD\BIN\..\..\dm\bin\link.exe
test+list+share+seq+array,,,user32+kernel32/noi;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

test.obj(test)
 Error 42: Symbol Undefined _init_10TypeInfo_i
--- errorlevel 1




-- 
Derek
Melbourne, Australia
18/10/2004 9:18:30 AM