[racket-dev] raco pkg and github
Hi all, One thing that a few people using `raco pkg` (including myself) have found is that when you upload a package to pkg.racket-lang.org that's hosted on github, you can easily get checksum errors. The checksum mismatch happens when the github HEAD has been updated, but the checksum on the PNS is out of date. The behavior that I expected was that `raco pkg` would just download the commit matching the PNS checksum from github and use that. Is there any design reason to not do that instead? Attached is a hackish patch that just demonstrates that this is do-able. As an example, you can try `raco pkg install sweet-exp`, which will install commit fbd09b4be38b rather than the current github HEAD. Cheers, Asumu From b1e89c1b30338d9b6788799c47ccfe247fa592da Mon Sep 17 00:00:00 2001 From: Asumu Takikawa as...@ccs.neu.edu Date: Wed, 30 Jan 2013 17:42:59 -0500 Subject: [PATCH] A hack to make checksums more flexible for github --- collects/planet2/lib.rkt | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/collects/planet2/lib.rkt b/collects/planet2/lib.rkt index d5404f3..699170e 100644 --- a/collects/planet2/lib.rkt +++ b/collects/planet2/lib.rkt @@ -398,7 +398,9 @@ #:force? [force? #f] descs) (define check-sums? (not ignore-checksums?)) - (define (install-package pkg given-type given-pkg-name) + (define (install-package pkg given-type given-pkg-name + ;; This is hackish, but it demonstrates it works + #:index-checksum [index-checksum #f]) (define-values (inferred-pkg-name type) (if (path? pkg) (package-source-name+type (path-string pkg) @@ -428,6 +430,7 @@ (update-install-info-orig-pkg (match type ['github +(set! checksum index-checksum) (unless checksum (pkg-error (~a could not find checksum for github package source, which implies it doesn't exist\n source: ~a) @@ -437,7 +440,7 @@ (define new-url (url https #f github.com #f #t (map (λ (x) (path/param x empty)) -(list user repo tarball branch)) +(list user repo tarball checksum)) empty #f)) (define tmp.tgz @@ -644,7 +647,8 @@ (define checksum (hash-ref index-info 'checksum)) (define info (install-package source #f -pkg-name)) +pkg-name +#:index-checksum checksum)) (when (and (install-info-checksum info) check-sums? (not (equal? (install-info-checksum info) checksum))) -- 1.7.10.4 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Instantiation syntax of `new`
On 2013-02-03 10:50:31 -0500, Tony Garnock-Jones wrote: (inst c% 1 2 3) (inst c% #:x 1 #:y 2) (inst c% 1 2 #:z 3) ;; not sure what to do about the last one Also if you want to play with this, I implemented something like this once: https://github.com/takikawa/racket/tree/kw-init I think the syntax was (define c% (class object% (super-new) (init-field #:x [x 3]))) like function headers. And you can initialize like: (new c% #:x 3) or (new c% [x 3]) Although it's a little buggy, because if you change [x 3] to [y 3] it won't accept #:x and will only accept #:y. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
On 2013-02-10 05:57:52 -0700, Matthew Flatt wrote: Sorry that it has taken me so long to join in and that I overlooked the PR way back in September. Thanks for the fix! On a related note, should any of the following interactions work? $ racket Welcome to Racket v5.3.3.1. - (enter! (submod scheme/unit compat)) ; module-namespace: unknown module in the current namespace ; name: #resolved-module-path:(submod ; /home/asumu/plt/racket-git/collects/scheme/unit.rkt compat) ; [,bt for context] - (module foo racket (define x 3) (module bar racket (define x 5))) - (enter! 'foo) 'foo (enter! 'bar) ; module-namespace: unknown module in the current namespace ; name: #resolved-module-path:'bar ; [,bt for context] 'foo (enter! (submod . bar)) ; standard-module-name-resolver: no base path for relative submodule path: ; (submod . bar) [,bt for context] Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Segfault on HEAD?
Hi all, I get a reproducible segfault when I built Racket from git HEAD. This is what I see: raco setup: 7 making: redex/examples (Reduction Semantics examples) reverse: contract violation expected: list? given: 4193052015854236082 SIGSEGV SI_KERNEL SI_CODE 128 fault on addr (nil) sent by kernel Aborted make[1]: *** [install-3m] Error 134 make[1]: Leaving directory `/home/asumu/plt/racket-git-segfault/src/build' make: *** [install] Error 2 It always seems to segfault at that point in the build. I'm building a fresh copy of the tree, so it's not a stale zo problem or anything. Anything I can do to diagnose? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Segfault on HEAD?
On 2013-02-13 11:24:35 -0500, Asumu Takikawa wrote: I get a reproducible segfault when I built Racket from git HEAD. This is what I see: A git bisect seems to pinpoint the segfault to commit 4a0adb6a74630f4afc7fd85275ffca76836037b4. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Fix for PR13305 displays oddly in Opera
Hi all, A few days ago, PR 13305 was fixed in commit 29031f0972ead0d3cd26d61f163b5e5b59e9ffce. Unfortunately, the fix makes some identifiers in the docs display oddly in Opera. I've attached some screenshots that demonstrate the issue. Cheers, Asumu attachment: toc.pngattachment: broken-toc.png_ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26316: master branch updated
On 2013-02-19 10:48:21 -0500, mfl...@racket-lang.org wrote: ca95129 Matthew Flatt mfl...@racket-lang.org 2013-02-19 08:02 : | JIT: inline `char-integer' and `integer-char' I think this commit broke the build for me. I get segfaults like this: raco setup: 7 making: ffi SIGSEGV MAPERR si_code 1 fault on addr 0x1386ad8 Aborted And I also get errors from integer-char like this: integer-char: contract violation expected: (and/c (integer-in 0 #x10) (not/c (integer-in #xD800 #xDFFF))) given: #bad-value I'll try getting a stack trace too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26316: master branch updated
On 2013-02-19 10:44:47 -0700, Matthew Flatt wrote: I forgot to check 32-bit mode, and I see a problem there. Are you using a 32-bit or 64-bit build? 64-bit. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Potential bug with icons in head
On 2013-02-19 19:19:24 +0100, Philippe Mechaï wrote: I've just compiled latest Racket version and found out icons are not displayed correctly as shown in attached screenshot. Please tell me if I can be of any help to diagnose this problem. FWIW, I've had this problem too on a 64-bit Linux machine. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Tweaked doc pages
On 2013-02-26 09:53:11 -0500, Eli Barzilay wrote: I have finally implemented a script that hacks the on-line doc pages. Currently, it does the following (and you can see the changes on the web now): Maybe I'm missing something, but the changes have been rolled back from the main page right? Can you upload the new version somewhere so we can see what it would look like? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] take/drop argument order
Late reply, but better than never. On 2013-03-10 16:20:14 -0400, Eli Barzilay wrote: Assuming this, here's a suggestion that I made in the past for resolving this: * Make the existing `take', `drop', `split-at' accept their arguments in *either* order. I'm fine with this. * Change the required types for lists to be a null-or-pair, or even require a `list?', or require a `list?' but throw an error only if scanning gets to a non-null-terminator. Any of these would make sure that the arguments are distinguishable. (You can currently write something like (take 0 1) -- it's not an error.) I would much prefer a `list?` if backwards compatibility for this isn't a concern. Has anyone *ever* used the feature that `take` can operate on non-lists? * And another thing that can be done to reduce the name clutter is to have only the plain names, but make them accept either an index or a predicate. I'm less sure about this change, since the `f` suffix isn't particularly verbose and the integer case is likely more common, but I'm not opposed to it either. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26528: master branch updated
On 2013-03-30 10:10:20 -0400, ry...@racket-lang.org wrote: 293b208 Ryan Culpepper ry...@racket-lang.org 2013-03-20 10:52 : | added optional #:grammar clause to defform, etc : M collects/scribble/private/manual-form.rkt | 68 - M collects/scribblings/scribble/manual.scrbl | 132 ++ Is this the preferred way of documenting forms now? It does look more convenient, and I noticed that `defform/subs` and friends are now relegated to a smaller corner of the docs. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26558: master branch updated
On 2013-04-04 10:29:30 -0700, Eric Dobson wrote: Can we make it so that IP addresses are immutable? This would require changing make-ip-address to have a call to make-immutable-bytes in each case. That's a good suggestion, thanks. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] take/drop argument order
On 2013-04-11 12:05:59 -0400, Eli Barzilay wrote: Remove the `*f' functions from the interface, and change the non-`*f' functions to accept keywords as follows: (take #:num N L) (take #:while P L) (take #:until P L) I like this suggestion since keywords seem like a nice Rackety solution. On the other hand, does this solve the original problem? As I understand, the original objection was that the `take` arguments should look familiar to someone from Clojure, Haskell, etc. Also, what happens if I wrote the following? (take #:while P L 5) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26710: master branch updated
On 2013-04-25 14:55:45 -0400, as...@racket-lang.org wrote: a15fa5b Asumu Takikawa as...@racket-lang.org 2013-04-20 23:18 : | Start on a notation section for the Reference : This is in response to the How to read procedure documentation? thread from the users list. It documents how to read some of the blue boxes with contracts from the Reference. I'm not sure this is the best place to put it, so feedback appreciated on where it should go (or anything else). Ryan was also suggesting that there should be explanations of blue boxes interspersed in the Guide as well (in 2.2.4 for example) with more Guide-like language, which I agree would be a good thing to add. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR tests sometimes fail with a promise error
On 2013-04-04 10:33:25 -0700, Eric Dobson wrote: Sometimes TR tests fail with the error [...] How can this happen? Is the thread getting killed? Also since this error doesn't have blame information I don't know if this is an internal promise error or if TR is misusing the promise library. I still don't know the cause of this problem, but the following smaller example seems to exhibit the issue: #lang racket ;; Run this in collects/tests/typed-racket/optimizer (require unstable/open-place) (define (start-worker get-ch name) (open-place ch (let loop () (loop (define-values (enq-ch deq-ch) (place-channel)) (define (start-workers) (for ([i 8]) (start-worker deq-ch i))) (define (mk-suite dir) (define prms (for/list ([name (directory-list dir)] ;; this line appears to be critical for some ;; strange reason #:when (regexp-match .*rkt$ name)) (delay/thread 0))) (for/list ([p prms]) (force p))) (define (optimization-tests) (mk-suite tests)) ;;; (start-workers) (optimization-tests) ;;; This produces a promise error on every third or fifth run or so for me. Commenting out the #:when line makes it work, very oddly. Since this error appears to be raised when the thread is killed prematurely (e.g., (thread-kill (current-thread)) or via a continuation abort), I would guess that the promise thread is somehow killed by a strange interaction with places or something else. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR tests sometimes fail with a promise error
On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote: This produces a promise error on every third or fifth run or so for me. Commenting out the #:when line makes it work, very oddly. Tried it on another machine, the #:when line didn't matter there. Also, I can reproduce this more reliably on a machine with fewer cores. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 2013-05-04 10:36:14 -0500, Robby Findler wrote: The racket2 wiki currently says try this out so I guess it isn't something people believe will definitely be better, but something to explore. FWIW, Clojure uses keywords for `else` so there is some experience there: http://clojuredocs.org/clojure_core/clojure.core/cond Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Package system quickstart section?
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
[racket-dev] [ANN] RacketCon 2013: 29 September
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
[racket-dev] set!-transformers and syntax-local-value/immediate
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
Re: [racket-dev] set!-transformers and syntax-local-value/immediate
On 2013-05-17 19:51:00 -0400, Carl Eastlund wrote: That's where the rename comes from. Ah, thanks! I should've looked closer at the expansion. (also thankfully it turns out I didn't need any complicated set!-transformer manipulation to do what I was trying to do) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26861: master branch updated
On 2013-05-19 17:55:26 -0700, Eric Dobson wrote: This doesn't pass with contract checking enabled. make-StructTop requires a Struct? not any old Type?. Is there a reason that the type is not just bottom? In the error case? I'm not sure. TBH, I cargo culted that line. Sam, do you have an opinion on this? (you had the last commit to touch that line before me) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote: 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. One nice thing about the current repo organization is that push notifications for every part of the PLT codebase go to all of the developers. Will that still be available in this organization scheme? (I don't care if it's opt-in too much, but opt-out will hopefully mean more eyes see the code) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] member like assoc
Hi all, Is it feasible to get `member` to have the same optional argument behavior as `assoc`? That is, to have an equality predicate as the third argument. I find myself writing the (imaginary) equivalent of things like: (member id some-list free-identifier=?) and it seems like it would be nicer with an extra `member` argument than with `memf`. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.
On 2013-06-09 00:06:21 +0530, Mayank Jain wrote: I am participating in Lisp in Summer Project[0]. *Recently I stated doing this course on coursera[1], and I realized that there is no equivalent of paredit[2] mode in DrRacket (atleast I couldn't find anything of that sort). That sounds like a great project idea! I just wanted to comment that if you get this working, I would definitely use it. And I was wondering if I could work on porting it. Can anyone guide me into what is possible? What I should be looking at etc? You will probably want to look into the main text editing interfaces in Racket's GUI library such as editor%, text%, and racket:text%. http://docs.racket-lang.org/gui/editor___.html http://docs.racket-lang.org/gui/text_.html http://docs.racket-lang.org/framework/Racket.html#%28def._%28%28lib._framework%2Fmain..rkt%29._racket~3atext~3c~25~3e%29%29 (maybe you can port paredit by replacing the emacs text buffer manipulation function calls with method calls into these interfaces) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.
On 2013-06-09 23:25:43 +0530, Mayank Jain wrote: While it does autocomplete the closing paren, it does not prevent you from breaking the form if I accidentally delete the opening/closing paren. This is a feature that I like a lot from paredit, because it provides some level of confidence that I won't have silly mismatched parens. One improvement over paredit that I'd like to see in a DrRacket port is to handle #; comments correctly. For the features of paredit that are already in DrRacket, it'd be nice if the paredit plugin could just change the keybindings around so that those of us who are used to emacs+paredit can use it without re-training (unless this is already the case). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] member like assoc
On 2013-05-31 19:40:52 -0400, Asumu Takikawa wrote: Is it feasible to get `member` to have the same optional argument behavior as `assoc`? That is, to have an equality predicate as the third argument. I went ahead and implemented this behavior and submitted a pull request: https://github.com/plt/racket/pull/366 To see if the change is pay as you go, I ran some microbenchmarks to see if old-style `member` calls would slow down (see below). There doesn't seem to be any significant slow-down AFAICT. I was surprised that the non-JIT version was faster in the first case but much slower in the second microbenchmark though. (note: I had to change the C implementation of `member` for the non-JIT path) I'd appreciate any suggestions on the code. Cheers, Asumu ;;; NEW BRANCH $ racket member-benchmark.rkt cpu time: 1748 real time: 1752 gc time: 0 $ racket --no-jit member-benchmark.rkt cpu time: 1524 real time: 1526 gc time: 0 ;;; MASTER $ racket member-benchmark.rkt cpu time: 1712 real time: 1716 gc time: 0 $ racket --no-jit member-benchmark.rkt cpu time: 1524 real time: 1528 gc time: 0 The microbenchmark is just this: #lang racket/base (require (only-in racket/list range)) (define lst (range 1 5000)) (time (for ([i 3]) (member 2500 lst))) On a slightly different microbenchmark: ;;; NEW BRANCH $ racket member-benchmark-2.rkt cpu time: 2396 real time: 2402 gc time: 0 $ racket --no-jit member-benchmark-2.rkt cpu time: 7156 real time: 7174 gc time: 0 ;;; MASTER $ racket member-benchmark-2.rkt cpu time: 2412 real time: 2416 gc time: 0 $ racket --no-jit member-benchmark-2.rkt cpu time: 6892 real time: 6911 gc time: 0 #lang racket/base (define lst '(a b c)) (time (for ([i 3000]) (member 'b lst))) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] member like assoc
On 2013-06-09 20:51:21 -0500, Robby Findler wrote: Do the times change if you put an 'in-range' in the for loops? Is this the code change you meant? #lang racket/base (require (only-in racket/list range)) (define lst (range 1 5000)) (time (for ([i (in-range 3)]) (member 2500 lst))) ;;; NEW BRANCH $ racket member-benchmark-3.rkt cpu time: 1756 real time: 1760 gc time: 0 $ racket --no-jit member-benchmark-3.rkt cpu time: 1524 real time: 1530 gc time: 0 ;;; MASTER $ racket member-benchmark-3.rkt cpu time: 1756 real time: 1761 gc time: 0 $ racket --no-jit member-benchmark-3.rkt cpu time: 1532 real time: 1535 gc time: 0 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] member like assoc
On 2013-06-09 21:15:31 -0500, Robby Findler wrote: Sorry: I should have been clearer: I would only expect a difference when the list is short (so your benchmark 2). Here're the numbers for that: #lang racket/base (define lst '(a b c)) (time (for ([i (in-range 3000)]) (member 'b lst))) ;;; NEW BRANCH $ racket member-benchmark-4.rkt cpu time: 1408 real time: 1414 gc time: 0 $ racket --no-jit member-benchmark-4.rkt cpu time: 3724 real time: 3731 gc time: 0 ;;; MASTER $ racket member-benchmark-4.rkt cpu time: 1380 real time: 1384 gc time: 0 $ racket --no-jit member-benchmark-4.rkt cpu time: 3616 real time: 3622 gc time: 0 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote: Because this change will break all sorts of things in the short run, I'd like to feel more confident that enough of us are ready before merging it to the main Racket repository. The pkg2 branch builds for me fine (modulo `plot`) and I can run DrRacket. The `plt-games` executable does not work, however, and just produces a blank window for me. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] path-relative-string/setup
Hi all, It looks like in the recent pkg reorganization, the function `path-relative-string/setup` has disappeared from the `setup/path-to-relative` module. As a result, XREPL's ,enter doesn't work anymore and possibly other things. Is this an intentional omission or was it just lost by accident? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] TR internal error
On 2013-01-21 10:48:48 +0100, Pierpaolo Bernardi wrote: the file attached causes the following internal error: Internal Typechecker Error: bad expected: #(struct:tc-results (#(struct:tc-result Char - -) #(struct:tc-result (Vector Integer Integer Integer Integer) - -)) #f) while typechecking: (#%app vector ah am as af) originally: (vector ah am as af) Thanks for the report! Sorry for not getting around to this earlier, but I've pushed a fix now. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] local-transformer-expand behavior
Hi all, Does anyone know what the behavior of (local-transformer-expand #'(define x 3) 'top-level null) should be? I'm not sure, but I expected something like what `local-expand` would do. Instead, I get an error like this: (define-syntax (m stx) (local-transformer-expand #'(define x 3) 'top-level null)) (m) ; readline-input:14:51: define: not allowed in an expression context ; in: (define x 3) ; [,bt for context] Am I just misuing the function? I also tried to wrap the quoted definition with a `let`, but then got errors saying `let-values` is unbound (which seems odd since it's a core form). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] engine-kill from racket/engine
Hi all, I was trying to write an example for the racket/engine docs and stumbled on a case that seems to cause a deadlock. I'm curious if this is intentional or just accidental behavior. Here's the example: #lang racket (require racket/engine) (define e (engine (lambda (s) (sleep 5 (thread (lambda () (sleep 2) (engine-kill e))) (engine-run never-evt e) This will never terminate. If you comment out the fourth line, it will terminate. If you change `never-evt` to 4000 (or any other event that will become ready), it's also fine. What seems to be going on is that `engine-kill` does actually kill the thread underlying the engine. However, `engine-run` is `sync`ed on (1) the given event (2) the engine being done or (3) an exception being raised. Since `engine-kill` does not trigger any of those, the `sync` is blocked. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Triggered a macro system internal error
Hi all, I accidentally triggered what appears to be an internal error message from the macro expander (to do with syntax taints). Unfortunately, I have no idea how to come up with a narrow test case since it happens due to changing Typed Racket's `struct:` expansion. I've attached a short patch below that shows what's needed to trigger it though. Here's the interaction I get with the patch applied: $ racket -I typed/racket Welcome to Racket v5.3.900.1. - (struct: Foo ([x : Integer])) ; internal error: cannot copy taint armings from tainted source [,bt for ; context] Any ideas on how I can get a better test case? Cheers, Asumu From 4abd6636420c0425b77015ca5a00ecb73230f3c7 Mon Sep 17 00:00:00 2001 From: Asumu Takikawa as...@ccs.neu.edu Date: Tue, 25 Jun 2013 10:03:02 -0400 Subject: [PATCH] Patch that triggers internal taint error --- .../typed-racket-lib/typed-racket/base-env/prims.rkt |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt b/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt index 548bfe4..d3a8b53 100644 --- a/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt +++ b/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt @@ -593,7 +593,10 @@ This file defines two sorts of primitives. All of them are provided into any mod nm.old-spec (fs ...) #:maker #,cname #,@mutable?))]) -#'(begin d-s dtsi)))] +(if (eq? (syntax-local-context) 'top-level) +#'(begin (module a typed/racket d-s dtsi) + (eval '(require 'a))) +#'(begin d-s dtsi] ;Copied from racket/private/define-struct -- 1.7.10.4 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] local-transformer-expand behavior
On 2013-06-25 11:02:37 +0200, Matthew Flatt wrote: That error is due to a bug in handling the 'top-level context, and I've pushed a repair. Thanks for the repair and nice explanation! Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Things we could move out of the core
On 2013-06-25 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
- mzlib/{pconvert, class100, serialize, thread, transcr}
According to the 5.3 release announcement, class100 is set to be removed
by the August release, so maybe we can just remove it entirely now.
Cheers,
Asumu
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27030: master branch updated
On 2013-06-27 22:21:23 -0400, as...@racket-lang.org wrote: 42b5cfe Asumu Takikawa as...@racket-lang.org 2013-06-27 22:17 : | Use racket/cmdline instead of mzlib/cmdline | | This should fix the build : This fixes the build on my machine, but there are several more files left over that have dependencies on `mzlib`. I don't know which are essential: * racket/src/worksp/gc2/make.rkt * racket/src/worksp/mzcom/xform.rkt * racket/src/racket/gc/upgrade.rkt * racket/src/mac/osx_appl.rkt Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] snapshot builds
On 2013-07-02 13:40:18 -0600, Matthew Flatt wrote: The snapshot page has * Racket installers with the usual stuff: DrRacket, HtDP support, etc. I tried the Racket Windows installer, but AFAICT it's missing DrRacket and other libraries. $ sha1sum.exe /home/asumu/racket-5.3.900.3-i386-win32.exe 5ba5331efbc0d8d0443dce795f1da045a24a4c21i/ $ ls doc etc include lib man Racket.exe raco.exe Uninstall.exe Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] snapshot builds
On 2013-07-03 22:56:16 -0600, Matthew Flatt wrote: The 32-bit Windows Racket installer works for me, this time --- but the Mac OX X builds seem completely broken. Thanks, this time I was able to get DrRacket from the installer. BTW, one thing that seems broken is if I go to the package manager and click on Installl from List, I get the following internal error: get-all-pkg-details-from-catalogs: bad response from server url: http://www.cs.utah.edu/plt/snapshots/20130703-d2ddfc0/catalog/pkgs-all?version=5.3.900.3 response: #f context...: C:\Program Files\Racket-5.3.900.3\lib\collects\pkg\lib.rkt:2008:2: for-loop C:\Program Files\Racket-5.3.900.3\lib\pkgs\drracket\pkg\gui\by-list.rkt:321:9: for-loop I can't seem to reproduce it the same way anymore, but it also happens if I click Update Package List. Also, thanks for setting this up! Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Tool warnings from raco
Hi all, I've suddenly started getting odd warnings from `raco` on git HEAD. Any idea what's going on? warning: tool make registered twice: make and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool exe registered twice: exe and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool pack registered twice: pack and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool unpack registered twice: unpack and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool decompile registered twice: decompile and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool test registered twice: test and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool expand registered twice: expand and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool distribute registered twice: distribute and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool ctool registered twice: ctool and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool demodularize registered twice: demodularize and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands warning: tool docs registered twice: docs and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/racket-pkgs/racket-doc/help warning: tool check-requires registered twice: check-requires and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/macro-debugger-pkgs/macro-debugger-text-lib/macro-debugger warning: tool show-dependencies registered twice: show-dependencies and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/macro-debugger-pkgs/macro-debugger-text-lib/macro-debugger warning: tool scribble registered twice: scribble and #path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/scribble-pkgs/scribble-lib/scribble Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] expand, local-expand, and syntax-procedure-converted-arguments-property
Hi all, I'm currently trying to fix the Typed Racket unit tests. I think I've narrowed down the issue to a certain syntax property for keyword functions. The issue is illustrated by the following example: #lang racket (require racket/file (for-syntax racket/file racket/keyword-transform)) ;; the property is #f (begin-for-syntax (displayln (syntax-case (expand-syntax #'(copy-directory/files 1 2)) () [(let-values (((temp1) _) ((temp2) _)) (if _ (#%plain-app1 copy-directory/files15 e1 ...) (#%plain-app2 copy-directory/files17 e2 ...))) (syntax-procedure-converted-arguments-property #'copy-directory/files15)]))) ;; property is syntax (begin-for-syntax (displayln (syntax-case (local-expand #'(copy-directory/files 1 2) 'expression null) () [(let-values (((temp1) _) ((temp2) _)) (if _ (#%plain-app1 copy-directory/files15 e1 ...) (#%plain-app2 copy-directory/files17 e2 ...))) (syntax-procedure-converted-arguments-property #'copy-directory/files15)]))) There are two syntax-time computations here. Both are expanding an application of a keyword function (one with local-expand, one with expand) and looking at the resulting syntax. The key point here is that I want to find the property looked up by `syntax-procedure-converted-arguments-property` on an output identifier because Typed Racket needs it to type-check the expansion. Unfortunately, as the comments indicate, only the second piece of code can find the property. The reason appears to be that the property key is actually a private `gensym`ed symbol and the two pieces of code appear to get separate instantiations of the kw.rkt module (perhaps at different phases). To check that, if I modify kw.rkt to use a plain symbol, both of the snippets above return the same property value. Anyone have any idea how I can keep using `expand` but still be able to look up the property? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] RacketCon Signup
*** Action Item: sign up for RacketCon http://bit.ly/racketconsignup2013 *** RacketCon 2013 will be taking place at Northeastern University on September 29. Please sign up at the link above if you plan on attending. If you are interested in giving a 10 minute talk on something you've built in or for Racket, please contact the organizers at racket...@racket-lang.org Cheers, Asumu Takikawa _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Motivation for handle-evt/wrap-evt contracts
Hi all, I had a question about `handle-evt` and synchronizable events in general. I was trying to understand the documentation and only have a partial idea of the motivation behind `handle-evt` and the contracts of `handle-evt` and `wrap-evt`. In particular, what is the motivation for disallowing objects that satisfy `handle-evt?` as an argument for `handle-evt` and `wrap-evt`? As far as I understand, `handle-evt` allows more efficient post-processing of a synchronization result because the handler is called in tail position. However, it doesn't seem necessary to disallow the addition of more handlers (with the caveat that the tail call guarantee will disappear if this happens). Am I missing something? Note: I'm asking because these restrictions in the contracts complicate the types that we need to assign in Typed Racket: https://github.com/plt/racket/pull/379 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Motivation for handle-evt/wrap-evt contracts
On 2013-07-25 12:55:25 -0500, Robby Findler wrote: I think the issue is that the tail guarantee can't be met if there are two handles (one won't be in tail position wrt to the sync). I understand. I guess what I'm asking is that there seem to be two reasonable choices for the semantics here: (1) Do not allow an event that is created as a handle event to ever have two handlers. (2) If an event ever ends up having two handlers, that's okay, but it will not respond #t to `handle-evt?`. My question boils down to why semantics (1) and not (2)? (though it doesn't matter much if we just choose not to reflect this in the type system, but that means you will sometimes get a contract error saying expected (not/c handle-evt?) but ...) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Motivation for handle-evt/wrap-evt contracts
On 2013-07-25 12:36:32 -0600, Matthew Flatt wrote: My thought was that you should only use `handle-evt' if you need tail behavior for something like a loop. If you use `handle-evt' and you're not getting tail behavior (but `sync' continues on, anyway), then something has gone wrong --- and maybe it's better to get an error than have a slow leak that will be tricky to detect. I could see how that might be a better choice for debugging. Especially since it seems that people don't check `handle-evt?` on events (which you would need to do to ensure tail-behavior in semantics 2). In particular, there are zero uses of `handle-evt?` in the codebase outside of tests. Since it's primarily a performance debugging feature, it seems OK to ignore the distinction in Typed Racket and keep the current semantics. Thanks, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] alarm-evt contract
Hi all, Is there any reason for the documented contract on `alarm-evt` to specify a non-negative real? The function will happily accept negative inputs and it seems like that's desirable (if for some reason your computer clock is set to before 1970 for a good reason). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote: I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. Perhaps it would be worth considering using the git subtree feature instead of submodules for the rest of the repository (just to clarify, I'm not saying we should reconsider submodules for native-pkgs). Description here: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt In particular, this aspect seems useful for us: you can also extract the entire history of a subdirectory from your project and make it into a standalone project From what I understand (not having used them yet), subtrees also enable end users of our main repo to just do a clone without any special consideration for the subtrees. Only package maintainers would have to occasionally update the subtrees in the main repo to pull in changes from their own package repos. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-30 17:44:37 -0400, Carl Eastlund wrote: I looked into git-subtree, and as I recall it, nothing in the setup recalls what subtree is used for what. Every git-subtree command you enter has to be fully explicit, which is a big hassle. AFAIK, you are correct. OTOH, I imagine that using subtree commands is actually going to be relatively rare. Here is my reasoning: * You are a developer on a Racket main distribution package: - Most of your commits will be local to that package while you work on it. Let's assume this is in a separate repo (otherwise the subtree thing is moot) - You'll work on a working copy of that package installed instead of the core package that ships with release Racket (using `raco pkg` to set up the links) - Assuming the last two points, you are unlikely to use any subtree commands until the changes need to be merged for a release or for wider use/testing. * You are a power user of Racket: - You'll just clone the whole Racket git repo and automatically get all of the subtrees. No additional effort necessary unless you want to make changes. * You are a developer responsible for the release: - You will probably end up pulling all subtrees (which is pretty manual work) and then cherry-pick all relevant commits. In comparison, I think submodules are supposed to make it less convenient for the power user who is just cloning the repo. That said, this isn't informed by a lot of experience with either feature, so please take with a salt mine. Maybe I will try this with Typed Racket somewhere and see what happens. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-31 00:04:20 -0400, Asumu Takikawa wrote: Maybe I will try this with Typed Racket somewhere and see what happens. One downside I discovered immediately after trying to set this up: the subtree command is only available in git 1.7.11 and newer and it's only available if the contrib tools are packaged in your git install (it's not in Debian). I tried using the subtree command to split out the main Typed Racket package into a separate repo. The result is here: https://github.com/takikawa/typed-racket-lib One issue is that the new repo only has history going back until the package split. This makes sense, given that the old paths are nonsense in the new repo. Maybe this is ok if the main Racket repo still has the history though. Unfortunately, this experiment didn't work very well. Doing a `git subtree pull` with just one simple new commit caused a spurious merge conflict, due to the fact that the new repo's SHA1s are different. Splitting out the package will require more clever git hackery. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] chaperone-evt restrictions?
Hi all, I'm currently trying to implement contracts for synchronizable events. During that, I've discovered that there seems to be an undocumented restriction that `chaperone-evt` can only chaperone an event that is not a handle event. Here's an example: - (sync (chaperone-evt (handle-evt always-evt identity) (lambda (e) (values e identity ; wrap-evt: contract violation ; expected: (and/c evt? (not/c handle-evt?)) ; given: #evt ; [,bt for context] This is problematic for Typed Racket. If the type system does not distinguish handle events vs. not (as is the case now), there's no way to refuse to generate a contract for the `handle-evt` case (which is necessary if the contract can't work). Also, is there supposed to be an `impersonate-evt` as well? I've noticed that the C code has a few code paths that hint at such a primitive, but it doesn't exist. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] chaperone-evt restrictions?
On 2013-08-02 18:32:38 -0400, Asumu Takikawa wrote: I'm currently trying to implement contracts for synchronizable events. During that, I've discovered that there seems to be an undocumented restriction that `chaperone-evt` can only chaperone an event that is not a handle event. Here's an example: I just realized this was supposed to be worded as a question, but I forgot to include the question: is this a fundamental limitation that I should work around in the type/contract system or can it be changed? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] struct:name exports from 2htdp/image, mrlib/image-core, etc.
Hi all, A few teaching libraries like `2htdp/image` provide struct constructors and accessors, but don't export the struct type descriptor values. Does anyone mind if I add the exports to libraries like `2htdp/image`, `mrlib/image-core`, etc.? (it's needed for Typed Racket with require/typed) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27263: master branch updated
On 2013-08-08 10:01:41 -0700, Eric Dobson wrote: Was this addition intentional? No, thanks for catching it. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Updating dependency packages from other sources
Hi all, I have a question about updating packages. I'll use an example development scenario to frame the question. Suppose I have package `aosd` installed that depends on `x11`: Installation-wide: Package ChecksumSource x11 0fc7555f6bc8f09601a75f9d88f44bfa3c4ff632(catalog x11) aosd 7ab51262a256a324b062d7b407cb5341d1f41f69(catalog aosd) Now suppose I want to work on the `x11` package since I need to upgrade it for some aspect of the `aosd` package. Right now it's installed from the package server, but I want to switch it to a linked package from the filesystem for development. If I try to remove just the `x11` package so I can replace it, I get this error: $ raco pkg remove x11 raco pkg remove: cannot remove packages that are dependencies of other packages dependencies: x11 (required by: (aosd)) which is reasonable. But I have to remove the package before I can install it from a different source. The `raco pkg update` command looks like it might help, but it doesn't let you update from a different source AFAICT. The `raco pkg install` command won't work because it'd be a conflicting package. What are the right steps to install over dependency packages? I don't think manually uninstalling and re-installing is a good solution. If n other packages depended on `x11` too, it seems like I'd have to re-install all n of them. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Updating dependency packages from other sources
On 2013-08-15 08:19:06 -0600, Jay McCarthy wrote: As for what we could do going forward, I think either of these approaches could be 'automated'. Yes, that'd be great. For instance, we could add a command like $ raco pkg replace x11 new-x11-source This would behave like either of those (which would be invisible to the user). Do you have any opinions about how you'd want to do this replacement? Maybe `raco pkg install` can have an additional flag that lets you replace existing packages? Or maybe it should allow conflicts if the package has the same name as an already installed package (possibly prompting/warning the user)? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Updating dependency packages from other sources
On 2013-08-16 14:27:41 -0600, Matthew Flatt wrote: How about allowing a package source as an argument to `raco pkg update`? After all, removing an old package implementation and installing a new one is already the job of `raco pkg update`, not `raco pkg install`. I like this idea better than what I suggested earlier. I have in mind that `raco pkg update` would treat as package name as it does now, instead of like other package sources. That is, it would update based on how the package was previously installed. Right now updates from the local filesystem (say in --copy mode) aren't tracked. Is the idea to change that so that `raco pkg update foo` will copy a new version of the package from the filesystem? (assuming it was installed that way to begin with) Similarly with URL installs, etc. If so, that sounds great too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27395: master branch updated
On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote: I worry about mutable sets here, but I can't think of any bugs it can cause ATM. I don't have any segfault-causing bugs, but here's a violation of the blame theorem: #lang racket (module a0 racket (define s (mutable-set 1 2 3)) (provide s)) (module a typed/racket (require/typed (submod .. a0) [s Any]) (: x (Setof Any)) (define x (assert s generic-set?)) (provide x)) (require 'a) x Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27511: master branch updated
On 2013-09-16 16:17:33 -0400, as...@racket-lang.org wrote: +@defmodule[math #:no-declare #:link-target? #f] +@defmodule[plot/typed #:no-declare #:link-target? #f] These two lines cause `raco setup` to complain with a warning about undeclared dependencies. It seems silly, though, to have the TR doc package force a dependency on `math`. Can I quelch the warning somehow? (like a I don't really care if the dependency is missing flag) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27511: master branch updated
On 2013-09-17 06:15:42 -0600, Matthew Flatt wrote: Yes, please treat missing package dependencies the same as any other build error. Mistakes will happen, but they should be corrected as soon as possible, even if it requires a stop-gap solution. Whoops, sorry for breaking the snapshots. I thought undeclared dependencies were warnings and not errors. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] raco pkg dependency checks and exit code
Hi all, I noticed that if you don't specify any dependencies for a package, then `raco` will warn you about that. However, the exit code is 0 and it's not an error. Comparatively, if you supply a dependencies field of `empty`, then you will get a bunch of errors about undeclared dependencies and the exit code is 1. Is there a reason why these two cases are treated differently? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco pkg dependency checks and exit code
On 2013-10-03 06:45:12 -0600, Jay McCarthy wrote: In the first case, you are forgetting to do it and we warn to tell you what you should put. In the second case, you put them in but are wrong and should be CAUGHT and PUNISHED. I think that's the logic behind it. That seems fair, but then in the first case, should `raco setup` tell you which dependencies are missing? It currently just says there are none (but not which are missing). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLT Package Catalog changes
On 2013-10-11 16:42:35 -0600, Jay McCarthy wrote: I've tested the JS code with most major browsers on Linux and I believe I use all standard things (jquery, etc) that are cross-browser, but please inform me of any problems you find. I can't seem to login on the new site. I don't get an error, but there is no response after clicking Log In. This is using Firefox 24. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `collection-path' Considered Brittle
On 2013-11-04 11:49:44 -0600, Robby Findler wrote: collection-path is legacy and should generally be removed when you find it (I think I fixed two uses of it Saturday in fact). But hopefully you could use collection-file-path in most cases instead of a collections-path function. There are still some cases where you may want a `collection-paths` function instead though. For example, it would be useful for `raco-find-collection` so that when a user asks for `typed-racket`, it can pick a better default than the alphabetic ordering. (right now you have to ask for `typed-racket/core` to disambiguate, which corresponds to using `collection-file-path`) For my purposes, I could just copy+paste the code in the compiler-lib, but maybe it should be moved into the core? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27802: master branch updated
On 2013-11-19 15:22:52 -0500, j...@racket-lang.org wrote: 80ba30e Jay McCarthy j...@racket-lang.org 2013-11-19 13:22 : | Fix PR14175 : M .../compiler-lib/compiler/commands/test.rkt | 21 +++- Thanks! I'm not sure it totally fixed the issue though. This looks better: - (require (submod compiler/commands/test paths)) - (collection-paths racket/gui) '(#path:/home/asumu/plt/racket-git/racket/collects/racket/gui) But shouldn't these return results? - (collection-paths typed) '() - (collection-paths plot) '() - (collection-paths math) '() Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system status
On 2013-11-20 14:10:05 -0500, Neil Van Dyke wrote: * The documentation for the package system in 5.3.6 does not seem to reflect previous discussion, and the chapter title still says (Beta). The 5.3.6 docs are by now fairly out of date. Your best bet is to look at the pre-release docs here: http://www.cs.utah.edu/plt/snapshots/current/doc/pkg/index.html The new first section gives a more helpful overview too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Check syntax + phase levels
Hi all, Would it be easy to supplement the current background syntax checking to display the phase level of an identifier use or definition? I was imagining it could draw the phase number next to the arrow. I'd be willing to try to implement it myself if it's feasible and someone points me in the right direction. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Should `dynamic-require`d libraries be in package dependencies?
Hi all, Should dynamically required libraries induce a package dependency? Take for example the xrepl-lib package. It currently depends on five other packages, but I think two of them can be dropped and `raco setup` won't complain. On the other hand, XREPL may `dynamic-require` the macro stepper (one of the dependencies that can be dropped). The same is true for DrRacket (not listed as a dependency), but it doesn't make much sense to make the XREPL package depend on DrRacket. Is there a best practice for these kinds of cases yet? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28054: master branch updated
On 2014-01-13 16:40:17 -0500, Eli Barzilay wrote: Why not (string-trim s #:left? #f) ? Only because I didn't know it existed. Thanks! Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Strange definition of dict-count in docs and tests
Hi Gustavo, On 2014-01-17 19:25:21 -0200, Gustavo Massaccesi wrote: The documentation about gen:dict http://docs.racket-lang.org/reference/dicts.html#%28def._%28%28lib._racket%2Fdict..rkt%29._gen~3adict%29%29 says that dict-count accepts one argument. But then it is defined with a #:default argument: Thanks for the report! I agree, it looks like a mistake. I'll push a fix later. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket v5.92
On 2014-01-25 12:55:43 -0500, Ryan Culpepper wrote: Racket 5.92 has a new package system, including a catalog of hundreds of already-available packages. Please visit I noticed that the src tarball of v5.92 has a different directory structure compared to previous releases. Namely, everything is under a `racket` directory rather than `racket-5.92`. Is that intentional? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Bug report lost? Here it is again: Issue with help
On 2014-01-26 11:45:43 -0500, Greg Hendershott wrote: But I didn't get a confirmation email. And I don't see it using advanced query arrival-date 2014-01-24 00:00 GMT. Is that this bug report by any chance? http://bugs.racket-lang.org/query/?cmd=viewpr=14313 Odd that you didn't get a notification though. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket v5.92
On 2014-01-25 12:55:43 -0500, Ryan Culpepper wrote: * Racket's HTML documentation has a new and improved look, thanks to Matthew Butterick. BTW, the 5.92 docs are missing some of the recent CSS changes from HEAD. Could we cherry-pick some of those for 6.0? For example, the blue boxes don't work here: http://docs.racket-lang.org/inside/Evaluation.html compare to: http://www.cs.utah.edu/plt/snapshots/current/doc/inside/Evaluation.html Also, could we cherry-pick a few documentation commits made recently? For example, this one: https://github.com/plt/racket/commit/d202f415d95ff04e295be101db59402489dc9bfa Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Testing for Racket v6.0
On 2014-02-14 15:55:59 -0500, Ryan Culpepper wrote: If you are interested in helping, please reply to this message to the mailing list and include the configuration(s) you are willing to test. I can test the following configurations: - Unix build from source, in-place install - Unix build from source, minimal, in-place install - Windows 64-bit Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 2014-02-20 20:31:56 -0700, Neil Toronto wrote: How close is this to being able to support, say, the plot library converted to TR? The OO stuff in it is a few custom classes without anything complicated, a couple of snip% descendants, and drawing onto device contexts. Should be very close. Not quite there currently because there are two more chunks that I've written and haven't pushed yet: * Implicit (mutual) recursive type aliases, so that a `define-type` can define mutually recursive type alises like the types for `bitmap%` and `bitmap-dc%`. * Types for everything in racket/gui and a few other libraries. Types for the framework are still work-in-progress. * Full contract support. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 2014-02-20 23:03:22 -0500, Asumu Takikawa wrote: Should be very close. Not quite there currently because there are two more chunks that I've written and haven't pushed yet: * Implicit (mutual) recursive type aliases, so that a `define-type` can define mutually recursive type alises like the types for `bitmap%` and `bitmap-dc%`. * Types for everything in racket/gui and a few other libraries. Types for the framework are still work-in-progress. * Full contract support. Apparently I should learn how to count though. :p Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On 2014-02-20 21:25:59 -0700, Neil Toronto wrote: You mean something like this would work? (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X))) (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X Yes, that should work. Here's an example interaction from my development branch: Welcome to Racket v5.90.0.10. - (let () (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X))) (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X (define: x : (Leaf1 Integer) (cons 3 (cons (cons 5 5) (cons 6 5 x) - : (Leaf1 Integer) '(3 (5 . 5) 6 . 5) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28450: master branch updated
On 2014-03-31 20:01:07 -0700, Eric Dobson wrote: Do we have a performance test case which shows improvment with this change? No, it turns out I misdiagnosed the issue and there was no performance bug. See commit 8a93eeb52bd7c98c5a060ca019bdc8f4c5a0b09c for the actual fix. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] class100 removal
Hi all, A few releases ago we announced our intention to remove the mzlib/class100 library from Racket. I think this was scheduled to happen around either last release or this upcoming release. Should I go ahead and remove mzlib/class100 and its docs? Its uses in the codebase should be long gone (I removed the last remaining uses a while back). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] class100 removal
On 2014-04-14 15:42:18 -0500, Robby Findler wrote: Lets have a full cycles without it in the git tree before the release, but otherwise, I think so yes. Okay, then I'll remove it after v6.0.1 is released. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
On 2014-04-15 18:13:31 -0400, claire alvis wrote: The push below includes changes to letrec expressions, internal definitions, units, classes, and certain ill-formed shared expressions so that they no longer leak the `undefined' value. This is great! (especially happy that TR, even with classes, doesn't have to worry about #undefined anymore) BTW, I found this weird behavior: Welcome to Racket v6.0.1.3. - (require racket/unsafe/ops) - (let () (+ x 3) (define x 3) 5) ; x: variable used before its definition [,bt for context] - (let () (unsafe-fx+ x 3) (define x 3) 5) 5 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
On 2014-04-15 21:19:16 -0600, Neil Toronto wrote: Does TR not having to worry about #undefined mean that the following program will typecheck? #lang typed/racket (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A (let () (define: lazy-zeros : (Lazy-Listof Zero) (delay (cons 0 lazy-zeros))) lazy-zeros) Yes, that should be the case. Here's an interaction from my pull request branch for removing undefined handling in TR: Welcome to Racket v6.0.1.3. - (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A - (let () (define: lazy-zeros : (Lazy-Listof Zero) (delay (cons 0 lazy-zeros))) lazy-zeros) - : (Lazy-Listof Zero) #promise:lazy-zeros That's assuming there aren't any design problems with that PR that come up in code review. BTW, I was happy to see that the type `Lazy-Listof' could be defined like that when coming up with the example. :D Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Regular expression types [was Re: [racket-bug] all/14455: wrong type for hash]
On 2014-04-20 14:38:50 -0400, Matthias Felleisen wrote: This might be one of those areas where we could 'generalize' gradual typing. I think we could do it without fundamentally changing anything about gradual typing. The issue is that uniform rest args assume that the type is always a `(Listof Foo)`. We could instead allow users to write down any type for the whole rest args list (classes take this approach for `init-rest`). While it's not a fundamental change, it's also not easy. It would also complicate the system and add more type syntax for a pretty modest benefit. (more important for classes which have weird initialization patterns) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.0.1
On 2014-05-01 13:49:55 -0400, Ryan Culpepper wrote: asumu: * Types in Typed Racket are now pretty-printed. * Function types can now be written in prefix style, which is now preferred and is used for printing. Infix function types are still accepted for backwards compatibility. * A new `-*' type constructor is used for writing types for functions with optional and keyword arguments. The notation is similar to the matching contract combinator. - TR :-less syntax (e6e3ab4e, 45d36579, 37b09521, etc) * Typed Racket forms do not have a `:' suffix by default now. For example, the `struct' form replaces `struct:'. The suffixed versions are all provided for backwards compatibility. - explain/warn about Class types? * Typed Racket now has preliminary support for classes and objects. However, it is still experimental and the APIs are subject to change. - TR recursive type aliases (a8cc430d) * Type aliases in Typed Racket now support recursion and mutual recursion. For example, `(define-type (MyList X) (U Null (Pair X (MyList X' is now a valid type alias. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Preserving trailing zeros in formatting numbers as strings
On 2014-04-24 05:25:07 -0400, Kathi Fisler wrote: I'm generating class notes in HTML via scribble. I'm trying to include the number 10.50 (as a price in an test case, so the trailing 0 matters). I'm using format to produce the strings that go into the rendered html. When I do this (whether with ~a or ~s), the trailing 0 is dropped, producing 10.5 in my output instead of 10.50. Maybe this is too late to be useful (I think the mailing list ate your post?), but here's one way to do it: (~r 10.5 #:precision '(= 2)) 10.50 Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28689: master branch updated
On 2014-05-07 00:27:34 -0400, as...@racket-lang.org wrote: f638247 Asumu Takikawa as...@racket-lang.org 2014-04-28 17:17 : | Add docs for TR's filter syntax : M .../scribblings/reference/types.scrbl | 69 +++- Since there's now documentation for the TR filter syntax, we should make sure before (add1 v6.0.1) that we're ok with what's there. Then we can also add support for printing the full filters when an option is enabled. In particular, some of the documented syntax is currently broken (and thus nobody could have used it), so it's a good opportunity to change it if we want. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
On 2014-06-09 00:19:40 -0700, Eric Dobson wrote: One issue I see is that we need an unforgeable property that the value actually came from the typed world so we know that eliding the new contract is safe. Does this seem like a reasonable thing to support/do people see issues with it? A potentially useful generalization of this that's not just for TR is to avoid duplicate complex check ons values (no types involved), making complicated contracts more feasible. Imagine a contract that parses a string to see if it is a valid IP address, for example. Would this only work for higher-order/behavioral values/types though? (i.e., not my IP example) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 2htdp/image Feature Suggestion
On 2014-06-22 20:27:21 -0700, Kevin Forchione wrote: Thanks! Is there any documentation or guide on which *styles* to prefer in writing Racket code? I find myself scratching my head at times in these matters! In recent Racket distributions and online docs there's now a style manual: http://docs.racket-lang.org/style/index.html Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28936: master branch updated
On 2014-06-26 07:30:40 -0400, Sam Tobin-Hochstadt wrote: Can we make this error message a little more informative? People find this confusing. Sure, did you have something in mind? Something like this? Type Checker: cannot apply a function with no known arities; Function `f` had type Procedure which cannot be applied Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] FOOL 2014 Call for Papers
Call For Papers 21th International Workshop on Foundations of Object-Oriented Languages (FOOL 2014) A Workshop of SPLASH (OOPSLA) 2014 Portland, Oregon, United States. http://homepages.ecs.vuw.ac.nz/~servetto/Fool2014/ Important dates: - August 15, 2014 Abstract submission - August 23, 2014 Full paper submission - September 26, 2014 Notification - October 10, 2014 Paper due for informal proceedings - October 20-24, 2014 Workshop (the day is still to be decided) The search for sound principles for object-oriented languages has given rise to much work during the past two decades, leading to a better understanding of the key concepts of object-oriented languages and to important developments in type theory, semantics, program verification, and program development. Submissions for this event are invited in the general area of foundations of object-oriented languages. Topics of interest include language semantics, type systems, type modifiers, memory models, program verification, object capabilities, formal calculi, concurrent and distributed languages, database languages, and language-based security issues. Papers are welcome to include formal descriptions and proofs, but these are not required; the key consideration is that papers should present novel and valuable ideas or experiences. The main focus in selecting workshop contributions will be the intrinsic interest and timeliness of the work, so authors are encouraged to submit polished descriptions of work in progress as well as papers describing completed projects. We solicit submissions on original research not previously published or currently submitted for publication elsewhere. The program chair should be informed of any related submissions; see the ACM SIGPLAN Republication Policy. Submissions should be PDF in standard SIGPLAN 10pt conference format for a US-letter size page. While submissions can be up to 12 pages, shorter papers describing promising preliminary work are also encouraged. Papers must be submitted electronically via EasyChair. ***NEW: Future of Object-Oriented Foundations session at FOOL 2014*** Over the past 20 years, research presented at FOOL has lead to a more solid understanding of the foundations of today's object-oriented programming languages. At the same time, new object-oriented languages and concepts are constantly being proposed, and there remain core topics that have not yet been fully explored. This year at FOOL 2014, we will hold a special session on the Future of Object-Oriented Foundations (FOOF). For this session, we solicit short papers as well as brief position statements regarding future research in object-oriented foundations: - A short paper will have the same format as regular submissions to FOOL, and will be reviewed in a similar way, but will be limited to 4 pages. - A position statement includes a title, authors, and 2-3 paragraphs of text summarizing the position. These will be lightly evaluated to ensure the position is of interest to the community. Authors of short papers will be given short presentation slots to present them in the FOOF session. One author of each position statement will be invited to participate in an panel related to the position statement's topic. Possible topics include, but are not limited to: brands, tags, and pattern matching; module systems and modularity; protocols, typestate, and sessions; ownership, permissions, and immutability; concurrent and distributed object models; OO logics and reasoning; and gradual/hybrid types and verification. An informal proceedings will be made publicly available on the web page. However, presentation at FOOL does not count as prior publication, and many of the results presented at FOOL have later been published at ECOOP, OOPSLA, POPL, and other main conferences. Program Committee Ferruccio Damiani (University of Turin) Sophia Drossopoulou (Imperial College London) Truong Anh Hoang (Vietnam National University Hanoi) Hidehiko Masuhara (Tokyo Institute of Technology) Rosemary Monahan (National University of Ireland, Maynooth) Alex Potanin (Victoria University of Wellington) Sukyoung Ryu (Korea Advanced Institute of Science and Technology) Marco Servetto (Victoria University of Wellington) Asumu Takikawa (Northeastern University) Thomas Wies (New York Univeristy) Tobias Wrigstad (Uppsala University) Elena Zucca (University of Genova) -- Organizers Marco Servetto (PC Chair) (Victoria University of Wellington) James Noble (Victoria University of Wellington) Jonathan Aldrich (Carnegie Mellon University ) - Steering Committee Jeremy Siek (Indiana University Bloomington) John Boyland (University of Wisconsin-Milwaukee) Atsushi Igarashi (Kyoto University) Shriram Krishnamurthi (Brown University) James Noble (Victoria University
[racket-dev] flatten-begin
Hi all, I was wondering what people think about a potential API addition to the `syntax/flatten-begin` library. Something like `flatten-begin*` (or a less terrible name) that would recursively flatten `begin` expressions like the `flatten` function does for plain lists. i.e., (flatten-begin* #'(begin (begin 1 2) 3 4)) = (list #'1 #'2 #'3 #'4) as opposed to (flatten-begin #'(begin (begin 1 2) 3 4)) = (list #'(begin 1 2) #'3 #'4) Would that be useful? I keep finding myself writing functions like this. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] flatten-begin
On 2014-07-17 22:17:18 -0500, Robby Findler wrote: Why doesn't flatten-begin already do this? I'm not sure. I was hoping someone else could tell me. :) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] flatten-begin
On 2014-07-18 09:52:26 -0500, Robby Findler wrote: Unless someone knows why it is a bad idea, how about adding a #:all? argument that flattens all the way down? I don't see many uses of flatten-begin in our tree, but the one in compatibility/package sure looks like it could use the #:all? argument. Ditto the one in TR (in class-prims.rkt). And I'm pretty sure that replacing the hand-rolled loops in drracket for doing this (they predate that library) would use the #:all? argument if they were rewritten. This sounds like a nice solution and it would be fine for my use-case too. Anyone have any reasons against? (otherwise I can make the change) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] flatten-begin
On 2014-07-19 23:12:51 -0400, Asumu Takikawa wrote: This sounds like a nice solution and it would be fine for my use-case too. Anyone have any reasons against? (otherwise I can make the change) I just realized that `flatten-begin` actually doesn't care if the form starts with a `begin`. In other words, the following evalutes like this: (flatten-begin #'(a 1 2)) = (list #'2 #'3) In which case the behavior of #:all? becomes a bit weird since it would care about the head being a `begin` (otherwise it would collapse too manay things). Maybe the recursive flattener should be a different function after all? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1
On 2014-07-21 16:14:27 -0400, Vincent St-Amour wrote: Sam, Asumu, Eric: what's new for this release? This came up on IRC the other day. I think Eric was saying the main changes were inference speedups, support for contracted functions, and better keyword support. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Problem with Values type constructor
On 2014-07-23 20:20:56 +0100, Antonio Menezes Leitao wrote: Although the typed racket documentation mentions Values as a type constructor, it does not work: [...] Am I missing something? Nope, this is just a bug. Thanks for the report. I've pushed a fix to git. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1
On 2014-07-28 14:33:07 -0400, Ryan Culpepper wrote: asumu: - removed mzlib/class100 (5711e900) - classes and TR (various) I don't have anything in particular for classes. For TR, we should add Stephen's contribution of async-channel support: * Typed Racket now supports asynchronous channels using the `typed/racket/async-channel' library. I also added a new syntax for asymmetric filters. Is that worth including? (and the filter syntax is now documented) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1
On 2014-08-01 13:54:15 -0400, Asumu Takikawa wrote: On 2014-07-28 14:33:07 -0400, Ryan Culpepper wrote: asumu: - removed mzlib/class100 (5711e900) Whoops, sorry, we should actually put in a blurb about class100 though. * As noted in the v5.3.2 release, the `mzlib/class100` library is deprecated. The library has now been removed from the distribution. Use `racket/class` instead. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] SGC as default
On 2014-08-12 05:16:21 +0100, Matthew Flatt wrote: If you have an existing build in a repo checkout, then `make` is likely to fail, because the makefile dependencies are not precise enough to deal with the switch. You can discard your old build directory, or it might work to simply delete builddir/racket/libmzgc.a The build didn't work for me in an existing checkout, so I tried making a fresh one and still got this failure: make xsrc/precomp.h make[7]: Entering directory '/home/asumu/plt/racket-fresh/racket/src/build/racket/gc2' env XFORM_PRECOMP=yes ../racketcgc -G /home/asumu/plt/racket-fresh/build/config -cqu ../../../racket/gc2/xform.rkt --setup . --cpp gcc -E -I./.. -I../../../racket/gc2/../include -pthread -DUSE_SENORA_GC --keep-lines -o xsrc/precomp.h ../../../racket/gc2/precomp.c Segmentation fault Makefile:202: recipe for target 'xsrc/precomp.h' failed make[7]: *** [xsrc/precomp.h] Error 139 Anything I should try to debug this? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
