On Tue, Sep 6, 2011 at 8:05 PM, John Clements 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 prob
On Sep 6, 2011, at 20:13, Kathi Fisler 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:
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 wrote:
> DrDr now has colorful, up-to-date, interactive charts for runtime on
> every file. For example, check out:
> htt
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 log
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 some
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
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 tim
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/l
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,
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
On Tue, Sep 6, 2011 at 12:46 PM, Shriram Krishnamurthi
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 leav
> 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,
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 th
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 spe
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
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 be
OK, no problem.
Thanks,
--- nadeem
On Tue, Sep 6, 2011 at 10:30 AM, Robby Findler
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
>
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 g
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.
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 wrote:
> [This is intentionally stream-of-consciousness...]
>
> The plan
[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.
T
20 matches
Mail list logo
