Indeed it does. Sorry for not thinking of that first!
-Nick
On Thu, Oct 2, 2014 at 12:59 PM, Matthew Flatt wrote:
> The latest should work. Please try a snapshot:
>
> http://pre.racket-lang.org/
>
>
> At Thu, 2 Oct 2014 12:55:50 -0700, Nick Sivo wrote:
>> Figured I&#x
Figured I'd wait until OS X Yosemite was closer to release before
mentioning this, but DrRacket 6.1 doesn't run on it. Now that Yosemite
has reached Release Candidate status is there anyone I can invite to
my Apple Developer Team so they can look into it? I'd try to track it
down myself but don't h
Hello,
I'm using call-with-atomic-output-file, and noticed a discrepancy in
the documentation and observed behavior.
http://docs.racket-lang.org/reference/Filesystem.html suggests that it
"Opens a temporary file for writing in the same directory as file ...
and then atomically moves the temporary
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 wrote:
> Hi,
>
> When building Racket from source on FreeBSD 9.1, I get the following errors:
>
> gcc -o racketcgc main
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':
/usr/nick/git/racket/src/build/racket/src/../../../racket/src/number.c:3461
I've had success both with the settings and normalization process
described here:
https://help.github.com/articles/dealing-with-line-endings
It comes up a lot since I work on Windows, Mac, and FreeBSD pretty regularly.
-Nick
On Tue, Dec 11, 2012 at 8:08 AM, Eli Barzilay wrote:
> Yesterday, Mat
Hi Everyone,
I'm trying to add support for per-thread allocation accounting to aid
in some performance debugging. I've already instrumented the GC and
can retrieve the statistics via hacks I added to current-memory-use.
I'm running into trouble reverting current-memory-use and instead
adding a p
Hello,
I'm optimizing some code and have used gc-info logging
to correlate substantial application pauses with GC occurrences. This make
sense. The obvious solution is to allocate less memory, but tracking down
where it's coming from isn't easy. In the short term I plan to inject
(current-memor
8 matches
Mail list logo
