I decided to use OCaml and GTK+ in my recent project. Everything seemed to be
OK, but I found that seemingly there is no way of printing.The application
should be able to print some text reports in
win32 environment.
So I use google to search possible solutions:
http://www.google.com.hk/url?s
Gerd Stolpmann writes:
> I don't know for SML, but OCaml also leaves the order unspecified in
> which function arguments are evaluated (and ocamlc and ocamlopt behave
> even differently in this respect). So I think the problem would
> translate to OCaml in some form.
This is a good point.
A pro
Am Dienstag, den 16.08.2011, 11:55 -0500 schrieb Jeffrey Scofield:
> (One great thing about the ML family is that there
> are exceptionally clear answers to questions like this.
> Especially for Standard ML.)
I don't know for SML, but OCaml also leaves the order unspecified in
which function argum
-[ Tue, Aug 16, 2011 at 05:10:42PM +0100, Richard W.M. Jones ]
> Nevertheless, the C compiler isn't allowed to just push 'list' blindly
> onto the stack and assume it doesn't change across the call to
> 'caml_copy_string'.
For me,
wrp_ml_cons(caml_copy_string(*s), list);
with caml_copy
An aside: In case people want to crib the language, the Racket (formerly PLT
Scheme) manual contains a warning about exactly this problem in the appended
text (Section 3.1.2 of the "Inside: Racket C API" at
http://docs.racket-lang.org/inside/im_memoryalloc.html#(part._im~3a3m~3astack)
). It sh
Török Edwin writes:
> But isn't this 'f(g(), x)' issue the same as the classic example
> of undefined behaviour with f(++i, ++i)?
It's not quite the same, because a function call (g())
introduces a sequence point. In the f(++i, ++i) case,
I think there's only a sequence point after the call
to
On Tue, Aug 16, 2011 at 07:34:31PM +0300, Török Edwin wrote:
> Undefined behaviour doesn't mean it must show different results with -O2,
> it *might* if the compiler decides to do some optimization.
>
> But isn't this 'f(g(), x)' issue the same as the classic example of undefined
> behaviour with
On 08/16/2011 07:27 PM, Richard W.M. Jones wrote:
> Grrr now _my_ program has a bug.
>
> --
> #include
> #include
>
> void f (int a, int b);
> int g (void);
> int *global = NULL;
>
> int
> main (void)
> {
> int x = 1;
> gl
On Tue, 16 Aug 2011, Richard W.M. Jones wrote:
> Grrr now _my_ program has a bug.
>
FWIW i have asked Richard Henderson to share his opinion and he found
nothing wrong with memory.h and/or the OP's code, and believes it's a
compiler bug.
[..snip..]
--
mailto:av1...@comtv.ru
--
Caml-list mai
Grrr now _my_ program has a bug.
--
#include
#include
void f (int a, int b);
int g (void);
int *global = NULL;
int
main (void)
{
int x = 1;
global = &x;
f (g (), x);
exit (0);
}
void
f (int a, int b)
{
printf ("a =
On Tue, Aug 16, 2011 at 08:18:48PM +0400, Dmitry Bely wrote:
> On Tue, Aug 16, 2011 at 8:10 PM, Richard W.M. Jones wrote:
>
> > Well it would certainly help if we had a piece of runnable code to
> > look at. The code supplied in the original email contains an infinite
> > loop.
>
> Yes, that wa
On Tue, Aug 16, 2011 at 8:10 PM, Richard W.M. Jones wrote:
> Well it would certainly help if we had a piece of runnable code to
> look at. The code supplied in the original email contains an infinite
> loop.
Yes, that was my mistake that I corrected later. The loop should be
for (; *s != NULL
On Tue, Aug 16, 2011 at 05:10:42PM +0100, Richard W.M. Jones wrote:
> Well it would certainly help if we had a piece of runnable code to
> look at. The code supplied in the original email contains an infinite
> loop.
I missed there was another email later that contains the
fixed code (s++).
I'm
On Tue, Aug 16, 2011 at 5:06 PM, John Carr wrote:
>
> Richard W.M. Jones wrote:
>
> > On Tue, Aug 16, 2011 at 11:37:03AM +0400, Dmitry Bely wrote:
> > > C compiler first puts "list" pointer on stack and then calls
> > > caml_copy_string(*s), potentially invalidating "list". Of course, the
> > >
On Tue, Aug 16, 2011 at 7:25 PM, Richard W.M. Jones wrote:
> On Tue, Aug 16, 2011 at 11:37:03AM +0400, Dmitry Bely wrote:
>> C compiler first puts "list" pointer on stack and then calls
>> caml_copy_string(*s), potentially invalidating "list". Of course, the
>> stack copy of "list" is not register
On Tue, Aug 16, 2011 at 05:51:38PM +0200, ri...@happyleptic.org wrote:
> -[ Tue, Aug 16, 2011 at 04:25:50PM +0100, Richard W.M. Jones ]
> > I think this must be a bug in your C compiler. The address of list is
> > stashed in the roots struct, so the C compiler should know that list
> > can be
Richard W.M. Jones wrote:
> On Tue, Aug 16, 2011 at 11:37:03AM +0400, Dmitry Bely wrote:
> > C compiler first puts "list" pointer on stack and then calls
> > caml_copy_string(*s), potentially invalidating "list". Of course, the
> > stack copy of "list" is not registered as a global root so wrp_m
Yes. The C compiler can see that the address of list has been passed to
external functions in CAMLlocal, so has to assume the worst: that the address
is stored in some global variable, and caml_copy_string or the functions it
calls can access it and thereby change the value of list. If the com
-[ Tue, Aug 16, 2011 at 04:25:50PM +0100, Richard W.M. Jones ]
> I think this must be a bug in your C compiler. The address of list is
> stashed in the roots struct, so the C compiler should know that list
> can be changed by the call to caml_copy_string.
Are you certain that the C abstract m
On Tue, Aug 16, 2011 at 11:37:03AM +0400, Dmitry Bely wrote:
> C compiler first puts "list" pointer on stack and then calls
> caml_copy_string(*s), potentially invalidating "list". Of course, the
> stack copy of "list" is not registered as a global root so wrp_ml_cons
> gets an invalid value.
I th
Mauricio Fernandez wrote:
> This has been in my mind for a while: why don't CAMLparamX declare the local
> variables as volatile?
That would not help.
Passing the address of a local variable to an external function
warns the compiler that the variable may change when another
external function
[Version française ci-dessous]
The Caml Examples package is a large set of Caml example programs.
Most of the programs are provided both in Objective Caml and in Caml Light.
This new enhanced version of the Caml Examples package contains the complete
set of examples from the book ``Le langage Cam
On Tue, Aug 16, 2011 at 11:37 AM, Dmitry Bely wrote:
(...)
> while (*s != NULL) {
> list = wrp_ml_cons(caml_copy_string(*s), list); /* bug! */
> }
Ah, s increment is missing. The loop should be written as
for (; *s != NULL; s++) {
list = wrp_ml_cons(caml_copy_string(*s),
-[ Tue, Aug 16, 2011 at 01:17:28PM +0300, Török Edwin ]
> So a best practice would be to always use a temporary variable
> registered with CAMLlocal* when you call a function that can potentially
> invoke the GC?
I would say the best practive would be to not call an allocating
function from a
On Tue, Aug 16, 2011 at 01:21:02PM +0400, Dmitry Bely wrote:
> On Tue, Aug 16, 2011 at 12:57 PM, Christophe TROESTLER
> wrote:
> > On Tue, 16 Aug 2011 11:37:03 +0400, Dmitry Bely wrote:
> >> In the line
> >>
> >> list = wrp_ml_cons(caml_copy_string(*s), list); /* bug! */
> >>
>
> Let me e
On 08/16/2011 12:53 PM, Dmitry Bely wrote:
> On Tue, Aug 16, 2011 at 1:46 PM, wrote:
>> -[ Tue, Aug 16, 2011 at 11:43:24AM +0300, Török Edwin ]
>>> 'list' should be reachable via caml_local_roots, so if it really gets an
>>> invalid value
>>> it sounds like a bug to me.
>>
>> list may not be
On Tue, Aug 16, 2011 at 1:46 PM, wrote:
> -[ Tue, Aug 16, 2011 at 11:43:24AM +0300, Török Edwin ]
>> 'list' should be reachable via caml_local_roots, so if it really gets an
>> invalid value
>> it sounds like a bug to me.
>
> list may not be garbage collected (since it is indeed registered a
-[ Tue, Aug 16, 2011 at 11:43:24AM +0300, Török Edwin ]
> 'list' should be reachable via caml_local_roots, so if it really gets an
> invalid value
> it sounds like a bug to me.
list may not be garbage collected (since it is indeed registered as the
root), but it may be moved arround (ie promo
On Tue, Aug 16, 2011 at 12:57 PM, Christophe TROESTLER
wrote:
> On Tue, 16 Aug 2011 11:37:03 +0400, Dmitry Bely wrote:
>>
>> I would like to share my experience of writing bad C bindings. The
>> following code is wrong, although no "living in harmony with the
>> garbage collector" rule seems to be
On 08/16/2011 11:25 AM, Dmitry Bely wrote:
> 2011/8/16 Török Edwin :
>> On 08/16/2011 10:37 AM, Dmitry Bely wrote:
>>> I would like to share my experience of writing bad C bindings. The
>>> following code is wrong, although no "living in harmony with the
>>> garbage collector" rule seems to be viol
Hello Jacques,
Le 08/08/2011 09:14, Jacques Garrigue a écrit :
On 2011/08/05, at 1:22, Sébastien Furic wrote:
What is the usual way in OCaml to define mutually recursive classes that share
default instances?
There is no concept of "default instance" in OCaml, and as you discovered
yoursel
2011/8/16 Török Edwin :
> On 08/16/2011 10:37 AM, Dmitry Bely wrote:
>> I would like to share my experience of writing bad C bindings. The
>> following code is wrong, although no "living in harmony with the
>> garbage collector" rule seems to be violated:
>>
>> value wrp_ml_cons (value v, value l)
On 08/16/2011 10:37 AM, Dmitry Bely wrote:
> I would like to share my experience of writing bad C bindings. The
> following code is wrong, although no "living in harmony with the
> garbage collector" rule seems to be violated:
>
> value wrp_ml_cons (value v, value l)
> {
> CAMLparam2(v, l);
>
I would like to share my experience of writing bad C bindings. The
following code is wrong, although no "living in harmony with the
garbage collector" rule seems to be violated:
value wrp_ml_cons (value v, value l)
{
CAMLparam2(v, l);
CAMLlocal1(cell);
cell = caml_alloc_small(2, Tag_cons);
Hello,
New version of llpp is now available (tagged v7) at
http://repo.or.cz/w/llpp.git
Blurb:
llpp a graphical PDF viewer which aims to superficially resemble
less(1)
Changes (relative to v5):
* Human readable/editable configuration file
* Optional (default on) proportional display (for docum
35 matches
Mail list logo
