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 closed,
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 pr
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 Rac
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 t
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 b
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 `normal-case
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 s
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 i
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 th
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 :
> >>
> >>
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
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 go
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 scheme_se
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()
After thinking about this more, it looks more promising to extend `raco
ctool --cmods` so that it can do a `raco distribute`-like step in
addition to a `raco exe`-like step.
In other words, `raco ctool --cmods` with some extra flag could give
you both a file (as currently, to embed in the executab
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:
Ma
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
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 +0
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 paths
19 matches
Mail list logo