Super! Thank you.
On Thu, Jan 29, 2015 at 7:51 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Wed, 28 Jan 2015 16:21:51 -0700, Byron Davies wrote:
Your code, commented:
(define orig-i (current-inspector)) ; saves the original inspector
(define sub-i (make-inspector orig-i)) ;make a
At Wed, 28 Jan 2015 16:21:51 -0700, Byron Davies wrote:
Your code, commented:
(define orig-i (current-inspector)) ; saves the original inspector
(define sub-i (make-inspector orig-i)) ;make a new inspector whose parent
is the original inspector
(current-inspector sub-i) ;makes the new
At Thu, 29 Jan 2015 15:34:37 -0300, Gustavo Massaccesi wrote:
If there are some easy technical details and advice, you can write a
nice blog post about this.
Good idea. I have some advice on finalization (don't do it), and I
could write about how Racket tries to help when you can't follow that
Hi Jan,
Interesting problem!
I think I see what you mean: There's no way to combine the completion
of an event plus saving its value as an atomic operation, except by
putting the synchronization in its own thread. But if you put the
synchronization in its own thread, then there's no way to
Is the issue that the E_b from Jan's original message might produce
multiple values and you are supposed to take the value that's
available only after something syncs on the E_m?
That is, I thought you could just create a separate thread that sync's
on E_b and then whenever you get a value from
I recently ran into a problem in which opaque types (types imported from
untyped code) cannot by parameterized by Typed Racket. I initially encountered
this problem in my attempt to port 2htdp/image to TR
https://github.com/lexi-lambda/racket-2htdp-typed/issues/1.
After some further
I think you’re reading too far into what I’m proposing, though I admit I
probably didn’t give enough context. I’ve been talking with Sam about this
issue on IRC, so he knows what I’m talking about, but I’ll try and clarify here.
This entire thing is just a fix for the problem described in
On Jan 29, 2015, at 11:34 PM, Alexis King lexi.lam...@gmail.com wrote:
But the problem is that if it’s an opaque type then it can’t unwrap it once
the value is returned from make-posn.
Yes, that’s precisely the problem. Your point about implementing everything
as single-valued structs on
Um, for this:
(module typed typed/racket/base
(provide (struct-out Foo))
(struct [A] Foo ([x : A] [y : A]) #:transparent))
(Foo a 'b)
Should be fine because Foo could be instantiated at the type (U String Symbol).
On Jan 29, 2015, at 9:25 PM, Alexis King lexi.lam...@gmail.com wrote:
I
Matthew Flatt wrote:
We've so far cut the peak memory use of a build by about 1/4 compared
to a v6.1.1 build.
Yes, peak memory use for me has now dropped from about 900MB to just
below 700MB. Veeery nice :-)
Philippe
_
Racket Developers list:
But the problem is that if it’s an opaque type then it can’t unwrap it once
the value is returned from make-posn.
Yes, that’s precisely the problem. Your point about implementing everything as
single-valued structs on the typed side is an interesting one, though I don’t
think it ultimately
This has bothered me too, but I've realized that I was on the wrong track.
The string a and symbol 'b are not different types. A struct (Foo a
'b), or (list a 'b), is a homogeneous data structure of type (U String
Symbol) just like Alexander said. This really upsets me -- I like the
Hindley
Furthermore, even if the wrappers were shared between functions, untyped code
would recieved wrapped values, which would render them quite useless.
If it’s not an opaque type, but something like a list, then this works, and the
untyped code receiving wrapped values isn’t a problem here:
#lang
Or Any for that matter. I know. The fact that it could be literally anything
was sort of the point.
On Jan 29, 2015, at 19:10, Alexander D. Knauth alexan...@knauth.org wrote:
Um, for this:
(module
It isn’t wrapped in an opaque structure. That wasn’t a part of my proposal, and
while I didn’t think of it until you brought it up, I still think it’s
unnecessary and doesn’t add any convenience.
Perhaps I’m not understanding you properly, but your “one-length string” idea
sounds like it has
On Thu, 2015-01-29 at 16:41 -0600, Robby Findler wrote:
That is, I thought you could just create a separate thread that sync's
on E_b and then whenever you get a value from it, then the E_m would
just continue to produce that all the time. But I think you're saying
that wouldn't work?
The
16 matches
Mail list logo
