Re: [racket-dev] Pre-Release Checklist for v5.2
Ryan Culpepper r...@cs.utah.edu writes: * Mike Sperber sper...@deinprogramm.de - DMdA Tests - Stepper Tests - Signature Tests Done. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
7 hours ago, Robby Findler wrote: On Wed, Oct 19, 2011 at 6:56 PM, Eli Barzilay e...@barzilay.org wrote: But this is very different from what the online check syntax is doing, and the current problem of letting the output go to the console still needs to be solved. (And IMO, it should be discarded, still.) This would be one way to solve it. Online check syntax would just save up its IO (for the most recent run, anyways) and when you opened up this new compile-time REPL, you'd see all that IO and the REPL would be ready to go much more quickly than you might expect (since opening the REPL will amount to just sending a message over to the other place and asking for the IO (which would block if the expansion were still pending)). Well, at this point you're talking about an optimization that happens to be possible because of the on-line check syntax. But I still think that there is too many differences between the two uses which will lead to problems when you try to do things this way. For example: * The REPL will need to run via messages to the existing place -- and that will probably make it different from running the REPL when the online syntax check is disabled. Either that, or you end up using a place for the REPL even when it's disabled. * What happens with other side effects that you cannot stash away somewhere? Like making a network connection, a sound, or popping up a window? (Yes, the gui happens to not be available, but that's a technicality...) * What happens when Matthias wants more stuff from that REPL, like getting more debugging information? Running the syntax level with debugging for the online checker doesn't make much sense, so you end up dumping whatever you get anyway. * And there's also a related problem that is already there: what happens if my syntax code does something really heavy, like run the C compiler for something, accumulating output in some log file, delete files, etc? (Or maybe requiring some planet library, which somehow fails and re-installs on the next update? Though I see an access error in this case, so maybe you're running it in a sandbox already?) That means that running it on almost every keystroke is very undesirable. And trying to avoid it, perhaps like that access error that I've seen with requiring planet code, means that syntax code runs in a more restricted environment, which might lead to different behavior than an actual run -- so you'll want to re-run the syntax code anyway before you give the user a REPL, otherwise it's a kind of a REPL that might have problems that you won't really have when you run the code as usual. Because of these differences, I think that it's perfectly fine to just avoid any such side effects as much as possible, and freely abort when the code tries to run some process, make a network connection, or pop up a window. It's easy to explain too: the online checker does its work unless the syntax code is trying to do these kind of side effects, in which case it'll just give up to avoid nasty surprises. The syntax level REPL is still useful, and of course in an unrestricted environment (other than the usual memory limits). You can fake it: [...] - (define-syntax-rule (#%top-interaction . x) (begin-for-syntax x)) Interesting thought. I have no idea how close that is to what you'd really want, tho. Is it close? Probably far enough to not be realistic... This is possibly closer: - (define-for-syntax x 100) - x ; reference to undefined identifier: x [,bt for context] - (begin-for-syntax (read-eval-print-loop)) - x 100 -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Matthew, On 10/18/11 17:10, Matthew Flatt wrote: At Tue, 18 Oct 2011 16:32:54 +0200, Marijn wrote: the attached program draws a grid in a canvas and paints a few of the cells so created. When resizing the window, the grid is also dynamically resized together with the coloring of a few painted cells. Everything seems to work fine, except that while the window is being changed in size the drawing is off and the colored cells do not properly correspond to the drawn grid. You can see this especially well if you hold down the mouse button after resizing. When releasing it the grid lines will change position to match up once more with the colorings. This was due to an internal inconsistency with `get-char-width' and `get-char-height'. I've pushed a repair. Could you perhaps comment on the slowness of the cursor appearing in a clicked cell? It seems to have something to do with the timer frequency, because if I decrease the frequency the first time that the cursor appears is also sooner after clicking in a cell. Another thing. How do you enable simple select/copy/cut/paste behavior with standard key-bindings in an editor? Thanks, Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6f5wsACgkQp/VmCx0OL2xPLgCgjPdS/Ii9Kdyj4bNKZGLYRcOh qn0An14oOSrI57/XU/n3tkELHvs4qhg3 =90cJ -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 8:16 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Oct 20, 2011, at 8:21 AM, Robby Findler wrote: I also believe that we don't support these programs well as it is. I didn't program with closures until I experienced them in Scheme 84 in 1984. Perhaps people haven't programmed in syntax REPLs because there aren't any. But then again, perhaps people see no need. I do start seeing a need and I am surprised why we haven't thought of this before. Or someone has and I can't recall -- Matthias Just to clarify: my these programs refers to programs that, at compile time, make network connections, or call out to gcc. Are you making an argument that we should be supporting them better? (If so, then Eli is right and we should not base a syntax-time REPL on online check syntax.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
I've certainly wanted this in the past. Ryan came up with some tricks that made it easier, but I think a separate REPL that basically ran (begin-for-syntax (print e)) would be a very nice addition. I'm also with Eli in thinking that this should be separate from online check syntax, unless we make the whole repl use the results of online check syntax. sam th On Oct 20, 2011 9:17 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Oct 20, 2011, at 8:21 AM, Robby Findler wrote: I also believe that we don't support these programs well as it is. I didn't program with closures until I experienced them in Scheme 84 in 1984. Perhaps people haven't programmed in syntax REPLs because there aren't any. But then again, perhaps people see no need. I do start seeing a need and I am surprised why we haven't thought of this before. Or someone has and I can't recall -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I've certainly wanted this in the past. Ryan came up with some tricks that made it easier, but I think a separate REPL that basically ran (begin-for-syntax (print e)) would be a very nice addition. I'm also with Eli in thinking that this should be separate from online check syntax, unless we make the whole repl use the results of online check syntax. I don't understand your unless. Just to be clear, I am imagining two different REPLs. One REPL you get when you click Run. One REPL you get when you click some other button and the second REPL has the compile-time bindings of the program in the definitions window. The second RPEL may or may not be instantly available depending on whether or not it is (internally) using the results of the online expansion. Eli's argument boil down to saying that there are programs that don't work in online check syntax (and implicitly saying we should support those programs in this new REPL). If you agree with that, then what programs have you written that have this property? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched
On Thu, Oct 20, 2011 at 9:29 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I've certainly wanted this in the past. Ryan came up with some tricks that made it easier, but I think a separate REPL that basically ran (begin-for-syntax (print e)) would be a very nice addition. I'm also with Eli in thinking that this should be separate from online check syntax, unless we make the whole repl use the results of online check syntax. I don't understand your unless. Just to be clear, I am imagining two different REPLs. One REPL you get when you click Run. One REPL you get when you click some other button and the second REPL has the compile-time bindings of the program in the definitions window. This sounds very nice, although I don't see why they need to be separate. We could just have a way to switch one repl back and forth (as Eli just suggested), or two tabs in the interaction window, or something else. But I would think one click of Run should be sufficient. For programs that take a while to run, I'd be frustrated having to do that multiple times. The second RPEL may or may not be instantly available depending on whether or not it is (internally) using the results of the online expansion. I guess I don't see why online check syntax is even relevant here. This seems like a case of premature optimization, and one with semantic restrictions. In addition to the issues discussed already, there would be a bunch of things that a REPL hooked up to a separate place couldn't do. For example, syntax snips would be really important at a syntax-time REPL, and they would be tricky if not impossible in the architecture. So would writing out code to a separate file. Eli's argument boil down to saying that there are programs that don't work in online check syntax (and implicitly saying we should support those programs in this new REPL). If you agree with that, then what programs have you written that have this property? I think here's it's important to draw a distinction between two kinds of compile-time I/O. One kind is done whenever a module is visited, eg (begin-for-syntax (printf foo)). This isn't very well handled at the moment in Racket, because how many times that happens is hard to predict. The other kind is I/O done in the course of a particular transcription step, such as `include'. That's quite well supported at the moment by Racket, and something that we shouldn't break. For examples of the second kind, here are a few I've written, used, or wanted to use: - logging to a file during expansion - opening up a macro-debugger window during expansion - Dave Herman's or Jay's C compiler libraries - Felix Klock's FFI generation tools (for Larceny, but a really nice idea that we could use) run the C compiler at expansion time - Invoking an external SAT solver for Typed Racket type checking -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/20/11 14:53, Matthew Flatt wrote:
At Thu, 20 Oct 2011 11:16:59 +0200, Marijn wrote:
Could you perhaps comment on the slowness of the cursor appearing
in a clicked cell? It seems to have something to do with the
timer frequency, because if I decrease the frequency the first
time that the cursor appears is also sooner after clicking in a
cell.
I think you need to add `(send grid refresh)' to the admin's
`set-focus' method.
It's funny that you mention this `set-focus' method, because I can't
find it in the docs, although my code seems to think it's a canvas%
method (oops?). I hope my confusion isn't contagious. ;P
Calling `refresh' of either the display or the editor in the admin's
on-focus works beautifully though, thanks.
Calling `on-focus' doesn't make an editor request a refresh, so
the refresh is currently happening only when the caret is blinked
(which does cause a refresh request).
That explains it.
Another thing. How do you enable simple select/copy/cut/paste
behavior with standard key-bindings in an editor?
Apply `(current-text-keymap-initializer)' to the editor.
I'm kinda struggling with this one. What I came up with is:
(define default-keymap (new keymap%))
((current-text-keymap-initializer) default-keymap)
(add-text-keymap-functions default-keymap)
and then I do (send editor set-keymap default-keymap) for each editor.
Is that what you meant?
This makes some emacs-like bindings work (C-a and C-e go to beginning
and end of line, C-y - yank). Is there a way to get the more familiar
{C-a - select-all, C-v - copy-selection, etc.} bindings?
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6gRRAACgkQp/VmCx0OL2ybiACfaC+KRtsiWWZKPoGbW7NrD0J6
TOEAnjhJ02SucsrekmvzVTgl2icwGkAM
=+/MB
-END PGP SIGNATURE-
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
At Thu, 20 Oct 2011 17:58:08 +0200, Marijn wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/20/11 14:53, Matthew Flatt wrote:
At Thu, 20 Oct 2011 11:16:59 +0200, Marijn wrote:
Could you perhaps comment on the slowness of the cursor appearing
in a clicked cell? It seems to have something to do with the
timer frequency, because if I decrease the frequency the first
time that the cursor appears is also sooner after clicking in a
cell.
I think you need to add `(send grid refresh)' to the admin's
`set-focus' method.
It's funny that you mention this `set-focus' method, because I can't
find it in the docs, although my code seems to think it's a canvas%
method (oops?). I hope my confusion isn't contagious. ;P
Calling `refresh' of either the display or the editor in the admin's
on-focus works beautifully though, thanks.
Sorry --- I meant the `on-focus' method in your admin class.
Another thing. How do you enable simple select/copy/cut/paste
behavior with standard key-bindings in an editor?
Apply `(current-text-keymap-initializer)' to the editor.
I'm kinda struggling with this one. What I came up with is:
(define default-keymap (new keymap%))
((current-text-keymap-initializer) default-keymap)
(add-text-keymap-functions default-keymap)
and then I do (send editor set-keymap default-keymap) for each editor.
Is that what you meant?
Yes, though I forgot exactly how the parameter value works.
This makes some emacs-like bindings work (C-a and C-e go to beginning
and end of line, C-y - yank). Is there a way to get the more familiar
{C-a - select-all, C-v - copy-selection, etc.} bindings?
Use `add-editor-keymap-functions' in addition to
`add-text-keymap-functions'.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
Generally, the menukey-c, menukey-v, keybindings (and friends)
come about via the menus, not via a keymap% object. And those menus
come in via a frame. I'm not sure how you're using your library, but
you might want to consider some of the mixins in the framework whose
names start with frame:.
Robby
On Thu, Oct 20, 2011 at 11:12 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Thu, 20 Oct 2011 17:58:08 +0200, Marijn wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/20/11 14:53, Matthew Flatt wrote:
At Thu, 20 Oct 2011 11:16:59 +0200, Marijn wrote:
Could you perhaps comment on the slowness of the cursor appearing
in a clicked cell? It seems to have something to do with the
timer frequency, because if I decrease the frequency the first
time that the cursor appears is also sooner after clicking in a
cell.
I think you need to add `(send grid refresh)' to the admin's
`set-focus' method.
It's funny that you mention this `set-focus' method, because I can't
find it in the docs, although my code seems to think it's a canvas%
method (oops?). I hope my confusion isn't contagious. ;P
Calling `refresh' of either the display or the editor in the admin's
on-focus works beautifully though, thanks.
Sorry --- I meant the `on-focus' method in your admin class.
Another thing. How do you enable simple select/copy/cut/paste
behavior with standard key-bindings in an editor?
Apply `(current-text-keymap-initializer)' to the editor.
I'm kinda struggling with this one. What I came up with is:
(define default-keymap (new keymap%))
((current-text-keymap-initializer) default-keymap)
(add-text-keymap-functions default-keymap)
and then I do (send editor set-keymap default-keymap) for each editor.
Is that what you meant?
Yes, though I forgot exactly how the parameter value works.
This makes some emacs-like bindings work (C-a and C-e go to beginning
and end of line, C-y - yank). Is there a way to get the more familiar
{C-a - select-all, C-v - copy-selection, etc.} bindings?
Use `add-editor-keymap-functions' in addition to
`add-text-keymap-functions'.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/20/11 18:12, Matthew Flatt wrote:
At Thu, 20 Oct 2011 17:58:08 +0200, Marijn wrote:
Another thing. How do you enable simple
select/copy/cut/paste behavior with standard key-bindings in
an editor?
Apply `(current-text-keymap-initializer)' to the editor.
I'm kinda struggling with this one. What I came up with is:
(define default-keymap (new keymap%))
((current-text-keymap-initializer) default-keymap)
(add-text-keymap-functions default-keymap)
The last line here is actually not needed and doesn't seem to do anything.
and then I do (send editor set-keymap default-keymap) for each
editor. Is that what you meant?
Yes, though I forgot exactly how the parameter value works.
This makes some emacs-like bindings work (C-a and C-e go to
beginning and end of line, C-y - yank). Is there a way to get
the more familiar {C-a - select-all, C-v - copy-selection,
etc.} bindings?
Use `add-editor-keymap-functions' in addition to
`add-text-keymap-functions'.
Actually I was already trying these, but AFAICT they don't do anything.
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6gS5kACgkQp/VmCx0OL2zM0QCeKhFeH89ymFTA+FzXoz0taFav
fXkAnjGjYenPu9gXbn+vIFFDdfGb3hdd
=sTyd
-END PGP SIGNATURE-
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robby, On 10/20/11 18:15, Robby Findler wrote: Generally, the menukey-c, menukey-v, keybindings (and friends) come about via the menus, not via a keymap% object. And those menus come in via a frame. I'm not sure how you're using your library, but you might want to consider some of the mixins in the framework whose names start with frame:. I'm actually trying to create something spreadsheet-like. I'm using editors to manage(display/edit) cell contents. Although each cell(-editor) individually doesn't have a menu, when used in a complete application there probably will be menus, and I'm planning to check out what the framework provides. However, I don't understand the logic of menus that bring about key bindings for editors. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6gTaQACgkQp/VmCx0OL2xPwQCeKkbJVMxYHBiCk3ERSmKockhM atIAoIhmA0QMroKZATMWI3xRXUWjEBc6 =7eHt -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] while resizing drawing into a canvas is off
On Thu, Oct 20, 2011 at 11:34 AM, Marijn hk...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robby, On 10/20/11 18:15, Robby Findler wrote: Generally, the menukey-c, menukey-v, keybindings (and friends) come about via the menus, not via a keymap% object. And those menus come in via a frame. I'm not sure how you're using your library, but you might want to consider some of the mixins in the framework whose names start with frame:. I'm actually trying to create something spreadsheet-like. I'm using editors to manage(display/edit) cell contents. Although each cell(-editor) individually doesn't have a menu, when used in a complete application there probably will be menus, and I'm planning to check out what the framework provides. However, I don't understand the logic of menus that bring about key bindings for editors. I'm not sure how to respond here, except to say that that's what the GUI designers of the world seem to have come up with. The keybindings that you asked for earlier (control-c and control-v for copy and paste under windows, for example (command-c and command-v on the mac)) are there because they are shortcuts for menu items, not because they are keybindings at the level of the editor. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Pre-Release Checklist for v5.2, Second Call
Checklist items for the v5.2 release (using the v5.1.900.1 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers Please use these installers (or source bundles) -- don't test from your own git clone (don't test v5.2.0.1 by mistake!). To get the tests directory in such a directory, you can do this: cd ...racket-root... git archive --remote=git://git.racket-lang.org/plt.git release \ -- collects/tests | tar x -- * John Clements cleme...@brinckerhoff.org - Stepper Tests Updates: - Stepper Updates: update HISTORY (updates should show v5.2 as the most current version; email me to pick the changes when they're done, or tell me if there are no such changes.) * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests * Noel Welsh noelwe...@gmail.com - Rackunit Tests - SRFI Tests - Ensure that all claimed srfi's are in the installer and they all load into racket or drracket (as appropriate) -- Ryan Culpepper _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Mac OS X default build: 64-bit for 10.6, 10.7
I've changed `configure' so that 64-bit mode is no longer disabled by default for Mac OS X builds. The build now uses the default mode of the compiler, which is typically 64-bit mode for Mac OS X 10.6 and 10.7. To get a 32-bit mode build when your compiler's default is 64-bit mode, configure with `--disable-mac64'. I know of no particular benefit to 64-bit mode for most programs, which use much less than 4GB of memory, and 32-bit mode is usually 10% faster (or as much as 30% faster for GC-intensive tasks). Since Racket now works fine for 64-bit Mac OS X, however, it makes sense to switch the default build mode to the system-wide default. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.2, Second Call
On 20 Oct 2011, at 8:36:28, Ryan Culpepper wrote: * Kathy Gray kathryn.g...@cl.cam.ac.uk - Test Engine Tests Done -Kathy _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] shared no longer works on cons?!?
According to my class notes from last year, the following examples worked just fine in ASL: (define web-colors (shared ([W (cons white G)] [G (cons grey W)]) W)) ; Will fail with error: ; (length web-colors) (check-expect (equal? web-colors (rest web-colors)) false) (check-expect (equal? web-colors (rest (rest web-colors))) true) (check-expect (first web-colors) white) (check-expect (first (rest web-colors)) grey) (check-expect (first (rest (rest web-colors))) white) (check-expect (first (rest (rest (rest web-colors grey) (check-expect (first (rest (rest (rest (rest web-colors) white) (check-expect (first (rest (rest (rest (rest (rest web-colors)) grey) Yet none of these work any longer: (first web-colors) first: expects a non-empty list; given (shared ((-0- (cons white (cons grey -0- -0-) (rest web-colors) rest: expects a non-empty list; given (shared ((-0- (cons white (cons grey -0- -0-) When did this change occur? And more importantly, what is the use of letting cons to be written inside shared if you can't extract it? How else is one supposed to extract from cons if not using first/rest? (Oddly, list-ref seems to work for extraction even though first and rest do not. I can anticipate numerous questions -- to which I don't know the answer -- as to why this is the case.) Several of my next few lectures depend on this working, so I'm a little dismayed by this. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
Looks like it works in 5.0.2 (November 2010) but fails in 5.1 (February 2011). The ultimate problem seems to be that deinprogramm/signature/signature-unit uses first from racket/list (checks list?, ie non-cyclic) rather than mzlib/list (only checks pair?). Ryan On 10/20/2011 08:38 PM, Shriram Krishnamurthi wrote: According to my class notes from last year, the following examples worked just fine in ASL: (define web-colors (shared ([W (cons white G)] [G (cons grey W)]) W)) ; Will fail with error: ; (length web-colors) (check-expect (equal? web-colors (rest web-colors)) false) (check-expect (equal? web-colors (rest (rest web-colors))) true) (check-expect (first web-colors) white) (check-expect (first (rest web-colors)) grey) (check-expect (first (rest (rest web-colors))) white) (check-expect (first (rest (rest (rest web-colors grey) (check-expect (first (rest (rest (rest (rest web-colors) white) (check-expect (first (rest (rest (rest (rest (rest web-colors)) grey) Yet none of these work any longer: (first web-colors) first: expects a non-empty list; given (shared ((-0- (cons white (cons grey -0- -0-) (rest web-colors) rest: expects a non-empty list; given (shared ((-0- (cons white (cons grey -0- -0-) When did this change occur? And more importantly, what is the use of letting cons to be written inside shared if you can't extract it? How else is one supposed to extract from cons if not using first/rest? (Oddly, list-ref seems to work for extraction even though first and rest do not. I can anticipate numerous questions -- to which I don't know the answer -- as to why this is the case.) Several of my next few lectures depend on this working, so I'm a little dismayed by this. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
On Thu, Oct 20, 2011 at 10:11 PM, Ryan Culpepper r...@cs.utah.edu wrote: Looks like it works in 5.0.2 (November 2010) but fails in 5.1 (February 2011). You're talking about in the teaching languages, right? In #lang racket, I see the first-produces-error behavior back to 5.0: [robby@penghu] /Applications/Racket v5.0.2/bin$ ./racket Welcome to Racket v5.0.2. (first (shared ((x (cons 1 x))) x)) first: expected argument of type non-empty list; given #0='(1 . #0#) At least for the racket language, this seems to go back at least as far as 5.0: [robby@penghu] /Applications$ ./Racket\ v5.0/bin/racket Welcome to Racket v5.0. (first (shared ((x (cons 1 x))) x)) first: expected argument of type non-empty list; given #0='(1 . #0#) The ultimate problem seems to be that deinprogramm/signature/signature-unit uses first from racket/list (checks list?, ie non-cyclic) rather than mzlib/list (only checks pair?). This looks like it was the commit that changed the behavior for the teaching languages: http://git.racket-lang.org/plt/commitdiff/c7d67f9babc2496aaf295a08264b79750785314b and judging from the commit message, the change in behavior was not intentional. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
On 10/20/2011 09:14 PM, Shriram Krishnamurthi wrote: Ryan, I noticed this seems to be a problem in full Racket as well: try #lang racket (define web-colors (shared ([W (cons white G)] [G (cons grey W)]) W)) (rest web-colors) Robby privately wrote to say it should be regarded as a bug. There seem to be conflicting intentions somewhere. Perhaps the racket/list checks were really intended to use proper-or-cyclic-list?... except that I think they were also put in place with the idea that list? was amortized constant time (cached in the pair header bits). I know Eli had to make the lazy version of first different for roughly the same reason, so maybe he can say whether this issue was considered for racket or the teaching languages. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
On Thu, Oct 20, 2011 at 10:27 PM, Ryan Culpepper r...@cs.utah.edu wrote: On 10/20/2011 09:14 PM, Shriram Krishnamurthi wrote: Ryan, I noticed this seems to be a problem in full Racket as well: try #lang racket (define web-colors (shared ([W (cons white G)] [G (cons grey W)]) W)) (rest web-colors) Robby privately wrote to say it should be regarded as a bug. There seem to be conflicting intentions somewhere. Perhaps the racket/list checks were really intended to use proper-or-cyclic-list?... except that I think they were also put in place with the idea that list? was amortized constant time (cached in the pair header bits). I know Eli had to make the lazy version of first different for roughly the same reason, so maybe he can say whether this issue was considered for racket or the teaching languages. Conflicting intentions aside, I think that this is a bug. At best, it is a failure to document a change in the behavior, but I think it is probably just a bug. (See the commit message) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
At Fri, 21 Oct 2011 05:14:28 +0200, Shriram Krishnamurthi wrote: Ryan, I noticed this seems to be a problem in full Racket as well: try #lang racket (define web-colors (shared ([W (cons white G)] [G (cons grey W)]) W)) (rest web-colors) Robby privately wrote to say it should be regarded as a bug. That is the correct behavior for `racket': `first' and `rest' work only on lists (according to `list?', which does not include cyclic lists). You can use `car' and `cdr' to access the parts of arbitrary pairs. I think `first' in ASL was intended to work on pairs, and the behavior was apparently changed by a well-meaning attempt to improve some error report. I'm not sure the old behavior is really the right thing, but we'll either fix the docs or we'll fix `first'. Meanwhile, you can use `car' and `cdr' in ASL. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
On Thu, Oct 20, 2011 at 10:29 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Robby privately wrote to say it should be regarded as a bug. That is the correct behavior for `racket': [...] Just in case this was not clear from my other messages, I still consider this a bug (not in #lang racket). Our customers (like Shriram in this case) expect things to behave in a consistent way and we should support them in that. IMO. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
Since I'm anyway providing my own custom language, can I provide car as first and cdr as rest? Can you think of any unexpected consequences offhand that would prevent that? (The only one I can think of so far is that second and friends don't work either, so I have to provide first, second, ... tenth afresh in terms of cad*r.) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
On 10/20/2011 09:24 PM, Robby Findler wrote: On Thu, Oct 20, 2011 at 10:11 PM, Ryan Culpepperr...@cs.utah.edu wrote: Looks like it works in 5.0.2 (November 2010) but fails in 5.1 (February 2011). You're talking about in the teaching languages, right? Right, I was talking about just the teaching languages. In #lang racket, I see the first-produces-error behavior back to 5.0: [robby@penghu] /Applications/Racket v5.0.2/bin$ ./racket Welcome to Racket v5.0.2. (first (shared ((x (cons 1 x))) x)) first: expected argument of typenon-empty list; given #0='(1 . #0#) At least for the racket language, this seems to go back at least as far as 5.0: [robby@penghu] /Applications$ ./Racket\ v5.0/bin/racket Welcome to Racket v5.0. (first (shared ((x (cons 1 x))) x)) first: expected argument of typenon-empty list; given #0='(1 . #0#) This behavior in the racket/scheme languages goes back to at least PLT Scheme 4.2, and probably as long as scheme/list has existed. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
Thanks for the help with the patch. But because I'm providing my own language, I think there's a cleaner solution. I anyway planned to release a new version of the course language in the morning that turned on shared printing, so this would mesh nicely. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
FWIW, the reason for the change to the teaching languages was so that 'first' doesn't say car in its error message. Robby On Thu, Oct 20, 2011 at 10:46 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Thanks for the help with the patch. But because I'm providing my own language, I think there's a cleaner solution. I anyway planned to release a new version of the course language in the morning that turned on shared printing, so this would mesh nicely. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] shared no longer works on cons?!?
Yeah, I caught that in the patch, thanks. I think it's the lesser of two evils for me right now (to export car as first, etc), and the price here is indeed very low. But thanks for the reminder, so I'm alert to it. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
