On Aug 25, 2012, at 4:28 PM, Philip Guo wrote:
> [Cc'ed Frank (Lingfeng), who is the student doing the actual implementation.
> Frank, please chime in with thoughts too …]
Okay, I just pushed a version of Racket (f107c4d2658) that includes an
"external interface" for the stepper, in
plt/coll
I've moved the tooltips so they are in a less annoying place now. I
think it can still be a bit better, but at least now it isn't as
annoying (I think).
Robby
On Mon, Aug 27, 2012 at 7:01 PM, Robby Findler
wrote:
> Thanks.
>
> I've been using it for a little while now and I actually really hate
Thanks.
I've been using it for a little while now and I actually really hate it. :)
I need to move it so it doesn't overlap with the (at least not as often).
Robby
On Monday, August 27, 2012, John Clements wrote:
> I see that you've added a tooltip on check-syntax hover that shows how
> many u
I see that you've added a tooltip on check-syntax hover that shows how many
uses a variable has. Thanks!
John
smime.p7s
Description: S/MIME cryptographic signature
_
Racket Developers list:
http://lists.racket-lang.org/dev
Since I've made the Typed Racket tests run in parallel, there have
been intermittent errors in DrDr, like this:
http://drdr.racket-lang.org/25278/collects/tests/typed-racket/run.rkt
I'm not sure exactly what could be causing this -- I don't think
promises should ever fail to `force`. Might the
Oh, okay. And so if you have a function that accepts a struct, does some
work with it, and then returns a new version of it (and you wanted to
optimize the body of the function), then you could get away with doing
something like 'struct-copy' to make the final version that gets returned.
Robby
On
FWIW, the Scala folks have done something along these lines, Value Classes,
originally aka Inline Classes.
https://docs.google.com/document/d/10TQKgMiJTbVtkdRG53wsLYwWM2MkhtmdV25-NZvLLMA/edit?hl=en_US&pli=1
On Mon, Aug 27, 2012 at 12:58 PM, Neil Toronto wrote:
> On 08/27/2012 09:11 AM, Vincent
On 08/27/2012 09:11 AM, Vincent St-Amour wrote:
TR's complex number optimizations eliminate repeated boxing and unboxing
in chains of operations that each consume and produce complex numbers.
Similar optimizations for structs would eliminate structs for
intermediate results in chains of operatio
I don't think it would be necessary.
For the optimization to trigger, the only thing a step in the chain can
do with its argument is use its components. Anything else (e.g. checking
whether it's a substruct) would require the argument to be boxed, and
would prevent the optimization from happening.
Would you need a "and is not a substruct?" predicate to make such things work?
Robby
On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour wrote:
> TR's complex number optimizations eliminate repeated boxing and unboxing
> in chains of operations that each consume and produce complex numbers.
>
> S
TR's complex number optimizations eliminate repeated boxing and unboxing
in chains of operations that each consume and produce complex numbers.
Similar optimizations for structs would eliminate structs for
intermediate results in chains of operations that each consume and
produce that same (single
11 matches
Mail list logo
