headers
Laurent Chéno | 1 Jul 1996 19:48
Picon
Picon

Re: Lettre de Caml #4


> Hello everybody,
>
> I would like to correct the formula page 3 in the "Lettre de Caml" #4 :
>
> we read :
>
>     for each k in {0,..,m-1} t_{i+k} = s_{i}
>
> the right formula is :
>
>     for each k in {0,..,m-1} t_{k} = s_{i+k}
>
>  t is the motif: i+m<n.
>  string_length s returns n
> and string-length t returns m.
>
>-- Younes El Amrani.
(excuse my very poor english, thank's)
I apologize. I have miswritten t for s... but the Caml programs run well :
I have tried all !

Best regards, Laurent Cheno
Permalink | Reply | 0 comments |
headers
Mark Hayden | 4 Jul 1996 08:55
Picon
Favicon

an ocaml performance test


  Several months back I asked this mailing list
if anyone had any tests for gauging the
performance of basic operations in ocaml.  I got
some responses, but no data, so I put together a
test program, which I'm posting for others who
might be interested.  The tests are intended to
give a sense of relative costs of similar
operations within ocaml.  The output was
gathered by running the program on a
sparcstation 10 from Ocaml 1.01, compiled with
the "ocamlopt -unsafe".
  The numbers in the table are meaningless on
their own.  The test program below should also
be examined to see exactly what is being
measured.
  Many of the tests are straightforward to
interpret.  For example, it appears that
scanning an array with Array.iter is
considerably slow than with a for loop.  I'm not
sure, however, how to interpret the tests
measuring the performance of function
application to various kinds of closures (marked
"partial" in the table).  I have some guesses,
but I would appreciate an explanation from
someone who knows what is going on.

thanks, Mark Hayden

OUTPUT
(Continue reading)

Permalink | Reply | 0 comments |
headers
licence informatique | 4 Jul 1996 17:17
Picon

Utilisation de


Bonjour

J'utilise CamlTk 4.0 (version mai 96)

Je souhaite utiliser une fonction retournant une valeur avec l'option Command
dans un menu;
par exemple :
	menu__add_command m [Label "Essai"; Command (let t = f(n))];

Il s'avere que cette instruction ne fonctionne pas car, l'option Command accepte
que les fonctions de type unit -> unit; 
Est-il possible de resoudre ce probleme sans utiliser des variables globales mutables ?

	Merci.

-- David HENRY --- Licence Informatique --
----------------------------- UBO BREST --
Permalink | Reply | 2 comments |
headers
Francois Rouaix | 5 Jul 1996 19:44
Picon
Picon

Re: Utilisation de


Cher usager,

> Je souhaite utiliser une fonction retournant une valeur avec l'option Command
> dans un menu;
> par exemple :
> 	menu__add_command m [Label "Essai"; Command (let t = f(n))];
> 
> Il s'avere que cette instruction ne fonctionne pas car, l'option Command
> accepte que les fonctions de type unit -> unit; 

De toutes facons elle est syntaxiquement incorrecte.
Les callbacks (Command ou autres) ne retournent jamais de valeur, pour
la simple raison que leur appelant est la boucle mainLoop de Tk. Ca n'a donc
pas de sens de renvoyer une valeur, sauf si la specification du callback
demande une valeur de retour (ce qui n'est jamais le cas pour la partie
standard de Tk). D'ou le -> unit pour tous les types de callbacks.

> Est-il possible de resoudre ce probleme sans utiliser des variables globales 
> mutables ?
Les callback sont par essence des fonctions qui produisent des effets de bord.
On utilise effectivement assez souvent des references ou des valeurs mutables
dans ce type de situation. La reference n'a pas forcement besoin d'etre
definie globalement bien sur, il suffit qu'elle ait la bonne portee.

----
Dear user,

[The question was about the inability to return values from callbacks]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jun P. Furuse | 5 Jul 1996 19:54
Picon

Re: Utilisation de


> J'utilise CamlTk 4.0 (version mai 96)
> 
> Je souhaite utiliser une fonction retournant une valeur avec l'option Command
> dans un menu;
> 
> par exemple :
> 	menu__add_command m [Label "Essai"; Command (let t = f(n))];
> 
> Il s'avere que cette instruction ne fonctionne pas car, l'option Command 
> accepte que les fonctions de type unit -> unit; 
> 
> Est-il possible de resoudre ce probleme sans utiliser des variables globales 
> mutables ?

I am sorry that my answer is in English. I just started learning French,
and I probably understand your question, but it is difficult to answer
in French for me ;-).

I think this is impossible. In general event driven programming, you
can not define values in callback functions and export them out of the
functions.  

 	let g = fun t -> t
	in 
	  menu__add_command m [Label "Essai"; Command (let t = f(n))];
	  ...;
	  g t

Of course it is wrong syntax. But even if it were correct, the value
(Continue reading)

Permalink | Reply | 0 comments |
headers
ESPERET PHILIPPE | 14 Jul 1996 08:32
Picon

Context-free in Caml


% camlist8.tex 14-7-1996 (9h:32)

                +-------------------------------------+
                |     Philippe Esperet (France)       |
                |    100060.2106 <at> compuserve.com       |
                |                                     |
                +-------------------------------------+

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Liste Caml light
email caml-light <at> pauillac.inria.fr
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
sujet : Context-free

   Has somebody written a package in Caml dealing with
context-free grammars (including the classical algorithms :
simplification, Chomsky, Griebach, CYK, Early...) ?

   Best regards
Permalink | Reply | 0 comments |
headers
Ernesto Posse | 17 Jul 1996 01:32
Picon

ocamldep


Hello everybody. I have been having a little trouble with the Dependency 
Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml. 
The reference manual says that the typical use of ocamldep should be 
something like this:

	ocamldep *.mli *.ml > .depend

The problem is that ocamldep doesn't seem to recognize the *.mli and 
*.ml arguments and I have to list explicitly all of my project files but 
I get a "line too long" error from the line command interpreter. (a 
MS-DOS window).

Does anyone know what the problem is and how could it be solved? Thank 
you. 

And by the way, I suppose someone already made the following suggestion 
but it would be very useful to have a "compile" option and a "make" 
option on the menus of ocamlwin.

I'm sorry if someone already asked this question, I've just joined the 
list and I didn't find anything like this in the FAQ.

I'm also sorry not to include a French abstract of the question but my 
knowledge of the French language is restricted to "Je ne parle pas 
France".

--

-- 
Ernesto Posse
Estudiante de Ingeniería de Sistemas y Computación
(Continue reading)

Permalink | Reply | 4 comments |
headers
Xavier Leroy | 18 Jul 1996 15:33
Picon
Picon

Re: ocamldep


> Hello everybody. I have been having a little trouble with the Dependency 
> Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml. 
> The reference manual says that the typical use of ocamldep should be 
> something like this:
> 
> 	ocamldep *.mli *.ml > .depend
> 
> The problem is that ocamldep doesn't seem to recognize the *.mli and 
> *.ml arguments

Well, the Objective Caml sources come from a Unix background, where
wildcards (*.ml) are expanded by the command shell and the commands
receive an already-expanded argument list. One day I may add
command-line expansion in the Objective Caml start-up code, but don't
hold your breath.

> and I have to list explicitly all of my project files but 
> I get a "line too long" error from the line command interpreter. (a 
> MS-DOS window).

I thought Win32 finally raised the length limit on the command line to
some reasonable value like 4k. At any rate, you can always split the
call to ocamldep thus:

        ocamldep [some files] > .depend
        ocamldep [more files] >> .depend
        ...

Also, a "for" loop may work, for instance
(Continue reading)

Permalink | Reply | 2 comments |
headers
Georg Bauer | 17 Jul 1996 20:21
Picon

ocamldep


Hi!

EP>And by the way, I suppose someone already made the following suggestion 
EP>but it would be very useful to have a "compile" option and a "make" 
EP>option on the menus of ocamlwin.

Actually my DOS-port does have a #compile command for the OCAML interactive
environment. It's easy since you need much of the modules aready to build
OCAML. I didn't include a make facility, because then I would have to
integrate the functionality of ocamldep. Hmm. I should think of that, it
would help much ;-)

bye, Georg
Permalink | Reply | 0 comments |
headers
Ian T Zimmerman | 19 Jul 1996 03:27
Picon

Re: ocamldep


In article <199607181333.PAA14029 <at> pauillac.inria.fr> Xavier Leroy
<Xavier.Leroy <at> inria.fr> writes:

> 
> 
> > Hello everybody. I have been having a little trouble with the Dependency 
> > Generator ocamldep that comes in the Windows 95 version 1.01 of O'Caml. 
> > The reference manual says that the typical use of ocamldep should be 
> > something like this:
> > 
> > 	ocamldep *.mli *.ml > .depend
> > 
> > The problem is that ocamldep doesn't seem to recognize the *.mli and 
> > *.ml arguments
> 

> Well, the Objective Caml sources come from a Unix background, where
> wildcards (*.ml) are expanded by the command shell and the commands
> receive an already-expanded argument list. One day I may add
> command-line expansion in the Objective Caml start-up code, but
> don't hold your breath.

> > and I have to list explicitly all of my project files but 
> > I get a "line too long" error from the line command interpreter. (a 
> > MS-DOS window).
> 

> I thought Win32 finally raised the length limit on the command line
> to some reasonable value like 4k. At any rate, you can always split
(Continue reading)

Permalink | Reply | 1 comment |

Gmane