The standard on modern unix systems is to name the shared libraries with
this pattern: lib + name + .so. + major version + . + minor
version. Racket uses libracket-5.3.6.so. It isn't correct.
-rwxr-xr-x 1 root wheel 9.0M Aug 17 04:28
/usr/local/lib/libracket3m-5.3.6.so
-rw-r--r-- 1 root
I've since changed to using a dynamic-require, but still the memory limit is
not respected. Why wouldn the globals from a dynamic-require be considered
reachable outside the sandbox that calls dynamic-require? There's no other way
to get it.
-Ian
- Original Message -
From: J. Ian
The namespace...?
On Wed, Sep 11, 2013 at 2:20 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
I've since changed to using a dynamic-require, but still the memory limit
is not respected. Why wouldn the globals from a dynamic-require be
considered reachable outside the sandbox that calls
Just so we're clear, this should not OOM, but rather print #t?
#lang racket/load
(module A racket
(provide global go)
(define global '())
(define (go) (set! global (cons (random) global)) (go)))
(module B racket
(require racket/sandbox)
(display
(with-handlers ([exn:fail:resource? (λ
Okay, stamourv made your response make sense. I added parameterize
([current-namespace (make-base-namespace)]) inside the thunk, and it works.
Albeit ''A was no longer a valid module path in #lang racket/load, it works for
files.
What is the right way to refer to module A in racket/load,
What does it mean to refer to module A in racket/load?
I think maybe there's some confusion about what role namespaces play and
how they work in Racket? I will try to explain. The basic idea is that a
namespace is a table mapping module names (A in this example) to actual
modules (it also maps
An hour ago, J. Ian Johnson wrote:
Okay, stamourv made your response make sense. I added parameterize
([current-namespace (make-base-namespace)]) inside the thunk, [...]
If you're going down that road (which makes sense, of course), then it
would probably be much easier to just use the full
Hi,
When building Racket from source on FreeBSD 9.1, I get the following errors:
gcc -o racketcgc main.o libracket.a libmzgc.a -pthread -lm
-rdynamic -L/usr/local/lib -lffi
libracket.a(number.o): In function `sch_powl':
Disabling extflonums (--disable-extflonums) seems to have it working
now. Are they unsupported on FreeBSD x64?
-Nick
On Wed, Sep 11, 2013 at 5:02 PM, Nick Sivo nicks...@gmail.com wrote:
Hi,
When building Racket from source on FreeBSD 9.1, I get the following errors:
gcc -o racketcgc main.o
We discussed this idea early on -- based on work by Casey and Robby and our own
reasoning -- and I am pretty sure it was on your list. If it is not there, we
should bring it in quickly. This should improve performance quite a bit. --
Matthias
On Sep 10, 2013, at 4:59 AM, Sam Tobin-Hochstadt
10 matches
Mail list logo
