Re: [Caml-list] Dynamically evaluating OCaml code

Re: [Caml-list] Dynamically evaluating OCaml code

[Issac Trotts]

On Wed, Apr 07, 2004 at 11:05:24PM +0200, Basile Starynkevitch wrote:
> On Wed, Apr 07, 2004 at 06:47:30PM +0000, John Goerzen wrote:
> 
> > I am moving from Python to OCaml and one of the things I miss is
> > Python's eval() call.  It takes a string representing a bit of Python
> > source code, evaluates it, and returns the result.  I would like to be
> > able to do similar things with OCaml.
[...]
> However, for the beginner, the good answer (at least as given by Ocaml
> gurus here) to the usual "I want eval" request is simply "no you don't
> really need it"

That being so, how would you use OCaml as an extension language for a C
program?  

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

Hello,

I am moving from Python to OCaml and one of the things I miss is
Python's eval() call.  It takes a string representing a bit of Python
source code, evaluates it, and returns the result.  I would like to be
able to do similar things with OCaml.

I have observed that /usr/bin/ocaml, the interactive top-level, is
itself written in OCaml, which suggests that this should be possible.
Although I have tried to study the source for this, it seems extremely
complex and I can't figure out a way to do the simple evaluation
described above.

Can anyone help me out here?

Thanks,
John


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Samuel Mimram]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

Le Wed, 7 Apr 2004 18:47:30 +0000 (UTC) John Goerzen
<jgoerzen@complete.org> a écrit :

> Hello,
> 
> I am moving from Python to OCaml and one of the things I miss is
> Python's eval() call.  It takes a string representing a bit of Python
> source code, evaluates it, and returns the result.  I would like to be
> able to do similar things with OCaml.
> 
> I have observed that /usr/bin/ocaml, the interactive top-level, is
> itself written in OCaml, which suggests that this should be possible.
> Although I have tried to study the source for this, it seems extremely
> complex and I can't figure out a way to do the simple evaluation
> described above.
> 
> Can anyone help me out here?
> 
> Thanks,
> John

Such a function cannot be programmed in OCaml because it would break the
typing system: what would the type of "eval"? 'a?
The following code could then lead to segfaults:

let n = ref "toto" in
n := eval "9"

because the typing system is borken: n is a string ref and gets an
integer! And there's no way to avoid that.

The only thing you can do is to dynamically load compiled bytecode files
(cf. the Dynlink module).

Samuel.


-- 
Samuel Mimram

samuel.mimram@ens-lyon.fr


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 01:32:41AM +0400, Vitaly Lugovsky wrote:
> 
> On Wed, 7 Apr 2004, John Goerzen wrote:
> 
> > Hello,
> >
> > I am moving from Python to OCaml and one of the things I miss
> > is Python's eval() call.  It takes a string representing a bit
> > of Python source code, evaluates it, and returns the result.
> > I would like to be able to do similar things with OCaml.
> 
>  OCaml is a compiler, not interpreter. But, you'll find that this
> feature is obsoleted by the partial application - it's a much
> more powerfull device then lispish eval, and it can be even a
> replacement for a macros.

I don't think that will help me here; I'm looking at being able to let
people insert OCaml expressions directly into otherwise plain-text
config files.

And while I understand your general point about OCaml being a compiler,
I think you'd have to admit that this line is at least blurred by the
interactive toplevel *interpreter* /usr/bin/ocaml :-)  It is a subset of
that program's functionality that I seek to imitate.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Basile Starynkevitch]

On Wed, Apr 07, 2004 at 06:47:30PM +0000, John Goerzen wrote:

> I am moving from Python to OCaml and one of the things I miss is
> Python's eval() call.  It takes a string representing a bit of Python
> source code, evaluates it, and returns the result.  I would like to be
> able to do similar things with OCaml.

As observed by others, there is a big typing issue around this (what
would be the type of the eval function)?

If you really need something, you could hack the toplevel (at your own
risk). I don't think it is a good idea, unless you did very well
understood what you really want to do.

However, the functional values are usually enough to avoid the "eval",
and an "eval" won't be really safe.

Also, you could use metaocaml, which provide constructs (inspired by
eval) to typefully meta-program, ie generate programs at runtime in a
rather safe manner.

See http://www.cs.rice.edu/~taha/MetaOCaml/ for more.

dynamics (like old work from Leroy & Mauny - see X.Leroy's publication
pages on http://cristal.inria.fr/~xleroy ) and runtime type
information (like in Jun Furse GCaml) might also help - and are in
some remote way a bit related to eval's typing.

In addition to typing issues, there is also a runtime issue: dynamic
code generation really requires garbage collection of executable code,
which is not available in Ocaml (and would be terrible to implement -
it would mean rewrite most of the system)

________________


However, for the beginner, the good answer (at least as given by Ocaml
gurus here) to the usual "I want eval" request is simply "no you don't
really need it"



-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - INRIA Rocquencourt
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Vitaly Lugovsky]

On Wed, 7 Apr 2004, John Goerzen wrote:

> Hello,
>
> I am moving from Python to OCaml and one of the things I miss
> is Python's eval() call.  It takes a string representing a bit
> of Python source code, evaluates it, and returns the result.
> I would like to be able to do similar things with OCaml.

 OCaml is a compiler, not interpreter. But, you'll find that this
feature is obsoleted by the partial application - it's a much
more powerfull device then lispish eval, and it can be even a
replacement for a macros.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Vitaly Lugovsky]

On Wed, 7 Apr 2004, John Goerzen wrote:

> >  OCaml is a compiler, not interpreter. But, you'll find that this
> > feature is obsoleted by the partial application - it's a much
> > more powerfull device then lispish eval, and it can be even a
> > replacement for a macros.
>
> I don't think that will help me here; I'm looking at being
> able to let
> people insert OCaml expressions directly into otherwise
> plain-text config files.

 You really need OCaml with all its power as a DSL for a
configuration, or, may be, you'd like to implement a small DSL,
may be even Caml subset?

> And while I understand your general point about OCaml being a
> compiler,
> I think you'd have to admit that this line is at least blurred
> by the
> interactive toplevel *interpreter* /usr/bin/ocaml :-)  It is a
> subset of
> that program's functionality that I seek to imitate.

 Ok. If you're happy with a performance of the bytecode
interpreter - you can use such a feature (the easiest way is to
just create a custom runtime, see the documentation on how to
do it). But this is absolutely impossible for a native compilation.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Benjamin Geer]

John Goerzen wrote:
> I'm looking at being able to let
> people insert OCaml expressions directly into otherwise plain-text
> config files.

One option you might not have considered is using Schoca, Christoph 
Bauer's implementation of the Scheme language in Caml:

http://sourceforge.net/project/showfiles.php?group_id=2598

Schoca contains an example Caml program that reads a configuration file 
written in Scheme.  Scheme has a lot going for it as an extension 
language; for one thing, it's very easy to learn.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[clement capel]

 Try this simple example:


 
 Toploop.initialize_toplevel_env();;

 let eval txt = let lb = (Lexing.from_string txt) in
   let phr = !Toploop.parse_toplevel_phrase lb in
   Toploop.execute_phrase true Format.std_formatter phr;;

 eval "let add1 x = x +1;;";;
 eval "add1 2;;";;

(compile with toplevellib.cma)

 But be careful, it can break the typing system.
 if you use the Toploop module in the 
"string parameter" of the function eval or if you
evaluate it in the toplevel. 
But it seems there's a guard with the new version (3.07+2).



 Hope it will help you.

 Regards,

                       Clément

> Le Mercredi 7 Avril 2004 18:47, John Goerzen a écrit :
> > Hello,
> >
> > I am moving from Python to OCaml and one of the things I miss is
> > Python's eval() call.  It takes a string representing a bit of Python
> > source code, evaluates it, and returns the result.  I would like to be
> > able to do similar things with OCaml.
> >
> > I have observed that /usr/bin/ocaml, the interactive top-level, is
> > itself written in OCaml, which suggests that this should be possible.
> > Although I have tried to study the source for this, it seems extremely
> > complex and I can't figure out a way to do the simple evaluation
> > described above.
> >
> > Can anyone help me out here?
> >
> > Thanks,
> > John
> >
> >
> > -------------------
> > To unsubscribe, mail caml-list-request@inria.fr Archives:
> > http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> > http://caml.inria.fr/FAQ/ Beginner's list:
> > http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Jon Harrop]

On Wednesday 07 April 2004 7:47 pm, John Goerzen wrote:
> I am moving from Python to OCaml and one of the things I miss is
> Python's eval() call.  It takes a string representing a bit of Python
> source code, evaluates it, and returns the result.  I would like to be
> able to do similar things with OCaml.

I know exactly what you mean. I used to use an equivalent "EVAL" function in 
BBC BASIC.

I notice that some of the responses to your post stated that this would break 
the type system. I think that this is incorrect because it is failing to 
distinguish between "eval" and dynamic code loading. Obviously we want the 
latter to be typesafe, but the former blurs the distinction between compile- 
and run-time, and valid results of calling "eval" would be a syntax error in 
the given code or, equally, a type mismatch in the result. I suspect you want 
a function which returns one of a set of possible values, or raises 
exceptions in the case of invalid code or return type.

Clement Capel's response is the most interesting so far (IMHO), but I would be 
interested to see a safe version which allowed you to get at the resulting 
data. :-)

Just out of curiosity, what kind of stuff do you want to evaluate? Simple 
mathematical expressions, or actual programs?

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Dustin Sallings]

On Jan 3, 2002, at 16:43, Issac Trotts wrote:

> That being so, how would you use OCaml as an extension language for a C
> program?

	You would do this in a similar way that you would use C++ as an 
extension language for a java program.

-- 
Dustin Sallings

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Brian Hurt]

On Thu, 3 Jan 2002, Issac Trotts wrote:

> That being so, how would you use OCaml as an extension language for a C
> program?  
> 

I would use C as an extension language for Ocaml.

This isn't meant to be a snarky answer.  Ocaml is an applications
language- you should write the bulk of the code in Ocaml, and drop to C in
places where you need to.  If you're looking for a language to embed, you
might try looking at one designed to be embeeded, like Lua.  Or a Lisp
variant.  But that isn't what Ocaml is designed for.

Nor would it be a good language for that.  Consider the complexity of the
Ocaml 'eval' function.  On my system (Redhat 9, x86, Ocaml 3.07) Ocamlc is
920K in size, and ocamlrun another 144K.  You'd have to replicate the
majority of that in the eval function- so you're talking north of a
megabyte of code.  As an application, that's small.  As a library, that's
huge.  It's of the same size as linking in libgtk (1.3M).  No, you want a 
small, simple language.  Although this might not be so bad- libperl.so on 
my machine weighs in at 3.2M.

As a side note, I don't see Ocaml as a science project.  It's a pragmatic
language, in that it doesn't automatically assume it knows what's best,
but instead provides the programmer the tools he needs to get the job
done.  As reflected in it's design decisions, the people designing Ocaml
were designing a production language to be used by real programmers on
real problems.  Science projects, especially computer science projects,
tend towards an extreme aesthetic, for two reasons.  First is that they're
designed to push a a specific idea or set of ideas.  Second, generality
requires extra effort, which isn't worth it if all you're doing is an
experiment.

Two examples of this in action.  First, consider the different ways you 
can run Ocaml code.  You can interpret it (like Perl or Lisp, although 
Ocaml doesn't provide eval), you can compile it to native (like Fortran or 
C/C++), or you can use a virtual machine (like P-system Pascal or Java).  
The Ocaml writters didn't assume that one way was the "right" way and just 
implement that, they implemented all three.  Better yet, the same code 
runs in all three, just with slightly different performance 
characteristics.  Whichever solution is best for my particular case, I can 
do.

Second, consider the different paradigms Ocaml embodies.  Yes, functional 
is the default mode.  But Ocaml supports both OO and imperitive/procedural 
programming as well.  If those paradigms allow you to express a better 
algorithm or express the same algorithm better, use them!

The fact that it didn't include some things (like an eval() function) 
means it did include others.  I'll fault Perl, Python, Lisp, and the rest 
for not having a good static type system.

Wandering into the arena of suspect analogy, if C and C++ are the blue
collar assembly line workers, tightening bolts by hand, than Ocaml is the
robot repairman maintaining the whole factory of robots.  He's every bit
as blue collar and about getting real work done, but more educated and a
heck of lot more productive.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Basile Starynkevitch]

On Thu, Jan 03, 2002 at 04:43:56PM -0800, Issac Trotts wrote:
> On Wed, Apr 07, 2004 at 11:05:24PM +0200, Basile Starynkevitch wrote:

> > However, for the beginner, the good answer (at least as given by Ocaml
> > gurus here) to the usual "I want eval" request is simply "no you don't
> > really need it"
> 
> That being so, how would you use OCaml as an extension language for a C
> program?  

I'm not sure to understand your point. Many applications coded in C
embed Ocaml inside. The simplest way is to give the application a
compiled ocaml bytecode file (which can be choosen at runtime) invoked
thru ocaml_main

See section 18.7.4 Main program in C of
http://caml.inria.fr/ocaml/htmlman/manual032.html

An alternative is to have the application being a custum ocaml
program, with lots of C primitives. This means that the ocaml runtime
system has the control and invoke appropriately the C primitives
provided by the application.

If you ask about embedding the ocaml toplevel into your application,
it is a different question. I agree that extending or embedding or
customizing the toplevel is not very well documented.

Regards.

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - INRIA Rocquencourt
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Oleg Trott]

Brian Hurt wrote:

>
>Two examples of this in action.  First, consider the different ways you 
>can run Ocaml code.  You can interpret it (like Perl or Lisp, although 
>Ocaml doesn't provide eval), you can compile it to native (like Fortran or 
>C/C++), or you can use a virtual machine (like P-system Pascal or Java).  
>
>  
>

Actually, any decent Lisp implementation compiles to native code (like 
Fortran or C/C++). In my experience, after you add a bunch of type 
declarations to Lisp, it runs about as fast as OCaml native, but it runs 
interactively (with eval and everything). The issues of

1. compilation to native code
2. interactivity & runtime eval
3. strict typing (i.e. variables have types, not values)

are all orthogonal. Lisp provides 1 & 2, Ocamlopt provides 1 & 3, Ocaml 
(toplevel) provides 2 & 3, which covers all possible combinations of 2 
out of 3. I think SML/NJ gives all 3, but I don't use it, so I'm not sure.


Oleg

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Thu, 2004-04-08 at 06:39, John Goerzen wrote:
> On Thu, Apr 08, 2004 at 01:32:41AM +0400, Vitaly Lugovsky wrote:

> I don't think that will help me here; I'm looking at being able to let
> people insert OCaml expressions directly into otherwise plain-text
> config files.

Yeah, you can do that! But you need to be tricky!

Analyse the file, changing the plain text parts to
strings. You may need some wrappers like:

option5 = /dev/null

becomes

print_endline "option5 = /dev/null"

Now you can compile the file with Ocaml, and execute it.

This is very nice because you WILL be typechecking the code
fragments. Indeed you can do better, by making the client
write the WHOLE file in psuedo code that translates
to Ocaml, then the code executes things, instead of just
printing a text file to be run through bash, or some other
text interpreter.

By the way the code fragment technique is exactly what
my interscript literate programming tool does,
which makes it vastly superior to similar tool:
it embeds Python though, which does have 'eval'.

You might want to use it instead..since it already
does what you want .. and happens to be able to 
pretty print HTML documentation as well :D

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Ville-Pertti Keinonen]

On Apr 8, 2004, at 9:24 AM, Brian Hurt wrote:

> As a side note, I don't see Ocaml as a science project.  It's a 
> pragmatic
> language, in that it doesn't automatically assume it knows what's best,

To add another point why OCaml is a pragmatic and usable language - 
OCaml has far better platform support than some even more established 
languages.  It's the only language I might choose for my personal 
projects other than C/C++ that supports native code for all of the 
relevant platforms I currently have access to.  I have FreeBSD/amd64, 
FreeBSD/x86, Linux/x86 and MacOS X machines, all of which run OCaml 
fine, and use various machines at work that should be supported 
(although the last time I tried, the CVS version built and worked on 
Tru64 but not Solaris/SPARC or HP-UX/PA).

Of course I'm not counting languages that use C or C++ as an 
intermediate language.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Ville-Pertti Keinonen]

On Apr 8, 2004, at 10:47 AM, Oleg Trott wrote:

> Actually, any decent Lisp implementation compiles to native code (like 
> Fortran or C/C++). In my experience, after you add a bunch of type 
> declarations to Lisp, it runs about as fast as OCaml native, but it 
> runs interactively (with eval and everything). The issues of
>
> 1. compilation to native code
> 2. interactivity & runtime eval
> 3. strict typing (i.e. variables have types, not values)
>
> are all orthogonal. Lisp provides 1 & 2, Ocamlopt provides 1 & 3, 
> Ocaml (toplevel) provides 2 & 3, which covers all possible 
> combinations of 2 out of 3. I think SML/NJ gives all 3, but I don't 
> use it, so I'm not sure.

The latency for an interactive top-level that does native compilation 
is a bit high, but Lisp systems are certainly impressive in that you 
can interactively disassemble your functions.

SML/NJ has all 3, but not as conveniently as Lisp systems, and like 
many Lisp systems (and unlike OCaml), it doesn't support generating 
stand-alone native binaries.  Also like many Lisp systems, it only 
supports 32-bit platforms (there is Alpha support, but it's a 32-bit 
kludge).

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Dustin Sallings]

On Apr 8, 2004, at 0:52, Ville-Pertti Keinonen wrote:

> To add another point why OCaml is a pragmatic and usable language - 
> OCaml has far better platform support than some even more established 
> languages.  It's the only language I might choose for my personal 
> projects other than C/C++ that supports native code for all of the 
> relevant platforms I currently have access to.  I have FreeBSD/amd64, 
> FreeBSD/x86, Linux/x86 and MacOS X machines, all of which run OCaml 
> fine, and use various machines at work that should be supported 
> (although the last time I tried, the CVS version built and worked on 
> Tru64 but not Solaris/SPARC or HP-UX/PA).

	I've got a recent compiler built for SunOS 4.1.4 (sun4c).  That was a 
pretty big bonus for me.  It took a little hacking, but ocamlopt works.

	Unfortunately, I end up doing a lot of my professional work in 
platform independent languages like Java (a recent enough-to-be-useful 
version of which only runs on a few of my computers).

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 01:24:45AM -0500, Brian Hurt wrote:
> majority of that in the eval function- so you're talking north of a
> megabyte of code.  As an application, that's small.  As a library, that's
> huge.  It's of the same size as linking in libgtk (1.3M).  No, you want a 
> small, simple language.  Although this might not be so bad- libperl.so on 
> my machine weighs in at 3.2M.

Indeed, and in fact:

-rw-r--r--    1 root     root      1073392 Feb 24 02:34 /usr/lib/libpython2.3.so.1.0

Python is often used as an embedded extension language as well.

> As a side note, I don't see Ocaml as a science project.  It's a pragmatic
> language, in that it doesn't automatically assume it knows what's best,
> but instead provides the programmer the tools he needs to get the job
> done.  As reflected in it's design decisions, the people designing Ocaml

Careful; that sounds like you're describing Perl :-)

[snip]

> Wandering into the arena of suspect analogy, if C and C++ are the blue
> collar assembly line workers, tightening bolts by hand, than Ocaml is the
> robot repairman maintaining the whole factory of robots.  He's every bit
> as blue collar and about getting real work done, but more educated and a
> heck of lot more productive.

I agree with most of your analogy here.  I'm still relatively new to
OCaml, having been using it for only a couple of months, but you've
touched on one of my pet peeves: the OCaml standard library is really
sub-par for doing real work.  Don't get me wrong; I'm still using OCaml,
but have to do a lot more wheel reinventing than with, say, Python.
Even basic functions that I've found in *every* other langauge I've used
are missing (here I'm thinking of things like asctime(), strptime(), and
many things relating to sockets and DNS [*especially* the complete lack
of IPv6 support).  The standard I/O functions miss out on trivial things
that I could do way back on DOS with Turbo Pascal, such as opening a
file for both read and write.  (I'd have to go through the Unix module
and some pain to do that in OCaml.)

Basic string processing is also more difficult than a language such as,
say, Python, where I can say, for instance:

y = x[2:-1]

In OCaml, I would write -- I think:

let y = String.sub x 2 ((String.length x) - 3))

Also, there is no string_of_char function (I'd have to use fill).
Things like splitting a string have to rely on str and regexps, an
unnecessary complexity for 90% of what I do.

Similar complaints exist for working with subsets of lists; it's really
too hard to say "replace elements 4 through 9 with this", "delete
elements 4 through 9", "return elements 4 through 9", etc.  (While we're
at it, I think it's silly that there is a list and an array type).  Yes,
I could write functions to do all of this, but my point is that I
shouldn't have to.

This library problem hurts productivity, and in some cases makes OCaml
less productive than even C.

One other thing to mention is that installing libraries is much more
difficult than it should be, and writing library build systems (and even
app build systems) is much more complex than it should be.  Part of this
is due to a lack of a standardized build system (think Perl's MakeMaker
or Python's setup.py).  Part of it is due to the complex array of OCaml
options -- for instance, some platforms do not support ocamlopt, so
while a library might normally build both native and byte-code versions,
it has to not try to if ocamlopt is missing.  (Something which, I have
found, many OCaml authors fail to consider.)  I've been toying with the
idea of writing a generic build system for OCaml to address this point
though.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Markus Mottl]

On Thu, 08 Apr 2004, John Goerzen wrote:
> Also, there is no string_of_char function (I'd have to use fill).

That's not quite true: there is "String.make", which does what you want.

> Similar complaints exist for working with subsets of lists; it's really
> too hard to say "replace elements 4 through 9 with this", "delete
> elements 4 through 9", "return elements 4 through 9", etc.

Yes, it's hard to do this with the current standard library.  The question
is: who needs these functions anyway?  I can't remember ever having felt
a need for them.

> (While we're at it, I think it's silly that there is a list and an
> array type).

I beg your pardon - what else do you have in mind???

> Yes, I could write functions to do all of this, but my point is that
> I shouldn't have to.

The point of the standard library is not to have a function for every
imaginable problem but to have ones that cover standard problems.

> This library problem hurts productivity, and in some cases makes OCaml
> less productive than even C.

Things are not half as bad as you describe them here.  There may be
cases where C is more productive - because you happen to have a library
function for the problem.  But even in this case you can just interface
to C, which is really not that difficult.

There are surely cases where the OCaml standard library lacks generally
useful functionality, but it's usually good enough for most problems.

Regards,
Markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Fernando Alegre]

On Thu, Apr 08, 2004 at 08:37:27AM -0500, John Goerzen wrote:

> Basic string processing is also more difficult than a language such as,
> say, Python, where I can say, for instance:
> 
> y = x[2:-1]
> 
> In OCaml, I would write -- I think:
> 
> let y = String.sub x 2 ((String.length x) - 3))
> 

You can always use the ability of Ocaml to create new operators to
partially overcome this problem:

# let ($<) s i = String.sub s 0 i;;
val ( $< ) : string -> int -> string = <fun>

# let ($>) s i = String.sub s (String.length s - i) i;;
val ( $> ) : string -> int -> string = <fun>

# "hello, world" $< 5 $> 3;;
- : string = "llo"

# "hello, world" $> 5 $< 3;;
- : string = "wor"

Fernando

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Richard Jones]

On Thu, Apr 08, 2004 at 04:56:06PM +0200, Markus Mottl wrote:
> Yes, it's hard to do this with the current standard library.  The question
> is: who needs these functions anyway?  I can't remember ever having felt
> a need for them.

My "private library" defines:

val first : int -> 'a list -> 'a list

which returns the first n members of a list.  As for slicing the
middle from a list, I tend to think that the original poster should
probably be using a different, more suitable structure.  Perhaps an
Array if he wants random access.

> > Yes, I could write functions to do all of this, but my point is that
> > I shouldn't have to.
> 
> The point of the standard library is not to have a function for every
> imaginable problem but to have ones that cover standard problems.

Well, having a broad library helps to implement things.  For example,
LWP-like functionality [in perl4caml] makes writing scripts which
analyse websites an awful lot simpler.  Having functions which allow
me to convert from Y/M/D to ISO-standard years and weeks [which I have
written] makes writing business analysis functions more tractable.
Perl and Python have all this stuff, which makes it much easier to
implement these sorts of boring businessy programs.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Perl4Caml lets you use any Perl library in your type-safe Objective
CAML programs. http://www.merjis.com/developers/perl4caml/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Jean-Marc EBER]

> ...  (While we're
> at it, I think it's silly that there is a list and an array type). ...

nice joke. :-)

Jean-Marc, working with lists *and* arrays all the day !


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Kenneth Knowles]

> I've been toying with the
> idea of writing a generic build system for OCaml to address this point
> though.

If you haven't already, take a look at the OCamlMakefile here:
http://www.ai.univie.ac.at/~markus/home/ocaml_sources.html

and ocamlconf (by yours truly) here:
http://kenn.frap.net/ocamlconf/

One of them may your needs, but if not I'm sure the authors would appreciate a
description of their insufficiencies.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Markus Mottl]

On Thu, 08 Apr 2004, Richard Jones wrote:
> My "private library" defines:
> 
> val first : int -> 'a list -> 'a list
> 
> which returns the first n members of a list.  As for slicing the
> middle from a list, I tend to think that the original poster should
> probably be using a different, more suitable structure.  Perhaps an
> Array if he wants random access.

That's also my opinion: it's usually an indication of a bad choice
concerning datastructure if you need such list functions.

> Well, having a broad library helps to implement things.  For example,
> LWP-like functionality [in perl4caml] makes writing scripts which
> analyse websites an awful lot simpler.  Having functions which allow
> me to convert from Y/M/D to ISO-standard years and weeks [which I have
> written] makes writing business analysis functions more tractable.
> Perl and Python have all this stuff, which makes it much easier to
> implement these sorts of boring businessy programs.

I absolutely agree with you!  But the point is: is this really so
important to have it in the _standard_ library?  You didn't mention the
word "standard" so I suppose you'd be perfectly happy if somebody wrote a
fully-featured library for this kind of functionality?  And you'd rather
like to see better "social tools" for making use of such contributions?

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 04:56:06PM +0200, Markus Mottl wrote:
> On Thu, 08 Apr 2004, John Goerzen wrote:
> > Also, there is no string_of_char function (I'd have to use fill).
> 
> That's not quite true: there is "String.make", which does what you want.

Yep, I missed that.

> > Similar complaints exist for working with subsets of lists; it's really
> > too hard to say "replace elements 4 through 9 with this", "delete
> > elements 4 through 9", "return elements 4 through 9", etc.
> 
> Yes, it's hard to do this with the current standard library.  The question
> is: who needs these functions anyway?  I can't remember ever having felt
> a need for them.

I need them all the time.  Just because you may not doesn't mean that
they are never needed.  For instance, I may get back a list of results
from a function that parses a network stream or a report, and I know
that I can always discard the first two and last three.  This is a
fairly common occurance here.

> > (While we're at it, I think it's silly that there is a list and an
> > array type).
> 
> I beg your pardon - what else do you have in mind???

One type that can do both.

> > Yes, I could write functions to do all of this, but my point is that
> > I shouldn't have to.
> 
> The point of the standard library is not to have a function for every
> imaginable problem but to have ones that cover standard problems.

Of course.  Do you think that obtaining slices of a list or printing the
current time in a human-readable format are not standard problems?  If
so, I would have to point out to you that there is a quite lengthy
history that supports my position on this.

> > This library problem hurts productivity, and in some cases makes OCaml
> > less productive than even C.
> 
> Things are not half as bad as you describe them here.  There may be
> cases where C is more productive - because you happen to have a library
> function for the problem.  But even in this case you can just interface
> to C, which is really not that difficult.

And I should not *have* to interface to C just to print out a date &
time or parse the time.  See, your attitude is part of the problem --
your position is that "it's not hard to reinvent the wheel."  My
position is that all the easy reinvention that has to happen adds up to
something that is hard, and goes against principles of code sharing,
since every OCaml programmer is going to reinvent things slightly
differently.

> There are surely cases where the OCaml standard library lacks generally
> useful functionality, but it's usually good enough for most problems.

Yes, "good enough", I'll buy that.  Barely.  But it's still *far* behind
other languages.  And you haven't even addressed my complaints about
IPv6 and other glaring socket omissions, read/write files handles,
string slicing, and IMAP libraries.  Should I add a few more?  Here are
some other functions that I have in C, Python, Perl (and, for the most
part, even Java) that are missing from OCaml:

realpath()
asctime()
strftime()
strptime()
basename()
dirname()
localtime()
gmtime()
ulimit()
getaddrinfo()
The following flags for recv/recvfrom: 
  MSG_WAITALL
  MSG_TRUNC
  MSG_ERRQUEUE
The following formats for socket():
  PF_INET6, PF_PACKET, PF_APPLETALK 
recvmsg()
mknod()
mountpoint()
ioctl()

These ommissions mean that I cannot write the following types of
programs in OCaml that I could in Python or Perl (and mostly, Java):

 * Any client or server that uses IPv6
 * Any file archiver or extractor
   + I cannot write a tar extractor in OCaml because no mknod() exists
   + I cannot write a general-purpose tar archiver in OCaml because
     mountpoint() does not exist (and I'd need that to implement -l)
 * Any kind of process (ie, server) that wishes to assert ulimit limits
   over its children (web servers restricting CGIs would be one example)
 * Any kind of program that reads or writes times obtained from
   the system in human-readable format
 * Things that need to obtain path information from relative paths
   in a secure manner that has no side-effects
 * A network tracer (tcpdump)
 * Audio programs (ioctl)
 * Tape backup utilities (ioctl)

These are all things that are in libc.  Most are specified in POSIX as
well and have been implemented widely for about 15 years.

If you limit the universe of "most problems" to be numerical analysis,
you may well be quite accurate.  However, such a limitation is going to
be misleading if you are talking about more general problems.  I have
zero need for numerical analysis tools here, and in the grand scheme of
things, needs for them make up a small minority of needs.

These are also real needs.  I regularly need to deal with times and
humans.  I also have done some work with archivers and the like, and the
problems highlighted here are real.  I have several machines that are
only reachable by IPv6, and this is a huge problem for me wrt OCaml.
OCaml apps are the only ones I have trouble with in this regard.

I do *not* need to do these things in a "system-level" language such as
C.  Perl and Python are both quite well suited to the ask, and OCaml
would be too if its standard library were more complete.  There is
nothing in the fundamental design of OCaml that prevents this.  In some
cases, it's just a matter of missing some constants from the system's .h
files.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Jon Harrop]

On Thursday 08 April 2004 3:56 pm, Markus Mottl wrote:
> On Thu, 08 Apr 2004, John Goerzen wrote:
> > Similar complaints exist for working with subsets of lists; it's really
> > too hard to say "replace elements 4 through 9 with this", "delete
> > elements 4 through 9", "return elements 4 through 9", etc.
>
> Yes, it's hard to do this with the current standard library.  The question
> is: who needs these functions anyway?  I can't remember ever having felt
> a need for them.

I could do with them! There are numerous such functions (and nice 
implementations, like "List.nth -1 l" fetching the last element, more 
powerful flatten etc.) which Mathematica has and which I miss.

> > (While we're at it, I think it's silly that there is a list and an
> > array type).
>
> I beg your pardon - what else do you have in mind???

Yes, what the hell are you talking about? ;-)

> > This library problem hurts productivity, and in some cases makes OCaml
> > less productive than even C.
>
> Things are not half as bad as you describe them here.  There may be
> cases where C is more productive - because you happen to have a library
> function for the problem.  But even in this case you can just interface
> to C, which is really not that difficult.

I wouldn't describe using multiple languages, multiple compilers, adding new 
source files, object files and writing code to transform ocaml's internal 
representations into those necessary for the language and back again as 
"really not that difficult". Quite the contrary, in fact, I have found it to 
be "quite difficult". I certainly wouldn't expect Jo User, whilst evaluating 
ocaml as yet another new language, to have to implement safe interfaces to 
common functions found in a language he/she already knows just to get a 
working program.

> There are surely cases where the OCaml standard library lacks generally
> useful functionality, but it's usually good enough for most problems.

Yes, it is currently sufficeable.

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 08:23:01AM -0700, Kenneth Knowles wrote:
> 
> > I've been toying with the
> > idea of writing a generic build system for OCaml to address this point
> > though.
> 
> If you haven't already, take a look at the OCamlMakefile here:
> http://www.ai.univie.ac.at/~markus/home/ocaml_sources.html

I had already looked at, and discared, OCamlMakefile because of several
problems -- mainly the inability to manage more complex projects that
may generate several executables that share some modules, and the
ability to determine, at build time, whether to build native binaries
and libraries.

> and ocamlconf (by yours truly) here:
> http://kenn.frap.net/ocamlconf/

That one I had not yet seen, and in fact, looks like it's along the
lines of what I was considering.  Thanks; I will look into it.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Jon Harrop]

On Thursday 08 April 2004 4:26 pm, Markus Mottl wrote:
> That's also my opinion: it's usually an indication of a bad choice
> concerning datastructure if you need such list functions.

If you mean a bad choice from the point of view of efficiency then yes, it is, 
but I know that the resulting inefficient code will only account for a 
fraction of a percent of the total run-time and, therefore, I don't care. I 
just want to have to write as little code as possible to get the job done.

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 05:26:54PM +0200, Markus Mottl wrote:
> On Thu, 08 Apr 2004, Richard Jones wrote:
> > which returns the first n members of a list.  As for slicing the
> > middle from a list, I tend to think that the original poster should
> > probably be using a different, more suitable structure.  Perhaps an
> > Array if he wants random access.
> 
> That's also my opinion: it's usually an indication of a bad choice
> concerning datastructure if you need such list functions.

One does not always have the choice of data structure.  Sometimes, and
this happens to be the case in several programs I've worked on recently,
the inadequecies arise when I'm trying to get data frmo an older system
into an OCaml-based one that does use more suitable structures.

For instance, consider this problem, which is a simplified version of a
real problem...  I am reading a line-oriented file delimited by "|".
It's easy enough to split this apart into a list (even though I must go
to Str and regexps to do it, grr).  

Now, I know that I must ignore the first two and last three elements in
that list.  I do not know in advance what size the list will be, and it
varies from line to line, but it always has at least five elements.  I
also do not necessarily know the values for "2" and "3" at compile time,
though they are constant throughout execution of the program.  The order
of the elements is significant and must not be altered.  Each element is
the same type (ie, a String).  There is nothing in the data itself that
differentiates it.

Now, which OCaml data structure gives me the ability to easily pull out
such a slice?  As far as I can tell, there are no standard functions for
any of Array or List to do that.  I could write a function for either of
them to loop over it and get me what I want, but the point is that this
functionality is useful.

Now, there are arguably other ways to do this; I could use a complex
regular expression to pull out the data in the center... ie:

  ([^|]*\|){2}(.*)(\|[^|]*){3}

may do the trick in this particular example, but not always.  (What if,
instead of lines, I am dealing with packets coming in off the network?)

One does not always get data handed to onesself on a platter, already
nicely ordered and suitable for storing in a nice structure (in any
language).  Hell, half the time my first step is to -- yes -- convert to
ASCII.  (I sometimes have to work with data coming from an AS/400, an
EBCDIC system that is thankfully being phased out)

> I absolutely agree with you!  But the point is: is this really so
> important to have it in the _standard_ library?  You didn't mention the
> word "standard" so I suppose you'd be perfectly happy if somebody wrote a
> fully-featured library for this kind of functionality?  And you'd rather
> like to see better "social tools" for making use of such contributions?

I don't really care if it comes in ocaml.tar.gz or not, for some of
these things.  Some of them absolutely should, especially more powerful
string/array/list slicing, IPv6, and POSIX interfaces.  But many of the
rest don't exist at all or require contortions to use.  (For instance,
there are two libraries out there named Extlib, both of which implement
some of what I want with little overlap between them.  How annoying.)

I see these as critical ommissions from the actual standard library:

 * IPv6 and other socket-related and DNS-related problems
 * Lack of support for read/write handles in Pervasives (relegated to
   Unix and with complex interactions between the two)
 * String/array/list indexing/slicing improvements
 * Standard C/POSIX date/time functions
 * Path manipulation functions (about 75% of these are already there;
   I have no idea why the other 25% aren't)
 * mknod() and similar functions  (we have mkfifo(), after all...)

These are all enhancements of functionality already present in the
standard library.  Why would I be able to use the standard library for
IPv4 but have to go elsewhere for IPv6?  That doesn't really make sense.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Xavier Leroy]

> Should I add a few more?  Here are
> some other functions that I have in C, Python, Perl (and, for the most
> part, even Java) that are missing from OCaml:

I'm afraid you haven't checked the OCaml docs before posting, because
some of these are already there.  More specifically:

> realpath()
> asctime()
> strftime()
> strptime()
> basename()
                is Filename.basename
> dirname()
                is Filename.dirname
> localtime()
                is Unix.localtime
> gmtime()
                is Unix.gmtime
> ulimit()
> getaddrinfo()
                is in the works, as part of IPv6 support
> The following flags for recv/recvfrom: 
>   MSG_WAITALL
>   MSG_TRUNC
>   MSG_ERRQUEUE
                the latter two aren't standard (not in SuSv2)
> The following formats for socket():
>   PF_INET6
                in the works as part of IPv6 support
> , PF_PACKET, PF_APPLETALK 
                not standard (not in SuSv2)
> recvmsg()
> mknod()
> mountpoint()
> ioctl()

Also note that ioctl cannot be supported in its full generality
because this function is not typeable.  Only special cases (with a
fixed second argument) can be expressed in OCaml.

Generally speaking, you have some valid points, but these get lost in
a lot of rather inflammatory comments.  I'd be more inclined to listen
to you if this wasn't the case.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Markus Mottl]

On Thu, 08 Apr 2004, John Goerzen wrote:
> > > (While we're at it, I think it's silly that there is a list and an
> > > array type).
> > 
> > I beg your pardon - what else do you have in mind???
> 
> One type that can do both.

That's a very bad idea, IMHO.  The efficiency tradeoffs are so large
for certain operations that I'd never put anything like this into a
standard library.

Arrays, for example, are something that should definitely be part of
a standard library, because the compiler can perform some extremely
valuable optimizations for them (e.g. unboxing).

> Of course.  Do you think that obtaining slices of a list or printing the
> current time in a human-readable format are not standard problems?  If
> so, I would have to point out to you that there is a quite lengthy
> history that supports my position on this.

I feel that this question really also touches the recent discussion
concerning library management.  If it were very easy to make use of
contributed code, we wouldn't talk so often about extensions to the
standard library.

> And I should not *have* to interface to C just to print out a date &
> time or parse the time.  See, your attitude is part of the problem --
> your position is that "it's not hard to reinvent the wheel."

No, my point is that it's easy enough to write such a library.  You don't
have to make it standard.

> My position is that all the easy reinvention that has to happen adds
> up to something that is hard, and goes against principles of code
> sharing, since every OCaml programmer is going to reinvent things
> slightly differently.

I agree here: that's why I'd like to see more social tools rather than
extensions to the standard library.  It's tiresome to search the web
for already invented wheels, downloading code, compiling it (hopefully
without problems), installing it and keeping it up-to-date (including
libraries that it depends on).

> And you haven't even addressed my complaints about
> IPv6 and other glaring socket omissions, read/write files handles,
> string slicing, and IMAP libraries.  Should I add a few more?  Here are
> some other functions that I have in C, Python, Perl (and, for the most
> part, even Java) that are missing from OCaml:

I am not questioning the fact that OCaml could need more libraries for
more functionality.  I am questioning that all of this should become
part of a standard library.  I wouldn't mind seeing the code there, of
course, but why burden the developers with tasks that could be done by
the community?  What is "standard" anyway?  Only what INRIA calls one?
Or what is used predominantly by the community?

> If you limit the universe of "most problems" to be numerical analysis,
> you may well be quite accurate.

This has nothing to do with academic vs. commercial applications.
Numerical analysis isn't even my main topic of interest.  It's all a
question of how contributions should be made to OCaml.  Putting an ever
increasing number of functions into the standard library is probably
not the solution.

> However, such a limitation is going to be misleading if you are talking
> about more general problems.  I have zero need for numerical analysis
> tools here, and in the grand scheme of things, needs for them make up
> a small minority of needs.

I wouldn't want to see numerical analysis in the standard library
either so this is a strawman argument.  Ideally, the standard library
would contain only functionality that is critical for making the
compiler/runtime work.  Everything else could be fetched from some
central repository.

> These are also real needs.  I regularly need to deal with times and
> humans.  I also have done some work with archivers and the like, and the
> problems highlighted here are real.  I have several machines that are
> only reachable by IPv6, and this is a huge problem for me wrt OCaml.
> OCaml apps are the only ones I have trouble with in this regard.

Again: I believe you that you need this functionality.  I just don't
think that all of this should be part of a standard library.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Bruno.Verlyck]

   Date: Thu, 8 Apr 2004 10:30:56 -0500
   From: John Goerzen <jgoerzen@complete.org>

I hate posting to such long threads, but if you care:

   glaring socket omissions, read/write files handles, string slicing,
- sockets (esp. IPV6): I've no full solution.
- read-write file handles: You can get them wit Unix.openfile and
  Unix.dup.  Then with Unix.{in,out}_channel_of_descr, you can use
  the Pervasives I/O functions.
- string handling: look at my (rather full-featured) Cstr library
  (http://pauillac.inria.fr/cash/cstr/); it doesn't answer syntax
  questions, but those are a different matter.  It doesn't implement
  negative indices, but if you dare looking at the sources, *maybe*
  only the check- macros have to be modified.

As for lists, I saw a message from someone trying to implement SRFI 1,
but no further announce.  I feel that it really calls for mutable
lists, with are less in OCaml's spirit, and you'll miss syntactic
sugar.

   Here are some other functions that I have in C, Python, Perl that
   are missing from OCaml:
    realpath()
    asctime()
    strftime()
    strptime()
    basename()
    dirname()
    localtime()
    gmtime()
    ulimit()
    getaddrinfo()
    The following flags for recv/recvfrom:
      MSG_WAITALL
      MSG_TRUNC
      MSG_ERRQUEUE
    The following formats for socket():
      PF_INET6, PF_PACKET, PF_APPLETALK
    recvmsg()
    mknod()
    mountpoint()
    ioctl()
Some of them are in Unix, some in Filename, some others (under other
names) in Cash (http://pauillac.inria.fr/cash/), with another view to
file descriptors / Caml channels.

For mknod, as an emergency measure, I'd fork the mknod command.

As for flags that aren't in Unix (or ulimit), you touch a strong
problem for library implementors: they are defined only for some OSes,
and are a pain to implement and test when you have no personal use for
them.  Yes, laziness.  On the other hand, you ask for free lunch.

(Another pain is making any general library, moreover part-time; even
Cstr, which is not big, nor very complicated, that I didn't design,
took me five times what I thought; OK, I played some games with
camlp4, but documenting and testing it is a lot of boring work).

HTH,
Bruno.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Issac Trotts]

On Thu, Apr 08, 2004 at 09:10:38AM +0200, Basile Starynkevitch wrote:
> On Thu, Jan 03, 2002 at 04:43:56PM -0800, Issac Trotts wrote:
> > On Wed, Apr 07, 2004 at 11:05:24PM +0200, Basile Starynkevitch wrote:
> 
> > > However, for the beginner, the good answer (at least as given by Ocaml
> > > gurus here) to the usual "I want eval" request is simply "no you don't
> > > really need it"
> > 
> > That being so, how would you use OCaml as an extension language for a C
> > program?  
> 
> I'm not sure to understand your point. Many applications coded in C
> embed Ocaml inside. The simplest way is to give the application a
> compiled ocaml bytecode file (which can be choosen at runtime) invoked
> thru ocaml_main
> 
> See section 18.7.4 Main program in C of
> http://caml.inria.fr/ocaml/htmlman/manual032.html

OK, please see below.

> An alternative is to have the application being a custum ocaml
> program, with lots of C primitives. This means that the ocaml runtime
> system has the control and invoke appropriately the C primitives
> provided by the application.

This won't do what I have in mind.  I would like to run arbitrary OCaml
code strings, given by the user, from within a C program.

> If you ask about embedding the ocaml toplevel into your application,
> it is a different question. I agree that extending or embedding or
> customizing the toplevel is not very well documented.

Below is the listing of what I tried.  It gave this error:

Initializing Caml code...
Fatal error: exception Sys_error(": No such file or directory")

As far as I can tell, the error is coming from Env.read_pers_struct
in ocaml-3.07/typing/.  

=== Makefile ===
CFLAGS=-I $(OCAML)
objects:=cmcaml.o cmstub.o cmmain.o
cced: $(objects)
	gcc -o $@ $(objects) -L $(OCAML) -lcamlrun -lm -ldl -ltermcap
cmcaml.o: cmcaml.ml
	ocamlc -g -output-obj -o cmcaml.o toplevellib.cma cmcaml.ml 
clean:
	rm -f *.o *.cmo *.cmi cced

=== cmcaml.ml ===
(* Caml part of the code *)

Toploop.initialize_toplevel_env();;
                                                                                
let eval txt = 
    let lb = (Lexing.from_string txt) in
    let phr = !Toploop.parse_toplevel_phrase lb in
    Toploop.execute_phrase true Format.std_formatter phr;;

(* Registration *)
let _ = Callback.register "eval" eval;;
 
=== cmmain.c ===
/* Based on cmmain.c in ocaml-3.07/test/Moretest */

#include <stdio.h>
#include <stdlib.h>
#include <caml/callback.h>

extern void eval(char const * code);

int main(int argc, char ** argv)
{
    printf("Initializing Caml code...\n");
    caml_startup(argv);
    printf("Back in C code...\n");
    while(1) {
        char buf[80*40];
        fprintf(stderr,"> ");
        if(fgets(buf,sizeof(buf)-1,stdin)==NULL) {
            break; 
        }
        eval(buf);
    }
    return 0;
}

=== cmstub.c ===
#include <string.h>
#include <caml/mlvalues.h>
#include <caml/callback.h>

/* Oops, this should be called exec. */
void eval(char const * str)
{
  value * closure = caml_named_value("eval");
  (void) callback(*closure, copy_string(str)); /* leaky? */
}

--
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Brian Hurt]

On Thu, 8 Apr 2004, John Goerzen wrote:

> On Thu, Apr 08, 2004 at 01:24:45AM -0500, Brian Hurt wrote:
> > majority of that in the eval function- so you're talking north of a
> > megabyte of code.  As an application, that's small.  As a library, that's
> > huge.  It's of the same size as linking in libgtk (1.3M).  No, you want a 
> > small, simple language.  Although this might not be so bad- libperl.so on 
> > my machine weighs in at 3.2M.
> 
> Indeed, and in fact:
> 
> -rw-r--r--    1 root     root      1073392 Feb 24 02:34 /usr/lib/libpython2.3.so.1.0
> 
> Python is often used as an embedded extension language as well.

I think I've talked myself into that Ocaml, at least the VM part, should 
be embeddable.

> 
> > As a side note, I don't see Ocaml as a science project.  It's a pragmatic
> > language, in that it doesn't automatically assume it knows what's best,
> > but instead provides the programmer the tools he needs to get the job
> > done.  As reflected in it's design decisions, the people designing Ocaml
> 
> Careful; that sounds like you're describing Perl :-)

I've heard that used to describe Perl, C++, and Java, in different ways.  
As such, I'm using it as a benchmark for what a "usable" language is.

> > Wandering into the arena of suspect analogy, if C and C++ are the blue
> > collar assembly line workers, tightening bolts by hand, than Ocaml is the
> > robot repairman maintaining the whole factory of robots.  He's every bit
> > as blue collar and about getting real work done, but more educated and a
> > heck of lot more productive.
> 
> I agree with most of your analogy here.  I'm still relatively new to
> OCaml, having been using it for only a couple of months, but you've
> touched on one of my pet peeves: the OCaml standard library is really
> sub-par for doing real work.  

Heh.  It's orders of magnitude better than the C or C++ standard
libraries.  Which explains why those languages never went anywhere :-).  
Note that POSIX is an add-on layer, not gaurenteed to be there.  So all
socket communication is optional and non-standard.  As is all database
connectivity, GUI handling, etc.  The thing is, almost no one actually
programs the "standard" C/C++ environment.  Every C/C++ environment comes 
with a whole collection of add-on libraries- POSIX at a minimum.  
Generally a whole lot more.

I think the problem here isn't technical, it's social- marketing, to be 
specific.  Having a language with a very minimialistic standard library 
isn't the problem- the problem is have a standard development environment 
with a minimialistic library.  The "core" language and libraries 
distribution should be, if not hidden, then at least not obvious.  
Instead, the "default" Ocaml distribution should be something more like 
CDK (is that project still alive?).  There shouldn't be links from the 
home page to the core, the home page should link to CDK *only*.  And we 
need to get the Linux distros up to speed and distributing CDK instead of 
only Ocaml-core.

While we're kvetching, here's my list of desires to be in the default 
development environment (note that I don't think any of these belong in 
the standard libraries):
	- OUnit
	- ExtLib (OK, this should perhaps become part of the standard)
	- BLAS/LAPACK, GMP, and MPI bindings
	- Regular expressions
	- ocamlexc
	- Camllisp (or similiar)
	- compression, encryption, etc. filters for I/O

Certain things can be moved out of the standard distribution and moved 
into the development environment in this case- pcaml, ocamldoc, ocamlex, 
ocamlyacc, etc.

Of course, the other advantage that the standard distribution has, in 
addition to being the default, is coherent documentation.  There is one 
book, and everything in the standard distribution is more or less equally 
well documented (ocamllex and ocamlyacc could use some help).  The same 
thing should be true for the development environment.


> Similar complaints exist for working with subsets of lists; it's really
> too hard to say "replace elements 4 through 9 with this", "delete
> elements 4 through 9", "return elements 4 through 9", etc.  (While we're
> at it, I think it's silly that there is a list and an array type).  Yes,
> I could write functions to do all of this, but my point is that I
> shouldn't have to.

They aren't hard to write, the problem is that they're O(N).  To replace 
element 9 in a list, you also end up replacing elements 0-8 as well.  I 
would argue that if you're wanting to do this routinely and efficiently, 
you shouldn't be using lists.  I'd recommend Map or Set myself.

> One other thing to mention is that installing libraries is much more
> difficult than it should be, and writing library build systems (and even
> app build systems) is much more complex than it should be.  Part of this
> is due to a lack of a standardized build system (think Perl's MakeMaker
> or Python's setup.py).  Part of it is due to the complex array of OCaml
> options -- for instance, some platforms do not support ocamlopt, so
> while a library might normally build both native and byte-code versions,
> it has to not try to if ocamlopt is missing.  (Something which, I have
> found, many OCaml authors fail to consider.)  I've been toying with the
> idea of writing a generic build system for OCaml to address this point
> though.

There have been several swings taken at this already- the relevent 
developers should be letting you know about them.

If you're regularly having to install more than one or two libraries for 
your development environment, that's a problem.  I mean, think about it.  
You install Linux, how many libraries do you generally need to add to do 
C/C++ programming?  Or Visual Studio?  You don't realize how much of the 
stuff is "optional" because it's all installed automatically.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Issac Trotts]

On Thu, Apr 08, 2004 at 01:24:45AM -0500, Brian Hurt wrote:
> On Thu, 3 Jan 2002, Issac Trotts wrote:
> 
> > That being so, how would you use OCaml as an extension language for a C
> > program?  
> > 
> 
> I would use C as an extension language for Ocaml.
> 
> This isn't meant to be a snarky answer.  Ocaml is an applications
> language- you should write the bulk of the code in Ocaml, and drop to C in
> places where you need to.  If you're looking for a language to embed, you
> might try looking at one designed to be embeeded, like Lua.  Or a Lisp
> variant.  But that isn't what Ocaml is designed for.

It may still be good for it even if it wasn't designed for it.  At any
rate, it bothers me to write code in languages lacking OCaml's type
safety.  Maybe the solution is to graft Hindley-Milner type inference
onto Scheme or Python.  Some people at CMU did something like this with
R4RS Scheme, but I don't know if they released the code.  

> Nor would it be a good language for that.  Consider the complexity of the
> Ocaml 'eval' function.  On my system (Redhat 9, x86, Ocaml 3.07) Ocamlc is
> 920K in size, and ocamlrun another 144K.  You'd have to replicate the
> majority of that in the eval function- so you're talking north of a
> megabyte of code.  As an application, that's small.  As a library, that's
> huge.  It's of the same size as linking in libgtk (1.3M).  No, you want a 
> small, simple language.  Although this might not be so bad- libperl.so on 
> my machine weighs in at 3.2M.

If I didn't know about OCaml I would say you are right, but OCaml is
robust and easy to modify (hence its complexity is not such a problem
for me), and easy on system resources (hence its code size is not such a
problem for me either).  So I would be very happy if I could use
OCaml to do experimental, bottom-up programming within a graphical
environment constructed in C.  

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Walid Taha]

Hi John,

You might want to take a look at MetaOCaml.  Instead of strings it uses
"Brackets" (written .<...>.) and uses ".!" for "eval".  Here's a simple
interactive session:

# let a = .< 1 + 2 >.;;
val a : int code = .<(1 + 2)>.
# let b = .< .~a + .~ a >.;;
val b : int code = .<((1 + 2) + (1 + 2))>.
# let c = .! a;;
val c : int = 3
# let d = .! b;;
val d : int = 6

Notice that the also type checks what goes inside the brackets (it doesn't
just say "code", it says "int code").

Walid.

On Wed, 7 Apr 2004, John Goerzen wrote:

|Hello,
|
|I am moving from Python to OCaml and one of the things I miss is
|Python's eval() call.  It takes a string representing a bit of Python
|source code, evaluates it, and returns the result.  I would like to be
|able to do similar things with OCaml.
|
|I have observed that /usr/bin/ocaml, the interactive top-level, is
|itself written in OCaml, which suggests that this should be possible.
|Although I have tried to study the source for this, it seems extremely
|complex and I can't figure out a way to do the simple evaluation
|described above.
|
|Can anyone help me out here?
|
|Thanks,
|John
|
|
|-------------------
|To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
|Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
|Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
|

-- 


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 06:44:04PM +0200, Markus Mottl wrote:

[ snip ]

> I feel that this question really also touches the recent discussion
> concerning library management.  If it were very easy to make use of
> contributed code, we wouldn't talk so often about extensions to the
> standard library.

[ snip ]

> I agree here: that's why I'd like to see more social tools rather than
> extensions to the standard library.  It's tiresome to search the web
> for already invented wheels, downloading code, compiling it (hopefully
> without problems), installing it and keeping it up-to-date (including
> libraries that it depends on).

Yes.  That would make sense for a lot of things.  The Humps are already
fairly usable for finding things, but installing them can be a different
matter.

I have to think twice before using things not in the standard library
for code that others will run because I must consider the complexity of
setting them up.  Some libraries don't compile out of the box on systems
that lack ocamlopt; others require various amounts of Makefile hacking
to see correct paths, etc.

Perl has a fairly small standard library but a very easy method to add
on to it (CPAN).  That works well.

Python has a fairly large standard library and an almost-as-easy method
to add on (setup.py; you have to download but install is easy).  That
works well, too.


> > IPv6 and other glaring socket omissions, read/write files handles,
> > string slicing, and IMAP libraries.  Should I add a few more?  Here are
> > some other functions that I have in C, Python, Perl (and, for the most
> > part, even Java) that are missing from OCaml:
> 
> I am not questioning the fact that OCaml could need more libraries for
> more functionality.  I am questioning that all of this should become
> part of a standard library.  I wouldn't mind seeing the code there, of
> course, but why burden the developers with tasks that could be done by
> the community?  What is "standard" anyway?  Only what INRIA calls one?
> Or what is used predominantly by the community?

I'd have no problem with having a more broad standard definition than
INRIA.  The reason I've been talking about the standard library thus far
is that basic support for some of the things I'm looking for already
exists there, so it would seem silly to reinvent it all somewhere else
-- not to mention the complexity that would cause with two competing
interfaces for the same task.  As an example, there's IPv6 support.  The
standard library already has IPv4 support, and given that, the amount of
effort required to add IPv6 is relatively small, and most of the
existing interfaces could be reused.  So to me, the standard library is
the only place it makes sense to put IPv6 (unless, for instance, INRIA
and the community decided to totally split off networking to a separate
module).

What it comes down to is that we need to have clearly-defined guidelines
for what goes into INRIA's standard library and what doesn't, and they
have to be sensible.  Something like "IPv4 yes, IPv6 no" or some date
functions but not others is not a good long-term solution.

Otherwise, we'll have some people using the INRIA functions (they may
not need the functionality that's lacking) and others using whatever
add-on library exists.  And it can be tough to integrate the two types
of code into a single system.

[ snip ]

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 06:44:15PM +0200, Bruno.Verlyck@inria.fr wrote:
> - read-write file handles: You can get them wit Unix.openfile and
>   Unix.dup.  Then with Unix.{in,out}_channel_of_descr, you can use
>   the Pervasives I/O functions.

I have discovered that, but it seems that I don't fully understand the
buffering semantics over on the Pervasives side.  For instance, it's not
entirely clear what happens if I write something to an out channel, then
seek somewhere via that channel, then read via the other channel.  The
results have not always been what I expected.  I've also tried to use
that trick to work with sockets, and the results there are *definately*
not what I expected.  But I didn't look into it in any great detail, so
I may have been missing something obvious.  (Pervasives appears to
sometimes make an underlying call to read or write a different number of
bytes than I requested -- which can be a problem for network protocols
where this can cause deadlock)

> - string handling: look at my (rather full-featured) Cstr library
>   (http://pauillac.inria.fr/cash/cstr/); it doesn't answer syntax
>   questions, but those are a different matter.  It doesn't implement
>   negative indices, but if you dare looking at the sources, *maybe*
>   only the check- macros have to be modified.

That looks great.  Has a lot of stuff I'd use.  It looks like it's
separate from cash; is that correct?  (If so, I'll package it up for
Debian right away <g>)

> As for flags that aren't in Unix (or ulimit), you touch a strong
> problem for library implementors: they are defined only for some OSes,
> and are a pain to implement and test when you have no personal use for
> them.  Yes, laziness.  On the other hand, you ask for free lunch.

I know what you mean.  It's going to mean a lot of autoconf tests :-)

And yeah, I know about volunteer time...  I try to do what I can to help
out (such as packaging things for Debian).  I don't have the requisite
experience yet to touch anything that deals with C or camlp4.  In time,
perhaps. :-)  I am, however, working on an IMAP library, time
permitting.  I have everything necessary to make that go and the basic
parser is complete already (I've gotta say -- OCaml streams are the
nicest thing since sliced bread for parsing complex grammars <g>)

> (Another pain is making any general library, moreover part-time; even
> Cstr, which is not big, nor very complicated, that I didn't design,
> took me five times what I thought; OK, I played some games with
> camlp4, but documenting and testing it is a lot of boring work).

That's true.  I have found OUnit to be very nice for testing, BTW.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Jean-Marc EBER]

John Goerzen wrote:

> 
> Now, I know that I must ignore the first two and last three elements in
> that list.  I do not know in advance what size the list will be, and it
> varies from line to line, but it always has at least five elements.  I
> also do not necessarily know the values for "2" and "3" at compile time,
> though they are constant throughout execution of the program.  The order
> of the elements is significant and must not be altered.  Each element is
> the same type (ie, a String).  There is nothing in the data itself that
> differentiates it.
> 
> Now, which OCaml data structure gives me the ability to easily pull out
> such a slice?  As far as I can tell, there are no standard functions for
> any of Array or List to do that.  I could write a function for either of
> them to loop over it and get me what I want, but the point is that this
> functionality is useful.
> 

In the time you wrote the previous paragraph, its also possible to write 
following (of course horribly inefficient, because it inverts two times the 
argument list) prototype implementation of the function you need, so that you 
can continue to work on your problem. When you hit efficiency problems, you will 
probably later on replace it with a better one...

let remove_2_3 = function
   | _ :: _ :: rest ->
       (match List.rev rest with
       | _ :: _ :: _ :: rest -> List.rev rest
       | _ -> failwith "error2")
   | _ -> failwith "error1";;

remove_2_3 [1; 2; 3; 4; 5; 6; 7];;

cd c:/cygwin/home/jmeber/mlfi/
ocaml eber.ml
[3; 4]

Compilation finished at Thu Apr 08 19:45:26

I don't need to mention that your previous particular problem is so trivial that 
it could easily be expressed with arrays as a "one liner" of caml code... Look 
at Array.sub...

Jean-Marc


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Kenneth Knowles]

On Thu, Apr 08, 2004 at 07:59:04PM +0200, Jean-Marc EBER wrote:
> I don't need to mention that your previous particular problem is so trivial 
> that it could easily be expressed with arrays as a "one liner" of caml 
> code... Look at Array.sub...

This is also a general principle - O'Caml is concise enough that a lot of helper
functions you would expect in imperative scripting languages or C are too simple
to include, for the sake of cleanliness.  I certainly don't think the standard
library is perfectly designed, but tiny list handling functions should be kept
to a minimum (I even think the current List might have too many).  

By the way, list slicing has the same complexity as Array.of_list and then
Array.sub so it is, in fact, in the standard library.  Don't even bother talking
about efficiency at a lower level than complexity of algorithms until you have a
complete, profiled program - and of course you are talking about disk access so
there's not a chance of the slicing being a bottleneck.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Nicolas Cannasse]

> > I've been toying with the
> > idea of writing a generic build system for OCaml to address this point
> > though.
>
> If you haven't already, take a look at the OCamlMakefile here:
> http://www.ai.univie.ac.at/~markus/home/ocaml_sources.html
>
> and ocamlconf (by yours truly) here:
> http://kenn.frap.net/ocamlconf/
>
> One of them may your needs, but if not I'm sure the authors would
appreciate a
> description of their insufficiencies.

Don't forget about OCamake, which does not need any other tool than itself
(and ocaml compilers), and is working very well on both Windows and Unix'es
:

http://tech.motion-twin.com/ocamake

Regards
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 07:59:04PM +0200, Jean-Marc EBER wrote:
> >such a slice?  As far as I can tell, there are no standard functions for
> >any of Array or List to do that.  I could write a function for either of
> >them to loop over it and get me what I want, but the point is that this
> >functionality is useful.
> >
> 
> In the time you wrote the previous paragraph, its also possible to write 
> following (of course horribly inefficient, because it inverts two times the 
> argument list) prototype implementation of the function you need, so that 

Not quite; the numbers 2 and 3 are not known in advance, but yes, I did
write a function to accomplish that anyway :-)

> I don't need to mention that your previous particular problem is so trivial 
> that it could easily be expressed with arrays as a "one liner" of caml 
> code... Look at Array.sub...

Is switching a whole thing back and forth between lists and arrays
really efficient?  Like I've said before, arrays aren't so useable in
the non-imperitive sense, and notably I don't think they can be used in
match like x::xs for lists -- which is very useful all over the place.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Gerd Stolpmann]

On Don, 2004-04-08 at 19:15, Brian Hurt wrote:
> > I agree with most of your analogy here.  I'm still relatively new to
> > OCaml, having been using it for only a couple of months, but you've
> > touched on one of my pet peeves: the OCaml standard library is really
> > sub-par for doing real work.  
> 
> Heh.  It's orders of magnitude better than the C or C++ standard
> libraries.  ...
>
> I think the problem here isn't technical, it's social- marketing, to be 
> specific.  Having a language with a very minimialistic standard library 
> isn't the problem- the problem is have a standard development environment 
> with a minimialistic library.  The "core" language and libraries 
> distribution should be, if not hidden, then at least not obvious.  
> Instead, the "default" Ocaml distribution should be something more like 
> CDK (is that project still alive?).  There shouldn't be links from the 
> home page to the core, the home page should link to CDK *only*.  And we 
> need to get the Linux distros up to speed and distributing CDK instead of 
> only Ocaml-core.

As far as I know, CDK isn't alive. Some times ago, I started the GODI
project to fill the gap, see http://www.ocaml-programming.de/godi. There
is already a working GODI distribution. There is already a lot of
infrastructure (mailing list, central repositories). The main error of
CDK was the missing capability of updating libraries; GODI avoids these
problems by using a packaging toolkit.

> While we're kvetching, here's my list of desires to be in the default 
> development environment (note that I don't think any of these belong in 
> the standard libraries):
> 	- OUnit
> 	- ExtLib (OK, this should perhaps become part of the standard)
> 	- BLAS/LAPACK, GMP, and MPI bindings
> 	- Regular expressions
> 	- ocamlexc
> 	- Camllisp (or similiar)
> 	- compression, encryption, etc. filters for I/O

Except regexps and encryption, GODI does not have these libraries yet.
But this is only a problem of packaging them, and uploading them to the
GODI repository. Volunteers are welcome! Ask in the GODI mailing list if
you are interested (https://gps.dynxs.de/mailman/listinfo/godi-list).

> Certain things can be moved out of the standard distribution and moved 
> into the development environment in this case- pcaml, ocamldoc, ocamlex, 
> ocamlyacc, etc.

Not when they are used for the compiler itself.

> Of course, the other advantage that the standard distribution has, in 
> addition to being the default, is coherent documentation.  There is one 
> book, and everything in the standard distribution is more or less equally 
> well documented (ocamllex and ocamlyacc could use some help).  The same 
> thing should be true for the development environment.

GODI does not enforce coherent documentation, but it is still a big step
forward, because all docs are in a single directory.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Thu, Apr 08, 2004 at 11:20:44AM -0700, Kenneth Knowles wrote:
> On Thu, Apr 08, 2004 at 07:59:04PM +0200, Jean-Marc EBER wrote:
> > I don't need to mention that your previous particular problem is so
> > trivial that it could easily be expressed with arrays as a "one
> > liner" of caml code... Look at Array.sub...
> 
> This is also a general principle - O'Caml is concise enough that a lot
> of helper functions you would expect in imperative scripting languages
> or C are too simple to include, for the sake of cleanliness.  I

That's an excellent practice, one I am still adjusting to.  For
instance, "String.make 1" makes sense as an alternative to
String.string_of_char.

However, while perhaps someone could design a more advanced String.sub
that can count backwards from the end of the string (I posted one such
example) in one line of the code, it may still have merit being in the
library.  Otherwise, everyone will probably end up writing a function
anyway (since it's too ugly to use inline with any frequency) and this
reduces the efficiency of programming with OCaml.

> By the way, list slicing has the same complexity as Array.of_list and
> then Array.sub so it is, in fact, in the standard library.  Don't even
> bother talking about efficiency at a lower level than complexity of
> algorithms until you have a complete, profiled program - and of course
> you are talking about disk access so there's not a chance of the
> slicing being a bottleneck.

My simplified example does not necessary represent all possible ones.
Some people may be dealing with 500MB structures where going back and
forth between lists and arrays is not even an executable option.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Christophe TROESTLER]

On Wed, 7 Apr 2004, John Goerzen <jgoerzen@complete.org> wrote:
> 
> [...] I'm looking at being able to let people insert OCaml
> expressions directly into otherwise plain-text config files.

Maybe 

Toploop.execute_phrase :
  bool -> Format.formatter -> Parsetree.toplevel_phrase -> bool

may help you but it lacks a bit of doc (I think some time ago the
question was asked on the ML, so checking the archives may be useful).

My 2¢,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Kenneth Knowles]

On Thu, Apr 08, 2004 at 01:39:57PM -0500, John Goerzen wrote:
> However, while perhaps someone could design a more advanced String.sub
> that can count backwards from the end of the string (I posted one such
> example) in one line of the code, it may still have merit being in the
> library.  Otherwise, everyone will probably end up writing a function
> anyway (since it's too ugly to use inline with any frequency) and this
> reduces the efficiency of programming with OCaml.

I agree that String.sub is not the exhaustive solution; a variety of ways to
select substrings is nice, and not provided in the standard library.  A huge
standard String module is still bad, so I wonder if anyone has submitted a
coherent patch with 2 or 3 fundamentally different string functions and strong
rationale?  Probably most people whine about how their 2000 line string library
isn't accepted into the standard, when the addition of less than 100 lines is
what String might need to be gracefully augmented.

Getting deep into the "what should go in the standard library" isn't what I want
to do - I just want to express general approval of small standard libraries with
functions that combine well.  I think a very beautiful solution to complaints
would be to have one fully independent library per module in the standard
library - one could easily make a complete String, List, Array, or Set library,
with useful, but non-orthogonal helper functions.

In particular, a comprehensive Date library would be very useful, since it is
not in the standard libs at all.  I think ocamli18n intended to solve this, but
I haven't tracked the project.

I haven't checked the Cstr library that was linked, so maybe it has some nice
stuff.

> My simplified example does not necessary represent all possible ones.
> Some people may be dealing with 500MB structures where going back and
> forth between lists and arrays is not even an executable option.

True, but let's not be silly.  A 500 MB structure is probably going to be its
own animal, not simply an array or list... and I've seen a lot of talk about
Persil on the mailing list for mixing on-disk and in-memory storage, which might
be appropriate.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Issac Trotts]

> I feel that this question really also touches the recent discussion
> concerning library management.  If it were very easy to make use of
> contributed code, we wouldn't talk so often about extensions to the
> standard library.

I'm thinking it would be very handy to have a code snippet server.
Something like this:

type fun_info = 
{
    key : int           (* unique identifier *)
    authors : string list
    date0 : int         (* initial revision, in minutes since 1980)
    date : int          (* most recent revision, in minutes since 1980)
    version : int list  (* major, minor, micro, etc. version numbers *)
    name : string       (* name of the function *)
    typ : string list   (* e.g., [ "int"; "string" ] for int -> string *)
    body : string       (* the source code for the function *)
    test : string       (* a function : unit -> unit that tests the code *)
    description : string
    digest : Digest.t
    dependencies : func list
    godi_deps : string list  (* list of godi packages it requires *)
    mutable num_downloads : int
    mutable rating_avg : float
    mutable rating_sdev : float
    license: BSD | GPL | LGPL | Qt | Other of string
}
type module_info = { ... }
type functor_info = { ... }
type class_info = { ... }
type snippet = 
      Fun of fun_info 
    | Module of module_info 
    | Functor of functor_info
    | Class of class_info

Database operations:
    - add new snippet
    - search on any field
    - create a module containing a function and all its dependencies
    - append a function and all of its dependencies to a .ml file and its
        .mli counterpart
    - load a function and all of its dependencies into the toplevel
    - add to local server a function and all its dependencies from a given
      server
    - add to local server all functions from a given server (mirror)

Maybe something fine-grained like this could be added to GODI.  

> I agree here: that's why I'd like to see more social tools rather than
> extensions to the standard library.  It's tiresome to search the web
> for already invented wheels, downloading code, compiling it (hopefully
> without problems), installing it and keeping it up-to-date (including
> libraries that it depends on).
>
> I am not questioning the fact that OCaml could need more libraries for
> more functionality.  I am questioning that all of this should become
> part of a standard library.  I wouldn't mind seeing the code there, of
> course, but why burden the developers with tasks that could be done by
> the community?  What is "standard" anyway?  Only what INRIA calls one?
> Or what is used predominantly by the community?

If the standard library gets too large, that also means longer compile
times for the ocaml distro.  It already takes long enough.

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Issac Trotts]

On Thu, Apr 08, 2004 at 04:31:26PM +0100, Jon Harrop wrote:
> On Thursday 08 April 2004 3:56 pm, Markus Mottl wrote:
> > On Thu, 08 Apr 2004, John Goerzen wrote:
> > > Similar complaints exist for working with subsets of lists; it's really
> > > too hard to say "replace elements 4 through 9 with this", "delete
> > > elements 4 through 9", "return elements 4 through 9", etc.
> >
> > Yes, it's hard to do this with the current standard library.  The question
> > is: who needs these functions anyway?  I can't remember ever having felt
> > a need for them.
> 
> I could do with them! There are numerous such functions (and nice 
> implementations, like "List.nth -1 l" fetching the last element, more 
> powerful flatten etc.) which Mathematica has and which I miss.

GCaml has the ability to do this kind of total flattenning of nested
lists.  OCaml cannot do it unless you re-express your nested lists as
binary trees or something similar.

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Markus Mottl]

On Thu, 08 Apr 2004, John Goerzen wrote:
> On Thu, Apr 08, 2004 at 08:23:01AM -0700, Kenneth Knowles wrote:
> > If you haven't already, take a look at the OCamlMakefile here:
> > http://www.ai.univie.ac.at/~markus/home/ocaml_sources.html
> 
> I had already looked at, and discared, OCamlMakefile because of several
> problems -- mainly the inability to manage more complex projects that
> may generate several executables that share some modules, and the
> ability to determine, at build time, whether to build native binaries
> and libraries.

What concerns "more complex projects": the latest major change to
OCamlMakefile was support for subprojects (which may also share some
modules!).  So I hope that this issue is not relevant anymore.

And regarding the optional building of native binaries/libraries: this
can be added.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Thu, 2004-04-08 at 23:37, John Goerzen wrote:

> I'm still relatively new to
> OCaml, having been using it for only a couple of months,

> Basic string processing is also more difficult than a language such as,
> say, Python, where I can say, for instance:

> Also, there is no string_of_char function (I'd have to use fill).

As a newbie, you'll think these omission more serious than
a more seasoned Ocaml programmer, IMHO. The reason is,
most of these things are just *so* easy to define as you want
in Ocaml, compared to other languages.

I've worked with ultra-rich C++ libraries and have nothing
but total criticism of them: there is a function for just about
everything you want to do .. if you can find it in the documentation,
and if it actually works .. and if the documentation is correct ..
and if you can spend hours running test code to determine which
combinations are most efficient ... UGGGG!

I'm not saying you're wrong, just that the problem here
is less than you might expect. Yeah, its a pain writing

let list_of_hashtbl cmp h =
  let x = ref [] in Hashtbl.iter
  (fun k v -> x := (k,v) :: !x)
  h; 
  sort cmp !x

but truly, it didn't take that long to write
(and would be even cuter with a fold .. :D

How many C++ users would write:

	std::copy(ss, se, d)

instead of

	for(p=ss;p!=se;)*d++=*p++;

The BIG advantage Python and C++ have over Ocaml here is that
they have coherent library design concepts. Both Python and C++
have a serialisation (iterator/sequence) concept and one
of associative containers, and both provide syntactic support.
(Python with things like for loops and slices, C++ with STL).

The real problem in Ocaml is that the right way to do this
is functorial polymorphism, which is still pretty bleeding edge.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Fri, 2004-04-09 at 01:14, Richard Jones wrote:
> On Thu, Apr 08, 2004 at 04:56:06PM +0200, Markus Mottl wrote:
> > Yes, it's hard to do this with the current standard library.  The question
> > is: who needs these functions anyway?  I can't remember ever having felt
> > a need for them.
> 
> My "private library" defines:
> 
> val first : int -> 'a list -> 'a list

And I need 'last' often (get last element).

> which returns the first n members of a list.  As for slicing the
> middle from a list, I tend to think that the original poster should
> probably be using a different, more suitable structure.  Perhaps an
> Array if he wants random access.

Sometimes inefficient operations are necessary,
there's no universally good data structure.

I need 'last' element of a list, because sometimes
my lists happen to be in the wrong order. I won't use an
Ocaml array, even if it were universally more efficient
for what I want, because it's mutable!

Fact is, most of my lists are so short I don't
care two hoots about efficiency. I care only
for the couple of really BIG lists I keep
(eg: list of all tokens of a program).

Even then I'd rather get it right and keep it simple,
and perhaps worry about performance down the track.
More than one solution may exist. For example,
I now cache the result of tokenisation, parsing,
and macro processing on disk with Marshal, which saves
one heck of a lot more time than merely changing the
data structure I use to represent program text
at the token level -- there's nothing faster than
building *no* data structure :D

Actually, the lists are so much easier to work with,
because there is builtin support for forward iteration:

let filt a b =
	match a with
	| [] -> b
	| COMMENT s :: t -> filt t b 
	| h :: t -> filt t (h::b)

Try doing that with an array .. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Fri, 2004-04-09 at 02:44, Markus Mottl wrote:
> On Thu, 08 Apr 2004, John Goerzen wrote:

> I agree here: that's why I'd like to see more social tools rather than
> extensions to the standard library.  It's tiresome to search the web
> for already invented wheels, downloading code, compiling it (hopefully
> without problems), installing it and keeping it up-to-date (including
> libraries that it depends on).

Sure .. and even more of a pain to finally find a nice library
by Markus Mottl only to discover that hidden away in the
source is a (L)GPL licence, making it useless if you happen
for example to be making a BSD licenced product .. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Remi Vanicat]

skaller <skaller@users.sourceforge.net> writes:

> On Fri, 2004-04-09 at 02:44, Markus Mottl wrote:
>> On Thu, 08 Apr 2004, John Goerzen wrote:
>
>> I agree here: that's why I'd like to see more social tools rather than
>> extensions to the standard library.  It's tiresome to search the web
>> for already invented wheels, downloading code, compiling it (hopefully
>> without problems), installing it and keeping it up-to-date (including
>> libraries that it depends on).
>
> Sure .. and even more of a pain to finally find a nice library
> by Markus Mottl only to discover that hidden away in the
> source is a (L)GPL licence, making it useless if you happen
> for example to be making a BSD licenced product .. 

If it is LGPL + special exception (as the stdlib of ocaml) I don't see
the problem. GPL can be a problem thought.

-- 
Rémi Vanicat

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Fri, 2004-04-09 at 03:35, John Goerzen wrote:

> Yes.  That would make sense for a lot of things.  The Humps are already
> fairly usable for finding things, but installing them can be a different
> matter.
> 
> I have to think twice before using things not in the standard library
> for code that others will run because I must consider the complexity of
> setting them up.  Some libraries don't compile out of the box on systems
> that lack ocamlopt; others require various amounts of Makefile hacking
> to see correct paths, etc.

With this I agree entirely. My policy is "NO THIRD PARTY LIBRARIES".
I'm quite happy to build and install them for my own use
but I can't figure a way to simultaneously redistribute them,
whilst at the same time not having to be responsible for
maintaining them (quite apart from licencing issues).

Guess I'd be happy to use 3PL's when the packaging/retrieval
mechanism (such as GODI) was itself part of the standard distro.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Pierre Weis]

> > ...  (While we're
> > at it, I think it's silly that there is a list and an array type). ...

Yes, it's silly that reality is so complex.

On the other hand, that's why life is so fun :)

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Fri, 2004-04-09 at 16:33, Remi Vanicat wrote:

> If it is LGPL + special exception (as the stdlib of ocaml) I don't see
> the problem. GPL can be a problem thought.

Not sure of the 'special exception' but my impression is that
whilst one is free to use "as is" an LGPL library by
first compiling it, then linking to it, without polluting
the licence of the code using it, that freedom doesn't
extend to the source itself. If I combine parts of 
the source of a library with my own sources, my sources
are contaminated.

My distro is entirely in 'pre-source' form,
which makes a mockery of the LGPL. 

It isn't clear what happens here:

(* LGPL_client.ml *)
module LGPL.Make(struct type t = int end)

ocamlc -i LGPL_client.ml > LGPL_client.mli

well, is that a 'derived work' covered by LGPL
or is it free for any use?

It sure as heck ain't a compiled binary: LGPL is basically
"unsustainable gobblegook" <g> outside the realm of C programming.
The legal impact would seem to me to be: 
permission for use isn't explicitly
and clearly given, so it doesn't exist.

Ocaml itself isn't a problem: the intent is clear,
the distro is to be trusted (I won't modify it even
if I do find a bug), and there is always an option
of a commercial licence.

I don't feel so trusting of third parties,
and can't expect to require my clients to either.

Actually, GODI will probably help enormously,
by at least imposing some uniformity on the
way in which third party packages are installed,
the potential reduced need to fiddle with a third
party component may provide enough separation
between sources to prevent contamination.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Remi Vanicat]

skaller <skaller@users.sourceforge.net> writes:

> On Fri, 2004-04-09 at 16:33, Remi Vanicat wrote:
>
>> If it is LGPL + special exception (as the stdlib of ocaml) I don't see
>> the problem. GPL can be a problem thought.
>
> Not sure of the 'special exception' but my impression is that
> whilst one is free to use "as is" an LGPL library by
> first compiling it, then linking to it, without polluting
> the licence of the code using it, that freedom doesn't
> extend to the source itself. 

Yes,

> If I combine parts of the source of a library with my own sources,
> my sources are contaminated.

Yes.

>
> My distro is entirely in 'pre-source' form, which makes a mockery of
> the LGPL.

Well, if your package include the unmodified library, there is no
problem. There is not problem even if you include a modified library
if the modified library is still under LGPL + special exception.

>
> It isn't clear what happens here:
>
> (* LGPL_client.ml *)
> module LGPL.Make(struct type t = int end)
>
> ocamlc -i LGPL_client.ml > LGPL_client.mli
>
> well, is that a 'derived work' covered by LGPL
> or is it free for any use?

No, you are using it, not deriving from it. The library is
unmodified. 

[...]


-- 
Rémi Vanicat

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

OT: licences (was Re: [Caml-list] Dynamically evaluating OCaml code)

[Benjamin Geer]

skaller wrote:
> Ocaml itself isn't a problem: the intent is clear,
> the distro is to be trusted (I won't modify it even
> if I do find a bug), and there is always an option
> of a commercial licence.

There's no harm in asking third-party library authors if they'll sell 
you a commercial licence, too.  This is what has enabled MySQL AB to 
release a popular database as free software.

 From the library vendor's point of view, the GPL is better than the 
LGPL for this purpose, because using the GPL requires more developers of 
non-free software to pay for commercial licences, thus providing more 
financial support for free software.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Markus Mottl]

On Fri, 09 Apr 2004, skaller wrote:
> Sure .. and even more of a pain to finally find a nice library
> by Markus Mottl only to discover that hidden away in the
> source is a (L)GPL licence, making it useless if you happen
> for example to be making a BSD licenced product .. 

I'd say it depends on the way you distribute things.  You may well use
an LGPLed library in a BSD licenced product - at least I don't see any
problem here.  However, what you cannot do is that you modify the LGPLed
source and put the result under a BSD licence.  So what's the problem
you have?

If you need to modify my library (you may also ask for modifications,
of course ;), just go ahead - as long as you keep the LGPL for the
modified library.  But this does not affect other software that uses
the library: it can have any licence you want, even commercial ones.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[james woodyatt]

On 08 Apr 2004, at 23:23, skaller wrote:
>
> Sure .. and even more of a pain to finally find a nice library
> by Markus Mottl only to discover that hidden away in the
> source is a (L)GPL licence, making it useless if you happen
> for example to be making a BSD licenced product ..

This is just a friendly reminder: my Cf library is distributed under 
the two-clause BSD-style license.  And it does contain a functional 
real-time catenable deque, among other trivial data structures and 
algorithms.  I'm getting ready to release a minor update to it in a 
week or two (fixes some bugs in Cf_gadget, adds some functions to 
Cf_seq and Cf_flow).

I'll even consider waiving the terms of the BSD license for the right 
price...


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Bruno.Verlyck]

   Date: Thu, 8 Apr 2004 12:55:19 -0500
   From: John Goerzen <jgoerzen@complete.org>

   On Thu, Apr 08, 2004 at 06:44:15PM +0200, Bruno.Verlyck@inria.fr wrote:
   > - read-write file handles: You can get them with Unix.openfile
   >   and Unix.dup.  Then with Unix.{in,out}_channel_of_descr, you
   >   can use the Pervasives I/O functions.
   I have discovered that, but it seems that I don't fully understand
   the buffering semantics over on the Pervasives side.  For instance,
   it's not entirely clear what happens if I write something to an out
   channel, then seek somewhere via that channel, then read via the
   other channel.  The results have not always been what I expected.
You aren't a lot better in C.  What does Posix/SUS V2 says for fopen ?
    When a file is opened with update mode (+ as the second or third
    character in the mode argument), both input and output may be
    performed on the associated stream.  However, output must not be
    directly followed by input without an intervening call to fflush()
    or to a file positioning function (fseek, fsetpos() or rewind()),
    and input must not be directly followed by output without an
    intervening call to a file positioning function, unless the input
    operation encounters end-of-file.
This is error-prone at least.

As for OCaml buffering semantics:
- you begin to understand why there's no read-write channel: a lot of
  complexity for a seldom used functionality;
- those having been banned, the OCaml I/O system makes no effort to
  ease things for you: the two channels are independently buffered,
  they don't known of each other, reading won't see your last
  modifications if nothing forces an update of the buffer.
Beware: this is what I remember, io.c is of course the ultimate
reference.

   (Pervasives appears to sometimes make an underlying call to read or
   write a different number of bytes than I requested -- which can be
This is called (you guessed it) buffering.
   a problem for network protocols where this can cause deadlock)
If it gets in your way, don't use Pervasives (but Unix.{read,write}).

   > - string handling: look at my (rather full-featured) Cstr library
   >   (http://pauillac.inria.fr/cash/cstr/);
   That looks great.  Has a lot of stuff I'd use.  It looks like it's
   separate from cash; is that correct?  (If so, I'll package it up
   for Debian right away <g>)
That's correct.  Thank you for the packaging.  Some bugs are fixed in
the CVS version (hopefully none introduced.. :-).

Bruno.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Fri, 2004-04-09 at 18:36, Markus Mottl wrote:

> I'd say it depends on the way you distribute things.  You may well use
> an LGPLed library in a BSD licenced product - at least I don't see any
> problem here.  However, what you cannot do is that you modify the LGPLed
> source and put the result under a BSD licence.  So what's the problem
> you have?

The whole of my distro consists of literate programmed
sources under a single licence. If I consider you an
unstable/unreliable source, I have to physically
include your sources with mine in a wrapped up
form.

I simply cannot require my clients require
their clients require downloading and installing
20 different third party Ocaml/C packages just
to get the Felix *compiler* to work, or spend
week analysing my code to decide which parts
are FFAU and which LGPL.

Stick PCRE in the standard Ocaml distro and
the problem goes away entirely. 

Hmm. Perhaps this is one way of expressing it:

My product is part of the Bazaar but it has
pretensions of being its own Cathedral and so
can't depend on the rest of the Bazaar,
only on other Cathedrals.

Arms length is OK. Two arms length is not :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: OT: licences (was Re: [Caml-list] Dynamically evaluating OCaml code)

[skaller]

On Fri, 2004-04-09 at 18:35, Benjamin Geer wrote:
> skaller wrote:
> > Ocaml itself isn't a problem: the intent is clear,
> > the distro is to be trusted (I won't modify it even
> > if I do find a bug), and there is always an option
> > of a commercial licence.
> 
> There's no harm in asking third-party library authors if they'll sell 
> you a commercial licence, too.  

.. and no point. I don't have any money to buy one.

Worse, the product may itself need other 3PL.
For example: PCRE depends on pcre. Markkus might
sell a licence for PCRE but its useless without
pcre, and he can't sell me a licence for that.

The problem is scale. I have no problem with Ocaml
because a really large client who wanted my system
could indeed negotiate with INRIA if needed.

But I can't expect them to trade with Markkus,
its bad enough that they're dealing with me :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Dynamically evaluating OCaml code

[Trevor Andrade]

I think when discussing this we have to separate means and ends.  The
end that we would like is that we want to download a caml distribution
from the internet and we get everything we want like IPV6, sockets,
directory functions etc, and also probably a lot of stuff we will never
use (internet connections are fast and disk space is cheap so who cares
if its big).  Ideally you should have one download where you get
everything.  Also this download should be fairly standardized so that
most people can download the same library and it should be of high
quality.

Why is this necessary?  Because history has shown it works.  One of the
main reasons many other languages like lisp and smalltalk are not very
popular is that they don't have large standardized libraries.  I also
think that the reasons C++ is dying is that it does not have a good
standardized library.  Languages like Python are very popular precisely
because they do have large standard libraries.  

Now the question is what are means through which you can accomplish
giving people large standardized distributions with everything they
need.  One way is just to have a big standard library.  Another way
might be to separate the standard library into two parts  a standard
core library and a separate extended standard library.  A third way is
to just have a centralized repository like Perl's CPAN or Ruby's RAA.  I
think you have to be careful with large centralized repositories because
the code quality can suck (eg Ruby's RAA) unless they are monitored
well.  Also if you do use a large central repository you often don't
have standardized tools because different versions exist for things.
Thirdly downloading and installing from centralized repositories should
be easy so there should be a tool for doing this like cygwin's
installation tool.  I should mention that cygwin's installation tool is
extremely nice.  It handles dependencies, versioning and does remote
installation.  Miktex uses the cygwin tool to access the Tex archives.
In this case the centralized repository method works pretty well.
However in tex it does often happen that there are separate packages
that you download that have some similar functions.  I think Pyhon's big
standard library model is the best.  Using this method you get a nice
big standardized distribution with everything you need. This makes your
life very easy.  In Python there are also many things outside the
standard library and as the quality of these things gets better they
often get put in the standard library.  It should also be noted that its
not really necessary for the core developers to manage everything in the
standard library.  In Python most of the standard library is not managed
by the core developers of the language who work on things like the
language and the interpreter.  Instead the different parts are managed
by either the author of that part or some maintainer.  I don't see why
core developers have to maintain the standard library.  They should just
decide what makes it in to the standard library. 

Regards,
Trevor


-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of John Goerzen
Sent: Thursday, April 08, 2004 11:59 AM
To: Richard Jones; Ocaml Mailing List
Subject: Re: [Caml-list] Dynamically evaluating OCaml code

On Thu, Apr 08, 2004 at 05:26:54PM +0200, Markus Mottl wrote:
> On Thu, 08 Apr 2004, Richard Jones wrote:
> > which returns the first n members of a list.  As for slicing the
> > middle from a list, I tend to think that the original poster should
> > probably be using a different, more suitable structure.  Perhaps an
> > Array if he wants random access.
> 
> That's also my opinion: it's usually an indication of a bad choice
> concerning datastructure if you need such list functions.

One does not always have the choice of data structure.  Sometimes, and
this happens to be the case in several programs I've worked on recently,
the inadequecies arise when I'm trying to get data frmo an older system
into an OCaml-based one that does use more suitable structures.

For instance, consider this problem, which is a simplified version of a
real problem...  I am reading a line-oriented file delimited by "|".
It's easy enough to split this apart into a list (even though I must go
to Str and regexps to do it, grr).  

Now, I know that I must ignore the first two and last three elements in
that list.  I do not know in advance what size the list will be, and it
varies from line to line, but it always has at least five elements.  I
also do not necessarily know the values for "2" and "3" at compile time,
though they are constant throughout execution of the program.  The order
of the elements is significant and must not be altered.  Each element is
the same type (ie, a String).  There is nothing in the data itself that
differentiates it.

Now, which OCaml data structure gives me the ability to easily pull out
such a slice?  As far as I can tell, there are no standard functions for
any of Array or List to do that.  I could write a function for either of
them to loop over it and get me what I want, but the point is that this
functionality is useful.

Now, there are arguably other ways to do this; I could use a complex
regular expression to pull out the data in the center... ie:

  ([^|]*\|){2}(.*)(\|[^|]*){3}

may do the trick in this particular example, but not always.  (What if,
instead of lines, I am dealing with packets coming in off the network?)

One does not always get data handed to onesself on a platter, already
nicely ordered and suitable for storing in a nice structure (in any
language).  Hell, half the time my first step is to -- yes -- convert to
ASCII.  (I sometimes have to work with data coming from an AS/400, an
EBCDIC system that is thankfully being phased out)

> I absolutely agree with you!  But the point is: is this really so
> important to have it in the _standard_ library?  You didn't mention
the
> word "standard" so I suppose you'd be perfectly happy if somebody
wrote a
> fully-featured library for this kind of functionality?  And you'd
rather
> like to see better "social tools" for making use of such
contributions?

I don't really care if it comes in ocaml.tar.gz or not, for some of
these things.  Some of them absolutely should, especially more powerful
string/array/list slicing, IPv6, and POSIX interfaces.  But many of the
rest don't exist at all or require contortions to use.  (For instance,
there are two libraries out there named Extlib, both of which implement
some of what I want with little overlap between them.  How annoying.)

I see these as critical ommissions from the actual standard library:

 * IPv6 and other socket-related and DNS-related problems
 * Lack of support for read/write handles in Pervasives (relegated to
   Unix and with complex interactions between the two)
 * String/array/list indexing/slicing improvements
 * Standard C/POSIX date/time functions
 * Path manipulation functions (about 75% of these are already there;
   I have no idea why the other 25% aren't)
 * mknod() and similar functions  (we have mkfifo(), after all...)

These are all enhancements of functionality already present in the
standard library.  Why would I be able to use the standard library for
IPv4 but have to go elsewhere for IPv6?  That doesn't really make sense.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Dynamically evaluating OCaml code

[Gerd Stolpmann]

You should have a look at GODI, http://www.ocaml-programming.de/godi,
which is a caml distribution (although not very complete yet). However,
GODI does not implement the "one big download" approach, but allows the
user to select the packages he wants. The big advantage is that
independent updates are possible. There is no disadvantage for the user
because there is a nice user interface that hides the complex technical
details.

Am Die, 2004-04-13 um 08.15 schrieb Trevor Andrade:
> 
> I think when discussing this we have to separate means and ends.  The
> end that we would like is that we want to download a caml distribution
> from the internet and we get everything we want like IPV6, sockets,
> directory functions etc, and also probably a lot of stuff we will never
> use (internet connections are fast and disk space is cheap so who cares
> if its big).  Ideally you should have one download where you get
> everything.  Also this download should be fairly standardized so that
> most people can download the same library and it should be of high
> quality.

I must admit that I don't see the point. What is the advantage when most
people have the same library? Aren't we individuals?

> Why is this necessary?  Because history has shown it works.  

It depends on how you interpret history. E.g. I don't believe C++ is
dying, there is so much code written in it, it must continue to live,
even as a vampire. It is not clear to me what you mean with
"standardized", maybe you mean "easily accessible"?

> One of the
> main reasons many other languages like lisp and smalltalk are not very
> popular is that they don't have large standardized libraries.  I also
> think that the reasons C++ is dying is that it does not have a good
> standardized library.  Languages like Python are very popular precisely
> because they do have large standard libraries.  
> 
> Now the question is what are means through which you can accomplish
> giving people large standardized distributions with everything they
> need.  One way is just to have a big standard library.  Another way
> might be to separate the standard library into two parts  a standard
> core library and a separate extended standard library.  A third way is
> to just have a centralized repository like Perl's CPAN or Ruby's RAA.  I
> think you have to be careful with large centralized repositories because
> the code quality can suck (eg Ruby's RAA) unless they are monitored
> well.  Also if you do use a large central repository you often don't
> have standardized tools because different versions exist for things.
> Thirdly downloading and installing from centralized repositories should
> be easy so there should be a tool for doing this like cygwin's
> installation tool.  I should mention that cygwin's installation tool is
> extremely nice.  It handles dependencies, versioning and does remote
> installation.  

Cygwin is an extremely simple case. GODI does much more, it does not
only download, but also compile the code. The complexity is somewhere
else.

> Miktex uses the cygwin tool to access the Tex archives.
> In this case the centralized repository method works pretty well.
> However in tex it does often happen that there are separate packages
> that you download that have some similar functions.  I think Pyhon's big
> standard library model is the best.  Using this method you get a nice
> big standardized distribution with everything you need. This makes your
> life very easy.  In Python there are also many things outside the
> standard library and as the quality of these things gets better they
> often get put in the standard library.  It should also be noted that its
> not really necessary for the core developers to manage everything in the
> standard library.  In Python most of the standard library is not managed
> by the core developers of the language who work on things like the
> language and the interpreter.  Instead the different parts are managed
> by either the author of that part or some maintainer.  I don't see why
> core developers have to maintain the standard library.  They should just
> decide what makes it in to the standard library. 

Don't forget that ocaml attracts mostly creative and individual people.
Even the core language supports that, there are usually many ways of
modelling APIs and such. I predict you would fail miserably if you tried
to establish a larger standardization process.

Ok, there are currently things missing in the ocaml stdlib that would be
difficult to add as a separate library. On the other hand, it is better
to keep the stdlib small but widely accepted, and to make it easy to
install add-on libraries. For the latter, GODI is my suggestion.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Dynamically evaluating OCaml code

[skaller]

On Tue, 2004-04-13 at 21:17, Gerd Stolpmann wrote:

> I must admit that I don't see the point. What is the advantage when most
> people have the same library? Aren't we individuals?

The advantage is transitivity. 

We're all nerds, we can faff about with tarballs
and post to this list about installation and
compatibility issues .. and be happy :D

But many of us are writing software for a market
that are not programmers but we still desire to
distribute our code as Source.

[In my case my market is C/C++ hackers .. not sure
if you'd consider then 'programmers' or not :]

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen]

On Tue, Apr 13, 2004 at 01:17:01PM +0200, Gerd Stolpmann wrote:
> You should have a look at GODI, http://www.ocaml-programming.de/godi,
> which is a caml distribution (although not very complete yet). However,
> GODI does not implement the "one big download" approach, but allows the
> user to select the packages he wants. The big advantage is that
> independent updates are possible. There is no disadvantage for the user
> because there is a nice user interface that hides the complex technical
> details.

Hi Gerd,

I've seen several references here to GODI and I checked it out.  I am
wearing several "hats" in this discussion; one of them is a developer
for Debian, and another is a developer, and another still is an end-user
of OCaml code.

>From the surface (and this is just from reading, not from actually
installing it), one problem I see with GODI is that it will not
necessarily play nice with an existing packaging system.  For instance,
if the user has installed OCaml and some libraries from Debian already,
but wants to add some others from GODI, it looks problematic.  Perl's
CPAN addresses this nicely (it will simply download things not already
present and install them in a separate directory).

Also, moving everything into ocamlfind may cause compatibility issues
for application developers that may be accustomed to not using ocamlfind
for certain libraries that are not normally distributed using ocamlfind.

Having said all that, I think that GODI is an excellent idea and sorely
needed.  I still maintain that installation of libraries and
applications in OCaml is way more difficult than it need be.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Gerd Stolpmann]

Am Die, 2004-04-13 um 16.24 schrieb John Goerzen:
> On Tue, Apr 13, 2004 at 01:17:01PM +0200, Gerd Stolpmann wrote:
> > You should have a look at GODI, http://www.ocaml-programming.de/godi,
> > which is a caml distribution (although not very complete yet). However,
> > GODI does not implement the "one big download" approach, but allows the
> > user to select the packages he wants. The big advantage is that
> > independent updates are possible. There is no disadvantage for the user
> > because there is a nice user interface that hides the complex technical
> > details.
> 
> Hi Gerd,
> 
> I've seen several references here to GODI and I checked it out.  I am
> wearing several "hats" in this discussion; one of them is a developer
> for Debian, and another is a developer, and another still is an end-user
> of OCaml code.
> 
> From the surface (and this is just from reading, not from actually
> installing it), one problem I see with GODI is that it will not
> necessarily play nice with an existing packaging system.  For instance,
> if the user has installed OCaml and some libraries from Debian already,
> but wants to add some others from GODI, it looks problematic.  Perl's
> CPAN addresses this nicely (it will simply download things not already
> present and install them in a separate directory).

Perl is a scripting language, installing something means mostly to copy
the files at the right places. O'Caml sources must be compiled, and once
that has happened, there are strict dependencies on the environment
(e.g. if library X uses library Y the signature of Y must not change any
more). This is one of the key reasons why GODI uses a rather
heavy-weight packaging system, unlike CPAN. Of course, this makes it
more complicated to integrate it into already existing packaging
systems.

However, I can imagine we could have "GODI Light" that assumes there is
already a working O'Caml installation, and that only installs the
missing parts. This is not impossible. (Actually, I have a similar idea
on my TODO list, namely to allow the usage of a CVS OCaml version.)

> Also, moving everything into ocamlfind may cause compatibility issues
> for application developers that may be accustomed to not using ocamlfind
> for certain libraries that are not normally distributed using ocamlfind.

The "-I +lib" syntax is supported for libraries that are used to be
installed this way. (This is currently achieved by symlinks. Not really
nice. Better would be a path where lib is searched, but this needs a
change in ocamlc.)

> Having said all that, I think that GODI is an excellent idea and sorely
> needed.  I still maintain that installation of libraries and
> applications in OCaml is way more difficult than it need be.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Matt Gushee]

On Tue, Apr 13, 2004 at 09:24:16AM -0500, John Goerzen wrote:
> 
> Also, moving everything into ocamlfind may cause compatibility issues
> for application developers that may be accustomed to not using ocamlfind
> for certain libraries that are not normally distributed using ocamlfind.

There's a simple solution to this (works well for standalone build; I'm
not sure if GODI accommodates this practice, but I can't imagine it
would be difficult to make the necessary modifications): you can install
the library in the traditional way, but also make it a "virtual" Findlib
package--i.e. create a package directory, and place in it a META file
that points to the real installation directory. Then people can access
the package either in the traditional manner or through Findlib. All it
takes is a short META file and two or three lines added to the Makefile,
so it's easy to do manually, but should also be easy to automate.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Dynamically evaluating OCaml code

[Benjamin Geer]

Gerd Stolpmann wrote:
> Don't forget that ocaml attracts mostly creative and individual people.
> Even the core language supports that, there are usually many ways of
> modelling APIs and such. I predict you would fail miserably if you tried
> to establish a larger standardization process.

This is a very perceptive observation and should probably be an FAQ. :) 
  However, even creative and individual people need standards in order 
to work together.  Here we are all speaking English (and sometimes 
French), for example.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: GODI (was: Dynamically evaluating OCaml code)

[Christophe TROESTLER]

On 13 Apr 2004, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> However, I can imagine we could have "GODI Light" that assumes there is
> already a working O'Caml installation, and that only installs the
> missing parts. This is not impossible. (Actually, I have a similar idea
> on my TODO list, namely to allow the usage of a CVS OCaml version.)

Well, I haven't had a look to GODI internals but IMHO I think it is
better that GODI exports some API that the Debian Package system could
use to make known to GODI what he has installed.  Also, in order to be
compliant with Debian policies GODI packages should be installed into
/usr/local/lib/ocaml/<version> (Debian developpers correct me on this).

ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI (was: Dynamically evaluating OCaml code)

[Gerd Stolpmann]

On Die, 2004-04-13 at 20:07, Christophe TROESTLER wrote:
> On 13 Apr 2004, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> > 
> > However, I can imagine we could have "GODI Light" that assumes there is
> > already a working O'Caml installation, and that only installs the
> > missing parts. This is not impossible. (Actually, I have a similar idea
> > on my TODO list, namely to allow the usage of a CVS OCaml version.)
> 
> Well, I haven't had a look to GODI internals but IMHO I think it is
> better that GODI exports some API that the Debian Package system could
> use to make known to GODI what he has installed.

So you would like to virtually add the Debian packages to GODI. In
principle, this is no problem for all findlib-based packages, just add
the Debian directory to the findlib path in findlib.conf. However, this
works only when there is no signature conflict (e.g. Debian's Pervasive
module has the same signature as GODI's). I don't know if this is the
case.

>  Also, in order to be
> compliant with Debian policies GODI packages should be installed into
> /usr/local/lib/ocaml/<version> (Debian developpers correct me on this).

You can freely select where you install GODI.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[Christophe TROESTLER]

On Tue, 13 Apr 2004, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> On Die, 2004-04-13 at 20:07, Christophe TROESTLER wrote:
> > On 13 Apr 2004, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> > > 
> > > However, I can imagine we could have "GODI Light" that assumes there is
> > > already a working O'Caml installation, and that only installs the
> > > missing parts. This is not impossible. (Actually, I have a similar idea
> > > on my TODO list, namely to allow the usage of a CVS OCaml version.)
> > 
> > Well, I haven't had a look to GODI internals but IMHO I think it is
> > better that GODI exports some API that the Debian Package system could
> > use to make known to GODI what he has installed.
> 
> So you would like to virtually add the Debian packages to GODI. In
> principle, this is no problem for all findlib-based packages, just add
> the Debian directory to the findlib path in findlib.conf. However, this
> works only when there is no signature conflict (e.g. Debian's Pervasive
> module has the same signature as GODI's). I don't know if this is the
> case.

Sven should say better what is possible but my idea is that GODI and
the Debian package system talk to each other.  So there should NOT be
two Pervasives modules.  If the GODI (Debian) package is installed,
the other Ocaml packages should make use of it.  If GODI wants to
recompile some Debian Package, either (1) delegate the task to the
Debian package manager (say there is a new version of the package
available or else use dpkg to download and build from source) or (2)
consider Debian packages as "on hold" and refuse the GODI operation.

That requires a correspondance between package names on the two sides
-- thus some dialog with the Debian maintainers -- but it is a good
idea not to have different names for a given package anyway...

My 2¢,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI

[Brandon J. Van Every]

Christophe TROESTLER wrote:
>
> Sven should say better what is possible but my idea is that GODI and
> the Debian package system talk to each other.

I am curious if any of these concerns about Package Management will ever
benefit those of us on the Windows platform?  And by that, I mean people
who favor standard Windows development approaches, not the MinGW /
Cygwin UNIX lookalike stuff.  Reading the GODI web pages, I was not
encouraged that it would happen anytime soon, if at all.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] eval for OCaml

[Brock]

Based on Clement's example, I created a usable eval. I am using

  The Objective Caml compiler, version 3.07+2

Here is the code:

testeval.ml
---------------------------------------------------------
exception EvalError

(* Reset the eval environment *)
let eval_reset() =
  Toploop.initialize_toplevel_env()

(* Eval some text. We get no result from this *)
let evalp txt =
  try
    let lb = (Lexing.from_string txt) in
    let phr = !Toploop.parse_toplevel_phrase lb in
    ignore(Toploop.execute_phrase false Format.std_formatter phr)
  with _ -> raise EvalError

(* Get the content of some defined variable *)
let evalv v =
  Obj.obj (Toploop.getvalue v)

(* Eval some text and then return some defined variable *)
let eval v txt =
  evalp txt;
  evalv v

let _ =
  eval_reset();
  evalp "let add1 x = x +1;;";
  let n : int = eval "n" "let n = add1 2;;" in
  print_string "n = ";
  print_int n;
  print_newline()

-------------------------------------------------

brock@ihd103:~/tmp$ ocamlc -o evaltest toplevellib.cma evaltest.ml
brock@ihd103:~/tmp$ ./evaltest
n = 3

-------------------------------------------------

Just as a reminder, THIS IS NOT TYPESAFE and is quite dangerous and
should be avoided at nearly all costs. :)

Improvements might include more shortcuts - for example one like

(* Evaluate an expression, return the result *)
let evalexp txt =
  eval "v" ("let v = " ^ txt ^ ";;")

--Brock


On 2004.04.07.23.25, clement capel wrote:
|
|  Try this simple example:
|
|  Toploop.initialize_toplevel_env();;
|
|  let eval txt = let lb = (Lexing.from_string txt) in
|    let phr = !Toploop.parse_toplevel_phrase lb in
|    Toploop.execute_phrase true Format.std_formatter phr;;
|
|  eval "let add1 x = x +1;;";;
|  eval "add1 2;;";;
|
| (compile with toplevellib.cma)
|
|  But be careful, it can break the typing system.
|  if you use the Toploop module in the
| "string parameter" of the function eval or if you
| evaluate it in the toplevel.
| But it seems there's a guard with the new version (3.07+2).
|
|
|
|  Hope it will help you.
|
|  Regards,
|
|                        Cl?ment

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI

[Gerd Stolpmann]

On Die, 2004-04-13 at 22:45, Brandon J. Van Every wrote:
> Christophe TROESTLER wrote:
> >
> > Sven should say better what is possible but my idea is that GODI and
> > the Debian package system talk to each other.
> 
> I am curious if any of these concerns about Package Management will ever
> benefit those of us on the Windows platform?  And by that, I mean people
> who favor standard Windows development approaches, not the MinGW /
> Cygwin UNIX lookalike stuff.  Reading the GODI web pages, I was not
> encouraged that it would happen anytime soon, if at all.

I think it is not possible to do it without the "MinGW/Cygwin Unix
lookalike stuff". There is a very simple reason: All library authors
provide Unix build scripts (i.e. Makefiles using standard Unix
commands). GODI just calls these scripts, so you need something like
Cygwin to interpret them.

The other question is which compiler is used as backend. I can imagine
to call MSVC, but there are limitations because of GODI's organization:
MSVC costs money. Don't forget that GODI is for free, and there isn't
any way to collect money for the necessary licenses. I must admit I
would also have problems to motivate myself for such a project.

When you look to other languages: There are often commercial interests
behind ports to Windows (e.g. ActiveState). I don't think the O'Caml
market is ready for such a thing.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[John Goerzen]

On Tue, Apr 13, 2004 at 09:57:09PM +0200, Christophe TROESTLER wrote:
> Sven should say better what is possible but my idea is that GODI and
> the Debian package system talk to each other.  So there should NOT be
> two Pervasives modules.  If the GODI (Debian) package is installed,
> the other Ocaml packages should make use of it.  If GODI wants to
> recompile some Debian Package, either (1) delegate the task to the
> Debian package manager (say there is a new version of the package
> available or else use dpkg to download and build from source) or (2)
> consider Debian packages as "on hold" and refuse the GODI operation.

I think the recompilation option is a perilous one; there are many
different packaging systems (dpkg, rpm, AIX, solaris, etc.) and
supporting them all, correctly, would be complex.  It may be just as
easy to put it somewhere in /usr/local that occurs first on the OCaml
search path.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[Jacques GARRIGUE]

From: Christophe TROESTLER <Christophe.Troestler@umh.ac.be>
> 
> Sven should say better what is possible but my idea is that GODI and
> the Debian package system talk to each other.  So there should NOT be
> two Pervasives modules.  If the GODI (Debian) package is installed,
> the other Ocaml packages should make use of it.  If GODI wants to
> recompile some Debian Package, either (1) delegate the task to the
> Debian package manager (say there is a new version of the package
> available or else use dpkg to download and build from source) or (2)
> consider Debian packages as "on hold" and refuse the GODI operation.
> 
> That requires a correspondance between package names on the two sides
> -- thus some dialog with the Debian maintainers -- but it is a good
> idea not to have different names for a given package anyway...

What you are saying amounts more or less to basing GODI on the debian
packaging system. Interfacing between packaging systems is going to be
just as difficult as interfacing between GC's: almost impossible if
you are not a guru of the two systems. And then why not do it for all
other packaging systems around (rpm, portage, freebsd packages...)

I think that it would be much more reasonable to have a packaging
system controlling all of ocaml, but only ocaml. This includes
compiling and installing from CVS, because those are the cases when a
recompiling package system is really necessary, and because many
developpers (and potential contributors to GODI) are using CVS
versions of ocaml.

The interface to external packaging systems could be just minimal:
external packaging systems handle non-ocaml dependencies, and issue
GODI commands for installing/uninstalling the package. Since GODI may
have to recompile things later, having an external packaging system
trying to track GODI files would be a pain, and probably a useless
one.

This also makes me think that godi should not handle non-ocaml
packages (like gdbm currently), because this is only going to generate
frictions with other packaging systems.

Last, we need support for windows, and for binary packages. I don't
know who is going to do it, but these are requirements to make godi
the standard.

And of course, lots of maintenance needed. I must be using exotic
architectures, but godi never worked properly on any of my machines
(solaris8/x86  and freebsd5.2), at least without lots of tweaking.
Making it work properly on a lot of platforms will require a huge
amount of work, and cannot be handled by a single developper.
Which creates another problem: GODI is based on C tools and BSD
makefiles. I'm not sure this is the favorite kind of things ocaml
programmers would maintain.

By the way I'm ready to help, if there is some understandable way to
do so.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI vs. Ocamake

[Brandon J. Van Every]

Jacques GARRIGUE wrote:
>
> I think that it would be much more reasonable to have a packaging
> system controlling all of ocaml, but only ocaml.

Reasonable, but foreign libraries aren't going away.  Not until OCaml
has everything under its own roof, and that will be quite some time.  A
proper OCaml package system will have deal with foreign libraries
somehow, even if the support is half-assed.

> Last, we need support for windows, and for binary packages.

I hope you only mean "last" as a way of listing things needed, i.e.
first, second, last.  If you mean these are your last priorities, I'd
never contribute to such a project.  I'm bloody fed up with GNU Make on
Windows for reasons I won't belabor here.

> Which creates another problem: GODI is based on C tools and BSD
> makefiles. I'm not sure this is the favorite kind of things ocaml
> programmers would maintain.

An OCaml-centric packaging tool should be written in OCaml.  Nobody's
switching to OCaml out of their love for C and C++!  If that means GODI
is unsuitable to task, that is unfortunate but reality is reality.
Other languages such as Python and Java have spawned their own build
tools.  There's a lot more to the world than Make.

So how is OCamake?  Is it not the obvious place to begin?


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI

[Brandon J. Van Every]

Gerd Stolpmann wrote:
>
> The other question is which compiler is used as backend. I can imagine
> to call MSVC, but there are limitations because of GODI's
> organization:
> MSVC costs money. Don't forget that GODI is for free, and there isn't
> any way to collect money for the necessary licenses. I must admit I
> would also have problems to motivate myself for such a project.

I am not interested in Free Software as in 'free beer', I am interested
as in 'free speech'.  And FWIW I'm on the MIT/BSD side of the debate.
If you're going to give it away, give it away completely.  If it's too
valuable to give away, don't.  I want my OCaml code to be commercially
useful for game development.  I'm only interested in Open Source as a
business model - where is the *profit* of the software commons?  I
think, it is in fixing stupid things that are a PITA for everyone over
and over again.  Like package management for instance.  I could care
less about FSF style idealism.  I want things to work on the platform
I'm stuck with for the forseeable future.

> When you look to other languages: There are often commercial interests
> behind ports to Windows (e.g. ActiveState). I don't think the O'Caml
> market is ready for such a thing.

Things don't get ready by waiting around for others to act.  People who
want to get it ready, are what get it ready.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[james woodyatt]

On 13 Apr 2004, at 22:35, Brandon J. Van Every wrote:
> Gerd Stolpmann wrote:
>>
>> When you look to other languages: There are often commercial interests
>> behind ports to Windows (e.g. ActiveState). I don't think the O'Caml
>> market is ready for such a thing.
>
> Things don't get ready by waiting around for others to act.  People who
> want to get it ready, are what get it ready.

Yeah well— I feel your pain.  I'd be very grateful if some kind 
volunteer were to step up and make Findlib or Ocaml (preferably both) 
aware of the Mac OS X bundles and frameworks model.  It's on the long 
list of things I'd be willing to do myself if I weren't so busy with 
more things that are more important to me.

Of course, the fact that doing it would mean forking somebody else's 
code does tend dampen my enthusiasm for the project...


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[Kenneth Knowles]

On Tue, Apr 13, 2004 at 10:35:59PM -0700, Brandon J. Van Every wrote:
> I am not interested in Free Software as in 'free beer', I am interested
> as in 'free speech'.  And FWIW I'm on the MIT/BSD side of the debate.
> If you're going to give it away, give it away completely.  If it's too
> valuable to give away, don't.  I want my OCaml code to be commercially
> useful for game development.  I'm only interested in Open Source as a
> business model - where is the *profit* of the software commons?  I
> think, it is in fixing stupid things that are a PITA for everyone over
> and over again.  Like package management for instance.  I could care
> less about FSF style idealism.  I want things to work on the platform
> I'm stuck with for the forseeable future.

The primary motivation for much free software *is* FSF-style idealism.  It is
not reasonable to expect to reap the benefits of this idealism while
contradicting its values.

All I hear is "gimme, gimme" when non-free software developers ask for MIT/BSD
and LGPL licenses.  I am a non-free software developer myself, so don't think I
don't see from that perspective.

> > When you look to other languages: There are often commercial interests
> > behind ports to Windows (e.g. ActiveState). I don't think the O'Caml
> > market is ready for such a thing.
> 
> Things don't get ready by waiting around for others to act.  People who
> want to get it ready, are what get it ready.

Well said.  It is telling that there is noone who wants to get it ready,
considering Windows' market share.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[Kenneth Knowles]

On Tue, Apr 13, 2004 at 11:00:06PM -0700, james woodyatt wrote:
> Yeah well? I feel your pain.  I'd be very grateful if some kind 
> volunteer were to step up and make Findlib or Ocaml (preferably both) 
> aware of the Mac OS X bundles and frameworks model.  It's on the long 
> list of things I'd be willing to do myself if I weren't so busy with 
> more things that are more important to me.
> 
> Of course, the fact that doing it would mean forking somebody else's 
> code does tend dampen my enthusiasm for the project...

I don't think you'd have to fork... Did Gerd say he wouldn't accept
contributions?  So far I've failed to pique the interest of the one OS X
developer I know.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Jacques GARRIGUE]

From: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
> Jacques GARRIGUE wrote:
> >
> > I think that it would be much more reasonable to have a packaging
> > system controlling all of ocaml, but only ocaml.
> 
> Reasonable, but foreign libraries aren't going away.  Not until OCaml
> has everything under its own roof, and that will be quite some time.  A
> proper OCaml package system will have deal with foreign libraries
> somehow, even if the support is half-assed.

What I meant was just that the packaging system should not try to
replace the native package system of the platform for non-ocaml
stuff. But it must of course handle stub libraries, and even
dependencies on external libraries. GODI makes some nice attempt at
that, through configuration pseudo-packages, that let it know how some
external libraries should be used.

> > Last, we need support for windows, and for binary packages.
> 
> I hope you only mean "last" as a way of listing things needed, i.e.

This just happened to be the end of my mail, when I was writing it,
but then I added more stuff, and last was invalidated.
By the way, the full paragraph was clear enough:

  Last, we need support for windows, and for binary packages. I don't
  know who is going to do it, but these are requirements to make godi
  the standard.

> So how is OCamake?  Is it not the obvious place to begin?

OCamake is a useful tool, but its goal is simplifying the building of
individual programs or libraries. It has no support for packaging or
recompilation that I know of. I believe the two problems are
orthogonal.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles]

On Tue, Apr 13, 2004 at 10:14:53PM -0700, Brandon J. Van Every wrote:
> An OCaml-centric packaging tool should be written in OCaml.  Nobody's
> switching to OCaml out of their love for C and C++!  If that means GODI
> is unsuitable to task, that is unfortunate but reality is reality.
> Other languages such as Python and Java have spawned their own build
> tools.  There's a lot more to the world than Make.
> 
> So how is OCamake?  Is it not the obvious place to begin?

First:
Due to the great variety of operating systems out there, I think autoconf, etc
has it exactly right - separating one stage of the build to "adjust" to the
system you are building on is a Good Idea.  

Second:
I like the idea of OCamake... I wrote ocamlconf with similar things in mind (a
strictly ocaml-centric build tool), but with only the intent of replacing the
"configure" portion of a build.  A combination with OCamake might prove fruitful
for an all-ocaml build process.

Third:
Porting to Windows is a pain in the ass without cygwin.  With just
autoconf/automake, one can make a C program that installs and runs (yes, the
build process is part of the install for _most_ OS's) on almost any unix, and
cygwin.  Making a special exception for Windows without cygwin isn't at the top
of my TODO list, particularly since there's not even a pretense of meeting me
halfway (for example, by adopting POSIX and providing a bourne shell).

I want to supply the same thing for ocaml through ocamlconf.  All it requires
(to my knowledge) is ocaml, a bourne shell, and make (not restricted to gnu
make, I think).

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] BSD vs. GPL

[Brandon J. Van Every]

Kenneth Knowles wrote:
> Brandon J. Van Every wrote:
> > I am not interested in Free Software as in 'free beer', I
> > am interested
> > as in 'free speech'.  And FWIW I'm on the MIT/BSD side of
> > the debate.
>
> The primary motivation for much free software *is* FSF-style
> idealism.

True.  And I can't stand those people.

> It is
> not reasonable to expect to reap the benefits of this idealism while
> contradicting its values.

Nonsense.  Read again: "I am on the MIT/BSD side of the debate," as are
MANY open source projects.

> All I hear is "gimme, gimme" when non-free software
> developers ask for MIT/BSD
> and LGPL licenses.  I am a non-free software developer
> myself, so don't think I don't see from that perspective.

Idealists think the programmer is supposed to contribute massive amounts
of time and money for the betterment of all mankind.  (Remember, time ==
money.)  Pragmatists think the individual should contribute very little,
and that the value of Open Source should come from the collective
accumulation of very small contributions.  To a pragmatist, this is
economically rational.  We think the idealists are extremely silly
people with way too much time (and hence money) on their hands.  Views
change a lot when you're blowing your own money, not someone else's.

> > > When you look to other languages: There are often
> > > commercial interests
> > > behind ports to Windows (e.g. ActiveState). I don't think
> > > the O'Caml market is ready for such a thing.
> >
> > Things don't get ready by waiting around for others to act.
> > People who want to get it ready, are what get it ready.
>
> Well said.  It is telling that there is noone who wants to
> get it ready, considering Windows' market share.

Get what ready, OCaml package managers that work on Windows?  I
certainly want to get it ready, but it's a question of rational labor
contributions.

A far better strategy for me, for now, is to put my attention into The
Nebula Device.  It has a very nice Windows build procedure that has
nothing to do with OCaml, and it doesn't employ a bunch of open source
dependencies needing package management.  Even if it did, it's got
plenty of Windows-centric slave labor behind it.  Simply put, for 3D
game stuff, it is a more effective organizational body than anything the
OCaml world has to offer.  (BSD project BTW. ;-)

Adding OCaml to Nebula is a modest project.  My pressing need for OCaml
package management only comes *after* undertaking that project.  And who
knows, maybe I'll mostly be writing original code than bothering with
anyone else's crufty code.  I don't know where future game projects will
lead me.

So, if nobody else is interested in OCaml package management on Windows
for now, don't be surprised that I don't volunteer to be the first upon
the sacrificial altar.  I only do things on an as-needed basis.  I'd be
happy to help if others have similar needs though.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Nicolas Cannasse]

> > Which creates another problem: GODI is based on C tools and BSD
> > makefiles. I'm not sure this is the favorite kind of things ocaml
> > programmers would maintain.
>
> An OCaml-centric packaging tool should be written in OCaml.  Nobody's
> switching to OCaml out of their love for C and C++!  If that means GODI
> is unsuitable to task, that is unfortunate but reality is reality.
> Other languages such as Python and Java have spawned their own build
> tools.  There's a lot more to the world than Make.
>
> So how is OCamake?  Is it not the obvious place to begin?

As Jacques Garrigue answered, OCamake have been designed as a compilation
tool, and is actually well suited for the Windows world since it doesn't
rely on any 3rd party tools (apart from ocaml official distribution ones :
ocamlc, ocamlopt and ocamldep) - it still work very well on Unixes. OCamake
does not handle right now the building of C stubs, so it's only building
pure-ocaml projects. But when we jump into the C side, you need a lot of
extra configuration :
    - on windows things here are quite easy, but if you want to support MSVC
+ Mingw ( cygwin being optional IMHO ) it will takes time
    - unix world is very different from windows one, and is already filled
with autoconf like tools that are checking a bunch of things in order to be
able to compile

The idea to enable OCamake to be highly configurable would be to have an
"Ocamake Library" and then you'll write a file "makefile.ml" using that
library in order to ease compilation and ensure you're writing a
system-idependant makefile. Then you'll run ocamake (the tool) that will
dynamicly load the makefile.ml in order to execute it.

This - the system-idenpendant build of C stubs - will require quite a lot of
work on Ocamake, and will require the library owners to write their
makefile.ml compilation files. But in the end we would get a
system-idependant build tool, that can later be used by a package manager in
order to (re)compile a given package (the inter-package dependencies being
handled at the package-manager level). Sadly, a lot of OCaml users are
unixes ones that doesn't care at all about support of systems such as
Windows or MacOs ( and they're sometimes true : when you're writing bindings
to a unix-only library, who cares about your bindings being compilable on
win32 ? ). Theses users are currently happy enough using autoconf / make
since it doesn't require additionnal learning. GODI+findlib are made with
the same thinking : they have not been designed to be SI since they're
basicly (very) smart scripts relying on a lot of other unix tools.

Other way of thinking is : what do we need in order to get binary-only
distributions ? OCaml have a bytecode interpreter, so why we can't release
libraries simply as a big CMA ( and some CMI's ). Answer : because the
bytecode binary format is very strict, and not suited for this kind of usage
(adding a function in the interface of a sub library needs to recompile all
top librairies ). Maybe a more flexible bytecode format would help the
community to build a good packaging tool without having to care about all
theses compilation issues. (of course people would still need to compile for
native code, but there is also here other ways such as providing a
marchalled typed-AST as a binary "reading for input to ocamlopt").

Regards,
Nicolas Cannasse
www.motion-twin.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[Matt Gushee]

On Wed, Apr 14, 2004 at 12:38:08AM -0700, Brandon J. Van Every wrote:
> 
> > All I hear is "gimme, gimme" when non-free software
> > developers ask for MIT/BSD
> > and LGPL licenses.  I am a non-free software developer
> > myself, so don't think I don't see from that perspective.
> 
> Idealists think the programmer is supposed to contribute massive amounts
> of time and money for the betterment of all mankind.

I'm not sure which idealists you're referring to ... but assuming you
mean the FSF itself and RMS, I have to ask:

Have you actually listened to (or read) what Stallman says on the
subject? Yes, he does believe that Free Software is good for all
humankind. But I think the above statement grossly misrepresents the
GNU ideology. Stallman has stated on numerous occasions that people
should be able to make money by developing and selling software; what
they should not be able to do is to accumulate wealth simply by
controlling intellectual property.

Now, it is of course debatable how well the GNU model works in practice.
Certainly there are few examples of business success based on GPLed
software. But it's still early in the game.

We don't have to agree with Stallman's philosophy, but I think we must
acknowledge his and the FSF's contributions to what we now know as open
source. Without the trail blazed by the FSF there would very likely be
no Linux, no Apache ... and no open source OCaml.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[Kenneth Knowles]

On Wed, Apr 14, 2004 at 12:38:08AM -0700, Brandon J. Van Every wrote:
> > The primary motivation for much free software *is* FSF-style
> > idealism.
> 
> True.  And I can't stand those people.

Right, but you shouldn't be surprised... in fact you should *expect* them to
license things under GPL and LGPL licenses, since those are the licenses which
defend their principles.  To desire otherwise is to hope to take advantage of
their idealism while violating said principles.  This is my entire point.
 
> Idealists think the programmer is supposed to contribute massive amounts
> of time and money for the betterment of all mankind.

No, idealists think programmers should be paid to write free software (and they
frequently are) 

> Get what ready, OCaml package managers that work on Windows?

Yes.  Exactly.  There is no OCaml package manager on Windows because nobody
wants it enough to support it through time or money (even collectively, as the
commons might).  The economics are plain.  Advanced package management is not
particularly critical, however.  After countless years of windows, 2 years of
Slackware, and about a year of Gentoo, I'd say it only saves maybe an hour or
two per month.  (I'm using Windows and Slackware as examples of systems with no
significant automated package management: autoconf == wizard installer)

> (BSD project BTW. ;-)

I'm actually happy to here of an open source project for the platform.  I'm
fairly happy in my linux/ocaml world without mass adoption, but I think Windows
will suck less as a development and desktop platform as more free software
becomes available.

It would be nice if it shipped with cygwin - it would be even nicer if MS wrote
the compatability layer so it would play real nice.  :-)

> Adding OCaml to Nebula is a modest project.  My pressing need for OCaml
> package management only comes *after* undertaking that project.  And who
> knows, maybe I'll mostly be writing original code than bothering with
> anyone else's crufty code.  I don't know where future game projects will
> lead me.

Looking at the nebula device page, I notice .Net languages are supported, so you
might take a look at Nemerle (recently linked) and F# (Microsoft's experimental
ocaml implementation for .Net).

The INRIA ocaml is much, much nicer than F#, though.

> ... don't be surprised that I don't volunteer to be the first upon
> the sacrificial altar.

Thanks for the laugh :-)

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[Wolfgang Müller]

On Wednesday 14 April 2004 10:32, Matt Gushee wrote:
> > Idealists think the programmer is supposed to contribute massive amounts
> > of time and money for the betterment of all mankind.

Oh, what I think, is that as a University person giving stuff back to the 
taxpayer for free is not so much of a bad thing. Same for the CS students who 
make up the core of KDE, for example.

Cheers,
Wolfgang

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[james woodyatt]

On 13 Apr 2004, at 23:21, Kenneth Knowles wrote:
> On Tue, Apr 13, 2004 at 11:00:06PM -0700, james woodyatt wrote:
>> Yeah well? I feel your pain.  I'd be very grateful if some kind
>> volunteer were to step up and make Findlib or Ocaml (preferably both)
>> aware of the Mac OS X bundles and frameworks model.  It's on the long
>> list of things I'd be willing to do myself if I weren't so busy with
>> more things that are more important to me.
>>
>> Of course, the fact that doing it would mean forking somebody else's
>> code does tend dampen my enthusiasm for the project...
>
> I don't think you'd have to fork... Did Gerd say he wouldn't accept
> contributions?  So far I've failed to pique the interest of the one OS 
> X
> developer I know.

I just went off and looked at findlib more carefully.  With v1.0 even 
more than before, I don't think it would make sense to adapt it to 
working with Mac OS X bundles and frameworks.  I now believe the right 
thing to do here is to develop a completely separate command driver for 
Mac OS X that handles this problem.  You probably want a support 
library too— so you can communicate effectively with Cocoa and Carbon 
applications via .plist files and such.

There are two related problems here and I want solutions to both 
actually: 1) deploy dynamically linked libraries (C wrappers and 
bytecode) inside Mac OS X frameworks/bundles; and 2) a nice Mac OS 
X-friendly notion of Ocaml SDK distributions.  I can probably get 2) by 
working with Gerd to put the right defaults in place for Findlib and 
GODI on Mac OS X.  Getting 1), on the other hand, I think will mean 
going off into the weeds alone.

Big piles of work.  It's going to be a long time before I get around to 
doing it.  I got a day job, and I'm working on a whole other set of 
problems in my spare time.  While I'm making wishes upon the stars, how 
qool would it be to have XCode integration?  Mmmmm.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI

[skaller]

On Wed, 2004-04-14 at 10:34, Gerd Stolpmann wrote:

> The other question is which compiler is used as backend. I can imagine
> to call MSVC, but there are limitations because of GODI's organization:
> MSVC costs money. 

LCC is free and runs on windows native platform.
Whether it's any good i cant say.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Wed, 2004-04-14 at 17:50, Nicolas Cannasse wrote:

> The idea to enable OCamake to be highly configurable would be to have an
> "Ocamake Library" and then you'll write a file "makefile.ml" using that
> library in order to ease compilation and ensure you're writing a
> system-idependant makefile. Then you'll run ocamake (the tool) that will
> dynamicly load the makefile.ml in order to execute it.

Yes. I agree with this model. The first order of the day
is to throw out make and replace it with a general purpose
language + a library which make writing program building
programs easier.

To put this another way, I regard 'autoconf' as one
of the worst evils around. The correct solution is
a combination of Standards and a full scale programming
language -- not hacked up special purpose tools which
are so grossly inadequate they need yet *another*
tool to configure them .. and still don't work right.

For this reason the Felix build processes uses
a high power general purpose language, namely Python.

The package manager is a high power general purpose
programming language, namely Python.

The two processes are one and the same and integrated
with a library of support functions and some lightweight
architecture, namely Interscript, my literate programming,
build, and package management tool .. also written
entirely in Python.

So in theory, it can build and install anything on
any operating system, provided only that Python
and a reasonable subset of the standard distribution's
libraries is installed.

Had I commenced the interscript project more recently,
I might have chosen the bytecode interpreter of Ocaml
instead of Python.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Wed, 2004-04-14 at 17:50, Nicolas Cannasse wrote:

> Other way of thinking is : what do we need in order to get binary-only
> distributions ? OCaml have a bytecode interpreter, so why we can't release
> libraries simply as a big CMA ( and some CMI's ). Answer : because the
> bytecode binary format is very strict, and not suited for this kind of usage
> (adding a function in the interface of a sub library needs to recompile all
> top librairies ). 

Who cares? 

I've worked on code where turnaround for compilations were:

1970's -- overnight (Fortran)
1980's -- 2-3 hours (Cobol/Pl1)
1990's -- 20-40 minutes (C/C++)
2000's -- 10-60 seconds (Ocaml)

and that's working on large Mainframe (Cyber 70),
Small mainframe (Facom), Medium Sun box,
and 500MHz Pentium III, respectively.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI

[Gerd Stolpmann]

Am Mit, 2004-04-14 um 04.52 schrieb Jacques GARRIGUE:
> From: Christophe TROESTLER <Christophe.Troestler@umh.ac.be>
> > 
> > Sven should say better what is possible but my idea is that GODI and
> > the Debian package system talk to each other.  So there should NOT be
> > two Pervasives modules.  If the GODI (Debian) package is installed,
> > the other Ocaml packages should make use of it.  If GODI wants to
> > recompile some Debian Package, either (1) delegate the task to the
> > Debian package manager (say there is a new version of the package
> > available or else use dpkg to download and build from source) or (2)
> > consider Debian packages as "on hold" and refuse the GODI operation.
> > 
> > That requires a correspondance between package names on the two sides
> > -- thus some dialog with the Debian maintainers -- but it is a good
> > idea not to have different names for a given package anyway...
> 
> What you are saying amounts more or less to basing GODI on the debian
> packaging system. Interfacing between packaging systems is going to be
> just as difficult as interfacing between GC's: almost impossible if
> you are not a guru of the two systems. And then why not do it for all
> other packaging systems around (rpm, portage, freebsd packages...)
> 
> I think that it would be much more reasonable to have a packaging
> system controlling all of ocaml, but only ocaml. This includes
> compiling and installing from CVS, because those are the cases when a
> recompiling package system is really necessary, and because many
> developpers (and potential contributors to GODI) are using CVS
> versions of ocaml.

They would really benefit from GODi because all the recompilations are
handled automatically. My idea to handle this is to substitute the
O'Caml core packages by fake packages, only to satisfy the dependencies.
But I think this is an option for advanced users only, there are much
more things that can go wrong.

> The interface to external packaging systems could be just minimal:
> external packaging systems handle non-ocaml dependencies, and issue
> GODI commands for installing/uninstalling the package. Since GODI may
> have to recompile things later, having an external packaging system
> trying to track GODI files would be a pain, and probably a useless
> one.
> 
> This also makes me think that godi should not handle non-ocaml
> packages (like gdbm currently), because this is only going to generate
> frictions with other packaging systems.

In principle, you are right here. The (few) non-ocaml packages exist for
user's convenience, especially on systems where they are not available
from the OS. They are optional anyway.

> Last, we need support for windows, and for binary packages. I don't
> know who is going to do it, but these are requirements to make godi
> the standard.

The development version works for Cygwin already. Well, I know, this is
not Windows, but one faces already typical Windows problems. For
example, the locking problem. It is essential for GODI that it can
update itself, and unfortunately, Windows does not allow it that a
running program replaces itself (unlike Unix). So a workaround was
needed. I found it, and guess, who helped? It was /bin/sh and the "exec"
call, two imports from the Unix world. Thanks these clever tools one
needs not to reboot after updating GODI.

This makes me think that a "pure" Windows port would be harder thank we
can imagine now. It will be impossible to make it "failsafe": Just cd to
a directory managed by GODI, and you break every update (because the
directory is locked, and cannot be removed). So I think a source
distribution would be too difficult, as it is hard to avoid to get into
situations where things fail because of the mentioned reasons, and to
recover from such failures in a clean way. In the Windows world,
building software is a task that should only happen in controlled
environments (without dumb users). So the only alternative is a binary
distribution for Windows (it is much easier to recover from failures).

> And of course, lots of maintenance needed. I must be using exotic
> architectures, but godi never worked properly on any of my machines
> (solaris8/x86  and freebsd5.2), at least without lots of tweaking.
> Making it work properly on a lot of platforms will require a huge
> amount of work, and cannot be handled by a single developper.

Well, I invested a lot of time to make it work under Solaris 8/Sparc,
and freebsd-4.8. On the latter OS it works nicely out-of-the-box, but I
had to disable POSIX threads (not my fault, freebsd's thread library is
simply not good enough). Solaris (and probably all commerical Unixes) is
a challenge, as the success depends on how properly add-on software (gcc
etc.) is installed.

My experience is not that a "huge amount of work" is needed to make GODI
work on new platforms (one mostly tweaks a number of settings), but a
huge amount of patience, simply because building software takes long.

> Which creates another problem: GODI is based on C tools and BSD
> makefiles. I'm not sure this is the favorite kind of things ocaml
> programmers would maintain.

It isn't my favourite thing, too, but when you search tools that are
powerful and flexible at the same time, the combination of C tools and
scripts is simply a good choice. I think for people who only want to
create packages, this isn't a burden, because packaging is a quite
descriptive task. The maintainance of the GODI core is the problem.

There is work underway rewriting some of the tools in O'Caml. For
example, there is already a parser for BSD Makefiles. Having our own
"make" utility is very interesting, because one can extend the
functionality (e.g. macros, or the integration of O'Caml scripts as
"make" actions).

Of course, these rewrites also simplify the Windows port.
 
> By the way I'm ready to help, if there is some understandable way to
> do so.

You can join the GODI mailing list
(https://gps.dynxs.de/mailman/listinfo). There is now also a bug
tracking system (https://gps.dynxs.de/tracker).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI vs. Ocamake

[Gerd Stolpmann]

Am Mit, 2004-04-14 um 07.14 schrieb Brandon J. Van Every:
> Jacques GARRIGUE wrote:
> >
> > I think that it would be much more reasonable to have a packaging
> > system controlling all of ocaml, but only ocaml.
> 
> Reasonable, but foreign libraries aren't going away.  Not until OCaml
> has everything under its own roof, and that will be quite some time.  A
> proper OCaml package system will have deal with foreign libraries
> somehow, even if the support is half-assed.
> 
> > Last, we need support for windows, and for binary packages.
> 
> I hope you only mean "last" as a way of listing things needed, i.e.
> first, second, last.  If you mean these are your last priorities, I'd
> never contribute to such a project.  I'm bloody fed up with GNU Make on
> Windows for reasons I won't belabor here.
> 
> > Which creates another problem: GODI is based on C tools and BSD
> > makefiles. I'm not sure this is the favorite kind of things ocaml
> > programmers would maintain.
> 
> An OCaml-centric packaging tool should be written in OCaml.  Nobody's
> switching to OCaml out of their love for C and C++!  If that means GODI
> is unsuitable to task, that is unfortunate but reality is reality.
> Other languages such as Python and Java have spawned their own build
> tools.  There's a lot more to the world than Make.

This is off-topic. GODI does not use Makefiles to build software, it
just calls whatever build tool is used by the upstream author (well,
usually Makefiles, but other tools like Ocamake are possible). It uses
Makefiles to control the overall build process.

So I'am sorry, Ocamake isn't an alternative for that. The whole debate
"GODI vs. Ocamake" does not make any sense for me.

Gerd

> So how is OCamake?  Is it not the obvious place to begin?

-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[John Goerzen]

On Wed, Apr 14, 2004 at 12:38:08AM -0700, Brandon J. Van Every wrote:
> Kenneth Knowles wrote:
> > Brandon J. Van Every wrote:
> > > I am not interested in Free Software as in 'free beer', I
> > > am interested
> > > as in 'free speech'.  And FWIW I'm on the MIT/BSD side of
> > > the debate.
> >
> > The primary motivation for much free software *is* FSF-style
> > idealism.
> 
> True.  And I can't stand those people.

Ah, so you wish that everyone that released Free software did so under a
license that allow you to personally profit from it by including it in
your vaporware games, while simultaneously reducing the rights of the
people you give it to, compared to what the FSF-style authors gave out?

I have no problem using BSD/MIT-licensed software.  The software *I*
write is *all* under the GPL, because I want to guarantee everyone the
same rights to use, modify, and copy it, regardless of where or from
whom they received it.

If somebody wants to use my code in a commercial project, they are of
course welcome to negotiate a different license for that with me.  I'm
not going to let them use it for free unless they comply with the GPL.

It seems that you want to have your cake and eat it to.

> Idealists think the programmer is supposed to contribute massive amounts
> of time and money for the betterment of all mankind.  (Remember, time ==
> money.)  Pragmatists think the individual should contribute very little,

You have managed to probably mischaracterize both positions to such an
extent that your argument is worhless.  To read about what you call the
"idealists", please visit www.fsf.org/philosophy.  As a hint,
development methodology has nothing to do with it; freedoms do.

> So, if nobody else is interested in OCaml package management on Windows
> for now, don't be surprised that I don't volunteer to be the first upon
> the sacrificial altar.  I only do things on an as-needed basis.  I'd be
> happy to help if others have similar needs though.

If you're writing commercial code, what use do you have for OCaml
package management anyway?  You'll just link all the packages in at
build time.

Package management is only useful for people that compile things from
source.  (OK, *marginally* for people that load libraries dynamically)

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: ocamlconf on Cygwin (Re: [Caml-list] Re: GODI vs. Ocamake)

[Kenneth Knowles]

Thanks for the tip; I wasn't aware of this limitation on cygwin.  Your idea is
actually not that bad.  However, upon perusing my code I think it would be
fairly easy to remove all Str and Unix dependencies.  This is what I will do,
since I don't have a cygwin box to test on.

Kenn

On Wed, Apr 14, 2004 at 12:28:53PM +0100, Peter Jolly wrote:
> Kenneth Knowles wrote:
> >Porting to Windows is a pain in the ass without cygwin.  With just 
> >autoconf/automake, one can make a C program that installs and runs
> >(yes, the build process is part of the install for _most_ OS's) on
> >almost any unix, and cygwin.
> 
> You might be interested to know, then, that ocamlconf doesn't work "out
> of the box" on Cygwin - the configure script relies on dynamic loading,
> which is not supported in the Cygwin ocaml.  It probably works with the
> MinGW port under Cygwin, but that has other problems (no debugger, for
> one) that make it less useful for everyday work.
> 
> Might it be possible, for example, to add a special case where, if the
> invocation of ocaml fails, the configure script tries to generate a
> temporary custom toplevel with Unix and Str built in?  Ugly, I know, but
> nothing more elegant springs to mind...

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles]

On Wed, Apr 14, 2004 at 09:54:27PM +1000, skaller wrote:
> Yes. I agree with this model. The first order of the day
> is to throw out make and replace it with a general purpose
> language + a library which make writing program building
> programs easier.

I agree here that make is not the end-all of building.  However, make is 
a language (shell) + a library (make itself).  The real problem is the library
is not written in the same language, and that both the language and the library
suck.

Re-implementing for different languages is a good idea.
 
> To put this another way, I regard 'autoconf' as one
> of the worst evils around. The correct solution is
> a combination of Standards and a full scale programming
> language -- not hacked up special purpose tools which
> are so grossly inadequate they need yet *another*
> tool to configure them .. and still don't work right.

I disagree completely here.  Autoconf is NOT a bunch of hacked up tools trying
to fix each other, but rather a set of programming modules in a support library
like you describe (albeit in weird languages).  Even with a library to make
writing program-building programs easier, it is a very intelligent division of
modules:

(1)  Adjust to current system
(2)  Accept compile-time parameters
(3)  Build system
(4)  Install system
(5)  Package system
(*)  More; like unit tests etc.
 
Autoconf *does* represent these modules, for the language of "shell/make/m4,"
with a target language of C.  Both python and perl have similar module
divisions (from my external users standpoint of having built modules for both).

Basically, what you should not assert is that "make" is even *supposed* to
perform any of the above except (3), or you are setting up a straw man.

It is nicer when the language used in the build process is more powerful/safe
than shell/make/m4.  It is also nice for it to be the same as the target
language, so no additional dependencies are introduced.

You may have a beef with GNU's choices of implementation languages.  Well I do
too, but I'm not surprised.  They also have a love affair with C, even for
high-level stuff.  I'm pretty sure we both agree that implementing the above
modules in OCaml, for OCaml, is the best thing to do. 

OCamlConf kind-of sort-of completes (1) and (2) and then outputs a makefile that
handles (3) through (5) pretty well.  I would be ecstatic to have (3) through
(5) written in ocaml, but haven't the time - thus my hope of possibly
integrating ocamake or similar thing for (3).  (4) and (5) are pretty trivial to
do by hand. 

Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
(1) and (3) all at once.

If ocamlconf+ocamake became "ocamlbuild" then I'd still keep the userland steps
of: 
1. Accept compile-time options and check system compatability.
2. Build desired items
3. Install desired items

> [Interscript is a great python build tool]

To your benefit, I assume that within Interscript, there is modularization, and
it probably falls along similar lines.  Indeed, this sounds like exactly a
wonderful solution for python, but it is best for build and target language to
be the same - firstly not to introduce dependencies and secondly so developers
are immediately comfortable.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[David Brown]

On Wed, Apr 14, 2004 at 01:40:28AM -0700, Kenneth Knowles wrote:

> Advanced package management is not particularly critical, however.
> After countless years of windows, 2 years of Slackware, and about a
> year of Gentoo, I'd say it only saves maybe an hour or two per month.
> (I'm using Windows and Slackware as examples of systems with no
> significant automated package management: autoconf == wizard
> installer)

Interesting argument.  It would be hard to describe how much time good
package management saves me, since without it, there would just be many
things I wouldn't do.  If I were to try and upgrade things as frequently
as I do now, I would probably spend 5-10 hours a week just doing the
upgrades.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] recompiling bytecode

[Brandon J. Van Every]

skaller wrote:
> On Wed, 2004-04-14 at 17:50, Nicolas Cannasse wrote:
>
> > Other way of thinking is : what do we need in order to get
> > binary-only
> > distributions ? OCaml have a bytecode interpreter, so why
> > we can't release
> > libraries simply as a big CMA ( and some CMI's ). Answer :
> > because the
> > bytecode binary format is very strict, and not suited for
> > this kind of usage
> > (adding a function in the interface of a sub library needs
> > to recompile all
> > top librairies ). > [re: having to recompile everything]
>
> Who cares?
>
> I've worked on code where turnaround for compilations were:
>
> 1970's -- overnight (Fortran)
> 1980's -- 2-3 hours (Cobol/Pl1)
> 1990's -- 20-40 minutes (C/C++)
> 2000's -- 10-60 seconds (Ocaml)

Because you are not compiling programs large enough and often enough for
this to become sheer hell?  I've read many a postmortem in GameDeveloper
magazine where excessive compile times are a major drain on
productivity.  Anecdotally, I've met too many happy Python programmers
to poo pooh the evasion of compile time.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] benefit of package management

[Brandon J. Van Every]

David Brown wrote:
> Kenneth Knowles wrote:
>
> > Advanced package management is not particularly critical, however.
> > After countless years of windows, 2 years of Slackware, and about a
> > year of Gentoo, I'd say it only saves maybe an hour or two
> > per month.
> > (I'm using Windows and Slackware as examples of systems with no
> > significant automated package management: autoconf == wizard
> > installer)
>
> Interesting argument.  It would be hard to describe how much time good
> package management saves me, since without it, there would
> just be many
> things I wouldn't do.  If I were to try and upgrade things as
> frequently
> as I do now, I would probably spend 5-10 hours a week just doing the
> upgrades.

Agreed.  For instance, I just blew off doing anything with OCamlSDL
because there are too many underlying libraries that don't compile
terribly well on Windows.  Using Nebula will be more work up front
because it has no OCaml support, but since adding that support is my
strategic objective anyways, I figure I'll just roll up my sleeves and
get on with it.

I think package management is an infrastructure, deployment, and
language growth argument.  Python, for instance, has abundant packaged
libraries and hence a much better growth trajectory than OCaml.  You,
the converted, may not save a lot of time with package management,
because you know your needs and they aren't changing often.  For someone
exploring a language and making a decision to adopt it, the case use is
very different.  I wish I had a dollar for every open source project
I've downloaded and evaluated in the past 6 months; it would be a lot of
beer money and wouldn't remotely pay for the time spent.

Incidentally, if you're wondering what the consequences of eschewing an
off-the-shelf mentality are, look at the Lisp community.  They're dead
in the water, they're never going to convince anyone to adopt their
language(s) en masse.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] recompiling bytecode

[John Goerzen]

On Wed, Apr 14, 2004 at 11:21:01AM -0700, Brandon J. Van Every wrote:
> > 1990's -- 20-40 minutes (C/C++)
> > 2000's -- 10-60 seconds (Ocaml)
> 
> Because you are not compiling programs large enough and often enough for
> this to become sheer hell?  I've read many a postmortem in GameDeveloper
> magazine where excessive compile times are a major drain on
> productivity.  Anecdotally, I've met too many happy Python programmers
> to poo pooh the evasion of compile time.

As a pretty much happy Python programmer myself, as well as a
disgruntled Java programmer and an OCaml novice, let me point out that
you are not providing the whole picture here.

Python does not have a zero compile time.  Like OCaml, it has a small
compile time on modern equipment, but actually this is because its
compile phase uses precompiled bytecode for just about all libraries, so
all it really has to compile is the application -- and it does this as
the different modules or functions are first used, rather than up front
for everything.  It is quite possible for an application to begin
executing before it has completely compiled.  (In fact, it pretty much
has to, since "import" is a command that is executed at runtime.)

In fact, the main difference between Python's compilation and OCaml's
bytecode compilation is not how fast or what happens, but *when*.

If you don't believe me, run a Python program from a writable directory
and note the .pyc files that magically appear.

Therefore, it is possible to have a Python program that does not
actually produce a syntax error until the program has been running for
some time and executes a particular code path.

Now, you should be able to infer from this that there is a productivity
setback with Python because certain glaring errors are not caught until
runtime.  If your program is such that it takes several minutes or hours
of processing to be able to hit the critical section with errors, you
can appreciate that this is not necessarily a good thing.  (It *is*
possible to compile things to bytecode in advance in most cases with
Python, but this is not well supported for the average programmer)
There are also entire classes of errors that even a Python compile will
not catch that an OCaml compile will -- such as reversing the order of
arguments in a function call when each argument has a different type.

I like OCaml's typing system.  It's effective at preventing mistakes
without being the lumbering typing dinosaur that is Java.

I have found OCaml to compile quite quickly.  In one project, I compile
about two dozen source files -- including ocamllex and ocamlyacc files
-- to generate one library and one application.  That completes in less
than one second, and it has structural ineffencies (make, for one) that
handicap it from the outset.  I'd venture to say that the compile
process spends more time forking and invoking bash than actually
compiling code.  (Of course, this could be optimized should I feel the
need to.  Suffice it to say I'm not really worred about a 1-second build
time.)

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] recompiling bytecode

[Issac Trotts]

On Wed, Apr 14, 2004 at 01:54:00PM -0500, John Goerzen wrote:
> On Wed, Apr 14, 2004 at 11:21:01AM -0700, Brandon J. Van Every wrote:
[...] 
> Now, you should be able to infer from this that there is a productivity
> setback with Python because certain glaring errors are not caught until
> runtime.  If your program is such that it takes several minutes or hours
> of processing to be able to hit the critical section with errors, you
> can appreciate that this is not necessarily a good thing.  (It *is*
> possible to compile things to bytecode in advance in most cases with
> Python, but this is not well supported for the average programmer)
> There are also entire classes of errors that even a Python compile will
> not catch that an OCaml compile will -- such as reversing the order of
> arguments in a function call when each argument has a different type.

There is a program called pychecker that can find some type errors and
other bugs in Python programs.  It's handy.

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] recompiling bytecode

[Basile Starynkevitch]

On Wed, Apr 14, 2004 at 11:21:01AM -0700, Brandon J. Van Every wrote:
> skaller wrote:
> > On Wed, 2004-04-14 at 17:50, Nicolas Cannasse wrote:
> >
> > > Other way of thinking is : what do we need in order to get
> > > binary-only distributions ? [....]
> > >  [re: having to recompile everything]
> >
> > Who cares?
> >
> > I've worked on code where turnaround for compilations were:
> >
> > 1970's -- overnight (Fortran)
> > 1980's -- 2-3 hours (Cobol/Pl1)
> > 1990's -- 20-40 minutes (C/C++)
> > 2000's -- 10-60 seconds (Ocaml)
> 
> Because you are not compiling programs large enough and often enough for
> this to become sheer hell? 

Even if Ocaml compiles much faster that Gcc, compile time still counts
a bit. Consider for example the compile time of the compiler compiling
itself:

with ocaml: make world opt bootstrap is around 10 minutes
with gcc: make bootstrap is about an hour.

(the x86 machines I work on are at home 2Ghz, at work 1GHz).

And there is something more that compilation time: correctly handling
the package dependencies, which has been discussed a lot on this list
recently.

Actually, compilation times still count (but there are features in
Ocaml, notably its module system, which help a lot - compare Ocaml
module compilation to C++ template compilation for example).

Regards
-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - INRIA Rocquencourt
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[skaller]

On Thu, 2004-04-15 at 01:05, John Goerzen wrote:
> On Wed, Apr 14, 2004 at 12:38:08AM -0700, Brandon J. Van Every wrote:

> If somebody wants to use my code in a commercial project, they are of
> course welcome to negotiate a different license for that with me.  

If so much as ONE other person contributes to your
code in any way, including any GPL code you include
in your package, the code is no longer yours,
and you are not free to offer a commercial licence.
ALL the other contributors would have to agree first.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:

> Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
> (1) and (3) all at once.

Yeah? How would they handle Interscript sources?
What about Camlp4?

My system also contains *Felix* programs,
since it happens to be a compiler. How do these
make systems handle that?

What about my use of SWIG to generate wrappers?
That's another 'programming language' which needs
to know about what libraries are installed on your target
system.

By far the best way to handle this complexity is with
a SINGLE general purpose language.

I chose Python because it runs on more platforms
than make, autoconf, or just about any other weird tool.
[C itself would have been more universal .. but a too hard
to write]

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:

> 
> > [Interscript is a great python build tool]
> 
> To your benefit, I assume that within Interscript, there is modularization, and
> it probably falls along similar lines.  

There is modularisation, it is called 'packages',
'modules' and 'classes'. These are Python language constructions.

What the client does next is up to the client.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] recompiling bytecode

[skaller]

On Thu, 2004-04-15 at 04:21, Brandon J. Van Every wrote:
> skaller wrote:

> > Who cares?
> >
> > I've worked on code where turnaround for compilations were:
> >
> > 1970's -- overnight (Fortran)
> > 1980's -- 2-3 hours (Cobol/Pl1)
> > 1990's -- 20-40 minutes (C/C++)
> > 2000's -- 10-60 seconds (Ocaml)
> 
> Because you are not compiling programs large enough and often enough for
> this to become sheer hell?  

No, I recompile every 20 seconds when I'm fixing bugs.
True, my current project only has around 60 ml files.

I certainly HAVE worked on systems where compile time
was an issue. That is the point of the data above:
I know all about it.

My build system does have 'dependency analysis'.
Its a simple linear order. I find that is perfectly
acceptable. If I change the parser it's a small pain,
since it's at the head of the list :D

But there is very little choice. Ocamlopt requires
the linear ordering to transmit optimisation information
forward. So you can't just recompile modules based on
dependency on interfaces (as you can in C).

And I'm ecstatic! Ocaml is so fast!

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[John Goerzen]

On Thu, Apr 15, 2004 at 10:20:54AM +1000, skaller wrote:
> On Thu, 2004-04-15 at 01:05, John Goerzen wrote:
> > On Wed, Apr 14, 2004 at 12:38:08AM -0700, Brandon J. Van Every wrote:
> 
> > If somebody wants to use my code in a commercial project, they are of
> > course welcome to negotiate a different license for that with me.  
> 
> If so much as ONE other person contributes to your
> code in any way, including any GPL code you include
> in your package, the code is no longer yours,
> and you are not free to offer a commercial licence.
> ALL the other contributors would have to agree first.

That is no different between the GPL and the BSD; if someone wanted a
non-BSD license from me, I'd have the same restriction.  Of course, the
difference lies in that somebody wanting to close the source to a
BSD-licensed work already has permission to do so, so it'd be less
likely to find them asking me.

But you have exaggerated it somewhat.  The "one other person" is correct
but "in any way" is, AFAIK, not.  The contribution must be significant
enough to be copyrightable.  That means that if I send you a diff that
corrects "5 + 6" to "5 + 7", you don't have anything to worry about.

There are some extensive threads on this topic in the debian-legal
archives should you wish to google for them.

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles]

On Thu, Apr 15, 2004 at 11:05:12AM +1000, skaller wrote:
> On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:
> 
> > Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
> > (1) and (3) all at once.
> 
> Yeah? How would they handle Interscript sources?
> What about Camlp4?

I never said they were perfect.  I don't use them.  However, I don't know of
anything other than a custom-rolled Makefile that handles such things.  Are you
suggesting one?  If so, I'm very interested, and I may have missed it in your
previous messages.

> By far the best way to handle this complexity is with
> a SINGLE general purpose language.

I'm still convinced that writing one build tool to rule them all is a Bad Idea.
It is a fraction as much work to write a separate one for each language
(setup.py, Makefile.PL, autoconf, ocamlconf), and glue them together when needed
with a scripting language or Makefile.

Kenn 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[Kenneth Knowles]

On Wed, Apr 14, 2004 at 10:14:29AM -0700, David Brown wrote:
> On Wed, Apr 14, 2004 at 01:40:28AM -0700, Kenneth Knowles wrote:
> 
> > Advanced package management is not particularly critical, however.
> > After countless years of windows, 2 years of Slackware, and about a
> > year of Gentoo, I'd say it only saves maybe an hour or two per month.
> > (I'm using Windows and Slackware as examples of systems with no
> > significant automated package management: autoconf == wizard
> > installer)
> 
> Interesting argument.  It would be hard to describe how much time good
> package management saves me, since without it, there would just be many
> things I wouldn't do.  If I were to try and upgrade things as frequently
> as I do now, I would probably spend 5-10 hours a week just doing the
> upgrades.

I see your perspective, and share it, since I upgrade constantly.  However, I'm
guessing it is the ease of upgrading that causes this, not any critical need for
constant update.  So I don't think it is a sound premise to include all of this
time in the comparison.

This risks getting off topic unless I mention GODI, the OCaml package manager.
I use CVS versions of OCaml and many other libraries, so I don't use it.  As a
consequence, I can't use my system's package management either.  It just means I
don't get a new OCaml CVS very regularly, but this has little impact on my
development speed or pleasure.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Thu, 2004-04-15 at 16:34, Kenneth Knowles wrote:
> On Thu, Apr 15, 2004 at 11:05:12AM +1000, skaller wrote:

> I never said they were perfect.  I don't use them.  However, I don't know of
> anything other than a custom-rolled Makefile that handles such things.  Are you
> suggesting one?  If so, I'm very interested, and I may have missed it in your
> previous messages.

I'm suggesting a whole class of them: general purpose languages.
Here's a fragment from the Felix build script.
Who needs autoconf?

if "compiler" in options or "bytecode" in options:
  # invoke ocaml interface compiler
  OCAML_OBJDIR='src'
  try:
    xqt('ocamlopt.opt')
    OCAMLCC = 'ocamlopt.opt '
    OCAMLLEX = 'ocamllex.opt '
    OCAMLYACC = 'ocamlyacc '
    BYTECODE = 0
  except:
    try:
      xqt('ocamlopt')
      OCAMLCC = 'ocamlopt '
      OCAMLLEX = 'ocamllex '
      OCAMLYACC = 'ocamlyacc '
      BYTECODE = 0
    except:
      try:
        xqt('ocamlc')
        OCAMLCC = 'ocamlc '
        if "debug" in options:
          OCAMLCC = 'ocamlc -g '
        OCAMLLEX = 'ocamllex '
        BYTECODE = 1
        OCAMLYACC = 'ocamlyacc '
      except:
        BYTECODE = -1
        OCAMLCC = '#ocamlc '
        OCAMLLEX = '#ocamllex '
        OCAMLYACC = '#ocamlyacc '

  try:
    xqt('ocamlc.opt')
    OCAMLB = 'ocamlc.opt '
  except:
    try:
      xqt('ocamlc')
      OCAMLB = 'ocamlc '
    except:
      OCAMLB = '#ocamlc '

  if "debug" in options:
    OCAMLB = OCAMLB + "-g "

  if "bytecode" in options:
    OCAMLOPT= OCAMLB + ' -I '+OCAML_OBJDIR+' '
    if BYTECODE <> -1: BYTECODE = 1
  else:
    OCAMLOPT= OCAMLCC + ' -I '+OCAML_OBJDIR+' '

  if "optimise" in options:
    OCAMLOPT = OCAMLOPT + "-unsafe -noassert -inline 5 "

  #OCAMLC=OCAMLB + ' -I '+OCAML_OBJDIR+' -rectypes '
  OCAMLC=OCAMLB + ' -I '+OCAML_OBJDIR+' '

  if BYTECODE == 0:
    OCAML_OBJECT_EXTENSION = '.cmx'
    OCAML_LIB_EXTENSION = '.cmxa'
  else:
    OCAML_OBJECT_EXTENSION = '.cmo'
    OCAML_LIB_EXTENSION = '.cma'
  
  # where the ocaml is installed
  result,x = get_stdout(OCAMLC + " -where")
  OCAML_INCLUDE_DIRECTORY= x[0][0:-1]
  print "OCAML at",OCAML_INCLUDE_DIRECTORY


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Markus Mottl]

On Thu, 15 Apr 2004, skaller wrote:
> On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:
> 
> > Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
> > (1) and (3) all at once.
> 
> Yeah? How would they handle Interscript sources?
> What about Camlp4?

No problem, OCamlMakefile handles them by letting the user specify a
preprocessor in a comment in the first line.  See camlp4-example in
the distribution.

> My system also contains *Felix* programs,
> since it happens to be a compiler. How do these
> make systems handle that?

Add new "make"-rules?

> What about my use of SWIG to generate wrappers?

Look at the way "camlidl" is supported by OCamlMakefile and just add
this feature.

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles]

On Thu, Apr 15, 2004 at 05:33:38PM +1000, skaller wrote:
> On Thu, 2004-04-15 at 16:34, Kenneth Knowles wrote:
> > On Thu, Apr 15, 2004 at 11:05:12AM +1000, skaller wrote:
> 
> > I never said they were perfect.  I don't use them.  However, I don't know of
> > anything other than a custom-rolled Makefile that handles such things.  Are you
> > suggesting one?  If so, I'm very interested, and I may have missed it in your
> > previous messages.
> 
> I'm suggesting a whole class of them: general purpose languages.
> Here's a fragment from the Felix build script.
> Who needs autoconf?
> 
> [script]

Do you see how you are doing the same work as autoconf, but in a language other
than m4/shell?  Moreover almost all of that should be provided by the build tool,
not written by the programmer.  A reasonable size of build script to locate the
ocaml tools and set a couple flags is under a dozen lines.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Thu, 2004-04-15 at 19:47, Markus Mottl wrote:
> On Thu, 15 Apr 2004, skaller wrote:
> > On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:
> > 
> > > Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
> > > (1) and (3) all at once.
> > 
> > Yeah? How would they handle Interscript sources?
> > What about Camlp4?
> 
> No problem, OCamlMakefile handles them by letting the user specify a
> preprocessor in a comment in the first line.  See camlp4-example in
> the distribution.

That may work for camlp4 but not interscript.
Interscript is a code generator, there is no simplistic
1-1 correspondence between inputs and outputs for which
any make rule could be encoded.

Make is all wrong, as I said before. Interscript is a new,
correct concept for building systems. It uses fixpoints.
It doesn't care what the outputs are --- they have to be tracked,
but not specified.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles]

On Fri, Apr 16, 2004 at 03:10:26AM +1000, skaller wrote:
> On Fri, 2004-04-16 at 02:00, Kenneth Knowles wrote:
> > > 
> > > [script]
> > 
> > Do you see how you are doing the same work as autoconf, but in a language other
> > than m4/shell? 
> 
> It's the whole POINT of presenting it!
> 
> you can write the tools you need and integrate them in a
> SINGLE unified language. And remove the depenencies
> on things like Make and Autoconf .. which don't really
> work anyhow.
> 
> [Say no to autoconf]

Ranting against autoconf is off-topic and uninteresting.  I'm not talking about
autoconf, I'm talking about the paradigm of even having a "configure" phase to
the build.  I support it, and *don't* think it is a good idea to create your own
from scratch each time.  Thus, ocamlconf, a support library for writing
configure scripts in O'Caml.

By the way, "Make" works perfectly; it is a domain-specific programming language
with a clear specification that it meets.  It just doesn't do what you want it
to, so let's drop that rant as well, and try to be a bit more productive.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] BSD vs. GPL

[Benjamin Geer]

skaller wrote:
> If so much as ONE other person contributes to your
> code in any way, including any GPL code you include
> in your package, the code is no longer yours,
> and you are not free to offer a commercial licence.
> ALL the other contributors would have to agree first.

Not if they've assigned the copyright to you.  That's how the GNU 
project works.

Ben

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Re: GODI vs. Ocamake

[Brandon J. Van Every]

Kenneth Knowles wrote:
>
> Ranting against autoconf is off-topic

Not really, considering the future of OCaml build tools is under
discussion.

> and uninteresting.

To you.

> I support it, and *don't* think it is a good idea
> to create your own from scratch each time.

So this devolves into an aesthetic / woulda coulda shoulda argument.
When the time comes, count me on the side of those who want to see
everything done in OCaml.  I'd put up with interim steps to get there,
I'm Python-friendly.

> so let's drop that rant as well, and try to be a bit more
> productive.

Productive would be, you go do your thing, we'll go do ours.  Enough
talk.  We know where our lines of disagreement are.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles]

On Thu, Apr 15, 2004 at 04:58:47PM -0700, Brandon J. Van Every wrote:
> Productive would be, you go do your thing, we'll go do ours.  Enough
> talk.  We know where our lines of disagreement are.

Actually I don't know at all.  All I know at this point is that we agree that
current tools are inadequate (many times over).  If we "go our separate ways"
it'd be stopping the discussion before it starts, and each party certainly has a
right to do that, it's just a bummer.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[Richard Cole]

skaller wrote:

>On Thu, 2004-04-15 at 19:47, Markus Mottl wrote:
>  
>
>>On Thu, 15 Apr 2004, skaller wrote:
>>    
>>
>>>On Thu, 2004-04-15 at 02:49, Kenneth Knowles wrote:
>>>
>>>      
>>>
>>>>Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
>>>>(1) and (3) all at once.
>>>>        
>>>>
>>>Yeah? How would they handle Interscript sources?
>>>What about Camlp4?
>>>      
>>>
>>No problem, OCamlMakefile handles them by letting the user specify a
>>preprocessor in a comment in the first line.  See camlp4-example in
>>the distribution.
>>    
>>
>
>That may work for camlp4 but not interscript.
>Interscript is a code generator, there is no simplistic
>1-1 correspondence between inputs and outputs for which
>any make rule could be encoded.
>
>Make is all wrong, as I said before. Interscript is a new,
>correct concept for building systems. It uses fixpoints.
>It doesn't care what the outputs are --- they have to be tracked,
>but not specified.
>  
>
Please forgive my ignorance of interscript but I'm interested in what 
problem interscript is trying to address. I understand that it makes 
sense to document code using some simple hypertext language -- something 
similar to WikiLanguages -- that allows you to make references to code 
artifacts, include diagrams etc.

Another aspect of building systems is configuration management. This is 
where my question really is. I've only worked on systems where 
configurations differed via library dependencies. So for example the 
linux version links to the linux-lowlevel library and the windows 
version links to the window-lowlevel library. Is there some other aspect 
of configuration management that interscript addresses?

The way that I now build makefiles is with tcl.

set projects { pig }
set ml_sources(pig) { one two three }
set mli_sources(pig) { two }

for y in $projects {


  #  Create .cmo files
 
  for x in [get ml_sources $y] {  
    if { [is_member $x [get mli_sources $y]] } {
      set mli_source $x
    } else {
      set mli_source ""
    }

    puts "$x.cmo: $x.ml $mli_source.mli"
    ...
  }
}

I find that this approach allows me to factor out the stuff that is 
repeated between projects and use variables to denote the stuff that 
changes between projects. This is kind of a moving target because as 
code develops what is common and what is different between projects changes.

Another aspect of configuration management is knowing which libraries a 
version of your project depends on. There are source level dependencies 
and after you build libraries there are binary level dependencies. This 
problem seems to be tackled in two ways: (i) package managers of which 
godi is a nice example, and (ii) autoconf which alleviates some source 
level dependencies by hacking the code in sometimes evil ways.

Another issue comes to mind. Under linux it seems that libraries have 
version numbers, libc.so.3.0.0 and the like. I haven't seen how this 
works with godi? Can you install multiple versions of an Ocaml package 
and pass version information to Ocamlfind? If not why not? Is the case 
of multiple deployed library versions something we are striving to 
avoid? I think for the user it is inescapable, e.g. my desktop requires 
both gtk-1.2 and gtk-2.0.

There is another type of dependency which is very nasty to support and 
one that I think we should strive to avoid, where possible. The same 
project supporting quite different build environments. Say for example 
that you want to want to write a build script that uses either CSH or 
KSH, whatever is available [1]. Now say that it is not possible to 
automatically, in general, convert CSH into KSH, so you write a 
conversion program that doesn't work in general, but works for your 
build script. This is going to make a difficult to understand mess, it 
is much better to select tools that are supported on all the platforms 
that you want to deploy your system. That pushes the "supporting 
different build environments" problem onto someone else.

regards,

Richard.

[1] I'm not advocating the use of build scripts in either csh or ksh 
just using them as an example.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] build tools - good vs. fast, both cheap

[Brandon J. Van Every]

Kenneth Knowles wrote:
> On Thu, Apr 15, 2004 at 04:58:47PM -0700, Brandon J. Van Every wrote:
> >
> > Productive would be, you go do your thing, we'll go do ours.  Enough
> > talk.  We know where our lines of disagreement are.
>
> Actually I don't know at all.  All I know at this point is
> that we agree that
> current tools are inadequate (many times over).  If we "go
> our separate ways"
> it'd be stopping the discussion before it starts, and each
> party certainly has a
> right to do that, it's just a bummer.

Ok, if you want to discuss, then let's please everybody refrain from
labeling other people's lines of discussion as offtopic rants,
uninteresting, etc.  I don't mind hearing when someone says they think
such-and-such tool or approach sucks.  They might, after all, be
partially or even wholly correct.  I do mind when someone says our
opinions aren't worth expressing.  It's a quick way to kill a
discussion.

So where are we?  We're having the age old engineering argument, "good,
fast, cheap, pick any two."  We're all open source developers so we're
all cheap.  :-)  We've got one camp that sees an all-OCaml build +
package management system as the goal.  Count me in on that, and I will
label it the "GOOD AND CHEAP" camp.  We've got another camp that sees
getting any build + package management system together as quickly as
possible from readily available parts as the goal.  I will label it the
"FAST AND CHEAP" camp.

We know that good will not be fast.  Ideal solutions take a long time to
develop.  We've got plenty of starting points and interim scaffolding
available though.

Will fast be any good?

What is the ultimate goal?  I say, the ultimate goal is total ease of
use for an OCaml developer.  The OCaml developer should have a major
platform advantage over everyone else.  It should be a helluva lot
easier for OCaml guys to get their packaging and dependency job done
than anyone else out there.  The tool should be completely
cross-platform.  I would like to think that somehow, OCaml would analyze
lotsa stuff and automagically figure tons of things out.  It should
seriously leverage the power of the language.  It should be a heavy duty
value add to the developer, a big incentive to join the OCaml community
because We Do Things Better [TM].  Makefiles and autoconf cannot achieve
that ultimate goal.  I've worked with them plenty, back in the day I was
an autoconf guru.  Now when I get back into it I just scream, "The
horror!  The horror!" before I die.  We shouldn't be aspiring to the
manual labor of Make and company.

My philosophy is, if it is not an advanced build and package management
system, there is no point in pursuing it.  The ad hoc methods already
suffice for lesser goals.  So, with that in mind, what is currently the
most advanced build and package management system known to Humankind, in
any language?  That is where we should be looking for design reuse.

After that, then we ask what kinds of expertise we already have among
us.  Some have already been mentioned: OCamake, OCamlconf, GODI,
Interscript.  Any / all of these things could potentially provide
components, designs, or scaffolding.  It is quite possible that what is
actually needed, has not yet been built by any one person.  In that case
it would be best if people recognize personal inadequacy and agree to
work together for the common good.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

When no one else sells courage, supply and demand take hold.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: GODI vs. Ocamake

[skaller]

On Fri, 2004-04-16 at 11:30, Richard Cole wrote:

> >
> Please forgive my ignorance of interscript but I'm interested in what 
> problem interscript is trying to address. 

Package, build, test and document software systems using a 
unified source format. As a Literate Programming tool, 
you don't document your code .. you embed code in a document.

Interscript is unique as follows. Most LP tools divide sources
into 2 kinds: (a) documentation (b) source program codes. 
You use a tool to do two jobs: (a) extract the code (b) generate
the documentation. Called 'tangling' and 'weaving'.

Interscript sources can have a third kind of stuff in it. 
Arbitrary executable code written in a high level language (Python).
I use executable code to generate programs, to generate documentation,
to compile code, to run test suites, to do configuration management,
and everything else. Some of these things have library and architecture
support, for example a registry for test results which is part of the
generated web site, other things do not: extensions may improve
the product, but you can always embed them directly and install
them as part of the build.

> Another aspect of building systems is configuration management. This is 
> where my question really is. I've only worked on systems where 
> configurations differed via library dependencies. So for example the 
> linux version links to the linux-lowlevel library and the windows 
> version links to the window-lowlevel library. Is there some other aspect 
> of configuration management that interscript addresses?

Not in particular: it doesn't really address anything.
It simply allows you to embed configuration management
code directly in the source tree in a uniform format.

Well, there are some interesting ideas: for example you can
'include' a generated file before it is generated. No problem!
That's because the idea is to run the build repeatedly until
the outputs converge to a fixpoint: if something fails
the first time it doesn't matter, just keep trying :D

This is already clearly mandatory for LaTeX, and if you think
about it is the only way to manage systems that bootstrap.

> is much better to select tools that are supported on all the platforms 
> that you want to deploy your system. That pushes the "supporting 
> different build environments" problem onto someone else.

Yeah, I chose Python. Shell script is too Unix centric,
and it just doesn't compare with a real programming language:
you don't need hacks kludges and glue to make it work.

The downside is that being general purpose, a high level language
like Python (or Ocaml) will need more code to get simple
jobs done. That's the price for being able to write code
for any job, no matter how complex, and knowing for SURE that
you will not be defeated by restrictions of more specialised tools.

Hey, you write code in Ocaml because it's not going to get
in your way like C++ does .. and isn't building a system
just another programming problem?


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Fri, 2004-04-16 at 16:31, Brandon J. Van Every wrote:

> So where are we?  We're having the age old engineering argument, "good,
> fast, cheap, pick any two."  We're all open source developers so we're
> all cheap.  :-)  We've got one camp that sees an all-OCaml build +
> package management system as the goal.  Count me in on that, and I will
> label it the "GOOD AND CHEAP" camp.  We've got another camp that sees
> getting any build + package management system together as quickly as
> possible from readily available parts as the goal.  I will label it the
> "FAST AND CHEAP" camp.

Ok, then my opinion is that this analysis misses the point.

We can do both. First hack together any crappy code that works,
then make something elegant -- using the crappy code to help
bootstrap the effort.

How do we do this? Well, one thing must NOT be crappy,
even for the crappy code -- and that is the specification.
Writing a package manager isn't the problem, IMHO. 
The problem is defining what a package IS, where the pieces go,
and how dependencies are stated.. etc etc.

> What is the ultimate goal?  I say, the ultimate goal is total ease of
> use for an OCaml developer. 

NO! Ocaml developers don't need package managers, we're nerds,
we'll happily use tarballs, CVS .. and even .. gasp .. autoconf.. :D

Package managers are for our CLIENTS.

I want to build something which USES your code,
and be able to distribute MY code and not yours .. and know
my client can get it easily .. preferably my build script
will do that automatically in a uniform way for your code,
fred's code, Joe's code and Mary's code .. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Fri, 2004-04-16 at 16:31, Brandon J. Van Every wrote:

> My philosophy is, if it is not an advanced build and package management
> system, there is no point in pursuing it.  The ad hoc methods already
> suffice for lesser goals.  So, with that in mind, what is currently the
> most advanced build and package management system known to Humankind, in
> any language?  That is where we should be looking for design reuse.

I suggest we look at something more abstract.
Dependencies, relations, processes, types, functions ..

Which abstraction is useful for dealing with that?

Category theory.

Here is a really simple processing category:

	'gcc -c': *c -> *.o

Now consider the categories needed to build a literate
programmed book of over 3000 pages .. there's a LOT more
to building books than mere software, especially when
using LP implies the sources contain the build scripts
for everying .. including running tests .. generating
documentation .. and trying to do all that in a way
that is practical performance wise: you don't typeset
3000 pages of LaTex just because you changed a few
lines of code.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Richard Jones]

Can I just jump in and say that there's already a model for this.

ExtUtils::MakeMaker

	- Written in Perl, generates Makefiles from simple Perl input
	  describing the package.  To see a typical Makefile.PL (Perl
	  input file) see [1]

CPAN (the module)

	- Examples the Perl input files, finds dependencies, downloads
	  them and compiles them.

CPAN (the global repository)

	- A big semi-self-organizing place where all packages can be
	  found.  This is important because CPAN (above) needs CPAN
	  (the global repository) to find packages.

dh-make-perl and equivalents

	- Automagically takes Perl source modules and turns them into
	  Debian binary packages.  Well, it's not completely automatic,
	  but I've heard reports that it is quite successful at producing
	  a "first cut".

Whether or not it's a good model, I leave you all to argue about, but
it's certainly a working model.  Certainly GODI is rather orthogonal
to this, seemingly inspired more by the *BSD packaging system rather
than anything from Perl.

Rich.

[1] http://cvs.sourceforge.net/viewcvs.py/*checkout*/reefknot/Net-ICal/Makefile.PL?content-type=text%2Fplain&rev=1.20

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

On Thu, Apr 15, 2004 at 11:31:44PM -0700, Brandon J. Van Every wrote:
> Ok, if you want to discuss, then let's please everybody refrain from
> labeling other people's lines of discussion as offtopic rants,
> uninteresting, etc.  

I agree, and apologize.  It was a bit frustrating to hear the same thing over
and over when I already agreed.
 
> So where are we?  We're having the age old engineering argument, "good,
> fast, cheap, pick any two."  We're all open source developers so we're
> all cheap.  :-)  We've got one camp that sees an all-OCaml build +
> package management system as the goal.  Count me in on that, and I will
> label it the "GOOD AND CHEAP" camp.  We've got another camp that sees
> getting any build + package management system together as quickly as
> possible from readily available parts as the goal.  I will label it the
> "FAST AND CHEAP" camp.

I think any good build process will make the creation of any package manager
easier, so that's what I'm focusing on - admittedly steering the discussion that
way whenever possible; I'm fairly confident in GODI, it just doesn't have what I
personally need yet.

As an example, Gentoo's ebuild scripts are highly specialized so that if you
have a predictable autoconf package they need less than 10 lines - but they are
capable of handling arbitrary commands.

And on the build system side, I think that "FAST AND CHEAP" could evolve into
"GOOD" one way or another as long as the motivations and design are sound.
So, since development has already started on a number of tools that might be
glued together, I'm most interested in critiquing not the tools but their
approaches to the problem.

These are the approaches I can see out there:

(1) Monolithic automagical GNU Makefile
(2) O'Caml script outputing make-agnostic Makefile
(3) Command-line build-every-at-once ocaml tool
(4) Roll your own Makefile, have the user edit it - often separated into a
    Makefile.config.
(5) Use autoconf (why, oh why?  it doesn't offer any O'Caml support)
(6) Interscript? I don't really understand what it does and what the developer
    must do.

My "plan" i.e. what I'm going to do eventually unless someone convinces me
otherwise, is to try to plug (2) into an enhanced (3) and thus the whole build
process will be in O'Caml.  It won't address the needs of projects that have
more than just O'Caml and C sources, but I already offered the following
rationale:

"It is easier to have many specialized build processes and glue them together
than to have one catch-all"

Anyone who is willing to write a build in a general purpose language should be
more than willing to write glue in a general purpose language.

If (6) can eliminate/reduce the work that I'm planning, then I'm still waiting
to hear about it.  Design time saves a lot more programming time than it wastes.

> Makefiles and autoconf cannot achieve
> that ultimate goal.  I've worked with them plenty, back in the day I was
> an autoconf guru.  Now when I get back into it I just scream, "The
> horror!  The horror!" before I die. 

Me too; I still have old C and C++ projects that I never touch... I've yet to
get a coherent response to my assertion that it is the implementation, not the
concept that is wrong.  (John provided an example in python which seems to imply
he agrees that the concept is good)

> So, with that in mind, what is currently the
> most advanced build and package management system known to Humankind, in
> any language?  That is where we should be looking for design reuse.

Do you truly disagree that these can be separated into two tasks?
On the build side, I don't know of anything more advanced than automake/autoconf
in design, though I hate their implementation choices.  For package management,
BSD, Gentoo, and Debian all have a model that is insufficient for O'Caml, and I
think GODI is addressing the unique re-compilation needs.

Kenn 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

On Fri, Apr 16, 2004 at 04:16:56PM +0100, Richard Jones wrote:
> Can I just jump in and say that there's already a model for this.
> 
> ExtUtils::MakeMaker
-> OcamlConf

> CPAN (the module)
-> GODI?
 
> CPAN (the global repository)
-> The Humps for the "place" / GODI's data files

> dh-make-perl and equivalents
-> ?? 
  
I'm not much into customized distribution methods, but I plan to augment
ocamlconf with at least enough power to output Gentoo ebuilds.

I like this model a lot, our tools just aren't as mature as perl's yet.

Kenn 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Richard Jones]

On Fri, Apr 16, 2004 at 09:12:18AM -0700, Kenneth Knowles wrote:
> > CPAN (the module)
> -> GODI?
>  
> > CPAN (the global repository)
> -> The Humps for the "place" / GODI's data files

I'm pretty sure that GODI is *not* like CPAN, fundamentally because
CPAN actually stores the source tarballs.  This is essential if you
want to set up a reliable distributed system which doesn't depend on
the vaguaries of uptimes of multiple small sites.

> > dh-make-perl and equivalents
> -> ?? 

Well, exactly.  Quite vital though, particularly for people like me
who basically drive everything from Debian packages.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Learning Objective CAML for C, C++, Perl and Java programmers:
http://www.merjis.com/richj/computers/ocaml/tutorial/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

On Fri, Apr 16, 2004 at 05:17:14PM +0100, Richard Jones wrote:
> On Fri, Apr 16, 2004 at 09:12:18AM -0700, Kenneth Knowles wrote:
> > > CPAN (the global repository)
> > -> The Humps for the "place" / GODI's data files
> 
> I'm pretty sure that GODI is *not* like CPAN, fundamentally because
> CPAN actually stores the source tarballs.  This is essential if you
> want to set up a reliable distributed system which doesn't depend on
> the vaguaries of uptimes of multiple small sites.

Ah, I see.  Gentoo does both - defaulting to your SRC_URI only if the Gentoo
mirror downloads fail.  This is just a matter of someone choosing to do the
hosting, yes, and then very minor changes to GODI to check that location first,
before going to the "multiple small sites"?

Step 1: make sure the GODI maintainers are interested in this model
Step 2: get hosting
Step 3: tweak GODI

None of which is my bag :-)
 
> > > dh-make-perl and equivalents
> > -> ?? 
> 
> Well, exactly.  Quite vital though, particularly for people like me
> who basically drive everything from Debian packages.

I wholly agree.  But I don't have the experience to do it (I've made exactly one
RPM in my life, a few ebuilds, and no .debs).  Even though I don't know the
internals, I imagine it could be orthogonally accomplished.

Or someone could send a patch to OcamlConf (or OCamlMakefile) enabling it to
output debs :-)

Admittedly, OCamlConf just has a list of sources and a list of "other files to
copy into the findlib directory" and in order to make a nice package they'd have
to be separated into data, docs, etc.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Sat, 2004-04-17 at 02:06, Kenneth Knowles wrote:

> These are the approaches I can see out there:
> 
> (1) Monolithic automagical GNU Makefile
> (2) O'Caml script outputing make-agnostic Makefile
> (3) Command-line build-every-at-once ocaml tool
> (4) Roll your own Makefile, have the user edit it - often separated into a
>     Makefile.config.
> (5) Use autoconf (why, oh why?  it doesn't offer any O'Caml support)
> (6) Interscript? I don't really understand what it does and what the developer
>     must do.

I'm against make. It just isn't necessary. Make is for C developers,
not Ocaml package installation. To build a package it suffices
to run a sequence of commands in a fixed order.

To understand interscript .. what does it do?
The answer is the same as tar -zxvf, except that
'extracting' a file can execute arbitrary code.
Its that simple. Here's an example:

@head(1,"My program")
Its only a demo.

@select(tangler("sample.ml")
let f x = x + x
@for i in [1..10]:
  tangle("print_endline (f "+i+");")

@doc()
This demo prints 2,4, .. 20. The Python script
means: @head -- document heading level 1.
The @select(tangler("sample.ml")) .. means 
"write the following stuff to sample.ml"

The @ starts an arbitrary Python command.
The select, tangler, and head functions
are just interscript library functions,
nothing special. The tangle() functions
write a string to output.

The for loop prints out 

print_endline(f 1);
print_endline(f 2);
...
etc up to 10. It is just a standard Python construction,
nothing special. If you want to compile
the above program instantly, here is how to do it:

@os.system("ocamlc -c sample.ml")

Duh. It just calls Python's system function,
which is C's system function. It is more usual
to do this though:

@select(tangler("Makefile"))
all:
@tangle("\tocamlc -c sample.ml")

@doc()
and then after you run interscript you have
a makefile, and you can compile using 
the ordinary 'make' command. 

The point of all this is: you can do anything
you want. Its just Python script, with a little
control loop that copies lines to the weaver
for typesetting, the tangler to write a source
file, or executes them (if they start with @).

Oh yes, there is much more than that,
but this is the basic idea...

EXECISE: What does this do:

@os.system("ocaml sample.ml > sample.out")
@f = open("sample.out")
@for i in [1..10]:
  tangle(f.readline())
@doc()

If you want to see a more advanced use
of the executable facilities, examine
section 6.4 of the interscript implementation
listing at http://interscript.sf.net.

What you will see there is the full
Unicode data, and code tables for something like
30 other standard character sets -- there
are hundreds of pages of character tables,
and the whole of it is generated by about
a page of code which downloads and reads
the unicode.org data files.

Here is a real example from Felix compiler.
Have you ever got annoyed at copying
things in both mli and ml files??

@head(1,'Compile time exceptions')
@python('//')
exceptions = """
open Flx_ast
open Flx_types
exception SyntaxError of string
exception ParseError of string
exception LexError of string
exception TokenError of string
exception ClientError of range_srcref * string
exception ClientError2 of range_srcref * range_srcref * string
exception SystemError of range_srcref * string
exception Exit of int
exception Bad_recursion
exception Expr_recursion of expr_t
exception Free_fixpoint of btypecode_t 
exception Unresolved_return of range_srcref * string
"""
//
@h = tangler('src/flx_exceptions.ml')
@select(h)
@tangle(exceptions)
let clierr2 sr sr2 s = raise (ClientError2 (sr,sr2,s))
let clierr sr s = raise (ClientError (sr,s))
let syserr sr s = raise (SystemError (sr,s))
let catch s f = try f() with _ -> failwith s

@h = tangler('src/flx_exceptions.mli')
@select(h)
@tangle(exceptions)
val clierr: range_srcref -> string -> 'a
val clierr2: range_srcref -> range_srcref -> string -> 'a
val syserr: range_srcref -> string -> 'a
val catch: string -> (unit -> 'a) -> 'a



-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

> I'm against make. It just isn't necessary. Make is for C developers,
> not Ocaml package installation.

So, in a similar system I'll call "MagicScript," because I'm talking
hypothetically, not particularly about Interscript:

* Efficient recompilation:  Use a makefile tangler?  Include a "make"
  python/OCaml module?  If either of these, then "MagicScript" should provide
  them.

* Typical "automake" actions: build, install, uninstall, etc - should be
  generated from metadata by "MagicScript" so I don't re-invent those wheels.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[John Goerzen]

On Sat, Apr 17, 2004 at 04:10:25AM +1000, skaller wrote:
> On Sat, 2004-04-17 at 02:06, Kenneth Knowles wrote:
> 
> To understand interscript .. what does it do?

You keep bringing that up, so I have to ask: why is that relevant as
part of a discussion of *OCaml* build tools?

-- John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

On Fri, Apr 16, 2004 at 01:46:56PM -0500, John Goerzen wrote:
> On Sat, Apr 17, 2004 at 04:10:25AM +1000, skaller wrote:
> > On Sat, 2004-04-17 at 02:06, Kenneth Knowles wrote:
> > 
> > To understand interscript .. what does it do?
> 
> You keep bringing that up, so I have to ask: why is that relevant as
> part of a discussion of *OCaml* build tools?

I'm not sure who you are addressing this to... I sure didn't bring it up, I was
just curious why someone else did.  By the way, now I know (see skaller's recent
posts)

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Richard Jones]

On Sat, Apr 17, 2004 at 04:10:25AM +1000, skaller wrote:
> I'm against make. It just isn't necessary. Make is for C developers,
> not Ocaml package installation. To build a package it suffices
> to run a sequence of commands in a fixed order.

Controversial view.  Why ..?  GNU make in particular is a very useful
tool for its specialised niche.  I use it all the time to build all
lots of things (not just C or OCaml).

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Sat, 2004-04-17 at 04:43, Kenneth Knowles wrote:
> > I'm against make. It just isn't necessary. Make is for C developers,
> > not Ocaml package installation.
> 
> So, in a similar system I'll call "MagicScript," because I'm talking
> hypothetically, not particularly about Interscript:
> 
> * Efficient recompilation:  Use a makefile tangler?  Include a "make"
>   python/OCaml module?  If either of these, then "MagicScript" should provide
>   them.

That's two options. Another is what I actually do in Felix.

    # STEP 4: Compile ocaml interfaces
    for interface in INTERFACES:
      file = 'src/'+interface
      if buildall or filetime(file + '.mli') > filetime(file+'.cmi'):
        buildall = 1
        xqt(OCAMLC + ' -c '+file+ '.mli')

    # STEP 5: Compile ocaml implementations
    for implementation in IMPLEMENTATIONS + EXES:
      file = 'src/'+implementation
      if buildall or filetime(file+ '.ml') \
          > filetime(file+OCAML_OBJECT_EXTENSION):
        buildall = 1
        xqt(OCAMLOPT + ' -c ' + file +'.ml')

This of course is a weaker version of the logic make
implements: it starts compilation at the first module
which is out of date and compiles all the others
after it in the list in order. That's enough for me for Felix.

So there are multiple options .. as many as there are
progammers?


> * Typical "automake" actions: build, install, uninstall, etc - should be
>   generated from metadata by "MagicScript" so I don't re-invent those wheels.

Sure, if you want! You can always write these scripts yourself,
and just include them. Alternatively, you can add them
to the MagicScript standard distro.

For an Ocaml-centric tool, you'd certainly want to have
a library with Ocaml-centric functions, as well as
generic ones.

Here are some interesting functions:

	let f = open_notouch(filename) in
	writeline_notouch(f,data);
	let changed = close_notouch(f) in ...

what this does is: the file is opened for INPUT.
Every writeline does a COMPARISON with the input
by reading it. When a line compares not equal,
the file is reopened for OUTPUT and positioned
at the changed line, and each subsequent write
actually writes to the file. The 'changed' flag
determines if the file was touched.

Using these functions whilst generating code
avoids touching unchanged files. This not only
allows 'make' to make the minimal set of things,
it also allows you to determine if your
build process has converged... if every file
written is unchanged, you can stop an iterative
rebuild because you've reached a fixpoint.

If you tell MagicScript to do this:

	ocamlc -c x.mli

it will create a .cmi file. But what if you 
do this instead:

	success = ocamlc -c x.mli -o tmp
	changed = tmp <> x.cmo | not success
	if changed cp tmp x.cmo

With that logic, you might do one extra recompile.
What's the point? The answer is: you don't CARE
what the dependencies are. Ocamlc knows already,
just execute it, either the compile fails,
it succeeds but the output is different to the old one,
or that part of the process has reached a fixpoint.

With that idea .. you can just compile every changed
file in any order, until they're all fixed.

Of course you DO try to optimise the order by trying
to find out the dependencies.. but an unaccounted
for dependency will not mess up the process (usually:
false fixpoints are possible but rare, and of course
cycles are also possible .. don't write the current
date/time into generated output tracked as above!)

Example: new verion of Ocaml installed .. we forgot
that the cmo depends on ocamlc .. (has no effect
on an already fixed system so you need to force
a rebuild in that one case).

Note that this 'build everything repeatedly until it 
all fixes' idea is completely different from make.
It assume a set of *executable build rules*,
and you must track the outputs. But you do not
build 'targets' and you don't need to specify
'dependencies' to find subtargets. There is a single
*universal* target: fixation.

The theoretical underpinings are different to make:
dependencies don't define build order,
they optimise it. The consequences are profound:
the system handles circularities. Make does not.
Almost all non-trivial code generating systems
have circular depenencies, because they invariably
involve bootstrapping (by poetic licence I define
'trivial' as 'not involving bootstrapping' :D

Bottom line: no need to use interscript,
but please lets not just copy existing tools
such as make without doing some theoretical analysis.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Sat, 2004-04-17 at 04:46, John Goerzen wrote:
> On Sat, Apr 17, 2004 at 04:10:25AM +1000, skaller wrote:
> > On Sat, 2004-04-17 at 02:06, Kenneth Knowles wrote:
> > 
> > To understand interscript .. what does it do?
> 
> You keep bringing that up, so I have to ask: why is that relevant as
> part of a discussion of *OCaml* build tools?
> 

Interscript is language independent and general purpose.
Language dependent tools are limited.
Because systems generally aren't uniform.

EG: you build a system (like Felix) which uses
Ocaml .. and C++ .. and Felix codes .. can you
use Ocamldep to document it? Of course not,
it only works for Ocaml. Interscript works
for ALL three languages. As well as every other
language you care to use or invent (provided
it is a linear text file kind of language :D
heck, ocamldoc doesn't even work with camlp4!

In addition, interscript uses some different
techniques such as literate programming
with executable script, has a new build
concept based on convergence to a fixpoint,
and generally speaking is so far in advance of
make and autoconf I don't even consider
those tools to provide any kind of model for
any part of a build process anymore.

The logic embodied in those tools is still
needed, but it should be represented
by library modules, not executables.
EG: topological sort is a useful module.
EG: getfiletime is a useful function!
EG: (dependency) graph is a useful module.
And given them you can write 'make'
in 10 lines of Ocaml .. well i exaggerate
but you get the idea.

Yes yes, bash is a (lame) general purpose
language and Unix commands are just library
modules... of an archaic programming system,
not a modern one.

Anyhow, hope that answers your question:
I have spent something like 5 years building
a tool that handles much the same set
of problem we're discussing, or at least
could handle them if so programmed,
and ended up with something quite different
from the spagetti the C world uses.
I really don't want to see Ocaml go down the
spagetti route :D

So far it hasn't: for example no lame preprocessor!
Yeah, Ocaml does finally have one, camlp4.
But a preprocessor that can extend the grammar,
and involves arbitrary executable caml code ..
that isn't even marginally lame .. its a completely
radical and worthy tool: perhaps not perfect,
but I'm so glad the Ocaml team resisted a spagetti
solution.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Sat, 2004-04-17 at 05:39, Richard Jones wrote:
> On Sat, Apr 17, 2004 at 04:10:25AM +1000, skaller wrote:
> > I'm against make. It just isn't necessary. Make is for C developers,
> > not Ocaml package installation. To build a package it suffices
> > to run a sequence of commands in a fixed order.
> 
> Controversial view.  

Yes, so it seems :D

> Why ..?  GNU make in particular is a very useful

Partly that is because many programming systems follow
the C model. Partly because of familiarity. And partly
because some of the underlying logic (dependencies etc)
is a genuine part of a building concept.

> tool for its specialised niche.  I use it all the time to build all
> lots of things (not just C or OCaml).

I'm not saying it isn't useful, rather that it isn't
useful enough these days. 

When I worked at the telco OT with C++ code base
of several million LOC, they didn't use make as such.
They used a custom general purpose tool called Makeit.
It used the same idea, but it also understood some
extra things:

(1) modules
(2) multiple platforms
(3) multiple target classes (standard, optimised, debugging)

and it could build the lot at once, or not, as you chose.
[It also knew about versioning, although I don't think that
part ever worked properly]

So for example you could have:

exes=A,B,C
platforms=Solaris,Linux
kinds=opt,debug
links=static,shlib

and it knew enough category theory to 'generate'
the product targets internally. 


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[William Lovas]

On Sat, Apr 17, 2004 at 12:38:08AM +1000, skaller wrote:
> Ok, then my opinion is that this analysis misses the point.
> 
> We can do both. First hack together any crappy code that works,
> then make something elegant -- using the crappy code to help
> bootstrap the effort.
> 
> How do we do this? Well, one thing must NOT be crappy,
> even for the crappy code -- and that is the specification.
> Writing a package manager isn't the problem, IMHO. 
> The problem is defining what a package IS, where the pieces go,
> and how dependencies are stated.. etc etc.

This is essentially the goal of the GODIVA project (formerly GODOR) that
Owen Gunden and i are working on:  We're grafting a sensible specification
onto the frontend of GODI so that it's easier for developers to make
packages.  In the future, this specification could stay around if some
other underlying backend technology supplanted GODI, and all that would
require updating would be the backend of GODIVA.

A (very!) preliminary release of GODIVA is available as the GODI package
called godor.  In a few days, Owen and i will be packaging up a new release
incorporating the ideas from this paper:

    http://projects.phauna.org/godiva/papers/godiva.ps
    http://projects.phauna.org/godiva/papers/godiva.pdf

(And this time, "a few days" really means "a few days" -- we have a hard
(academic) deadline to meet!)

More information is available on the GODIVA website (but the paper is more
up-to-date):

    http://projects.phauna.org/godiva/

cheers,
William

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[skaller]

On Sat, 2004-04-17 at 07:53, William Lovas wrote:
> On Sat, Apr 17, 2004 at 12:38:08AM +1000, skaller wrote:

> This is essentially the goal of the GODIVA project (formerly GODOR) that
> Owen Gunden and i are working on:  We're grafting a sensible specification
> onto the frontend of GODI so that it's easier for developers to make
> packages. 

>     http://projects.phauna.org/godiva/papers/godiva.ps
>     http://projects.phauna.org/godiva/papers/godiva.pdf

OK, I've read this now, especially the most interesting part,
the build policy. Since I don't know what constraints are
Godiva's, and which are Godi's and which are bsd's .. I'll
just make some comments.

I'm going to see how this would go installing Felix.

(1) Make all/make opt.

What I do is:

make compiler
make compiler.bytecode

There is a reason for this. First, the target is 'compiler'
and not 'all'. "all" is a lot more than just the tools
generated by ocaml, see below.

Second, make compiler automatically makes the native
code version if possible, otherwise it makes the bytecode
version. The compiler.bytecode target makes bytecode only.

(2) make htdoc

I wish it were that simple. The felix documentation
consists of the following, at least:

(a) A complete typeset listing of the source code.
(b) An Ocamldoc generated module reference.
(c) Several tutorials
(d) A reference manual (not written yet :)
(e) A users guide (not written yet)
(f) Theory and principles papers (not written yet)
(g) Typset listing of test inputs (other than the tutorial
codes which are in fact the primary unit tests).
There are two sections at the moment: special regression
and unit tests, and a set of performance tests.
(h) Man pages, including HTML formatted versions of them

In addition, interscript "in theory" can generate
documentation in any language: technically a few
navigation bars can be done in English, Spanish etc,
however there is a possibility of selecting a non-native
language section (a paragraph could be provided in several
languages). The point here is that the choice of languages
is a mandatory command line parameter: there is, deliberately,
no default. Note also the plural. You can simultaneously
generate documentation in any number of languages, the
files are prefixed by the ISO language code: en_ for english,
es_ for spanish, fr_ for French (thought I'd better add that
one here .. ). Etc.

So there needs to be a way for the client to configure that.
[There isn't at present, even in my build scripts]

The generated documentation doesn't all go in the same place.
The tutorial goes in tutorial/doc. The ocamldep output goes
into impldoc, the html listing into doc, and the html man
pages into htmlman.

(3) Missing targets.

First: there are test targets. Running the tests is considered
essential.

Second: Felix itself is a compiler. Naturally IT has a 
standard library and there are some tools written in it.
These must be built and tested too .. 

Third: Felix can call C libraries via wrappers.
These wrapper have to be generated. At the moment I'm
using SWIG with a custom module which can't be used
with SWIG without first patching it. So SWIG needs
to be relinked and installed (the patched version
makes an extra executable).

Then there has to be a way to determine *which* libraries
to wrap. The current method is intended to be: everything
there is a SWIG wrapper for, if the library exists, PLUS,
every library in the systems pkg-config database PLUS
any the user specifies. Wrappers get generated even if there
is no SWIG annotation file. Maybe :D

(4) Bootstrapping problem.

Felix consists of LP source codes. When you unpack the
tarball, there is a 'courtesy' makefile to bootstrap
the system. To get the thing rolling you have to do this:

make boot
./configure
make extract compiler drivers tests .......

The actual Makefile.ac is extracted by make boot,
then configure creates the makefile from it.
Make boot currently runs autoconf and friends
to generate the configure script from configure.ac.

-------------------------------------------------------------

INSTALLATION

Felix installs much as described in A.1, except there
is more. In fact some components are a nightmare.
For example 'felix.vim' has to go in

/usr/local/share/vim/vim61/syntax

but that isn't enough (some other files have to be patched)
which is a design flaw in vim.

Much of Felix actually lives in

/usr/local/lib/felix

because this is the kind of thing Ocaml and Python do.
The suggested /usr/local/share/felix isn't used,
because most of the shared data is actually Felix
program source.

The installation point for generated wrappers is a nightmare!

----------------------------------------------------

RECOMMENDATIONS

A mandatory

make test

target. The test must be run by GODI, and installation
refused if it fails. 

More is needed but my brain is overloaded now :D

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Blair Zajac]

William Lovas wrote:
> 
> This is essentially the goal of the GODIVA project (formerly GODOR) that
> Owen Gunden and i are working on:  We're grafting a sensible specification
> onto the frontend of GODI so that it's easier for developers to make
> packages.  In the future, this specification could stay around if some
> other underlying backend technology supplanted GODI, and all that would
> require updating would be the backend of GODIVA.
> 
> A (very!) preliminary release of GODIVA is available as the GODI package
> called godor.  In a few days, Owen and i will be packaging up a new release
> incorporating the ideas from this paper:
> 
>     http://projects.phauna.org/godiva/papers/godiva.ps
>     http://projects.phauna.org/godiva/papers/godiva.pdf
> 
> (And this time, "a few days" really means "a few days" -- we have a hard
> (academic) deadline to meet!)

I took a look at the PDF and it looks great.  I'm looking forward
to getting some cycles to put a couple of packages into it.

Some comments in no particular order, and some may be relevant for
Godi:

1) I think it would be a good idea to take a look at the Fink
   package management system that is used for Mac OS X

   http://fink.sourceforge.net

   I think they've dealt with many of the issues that we'll deal
   with and we can learn from their mistakes.  They've been around
   since Mac OS X 10.0, so that's been a while.

   Fink compiles libraries, binaries, etc and has a similar
   format as Godiva's files.

   The packaging specification is at

   http://fink.sourceforge.net/doc/packaging/index.php

2) To make updating the Godiva file easier for a new package and to
   prevent mistakes, say somebody updates the Version field and
   forgets to update Sources: have a %v replacement in the URL that
   uses the Version field.

3) Having a License field would be good for people to easily
   see what license the package is licensed under.

4) The Fink people split packages into SSL and non-SSL packages
   for distribution of Fink to countries where encryption is more
   restricted.  Maybe keep a field for this.

5) Have a Conflicts field if two different packages conflict?
   Say if you have hooks to Berkeley DB3 and DB4 and because they
   both have a db.mli, only one can be installed.  This ties into...

6) What about splitting libraries into two separate packages,
   one for interface files and one for the libraries?  That way you
   can have installed different .so files for different libraries
   and binaries that linked against them and not have the .mli files
   around.  I may be thinking too much of a C environment here.

7) Having a single sources_unpacksto may not handle all cases.  Fink
   has a rich set of settings for this that would be good to look
   at

   http://fink.sourceforge.net/doc/packaging/reference.php?phpLang=en

I think my major point is that has more packages use Godiva to
build and install and issues come up, it would be great to
reference Fink.  Definitely take a look at it.

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Jacques GARRIGUE]

From: Kenneth Knowles <kknowles@berkeley.edu>
> On Fri, Apr 16, 2004 at 05:17:14PM +0100, Richard Jones wrote:
> > On Fri, Apr 16, 2004 at 09:12:18AM -0700, Kenneth Knowles wrote:
> > > > CPAN (the global repository)
> > > -> The Humps for the "place" / GODI's data files
> > 
> > I'm pretty sure that GODI is *not* like CPAN, fundamentally because
> > CPAN actually stores the source tarballs.  This is essential if you
> > want to set up a reliable distributed system which doesn't depend on
> > the vaguaries of uptimes of multiple small sites.
> 
> Ah, I see.  Gentoo does both - defaulting to your SRC_URI only if the Gentoo
> mirror downloads fail.  This is just a matter of someone choosing to do the
> hosting, yes, and then very minor changes to GODI to check that location first,
> before going to the "multiple small sites"?
> 
> Step 1: make sure the GODI maintainers are interested in this model
> Step 2: get hosting
> Step 3: tweak GODI

There's nothing to tweak: GODI is based on BSD ports, which already
provide for this. Usually a BSD distribution comes with a distfile
directory, which contains all the files needed by all the ports, at
least those for which the licensing allows redistribution.

But then you need a site with sufficient bandwidth to support
potentially a lot of downloads of different packages.
So step 2 is probably the most difficult one.

The point in the BSD approach is not to avoid distributing the full
sources, but to avoid making this a requirement. In particular the
mirroring may be slower than the distribution of the meta files, but
you still want to be able to use the latest version. Also this makes sure
that the packaging is made as patches to the distributed sources, so
that upgrading to a new version is easier.
(Gentoo's portage is just a reimplementation of BSD ports to linux.)

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

On Sat, Apr 17, 2004 at 03:01:31PM +0900, Jacques GARRIGUE wrote:
> > Step 2: get hosting
> > Step 3: tweak GODI
> 
> There's nothing to tweak: GODI is based on BSD ports, which already
> provide for this. Usually a BSD distribution comes with a distfile
> directory, which contains all the files needed by all the ports, at
> least those for which the licensing allows redistribution.
> 
> But then you need a site with sufficient bandwidth to support
> potentially a lot of downloads of different packages.
> So step 2 is probably the most difficult one.
> 
> The point in the BSD approach is not to avoid distributing the full
> sources, but to avoid making this a requirement. In particular the
> mirroring may be slower than the distribution of the meta files, but
> you still want to be able to use the latest version. Also this makes sure
> that the packaging is made as patches to the distributed sources, so
> that upgrading to a new version is easier.
> (Gentoo's portage is just a reimplementation of BSD ports to linux.)

Awesome.  I'm quite aware that portage == ports, and just giving my two cents.
If GODI preempts what we're talking about, its useful that you have just let us
know.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Kenneth Knowles]

I don't want to be redundant, but certainly Gentoo's ebuilds (which I'm *not*
advocating as an exact model) are very similar too.  If you haven't checked 'em
out then you should, but it seems like you've covered most everything that they
have, and then some.

Kenn

On Fri, Apr 16, 2004 at 10:47:24PM -0700, Blair Zajac wrote:
> William Lovas wrote:
> > 
> > This is essentially the goal of the GODIVA project (formerly GODOR) that
> > Owen Gunden and i are working on:  We're grafting a sensible specification
> > onto the frontend of GODI so that it's easier for developers to make
> > packages.  In the future, this specification could stay around if some
> > other underlying backend technology supplanted GODI, and all that would
> > require updating would be the backend of GODIVA.
> > 
> > A (very!) preliminary release of GODIVA is available as the GODI package
> > called godor.  In a few days, Owen and i will be packaging up a new release
> > incorporating the ideas from this paper:
> > 
> >     http://projects.phauna.org/godiva/papers/godiva.ps
> >     http://projects.phauna.org/godiva/papers/godiva.pdf
> > 
> > (And this time, "a few days" really means "a few days" -- we have a hard
> > (academic) deadline to meet!)
> 
> I took a look at the PDF and it looks great.  I'm looking forward
> to getting some cycles to put a couple of packages into it.
> 
> Some comments in no particular order, and some may be relevant for
> Godi:
> 
> 1) I think it would be a good idea to take a look at the Fink
>    package management system that is used for Mac OS X
> 
>    http://fink.sourceforge.net
> 
>    I think they've dealt with many of the issues that we'll deal
>    with and we can learn from their mistakes.  They've been around
>    since Mac OS X 10.0, so that's been a while.
> 
>    Fink compiles libraries, binaries, etc and has a similar
>    format as Godiva's files.
> 
>    The packaging specification is at
> 
>    http://fink.sourceforge.net/doc/packaging/index.php
> 
> 2) To make updating the Godiva file easier for a new package and to
>    prevent mistakes, say somebody updates the Version field and
>    forgets to update Sources: have a %v replacement in the URL that
>    uses the Version field.
> 
> 3) Having a License field would be good for people to easily
>    see what license the package is licensed under.
> 
> 4) The Fink people split packages into SSL and non-SSL packages
>    for distribution of Fink to countries where encryption is more
>    restricted.  Maybe keep a field for this.
> 
> 5) Have a Conflicts field if two different packages conflict?
>    Say if you have hooks to Berkeley DB3 and DB4 and because they
>    both have a db.mli, only one can be installed.  This ties into...
> 
> 6) What about splitting libraries into two separate packages,
>    one for interface files and one for the libraries?  That way you
>    can have installed different .so files for different libraries
>    and binaries that linked against them and not have the .mli files
>    around.  I may be thinking too much of a C environment here.
> 
> 7) Having a single sources_unpacksto may not handle all cases.  Fink
>    has a rich set of settings for this that would be good to look
>    at
> 
>    http://fink.sourceforge.net/doc/packaging/reference.php?phpLang=en
> 
> I think my major point is that has more packages use Godiva to
> build and install and issues come up, it would be great to
> reference Fink.  Definitely take a look at it.
> 
> Best,
> Blair
> 
> -- 
> Blair Zajac <blair@orcaware.com>
> Plots of your system's performance - http://www.orcaware.com/orca/
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] build tools - good vs. fast, both cheap

[Alain.Frisch]

On Fri, Apr 16, 2004 at 05:17:14PM +0100, Richard Jones wrote:
> I'm pretty sure that GODI is *not* like CPAN, fundamentally because
> CPAN actually stores the source tarballs.  This is essential if you
> want to set up a reliable distributed system which doesn't depend on
> the vaguaries of uptimes of multiple small sites.

An automated script makes a copy of source packages as soon as a GODI
package is created for them. They are stored here:

http://www.ocaml-programming.de/godi-backup/

which is the first URL in the default MASTER_SITE_BACKUP variable.


-- Alain

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Is GCaml Dead Again?

[Greg K]

I noticed that the last message from Jun Furuse was from the University of 
Tokyo. Has he left INRIA? He'd talked on the list (last May) of resuming 
GCaml work once 3.0.7 was out. Does his leaving (if he has left) mean the 
GCaml is "officially" dead again?

Would be a pity as generics seem a very expressive addition to Caml....

Greg

At 12:52 PM 4/8/2004, Issac Trotts wrote:
>On Thu, Apr 08, 2004 at 04:31:26PM +0100, Jon Harrop wrote:
> > On Thursday 08 April 2004 3:56 pm, Markus Mottl wrote:
> > > On Thu, 08 Apr 2004, John Goerzen wrote:
> > > > Similar complaints exist for working with subsets of lists; it's really
> > > > too hard to say "replace elements 4 through 9 with this", "delete
> > > > elements 4 through 9", "return elements 4 through 9", etc.
> > >
> > > Yes, it's hard to do this with the current standard library.  The 
> question
> > > is: who needs these functions anyway?  I can't remember ever having felt
> > > a need for them.
> >
> > I could do with them! There are numerous such functions (and nice
> > implementations, like "List.nth -1 l" fetching the last element, more
> > powerful flatten etc.) which Mathematica has and which I miss.
>
>GCaml has the ability to do this kind of total flattenning of nested
>lists.  OCaml cannot do it unless you re-express your nested lists as
>binary trees or something similar.
>
>--
>Issac Trotts
>http://mallorn.ucdavis.edu/~ijtrotts
>(w) 530-757-8789
>
>-------------------
>To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
>Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
>Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners