Re: [racket-dev] Pre-Release Checklist for v5.2

2011-10-20 Thread Michael Sperber

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

2011-10-20 Thread Eli Barzilay
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

2011-10-20 Thread Marijn
-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

2011-10-20 Thread Matthias Felleisen

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


Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched

2011-10-20 Thread Robby Findler
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

2011-10-20 Thread Sam Tobin-Hochstadt
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

2011-10-20 Thread Robby Findler
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

2011-10-20 Thread Eli Barzilay
An hour and a half ago, Robby Findler wrote:
 On Thu, Oct 20, 2011 at 2:08 AM, Eli Barzilay e...@barzilay.org wrote:
 
  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.
 
 It would not work if online check syntax were disabled. There would
 be a message about it in the REPL. Unless there was some reason to
 support this behavior and then we could consider having two modes
 for this REPL.

I can definitely say that I would be very surprised at such a
decision.  I see debugging syntax level code as something much more
important and needed than online syntax checking.  The latter is a
kind of a nice bonus to have, one that I could do without at a minor
cost of losing immediate reactions, but it's far less needed than a
REPL (of any kind).


  * 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...)
 
 They would continue to be disallowed via security guards. You'd get
 errors in the REPL.

Touching files and running sub-processes was a very relevant example
here.  It's something that is very useful if you want to do some C
compilation at the syntax level -- for example, to allow the runtime
code to use it (as with Jay's C-in-Racket planet package), or to find
out information from the C world (as was done with the sgl compilation
that would create a C file to find out data sizes).

So it looks like what you're talking about is not excluding these
completely -- just making the online syntax check useless when they're
used (which seems to me like a perfectly fine and even desirable
choice).  And in addition, you're saying that such a syntax REPL would
not be usable for such code -- and *that* sounds like a major
disadvantage.  If anything, it's such side-effectful code needs much
more REPL-style debugging support than the usual pure code where the
syntax stepper is perfectly fine.


 I think that this is not a big deal since most of the programs that
 run at compile time don't do this.  If they did, we'd have to
 reconsider, of course.  Even better, we might turn these
 restrictions on in 'raco setup'.

(That would be better in terms of getting everything uniform, but
it's achieving that by crippling all syntax code, making perfectly
fine tools invalid.)


 Just to be clear, what you're saying is making a tradeoff in a
 different way; getting the REPL ready slower in return for the
 ability to run more programs.

I don't see this as slower -- I see it as giving me proper
semantics to interact with since I need that to be able to debug the
code.  This is in contrast with the online syntax checker, which I
view as if you can, show extra information, otherwise don't -- no
major harm done.


 In addition to the point I made above (that I think no one cares
 about these programs), I also believe that we don't support these
 programs well as it is. Calls to particular transformers can happen
 at unpredictable times already (like when errortrace is turned on).

Yes, and that's a problem that does surprise people every once in a
while, but the online syntax checker is worse since it's not only
running the syntax level twice more -- it's running it N times based
on interaction, and worse, it will abort it mid-way every once in a
while.  Actually, the fact that people do get surprised by the current
thing is a good indication that such programs are used...


  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
 
 How do you get a module's syntax definitions into the REPL in the
 first place?

You just require it as usual.  With a slight improvement to xrepl:

  Welcome to Racket v5.2.0.1.
  - (module foo racket (define-for-syntax x 10) (define x 20))
  - ,enter foo
  'foo x
  20
  'foo (begin-for-syntax (read-eval-print-loop))
  'foo[1] x
  10

In fact, it seems to me now that this is a good approach for
implementing this -- and it also looks like there's no need to do
anything drracket...  Instead, just have some macro that does that,
so instead of that long thing you just type something like (meta!) or
something similar.  (The only drr extension would be to make the
prompt show where you are.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
   

Re: [racket-dev] 5.2.0.1: displayln appears to write to console from where drracket was launched

2011-10-20 Thread Sam Tobin-Hochstadt
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

2011-10-20 Thread Marijn
-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

2011-10-20 Thread Matthew Flatt
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

2011-10-20 Thread Robby Findler
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

2011-10-20 Thread Marijn
-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

2011-10-20 Thread Marijn
-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

2011-10-20 Thread Robby Findler
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

2011-10-20 Thread Ryan Culpepper
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

2011-10-20 Thread Matthew Flatt
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

2011-10-20 Thread Kathy Gray

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?!?

2011-10-20 Thread Shriram Krishnamurthi
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?!?

2011-10-20 Thread Ryan Culpepper
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?!?

2011-10-20 Thread Shriram Krishnamurthi
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.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] shared no longer works on cons?!?

2011-10-20 Thread Robby Findler
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?!?

2011-10-20 Thread Ryan Culpepper

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?!?

2011-10-20 Thread Robby Findler
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?!?

2011-10-20 Thread Matthew Flatt
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?!?

2011-10-20 Thread Robby Findler
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?!?

2011-10-20 Thread Shriram Krishnamurthi
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?!?

2011-10-20 Thread Ryan Culpepper

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?!?

2011-10-20 Thread Shriram Krishnamurthi
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?!?

2011-10-20 Thread Robby Findler
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?!?

2011-10-20 Thread Shriram Krishnamurthi
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