Please take me off the list Thanks
On Mon, Sep 29, 2014 at 4:32 PM, <users-requ...@racket-lang.org> wrote: > Send users mailing list submissions to > users@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-requ...@racket-lang.org > > You can reach the person managing the list at > users-ow...@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 <matth...@ccs.neu.edu> > To: Sam Tobin-Hochstadt <sa...@cs.indiana.edu> > Cc: users <users@racket-lang.org> > Subject: Re: [racket] Cyclic data structures in Typed Racket > Message-ID: <3597e44f-0ef5-4837-aa2d-e06e728b8...@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 <sa...@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.hin...@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 <n...@neilvandyke.org> > To: Jonathan Schuster <schus...@ccs.neu.edu>, Robby Findler > <ro...@eecs.northwestern.edu> > Cc: Racket List <users@racket-lang.org> > Subject: Re: [racket] Better discoverability for errortrace > Message-ID: <5429b426.7020...@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 <ro...@eecs.northwestern.edu> > To: Jonathan Schuster <schus...@ccs.neu.edu> > Cc: Racket List <users@racket-lang.org> > Subject: Re: [racket] Better discoverability for errortrace > Message-ID: > <CAL3TdOPCAahyza53fPqtMQH23bumTO=ttoubpq+yx3pr8ok...@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 <schus...@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 <ro...@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 <schus...@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 <bl...@cornell.edu> > To: Matthias Felleisen <matth...@ccs.neu.edu> > Cc: users <users@racket-lang.org>, Sam Tobin-Hochstadt > <sa...@cs.indiana.edu> > Subject: Re: [racket] Cyclic data structures in Typed Racket > Message-ID: > <CAAtAoRoBwwg=ddmvkl49sxajunlzqrfcb5tsdbpxr0mfetr...@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 <matth...@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 <sa...@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.hin...@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 > ************************************** ____________________ Racket Users list: http://lists.racket-lang.org/users
