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

[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

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

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

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

[Ryan Culpepper]

On 10/20/2011 09:24 PM, Robby Findler wrote:

On Thu, Oct 20, 2011 at 10:11 PM, Ryan Culpepper  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 type; 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; 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?!?

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

[Robby Findler]

On Thu, Oct 20, 2011 at 10:29 PM, Matthew Flatt  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?!?

[Robby Findler]

Shriram,

  In case you didn't follow the implication of Ryan's message, you can
the diff below to your tree and your program below will run (I tested
by applying the diff to the latest git version, but I think it will
still work for 5.1.3.)

If you wish, you can make a .plt file that you can distribute to your
students via a web page (they would have to use File|Install .plt file
to install it), that will also apply this diff to their installations
of 5.1.3 (I suggest you also put something into the .plt file that
changes the version number to avoid possible confusion).

I hope this helps.

Robby

[robby@yanpu] ~/git/plt/collects/deinprogramm$ git diff
diff --git a/collects/deinprogramm/signature/signature-unit.rkt
b/collects/deinprogramm/signature/si
index 2059bb7..c608317 100644
--- a/collects/deinprogramm/signature/signature-unit.rkt
+++ b/collects/deinprogramm/signature/signature-unit.rkt
@@ -5,7 +5,7 @@

 (require scheme/promise
 mzlib/struct
- (only-in racket/list first rest)
+ (only-in mzlib/list first rest)
 (for-syntax scheme/base)
 (for-syntax stepper/private/shared))

[robby@yanpu] ~/git/plt/collects/deinprogramm$



On Thu, Oct 20, 2011 at 9: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?!?

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

[Robby Findler]

On Thu, Oct 20, 2011 at 10:27 PM, Ryan Culpepper  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?!?

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

[Robby Findler]

On Thu, Oct 20, 2011 at 10:11 PM, Ryan Culpepper  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 ; 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 ; 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?!?

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

[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

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

[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] Pre-Release Checklist for v5.2, Second Call

[Kathy Gray]

On 20 Oct 2011, at 8:36:28, Ryan Culpepper wrote:

> * Kathy Gray 
>  - Test Engine Tests

Done
-Kathy
_
  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

[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

[racket-dev] Pre-Release Checklist for v5.2, Second Call

[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 
  - 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 
  - Test Engine Tests

* Noel Welsh 
  - 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

Re: [racket-dev] while resizing drawing into a canvas is off

[Robby Findler]

On Thu, Oct 20, 2011 at 11:34 AM, Marijn  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Robby,
>
> On 10/20/11 18:15, Robby Findler wrote:
>> Generally, the -c, -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

Re: [racket-dev] while resizing drawing into a canvas is off

[Marijn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Robby,

On 10/20/11 18:15, Robby Findler wrote:
> Generally, the -c, -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

[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

[Robby Findler]

Generally, the -c, -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  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

[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

[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] 5.2.0.1: displayln appears to write to console from where drracket was launched

[Sam Tobin-Hochstadt]

On Thu, Oct 20, 2011 at 9:29 AM, Robby Findler
 wrote:
> On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt  
> 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] 5.2.0.1: displayln appears to write to console from where drracket was launched

[Eli Barzilay]

An hour and a half ago, Robby Findler wrote:
> On Thu, Oct 20, 2011 at 2:08 AM, Eli Barzilay  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.)

-- 
  ((lam

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

[Robby Findler]

On Thu, Oct 20, 2011 at 8:25 AM, Sam Tobin-Hochstadt  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

[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"  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

[Robby Findler]

On Thu, Oct 20, 2011 at 8:16 AM, Matthias Felleisen
 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

[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] while resizing drawing into a canvas is off

[Matthew Flatt]

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.

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).

> 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.

_
  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

[Robby Findler]

On Thu, Oct 20, 2011 at 2:08 AM, Eli Barzilay  wrote:
> 7 hours ago, Robby Findler wrote:
>> On Wed, Oct 19, 2011 at 6:56 PM, Eli Barzilay  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.

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.

> * 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.

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'.

> * 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.

It is actually doing that now, I believe. If the language dialog says
errortrace & profiling, then the code is compiled with those things
on. I'm not sure how well they work, but hey.

> * 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".

From my perspective, this is a restatement of bullet 2 (I have the
same answer, anyways).

> 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).

I think the syntax REPL would still be useful in a restricted environment.

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.

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).

>> > 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
>  ; r

Re: [racket-dev] while resizing drawing into a canvas is off

[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

[Eli Barzilay]

7 hours ago, Robby Findler wrote:
> On Wed, Oct 19, 2011 at 6:56 PM, Eli Barzilay  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