Re: [racket-dev] Comments and DrRacket
Hi Harry, This would be a nice feature indeed. Note that you can use code folding for that purpose, but I personally don't like it because it makes the saved source code non-textual. One related proposal that I made earlier is to have a multi-view document, where you could select Source, Source + Tests, Tests only, and then maybe same for comments, etc. though maybe you'd like partial hiding of the comments. It's unlikely that PLT is going to implement that any time soon, so it's more in our hands I guess (though it's unlikely that I'll do that anytime soon either). Laurent On Wed, Jun 20, 2012 at 12:16 AM, Harry Spier vasishtha.sp...@gmail.comwrote: I tend to put a lot of comments not just at the beginning of procedures but also in the body of the procedures, usually above lines of code instead of to the right because the comments can be fairly long and multi-line. This makes it easier to understand the procedure on the one hand but because it spreads the procedure out over several screens makes it harder to follow also. For that reason I thought a nice feature in DrRacket might be a menu button to either display or hide comments, so you could see the comments and then click the button and disappear them and see the entire or most of the procedure to see the program flow. Thanks, Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Redex for abstract machines / analysis prototypes
My papers have been using record notation. Say for lookup:
s{C = x, E = rho} -- s[C := v, E := rho_0] where rho(x) = (v rho_0)
Is this not good enough?
-Ian
- Original Message -
From: Robby Findler ro...@eecs.northwestern.edu
To: J. Ian Johnson i...@ccs.neu.edu
Cc: dev dev@racket-lang.org, n...@ccs.neu.edu
Sent: Wed, 20 Jun 2012 01:27:18 -0400 (EDT)
Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes
I have thought about adding something that would solve this problem to
Redex off and on for a few years and am circling something I think is
reasonable. (The main thing I think you've not considered below is how
to typeset things, but that said I have in mind something similar in
spirit to what you write.)
Unfortunately, I don't see myself getting to it in the short term (ie
the coming month or two), but your message will definitely move it up
on my list.
Robby
On Tue, Jun 19, 2012 at 6:08 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
Machine semantics for real machines (like the JVM or Racket's VM) or
non-standard semantics for an abstract interpretation (like what I end up
getting into) can get up to monstrous numbers of components for each state
that usually don't matter. I and I'm sure many others would appreciate a
reduction relation language that is a little more like UIUC's K.
Here is a concrete suggestion of what I imagine (some support for patterns on
hashes):
1) Add a pattern (hash (literal pat) ...) to match hashes up to the specified
keys (hashes with more keys are still accepted).
2) Add rewrite rules for changing the current state.
-- (next-state (r r) ...)
-- (get r r)
-- (set r r r)
-- (set* r (r r) ...)
Where
(get r_0 r_1) is ,(hash-ref (term r_0) (term r_1)
'something-that-never-matches)
(set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2))
(set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to
write.
And assuming the LHS is named state,
(next-state (r_k r_v) ...) is (set* state (r_k r_v) ...)
Not-the-best-example-since-it's-so-minimal:
(define-language CEK
[e x (e e) lam]
[lam (lambda (x) e)]
[rho (hash)]
[kont mt (ar e rho kont) (fn e rho kont))])
(define R
(machine-step CEK
[-- (hash (C x) (E rho))
(next-state (C lam) (E rho*))
(where (lam rho*) (get rho x))]
[-- (hash (C (e_0 e_1)) (E rho) (K kont))
(next-state (C e_0) (K (ar e_1 rho kont)))]
[-- (hash (C lam) (E rho) (K (ar e rho_0 kont)))
(next-state (C e) (E rho_0) (K (fn lam rho kont)))]
[-- (hash (C v) (K (fn (lambda (x) e) rho kont)))
(next-state (C e) (E (set rho x (v rho))) (K kont))]))
(define (inject e) (term (set* #hash() (C ,e) (E #hash()) (K mt
Is this reasonably simple to add to Redex? It would be a very welcome
addition.
-Ian
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Redex for abstract machines / analysis prototypes
On Wed, Jun 20, 2012 at 7:48 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
My papers have been using record notation. Say for lookup:
s{C = x, E = rho} -- s[C := v, E := rho_0] where rho(x) = (v rho_0)
Can you explain this line in a little more detail?
Is this not good enough?
I don't think I said it wasn't.
Robby
-Ian
- Original Message -
From: Robby Findler ro...@eecs.northwestern.edu
To: J. Ian Johnson i...@ccs.neu.edu
Cc: dev dev@racket-lang.org, n...@ccs.neu.edu
Sent: Wed, 20 Jun 2012 01:27:18 -0400 (EDT)
Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes
I have thought about adding something that would solve this problem to
Redex off and on for a few years and am circling something I think is
reasonable. (The main thing I think you've not considered below is how
to typeset things, but that said I have in mind something similar in
spirit to what you write.)
Unfortunately, I don't see myself getting to it in the short term (ie
the coming month or two), but your message will definitely move it up
on my list.
Robby
On Tue, Jun 19, 2012 at 6:08 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
Machine semantics for real machines (like the JVM or Racket's VM) or
non-standard semantics for an abstract interpretation (like what I end up
getting into) can get up to monstrous numbers of components for each state
that usually don't matter. I and I'm sure many others would appreciate a
reduction relation language that is a little more like UIUC's K.
Here is a concrete suggestion of what I imagine (some support for patterns
on hashes):
1) Add a pattern (hash (literal pat) ...) to match hashes up to the
specified keys (hashes with more keys are still accepted).
2) Add rewrite rules for changing the current state.
-- (next-state (r r) ...)
-- (get r r)
-- (set r r r)
-- (set* r (r r) ...)
Where
(get r_0 r_1) is ,(hash-ref (term r_0) (term r_1)
'something-that-never-matches)
(set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2))
(set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to
write.
And assuming the LHS is named state,
(next-state (r_k r_v) ...) is (set* state (r_k r_v) ...)
Not-the-best-example-since-it's-so-minimal:
(define-language CEK
[e x (e e) lam]
[lam (lambda (x) e)]
[rho (hash)]
[kont mt (ar e rho kont) (fn e rho kont))])
(define R
(machine-step CEK
[-- (hash (C x) (E rho))
(next-state (C lam) (E rho*))
(where (lam rho*) (get rho x))]
[-- (hash (C (e_0 e_1)) (E rho) (K kont))
(next-state (C e_0) (K (ar e_1 rho kont)))]
[-- (hash (C lam) (E rho) (K (ar e rho_0 kont)))
(next-state (C e) (E rho_0) (K (fn lam rho kont)))]
[-- (hash (C v) (K (fn (lambda (x) e) rho kont)))
(next-state (C e) (E (set rho x (v rho))) (K kont))]))
(define (inject e) (term (set* #hash() (C ,e) (E #hash()) (K mt
Is this reasonably simple to add to Redex? It would be a very welcome
addition.
-Ian
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Redex for abstract machines / analysis prototypes
That line is how I would render the lookup rule for the CEK machine (in the
below example).
I actually use \equiv to match structure instead of = in this LHS:
s{C \equiv x, E \equiv rho}
That is, I say that for whatever is in C, there exists an x of the type of x's
nonterminal (in this case variable-not-otherwise-mentioned) such that C = x.
This kind of implicit quantification is not always necessary. Indeed, others
might lift the existential quantification over the entire reduction relation
definition and make them universal. That said, I think that a visual
distinction between matching and rewriting is important.
And I use braces to note selection of multiple fields. For a single field
(let's say E), I would say
s.E
This selection is also written a different way in some texts (indeed in a draft
I've written) as
E_s
Though cascading nesting leads to vanishingly small notation. I thus abandoned
that notation.
As for the RHS, I use brackets and := to note substitutions. Usual substitution
notation like e[v/x] has been ambiguous across texts (are we substituting v for
x or x for v?) and its extension to many substitutions is also comma separated.
Seeing as a field of a record should not be considered an identifier, lambda
calculus-style substitution notation makes less sense.
As for the rho(x) in the where clause, I treat finite maps as primitive in
most of by machines, and I lament having to escape to hash-ref or hash-set.
Thus I suggested a special form for environment look-ups and functional
extension. In fact that reminds me of another piece of notation I use.
Suppose I have a starting store sigma, and I construct what I see as the
extension to sigma due to many allocations in one step, sigma'. To denote the
store that is sigma with all mappings of sigma' preferred before going to
sigma, I write
sigma \triangleleft sigma'
I would also want to override that notation, since when I move to an abstract
interpretation, that would become a join,
sigma \sqcup sigma'
This is just how I note such record/environment manipulations. I would be
interested if any other heavy users of Redex for machine semantics have a
different opinion.
-Ian
- Original Message -
From: Robby Findler ro...@eecs.northwestern.edu
To: J. Ian Johnson i...@ccs.neu.edu
Cc: dev dev@racket-lang.org, n...@ccs.neu.edu
Sent: Wednesday, June 20, 2012 9:20:35 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes
On Wed, Jun 20, 2012 at 7:48 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
My papers have been using record notation. Say for lookup:
s{C = x, E = rho} -- s[C := v, E := rho_0] where rho(x) = (v rho_0)
Can you explain this line in a little more detail?
Is this not good enough?
I don't think I said it wasn't.
Robby
-Ian
- Original Message -
From: Robby Findler ro...@eecs.northwestern.edu
To: J. Ian Johnson i...@ccs.neu.edu
Cc: dev dev@racket-lang.org, n...@ccs.neu.edu
Sent: Wed, 20 Jun 2012 01:27:18 -0400 (EDT)
Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes
I have thought about adding something that would solve this problem to
Redex off and on for a few years and am circling something I think is
reasonable. (The main thing I think you've not considered below is how
to typeset things, but that said I have in mind something similar in
spirit to what you write.)
Unfortunately, I don't see myself getting to it in the short term (ie
the coming month or two), but your message will definitely move it up
on my list.
Robby
On Tue, Jun 19, 2012 at 6:08 PM, J. Ian Johnson i...@ccs.neu.edu wrote:
Machine semantics for real machines (like the JVM or Racket's VM) or
non-standard semantics for an abstract interpretation (like what I end up
getting into) can get up to monstrous numbers of components for each state
that usually don't matter. I and I'm sure many others would appreciate a
reduction relation language that is a little more like UIUC's K.
Here is a concrete suggestion of what I imagine (some support for patterns
on hashes):
1) Add a pattern (hash (literal pat) ...) to match hashes up to the
specified keys (hashes with more keys are still accepted).
2) Add rewrite rules for changing the current state.
-- (next-state (r r) ...)
-- (get r r)
-- (set r r r)
-- (set* r (r r) ...)
Where
(get r_0 r_1) is ,(hash-ref (term r_0) (term r_1)
'something-that-never-matches)
(set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2))
(set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to
write.
And assuming the LHS is named state,
(next-state (r_k r_v) ...) is (set* state (r_k r_v) ...)
Not-the-best-example-since-it's-so-minimal:
(define-language CEK
[e x (e e) lam]
[lam (lambda (x) e)]
[rho (hash)]
[kont mt (ar e rho kont) (fn e rho kont))])
(define R
(machine-step CEK
[-- (hash (C x) (E rho))
(next-state (C lam) (E
Re: [racket-dev] [plt] Push #24868: master branch updated
Just now, Jon Rafkind wrote: This push resulted in the following failure (drdr will tell you the same thing in a few minutes probably). raco setup: error: during making for stepper/private raco setup: expand: unbound identifier in module raco setup: in: stepper-syntax-property raco setup: source: raco setup: xml-box.rkt:20:11 It killed the nightly build too. Re drdr: it's not too useful at the moment, due to a change I did to the props file (not the properties, just the code). Fortunately, the failure bugged only the current list of nobodies (Sam, Jay, and me). My recent push should get it to working state again. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message structure (error-message overhaul)
Eli Barzilay wrote at 06/19/2012 08:11 PM: * There's a whole range of tools that work with the usual file:line:vol: message per line format -- Emacs compilation buffer, the on-line-check-syntax-like error highlighting, log parsers, etc. (The emacs on-line checking is something that two people already noticed as a victim...) FWIW, I think I can make the Emacs stuff work better with the new error message format. On a related matter, it's helpful when file names in error messages contain a complete path. (Prior to these new error messages, for example, raco setup would produce a mix of relative and absolute paths in error messages.) Performance-wise, for exceptions involving paths, if resolving a complete path happens to be expensive... If the site that constructs an exn that includes a relative path also has a way to include in the struct a complete path to which the path in question is relative, that would let error message rendering show a full path without slowing things in cases in which the exception is handled without rendering the path. Or maybe resolving a complete path is relatively inexpensive in cases in which we'd want to raise and handle an exception with a path. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24868: master branch updated
On Jun 20, 2012, at 9:10 AM, Eli Barzilay wrote: Just now, Jon Rafkind wrote: This push resulted in the following failure (drdr will tell you the same thing in a few minutes probably). raco setup: error: during making for stepper/private raco setup: expand: unbound identifier in module raco setup: in: stepper-syntax-property raco setup: source: raco setup: xml-box.rkt:20:11 It killed the nightly build too. Re drdr: it's not too useful at the moment, due to a change I did to the props file (not the properties, just the code). Fortunately, the failure bugged only the current list of nobodies (Sam, Jay, and me). My recent push should get it to working state again. Yep, fixed this in #24872. I shouldn't admit this, but I'm happy that's the extent of the damage (seen thus far); I removed a bunch of references to the stepper collection entirely (from things like lang, deinprogramm, 2htdp) and I'm surprised there was as much apparently dead code as I found. Thanks again, John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message structure (error-message overhaul)
Earlier today, Neil Toronto wrote: On 06/19/2012 06:11 PM, Eli Barzilay wrote: [...] (plot sin) [...] Hear, hear! I make this mistake myself after going a month or two without plotting anything. (Off-topic for the thread, but why not make that work since it's apparently an even more popular expectation than I thought if *you* make that mistake?) Every time, I've dreaded some possible future in which I do it in front of a non-Racketeer. Yeah -- and with students this dread is translated to concrete terms: when a student sees such an error message (TR, in my case), they will, in the absolute majority of cases, complain that my code is broken. I've had plenty of semesters that were free of any problems in my course code, yet when students saw these errors they'd quickly conclude that my code is broken. 12 hours ago, Robby Findler wrote: I don't know if it is intended, but these messages come across as just disliking the idea of putting more (and structured) information into the error messages. I'm guessing Eli does not intend that [...] Your guess is very much correct. I very strongly *like* the idea of both more information and of more structure. In fact, the `plot'-error is something that we talked about at NEU shortly before Matthew did this revision, and one of the things that we rolled around was having a similar kind of structure. And only a week later when Matthew came I learned about the revision that does it half-way in a text format. So on the structure side, I'd really like to have *more* of it. On the information side, one of the disadvantages of having just text is that you can't add more random bits of information since soon enogh all error messages become multi-page disasters -- so it's implicit in my other discussion on the organization of errors, but another goal that I would very much like to promote is to have *more* information (and make it possible by not always showing all of it). And while I'm certainly biased, I don't dread showing the (plot sin) message to a Racket outsider. I think it is pretty informative, if you start at the beginning and read it out loud. It might look like a joke if I'll quote how a student would read it, but it's more than just a joke -- it's an explanation for why they don't have a clue about what went wrong, then resort to this verbatim reading, and later the inevitable conclusion that the software is broke. Anyways, I can see two possibilities to help here. See if either of them seem reasonable to those unsatisfied: 1) we can adjust pretty-print so it (when it fits), puts lists that have keywords followed by non-keywords on the same line. [...] That would be a good tweak, but I don't think that it's enough to avoid the reaction I'm talking about... 2) in DrRacket, we can adjust the error print handler so that it prints only the first three or four lines (or perhaps the first two sections or something like that) and then puts a more ... link (in a different font in a nice looking way like we see all over the web) that will unfold the entire error. That's very close to a concrete suggestion that I started on last night. I'll post that in another thread. 20 minutes ago, Neil Van Dyke wrote: FWIW, I think I can make the Emacs stuff work better with the new error message format. Only if it becomes reliabley parsable. But in any case, what I talked about is the fact that there are many tools that just work with the traditional error messages. On a related matter, it's helpful when file names in error messages contain a complete path. (Prior to these new error messages, for example, raco setup would produce a mix of relative and absolute paths in error messages.) That's related to this because if there are known properties with specific kinds of values, then the decision to show a shortened name can be done in the renderrer. Performance-wise, for exceptions involving paths, if resolving a complete path happens to be expensive... (One of the nice things about errors is that performance is usually not an issue...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Error message proposal
Here's a concrete proposal for error message structe. I'll leave the highlevel philosophical discussion to the other threads -- but JFYI, it does require accepting the problems I mention in the phrasing thread. The general idea is that the first line of an error message is a title, and therefore should provide as much helpful information as possible, in a short form that usually will fit on a single line. This works well with the previous error message format, but broken down completely when errors contain a lot of details. Notable examples: list of paths in a cyclic require; the list of other arguments in type errors; the probably explanation on an empty () application error; and the suggestion made in the link errors. So I'm suggesting that the first line is the error title which is kept in a form similar to what it was. That is: [optional short location information] offending token: short description (fits on one line) The next line(s) (single or few) add more precise and verbose details on the error. Examples of that are the suggestion I mentioned above, or the more accurate description of an unbound identifier error, or the `#%app' mention in the () case. Following that are the fields, which can stay in a semi-structured textual format for making them parsable. This structure should be specified, but given the above two parts there is no need for being very specific with various fields etc. As a concrete example, a contract error could be: foo.rkt:10:15: blah: bad input Contract violation in the first argument, your code broke the contract of blah from `some-library/blah'. expected: ... given: ... argument position: ... other arguments: ... full path: ... contract location: ... context: ... Note how the first line is imprecise, and provides just a summary. The idea is what I discussed previously -- in many cases this error will pop up after some revision to the code that you just did, so that's enough to know what the problem. The following two lines provide more precise information -- and now that they're on following lines, that description is no longer restriced to be short in any way. This means, for example, that Ryan's semi-complaint about the non-preciseness of unbound identifier errors can be addressed. Next to that there is the list of fields, and since it's all down after the main texts, it's becoming practical to add a lot of relevant information like full paths of the files in question, even more detailed explanations on what the error is, suggestions for fixing it, pointers to URLs about those errors, etc etc. From a presentation point of view (eg, drracket and xrepl), this format makes things very easy, since it follows the way you'd want to present the information. For example, drracket can do the following pretty easily (just random suggestions, of course): * Show the usual stop-sign line with just the title line (without the location) * When you hover over the line, a popup opens up with the detailed two-line explanation. * When you click the icon, you jump to the relevant location with that popup. * When you hover over the error, or maybe in the popup, you see a list of field names, and clicking them shows the contents of the field. Even a textual interface like xrepl can do something similar, where the exposition of details goes gradually based on your needs. More benefits: * It's probably not hard to re-change the code, since it's keeping the multi-line aspect and the fields. * Sounds like `error' is not going away in its current format which already does the first-line thing fine. * Existing un-updated code works fine too. * With the assumption that fields are not initially shown (which translates to some parameter), a lot more information can be added in them, even when they're irrelevant for human consumption. For example, full paths to source files can blow up the message (eg, paths to the blamed file, the contract definition, and the contracted file; or list of paths in a cycle; or showing a *complete* stacktrace). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message proposal
I really like this idea. It seems to be the best of both worlds. I agree with Robby that more information and structure is good. I also think, with Eli, that the first line is special for humans and for existing tools. Jay On Wed, Jun 20, 2012 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote: Here's a concrete proposal for error message structe. I'll leave the highlevel philosophical discussion to the other threads -- but JFYI, it does require accepting the problems I mention in the phrasing thread. The general idea is that the first line of an error message is a title, and therefore should provide as much helpful information as possible, in a short form that usually will fit on a single line. This works well with the previous error message format, but broken down completely when errors contain a lot of details. Notable examples: list of paths in a cyclic require; the list of other arguments in type errors; the probably explanation on an empty () application error; and the suggestion made in the link errors. So I'm suggesting that the first line is the error title which is kept in a form similar to what it was. That is: [optional short location information] offending token: short description (fits on one line) The next line(s) (single or few) add more precise and verbose details on the error. Examples of that are the suggestion I mentioned above, or the more accurate description of an unbound identifier error, or the `#%app' mention in the () case. Following that are the fields, which can stay in a semi-structured textual format for making them parsable. This structure should be specified, but given the above two parts there is no need for being very specific with various fields etc. As a concrete example, a contract error could be: foo.rkt:10:15: blah: bad input Contract violation in the first argument, your code broke the contract of blah from `some-library/blah'. expected: ... given: ... argument position: ... other arguments: ... full path: ... contract location: ... context: ... Note how the first line is imprecise, and provides just a summary. The idea is what I discussed previously -- in many cases this error will pop up after some revision to the code that you just did, so that's enough to know what the problem. The following two lines provide more precise information -- and now that they're on following lines, that description is no longer restriced to be short in any way. This means, for example, that Ryan's semi-complaint about the non-preciseness of unbound identifier errors can be addressed. Next to that there is the list of fields, and since it's all down after the main texts, it's becoming practical to add a lot of relevant information like full paths of the files in question, even more detailed explanations on what the error is, suggestions for fixing it, pointers to URLs about those errors, etc etc. From a presentation point of view (eg, drracket and xrepl), this format makes things very easy, since it follows the way you'd want to present the information. For example, drracket can do the following pretty easily (just random suggestions, of course): * Show the usual stop-sign line with just the title line (without the location) * When you hover over the line, a popup opens up with the detailed two-line explanation. * When you click the icon, you jump to the relevant location with that popup. * When you hover over the error, or maybe in the popup, you see a list of field names, and clicking them shows the contents of the field. Even a textual interface like xrepl can do something similar, where the exposition of details goes gradually based on your needs. More benefits: * It's probably not hard to re-change the code, since it's keeping the multi-line aspect and the fields. * Sounds like `error' is not going away in its current format which already does the first-line thing fine. * Existing un-updated code works fine too. * With the assumption that fields are not initially shown (which translates to some parameter), a lot more information can be added in them, even when they're irrelevant for human consumption. For example, full paths to source files can blow up the message (eg, paths to the blamed file, the contract definition, and the contracted file; or list of paths in a cycle; or showing a *complete* stacktrace). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message proposal
Thanks. I'll give this a try as soon as possible. At Wed, 20 Jun 2012 13:32:32 -0400, Eli Barzilay wrote: Here's a concrete proposal for error message structe. I'll leave the highlevel philosophical discussion to the other threads -- but JFYI, it does require accepting the problems I mention in the phrasing thread. The general idea is that the first line of an error message is a title, and therefore should provide as much helpful information as possible, in a short form that usually will fit on a single line. This works well with the previous error message format, but broken down completely when errors contain a lot of details. Notable examples: list of paths in a cyclic require; the list of other arguments in type errors; the probably explanation on an empty () application error; and the suggestion made in the link errors. So I'm suggesting that the first line is the error title which is kept in a form similar to what it was. That is: [optional short location information] offending token: short description (fits on one line) The next line(s) (single or few) add more precise and verbose details on the error. Examples of that are the suggestion I mentioned above, or the more accurate description of an unbound identifier error, or the `#%app' mention in the () case. Following that are the fields, which can stay in a semi-structured textual format for making them parsable. This structure should be specified, but given the above two parts there is no need for being very specific with various fields etc. As a concrete example, a contract error could be: foo.rkt:10:15: blah: bad input Contract violation in the first argument, your code broke the contract of blah from `some-library/blah'. expected: ... given: ... argument position: ... other arguments: ... full path: ... contract location: ... context: ... Note how the first line is imprecise, and provides just a summary. The idea is what I discussed previously -- in many cases this error will pop up after some revision to the code that you just did, so that's enough to know what the problem. The following two lines provide more precise information -- and now that they're on following lines, that description is no longer restriced to be short in any way. This means, for example, that Ryan's semi-complaint about the non-preciseness of unbound identifier errors can be addressed. Next to that there is the list of fields, and since it's all down after the main texts, it's becoming practical to add a lot of relevant information like full paths of the files in question, even more detailed explanations on what the error is, suggestions for fixing it, pointers to URLs about those errors, etc etc. From a presentation point of view (eg, drracket and xrepl), this format makes things very easy, since it follows the way you'd want to present the information. For example, drracket can do the following pretty easily (just random suggestions, of course): * Show the usual stop-sign line with just the title line (without the location) * When you hover over the line, a popup opens up with the detailed two-line explanation. * When you click the icon, you jump to the relevant location with that popup. * When you hover over the error, or maybe in the popup, you see a list of field names, and clicking them shows the contents of the field. Even a textual interface like xrepl can do something similar, where the exposition of details goes gradually based on your needs. More benefits: * It's probably not hard to re-change the code, since it's keeping the multi-line aspect and the fields. * Sounds like `error' is not going away in its current format which already does the first-line thing fine. * Existing un-updated code works fine too. * With the assumption that fields are not initially shown (which translates to some parameter), a lot more information can be added in them, even when they're irrelevant for human consumption. For example, full paths to source files can blow up the message (eg, paths to the blamed file, the contract definition, and the contracted file; or list of paths in a cycle; or showing a *complete* stacktrace). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Bug in Racket's I/O?
Hi all, I think I've found a bug in Racket's I/O. Please interpret the following text as relating to the attached tarball with a small example of the problem. The problem manifests for me on both platforms I've tried, OS X and Linux. When `sync`ing on `read-bytes-evt` at the same time as on `alarm-evt`, it seems that if the `read-bytes-evt` would have come ready but the `alarm-evt` is the one actually chosen, the input from `read-bytes-evt` gets corrupted. This only seems to happen if a single `read-bytes-evt` instance is reused! If a fresh `read-bytes-evt` is constructed every time, the input stream remains uncorrupted. To see this, run `racket buggy-server.rkt 0`, which uses a single `read-bytes-evt` instance but does not use any `alarm-evt` instances. In another terminal, run `./run-test-osx.sh` (or `./run-test-linux.sh`, as appropriate). The program `./run-test-osx.sh` should terminate without producing any output. Now, kill off the instance of `buggy-server.rkt`, and start another, this time by running `racket buggy-server.rkt 1`. This instance uses both a single `read-bytes-evt` instance and an `alarm-evt` instance. Now, running `./run-test-osx.sh` should still produce no output, but in fact on most runs, some output (from diffing the input against the output of the socket) is produced, meaning that the echoed output differed from the input. Regards, Tony io-bug.tar.gz Description: GNU Zip compressed data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Bug in Racket's I/O?
Sorry, I should have filed a bug report instead of mailing the list. I'm filing the report now. On 2012-06-20 8:22 PM, Tony Garnock-Jones wrote: Hi all, I think I've found a bug in Racket's I/O. Please interpret the following text as relating to the attached tarball with a small example of the problem. The problem manifests for me on both platforms I've tried, OS X and Linux. When `sync`ing on `read-bytes-evt` at the same time as on `alarm-evt`, it seems that if the `read-bytes-evt` would have come ready but the `alarm-evt` is the one actually chosen, the input from `read-bytes-evt` gets corrupted. This only seems to happen if a single `read-bytes-evt` instance is reused! If a fresh `read-bytes-evt` is constructed every time, the input stream remains uncorrupted. To see this, run `racket buggy-server.rkt 0`, which uses a single `read-bytes-evt` instance but does not use any `alarm-evt` instances. In another terminal, run `./run-test-osx.sh` (or `./run-test-linux.sh`, as appropriate). The program `./run-test-osx.sh` should terminate without producing any output. Now, kill off the instance of `buggy-server.rkt`, and start another, this time by running `racket buggy-server.rkt 1`. This instance uses both a single `read-bytes-evt` instance and an `alarm-evt` instance. Now, running `./run-test-osx.sh` should still produce no output, but in fact on most runs, some output (from diffing the input against the output of the socket) is produced, meaning that the echoed output differed from the input. Regards, Tony _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-syntax hack: patch to show how many uses an identifier has
John Clements wrote at 06/20/2012 10:48 PM: When I'm using online check syntax, I often look at the lines leaving an identifier and wonder: is that just one line, or are there two or three? When lines overlap, there's no easy way to tell. This can be important in refactoring decisions, or in debugging (how many uses of this thing are there to check?). Yes, I've wondered this too. And in large files, it's often really hard to tell, like in your first screenshot. Maybe, if the mouse hovers over the center point of a binding identifier, there's a tooltip that shows useful info, such as how many references (maybe in what procedures?), and whether it's provided by the module. (I haven't thought about submodules, though.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
