From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Jesper Louis Andersen <jesper.louis.andersen@gmail.com>
Cc: Anthony Tavener <anthony.tavener@gmail.com>,
"caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Occasional malformed strings; OCaml -> OpenGL, via tgls/ctypes.
Date: Sun, 8 May 2016 18:52:33 -0400 [thread overview]
Message-ID: <CAPFanBEa0QVDxp3fMsysfPgc=W90KL+RLw6Y109XT_D2TCnA3w@mail.gmail.com> (raw)
In-Reply-To: <CAGrdgiUnEGHmA8uGgH9KQ+kcOB9=0+GONTihMGk9Paj6jZmx2A@mail.gmail.com>
On Sun, May 8, 2016 at 5:04 PM, Jesper Louis Andersen
<jesper.louis.andersen@gmail.com> wrote:
> The problem there is too aggressive optimization on an ignore statement,
> but if the OpenGL bindings, or flambda is to blame is a bit up in the air to me.
If you look at the corresponding commit:
https://github.com/LaurentMazare/tensorflow-ocaml/commit/111b4727cec992bab8bc67c22ccc8c31942ffbb2
It seems clear to me that the code was making un-portable assumptions
on the fact that using (ignore l) in a closure would force l to remain
live. It is not a bug of flambda if these kind of assumptions are
broken. (On the other hand, the fact that flambda breaks a lot of the
"probably too clever for its own good" code out there suggests that
one should be careful when adopting it.)
Note the nice trick to use the new 4.03 function opaque_identity in a
way that still works on older OCaml versions:
+ (* [opaque_identity] is not available pre 4.03, this hack ensure
that it + exists. *)
+ let opaque_identity x = x
+ let _ = opaque_identity
+ let opaque_identity = let open Sys in opaque_identity
On older versions, this is just a rebinding, on newer version this
uses "let open" shadowing.
(I suspect that the warnings that try to detect involuntary shadowing
may fire on this code, now or in the future.
Speaking of code slightly too clever for its own good...)
On Sun, May 8, 2016 at 5:04 PM, Jesper Louis Andersen
<jesper.louis.andersen@gmail.com> wrote:
>
> On Sun, May 8, 2016 at 7:08 PM, Anthony Tavener <anthony.tavener@gmail.com>
> wrote:
>>
>> TL;DR: Constant string like "fontColor" can (rarely) come out like
>> "\220\552\663\1" after foreign call to OpenGL.
>
>
> It may be flambda-related, as the following problem looks much like it:
>
> https://github.com/LaurentMazare/tensorflow-ocaml/issues/7
>
> I hit that last week with flambda. The problem there is too aggressive
> optimization on an ignore statement, but if the OpenGL bindings, or flambda
> is to blame is a bit up in the air to me.
>
>
> --
> J.
next prev parent reply other threads:[~2016-05-08 22:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 17:08 Anthony Tavener
2016-05-08 21:04 ` Jesper Louis Andersen
2016-05-08 22:52 ` Gabriel Scherer [this message]
2016-05-09 4:52 ` Jeremy Yallop
2016-05-09 5:32 ` Anthony Tavener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPFanBEa0QVDxp3fMsysfPgc=W90KL+RLw6Y109XT_D2TCnA3w@mail.gmail.com' \
--to=gabriel.scherer@gmail.com \
--cc=anthony.tavener@gmail.com \
--cc=caml-list@inria.fr \
--cc=jesper.louis.andersen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox