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

2011-07-27 Thread Michael Sperber

Eli Barzilay  writes:

> 11 hours ago, Michael Sperber wrote:
>> 
>> I still need Stephen Chang's commit to be merged over:
>> 
>> commit 8956364387fa25ffeb51e50fc1a83c20fd88af32
>> Author: Stephen Chang 
>> 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.

Thanks - works now, and I'm done with my tests.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_
  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  wrote:
> On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund  wrote:
>> On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay  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


Re: [racket-dev] A basic package system

2011-07-27 Thread Jay McCarthy
On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund  wrote:
> On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay  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 
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

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

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:20 PM, Tony Garnock-Jones  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


Re: [racket-dev] Racket on Rockets

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 4:17 PM, Sam Tobin-Hochstadt  wrote:
> On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones  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 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 Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones  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] 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  wrote:
> * Carl Eastlund 
>  - 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] A basic package system

2011-07-27 Thread Carl Eastlund
On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay  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] 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] Racket on Rockets

2011-07-27 Thread Sam Tobin-Hochstadt
On Wed, Jul 27, 2011 at 12:21 PM, Tony Garnock-Jones  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 is a Ruby Raw Packet Library

2011-07-27 Thread Eli Barzilay
8 minutes ago, Tony Garnock-Jones wrote:
> Hi all,
> 
> You may be interested to learn that Racket,
> http://spoofed.org/files/racket/doc/, is a Ruby Raw Packet Library
> for working with various network layers,

Yes, the ohloh project page for "racket" was for that thing.


> that has been incorporated into Metasploit
> http://www.metasploit.com/, a penetration testing toolkit.

And that explains why it was dead for a number of years.  ("It" = it's
page on google code.)

-- 
  ((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 Tony Garnock-Jones
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.

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


[racket-dev] Racket is a Ruby Raw Packet Library

2011-07-27 Thread Tony Garnock-Jones
Hi all,

You may be interested to learn that Racket,
http://spoofed.org/files/racket/doc/, is a Ruby Raw Packet Library for
working with various network layers, that has been incorporated into
Metasploit http://www.metasploit.com/, a penetration testing toolkit.

I know I was!

Cheers,
  Tony
_
  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 
> 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] Pre-Release Checklist for v5.1.2

2011-07-27 Thread Carl Eastlund
On Tue, Jul 19, 2011 at 5:16 PM, Ryan Culpepper  wrote:
>
> * Carl Eastlund 
>  - 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

2011-07-27 Thread Eli Barzilay
On Sunday, Stephen Bloch wrote:
> 
> On Jul 19, 2011, at 5:16 PM, Ryan Culpepper wrote:
> 
> > * Stephen Bloch 
> >  - 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] 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


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


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

Re: [racket-dev] A basic package system

2011-07-27 Thread Jay McCarthy
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
 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  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 
>> 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
>>
>



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

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

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

Re: [racket-dev] Pre-Release Checklist for v5.1.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
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  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 
> 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

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

2011-07-27 Thread Michael Sperber

Ryan Culpepper  writes:

> * Mike Sperber 
>   - Stepper Tests

I still need Stephen Chang's commit to be merged over:

commit 8956364387fa25ffeb51e50fc1a83c20fd88af32
Author: Stephen Chang 
Date:   Sun Jul 24 12:18:09 2011 -0400

change recon-val in stepper to use render-to-sexpr for non-lazy lists

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev