Thanks.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
Hi!
I have applied the changes to env.c and thread.c with a
minor modification in thread.c (FUTURES instead MZRT!)):
-#ifdef MZ_USE_FUTURES
+#if defined(MZ_USE_FUTURES) && !defined(DONT_USE_FOREIGN)
I get now the following errors:
-
Are there any plans to fix text highlighting on Windows, please? (It's bug
9202/10166: in Racket 5.0 on Windows 7, highlighted text is poorly rendered
whatever rendering settings in DrRacket or Windows are used.) As far as I can
tell, this is the only thing making Racket unsuitable for desktop apps
Operating System(s): Ubuntu 10.04 running as a guest on VMWare Fusion
3.1.0 on Mac OS X 10.6.4
Hardware: MacBook Pro, 2.66 GHz Intel Core i7, 4GB memory
Running DrRacket from the prebuilt Ubuntu package available at
www.racket-lang.org
VMWare has a feature by which the guest OS (Ubuntu 10.04)
On Tue, Jul 13, 2010 at 6:39 PM, Greg Hendershott
wrote:
> OK mister smartypants. :)
Indeed! :)
> I set the limit back to 1024 MB.
>
> And ... it crashed again DrRacket again.
That limit is probably high enough to be ineffective as an actual
limit. I don't understand the precise connection betw
OK mister smartypants. :)
I set the limit back to 1024 MB.
And ... it crashed again DrRacket again.
Just like it did back when I decided to try setting it to "unlimited"
in the first place, to avoid this happening.
Seriously, is the idea that users are supposed to:
[1] Understand the maximum me
The main obstacle was that operations like `raco make' and `raco setup'
needed SHA-1 hashing from OpenSSL via the FFI.
I've adjusted several things so that `make' and `make install' can
work when the FFI is disabled:
* A new `file/sha1' library ports Eric Knauel's implementation of
SHA-1 to R
This is what the memory limit is for! If you disable it, you no longer
have that barrier. :)
Robby
On Tue, Jul 13, 2010 at 5:07 PM, Greg Hendershott
wrote:
> A couple more observations:
>
> [1] I'm spending a lot of time staring at the GC log scrolling by in
> DrRacket. I'm seeing many examples
A couple more observations:
[1] I'm spending a lot of time staring at the GC log scrolling by in
DrRacket. I'm seeing many examples where the amount collected is
negative. Ex:
GC [minor] at 1028656788 bytes; 4636116 collected in 47 msec
GC [minor] at 1025017408 bytes; -3872 collected in 15 msec
G
On Tue, Jul 13, 2010 at 2:05 PM, Greg Hendershott
wrote:
> Hey wait a second. Aren't Racket pointers a couple bits less than 32?
> Like, say, 30 bits? And that's 1 GB address space? Q.E.D. ... ?
Racket uses the "odd" pointers to represent small integers, but I
don't think that matters much her
Although it makes sense that a 32-bit pointer can address only 4 GB
(virtual or physical, regardless). I agree it's odd that you get only
2 of the 4 GB address space for your app under Win64 and the other 2
is reserved for the system. Of course the clear way forward is to make
a 64-bit app, I don't
I run DrRacket on Window 7 premium home and can go up to 2 Gb. (I have a
dual core 32 bit processor, 4 Gb memory of which 3 Gb for applications)
What amazes me is, that when setting memory unlimited, DrRacket can't go
over 2 Gb. In stead, when passing this limit, DrRacket is aborted by windows
7. (
Call for Papers
===
13th International Symposium on
Practical Aspects of Declarative Languages (PADL 2011)
http://www.dcc.fc.up.pt/PADL-2011
Austin, Texas, USA, January 24-25,
Kevin Tew wrote at 07/13/2010 12:19 PM:
the 3m variant still doesn't build do to more reliance on the ffi
during xform. setup is also going to try to use the ffi.
We have added additional dependencies on the ffi (foreign function
interface) and need to decide if we are going to support build
Thanks Matthew. This was Racket 5.0. I swore "unlimited" was set in
DrRacket GUI. Maybe some bug where that was ignored? I'll check again
but meanwhile I reverted temporarily to PLT Scheme 4.2.5. Another git
bisect turned up a point where the behavior changed (before that I
wasn't running out of m
> No, you have real talent! (Do people still do ASCII art by hand? I
> thought programs had taken over.)
Oh yes but artisans have mostly moved on to Unicode. Plus this avant
garde splinter group is making QR codes out of Kanji, which in turn
are composed into representations of Campbell's soup can
Ok I tried compiling with your configure line myself.
I had to make an additional change to get racket/racketcgc to build.
the 3m variant still doesn't build do to more reliance on the ffi
during xform.
setup is also going to try to use the ffi.
We have added additional dependencies on the ff
Try this patch, if it works for you. I'll commit it
Kevin
diff --git a/src/racket/src/env.c b/src/racket/src/env.c
index b1c0a8d..68b634b 100644
--- a/src/racket/src/env.c
+++ b/src/racket/src/env.c
@@ -501,7 +501,9 @@ static Scheme_Env *place_instance_init(void
*stack_base, int initial_main_o
Hi folks!
I have tried to compile Racket on Maemo 5 (<--> Nokia N900).
Following the usual configure and make schema I have proceeded
as follows:
# cd plt-5.0/src/build
# ../configure --prefix=/home/user/local/racket-5.0 --without-x
--disable-gracket --disable-foreign
# make
...
...
a - src/
At Mon, 12 Jul 2010 16:55:17 -0400, Greg Hendershott wrote:
> Ah. If the GC needs 2X actual that would explain 2 GB --> 1 GB usable.
> That's a shame but I understand.
I don't think that's it. If you have a memory limit set, then there's a
factor of 2 involved, but that doesn't apply when you don'
On Mon, Jul 12, 2010 at 9:55 PM, Greg Hendershott
wrote:
>
> Yeah I'll keep my day job rather than pursue a career in ASCII art.
No, you have real talent! (Do people still do ASCII art by hand? I
thought programs had taken over.)
> During which lots of
> little ~30 msec GCs (according to DrRacke
21 matches
Mail list logo
