[racket] users Digest, Vol 109, Issue 79

Please take me off the list

Thanks


On Mon, Sep 29, 2014 at 4:32 PM,  <users-request at racket-lang.org> wrote:
> Send users mailing list submissions to
>         users at racket-lang.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.racket-lang.org/users/listinfo
> or, via email, send a message with subject or body 'help' to
>         users-request at racket-lang.org
>
> You can reach the person managing the list at
>         users-owner at racket-lang.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> [Racket Users list:
>  http://lists.racket-lang.org/users ]
>
>
> Today's Topics:
>
>    1. Re: Cyclic data structures in Typed Racket (Matthias Felleisen)
>    2. Re: Better discoverability for errortrace (Neil Van Dyke)
>    3. Re: Better discoverability for errortrace (Robby Findler)
>    4. Re: Cyclic data structures in Typed Racket (Benjamin Greenman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 29 Sep 2014 15:30:52 -0400
> From: Matthias Felleisen <matthias at ccs.neu.edu>
> To: Sam Tobin-Hochstadt <samth at cs.indiana.edu>
> Cc: users <users at racket-lang.org>
> Subject: Re: [racket] Cyclic data structures in Typed Racket
> Message-ID: <3597E44F-0EF5-4837-AA2D-E06E728B8B71 at ccs.neu.edu>
> Content-Type: text/plain; charset=us-ascii
>
>
> I guess the real problem is to create suitable default values so
> that the pass the type checker or to figure out a cast that forces
> TR to accept some other value as the default value (and making sure
> you never use the object).
>
> Undefined not completely solved. Argh. -- Matthias
>
>
>
>
>
> On Sep 29, 2014, at 12:52 PM, Sam Tobin-Hochstadt <samth at cs.indiana.edu> wrote:
>
>> Ah, if you want to create truly cyclic structure with no base case
>> like this, then you'll have to do more work. Either you'll need to
>> expand the type of the `x` field in `foo` to allow an initial value,
>> or you'll need to create a dummy `foo` with that extended type, and
>> then copy the cyclic data once you've created it to a new version of
>> `foo`, using hash tables to track cycles. That's basically how
>> `shared` works, although I haven't tried implementing it in TR and it
>> might not be possible.
>>
>> Sam
>>
>> On Mon, Sep 29, 2014 at 12:33 PM, Konrad Hinsen
>> <konrad.hinsen at fastmail.net> wrote:
>>> Sam Tobin-Hochstadt writes:
>>>
>>>> I recommend doing the mutation yourself, and not using `shared`.
>>>> That's the most obvious solution.
>>>
>>> Not for me, unfortunately, but probably I am missing something
>>> obvious.
>>>
>>> Here's explicit mutation in untyped Racket:
>>>
>>>   #lang racket
>>>
>>>   (struct foo (x) #:mutable)
>>>   (struct bar (x))
>>>
>>>   (define f (foo (void)))
>>>   (define b (bar f))
>>>   (set-foo-x! f b)
>>>
>>>   (eq? (bar-x b) f)
>>>   (eq? (foo-x f) b)
>>>
>>> That works fine. Moving to Typed Racket, this is rejected by the type
>>> checker because (void) is of type Void.  Since I need a bar to make a
>>> foo and a foo to make a bar, I don't see how I can ever initialize my
>>> foo structure.
>>>
>>>> The reason that your `require/typed` doesn't work is that it creates
>>>> new versions of the placeholder functions, but those aren't the ones
>>>> that `shared` uses internally, so Typed Racket doesn't use the types
>>>> you've given.
>>>
>>> That makes sense, thanks for the explanation!
>>>
>>> Konrad.
>> ____________________
>>  Racket Users list:
>>  http://lists.racket-lang.org/users
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 29 Sep 2014 15:33:58 -0400
> From: Neil Van Dyke <neil at neilvandyke.org>
> To: Jonathan Schuster <schuster at ccs.neu.edu>, Robby Findler
>         <robby at eecs.northwestern.edu>
> Cc: Racket List <users at racket-lang.org>
> Subject: Re: [racket] Better discoverability for errortrace
> Message-ID: <5429B426.7020404 at neilvandyke.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Small comment: In addition to discoverability, try to have this go
> direct to *understanding* of how&when to use "errortrace".
>
> (Multiple times over the years, I have been doing crucial performance
> optimizations to server code, and remnants of various versions of
> "errortrace" kept getting added back into the code. Pattern: get it
> optimized, incidentally also remove killer "errortrace" bits, then
> someone merges the changes, and some terrible "#! ... -l errortrace" or
> ancient "require ... errortrace.ss" somehow sneaks back into several
> different places each in multiple branches, sneaks back into hurting
> production capacity.  Even if you provide a switch in the app-specific
> build environment to enable/disable errortrace.  With lots of code and
> lots of branches and merging, it seems that errortrace can be like bed
> bugs -- terrorizing you with small bites everywhere, and you just can't
> get rid of it.  This might seem like a CM and merging problem, not an
> "errortrace" problem, but it seems somewhat peculiar to "errortrace" in
> practice.  I am forming a theory that some programmers are afraid to let
> a merge remove whatever cargo-cult incantations they found in the past
> gave them better backtraces, damn any consequences. :)  Hence my
> suggestion to have your improved discoverability send the programmer
> direct to *understanding*, rather than to cargo-cult "add this magical
> snippet to your project" with an implied "and never lose the faith".)
>
> (Like many programming pragmatics, I know it looks silly to consider
> this seemingly little thing a matter of importance worth mention, but my
> view from the ground is that it has been important.)
>
> Neil V.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 29 Sep 2014 14:59:19 -0500
> From: Robby Findler <robby at eecs.northwestern.edu>
> To: Jonathan Schuster <schuster at ccs.neu.edu>
> Cc: Racket List <users at racket-lang.org>
> Subject: Re: [racket] Better discoverability for errortrace
> Message-ID:
>         <CAL3TdOPCAahyza53fPqtMQH23bumTO=tTOubpq+YX3Pr8ok6_g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> If you want to go that way, I think the right thing is to change the
> initial error-display-handler that racket installs when it is started
> up in "open a repl" mode.
>
> I will note, however, that there are lots of things that aren't
> discoverable in this way. Indeed, I would prefer that if someone were
> unhappy with their feedback of the racket repl that they were directed
> to a) use xrepl, b) use Greg's emacs mode, or c) use drracket, all
> ahead of being directed to use "racket -l errortrace -t file.rkt".
> That latter one I view as a convenience for wizards, not something
> where discovery is important.
>
> Robby
>
>
> On Mon, Sep 29, 2014 at 1:42 PM, Jonathan Schuster <schuster at ccs.neu.edu> wrote:
>> Hmm, I agree that there are cases when the message is extraneous, but I
>> think adding it only to something like xrepl doesn't solve the core
>> discoverability issue for those who use plain vanilla Racket on the command
>> line. What about a parameter that determines if the message should be
>> printed or not, and DrRacket could enable or disable it as needed? It could
>> be enabled by default, so that places like the REPL would still show the
>> message.
>>
>> On Mon, Sep 29, 2014 at 2:12 PM, Robby Findler <robby at eecs.northwestern.edu>
>> wrote:
>>>
>>> I don't think that that particular message makes sense as part of the
>>> default error messages. Specifically, if you disable errortrace in
>>> drracket, then you wouldn't want to see those messages (or, perhaps
>>> more accurately, you'd want to see different error messages). Maybe
>>> the repl that racket starts up can do that, tho?
>>>
>>> But perhaps this is something to add to xrepl?
>>>
>>> Robby
>>>
>>> On Mon, Sep 29, 2014 at 1:06 PM, Jonathan Schuster <schuster at ccs.neu.edu>
>>> wrote:
>>> > We were having a discussion today in the Northeastern lab about how the
>>> > Racket stack traces sometimes don't give enough information, and the
>>> > solution to the problem (errrortrace) is not very discoverable if you're
>>> > not
>>> > using DrRacket.
>>> >
>>> > Here's an example of the kind of case I mean:
>>> >
>>> > $ racket -t jpg.rkt
>>> > Assertion failed on #f
>>> >   context...:
>>> >    do-it
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop
>>> >    decode-jpeg
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]
>>> >
>>> > $ racket -l errortrace -t jpg.rkt
>>> > Assertion failed on #f
>>> >   errortrace...:
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt:126:16: (assert #f)
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt:363:36: (huff-dc-decode
>>> > dc-tree
>>> > bits)
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt:407:37: (reader bits)
>>> >    <eliding for length>
>>> >   context...:
>>> >    huff-dc-decode
>>> >    do-it
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt:406:5: for-loop
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop
>>> >    decode-jpeg
>>> >    /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]
>>> >
>>> >
>>> > To solve the discoverability issue, what would people think of putting a
>>> > message like "If this information is not sufficient, try errrortrace
>>> > with
>>> > racket -l errortrace -t <prog>" after the default trace? Also, can
>>> > anyone
>>> > think of a way to programmatically detect when a trace is not
>>> > informative
>>> > enough and only display the message in those cases? I haven't looked
>>> > into
>>> > the feasibility of this myself; it's just an idea that came up during
>>> > our
>>> > discussion.
>>> >
>>> > ____________________
>>> >   Racket Users list:
>>> >   http://lists.racket-lang.org/users
>>> >
>>
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 29 Sep 2014 16:32:19 -0400
> From: Benjamin Greenman <blg59 at cornell.edu>
> To: Matthias Felleisen <matthias at ccs.neu.edu>
> Cc: users <users at racket-lang.org>, Sam Tobin-Hochstadt
>         <samth at cs.indiana.edu>
> Subject: Re: [racket] Cyclic data structures in Typed Racket
> Message-ID:
>         <CAAtAoRoBwwg=DDMVKL49SxAJUNLzqRfcB5TSdbpxR0MFeTRODQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Could Andrew Myer's work on masked types (to eliminate nulls for object
> initialization) be relevant?
> http://www.cs.cornell.edu/Projects/jmask/
>
> On Mon, Sep 29, 2014 at 3:30 PM, Matthias Felleisen <matthias at ccs.neu.edu>
> wrote:
>
>>
>> I guess the real problem is to create suitable default values so
>> that the pass the type checker or to figure out a cast that forces
>> TR to accept some other value as the default value (and making sure
>> you never use the object).
>>
>> Undefined not completely solved. Argh. -- Matthias
>>
>>
>>
>>
>>
>> On Sep 29, 2014, at 12:52 PM, Sam Tobin-Hochstadt <samth at cs.indiana.edu>
>> wrote:
>>
>> > Ah, if you want to create truly cyclic structure with no base case
>> > like this, then you'll have to do more work. Either you'll need to
>> > expand the type of the `x` field in `foo` to allow an initial value,
>> > or you'll need to create a dummy `foo` with that extended type, and
>> > then copy the cyclic data once you've created it to a new version of
>> > `foo`, using hash tables to track cycles. That's basically how
>> > `shared` works, although I haven't tried implementing it in TR and it
>> > might not be possible.
>> >
>> > Sam
>> >
>> > On Mon, Sep 29, 2014 at 12:33 PM, Konrad Hinsen
>> > <konrad.hinsen at fastmail.net> wrote:
>> >> Sam Tobin-Hochstadt writes:
>> >>
>> >>> I recommend doing the mutation yourself, and not using `shared`.
>> >>> That's the most obvious solution.
>> >>
>> >> Not for me, unfortunately, but probably I am missing something
>> >> obvious.
>> >>
>> >> Here's explicit mutation in untyped Racket:
>> >>
>> >>   #lang racket
>> >>
>> >>   (struct foo (x) #:mutable)
>> >>   (struct bar (x))
>> >>
>> >>   (define f (foo (void)))
>> >>   (define b (bar f))
>> >>   (set-foo-x! f b)
>> >>
>> >>   (eq? (bar-x b) f)
>> >>   (eq? (foo-x f) b)
>> >>
>> >> That works fine. Moving to Typed Racket, this is rejected by the type
>> >> checker because (void) is of type Void.  Since I need a bar to make a
>> >> foo and a foo to make a bar, I don't see how I can ever initialize my
>> >> foo structure.
>> >>
>> >>> The reason that your `require/typed` doesn't work is that it creates
>> >>> new versions of the placeholder functions, but those aren't the ones
>> >>> that `shared` uses internally, so Typed Racket doesn't use the types
>> >>> you've given.
>> >>
>> >> That makes sense, thanks for the explanation!
>> >>
>> >> Konrad.
>> > ____________________
>> >  Racket Users list:
>> >  http://lists.racket-lang.org/users
>>
>>
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.racket-lang.org/users/archive/attachments/20140929/0ff9b0cf/attachment.html>
>
> End of users Digest, Vol 109, Issue 79
> **************************************