From matthias at ccs.neu.edu Wed Apr 1 10:51:31 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 1 10:52:39 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' Message-ID: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> Please read http://programmingpraxis.wordpress.com/2009/03/31/rail-fence-cipher/ and compare the Scheme code with the Haskell code. How can anyone in his sound mind prefer Scheme over Haskell after reading this post? So let's refine this statement. Here are my comments: 1. The first impression of this Haskell style is a throw back to Backus's "variable free" programming. It's almost all combinators, difficult to read and comprehend. 2. The second look suggests that it is more readable than the old Backus experience would suggest. And if you don't have FL experiences or don't even know what this is, the concise mix of combinators and variables makes this look nice. 3. Once you understand 'waves' > waves :: Int -> String -> [Int] > waves n = map snd . sort . zip (cycle $ [1..n] ++ [n-1,n-2..2]) . > zipWith const [0..] you see that the poster has chosen a "Fortran" design. Instead of traversing the list in an up and down motion, the 'waves' function plays "indexing games." That is a turn-off. 4. The next thing you get out of 'waves' is that it is the only use of laziness in the whole program. It zips and zaps over "infinite" lists but the finite string, eh, list of chars, delimits the use of laziness. Neat. 5. The final insight that I took away from this code inspection is that strings as list of chars is a neat idea because you almost always want to traverse the string in some sequential order. Of course, once you discover that for/xyz treats strings as sequences, you're fine in PLT Scheme. ;; --- I have posted a response that demonstrates how point 5 can be reversed for a language like PLT Scheme. (Oh and thanks for allowing 'append' as a constructor in shared.) So here we go: > (define (fence s n) > (define is (shared ((x (append (range 1 n) (range (- n 1) 2) x))) > x)) > (define wv (for/list ((c s)) (begin0 (list c (car is)) (set! is > (cdr is))))) > (map first (sort2 wv))) These four lines demonstrate how a locally delimited use of mutation achieves the same purpose. FEATURE REQUEST: could for just treat something like is as a sequence? I have seen this trick I just used time and again over my Scheme career and we shouldn't have to expose the set! statement at all. (BTW, I don't think I can use the built-ins to turn this cyclic form of data into a 'sequence'.) -- Matthias From eli at barzilay.org Wed Apr 1 11:22:55 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Apr 1 11:23:15 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> Message-ID: <18899.34511.843428.614036@winooski.ccs.neu.edu> On Apr 1, Matthias Felleisen wrote: > > > (define (fence s n) > > (define is > > (shared ((x (append (range 1 n) (range (- n 1) 2) x))) x)) > > (define wv > > (for/list ((c s)) (begin0 (list c (car is)) (set! is (cdr is))))) > > (map first (sort2 wv))) > > > These four lines demonstrate how a locally delimited use of mutation > achieves the same purpose. > > FEATURE REQUEST: could for just treat something like is as a > sequence? I have seen this trick I just used time and again over my > Scheme career and we shouldn't have to expose the set! statement at > all. It could -- but you're using the generic form of the sequence, so it's trying to guess what you want to iterate over. This works: (define wv (for/list ([c s] [i (in-list is)]) (list c i))) > (BTW, I don't think I can use the built-ins to turn this cyclic form > of data into a 'sequence'.) ...but I think that the real need here is for more sequence combinators. In my Swindle iterator macros, I had this iteration specification: (x <- something <- something-else) which would iterate over the first thing and then over the second one. It works even with another sequence that is broken differently: => (list-of (list x y) (x <- 1 .. 4 <- 3 .. 1 and y <- '(x x) <- 1 ..)) ((1 x) (2 x) (3 1) (4 2) (3 3) (2 4) (1 5)) Given that `for' uses a new kind of sequene values, it would be nice to have some way to concatenate them (for/list ([x (seq+ (range 1 4) (range 3 1))]) x) and if the parts of the `seq+' expressions are lazy, you'd be able to do iterate with: (define waves (seq+ (range 1 n) (range (- n 1) 2) waves)) (define wv (for/list ([c s] [i waves]) (list c i))) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Wed Apr 1 11:40:49 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 1 11:41:52 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <18899.34511.843428.614036@winooski.ccs.neu.edu> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <18899.34511.843428.614036@winooski.ccs.neu.edu> Message-ID: <916BEC47-E9C7-4840-94A6-A71EEE4996E3@ccs.neu.edu> On Apr 1, 2009, at 11:22 AM, Eli Barzilay wrote: > It could -- but you're using the generic form of the sequence, so it's > trying to guess what you want to iterate over. This works: > > (define wv (for/list ([c s] [i (in-list is)]) (list c i))) Oops thank you. That saved a line! And a surface set! ;; --- I am still impressed by Haskell's notational economy. From david.vanderson at gmail.com Wed Apr 1 22:39:14 2009 From: david.vanderson at gmail.com (David Vanderson) Date: Wed Apr 1 22:39:39 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> Message-ID: <49D42552.8020303@gmail.com> Matthias Felleisen wrote: >> (define (fence s n) >> (define is (shared ((x (append (range 1 n) (range (- n 1) 2) x))) x)) >> (define wv (for/list ((c s)) (begin0 (list c (car is)) (set! is (cdr >> is))))) >> (map first (sort2 wv))) I very much enjoyed trying my hand at this problem and then figuring out how this function works. But I couldn't find "range" or "sort2" in the PLT docs. Are those functions that seasoned schemers are assumed to know about and have on hand? Thanks, Dave From matthias at ccs.neu.edu Wed Apr 1 23:01:58 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 1 23:03:04 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <49D42552.8020303@gmail.com> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> Message-ID: (define (range lo hi) (if (>= hi lo) (build-list (+ (- hi lo) 1) (lambda (i) (+ lo i))) (build-list (+ (- lo hi) 1) (lambda (i) (- lo i))))) (define (sort2 l) (sort l (lambda (i j) (< (second i) (second j))))) -- Matthias On Apr 1, 2009, at 10:39 PM, David Vanderson wrote: > > Matthias Felleisen wrote: >>> (define (fence s n) >>> (define is (shared ((x (append (range 1 n) (range (- n 1) 2) >>> x))) x)) >>> (define wv (for/list ((c s)) (begin0 (list c (car is)) (set! is >>> (cdr is))))) >>> (map first (sort2 wv))) > > I very much enjoyed trying my hand at this problem and then > figuring out how this function works. But I couldn't find "range" > or "sort2" in the PLT docs. Are those functions that seasoned > schemers are assumed to know about and have on hand? > > Thanks, > Dave From jay.mccarthy at gmail.com Thu Apr 2 10:02:59 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu Apr 2 10:03:21 2009 Subject: [plt-dev] Are ZOs cross platform? Message-ID: I know they are not cross version, but will a zo compiled on OS X work on Linux? What if the OS X machine is PPC and linux is X86? Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From mflatt at cs.utah.edu Thu Apr 2 10:20:25 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Thu Apr 2 10:20:46 2009 Subject: [plt-dev] Are ZOs cross platform? In-Reply-To: References: Message-ID: <20090402142026.90469650115@mail-svr1.cs.utah.edu> At Thu, 2 Apr 2009 08:02:59 -0600, Jay McCarthy wrote: > I know they are not cross version, but will a zo compiled on OS X work > on Linux? Yes. > What if the OS X machine is PPC and linux is X86? No problem. In fact, the .zos included in all PLT Scheme distributions, independent of the platform, are built on an x86_64 Linux machine. From jay.mccarthy at gmail.com Thu Apr 2 10:27:25 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Thu Apr 2 10:27:46 2009 Subject: [plt-dev] Are ZOs cross platform? In-Reply-To: <20090402142026.90469650115@mail-svr1.cs.utah.edu> References: <20090402142026.90469650115@mail-svr1.cs.utah.edu> Message-ID: I love it when things just work. PLT Scheme is the best! Jay On Thu, Apr 2, 2009 at 8:20 AM, Matthew Flatt wrote: > At Thu, 2 Apr 2009 08:02:59 -0600, Jay McCarthy wrote: >> I know they are not cross version, but will a zo compiled on OS X work >> on Linux? > > Yes. > >> What if the OS X machine is PPC and linux is X86? > > No problem. > > In fact, the .zos included in all PLT Scheme distributions, independent > of the platform, are built on an x86_64 Linux machine. > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From pocmatos at gmail.com Thu Apr 2 10:48:10 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Thu Apr 2 10:48:46 2009 Subject: [plt-dev] Are ZOs cross platform? In-Reply-To: References: <20090402142026.90469650115@mail-svr1.cs.utah.edu> Message-ID: <11b141710904020748s47a03faj84e457cc5ba75246@mail.gmail.com> On Thu, Apr 2, 2009 at 2:27 PM, Jay McCarthy wrote: > I love it when things just work. PLT Scheme is the best! > +1 > Jay > > On Thu, Apr 2, 2009 at 8:20 AM, Matthew Flatt wrote: >> At Thu, 2 Apr 2009 08:02:59 -0600, Jay McCarthy wrote: >>> I know they are not cross version, but will a zo compiled on OS X work >>> on Linux? >> >> Yes. >> >>> What if the OS X machine is PPC and linux is X86? >> >> No problem. >> >> In fact, the .zos included in all PLT Scheme distributions, independent >> of the platform, are built on an x86_64 Linux machine. >> >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From eli at barzilay.org Thu Apr 2 12:05:49 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Apr 2 12:06:11 2009 Subject: [plt-dev] Are ZOs cross platform? In-Reply-To: <20090402142026.90469650115@mail-svr1.cs.utah.edu> References: <20090402142026.90469650115@mail-svr1.cs.utah.edu> Message-ID: <18900.57949.403931.878201@winooski.ccs.neu.edu> On Apr 2, Matthew Flatt wrote: > At Thu, 2 Apr 2009 08:02:59 -0600, Jay McCarthy wrote: > > I know they are not cross version, but will a zo compiled on OS X > > work on Linux? > > Yes. > > > What if the OS X machine is PPC and linux is X86? > > No problem. > > In fact, the .zos included in all PLT Scheme distributions, independent > of the platform, are built on an x86_64 Linux machine. But note that there is nothing that stands in the way of macros from expanding to platform-specific code -- and that will make the resulting zo files platform dependent. This is why things that depend on `system-type' are usually found in runtime code, not in macros. In the PLT tree there is currently one exception: the collects/sgl/compiled/gl-info_ss.zo file contains platform-specific information about opengl. And BTW, a good number of years ago (I don't remember when, but well before I came in) PLT was distributed as a single tree with different binaries for the different platforms. I continue to use that organization today -- I basically have a single tree that I use everywhere, even on Windows. (I have a script that I run after every release, which collects the installers, puts the binaries in place and patch them to find the collection tree in ../../collects.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Thu Apr 2 12:05:51 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Apr 2 12:07:02 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> Message-ID: <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> So Mr Fortran-Hakell has posted another combinator version of the code, and I approximated it in PLT. #| import Data.List import GHC.Exts main = do print $ rail 4 "PROGRAMMING PRAXIS" print . derail 4 $ rail 4 "PROGRAMMING PRAXIS" rail :: Int -> [a] -> [a] rail n = zipSort (cycle $ [1..n] ++ [n-1,n-2..2]) derail :: Ord a => Int -> [a] -> [a] derail n s = zipSort (rail n $ zipWith const [0..] s) s zipSort :: Ord a => [a] -> [b] -> [b] zipSort ks = map snd . sortWith fst . zip ks |# ;; String Nat -> String ;; encrypt according to fence shape (define (encrypt ls n) (list->string (wave ls n))) ;; String Nat -> String ;; decrypt according to fence shape (define (decrypt s n) (list->string (sort2 (wave (for/list ((i (in-naturals)) (c s)) i) n) (string- >list s)))) ;; [Listof X] Nat -> [Listof X] ;; create a wave from the list, depth n ;; [needed because in Scheme, string != (Listof Char)] (define (wave ls n) (sort2 (in-list (shared ((x (append (range 1 n) (range (- n 1) 2) x))) x)) ls)) ;; [Listof Nat] [Sequence Y] -> [Listof Y] ;; sort lst according to indicies in list inds (define (sort2 ks ls) (map second (sort (for/list ((k ks) (l ls)) (list k l)) < #:key first))) ;; ------------------------------------------------------------------------ ----- ;; Nat Nat -> [Listof Nat] (define (range lo hi) (if (>= hi lo) (build-list (+ (- hi lo) 1) (lambda (i) (+ lo i))) (build-list (+ (- lo hi) 1) (lambda (i) (- lo i))))) (check-expect (encrypt "diesisteinklartext" 6) "dkinleiasertittxse") (check-expect (decrypt "dkinleiasertittxse" 6) "diesisteinklartext") (check-expect (decrypt (encrypt "diesisteinklartext" 6) 6) "diesisteinklartext") (check-expect (wave "diesisteinklartext" 6) (string->list "dkinleiasertittxse")) (check-expect (sort2 '(1 3 2) '(a b c)) '(a c b)) (test) From samth at ccs.neu.edu Thu Apr 2 12:42:15 2009 From: samth at ccs.neu.edu (Sam TH) Date: Thu Apr 2 12:42:34 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> Message-ID: <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> Here's another PLT implementation: (define (rail n l) (zip-sort (for/list ([i (cycle (in-range 1 (add1 n)) (in-range (sub1 n) 1 -1))] [e l]) (cons i e)))) (define (derail n s) (zip-sort (map cons (rail n (for/list ([i (in-naturals)] [e s]) i)) s))) (define (zip-sort ks/vs) (map cdr (sort #:key car ks/vs <))) (apply string (rail 4 "PROGRAMMING PRAXIS")) (apply string (derail 4 (rail 4 "PROGRAMMING PRAXIS"))) Here's the implementation of `cycle' (which should probably be in the sequence library): (Also the interface for `make-do-sequence' is pretty hard to use.) (define (seq-append seq1 seq2) (define-values (s1? s1) (sequence-generate seq1)) (define-values (s2? s2) (sequence-generate seq2)) (make-do-sequence (lambda () (values (lambda (p) (if (s1?) (s1) (s2))) (lambda (p) #t) #t (lambda _ (or (s1?) (s2?))) (lambda _ #t) (lambda _ #t))))) (define (cycle seq . seqs) (define l (reverse (cons seq seqs))) (define-values (s? s) (sequence-generate (foldr seq-append (car l) (cdr l)))) (define cache null) (define head #f) (make-do-sequence (lambda () (values (lambda (p) (if p (mcar p) (let* ([v (s)] [pr (mcons v cache)]) (unless head (set! head pr)) (set! cache pr) v))) (lambda (p) (cond [(mpair? p) (mcdr p)] [(s?) #f] [else (set-mcdr! head cache) head])) #f (lambda _ #t) (lambda _ #t) (lambda _ #t))))) -- sam th samth@ccs.neu.edu From matthias at ccs.neu.edu Thu Apr 2 12:44:23 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Apr 2 12:45:28 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> Message-ID: <1DABB5A2-CF3B-44B1-9141-3FDF442CC86A@ccs.neu.edu> That's nearly the same I sent. On Apr 2, 2009, at 12:42 PM, Sam TH wrote: > Here's another PLT implementation: > > (define (rail n l) > (zip-sort (for/list ([i (cycle (in-range 1 (add1 n)) (in-range (sub1 > n) 1 -1))] [e l]) > (cons i e)))) > > (define (derail n s) > (zip-sort (map cons (rail n (for/list ([i (in-naturals)] [e s]) > i)) s))) > > (define (zip-sort ks/vs) > (map cdr (sort #:key car ks/vs <))) > > (apply string (rail 4 "PROGRAMMING PRAXIS")) > (apply string (derail 4 (rail 4 "PROGRAMMING PRAXIS"))) > > Here's the implementation of `cycle' (which should probably be in the > sequence library): > > (Also the interface for `make-do-sequence' is pretty hard to use.) > > (define (seq-append seq1 seq2) > (define-values (s1? s1) (sequence-generate seq1)) > (define-values (s2? s2) (sequence-generate seq2)) > (make-do-sequence (lambda () > (values (lambda (p) (if (s1?) (s1) (s2))) > (lambda (p) #t) > #t > (lambda _ (or (s1?) (s2?))) > (lambda _ #t) > (lambda _ #t))))) > > (define (cycle seq . seqs) > (define l (reverse (cons seq seqs))) > (define-values (s? s) (sequence-generate (foldr seq-append (car > l) (cdr l)))) > (define cache null) > (define head #f) > (make-do-sequence (lambda () > (values (lambda (p) (if p > (mcar p) > (let* ([v (s)] > [pr (mcons v > cache)]) > (unless head > (set! head pr)) > (set! cache pr) > v))) > (lambda (p) (cond [(mpair? p) (mcdr p)] > [(s?) #f] > [else > (set-mcdr! head > cache) > head])) > #f > (lambda _ #t) > (lambda _ #t) > (lambda _ #t))))) > > > -- > sam th > samth@ccs.neu.edu From eli at barzilay.org Thu Apr 2 20:48:23 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Apr 2 20:48:45 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> Message-ID: <18901.23767.769985.361302@winooski.ccs.neu.edu> On Apr 2, Sam TH wrote: > > Here's the implementation of `cycle' (which should probably be in the > sequence library): > [...] Below is a better implementation of `in-sequences' using a `append-sequences' helper. It's also implementing `in-cycle', which just uses the same `append-sequences' utility with a cyclic list of the inputs. (And BTW, it doesn't cache the items, which looks like a mistake to do.) After that I implemented an `in-lazy' macro, using `in-thunk' (with apologies for Ryan...) -- the cute thing is that you can then implement a cyclic iteration with: (for ([i (letrec ([seq (in-sequences (in-range 4) (in-lazy seq))]) seq)]) (printf "i = ~s\n" i)) or even: (for ([i (letrec ([seq (in-lazy (in-sequences (in-range 4) seq))]) seq)]) (printf "i = ~s\n" i)) But there's a problem with this -- AFAICT, there is no way for a sequence to just return a new sequence to iterate over, which would be a tail-call kind of transfer to the new sequence. So the `in-lazy' thing must create a sequence that forever wraps the input sequence. The result is a growing chain of sequence proxies. Maybe there's a nice way to extend the api so a sequence can stop and return a "continuation sequence", but looking at the code that change doesn't look easy. In any case, I don't think that there are any practical uses of an `in-lazy', so it looks to my like `in-sequences' and `in-cycle' are enough as an addtion. #lang scheme (define (append-sequences seqs) (define (seqs->m+g+r seqs) (and (pair? seqs) (let-values ([(more? get) (sequence-generate (car seqs))]) (list* more? get (cdr seqs))))) (make-do-sequence (lambda () ;; place is (cur-more? cur-get rest-seqs ...) or #f (values (lambda (m+g+r) ((cadr m+g+r))) (lambda (m+g+r) (let loop ([m+g+r m+g+r]) (if (and (pair? m+g+r) (not ((car m+g+r)))) (seqs->m+g+r (cddr m+g+r)) m+g+r))) (seqs->m+g+r seqs) (lambda (p) p) (lambda _ #t) (lambda _ #t))))) (define (in-sequences . seqs) (append-sequences seqs)) (define (in-cycle . seqs) (append-sequences (shared ([x (append seqs x)]) x))) (define (in-thunk sthunk) (make-do-sequence (lambda () (define-values [more? get] (sequence-generate (sthunk))) (values (lambda (_) (get)) void (void) (lambda (_) (more?)) (lambda _ #t) (lambda _ #t))))) (define-syntax-rule (in-lazy seq-expr) (in-thunk (lambda () seq-expr))) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From samth at ccs.neu.edu Thu Apr 2 21:12:40 2009 From: samth at ccs.neu.edu (Sam TH) Date: Thu Apr 2 21:12:59 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <18901.23767.769985.361302@winooski.ccs.neu.edu> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> <18901.23767.769985.361302@winooski.ccs.neu.edu> Message-ID: <63bb19ae0904021812v3dd25a07ue246830b3fe2e74a@mail.gmail.com> On Thu, Apr 2, 2009 at 8:48 PM, Eli Barzilay wrote: > On Apr ?2, Sam TH wrote: >> >> Here's the implementation of `cycle' (which should probably be in the >> sequence library): >> [...] > > Below is a better implementation of `in-sequences' using a > `append-sequences' helper. ?It's also implementing `in-cycle', which > just uses the same `append-sequences' utility with a cyclic list of > the inputs. ?(And BTW, it doesn't cache the items, which looks like a > mistake to do.) Thanks for the implementation. Caching the items is necessary if you want to work with a sequence of bytes from a port, for example (see `in-input-bytes-port'). > But there's a problem with this -- AFAICT, there is no way for a > sequence to just return a new sequence to iterate over, which would be > a tail-call kind of transfer to the new sequence. ?So the `in-lazy' > thing must create a sequence that forever wraps the input sequence. > The result is a growing chain of sequence proxies. ?Maybe there's a > nice way to extend the api so a sequence can stop and return a > "continuation sequence", but looking at the code that change doesn't > look easy. When I was writing my code, I also wanted that API addition. > ? ? ? ? ? ? ? (let loop ([m+g+r m+g+r]) > ? ? ? ? ? ? ? ? (if (and (pair? m+g+r) (not ((car m+g+r)))) > ? ? ? ? ? ? ? ? ? (seqs->m+g+r (cddr m+g+r)) > ? ? ? ? ? ? ? ? ? m+g+r))) The `loop' here is never used. -- sam th samth@ccs.neu.edu From samth at ccs.neu.edu Fri Apr 3 12:16:31 2009 From: samth at ccs.neu.edu (Sam TH) Date: Fri Apr 3 12:16:49 2009 Subject: [plt-dev] scribble styles Message-ID: <63bb19ae0904030916g1d6821d2r959ac687f1f39d6a@mail.gmail.com> Right now, it's possible to customize the latex environment associated with tables, itemizations, and blockquotes. But it's not possible to put arbitrary other scribble code inside a particular latex environment. For example, I'd like to write something like this: @make-paragraph[#:style "figure"]{ ... stuff goes here ... } But this will produce \figure{... stuff goes here ...} which is not the desired result. It's even worse if you want 'verbatim', which can't be abstracted into a LaTeX macro. It would be nice if there were a way to create a paragraph that was styled by an environment instead of a macro. -- sam th samth@ccs.neu.edu From matthias at ccs.neu.edu Sun Apr 5 15:27:32 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sun Apr 5 15:28:41 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: <63bb19ae0904021812v3dd25a07ue246830b3fe2e74a@mail.gmail.com> References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> <18901.23767.769985.361302@winooski.ccs.neu.edu> <63bb19ae0904021812v3dd25a07ue246830b3fe2e74a@mail.gmail.com> Message-ID: 1. Is this going into the code base? 2. Why is for on lazy things not practical? -- Matthias On Apr 2, 2009, at 9:12 PM, Sam TH wrote: > On Thu, Apr 2, 2009 at 8:48 PM, Eli Barzilay wrote: >> On Apr 2, Sam TH wrote: >>> >>> Here's the implementation of `cycle' (which should probably be in >>> the >>> sequence library): >>> [...] >> >> Below is a better implementation of `in-sequences' using a >> `append-sequences' helper. It's also implementing `in-cycle', which >> just uses the same `append-sequences' utility with a cyclic list of >> the inputs. (And BTW, it doesn't cache the items, which looks like a >> mistake to do.) > > Thanks for the implementation. > > Caching the items is necessary if you want to work with a sequence of > bytes from a port, for example (see `in-input-bytes-port'). > > >> But there's a problem with this -- AFAICT, there is no way for a >> sequence to just return a new sequence to iterate over, which >> would be >> a tail-call kind of transfer to the new sequence. So the `in-lazy' >> thing must create a sequence that forever wraps the input sequence. >> The result is a growing chain of sequence proxies. Maybe there's a >> nice way to extend the api so a sequence can stop and return a >> "continuation sequence", but looking at the code that change doesn't >> look easy. > > When I was writing my code, I also wanted that API addition. > >> (let loop ([m+g+r m+g+r]) >> (if (and (pair? m+g+r) (not ((car m+g+r)))) >> (seqs->m+g+r (cddr m+g+r)) >> m+g+r))) > > The `loop' here is never used. > > -- > sam th > samth@ccs.neu.edu From eli at barzilay.org Sun Apr 5 15:39:57 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Apr 5 15:40:17 2009 Subject: [plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for' In-Reply-To: References: <08F8F861-E006-40E2-BA43-EDE10557C662@ccs.neu.edu> <49D42552.8020303@gmail.com> <9AB69D78-FFE0-4ED1-B863-A2E4BA91D632@ccs.neu.edu> <63bb19ae0904020942n5d3eedafr440578047aa671b@mail.gmail.com> <18901.23767.769985.361302@winooski.ccs.neu.edu> <63bb19ae0904021812v3dd25a07ue246830b3fe2e74a@mail.gmail.com> Message-ID: <18905.2317.415265.323917@winooski.ccs.neu.edu> On Apr 5, Matthias Felleisen wrote: > > 1. Is this going into the code base? Already did, I'll send a message shortly. > 2. Why is for on lazy things not practical? There are two kinds of laziness that you can talk about: * Iterating over a lazy sequence like an infinite list. (for ([x (in-lazy-list (letrec ([l (lazy-append '(1 2 3) l)]) l))]) ...) * Having the sequence value itself be lazy. (for ([x (letrec ([seq (lazy-sequence-append (in-list '(1 2 3)) seq)]) seq)]) ...) The first kind seems to me useful, and would be easy to implement. The second is harder (it requires changing the `for' implementation for the reason I said earlier), and I don't see much practical use of that. (A `for' in a lazy language, should be lazy in both ways, of course.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dvanhorn at ccs.neu.edu Sun Apr 5 21:47:30 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sun Apr 5 21:47:55 2009 Subject: [plt-dev] Moving archive URLs Message-ID: <49D95F32.6030000@ccs.neu.edu> I just noticed that the plt-scheme list archive URLs have shifted! You can see the difference by looking at what is in the Google cache vs. what is at the actual link for the second item here: http://www.google.com/search?hl=en&q=embedded+images+image-snip%25+dvanhorn Is there anyway to undo this? If not, is there anyway to ensure the URLs don't shift in the future? I link to the archive frequently and now all those links are broken. Thanks, David From grettke at acm.org Sun Apr 5 21:58:35 2009 From: grettke at acm.org (Grant Rettke) Date: Sun Apr 5 21:58:57 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <49D95F32.6030000@ccs.neu.edu> References: <49D95F32.6030000@ccs.neu.edu> Message-ID: <756daca50904051858o71e5d030r52ff7dd9f98455f3@mail.gmail.com> You can link here instead: http://list.cs.brown.edu/pipermail/plt-scheme/ On Sun, Apr 5, 2009 at 8:47 PM, David Van Horn wrote: > I just noticed that the plt-scheme list archive URLs have shifted! > > You can see the difference by looking at what is in the Google cache vs. > what is at the actual link for the second item here: > > http://www.google.com/search?hl=en&q=embedded+images+image-snip%25+dvanhorn > > Is there anyway to undo this? ?If not, is there anyway to ensure the URLs > don't shift in the future? > > I link to the archive frequently and now all those links are broken. > > Thanks, > David > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- http://www.wisdomandwonder.com/ From eli at barzilay.org Sun Apr 5 22:07:59 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Apr 5 22:08:20 2009 Subject: [plt-dev] Some additions Message-ID: <18905.25599.521131.300926@winooski.ccs.neu.edu> I have added these things, which are available from scheme/base: * `hash-has-key?' -- a predicate to test if a key is present in a hash table. * `hash-ref!' -- similar to `hash-ref' where the failure argument is required, and if the key is not found then this failure argument determines the result but also stores it in the table. (This is the function version of the `with-hash' macro that I suggested.) * `in-sequences' -- a new construct for `for' loops, which concatenates sequences. * `in-cycle' -- similar to `in-sequences', but the sequences are repeated in an infinite loop. Note that unlike Sam's version this does not cache the values -- it looks to me like a dangerous implicit behavior when you can achieve it explicitly by collecting the list first explicitly. For example, to cycle a file's contents you can read it first with `file->bytes'. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Sun Apr 5 22:16:22 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Apr 5 22:16:42 2009 Subject: [plt-dev] Statistical profiler & graph layout Message-ID: <18905.26102.878937.31902@winooski.ccs.neu.edu> As some people have noticed, I have committed a statistical profiler that is similar in style to profiles like gprof. This is not finished yet -- the plan is to have a GUI front end to conveniently visualize the call graph, and make that front end available as a DrScheme tool. I have most of the GUI done, but I'm stuck on getting a sane layout algorithm. I've tried to find information about the Sugiyama algorithm for graph layout, which is (IIUC) the basis for the layout that `dot' (from the graphviz suite) is doing -- but I'm stuck on some of the obscure details. In case anyone knows about graph layout algorithms, please contact me off-list. Alternatively, if someone has a copy of Graph Drawing: Algorithms for the Visualization of Graphs Tollis, Di Battista, Eades & Tamassia then please contact me too. (As much as I looked, this looks like it might have a usable description of the algorithm.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From dvanhorn at ccs.neu.edu Sun Apr 5 22:56:34 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Sun Apr 5 22:57:04 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <756daca50904051858o71e5d030r52ff7dd9f98455f3@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <756daca50904051858o71e5d030r52ff7dd9f98455f3@mail.gmail.com> Message-ID: <49D96F62.1040008@ccs.neu.edu> Grant Rettke wrote: > You can link here instead: http://list.cs.brown.edu/pipermail/plt-scheme/ I think you've misunderstood, Grant. What used to be at http://list.cs.brown.edu/pipermail/plt-scheme/2008-October/027808.html has changed. Until the next time Google sweeps over list.cs.brown.edu, you can see the difference by visiting what is at that URL now, versus what is cached here: http://74.125.93.104/search?q=cache:JCbohWdurYYJ:list.cs.brown.edu/pipermail/plt-scheme/2008-October/027808.html A link to the top-level archive page not help. David > On Sun, Apr 5, 2009 at 8:47 PM, David Van Horn wrote: >> I just noticed that the plt-scheme list archive URLs have shifted! >> >> You can see the difference by looking at what is in the Google cache vs. >> what is at the actual link for the second item here: >> >> http://www.google.com/search?hl=en&q=embedded+images+image-snip%25+dvanhorn >> >> Is there anyway to undo this? If not, is there anyway to ensure the URLs >> don't shift in the future? >> >> I link to the archive frequently and now all those links are broken. >> >> Thanks, >> David >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > > From grettke at acm.org Sun Apr 5 23:08:47 2009 From: grettke at acm.org (Grant Rettke) Date: Sun Apr 5 23:09:05 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <49D96F62.1040008@ccs.neu.edu> References: <49D95F32.6030000@ccs.neu.edu> <756daca50904051858o71e5d030r52ff7dd9f98455f3@mail.gmail.com> <49D96F62.1040008@ccs.neu.edu> Message-ID: <756daca50904052008h1180edd8yf40a92917ad03760@mail.gmail.com> On Sun, Apr 5, 2009 at 9:56 PM, David Van Horn wrote: > I think you've misunderstood, Grant. ?What used to be at I see. I have a lot of links that are affected. From carl.eastlund at gmail.com Sun Apr 5 23:23:48 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Sun Apr 5 23:24:07 2009 Subject: [plt-dev] Some additions In-Reply-To: <18905.25599.521131.300926@winooski.ccs.neu.edu> References: <18905.25599.521131.300926@winooski.ccs.neu.edu> Message-ID: <990e0c030904052023r6820803dwc03325ccd03359f1@mail.gmail.com> On Sun, Apr 5, 2009 at 10:07 PM, Eli Barzilay wrote: > > * `in-cycle' -- similar to `in-sequences', but the sequences are > ?repeated in an infinite loop. ?Note that unlike Sam's version this > ?does not cache the values -- it looks to me like a dangerous > ?implicit behavior when you can achieve it explicitly by collecting > ?the list first explicitly. ?For example, to cycle a file's contents > ?you can read it first with `file->bytes'. That greatly changes the behavior of in-cycle, Eli. First of all, it means every imperative sequence needs to come with a list- or vector-generating version to do manual caching. Secondly, it means imperative sequences have no way of doing on-demand in-cycle: the whole sequence will be read before processing the elements, instead of reading elements one at a time. Third, there will be no way to run in-cycle on potentially infinite imperative sequences, even though it would be nice to have the behavior of "process as long as there's something new, or loop if there's not". My vote is for caching in-cycle. --Carl From eli at barzilay.org Sun Apr 5 23:55:27 2009 From: eli at barzilay.org (Eli Barzilay) Date: Sun Apr 5 23:55:48 2009 Subject: [plt-dev] Some additions In-Reply-To: <990e0c030904052023r6820803dwc03325ccd03359f1@mail.gmail.com> References: <18905.25599.521131.300926@winooski.ccs.neu.edu> <990e0c030904052023r6820803dwc03325ccd03359f1@mail.gmail.com> Message-ID: <18905.32047.164044.354697@winooski.ccs.neu.edu> On Apr 5, Carl Eastlund wrote: > On Sun, Apr 5, 2009 at 10:07 PM, Eli Barzilay wrote: > > > > * `in-cycle' -- similar to `in-sequences', but the sequences are > > ?repeated in an infinite loop. ?Note that unlike Sam's version > > ?this does not cache the values -- it looks to me like a dangerous > > ?implicit behavior when you can achieve it explicitly by > > ?collecting the list first explicitly. ?For example, to cycle a > > ?file's contents you can read it first with `file->bytes'. > > That greatly changes the behavior of in-cycle, Eli. First of all, > it means every imperative sequence needs to come with a list- or > vector-generating version to do manual caching. You can get the caching behavior from the non-caching cycle in a straightforward way: (define-syntax-rule (in-caching-cycle seq ...) (in-cycle (in-list (for/list ([x (in-sequences seq ...)]) x)))) but you cannot get the non-caching cycle from the caching one. > Secondly, it means imperative sequences have no way of doing > on-demand in-cycle: the whole sequence will be read before > processing the elements, instead of reading elements one at a time. Right -- but is there any *practical* use case where you'd want that? That is, is there any case where some code is willing to potentially cache a large list but needs to do so as needed. The thing is that in contrast to this limitation there is the other side, which is a problem with the caching version: > Third, there will be no way to run in-cycle on potentially infinite > imperative sequences, even though it would be nice to have the > behavior of "process as long as there's something new, or loop if > there's not". if caching does happen, then you cannot use `in-cycle' on a potentially infinite imperative sequence too -- since that will accumulate the infinite list. (Right now, it *is* possible to do that.) The bottom line is that not caching seems like a much healthier default for two reasons: 1. It's the least surprising of the two options. 2. "Most" practical cases of needing to cycle over a sequence are cases where there is no need to get both caching behavior and a lazy by-need use of the cycled sequence. The "most" in the last item refers to use cases that I know about. If there are cases where it is needed (for *practical* reasons), then I'll add either a keyword or another binding for the caching version. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From clements at brinckerhoff.org Mon Apr 6 17:42:02 2009 From: clements at brinckerhoff.org (John Clements) Date: Mon Apr 6 17:42:55 2009 Subject: [plt-dev] bugfix for handin-server Message-ID: <2845B4D0-A789-41A9-841A-2D941D29F3D9@brinckerhoff.org> AFAICT, the handin-server is written with the assumption that (current- directory) returns a string. In particular, the 'run-servlet' function in web-status-server.ss calls string->path on server-dir, which may be obtained using (current-directory). Fortunately, it appears that the downstream uses of this value don't require it to be a string, so it appears that you can fix this problem simply by removing the call to string->path. Here's the diff: clements@li21-127:~/class/collects/handin-server$ svn diff web-status- server.ss Index: web-status-server.ss =================================================================== --- web-status-server.ss (revision 14438) +++ web-status-server.ss (working copy) @@ -251,14 +251,13 @@ (body ,msg "; " (a ([href "/"]) "restarting") " in 3 seconds."))) (define ((run-servlet port)) - (define dir (string->path server-dir)) (serve/servlet (lambda (request) (parameterize ([current-session (web-counter)]) (login-page (aget (request-bindings request) 'handin) #f))) #:port port #:listen-ip #f #:ssl? #t #:command-line? #t #:servlet-path "/" #:servlet-regexp #rx"" - #:server-root-path dir #:servlets-root dir + #:server-root-path server-dir #:servlets-root server-dir #:file-not-found-responder (send-error "File not found") #:servlet-namespace '(handin-server/private/md5 handin-server/private/logger I've committed this; naturally, I'll unwind it if I've made a mistake. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090406/4e076a58/smime.bin From eli at barzilay.org Mon Apr 6 19:17:50 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Apr 6 19:18:11 2009 Subject: [plt-dev] Re: bugfix for handin-server In-Reply-To: <2845B4D0-A789-41A9-841A-2D941D29F3D9@brinckerhoff.org> References: <2845B4D0-A789-41A9-841A-2D941D29F3D9@brinckerhoff.org> Message-ID: <18906.36254.17053.170879@winooski.ccs.neu.edu> On Apr 6, John Clements wrote: > AFAICT, the handin-server is written with the assumption that > (current- directory) returns a string. In particular, the > 'run-servlet' function in web-status-server.ss calls string->path on > server-dir, which may be obtained using (current-directory). > Fortunately, it appears that the downstream uses of this value don't > require it to be a string, so it appears that you can fix this > problem simply by removing the call to string->path. Here's the > diff: > [...] > > I've committed this; naturally, I'll unwind it if I've made a mistake. Yes, it looks like a correct fix... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Tue Apr 7 01:46:33 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Apr 7 01:46:54 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <49D95F32.6030000@ccs.neu.edu> References: <49D95F32.6030000@ccs.neu.edu> Message-ID: <18906.59577.268171.934232@winooski.ccs.neu.edu> On Apr 5, David Van Horn wrote: > I just noticed that the plt-scheme list archive URLs have shifted! > > You can see the difference by looking at what is in the Google cache > vs. what is at the actual link for the second item here: > > http://www.google.com/search?hl=en&q=embedded+images+image-snip%25+dvanhorn > > Is there anyway to undo this? If not, is there anyway to ensure the > URLs don't shift in the future? > > I link to the archive frequently and now all those links are broken. This turned out to be due to a reindexing that was needed to remove some messages -- and according to the brown sysadmins, mailman doesn't try to make old urls persist. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From samth at ccs.neu.edu Tue Apr 7 01:58:07 2009 From: samth at ccs.neu.edu (Sam TH) Date: Tue Apr 7 01:58:40 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <18906.59577.268171.934232@winooski.ccs.neu.edu> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> Message-ID: <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> On Tue, Apr 7, 2009 at 1:46 AM, Eli Barzilay wrote: > On Apr ?5, David Van Horn wrote: >> I just noticed that the plt-scheme list archive URLs have shifted! >> >> You can see the difference by looking at what is in the Google cache >> vs. what is at the actual link for the second item here: >> >> http://www.google.com/search?hl=en&q=embedded+images+image-snip%25+dvanhorn >> >> Is there anyway to undo this? ?If not, is there anyway to ensure the >> URLs don't shift in the future? >> >> I link to the archive frequently and now all those links are broken. > > This turned out to be due to a reindexing that was needed to remove > some messages -- and according to the brown sysadmins, mailman doesn't > try to make old urls persist. That's extremely unfortunate. We have many, many links to those URLs, including in mail messages themselves. Our entire history has become less useful. Is there any way to persuade the Brown admins to undo this change? -- sam th samth@ccs.neu.edu From eli at barzilay.org Tue Apr 7 02:00:51 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Apr 7 02:01:12 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> Message-ID: <18906.60435.661241.478868@winooski.ccs.neu.edu> On Apr 7, Sam TH wrote: > > That's extremely unfortunate. We have many, many links to those > URLs, including in mail messages themselves. Our entire history has > become less useful. I know. > Is there any way to persuade the Brown admins to undo this change? I don't think that it will be effective. If you want, then feel free to email me something and I'll proxy it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From stephen at degabrielle.name Tue Apr 7 04:28:43 2009 From: stephen at degabrielle.name (Stephen De Gabrielle) Date: Tue Apr 7 04:29:06 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> Message-ID: <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> ---------- Forwarded message ---------- From: Stephen De Gabrielle Date: Tue, 7 Apr 2009 08:51:54 +0100 Subject: Re: [plt-dev] Moving archive URLs To: Eli Barzilay Hi, If a rollback isn't possible, is it possible to get a snapshot of the pages before the change- that way old emails can be found by a simple change to their url. stephen On 4/7/09, Eli Barzilay wrote: > On Apr 7, Sam TH wrote: >> >> That's extremely unfortunate. We have many, many links to those >> URLs, including in mail messages themselves. Our entire history has >> become less useful. > > I know. > > >> Is there any way to persuade the Brown admins to undo this change? > > I don't think that it will be effective. If you want, then feel free > to email me something and I'll proxy it. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Sent from my mobile device Cheers, Stephen -- Stephen De Gabrielle s.degabrielle@cs.ucl.ac.uk Telephone +44 (0)20 7679 0693 (x30693) Mobile 079 851 890 45 Project: Making Sense of Information (MaSI) Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html Home:http://www.degabrielle.name/stephen UCL Interaction Centre MPEB 8th floor University College London Gower Street London WC1E 6BT -- Sent from my mobile device Cheers, Stephen -- Stephen De Gabrielle s.degabrielle@cs.ucl.ac.uk Telephone +44 (0)20 7679 0693 (x30693) Mobile 079 851 890 45 Project: Making Sense of Information (MaSI) Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html Home:http://www.degabrielle.name/stephen UCL Interaction Centre MPEB 8th floor University College London Gower Street London WC1E 6BT From sk at cs.brown.edu Tue Apr 7 07:13:23 2009 From: sk at cs.brown.edu (Shriram Krishnamurthi) Date: Tue Apr 7 07:15:29 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> Message-ID: I'll find out. I think you're failing to realize that it's not the fault of the Brown admins. It's the fault of mailman for not creating persistent URLs! From grettke at acm.org Tue Apr 7 09:53:29 2009 From: grettke at acm.org (Grant Rettke) Date: Tue Apr 7 09:53:48 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> Message-ID: <756daca50904070653i71e1db12o12e55e8c433bb8b4@mail.gmail.com> On Tue, Apr 7, 2009 at 3:28 AM, Stephen De Gabrielle wrote: > If a rollback isn't possible, is it possible to get a snapshot of the > pages before the change- that way old emails can be found by a simple > change to their url. Why doesn't the archive keep the same url and the reindexed server take a new url? From stephen at degabrielle.name Tue Apr 7 12:33:14 2009 From: stephen at degabrielle.name (Stephen De Gabrielle) Date: Tue Apr 7 12:33:37 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> Message-ID: <595b9ab20904070933n4a0e4621mc31e4c9320b27baa@mail.gmail.com> My apologies Shriram, I didn't wish to give the impression I was blaming anyone. (sysadmins always -unfairly- cop the blame when things go wrong) I must also apologise to Eli, as forwarding the message I mis-sent to him also gave the wrong impression. I was only suggesting an alternative to rollback(Sam TH), that might be workable. Welcome to the digital 'dark ages' . (unfortunately the wayback machine didn't spider the archive http://web.archive.org/web/20070819160400/http://list.cs.brown.edu/pipermail/plt-scheme/ ) Regards, Stephen On Tue, Apr 7, 2009 at 12:13 PM, Shriram Krishnamurthi wrote: > I'll find out. ?I think you're failing to realize that it's not the > fault of the Brown admins. ?It's the fault of mailman for not creating > persistent URLs! -- Cheers, Stephen -- Stephen De Gabrielle s.degabrielle@cs.ucl.ac.uk Telephone +44 (0)20 7679 0693 (x30693) Mobile 079 851 890 45 Project: Making Sense of Information (MaSI) Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html Home:http://www.degabrielle.name/stephen UCL Interaction Centre MPEB 8th floor University College London Gower Street London WC1E 6BT From stephen at degabrielle.name Tue Apr 7 12:38:14 2009 From: stephen at degabrielle.name (Stephen De Gabrielle) Date: Tue Apr 7 12:38:36 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <595b9ab20904070933n4a0e4621mc31e4c9320b27baa@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> <595b9ab20904070933n4a0e4621mc31e4c9320b27baa@mail.gmail.com> Message-ID: <595b9ab20904070938j1f371447m29689b1bacdb5044@mail.gmail.com> Good news; http://web.archive.org/web/*/http://list.cs.brown.edu/pipermail/plt-scheme/ it is archived up to June 2006 (which is better than nothing) Cheers, Stephen From mflatt at cs.utah.edu Tue Apr 7 12:50:15 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Apr 7 12:50:36 2009 Subject: [plt-dev] scribble styles In-Reply-To: <63bb19ae0904030916g1d6821d2r959ac687f1f39d6a@mail.gmail.com> References: <63bb19ae0904030916g1d6821d2r959ac687f1f39d6a@mail.gmail.com> Message-ID: <20090407165016.55A2D6500C6@mail-svr1.cs.utah.edu> At Fri, 3 Apr 2009 12:16:31 -0400, Sam TH wrote: > Right now, it's possible to customize the latex environment associated > with tables, itemizations, and blockquotes. But it's not possible to > put arbitrary other scribble code inside a particular latex > environment. For example, I'd like to write something like this: > > @make-paragraph[#:style "figure"]{ > ... stuff goes here ... > } > > But this will produce > > \figure{... stuff goes here ...} > > which is not the desired result. Use `blockquote' to install environments instead of macros. In particular, a figure can have multiple paragraphs inside it, so `blockquote' with style "figure" is really the right mapping. The choice of mapping paragraphs styles to Latex macros and blockquotes to environments may be arbitrary, but it seems to work well overall. Meanwhile, `blockquote' is really a poor name for a block that contains other blocks, but I never worked out the transition path to a better name (which may be as simple as providing both the new and old names). > It's even worse if you want 'verbatim', which can't be abstracted into > a LaTeX macro. Maybe I misunderstand, but trying to use "verbatim" as a style surely has many other problems, since the Scribble-to-Latex layer will encode plain text into Latex. From sk at cs.brown.edu Tue Apr 7 12:52:36 2009 From: sk at cs.brown.edu (Shriram Krishnamurthi) Date: Tue Apr 7 12:53:09 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: <595b9ab20904070933n4a0e4621mc31e4c9320b27baa@mail.gmail.com> References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> <595b9ab20904070933n4a0e4621mc31e4c9320b27baa@mail.gmail.com> Message-ID: Thanks. Our admins are looking at doing a rollback so that the old URLs will continue to work. Some patching may be necessary. We'll keep you updated. (Maybe a better list manager would just use SHA1 codes as the message indices, but that's not the world we have right now.) Shriram From mflatt at cs.utah.edu Tue Apr 7 13:12:59 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Apr 7 13:13:18 2009 Subject: [plt-dev] editor classes committed (v4.1.5.4) Message-ID: <20090407171259.99A5F650064@mail-svr1.cs.utah.edu> FYI, the Scheme-implemented editor classes are now committed in the SVN trunk. I recommend starting your next `configure' and `make' in a clean build directory. From mflatt at cs.utah.edu Tue Apr 7 13:32:22 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Tue Apr 7 13:32:41 2009 Subject: [plt-dev] on-demand phase instantiation (v4.1.5.4) Message-ID: <20090407173223.1C3196500AA@mail-svr1.cs.utah.edu> Prior to v4.1.5.4 (which is now the SVN trunk), then scheme -l program would not only execute the run-time code for `program', it would also run all the compile-time code, and the compile-compile-time code, and so on --- just in case you later evaluate an expression that requires macro expansion in the module's namespace. In v4.1.5.4, phases above 0 are evaluated on-demand when some expansion is initiated at the prior phase. In the above example, if `program' doesn't call functions like `eval', then code at phase 0 and higher will not run. Even if `program' calls `eval', if the evaluated expressions never include phase-1 code (such as the right-hand side of a `define-syntax' or `let-values'), then phase 2 is never run, and so on. For some programs, this change saves start-up time. For example, just mzscheme -l scheme or mzscheme -l scheme -e '(exit)' is about 40% faster than in v4.1.5. Previously, the above command-line had to start a tower of modules that was about 18 phases deep, while only 1-2 phases are now run. (The difference between the above examples is in whether phase 1 has to run to compile `(exit)'.) In principle, the savings from on-demand instantiation can be substantial. In practice, the savings are modest, such as twice-as-fast no-op examples as above, a 2-4% reduction in DrScheme's initial footprint, and slightly faster loading of Scribble documents like "reference.scrbl" that use many sandboxes for examples. None of these savings are big, because instantiating a module that is use `for-syntax' usually doesn't cost much, but the savings seem enough to be worthwhile. There's some risk on-demand lazy instantiation of phases will be confusing --- mostly if you try to use printouts to track what's going on. Again, this looks (so far) like a good trade-off for better performance. Most importantly, on-demand instantiation is at the phase granularity, not module granularity; there are no new ordering issues within a phase, and the intentional difficulty of sharing across a phase should minimize ordering effects across phases. From cce at ccs.neu.edu Wed Apr 8 11:04:19 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Wed Apr 8 11:04:38 2009 Subject: [plt-dev] Build error in r14464 Message-ID: <990e0c030904080804r3ce7fe31j38a44ebf72d1ab11@mail.gmail.com> I get the following error message from a clean build: gcc -g -O2 -Wall -DOS_X -D_DARWIN_UNLIMITED_SELECT -fno-common -I./.. -I../../../mzscheme/src/../include -c ../../../mzscheme/src/number.c -o number.o /var/folders/7w/7wGfCrmpHTi+1oWNeq9VVE+++TI/-Tmp-//cc06U9d0.s:804:Invalid mnemonic 'fldcw' -- Carl Eastlund From mflatt at cs.utah.edu Wed Apr 8 11:09:03 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Wed Apr 8 11:09:22 2009 Subject: [plt-dev] Build error in r14464 In-Reply-To: <990e0c030904080804r3ce7fe31j38a44ebf72d1ab11@mail.gmail.com> References: <990e0c030904080804r3ce7fe31j38a44ebf72d1ab11@mail.gmail.com> Message-ID: <20090408150904.75D186500A8@mail-svr1.cs.utah.edu> At Wed, 8 Apr 2009 11:04:19 -0400, Carl Eastlund wrote: > I get the following error message from a clean build: > > gcc -g -O2 -Wall -DOS_X -D_DARWIN_UNLIMITED_SELECT -fno-common > -I./.. -I../../../mzscheme/src/../include -c > ../../../mzscheme/src/number.c -o number.o > /var/folders/7w/7wGfCrmpHTi+1oWNeq9VVE+++TI/-Tmp-//cc06U9d0.s:804:Invalid > mnemonic 'fldcw' Misplaced CPP declaration now fixed. From jay.mccarthy at gmail.com Wed Apr 8 14:14:01 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Apr 8 14:14:23 2009 Subject: [plt-dev] Moving archive URLs In-Reply-To: References: <49D95F32.6030000@ccs.neu.edu> <18906.59577.268171.934232@winooski.ccs.neu.edu> <63bb19ae0904062258m5d407d52m43218f4e853473e5@mail.gmail.com> <18906.60435.661241.478868@winooski.ccs.neu.edu> <595b9ab20904070051t744494f2m1417a8500fa9fcc0@mail.gmail.com> <595b9ab20904070128l35c0e9bak47847e7e2f4a66b6@mail.gmail.com> <595b9ab20904070933n4a0e4621mc31e4c9320b27baa@mail.gmail.com> Message-ID: On Tue, Apr 7, 2009 at 10:52 AM, Shriram Krishnamurthi wrote: > (Maybe a better list manager would just use SHA1 codes as the message > indices, but that's not the world we have right now.) I'm pretty sure that's what google groups is doing. Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From matthias at ccs.neu.edu Sat Apr 11 12:17:59 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Sat Apr 11 12:19:17 2009 Subject: [plt-dev] Re: [plt-scheme] stepper interface suggestion for "start-from-here"? In-Reply-To: <9CFAF44D-C366-4ACB-959D-A508294D913A@brinckerhoff.org> References: <9CFAF44D-C366-4ACB-959D-A508294D913A@brinckerhoff.org> Message-ID: <53DB7536-3A8A-44EF-9401-D0E77888F9BB@ccs.neu.edu> Have you considered using the repl instead? Something like "start stepping with the expression that I enter at the REPL"? That would be absolutely ideal. On Apr 10, 2009, at 8:52 PM, John Clements wrote: > A few weeks ago Jay McCarthy suggested a feature for the stepper > that was so obvious that I had to implement it (also, I have a > sneaking suspicion that others must have suggested it): starting to > step at a specified expression, rather than from the beginning. As > I expected, it wasn't too hard, except for this one problem: how > should it be enabled? Here's what I've been able to come up with: > > 1) It's always enabled: the stepper starts from wherever the cursor > is (or the beginning of the selection) > 2) It's a menu entry in the "Scheme" Menu. > 3) Clicking on the stepper button always brings up a dialog. > 4) It's a preference. > 5) You right-click on a selected expression. > > Choices 1 & 3 seem too intrusive. Choices 2,4, and 5 seem not > intrusive enough (a.k.a. they'll never be discovered). Any other > suggestions? > > Thanks in advance, > > John > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-scheme From clements at brinckerhoff.org Mon Apr 13 19:02:12 2009 From: clements at brinckerhoff.org (John Clements) Date: Mon Apr 13 19:02:55 2009 Subject: [plt-dev] transient editor-related error message in stepper development Message-ID: I just saw this happen once; its transience (+ my knowledge that editors are under development) makes me want to believe that it's not a stepper bug. John send: no such method: do-scroll-to for class: canvas-editor-admin% === context === /Users/clements/plt/collects/scheme/private/class-internal.ss:3671:2: obj-error /Users/clements/plt/collects/mred/private/wxme/editor-canvas.ss: 1034:2: core /Users/clements/plt/collects/mred/private/wxme/text.ss:4654:2: redraw method in text% /Users/clements/plt/collects/mred/private/wxme/text.ss:691:2: end-edit- sequence method in text% /Users/clements/plt/collects/stepper/view-controller.ss:298:2: update- view/existing -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090413/b890b276/smime.bin From mflatt at cs.utah.edu Mon Apr 13 19:11:08 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Mon Apr 13 19:11:41 2009 Subject: [plt-dev] transient editor-related error message in stepper development In-Reply-To: References: Message-ID: <20090413231110.99DDA650091@mail-svr1.cs.utah.edu> Yes. Fixed in SVN. At Mon, 13 Apr 2009 16:02:12 -0700, John Clements wrote: > I just saw this happen once; its transience (+ my knowledge that > editors are under development) makes me want to believe that it's not > a stepper bug. > > John > > > > send: no such method: do-scroll-to for class: canvas-editor-admin% > > === context === > /Users/clements/plt/collects/scheme/private/class-internal.ss:3671:2: > obj-error > /Users/clements/plt/collects/mred/private/wxme/editor-canvas.ss: > 1034:2: core > /Users/clements/plt/collects/mred/private/wxme/text.ss:4654:2: redraw > method in text% > /Users/clements/plt/collects/mred/private/wxme/text.ss:691:2: end-edit- > sequence method in text% > /Users/clements/plt/collects/stepper/view-controller.ss:298:2: update- > view/existing > > > > ------------------------------------------------------------------------------ > [application/#f "smime.p7s"] [~/Desktop & open] [~/Temp & open] > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From clements at brinckerhoff.org Tue Apr 14 16:32:21 2009 From: clements at brinckerhoff.org (John Clements) Date: Tue Apr 14 16:32:54 2009 Subject: [plt-dev] scribble/comment-reader doc change? Message-ID: <778A7913-CF9F-4D0E-9A39-5AECABE99BF1@brinckerhoff.org> I struggled for a while with the new scribble/comment-reader form before discovering an important unstated constraint: it appears that the column-counting is off-by-one in the new reader's body. This means that putting code right up against the left edge results in errors, because the source position has a negative number in the column count. In particular, consider this example: #lang scribble/doc @(require scribble/manual) @#reader scribble/comment-reader (schemeblock ;; This is not a pipe (make-pipe) ) Evaluating this signals this error: Module Language: invalid module text datum->syntax: expects type as 3rd argument, given: #(# 6 -1 81 51); other arguments were: #f (# # # I suggest either changing this behavior or adding a paragraph such as this to the docs: Finally, note that the column indexes in the block governed by the new reader are considered relative to the # in the leading line, and therefore that placing text in the leftmost column of the editor will result in column indices of -1 (and lead to errors). No? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090414/38811abf/smime.bin From robby at eecs.northwestern.edu Tue Apr 14 16:35:59 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Tue Apr 14 16:36:22 2009 Subject: [plt-dev] scribble/comment-reader doc change? In-Reply-To: <778A7913-CF9F-4D0E-9A39-5AECABE99BF1@brinckerhoff.org> References: <778A7913-CF9F-4D0E-9A39-5AECABE99BF1@brinckerhoff.org> Message-ID: <932b2f1f0904141335r6c95da8xdd0a15d0ad0fd3ca@mail.gmail.com> The latter route should probably come with a syntax error, too. Robby On Tue, Apr 14, 2009 at 3:32 PM, John Clements wrote: > I struggled for a while with the new scribble/comment-reader form before > discovering an important unstated constraint: it appears that the > column-counting is off-by-one in the new reader's body. This means that > putting code right up against the left edge results in errors, because the > source position has a negative number in the column count. > > In particular, consider this example: > > #lang scribble/doc > > @(require scribble/manual) > > @#reader scribble/comment-reader > (schemeblock > ?;; This is not a pipe > ?(make-pipe) > ) > > Evaluating this signals this error: > > Module Language: invalid module text > datum->syntax: expects type > as 3rd argument, given: #(# 6 -1 81 51); other > arguments were: #f (# > # # > > > I suggest either changing this behavior or adding a paragraph such as this > to the docs: > > Finally, note that the column indexes in the block governed by the new > reader are considered relative to the # in the leading line, and therefore > that placing text in the leftmost column of the editor will result in column > indices of -1 (and lead to errors). > > No? > > John > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From matthias at ccs.neu.edu Wed Apr 15 09:03:09 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 15 09:06:34 2009 Subject: [plt-dev] #lang sicp Message-ID: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> We are looking for someone who is willing to create an SICP language for DrScheme, including a test suite, documentation, the hooks for making it a language level, etc. It's also possible that a pair may wish to share this kind of work. -- Matthias From geoff at knauth.org Wed Apr 15 13:54:58 2009 From: geoff at knauth.org (Geoffrey S. Knauth) Date: Wed Apr 15 14:03:47 2009 Subject: [plt-dev] #lang sicp In-Reply-To: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> References: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> Message-ID: <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> On Apr 15, 2009, at 09:03, Matthias Felleisen wrote: > We are looking for someone who is willing to create an SICP language > for DrScheme, including a test suite, documentation, the hooks for > making it a language level, etc. It's also possible that a pair may > wish to share this kind of work. I would be willing to be a helper, a doer of grunt work, if someone with greater PLT architecture experience were the leader. From neil at neilvandyke.org Wed Apr 15 16:35:04 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Wed Apr 15 16:35:47 2009 Subject: [plt-dev] #lang sicp In-Reply-To: <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> References: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> Message-ID: <49E644F8.6000605@neilvandyke.org> I just kludged up a language that provides R5RS and "error", and can be selected from a "SICP" entry in the DrScheme Languages list or by "#lang sicp". The bulk of it is a clone of "eopl-tool.ss". If Geoffrey or anyone wants to use this as a starting point, just let tell me where to email a tarball. I'd be happy to implement any Scheme dialect characteristics expected by SICP, if someone tells me what they are. Neil Geoffrey S. Knauth wrote at 04/15/2009 01:54 PM: > On Apr 15, 2009, at 09:03, Matthias Felleisen wrote: > >> We are looking for someone who is willing to create an SICP language >> for DrScheme, including a test suite, documentation, the hooks for >> making it a language level, etc. It's also possible that a pair may >> wish to share this kind of work. > > I would be willing to be a helper, a doer of grunt work, if someone > with greater PLT architecture experience were the leader. > -- http://www.neilvandyke.org/ From matthias at ccs.neu.edu Wed Apr 15 16:50:13 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 15 16:53:45 2009 Subject: [plt-dev] #lang sicp In-Reply-To: <49E644F8.6000605@neilvandyke.org> References: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> <49E644F8.6000605@neilvandyke.org> Message-ID: <85577972-5F12-486E-A9C9-F5485DBCB103@ccs.neu.edu> Sounds like a number of people are interested. Please coordinate and you're welcome to use the list to do so. As I wrote to someone else: >> >> You do NOT need to use drscheme at all -- initially -- to >> develop and use a language. >> > > Ah, excellent... i misunderstood your message to the list, and was > already thinking of the languages on DrScheme's language menu. > > >> >> Start with something as simple as >> >> myFirstLang.ss >> #lang scheme >> (provide lambda #%app) >> >> and use it >> >> #lang myFirstLang >> >> You will quickly see the limitation of this language, but >> it's a start. >> >> ;; --- >> >> Once we have the language, we can decide whether we want >> to hook it into the drscheme language menu or just supply >> it as a module language. >> > > Understood. Thanks for the hints. > -- Matthias On Apr 15, 2009, at 4:35 PM, Neil Van Dyke wrote: > I just kludged up a language that provides R5RS and "error", and > can be selected from a "SICP" entry in the DrScheme Languages list > or by "#lang sicp". The bulk of it is a clone of "eopl-tool.ss". > > If Geoffrey or anyone wants to use this as a starting point, just > let tell me where to email a tarball. > > I'd be happy to implement any Scheme dialect characteristics > expected by SICP, if someone tells me what they are. > > Neil > > Geoffrey S. Knauth wrote at 04/15/2009 01:54 PM: >> On Apr 15, 2009, at 09:03, Matthias Felleisen wrote: >> >>> We are looking for someone who is willing to create an SICP >>> language for DrScheme, including a test suite, documentation, the >>> hooks for making it a language level, etc. It's also possible >>> that a pair may wish to share this kind of work. >> >> I would be willing to be a helper, a doer of grunt work, if >> someone with greater PLT architecture experience were the leader. >> > > -- > http://www.neilvandyke.org/ From jao at gnu.org Wed Apr 15 17:28:24 2009 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Wed Apr 15 19:05:25 2009 Subject: [plt-dev] Re: #lang sicp References: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> <49E644F8.6000605@neilvandyke.org> <85577972-5F12-486E-A9C9-F5485DBCB103@ccs.neu.edu> Message-ID: <87tz4pli87.fsf@mithrandir.homeunix.net> hi, i'm the someone else below :) i offered Matthias to implement this; but, for some boring reasons, i wanted to do it all by myself, and only in case nobody else was up to the task. if you Neil and Geoffrey are willing to take the bait, i'll be very happy to let you have the fun and enjoy the results; moreover, i'm sure both of you know plt much better than me, and i already have a couple other projects in mind where i'd like to use plt. so please, go ahead! :) cheers, jao -- You err by thinking simplicity and elegance are mostly cosmetic. Simplicity and elegance are overwhelmingly practical virtues. - William D Clinger, comp.lang.scheme Matthias Felleisen writes: > Sounds like a number of people are interested. Please coordinate and > you're welcome to use the list to do so. As I wrote to someone else: > >>> >>> You do NOT need to use drscheme at all -- initially -- to >>> develop and use a language. >>> >> >> Ah, excellent... i misunderstood your message to the list, and was >> already thinking of the languages on DrScheme's language menu. >> >> >>> >>> Start with something as simple as >>> >>> myFirstLang.ss >>> #lang scheme >>> (provide lambda #%app) >>> >>> and use it >>> >>> #lang myFirstLang >>> >>> You will quickly see the limitation of this language, but >>> it's a start. >>> >>> ;; --- >>> >>> Once we have the language, we can decide whether we want >>> to hook it into the drscheme language menu or just supply >>> it as a module language. >>> >> >> Understood. Thanks for the hints. >> From neil at neilvandyke.org Wed Apr 15 19:59:14 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Wed Apr 15 19:59:52 2009 Subject: [plt-dev] #lang sicp In-Reply-To: <85577972-5F12-486E-A9C9-F5485DBCB103@ccs.neu.edu> References: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> <49E644F8.6000605@neilvandyke.org> <85577972-5F12-486E-A9C9-F5485DBCB103@ccs.neu.edu> Message-ID: <49E674D2.8030701@neilvandyke.org> This is a request for someone who wants to read through SICP to run with this project... I have added a few more MIT Scheme-isms to my code, and pulled in the "soegaard/sicp" PLaneT package to get at least part of the picture language. At this point, it could use someone who wants to work through SICP, to make sure everything that needs to be provided *is* provided, and that it would work smoothly for students. (I have tried to use Check Syntax on SICP "allcode.tar.gz" to find missing definitions, but searches of SICP when something is undefined are not always clear on who is supposed to define it.) Is anyone up for doing this (the hard part, after I've done the easy part)? Otherwise, I will ask on the "plt-scheme" list. If all else fails, I could ask Abelson&Sussman whether they want to sic a TA/RA/UROP on it. -- http://www.neilvandyke.org/ From geoff at knauth.org Wed Apr 15 20:54:14 2009 From: geoff at knauth.org (Geoffrey S. Knauth) Date: Wed Apr 15 20:54:36 2009 Subject: [plt-dev] #lang sicp In-Reply-To: <49E674D2.8030701@neilvandyke.org> References: <88F5F568-66B0-4951-85D7-93615B6DFC8E@ccs.neu.edu> <28A95F6F-B60B-49B9-9BED-E9C332EAA388@knauth.org> <49E644F8.6000605@neilvandyke.org> <85577972-5F12-486E-A9C9-F5485DBCB103@ccs.neu.edu> <49E674D2.8030701@neilvandyke.org> Message-ID: <85828D1A-7C4C-447B-8177-7FA6B077F6CC@knauth.org> I'd be happy to help with this. I gladly kneel before SICP. My semester is winding down. 7 more days of classes, 2 exams, then ( ahhhhh ... ) until 31 AUG. Well actually I'm working on a robotics thingie (DrScheme-MindstormsNXT), but working through SICP will help with that, as I have to get down and dirty with PLT anyway. I've been trying to evaluate just the highlighted expression (? la Smalltalk) and have it shoot over to the robot via bluetooth. Geoff On Apr 15, 2009, at 19:59, Neil Van Dyke wrote: > This is a request for someone who wants to read through SICP to run > with this project... > > I have added a few more MIT Scheme-isms to my code, and pulled in > the "soegaard/sicp" PLaneT package to get at least part of the > picture language. > > At this point, it could use someone who wants to work through SICP, > to make sure everything that needs to be provided *is* provided, and > that it would work smoothly for students. (I have tried to use > Check Syntax on SICP "allcode.tar.gz" to find missing definitions, > but searches of SICP when something is undefined are not always > clear on who is supposed to define it.) > > Is anyone up for doing this (the hard part, after I've done the easy > part)? Otherwise, I will ask on the "plt-scheme" list. If all else > fails, I could ask Abelson&Sussman whether they want to sic a TA/RA/ > UROP on it. > > -- > http://www.neilvandyke.org/ From jao at gnu.org Wed Apr 15 19:29:04 2009 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Wed Apr 15 21:08:33 2009 Subject: [plt-dev] drscheme window sizes Message-ID: <87hc0plcn3.fsf@mithrandir.homeunix.net> hi, i have this tiny netbook with a vertical window resolution of 600 pixels. i can open drscheme without problems (maximized, i'm using a tiling wm, xmonad): its content resizes alright. but when i open the preferences window, it gets cut from below instead of resizing (seems it wants to be taller than the available height), and i cannot access the ok/cancel buttons. is this a problem with my setup, a bug, something i can fix somehow? thanks! jao -- Genius may have its limitations, but stupidity is not thus handicapped. -Elbert Hubbard From robby at eecs.northwestern.edu Wed Apr 15 21:34:10 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 15 21:34:31 2009 Subject: [plt-dev] drscheme window sizes In-Reply-To: <87hc0plcn3.fsf@mithrandir.homeunix.net> References: <87hc0plcn3.fsf@mithrandir.homeunix.net> Message-ID: <932b2f1f0904151834s769cb36eu50f1c012e220fcd5@mail.gmail.com> There isn't anything you can easily do, I'm sorry to say (besides trying the keyboard, things like return or esc). Is there a way to get a WM that has a larger virtual space than the physical space? Or maybe setting a smaller font (temporarily?) The only thing to do at the drscheme level is to change the dialog so that it has fewer controls (or re-distribute them to take less vertical space). Robby On Wed, Apr 15, 2009 at 6:29 PM, Jose A. Ortega Ruiz wrote: > > hi, > > i have this tiny netbook with a vertical window resolution of 600 > pixels. i can open drscheme without problems (maximized, i'm using a > tiling wm, xmonad): its content resizes alright. but when i open the > preferences window, it gets cut from below instead of resizing (seems it > wants to be taller than the available height), and i cannot access the > ok/cancel buttons. is this a problem with my setup, a bug, something i > can fix somehow? > > thanks! > jao > -- > Genius may have its limitations, but stupidity is not thus handicapped. > ?-Elbert Hubbard > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From jao at gnu.org Thu Apr 16 03:03:00 2009 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Thu Apr 16 03:08:38 2009 Subject: [plt-dev] Re: drscheme window sizes References: <87hc0plcn3.fsf@mithrandir.homeunix.net> <932b2f1f0904151834s769cb36eu50f1c012e220fcd5@mail.gmail.com> Message-ID: <87d4bdkrmj.fsf@mithrandir.homeunix.net> Robby Findler writes: > There isn't anything you can easily do, I'm sorry to say (besides > trying the keyboard, things like return or esc). Is there a way to get > a WM that has a larger virtual space than the physical space? Or maybe > setting a smaller font (temporarily?) The virtual space size can be tweaked in the X11 configuration, yes (although it's a bit inconvenient). I already tried reducing the font size, but it was not enough. What i've finally done is configuring things in another machine and copying plt-prefs.ss to the netbook, manually editing it as needed. > The only thing to do at the drscheme level is to change the dialog so > that it has fewer controls (or re-distribute them to take less > vertical space). Given the raising popularity of netbooks with small vertical space available, perhaps it'd be a good thing (in a future release) to redistribute controls automatically if the situation is detected... just a thought (unfortunately, i know nearly nothing about Framework, so i'm talking out of my hat). Thanks for the quick response anyway! Cheers, jao -- We shall do a much better programming job, provided we approach the task with a full appreciation of its tremendous difficulty, provided that we respect the intrinsic limitations of the human mind and approach the task as very humble programmers. -Alan Turing From spdegabrielle at gmail.com Thu Apr 16 10:44:47 2009 From: spdegabrielle at gmail.com (Stephen De Gabrielle) Date: Thu Apr 16 10:45:08 2009 Subject: [plt-dev] Re: drscheme window sizes In-Reply-To: <87d4bdkrmj.fsf@mithrandir.homeunix.net> References: <87hc0plcn3.fsf@mithrandir.homeunix.net> <932b2f1f0904151834s769cb36eu50f1c012e220fcd5@mail.gmail.com> <87d4bdkrmj.fsf@mithrandir.homeunix.net> Message-ID: <595b9ab20904160744y29eabbb1q94d9ed50fef8610@mail.gmail.com> I have the same problem(early asus netbook), but I can't even see the preferences option in the file menu because it is too long - I'm assuming X11 is misleading DrScheme about the height of the screen. I normally get by using the tab button to jump between invisible fields, moving the window top above the screen and attempting a resize, and just editing the config file by hand. HTH, Stephen On Thu, Apr 16, 2009 at 8:03 AM, Jose A. Ortega Ruiz wrote: > > Robby Findler > writes: > >> There isn't anything you can easily do, I'm sorry to say (besides >> trying the keyboard, things like return or esc). Is there a way to get >> a WM that has a larger virtual space than the physical space? Or maybe >> setting a smaller font (temporarily?) > > The virtual space size can be tweaked in the X11 configuration, yes > (although it's a bit inconvenient). I already tried reducing the font > size, but it was not enough. What i've finally done is configuring things > in another machine and copying plt-prefs.ss to the netbook, manually > editing it as needed. > >> The only thing to do at the drscheme level is to change the dialog so >> that it has fewer controls (or re-distribute them to take less >> vertical space). > > Given the raising popularity of netbooks with small vertical space > available, perhaps it'd be a good thing (in a future release) to > redistribute controls automatically if the situation is detected... just > a thought (unfortunately, i know nearly nothing about Framework, so i'm > talking out of my hat). > > Thanks for the quick response anyway! > > Cheers, > jao > -- > We shall do a much better programming job, provided we approach the > task with a full appreciation of its tremendous difficulty, provided > that we respect the intrinsic limitations of the human mind and > approach the task as very humble programmers. -Alan Turing > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From matthias at ccs.neu.edu Thu Apr 16 12:11:15 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Apr 16 12:44:56 2009 Subject: [plt-dev] help Message-ID: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> Where do we stand with context-sensitive search in drscheme? I am in Beginner, I type 'image', and I get results on the first page that have almost nothing to do with the htdp/image library except for alpha-color-list->image, a concept that I am unlikely to even use in a typical 211. Another example concerns Module, and I am looking for 'keyword'. The first few entries don't look like what I want. So "Declaring Keyword Arguments" and "Keyword Arguments" look like the right thing. I open both and I start reading two strangely related but not quite the same doc pieces. What's going on? I can't see the margin note at the top of the page that mzlib/kw isn't compatible with the new stuff. I am recounting these stories from my perspective but they didn't happen to me. We need to improve this search somehow. -- Matthias P.S. I am so used to the kind of results I get and what I have to look for that I didn't even see the problem until someone else rubbed my nose in it. From robby at eecs.northwestern.edu Thu Apr 16 13:19:59 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 16 13:20:19 2009 Subject: [plt-dev] drscheme window sizes In-Reply-To: <87hc0plcn3.fsf@mithrandir.homeunix.net> References: <87hc0plcn3.fsf@mithrandir.homeunix.net> Message-ID: <932b2f1f0904161019y6250edd7u97bcc18186c90125@mail.gmail.com> I've checked in changes to drscheme that, when you disable the profj tool turn the preferences window from 730 pixels high to 544 pixels high on my mac os x machine. (It isn't the most semantically sensible change, in that I've moved some things from editing|general into just general (a new tab); things that weren't really about editing, but having catchall categories is never that great.) Kathy, if you have time to see if you can split up the colors in profj into multiple panels or maybe have a more space-efficient set of controls somehow, that would be great. In the meantime, for those that don't use profj, you can disable it in the preferences and get the shorter window. Of course, I realize that there is a kind of chicken & egg problem there, so if you get stuck, I can sort out the programmatic way to disable the profj tool. Robby On Wed, Apr 15, 2009 at 6:29 PM, Jose A. Ortega Ruiz wrote: > > hi, > > i have this tiny netbook with a vertical window resolution of 600 > pixels. i can open drscheme without problems (maximized, i'm using a > tiling wm, xmonad): its content resizes alright. but when i open the > preferences window, it gets cut from below instead of resizing (seems it > wants to be taller than the available height), and i cannot access the > ok/cancel buttons. is this a problem with my setup, a bug, something i > can fix somehow? > > thanks! > jao > -- > Genius may have its limitations, but stupidity is not thus handicapped. > ?-Elbert Hubbard > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From jao at gnu.org Thu Apr 16 15:15:47 2009 From: jao at gnu.org (Jose A. Ortega Ruiz) Date: Thu Apr 16 16:08:35 2009 Subject: [plt-dev] Re: drscheme window sizes References: <87hc0plcn3.fsf@mithrandir.homeunix.net> <932b2f1f0904161019y6250edd7u97bcc18186c90125@mail.gmail.com> Message-ID: <874owol89o.fsf@mithrandir.homeunix.net> Robby Findler writes: > I've checked in changes to drscheme that, when you disable the profj > tool turn the preferences window from 730 pixels high to 544 pixels > high on my mac os x machine. (It isn't the most semantically sensible > change, in that I've moved some things from editing|general into just > general (a new tab); things that weren't really about editing, but > having catchall categories is never that great.) Excellent! Thanks a lot, Robby. > Kathy, if you have time to see if you can split up the colors in profj > into multiple panels or maybe have a more space-efficient set of > controls somehow, that would be great. > > In the meantime, for those that don't use profj, you can disable it in > the preferences and get the shorter window. Of course, I realize that > there is a kind of chicken & egg problem there, so if you get stuck, I > can sort out the programmatic way to disable the profj tool. As a first approximation, i guess editting plt-prefs.ss to contain something like: (plt:framework-pref:drscheme:tools-configuration ( (((lib "profj") ("tool.ss")) skip) )) would do the job, right? Cheers, jao -- Children enter school as question marks and leave as periods. -Neil Postman, professor and author (1931- ) From robby at eecs.northwestern.edu Thu Apr 16 16:18:47 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 16 16:19:09 2009 Subject: [plt-dev] Re: drscheme window sizes In-Reply-To: <874owol89o.fsf@mithrandir.homeunix.net> References: <87hc0plcn3.fsf@mithrandir.homeunix.net> <932b2f1f0904161019y6250edd7u97bcc18186c90125@mail.gmail.com> <874owol89o.fsf@mithrandir.homeunix.net> Message-ID: <932b2f1f0904161318l4c69fb08vf89caa2dff3b060f@mail.gmail.com> Ah, yeah. I actually did this: (plt:framework-pref:drscheme:tools-configuration ((((lib "profjWizard") ("tool.ss")) skip) (((lib "profj") ("tool.ss")) skip))) but that might not be necessary. On Thu, Apr 16, 2009 at 2:15 PM, Jose A. Ortega Ruiz wrote: > Robby Findler > writes: > >> I've checked in changes to drscheme that, when you disable the profj >> tool turn the preferences window from 730 pixels high to 544 pixels >> high on my mac os x machine. (It isn't the most semantically sensible >> change, in that I've moved some things from editing|general into just >> general (a new tab); things that weren't really about editing, but >> having catchall categories is never that great.) > > Excellent! Thanks a lot, Robby. > >> Kathy, if you have time to see if you can split up the colors in profj >> into multiple panels or maybe have a more space-efficient set of >> controls somehow, that would be great. >> >> In the meantime, for those that don't use profj, you can disable it in >> the preferences and get the shorter window. Of course, I realize that >> there is a kind of chicken & egg problem there, so if you get stuck, I >> can sort out the programmatic way to disable the profj tool. > > As a first approximation, i guess editting plt-prefs.ss to contain > something like: > > ?(plt:framework-pref:drscheme:tools-configuration > ?( > ? (((lib "profj") ("tool.ss")) skip) > ?)) > > would do the job, right? > > Cheers, > jao > -- > Children enter school as question marks and leave as periods. > ?-Neil Postman, professor and author (1931- ) > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From spdegabrielle at gmail.com Thu Apr 16 19:33:51 2009 From: spdegabrielle at gmail.com (Stephen De Gabrielle) Date: Thu Apr 16 19:34:12 2009 Subject: [plt-dev] help In-Reply-To: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> Message-ID: <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> Partition the index, do testing on users. What do you want to do? Stephen On Thu, Apr 16, 2009 at 5:11 PM, Matthias Felleisen wrote: > > Where do we stand with context-sensitive search in drscheme? > > I am in Beginner, I type 'image', and I get results on the first page that > have almost nothing to do with the htdp/image library except for > alpha-color-list->image, a concept that I am unlikely to even use in a > typical 211. > > Another example concerns Module, and I am looking for 'keyword'. The first > few entries don't look like what I want. So "Declaring Keyword Arguments" > and "Keyword Arguments" look like the right thing. I open both and I start > reading two strangely related but not quite the same doc pieces. What's > going on? I can't see the margin note at the top of the page that mzlib/kw > isn't compatible with the new stuff. > > I am recounting these stories from my perspective but they didn't happen to > me. > > We need to improve this search somehow. -- Matthias > > P.S. I am so used to the kind of results I get and what I have to look for > that I didn't even see the problem until someone else rubbed my nose in > it._________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > -- Cheers, Stephen -- Stephen De Gabrielle s.degabrielle@cs.ucl.ac.uk Telephone +44 (0)20 7679 0693 (x30693) Mobile 079 851 890 45 Project: Making Sense of Information (MaSI) Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html Home:http://www.degabrielle.name/stephen UCL Interaction Centre MPEB 8th floor University College London Gower Street London WC1E 6BT From stephen at degabrielle.name Fri Apr 17 11:18:56 2009 From: stephen at degabrielle.name (Stephen De Gabrielle) Date: Fri Apr 17 11:19:18 2009 Subject: [plt-dev] help In-Reply-To: <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> Message-ID: <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> can search tell what language libraries are being used when called via f1? On 4/17/09, Stephen De Gabrielle wrote: > Partition the index, do testing on users. > > What do you want to do? > > Stephen > > On Thu, Apr 16, 2009 at 5:11 PM, Matthias Felleisen > wrote: >> >> Where do we stand with context-sensitive search in drscheme? >> >> I am in Beginner, I type 'image', and I get results on the first page >> that >> have almost nothing to do with the htdp/image library except for >> alpha-color-list->image, a concept that I am unlikely to even use in a >> typical 211. >> >> Another example concerns Module, and I am looking for 'keyword'. The >> first >> few entries don't look like what I want. So "Declaring Keyword Arguments" >> and "Keyword Arguments" look like the right thing. I open both and I >> start >> reading two strangely related but not quite the same doc pieces. What's >> going on? I can't see the margin note at the top of the page that >> mzlib/kw >> isn't compatible with the new stuff. >> >> I am recounting these stories from my perspective but they didn't happen >> to >> me. >> >> We need to improve this search somehow. -- Matthias >> >> P.S. I am so used to the kind of results I get and what I have to look >> for >> that I didn't even see the problem until someone else rubbed my nose in >> it._________________________________________________ >> ?For list-related administrative tasks: >> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > > > > -- > Cheers, > > Stephen > > -- > Stephen De Gabrielle > s.degabrielle@cs.ucl.ac.uk > Telephone +44 (0)20 7679 0693 (x30693) > Mobile 079 851 890 45 > Project: Making Sense of Information (MaSI) > Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html > Home:http://www.degabrielle.name/stephen > > > UCL Interaction Centre > MPEB 8th floor > University College London > Gower Street > London WC1E 6BT > -- Sent from my mobile device Cheers, Stephen -- Stephen De Gabrielle s.degabrielle@cs.ucl.ac.uk Telephone +44 (0)20 7679 0693 (x30693) Mobile 079 851 890 45 Project: Making Sense of Information (MaSI) Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html Home:http://www.degabrielle.name/stephen UCL Interaction Centre MPEB 8th floor University College London Gower Street London WC1E 6BT From matthias at ccs.neu.edu Fri Apr 17 13:34:48 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Apr 17 13:38:25 2009 Subject: [plt-dev] help In-Reply-To: <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> Message-ID: <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> Like bug reports, help is launched from within drscheme and can gather all this information. On Apr 17, 2009, at 11:18 AM, Stephen De Gabrielle wrote: > can search tell what language libraries are being used when called > via f1? > > On 4/17/09, Stephen De Gabrielle wrote: >> Partition the index, do testing on users. >> >> What do you want to do? >> >> Stephen >> >> On Thu, Apr 16, 2009 at 5:11 PM, Matthias Felleisen >> wrote: >>> >>> Where do we stand with context-sensitive search in drscheme? >>> >>> I am in Beginner, I type 'image', and I get results on the first >>> page >>> that >>> have almost nothing to do with the htdp/image library except for >>> alpha-color-list->image, a concept that I am unlikely to even use >>> in a >>> typical 211. >>> >>> Another example concerns Module, and I am looking for 'keyword'. The >>> first >>> few entries don't look like what I want. So "Declaring Keyword >>> Arguments" >>> and "Keyword Arguments" look like the right thing. I open both and I >>> start >>> reading two strangely related but not quite the same doc pieces. >>> What's >>> going on? I can't see the margin note at the top of the page that >>> mzlib/kw >>> isn't compatible with the new stuff. >>> >>> I am recounting these stories from my perspective but they didn't >>> happen >>> to >>> me. >>> >>> We need to improve this search somehow. -- Matthias >>> >>> P.S. I am so used to the kind of results I get and what I have to >>> look >>> for >>> that I didn't even see the problem until someone else rubbed my >>> nose in >>> it._________________________________________________ >>> For list-related administrative tasks: >>> http://list.cs.brown.edu/mailman/listinfo/plt-dev >>> >> >> >> >> -- >> Cheers, >> >> Stephen >> >> -- >> Stephen De Gabrielle >> s.degabrielle@cs.ucl.ac.uk >> Telephone +44 (0)20 7679 0693 (x30693) >> Mobile 079 851 890 45 >> Project: Making Sense of Information (MaSI) >> Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html >> Home:http://www.degabrielle.name/stephen >> >> >> UCL Interaction Centre >> MPEB 8th floor >> University College London >> Gower Street >> London WC1E 6BT >> > > -- > Sent from my mobile device > > Cheers, > > Stephen > > -- > Stephen De Gabrielle > s.degabrielle@cs.ucl.ac.uk > Telephone +44 (0)20 7679 0693 (x30693) > Mobile 079 851 890 45 > Project: Making Sense of Information (MaSI) > Work:http://www.uclic.ucl.ac.uk/annb/MaSI.html > Home:http://www.degabrielle.name/stephen > > > UCL Interaction Centre > MPEB 8th floor > University College London > Gower Street > London WC1E 6BT From eli at barzilay.org Fri Apr 17 13:45:13 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 13:45:38 2009 Subject: [plt-dev] help In-Reply-To: <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> Message-ID: <18920.49193.298074.442894@winooski.ccs.neu.edu> On Apr 17, Matthias Felleisen wrote: > > Like bug reports, help is launched from within drscheme and can > gather all this information. It can pass along information to the search page, and there is a facility to customize the result by setting a "search context" which pre-filters the results that you will see. The issues that need a solution are: 1. The kind of things that you can do with search quesries are limited, specifically, there is no way right now to write an `or' query. (IIRC, this was the main problem with the student languages.) 2. The interface for dealing with these context queries (showing the current context, clearing it, and editing it) is probably suboptimal. This is at least my own guess based on the fact that almost nobody is using it. Suggestions are welcome, and (working) patches are welcome even more. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Fri Apr 17 13:54:14 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Fri Apr 17 13:54:35 2009 Subject: [plt-dev] help In-Reply-To: <18920.49193.298074.442894@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> Message-ID: <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> I think we tried this (with the currently available search narrowing) and found we had people the were very confused about why they could not get teachpack docs. Perhaps instead of narrowing the search e could have a mode where any hit in a given manual would show up before any other results (maybe in another color too)? Robby On Friday, April 17, 2009, Eli Barzilay wrote: > On Apr 17, Matthias Felleisen wrote: >> >> Like bug reports, help is launched from within drscheme and can >> gather all this information. > > It can pass along information to the search page, and there is a > facility to customize the result by setting a "search context" which > pre-filters the results that you will see. ?The issues that need a > solution are: > > 1. The kind of things that you can do with search quesries are > ? limited, specifically, there is no way right now to write an `or' > ? query. ?(IIRC, this was the main problem with the student > ? languages.) > > 2. The interface for dealing with these context queries (showing the > ? current context, clearing it, and editing it) is probably > ? suboptimal. ?This is at least my own guess based on the fact that > ? almost nobody is using it. > > Suggestions are welcome, and (working) patches are welcome even more. > > -- > ? ? ? ? ?((lambda (x) (x x)) (lambda (x) (x x))) ? ? ? ? ?Eli Barzilay: > ? ? ? ? ? ? ? ? ?http://www.barzilay.org/ ? ? ? ? ? ? ? ? Maze is Life! > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > From eli at barzilay.org Fri Apr 17 13:56:47 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 13:57:09 2009 Subject: [plt-dev] help In-Reply-To: <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> Message-ID: <18920.49887.162908.449792@winooski.ccs.neu.edu> On Apr 17, Robby Findler wrote: > I think we tried this (with the currently available search > narrowing) and found we had people the were very confused about why > they could not get teachpack docs. > > Perhaps instead of narrowing the search e could have a mode where > any hit in a given manual would show up before any other results > (maybe in another color too)? Yes, that goes with the first bullet: it would be nice to find some query syntax that will make the results show in a different order. That's significantly more work though. (As for color -- that's more difficult, since it just renders the html that scribble produces -- no interfering with it.) > > 1. The kind of things that you can do with search quesries are > > ? limited, specifically, there is no way right now to write an `or' > > ? query. ?(IIRC, this was the main problem with the student > > ? languages.) > > > > 2. The interface for dealing with these context queries (showing the > > ? current context, clearing it, and editing it) is probably > > ? suboptimal. ?This is at least my own guess based on the fact that > > ? almost nobody is using it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Fri Apr 17 15:37:25 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Apr 17 15:40:56 2009 Subject: [plt-dev] help In-Reply-To: <18920.49887.162908.449792@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> Message-ID: <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> Well what we have now is way way way suboptimal as even experienced FPers (thought not Schemers) in our lab get tripped over this stuff. 1. I had forgotten that context narrowing exists. Other people don't seem to know either. 1a. I bet the interface is too clumsy, if people can't find what they want. 2. We need automatic context narrowing for teaching languages from HtDP (and its relatives). -- Matthias From eli at barzilay.org Fri Apr 17 15:46:03 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 15:46:26 2009 Subject: [plt-dev] help In-Reply-To: <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> Message-ID: <18920.56443.793590.802135@winooski.ccs.neu.edu> On Apr 17, Matthias Felleisen wrote: > > Well what we have now is way way way suboptimal as even experienced > FPers (thought not Schemers) in our lab get tripped over this stuff. > > 1. I had forgotten that context narrowing exists. Other people don't > seem to know either. > > 1a. I bet the interface is too clumsy, if people can't find what > they want. Like I said, suggestions are welcome. (That's the part that should be easier to fix.) I can't think of anything better. > 2. We need automatic context narrowing for teaching languages from > HtDP (and its relatives). That's doable (and as Robby reminded, we had it for a while), but to do it properly it requires a more powerful query syntax -- allowing `or' queries, or allowing changing the order of results. This part is harder to fix. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Fri Apr 17 15:45:02 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Apr 17 15:48:33 2009 Subject: [plt-dev] help In-Reply-To: <18920.56443.793590.802135@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> Message-ID: On Apr 17, 2009, at 3:46 PM, Eli Barzilay wrote: > On Apr 17, Matthias Felleisen wrote: >> >> Well what we have now is way way way suboptimal as even experienced >> FPers (thought not Schemers) in our lab get tripped over this stuff. >> >> 1. I had forgotten that context narrowing exists. Other people don't >> seem to know either. >> >> 1a. I bet the interface is too clumsy, if people can't find what >> they want. > > Like I said, suggestions are welcome. (That's the part that should be > easier to fix.) I can't think of anything better. > >> 2. We need automatic context narrowing for teaching languages from >> HtDP (and its relatives). > > That's doable (and as Robby reminded, we had it for a while), but to > do it properly it requires a more powerful query syntax -- allowing > `or' queries, or allowing changing the order of results. This part is > harder to fix For now, I am proposing that we order the query results by information from the context. Specifically, we display all information that are relevant according to the context on the first page. Everything else is displayed on page 2 and up. How's that? -- Matthias From eli at barzilay.org Fri Apr 17 15:54:41 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 15:55:03 2009 Subject: [plt-dev] help In-Reply-To: References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> Message-ID: <18920.56961.772409.988484@winooski.ccs.neu.edu> On Apr 17, Matthias Felleisen wrote: > > On Apr 17, 2009, at 3:46 PM, Eli Barzilay wrote: > > > On Apr 17, Matthias Felleisen wrote: > >> > >> Well what we have now is way way way suboptimal as even experienced > >> FPers (thought not Schemers) in our lab get tripped over this stuff. > >> > >> 1. I had forgotten that context narrowing exists. Other people don't > >> seem to know either. > >> > >> 1a. I bet the interface is too clumsy, if people can't find what > >> they want. > > > > Like I said, suggestions are welcome. (That's the part that should be > > easier to fix.) I can't think of anything better. > > > >> 2. We need automatic context narrowing for teaching languages from > >> HtDP (and its relatives). > > > > That's doable (and as Robby reminded, we had it for a while), but > > to do it properly it requires a more powerful query syntax -- > > allowing `or' queries, or allowing changing the order of results. > > This part is harder to fix > > For now, I am proposing that we order the query results by > information from the context. Specifically, we display all > information that are relevant according to the context on the first > page. Everything else is displayed on page 2 and up. > > How's that? -- Matthias That's exactly the hard part. It's even more than just the hard part, it combines both `or' queries, and reordering the results. (And in the meantime it doesn't address the problem of making the context query more usable.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Fri Apr 17 15:57:32 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Apr 17 16:01:15 2009 Subject: [plt-dev] help In-Reply-To: <18920.56961.772409.988484@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> Message-ID: <694BA7F8-0D9A-416D-9982-8D0FA0401CAE@ccs.neu.edu> Why don't you start with these guidelines: context = TL + tp(1) + ... + tp(n) The first page must contain only: (1) all query results that concern tp(i) (2) all results concerning TL (3) tp results appear BEFORE TL results [(4) we might also wish to order results so that those for tp(j) occur before tp(i) if j > i] All other results appear on pages 2 and up. I suspect you can scale these rules to #lang scheme/gui and friends. I just wish we had scheme/redex. -- Matthias On Apr 17, 2009, at 3:54 PM, Eli Barzilay wrote: > On Apr 17, Matthias Felleisen wrote: >> >> On Apr 17, 2009, at 3:46 PM, Eli Barzilay wrote: >> >>> On Apr 17, Matthias Felleisen wrote: >>>> >>>> Well what we have now is way way way suboptimal as even experienced >>>> FPers (thought not Schemers) in our lab get tripped over this >>>> stuff. >>>> >>>> 1. I had forgotten that context narrowing exists. Other people >>>> don't >>>> seem to know either. >>>> >>>> 1a. I bet the interface is too clumsy, if people can't find what >>>> they want. >>> >>> Like I said, suggestions are welcome. (That's the part that >>> should be >>> easier to fix.) I can't think of anything better. >>> >>>> 2. We need automatic context narrowing for teaching languages from >>>> HtDP (and its relatives). >>> >>> That's doable (and as Robby reminded, we had it for a while), but >>> to do it properly it requires a more powerful query syntax -- >>> allowing `or' queries, or allowing changing the order of results. >>> This part is harder to fix >> >> For now, I am proposing that we order the query results by >> information from the context. Specifically, we display all >> information that are relevant according to the context on the first >> page. Everything else is displayed on page 2 and up. >> >> How's that? -- Matthias > > That's exactly the hard part. It's even more than just the hard part, > it combines both `or' queries, and reordering the results. (And in > the meantime it doesn't address the problem of making the context > query more usable.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! From neil at neilvandyke.org Fri Apr 17 16:08:01 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Fri Apr 17 16:08:39 2009 Subject: [plt-dev] help In-Reply-To: <18920.56961.772409.988484@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> Message-ID: <49E8E1A1.5090300@neilvandyke.org> For the students, the help system knows what Language and Teachpacks are in use, possibly what modules are in use, and maybe even what HtDP assignment is being worked on. There are a few additional techniques that might improve relevance ranking and recall for this purpose: * TFIDF to focus on the most information-carrying terms. * Application-specific synonym dictionary that you could come up with yourself pretty easily. * General synonym dictionary, such as from WordNet. * Latent Semantic Indexing. Some presentation tweaks might help too. Perhaps a tabular listing, with sortable columns as a kind of interactive query refinement. Though that would be more for non-student developers who have a larger search space. Neil -- http://www.neilvandyke.org/ From eli at barzilay.org Fri Apr 17 16:13:50 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 16:14:12 2009 Subject: [plt-dev] help In-Reply-To: <694BA7F8-0D9A-416D-9982-8D0FA0401CAE@ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <694BA7F8-0D9A-416D-9982-8D0FA0401CAE@ccs.neu.edu> Message-ID: <18920.58110.92775.113219@winooski.ccs.neu.edu> On Apr 17, Matthias Felleisen wrote: > > Why don't you start with these guidelines: > > context = TL + tp(1) + ... + tp(n) > > The first page must contain only: > (1) all query results that concern tp(i) > (2) all results concerning TL > (3) tp results appear BEFORE TL results > [(4) we might also wish to order results so that those for tp(j) > occur before tp(i) if j > i] > > All other results appear on pages 2 and up. > > I suspect you can scale these rules to #lang scheme/gui and friends. > I just wish we had scheme/redex. I'm guessing that by "TL" and "TP" you mean "Teaching Language" and "Teachpack". The index entries are *not* divided onto these -- this thing is working from the plain index nothing more and nothing less. I don't see any reason to add any kind of specialization for the teaching languages and teachpacks -- since the same issues are relevant in all other languages too. It is the responsibility of teaching language to generate a query that will narrow down the full index to the relevant index -- and this should be done by a "context query". There are search operators that make it possible to write a query that shows only entries from some manual or that are provided from some module -- but in your suggested organization you do hit the two big problems that I mentioned many times now: you're describing a query that uses `or', and you're describing a query that changes the order of results. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From eli at barzilay.org Fri Apr 17 16:16:37 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 16:17:04 2009 Subject: [plt-dev] help In-Reply-To: <49E8E1A1.5090300@neilvandyke.org> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <49E8E1A1.5090300@neilvandyke.org> Message-ID: <18920.58277.522086.598258@winooski.ccs.neu.edu> On Apr 17, Neil Van Dyke wrote: > For the students, the help system knows what Language and Teachpacks > are in use, possibly what modules are in use, and maybe even what > HtDP assignment is being worked on. > > There are a few additional techniques that might improve relevance > ranking and recall for this purpose: > > * TFIDF to focus on the most information-carrying terms. TFIDF would be suitable if we had a full-text index. We don't -- the search is using only index entries, so there is no different amounts of information associated with various terms. > * Application-specific synonym dictionary that you could come up > with yourself pretty easily. > * General synonym dictionary, such as from WordNet. > * Latent Semantic Indexing. These are also all tools that would fit a full text search facility. Doing that doesn't seem to me to be practical in javascript. (We're scratching the limits of browsers as it is, and as you've experienced.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From neil at neilvandyke.org Fri Apr 17 16:45:13 2009 From: neil at neilvandyke.org (Neil Van Dyke) Date: Fri Apr 17 16:45:50 2009 Subject: [plt-dev] help In-Reply-To: <18920.58277.522086.598258@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <49E8E1A1.5090300@neilvandyke.org> <18920.58277.522086.598258@winooski.ccs.neu.edu> Message-ID: <49E8EA59.7080709@neilvandyke.org> Even a small application-specific synonym dictionary would be helpful. Or perhaps you already have synonym index entries in manuals, and can add more such entries to the manuals as you find key ones are missing. From eli at barzilay.org Fri Apr 17 16:46:38 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 16:46:58 2009 Subject: [plt-dev] help In-Reply-To: <49E8EA59.7080709@neilvandyke.org> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <49E8E1A1.5090300@neilvandyke.org> <18920.58277.522086.598258@winooski.ccs.neu.edu> <49E8EA59.7080709@neilvandyke.org> Message-ID: <18920.60078.238063.195908@winooski.ccs.neu.edu> On Apr 17, Neil Van Dyke wrote: > Even a small application-specific synonym dictionary would be > helpful. > > Or perhaps you already have synonym index entries in manuals, and > can add more such entries to the manuals as you find key ones are > missing. That's how it works now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From clements at brinckerhoff.org Fri Apr 17 16:48:57 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Apr 17 16:49:23 2009 Subject: [plt-dev] JFYI editor performance note Message-ID: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> On my ancient PPC G5 cheese-grater, svn head editors are very very slow relative to 4.1.4. I note the following things: 1) I can get *way* ahead of the keystroke buffer. In particular, if I type 160 characters quickly, it takes svn head 15 seconds to get them all onto the screen. In 4.1.4, on the other hand, DrScheme takes them as fast as I personally can type them, in this case 154 chars in 5 seconds. So, this is at least 3 times as fast, possibly much more. 2) Pasting text from one buffer into another is a particular problem, often taking many seconds. Perhaps this is a PPC-specific issue? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090417/340004bf/smime.bin From carl.eastlund at gmail.com Fri Apr 17 16:56:36 2009 From: carl.eastlund at gmail.com (Carl Eastlund) Date: Fri Apr 17 16:56:55 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> Message-ID: <990e0c030904171356m42e40f6as4188c25732a089ed@mail.gmail.com> You mean, things got slower after Matthew ported a lot of MrEd from C++ to Scheme? Perhaps you forgot about that change. :) On Fri, Apr 17, 2009 at 4:48 PM, John Clements wrote: > On my ancient PPC G5 cheese-grater, svn head editors are very very slow > relative to 4.1.4. I note the following things: > > 1) I can get *way* ahead of the keystroke buffer. ?In particular, if I type > 160 characters quickly, it takes svn head 15 seconds to get them all onto > the screen. ?In 4.1.4, on the other hand, DrScheme takes them as fast as I > personally can type them, in this case 154 chars in 5 seconds. ?So, this is > at least 3 times as fast, possibly much more. > > 2) Pasting text from one buffer into another is a particular problem, often > taking many seconds. > > > Perhaps this is a PPC-specific issue? > > John From clements at brinckerhoff.org Fri Apr 17 17:02:53 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Apr 17 17:03:19 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <990e0c030904171356m42e40f6as4188c25732a089ed@mail.gmail.com> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> <990e0c030904171356m42e40f6as4188c25732a089ed@mail.gmail.com> Message-ID: On Apr 17, 2009, at 1:56 PM, Carl Eastlund wrote: > You mean, things got slower after Matthew ported a lot of MrEd from > C++ to Scheme? Perhaps you forgot about that change. :) Right, I'm aware of that; that's why I labeled it a JFYI. It's one data point, only interesting as part of the larger picture. For instance, this might be wildly out-of-whack with other processor/OS results, in which case it would be worth mentioning. John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090417/79197792/smime.bin From mflatt at cs.utah.edu Fri Apr 17 17:05:37 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Apr 17 17:05:57 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> Message-ID: <20090417210538.AC7536500AA@mail-svr1.cs.utah.edu> At Fri, 17 Apr 2009 13:48:57 -0700, John Clements wrote: > On my ancient PPC G5 cheese-grater, svn head editors are very very > slow relative to 4.1.4. I note the following things: > > 1) I can get *way* ahead of the keystroke buffer. In particular, if I > type 160 characters quickly, it takes svn head 15 seconds to get them > all onto the screen. In 4.1.4, on the other hand, DrScheme takes them > as fast as I personally can type them, in this case 154 chars in 5 > seconds. So, this is at least 3 times as fast, possibly much more. >From my measurements, many core editor operations now take 6-10 times as long as before. Even, the operation of inserting a character shouldn't take 1/10 second. I'll investigate into this example specifically. > 2) Pasting text from one buffer into another is a particular problem, > often taking many seconds. Pasting has some deeper problem, which is still under investigation. Thanks for the data points! From matthias at ccs.neu.edu Fri Apr 17 17:10:26 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Fri Apr 17 17:14:03 2009 Subject: [plt-dev] help In-Reply-To: <18920.58110.92775.113219@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <694BA7F8-0D9A-416D-9982-8D0FA0401CAE@ccs.neu.edu> <18920.58110.92775.113219@winooski.ccs.neu.edu> Message-ID: <0CF06101-2F03-44A2-8520-17FC46269E3F@ccs.neu.edu> All index entries say where they point to. This information is all you need to give good feedback when a student asks. This is the most important area of improvement for now, and I would like this to be done -- ideally in time for the fall semester. I don't see why it shouldn't be doable -- Matthias On Apr 17, 2009, at 4:13 PM, Eli Barzilay wrote: > On Apr 17, Matthias Felleisen wrote: >> >> Why don't you start with these guidelines: >> >> context = TL + tp(1) + ... + tp(n) >> >> The first page must contain only: >> (1) all query results that concern tp(i) >> (2) all results concerning TL >> (3) tp results appear BEFORE TL results >> [(4) we might also wish to order results so that those for tp(j) >> occur before tp(i) if j > i] >> >> All other results appear on pages 2 and up. >> >> I suspect you can scale these rules to #lang scheme/gui and friends. >> I just wish we had scheme/redex. > > I'm guessing that by "TL" and "TP" you mean "Teaching Language" and > "Teachpack". The index entries are *not* divided onto these -- this > thing is working from the plain index nothing more and nothing less. > I don't see any reason to add any kind of specialization for the > teaching languages and teachpacks -- since the same issues are > relevant in all other languages too. > > It is the responsibility of teaching language to generate a query that > will narrow down the full index to the relevant index -- and this > should be done by a "context query". There are search operators that > make it possible to write a query that shows only entries from some > manual or that are provided from some module -- but in your suggested > organization you do hit the two big problems that I mentioned many > times now: you're describing a query that uses `or', and you're > describing a query that changes the order of results. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! From clements at brinckerhoff.org Fri Apr 17 17:25:26 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Apr 17 17:25:53 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <20090417210538.AC7536500AA@mail-svr1.cs.utah.edu> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> <20090417210538.AC7536500AA@mail-svr1.cs.utah.edu> Message-ID: On Apr 17, 2009, at 2:05 PM, Matthew Flatt wrote: > At Fri, 17 Apr 2009 13:48:57 -0700, John Clements wrote: >> On my ancient PPC G5 cheese-grater, svn head editors are very very >> slow relative to 4.1.4. I note the following things: >> >> 1) I can get *way* ahead of the keystroke buffer. In particular, >> if I >> type 160 characters quickly, it takes svn head 15 seconds to get them >> all onto the screen. In 4.1.4, on the other hand, DrScheme takes >> them >> as fast as I personally can type them, in this case 154 chars in 5 >> seconds. So, this is at least 3 times as fast, possibly much more. > >> From my measurements, many core editor operations now take 6-10 times > as long as before. Even, the operation of inserting a character > shouldn't take 1/10 second. I'll investigate into this example > specifically. FWIW, I see that this does depend on the content of the buffer. I observe the behavior I described when typing at position zero in with this in the buffer: #lang scheme (require redex) ;; going to just one argument. (define-language lamv (e (e e ...) (if0 e e e) x v) (v (lam (x) e) true false nand) (E (E e) (v E) (if0 E e e) hole) (x (variable-except lam true false nand if0))) (define red (reduction-relation lamv (--> (in-hole E (if0 true e_1 e_2)) (in-hole E e_1) "if0t") (--> (in-hole E (if0 false e_1 e_2)) (in-hole E e_2) "if0f") ;; gets stuck otherwise? (--> (in-hole E (nand true true)) (in-hole E false) "nandt") (--> (in-hole E (nand e_1 e_2)) (in-hole E true) "nandf" (side-condition (and (member (term e_1) '(true false)) (member (term e_2) '(true false))))) (--> (in-hole E ((lam (x) e) v)) (in-hole E (subst (x v) e)) "beta-v"))) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090417/928df5ea/smime.bin From mflatt at cs.utah.edu Fri Apr 17 17:27:13 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Apr 17 17:27:32 2009 Subject: [plt-dev] help In-Reply-To: <18920.60078.238063.195908@winooski.ccs.neu.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <49E8E1A1.5090300@neilvandyke.org> <18920.58277.522086.598258@winooski.ccs.neu.edu> <49E8EA59.7080709@neilvandyke.org> <18920.60078.238063.195908@winooski.ccs.neu.edu> Message-ID: <20090417212714.242486500B9@mail-svr1.cs.utah.edu> At Fri, 17 Apr 2009 16:46:38 -0400, Eli Barzilay wrote: > On Apr 17, Neil Van Dyke wrote: > > Even a small application-specific synonym dictionary would be > > helpful. > > > > Or perhaps you already have synonym index entries in manuals, and > > can add more such entries to the manuals as you find key ones are > > missing. > > That's how it works now. You mean the latter, right? When writing the old docs, I added explicit index entries for synonyms, and it was a pain. For the new docs, I threw out lots of synonym entries when porting, because a synonym dictionary seems like a better way to go, along with some automatic rules for plurals and things like that. Eventually. From eli at barzilay.org Fri Apr 17 17:32:43 2009 From: eli at barzilay.org (Eli Barzilay) Date: Fri Apr 17 17:33:09 2009 Subject: [plt-dev] help In-Reply-To: <20090417212714.242486500B9@mail-svr1.cs.utah.edu> References: <46599437-791A-4771-858C-1617922BCEB0@ccs.neu.edu> <595b9ab20904161633j65edd90bq7b2e092ccb20df50@mail.gmail.com> <595b9ab20904170818u3fc15d46qb92e0255c4e0a5bf@mail.gmail.com> <54F17D8B-BBE5-4FF3-9116-6CE82B35EA4C@ccs.neu.edu> <18920.49193.298074.442894@winooski.ccs.neu.edu> <932b2f1f0904171054y640c2096t4c3f15799633926c@mail.gmail.com> <18920.49887.162908.449792@winooski.ccs.neu.edu> <4AB65DEF-A1EB-444E-8610-B63568E71E7D@ccs.neu.edu> <18920.56443.793590.802135@winooski.ccs.neu.edu> <18920.56961.772409.988484@winooski.ccs.neu.edu> <49E8E1A1.5090300@neilvandyke.org> <18920.58277.522086.598258@winooski.ccs.neu.edu> <49E8EA59.7080709@neilvandyke.org> <18920.60078.238063.195908@winooski.ccs.neu.edu> <20090417212714.242486500B9@mail-svr1.cs.utah.edu> Message-ID: <18920.62843.733596.291948@winooski.ccs.neu.edu> On Apr 17, Matthew Flatt wrote: > At Fri, 17 Apr 2009 16:46:38 -0400, Eli Barzilay wrote: > > On Apr 17, Neil Van Dyke wrote: > > > Even a small application-specific synonym dictionary would be > > > helpful. > > > > > > Or perhaps you already have synonym index entries in manuals, and > > > can add more such entries to the manuals as you find key ones are > > > missing. > > > > That's how it works now. > > You mean the latter, right? Yes. > When writing the old docs, I added explicit index entries for > synonyms, and it was a pain. For the new docs, I threw out lots of > synonym entries when porting, because a synonym dictionary seems > like a better way to go, along with some automatic rules for plurals > and things like that. Eventually. (a) I think that the synonym information should come from the docs. (That is, the semantic decision of what should be considered a synonym belongs in the same world as writing the prose.) To be used by the search, it should be some table that can be used by the JS code. (b) Actually using such a table is going to make things very slow at this point, unless some normalization happens when the JS index is generated so it doesn't have to do multiple comparisons when a query is running. This might make the index bigger to, so it will still have an effect on performance. (c) I'm not sure how it will be done eventually, but there is also the ordering issue to deal with -- using too many synonyms might make the results appear in what looks like a random order. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From mflatt at cs.utah.edu Fri Apr 17 18:54:10 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Apr 17 18:54:32 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> Message-ID: <20090417225412.AA08D6500B2@mail-svr1.cs.utah.edu> At Fri, 17 Apr 2009 13:48:57 -0700, John Clements wrote: > 2) Pasting text from one buffer into another is a particular problem, > often taking many seconds. I think I've fixed this part. The default on the `overwrite-styles?' argument of `read-from-file' (which is also used for pasting from the clipboard) was backward compared the old implementation (because it was documented wrong), causing lots of unnecessary style notifications and size recalculations on each paste. From mflatt at cs.utah.edu Fri Apr 17 21:49:37 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Apr 17 21:49:58 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> Message-ID: <20090418014939.36AB16500AF@mail-svr1.cs.utah.edu> At Fri, 17 Apr 2009 13:48:57 -0700, John Clements wrote: > 1) I can get *way* ahead of the keystroke buffer. In particular, if I > type 160 characters quickly, it takes svn head 15 seconds to get them > all onto the screen. In 4.1.4, on the other hand, DrScheme takes them > as fast as I personally can type them, in this case 154 chars in 5 > seconds. So, this is at least 3 times as fast, possibly much more. I was able to see the same effect with my old PPC machine. This is now fixed in SVN. The problem was that every keystroke would trigger a redraw for the whole canvas, instead of just the line where the character was inserted. From clements at brinckerhoff.org Fri Apr 17 23:08:28 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Apr 17 23:09:13 2009 Subject: [plt-dev] JFYI editor performance note In-Reply-To: <20090418014939.36AB16500AF@mail-svr1.cs.utah.edu> References: <0DBE700E-B0AB-40DA-886F-77E9F64207EF@brinckerhoff.org> <20090418014939.36AB16500AF@mail-svr1.cs.utah.edu> Message-ID: On Apr 17, 2009, at 6:49 PM, Matthew Flatt wrote: > At Fri, 17 Apr 2009 13:48:57 -0700, John Clements wrote: >> 1) I can get *way* ahead of the keystroke buffer. In particular, >> if I >> type 160 characters quickly, it takes svn head 15 seconds to get them >> all onto the screen. In 4.1.4, on the other hand, DrScheme takes >> them >> as fast as I personally can type them, in this case 154 chars in 5 >> seconds. So, this is at least 3 times as fast, possibly much more. > > I was able to see the same effect with my old PPC machine. This is now > fixed in SVN. > > The problem was that every keystroke would trigger a redraw for the > whole canvas, instead of just the line where the character was > inserted. Many thanks! John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090417/2751e4e0/smime.bin From jos.koot at telefonica.net Wed Apr 22 09:42:00 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Wed Apr 22 09:42:24 2009 Subject: [plt-dev] order of module requires Message-ID: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> It appears that modules are not run in the same order as they are required. This can give trouble when modules have side effects, for instance one module writing a file and the other one reading that file. As an example: File module-sequence1.ss #lang scheme (printf "module 1~n") File module-sequence2.ss #lang scheme (printf "module 2~n") File module-sequence12.ss #lang scheme (require "module-sequence1.ss") (require "module-sequence2.ss") ;Displays: ;module 2 ;module 1 Is it possible to run modules in the order they are required? (may be by inserting 'inverse' somewhere in #%module-begin?) Jos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090422/f1060de6/attachment-0001.html From robby at eecs.northwestern.edu Wed Apr 22 09:45:10 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 22 09:45:31 2009 Subject: [plt-dev] order of module requires In-Reply-To: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> References: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> Message-ID: <932b2f1f0904220645q38106428i400c0b153773775e@mail.gmail.com> It is unwise to rely on the (implicit) ordering of modules. When you just have the simple setup you suggest below, that all seems reasonable, but do the "only instantiate once" behavior of module requires, some other module might come along and require module-sequence2.ss from some faraway place and break things. Better to just put your initialization code into thunks and then have a main thunk somewhere that calls all of the initialization code in the right order. Robby On Wed, Apr 22, 2009 at 8:42 AM, Jos Koot wrote: > It appears that modules are not run in the same order as they are required. > This can give trouble when modules have side effects, for instance one > module writing a file and the other one reading that file. As an example: > > File module-sequence1.ss > #lang scheme > (printf "module 1~n") > > File module-sequence2.ss > #lang scheme > (printf "module 2~n") > > File module-sequence12.ss > #lang scheme > (require "module-sequence1.ss") > (require "module-sequence2.ss") > ;Displays: > ;module 2 > ;module 1 > > Is it possible to run modules in the order they are required? > (may be by inserting 'inverse' somewhere?in #%module-begin?) > Jos > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From jos.koot at telefonica.net Wed Apr 22 10:20:49 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Wed Apr 22 10:21:15 2009 Subject: [plt-dev] order of module requires References: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> <932b2f1f0904220645q38106428i400c0b153773775e@mail.gmail.com> Message-ID: That's exacltly what I am doing now. Thanks, Jos ----- Original Message ----- From: "Robby Findler" To: "Jos Koot" Cc: Sent: Wednesday, April 22, 2009 3:45 PM Subject: Re: [plt-dev] order of module requires It is unwise to rely on the (implicit) ordering of modules. When you just have the simple setup you suggest below, that all seems reasonable, but do the "only instantiate once" behavior of module requires, some other module might come along and require module-sequence2.ss from some faraway place and break things. Better to just put your initialization code into thunks and then have a main thunk somewhere that calls all of the initialization code in the right order. Robby On Wed, Apr 22, 2009 at 8:42 AM, Jos Koot wrote: > It appears that modules are not run in the same order as they are required. > This can give trouble when modules have side effects, for instance one > module writing a file and the other one reading that file. As an example: > > File module-sequence1.ss > #lang scheme > (printf "module 1~n") > > File module-sequence2.ss > #lang scheme > (printf "module 2~n") > > File module-sequence12.ss > #lang scheme > (require "module-sequence1.ss") > (require "module-sequence2.ss") > ;Displays: > ;module 2 > ;module 1 > > Is it possible to run modules in the order they are required? > (may be by inserting 'inverse' somewhere in #%module-begin?) > Jos > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From eli at barzilay.org Wed Apr 22 11:58:18 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Apr 22 11:58:43 2009 Subject: [plt-dev] order of module requires In-Reply-To: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> References: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> Message-ID: <18927.16026.739076.532799@winooski.ccs.neu.edu> On Apr 22, Jos Koot wrote: > It appears that modules are not run in the same order as they are > required. This can give trouble when modules have side effects, for > instance one module writing a file and the other one reading that > file. As an example: > > File module-sequence1.ss > #lang scheme > (printf "module 1~n") > > File module-sequence2.ss > #lang scheme > (printf "module 2~n") > > File module-sequence12.ss > #lang scheme > (require "module-sequence1.ss") > (require "module-sequence2.ss") > ;Displays: > ;module 2 > ;module 1 There is another solution here besides thunks: if you want the first module to be running first, then make the second one require it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Wed Apr 22 13:41:35 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 22 13:41:54 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: References: <18927.17389.510355.969144@winooski.ccs.neu.edu> <932b2f1f0904220927s43d06f52g4809680b44a128d3@mail.gmail.com> <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> Message-ID: <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> I've redirected the cc's to plt-dev. (please do the same.) On Wed, Apr 22, 2009 at 12:36 PM, Michael Sperber wrote: > > Robby Findler writes: > >> The test suite engine kind of straddles this world, so as long as >> you're careful to do the same straddling, then you should be safe. But >> do note that this means you should not be using the string-constant >> form on code that runs as part of the user's program (since it expands >> into code that might touch the preferences file). > > I still don't understand: Of course, the test cases are run by the > user's program, and the error messages are caused by that program, too. > But the user's program doesn't expand into code that uses the string > constants---rather, it calls out to that code. If you're happy with your code only working in drscheme, that's fine. But I wouldn't be happy with that for the HtDP teaching languages. In general, the HtDP teaching languages code does not depend on the drscheme-level preferences and I would prefer to keep it that way. I'm not sure what Matthias okay'd, but I don't think he would/should have okay'd that. The solution seems pretty straightforward, however -- just don't use string-constants for this. Have two versions of the testing library, a german one and an english one and just load the right one in the right teaching language. Robby From sperber at deinprogramm.de Wed Apr 22 13:48:57 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Wed Apr 22 13:49:19 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> (Robby Findler's message of "Wed, 22 Apr 2009 12:41:35 -0500") References: <18927.17389.510355.969144@winooski.ccs.neu.edu> <932b2f1f0904220927s43d06f52g4809680b44a128d3@mail.gmail.com> <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> Message-ID: Robby Findler writes: > If you're happy with your code only working in drscheme, that's fine. > But I wouldn't be happy with that for the HtDP teaching languages. > > In general, the HtDP teaching languages code does not depend on the > drscheme-level preferences and I would prefer to keep it that way. I still don't understand: There are all kinds of preference settings that apply to the HtDP teaching languages. Moreover, there were even uses of string constants in the test-engine collection---note that test-display.scm already had a require of string-constants. What concrete problem am I introducing? > The solution seems pretty straightforward, however -- just don't use > string-constants for this. Have two versions of the testing library, a > german one and an english one and just load the right one in the right > teaching language. You mean I should duplicate all the code in collects/test-engine? -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From robby at eecs.northwestern.edu Wed Apr 22 13:52:48 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 22 13:53:06 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: References: <18927.17389.510355.969144@winooski.ccs.neu.edu> <932b2f1f0904220927s43d06f52g4809680b44a128d3@mail.gmail.com> <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> Message-ID: <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> On Wed, Apr 22, 2009 at 12:48 PM, Michael Sperber wrote: > > Robby Findler writes: > >> If you're happy with your code only working in drscheme, that's fine. >> But I wouldn't be happy with that for the HtDP teaching languages. >> >> In general, the HtDP teaching languages code does not depend on the >> drscheme-level preferences and I would prefer to keep it that way. > > I still don't understand: There are all kinds of preference settings > that apply to the HtDP teaching languages. Unless there are bugs, these only apply to setting up of the initial environment in which a teaching program is run. That same environment is built into the binary when an executable is created from a teaching language program. >?Moreover, there were even > uses of string constants in the test-engine collection---note that > test-display.scm already had a require of string-constants. ?What > concrete problem am I introducing? This I'm not sure. I see that creating a distribution archive with a 'check-expect' expression in just ignore the check-expects, so maybe there is special-case code in there already that takes care of everything. If you didn't add any 'require's to the string-constants library, then you're probably safe. If creation of executables still works, then you're probably safe. >> The solution seems pretty straightforward, however -- just don't use >> string-constants for this. Have two versions of the testing library, a >> german one and an english one and just load the right one in the right >> teaching language. > > You mean I should duplicate all the code in collects/test-engine? I would use abstraction. Robby From jos.koot at telefonica.net Wed Apr 22 14:27:29 2009 From: jos.koot at telefonica.net (Jos Koot) Date: Wed Apr 22 14:27:54 2009 Subject: [plt-dev] order of module requires References: <9753C690E0DE4B8EA00AFB365EE400F8@uw2b2dff239c4d> <18927.16026.739076.532799@winooski.ccs.neu.edu> Message-ID: <33675FAFEDDB4591A688CDEE95D01A6E@uw2b2dff239c4d> That is not what I want. There may be other programs requiring the same module. I prefer the method of delaying execution by making required modules to do nothing else than expor procedures (or macros) and make the top level module invoke the exported/imported procedures. Now that I follow this method I no longer have any problem. This gives me full control of the order of side effects. Hence I make a distictions between top level modules and requirds modules. Non top modules must not producd side effects. They may export procedures that produce side effects, but these procedures will be called by the top level module only. (mho) Jos ----- Original Message ----- From: "Eli Barzilay" To: "Jos Koot" Cc: Sent: Wednesday, April 22, 2009 5:58 PM Subject: Re: [plt-dev] order of module requires > On Apr 22, Jos Koot wrote: >> It appears that modules are not run in the same order as they are >> required. This can give trouble when modules have side effects, for >> instance one module writing a file and the other one reading that >> file. As an example: >> >> File module-sequence1.ss >> #lang scheme >> (printf "module 1~n") >> >> File module-sequence2.ss >> #lang scheme >> (printf "module 2~n") >> >> File module-sequence12.ss >> #lang scheme >> (require "module-sequence1.ss") >> (require "module-sequence2.ss") >> ;Displays: >> ;module 2 >> ;module 1 > > There is another solution here besides thunks: if you want the first > module to be running first, then make the second one require it. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > From matthias at ccs.neu.edu Wed Apr 22 20:34:21 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 22 20:35:51 2009 Subject: [plt-dev] Re: localization In-Reply-To: <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> References: <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904221607y161b4fe2t851d8989ee5d681a@mail.gmail.com> <6A21840F-A6DD-4C8E-9E81-8433CE3C5C86@ccs.neu.edu> <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> Message-ID: <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> Now I get it. The natural language selection is a drscheme-specific preference, because that's where language selection is visible (has an effect). So for teaching languages, the string-constants library stores the current "locale" in the preferences. Ergo, when drscheme creates an executable for programs in TLs, this program suddenly depends on the preferences. ;; --- I have two reactions to that: 1. Since people wish to build apps that are locale-specific (say British English vs German vs whoknowswhat), perhaps the DrScheme preferences are the wrong place to store this selection. 2. Teaching languages are perhaps the wrong place to teach the creation of locale-specific apps. BUT, for heaven's sake, we should be happy that a non-English speaking culture wishes to exploit our ideas and software, let's figure out to help them. ;; --- Having said that, I am wondering how Java apps are localized. Anyone know? -- Matthias From robby at eecs.northwestern.edu Wed Apr 22 20:53:54 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 22 20:54:12 2009 Subject: [plt-dev] Re: localization In-Reply-To: <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> References: <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904221607y161b4fe2t851d8989ee5d681a@mail.gmail.com> <6A21840F-A6DD-4C8E-9E81-8433CE3C5C86@ccs.neu.edu> <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> Message-ID: <932b2f1f0904221753x1db5c54ctfaebcac47ea8b5c1@mail.gmail.com> How about this: Mike has (I believe) string-constant-izied some files so that he can use the testing code in German. I'll take what he's done and abstract it slightly differently so that we just have two versions, a German one and an English one and htdp will use one and deinprogramm the other. ok? Mike, want to send me the files? (But note that I don't think your first reaction is appropriate for the start of this thread -- here we're localizing the PL that implements a program (hdtp langs vs deinprogramm langs, not the program itself. It does make sense for apps that are actually localized to use the user's locale, but that is still a drscheme-level issue (or maybe framework).) Robby On Wed, Apr 22, 2009 at 7:34 PM, Matthias Felleisen wrote: > > Now I get it. > > The natural language selection is a drscheme-specific preference, because > that's where language selection is visible (has an effect). > > So for teaching languages, the string-constants library stores the current > "locale" in the preferences. > > Ergo, when drscheme creates an executable for programs in TLs, this program > suddenly depends on the preferences. > > ;; --- > > I have two reactions to that: > > 1. Since people wish to build apps that are locale-specific (say British > English vs German vs whoknowswhat), perhaps the DrScheme preferences are the > wrong place to store this selection. > > 2. Teaching languages are perhaps the wrong place to teach the creation of > locale-specific apps. BUT, for heaven's sake, we should be happy that a > non-English speaking culture wishes to exploit our ideas and software, let's > figure out to help them. > > ;; --- > > Having said that, I am wondering how Java apps are localized. Anyone know? > > -- Matthias > > From matthias at ccs.neu.edu Wed Apr 22 20:57:19 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Wed Apr 22 20:58:49 2009 Subject: [plt-dev] Re: localization In-Reply-To: <932b2f1f0904221753x1db5c54ctfaebcac47ea8b5c1@mail.gmail.com> References: <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904221607y161b4fe2t851d8989ee5d681a@mail.gmail.com> <6A21840F-A6DD-4C8E-9E81-8433CE3C5C86@ccs.neu.edu> <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> <932b2f1f0904221753x1db5c54ctfaebcac47ea8b5c1@mail.gmail.com> Message-ID: On Apr 22, 2009, at 8:53 PM, Robby Findler wrote: > How about this: Mike has (I believe) string-constant-izied some files > so that he can use the testing code in German. I'll take what he's > done and abstract it slightly differently so that we just have two > versions, a German one and an English one and htdp will use one and > deinprogramm the other. I think this is a fair compromise for now. > (But note that I don't think your first reaction is appropriate for > the start of this thread -- here we're localizing the PL that > implements a program (hdtp langs vs deinprogramm langs, not the > program itself. It does make sense for apps that are actually > localized to use the user's locale, but that is still a drscheme-level > issue (or maybe framework).) A PL is just a scriptable app. So I think my reaction is basically on the right track. -- Matthias > > > Robby > > On Wed, Apr 22, 2009 at 7:34 PM, Matthias Felleisen > wrote: >> >> Now I get it. >> >> The natural language selection is a drscheme-specific preference, >> because >> that's where language selection is visible (has an effect). >> >> So for teaching languages, the string-constants library stores the >> current >> "locale" in the preferences. >> >> Ergo, when drscheme creates an executable for programs in TLs, >> this program >> suddenly depends on the preferences. >> >> ;; --- >> >> I have two reactions to that: >> >> 1. Since people wish to build apps that are locale-specific (say >> British >> English vs German vs whoknowswhat), perhaps the DrScheme >> preferences are the >> wrong place to store this selection. >> >> 2. Teaching languages are perhaps the wrong place to teach the >> creation of >> locale-specific apps. BUT, for heaven's sake, we should be happy >> that a >> non-English speaking culture wishes to exploit our ideas and >> software, let's >> figure out to help them. >> >> ;; --- >> >> Having said that, I am wondering how Java apps are localized. >> Anyone know? >> >> -- Matthias >> >> From eli at barzilay.org Wed Apr 22 21:04:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Wed Apr 22 21:04:29 2009 Subject: [plt-dev] Re: localization In-Reply-To: <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> References: <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904221607y161b4fe2t851d8989ee5d681a@mail.gmail.com> <6A21840F-A6DD-4C8E-9E81-8433CE3C5C86@ccs.neu.edu> <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> Message-ID: <18927.48770.261272.856772@winooski.ccs.neu.edu> On Apr 22, Matthias Felleisen wrote: > Having said that, I am wondering how Java apps are localized. Anyone > know? IIUC, it's very similar to the string-constants library, with one big difference, which is (IMO) a design problem with string-constants... The difference is that each application has its own set of strings, instead of a single repository. The problem is that the current collection of strings is "mostly drscheme", with some tools that are part of its gui -- and this creates a dependency bottleneck. Ignoring the issue of whether it's good or not to localize error messages without localizing the languae's identifiers, a more obvious way to see the problem is if someone wants to write a DrScheme extension and make it use different strings -- with the current design, the only way to get that is to add the new strings to the central pool, which doesn't make much sense. "Fixing" the current string-constants should probably be done roughly as a generalization of the core language selection mechanism and macro into a new library, then make the current string-constant library use that. If/when that's done, it will be possible to split the constants into the different applications. There is a problem with that though -- translation work becomes more difficult to do, since there are more than one file to track down. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Wed Apr 22 21:09:46 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 22 21:10:04 2009 Subject: [plt-dev] Re: localization In-Reply-To: <18927.48770.261272.856772@winooski.ccs.neu.edu> References: <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904221607y161b4fe2t851d8989ee5d681a@mail.gmail.com> <6A21840F-A6DD-4C8E-9E81-8433CE3C5C86@ccs.neu.edu> <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> <18927.48770.261272.856772@winooski.ccs.neu.edu> Message-ID: <932b2f1f0904221809k2114c73g28096be241a905e@mail.gmail.com> On Wed, Apr 22, 2009 at 8:04 PM, Eli Barzilay wrote: > On Apr 22, Matthias Felleisen wrote: >> Having said that, I am wondering how Java apps are localized. Anyone >> know? > > IIUC, it's very similar to the string-constants library, with one big > difference, which is (IMO) a design problem with string-constants... > The difference is that each application has its own set of strings, > instead of a single repository. ?The problem is that the current > collection of strings is "mostly drscheme", with some tools that are > part of its gui -- and this creates a dependency bottleneck. ?Ignoring > the issue of whether it's good or not to localize error messages > without localizing the languae's identifiers, a more obvious way to > see the problem is if someone wants to write a DrScheme extension and > make it use different strings -- with the current design, the only way > to get that is to add the new strings to the central pool, which > doesn't make much sense. > > "Fixing" the current string-constants should probably be done roughly > as a generalization of the core language selection mechanism and macro > into a new library, then make the current string-constant library use > that. ?If/when that's done, it will be possible to split the constants > into the different applications. > > There is a problem with that though -- translation work becomes more > difficult to do, since there are more than one file to track down. fwiw, the string constants library started out for just a single app. So the above (modulo the problem you mention) is a natural step in its evolution. Robby From robby at eecs.northwestern.edu Wed Apr 22 21:13:19 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Wed Apr 22 21:13:37 2009 Subject: [plt-dev] Re: localization In-Reply-To: References: <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904221607y161b4fe2t851d8989ee5d681a@mail.gmail.com> <6A21840F-A6DD-4C8E-9E81-8433CE3C5C86@ccs.neu.edu> <932b2f1f0904221652k149d781bjd706a84531e1c5bc@mail.gmail.com> <72509C7B-E44F-43C2-83D3-7F63D2DA4D29@ccs.neu.edu> <932b2f1f0904221753x1db5c54ctfaebcac47ea8b5c1@mail.gmail.com> Message-ID: <932b2f1f0904221813w4ad32beck32661d9d570c63ce@mail.gmail.com> On Wed, Apr 22, 2009 at 7:57 PM, Matthias Felleisen wrote: > > On Apr 22, 2009, at 8:53 PM, Robby Findler wrote: > >> How about this: Mike has (I believe) string-constant-izied some files >> so that he can use the testing code in German. I'll take what he's >> done and abstract it slightly differently so that we just have two >> versions, a German one and an English one and htdp will use one and >> deinprogramm the other. > > I think this is a fair compromise for now. > > >> (But note that I don't think your first reaction is appropriate for >> the start of this thread -- here we're localizing the PL that >> implements a program (hdtp langs vs deinprogramm langs, not the >> program itself. It does make sense for apps that are actually >> localized to use the user's locale, but that is still a drscheme-level >> issue (or maybe framework).) > > > A PL is just a scriptable app. So I think my reaction is basically on the > right track. > Okay, sure in that sense. But I don't think it is a good design to have while spelled "dergumphenwhilenplatzenmaker" in Germany and "rightocarryon" in the UK. Perhaps we should have skinnable PLs somehow that know how render the keywords differently in different places instead. Robby From sperber at deinprogramm.de Thu Apr 23 02:46:02 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Thu Apr 23 02:46:24 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> (Robby Findler's message of "Wed, 22 Apr 2009 12:52:48 -0500") References: <18927.17389.510355.969144@winooski.ccs.neu.edu> <932b2f1f0904220927s43d06f52g4809680b44a128d3@mail.gmail.com> <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> Message-ID: Robby Findler writes: > This I'm not sure. I see that creating a distribution archive with a > 'check-expect' expression in just ignore the check-expects, so maybe > there is special-case code in there already that takes care of > everything. > > If you didn't add any 'require's to the string-constants library, then > you're probably safe. If creation of executables still works, then > you're probably safe. Creating an executable (on MacOS) (and running it) works fine for me. Anything specific I should test? Of course, I didn't add any requires to the string-constants itself. I just added some string constants. So let me see whether I have a clue what Eli and you are talking about: You're concerned that string-constantizing the test engine would introduce dependencies for HtDP programs that weren't previously there, that would create problems in some scenarios. Is that correct? If so, is there documentation or anything that describes what dependencies are OK and which one's aren't? In the discussion, you seem to be implying knowledge of that, and therefore I don't understand what you're talking about. If the dependency on string-constants is not OK, why isn't the require of string-constants in test-display.scm a problem? -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From matthias at ccs.neu.edu Thu Apr 23 08:27:19 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Thu Apr 23 08:28:55 2009 Subject: [plt-dev] Fwd: [plt-scheme] Newbie help using (check-expect): problem nesting (generate-report) References: Message-ID: We should really smoothen the path from the test engine to the unit testing framework. -- Matthias Begin forwarded message: > From: Matt Jadud > Date: April 23, 2009 7:20:37 AM EDT > To: mattdz@udel.edu > Cc: plt-scheme@list.cs.brown.edu > Subject: Re: [plt-scheme] Newbie help using (check-expect): problem > nesting (generate-report) > > On Thu, Apr 23, 2009 at 1:11 AM, wrote: >> >> Instead of just listing a whole lot of (check-expect) expressions >> all serially one after another, >> and then evaluating them all when I run the code, I was hoping to >> be able to do something like >> this: > > Hi Mattdz, > > Does this help at all? > > http://www.rockalypse.org/courses/cmpsc220sp09/resources/ > unit_testing_in_plt_scheme.html > > You might, in short, try using SchemeUnit. It isn't far off from where > you're at, and it lets you write your tests in test suites, which you > can then combine into larger suites and run. (Or, you can run > individual suites.) Also, you can "define-simple-check", which lets > you write your own checks. > > The documentation for SchemeUnit is good, and you're welcome to ask > questions about it here. There is also the possibility that someone > will chime in and tell you how you can go about this using the tools > you're already using. > > The transition from one to the other should be minor/painless, though, > so I don't think I'm leading you vastly astray by suggesting > SchemeUnit. > > Cheers, > Matt > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-scheme From robby at eecs.northwestern.edu Thu Apr 23 09:40:54 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 23 09:41:13 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: References: <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> Message-ID: <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> On Thu, Apr 23, 2009 at 1:46 AM, Michael Sperber wrote: > > Robby Findler writes: > >> This I'm not sure. I see that creating a distribution archive with a >> 'check-expect' expression in just ignore the check-expects, so maybe >> there is special-case code in there already that takes care of >> everything. >> >> If you didn't add any 'require's to the string-constants library, then >> you're probably safe. If creation of executables still works, then >> you're probably safe. > > Creating an executable (on MacOS) (and running it) works fine for me. > Anything specific I should test? ?Of course, I didn't add any requires > to the string-constants itself. ?I just added some string constants. > > So let me see whether I have a clue what Eli and you are talking about: > > You're concerned that string-constantizing the test engine would > introduce dependencies for HtDP programs that weren't previously there, > that would create problems in some scenarios. ?Is that correct? Yes, > If so, is there documentation or anything that describes what > dependencies are OK and which one's aren't? I believe Eli maintains this information. Generally the way it works is someone adds require somewhere that breaks things and Eli lets them know when a script fails somewhere. I don't know if the precise list is available on the web, but I'm sure Eli would be more than happy to make it be so if it isn't. >?In the discussion, you seem > to be implying knowledge of that, and therefore I don't understand what > you're talking about. ?If the dependency on string-constants is not OK, > why isn't the require of string-constants in test-display.scm a problem? If you can create executables with your patch and things are working fine and if you didn't introduce any new requires, then I don't see how your change could have created a (new) problem. Robby From eli at barzilay.org Thu Apr 23 13:16:08 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Apr 23 13:16:36 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> References: <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> Message-ID: <18928.41560.678600.472124@winooski.ccs.neu.edu> On Apr 23, Robby Findler wrote: > On Thu, Apr 23, 2009 at 1:46 AM, Michael Sperber > wrote: > > If so, is there documentation or anything that describes what > > dependencies are OK and which one's aren't? > > I believe Eli maintains this information. Generally the way it works > is someone adds require somewhere that breaks things and Eli lets > them know when a script fails somewhere. I don't know if the precise > list is available on the web, but I'm sure Eli would be more than > happy to make it be so if it isn't. * This is in iplt/build/distribution-specs. * Yes, there is a dependency now, this is bad -- but making it worse is not a good idea. (You can see this by the fact that "test-engine" appears in dr-extras instead of plt-extras) * There is another issue here which is that the teaching languages are intended to be used by themselves, are used in a handin server situation, etc. Adding a preference-dependent option to this kind of thing is bad. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Thu Apr 23 13:20:46 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 23 13:21:04 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <18928.41560.678600.472124@winooski.ccs.neu.edu> References: <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> <18928.41560.678600.472124@winooski.ccs.neu.edu> Message-ID: <932b2f1f0904231020t7b8d0686h9c240a1ed5445cac@mail.gmail.com> On Thu, Apr 23, 2009 at 12:16 PM, Eli Barzilay wrote: > On Apr 23, Robby Findler wrote: >> On Thu, Apr 23, 2009 at 1:46 AM, Michael Sperber >> wrote: >> > If so, is there documentation or anything that describes what >> > dependencies are OK and which one's aren't? >> >> I believe Eli maintains this information. Generally the way it works >> is someone adds require somewhere that breaks things and Eli lets >> them know when a script fails somewhere. I don't know if the precise >> list is available on the web, but I'm sure Eli would be more than >> happy to make it be so if it isn't. > > * This is in iplt/build/distribution-specs. > > * Yes, there is a dependency now, this is bad -- but making it worse > ?is not a good idea. ?(You can see this by the fact that > ?"test-engine" appears in dr-extras instead of plt-extras) I do not believe Mike has actually made it worse in any interesting way. It will require a few more Emacs macros to undo his changes, but that can only happen when the larger problem is fixed. Put another way: we should not stand in the way of Mike for this reason. It was not his doing that put us in this bind so we should not punish him! > * There is another issue here which is that the teaching languages are > ?intended to be used by themselves, are used in a handin server > ?situation, etc. ?Adding a preference-dependent option to this kind > ?of thing is bad. The word "adding" is misused here, iiuc. Whatever thing needs to be done so that check-expect works in the handin server still needs to be done and what Mike has done does not changed that. Robby From eli at barzilay.org Thu Apr 23 13:29:38 2009 From: eli at barzilay.org (Eli Barzilay) Date: Thu Apr 23 13:29:59 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <932b2f1f0904231020t7b8d0686h9c240a1ed5445cac@mail.gmail.com> References: <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> <18928.41560.678600.472124@winooski.ccs.neu.edu> <932b2f1f0904231020t7b8d0686h9c240a1ed5445cac@mail.gmail.com> Message-ID: <18928.42370.966305.512270@winooski.ccs.neu.edu> On Apr 23, Robby Findler wrote: > On Thu, Apr 23, 2009 at 12:16 PM, Eli Barzilay wrote: > > On Apr 23, Robby Findler wrote: > >> On Thu, Apr 23, 2009 at 1:46 AM, Michael Sperber > >> wrote: > >> > If so, is there documentation or anything that describes what > >> > dependencies are OK and which one's aren't? > >> > >> I believe Eli maintains this information. Generally the way it > >> works is someone adds require somewhere that breaks things and > >> Eli lets them know when a script fails somewhere. I don't know if > >> the precise list is available on the web, but I'm sure Eli would > >> be more than happy to make it be so if it isn't. > > > > * This is in iplt/build/distribution-specs. > > > > * Yes, there is a dependency now, this is bad -- but making it > > worse is not a good idea. ?(You can see this by the fact that > > "test-engine" appears in dr-extras instead of plt-extras) > > I do not believe Mike has actually made it worse in any interesting > way. It will require a few more Emacs macros to undo his changes, > but that can only happen when the larger problem is fixed. No, it's not worse in an interesting way -- just worse. Each such change makes disconnecting DrScheme from such components so that distribution is sane more a dream than a possible reality. > Put another way: we should not stand in the way of Mike for this > reason. It was not his doing that put us in this bind so we should > not punish him! It *is* making things worse. > > * There is another issue here which is that the teaching languages are > > ?intended to be used by themselves, are used in a handin server > > ?situation, etc. ?Adding a preference-dependent option to this kind > > ?of thing is bad. > > The word "adding" is misused here, iiuc. No -- the current use of string-constant in the test-engine collection is *only* for gui strings, so any behavior that would be seen through a handin server or through a distributed program would be the same. > Whatever thing needs to be done so that check-expect works in the > handin server still needs to be done and what Mike has done does not > changed that. Of course it needs to be done still -- but the current problem with it is unrelated to the current issue. The current issue is potentially going to add a new problem. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From robby at eecs.northwestern.edu Thu Apr 23 15:20:06 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 23 15:20:24 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <18928.42370.966305.512270@winooski.ccs.neu.edu> References: <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> <18928.41560.678600.472124@winooski.ccs.neu.edu> <932b2f1f0904231020t7b8d0686h9c240a1ed5445cac@mail.gmail.com> <18928.42370.966305.512270@winooski.ccs.neu.edu> Message-ID: <932b2f1f0904231220j6527aa54o90f993f59e4ab399@mail.gmail.com> On Thu, Apr 23, 2009 at 12:29 PM, Eli Barzilay wrote: > No -- the current use of string-constant in the test-engine collection > is *only* for gui strings, so any behavior that would be seen through > a handin server or through a distributed program would be the same. IIUC, the invariant (following "so any ..." above) is not violated, which is what we really care about, right? >> Whatever thing needs to be done so that check-expect works in the >> handin server still needs to be done and what Mike has done does not >> changed that. > > Of course it needs to be done still -- but the current problem with it > is unrelated to the current issue. ?The current issue is potentially > going to add a new problem. "potentially" or "actually"? (Does it take longer to write your next reply or to actually check...?) Robby From robby at eecs.northwestern.edu Thu Apr 23 20:57:30 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 23 20:57:49 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: References: <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> Message-ID: <932b2f1f0904231757p23cce608ye385c118b1571166@mail.gmail.com> Mike -- please go ahead and check your changes in. At some point in the future we may have to rewrite things either because a) we've found a better way to set up the string-constants that makes it work better in "userspace" programs or (in the less ambitious world) we decide to clean the check-expect code up and end up having to make all deinprogramm uses of it give German error messages and all htdp uses give English error messages, regardless of the user's language preferences. But not today. Robby On Thu, Apr 23, 2009 at 1:46 AM, Michael Sperber wrote: > > Robby Findler writes: > >> This I'm not sure. I see that creating a distribution archive with a >> 'check-expect' expression in just ignore the check-expects, so maybe >> there is special-case code in there already that takes care of >> everything. >> >> If you didn't add any 'require's to the string-constants library, then >> you're probably safe. If creation of executables still works, then >> you're probably safe. > > Creating an executable (on MacOS) (and running it) works fine for me. > Anything specific I should test? ?Of course, I didn't add any requires > to the string-constants itself. ?I just added some string constants. > > So let me see whether I have a clue what Eli and you are talking about: > > You're concerned that string-constantizing the test engine would > introduce dependencies for HtDP programs that weren't previously there, > that would create problems in some scenarios. ?Is that correct? > > If so, is there documentation or anything that describes what > dependencies are OK and which one's aren't? ?In the discussion, you seem > to be implying knowledge of that, and therefore I don't understand what > you're talking about. ?If the dependency on string-constants is not OK, > why isn't the require of string-constants in test-display.scm a problem? > > -- > Cheers =8-} Mike > Friede, V?lkerverst?ndigung und ?berhaupt blabla > From clements at brinckerhoff.org Fri Apr 24 13:46:09 2009 From: clements at brinckerhoff.org (John Clements) Date: Fri Apr 24 13:46:50 2009 Subject: [plt-dev] FYI: Intermittently, editors pack/unpack to length 0 string ? Message-ID: I'm having another intermittent problem that may be related to the recent changes to editors. I'm using the handin engine to accept assignments, and I've now twice gotten into a state where the handin server reports failure because it claims that the submission is of zero length. I added some diagnostic code the first time, and discovered that sending "get-text" (sp?) to the text% that is the result of .. okay, let me just write this in scheme: (let*-values ([(defs dc) (unpack-submission bytes)] [(text) (send defs get-text)]) (string-length text)) This evaluates to zero. Closing and restarting the client-side DrScheme makes the problem go away. I realize that a valuable diagnostic result here would be the length (and content) of the value 'bytes', and if this happens again, I'll try to capture it. In the meantime, all I can tell you is that packing and unpacking the definitions window using the Handin server periodically results in an empty string. One final piece of information, hopefully irrelevant: I'm using drocaml, here, so the definitions window in question contains an editor that's being operated on by drocaml code. I imagine that it shouldn't be possible for drocaml to get the editor into a "bad state", but I can't be sure. This may belong in the FYI bin. John Clements -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2484 bytes Desc: not available Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090424/b4ada55c/smime-0001.bin From cce at ccs.neu.edu Fri Apr 24 14:14:19 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Apr 24 14:14:37 2009 Subject: [plt-dev] Segfault running setup-plt Message-ID: <990e0c030904241114i6c44bb92w826931b153b40a87@mail.gmail.com> My incremental build today died during setup-plt without an error message (multiple times, actually, when I retried it in various degrees of "clean-ness"), so I blew away Library/PLT Scheme/ and trunk/, checked out the trunk again, and ran configure, make, and make install. The make install died as soon as setup-plt started: mzscheme/mzscheme3m -X "/Users/cce/plt/trunk/collects" -l setup setup-plt: bootstrapping from source... make[1]: *** [install-3m] Segmentation fault make: *** [install] Error 2 Anyone know what might be causing this? -- Carl Eastlund From mflatt at cs.utah.edu Fri Apr 24 14:27:51 2009 From: mflatt at cs.utah.edu (Matthew Flatt) Date: Fri Apr 24 14:28:15 2009 Subject: [plt-dev] Segfault running setup-plt In-Reply-To: <990e0c030904241114i6c44bb92w826931b153b40a87@mail.gmail.com> References: <990e0c030904241114i6c44bb92w826931b153b40a87@mail.gmail.com> Message-ID: <20090424182752.A259E6500B1@mail-svr1.cs.utah.edu> Possibly fixed in SVN... At Fri, 24 Apr 2009 14:14:19 -0400, Carl Eastlund wrote: > My incremental build today died during setup-plt without an error > message (multiple times, actually, when I retried it in various > degrees of "clean-ness"), so I blew away Library/PLT Scheme/ and > trunk/, checked out the trunk again, and ran configure, make, and make > install. The make install died as soon as setup-plt started: > > mzscheme/mzscheme3m -X "/Users/cce/plt/trunk/collects" -l setup > setup-plt: bootstrapping from source... > make[1]: *** [install-3m] Segmentation fault > make: *** [install] Error 2 > > Anyone know what might be causing this? > > -- > Carl Eastlund > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From cce at ccs.neu.edu Fri Apr 24 15:22:26 2009 From: cce at ccs.neu.edu (Carl Eastlund) Date: Fri Apr 24 15:22:45 2009 Subject: [plt-dev] Segfault running setup-plt In-Reply-To: <20090424182752.A259E6500B1@mail-svr1.cs.utah.edu> References: <990e0c030904241114i6c44bb92w826931b153b40a87@mail.gmail.com> <20090424182752.A259E6500B1@mail-svr1.cs.utah.edu> Message-ID: <990e0c030904241222ra3ae7d8s38d1864b1a4d31fa@mail.gmail.com> Thanks, 'make install' ran to completion this time. On Fri, Apr 24, 2009 at 2:27 PM, Matthew Flatt wrote: > Possibly fixed in SVN... > > At Fri, 24 Apr 2009 14:14:19 -0400, Carl Eastlund wrote: >> My incremental build today died during setup-plt without an error >> message (multiple times, actually, when I retried it in various >> degrees of "clean-ness"), so I blew away Library/PLT Scheme/ and >> trunk/, checked out the trunk again, and ran configure, make, and make >> install. ?The make install died as soon as setup-plt started: >> >> mzscheme/mzscheme3m -X "/Users/cce/plt/trunk/collects" -l setup >> setup-plt: bootstrapping from source... >> make[1]: *** [install-3m] Segmentation fault >> make: *** [install] Error 2 >> >> Anyone know what might be causing this? >> >> -- >> Carl Eastlund From sperber at deinprogramm.de Mon Apr 27 06:27:49 2009 From: sperber at deinprogramm.de (Michael Sperber) Date: Mon Apr 27 06:28:09 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <18928.41560.678600.472124@winooski.ccs.neu.edu> (Eli Barzilay's message of "Thu, 23 Apr 2009 13:16:08 -0400") References: <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> <18928.41560.678600.472124@winooski.ccs.neu.edu> Message-ID: Eli Barzilay writes: > * This is in iplt/build/distribution-specs. The problem is that this documents the specs *as they are*, rather than as you'd like to see them. How would it have helped me figure out there's a problem? (It also seem way too complex to make for a good guideline for developers.) > * Yes, there is a dependency now, this is bad -- but making it worse > is not a good idea. Then maybe the test-engine needs to split in two parts: One that knows about DrScheme (and which can have translations), and one that doesn't. It seems Kathy has already catered to that scenario the way the modules in collects/test-engine are organized. > (You can see this by the fact that > "test-engine" appears in dr-extras instead of plt-extras) A comment might help idle readers like me figure out that you consider this undesirable. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From eli at barzilay.org Mon Apr 27 06:53:02 2009 From: eli at barzilay.org (Eli Barzilay) Date: Mon Apr 27 06:53:25 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: References: <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> <18928.41560.678600.472124@winooski.ccs.neu.edu> Message-ID: <18933.36494.693150.693380@winooski.ccs.neu.edu> On Apr 27, Michael Sperber wrote: > > Eli Barzilay writes: > > > * This is in iplt/build/distribution-specs. > > The problem is that this documents the specs *as they are*, rather > than as you'd like to see them. How would it have helped me figure > out there's a problem? By the fact that it's added to the `dr' distribution -- that implies that drscheme depends on it. BTW, the part for packages is pretty simple -- the main mess is in the overall rules for the system. (Initially I even thought about putting package specific rules in the packages info files or some other meta-file local to the package directory.) > > * Yes, there is a dependency now, this is bad -- but making it > > worse is not a good idea. > > Then maybe the test-engine needs to split in two parts: One that > knows about DrScheme (and which can have translations), and one that > doesn't. It seems Kathy has already catered to that scenario the > way the modules in collects/test-engine are organized. * Yes, such splits are good -- but I basically get zero help from package authors. (I've stopped trying to do that, so I just email when I see something obvious.) * The files that are in the `dr' distribution are files that drscheme depends on, not the other way (otherwise they'd move to the `plt' distribution). > > (You can see this by the fact that > > "test-engine" appears in dr-extras instead of plt-extras) > > A comment might help idle readers like me figure out that you > consider this undesirable. I tried to explain it several times, I don't think that anyone remembers. (This also applies to having `mr' and `dr' distros when they're not really being built.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From matthias at ccs.neu.edu Mon Apr 27 08:42:06 2009 From: matthias at ccs.neu.edu (Matthias Felleisen) Date: Mon Apr 27 08:42:38 2009 Subject: [plt-dev] Re: [plt-translators] Translations for test engine In-Reply-To: <18933.36494.693150.693380@winooski.ccs.neu.edu> References: <18927.18651.986384.678868@winooski.ccs.neu.edu> <932b2f1f0904220944u4b9f282o9775b4e387b049be@mail.gmail.com> <932b2f1f0904221032m61f53a20s9a8d8a23c4e0169d@mail.gmail.com> <932b2f1f0904221041x4d68a579y58d9fb9378412c67@mail.gmail.com> <932b2f1f0904221052p2aa6f5danc427efe02aef98e2@mail.gmail.com> <932b2f1f0904230640i10154f94u9e154f7b01108fc0@mail.gmail.com> <18928.41560.678600.472124@winooski.ccs.neu.edu> <18933.36494.693150.693380@winooski.ccs.neu.edu> Message-ID: <154BD3DC-59F5-49EB-AFEA-78DE56D7D195@ccs.neu.edu> The explanation happened at the wrong level. Time to bring in Shriram and throw this problem at Alloy. Or something like that :-) On Apr 27, 2009, at 6:53 AM, Eli Barzilay wrote: > On Apr 27, Michael Sperber wrote: >> >> Eli Barzilay writes: >> >>> * This is in iplt/build/distribution-specs. >> >> The problem is that this documents the specs *as they are*, rather >> than as you'd like to see them. How would it have helped me figure >> out there's a problem? > > By the fact that it's added to the `dr' distribution -- that implies > that drscheme depends on it. BTW, the part for packages is pretty > simple -- the main mess is in the overall rules for the system. > (Initially I even thought about putting package specific rules in the > packages info files or some other meta-file local to the package > directory.) > > >>> * Yes, there is a dependency now, this is bad -- but making it >>> worse is not a good idea. >> >> Then maybe the test-engine needs to split in two parts: One that >> knows about DrScheme (and which can have translations), and one that >> doesn't. It seems Kathy has already catered to that scenario the >> way the modules in collects/test-engine are organized. > > * Yes, such splits are good -- but I basically get zero help from > package authors. (I've stopped trying to do that, so I just email > when I see something obvious.) > > * The files that are in the `dr' distribution are files that drscheme > depends on, not the other way (otherwise they'd move to the `plt' > distribution). > > >>> (You can see this by the fact that >>> "test-engine" appears in dr-extras instead of plt-extras) >> >> A comment might help idle readers like me figure out that you >> consider this undesirable. > > I tried to explain it several times, I don't think that anyone > remembers. (This also applies to having `mr' and `dr' distros when > they're not really being built.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > Barzilay: > http://www.barzilay.org/ Maze is > Life! > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev From jay.mccarthy at gmail.com Tue Apr 28 17:23:34 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Tue Apr 28 17:23:55 2009 Subject: [plt-dev] Lazy localization initialization in srfi/19 Message-ID: Here's a patch to srfi/19 that makes the localization initialization lazy: Does anyone object? Jay Index: time.ss =================================================================== --- time.ss (revision 14641) +++ time.ss (working copy) @@ -95,23 +95,26 @@ date->string string->date ) - ;; SRFI-29: Localization initialization: - (re-read-locale) - (or (load-bundle! (list* 'srfi-19 - (current-language) - (current-country) - (current-locale-details))) - ;; A little bit less specific - (load-bundle! (list 'srfi-19 - (current-language) - (current-country))) - ;; less specific - (load-bundle! (list 'srfi-19 (current-language))) - ;; the least specific one (this one *do* exists!, it comes with this srfi) don't worry: - (load-bundle! (list 'srfi-19))) - + (define localized? #f) (define localized-message (lambda (message-name) + (unless localized? + ;; SRFI-29: Localization initialization: + (re-read-locale) + (or (load-bundle! (list* 'srfi-19 + (current-language) + (current-country) + (current-locale-details))) + ;; A little bit less specific + (load-bundle! (list 'srfi-19 + (current-language) + (current-country))) + ;; less specific + (load-bundle! (list 'srfi-19 (current-language))) + ;; the least specific one (this one *do* exists!, it comes with this srfi) don't worry: + (load-bundle! (list 'srfi-19))) + (set! localized? #t)) + (localized-template 'srfi-19 message-name))) ;; Constants -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From eli at barzilay.org Tue Apr 28 19:09:28 2009 From: eli at barzilay.org (Eli Barzilay) Date: Tue Apr 28 19:09:49 2009 Subject: [plt-dev] Lazy localization initialization in srfi/19 In-Reply-To: References: Message-ID: <18935.36008.207805.339600@winooski.ccs.neu.edu> On Apr 28, Jay McCarthy wrote: > Here's a patch to srfi/19 that makes the localization initialization > lazy: > > Does anyone object? (I sounds good to me -- I think that there was once a problem with some code that was accessing the preferences too eagerly.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! From jay.mccarthy at gmail.com Wed Apr 29 11:05:31 2009 From: jay.mccarthy at gmail.com (Jay McCarthy) Date: Wed Apr 29 11:05:52 2009 Subject: [plt-dev] Reorganization of scheme/private/class-internal's initialization of object% and object<%> Message-ID: I'm trying to find place where initialization is at the top-level, but doesn't have to be. There's an instance in the class system. Here's a patch that hides it. It is tested. Anyone object to a commit? Index: private/class-internal.ss =================================================================== --- private/class-internal.ss (revision 14649) +++ private/class-internal.ss (working copy) @@ -2543,10 +2543,14 @@ (make-struct-type name type 0 0 #f null insp)]) make-)) - (define object<%> ((make-naming-constructor struct:interface 'interface:object%) - 'object% null #f null #f null)) - (setup-all-implemented! object<%>) - (define object% ((make-naming-constructor struct:class 'class:object%) + (define object<%> + (local [(define object<%> + ((make-naming-constructor struct:interface 'interface:object%) + 'object% null #f null #f null))] + (setup-all-implemented! object<%>) + object<%>)) + (define object% + (local [(define object% ((make-naming-constructor struct:class 'class:object%) 'object% 0 (vector #f) object<%> @@ -2571,17 +2575,18 @@ (lambda (obj) #(())) ; serialize (lambda (obj args) (void)) ; deserialize-fixup - #t)) ; no super-init + #t))] ; no super-init - (vector-set! (class-supers object%) 0 object%) - (let*-values ([(struct:obj make-obj obj? -get -set!) - (make-struct-type 'object #f 0 0 #f (list (cons prop:object object%)) #f)]) - (set-class-struct:object! object% struct:obj) - (set-class-make-object! object% make-obj)) - (set-class-object?! object% object?) ; don't use struct pred; it wouldn't work with prim classes + (vector-set! (class-supers object%) 0 object%) + (let*-values ([(struct:obj make-obj obj? -get -set!) + (make-struct-type 'object #f 0 0 #f (list (cons prop:object object%)) #f)]) + (set-class-struct:object! object% struct:obj) + (set-class-make-object! object% make-obj)) + (set-class-object?! object% object?) ; don't use struct pred; it wouldn't work with prim classes + + (set-interface-class! object<%> object%) + object%)) - (set-interface-class! object<%> object%) - ;;-------------------------------------------------------------------- ;; instantiation ;;-------------------------------------------------------------------- -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 From dvanhorn at ccs.neu.edu Thu Apr 30 11:19:23 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Thu Apr 30 11:19:53 2009 Subject: [plt-dev] Patch: index planet info fields Message-ID: <49F9C17B.1060006@ccs.neu.edu> The attached patch adds index entries for all the planet info.ss fields, such as 'blurb, 'release-notes, etc. David -------------- next part -------------- Index: collects/planet/planet.scrbl =================================================================== --- collects/planet/planet.scrbl (revision 14668) +++ collects/planet/planet.scrbl (working copy) @@ -766,41 +766,43 @@ @itemize[ -@item{The @scheme['blurb] field: If present, the blurb field should contain a list of XHTML fragments -encoded as x-expressions (see the xml collection for details) that -PLaneT will use as a short description of your project.} +@item{The @indexed-scheme['blurb] field: If present, the blurb field +should contain a list of XHTML fragments encoded as x-expressions (see +the xml collection for details) that PLaneT will use as a short +description of your project.} -@item{The @scheme['release-notes] field: If present, the release-notes field should contain a list of XHTML -fragments encoded as x-expressions (see the xml collection for -details) that PLaneT will use as a short description of what's new -in this release of your package.} +@item{The @indexed-scheme['release-notes] field: If present, the +release-notes field should contain a list of XHTML fragments encoded +as x-expressions (see the xml collection for details) that PLaneT will +use as a short description of what's new in this release of your +package.} -@item{The @scheme['categories] field: -If present, the categories field should be a list of symbols -corresponding to the categories under which this package should be listed. +@item{The @indexed-scheme['categories] field: If present, the categories +field should be a list of symbols corresponding to the categories +under which this package should be listed. The valid categories are: @itemize[ - @item{@scheme['devtools]: Development Tools} - @item{@scheme['net]: Networking and Protocols} - @item{@scheme['media]: Graphics and Audio} - @item{@scheme['xml]: XML-Related} - @item{@scheme['datastructures]: Data Structures and Algorithms} - @item{@scheme['io]: Input/Output and Filesystem} - @item{@scheme['scientific]: Mathematical and Scientific} - @item{@scheme['system]: Hardware/Operating System-Specific Tools} - @item{@scheme['ui]: Textual and Graphical User Interface} - @item{@scheme['metaprogramming]: Metaprogramming Tools} - @item{@scheme['planet]: PLaneT-Related} - @item{@scheme['misc]: Miscellaneous}] + @item{@indexed-scheme['devtools]: Development Tools} + @item{@indexed-scheme['net]: Networking and Protocols} + @item{@indexed-scheme['media]: Graphics and Audio} + @item{@indexed-scheme['xml]: XML-Related} + @item{@indexed-scheme['datastructures]: Data Structures and Algorithms} + @item{@indexed-scheme['io]: Input/Output and Filesystem} + @item{@indexed-scheme['scientific]: Mathematical and Scientific} + @item{@indexed-scheme['system]: Hardware/Operating System-Specific Tools} + @item{@indexed-scheme['ui]: Textual and Graphical User Interface} + @item{@indexed-scheme['metaprogramming]: Metaprogramming Tools} + @item{@indexed-scheme['planet]: PLaneT-Related} + @item{@indexed-scheme['misc]: Miscellaneous}] If you put symbols other than these the categories field, they will be ignored. If you put no legal symbols in the categories field or do not include this field in your info.ss file, your package will be categorized as "Miscellaneous."} -@item{The @scheme['can-be-loaded-with] field: +@item{The @indexed-scheme['can-be-loaded-with] field: If present, the can-be-loaded-with field should be a quoted datum of one of the following forms: @@ -819,13 +821,13 @@ file, then multiple versions of the same package being loaded simultaneously may be a problem. This field allows you to specify whether your package can be loaded simultaneously with older versions -of itself. If its value is @scheme['all], then the package may be loaded with -any older version. If it is @scheme['none], then it may not be loaded with -older versions at all. If it is @scheme[(list 'all-except VER-SPEC ...)] then -any package except those that match one of the given VER-SPEC forms -may be loaded with this package; if it is @scheme[(list 'only VER-SPEC ...)] -then only packages that match one of the given VER-SPEC forms may be -loaded with this package. +of itself. If its value is @indexed-scheme['all], then the package may be +loaded with any older version. If it is @indexed-scheme['none], then it +may not be loaded with older versions at all. If it is @scheme[(list +'all-except VER-SPEC ...)] then any package except those that match +one of the given VER-SPEC forms may be loaded with this package; if it +is @scheme[(list 'only VER-SPEC ...)] then only packages that match +one of the given VER-SPEC forms may be loaded with this package. When checking to see if a package may be loaded, PLaneT compares it to all other currently-loaded instances of the same package with any @@ -834,16 +836,16 @@ such comparisons succeed then the new package may be loaded; otherwise PLaneT signals an error. -The default for this field is @scheme['none] as a conservative protection -measure. For many packages it is safe to set this field to -@scheme['any].} +The default for this field is @indexed-scheme['none] as a conservative +protection measure. For many packages it is safe to set this field to +@indexed-scheme['any].} -@item{The @scheme['homepage] field: +@item{The @indexed-scheme['homepage] field: If present, the URL field should be a string corresponding to a URL for the package. PLaneT provides this link with the description of your package on the main PLaneT web page.} -@item{The @scheme['primary-file] field: +@item{The @indexed-scheme['primary-file] field: If present, the primary-file field should be a either a string corresponding to the name (without path) of the main Scheme source file of your package, or a list of such strings. The PLaneT web page @@ -856,7 +858,7 @@ line printed on your package's page. If you include a list of strings, then the first legal file string in the list will be used.} -@item{The @scheme['required-core-version] field: If present, the +@item{The @indexed-scheme['required-core-version] field: If present, the required-core-version field should be a string with the same syntax as the output of the @scheme[version] function. Defining this field indicates that PLaneT should only allow users of a version of mzscheme @@ -866,14 +868,14 @@ instance, setting this field to @scheme["300.2"] would cause the PLaneT server not to serve it to MzScheme v300.1 or older clients.} -@item{The @scheme['version] field: +@item{The @indexed-scheme['version] field: If present, the version field should be a string that describes the version number of this code that should be presented to users (e.g., @scheme["0.15 alpha"]). This field does not override or in any way interact with your package's package version number, which is assigned by PLaneT, but may be useful to users.} -@item{The @scheme['repositories] field: If present, the repositories +@item{The @indexed-scheme['repositories] field: If present, the repositories field should be a list consisting of some subset of the strings @scheme["4.x"] and @scheme["3xx"]. The string @scheme["4.x"] indicates that this package should be included in the v4.x repository (which @@ -886,9 +888,9 @@ In addition, PLaneT uses the setup-plt installer to install packages on client machines, so most fields it looks for can be included with -their usual effects. In particular, adding a @scheme['name] field indicates that -the Scheme files in the package should be compiled during -installation; it is a good idea to add it. +their usual effects. In particular, adding a @indexed-scheme['name] +field indicates that the Scheme files in the package should be +compiled during installation; it is a good idea to add it. An example info.ss file looks like this: From robby at eecs.northwestern.edu Thu Apr 30 11:27:24 2009 From: robby at eecs.northwestern.edu (Robby Findler) Date: Thu Apr 30 11:27:46 2009 Subject: [plt-dev] Patch: index planet info fields In-Reply-To: <49F9C17B.1060006@ccs.neu.edu> References: <49F9C17B.1060006@ccs.neu.edu> Message-ID: <932b2f1f0904300827k18aa6a46o8f0185b3716361b3@mail.gmail.com> Thanks! Can you check it in, or do you need someone else to? (I never figured out patch files, so if you can't check it in, please send me the whole file and I will.) Robby On Thu, Apr 30, 2009 at 10:19 AM, David Van Horn wrote: > The attached patch adds index entries for all the planet info.ss fields, > such as 'blurb, 'release-notes, etc. > > David > > > Index: collects/planet/planet.scrbl > =================================================================== > --- collects/planet/planet.scrbl ? ? ? ?(revision 14668) > +++ collects/planet/planet.scrbl ? ? ? ?(working copy) > @@ -766,41 +766,43 @@ > > ?@itemize[ > > -@item{The @scheme['blurb] field: If present, the blurb field should contain > a list of XHTML fragments > -encoded as x-expressions (see the xml collection for details) that > -PLaneT will use as a short description of your project.} > +@item{The @indexed-scheme['blurb] field: If present, the blurb field > +should contain a list of XHTML fragments encoded as x-expressions (see > +the xml collection for details) that PLaneT will use as a short > +description of your project.} > > -@item{The @scheme['release-notes] field: If present, the release-notes > field should contain a list of XHTML > -fragments encoded as x-expressions (see the xml collection for > -details) that PLaneT will use as a short description of what's new > -in this release of your package.} > +@item{The @indexed-scheme['release-notes] field: If present, the > +release-notes field should contain a list of XHTML fragments encoded > +as x-expressions (see the xml collection for details) that PLaneT will > +use as a short description of what's new in this release of your > +package.} > > -@item{The @scheme['categories] field: > -If present, the categories field should be a list of symbols > -corresponding to the categories under which this package should be listed. > +@item{The @indexed-scheme['categories] field: If present, the categories > +field should be a list of symbols corresponding to the categories > +under which this package should be listed. > > ?The valid categories are: > > ?@itemize[ > - ?@item{@scheme['devtools]: ? ? ? ? Development Tools} > - ?@item{@scheme['net]: ? ? ? ? ? ? ?Networking and Protocols} > - ?@item{@scheme['media]: ? ? ? ? ? ?Graphics and Audio} > - ?@item{@scheme['xml]: ? ? ? ? ? ? ?XML-Related} > - ?@item{@scheme['datastructures]: ? Data Structures and Algorithms} > - ?@item{@scheme['io]: ? ? ? ? ? ? ? Input/Output and Filesystem} > - ?@item{@scheme['scientific]: ? ? ? Mathematical and Scientific} > - ?@item{@scheme['system]: ? ? ? ? ? Hardware/Operating System-Specific > Tools} > - ?@item{@scheme['ui]: ? ? ? ? ? ? ? Textual and Graphical User Interface} > - ?@item{@scheme['metaprogramming]: ?Metaprogramming Tools} > - ?@item{@scheme['planet]: ? ? ? ? ? PLaneT-Related} > - ?@item{@scheme['misc]: ? ? ? ? ? ? Miscellaneous}] > + ?@item{@indexed-scheme['devtools]: ? ? ? ? Development Tools} > + ?@item{@indexed-scheme['net]: ? ? ? ? ? ? ?Networking and Protocols} > + ?@item{@indexed-scheme['media]: ? ? ? ? ? ?Graphics and Audio} > + ?@item{@indexed-scheme['xml]: ? ? ? ? ? ? ?XML-Related} > + ?@item{@indexed-scheme['datastructures]: ? Data Structures and Algorithms} > + ?@item{@indexed-scheme['io]: ? ? ? ? ? ? ? Input/Output and Filesystem} > + ?@item{@indexed-scheme['scientific]: ? ? ? Mathematical and Scientific} > + ?@item{@indexed-scheme['system]: ? ? ? ? ? Hardware/Operating > System-Specific Tools} > + ?@item{@indexed-scheme['ui]: ? ? ? ? ? ? ? Textual and Graphical User > Interface} > + ?@item{@indexed-scheme['metaprogramming]: ?Metaprogramming Tools} > + ?@item{@indexed-scheme['planet]: ? ? ? ? ? PLaneT-Related} > + ?@item{@indexed-scheme['misc]: ? ? ? ? ? ? Miscellaneous}] > > ?If you put symbols other than these the categories field, they will be > ?ignored. If you put no legal symbols in the categories field or do not > ?include this field in your info.ss file, your package will be > ?categorized as "Miscellaneous."} > > -@item{The @scheme['can-be-loaded-with] field: > +@item{The @indexed-scheme['can-be-loaded-with] field: > ?If present, the can-be-loaded-with field should be a quoted datum of > ?one of the following forms: > > @@ -819,13 +821,13 @@ > ?file, then multiple versions of the same package being loaded > ?simultaneously may be a problem. This field allows you to specify > ?whether your package can be loaded simultaneously with older versions > -of itself. If its value is @scheme['all], then the package may be loaded > with > -any older version. If it is @scheme['none], then it may not be loaded with > -older versions at all. If it is @scheme[(list 'all-except VER-SPEC ...)] > then > -any package except those that match one of the given VER-SPEC forms > -may be loaded with this package; if it is @scheme[(list 'only VER-SPEC > ...)] > -then only packages that match one of the given VER-SPEC forms may be > -loaded with this package. > +of itself. If its value is @indexed-scheme['all], then the package may be > +loaded with any older version. If it is @indexed-scheme['none], then it > +may not be loaded with older versions at all. If it is @scheme[(list > +'all-except VER-SPEC ...)] then any package except those that match > +one of the given VER-SPEC forms may be loaded with this package; if it > +is @scheme[(list 'only VER-SPEC ...)] ?then only packages that match > +one of the given VER-SPEC forms may be loaded with this package. > > ?When checking to see if a package may be loaded, PLaneT compares it to > ?all other currently-loaded instances of the same package with any > @@ -834,16 +836,16 @@ > ?such comparisons succeed then the new package may be loaded; otherwise > ?PLaneT signals an error. > > -The default for this field is @scheme['none] as a conservative protection > -measure. For many packages it is safe to set this field to > -@scheme['any].} > +The default for this field is @indexed-scheme['none] as a conservative > +protection measure. For many packages it is safe to set this field to > +@indexed-scheme['any].} > > -@item{The @scheme['homepage] field: > +@item{The @indexed-scheme['homepage] field: > ?If present, the URL field should be a string corresponding to a URL > ?for the package. PLaneT provides this link with the description of your > ?package on the main PLaneT web page.} > > -@item{The @scheme['primary-file] field: > +@item{The @indexed-scheme['primary-file] field: > ?If present, the primary-file field should be a either a string > ?corresponding to the name (without path) of the main Scheme source > ?file of your package, or a list of such strings. The PLaneT web page > @@ -856,7 +858,7 @@ > ?line printed on your package's page. If you include a list of strings, > ?then the first legal file string in the list will be used.} > > -@item{The @scheme['required-core-version] field: If present, the > +@item{The @indexed-scheme['required-core-version] field: If present, the > ?required-core-version field should be a string with the same syntax as > ?the output of the @scheme[version] function. Defining this field > ?indicates that PLaneT should only allow users of a version of mzscheme > @@ -866,14 +868,14 @@ > ?instance, setting this field to @scheme["300.2"] would cause the PLaneT > server > ?not to serve it to MzScheme v300.1 or older clients.} > > -@item{The @scheme['version] field: > +@item{The @indexed-scheme['version] field: > ?If present, the version field should be a string that describes the > ?version number of this code that should be presented to users (e.g., > ?@scheme["0.15 alpha"]). This field does not override or in any way interact > ?with your package's package version number, which is assigned by > ?PLaneT, but may be useful to users.} > > -@item{The @scheme['repositories] field: If present, the repositories > +@item{The @indexed-scheme['repositories] field: If present, the > repositories > ?field should be a list consisting of some subset of the strings > ?@scheme["4.x"] and @scheme["3xx"]. The string @scheme["4.x"] indicates > ?that this package should be included in the v4.x repository (which > @@ -886,9 +888,9 @@ > > ?In addition, PLaneT uses the setup-plt installer to install packages > ?on client machines, so most fields it looks for can be included with > -their usual effects. In particular, adding a @scheme['name] field indicates > that > -the Scheme files in the package should be compiled during > -installation; it is a good idea to add it. > +their usual effects. In particular, adding a @indexed-scheme['name] > +field indicates that the Scheme files in the package should be > +compiled during installation; it is a good idea to add it. > > ?An example info.ss file looks like this: > > > _________________________________________________ > ?For list-related administrative tasks: > ?http://list.cs.brown.edu/mailman/listinfo/plt-dev > > From dvanhorn at ccs.neu.edu Thu Apr 30 11:38:17 2009 From: dvanhorn at ccs.neu.edu (David Van Horn) Date: Thu Apr 30 11:38:58 2009 Subject: [plt-dev] Patch: index planet info fields In-Reply-To: <932b2f1f0904300827k18aa6a46o8f0185b3716361b3@mail.gmail.com> References: <49F9C17B.1060006@ccs.neu.edu> <932b2f1f0904300827k18aa6a46o8f0185b3716361b3@mail.gmail.com> Message-ID: <49F9C5E9.4080505@ccs.neu.edu> I can't check in, but here's the whole file. David Robby Findler wrote: > Thanks! > > Can you check it in, or do you need someone else to? (I never figured > out patch files, so if you can't check it in, please send me the whole > file and I will.) > > Robby > > On Thu, Apr 30, 2009 at 10:19 AM, David Van Horn wrote: >> The attached patch adds index entries for all the planet info.ss fields, >> such as 'blurb, 'release-notes, etc. >> >> David >> >> >> Index: collects/planet/planet.scrbl >> =================================================================== >> --- collects/planet/planet.scrbl (revision 14668) >> +++ collects/planet/planet.scrbl (working copy) >> @@ -766,41 +766,43 @@ >> >> @itemize[ >> >> -@item{The @scheme['blurb] field: If present, the blurb field should contain >> a list of XHTML fragments >> -encoded as x-expressions (see the xml collection for details) that >> -PLaneT will use as a short description of your project.} >> +@item{The @indexed-scheme['blurb] field: If present, the blurb field >> +should contain a list of XHTML fragments encoded as x-expressions (see >> +the xml collection for details) that PLaneT will use as a short >> +description of your project.} >> >> -@item{The @scheme['release-notes] field: If present, the release-notes >> field should contain a list of XHTML >> -fragments encoded as x-expressions (see the xml collection for >> -details) that PLaneT will use as a short description of what's new >> -in this release of your package.} >> +@item{The @indexed-scheme['release-notes] field: If present, the >> +release-notes field should contain a list of XHTML fragments encoded >> +as x-expressions (see the xml collection for details) that PLaneT will >> +use as a short description of what's new in this release of your >> +package.} >> >> -@item{The @scheme['categories] field: >> -If present, the categories field should be a list of symbols >> -corresponding to the categories under which this package should be listed. >> +@item{The @indexed-scheme['categories] field: If present, the categories >> +field should be a list of symbols corresponding to the categories >> +under which this package should be listed. >> >> The valid categories are: >> >> @itemize[ >> - @item{@scheme['devtools]: Development Tools} >> - @item{@scheme['net]: Networking and Protocols} >> - @item{@scheme['media]: Graphics and Audio} >> - @item{@scheme['xml]: XML-Related} >> - @item{@scheme['datastructures]: Data Structures and Algorithms} >> - @item{@scheme['io]: Input/Output and Filesystem} >> - @item{@scheme['scientific]: Mathematical and Scientific} >> - @item{@scheme['system]: Hardware/Operating System-Specific >> Tools} >> - @item{@scheme['ui]: Textual and Graphical User Interface} >> - @item{@scheme['metaprogramming]: Metaprogramming Tools} >> - @item{@scheme['planet]: PLaneT-Related} >> - @item{@scheme['misc]: Miscellaneous}] >> + @item{@indexed-scheme['devtools]: Development Tools} >> + @item{@indexed-scheme['net]: Networking and Protocols} >> + @item{@indexed-scheme['media]: Graphics and Audio} >> + @item{@indexed-scheme['xml]: XML-Related} >> + @item{@indexed-scheme['datastructures]: Data Structures and Algorithms} >> + @item{@indexed-scheme['io]: Input/Output and Filesystem} >> + @item{@indexed-scheme['scientific]: Mathematical and Scientific} >> + @item{@indexed-scheme['system]: Hardware/Operating >> System-Specific Tools} >> + @item{@indexed-scheme['ui]: Textual and Graphical User >> Interface} >> + @item{@indexed-scheme['metaprogramming]: Metaprogramming Tools} >> + @item{@indexed-scheme['planet]: PLaneT-Related} >> + @item{@indexed-scheme['misc]: Miscellaneous}] >> >> If you put symbols other than these the categories field, they will be >> ignored. If you put no legal symbols in the categories field or do not >> include this field in your info.ss file, your package will be >> categorized as "Miscellaneous."} >> >> -@item{The @scheme['can-be-loaded-with] field: >> +@item{The @indexed-scheme['can-be-loaded-with] field: >> If present, the can-be-loaded-with field should be a quoted datum of >> one of the following forms: >> >> @@ -819,13 +821,13 @@ >> file, then multiple versions of the same package being loaded >> simultaneously may be a problem. This field allows you to specify >> whether your package can be loaded simultaneously with older versions >> -of itself. If its value is @scheme['all], then the package may be loaded >> with >> -any older version. If it is @scheme['none], then it may not be loaded with >> -older versions at all. If it is @scheme[(list 'all-except VER-SPEC ...)] >> then >> -any package except those that match one of the given VER-SPEC forms >> -may be loaded with this package; if it is @scheme[(list 'only VER-SPEC >> ...)] >> -then only packages that match one of the given VER-SPEC forms may be >> -loaded with this package. >> +of itself. If its value is @indexed-scheme['all], then the package may be >> +loaded with any older version. If it is @indexed-scheme['none], then it >> +may not be loaded with older versions at all. If it is @scheme[(list >> +'all-except VER-SPEC ...)] then any package except those that match >> +one of the given VER-SPEC forms may be loaded with this package; if it >> +is @scheme[(list 'only VER-SPEC ...)] then only packages that match >> +one of the given VER-SPEC forms may be loaded with this package. >> >> When checking to see if a package may be loaded, PLaneT compares it to >> all other currently-loaded instances of the same package with any >> @@ -834,16 +836,16 @@ >> such comparisons succeed then the new package may be loaded; otherwise >> PLaneT signals an error. >> >> -The default for this field is @scheme['none] as a conservative protection >> -measure. For many packages it is safe to set this field to >> -@scheme['any].} >> +The default for this field is @indexed-scheme['none] as a conservative >> +protection measure. For many packages it is safe to set this field to >> +@indexed-scheme['any].} >> >> -@item{The @scheme['homepage] field: >> +@item{The @indexed-scheme['homepage] field: >> If present, the URL field should be a string corresponding to a URL >> for the package. PLaneT provides this link with the description of your >> package on the main PLaneT web page.} >> >> -@item{The @scheme['primary-file] field: >> +@item{The @indexed-scheme['primary-file] field: >> If present, the primary-file field should be a either a string >> corresponding to the name (without path) of the main Scheme source >> file of your package, or a list of such strings. The PLaneT web page >> @@ -856,7 +858,7 @@ >> line printed on your package's page. If you include a list of strings, >> then the first legal file string in the list will be used.} >> >> -@item{The @scheme['required-core-version] field: If present, the >> +@item{The @indexed-scheme['required-core-version] field: If present, the >> required-core-version field should be a string with the same syntax as >> the output of the @scheme[version] function. Defining this field >> indicates that PLaneT should only allow users of a version of mzscheme >> @@ -866,14 +868,14 @@ >> instance, setting this field to @scheme["300.2"] would cause the PLaneT >> server >> not to serve it to MzScheme v300.1 or older clients.} >> >> -@item{The @scheme['version] field: >> +@item{The @indexed-scheme['version] field: >> If present, the version field should be a string that describes the >> version number of this code that should be presented to users (e.g., >> @scheme["0.15 alpha"]). This field does not override or in any way interact >> with your package's package version number, which is assigned by >> PLaneT, but may be useful to users.} >> >> -@item{The @scheme['repositories] field: If present, the repositories >> +@item{The @indexed-scheme['repositories] field: If present, the >> repositories >> field should be a list consisting of some subset of the strings >> @scheme["4.x"] and @scheme["3xx"]. The string @scheme["4.x"] indicates >> that this package should be included in the v4.x repository (which >> @@ -886,9 +888,9 @@ >> >> In addition, PLaneT uses the setup-plt installer to install packages >> on client machines, so most fields it looks for can be included with >> -their usual effects. In particular, adding a @scheme['name] field indicates >> that >> -the Scheme files in the package should be compiled during >> -installation; it is a good idea to add it. >> +their usual effects. In particular, adding a @indexed-scheme['name] >> +field indicates that the Scheme files in the package should be >> +compiled during installation; it is a good idea to add it. >> >> An example info.ss file looks like this: >> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> >> -------------- next part -------------- #lang scribble/doc @(require scribble/manual scribble/bnf scribble/eval (for-label scheme) (for-label planet/config) (for-label planet/util)) @(define-syntax-rule (eg (code resl) ...) (interaction (eval:alts code resl) ...)) @title{@bold{PLaneT}: Automatic Package Distribution} @author["Jacob Matthews"] The @PLaneT system is a method for automatically sharing code packages, both as libraries and as full applications, that gives every user of a @PLaneT client the illusion of having a local copy of every code package on the server. It consists of @link["http://planet.plt-scheme.org/"]{the central @PLaneT package repository}, a server that holds all PLaneT packages, and the PLaneT client, built into PLT Scheme, which transparently interacts with the server on your behalf when necessary. @table-of-contents[] @section{Using PLaneT} To use a @PLaneT package in a program, require it using the @scheme[planet] @scheme[require] form (see @(secref "require" #:doc '(lib "scribblings/reference/reference.scrbl")) for a full reference on the features of the @scheme[require] statement in general and the exact allowed grammar of PLaneT require statements). Here we explain how to use PLaneT by example. @subsection[#:tag "finding-a-package"]{Finding a Package} If you are new to PLaneT, the first thing to to is visit @link["http://planet.plt-scheme.org/"]{the PLaneT repository web site} and see what packages are available. People contribute new PLaneT packages all the time --- if you want to be notified whenever a new or updated package is released, you can subscribe to the (announcement-only) @link["http://mailman.cs.uchicago.edu/mailman/listinfo/planet-announce"]{PLaneT-announce mailing list} or use an RSS reader to subscribe to @link["http://planet.plt-scheme.org/300/planet.rss"]{PLaneT's RSS feed}. To use a package from PLaneT in your program, the easiest thing to do is copy the @scheme[require] code snippet off of that package's page and paste it ino your program. For instance, to use Schematics' @link["http://planet.plt-scheme.org/users/schematics/spgsql.plt"]{spgsql.plt} package (a library for interacting with the @link["http://www.postgresql.org/"]{PostgresQL} database), as of this writing you would copy and paste the line: @schemeblock[(require (planet "spgsql.ss" ("schematics" "spgsql.plt" 2 3)))] into your program. This line requires the file @filepath{spgsql.ss} in package version 2.3 of the @filepath{spgsql.plt} package written by @filepath{schematics}. That does two things: first, it downloads and installs a version of @filepath{spgsql.plt} that is compatible with package version 2.3 from @link["http://planet.plt-scheme.org/"]{the central PLaneT repository} if a compatible version hasn't already been installed. Second, it requires the module in file @filepath{spgsql.ss} from that package, making all of its exported bindings available for use. Unlike with most package-distribution systems, package downloading and installation in PLaneT is @emph{transparent}: there's no need for you to do anything special the first time you want to use a package, and there's no need for you to even know whether or not a particular package is installed on your computer or the computers where your code will be deployed. @subsection{Shorthand Syntax} As of PLT Scheme version 4.0, the code snippet above can also be written using a new shorter syntax: @schemeblock[(require (planet schematics/spgsql:2:3/spgsql))] The two forms behave identically. In the abbreviated syntax, however, it is illegal to write the trailing @filepath{.ss} suffix on the file name to be required or the trailing @filepath{.plt} on the package file name. (They are mandatory for the long-form syntax.) It is also legal in the abbreviated syntax to omit a filename to be required entirely; in that case, PLaneT requires the file @filepath{main.ss} in the given package. @subsection{Networking troubles} Sometimes, when PLaneT tries to download and install a package for the first time, your operating system may block it from access to the network. If you are uncomfortable giving DrScheme free access to the network (or if your attempts to do so do not seem to work), then you can use your browser to manually install a planet package. To see how this works, lets assume you want to install the PLAI package and @schemeblock[(require (planet plai/plai:1))] is not working for you. @itemize[ @item{First, fire up a command-line window and use @tt{planet url} to determine the url for downloading the package. To find the url for version @tt{(1 1)} of the plai package, do this: @tt{% planet url plai plai.plt 1 1} and get this as a response: @tt{http://planet.plt-scheme.org/servlets/planet-servlet.ss?lang=%224.1.5.3%22&name=%22plai.plt%22&maj=1&min-lo=1&min-hi=%23f&path=%28%22plai%22%29}} @item{Copy and paste that url into your browser, which should trigger the dowload of a file called @tt{plai.plt}. Note that your browser will probably try to call the file something else. Rename it to @tt{plai.plt}.} @item{Now run the command-line tool one more time to install the plt file: @tt{% planet fileinject plai plai.plt 1 1} This command should be run from the same directory where you saved @tt{plai.plt}. This command may fail, since version @tt{(1 1)} of the PLAI package depends on @tt{cce/scheme:4:1}. If it does, simply repeat the above steps for that package first, and then continue with the @tt{fileinject} command for PLAI.} @item{Finally, to check that the installation is successful, run @tt{planet show}. You should see output like this (possibly with slightly different version numbers, if the packages have been updated since this was written): @verbatim{ Normally-installed packages: cce scheme.plt 4 1 plai plai.plt 1 1 }} ] Once that is complete, PLaneT will use that version of the package for any subsequent @scheme[require]s and won't try to use the network. @subsection{Fine-Grained Control Over Package Imports} The PLaneT client is designed to balance two competing goals: transparent upgradability and control over the effect of a package requirement. To that end, the most basic PLaneT require form offers maximum upgradability, but several more specialized forms allow finer-grained control over what versions of the named package may be downloaded. @margin-note{Package versions should not be confused with program or library versions; a @italic{package version} is a PLaneT-specific version number that encodes backwards-compatibility information.} The most basic planet require line, which is what is used in the form @schemeblock[(require (planet "spgsql.ss" ("schematics" "spgsql.plt" 2 3)))] in longhand notation, or @schemeblock[(require (planet schematics/spgsql:2:3/spgsql))] in shorthand notation, should be read ``Require from PLaneT @italic{any} release of Schematics' @filepath{spgsql.plt} package that is backwards-compatible with package version 2.3.'' (The actual package version used is determined by @seclink["search-order"]{the PLaneT search order}.) To signal this explicitly, it is possible to write @schemeblock[(require (planet "spgsql.ss" ("schematics" "spgsql.plt" 2 (+ 3))))] or @schemeblock[(require (planet schematics/spgsql:2:>=3/spgsql))] both of which mean the same thing as the first pair of require lines. @margin-note{See @secref{backwards-compatibility} for a more detailed discussion of backwards-compatibility obligations for PLaneT packages.} The notion of ``backwards-compatibility'' has a specific meaning in PLaneT: by definition, for the purposes of automation, a package is considered to be backwards-compatible with any other package of the same owner, name, and major version, and any @italic{lower} minor version. Package maintainers are responsible for marking new releases that break backwards-compatibility by incrementing their major-version number. This means that all of the above require specifications will match any release of @filepath{unlib.plt} with major package version 3 (and any minor version), but will @italic{never} match releases of @filepath{unlib.plt} with higher (or lower) major version numbers. Of course a package author may make a mistake and introduced a backwards-incompatibility unintentionally, or may fix a bug that code in third-party libraries was already working around. In those cases, it may help to make use of the ``upper bound'' form of the planet require, in longhand form: @schemeblock[(require (planet "reduction-semantics.ss" ("robby" "redex.plt" 4 (- 3))))] and using shorthand notation: @schemeblock[(require (planet robby/redex:4:<=3/reduction-semantics))] In this require line, any version of the package @filepath{redex.plt} from package version 4.0 to package version 4.3 will match the require spec (though as with any PLaneT require specification, @seclink["search-order"]{the PLaneT package search order} determines which package is actually loaded). It is also possible to specify both an upper and a lower bound, using the planet require's ``range'' form: @schemeblock[(require (planet "test.ss" ("schematics" "schemeunit.plt" 2 (9 10))))] or @schemeblock[(require (planet schematics/schemeunit:2:9-10/test))] This form matches any package in the specified range (inclusive on both ends), in this example the specifications match either package version 2.9 or 2.10 of the @filepath{schemeunit.plt} package, but do not match version with higher or lower minor version numbers (or any other major version number). Using the range form, it is possible to require a specific version of a package as a special case (choosing the upper and lower bounds to be equal), but this is a common enough case that it has special support with the ``exact-match'' form: @schemeblock[(require (planet "unzip.ss" ("dherman" "zip.plt" 2 (= 1))))] or @schemeblock[(require (planet dherman/zip:2:=1/unzip))] match only the exact package version 2.1 of the @filepath{zip.plt} package. @;@subsection{Linkage} @;@subsection{The Diamond Property} @subsection{Monitoring PLaneT's progress} PLaneT logs information about what it is doing to the @tt{info} log (via @scheme[log-info]). In DrScheme, you can view the logs from the @onscreen{Show Log} menu item in the @onscreen{View} menu, and MzScheme's logging output can be controlled via command-line options and via environment variables. See @secref["logging" #:doc '(lib "scribblings/reference/reference.scrbl")] for more details. @section[#:tag "search-order"]{The PLaneT Search Order} PLaneT has four strategies it uses in order to match a request with an appropriate package that. @subsection{Previous Linkage} Whenever a file requires a package via PLaneT and that requirement is satisfied, the system makes a note of exactly which package satisfied that requirement and from then on always uses that exact same package, even if a newer version is available. This is done to prevent "magic upgrades" in which a program stops working after installation because an unrelated package was installed. Such connections are called links and are stored in a user-specific table called the linkage table. @subsection{Acceptable Local Package} If the PLaneT client doesn't have any previous linkage information, it checks its list of already-installed PLaneT packages for one that meets the requirement, and uses it if available. Both PLaneT-installed packages and packages established through a development link (see @secref{devlinks}) are checked simultaneously at this stage. @subsection{Acceptable Remote Package} If there is no acceptable local package, the PLaneT client sends a request to the PLaneT server for a new package that would satisfy the requirement. The server then finds the newest matching package and sends it back to the client, which then installs it and uses it to satisfy the original requirement. @subsection{Cached Installation Archive} If the remote server cannot be contacted (or fails in any way to deliver an acceptable package), the PLaneT client consults the uninstalled-packages cache, a cache of all previously-downloaded packages, even those that are not currently installed. PLT Scheme users who frequently upgrade their installations may have many packages downloaded but not installed at any given time; this step is intended to ensure that these users can still run programs even if they temporarily lose network connection. @section[#:tag "cmdline"]{The @exec{planet} Command-Line Tool} The @exec{planet} command-line tool allows a command-line interface to the most commonly-performed PLaneT tasks. It is invoked from the command line as @commandline{planet @italic{subcommand} arg ...} where @italic{command} is a subcommand from the following list, and @exec{arg} is a sequence of arguments determined by that subcommand: @(define (cmd name desc) @item{@(seclink name (exec name)): @desc}) @itemize[ @cmd["create"]{create a PLaneT archive from a directory} @cmd["install"]{download and install a given package} @cmd["remove"]{remove the specified package from the local cache} @cmd["show"]{list the packages installed in the local cache} @cmd["clearlinks"]{clear the linkage table, allowing upgrades} @cmd["fileinject"]{install a local file to the planet cache} @cmd["link"]{create a development link} @cmd["unlink"]{remove development link associated with the given package} @cmd["fetch"]{download a package file without installing it} @cmd["url"]{get a URL for the given package} @cmd["open"]{unpack the contents of the given package} @cmd["structure"]{display the structure of a given .plt archive} @cmd["print"]{display a file within of the given .plt archive}] Each of these commands is described in more detail below. All the functionality of the command-line tool is also provided with a programmatic interface by @seclink["util.ss"]{the @filepath{util.ss} library}. @subsection[#:tag "create"]{@exec{create}} Usage: @commandline{planet create [