I found another place where case-normalization of paths was not handled
correctly.
Your example now works for me with a snapshot build. Can you try the
latest?
At Sun, 15 Nov 2015 17:57:43 +0300, Dmitry Pavlov wrote:
> Matthew,
>
> >>> [...] So, if the immediate
> >>> repair doesn't solve the
Matthew
On 11/17/2015 03:50 PM, Matthew Flatt wrote:
I found another place where case-normalization of paths was not handled
correctly.
Your example now works for me with a snapshot build. Can you try the
latest?
Yes the latest build works! Thank you very much.
The case can be finally
Matthew,
[...] So, if the immediate
repair doesn't solve the problem for you, a follow-up change might.
[...]
Is it e3d78e4, or it is to be done yet?
Yes, it's e3d78e4.
I hate to tell you this, but the error still remains in the
latest nightly build, Windows i386:
>racket
Welcome to
At Sun, 15 Nov 2015 13:24:07 +0300, Dmitry Pavlov wrote:
> On 11/13/2015 06:33 PM, Matthew Flatt wrote:
> > [...] So, if the immediate
> > repair doesn't solve the problem for you, a follow-up change might.
>
> [...]
> Is it e3d78e4, or it is to be done yet?
Yes, it's e3d78e4.
--
You received
Matthew,
On 11/13/2015 06:33 PM, Matthew Flatt wrote:
I've pushed a change that may solve this problem.
The change was to the way that `--runtime` determines a shared path
prefix among runtime files, so that it can copy them to a new place but
keep relative paths intact. On Windows, the paths
I've pushed a change that may solve this problem.
The change was to the way that `--runtime` determines a shared path
prefix among runtime files, so that it can copy them to a new place but
keep relative paths intact. On Windows, the paths being compared were
sometimes normalized with
Matthew,
I am reviving this 6-week-old discussion about
raco and runtime paths.
That time, I did not go through with it on Windows.
In my Windows build, I used raco ctool without the --runtime
option, leaving the library tied to absolute paths in the system.
Now I am willing to accomplish the
At Sun, 20 Sep 2015 16:08:48 -0600, Matthew Flatt wrote:
> > I just tried the 32-bit Utah snapshot and 32-bit C app -- build OK,
> > but the app crashed right on scheme_main_setup with zero pointer
> > access. It did not even enter my "run" function.
>
> My initial guess is that it's related to
I just tried the 32-bit Utah snapshot and 32-bit C app -- build OK,
but the app crashed right on scheme_main_setup with zero pointer
access. It did not even enter my "run" function.
My initial guess is that it's related to thread-local storage and
missing instructions in "Inside". I'll look
Matthew,
I've added a `--runtime ` argument to `raco ctool --cmods`, which
gathers runtime files into and makes the embedded modules refer
to them in (which is expected to be relative to the executable,
but see also the `--runtime-access` option).
The embedding executable must call
At Mon, 21 Sep 2015 01:04:15 +0300, Dmitry Pavlov wrote:
> Matthew,
>
> On 09/21/2015 12:38 AM, Matthew Flatt wrote:
> > At Sun, 20 Sep 2015 23:53:42 +0300, Dmitry Pavlov wrote:
> >> On Windows, though, I ran into a problem when linking my app
> >> with pre-built libracket3m_9yy8mp.lib :
> >>
>
At Sun, 20 Sep 2015 23:53:42 +0300, Dmitry Pavlov wrote:
> On Windows, though, I ran into a problem when linking my app
> with pre-built libracket3m_9yy8mp.lib :
>
> error LNK2001: unresolved external symbol __imp_scheme_get_mz_setjmp
>
> That is the only unresolved symbol. All the others were
Matthew,
On 09/21/2015 12:38 AM, Matthew Flatt wrote:
At Sun, 20 Sep 2015 23:53:42 +0300, Dmitry Pavlov wrote:
On Windows, though, I ran into a problem when linking my app
with pre-built libracket3m_9yy8mp.lib :
error LNK2001: unresolved external symbol __imp_scheme_get_mz_setjmp
That is the
I've added a `--runtime ` argument to `raco ctool --cmods`, which
gathers runtime files into and makes the embedded modules refer
to them in (which is expected to be relative to the executable,
but see also the `--runtime-access` option).
The embedding executable must call scheme_set_exec_cmd()
Hello,
I just created a C program that uses my Racket library via
Racket's embedding mechanism, and it works fantastic.
Now I am wondering---how to ship my C program's
executable if the underlying Racket library has runtime
paths in it? The executable seems to have been set up for
absolute
The most likely solution is to make the executable look enough like a
"PLT executable", but I'll have to try it out to pin down additions
that will work.
Are you interested in this only for Unix variants or for all platforms?
I think Windows will be more difficult.
At Wed, 16 Sep 2015 14:26:41
Matthew,
The most likely solution is to make the executable look enough like a
"PLT executable", but I'll have to try it out to pin down additions
that will work.
Are you interested in this only for Unix variants or for all platforms?
I think Windows will be more difficult.
Thank you for the
Also, if it matters, I usually make my Windows builds on Linux
with MinGW (i686-w64-mingw32-gcc, x86_64-w64-mingw32). But I can
use Visual Studio too, I guess, if that will make things easier
for raco distribute or whatever.
Best regards,
Dmitry
On 09/16/2015 03:52 PM, Dmitry Pavlov wrote:
18 matches
Mail list logo
