[racket-users] Hi all, I need help in racket

2015-11-27 Thread Alejandro López
I would like to  clicking on a window, then appears an image and go counting 
each pair is a picture and impar is other image.
for example first click=image1 second click =image2 third click=image1 fourth 
click= image2 5 = image1 etc ...

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] change DrRacket syntax coloring per-source rather than per-lang?

2015-11-27 Thread mb
In `#lang pollen`, which uses a variant of at-expressions, you can change the 
command character on a per-source-file basis, so you can say `◊(+ 1 1)` or `∆(+ 
1 1)` or `@(+ 1 1)` ...

I'm trying to figure out if I can bubble this up to DrRacket for syntax 
coloring. I see two wrinkles:

1) For syntax-coloring purposes, the command character is set in the `get-info` 
function for the #lang, which in pollen looks like this:

(define (get-info in mod line col pos)
  (λ (key default)
(case key
  [(color-lexer)
   (define make-scribble-inside-lexer2
 (dynamic-require 'syntax-color/scribble-lexer 
'make-scribble-inside-lexer (λ () #f)))
   (cond [make-scribble-inside-lexer2
  (make-scribble-inside-lexer2 #:command-char #\◊)]
 [else default])]
  [else default])))


I could set the command character properly if I had access to the path of the 
source file. But IIUC DrRacket invokes the `get-info` for a #lang on a "global" 
basis, i.e., before it considers any source-specific information.


2) DrRacket seems to cache the result of `get-info` for a whole session. So 
even if I could set the command character correctly for the first source file, 
it wouldn't change if I had multiple source files open with multiple command 
characters (in different tabs or windows).




-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] change DrRacket syntax coloring per-source rather than per-lang?

2015-11-27 Thread Robby Findler
I think that you have to make the syntax colorer discover which is the
@ character in the same way "#lang pollen" discovers it and then pass
that along to the scribble-inside-lexer. (This may require changing
scribble-inside-lexer to be more flexible in when it accepts the
character.) Lexers have a way to track context information (via the
"mode" argument and the last result) and so that can be extended to
track whether or not the character has been seen yet and, if it has,
what it is.

Robby


On Fri, Nov 27, 2015 at 10:09 AM,   wrote:
> In `#lang pollen`, which uses a variant of at-expressions, you can change the 
> command character on a per-source-file basis, so you can say `◊(+ 1 1)` or 
> `∆(+ 1 1)` or `@(+ 1 1)` ...
>
> I'm trying to figure out if I can bubble this up to DrRacket for syntax 
> coloring. I see two wrinkles:
>
> 1) For syntax-coloring purposes, the command character is set in the 
> `get-info` function for the #lang, which in pollen looks like this:
>
> (define (get-info in mod line col pos)
>   (λ (key default)
> (case key
>   [(color-lexer)
>(define make-scribble-inside-lexer2
>  (dynamic-require 'syntax-color/scribble-lexer 
> 'make-scribble-inside-lexer (λ () #f)))
>(cond [make-scribble-inside-lexer2
>   (make-scribble-inside-lexer2 #:command-char #\◊)]
>  [else default])]
>   [else default])))
>
>
> I could set the command character properly if I had access to the path of the 
> source file. But IIUC DrRacket invokes the `get-info` for a #lang on a 
> "global" basis, i.e., before it considers any source-specific information.
>
>
> 2) DrRacket seems to cache the result of `get-info` for a whole session. So 
> even if I could set the command character correctly for the first source 
> file, it wouldn't change if I had multiple source files open with multiple 
> command characters (in different tabs or windows).
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] DrRacket fights `racket` on print behavior in `#lang racket/base`

2015-11-27 Thread Paolo Giarrusso
Here's an example showing that this test will not behave consistently in 
DrRacket and Racket, because `print` won't.

Is that a bug, or is it a "bad practice (tm)" that I ever use `print` 
programmatically and expect specific output? Take the question as "me learning 
Racket, somewhat chaotically" :-).
(This question arose in the context of another thread, but I'd like the version 
without the context).

```
#lang racket/base

(require rackunit
 racket/format)

(struct posn (x y) #:transparent)
(struct game-state (speed circle target) #:transparent)
(define p (posn 150 100))
(list (game-state p p p))

; This test works in DrRacket and fails with `racket -t $ThisFile`
(check-equal? (~v (list (game-state p p p))) "(list (game-state (posn 150 100) 
(posn 150 100) (posn 150 100)))")
```

The `print` statement produces `(list (game-state (posn 150 100) (posn 150 100) 
(posn 150 100)))` in DrRacket and `(list (game-state #0=(posn 150 100) #0# 
#0#))` otherwise:

```
$ racket -t printing.rkt
(list (game-state #0=(posn 150 100) #0# #0#))

FAILURE
actual: "(list (game-state #0=(posn 150 100) #0# #0#))"
expected:   "(list (game-state (posn 150 100) (posn 150 100) (posn 150 100)))"
name:   check-equal?
location:   
(#
 13 0 279 112)
expression: (check-equal? (~v (list (game-state p p p))) "(list (game-state 
(posn 150 100) (posn 150 100) (posn 150 100)))")

Check failure

```

I thought this boiled down to `print-graph`, but it's already false. I also 
looked into `(current-print)`, thanks Benjamin Greenman's suggestion, but that 
seems to only affect the REPL behavior, not print's.

Cheers,
Paolo

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Value printing in REPL and for students

2015-11-27 Thread Paolo Giarrusso
On 27 November 2015 at 03:48, Robby Findler  wrote:
> DrRacket pulls some shenanigans with the language dialog-based
> teaching languages and it needs some adjust to make things work the
> way you want with printing in 'raco test' and 'racket'.

I fear I've seen that — but this goes beyond teaching languages. I've
opened a separate thread for that.

> Probably there
> isn't a simple path to that precise goal, but maybe there is a way to
> another goal?

> Is it the case that you're trying to get things set up so that output
> that you produce running inside the handin server is suitable to be
> presented to students so that you can tell them that their submission
> failed somehow?

Yeah. With the complication that I'm also running tests of my own. And
that we're perfectionist PhD students, so we're trying to have
checkers with the same quality as the other HtDP material, without
being Racket experts. Mid-semester.

> (In which case, I might just prefix the error message
> with "This is not exactly the error that you will see in DrRacket,
> where you'll get a clearer message. Please run your program there.")

Yeah, I'm afraid we'll have to do something like that. But then, I
also need to reimplement `!test` because of different requirements:
our checkers have tests that users don't have, and must pretty-print
results to report errso

Luckily, I can still copy more of it :-). Meanwhile, I've rediscovered
the libraries in the handin-server which try to do that. There's code
using mzlib/pconvert which gives me more hope, however legacy that
library is declared.

> My hope is to find time to get the #lang htdp/bsl (etc) languages up
> to stuff so that my advice would switch to "use #lang htdp/bsl and all
> will be fine" but I'm not there yet.

That'd be... cool! At least Racket-generated errors would be better.
Still, that doesn't help when implementing `!test` — unless I managed
to do (!eval `(print ,v)). Should try that.

Cheers,
Paolo

> On Thu, Nov 26, 2015 at 6:16 PM, Paolo Giarrusso  
> wrote:
>> Hi all!
>>
>> How does the REPL print values? In some circumstances I see graph printing 
>> markers, even though `(print-graph)` is disabled. Because these are error 
>> messages for students using teaching languages, cycle printing is not an 
>> option.
>>
>> messages.rkt> (print-graph)
>> #f
>> messages.rkt> (list (game-state p p p))
>> (list (game-state (posn 150 100) (posn 150 100) (posn 150 100)))
>> messages.rkt> (~v (list (game-state p p p)))
>> "(list (game-state #0=(posn 150 100) #0# #0#))"
>>
>> Funnily, that doesn't happen in DrRacket, but it does happen both in 
>> racket-mode, in my actual production environment, and under raco test. In 
>> particular, test results in DrRacket are the ones I'd want, but are 
>> inconsistent with the ones everywhere else.
>>
>> Apart from being frustrated at parameters, how do I gain control over this?
>>
>> PS: I've just found that `global-port-print-handler` is customized by 
>> DrRacket. That seems incompatible with using `print` and relying on it 
>> producing certain results. I understand that's the point of `print`, but 
>> neither `write` nor `display` does what I want.
>>
>> HTDP code itself uses `~e` (also in htdp/error), but finding the appropriate 
>> handler to install isn't trivial either; and that's not enough, because 
>> sometimes I need to show the source code we evaluated.
>>
>> Sorry for how chaotic is this message — I guess that reflects my confusion 
>> at Racket printing. (I've taken some looks at the relevant documentation, 
>> but not at all of it).
>>
>> Cheers,
>> Paolo
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.



-- 
Paolo G. Giarrusso - Ph.D. Student, Tübingen University
http://ps.informatik.uni-tuebingen.de/team/giarrusso/

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Value printing in REPL and for students

2015-11-27 Thread Robby Findler
I've added "check over/improve handin support" to my teaching
languages list of things to fix. :)

You should be able to get close pretty easily if you first do
print-convert and then do pretty-write. You will want to tweak the
parameters that control print-convert based on which language level
you're using. Or, it may be better to run the test, discover it fails,
and then print out the source code of the test to send back to the
students instead of sending back the result (well, you could send back
"wrong answer", "got an error", or "timed out" or something granular
like that).

hth,
Robby


On Fri, Nov 27, 2015 at 6:57 AM, Paolo Giarrusso  wrote:
> On 27 November 2015 at 03:48, Robby Findler  
> wrote:
>> DrRacket pulls some shenanigans with the language dialog-based
>> teaching languages and it needs some adjust to make things work the
>> way you want with printing in 'raco test' and 'racket'.
>
> I fear I've seen that — but this goes beyond teaching languages. I've
> opened a separate thread for that.
>
>> Probably there
>> isn't a simple path to that precise goal, but maybe there is a way to
>> another goal?
>
>> Is it the case that you're trying to get things set up so that output
>> that you produce running inside the handin server is suitable to be
>> presented to students so that you can tell them that their submission
>> failed somehow?
>
> Yeah. With the complication that I'm also running tests of my own. And
> that we're perfectionist PhD students, so we're trying to have
> checkers with the same quality as the other HtDP material, without
> being Racket experts. Mid-semester.
>
>> (In which case, I might just prefix the error message
>> with "This is not exactly the error that you will see in DrRacket,
>> where you'll get a clearer message. Please run your program there.")
>
> Yeah, I'm afraid we'll have to do something like that. But then, I
> also need to reimplement `!test` because of different requirements:
> our checkers have tests that users don't have, and must pretty-print
> results to report errso
>
> Luckily, I can still copy more of it :-). Meanwhile, I've rediscovered
> the libraries in the handin-server which try to do that. There's code
> using mzlib/pconvert which gives me more hope, however legacy that
> library is declared.
>
>> My hope is to find time to get the #lang htdp/bsl (etc) languages up
>> to stuff so that my advice would switch to "use #lang htdp/bsl and all
>> will be fine" but I'm not there yet.
>
> That'd be... cool! At least Racket-generated errors would be better.
> Still, that doesn't help when implementing `!test` — unless I managed
> to do (!eval `(print ,v)). Should try that.
>
> Cheers,
> Paolo
>
>> On Thu, Nov 26, 2015 at 6:16 PM, Paolo Giarrusso  
>> wrote:
>>> Hi all!
>>>
>>> How does the REPL print values? In some circumstances I see graph printing 
>>> markers, even though `(print-graph)` is disabled. Because these are error 
>>> messages for students using teaching languages, cycle printing is not an 
>>> option.
>>>
>>> messages.rkt> (print-graph)
>>> #f
>>> messages.rkt> (list (game-state p p p))
>>> (list (game-state (posn 150 100) (posn 150 100) (posn 150 100)))
>>> messages.rkt> (~v (list (game-state p p p)))
>>> "(list (game-state #0=(posn 150 100) #0# #0#))"
>>>
>>> Funnily, that doesn't happen in DrRacket, but it does happen both in 
>>> racket-mode, in my actual production environment, and under raco test. In 
>>> particular, test results in DrRacket are the ones I'd want, but are 
>>> inconsistent with the ones everywhere else.
>>>
>>> Apart from being frustrated at parameters, how do I gain control over this?
>>>
>>> PS: I've just found that `global-port-print-handler` is customized by 
>>> DrRacket. That seems incompatible with using `print` and relying on it 
>>> producing certain results. I understand that's the point of `print`, but 
>>> neither `write` nor `display` does what I want.
>>>
>>> HTDP code itself uses `~e` (also in htdp/error), but finding the 
>>> appropriate handler to install isn't trivial either; and that's not enough, 
>>> because sometimes I need to show the source code we evaluated.
>>>
>>> Sorry for how chaotic is this message — I guess that reflects my confusion 
>>> at Racket printing. (I've taken some looks at the relevant documentation, 
>>> but not at all of it).
>>>
>>> Cheers,
>>> Paolo
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Paolo G. Giarrusso - Ph.D. Student, Tübingen University
> http://ps.informatik.uni-tuebingen.de/team/giarrusso/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To 

Re: [racket-users] Racket v6.3

2015-11-27 Thread Robby Findler
Those are menu items that DrRacket updates via a callback that happens when
you click on the menubar, something that has been problematic in the past.
I could change DrRacket to avoid doing the update at that time, if that's
necessary.

The "open recent" submenu in the "file" menu also does stuff like that, but
it follows up the changes with a callback to repeat them because that one
seems to be more problematic than the changes that happen to the View menu.

Do you see reasonable content in the "open recent" menu item? ANd if not,
what happens if you open and close a new window and then check again?

Robby



On Fri, Nov 27, 2015 at 3:03 AM, John Berry  wrote:

> Under OS X Yosemite I get some odd behavior with the menus. My view menu
> has missing items, and the windows menu does nothing at all.  See picture
> below:
>
> ​
>
> On Tue, Nov 24, 2015 at 6:34 AM, Ryan Culpepper  wrote:
>
>> Racket version 6.3 is now available from
>>
>> http://racket-lang.org/
>>
>> - Racket's macro expander uses a new representation of binding called
>>   "set of scopes". The new binding model provides a simpler
>>   explanation of how macros preserve binding, especially across module
>>   boundaries and in hygiene-bending expansions. The new expander is
>>   mostly compatible with existing Racket macros, but there are some
>>   incompatibilities. For the formally inclined, a research paper on
>>   this macro system will appear at POPL next year:
>>
>>   http://www.cs.utah.edu/plt/scope-sets/
>>
>> - Racket's GUI library now uses Gtk+ 3 when available, instead of Gtk+
>>   2. Set the `PLT_GTK2` environment variable to select Gtk+ 2.
>>
>> - Added a new Redex tutorial based on a week-long workshop in SLC.
>>
>> - Better syntax error checking for Redex patterns that do not use
>>   holes correctly.
>>
>> - The blueboxes are more agressive about finding names to look up in
>>   the docs, meaning they are useful much more often.
>>
>> - Submodules are now fully supported in Typed Racket. Previously, some
>>   uses of submodules would produce internal errors, making it hard to
>>   `module+ test` and `module+ main` effectively in Typed Racket. The
>>   switch to the set-of-scopes expander fixed these problems, and
>>   submodules are now happily at home in Typed Racket.
>>
>> - The `typed/racket/unsafe` library provides import and export forms
>>   that circumvent contract generation. This improves performance for
>>   typed-untyped interaction at the cost of safety and debuggability.
>>
>> - Typed Racket provides experimental support for units (from
>>   `racket/unit`).
>>
>> - The experimental `define-new-subtype` form allows overlaying finer
>>   distinctions between otherwise identical types, similar to Haskell's
>>   `newtype`.
>>
>> - The `Promise` type constructor changes in a backwards-incompatible
>>   way to exclude promises created with `promise/name`.
>>
>> - The `unstable-*` packages are out of the main distribution. Most of
>>   their contents have been either merged with established Racket
>>   libraries or spun off as their own packages. This change is
>>   backwards compatible for packages that properly list their
>>   dependencies. Full details:
>>   http://blog.racket-lang.org/2015/10/retiring-unstable.html
>>
>> - edu: `big-bang` supports a display-mode clause so that world
>>   programs can take over the entire screen.
>>
>> Feedback welcome
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] DrRacket fights `racket` on print behavior in `#lang racket/base`

2015-11-27 Thread George Neuner
It's definitely due to printing the values.  Notice that it also happens 
in DrRacket when "show sharing in values" is selected on the Choose 
Language dialog.


I'm not aware of a way to prevent the reader from creating objects with 
shared structure.  You can explicitly disallow use of the #0= sharing 
syntax for input, but that has no impact on the object graph output by 
the reader.


If you deliberately create an unshared structure (by copying), the check 
passes in racket.  e.g.,


:
(define shared   (list (game-state p p p)))
(define unshared (list (game-state (struct-copy posn p)
   (struct-copy posn p)
   (struct-copy posn p


(check-equal? (~v shared) "(list (game-state (posn 150 100) (posn 
150 100) (posn 150 100)))")
(check-equal? (~v unshared) "(list (game-state (posn 150 100) (posn 
150 100) (posn 150 100)))")

:

When you substitute this in your code you get the check failure only on 
the structure sharing version.



Also notice that

(check-equal? (~v shared) "(list (game-state #0=(posn 150 100) #0# 
#0#))")


works consistently.   The problem there is being certain your check 
string exactly matches the #?# numbers as they would be printed.  AFAIK, 
the numbers reset to zero for each object, but with a complicated graph, 
it's easy to make a mistake writing the check string.



For checking individual objects, my advice is to use check-pred. 
Although check-equal? works with static objects, IMO it's really meant 
for tests that aren't normally executed - e.g., for comparing results of 
different computation methods: the fast "clever" version vs the slow 
"brute force" version.  MMV ... people have different ideas regarding 
appropriate uses of testing.



Hope this helps,
George



On 11/27/2015 7:13 AM, Paolo Giarrusso wrote:

Here's an example showing that this test will not behave consistently in 
DrRacket and Racket, because `print` won't.

Is that a bug, or is it a "bad practice (tm)" that I ever use `print` programmatically 
and expect specific output? Take the question as "me learning Racket, somewhat 
chaotically" :-).
(This question arose in the context of another thread, but I'd like the version 
without the context).

```
#lang racket/base

(require rackunit
  racket/format)

(struct posn (x y) #:transparent)
(struct game-state (speed circle target) #:transparent)
(define p (posn 150 100))
(list (game-state p p p))

; This test works in DrRacket and fails with `racket -t $ThisFile`
(check-equal? (~v (list (game-state p p p))) "(list (game-state (posn 150 100) (posn 
150 100) (posn 150 100)))")
```

The `print` statement produces `(list (game-state (posn 150 100) (posn 150 100) 
(posn 150 100)))` in DrRacket and `(list (game-state #0=(posn 150 100) #0# 
#0#))` otherwise:

```
$ racket -t printing.rkt
(list (game-state #0=(posn 150 100) #0# #0#))

FAILURE
actual: "(list (game-state #0=(posn 150 100) #0# #0#))"
expected:   "(list (game-state (posn 150 100) (posn 150 100) (posn 150 100)))"
name:   check-equal?
location:   
(#
 13 0 279 112)
expression: (check-equal? (~v (list (game-state p p p))) "(list (game-state (posn 
150 100) (posn 150 100) (posn 150 100)))")

Check failure

```

I thought this boiled down to `print-graph`, but it's already false. I also 
looked into `(current-print)`, thanks Benjamin Greenman's suggestion, but that 
seems to only affect the REPL behavior, not print's.

Cheers,
Paolo





--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] change DrRacket syntax coloring per-source rather than per-lang?

2015-11-27 Thread mb
Sorry for the noob question, but broadly, how does one affect the behavior of 
the syntax colorer (and thereby the lexer) from the #lang (if not through 
`get-info`)?


On Friday, November 27, 2015 at 8:37:47 AM UTC-8, Robby Findler wrote:
> I think that you have to make the syntax colorer discover which is the
> @ character in the same way "#lang pollen" discovers it and then pass
> that along to the scribble-inside-lexer. (This may require changing
> scribble-inside-lexer to be more flexible in when it accepts the
> character.) Lexers have a way to track context information (via the
> "mode" argument and the last result) and so that can be extended to
> track whether or not the character has been seen yet and, if it has,
> what it is.
> 
> Robby
> 
> 
> On Fri, Nov 27, 2015 at 10:09 AM, MB wrote:
> > In `#lang pollen`, which uses a variant of at-expressions, you can change 
> > the command character on a per-source-file basis, so you can say `◊(+ 1 1)` 
> > or `∆(+ 1 1)` or `@(+ 1 1)` ...
> >
> > I'm trying to figure out if I can bubble this up to DrRacket for syntax 
> > coloring. I see two wrinkles:
> >
> > 1) For syntax-coloring purposes, the command character is set in the 
> > `get-info` function for the #lang, which in pollen looks like this:
> >
> > (define (get-info in mod line col pos)
> >   (λ (key default)
> > (case key
> >   [(color-lexer)
> >(define make-scribble-inside-lexer2
> >  (dynamic-require 'syntax-color/scribble-lexer 
> > 'make-scribble-inside-lexer (λ () #f)))
> >(cond [make-scribble-inside-lexer2
> >   (make-scribble-inside-lexer2 #:command-char #\◊)]
> >  [else default])]
> >   [else default])))
> >
> >
> > I could set the command character properly if I had access to the path of 
> > the source file. But IIUC DrRacket invokes the `get-info` for a #lang on a 
> > "global" basis, i.e., before it considers any source-specific information.
> >
> >
> > 2) DrRacket seems to cache the result of `get-info` for a whole session. So 
> > even if I could set the command character correctly for the first source 
> > file, it wouldn't change if I had multiple source files open with multiple 
> > command characters (in different tabs or windows).

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] change DrRacket syntax coloring per-source rather than per-lang?

2015-11-27 Thread Robby Findler
That is indeed how.

But now that looked at the pollen docs, I see the issue. It looks like
you have to be able to run the config submodule of some program to be
able to figure out how to syntax color it? That's not generally
something that is well-supported, although I suppose you could make it
work. There are some dicey questions, tho, like what if the config
submodule has a definition like this:

#lang racket/base
(define (tuesday?)
  (= (date-week-day (second->date (current-seconds)))
 2))
(define command-char (if (tuesday?) #\◊ #\☺))


Then if I compiled a file on tueday and ran it on wednesday things
wouldn't really be doing the right thing.

The usual way we deal with configuration at that level would be to
allow someone to write, say.

#lang pollen command-char ☺

and, as long as the "command-char" declaration appears on the first
line, then the pollen reader would respect it and change the
command-char.

And one could, without too much trouble, define "#lang spollen" that
was a shorthand for "#lang pollen command-char ☺".

(If that all seems reasonable, then my original reply would apply.)

Robby



On Fri, Nov 27, 2015 at 3:42 PM,   wrote:
> Sorry for the noob question, but broadly, how does one affect the behavior of 
> the syntax colorer (and thereby the lexer) from the #lang (if not through 
> `get-info`)?
>
>
> On Friday, November 27, 2015 at 8:37:47 AM UTC-8, Robby Findler wrote:
>> I think that you have to make the syntax colorer discover which is the
>> @ character in the same way "#lang pollen" discovers it and then pass
>> that along to the scribble-inside-lexer. (This may require changing
>> scribble-inside-lexer to be more flexible in when it accepts the
>> character.) Lexers have a way to track context information (via the
>> "mode" argument and the last result) and so that can be extended to
>> track whether or not the character has been seen yet and, if it has,
>> what it is.
>>
>> Robby
>>
>>
>> On Fri, Nov 27, 2015 at 10:09 AM, MB wrote:
>> > In `#lang pollen`, which uses a variant of at-expressions, you can change 
>> > the command character on a per-source-file basis, so you can say `◊(+ 1 
>> > 1)` or `∆(+ 1 1)` or `@(+ 1 1)` ...
>> >
>> > I'm trying to figure out if I can bubble this up to DrRacket for syntax 
>> > coloring. I see two wrinkles:
>> >
>> > 1) For syntax-coloring purposes, the command character is set in the 
>> > `get-info` function for the #lang, which in pollen looks like this:
>> >
>> > (define (get-info in mod line col pos)
>> >   (λ (key default)
>> > (case key
>> >   [(color-lexer)
>> >(define make-scribble-inside-lexer2
>> >  (dynamic-require 'syntax-color/scribble-lexer 
>> > 'make-scribble-inside-lexer (λ () #f)))
>> >(cond [make-scribble-inside-lexer2
>> >   (make-scribble-inside-lexer2 #:command-char #\◊)]
>> >  [else default])]
>> >   [else default])))
>> >
>> >
>> > I could set the command character properly if I had access to the path of 
>> > the source file. But IIUC DrRacket invokes the `get-info` for a #lang on a 
>> > "global" basis, i.e., before it considers any source-specific information.
>> >
>> >
>> > 2) DrRacket seems to cache the result of `get-info` for a whole session. 
>> > So even if I could set the command character correctly for the first 
>> > source file, it wouldn't change if I had multiple source files open with 
>> > multiple command characters (in different tabs or windows).
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Racket v6.3

2015-11-27 Thread Robby Findler
Yeah, that's the same issue. DrRacket tries to update that menu in the time
after you click on the menubar, before the menus are displayed. It then
also follows up with a callback later to do it again since that first
attempt can fail.

This is something that probably requires a different strategy at the
DrRacket level, but I'm not sure what's the right approach. It may be best
for DrRacket to just stop using the on-demand callback (altho that callback
is very convenient!).

Robby


On Fri, Nov 27, 2015 at 8:59 AM, Jens Axel Søgaard 
wrote:

> FWIW there is a small annoyance (bug?) with the open recent menu.
> If as the first thing after starting DrRacket, one touches "File" and then
> "Open Recent" then
> then no files are displayed. Choosing "Open Recent" again will work though.
>
> /Jens Axel
>
>
> 2015-11-27 15:42 GMT+01:00 Robby Findler :
>
>> Those are menu items that DrRacket updates via a callback that happens
>> when you click on the menubar, something that has been problematic in the
>> past. I could change DrRacket to avoid doing the update at that time, if
>> that's necessary.
>>
>> The "open recent" submenu in the "file" menu also does stuff like that,
>> but it follows up the changes with a callback to repeat them because that
>> one seems to be more problematic than the changes that happen to the View
>> menu.
>>
>> Do you see reasonable content in the "open recent" menu item? ANd if not,
>> what happens if you open and close a new window and then check again?
>>
>> Robby
>>
>>
>>
>> On Fri, Nov 27, 2015 at 3:03 AM, John Berry  wrote:
>>
>>> Under OS X Yosemite I get some odd behavior with the menus. My view menu
>>> has missing items, and the windows menu does nothing at all.  See picture
>>> below:
>>>
>>> ​
>>>
>>> On Tue, Nov 24, 2015 at 6:34 AM, Ryan Culpepper 
>>> wrote:
>>>
 Racket version 6.3 is now available from

 http://racket-lang.org/

 - Racket's macro expander uses a new representation of binding called
   "set of scopes". The new binding model provides a simpler
   explanation of how macros preserve binding, especially across module
   boundaries and in hygiene-bending expansions. The new expander is
   mostly compatible with existing Racket macros, but there are some
   incompatibilities. For the formally inclined, a research paper on
   this macro system will appear at POPL next year:

   http://www.cs.utah.edu/plt/scope-sets/

 - Racket's GUI library now uses Gtk+ 3 when available, instead of Gtk+
   2. Set the `PLT_GTK2` environment variable to select Gtk+ 2.

 - Added a new Redex tutorial based on a week-long workshop in SLC.

 - Better syntax error checking for Redex patterns that do not use
   holes correctly.

 - The blueboxes are more agressive about finding names to look up in
   the docs, meaning they are useful much more often.

 - Submodules are now fully supported in Typed Racket. Previously, some
   uses of submodules would produce internal errors, making it hard to
   `module+ test` and `module+ main` effectively in Typed Racket. The
   switch to the set-of-scopes expander fixed these problems, and
   submodules are now happily at home in Typed Racket.

 - The `typed/racket/unsafe` library provides import and export forms
   that circumvent contract generation. This improves performance for
   typed-untyped interaction at the cost of safety and debuggability.

 - Typed Racket provides experimental support for units (from
   `racket/unit`).

 - The experimental `define-new-subtype` form allows overlaying finer
   distinctions between otherwise identical types, similar to Haskell's
   `newtype`.

 - The `Promise` type constructor changes in a backwards-incompatible
   way to exclude promises created with `promise/name`.

 - The `unstable-*` packages are out of the main distribution. Most of
   their contents have been either merged with established Racket
   libraries or spun off as their own packages. This change is
   backwards compatible for packages that properly list their
   dependencies. Full details:
   http://blog.racket-lang.org/2015/10/retiring-unstable.html

 - edu: `big-bang` supports a display-mode clause so that world
   programs can take over the entire screen.

 Feedback welcome

 --
 You received this message because you are subscribed to the Google
 Groups "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Racket Users" group.
>>> To unsubscribe 

Re: [racket-users] Racket v6.3

2015-11-27 Thread John Berry
Under OS X Yosemite I get some odd behavior with the menus. My view menu
has missing items, and the windows menu does nothing at all.  See picture
below:

​

On Tue, Nov 24, 2015 at 6:34 AM, Ryan Culpepper  wrote:

> Racket version 6.3 is now available from
>
> http://racket-lang.org/
>
> - Racket's macro expander uses a new representation of binding called
>   "set of scopes". The new binding model provides a simpler
>   explanation of how macros preserve binding, especially across module
>   boundaries and in hygiene-bending expansions. The new expander is
>   mostly compatible with existing Racket macros, but there are some
>   incompatibilities. For the formally inclined, a research paper on
>   this macro system will appear at POPL next year:
>
>   http://www.cs.utah.edu/plt/scope-sets/
>
> - Racket's GUI library now uses Gtk+ 3 when available, instead of Gtk+
>   2. Set the `PLT_GTK2` environment variable to select Gtk+ 2.
>
> - Added a new Redex tutorial based on a week-long workshop in SLC.
>
> - Better syntax error checking for Redex patterns that do not use
>   holes correctly.
>
> - The blueboxes are more agressive about finding names to look up in
>   the docs, meaning they are useful much more often.
>
> - Submodules are now fully supported in Typed Racket. Previously, some
>   uses of submodules would produce internal errors, making it hard to
>   `module+ test` and `module+ main` effectively in Typed Racket. The
>   switch to the set-of-scopes expander fixed these problems, and
>   submodules are now happily at home in Typed Racket.
>
> - The `typed/racket/unsafe` library provides import and export forms
>   that circumvent contract generation. This improves performance for
>   typed-untyped interaction at the cost of safety and debuggability.
>
> - Typed Racket provides experimental support for units (from
>   `racket/unit`).
>
> - The experimental `define-new-subtype` form allows overlaying finer
>   distinctions between otherwise identical types, similar to Haskell's
>   `newtype`.
>
> - The `Promise` type constructor changes in a backwards-incompatible
>   way to exclude promises created with `promise/name`.
>
> - The `unstable-*` packages are out of the main distribution. Most of
>   their contents have been either merged with established Racket
>   libraries or spun off as their own packages. This change is
>   backwards compatible for packages that properly list their
>   dependencies. Full details:
>   http://blog.racket-lang.org/2015/10/retiring-unstable.html
>
> - edu: `big-bang` supports a display-mode clause so that world
>   programs can take over the entire screen.
>
> Feedback welcome
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.