The style guide has this to say about blank lines:
"5.8 Spaces
Don’t pollute your code with spaces at the end of lines and extraneous blank
lines."
This comes out pretty strongly against "extraneous" blank lines. In writing the
code below, though, it seems to me that the blank lines aid readab
I just pushed support for this. The Web server will read chunked
requests properly and will output them (with 1K chunks) for streaming
responses---which allows streaming responses to keep HTTP/1.1
keep-alive connections open.
Jay
On Fri, Mar 9, 2012 at 3:45 PM, John Clements wrote:
>
> On Mar 9,
`evcase' is currently provided by `mzlib/etc'.
Should we provide it in `racket' as well?
Vincent
At Mon, 12 Mar 2012 16:53:14 -0400,
Matthias Felleisen wrote:
>
>
> see evcase
>
>
> On Mar 12, 2012, at 4:45 PM, Rüdiger Asche wrote:
>
> > Hi there,
> >
> > why is the Zero alias replaced
I agree with Robby.
Jay
On Mon, Mar 12, 2012 at 1:18 PM, Robby Findler
wrote:
> I thought Matthew was pointing out how we can distribute some source
> that works if you set a parameter properly and that same source will
> contain no test-based dependencies.
>
> Boy, this conversation sure makes
I thought Matthew was pointing out how we can distribute some source
that works if you set a parameter properly and that same source will
contain no test-based dependencies.
Boy, this conversation sure makes me wish for the ability to just
gather everyone up around a whiteboard or something :(
Ro
I think Jay is expressing an Eli-concern: we need to distribute
the full source to determine whether something can be thrown away.
On Mar 12, 2012, at 3:13 PM, Robby Findler wrote:
> Oh, I get it now. Thanks.
>
> This also seems like something that you'd want to put control over at
> the pac
Oh, I get it now. Thanks.
This also seems like something that you'd want to put control over at
the package level, I guess. That is, a package can depend on another
package, but without that second package's test modules or something.
Robby
On Mon, Mar 12, 2012 at 2:05 PM, Matthew Flatt wrote:
Ya, even if someone does their best by moving dependencies into the
tightest module*, there is a compilation problem:
"m.rk"
#lang racket
(module* test #f
(require tests/eli-tester))
simply does not compile if tests/eli-tester is not there. If you did
compile it but didn't instantiate the test m
Yes: In other words, there could be a parameter that causes the macro
expander to drop `test' submodules before it even attempts to expand
them --- roughly like not using `-g' with `gcc'.
Meanwhile, the after-the-fact pruning tool could be called `raco
strip'.
At Mon, 12 Mar 2012 15:02:58 -0400,
Or you make the pruning step a part of the compiler.
On Mar 12, 2012, at 3:01 PM, Robby Findler wrote:
> Yes, I think the point that Jay's making is that the thing you'd
> distribute wouldn't be rkt code, but some low-level thing. Well,
> either that or you distribute .rkt code that doesn't ac
Yes, I think the point that Jay's making is that the thing you'd
distribute wouldn't be rkt code, but some low-level thing. Well,
either that or you distribute .rkt code that doesn't actually run.
Robby
On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen
wrote:
>
> I know that. But we could cons
I know that. But we could consider the pruning step as part of compilation.
On Mar 12, 2012, at 2:57 PM, Robby Findler wrote:
> He's saying that there is no easy way to, without expanding the code
> (and perhaps without going one step further beyond a fully expanded
> program, but nevermind th
He's saying that there is no easy way to, without expanding the code
(and perhaps without going one step further beyond a fully expanded
program, but nevermind that detail), split apart the submodules that
come from a single module. You just cannot tell, without expanding
everything, which of the i
Why does it not compile? Do you mean it doesn't compile to the same byte codes?
On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote:
> Sorry Matthias, I don't think I understand your question.
>
> At the bytecode level, it would be "easy", so we could change the
> distribution scripts to do tha
Sorry Matthias, I don't think I understand your question.
At the bytecode level, it would be "easy", so we could change the
distribution scripts to do that.
At the source level, it's not really possible because of macros that
generate code in a submodule.
My personal taste is that it is bad to s
On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote:
> The current demodularizer would do that. Presumably we could make a
> tool that operated on a single module's zo and removed such
> submodules. The main problem would be that the source is
> un-compilable.
Meaning? Removing docs and tests shou
The current demodularizer would do that. Presumably we could make a
tool that operated on a single module's zo and removed such
submodules. The main problem would be that the source is
un-compilable.
Jay
On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen
wrote:
>
> Yes, dependencies abound if w
Yes, dependencies abound if we include tests and doc in the same module. At the
same time it is good practice to have things together.
Can't this problem be solved with module-flattening tools? From what I can
tell, these test and doc modules could be dropped leaving the running residual,
whi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-03-12 19:00, Matthew Flatt wrote:
> I've fixed the Gtk and Cocoa bindings to never invoke a
> `tab-panel%' callback when the tab changes indirectly via the
> `set', `append', or `delete' method.
Thanks!
> It's possible that you were hoping to h
19 matches
Mail list logo
