http://blog.gmane.org/gmane.comp.lang.racket.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.racket.devel/8891 <pre>Hi. I've successfully started Racket 5.3.4.7 with Geiser server through JNI + SDL2 on Android (and this combination mostly works with small hacks), but got some issues due to racket's implementation. This is last one I'm trying to understand. What should be here instead of the "address" expression? 2349 } else { 2350 scheme_raise_exn(MZEXN_FAIL_NETWORK, 2351 "tcp-listen: host not found\n" 2352 " address: %s\n" 2353 " system error: %N", 2354 address, 1, err); 2355 return NULL; 2356 } 2357 } https://github.com/plt/racket/blob/master/src/racket/src/network.c#L2354 It looks like there should be (but i'm not sure) address ? address : "#f" // as i see at another place, because it's possible to have NULL according to the: https://github.com/plt/racket/blob/master/src/racket/src/network.c#L2147 Without such change I got segfault because sch_vsprintf tried to process NULL pointer, when i forgot to grant internet permissions for my application and tried to call start-geiser function (getaddrinfo returns fail in this situation and this `else` block is called). </pre> Alex Moiseenko 2013-05-21T01:57:25 http://comments.gmane.org/gmane.comp.lang.racket.devel/8884 <pre>I used to think that we'd take advantage of the package manager by gradually pulling parts out of the Racket git repo and making them packages. Now, I think we should just shift directly to a small-ish Racket core, making everything else a package immediately. "Core" means enough to run `raco pkg'. A key point to remember is that "package" does not mean "omitted from the distribution". Instead, we'll construct a distribution by combining the core with a selected set of packages. Initially the selected set of packages will cover everything in the current distribution. Jay and I have been lining up the pieces for this change (it's difficult to make a meaningful proposal without trying a lot of the work, first), and I provide a sketch of the overall plan below. This plan has two prominent implications: * The current git repo's directory structure will change. Anyone who currently works with the Racket repo will need to adapt to the new directory structure (and probably git &lt;submodules in the future). All of the code currently in the Racket git repo will stay there (for now), but using it will involve at least one new step: linking packages within the repo into the core build --- probably by running some setup script. * The main Racket distributions at http://racket-lang.org/download/ will omit sources, including ".rkt" files, ".scrbl" files, and tests. Sources will remain readily available through the git repo and through the package manager, but getting users to try a source-code change will be less convenient than now. See "Binary Builds" below. Repository Reorganization ------------------------- To convert the current monolith into a core plus packages, we propose to reorganize the Racket git repository by 1. pushing the current content into a "core" subdirectory, and 2. lifting pieces back out of "core" and into new subdirectories, one for each package. The resulting repo will have top-level directories with names like "core", "scribble", "gui", "slideshow", "drracket", and so on. Each directory other than "core" corresponds to a package. We'll have to try this out to discover how finely we can break up the existing tree into packages. At worst, the "mr", "dr", and "plt" layers of "dist-specs.rkt" should work, but I think we'll be able to do better than that. Eventually, when the dust settles, I think we'll want to convert every directory to its own git repo, and then we can incorporate the individual repos as git submodules. Rearranging the repo will obviously break the current build system. Jay and I are creating a new build system, so the current nightly build and distribution processes do not need to adapt (although we're using many existing pieces). The new build system might be ready by the end of the week (and the repo reorganization will wait until the build system is ready). Binary Builds ------------- The proposed switch to binary distributions --- instead of always including source alongside generated bytecode and documentation --- is aimed at reducing dependencies between packages. Support for binary packages is also aimed at supporting faster installs. In terms of dependencies, documentation for a library usually has more dependencies than the library itself. We don't want to limit the *documentation* for package X to avoid using or referring to package Y libraries in order to avoid a run-time dependency of X on Y. For that matter, we don't want to avoid documenting X in order to avoid a dependency on Scribble. A library's tests similarly could have dependencies that are not needed for the library itself. We've adjusted `raco setup' and `raco pkg' to work with collections and packages that are in binary form. "Binary" is not a specific attribute of a package; it's just a package that happens to have ".zo" files without corresponding ".rkt" files, documentation without ".scrbl" sources, and so on. The intent is not for programmers to create binary packages, but to enable an automatic conversion of a source package to a binary package. We can then set up different catalog severs to serve source and binary versions of packages. Finally, we'll be able to quickly create distributions --- either the standard one or others --- by combining a core build with a set of binary packages. Some drawbacks to omitting source are immediately apparent: - Users will be less able to make source changes on their systems to help us debug. Having the binary form of a package installed does not preclude "upgrading" to a source package. So, we could ask a user to use the package manager to install the source form of, say, the "drracket" package, and then try out a change. In that way, users can still help, but it will be less convenient. - Users will be less able to read installed code as examples. Our source code is now easily available via the web interfaces at http://git.racket-lang.org/ and GitHub, so users can always look there, instead. It would be possible, of course, to support distributions and packages that include both source and compiled forms (like our current distribution), but that arrangement requires even more work. We'd like to try out the simpler source vs. binary options, first. More Detail ----------- Here's our plan for a new repo and build process: * There's a Racket core, which will look a lot like this: https://github.com/mflatt/min-racket The core is intended to provide everything that is needed to run `raco pkg', which is the way to install anyything else. The repo above is not yet minimal in that sense, but I think it's close. After `make install', a simple tool (probably a new mode for `setup/unixstyle-install') can copy a built tree to distribution form. The copy strips sources for which bytecode files exist. The core has no documentation or even documentation sources, and dropping sources for a distribution includes dropping "tests" subdirectories. In the distribution copy, the default package catalog is switched to a binary package server, instead of a source package server. (Developers can continue to work with an in-place build in package-source mode, as usual.) * For each package to be included in the distribution, a build machine installs and strips each package to binary form, where "binary" form means that sources are removed while bytecode is kept, etc. A package's `deps' in "info.rkt" should describe all run-time dependencies. Additional build-time dependencies must be specified by `build-deps', so the complete set of dependencies when building a package from source is `deps' plus `source-deps'. (In the long run, we can add machinery to check these dependency declarations.) Stripping to binary form adjusts "info.rkt": the `build-deps' entry is dropped, and the `scribblings' entry is rewritten to `rendered-scribblings' to install pre-built documentation, and so on. Fields in "info.rkt" can fine-tune the stipping process for a package or collection. A package must not depend on anything in another package that is stripped away for binary form. Rendered documentation for a binary package redirects to a server for any link that goes outside the document. Every package's documentation therefore makes sense by itself, so it is easy to include rendered documentation in a package; meanwhile, the documentation server will be populated with built packages. When a package is installed with its documentation, links are redirected to local copies for any documentation that is locally installed. * On the N platforms for which we want to provide distributions, we build the core, install binary packages (i.e., the ones to be included in the distribution), and then convert to an installer. There should be no need for "dist-specs". The distinction between source and binary is mostly implicit and otherwise specified per-package as part of package stripping. A binary installer is packed directly from a binary installation. The build and installer-creation scripts will themselves be packages, so anyone can run them. Also, we hope to eventually offer a service takes takes a set of packages and produces a set of installers that are preconfigured with the given packages. As a minor point, platform-specific packages must be created in binary form in the first place (i.e., there is no source form), since the creation of binary packages from source form will happen only on one platform. For example, the current `make'-time download of GUI libraries on Windows and Mac OS X will turn into platform-specific package dependencies, and the packages are straightforwardly created as binary in the first place. * There's just one core source distribution --- not different ones for Unix, Windows, and Mac --- that is derived directly from the git repo. We envision no distribution that includes both source and compiled bytecode/documentation, which is the form that our current distributions take. We could conceivably support such distributions one day, either by building from source on N machines or having a third kind of package that includes both source and compiled parts, but this is a good place to simplify at first. Some pieces yet to be implemented: - Stripping a core build to prepare for binary package installs (looks easy). - Submodule stripping when converting a package to binary form (looks easy). - Scripts and servers to drive (1) the core and package build once, and (2) the core builds, package installs, and installer bundles on various platforms. Some complexities of the current build/bundle process that go away: - No "dist-specs"; no mz/mr/dr/plt spec. - No "info-domain" fixup when packaging a distribution. - No extracting of binaries from one platform an splicing them into a generic build shell (or construction of the generic build shell). - No "src" distribution variants. Some complexities that stick around: - DESTDIR mangling and `setup/unixstyle-install' shuffling. - Some process for taking a pile of installers and putting them on a web page. - DrDr builds and tests from source, including ring-0 packages. _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Matthew Flatt 2013-05-20T20:42:15 http://comments.gmane.org/gmane.comp.lang.racket.devel/8878 <pre>Hi all, I'm confused about an aspect of set! and rename transformers. I'll explain with this example: #lang racket ;; a macro that uses `syntax-local-value/immediate` (define-syntax (lookup stx) (syntax-case stx () [(_ id) (let-values ([(f _) (syntax-local-value/immediate #'id)]) (displayln (rename-transformer? f)) (displayln (set!-transformer? f)) #'0)])) ;; f is a set!-transformer (let-syntax ([f (make-set!-transformer values)]) (lookup f)) ;; sanity check (rename-transformer? (make-set!-transformer values)) In this example, `f` is bound to a set!-transformer. The macro `lookup` will look up the value bound to `f` at compile-time, and I expected that the result would be the set! transformer. However, it seems like the set! transformer is somehow being turned into a rename transformer (note the two print statements produce #t and #f respectively). The last line suggests that set! transformers are not actually a "subtype" of rename transformers though. Am I confused about set! transformers or is there a bug here? Cheers, Asumu _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Asumu Takikawa 2013-05-17T23:30:35 http://comments.gmane.org/gmane.comp.lang.racket.devel/8875 <pre>This is related to http://www.mail-archive.com/users-GvBox1K3Ixw1Q5oZIJT9Xw&lt; at &gt;public.gmane.org/msg17597.html. Forgive me for posting it again, I wanted to make sure it didn't disappear into a black hole. Launching a racket thread that calls make-keyword-procedure may produce a seg fault. For instance, (let loop () (thread (make-keyword-procedure (lambda (x y) '()))) (loop)) Reliably causes a seg fault. Repeatedly calling (thread (make-keyword-procedure (lambda (x y) '()))) will eventually (but not consistently) produce a seg fault. Functions defined with make-keyword-procedure, such as const and thunk* suffer the same fate (plain ol' thunk is fine). A coredump of the racket repl from this segfault shows a stack overflow in scheme_uncopy_stack, with the Scheme_Jumpup_Buf zeroed out. Please see our gdp session at http://pastebin.com/aBx2FTcK (This is from racket compiled without optimization) or cause your own seg fault with the above code. Perhaps we're being incredibly daft to write code where we'd need to const or thunk* something inside a thread, or perhaps this is a bug in racket. We might just be incredibly daft by calling a const inside a thread, or this is a bug in racket, or something else is up. In any case, we've exhausted our abilities to investigate it further and would appreciate advice from those more familiar with the code. Regards, -- Matthew Eric Bassett | http://mebassett.info _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Matthew Eric Bassett 2013-05-15T12:40:04 http://comments.gmane.org/gmane.comp.lang.racket.devel/8873 <pre>JFYI, I've made the svn server be mostly read-only. </pre> Eli Barzilay 2013-05-13T01:49:33 http://comments.gmane.org/gmane.comp.lang.racket.devel/8867 <pre>My branch with immediately represented characters is available at: https://github.com/97jaz/racket/tree/immediate-chars I'm interested to hear any opinions from the members of this list on the implementation. For my own part, I'm ambivalent on the matter of actually incorporating this work into the official tree. Benchmarks that are heavy on character manipulation -- and there are few enough of these </pre> Jon Zeppieri 2013-05-12T17:38:23 http://comments.gmane.org/gmane.comp.lang.racket.devel/8853 <pre>No matter what the input color's alpha is, set-pixel uses 100% opacity. Similarly, get-pixel ignores the alpha in the image. I think we should change this with the patch below, but I wonder if there is some deeper reason it works this way and it shouldn't change. Matthew? Jay diff --git a/collects/racket/draw/private/bitmap-dc.rkt b/collects/racket/draw/private/bitmap-dc.rkt index 08bb51c..5d9e241 100644 --- a/collects/racket/draw/private/bitmap-dc.rkt +++ b/collects/racket/draw/private/bitmap-dc.rkt &lt; at &gt;&lt; at &gt; -119,14 +119,18 &lt; at &gt;&lt; at &gt; (internal-get-bitmap)) (define/public (set-pixel x y c) - (let ([s (bytes 255 (color-red c) (color-green c) (color-blue c))]) + (let ([s (bytes (inexact-&gt;exact (round (* 255 (color-alpha c)))) + (color-red c) + (color-green c) + (color-blue c))]) (set-argb-pixels x y 1 1 s))) (define/public (get-pixel x y c) (let-values ([(w h) (get-size)]) (let ([b (make-bytes 4)]) (get-argb-pixels x y 1 1 b) - (send c set (bytes-ref b 1) (bytes-ref b 2) (bytes-ref b 3)) + (send c set (bytes-ref b 1) (bytes-ref b 2) (bytes-ref b 3) + (/ (bytes-ref b 0) 255)) (and (&lt;= 0 x w) (&lt;= 0 y h))))) (define/public (set-argb-pixels x y w h bstr -- Jay McCarthy &lt;jay-LBaQsqPCPro3uPMLIKxrzw&lt; at &gt;public.gmane.org&gt; Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&amp;C 93 _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Jay McCarthy 2013-05-11T01:23:35 http://comments.gmane.org/gmane.comp.lang.racket.devel/8852 <pre>My experiment with immediately represented characters has gotten to a state where a non-JIT build passes all tests, but a JIT build fails (as in, segfaults) on the following program: #\c It also fails on: (integer-&gt;char 99) and: (define (foo x) (integer-&gt;char x)) (foo 99) but not on: (define (foo x) (write (integer-&gt;char x))) (foo 99) So there seems to be a problem returning a character from a jitted function back to the repl. I haven't been able to figure out where this occurs, though. gdb's stack traces don't seem very useful for jitted code, and I can't use Sam's disassembler, because the process dies. Any idea where to look or what debugging tools might be useful? -Jon _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Jon Zeppieri 2013-05-11T01:19:25 http://comments.gmane.org/gmane.comp.lang.racket.devel/8851 <pre> I've always wondered why the syntax of keywords implied two elements: the #:keyword and the identifier. I find that quite heavy for procedure headers, and most of the time I use the same symbol for the identifier and the keyword (and when I don't it's because I'm simply lazy and use a shorter identifier). Is there a rationale somewhere for that? Would it be a bad idea for Racket2 to consider that keyword identifiers are the same as the keyword without the `#:' ? Laurent _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Laurent 2013-05-09T14:22:54 http://comments.gmane.org/gmane.comp.lang.racket.devel/8846 <pre>RacketCon 2013 -------------- We are pleased to announce that (third RacketCon) will take place on September 29, 2013 at Northeastern University in Boston. This year, we plan to bring in several speakers from industry, as well as host talks from Racket developers and users. Lunch will be provided. On the Saturday (28th) before RacketCon, we plan to hold a hackathon to work on various Racket projects. Registration will open during the summer, and we will post a detailed schedule of events around the same time. The conference website is at http://con.racket-lang.org/ Asumu Takikawa and PLT _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Asumu Takikawa 2013-05-08T15:49:49 http://comments.gmane.org/gmane.comp.lang.racket.devel/8844 <pre>Hi all, Would anyone be opposed to adding a "Quickstart" section to the Package System documentation page? The current first section[1] is useful, but it's a pretty dense read for someone who just wants to know how to install a package. I'm imagining that the Quickstart would describe where to find packages (pkg.racket-lang.org, github, etc.) and the commands you need to type to install a package from typical sources. Maybe screenshots showing how to use the package GUI. [1]: http://docs.racket-lang.org/planet2/Package_Concepts.html Cheers, Asumu _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Asumu Takikawa 2013-05-08T12:56:19 http://comments.gmane.org/gmane.comp.lang.racket.devel/8841 <pre>I realize that I should get a --disable-jit version running before tackling this, but since I stumbled into it last night... In jitinline.c, at line 1834, there is code for generating a JIT-ted version of char-&gt;integer. I think I understand all of it, except for line 1851: 1851: jit_movr_p(dest, JIT_R0); If the initial test (at line 1846 succeeds, then we jump past this instruction (although we might jump back later, if the type-tag test (at 1853) fails (well, succeeds, I suppose). But, if we ever get to the code at line 1849: (void)jit_calli(sjc.bad_char_to_integer_code); Then we're never going to return from there... I think. So, I'm not sure what execution path the code could take where that move instruction would matter. Also, assuming that instruction is reachable, I still don't know what it's for. Can anyone (probably Matthew) enlighten me? -Jon _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Jon Zeppieri 2013-05-07T21:29:52 http://comments.gmane.org/gmane.comp.lang.racket.devel/8838 <pre>When you run #lang racket '#(1 1 1) the output is '#(1 1 1) When you run #lang scheme '#(1 1 1) the output is #(1 1 1) The difference in output (i.e., whether there's a leading quote) is because the `racket' and `scheme' languages arrange different run-time configuration of printing parameters. The language of a program's main module determines the configuration that is used. Until version 5.3.4.8, this run-time configuration was implemented via the `#lang' reader, which attached a syntax property to the module, which was preserved in the bytecode and accessed via `module-&gt;language-info', which produced a vector that referred to another module and a name of one of its exports, and so on... The complex chain of indirections was designed to enable loading code for different times at the right time --- but that's what submodules are for. Now, command-line `racket', DrRacket, and `raco exe' look for a `configure-runtime' submodule of a program's main module to be run before the main module. This is a much simpler and more general way to set up run-time parameters. For example, the output of #lang racket (module configure-runtime racket/base (print-vector-length #t)) '#(1 1 1) is '#3(1) since the `configure-runtime' module above turns on vector lengths. Normally, you don't write a `configure-runtime' submodule, and a language's `#%module-begin' introduces a suitable declaration automatically. The `racket' (and `racket/base') language adds a `configure-runtime' submodule to a module body unless there's already an immediate declaration (i.e., not under `begin' and not introduced by a macro). Besides being simpler to write and read, using a submodule is more general than a reader-added property. I think Carl once asked for a way to add runtime configuration at the macro level instead of the reader level, and now that's available. I haven't yet re-written the Guide's chapter 17 to use submodules, but I'm planning to do that next. _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Matthew Flatt 2013-05-07T13:17:16 http://comments.gmane.org/gmane.comp.lang.racket.devel/8837 <pre>It says "503 - The load average on the server is too high". Robby _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Robby Findler 2013-05-07T04:06:22 http://comments.gmane.org/gmane.comp.lang.racket.devel/8825 <pre>When I try to make a hole in the enumeration defined in stypes.h (by explicitly setting the value of a member), I get a segfault in the 3m build, though not the cgc one. Depending on where I place the hole, I've seen different stack traces. If I place the new tag before the _rt_ tags, then I get: #0 0x00007fff886d9db0 in bzero$VARIANT$sse42 () #1 0x000000010030d5ea in malloc_pages () at vm_osx.c:185 #2 0x0000000100314106 in allocate_big (request_size_bytes=32807, type=0) at newgc.c:974 #3 0x0000000100314e08 in GC_malloc_weak_array (size_in_bytes=16384, replace_val=0x0) at newgc.c:1463 If I place it after (which is where I want to place it), I get: #0 0x0000000000000000 in ?? () #1 0x0000000100310e9f in repair_heap [inlined] () at /Users/jaz/src/racket/src/racket/gc2/newgc.c:4171 #2 0x0000000100310e9f in garbage_collect (gc=0x7fff5fbf7c00, force_full=5339440, switching_master=1606384640, lmi=0x7fff5fbf7c00) at newgc.c:4753 #3 0x000000010031487a in scheme_get_thread_local_variables [inlined] () at /Users/jaz/src/racket/src/racket/include/schthread.h:1283 #4 0x000000010031487a in allocate_slowpath [inlined] () at /Users/jaz/src/racket/src/racket/gc2/newgc.c:1289 #5 0x000000010031487a in allocate (request_size=4300306736, type=1606384720) at newgc.c:1348 #6 0x00000001002ad122 in scheme_make_stx_w_offset (val=0x102a00300, src=0x1003b10b8, props=0x1003b10b8, line=-1, col=-1, pos=1553, span=140734799772896) at syntax.c:577 I noticed that gc2.h's description of GC_init_type_tags() mentions that the count parameter will always be less than 256, and I wondered if that could be causing a problem, because I was trying to create a type tag with a value of 512. However, the comment appears to be wrong, because stypes.h currently defines tags up to 259 (_scheme_last_type_ == 260), and it looks like _scheme_last_type_ is used as the count param in salloc.c. Is there some other limit (aside from the limit of Scheme_Type itself, which is defined as a short, so that's at least 16 bits)? Or is there an assumption that the enumeration is dense? Or something else? -Jon _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Jon Zeppieri 2013-05-06T00:16:46 http://comments.gmane.org/gmane.comp.lang.racket.devel/8813 <pre>Speaking of invariants, from time to time I would like Racket to know some properties about its usual operators, so that some usual treatments get simplified and can be easily generalized. For example, considering group theory, properties like 'identity-element', 'absorbing-elements', 'inverse-operator', 'commutative?', 'associative?' and such could be attached to operators like `+', `*', `max', `string-append', `hc-append', etc. Forms like `for/op' could use this information to know how to loop and accumulate, and even possibly to optimize the code, even for newly created operators. In the simple case of + and such, one also only needs to define the binary operator, and the multi-argument procedure can be generated automatically. Of course it needs not be tied to group/category/mathematical theory. It can be about whatever is useful. It's only an idea, in case this resonates for someone. Laurent _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Laurent 2013-05-05T15:00:52 http://comments.gmane.org/gmane.comp.lang.racket.devel/8794 <pre>Since incompatible future changes seem to be coming up a lot, I thought I'd add one more. What do the members of this list think of removing eqv? all of its associated machinery (e.g., memv, hasheqv, etc.)? (Along with this change, it would be nice if characters could all be immediately represented, so that those with equal code points would be eq? RIght now, all unicode code points can be encoded in 22 bits, I think. I'm not so familiar with racket's current representation of characters, but I figure that they could easily be fit into a single machine word on 64-bit builds. I don't know how difficult it would be on 32-bit builds. And, of course, there's no guarantee that the number of code points won't increase significantly.) Alternatively (and following Sam's line of thought from [1]), eqv? could be extended to cover all of racket's immutable data structures. In this case eqv? should also be made generic so that user-defined immutable data structures can use it, as well. [1] http://lists.racket-lang.org/users/archive/2013-April/057510.html _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Jon Zeppieri 2013-05-04T15:57:21 http://comments.gmane.org/gmane.comp.lang.racket.devel/8760 <pre>[ for those that just want to see what I'm getting at, scroll to the end ] While the docs are clear (enough) on this point, I think it can be quite confusing. See if you spot the bug in this program: #lang racket (define (find-literals e) (define literals '()) (let loop ([e e]) (match e [`(λ (,x) ,e) (loop e)] [`(,e1 ,e2) (loop e1) (loop e2)] [(? symbol?) (void)] [else (cond [(member e literals) (void)] [else (set! literals (cons e literals))])])) literals) (module+ test (require rackunit) (check-equal? (find-literals '(λ (x) x)) '()) (check-equal? (find-literals '((λ (x) x) 1)) '(1)) (check-equal? (find-literals '((λ (x) x) #f)) '(#f))) Hint: the last test case fails. Second hint: if you switch it to use sets, it starts working. Third hint: this isn't about lists. :) The bug is that 'else' is treated as a variable in match, so it gets bound to #f, which shadows the else in the cond which .... is confusing. So, how about making match treat else specially? I don't ask this completely from outer space; there was a bug in Redex's random generation that was caused exactly by this shadowing of else. Robby _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Robby Findler 2013-05-03T13:39:07 http://comments.gmane.org/gmane.comp.lang.racket.devel/8754 <pre>The release announcement sketch that I have so far is below. Please mail me new items and/or edits. ---------------------------------------------------------------------- * Extflonums (80-bit floating-point numbers) are supported on some x86/x86_64 platforms --- including Windows, and including platforms where Racket is compiled to use SSE instructions for flonum arithmetic. Thanks to Michael Filonenko. * DrRacket (and all of the other apps) are now signed with an official OS X key. * Tally Maze: a new game based an enumeration of 2d mazes. * The Optimization Coach DrRacket plugin has been moved from the Racket distribution to the Racket package repository. * Redex: define-union-language now merges productions when languages define the same nonterminals. Thanks to William Bowman. * The srfi/19 library is now compatible with the date structure type exported by racket/base. ---------------------------------------------------------------------- _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Ryan Culpepper 2013-05-01T19:57:45 http://comments.gmane.org/gmane.comp.lang.racket.devel/8747 <pre>I'm seeing the following error message on HEAD (08dc0e10d934cb29b9830a94945c2e38c275a9d8): application: procedure does not expect an argument with given keyword procedure: t-&gt;c/both given keyword: #:kind given arguments: Boolean #:kind 'impersonator #:seen (list (cons #(struct:#&lt;syntax:/Users/dyoo/work/whalesong/whalesong/promise.rkt:13:20 MyPromise&gt; (Boolean (-&gt; g305) (U Sentinel g305))) #&lt;syntax rec5&gt;)) context...: /Users/dyoo/local/racket/collects/racket/private/kw.rkt:1255:14 /Users/dyoo/local/racket/collects/typed-racket/private/type-contract.rkt:428:16: for-loop parse-loop178 /Users/dyoo/local/racket/collects/racket/private/map.rkt:21:13: map parse-loop1254 /Users/dyoo/local/racket/collects/typed-racket/private/type-contract.rkt:215:13 /Users/dyoo/local/racket/collects/racket/private/map.rkt:21:13: map f902 /Users/dyoo/local/racket/collects/typed-racket/typecheck/provide-handling.rkt:54:2: mk16 /Users/dyoo/local/racket/collects/unstable/list.rkt:139:0: map/values /Users/dyoo/local/racket/collects/typed-racket/typecheck/provide-handling.rkt:55:4: mk-untyped-syntax /Users/dyoo/local/racket/collects/typed-racket/typecheck/provide-handling.rkt:54:2: mk16 /Users/dyoo/local/racket/collects/typed-racket/typecheck/provide-handling.rkt:143:2: for-loop /Users/dyoo/local/racket/collects/typed-racket/typecheck/provide-handling.rkt:49:0: generate-prov /Users/dyoo/local/racket/collects/typed-racket/typecheck/tc-toplevel.rkt:292:0: type-check success... _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Danny Yoo 2013-04-29T23:27:29 http://comments.gmane.org/gmane.comp.lang.racket.devel/8724 <pre>Checklist items for the v5.3.4 release (using the v5.3.3.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. --&gt; Release candidates are at --&gt; http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test the `master' branch by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x ---------------------------------------------------------------------- * John Clements &lt;clements-USm5ewCNdr/ECKqllllIWg&lt; at &gt;public.gmane.org&gt; - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.3.4 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Matthias Felleisen &lt;matthias-1vnkWVZi4QaVc3sceRu5cw&lt; at &gt;public.gmane.org&gt; - Teachpacks Tests: check that new teachpacks are addable - Teachpack Docs: check teachpack docs in the bundles Updates: - Teachpack Updates: update HISTORY (updates should show v5.3.4 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Kathy Gray &lt;kathryn.gray-kDbDZe0LBGWFxr2TtlUqVg&lt; at &gt;public.gmane.org&gt; - Test Engine Tests * Noel Welsh &lt;noelwelsh-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) * Eli Barzilay &lt;eli-oSK4jVRJLyZg9hUCZPvPmw&lt; at &gt;public.gmane.org&gt; - Verify PL language - Racket Tree: compare new distribution tree to previous one * Carl Eastlund &lt;cce-1vnkWVZi4QaVc3sceRu5cw&lt; at &gt;public.gmane.org&gt; - Dracula Tests (confirm that Dracula runs from PLaneT) * Neil Toronto &lt;neil.toronto-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; - Plot Tests - Images Tests - Inspect icons - Math tests _________________________ Racket Developers list: http://lists.racket-lang.org/dev </pre> Ryan Culpepper 2013-04-23T03:29:42 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.racket.devel