[racket-dev] planet bug reporting interface
[This is intentionally stream-of-consciousness...] The planet home page doesn't say anything about how to report bugs (the word bug really only appears in package descriptions, and error doesn't at all). The same is true of individual packages. So it's really not clear what one should do. There is also a Top Bug Closers [Trac], which is a bit confusing because it looks like it *might* be a mechanism for submitting bug reports, but the Trac interface does not make this obvious. In addition, clicking on the author's page says what tickets they have open but not how to create a new one. To me it's even more confusing that the package's description lists the # of tickets but doesn't have a link to where/what. Okay, after nearly eight minutes of searching I found that I need to look for the New Ticket link! It was under the fold (ie, I needed to scroll down) in my browser. This was all probably completely intuitive to the designer, but it wasn't at all so to me even though, as outlined, I was trying my darndest to find a way to report a problem, but couldn't find how. I suggest that there are already enough words floating around (bug, error, problem, issue) that adding one more (ticket) is unnecessary. I recognize that ticket is more neutral (eg, can include a feature request), but still. Also, I think a prominent link entitled something like Report a problem (ideally the same text as in the Help menu -- so I guess Submit Bug Report...) would be good. Of course, that then takes you to to the open bugs portion of the package. In the CSS styling there, a little more space around the line with [All Tickets] [New Ticket] would also make it easier to find the latter. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet bug reporting interface
FWIW, ticket is a trac term and while I agree that it would be good to avoid another piece of vocab, that's not something I think we'll change before planet 2.0. Robby On Tue, Sep 6, 2011 at 8:20 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: [This is intentionally stream-of-consciousness...] The planet home page doesn't say anything about how to report bugs (the word bug really only appears in package descriptions, and error doesn't at all). The same is true of individual packages. So it's really not clear what one should do. There is also a Top Bug Closers [Trac], which is a bit confusing because it looks like it *might* be a mechanism for submitting bug reports, but the Trac interface does not make this obvious. In addition, clicking on the author's page says what tickets they have open but not how to create a new one. To me it's even more confusing that the package's description lists the # of tickets but doesn't have a link to where/what. Okay, after nearly eight minutes of searching I found that I need to look for the New Ticket link! It was under the fold (ie, I needed to scroll down) in my browser. This was all probably completely intuitive to the designer, but it wasn't at all so to me even though, as outlined, I was trying my darndest to find a way to report a problem, but couldn't find how. I suggest that there are already enough words floating around (bug, error, problem, issue) that adding one more (ticket) is unnecessary. I recognize that ticket is more neutral (eg, can include a feature request), but still. Also, I think a prominent link entitled something like Report a problem (ideally the same text as in the Help menu -- so I guess Submit Bug Report...) would be good. Of course, that then takes you to to the open bugs portion of the package. In the CSS styling there, a little more space around the line with [All Tickets] [New Ticket] would also make it easier to find the latter. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet bug reporting interface
By the way, something happened recently (in the past week or two) to the tickets on planet. I had opened two tickets in early August to remind myself of things to fix, but a few days ago when I looked, there were no open tickets listed anymore for the package (http://planet.racket-lang.org/display.ss?package=racketui.pltowner=nah22). I still have the confirmation emails (one is below), and the trac ticket URLs now go to some completely unrelated ticket and I can't seem to find mine by searching the trac site. --- nadeem #343: removing entry from empty list of saved entries causes error +--- Reporter: nadeem@…|Owner: nah22 Type: defect | Status: new Priority: minor |Milestone: Component: nah22/racketui.plt | Keywords: Planetversion: (1 5) | Pltversion: +--- removing entry from empty list of saved entries causes error -- Ticket URL: http://planet.racket-lang.org/trac/ticket/343 PLaneT Issue Tracking System http://planet.racket-lang.org/ A Trac-based issue-tracking system for PLaneT, the package repository for Racket _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet bug reporting interface
I'm not sure what happened here, but it could have been that I accidentally deleted them because of all of the spam tickets that we get (ie I messed up and thought they were spam or I typed the wrong numbers). I'm very sorry if that was the case. I do try to be careful (and nearly all of the spam goes to a specific package (not yours) so it is usually a big red flag when I'm deleting a ticket that didn't go to that package). Anyways, if that did happen, I'm very sorry. Please do re-file them. Robby On Tue, Sep 6, 2011 at 9:23 AM, Nadeem Abdul Hamid nad...@acm.org wrote: By the way, something happened recently (in the past week or two) to the tickets on planet. I had opened two tickets in early August to remind myself of things to fix, but a few days ago when I looked, there were no open tickets listed anymore for the package (http://planet.racket-lang.org/display.ss?package=racketui.pltowner=nah22). I still have the confirmation emails (one is below), and the trac ticket URLs now go to some completely unrelated ticket and I can't seem to find mine by searching the trac site. --- nadeem #343: removing entry from empty list of saved entries causes error +--- Reporter: nadeem@… | Owner: nah22 Type: defect | Status: new Priority: minor | Milestone: Component: nah22/racketui.plt | Keywords: Planetversion: (1 5) | Pltversion: +--- removing entry from empty list of saved entries causes error -- Ticket URL: http://planet.racket-lang.org/trac/ticket/343 PLaneT Issue Tracking System http://planet.racket-lang.org/ A Trac-based issue-tracking system for PLaneT, the package repository for Racket _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet bug reporting interface
OK, no problem. Thanks, --- nadeem On Tue, Sep 6, 2011 at 10:30 AM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure what happened here, but it could have been that I accidentally deleted them because of all of the spam tickets that we get (ie I messed up and thought they were spam or I typed the wrong numbers). I'm very sorry if that was the case. I do try to be careful (and nearly all of the spam goes to a specific package (not yours) so it is usually a big red flag when I'm deleting a ticket that didn't go to that package). Anyways, if that did happen, I'm very sorry. Please do re-file them. Robby On Tue, Sep 6, 2011 at 9:23 AM, Nadeem Abdul Hamid nad...@acm.org wrote: By the way, something happened recently (in the past week or two) to the tickets on planet. I had opened two tickets in early August to remind myself of things to fix, but a few days ago when I looked, there were no open tickets listed anymore for the package (http://planet.racket-lang.org/display.ss?package=racketui.pltowner=nah22). I still have the confirmation emails (one is below), and the trac ticket URLs now go to some completely unrelated ticket and I can't seem to find mine by searching the trac site. --- nadeem #343: removing entry from empty list of saved entries causes error +--- Reporter: nadeem@… | Owner: nah22 Type: defect | Status: new Priority: minor | Milestone: Component: nah22/racketui.plt | Keywords: Planetversion: (1 5) | Pltversion: +--- removing entry from empty list of saved entries causes error -- Ticket URL: http://planet.racket-lang.org/trac/ticket/343 PLaneT Issue Tracking System http://planet.racket-lang.org/ A Trac-based issue-tracking system for PLaneT, the package repository for Racket _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet bug reporting interface
Understood. Hopefully the UI/UX comments in my message will help as you're designing 2.0. On Tue, Sep 6, 2011 at 9:25 AM, Robby Findler ro...@eecs.northwestern.edu wrote: FWIW, ticket is a trac term and while I agree that it would be good to avoid another piece of vocab, that's not something I think we'll change before planet 2.0. Robby On Tue, Sep 6, 2011 at 8:20 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: [This is intentionally stream-of-consciousness...] The planet home page doesn't say anything about how to report bugs (the word bug really only appears in package descriptions, and error doesn't at all). The same is true of individual packages. So it's really not clear what one should do. There is also a Top Bug Closers [Trac], which is a bit confusing because it looks like it *might* be a mechanism for submitting bug reports, but the Trac interface does not make this obvious. In addition, clicking on the author's page says what tickets they have open but not how to create a new one. To me it's even more confusing that the package's description lists the # of tickets but doesn't have a link to where/what. Okay, after nearly eight minutes of searching I found that I need to look for the New Ticket link! It was under the fold (ie, I needed to scroll down) in my browser. This was all probably completely intuitive to the designer, but it wasn't at all so to me even though, as outlined, I was trying my darndest to find a way to report a problem, but couldn't find how. I suggest that there are already enough words floating around (bug, error, problem, issue) that adding one more (ticket) is unnecessary. I recognize that ticket is more neutral (eg, can include a feature request), but still. Also, I think a prominent link entitled something like Report a problem (ideally the same text as in the Help menu -- so I guess Submit Bug Report...) would be good. Of course, that then takes you to to the open bugs portion of the package. In the CSS styling there, a little more space around the line with [All Tickets] [New Ticket] would also make it easier to find the latter. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] planet versioning spec?
In the planet documentation, I don't see a spec of the semantics of versioning. (If it's there, can someone please point me to it?) My understanding is this; can someone confirm or correct it? (The #lang part probably isn't relevant, but since that's how I need to use it, I'm being maximally specific.) If I say #lang planet foo/bar:1:1 that presumably is an explicit reference to :1:1, no more and no fewer. If I just say #lang planet foo/bar I mean the latest version of foo/bar that I've downloaded; don't go checking right now for whether there's a newer version. So if foo/bar has moved on to :1:2, I'm still running :1:1. But I say ONCE #lang planet foo/bar:1:2 that will download and install it; subsequently, #lang planet foo/bar refers to :1:2. (I *think* this is part of what the section Previous Linkage says -- http://docs.racket-lang.org/planet/search-order.html -- but not all of this is specified.) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet versioning spec?
Did you see section 1.4 of the planet docs? Also there are two bugs (both of which are in 5.1.3 I believe): - one bug prevented planet from re-using downloaded packages; this has been fixed - the second bug prevented the linkage table from working (the bug's result caused just always ignored the linkage table). I kept that bug by making it clear that linkage table isn't work (stubbing out the code). I see I forgot to update the docs; I'll fix that. I posted here about the second bug and no one replied so I took that to mean that no one cared about this form of automatic upgrade. Here is the message: http://www.mail-archive.com/dev@racket-lang.org/msg03891.html As for your specific questions, I don't think what you write is what planet does, but maybe what you actually think is different (as I'm not completely clear about what you mean); hopefully the above clarifies... Robby On Tue, Sep 6, 2011 at 11:29 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: In the planet documentation, I don't see a spec of the semantics of versioning. (If it's there, can someone please point me to it?) My understanding is this; can someone confirm or correct it? (The #lang part probably isn't relevant, but since that's how I need to use it, I'm being maximally specific.) If I say #lang planet foo/bar:1:1 that presumably is an explicit reference to :1:1, no more and no fewer. If I just say #lang planet foo/bar I mean the latest version of foo/bar that I've downloaded; don't go checking right now for whether there's a newer version. So if foo/bar has moved on to :1:2, I'm still running :1:1. But I say ONCE #lang planet foo/bar:1:2 that will download and install it; subsequently, #lang planet foo/bar refers to :1:2. (I *think* this is part of what the section Previous Linkage says -- http://docs.racket-lang.org/planet/search-order.html -- but not all of this is specified.) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet versioning spec?
Did you see section 1.4 of the planet docs? Yes, I did. It referred me to section 2 for the search order. The rest of it is about referring to explicit version numbers, whereas my message was about what happens if you leave off version numbers. I guess I could boil down my basic question to, When is the network accessed? (relative to the naming of versions). Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] planet versioning spec?
On Tue, Sep 6, 2011 at 12:46 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Did you see section 1.4 of the planet docs? Yes, I did. It referred me to section 2 for the search order. The rest of it is about referring to explicit version numbers, whereas my message was about what happens if you leave off version numbers. I guess I could boil down my basic question to, When is the network accessed? (relative to the naming of versions). Without the bug fix: each time a package is installed. Otherwise, it is as you said. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] [Feature Request] for macro #:when clauses should bind their results if asked.
When writing a natural extension to racket/base for hashes, hash-filter-map, I found that what would be the most natural way to write it would look like so: (define (hash-filter-map f ht) (for/list ([(k v) (in-hash ht)] #:when/bind [res (f k v)]) res)) Instead I had to write (define (hash-filter-map f ht) (for/fold ([result '()]) ([(k v) (in-hash ht)] (cond [(f k v) = (lambda (temp) (cons temp result))] [else result]))) Which is less pretty. I'd add this myself, but the for macros are scary. Anyone familiar with this section of code willing to add this? -Ian _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [Feature Request] for macro #:when clauses should bind their results if asked.
You can also write: (for*/list ([(k v) (in-hash ht)] [res (in-value (f k v))] #:when res) res) The in-value sequence lifts values to length-one sequences for just such kinds of bindings. (The above is untested, so may need some fixing.) Carl Eastlund On Tue, Sep 6, 2011 at 2:35 PM, J. Ian Johnson i...@ccs.neu.edu wrote: When writing a natural extension to racket/base for hashes, hash-filter-map, I found that what would be the most natural way to write it would look like so: (define (hash-filter-map f ht) (for/list ([(k v) (in-hash ht)] #:when/bind [res (f k v)]) res)) Instead I had to write (define (hash-filter-map f ht) (for/fold ([result '()]) ([(k v) (in-hash ht)] (cond [(f k v) = (lambda (temp) (cons temp result))] [else result]))) Which is less pretty. I'd add this myself, but the for macros are scary. Anyone familiar with this section of code willing to add this? -Ian _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [Feature Request] for macro #:when clauses should bind their results if asked.
Just now, Carl Eastlund wrote: You can also write: (for*/list ([(k v) (in-hash ht)] [res (in-value (f k v))] #:when res) res) [It does seem a little too verbose with the 3 mentions of `res', but that's the same kind of verbosity as repeating `x' in: (for/list ([x (in-range 100 110)]) x) If there was some rule like with no body, the last bound loop variable(s) is used, then this becomes (for/list ([x (in-range 100 110)])) and the above: (for*/list ([(k v) (in-hash ht)] [res (in-value (f k v))] #:when res)) ] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] New runtime charting for DrDr
DrDr now has colorful, up-to-date, interactive charts for runtime on every file. For example, check out: http://drdr.racket-lang.org/23468/collects/tests/racket/benchmarks/common/ray.rkt The quick explanation: the solid yellow line shows the overall runtime of the file. The circles show the timing of uses of `time' inside the file. You can select any region of the chart to zoom into it. The reset button goes back to the initial state. You can turn the legend on and off with the show/hide legend button. Mousing over an individual point will tell you the exact timing at a particular push #. If the internal timing is much much shorter-duration than the overall runtime, it's shown on a different scale on the right y-axis. This is all built on the Flot [1] JavaScript charting library. Using this, it's possible to see trends in performance. For example, I want your feedback about this. Is it readable? Should I add the gc/system time for uses of `time'? Should I switch from points to lines? Is there anything else you'd like? [1] http://code.google.com/p/flot/ -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax property duplication
On Aug 18, 2011, at 5:32 AM, Sam Tobin-Hochstadt wrote: Yes, I understand why this happens. As I see it, there are a few possibilities: 1. The expander should check for duplicates, in some fashion. 2. This idiom is problematic, in the case where `stx' is both the input and used for the syntax properties of the output. 3. Macros may freely duplicate syntax properties. All of these have drawbacks, but (3), which you are suggesting, means either that syntax properties can only be used to specify idempotent information or that the non-idempotent ones need to have some *explicit* means by which equal elements can be distinguished, which must be part of the API of that syntax property. If we think this is how syntax properties ought to work, then we should add something to the documentation making this clear, and we should recognize that it's a limitation. Would syntax-property guards solve this problem? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Suggestions for monitoring unresponsive web server connection?
Our homework submission application, currently running under 5.1.1 with Jay's stateless infrastructure, has been going unresponsive on us a lot lately. In some cases, the process is still alive but the web server does not respond to requests. In some cases, the process has died. While this sometimes happens concurrently with high load, load is neither necessary nor sufficient. Are there commands we can use when we startup racket or the server that might give diagnostics to help trace the problem? We are not getting core dumps (even when the process dies). So far, monitoring top output hasn't revealed anything unusual or telling. Here's the uname -a listing, in case that is helpful: Linux turnin.cs.wpi.edu 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:22:04 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux thanks, Kathi _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Suggestions for monitoring unresponsive web server connection?
Kathi Fisler wrote at 09/06/2011 08:13 PM: Are there commands we can use when we startup racket or the server that might give diagnostics to help trace the problem? Intermittent failures are a headache. In addition to whatever people advise here, you might want to add your own detailed logging to a file, with timestamps. Don't be afraid to dump dozens of lines of log output per HTTP request. We are not getting core dumps (even when the process dies). You also might want to confirm that your kernel is set up to do core dumps, that the process limits on the actual racket process would permit core dumps, and that whatever directoryfile the kernel config would say to put the core dump would be writable. All these are about arranging to capture diagnostic info, should an intermittent failure occur again. In addition to that, you might want to audit the code, looking for potential deadlocks. If you're using the FFI or C extensions, you have to assess how much you trust the code and whether you're calling it in a safe way, since auditing C code will be harder than auditing Racket code. Oh, and Matthew discovered a conceivable issue with address space randomization, and I don't know whether he's 100% ruled it out as a problem. You might want to disable that feature in Linux, just in case (although there are reasons why they added that feature, but I think the feature is less relevant if the only server code you're running on the machine is in Racket). -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New runtime charting for DrDr
In the old version you could click on a point in the graph to go to that revision. Can you bring that back, please? Robby On Tue, Sep 6, 2011 at 5:24 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: DrDr now has colorful, up-to-date, interactive charts for runtime on every file. For example, check out: http://drdr.racket-lang.org/23468/collects/tests/racket/benchmarks/common/ray.rkt The quick explanation: the solid yellow line shows the overall runtime of the file. The circles show the timing of uses of `time' inside the file. You can select any region of the chart to zoom into it. The reset button goes back to the initial state. You can turn the legend on and off with the show/hide legend button. Mousing over an individual point will tell you the exact timing at a particular push #. If the internal timing is much much shorter-duration than the overall runtime, it's shown on a different scale on the right y-axis. This is all built on the Flot [1] JavaScript charting library. Using this, it's possible to see trends in performance. For example, I want your feedback about this. Is it readable? Should I add the gc/system time for uses of `time'? Should I switch from points to lines? Is there anything else you'd like? [1] http://code.google.com/p/flot/ -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Suggestions for monitoring unresponsive web server connection?
On Sep 6, 2011, at 20:13, Kathi Fisler kfis...@gmail.com wrote: We are not getting core dumps (even when the process dies). It might be worth checking if any conditions hold under which core dumps are not written: http://linux.die.net/man/5/core Geoff Knauth, Capt, CAP, PA065/CC http://knauth.org/gsk | http://williamsportcap.org _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] syntax property duplication
On Tue, Sep 6, 2011 at 8:05 PM, John Clements cleme...@brinckerhoff.org wrote: On Aug 18, 2011, at 5:32 AM, Sam Tobin-Hochstadt wrote: Yes, I understand why this happens. As I see it, there are a few possibilities: 1. The expander should check for duplicates, in some fashion. 2. This idiom is problematic, in the case where `stx' is both the input and used for the syntax properties of the output. 3. Macros may freely duplicate syntax properties. All of these have drawbacks, but (3), which you are suggesting, means either that syntax properties can only be used to specify idempotent information or that the non-idempotent ones need to have some *explicit* means by which equal elements can be distinguished, which must be part of the API of that syntax property. If we think this is how syntax properties ought to work, then we should add something to the documentation making this clear, and we should recognize that it's a limitation. Would syntax-property guards solve this problem? I don't really see how. What are you thinking of? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
