Re: [racket-dev] A basic package system

2011-07-27 Thread Robby Findler
Bullet point 2 seems like it may overlap (in a practical, what do I
use today sort of a way) with Matthew's modulelet construct. Both
group modules together, both provide independently loadable things.

Do we really want/need both of these?

Robby

On Tue, Jul 26, 2011 at 5:49 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 Eli and I had a very useful conversation last night and we realized
 that a lot of the ideal package system we are imagining is within our
 reach very quickly. Today I made a demonstration of our ideas:

 https://github.com/jeapostrophe/exp/tree/master/pkgs

 There's a README there. Once you read it,

 Run use/program.rkt

 Then edit use/pkg-in.rkt and change the safe to unsafe

 You'll see that it changes the meaning of racket/listy module
 reference in use/program.rkt

 I haven't implemented the module algebra, but it should be clear from
 looking at the macro implementations that the existing identifier
 algebra in require/provide will work transparently.

 Jay

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

 The glory of God is Intelligence - DC 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

Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call

2011-07-27 Thread John Clements

On Jul 27, 2011, at 1:29 AM, Ryan Culpepper wrote:

 Checklist items for the v5.1.2 release
  (using the v5.1.1.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

This installer page still shows Saturday 23rd as the most recent build. I 
believe I'm blocked on this.

John



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] A basic package system

2011-07-27 Thread Robby Findler
They have more similarities than your message suggests I believe. And it is
probably worth exploring that. As far as I can see a facet/modulet has less
stuff than a package and possibly a different story vis a vis files in the
filesystem.

Robby

On Wednesday, July 27, 2011, Jay McCarthy jay.mccar...@gmail.com wrote:
 I don't see them as overlapping, but you may understand them different
 than I do.

 The way I see modules/facets is that 'racket/list.rkt' will have a
 'default' facet and a 'testing' facet and a 'documentation' facet, so
 that each use can be syntactically close but separately loadable.

 The way I see packages is that they allow indirection of module paths,
 so that inside 'a.rkt', 'racket/list' can refer to something other
 than the usual thing because of what package it is inside. Packages
 also allow module privacy in a way we don't provide now, because some
 modules may not be provided from the package, even though they are
 inside it.

 So... do you think those two understandings overlap? Or do you
 understand them differently?

 Jay

 On Wed, Jul 27, 2011 at 7:52 AM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 Bullet point 2 seems like it may overlap (in a practical, what do I
 use today sort of a way) with Matthew's modulelet construct. Both
 group modules together, both provide independently loadable things.

 Do we really want/need both of these?

 Robby

 On Tue, Jul 26, 2011 at 5:49 PM, Jay McCarthy jay.mccar...@gmail.com
wrote:
 Eli and I had a very useful conversation last night and we realized
 that a lot of the ideal package system we are imagining is within our
 reach very quickly. Today I made a demonstration of our ideas:

 https://github.com/jeapostrophe/exp/tree/master/pkgs

 There's a README there. Once you read it,

 Run use/program.rkt

 Then edit use/pkg-in.rkt and change the safe to unsafe

 You'll see that it changes the meaning of racket/listy module
 reference in use/program.rkt

 I haven't implemented the module algebra, but it should be clear from
 looking at the macro implementations that the existing identifier
 algebra in require/provide will work transparently.

 Jay

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

 The glory of God is Intelligence - DC 93
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev





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

 The glory of God is Intelligence - DC 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

Re: [racket-dev] A basic package system

2011-07-27 Thread Eli Barzilay
10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

They're really unrelated -- the new thing with
facets/modulets/whatever name they get is a kind of a separately
loadable sub-module.  What we were talking about is basically making
the `foo' in (require foo) be an identifier that you could define to
actually point to some random file.

-- 
  ((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


[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

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

2011-07-27 Thread Eli Barzilay
50 minutes ago, Will M. Farr wrote:
 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).

To see a difference you should make sure that you're timing some code
that runs at the C level -- since racket code gets jitted the same
anyway.  (Maybe compilation could be faster since there's a lot of
syntax work and that's mostly at the C side.)

-- 
  ((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.2

2011-07-27 Thread Eli Barzilay
On Sunday, Stephen Bloch wrote:
 
 On Jul 19, 2011, at 5:16 PM, Ryan Culpepper wrote:
 
  * Stephen Bloch sbl...@adelphi.edu
   - Picturing Programs Tests
 
 Looks good.  I've just pushed three commits:
 ab01d563ca6a0313e1cb5c07372a2bd2929ae4bc should definitely go into the 
 release (it corrects some error messages to match what they are now)
 9a24e66df0e2f7c3a516ce3d3542aab099afaaa3 should probably go into the release 
 (it fixes a bug in one of my test cases, so it passes now)
 764f356fdcda14bf5a0af91474bd8ad0640564b5 could go into the release (it adds 
 some test cases, which pass in both the release candidate and the latest git 
 update)

I picked the first two, but not the third.

-- 
  ((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.2

2011-07-27 Thread Carl Eastlund
On Tue, Jul 19, 2011 at 5:16 PM, Ryan Culpepper r...@cs.utah.edu wrote:

 * Carl Eastlund c...@ccs.neu.edu
  - Dracula Tests (confirm that Dracula runs from PLaneT)

Done.

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


Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call

2011-07-27 Thread Eli Barzilay
11 hours ago, Michael Sperber wrote:
 
 I still need Stephen Chang's commit to be merged over:
 
 commit 8956364387fa25ffeb51e50fc1a83c20fd88af32
 Author: Stephen Chang stchang...@gmail.com
 Date:   Sun Jul 24 12:18:09 2011 -0400
 
 change recon-val in stepper to use render-to-sexpr for non-lazy lists

There was a conflict with that change -- I've finally resolved it and
started a new build.


Four hours ago, John Clements wrote:
 
 This installer page still shows Saturday 23rd as the most recent
 build. I believe I'm blocked on this.

Should take about three hours for the build to finish.

-- 
  ((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] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 12:21 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-26 1:20 PM, Jay McCarthy wrote:
 I don't have a lot of expertise on the ORM side, but I think Snooze
 would probably be awesome and my MongoDB-backed structs may be helpful
 too.

 Is there a way of generically traversing all structure in a completely
 privileged way in Racket, without programming at the VM level? For
 example, one might wish to serialize some arbitrary data structure or
 write an object inspector or interactive debugger.

If you have a sufficiently powerful inspector, you can traverse any
structure.  In principle, you can even traverse closures this way, but
no inspector with the needed power exists.  See `struct-vector'.

 I'm guessing no is the answer, based on the existence of separate
 serializable and non-serializable structure definitions. I guess
 that if I were to try it out I'd be defeated by opaque closures and by
 the inspector mechanism. Does that sound right?

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




-- 
sam th
sa...@ccs.neu.edu

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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Tony Garnock-Jones
On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote:
 If you have a sufficiently powerful inspector, you can traverse any
 structure.  In principle, you can even traverse closures this way, but
 no inspector with the needed power exists.  See `struct-vector'.

That sounds fantastic! Especially the traversal of closures. What kinds
of dark alchemy would I have to engage in to get hold of the necessary
inspector?

Would such an inspector be able to represent the structure of chaperoned
and impersonated values accurately?

Finally, what about the other direction? I notice there's no obvious
`vector-struct`. Is there a general way of moving from the description
of a structure to the structure itself?

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


Re: [racket-dev] A basic package system

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote:
 10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

 They're really unrelated -- the new thing with
 facets/modulets/whatever name they get is a kind of a separately
 loadable sub-module.  What we were talking about is basically making
 the `foo' in (require foo) be an identifier that you could define to
 actually point to some random file.

Would a binding for foo affect uses like foo/bar?  And would this mean
going to a semantics for require specs where unbound identifiers have
one meaning, and bound identifiers have another?  That leads to issues
with silent failures, where you try to refer to a binding but a typo
leads to the wrong require instead of a syntax error.  Also, right now
I can do (define racket Racket) and then (require racket) and it
works fine.  If require starts looking at bindings, suddenly the
collection namespace becomes part of the normal Racket namespace.

--Carl

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


Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 1:29 AM, Ryan Culpepper r...@cs.utah.edu wrote:
 * Carl Eastlund c...@ccs.neu.edu
  - Dracula Tests (confirm that Dracula runs from PLaneT)

Done, in case my [late] response on the prior thread was missed.

--Carl

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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote:
 If you have a sufficiently powerful inspector, you can traverse any
 structure.  In principle, you can even traverse closures this way, but
 no inspector with the needed power exists.  See `struct-vector'.

 That sounds fantastic! Especially the traversal of closures. What kinds
 of dark alchemy would I have to engage in to get hold of the necessary
 inspector?

No such alchemy exists, it's just intended as part of the conceptual framework.

 Would such an inspector be able to represent the structure of chaperoned
 and impersonated values accurately?

No, `struct-vector' uses the chaperoned accessors, but doesn't
represent their structure.

 Finally, what about the other direction? I notice there's no obvious
 `vector-struct`. Is there a general way of moving from the description
 of a structure to the structure itself?

No.
-- 
sam th
sa...@ccs.neu.edu

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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Tony Garnock-Jones
On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote:
 No such alchemy exists, it's just intended as part of the conceptual 
 framework.

Would it be fair to say that were such a thing to come into existence,
the VM would need to be changed as part of that work?

 No, `struct-vector' uses the chaperoned accessors, but doesn't
 represent their structure.

OK. And there's nothing else that can expose that structure?

 No.

OK.

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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 4:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote:
 If you have a sufficiently powerful inspector, you can traverse any
 structure.  In principle, you can even traverse closures this way, but
 no inspector with the needed power exists.  See `struct-vector'.

 That sounds fantastic! Especially the traversal of closures. What kinds
 of dark alchemy would I have to engage in to get hold of the necessary
 inspector?

 No such alchemy exists, it's just intended as part of the conceptual 
 framework.

 Would such an inspector be able to represent the structure of chaperoned
 and impersonated values accurately?

 No, `struct-vector' uses the chaperoned accessors, but doesn't
 represent their structure.

 Finally, what about the other direction? I notice there's no obvious
 `vector-struct`. Is there a general way of moving from the description
 of a structure to the structure itself?

 No.

There is struct-type-make-constructor; if you have the inspector for
the structure, you can get at its structure type as well.

--Carl

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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:20 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote:
 On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote:
 No such alchemy exists, it's just intended as part of the conceptual 
 framework.

 Would it be fair to say that were such a thing to come into existence,
 the VM would need to be changed as part of that work?

Yes.

 No, `struct-vector' uses the chaperoned accessors, but doesn't
 represent their structure.

 OK. And there's nothing else that can expose that structure?

Right.

-- 
sam th
sa...@ccs.neu.edu
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


[racket-dev] Recommending nightly builds during releases

2011-07-27 Thread Eli Barzilay
An hour and a half ago, Vincent St-Amour wrote:
 Have you tried the nightly builds?
 
 http://pre.racket-lang.org/installers/

Just a quick note: when there's a release going on, it's a perfect
opportunity to recommend using that build rather than going for the
nightly that has moved on since the release started...

-- 
  ((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] A basic package system

2011-07-27 Thread Jay McCarthy
On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund c...@ccs.neu.edu wrote:
 On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote:
 10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

 They're really unrelated -- the new thing with
 facets/modulets/whatever name they get is a kind of a separately
 loadable sub-module.  What we were talking about is basically making
 the `foo' in (require foo) be an identifier that you could define to
 actually point to some random file.

 Would a binding for foo affect uses like foo/bar?  And would this mean
 going to a semantics for require specs where unbound identifiers have
 one meaning, and bound identifiers have another?  That leads to issues
 with silent failures, where you try to refer to a binding but a typo
 leads to the wrong require instead of a syntax error.  Also, right now
 I can do (define racket Racket) and then (require racket) and it
 works fine.  If require starts looking at bindings, suddenly the
 collection namespace becomes part of the normal Racket namespace.

I just want id-require-transformers. Right now we have
require-transformers but there's no reason we couldn't/shouldn't have
id macros too.

(define racket Racket) is not problem because it's a phase-0,
non-require-transformer binding.

Using these macros this way is just a nice way to implement the
package system. It's not really a new feature (as my example shows...
we already have it.)

Jay



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

The glory of God is Intelligence - DC 93

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

Re: [racket-dev] A basic package system

2011-07-27 Thread Carl Eastlund
On Thu, Jul 28, 2011 at 12:35 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
 On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund c...@ccs.neu.edu wrote:
 On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote:
 10 minutes ago, Robby Findler wrote:
 They have more similarities than your message suggests I believe.
 And it is probably worth exploring that.  As far as I can see a
 facet/modulet has less stuff than a package and possibly a different
 story vis a vis files in the filesystem.

 They're really unrelated -- the new thing with
 facets/modulets/whatever name they get is a kind of a separately
 loadable sub-module.  What we were talking about is basically making
 the `foo' in (require foo) be an identifier that you could define to
 actually point to some random file.

 Would a binding for foo affect uses like foo/bar?  And would this mean
 going to a semantics for require specs where unbound identifiers have
 one meaning, and bound identifiers have another?  That leads to issues
 with silent failures, where you try to refer to a binding but a typo
 leads to the wrong require instead of a syntax error.  Also, right now
 I can do (define racket Racket) and then (require racket) and it
 works fine.  If require starts looking at bindings, suddenly the
 collection namespace becomes part of the normal Racket namespace.

 I just want id-require-transformers. Right now we have
 require-transformers but there's no reason we couldn't/shouldn't have
 id macros too.

I would say that the silent failure mode is a reason not to.  The only
other place I can think of where we allow both bound and unbound
identifiers, and interpret them differently, is syntax templates.  I
don't think of a require spec as a template -- mostly data with a few,
special, overriding references -- I generally expect each name to have
a single unambiguous meaning.

 (define racket Racket) is not problem because it's a phase-0,
 non-require-transformer binding.

Require transformers are at phase 0, too.  Or are you suggesting that
we interpret bound names if they are require transformers, but not if
they're something else?  Once again, only templates behave that way.
It would be very odd to me to treat require specs as mostly data, with
a few special, overriding bindings, rather than as a type of
expression where each name has a single meaning.

 Using these macros this way is just a nice way to implement the
 package system. It's not really a new feature (as my example shows...
 we already have it.)

We already have require macros for application positions because all
application positions in require specs are interpreted as bindings.
All identifier-only positions are interpreted as data and used as
collection names.  In general, Racket macros avoid mixing data and
expressions (anything that interprets bindings), because it leads to
very confusing behavior.  This is similar to why cond has a binding
for else rather than using its symbolic name, and even more directly
similar to why match does not have id transformers either.

--Carl

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