[racket-dev] Memory consumption of Racket

[Nevo]

hi
  My attempt on porting Racket interpreter to iOS has been for a while and
I've been able to run interpreter on both iOS device as well iOS simulator.
Right now, it runs perfectly on iOS simulator, but lack of satisfaction on
device. The reason is for those devices like iPad/iPhone or Android, the
memory for standalone application is always constrained, and even a single
"hello world" evaluation would easily put the whole app runtime to death,
per my test. In particular, here I've got some commented out "printf" code
compiled in for newgc.c, and trying to load a simple "hello world" racket
file to evaluate results in more than 30MB memory in use (reported by gc).
This is nothing for a desktop, but will kill itself easily in iOS which
usually requires the average memory allocation will be less than 20MB. So
I'm asking if there's some known compiling or runtime configuration which I
may not know to reduce memory usage, at least keep average allocation
acceptable for those memory constrained devices. Thanks for your suggests
here!

Nevo
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] arrows missing from check syntax?

[Eli Barzilay]

This is probably on a linux -- and is a problem that I reported as
part of PR 11778 (and probably better to file a new one, to make it
more visible, since it doesn't really belong in 11778).  The short
story is that the arrows are not drawn on the screen, but if you force
a redraw of DrRacket somehow you'll see them.


5 hours ago, Robby Findler wrote:
> Uhh.. no. But I see them, as attached. That's a mac with an older
> version than yours; I've also checked the release candidate under
> windows with the same program and they were there.
> 
> Robby
> 
> On Thu, Apr 21, 2011 at 4:42 PM, Danny Yoo  wrote:
> > The lexical scoping arrows seem to be missing from Check
> > Syntax.  Is this deliberate?  Currently using
> > 5.1.1.3--2011-04-21.  Thanks!

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Robby Findler]

On Thu, Apr 21, 2011 at 7:42 PM, Robby Findler
 wrote:
> On Wed, Apr 20, 2011 at 10:41 PM, Ryan Culpepper  wrote:
>> * Robby Findler 
>>  - DrRacket Tests
>
> all passed except tests/drracket/test-engine-test.rkt and I'll be
> looking into that one.

This is now fixed.

Those of you who do teaching-related language tests please re-run
after this change (sorry).

Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Build failure on OS X

[Eric Dobson]

It looks like it was a problem with libffi, which was also out of date in my 
macports. I upgraded it before your email, and the build got past that point 
where it was failing. Hopefully it won't have any more problems. 

Thanks for the help.

-Eric


On Apr 21, 2011, at 10:17 PM, Matthew Flatt wrote:

> The recent change to `configure' makes it use `pkg-config' to add -L
> and -I flags for libffi. But those should flags be added consistently;
> that is, you should end up with a build that uses `libiconv' from
> macports.
> 
> Did you run `configure' in a fresh build directory? If not, maybe you
> have files leftover from a previous build that had different flags from
> `configure'?
> 
> If not, can you show the compile line for "string.c"?
> 
> At Thu, 21 Apr 2011 22:01:31 -0400, Eric Dobson wrote:
>> I don't have any *FLAGS variables set in my environment when I run configure 
>> or 
>> make. But I do have libiconv installed through macports. It was out of date, 
>> and I upgraded it, but now I am getting a different message:
>> 
>> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
>> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  
>> -liconv 
>> -L/opt/local/lib -lffi   
>> ld: warning: in /opt/local/lib/libiconv.dylib, file was built for 
>> unsupported 
>> file format which is not the architecture being linked (i386)
>> Undefined symbols:
>>  "_iconv_close", referenced from:
>>  _do_convert in libracket.a(string.o)
>>  _do_convert in libracket.a(string.o)
>>  _do_convert in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _close_converter in libracket.a(string.o)
>>  "_iconv_open", referenced from:
>>  _do_convert in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _scheme_open_converter in libracket.a(string.o)
>>  "_iconv", referenced from:
>>  _do_convert in libracket.a(string.o)
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>> 
>> (Note the warning about a different architecture.)
>> 
>> I assume that If I tell it to use the system version of iconv, things will 
>> work 
>> out. But how do I tell it to ignore the bad version?
>> 
>> -Eric
>> 
>> 
>> 
>> On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote:
>> 
>>> It looke like you have `-L/opt/local/lib' in your LDFLAGS
>>> configuration. Do you also have `-I/opt/local/include' in CPPFLAGS?
>>> 
>>> You machine is probably like mine, where you have two installations of
>>> libiconv, and this error happens when the C headers of one installation
>>> get mixed with the lib of the other.
>>> 
>>> At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote:
 I tried to build the git HEAD today and ran into problems. During the make 
 process, it fails to create the framework with the following error message:
 
 gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
 CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  
>> -liconv 
 -L/opt/local/lib -lffi   
 Undefined symbols:
 "_iconv_close", referenced from:
 _do_convert in libracket.a(string.o)
 _do_convert in libracket.a(string.o)
 _do_convert in libracket.a(string.o)
 _string_to_from_locale in libracket.a(string.o)
 _string_to_from_locale in libracket.a(string.o)
 _string_to_from_locale in libracket.a(string.o)
 _close_converter in libracket.a(string.o)
 "_iconv_open", referenced from:
 _do_convert in libracket.a(string.o)
 _string_to_from_locale in libracket.a(string.o)
 _string_to_from_locale in libracket.a(string.o)
 _scheme_open_converter in libracket.a(string.o)
 "_iconv", referenced from:
 _do_convert in libracket.a(string.o)
 ld: symbol(s) not found
 collect2: ld returned 1 exit status
 
 Does anyone know what might cause this?
 
 Thanks,
 Eric
 
 
 _
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Build failure on OS X

[Matthew Flatt]

The recent change to `configure' makes it use `pkg-config' to add -L
and -I flags for libffi. But those should flags be added consistently;
that is, you should end up with a build that uses `libiconv' from
macports.

Did you run `configure' in a fresh build directory? If not, maybe you
have files leftover from a previous build that had different flags from
`configure'?

If not, can you show the compile line for "string.c"?

At Thu, 21 Apr 2011 22:01:31 -0400, Eric Dobson wrote:
> I don't have any *FLAGS variables set in my environment when I run configure 
> or 
> make. But I do have libiconv installed through macports. It was out of date, 
> and I upgraded it, but now I am getting a different message:
> 
> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  -liconv 
> -L/opt/local/lib -lffi   
> ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported 
> file format which is not the architecture being linked (i386)
> Undefined symbols:
>   "_iconv_close", referenced from:
>   _do_convert in libracket.a(string.o)
>   _do_convert in libracket.a(string.o)
>   _do_convert in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _close_converter in libracket.a(string.o)
>   "_iconv_open", referenced from:
>   _do_convert in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _scheme_open_converter in libracket.a(string.o)
>   "_iconv", referenced from:
>   _do_convert in libracket.a(string.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> (Note the warning about a different architecture.)
> 
> I assume that If I tell it to use the system version of iconv, things will 
> work 
> out. But how do I tell it to ignore the bad version?
> 
> -Eric
> 
> 
> 
> On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote:
> 
> > It looke like you have `-L/opt/local/lib' in your LDFLAGS
> > configuration. Do you also have `-I/opt/local/include' in CPPFLAGS?
> > 
> > You machine is probably like mine, where you have two installations of
> > libiconv, and this error happens when the C headers of one installation
> > get mixed with the lib of the other.
> > 
> > At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote:
> >> I tried to build the git HEAD today and ran into problems. During the make 
> >> process, it fails to create the framework with the following error message:
> >> 
> >> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
> >> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  
> -liconv 
> >> -L/opt/local/lib -lffi   
> >> Undefined symbols:
> >>  "_iconv_close", referenced from:
> >>  _do_convert in libracket.a(string.o)
> >>  _do_convert in libracket.a(string.o)
> >>  _do_convert in libracket.a(string.o)
> >>  _string_to_from_locale in libracket.a(string.o)
> >>  _string_to_from_locale in libracket.a(string.o)
> >>  _string_to_from_locale in libracket.a(string.o)
> >>  _close_converter in libracket.a(string.o)
> >>  "_iconv_open", referenced from:
> >>  _do_convert in libracket.a(string.o)
> >>  _string_to_from_locale in libracket.a(string.o)
> >>  _string_to_from_locale in libracket.a(string.o)
> >>  _scheme_open_converter in libracket.a(string.o)
> >>  "_iconv", referenced from:
> >>  _do_convert in libracket.a(string.o)
> >> ld: symbol(s) not found
> >> collect2: ld returned 1 exit status
> >> 
> >> Does anyone know what might cause this?
> >> 
> >> Thanks,
> >> Eric
> >> 
> >> 
> >> _
> >>  For list-related administrative tasks:
> >>  http://lists.racket-lang.org/listinfo/dev
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] racket 5.1 build failure on debian/kfreebsd

[David Bremner]

On Thu, 21 Apr 2011 19:32:18 -0600, Matthew Flatt  wrote:
> At Thu, 21 Apr 2011 22:22:00 -0300, David Bremner wrote:
> 
> Besides some code-organization problems, my guess is that "sconfig.h"
> doesn't figure out that you're on a FreeBSD variant. Do you know what
> pre-processor definition should be detected, if it's not __FreeBSD__?
> 

At a guess, I'd say __FreeBSD_kernel__  

I can try replacing 

#if defined(__FreeBSD__)  

with

#if defined(__FreeBSD__)  || defined(__FreeBSD_kernel__) 

and see what happens.

Thanks,

David
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Build failure on OS X

[Eric Dobson]

I don't have any *FLAGS variables set in my environment when I run configure or 
make. But I do have libiconv installed through macports. It was out of date, 
and I upgraded it, but now I am getting a different message:

gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  -liconv 
-L/opt/local/lib -lffi   
ld: warning: in /opt/local/lib/libiconv.dylib, file was built for unsupported 
file format which is not the architecture being linked (i386)
Undefined symbols:
  "_iconv_close", referenced from:
  _do_convert in libracket.a(string.o)
  _do_convert in libracket.a(string.o)
  _do_convert in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _close_converter in libracket.a(string.o)
  "_iconv_open", referenced from:
  _do_convert in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _scheme_open_converter in libracket.a(string.o)
  "_iconv", referenced from:
  _do_convert in libracket.a(string.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

(Note the warning about a different architecture.)

I assume that If I tell it to use the system version of iconv, things will work 
out. But how do I tell it to ignore the bad version?

-Eric



On Apr 21, 2011, at 9:48 PM, Matthew Flatt wrote:

> It looke like you have `-L/opt/local/lib' in your LDFLAGS
> configuration. Do you also have `-I/opt/local/include' in CPPFLAGS?
> 
> You machine is probably like mine, where you have two installations of
> libiconv, and this error happens when the C headers of one installation
> get mixed with the lib of the other.
> 
> At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote:
>> I tried to build the git HEAD today and ran into problems. During the make 
>> process, it fails to create the framework with the following error message:
>> 
>> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
>> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  
>> -liconv 
>> -L/opt/local/lib -lffi   
>> Undefined symbols:
>>  "_iconv_close", referenced from:
>>  _do_convert in libracket.a(string.o)
>>  _do_convert in libracket.a(string.o)
>>  _do_convert in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _close_converter in libracket.a(string.o)
>>  "_iconv_open", referenced from:
>>  _do_convert in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _string_to_from_locale in libracket.a(string.o)
>>  _scheme_open_converter in libracket.a(string.o)
>>  "_iconv", referenced from:
>>  _do_convert in libracket.a(string.o)
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>> 
>> Does anyone know what might cause this?
>> 
>> Thanks,
>> Eric
>> 
>> 
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Build failure on OS X

[Matthew Flatt]

It looke like you have `-L/opt/local/lib' in your LDFLAGS
configuration. Do you also have `-I/opt/local/include' in CPPFLAGS?

You machine is probably like mine, where you have two installations of
libiconv, and this error happens when the C headers of one installation
get mixed with the lib of the other.

At Thu, 21 Apr 2011 21:42:54 -0400, Eric Dobson wrote:
> I tried to build the git HEAD today and ran into problems. During the make 
> process, it fails to create the framework with the following error message:
> 
> gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
> CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  -liconv 
> -L/opt/local/lib -lffi   
> Undefined symbols:
>   "_iconv_close", referenced from:
>   _do_convert in libracket.a(string.o)
>   _do_convert in libracket.a(string.o)
>   _do_convert in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _close_converter in libracket.a(string.o)
>   "_iconv_open", referenced from:
>   _do_convert in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _string_to_from_locale in libracket.a(string.o)
>   _scheme_open_converter in libracket.a(string.o)
>   "_iconv", referenced from:
>   _do_convert in libracket.a(string.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> Does anyone know what might cause this?
> 
> Thanks,
>  Eric
> 
> 
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Build failure on OS X

[Eric Dobson]

I tried to build the git HEAD today and ran into problems. During the make 
process, it fails to create the framework with the following error message:

gcc -o Racket.framework/Versions/5.1.1.3/Racket  -m32 -pthread -framework 
CoreFoundation -dynamiclib -all_load  libracket.a libmzgc.a -ldl -lm  -liconv 
-L/opt/local/lib -lffi   
Undefined symbols:
  "_iconv_close", referenced from:
  _do_convert in libracket.a(string.o)
  _do_convert in libracket.a(string.o)
  _do_convert in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _close_converter in libracket.a(string.o)
  "_iconv_open", referenced from:
  _do_convert in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _string_to_from_locale in libracket.a(string.o)
  _scheme_open_converter in libracket.a(string.o)
  "_iconv", referenced from:
  _do_convert in libracket.a(string.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

Does anyone know what might cause this?

Thanks,
 Eric


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] racket 5.1 build failure on debian/kfreebsd

[Matthew Flatt]

At Thu, 21 Apr 2011 22:22:00 -0300, David Bremner wrote:
> I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with
> src/racket/src/port.c
> 
> The main problems stem from MZ_FLUSH_* not being defined. This in turn
> seems to be because MZ_FDS is not defined at line 259.  At that point I
> got stuck, I couldn't see what controlled this definition.

Besides some code-organization problems, my guess is that "sconfig.h"
doesn't figure out that you're on a FreeBSD variant. Do you know what
pre-processor definition should be detected, if it's not __FreeBSD__?


(The `configure' script should replace more of "sconfig.h"... one day.)

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] racket 5.1 build failure on debian/kfreebsd

[David Bremner]

Hi All;

I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with
src/racket/src/port.c

The main problems stem from MZ_FLUSH_* not being defined. This in turn
seems to be because MZ_FDS is not defined at line 259.  At that point I
got stuck, I couldn't see what controlled this definition.

The full build log is 

https://buildd.debian.org/status/fetch.php?pkg=racket&arch=kfreebsd-amd64&ver=5.1%2Bdfsg1-1&stamp=1303128559

The relevant seeming part is as follows:

gcc -I./.. 
-I/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/../include
 -g  -Wall -c 
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c
 -o port.o
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:
 In function 'scheme_file_buffer':
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4649:12:
 error: 'MZ_FLUSH_NEVER' undeclared (first use in this function)
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4649:12:
 note: each undeclared identifier is reported only once for each function it 
appears in
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4651:12:
 error: 'MZ_FLUSH_BY_LINE' undeclared (first use in this function)
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4653:12:
 error: 'MZ_FLUSH_ALWAYS' undeclared (first use in this function)
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:
 In function 'file_buffer_mode':
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4902:15:
 error: 'MZ_FLUSH_NEVER' undeclared (first use in this function)
/build/buildd-racket_5.1+dfsg1-1-kfreebsd-amd64-wZ0aXZ/racket-5.1+dfsg1/src/racket/src/port.c:4904:20:
 error: 'MZ_FLUSH_BY_LINE' undeclared (first use in this function)



_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Matthew Flatt]

At Wed, 20 Apr 2011 23:41:08 -0400, Ryan Culpepper wrote:
> * Matthew Flatt 
>   - Racket Tests
>   - Languages Tests
>   - GRacket Tests (Also check that `gracket -z' and `gracket-text' still
> works in Windows and Mac OS X)
>   - mzc Tests
>   - mzc --exe tests
>   - .plt-packing Tests
>   - Games Tests
>   - Unit Tests
>   - Syntax Color Tests
>   - R6RS Tests
>   - JPR's test suite.
>   - Create an executable from a BSL program.
>   Updates:
>   - Racket Updates: update HISTORY

Done.

>   - GRacket Updates: update README, HISTORY

Obsolete; please remove this checklist item.

>   - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1

No changes.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Robby Findler]

On Wed, Apr 20, 2011 at 10:41 PM, Ryan Culpepper  wrote:
> * Robby Findler 
>  - DrRacket Tests

all passed except tests/drracket/test-engine-test.rkt and I'll be
looking into that one.

>  - Framework Tests
>  - Contracts Tests
>  - Games Tests
>  - Teachpacks Tests: image tests
>  - PLaneT Tests

done


>  Updates:
>  - DrRacket Updates: update HISTORY
>  (updates should show v5.1.1 as the most current version)

done, commit: 8655c4a

>  - Ensure that previous version of DrRacket's preference files still
>    starts up with new DrRacket

done

>  - Update man pages in racket/man/man1: drracket.1

no changes to drracket, but I removed the drscheme.1 man page.

Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Doug Williams]

All of the plot tests and plot extensions in the science collection work as
expected.

On Wed, Apr 20, 2011 at 9:41 PM, Ryan Culpepper  wrote:

> Checklist items for the v5.1.1 release
>  (using the v5.1.0.900 release candidate build)
>
> Search for your name to find relevant items, reply when you finish an
> item (please indicate which item/s is/are done).  Also, if you have any
> commits that should have been picked, make sure that the changes are in.
>
> Important: new builds are created without announcement, usually whenever
> I pick a few commits.  If you need to commit changes, please make sure
> you tell me to pick it into the release branch.
>
> --> Release candidates are at
> -->   http://pre.racket-lang.org/release/installers
>
> Please use these installers (or source bundles) -- don't test from
> your own git clone (don't test v5.1.1.1 by mistake!).  To get
> the tests directory in such a directory, you can do this:
>  cd ...racket-root...
>  git archive --remote=git://git.racket-lang.org/plt.git release \
>  -- collects/tests | tar x
>
> --
>
> * Matthew Flatt 
>  - Racket Tests
>  - Languages Tests
>  - GRacket Tests (Also check that `gracket -z' and `gracket-text' still
>works in Windows and Mac OS X)
>  - mzc Tests
>  - mzc --exe tests
>  - .plt-packing Tests
>  - Games Tests
>  - Unit Tests
>  - Syntax Color Tests
>  - R6RS Tests
>  - JPR's test suite.
>  - Create an executable from a BSL program.
>  Updates:
>  - Racket Updates: update HISTORY
>  - GRacket Updates: update README, HISTORY
>  (updates should show v5.1.1 as the most current version)
>  - Update man pages in racket/man/man1: racket.1, gracket.1, raco.1
>  Email me to pick the changes when they're done, or tell me if there
>  are no such changes.
>
> * Robby Findler 
>  - DrRacket Tests
>  - Framework Tests
>  - Contracts Tests
>  - Games Tests
>  - Teachpacks Tests: image tests
>  - PLaneT Tests
>  Updates:
>  - DrRacket Updates: update HISTORY
>  (updates should show v5.1.1 as the most current version)
>  - Ensure that previous version of DrRacket's preference files still
>starts up with new DrRacket
>  - Update man pages in racket/man/man1: drracket.1
>  Email me to pick the changes when they're done, or tell me if there
>  are no such changes.
>
> * John Clements 
>  - Stepper Tests
>  Updates:
>  - Stepper Updates: update HISTORY
>  (updates should show v5.1.1 as the most current version; email me
>  to pick the changes when they're done, or tell me if there are no such
>  changes.)
>
> * Matthias Felleisen 
>  - Teachpacks Tests: check that new teachpacks are addable
>  - Teachpack Docs: check teachpack docs in the bundles
>  Updates:
>  - Teachpack Updates: update HISTORY
>  (updates should show v5.1.1 as the most current version; email me
>  to pick the changes when they're done, or tell me if there are no such
>  changes.)
>
> * Casey Klein 
>  - Redex Tests
>  Updates:
>  - Redex Updates: update HISTORY
>  (updates should show v5.1.1 as the most current version; email me
>  to pick the changes when they're done, or tell me if there are no such
>  changes.)
>
> * Ryan Culpepper 
>  - Macro Debugger Tests
>  - Syntax Classifier Tests
>  - RackUnit GUI Tests
>  - Data Tests
>
> * Jay McCarthy 
>  - Web Server Tests
>  - XML Tests
>  - HTML Tests
>  - PLAI Tests
>  - Racklog tests
>  - Datalog tests
>
> * Paul Steckler 
>  - MysterX Tests
>  - MzCOM Tests
>
> * Kathy Gray 
>  - Test Engine Tests
>
> * Noel Welsh 
>  - Rackunit Tests
>  - SRFI Tests
>  - Ensure that all claimed srfi's are in the installer and they all
>load into racket or drracket (as appropriate)
>
> * Sam Tobin-Hochstadt 
>  - Match Tests
>  - Typed Racket Tests
>
> * Stevie Strickland 
>  - Unit Contract Tests
>  - Contract Region Tests
>
> * Eli Barzilay 
>  - Swindle Tests
>  - Plot Tests
>  - Verify that the unix installer works in both modes
>  - Racket Tree: compare new distribution tree to previous one
>  Version Updates: if a major change has happened, update the version
>  number in:
>  - racket/collects/mzscheme/info.rkt
>  - racket/collects/mred/info.rkt
>
> * Doug Williams 
>  - Plot Tests
>
> * Stephen Bloch 
>  - Picturing Programs Tests
>
> * Greg Cooper 
>  - FrTime Tests
>
> * Carl Eastlund 
>  - Dracula Tests (confirm that Dracula runs from PLaneT)
>
> * Jon Rafkind 
>  Release tests for (one of the) linux releases:
>  - Test that the `racket' and `racket-textual' source releases
>compile fine
>  - Test that the binary installers for both work, try each one in
>both normal and unix-style installation modes. (just ubuntu)
>  [Note: get the release candidates from the URL in this email. Use
>   the 'static table' link to see a list of all tar files available]
>
> * Shriram Krishnamurthi 
>  Tour: check the tour and generate a new one if needed.
>  [Note: Since this is a v5.1.0.900 build, you will need to edit your
>.../collects/framework/privat

Re: [racket-dev] my '312' this semester, how we compare to others

[Matthias Felleisen]

Two points worth noting: 

1. Robby pointed out that I forgot to compile my code when I ran the script. 
That was a critical omission on my side and it eliminates point -A- from my 
list of negative observations. 

2. I forgot to mention the most amazing aspect of my final test run with the 
students. For their final, we ran their server and my clients. In addition to 
regular clients, I had nasty ones and bad ones. I wrote one nasty one 
especially for the C++ project. This client would send the following kind of 
XML to the server to initiate the dialog: 

  

As you can see, it's regular XML but a lot of work. The amazing point: 

 -- the C++ project is the ONLY one (other than my own server) that 'survives' 
this message. 
(It fails to truncate the name and thus generates too much network 
traffic in the end. 
On occasion it may fail for this reason. To be precise, it times out.) 

 -- ALL other projects (Java, Python) failed on this one. The Java and Python 
libraries are 
so clumsy that the programmers naturally make mistakes (five different 
mistakes in 
six temas). 

For full disclosure, the C++ hacker is a systems PhD student (uncommon for this 
course) and is a Google Chrome part-time developer. 

-- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] arrows missing from check syntax?

[Robby Findler]

Uhh.. no. But I see them, as attached. That's a mac with an older
version than yours; I've also checked the release candidate under
windows with the same program and they were there.

Robby

On Thu, Apr 21, 2011 at 4:42 PM, Danny Yoo  wrote:
> The lexical scoping arrows seem to be missing from Check Syntax.  Is
> this deliberate?  Currently using 5.1.1.3--2011-04-21.  Thanks!
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>
<>_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] arrows missing from check syntax?

[Danny Yoo]

The lexical scoping arrows seem to be missing from Check Syntax.  Is
this deliberate?  Currently using 5.1.1.3--2011-04-21.  Thanks!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Vincent St-Amour]

At Wed, 20 Apr 2011 23:41:08 -0400,
Ryan Culpepper wrote:
>   - Typed Racket Tests

Done.

Vincent
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] my '312' this semester, how we compare to others

[Matthias Felleisen]

I had a request for line counts: 

 -- my own project used ~5,000loc, which includes comments and blank lines 
-- of these, ~3,200 lines are 'real' code and some ~1,800 lines of 
rackunit code 

 -- the Java projects run at about 2x to 3x the line count (the best project 
comes in at close to 12Kloc)

 -- the C++ project is close to 4Kloc, w/o any tests 

 -- the Python project came out to 2,8000 lines, including tests 

Some caveats apply of course: 

 ++ Java is extremely verbose and cumbersome, even with parametric 
polymorphism. 

 ++ Only one project had a larger test ratio than my own. But the project was 
in Java and see preceding bullet. 
 
 ++ Only the C++ project has a GUI that is comparable to my own. 

 ++ Not one server lived up to the same quality level as mine. (I sent them a 
free-formatted string of 1,000,000 lines and that broke everyone's code).

 ++ Two of seven clients faulted all the time. One faulted on an intermittent 
basis. 

And there are other caveats. I am sure I could write more compact Java code 
than any of the students, though I doubt I'd get close to what I have. 

I will reflect some more and report on the language comparison a bit more. 

-- Matthias





_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Carl Eastlund]

On Wed, Apr 20, 2011 at 11:41 PM, Ryan Culpepper  wrote:
> * Carl Eastlund 
>  - Dracula Tests (confirm that Dracula runs from PLaneT)

Done.

--Carl

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Jay McCarthy]

Not a mistake. 'mzscheme' is kept for script-compatibility but
'drscheme' is dropped as part of the name change transition.

Jay

2011/4/21 Jon Rafkind :
> Source distributions compiled ok. The racket distribution no longer
> produces a 'drscheme' executable even though it does produce 'mzscheme'.
>
> Is that a mistake?
>
> On 04/21/2011 11:50 AM, Jon Rafkind wrote:
>>> * Jon Rafkind 
>>>   Release tests for (one of the) linux releases:
>>>   - Test that the `racket' and `racket-textual' source releases
>>>     compile fine
>>>   - Test that the binary installers for both work, try each one in
>>>     both normal and unix-style installation modes. (just ubuntu)
>>>   [Note: get the release candidates from the URL in this email. Use
>>>    the 'static table' link to see a list of all tar files available]
>>>
>> The binary installers had problems with libffi.so.5. Source
>> distributions are still compiling. I used
>>
>> plt-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh
>> mz-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh
>>
>> My notes:
>> textual - failed in normal mode after install
>>    $ ./racket
>>    ./racket: error while loading shared libraries: libffi.so.5: cannot
>> open shared object file: No such file or directory
>>
>>   failed in unix mode during install
>>   Unpacking into
>> "/tmp/work/x/binary/textual-unix/racket-textual-tmp-install"... done.
>>   racket-textual-tmp-install/bin/racket: error while loading shared
>> libraries: libffi.so.5: cannot open shared object file: No such file or
>> directory
>>
>>   racket - failed in normal mode after install
>>     $ ./racket
>>     ./racket: error while loading shared libraries: libffi.so.5: cannot
>> open shared object file: No such file or directory
>>
>>   failed in unix mode during install
>>    Unpacking into "/tmp/work/x/binary/racket-unix/racket-tmp-install"...
>> done.
>>    racket-tmp-install/bin/racket: error while loading shared libraries:
>> libffi.so.5: cannot open shared object file: No such file or directory
>>    Error: installation failed
>>      (Removing installation files in
>> /tmp/work/x/binary/racket-unix/racket-tmp-install)
>>
>> _
>>   For list-related administrative tasks:
>>   http://lists.racket-lang.org/listinfo/dev
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Jon Rafkind]

Source distributions compiled ok. The racket distribution no longer
produces a 'drscheme' executable even though it does produce 'mzscheme'.

Is that a mistake?

On 04/21/2011 11:50 AM, Jon Rafkind wrote:
>> * Jon Rafkind 
>>   Release tests for (one of the) linux releases:
>>   - Test that the `racket' and `racket-textual' source releases
>> compile fine
>>   - Test that the binary installers for both work, try each one in
>> both normal and unix-style installation modes. (just ubuntu)
>>   [Note: get the release candidates from the URL in this email. Use
>>the 'static table' link to see a list of all tar files available]
>>
> The binary installers had problems with libffi.so.5. Source
> distributions are still compiling. I used
>
> plt-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh
> mz-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh
>
> My notes:
> textual - failed in normal mode after install
>$ ./racket
>./racket: error while loading shared libraries: libffi.so.5: cannot
> open shared object file: No such file or directory
>
>   failed in unix mode during install
>   Unpacking into
> "/tmp/work/x/binary/textual-unix/racket-textual-tmp-install"... done.
>   racket-textual-tmp-install/bin/racket: error while loading shared
> libraries: libffi.so.5: cannot open shared object file: No such file or
> directory
>
>   racket - failed in normal mode after install
> $ ./racket
> ./racket: error while loading shared libraries: libffi.so.5: cannot
> open shared object file: No such file or directory
>
>   failed in unix mode during install
>Unpacking into "/tmp/work/x/binary/racket-unix/racket-tmp-install"...
> done.
>racket-tmp-install/bin/racket: error while loading shared libraries:
> libffi.so.5: cannot open shared object file: No such file or directory
>Error: installation failed
>  (Removing installation files in
> /tmp/work/x/binary/racket-unix/racket-tmp-install)
>
> _
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] my '312' this semester, how we compare to others

[Neil Van Dyke]

Matthias Felleisen wrote at 04/21/2011 01:07 PM:

-A- I demanded that students deliver their functionality via Unix shell 
scripts, and so I did so too. My tcsh scripts check the argument number and 
pass the arguments on to Racket. Firing up one of my clients or servers takes 
several seconds. All other language implementations appear to bring up their 
servers or clients instantaneously.
  


I only see slow performance like that from non-GUI Racket when the 
Racket code is not yet compiled, and perhaps when the files that need to 
be read (or ELF loaded) by the OS are not in OS caches.


The "racket" REPL executable startup *did* seem to get a lot slower a 
while ago -- a few seconds -- compared to the old "mzscheme" REPL.  But 
5.1 was less than 1 second to REPL prompt when I tried it just now.


Three shell script tips that shouldn't matter much, but might speed you 
up a little: (1) Consider using "/bin/sh" or "/bin/bash" instead of 
"tcsh", since the old rule is Bourne for scripting, C-shell for 
interactive; (2)  In the "#!" line, use command line options to disable 
shell features that load various system and user rc files, since these 
are slow to read and interpret, and can be huge like completion tables, 
plus in a production app other people's shell rc files can introduce 
instability; (3) After your script does the minimal stuff it has to do 
in shell rather than Racket, use an "exec" to fire off "racket", so that 
everyone can forget sooner that shell ever happened.


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Pre-Release Checklist for v5.1.1

[Jon Rafkind]

> * Jon Rafkind 
>   Release tests for (one of the) linux releases:
>   - Test that the `racket' and `racket-textual' source releases
> compile fine
>   - Test that the binary installers for both work, try each one in
> both normal and unix-style installation modes. (just ubuntu)
>   [Note: get the release candidates from the URL in this email. Use
>the 'static table' link to see a list of all tar files available]
>

The binary installers had problems with libffi.so.5. Source
distributions are still compiling. I used

plt-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh
mz-5.1.0.900-bin-i386-linux-ubuntu-jaunty.sh

My notes:
textual - failed in normal mode after install
   $ ./racket
   ./racket: error while loading shared libraries: libffi.so.5: cannot
open shared object file: No such file or directory

  failed in unix mode during install
  Unpacking into
"/tmp/work/x/binary/textual-unix/racket-textual-tmp-install"... done.
  racket-textual-tmp-install/bin/racket: error while loading shared
libraries: libffi.so.5: cannot open shared object file: No such file or
directory

  racket - failed in normal mode after install
$ ./racket
./racket: error while loading shared libraries: libffi.so.5: cannot
open shared object file: No such file or directory

  failed in unix mode during install
   Unpacking into "/tmp/work/x/binary/racket-unix/racket-tmp-install"...
done.
   racket-tmp-install/bin/racket: error while loading shared libraries:
libffi.so.5: cannot open shared object file: No such file or directory
   Error: installation failed
 (Removing installation files in
/tmp/work/x/binary/racket-unix/racket-tmp-install)

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] my '312' this semester, how we compare to others

[Matthias Felleisen]

[ In case you don't know: since the late 90s, I have been teaching a course 
dubbed software dev every so often. Students choose their favorite language, I 
choose the project, they program, I program in Racket and in DrRacket (and 
strictly). Over the semester the students code-walk their projects in class and 
the 'finals' are two-hour code walks with 'stress tests' of their servers 
working with my clients and vice versa. This gives me some idea of what 
languages contribute to the standard of programming and what's out there. ]

* OBSERVATIONS from this year's '312', starting with some background: 

(1) this is the first year the course was open to MS students and limited 
enrollment only. So I ended up with 10 MS students and 6 undergraduates. 
(2) I saw much less variety than usual. 
(3) two undergraduates started with Racket but due to team rotations they ended 
up with Java partners. 
(4) all MS students fell back into their Java/Eclipse monoculture after having 
seen Racket/DrRacket in the Bootcamp course for MS students. 
(5) one pair chose Python 
(6) one pair chose C++, and lo and behold, this is the first time in 14 years 
that the C++ pair survived the course. 

On local basis (ten lines here, ten lines there), the C++ and Python code looks 
as good as Racket code. 

Java looks worst. Period. 

I stuck to Racket's OO world, and I will say that I mostly enjoyed this. 

Racket didn't provide me with much of an advantage anymore. I did benefit from 
mixins (twice), custodians (once), proper contracts (huge win) and my first 
large-scale use of rackunit (another large win). If I had remembered logging in 
Racket, I would have saved myself 40 lines of code and 2 hours of debugging. 
Higher-order functions and macros played very minor roles. This is possibly due 
to my choice of project. (Look for Ingenious board game; distributed; 
variations on the rules) 

Bottom line here: My code implements more features, is easier to read, has many 
fewer bugs, I am more productive than anybody in there. But it's my personal 
skill set (with Racket) not the language features that give me most of the 
advantage. 

;; --- 

Let's get to what I learned about how others live and where we fail: 

* PROBLEMS WITH DRRACKET: compared to the Eclipse-Java monoculture, 
DrRacket suffers from three major problems as far as I am concerned as a 
program designer: 

-1- Eclipse performs 'check syntax' in an on-line fashion. If you are reading a 
piece of code, and you wish to jump to the definition of some method you're 
calling, click and you jump. 

-2- Eclipse autocompletes all the time and in a highly convenient manner. 

-3- Eclipse displays tooltips on ids with relevant docs. It makes it trivial to 
learn the APIs and to recall what your own methods do (assuming your types and 
your purpose statements contain the proper information). 

DrRacket/Racket is superior to Eclipse in two regards: 

+1+ Contracts are properly integrated into our tool chain. They are comments 
and or strings in the rest of the world. 

+2+ My discipline of using define/provide-test-suite enabled me to keep 
interfaces narrow and tests accurate and called properly. 

* PROBLEMS WITH RACKET: our performance suffers from two problems. 

-A- I demanded that students deliver their functionality via Unix shell 
scripts, and so I did so too. My tcsh scripts check the argument number and 
pass the arguments on to Racket. Firing up one of my clients or servers takes 
several seconds. All other language implementations appear to bring up their 
servers or clients instantaneously. 

-B- When it comes to raw computational performance (ignore loading Racket, 
start from REPL and run a single game -- 10 seconds), my implementation is 
faster than Python (but barely) and one of the Java implementations. But one 
Java implementation is 10x faster. My hunch is that our OO system is 
significantly slower than Java's because we lack types to reduce dispatch 
overhead. Then again I might be wrong. -- Another possibility is that my 
extremely heavy use of our wonderful (!) contracts may impose a large overhead. 
I use mostly ->i and ->m. 

;; --- 

So this is the view from the frontline. I am equally delighted and frustrated 
this year -- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [plt] Push #22500: master branch updated

[Eli Barzilay]

An hour and a half ago, Kevin Tew wrote:
> An alternative patch that keeps places enabled but uses processes
> for build.

Yes -- this is what I meant by disabling it.  (Assuming that this
disables the parallel build with either places or processes.)


> diff --git a/collects/setup/parallel-do.rkt b/collects/setup/parallel-do.rkt
> index 00823fe..2716c2a 100644
> --- a/collects/setup/parallel-do.rkt
> +++ b/collects/setup/parallel-do.rkt
> @@ -168,7 +168,8 @@
>(find-system-path 'orig-dir))
> 
>   (define (parallel-do-event-loop module-path funcname initialmsg 
> jobqueue nprocs [stopat #f])
> -  (define use-places (place-enabled?))
> +;  (define use-places (place-enabled?))
> +  (define use-places #f)
> (define (spawn id)
>   (define wrkr (if use-places (new PlaceWorker%) (new Worker%)))
>   (wrkr/spawn wrkr id module-path funcname initialmsg)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [plt] Push #22500: master branch updated

[Kevin Tew]

An alternative patch that keeps places enabled but uses processes for build.

diff --git a/collects/setup/parallel-do.rkt b/collects/setup/parallel-do.rkt
index 00823fe..2716c2a 100644
--- a/collects/setup/parallel-do.rkt
+++ b/collects/setup/parallel-do.rkt
@@ -168,7 +168,8 @@
  (find-system-path 'orig-dir))

 (define (parallel-do-event-loop module-path funcname initialmsg 
jobqueue nprocs [stopat #f])

-  (define use-places (place-enabled?))
+;  (define use-places (place-enabled?))
+  (define use-places #f)
   (define (spawn id)
 (define wrkr (if use-places (new PlaceWorker%) (new Worker%)))
 (wrkr/spawn wrkr id module-path funcname initialmsg)



On 04/21/2011 06:13 AM, mfl...@racket-lang.org wrote:

mflatt has updated `master' from 2177681336 to 8760d38a95.
   http://git.racket-lang.org/plt/2177681336..8760d38a95

=[ 1 Commits ]==

Directory summary:
   38.9% src/racket/
   12.4% src/worksp/
   48.6% src/

~~

8760d38 Matthew Flatt  2011-04-21 06:12
:
| disable places-by-default for now
|  --- pending further investigation of memory consumption
:
   M src/configure   |   12 ++--
   M src/racket/configure.ac |   12 ++--
   M src/worksp/mzconfig.h   |2 +-

=[ Overall Diff ]===

src/configure
~
--- OLD/src/configure
+++ NEW/src/configure
@@ -1327,7 +1327,7 @@ Optional Features:
--enable-jitcompile JIT support (enabled by default)
--enable-foreigncompile foreign support (enabled by default)
--enable-libffi use installed libffi (enabled by default)
-  --enable-places compile places support (usually enabled by default)
+  --enable-places compile places support
--enable-futurescompile futures support (usually enabled by default)
--enable-cgcdefault use CGC (Boehm or Senora) as default build
--enable-sgcuse Senora GC instead of the Boehm GC
@@ -8255,11 +8255,11 @@ fi

  ### places ###

-if test "${enable_parallel_by_default}" = "yes" ; then
-  if test "${enable_places}" = "" ; then
-enable_places=yes
-  fi
-fi
+#if test "${enable_parallel_by_default}" = "yes" ; then
+#  if test "${enable_places}" = "" ; then
+#enable_places=yes
+#  fi
+#fi

  if test "${enable_places}" = "yes" ; then


src/racket/configure.ac
~~~
--- OLD/src/racket/configure.ac
+++ NEW/src/racket/configure.ac
@@ -38,7 +38,7 @@ AC_ARG_ENABLE(jit, [  --enable-jitcompile JIT 
support (enabled b
  AC_ARG_ENABLE(foreign, [  --enable-foreigncompile foreign support 
(enabled by default)], , enable_foreign=yes)
  AC_ARG_ENABLE(libffi,  [  --enable-libffi use installed libffi 
(enabled by default)], , enable_libffi=yes)

-AC_ARG_ENABLE(places,  [  --enable-places compile places support 
(usually enabled by default)])
+AC_ARG_ENABLE(places,  [  --enable-places compile places support])
  AC_ARG_ENABLE(futures, [  --enable-futurescompile futures support 
(usually enabled by default)])

  AC_ARG_ENABLE(cgcdefault, [  --enable-cgcdefault use CGC (Boehm or 
Senora) as default build])
@@ -1006,11 +1006,11 @@ fi

  ### places ###

-if test "${enable_parallel_by_default}" = "yes" ; then
-  if test "${enable_places}" = "" ; then
-enable_places=yes
-  fi
-fi
+#if test "${enable_parallel_by_default}" = "yes" ; then
+#  if test "${enable_places}" = "" ; then
+#enable_places=yes
+#  fi
+#fi

  if test "${enable_places}" = "yes" ; then
AC_DEFINE(MZ_USE_PLACES,1,[Places enabled])

src/worksp/mzconfig.h
~
--- OLD/src/worksp/mzconfig.h
+++ NEW/src/worksp/mzconfig.h
@@ -42,7 +42,7 @@
  #define MZ_USE_FUTURES

  /* Enable places: */
-#define MZ_USE_PLACES
+/*#define MZ_USE_PLACES*/

  /* Enable single-precision floats: */
  #define USE_SINGLE_FLOATS


_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Places -- on by default in v5.1.1.2. (git master)

[Matthew Flatt]

At Thu, 21 Apr 2011 05:33:47 -0400, Eli Barzilay wrote:
> Two days ago, Kevin Tew wrote:
> > 
> > This means that parallel zo and doc builds will use places instead
> > of processes.
> > 
> > Report bugs as usual :)
> 
> Here's a major bug: the memory consumption is *horrible*.

Ok, we'll disable for now and check on the change in memory use.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Places -- on by default in v5.1.1.2. (git master)

[Eli Barzilay]

Two days ago, Kevin Tew wrote:
> 
> This means that parallel zo and doc builds will use places instead
> of processes.
> 
> Report bugs as usual :)

Here's a major bug: the memory consumption is *horrible*.  Winooski,
the main build machine, has 4 cores and 4gb ram.  Things used to be
pretty bad with 4 build processes, each taking around 500mb or a
little more -- but this change turned it from bad to nightmarish.
(The machine gets overwhelmed by the load while memory consumption
goes up mercilessly, gets to the point of thrashing badly and leading
the kernell to go off on a random killing spree.)

Please disable it.

The first build died in a way that was probably similar to that.  The
second one happened while I was working, so I got to see the horror
from a closer range, and killed it myself.  (A project that took about
10 minutes to accomplish.)  Before it died, the rough numbers were:
about 3.8gb of virtual memory, and a resident size of around 2.1gb.
My guess is that, like you said, the memory footprint is essentially
the same, but with 4 processes the kernel can sort things out and
starve one process while the others make progress, and with one
there's not much that it can do.  (But that's just a guess.)

As for the reason I ask to disable it: IMO, a 4gb memory is not
something that should be considered common, and >= 4 cores too.  So
this makes a good recipe for a bad first-experience with the
langauge.  (If I see some random language that kills my machine when I
try to compile it, I'd probably not only dump it, but complain loudly
whenever I see it mentioned.)

Alternatively, if there's a way to check the machine's physical
memory, then make it use something like 1 core per 2gb ram.  This
applies for the multiple-processes variant too, though the number
might be a little lower.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev