• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> Oct 17 2004
• Ben Hinkle <bhinkle4 juno.com> Oct 17 2004
• Ben Hinkle <bhinkle4 juno.com> Oct 17 2004
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> Oct 17 2004
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> Oct 17 2004
• =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> Oct 17 2004
• Ben Hinkle <bhinkle4 juno.com> Oct 17 2004
• Regan Heath <regan netwin.co.nz> Oct 17 2004
• Ben Hinkle <bhinkle4 juno.com> Oct 17 2004
• Derek Parnell <derek psych.ward> Oct 17 2004
• "Ben Hinkle" <bhinkle mathworks.com> Oct 18 2004
• "Matthew" <admin.hat stlsoft.dot.org> Oct 18 2004

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:
 
 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/

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

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

[snip]
 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


Hmm. For me it works on Linux and Windows but when I try with the -unittest
flag on Windows I get
list.obj(list)
 Error 42: Symbol Undefined _init_10TypeInfo_a
list.obj(list)
 Error 42: Symbol Undefined _init_11TypeInfo_Aa
list.obj(list)
 Error 42: Symbol Undefined _init_10TypeInfo_i
--- errorlevel 3

There could be some issue about __init vs _init. See also
digitalmars.D.bugs/1904
and
digitalmars.D.bugs/1946

-Ben

 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.


My fault, not yours. (I didn't realise that that was the case - I thought it
was all relative.)

DTL 0.3 will be coming as soon as I've got 15 million things sorted, and will
have a sensible makefile.

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


It shouldn't. DTL is currently floundering at the end of a list.

If there's anyone's left who's interested when I get round to doing the next
round, things should be significantly 
better.

Matthew