Re: [racket-dev] #:namespace
It sounds like one could work around this by taking whatever was passed to #:namespace and making the servlets move over to that namespace, at least. Robby On Mon, Oct 4, 2010 at 8:28 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I didn't realize the handin server used it when I removed it. It definitely doesn't need it. The #:namespace argument made it so the closure given as the request handler was called in a different namespace than it was evaluated in, causing a reinstantiation of the module and other weirdness. For example, #lang web-server/insta (require (only-in some-stateful-module.rkt set-a! unbox-a)) ; where a defaults to Hello World (set-a! Hello World, not) (define (start req) (unbox-a)) would evaluate to Hello World instead of Hello World, not, because some-stateful-module was not shared with the new namespace. This seems incredibly wrong, so I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The #:namespace argument is still useful for other servlets that come from serve/servlet, because they are loaded from disk and may need to share some modules with the main one, but should otherwise be isolated. Jay On Mon, Oct 4, 2010 at 5:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Probably there was some mail on this topic, but... Why did `dispatch/servlet' lose its `#:namespace' argument? The handin server was using that argument, so it no longer runs. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/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] #:namespace
That's not how the #:namespace argument ever worked. #:namespace takes a list of module names that are shared between the server and the servlets. In the case of the command-line tool, this is effectively a way to make some modules shared between different servlets, through the common party of the server. Since those servlet modules haven't been run, there's no confusing because they've always been evaluated in the same namespace. In contrast, web-server/insta, serve/servlet, and dispatch/servlet all take a closure rather than a module name as the servlet. This closure must have come from some namespace and it causes weird, unexpected behavior to not allow it to use the same namespace it came from when it runs. Basically, the addition of the #:namespace argument in the first place was just a knee-jerk reaction on my part making dispatch/servlet do everything that dispatch-servlets does without really thinking through whether it needed/made sense to have each feature. Jay On Mon, Oct 4, 2010 at 7:41 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It sounds like one could work around this by taking whatever was passed to #:namespace and making the servlets move over to that namespace, at least. Robby On Mon, Oct 4, 2010 at 8:28 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I didn't realize the handin server used it when I removed it. It definitely doesn't need it. The #:namespace argument made it so the closure given as the request handler was called in a different namespace than it was evaluated in, causing a reinstantiation of the module and other weirdness. For example, #lang web-server/insta (require (only-in some-stateful-module.rkt set-a! unbox-a)) ; where a defaults to Hello World (set-a! Hello World, not) (define (start req) (unbox-a)) would evaluate to Hello World instead of Hello World, not, because some-stateful-module was not shared with the new namespace. This seems incredibly wrong, so I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The #:namespace argument is still useful for other servlets that come from serve/servlet, because they are loaded from disk and may need to share some modules with the main one, but should otherwise be isolated. Jay On Mon, Oct 4, 2010 at 5:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Probably there was some mail on this topic, but... Why did `dispatch/servlet' lose its `#:namespace' argument? The handin server was using that argument, so it no longer runs. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/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://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] thoughts?
As briefly as I can: 0. I've seen one very big OCaml program. One thing that surprised me is when one day I wanted to follow how a specific piece of functionality was done. I grabbed the relevant file, then the file that it required and so on -- that specific piece of functionality was spread over so many files that it made it very difficult to track. By then I knew very well that the type system helps you when there are changes to the code -- you'd get it to tell you about most places that need to change too. What I realized (by surprise) is that this backfired at the big-project scale: the code was working fine, but it was much less organized than big projects I've seen in dynamically typed languages. 20 minutes ago, Matthias Felleisen wrote: Question 1: is it the macro-full-ness of our code that does it? Is it a lack of conventions? Is it the size of the functions/modules that we have? So IMO macros are unrelated. Question 2: if you could pick three guidelines, what would you suggest to everyone else who contributes to the code base? (This isn't about 'if' indenting, though I have my thoughts on that, too.) Thinking about module dependencies. Not because of any silly distribution issues -- but because they are (IMO) the way the system is explained. Modules work well on a small-scale with relatively short pieces of code. If you're not organized enough when you go up from that level, you get a big and incomprehensible pile of stuff. -- ((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] #:namespace
I didn't realize the handin server used it when I removed it. It definitely doesn't need it. The #:namespace argument made it so the closure given as the request handler was called in a different namespace than it was evaluated in, causing a reinstantiation of the module and other weirdness. For example, #lang web-server/insta (require (only-in some-stateful-module.rkt set-a! unbox-a)) ; where a defaults to Hello World (set-a! Hello World, not) (define (start req) (unbox-a)) would evaluate to Hello World instead of Hello World, not, because some-stateful-module was not shared with the new namespace. This seems incredibly wrong, so I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The #:namespace argument is still useful for other servlets that come from serve/servlet, because they are loaded from disk and may need to share some modules with the main one, but should otherwise be isolated. Jay On Mon, Oct 4, 2010 at 5:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Probably there was some mail on this topic, but... Why did `dispatch/servlet' lose its `#:namespace' argument? The handin server was using that argument, so it no longer runs. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #:namespace
On Mon, Oct 4, 2010 at 8:17 AM, Eli Barzilay e...@barzilay.org wrote: 40 minutes ago, Jay McCarthy wrote: [...] I removed the namespace argument and the request handler closure is simply evaluated in the namespace it came from. The relevant piece of code: #lang racket/base (require ... handin-server/private/logger ...) (provide run) (define (run) ... (run-servlet dispatcher #:namespace '(... handin-server/private/logger ...) #:log-file (get-conf 'web-log-file)) ...) does the above mean that the logger will be shared because there is no new instantiation of this code? Yup Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Bug? identifier `make-Int' not included in nested require spec.
Am I doing some thing wrong or is it a bug? #lang racket/load (module UNTYPED racket/base (struct Int (elem)) (provide (struct-out Int))) (module TYPED typed/racket (require/typed 'UNTYPED [struct Int ([elem : Integer])])) I get the following error only-in: identifier `make-Int' not included in nested require spec in: (quote UNTYPED) Hari _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Bug? identifier `make-Int' not included in nested require spec.
This is a known bug with the interaction of `struct' and `require/typed'. `define-struct' should work here. On Mon, Oct 4, 2010 at 7:11 PM, Hari Prashanth krh...@ccs.neu.edu wrote: Am I doing some thing wrong or is it a bug? #lang racket/load (module UNTYPED racket/base (struct Int (elem)) (provide (struct-out Int))) (module TYPED typed/racket (require/typed 'UNTYPED [struct Int ([elem : Integer])])) I get the following error only-in: identifier `make-Int' not included in nested require spec in: (quote UNTYPED) Hari _ 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] Bug? identifier `make-Int' not included in nested require spec.
Ok it does work... Thanks Hari - Original Message - From: Sam Tobin-Hochstadt sa...@ccs.neu.edu To: Hari Prashanth krh...@ccs.neu.edu Cc: dev dev@racket-lang.org Sent: Monday, October 4, 2010 7:16:26 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Bug? identifier `make-Int' not included in nested require spec. This is a known bug with the interaction of `struct' and `require/typed'. `define-struct' should work here. On Mon, Oct 4, 2010 at 7:11 PM, Hari Prashanth krh...@ccs.neu.edu wrote: Am I doing some thing wrong or is it a bug? #lang racket/load (module UNTYPED racket/base (struct Int (elem)) (provide (struct-out Int))) (module TYPED typed/racket (require/typed 'UNTYPED [struct Int ([elem : Integer])])) I get the following error only-in: identifier `make-Int' not included in nested require spec in: (quote UNTYPED) Hari _ 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