Re: [racket-dev] Using clang to Build Racket on Mac OS X

2011-09-10 Thread Will M. Farr
Thanks, Matthew!  It seems to build OK now.  

Will

On Sep 11, 2011, at 6:42 AM, Matthew Flatt wrote:

 At Wed, 27 Jul 2011 10:38:44 -0500, Will M. Farr wrote:
 The only wart in the process is the following: when compiling with clang or 
 llvm-gcc with the -O4 option, which enables link-time optimization in the 
 LLVM 
 backend, the GC is unable to correctly determine the stack growth direction. 
  
 Unfortunately, the configure script doesn't realize that it cannot determine 
 the direction---apparently the test gets it wrong, but appears 
 successful---so 
 supplying the direction manually via the configure argument doesn't work.  
 The 
 build fails when first trying to run raco setup when the GC notes that the 
 stack growth is inconsistent with its assumptions.  
 
 I've pushed a fix for this problem, along with other changes to avoid
 warnings when compiling with clang.
 



PGP.sig
Description: This is a digitally signed message part
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Using clang to Build Racket on Mac OS X

2011-07-27 Thread Will M. Farr
Hello Racket Developers,

I thought I would write a quick note about building Racket on Mac OS X 10.6.8 
with the new clang compiler (the new front-end to the LLVM compiler backend 
that is becoming the standard compiler on Mac OS X for XCode 4 and later).  
Overall, it's been a good experience.  As promised, clang seems to compile the 
C sources in the racket distribution much more quickly than gcc, and has 
better-formatted error and warning messages.  I believe that the resulting 
native code libraries make racket run faster, but haven't run any detailed 
tests (there was quite a gap between my last gcc-based build and my first 
clang-based one, so the improvements may also be due to Racket development).  

The only wart in the process is the following: when compiling with clang or 
llvm-gcc with the -O4 option, which enables link-time optimization in the LLVM 
backend, the GC is unable to correctly determine the stack growth direction.  
Unfortunately, the configure script doesn't realize that it cannot determine 
the direction---apparently the test gets it wrong, but appears successful---so 
supplying the direction manually via the configure argument doesn't work.  The 
build fails when first trying to run raco setup when the GC notes that the 
stack growth is inconsistent with its assumptions.  

I'm writing this email partly to see if anyone else has seen the error and 
knows what to do about it, and partly because I thought you might like to know 
how racket fairs on the newer OS X compiler.  If someone wants to test 
modifications to the configure script's stack growth test, I would be happy to 
take patches and test-compile them on my system.  For now, I am having great 
luck building with clang -O3; eventually, it would be nice to have the LTO, 
since that's one of the most exciting benefits of using the LLVM toolchain.

Thanks again for the Racket system!

Will

PGP.sig
Description: This is a digitally signed message part
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] flvector-copy

2010-09-16 Thread Will M. Farr
Hello all,

The attached patch against the current git master adds an flvector-copy 
procedure (along with docs and tests); it's simple, but nice to have in the 
flvector library.  Let me know if there are any issues with including this in 
racket.

Thanks,
Will



0004-Added-flvector-copy-with-tests-and-docs.patch
Description: Binary data
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Contract Errors in the Test Suite

2010-09-12 Thread Will M. Farr
FYI, I've submitted a bug to the bug tracker detailing this problem.

Will

On Sep 11, 2010, at 5:04 PM, Will M. Farr wrote:

 I've finished the testing of configure options.  It seems to be the places 
 library.  Running with or without optimization options, the --enable-places 
 flag to configure generates a racket that fails the contract tests in the way 
 I described in my original email.  
 
 Will
 
 On Sep 11, 2010, at 4:39 PM, Will M. Farr wrote:
 
 On Sep 11, 2010, at 4:20 PM, Robby Findler wrote:
 
 My laptop has a version of the tree
 from about 10 days ago and I'm not seeing any errors there. Is there
 something more that would help me reproduce this behavior?
 
 Thanks,
 Robby
 
 Huh.  Or maybe it's option 4: system/OS dependent.  I'm running on a Mac OS 
 10.6.4, Core 2 Duo system, compiling with gcc 4.2.1 (Apple version), in 
 64-bit mode (no gracket, since it doesn't work with 64-bit yet).  Configure 
 options:
 
 CFLAGS=-O3 -march=core2 CXXFLAGS=-O3 -march=core2 --enable-mac64 
 --disable-gracket --enable-places
 
 I'm trying a build right now without the optimization options to the C 
 compiler, and with places disabled; I'll let you know whether that fixes 
 anything.  
 
 I run the test suite using 
 
 bin/racket collects/tests/run-automated-tests.rkt
 
 from the top-level directory of the source repository (i.e. using the 
 newly-build racket, not the one I have installed on my system).
 
 Anything in this jumping out at you as the possible source of the problem?
 
 Thanks,
 Will
 

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


Re: [racket-dev] Contract Errors in the Test Suite

2010-09-11 Thread Will M. Farr
On Sep 11, 2010, at 4:20 PM, Robby Findler wrote:

 My laptop has a version of the tree
 from about 10 days ago and I'm not seeing any errors there. Is there
 something more that would help me reproduce this behavior?
 
 Thanks,
 Robby

Huh.  Or maybe it's option 4: system/OS dependent.  I'm running on a Mac OS 
10.6.4, Core 2 Duo system, compiling with gcc 4.2.1 (Apple version), in 64-bit 
mode (no gracket, since it doesn't work with 64-bit yet).  Configure options:

CFLAGS=-O3 -march=core2 CXXFLAGS=-O3 -march=core2 --enable-mac64 
--disable-gracket --enable-places

I'm trying a build right now without the optimization options to the C 
compiler, and with places disabled; I'll let you know whether that fixes 
anything.  

I run the test suite using 

bin/racket collects/tests/run-automated-tests.rkt

from the top-level directory of the source repository (i.e. using the 
newly-build racket, not the one I have installed on my system).

Anything in this jumping out at you as the possible source of the problem?

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


Re: [racket-dev] Contract Errors in the Test Suite

2010-09-11 Thread Will M. Farr
I've finished the testing of configure options.  It seems to be the places 
library.  Running with or without optimization options, the --enable-places 
flag to configure generates a racket that fails the contract tests in the way I 
described in my original email.  

Will

On Sep 11, 2010, at 4:39 PM, Will M. Farr wrote:

 On Sep 11, 2010, at 4:20 PM, Robby Findler wrote:
 
 My laptop has a version of the tree
 from about 10 days ago and I'm not seeing any errors there. Is there
 something more that would help me reproduce this behavior?
 
 Thanks,
 Robby
 
 Huh.  Or maybe it's option 4: system/OS dependent.  I'm running on a Mac OS 
 10.6.4, Core 2 Duo system, compiling with gcc 4.2.1 (Apple version), in 
 64-bit mode (no gracket, since it doesn't work with 64-bit yet).  Configure 
 options:
 
 CFLAGS=-O3 -march=core2 CXXFLAGS=-O3 -march=core2 --enable-mac64 
 --disable-gracket --enable-places
 
 I'm trying a build right now without the optimization options to the C 
 compiler, and with places disabled; I'll let you know whether that fixes 
 anything.  
 
 I run the test suite using 
 
 bin/racket collects/tests/run-automated-tests.rkt
 
 from the top-level directory of the source repository (i.e. using the 
 newly-build racket, not the one I have installed on my system).
 
 Anything in this jumping out at you as the possible source of the problem?
 
 Thanks,
 Will

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


Re: [racket-dev] gc vs assignment

2010-08-24 Thread Will M. Farr
On Aug 24, 2010, at 10:46 AM, Matthias Felleisen wrote:

 (I don't quite understand why there's no extra cost for the second access, 
 but I'll think about it and figure it out.)

If I understand things correctly, the short answer is fancy hardware.  The 
page is marked as read-only in the MMU, so a write incurs a page fault.  The 
page fault is trapped by the GC, which records the page in a table of 
written-to pages, marks it read-write in the MMU, and continues the program.  
Now, any write to that page is just like a write to anywhere in memory, but the 
GC knows to scan the page.  This type of thing is only possible with the 
support in hardware for these sort of read-only page marks.

Do I have it right?

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


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

2010-08-22 Thread Will M. Farr
Matthew  co,

On Aug 21, 2010, at 7:14 AM, Matthew Flatt wrote:

 I didn't think of this before, but probably you should add a check that
 the length expression proceduces a nonnegative exact integer:
 
 (syntax/loc stx
   (let ((len length-expr))
 (unless (exact-nonnegative-integer? len)
   (raise-type-error 'for/vector exact nonnegative integer len))
 (let ((v (make-vector len)))
   (for ((i (in-naturals))
 for-clause ...)
 (vector-set! v i body))
   v)))

Absolutely.  I'll take care of it.  

 More things that I didn't think of below...
 
 As for the issue 
 of a #:size that doesn't match the length of the iteration, I have been 
 thinking about adding a check inside the loop (for sizes that are too 
 small), 
 and a check outside the loop (for sizes that are too large).  If the size 
 does 
 not match the number of loop iterations would it be better to (error 
 'for/vector loop iterations (~a) and vector size (~a) do not match iter 
 size), raise one of the exn:fail:contract type exceptions, or manually 
 construct a blame object and (raise-blame-error ...), or ...?  If it were 
 simply my code, I would just call (error ...), but that's maybe not the best 
 in a general purpose library.
 
 A `exn:fail:contract' exception would be the right one. It's probably
 easiest to use `raise-mismatch-error'.
 
 It might also be ok to use
 
  (i (in-range 0 len))
 
 and say that the loop stops when either the sequence runs out or the
 number of iterations matches the length. I'd be happy with that but i
 can imagine that others might prefer an error.

I think I prefer this second approach; maybe there is sometimes a use for 
creating a vector that is longer than its initially set length.  For example, I 
could imagine having an extendable vector implementation where you want to 
leave some space at the end for future expansion.

 Either choice --- error or stopping --- interacts awkwardly with
 `for*/vector'. If you've going to raise an exception, the natural thing
 to do with `for/vector' would be to stop as soon as the sequence goes
 too far. But `for*/vector' with a length currently just uses
 `for*/vector' without the length; you could check afterward, but that
 would be different than the natural choice for `for/vector'.
 
 Along similar lines, every `for/vector' is a `for*/vector' in a way,
 because a `#:when' clause can introduce a nesting. The `for/vector'
 macro with an without a length behaves very differently than the one
 with a length when a `#:when' clause is used.
 
 Maybe `for/vector' with a length clause should be syntactically
 restricted to have no `#:when' clauses, and maybe there just shouldn't
 be a variant of `for*/vector' that supports `#:length'.

I'll make sure to throw a syntax error if I see a #:when in the for-clauses, 
and I think I should give up on the for*/vector #:length variant.  I was hoping 
that you would have some sort of neat trick to keep a running counter during 
the nested iteration

I'll send Sam the latest when I'm done with the modifications.

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


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

2010-08-20 Thread Will M. Farr
Matthew,

Thanks very much for the comments.  I'll get to work preparing an updated 
version using #:size soon, and send it to Sam for pushing.  As for the issue of 
a #:size that doesn't match the length of the iteration, I have been thinking 
about adding a check inside the loop (for sizes that are too small), and a 
check outside the loop (for sizes that are too large).  If the size does not 
match the number of loop iterations would it be better to (error 'for/vector 
loop iterations (~a) and vector size (~a) do not match iter size), raise one 
of the exn:fail:contract type exceptions, or manually construct a blame object 
and (raise-blame-error ...), or ...?  If it were simply my code, I would just 
call (error ...), but that's maybe not the best in a general purpose library.

Will

On Aug 19, 2010, at 5:57 PM, Matthew Flatt wrote:

 At Thu, 19 Aug 2010 18:45:43 -0400, sa...@racket-lang.org wrote:
 +(define-syntax for*/flvector
 +  (lambda (stx)
 +(syntax-case stx ()
 +  ((for*/flvector (for-clause ...) body)
 +   (syntax/loc stx
 + (list-flvector (for*/list (for-clause ...) body
 +  ((for*/flvector length-expr (for-clause ...) body)
 +   (syntax/loc stx
 + (for*/flvector (for-clause ...) body))
 
 
 I'm not comfortable with overloading based on the number of forms (the
 same with `for/vector' and `for*/vector'), since the `for' forms
 normally allow multiple expressions and internal definitions in the
 `for' body.
 
 It would be better to use a `#:size' keyword when supplying a specific
 size instead of relying on the number of forms within `for/vector'.
 
 +...@defform*[((for/vector (for-clause ...) body)
 +   (for/vector length-expr (for-clause ...) body))]
 
 Along the same lines: the `body' meta-variable must always be followed
 by `...+' in a syntax description. If you allow only one expression,
 it's `expr' insteda of `body'. (But I think the solution here is to
 change the syntax so that the docs will have `body ...+'.)
 
 +...@defform*[((for*/vector (for-clause ...) body)
 +   (for*/vector length-expr (for-clause ...) body))])]{
 +
 +Iterates like @scheme[for] or @scheme[for*], but the values of the
 +...@scheme[body] expression are placed in a vector whose length is the
 +number of iterations.  The optional @scheme[length-expr], if present,
 +is evaluated to determine the length of the vector in advance of the
 +iteration; if @scheme[length-expr] is provided, the computation is
 +more efficient.}
 
 The documentation doesn't answer the question that you asked before,
 which is what happens when the result of `length-expr' doesn't match
 the number of iterations. There appear to be no tests for that case,
 either.
 
 _
  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] PLaneT Library of Iterations/Comprehensions

2010-08-19 Thread Will M. Farr
Sam,

On Aug 18, 2010, at 1:39 PM, Sam Tobin-Hochstadt wrote:

 
 The for/... forms have the option of having a first expression that gives 
 the length of the resulting object (similar to srfi-42's vector-of-length-ec 
 form) to allow generating more efficient code:
 
 (for/vector ((x (in-range 3))) x) = (vector 0 1 2)
 (for/vector 3 ((x (in-range 3))) x) = (vector 0 1 2) ; but more efficiently
 
 What does this do if the specified length is wrong?

If the length is too short, then there will be a vector access error with the 
correct syntax location (though it may be a bit cryptic); if the length is too 
long, then the returned vector will have some slots at the end that are 
undefined (i.e. filled with whatever (make-vector NN) produces).  I think this 
kinda sucks, but I don't see any way to grab the length of a (for ...) form 
before it's run to check for consistency (in fact, I'm pretty sure you can't, 
since for loops can have #:while clauses that turn computation of the length 
into the halting problem).  In my opinion, offering the fast path (the slow 
path makes a list first, then calls (list-vector ...) on the result, so the 
fast path should be a big win both in memory and speed) is worth the risk, but 
I'd be interested to hear what you think.

I'm currently preparing the patch you requested; I'll let you know when it 
compiles and passes the tests on my system (which takes a while, since I have 
to build the whole racket environment).

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


[racket-dev] PLaneT Library of Iterations/Comprehensions

2010-08-18 Thread Will M. Farr
Hello all,

I've been thinking for a while about putting together a PLaneT library of some 
iteration/comprehension forms that I often use that are not found in the racket 
core.  Right now, I have a small it-comp.plt local PLaneT package that contains

for/vector
for/flvector
in-flvector

The for/... forms have the option of having a first expression that gives the 
length of the resulting object (similar to srfi-42's vector-of-length-ec form) 
to allow generating more efficient code:

(for/vector ((x (in-range 3))) x) = (vector 0 1 2)
(for/vector 3 ((x (in-range 3))) x) = (vector 0 1 2) ; but more efficiently

I'll be adding more forms from time to time, as I need them.  Eventually, I'll 
release this to PLaneT, but I thought I might ask the community two questions 
first:

1. Am I duplicating the functionality of some library?  (If so, I'll just 
contribute to that instead.)
2. Do you have any iteration favorites that I should include in the library?  
(Code welcome, but I'm also happy to implement suggestions myself.)

Alternately, if you guys want to add these to the core, I'd be happy to 
contribute code and tests

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