Re: [racket-dev] Math library pushed

[Kevin Tew]

Use git format-patch to create patch files for your range of commits and 
then apply them to the current head using git am


Kevin

On 11/17/2012 06:57 AM, Jens Axel Søgaard wrote:

2012/11/16 Neil Toronto :

I've just made the initial commit for the math library. You will all notice
the build time increase. Some will notice that "(require math)" imports a
bunch of goodies that Racket didn't have before.

About half is documented so far, and half has coverage in the test cases.
Some things are known to be broken, but not many. The most egregious, which
needs to be fixed very soon, is this one:

I have made a pull request on Github with documentation on the number
theory functions (and other stuff).

However since Neil's initial commit didn't include the history, the
pull request contains ~300 commits.

Is there a better way to commit my changes?

 https://github.com/plt/racket/pull/169



_
 Racket Developers list:
 http://lists.racket-lang.org/dev

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

[Kevin Tew]

On 05/10/2012 05:38 PM, Eli Barzilay wrote:

Two hours ago, t...@racket-lang.org wrote:

   A collects/racket/place/distributed/RMPI.rkt

Can we avoid having capitals in public api modules and CamelCase names
like `RMPI-AllReduce'?


I'll fix it.
_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] Master-Worker with Places

[Kevin Tew]

On 03/29/2012 12:00 PM, Nick Shelley wrote:
In my limited experience with parallel computing, it seems like the 
master-worker paradigm is somewhat common. However, it seems like 
Racket's places (or at least the way events are done with 
place-channels) makes this inconvenient. Since there is nothing that I 
can find in the result of syncing on a place-channel that would allow 
me to then send some new work to the same channel, I have to implement 
this manually by having each channel keep track of it's place in the 
list of workers and send that information explicitly. This approach 
seems hacky and more prone to bugs.


You need to use wrap-evt or handle-evt with a closure that includes the 
channel.


I think it would make more sense for the result of syncing on a 
place-channel to return the channel itself as a result. This would 
make an explicit call to place-channel-get necessary, which may be a 
downside, but the upside is I could then put something on the same 
channel or do whatever else I may want with it.
This is one way to do it, however we choose to make place-channels work 
like plain channels in Racket.
Its a trade off.  Either you have to explicitly call place-channel-get 
or you have to use wrap-evt or handle-evt to maintain a reference to the 
channel.


If changing how place-channel events are treated isn't feasible, I 
think it would at least be useful to provide an abstraction that makes 
master-worker more convenient. One idea might be a sync-channel 
function that returns the channel.

wrap-evt and handle-evt are those abstractions.

Place-channel is meant to be a simple primitive, enabling more 
complicated parallel constructs to be built on top of place-channels.

We don't yet have a master-worker library. It would be nice if we did.

Some example you can look at include:
The places paper at 
http://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf, demonstrates a 
master-worker parallel build using a jobqueue and handle-evt.
The file collects/setup/parallel-do.rkt is a very complicated example of 
a master-worker implementation using work-queues and wrap-evt


As a sort of side note, it would be nice to be able to treat this 
problem similar to a user thread problem where you can conceptually 
imagine having infinite workers and just giving one chunk of work to 
each of them. I tried to do this at first, but because of the way 
places are implemented, I ran out of file descriptors relatively 
quickly (and the overhead of starting a new VM for each chunk of work 
might have been too much anyway, I don't know). I don't know if an 
abstraction like that is possible or useful in general, but it may be 
something to consider.


Places are too resource expensive to spawn one for each work item.  You 
have to use a work-queue and a small number of worker places.


Kevin



_
   Racket Developers list:
   http://lists.racket-lang.org/dev




On 03/29/2012 12:00 PM, Nick Shelley wrote:
In my limited experience with parallel computing, it seems like the 
master-worker paradigm is somewhat common. However, it seems like 
Racket's places (or at least the way events are done with 
place-channels) makes this inconvenient. Since there is nothing that I 
can find in the result of syncing on a place-channel that would allow 
me to then send some new work to the same channel, I have to implement 
this manually by having each channel keep track of it's place in the 
list of workers and send that information explicitly. This approach 
seems hacky and more prone to bugs.


I think it would make more sense for the result of syncing on a 
place-channel to return the channel itself as a result. This would 
make an explicit call to place-channel-get necessary, which may be a 
downside, but the upside is I could then put something on the same 
channel or do whatever else I may want with it.


If changing how place-channel events are treated isn't feasible, I 
think it would at least be useful to provide an abstraction that makes 
master-worker more convenient. One idea might be a sync-channel 
function that returns the channel.


As a sort of side note, it would be nice to be able to treat this 
problem similar to a user thread problem where you can conceptually 
imagine having infinite workers and just giving one chunk of work to 
each of them. I tried to do this at first, but because of the way 
places are implemented, I ran out of file descriptors relatively 
quickly (and the overhead of starting a new VM for each chunk of work 
might have been too much anyway, I don't know). I don't know if an 
abstraction like that is possible or useful in general, but it may be 
something to consider.


-Nick


_
   Racket Developers list:
   http://lists.racket-lang.org/dev


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] odd error message in race setup

[Kevin Tew]

Its an example from the distributed places docs.  I'll remove it.

Kevin

On 03/08/2012 06:00 PM, Robby Findler wrote:

I think that the issue probably does not predate Kevin's recent push
(distributed places).

If you'd like to audit the push security concerns, I'm sure that'd be welcome.

Robby

On Thu, Mar 8, 2012 at 5:32 PM, Neil Van Dyke  wrote:

Robby Findler wrote at 03/08/2012 05:45 PM:


Looks like something is trying to ssh while building the docs?


Can whoever figures this out let the list know, or email me privately?
  Thanks.

If it turns out that a use of SSH made it into a *released* version of
Racket source, I might have to take a look at it, regardless of how
legitimate it is.

(Looks like something is trying to SSH, and "localhost"'s fingerprint
disagrees with user's SSH "known_hosts".  So might have been going on for a
while, quietly, and only noticed now because of the unusual situation of the
fingerprint being different.  And noticed because someone was paying
attention to the "raco setup" logs (if that indeed "raco setup" process was
the source, rather than some other process that just had a handle for the
stdio/terminal).  I don't "grep" an obvious use of SSH in the 5.2.1 sources
I'm using right now.)

--
http://www.neilvandyke.org/

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
   Racket Developers list:
   http://lists.racket-lang.org/dev


_
 Racket Developers list:
 http://lists.racket-lang.org/dev

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

[Kevin Tew]

On 02/28/2012 01:56 PM, Robby Findler wrote:

On Tue, Feb 28, 2012 at 2:43 PM, Ryan Culpepper  wrote:

On my machine before the change, "raco setup -D" took 8m13s real, 13m52s
user; after the change, it takes 4m0s real, 9m3s user.

I guess you have a faster machine than I do. (Are you running the 64
bit build or 32?)

FWIW, the times I'm reporting are after your commit.


It's useful to look at the progress output, particularly the place that a
particular collection is scheduled on. Before, progress would stop on the
"macro-debugger" collection for a long time. Now, you can still see
individual places blocking for long periods of time by looking for long runs
where a place number is absent.

On my machine, the "images" collection is scheduled on place 0, and it keeps
0 occupied for a long time---until around when setup hits "scribblings".
Then place 2 is occupied by "gui-debugger", then 1 is occupied by
"macro-debugger". CPUs utilization drops to around 75% when it hits
"gui-debugger" and then to around 50% at "macro-debugger". Both of those
collections depend on "images". It drops again, briefly, around "scribble",
which is also around when "images" finishes---I'm not sure what that means.
It also takes a while to climb back to around 100%, and I'm not sure why
that happens either (possibly related to "scribble"/"scribblings"?).

It seems like it should help to issue more collections while those few
block, but doing it naively (-j 5 or -j 6) doesn't work.

I've put together something that reads .dep files and does a
topological sort of the collections based on the dependencies (after
breaking links to get rid of the cycles) and uses that to schedule the
collections. I'm running some timing tests now.

Robby
_
   Racket Developers list:
   http://lists.racket-lang.org/dev

I think this will be a great compromise between the status quo
and earlier work when I created a dependency graph for all .rkt files
in collects.

The dependencies between collections is likely to change less often.

How expensive is calculating the dependencies between collections?
I assume you have to look at the dependencies for every .rkt file in 
each collection. Yes?


Kevin
_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] More places questions

[Kevin Tew]

Yeah I think you are right.  I'll commit a change.

Kevin

On 09/30/2011 03:17 PM, John Clements wrote:

On Sep 30, 2011, at 5:28 AM, Sam Tobin-Hochstadt wrote:


On Fri, Sep 30, 2011 at 12:26 AM, John Clements
  wrote:

I'm guessing that calling place-channel-put with a descriptor pulls out the 
associated channel... should the docs indicate this?

The docs here: 
http://pre.racket-lang.org/docs/html/reference/places.html?q=place#%28tech._place._descriptor%29
say that.

They do indeed; specifically, they say "Every place descriptor is also a place 
channel".

But in that case, I think that this program:

#lang racket

(define (main)
   (define p
 (place ch
3))
   (place-channel? p))

... should produce #t, but it produces #f. No?

John



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

Re: [racket-dev] More places questions

[Kevin Tew]

place-channel-put is not blocking.

I'll add it to the docs.


On 09/30/2011 06:28 AM, Sam Tobin-Hochstadt wrote:

On Fri, Sep 30, 2011 at 12:26 AM, John Clements
  wrote:

I'm guessing that calling place-channel-put with a descriptor pulls out the 
associated channel... should the docs indicate this?

The docs here: 
http://pre.racket-lang.org/docs/html/reference/places.html?q=place#%28tech._place._descriptor%29
say that.


Also, my tiny experiments suggest that place-channel-put is blocking, is that 
right?

I think that's correct (like with `channel-put'), but the docs don't
seem to say.


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

Re: [racket-dev] Using places to synchronize with C threads?

[Kevin Tew]

Place channels only work between places (os threads spawned using the 
`place' primitives).
Place channels can't be used with an OS thread spawned by an arbitrary C 
library.


but

src/racket/src/mzrt.c contains synchronization operations for use 
between OS threads.
Place channels are built on top of the low level wrappers found in 
src/racket/src/mzrt.c.
The wrappers in src/racket/src/mzrt.c can safely be called from any C 
thread.
The downside is that these OS thread synchronization are not exposed in 
the racket language.
The wrappers aren't documented, but they are just a platform portability 
layer over pthread synchronization primitives.


If you are spawning the OS thread, you might want to look at Ryan's 
sqlite db layer which places the sqlite ffi calls in a second `place' so 
the interactivity of the main `place' is preserved.
If the OS thread is spawned by a third party library, you might be able 
to use the ffi and the non-blocking mzrt_mutex_trylock call to build 
what you need.


If none of the above work, we might need to build some more 
infrastructure for synchronizing with OS threads.


Kevin


On 09/20/2011 12:17 PM, John Clements wrote:

It looks like you've done the heavy lifting of creating primitives that can be 
used to synchronize between OS threads.  Is there any way to use place channels 
to interact between the main Racket thread and an OS thread spawned by an audio 
library?  I don't see any documentation that provides a C interface to the 
place primitives, and I've learned the hard way that I can't assume that 
calling racket functions in a C thread is safe.

John



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

Re: [racket-dev] foreign struct access different in 5.1.3?

[Kevin Tew]

I'll do that.

Kevin
On 09/17/2011 07:53 AM, Matthew Flatt wrote:

At Sat, 17 Sep 2011 07:44:50 -0600, Kevin Tew wrote:

If you would like document the fact that cstructs are generative only up
to version 5.1.3.  I think that improve the docs.

I think the right next step is for you (Kevin) to update
"doc/release-notes/racket/HISTORY.txt" to describe the change.



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

Re: [racket-dev] foreign struct access different in 5.1.3?

[Kevin Tew]

On 09/16/2011 09:04 PM, John Clements wrote:

On Sep 16, 2011, at 3:06 PM, John Clements wrote:


I'm trying to backport working FFI code to 5.1.3, and I'm having trouble 
referring to elements of a C struct. Specifically, in the presence of this 
definition

(define-cstruct _rack-audio-closure
  ([sound _pointer]
   [cur-sample_ulong]
   [num-samples   _ulong]
   [stop-now  _bool]
   [stop-sema-ptr _pointer]))

using the function (rack-audio-closure-cur-sample) on the result of an FFI call 
with signature

(_fun _pointer _ulong _pointer ->  _rack-audio-closure-pointer)

produces this error:

rack-audio-closure-cur-sample: expected argument of type; 
given #

in 5.1.3, but it works just fine in the git head.

More research suggests that the problem is more limited; it looks like a problem of 
generativity. That is, if I have two modules that declare the "same" cstruct 
(same name, same fields, same types) then cpointers to these structures returned by 
functions from the first module cannot be accessed in the other module.


in 5.1.3 "same" cstructs defined in two different modules could not 
inter-operate.

Each place has it own copy of modules, so
the "same" cstruct defined in the same module but in two different 
places wouldn't inter-operate either.

Hence the change.


AFAICT, This is not the case in more recent versions; that is, these cstructs 
are not generative.  Assuming this is deliberate, I could document it.

This is deliberate.  It allows foreign pointers to be shared between places.

The following text was removed from the documentation in the head 
version because cstructs are not generative anymore.


Note that tags are compared with @racket[eq?] (or @racket[memq]), which 
means

an interface can hide its value from users (e.g., not provide the
@racket[cpointer-tag] accessor), which makes such pointers un-fake-able.

If you would like document the fact that cstructs are generative only up 
to version 5.1.3.  I think that improve the docs.

Thanks,

Kevin


John



_
   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] Downloading DrRacket for Mac is hard?

[Kevin Tew]

look at the firefox download page for an example:
There is a nice huge pretty button that is the download for your current 
platform.
Below the big button there is a small link that says "All Systems & 
Languages " which links 
to the matrix of all possible downloads.


I think http://www.mozilla.com/ is an excellent landing page for "Here, 
Get Our Stuff".


Kevin

On 08/11/2011 10:48 AM, Matthias Felleisen wrote:

His answer was inappropriate. Our goal must be to understand
problems posed, check relevance, figure out a solution. There
is no other default mode.



On Aug 11, 2011, at 8:54 AM, Jay McCarthy wrote:


Maybe Eli is saying that 64bit is really the better default, given new
OS X defaults.

Jay

On Thu, Aug 11, 2011 at 6:23 AM, Robby Findler
  wrote:

Why would it damage more people?

I think it makes sense to put on the first page some kind of an
indication that "this is what we guess your machine is; if you don't
know, try this one first". Perhaps not Guillaume's exact words, but
something that would help this person.

Robby

On Thu, Aug 11, 2011 at 2:25 AM, Eli Barzilay  wrote:

On Aug 10, 2011, at 11:33 PM, Guillaume Marceau  wrote:

Does the combo box auto detect the
downloader's platform for the User-Agent header.

Yes, in some cases when it's possible to make a guess.



If so, then the next
step is to change the layout to:

  Download:  __Macintosh OS X (Intel i386)__
  (this is the version of DrRacket for your system. In rare cases,
you might need a version for a __different system__)

This will damage many more people.
_
  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


_
   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] gtk & too-small menu bar

[Kevin Tew]

Its fixed for me now.

Ubuntu 11.04 x86_64.

Thanks.

On 05/17/2011 10:04 AM, Robby Findler wrote:

In consultation with Matthew, I've pushed a change that fixes the too
small menu bar problem, at least on a VM on my laptop.

If you're seeing this problem, can you check and see if the change
fixes it for you too?

Also, if someone could try it out on a unity setup, that'd be helpful.

Thanks,
Robby
_
   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] wishes

[Kevin Tew]

On 05/06/2011 09:44 AM, Vincent St-Amour wrote:

At Fri, 6 May 2011 11:22:48 -0400,
Matthias Felleisen wrote:

1. Python seems to provide the following unit testing functionality:

if a file/module is run as 'main', the test suites are run;
if it is required into some other file, the tests aren't run.

It looks truly convenient. I believe we should be able to write a
define-test-suite macro that can do that too.

Along these lines, a "raco test" command that runs the tests for a
file, without running the program itself, would be great.

Vincent
_
   For list-related administrative tasks:
   http://lists.racket-lang.org/listinfo/dev
racket -tm some_module.rkt  runs the main function in some_module.rkt. 
with the command-line arguments


Welcome to Racket v5.1.1.4.
racket [ ...]  ...
 File and expression options:
 -t , --require  : Like -e '(require (file ""))'
 -m, --main : Call `main' with command-line arguments, print results

I would like racket -tM some_module.rkt some_function to run 
some_function in the same manner as -tm runs main.

e.g.
racket -tM my_module.rkt  main
racket -tM my_module.rkt  core-tests
racket -tM my_module.rkt  tests

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

[racket-dev] Parallel build switched to use Places by default.

[Kevin Tew]

The parallel build has been changed again to use places by default. (The 
previous memory leak problems have been fixed.)
This means that parallel zo and doc builds will use places instead of 
processes.


Please look out for any unusual behavior and report bugs as usual

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

Re: [racket-dev] Memory consumption of Racket

[Kevin Tew]

If your willing, we would like to see your code changes/patches get 
integrated back into the project.
This is the best way to get more developers interested and willing to 
work on Racket for iOS.


Are you willing to share your changes?
We are willing to take them in any form, clean them up, and get them 
committed.


Kevin


On 04/25/2011 06:15 PM, Nevo wrote:

hi Kevin:
  I've successfully enabled places with a few in-code fix to be 
compiler happy, mostly are implement atomic operations using 
OSAtomicXXX provided by Apple and emit arm instruction instead of 
thumb. It just run without low memory crashes (at least per my recent 
runs), although still getting a level 1 memory warning which is common 
for most of complicated softwares in iOS I think. But I would be 
rather appreciated if you have something else which I can look into by 
myself to further reduce memory consumption. Thanks!


Cheers
Nevo

On 23 April 2011 21:24, Nevo <mailto:sakur.dea...@gmail.com>> wrote:


hi Kevin:
  Thanks for your help here. I'm trying to enable "place" first
then I think I can apply your patch. Is there still a way to
reduce unused memory as in your patch, but without the need of
"place"?

Nevo


On 23 April 2011 21:16, Kevin Tew mailto:t...@cs.utah.edu>> wrote:

Here is another patch you can try to reduce caching of unused
memory.

diff --git a/src/racket/gc2/alloc_cache.c
b/src/racket/gc2/alloc_cache.c
index 44895af..d1f1c03 100644
--- a/src/racket/gc2/alloc_cache.c
+++ b/src/racket/gc2/alloc_cache.c
@@ -10,7 +10,7 @@
 */

 /* Controls how often freed pages are actually returned to OS: */
-#define BLOCKFREE_UNMAP_AGE 3
+#define BLOCKFREE_UNMAP_AGE 0

 /* Controls size of the cache */
 #define BLOCKFREE_CACHE_SIZE 3000



On 04/23/2011 05:14 AM, Jens Axel Søgaard wrote:

2011/4/22 Nevomailto:sakur.dea...@gmail.com>>:

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.

Great news.

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.

I am curious which iPhone and which iPad?

For the non-iPad owners here are a few (unofficial) specs,
so you
have a rough idea of how much memory the iDevices have:

Internal RAM for:
  iPad 2512MB
  iPad 1256MB

  iPhone 4 512MB
  iPhone 3GS256MB
  iPhone 3G  128MB
  iPhone   128MB






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

Re: [racket-dev] Memory consumption of Racket

[Kevin Tew]

Here is another patch you can try to reduce caching of unused memory.

diff --git a/src/racket/gc2/alloc_cache.c b/src/racket/gc2/alloc_cache.c
index 44895af..d1f1c03 100644
--- a/src/racket/gc2/alloc_cache.c
+++ b/src/racket/gc2/alloc_cache.c
@@ -10,7 +10,7 @@
 */

 /* Controls how often freed pages are actually returned to OS: */
-#define BLOCKFREE_UNMAP_AGE 3
+#define BLOCKFREE_UNMAP_AGE 0

 /* Controls size of the cache */
 #define BLOCKFREE_CACHE_SIZE 3000


On 04/23/2011 05:14 AM, Jens Axel Søgaard wrote:

2011/4/22 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.

Great news.


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.

I am curious which iPhone and which iPad?

For the non-iPad owners here are a few (unofficial) specs, so you
have a rough idea of how much memory the iDevices have:

Internal RAM for:
   iPad 2512MB
   iPad 1256MB

   iPhone 4 512MB
   iPhone 3GS256MB
   iPhone 3G  128MB
   iPhone   128MB



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

Re: [racket-dev] Memory consumption of Racket

[Kevin Tew]

BLOCK_CACHE IS enabled by default in 5.1.1.3.
#define MZ_USE_PLACES (the default as of 5.1.1.3) enables block cache 
(see top of gc2/vm.c file).


If you have a pre 5.1.1 version or have places disabled, then my block 
cache patch won't be of any help.


Kevin



On 04/23/2011 01:09 AM, Nevo wrote:

hi Kevin:
  Your patch seems requiring "USE_BLOCK_CACHE" to be enabled. Sorry 
for my lack of knowledge into Racket's memory management component, 
how can I safely enable that because I cannot find its reference in 
configure or Makefile.in? Thanks!


Nevo

On 23 April 2011 14:27, Nevo > wrote:


hi Robby
  Just back from out of town, sorry for the late reply.
  No. This doesn't help at all, still got low-memory killing on my
ipad. Actually, my own test is all based on "#lang racket/base".
I'll try Kevin's patch to see any difference. I've also tried to
throttle the max_pages_in_heap to allow around 25MB pages to use,
it will soon throw "out of memory" exception and abort after a
couple of GC cycles.

Nevo


On 22 April 2011 19:08, Robby Findler mailto:ro...@eecs.northwestern.edu>> wrote:

This program:

 #lang racket/base
 (printf "hi\n")

uses a lot less memory than this one:

 #lang racket
 (printf "hi\n")

Does that help at all?

Robby

On Fri, Apr 22, 2011 at 12:09 AM, Nevo mailto:sakur.dea...@gmail.com>> wrote:
> 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
>





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

Re: [racket-dev] Memory consumption of Racket

[Kevin Tew]

You might try this patch

diff --git a/src/racket/gc2/block_cache.c b/src/racket/gc2/block_cache.c
index dd522aa..c34c2df 100644
--- a/src/racket/gc2/block_cache.c
+++ b/src/racket/gc2/block_cache.c
@@ -7,7 +7,7 @@ static void  *os_alloc_pages(size_t len);
 static void   os_free_pages(void *p, size_t len);
 static void   os_protect_pages(void *p, size_t len, int writable);

-#define BC_BLOCK_SIZE (1 << 24)  /* 16 MB */
+#define BC_BLOCK_SIZE (1 << 21)  /* 2 MB */

 struct block_desc;
 static AllocCacheBlock *alloc_cache_create();


On 04/22/2011 05:08 AM, Robby Findler wrote:

This program:

   #lang racket/base
   (printf "hi\n")

uses a lot less memory than this one:

   #lang racket
   (printf "hi\n")

Does that help at all?

Robby

On Fri, Apr 22, 2011 at 12:09 AM, Nevo  wrote:

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


_
   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] [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)

[Kevin Tew]

On 04/19/2011 10:26 AM, John Clements wrote:

On Apr 19, 2011, at 8:27 AM, Kevin Tew wrote:


The configure script has been changed to enable places by default.
Note:  places are NOT enabled by default for the upcoming V5.1.1 release.

This means that parallel zo and doc builds will use places instead of processes.

Should I expect to see speed or space differences as a result of this change?  
Will the one process be about the same size as the sum of the old two (or three 
or ...) ?

No significant speed or space differences.

Yes the size should be ~ the sum of the old two (or three or ...) processes

Hoping for magical things,

That's the next step, remove duplication and Increase sharing of constant.
Using something similar to Jay's serializable closures is also a 
possible, future magical thing.


Kevin

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

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

[Kevin Tew]

The configure script has been changed to enable places by default.
Note:  places are NOT enabled by default for the upcoming V5.1.1 release.

This means that parallel zo and doc builds will use places instead of 
processes.


Report bugs as usual :)

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

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

[Kevin Tew]

Speaking of hashing I though Google's new fast CityHash implementation 
was interesting.

http://google-opensource.blogspot.com/2011/04/introducing-cityhash.html

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

mflatt has updated `master' from 91d98aa0fa to f6d185abab.
   http://git.racket-lang.org/plt/91d98aa0fa..f6d185abab

=[ 4 Commits ]==

Directory summary:
8.9% collects/setup/
   56.3% src/racket/src/
   17.3% src/racket/
   17.3% src/

~~

8a2d587 Matthew Flatt  2011-04-11 16:38
:
| minor hash tuning
:
   M src/racket/src/bool.c |   68 +-
   M src/racket/src/env.c  |   14 ++---
   M src/racket/src/hash.c |6 +++-

~~

f36e3ad Matthew Flatt  2011-04-11 23:29
:
| small clean-ups
:
   M collects/setup/setup-unit.rkt |7 +--

~~

efed709 Matthew Flatt  2011-04-12 10:21
:
| improve error reporting when using exec
:
   M src/racket/src/port.c |   10 +-

~~

f6d185a Matthew Flatt  2011-04-13 10:56
:
| configure: use `pkg-config' for libffi
:
   M src/configure   |   32 +++-
   M src/racket/configure.ac |   32 +++-

=[ Overall Diff ]===

collects/setup/setup-unit.rkt
~
--- OLD/collects/setup/setup-unit.rkt
+++ NEW/collects/setup/setup-unit.rkt
@@ -684,9 +684,12 @@
  (match (parallel-workers)
[(? (lambda (x) (x .>  . 1)))
  (compile-cc (collection->cc (list (string->path "racket"))) 0)
-(managed-compile-zo (build-path main-collects-dir  
"setup/parallel-build-worker.rkt"))
+(managed-compile-zo (collection-file-path "parallel-build-worker.rkt" 
"setup"))
  (with-specified-mode
-  (let ([cct (move-to-begining (list "compiler" "raco" "racket") (move-to-end 
"drscheme" (sort-collections-tree (collection-tree-map top-level-plt-collects])
+  (let ([cct (move-to-begining (list "compiler" "raco" "racket")
+   (move-to-end "drscheme"
+(sort-collections-tree
+ (collection-tree-map 
top-level-plt-collects])
  (iterate-cct (lambda (cc)
(let ([dir (cc-path cc)]
  [info (cc-info cc)])

src/configure
~
--- OLD/src/configure
+++ NEW/src/configure
@@ -5120,8 +5120,34 @@ if test "${enable_libffi}" = "yes" ; then
   if test "${enable_foreign}" = "yes" ; then
{ echo "$as_me:$LINENO: checking for libffi">&5
  echo $ECHO_N "checking for libffi... $ECHO_C">&6; }
+
+  # Try to get flags form pkg-config:
+  libffi_config_prog="pkg-config libffi"
+  libffi_config_preflags=`$libffi_config_prog --cflags-only-I  2>  /dev/null`
+  if test "$?" = 0 ; then
+libffi_config_cflags=`$libffi_config_prog --cflags-only-other  2>  
/dev/null`
+if test "$?" = 0 ; then
+  libffi_config_ldflags=`$libffi_config_prog --libs  2>  /dev/null`
+  if test "$?" != 0 ; then
+libffi_config_preflags=""
+libffi_config_cflags=""
+libffi_config_ldflags="-lffi"
+  fi
+else
+  libffi_config_preflags=""
+  libffi_config_cflags=""
+  libffi_config_ldflags="-lffi"
+fi
+  else
+libffi_config_preflags=""
+libffi_config_cflags=""
+libffi_config_ldflags="-lffi"
+  fi
+
+  OLD_CFLAGS="${CFLAGS}"
OLD_LDFLAGS="${LDFLAGS}"
-  LDFLAGS="${LDFLAGS} -lffi"
+  CFLAGS="${CFLAGS} ${libffi_config_preflags} ${libffi_config_cflags}"
+  LDFLAGS="${LDFLAGS} ${libffi_config_ldflags}"
cat>conftest.$ac_ext<<_ACEOF
  /* confdefs.h.  */
  _ACEOF
@@ -5169,9 +5195,13 @@ rm -f core conftest.err conftest.$ac_objext 
conftest_ipa8_conftest.oo \
{ echo "$as_me:$LINENO: result: $have_libffi">&5
  echo "${ECHO_T}$have_libffi">&6; }
if test "${have_libffi}" = "no" ; then
+CFLAGS="${OLD_CFLAGS}"
  LDFLAGS="${OLD_LDFLAGS}"
  echo "Building own libffi"
else
+CFLAGS="${OLD_CFLAGS}"
+PREFLAGS="${PREFLAGS} ${libffi_config_preflags}"
+CFLAGS="${COMPFLAGS} ${libffi_config_cflags}"
  echo "Using installed libffi"
  OWN_LIBFFI="OFF"
fi

src/racket/configure.ac
~~~
--- OLD/src/racket/configure.ac
+++ NEW/src/racket/configure.ac
@@ -855,8 +855,34 @@ AC_MSG_RESULT($mbsrtowcs)
  if test "${enable_libffi}" = "yes" ; then
   if test "${enable_foreign}" = "yes" ; then
AC_MSG_CHECKING([for libffi])
+
+  # Try to get flags form pkg-config:
+  libffi_config_prog="pkg-config libffi"
+  libffi_config_preflags=`$libffi_config_prog --cflags-only-I  2>  /dev/null`
+  if test "$?" = 0 ; then
+libffi_config_cflags=`$libffi_config_prog --cflags-only-other  2>  
/dev/null`
+if test "$?" = 0 ; then
+  libffi_config_ldflags=`$libffi_config_prog --libs  2>  /dev/null`
+  if test "$?" != 0 ; then

Re: [racket-dev] a few bugs

[Kevin Tew]

fix pushed

On 03/28/2011 06:08 PM, Sam Tobin-Hochstadt wrote:

A simple experiment with parallelism and syntax exposed several Racket
bugs.  All of these programs start with this header:

#lang racket

(require racket/future)
(current-directory "collects/racket/private")
(current-namespace (make-base-namespace))

(define (big) (expand (read-syntax #f (open-input-file "for.rkt"

(define (go1)
   (let loop ([s (big)])
 (syntax-case s ()
   [(a . b) (loop #'a) (loop #'b)]
   [_ (display 1)])))

Then, if we do:

(define (gon)
   (for ([i (in-range 1000)]) (go1)))

(define l (list (future gon) (future gon)))
(map touch l)

we get this error:
   make-vector: expected argument of type;
given 831868466

If we do:

(define l (list (future go1) (future go1)))
(map touch l)

Then we sometime get segfaults, and sometimes run to completion.

If we just do:

(go1)

Then it runs correctly in Racket, but consistently segfaults in
DrRacket, like this:

   Seg fault (internal error during gc) at 0x8147c64
   SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0x8147c64

This is all with the latest Git, *with --enable-places* (although
places aren't used).


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

Re: [racket-dev] Making --enable -places the default.

[Kevin Tew]

Being able to sync on when they terminate?
Thats pretty easy to add, I should do it.

Place currently is an event you can sync on, but it becomes ready when a 
message arrives.  Not when it terminates.

On 03/28/2011 05:34 PM, Sam Tobin-Hochstadt wrote:

Not a bug or crash, but it would be nice if a `place' was an event, in
the sense of `evt?'.  Come to think of it, this would be good for
`future' as well.

On Mon, Mar 28, 2011 at 1:08 PM, Kevin Tew  wrote:

I would like to make --enable-places the default in the near future.

I would appreciate it, if racket developers could configure and build with
--enable-places
and report any bugs or crashes.

Thanks,
Kevin

_
  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] Making --enable -places the default.

[Kevin Tew]

I would like to make --enable-places the default in the near future.

I would appreciate it, if racket developers could configure and build 
with --enable-places

and report any bugs or crashes.

Thanks,
Kevin

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

Re: [racket-dev] MySQL connect in Racket

[Kevin Tew]

Google for plt planet mysql

http://planet.plt-scheme.org/display.ss?package=mysql.plt

Note that the planet web server is down right now, so the page won't 
load,  check it later today.


Kevin Tew

On 01/21/2011 02:38 PM, Insik Cho wrote:

Hi racketers,

I would like to build a test web server in racket, and need to connect 
to MySQL dbms.


Googling with keywords 'racket lang mysql connect', I couldn't get any 
clue.


Do you have any idea?

- Joe


_
   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] Fwd: Re: [plt-scheme] Recommended style for ncurses ffi?

[Kevin Tew]

 Original Message 
Subject:Re: [plt-scheme] Recommended style for ncurses ffi?
Date:   Tue, 16 Nov 2010 13:47:59 -0600
From:   Michael Forster 
To: Kevin Tew 



On Thu, Nov 11, 2010 at 10:11 PM, Kevin Tew  wrote:

 How far along did you get with your ncurses impl?
 Would you be willing to put it on github?

 Kevin Tew



Hi Kevin,

Not too far before we encountered reliability problems with PLT Scheme
in our 64bit FreeBSD deployment environment.  We posted a bug report
and core stack trace to PLT regarding the segfaults and socket
disconnects we were receiving, but it was closed as being an "os
problem".  However, since that environment runs several applications
written in various versions each of Common Lisp, Haskell, and OCaml --
all without a single segfault or other serious failure -- we had to
dump PLT Scheme.  Too bad.  We did like PLT Scheme, but business
demanded that we move on.


Regards,

Mike

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

[racket-dev] Fwd: Re: parallel build error

[Kevin Tew]

Jay, Your DrDr error resembles Robby's past problem below.

I capture STDOUT and STDERROR during compile so I'm curious to how these 
problems arise.


My only guess is that a debug printf got introduced into collects/setup 
or collects/compiler


 Original Message 
Subject:Re: parallel build error
Date:   Fri, 17 Sep 2010 11:27:12 -0500
From:   Robby Findler 
To:     Kevin Tew 
CC: Matthew Flatt , Eli Barzilay 



I had a printf in there. Maybe that screwed things up?

This was a version from a few days ago, I think. After removing the
printf and getting the latest, the problem is gone.

Sorry for the noise.

Robby

On Fri, Sep 17, 2010 at 11:21 AM, Kevin Tew  wrote:

 I haven't changed anything, did the info format change?
 It looks like info information is bleeding into the list of files to be
 compiled.

 I'll keep looking.

 Kevin

 On 09/17/2010 09:51 AM, Robby Findler wrote:


 Is this a bug in the parallel build support?

 raco setup: --- parallel build using 8 processor cores ---
 match: no matching clause for (list (list (cc '(#
 #) #
 "at-exp/lang" ##
 #
 '((lib "at-exp" ...

   === context ===
 /Users/robby/git/plt/collects/racket/match/runtime.rkt:19:0: match:error
 /Users/robby/git/plt/collects/setup/parallel-do.rkt:102:69
 /Users/robby/git/plt/collects/setup/setup-unit.rkt:604:17: thunk
 /Users/robby/git/plt/collects/setup/setup-go.rkt: [running body]
 /Users/robby/git/plt/collects/raco/main.rkt: [running body]

 Robby






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

Re: [racket-dev] Racket runs on 64-bit ubuntu, right?

[Kevin Tew]

I should have added that the student also needs to type
gdb> backtrace
to get a full backtrace.

a full backtrace will be more informative.


racket segfaults always end in with a SIGABRT due to our custom use of 
the SIGSEGV handler.

So the stack below is typical of segfaults.


On 10/07/2010 04:18 PM, John Clements wrote:

On Oct 5, 2010, at 10:37 AM, Kevin Tew wrote:


I build on 64bit ubuntu every day.
a gdb backtrace would be helpful.

gdb>  handle SIGSEGV nostop noprint
gdb>  run

Kevin

I finally got a reply from the student. Here's what he said:


Ok, sorry this took so long, but I had to do the ritual restoring of grub after 
installing windoze.

The contents of the terminal: I highlighted my input, and also the error I get 
when I try just running drracket.


Note; I did not run a backtrace on drracket, but gracket, which drracket links 
to. When I tried to run a backtrace on drracket it said it was not an 
executable, so I read the contents of drracket and it just links to gracket.

tm...@brutus:~$ gdb /home/tmill/racket/plt-5.0.1.7/bin/gracket
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tmill/racket/plt-5.0.1.7/bin/gracket...done.
(gdb) handle SIGSEGV nostop noprint
SignalStopPrintPass to programDescription
SIGSEGV   NoNoYesSegmentation fault
(gdb) run
Starting program: /home/tmill/racket/plt-5.0.1.7/bin/gracket
[Thread debugging using libthread_db enabled]
[New Thread 0x746d7710 (LWP 8906)]
SIGSEGV MAPERR si_code 1 fault on addr 0x4

Program received signal SIGABRT, Aborted.
0x75e72ba5 in raise (sig=)
 at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
 in ../nptl/sysdeps/unix/sysv/linux/raise.c

 From Tony

This sure doesn't *look* like the font issue that Matthew mentioned

John



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

Re: [racket-dev] Racket runs on 64-bit ubuntu, right?

[Kevin Tew]

I build on 64bit ubuntu every day.
a gdb backtrace would be helpful.

gdb> handle SIGSEGV nostop noprint
gdb> run

Kevin

On 10/05/2010 11:26 AM, John Clements wrote:

I have a student who hasn't succeeded in running compiled-from-source DrRacket 
on 64-bit ubuntu.  Specifically, he claims it dumps core with


SIGSEGV MAPERR si_code 1 fault on addr 0x4
Aborted


on startup.  I have *not* tried to verify this myself, so he's almost certainly made a 
minor mistake.  I'm writing this just in case one of you has a knee-jerk "oh yeah, 
that doesn't work"  to give me.  Otherwise, please ignore this e-mail.

John



_
   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] Problem with GC or with my machine?

[Kevin Tew]

Yes can you send me the code?
The smaller the better :)

Kevin

On 09/02/2010 09:27 PM, Hari Prashanth wrote:

I am getting the following error... And this is the only message I get...

SIGSEGV MAPERR si_code 1 fault on addr 0xfffc
This often means 0xfffc isn't getting marked, and was prematurely 
freed
Aborted

What does it mean? Has anyone seen this?

If you want to take a look at the code that is causing this, let me know.

Hari

_
   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] gc vs assignment

[Kevin Tew]

On 08/24/2010 11:38 AM, Jay McCarthy wrote:

On Tue, Aug 24, 2010 at 10:53 AM, Joe Marshall  wrote:
   

I'm surprised that racket3m uses page protection.  Taking a hardware trap
can often be thousands of times slower than taking an inline conditional
branch.
 

My understanding is that 3m does this because it is doing exact
garbage-collection on the C code rather than just on the Racket. I
presume that it would be hard (and useful) engineering to make it GC
more traditionally.

Jay

   

Right.
To use more traditional write barriers, xform would need to become a lot 
smarter, inserting write barriers at assignments in the c code.

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

Re: [racket-dev] gc vs assignment

[Kevin Tew]

After a garbage collection all non-nursery memory is write-protected.
The first write to a page (16kB) , after a garbage collection, incurs 
the cost of unprotecting the page so it is writable and recording that 
the page has been written on.
All subsequent mutations to objects in a unprotected page do not have a 
write barrier cost, until the next garbage collection run.


At then next garbage collection all unprotected pages are 
re-write-protected and subsequent first page access will have a write 
barrier cost.


Kevin

On 08/24/2010 09:04 AM, Matthias Felleisen wrote:

And what if they don't live in the nursery?


On Aug 24, 2010, at 10:51 AM, Kevin Tew wrote:

   

Write barriers in racket3m are implemented using memory protection primitives 
provided by the OS.
Between collections we only incur a write barrier cost the first time a page 
(16k in racket) is written to.
After the first access per page, additional mutations on that page have no 
extra cost, until the gc collects again.
Mutating objects living in the nursery has no gc overhead.

Kevin

On 08/24/2010 08:18 AM, Matthias Felleisen wrote:
 

Yes, I was taught the same thing in 1984. That's not the issue.



On Aug 24, 2010, at 10:17 AM, Robby Findler wrote:


   

My experience is that allocation is the primary thing to look for to
improve performance.

Robby

On Tuesday, August 24, 2010, Matthias Felleisen   wrote:

 

Catching up with some mail.

Neil wrote:


   

Avoiding allocation reduces GC collects, which reduces stutters and hitches.

 

My (possibly old) understanding of GC and mutation tell me that this is one of 
those prejudices that programmers should get rid of. Every mutation goes across 
an access barrier in a GC like ours and can thus be much more expensive than a 
lightweight allocation. This was certainly true for early generational 
collectors. I do know that the hordes of Java programmers who invaded GCLand 
forced GC builders to make C/C++-like programs in Java work reasonably fast 
with collectors and so collectors changed.

Matthew, do you know what it's really like for us?
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


   

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

   

_
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] gc vs assignment

[Kevin Tew]

Write barriers in racket3m are implemented using memory protection 
primitives provided by the OS.
Between collections we only incur a write barrier cost the first time a 
page (16k in racket) is written to.
After the first access per page, additional mutations on that page have 
no extra cost, until the gc collects again.

Mutating objects living in the nursery has no gc overhead.

Kevin

On 08/24/2010 08:18 AM, Matthias Felleisen wrote:

Yes, I was taught the same thing in 1984. That's not the issue.



On Aug 24, 2010, at 10:17 AM, Robby Findler wrote:

   

My experience is that allocation is the primary thing to look for to
improve performance.

Robby

On Tuesday, August 24, 2010, Matthias Felleisen  wrote:
 

Catching up with some mail.

Neil wrote:

   

Avoiding allocation reduces GC collects, which reduces stutters and hitches.
 

My (possibly old) understanding of GC and mutation tell me that this is one of 
those prejudices that programmers should get rid of. Every mutation goes across 
an access barrier in a GC like ours and can thus be much more expensive than a 
lightweight allocation. This was certainly true for early generational 
collectors. I do know that the hordes of Java programmers who invaded GCLand 
forced GC builders to make C/C++-like programs in Java work reasonably fast 
with collectors and so collectors changed.

Matthew, do you know what it's really like for us?
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

   

_
   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] How to build Places

[Kevin Tew]

Places is ready for experimentation by a wider audience.

Build Instructions

mkdir build_places
cd build_places
../src/configure --enable-places
make
make install

Basic place API documentation should build in your user docs directory.
collects/tests/racket/place-channel.rktl tests communication of simple 
datatypes.



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

Re: [racket-dev] Release Announcement for v5.0.1

[Kevin Tew]

How is this:

By default make install and raco setup build collects in parallel on all 
available processors.
Use env PLT_SETUP_OPTIONS="-j 1" make install or raco setup -j 1 to 
build using only one processor.


Kevin

On 07/27/2010 10:06 AM, Eli Barzilay wrote:

On Jul 27, Kevin Tew wrote:
   

Parallel-build is somewhat behind the scenes.  I would delay talking
about it until the next release which will include -j documentation
and parallel rendering of docs.
 

Normally I'd agree with hiding it as a detail, but since it's on by
default and it is a place which can easily break things up I want to
have at least a short "JFYI-style" note on it.

   


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

Re: [racket-dev] State of Places (native threads)

[Kevin Tew]

It isn't ready for use yet.

I'm working on parallel build of collects and docs right now.
That work is almost done and then I'll go back to working on places.

We have been able to use places, comparing parallel build using both 
processes and places.

But it still isn't ready for public use.

Kevin


On 07/14/2010 07:52 AM, Paulo J. Matos wrote:

Hi,

What's the state of places in racket? Is it already usable?
How can I give it a try?

Cheers,

   


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

Re: [racket-dev] Parallel Build of Collects

[Kevin Tew]

I'm fine with renaming -u to -J.


On 07/05/2010 04:37 PM, Eli Barzilay wrote:

On Jul  5, Kevin Tew wrote:
   

Parallel build of collects is now the default option.

You can change the setup options by specify an environment variable
to make install

Examples:
; only use one processor
SETUP_OPTIONS="-j 1" make install
or
; use three processors don't build docs
SETUP_OPTIONS="-j 1 -D" make install

raco setup -u now means uniprocessor.  It will build collects using
the original serial process (before parallel build was committed)
 

Why not something that is more related to "-j" like "-J" or "+j"?
(Especially given that it's not the same as "-j 1", so it's not really
an option to be used for a uniprocessor situation).

   


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

Re: [racket-dev] Parallel Build of Collects

[Kevin Tew]

Parallel build of collects is now the default option.

You can change the setup options by specify an environment variable to 
make install


Examples:
; only use one processor
SETUP_OPTIONS="-j 1" make install
or
; use three processors don't build docs
SETUP_OPTIONS="-j 1 -D" make install

raco setup -u now means uniprocessor.  It will build collects using the 
original serial process (before parallel build was committed)


Kevin

On 07/02/2010 02:44 PM, Kevin Tew wrote:
raco setup -u will build collects in parallel, using all the cores 
your machine has.
rack setup -u -j X ie (-j 2) can be used to throttle parallel build to 
only use X cores.


Parallel build is currently done by spawning worker processes and 
communicating over pipes.
Building scribble documentation is still serial, I'm working to 
parallelize that as well.


Kevin


_
 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] Parallel Build of Collects

[Kevin Tew]

raco setup -u will build collects in parallel, using all the cores your 
machine has.
rack setup -u -j X ie (-j 2) can be used to throttle parallel build to 
only use X cores.


Parallel build is currently done by spawning worker processes and 
communicating over pipes.
Building scribble documentation is still serial, I'm working to 
parallelize that as well.


Kevin


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