[racket-users] Racket Docker images from Alpine

2016-07-12 Thread Marc Burns

Hi all,

I remember this topic came up on the list a while back. I've made a 
Docker image of the latest Racket from alpine 3.3 with just musl libc. I 
had to monkey patch some Racket internals to get this working, so it 
might be badly and subtly broken. Feedback is appreciated!


Dockerfile etc.: https://github.com/m4burns/racket-docker
Docker repo: https://hub.docker.com/r/m4burns/racket/

The size is a little bit of an improvement over Jack Firth's images (35 
vs 22 mb). I'm not sure it's worth the uncertainty of using musl instead 
of glibc.


Enjoy!

Marc

--
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] TR could be even more spectacularly awesome:

2016-07-12 Thread Vincent St-Amour
OC gets its dead code info from TR, so the two should agree.

Vincent


On Tue, 12 Jul 2016 16:54:10 -0500,
Robby Findler wrote:
> 
> I think you are saying that TR does not declare variables in for/hash
> as dead code but that OC does. Is that what you're saying? Is that
> true?
> 
> Robby
> 
> On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
>  wrote:
> >
> > The coach is different from the type checker.
> >
> > I think that the type checker should use these colors only when type
> > checking succeeds, and in that case, I’d consider the colors highly
> > useful.
> >
> >
> >
> >
> >
> >
> >> On Jul 12, 2016, at 5:46 PM, Robby Findler  
> >> wrote:
> >>
> >> That would require too mcuh work and also be ugly, IMO. :)
> >>
> >> I think that an on-mouseover option would be too hard to discover.
> >>
> >> John raises a good point.
> >>
> >> Robby
> >>
> >>
> >> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
> >>  wrote:
> >>> I hesitate to suggest it as well, but what about the little red
> >>> squiggles seen in editors/word processors/etc?
> >>>
> >>> But I'm happy with any of these options.
> >>>
> >>> Sam
> >>>
> >>> On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
> >>>  wrote:
>  Yes.
> 
>  I hesitate to suggest it, but would a background color on the text be
>  the way to go? I find that a bit on the annoying side, tho.
> 
>  You could use an existing pipeline to do something like the unused
>  require highlighting (which requires mouseover).
> 
>  Robby
> 
>  On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
>   wrote:
> > Could this be an API like the one for tooltips? IOW, some sort of 
> > general
> > warning with a message and a syntax location?
> >
> > Sam
> >
> > On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
> > 
> > wrote:
> >>
> >> I think it would be straightforward to add something to Check Syntax
> >> that reported unreachable code and that seems pretty cool and useful
> >> for TR. So CS could report any code that TR could prove was
> >> unreachable and yet the code came from the original program. I guess
> >> if John had seen that showing up in his program it might have prompted
> >> him to figure out what the bug was?
> >>
> >> Robby
> >>
> >>
> >> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
> >>  wrote:
> >>>
>  On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
>  
>  wrote:
> 
> >
> > 2) Is there some nice user interface that we could use to make the
> > warnings visible to the case of the user? Maybe a “I think I have a 
> > bug, can
> > I see the compilation warnings” button?
> 
>  I agree -- I think we need a better story generally for warning UI in
>  Racket, but I don't know what the right solution is.
> >>>
> >>>
> >>> [Sorry John, I overlooked your questions.]
> >>>
> >>>
> >>> Instead of watching warnings scroll by in some widget, I’d rather see
> >>> the coloring solution for testing from the teaching languages adapted 
> >>> to TR.
> >>>
> >>> At a minimum, I could see two colors:
> >>>
> >>> RED: you’re typed. Blessed. You’re wonderful.
> >>> BLUE: you’re bad. Untyped. My propositions hate you.
> >>>
> >>> Or something like that. I could see the use of four or five colors 
> >>> even.
> >>> But starting with two would be a _good thing_.
> >>>
> >>> More brainstorming ideas?
> >>>
> >>> --
> >>> 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.
> >>>
> >>> --
> >>> 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

Re: [racket-users] TR could be even more spectacularly awesome:

2016-07-12 Thread Sam Tobin-Hochstadt
This isn't really a for loop specific problem -- any complicated macro
could run into this, and so we need a more general solution.

Sam

On Tue, Jul 12, 2016, 6:17 PM Matthias Felleisen 
wrote:

>
> Alex is working on for loops in general, using a suggestion from Asumu.
>
>
>
> > On Jul 12, 2016, at 6:13 PM, Sam Tobin-Hochstadt 
> wrote:
> >
> > I've opened https://github.com/racket/typed-racket/issues/402 to track
> those issues.
> >
> > What's likely going on is that `for/hash` expands into some code that is
> unreachable, and gives it the source location of the full `for/hash`
> expression. I think we can do a better job with avoiding this, though.
> >
> > Sam
> >
> > On Tue, Jul 12, 2016 at 5:56 PM Matthias Felleisen 
> wrote:
> >
> > Sorry, I really should have said “for/* loops are a mess in types.”
> >
> > Otherwise the OC is a tool you should use for optimization hunting,
> > not type error hunting.
> >
> >
> > > On Jul 12, 2016, at 5:54 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
> > >
> > > I think you are saying that TR does not declare variables in for/hash
> > > as dead code but that OC does. Is that what you're saying? Is that
> > > true?
> > >
> > > Robby
> > >
> > > On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
> > >  wrote:
> > >>
> > >> The coach is different from the type checker.
> > >>
> > >> I think that the type checker should use these colors only when type
> > >> checking succeeds, and in that case, I’d consider the colors highly
> > >> useful.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>> On Jul 12, 2016, at 5:46 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
> > >>>
> > >>> That would require too mcuh work and also be ugly, IMO. :)
> > >>>
> > >>> I think that an on-mouseover option would be too hard to discover.
> > >>>
> > >>> John raises a good point.
> > >>>
> > >>> Robby
> > >>>
> > >>>
> > >>> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
> > >>>  wrote:
> >  I hesitate to suggest it as well, but what about the little red
> >  squiggles seen in editors/word processors/etc?
> > 
> >  But I'm happy with any of these options.
> > 
> >  Sam
> > 
> >  On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
> >   wrote:
> > > Yes.
> > >
> > > I hesitate to suggest it, but would a background color on the text
> be
> > > the way to go? I find that a bit on the annoying side, tho.
> > >
> > > You could use an existing pipeline to do something like the unused
> > > require highlighting (which requires mouseover).
> > >
> > > Robby
> > >
> > > On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
> > >  wrote:
> > >> Could this be an API like the one for tooltips? IOW, some sort of
> general
> > >> warning with a message and a syntax location?
> > >>
> > >> Sam
> > >>
> > >> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler <
> ro...@eecs.northwestern.edu>
> > >> wrote:
> > >>>
> > >>> I think it would be straightforward to add something to Check
> Syntax
> > >>> that reported unreachable code and that seems pretty cool and
> useful
> > >>> for TR. So CS could report any code that TR could prove was
> > >>> unreachable and yet the code came from the original program. I
> guess
> > >>> if John had seen that showing up in his program it might have
> prompted
> > >>> him to figure out what the bug was?
> > >>>
> > >>> Robby
> > >>>
> > >>>
> > >>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
> > >>>  wrote:
> > 
> > > On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt <
> sa...@cs.indiana.edu>
> > > wrote:
> > >
> > >>
> > >> 2) Is there some nice user interface that we could use to
> make the
> > >> warnings visible to the case of the user? Maybe a “I think I
> have a bug, can
> > >> I see the compilation warnings” button?
> > >
> > > I agree -- I think we need a better story generally for
> warning UI in
> > > Racket, but I don't know what the right solution is.
> > 
> > 
> >  [Sorry John, I overlooked your questions.]
> > 
> > 
> >  Instead of watching warnings scroll by in some widget, I’d
> rather see
> >  the coloring solution for testing from the teaching languages
> adapted to TR.
> > 
> >  At a minimum, I could see two colors:
> > 
> >  RED: you’re typed. Blessed. You’re wonderful.
> >  BLUE: you’re bad. Untyped. My propositions hate you.
> > 
> >  Or something like that. I could see the use of four or five
> colors even.
> >  But starting with two would be a _good thing_.
> > 
> >  More brainstorming ideas?
> > 
> >  --
> >  You received this message because you are subscribed to the
> Google
> >  Groups "Racket Users" group.
> > >>

Re: [racket-users] TR could be even more spectacularly awesome:

2016-07-12 Thread Matthias Felleisen

Alex is working on for loops in general, using a suggestion from Asumu. 



> On Jul 12, 2016, at 6:13 PM, Sam Tobin-Hochstadt  wrote:
> 
> I've opened https://github.com/racket/typed-racket/issues/402 to track those 
> issues.
> 
> What's likely going on is that `for/hash` expands into some code that is 
> unreachable, and gives it the source location of the full `for/hash` 
> expression. I think we can do a better job with avoiding this, though.
> 
> Sam
> 
> On Tue, Jul 12, 2016 at 5:56 PM Matthias Felleisen  
> wrote:
> 
> Sorry, I really should have said “for/* loops are a mess in types.”
> 
> Otherwise the OC is a tool you should use for optimization hunting,
> not type error hunting.
> 
> 
> > On Jul 12, 2016, at 5:54 PM, Robby Findler  
> > wrote:
> >
> > I think you are saying that TR does not declare variables in for/hash
> > as dead code but that OC does. Is that what you're saying? Is that
> > true?
> >
> > Robby
> >
> > On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
> >  wrote:
> >>
> >> The coach is different from the type checker.
> >>
> >> I think that the type checker should use these colors only when type
> >> checking succeeds, and in that case, I’d consider the colors highly
> >> useful.
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Jul 12, 2016, at 5:46 PM, Robby Findler  
> >>> wrote:
> >>>
> >>> That would require too mcuh work and also be ugly, IMO. :)
> >>>
> >>> I think that an on-mouseover option would be too hard to discover.
> >>>
> >>> John raises a good point.
> >>>
> >>> Robby
> >>>
> >>>
> >>> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
> >>>  wrote:
>  I hesitate to suggest it as well, but what about the little red
>  squiggles seen in editors/word processors/etc?
> 
>  But I'm happy with any of these options.
> 
>  Sam
> 
>  On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
>   wrote:
> > Yes.
> >
> > I hesitate to suggest it, but would a background color on the text be
> > the way to go? I find that a bit on the annoying side, tho.
> >
> > You could use an existing pipeline to do something like the unused
> > require highlighting (which requires mouseover).
> >
> > Robby
> >
> > On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
> >  wrote:
> >> Could this be an API like the one for tooltips? IOW, some sort of 
> >> general
> >> warning with a message and a syntax location?
> >>
> >> Sam
> >>
> >> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
> >> 
> >> wrote:
> >>>
> >>> I think it would be straightforward to add something to Check Syntax
> >>> that reported unreachable code and that seems pretty cool and useful
> >>> for TR. So CS could report any code that TR could prove was
> >>> unreachable and yet the code came from the original program. I guess
> >>> if John had seen that showing up in his program it might have prompted
> >>> him to figure out what the bug was?
> >>>
> >>> Robby
> >>>
> >>>
> >>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
> >>>  wrote:
> 
> > On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
> > 
> > wrote:
> >
> >>
> >> 2) Is there some nice user interface that we could use to make the
> >> warnings visible to the case of the user? Maybe a “I think I have 
> >> a bug, can
> >> I see the compilation warnings” button?
> >
> > I agree -- I think we need a better story generally for warning UI 
> > in
> > Racket, but I don't know what the right solution is.
> 
> 
>  [Sorry John, I overlooked your questions.]
> 
> 
>  Instead of watching warnings scroll by in some widget, I’d rather see
>  the coloring solution for testing from the teaching languages 
>  adapted to TR.
> 
>  At a minimum, I could see two colors:
> 
>  RED: you’re typed. Blessed. You’re wonderful.
>  BLUE: you’re bad. Untyped. My propositions hate you.
> 
>  Or something like that. I could see the use of four or five colors 
>  even.
>  But starting with two would be a _good thing_.
> 
>  More brainstorming ideas?
> 
>  --
>  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 r

Re: [racket-users] TR could be even more spectacularly awesome:

2016-07-12 Thread Sam Tobin-Hochstadt
I've opened https://github.com/racket/typed-racket/issues/402 to track
those issues.

What's likely going on is that `for/hash` expands into some code that is
unreachable, and gives it the source location of the full `for/hash`
expression. I think we can do a better job with avoiding this, though.

Sam

On Tue, Jul 12, 2016 at 5:56 PM Matthias Felleisen 
wrote:

>
> Sorry, I really should have said “for/* loops are a mess in types.”
>
> Otherwise the OC is a tool you should use for optimization hunting,
> not type error hunting.
>
>
> > On Jul 12, 2016, at 5:54 PM, Robby Findler 
> wrote:
> >
> > I think you are saying that TR does not declare variables in for/hash
> > as dead code but that OC does. Is that what you're saying? Is that
> > true?
> >
> > Robby
> >
> > On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
> >  wrote:
> >>
> >> The coach is different from the type checker.
> >>
> >> I think that the type checker should use these colors only when type
> >> checking succeeds, and in that case, I’d consider the colors highly
> >> useful.
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Jul 12, 2016, at 5:46 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
> >>>
> >>> That would require too mcuh work and also be ugly, IMO. :)
> >>>
> >>> I think that an on-mouseover option would be too hard to discover.
> >>>
> >>> John raises a good point.
> >>>
> >>> Robby
> >>>
> >>>
> >>> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
> >>>  wrote:
>  I hesitate to suggest it as well, but what about the little red
>  squiggles seen in editors/word processors/etc?
> 
>  But I'm happy with any of these options.
> 
>  Sam
> 
>  On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
>   wrote:
> > Yes.
> >
> > I hesitate to suggest it, but would a background color on the text be
> > the way to go? I find that a bit on the annoying side, tho.
> >
> > You could use an existing pipeline to do something like the unused
> > require highlighting (which requires mouseover).
> >
> > Robby
> >
> > On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
> >  wrote:
> >> Could this be an API like the one for tooltips? IOW, some sort of
> general
> >> warning with a message and a syntax location?
> >>
> >> Sam
> >>
> >> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler <
> ro...@eecs.northwestern.edu>
> >> wrote:
> >>>
> >>> I think it would be straightforward to add something to Check
> Syntax
> >>> that reported unreachable code and that seems pretty cool and
> useful
> >>> for TR. So CS could report any code that TR could prove was
> >>> unreachable and yet the code came from the original program. I
> guess
> >>> if John had seen that showing up in his program it might have
> prompted
> >>> him to figure out what the bug was?
> >>>
> >>> Robby
> >>>
> >>>
> >>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
> >>>  wrote:
> 
> > On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt <
> sa...@cs.indiana.edu>
> > wrote:
> >
> >>
> >> 2) Is there some nice user interface that we could use to make
> the
> >> warnings visible to the case of the user? Maybe a “I think I
> have a bug, can
> >> I see the compilation warnings” button?
> >
> > I agree -- I think we need a better story generally for warning
> UI in
> > Racket, but I don't know what the right solution is.
> 
> 
>  [Sorry John, I overlooked your questions.]
> 
> 
>  Instead of watching warnings scroll by in some widget, I’d rather
> see
>  the coloring solution for testing from the teaching languages
> adapted to TR.
> 
>  At a minimum, I could see two colors:
> 
>  RED: you’re typed. Blessed. You’re wonderful.
>  BLUE: you’re bad. Untyped. My propositions hate you.
> 
>  Or something like that. I could see the use of four or five
> colors even.
>  But starting with two would be a _good thing_.
> 
>  More brainstorming ideas?
> 
>  --
>  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 ar

Re: [racket-users] TR could be even more spectacularly awesome:

2016-07-12 Thread Robby Findler
I think you are saying that TR does not declare variables in for/hash
as dead code but that OC does. Is that what you're saying? Is that
true?

Robby

On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
 wrote:
>
> The coach is different from the type checker.
>
> I think that the type checker should use these colors only when type
> checking succeeds, and in that case, I’d consider the colors highly
> useful.
>
>
>
>
>
>
>> On Jul 12, 2016, at 5:46 PM, Robby Findler  
>> wrote:
>>
>> That would require too mcuh work and also be ugly, IMO. :)
>>
>> I think that an on-mouseover option would be too hard to discover.
>>
>> John raises a good point.
>>
>> Robby
>>
>>
>> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
>>  wrote:
>>> I hesitate to suggest it as well, but what about the little red
>>> squiggles seen in editors/word processors/etc?
>>>
>>> But I'm happy with any of these options.
>>>
>>> Sam
>>>
>>> On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
>>>  wrote:
 Yes.

 I hesitate to suggest it, but would a background color on the text be
 the way to go? I find that a bit on the annoying side, tho.

 You could use an existing pipeline to do something like the unused
 require highlighting (which requires mouseover).

 Robby

 On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
  wrote:
> Could this be an API like the one for tooltips? IOW, some sort of general
> warning with a message and a syntax location?
>
> Sam
>
> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
> 
> wrote:
>>
>> I think it would be straightforward to add something to Check Syntax
>> that reported unreachable code and that seems pretty cool and useful
>> for TR. So CS could report any code that TR could prove was
>> unreachable and yet the code came from the original program. I guess
>> if John had seen that showing up in his program it might have prompted
>> him to figure out what the bug was?
>>
>> Robby
>>
>>
>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
>>  wrote:
>>>
 On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
 wrote:

>
> 2) Is there some nice user interface that we could use to make the
> warnings visible to the case of the user? Maybe a “I think I have a 
> bug, can
> I see the compilation warnings” button?

 I agree -- I think we need a better story generally for warning UI in
 Racket, but I don't know what the right solution is.
>>>
>>>
>>> [Sorry John, I overlooked your questions.]
>>>
>>>
>>> Instead of watching warnings scroll by in some widget, I’d rather see
>>> the coloring solution for testing from the teaching languages adapted 
>>> to TR.
>>>
>>> At a minimum, I could see two colors:
>>>
>>> RED: you’re typed. Blessed. You’re wonderful.
>>> BLUE: you’re bad. Untyped. My propositions hate you.
>>>
>>> Or something like that. I could see the use of four or five colors even.
>>> But starting with two would be a _good thing_.
>>>
>>> More brainstorming ideas?
>>>
>>> --
>>> 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.
>>>
>>> --
>>> 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, s

Re: [racket-users] TR could be even more spectacularly awesome:

2016-07-12 Thread Matthias Felleisen

Sorry, I really should have said “for/* loops are a mess in types.” 

Otherwise the OC is a tool you should use for optimization hunting, 
not type error hunting. 


> On Jul 12, 2016, at 5:54 PM, Robby Findler  
> wrote:
> 
> I think you are saying that TR does not declare variables in for/hash
> as dead code but that OC does. Is that what you're saying? Is that
> true?
> 
> Robby
> 
> On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
>  wrote:
>> 
>> The coach is different from the type checker.
>> 
>> I think that the type checker should use these colors only when type
>> checking succeeds, and in that case, I’d consider the colors highly
>> useful.
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jul 12, 2016, at 5:46 PM, Robby Findler  
>>> wrote:
>>> 
>>> That would require too mcuh work and also be ugly, IMO. :)
>>> 
>>> I think that an on-mouseover option would be too hard to discover.
>>> 
>>> John raises a good point.
>>> 
>>> Robby
>>> 
>>> 
>>> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
>>>  wrote:
 I hesitate to suggest it as well, but what about the little red
 squiggles seen in editors/word processors/etc?
 
 But I'm happy with any of these options.
 
 Sam
 
 On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
  wrote:
> Yes.
> 
> I hesitate to suggest it, but would a background color on the text be
> the way to go? I find that a bit on the annoying side, tho.
> 
> You could use an existing pipeline to do something like the unused
> require highlighting (which requires mouseover).
> 
> Robby
> 
> On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
>  wrote:
>> Could this be an API like the one for tooltips? IOW, some sort of general
>> warning with a message and a syntax location?
>> 
>> Sam
>> 
>> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
>> 
>> wrote:
>>> 
>>> I think it would be straightforward to add something to Check Syntax
>>> that reported unreachable code and that seems pretty cool and useful
>>> for TR. So CS could report any code that TR could prove was
>>> unreachable and yet the code came from the original program. I guess
>>> if John had seen that showing up in his program it might have prompted
>>> him to figure out what the bug was?
>>> 
>>> Robby
>>> 
>>> 
>>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
>>>  wrote:
 
> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
> 
> wrote:
> 
>> 
>> 2) Is there some nice user interface that we could use to make the
>> warnings visible to the case of the user? Maybe a “I think I have a 
>> bug, can
>> I see the compilation warnings” button?
> 
> I agree -- I think we need a better story generally for warning UI in
> Racket, but I don't know what the right solution is.
 
 
 [Sorry John, I overlooked your questions.]
 
 
 Instead of watching warnings scroll by in some widget, I’d rather see
 the coloring solution for testing from the teaching languages adapted 
 to TR.
 
 At a minimum, I could see two colors:
 
 RED: you’re typed. Blessed. You’re wonderful.
 BLUE: you’re bad. Untyped. My propositions hate you.
 
 Or something like that. I could see the use of four or five colors 
 even.
 But starting with two would be a _good thing_.
 
 More brainstorming ideas?
 
 --
 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.
 
 --
 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 rec

Re: [racket-users] TR could be even more spectacularly awesome:

2016-07-12 Thread Matthias Felleisen

The coach is different from the type checker. 

I think that the type checker should use these colors only when type 
checking succeeds, and in that case, I’d consider the colors highly 
useful. 






> On Jul 12, 2016, at 5:46 PM, Robby Findler  
> wrote:
> 
> That would require too mcuh work and also be ugly, IMO. :)
> 
> I think that an on-mouseover option would be too hard to discover.
> 
> John raises a good point.
> 
> Robby
> 
> 
> On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
>  wrote:
>> I hesitate to suggest it as well, but what about the little red
>> squiggles seen in editors/word processors/etc?
>> 
>> But I'm happy with any of these options.
>> 
>> Sam
>> 
>> On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
>>  wrote:
>>> Yes.
>>> 
>>> I hesitate to suggest it, but would a background color on the text be
>>> the way to go? I find that a bit on the annoying side, tho.
>>> 
>>> You could use an existing pipeline to do something like the unused
>>> require highlighting (which requires mouseover).
>>> 
>>> Robby
>>> 
>>> On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
>>>  wrote:
 Could this be an API like the one for tooltips? IOW, some sort of general
 warning with a message and a syntax location?
 
 Sam
 
 On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
 wrote:
> 
> I think it would be straightforward to add something to Check Syntax
> that reported unreachable code and that seems pretty cool and useful
> for TR. So CS could report any code that TR could prove was
> unreachable and yet the code came from the original program. I guess
> if John had seen that showing up in his program it might have prompted
> him to figure out what the bug was?
> 
> Robby
> 
> 
> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
>  wrote:
>> 
>>> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
>>> wrote:
>>> 
 
 2) Is there some nice user interface that we could use to make the
 warnings visible to the case of the user? Maybe a “I think I have a 
 bug, can
 I see the compilation warnings” button?
>>> 
>>> I agree -- I think we need a better story generally for warning UI in
>>> Racket, but I don't know what the right solution is.
>> 
>> 
>> [Sorry John, I overlooked your questions.]
>> 
>> 
>> Instead of watching warnings scroll by in some widget, I’d rather see
>> the coloring solution for testing from the teaching languages adapted to 
>> TR.
>> 
>> At a minimum, I could see two colors:
>> 
>> RED: you’re typed. Blessed. You’re wonderful.
>> BLUE: you’re bad. Untyped. My propositions hate you.
>> 
>> Or something like that. I could see the use of four or five colors even.
>> But starting with two would be a _good thing_.
>> 
>> More brainstorming ideas?
>> 
>> --
>> 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.
>> 
>> --
>> 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] TR could be even more spectacularly awesome:

2016-07-12 Thread Robby Findler
That would require too mcuh work and also be ugly, IMO. :)

I think that an on-mouseover option would be too hard to discover.

John raises a good point.

Robby


On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
 wrote:
> I hesitate to suggest it as well, but what about the little red
> squiggles seen in editors/word processors/etc?
>
> But I'm happy with any of these options.
>
> Sam
>
> On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
>  wrote:
>> Yes.
>>
>> I hesitate to suggest it, but would a background color on the text be
>> the way to go? I find that a bit on the annoying side, tho.
>>
>> You could use an existing pipeline to do something like the unused
>> require highlighting (which requires mouseover).
>>
>> Robby
>>
>> On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
>>  wrote:
>>> Could this be an API like the one for tooltips? IOW, some sort of general
>>> warning with a message and a syntax location?
>>>
>>> Sam
>>>
>>> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
>>> wrote:

 I think it would be straightforward to add something to Check Syntax
 that reported unreachable code and that seems pretty cool and useful
 for TR. So CS could report any code that TR could prove was
 unreachable and yet the code came from the original program. I guess
 if John had seen that showing up in his program it might have prompted
 him to figure out what the bug was?

 Robby


 On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
  wrote:
 >
 >> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
 >> wrote:
 >>
 >>>
 >>> 2) Is there some nice user interface that we could use to make the
 >>> warnings visible to the case of the user? Maybe a “I think I have a 
 >>> bug, can
 >>> I see the compilation warnings” button?
 >>
 >> I agree -- I think we need a better story generally for warning UI in
 >> Racket, but I don't know what the right solution is.
 >
 >
 > [Sorry John, I overlooked your questions.]
 >
 >
 > Instead of watching warnings scroll by in some widget, I’d rather see
 > the coloring solution for testing from the teaching languages adapted to 
 > TR.
 >
 > At a minimum, I could see two colors:
 >
 > RED: you’re typed. Blessed. You’re wonderful.
 > BLUE: you’re bad. Untyped. My propositions hate you.
 >
 > Or something like that. I could see the use of four or five colors even.
 > But starting with two would be a _good thing_.
 >
 > More brainstorming ideas?
 >
 > --
 > 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.
>
> --
> 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] TR could be even more spectacularly awesome:

2016-07-12 Thread 'John Clements' via Racket Users

> On Jul 12, 2016, at 2:38 PM, Robby Findler  
> wrote:
> 
> Yes.
> 
> I hesitate to suggest it, but would a background color on the text be
> the way to go? I find that a bit on the annoying side, tho.
> 
> You could use an existing pipeline to do something like the unused
> require highlighting (which requires mouseover).

I should also mention this: when I went looking for this feedback in my larger 
program, by enabling the optimization coach and the warning log window, I also 
saw a number of “usual suspects” locations (e.g., the bound name in a for/hash) 
that were marked as unreachable. For a tool like this to be useful in an 
“always-on” mode, I think you’d have to find some way to not mark these 
situations.

John



-- 
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] TR could be even more spectacularly awesome:

2016-07-12 Thread Sam Tobin-Hochstadt
I hesitate to suggest it as well, but what about the little red
squiggles seen in editors/word processors/etc?

But I'm happy with any of these options.

Sam

On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
 wrote:
> Yes.
>
> I hesitate to suggest it, but would a background color on the text be
> the way to go? I find that a bit on the annoying side, tho.
>
> You could use an existing pipeline to do something like the unused
> require highlighting (which requires mouseover).
>
> Robby
>
> On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
>  wrote:
>> Could this be an API like the one for tooltips? IOW, some sort of general
>> warning with a message and a syntax location?
>>
>> Sam
>>
>> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
>> wrote:
>>>
>>> I think it would be straightforward to add something to Check Syntax
>>> that reported unreachable code and that seems pretty cool and useful
>>> for TR. So CS could report any code that TR could prove was
>>> unreachable and yet the code came from the original program. I guess
>>> if John had seen that showing up in his program it might have prompted
>>> him to figure out what the bug was?
>>>
>>> Robby
>>>
>>>
>>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
>>>  wrote:
>>> >
>>> >> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
>>> >> wrote:
>>> >>
>>> >>>
>>> >>> 2) Is there some nice user interface that we could use to make the
>>> >>> warnings visible to the case of the user? Maybe a “I think I have a 
>>> >>> bug, can
>>> >>> I see the compilation warnings” button?
>>> >>
>>> >> I agree -- I think we need a better story generally for warning UI in
>>> >> Racket, but I don't know what the right solution is.
>>> >
>>> >
>>> > [Sorry John, I overlooked your questions.]
>>> >
>>> >
>>> > Instead of watching warnings scroll by in some widget, I’d rather see
>>> > the coloring solution for testing from the teaching languages adapted to 
>>> > TR.
>>> >
>>> > At a minimum, I could see two colors:
>>> >
>>> > RED: you’re typed. Blessed. You’re wonderful.
>>> > BLUE: you’re bad. Untyped. My propositions hate you.
>>> >
>>> > Or something like that. I could see the use of four or five colors even.
>>> > But starting with two would be a _good thing_.
>>> >
>>> > More brainstorming ideas?
>>> >
>>> > --
>>> > 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.

-- 
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] TR could be even more spectacularly awesome:

2016-07-12 Thread Robby Findler
Yes.

I hesitate to suggest it, but would a background color on the text be
the way to go? I find that a bit on the annoying side, tho.

You could use an existing pipeline to do something like the unused
require highlighting (which requires mouseover).

Robby

On Tue, Jul 12, 2016 at 4:36 PM, Sam Tobin-Hochstadt
 wrote:
> Could this be an API like the one for tooltips? IOW, some sort of general
> warning with a message and a syntax location?
>
> Sam
>
> On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
> wrote:
>>
>> I think it would be straightforward to add something to Check Syntax
>> that reported unreachable code and that seems pretty cool and useful
>> for TR. So CS could report any code that TR could prove was
>> unreachable and yet the code came from the original program. I guess
>> if John had seen that showing up in his program it might have prompted
>> him to figure out what the bug was?
>>
>> Robby
>>
>>
>> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
>>  wrote:
>> >
>> >> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
>> >> wrote:
>> >>
>> >>>
>> >>> 2) Is there some nice user interface that we could use to make the
>> >>> warnings visible to the case of the user? Maybe a “I think I have a bug, 
>> >>> can
>> >>> I see the compilation warnings” button?
>> >>
>> >> I agree -- I think we need a better story generally for warning UI in
>> >> Racket, but I don't know what the right solution is.
>> >
>> >
>> > [Sorry John, I overlooked your questions.]
>> >
>> >
>> > Instead of watching warnings scroll by in some widget, I’d rather see
>> > the coloring solution for testing from the teaching languages adapted to 
>> > TR.
>> >
>> > At a minimum, I could see two colors:
>> >
>> > RED: you’re typed. Blessed. You’re wonderful.
>> > BLUE: you’re bad. Untyped. My propositions hate you.
>> >
>> > Or something like that. I could see the use of four or five colors even.
>> > But starting with two would be a _good thing_.
>> >
>> > More brainstorming ideas?
>> >
>> > --
>> > 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] TR could be even more spectacularly awesome:

2016-07-12 Thread Sam Tobin-Hochstadt
Could this be an API like the one for tooltips? IOW, some sort of general
warning with a message and a syntax location?

Sam

On Tue, Jul 12, 2016 at 5:34 PM Robby Findler 
wrote:

> I think it would be straightforward to add something to Check Syntax
> that reported unreachable code and that seems pretty cool and useful
> for TR. So CS could report any code that TR could prove was
> unreachable and yet the code came from the original program. I guess
> if John had seen that showing up in his program it might have prompted
> him to figure out what the bug was?
>
> Robby
>
>
> On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
>  wrote:
> >
> >> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt 
> wrote:
> >>
> >>>
> >>> 2) Is there some nice user interface that we could use to make the
> warnings visible to the case of the user? Maybe a “I think I have a bug,
> can I see the compilation warnings” button?
> >>
> >> I agree -- I think we need a better story generally for warning UI in
> >> Racket, but I don't know what the right solution is.
> >
> >
> > [Sorry John, I overlooked your questions.]
> >
> >
> > Instead of watching warnings scroll by in some widget, I’d rather see
> the coloring solution for testing from the teaching languages adapted to TR.
> >
> > At a minimum, I could see two colors:
> >
> > RED: you’re typed. Blessed. You’re wonderful.
> > BLUE: you’re bad. Untyped. My propositions hate you.
> >
> > Or something like that. I could see the use of four or five colors even.
> But starting with two would be a _good thing_.
> >
> > More brainstorming ideas?
> >
> > --
> > 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] TR could be even more spectacularly awesome:

2016-07-12 Thread Robby Findler
I think it would be straightforward to add something to Check Syntax
that reported unreachable code and that seems pretty cool and useful
for TR. So CS could report any code that TR could prove was
unreachable and yet the code came from the original program. I guess
if John had seen that showing up in his program it might have prompted
him to figure out what the bug was?

Robby


On Tue, Jul 12, 2016 at 4:13 PM, Matthias Felleisen
 wrote:
>
>> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt  
>> wrote:
>>
>>>
>>> 2) Is there some nice user interface that we could use to make the warnings 
>>> visible to the case of the user? Maybe a “I think I have a bug, can I see 
>>> the compilation warnings” button?
>>
>> I agree -- I think we need a better story generally for warning UI in
>> Racket, but I don't know what the right solution is.
>
>
> [Sorry John, I overlooked your questions.]
>
>
> Instead of watching warnings scroll by in some widget, I’d rather see the 
> coloring solution for testing from the teaching languages adapted to TR.
>
> At a minimum, I could see two colors:
>
> RED: you’re typed. Blessed. You’re wonderful.
> BLUE: you’re bad. Untyped. My propositions hate you.
>
> Or something like that. I could see the use of four or five colors even. But 
> starting with two would be a _good thing_.
>
> More brainstorming ideas?
>
> --
> 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] TR could be even more spectacularly awesome:

2016-07-12 Thread Matthias Felleisen

> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt  wrote:
> 
>> 
>> 2) Is there some nice user interface that we could use to make the warnings 
>> visible to the case of the user? Maybe a “I think I have a bug, can I see 
>> the compilation warnings” button?
> 
> I agree -- I think we need a better story generally for warning UI in
> Racket, but I don't know what the right solution is.


[Sorry John, I overlooked your questions.]


Instead of watching warnings scroll by in some widget, I’d rather see the 
coloring solution for testing from the teaching languages adapted to TR. 

At a minimum, I could see two colors: 

RED: you’re typed. Blessed. You’re wonderful. 
BLUE: you’re bad. Untyped. My propositions hate you. 

Or something like that. I could see the use of four or five colors even. But 
starting with two would be a _good thing_. 

More brainstorming ideas? 

-- 
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] TR could be even more spectacularly awesome:

2016-07-12 Thread Sam Tobin-Hochstadt
On Tue, Jul 12, 2016 at 4:50 PM, 'John Clements' via Racket Users
 wrote:
>
> So, I have two questions:
>
> 1) Why doesn’t the optimization coach locate the unreachable code in this 
> example? Perhaps it’s too small?

TR doesn't prove that the else branch is unreachable. I think what's
happening is that TR doesn't feed enough information from the result
_type_ [here, (U #t 'odd 'even)] to the result _proposition_ (which is
what tells it if the branch is unreachable).  Here's an even smaller
example:

#lang typed/racket
(: process-number : -> Symbol)
(define (process-number)
  (if (add1 5) 'both-odd "x"))

I've reported it as https://github.com/racket/typed-racket/issues/400

> 2) Is there some nice user interface that we could use to make the warnings 
> visible to the case of the user? Maybe a “I think I have a bug, can I see the 
> compilation warnings” button?

I agree -- I think we need a better story generally for warning UI in
Racket, but I don't know what the right solution is.

Sam

-- 
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] TR could be even more spectacularly awesome:

2016-07-12 Thread Matthias Felleisen

> On Jul 12, 2016, at 4:50 PM, 'John Clements' via Racket Users 
>  wrote:
> 
> lang typed/racket
> 
> (: process-number (Integer -> (U 'both-odd 'not-both-odd)))
> (define (process-number n)
>  (if (andmap is-odd? (list (sub1 n) (add1 n)))
>  'both-odd
>  'not-both-odd))
> 
> (: is-odd? (Integer -> (U 'odd 'even)))
> (define (is-odd? n)
>  (if (= (modulo n 2) 0)
>  'even
>  'odd))
> 
> (process-number 13) ;; > returns ‘both-odd

> this program suggests that both 12 and 14 are odd numbers. Can you see the 
> bug?


Obviously ‘odd and ‘even are both Truthy values in Typed Racket. This is not a 
bug. This is proof that TR accommodates R. 

Here is the fixed version: 

#lang typed/racket

(: process-number (Integer -> (U 'both-odd 'not-both-odd)))
(define (process-number n)
 (if (andmap (lambda ({x : Integer}) (eq? (is-odd? x) 'odd)) (list (sub1 n) 
(add1 n)))
 'both-odd
 'not-both-odd))

(: is-odd? (Integer -> (U 'odd 'even)))
(define (is-odd? n)
 (if (= (modulo n 2) 0)
 'even
 'odd))

(process-number 13) 

-- 
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] TR could be even more spectacularly awesome:

2016-07-12 Thread 'John Clements' via Racket Users
Quick puzzle: why does this program return the wrong answer:

#lang typed/racket

(: process-number (Integer -> (U 'both-odd 'not-both-odd)))
(define (process-number n)
  (if (andmap is-odd? (list (sub1 n) (add1 n)))
  'both-odd
  'not-both-odd))

(: is-odd? (Integer -> (U 'odd 'even)))
(define (is-odd? n)
  (if (= (modulo n 2) 0)
  'even
  'odd))

(process-number 13) ;; > returns ‘both-odd

this program suggests that both 12 and 14 are odd numbers. Can you see the bug?

…


^L

Okay, so: couldn’t TR have found this bug for me? Yes, it definitely could 
have. In fact, if you hover over the type of the test argument, you’ll see that 
the else is unreachable.  And, in the larger program that I first encountered 
this bug in running the optimization coach and turning on the “warning” section 
of the log actually identifies unreachable code, clearly indicating the 
location of the bug.

So, I have two questions:

1) Why doesn’t the optimization coach locate the unreachable code in this 
example? Perhaps it’s too small? 

… but probably harder and more interesting:

2) Is there some nice user interface that we could use to make the warnings 
visible to the case of the user? Maybe a “I think I have a bug, can I see the 
compilation warnings” button?






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