compilation of lablgl examples.

compilation of lablgl examples.

[Peter Ronnquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 910 bytes --]

Hello,
I have a problem with compiling the laglgl examples. I
can run them with the top level:
lablgl -labels simple.ml

but 

ocamlc -I /usr/lib/ocaml/labltk  -I 
/usr/lib/ocaml/lablGL -I /usr/lib/labltk.cma
lablgl.cma togl.cmo simple.ml -o program

gives the following output:
/usr/bin/ld: cannot find -ltk8.0
collect2: ld returned 1 exit status
Error while building custom runtime system

I have libtk8.0.so.1 in /usr/lib
so I guess that the library really should be found,
also the fact that the toplevel works seems to support
that this library indeed is existing and usable.
Does anyone else have similar problems?

I am running debian/woody.

BR
Peter Rönnquist

PS please CC any comments to me since I am not yet
subscibed to this mailing list.

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: compilation of lablgl examples.

[John Max Skaller]

Has anyone considered a tool to covert sources using standard variants
to polymorphic variants?

The reason I ask is that I'm considering switching my current
pet project over to them ... but the use of standard variant
constructors is extremely heavy, and I'm having trouble
coming to terms with the need to virtually rewrite my
entire source.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: compilation of lablgl examples.

[Pierre Weis]

[...]
> pet project over to them ... but the use of standard variant
> constructors is extremely heavy, and I'm having trouble
> coming to terms with the need to virtually rewrite my
> entire source.
> 
> -- 
> John (Max) Skaller, mailto:skaller@maxtal.com.au
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net

Could you explain a bit why ``the use of standard variant
constructors is extremely heavy'' (I thought it was on the contrary
extremely light and elegant!) ?

Best regards,

Pierre Weis

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

Re: compilation of lablgl examples.

[John Max Skaller]

Pierre Weis wrote:
> 
> [...]
> > pet project over to them ... but the use of standard variant
> > constructors is extremely heavy, and I'm having trouble
> > coming to terms with the need to virtually rewrite my
> > entire source.
 
> Could you explain a bit why ``the use of standard variant
> constructors is extremely heavy'' (I thought it was on the contrary
> extremely light and elegant!) ?

	Excuse my poor English -- what I meant was
"A very large percentage of symbols in the source code
are variant constructor names". A very large amount of code
consists of match .. with statements where the expression
is a variant type, and the result expressions are another
variant. 

	For example, something like this happens:
the type of a function declaration in the Abstract Syntax Tree is:

  | AST_function of id_t * parameter_t list * typecode_t * statement_t
list

which is converted to:
 
  | DCL_function of   parameter_t list * typecode_t * asm_t list

which is converted to:

  | SYMDEF_function of parameter_t list * typecode_t * int list * exe_t
list * name_map_t
 
which is converted to:

  | BDCL_function of   bparameter_t list * btypecode_t * int list *
exe_t list * name_map_t

which is converted to:

  | BBDCL_function of   bparameter_t list * btypecode_t * int list *
bexe_t list * name_map_t

That is, there are FIVE separate types for each phase of the
compilation,
all of which represent a function declaration (and the same again
for other constructions).

What is happening is: first, the statements are desugared and split
into declarative and executable parts of a lower level language,
then the list of statements of a function is split into
executable code and a map representing contained declarations,
then the type names are bound, and finally variable names 
are bound. The final structure is then used by the back end to
generate a list of non-nested functions (C++ classes, actually).

The strict 'phasing' enforced by the separate typing makes
it easy to find errors statically. But the verbosity makes
it easy to _make_ a lot more errors, and the structure is
inflexible. Said another way, the current design consists of
a sequence of functors:

	Lex -> Parse -> AST -> SYM -> DCL -> BDCL -> BBDCL -> C++ 

where the categories joining these functors are distinct.

Another solution would be to use a single category for the inner
work space, moving from one 'subspace' to another, but while this
is very flexible, the lack of structure makes static error checking
weak.

But with polymorphic variants, types can be ascribed to the
'subspaces' even when they overlap, and it can be done
_after_ the fact to check correctness, while standard
variants require the typing to be designed first.

I.e., polymorphic variants are more useful for prototyping,
since types do not need to be declared before writing
algorithms, yet the declarations can still be added later
when the design is solider to check just how solid it really is.

At least, this is my expectation. For example, an 'expression'
type can be defined to include BOTH 'string name' and
'name as integer index into symbol table', allowing
a single routine 'print expression', while it is still
possible to give a type for 'expression not containing
any string names' (to be used after all the names are bound).

[At present, there are three 'types' for expressions,
and three almost identical print routines to display them:
all the expressions are the same, except that the second
type has all lambda's removed and _also_ has the names
of types bound (but not variables) while the third type
has variable names bound as well: the first type 
already fails to use static typing to distingush
'expression with lambdas' and 'expression with lambdas removed'
which in principle it should.]

I am not certain this will work. Comments appreciated.
I am loath to try it out, since it would takes many days to
rewrite all the constructor names, and I would have to undo
all the work if the experiment failed. Note that doing it
all manually (mainly adding a back quote in front of all
the constructor names everywhere) it is easy to make a spelling
mistake, which will lead to obscure typing problems:
it is hard to do this conversion incrementally, and therefore
isolate the source of a problem. If I could 'add backquotes'
in front of all the constructor names mechanically,
then everything would work 'as is', and I could begin the task
of identifying formerly distinct variant components.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: compilation of lablgl examples.

[Pierre Weis]

> > Could you explain a bit why ``the use of standard variant
> > constructors is extremely heavy'' (I thought it was on the contrary
> > extremely light and elegant!) ?
> 
> 	Excuse my poor English -- what I meant was
> "A very large percentage of symbols in the source code
> are variant constructor names". A very large amount of code
> consists of match .. with statements where the expression
> is a variant type, and the result expressions are another
> variant. 

May be it is my understanding of English which is bad, not your way to
write it :(

> 	For example, something like this happens:
> the type of a function declaration in the Abstract Syntax Tree is:
> 
>   | AST_function of id_t * parameter_t list * typecode_t * statement_t
> list
> 
> which is converted to:
>  
>   | DCL_function of   parameter_t list * typecode_t * asm_t list
> 
> which is converted to:
> 
>   | SYMDEF_function of parameter_t list * typecode_t * int list * exe_t
> list * name_map_t
>  
> which is converted to:
> 
>   | BDCL_function of   bparameter_t list * btypecode_t * int list *
> exe_t list * name_map_t
> 
> which is converted to:
> 
>   | BBDCL_function of   bparameter_t list * btypecode_t * int list *
> bexe_t list * name_map_t

This is very often considered good practice. However, I agree with you
that is can be heavy to code. Sometimes you can use polymorphism to
help for instance defining

| Function of 'parameter list * typecode_t * 'b

could be used to modelize both
| DCL_function of   parameter_t list * typecode_t * asm_t list
| BDCL_function of   bparameter_t list * btypecode_t * int list *
 exe_t list * name_map_t

and similarly

| Bfunction of 'parameter list * btypecode_t * int list * 'exe list *
name_map_t

coulod serve for:
| BDCL_function of   bparameter_t list * btypecode_t * int list * exe_t list * name_map_t
and
| BBDCL_function of   bparameter_t list * btypecode_t * int list * bexe_t list * name_map_t

This does not jeopardize static typing and lowers the needs for type
declarations ...

[...]
> I.e., polymorphic variants are more useful for prototyping,
> since types do not need to be declared before writing
> algorithms, yet the declarations can still be added later
> when the design is solider to check just how solid it really is.

This is an interesting idea, worth a try. I'm still not sure the
static type checker could handle gracefully the ``partial and
exhaustive match'' problem, but I may be wrong...

[...]
You should try on a small example, not on a huge optimizing compiler
for a full fledged language!

Best regards,

Pierre Weis

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

Re: compilation of lablgl examples.

[Patrick M Doane]

On Wed, 7 Feb 2001, Pierre Weis wrote:

> [...]
> > I.e., polymorphic variants are more useful for prototyping,
> > since types do not need to be declared before writing
> > algorithms, yet the declarations can still be added later
> > when the design is solider to check just how solid it really is.
> 
> This is an interesting idea, worth a try. I'm still not sure the
> static type checker could handle gracefully the ``partial and
> exhaustive match'' problem, but I may be wrong...
> 
> [...]
> You should try on a small example, not on a huge optimizing compiler
> for a full fledged language!

I tried two experiments that had similar goals to the ones John originally
mentioned.

The first was changing an abstract syntax to use polymorphic variants. For
this particular syntax, different subsets of variant types wanted to be
used through the syntax. This seemed to be a good match for the
polymorphic variants and it really improved the code readability.

I eventually abandoned the approach though as I tried to develop and
prototype with it. Since the abstract syntax was quite large, the
"exhaustive match" errors were also very large. At one point I had to
switch the project back to using regular variants simply to fix a problem
I couldn't track down. Maybe some kind of tree-based difference algorithm
could improve the error messages here? 

The second experiment was with a set of types that were refined over time
in a fashion similar to a compiler. There were particular components that
were similar at every stage, but the associated data evolved throughout
the flow. My first attempt was to introduce polymorphic type variables to
the constructors but this became unwieldy because of cyclic dependencies
among types. I needed about 8 type variables for every type throughout the
module. This really hurt readability and couldn't be reasonably used.

Switching to polymorphic variants worked quite well. Although I quickly
discovered that the expressiveness of this approach is much better for
code that is purely functional. For example, you can't translate a
hashtable containing one variant type to a subset through imperative
update. Since a large body of the transformations I need to express were
imperative, this approach didn't work in practice.

I do think that it is reasonable to try this on a multi-phase compiler and
the approach could provide many benefits. It is probably best to test on a
small toy language first though.

Patrick Doane

Re: compilation of lablgl examples.

[John Max Skaller]

Pierre Weis wrote:

> May be it is my understanding of English which is bad, not your way to
> write it :(

	I tend to write abbreviated idiomatic script flavoured by
my native language (Strine :-)
 
> >       For example, something like this happens:
> > the type of a function declaration in the Abstract Syntax Tree is:
> >
> >   | AST_function of id_t * parameter_t list * typecode_t * statement_t
> > list
> >
> > which is converted to:

[]

> > which is converted to:
> >
> >   | BBDCL_function of   bparameter_t list * btypecode_t * int list *
> > bexe_t list * name_map_t
> 
> This is very often considered good practice. However, I agree with you
> that is can be heavy to code. 

	Static typing today is not strong enough to express the actual
typing, so there is always some compromise/balance between static and
dynamic checking. I find it is difficult to engineer a good balance.
Ideally, I could change that balance easily, however it is even harder
to 'meta-engineer' code so that it is easy to change.

> Sometimes you can use polymorphism to
> help for instance defining
> 
> | Function of 'parameter list * typecode_t * 'b
> 
> could be used to modelize both
> | DCL_function of   parameter_t list * typecode_t * asm_t list
> | BDCL_function of   bparameter_t list * btypecode_t * int list *
>  exe_t list * name_map_t

	I'm not sure how: these two declarations are for variant 
components of _distinct_ types.

[Try using variants .. ]
 
> You should try on a small example, not on a huge optimizing compiler
> for a full fledged language!

	Thats a good idea .. although I must say that Felix is not (yet)
a 'huge' or  'optimising' compiler :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: compilation of lablgl examples.

[Pierre Weis]

> Pierre Weis wrote:
[...]
> > Sometimes you can use polymorphism to
> > help for instance defining
> > 
> > | Function of 'parameter list * typecode_t * 'b
> > 
> > could be used to modelize both
> > | DCL_function of   parameter_t list * typecode_t * asm_t list
> > | BDCL_function of   bparameter_t list * btypecode_t * int list *
> >  exe_t list * name_map_t
> 
> 	I'm not sure how: these two declarations are for variant 
> components of _distinct_ types.
[...]
> John (Max) Skaller, mailto:skaller@maxtal.com.au
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net

Right. I meant you define only one type

type ('parameter, 'b) ast =
   | Function of 'parameter list * typecode_t * 'b;;

Then you define two abbreviations instances of ast to define the types
to which DCL_function and BDCL_function belong:

type dcl = (parameter_t, asm_t list) ast
and bdcl = (bparameter_t, int list * exe_t list * name_map_t) ast;;

That's only an idea: if types are too diffrent the number of type
parameters rapidly becomes excessive.

Regards,

Pierre Weis

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

Re: compilation of lablgl examples.

[Jacques Garrigue]

From: John Max Skaller <skaller@ozemail.com.au>

[See John's post for his detailed expample]
> I.e., polymorphic variants are more useful for prototyping,
> since types do not need to be declared before writing
> algorithms, yet the declarations can still be added later
> when the design is solider to check just how solid it really is.
> 
> At least, this is my expectation. For example, an 'expression'
> type can be defined to include BOTH 'string name' and
> 'name as integer index into symbol table', allowing
> a single routine 'print expression', while it is still
> possible to give a type for 'expression not containing
> any string names' (to be used after all the names are bound).

Well, theoretically yes, but do not forget that early type-checking
plays a great role in making prototyping faster.
Using polymorphic variants partly disables that, by delaying the check
until the call point. This means that you may have a harder to
understand where errors come from.

I suggest you first check the concept on a small example before going
for a full-fledge interpreter.
By the way, I've wrote a paper (almost) on this subject.
See it at http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/

Cheers,

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

Re: compilation of lablgl examples.

[Jacques Garrigue]

From: Peter Ronnquist <pronnquist@yahoo.com>

> I have a problem with compiling the laglgl examples. I
> can run them with the top level:
> lablgl -labels simple.ml
> 
> but 
> 
> ocamlc -I /usr/lib/ocaml/labltk  -I 
> /usr/lib/ocaml/lablGL -I /usr/lib/labltk.cma
> lablgl.cma togl.cmo simple.ml -o program
> 
> gives the following output:
> /usr/bin/ld: cannot find -ltk8.0
> collect2: ld returned 1 exit status
> Error while building custom runtime system
> 
> I have libtk8.0.so.1 in /usr/lib
> so I guess that the library really should be found,
> also the fact that the toplevel works seems to support
> that this library indeed is existing and usable.

At link time you also need a symbolic link libtk8.0.so -> libtk8.0.so.1.
Is it there?
Did you compile lablgl yourself, and how di you modify the Makefile?
The only reason I see is that you would have used a package which
only requires the runtime of tcltk, and not the developper
environment.

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

Re: compilation of lablgl examples.

[Sven LUTHER]

On Tue, Feb 06, 2001 at 11:34:16AM +0900, Jacques Garrigue wrote:
> From: Peter Ronnquist <pronnquist@yahoo.com>
> 
> > I have a problem with compiling the laglgl examples. I
> > can run them with the top level:
> > lablgl -labels simple.ml
> > 
> > but 
> > 
> > ocamlc -I /usr/lib/ocaml/labltk  -I 
> > /usr/lib/ocaml/lablGL -I /usr/lib/labltk.cma
> > lablgl.cma togl.cmo simple.ml -o program
> > 
> > gives the following output:
> > /usr/bin/ld: cannot find -ltk8.0
> > collect2: ld returned 1 exit status
> > Error while building custom runtime system
> > 
> > I have libtk8.0.so.1 in /usr/lib
> > so I guess that the library really should be found,
> > also the fact that the toplevel works seems to support
> > that this library indeed is existing and usable.
> 
> At link time you also need a symbolic link libtk8.0.so -> libtk8.0.so.1.
> Is it there?
> Did you compile lablgl yourself, and how di you modify the Makefile?
> The only reason I see is that you would have used a package which
> only requires the runtime of tcltk, and not the developper
> environment.

I think the problem is already solved.

He was using the debian package of it, and had not installed the developpment
package of tcl/tk.

I am adding them as dependencies for the next package.

Friendly,

Sven Luther

Re: compilation of lablgl examples.

[Peter Ronnquist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2013 bytes --]


--- Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
wrote:
> From: Peter Ronnquist <pronnquist@yahoo.com>
> 
> > I have a problem with compiling the laglgl
> examples. I
> > can run them with the top level:
> > lablgl -labels simple.ml
> > 
> > but 
> > 
> > ocamlc -I /usr/lib/ocaml/labltk  -I 
> > /usr/lib/ocaml/lablGL -I /usr/lib/labltk.cma
> > lablgl.cma togl.cmo simple.ml -o program
> > 
> > gives the following output:
> > /usr/bin/ld: cannot find -ltk8.0
> > collect2: ld returned 1 exit status
> > Error while building custom runtime system
> > 
> > I have libtk8.0.so.1 in /usr/lib
> > so I guess that the library really should be
> found,
> > also the fact that the toplevel works seems to
> support
> > that this library indeed is existing and usable.
> 
> At link time you also need a symbolic link
> libtk8.0.so -> libtk8.0.so.1.
> Is it there?
> Did you compile lablgl yourself, and how di you
> modify the Makefile?
> The only reason I see is that you would have used a
> package which
> only requires the runtime of tcltk, and not the
> developper
> environment.
> 
> Jacques Garrigue
>
---------------------------------------------------------------------------
> Jacques Garrigue      Kyoto University     garrigue
> at kurims.kyoto-u.ac.jp
> 		<A 

Thank you for your help Jacques, as Sven Luther
mentioned he helped me and pointed me to the developer
packages of tcl and tk.

Now I am trying to get the lablgl examples to run
fast. I get accelrated gl with the c version of gears
(900 fps). But the performance of the planet.ml and
tennis.ml is nowhere near this performance. I guess
that dri must be used by lablgl if it is available. 

Do you get good performance? Maybe the drawing in
these examples are done to the window directly and not
to the "back/offscreen" buffer? Thus the slower
performance?

Best Regards
Peter Rönnquist

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

Re: compilation of lablgl examples.

[Sven]

On Wed, Feb 07, 2001 at 04:09:29AM -0800, Peter Ronnquist wrote:
> 
> --- Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
> wrote:
> > From: Peter Ronnquist <pronnquist@yahoo.com>
> > 
> > > I have a problem with compiling the laglgl
> > examples. I
> > > can run them with the top level:
> > > lablgl -labels simple.ml
> > > 
> > > but 
> > > 
> > > ocamlc -I /usr/lib/ocaml/labltk  -I 
> > > /usr/lib/ocaml/lablGL -I /usr/lib/labltk.cma
> > > lablgl.cma togl.cmo simple.ml -o program
> > > 
> > > gives the following output:
> > > /usr/bin/ld: cannot find -ltk8.0
> > > collect2: ld returned 1 exit status
> > > Error while building custom runtime system
> > > 
> > > I have libtk8.0.so.1 in /usr/lib
> > > so I guess that the library really should be
> > found,
> > > also the fact that the toplevel works seems to
> > support
> > > that this library indeed is existing and usable.
> > 
> > At link time you also need a symbolic link
> > libtk8.0.so -> libtk8.0.so.1.
> > Is it there?
> > Did you compile lablgl yourself, and how di you
> > modify the Makefile?
> > The only reason I see is that you would have used a
> > package which
> > only requires the runtime of tcltk, and not the
> > developper
> > environment.
> > 
> > Jacques Garrigue
> >
> ---------------------------------------------------------------------------
> > Jacques Garrigue      Kyoto University     garrigue
> > at kurims.kyoto-u.ac.jp
> > 		<A 
> 
> Thank you for your help Jacques, as Sven Luther
> mentioned he helped me and pointed me to the developer
> packages of tcl and tk.
> 
> Now I am trying to get the lablgl examples to run
> fast. I get accelrated gl with the c version of gears
> (900 fps). But the performance of the planet.ml and
> tennis.ml is nowhere near this performance. I guess
> that dri must be used by lablgl if it is available. 

Just a stupid question, but i assume you are suing the native code compiler, not the bytecode one ?

Friendly,

Sven Luther