Re: [racket-users] Ubuntu PPA also updated to v8.2
So I tried installing racket 8.2 from the experimental repos (downloaded it) and the dependencies (newer version of libc6) will break some things. So install at your own risk. I'll stick with 7.2 for now. Jul 30, 2021 7:31:55 PM David Bremner : > Joseph Turco writes: > >> Now we just need the Debian ppas to update to 8.2 for x86 and arm. I'm >> more inclined for arm as building racket on a 64bit distro on a pi 400 >> hangs the OS. > > I don't know what you refer to when you say "Debian ppas", but 8.2 is > available in Debian experimental for amd64, arm64, armhf, i386, > mips64el, mipsel, ppc64el, and s390x > > d -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/62d076ca-e5c0-4283-9285-1abf6d42cc69%40gmail.com.
Re: [racket-users] Ubuntu PPA also updated to v8.2
Sorry I have Ubuntu in my head. I didn't find the experimental packages. I'll check again. Many thanks. Jul 30, 2021 7:31:55 PM David Bremner : > Joseph Turco writes: > >> Now we just need the Debian ppas to update to 8.2 for x86 and arm. I'm >> more inclined for arm as building racket on a 64bit distro on a pi 400 >> hangs the OS. > > I don't know what you refer to when you say "Debian ppas", but 8.2 is > available in Debian experimental for amd64, arm64, armhf, i386, > mips64el, mipsel, ppc64el, and s390x > > d -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/3576ac17-4c9a-4219-8003-d063f4909791%40gmail.com.
Re: [racket-users] Ubuntu PPA also updated to v8.2
Joseph Turco writes: > Now we just need the Debian ppas to update to 8.2 for x86 and arm. I'm > more inclined for arm as building racket on a 64bit distro on a pi 400 > hangs the OS. I don't know what you refer to when you say "Debian ppas", but 8.2 is available in Debian experimental for amd64, arm64, armhf, i386, mips64el, mipsel, ppc64el, and s390x d -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87im0r4bvb.fsf%40tethera.net.
Re: [racket-users] Ubuntu PPA also updated to v8.2
Now we just need the Debian ppas to update to 8.2 for x86 and arm. I'm more inclined for arm as building racket on a 64bit distro on a pi 400 hangs the OS. Jul 30, 2021 1:53:07 AM Asumu Takikawa : > On 2021-07-18 18:55:35 +, 'John Clements' via Racket Users wrote: >> Racket version 8.2 is now available from > > The Ubuntu PPA is also now updated to v8.2 on all supported releases (groovy > no > longer supported): > > https://launchpad.net/~plt/+archive/ubuntu/racket > > As usual please report bugs here: > > https://github.com/takikawa/racket-ppa > > Cheers, > Asumu > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/20210730055304.ejfhyn2zi3bozu26%40pazu. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/596d3684-95cc-4447-bd36-72a764cb4e57%40gmail.com.
Re: [racket-users] Re: Re-entrant parameterize modification isolation when using shift/reset
Thanks, I think that makes sense. Is the `parameter * thread * parameterization -> box` part implemented as something like a global weak-hash, or is it built directly into the stack representation? Continuing the other conversation for a moment with a code reference to explain to my future self, or anyone else curious, what I meant by "algebraic state effects". Here's a simple implementation with a couple examples: ``` #lang racket/base (require racket/control) (struct state-parameter (tag) #:property prop:procedure (case-lambda ((self) (shift-at (state-parameter-tag self) k (lambda (x) ((k x) x ((self v) (shift-at (state-parameter-tag self) k (lambda (_) ((k (void)) v)) ;; Analogous to make-parameter, but without a default value (define (make-state-parameter) (state-parameter (make-continuation-prompt-tag))) (define-syntax state-parameterize* (syntax-rules () ((_ () body ...) (let () body ...)) ((_ ((e.p e)) body ...) (let ((p e.p) (x e)) ((reset-at (state-parameter-tag p) (let ((result (begin body ...))) (lambda (_) result))) x))) ((_ (b bs ...) body ...) (state-parameterize* (b) (state-parameterize* (bs ...) body ...) (define-syntax state-parameterize-etc (syntax-rules () ((_ final () body ...) (state-parameterize* final body ...)) ((_ (final ...) ((e.p e) bs ...) body ...) (let ((p e.p) (x e)) (state-parameterize-etc (final ... (p x)) (bs ...) body ...) ;; Analogous to parameterize (define-syntax-rule (state-parameterize etc ...) (state-parameterize-etc () etc ...)) ;; The same kind of single state example (define P (make-state-parameter)) (define (show) (displayln (P))) (define (inc) (P (+ 1 (P (define K (reset (state-parameterize ((P 0)) (show) (inc) (shift k k) (show) (inc) (P (displayln "with algebraic state:") (K) ; 2 (K) ; 2 (K) ; 2 ;; An example with multiple states (define R (make-state-parameter)) (define Q (make-state-parameter)) (define (show2) (displayln `(R: ,(R) Q: ,(Q (define (inc2) (R (+ 1 (R))) (Q (- (Q) 1))) (define J (reset (state-parameterize ((R 0) (Q 0)) (show2) (inc2) (shift k k) (show2) (inc2) (list (R) (Q) (displayln "with multiple algebraic states:") (J) ; 2 -2 (J) ; 2 -2 (J) ; 2 -2 ``` On Friday, July 30, 2021 at 11:04:09 AM UTC-4 Matthew Flatt wrote: > At Sun, 25 Jul 2021 10:35:00 -0700 (PDT), Greg Rosenblatt wrote: > > I was surprised that subsequent re-entries can observe modifications > from > > the earlier ones, since my mental model of dynamic parameters was that > > their values were retrieved from a fresh dynamic calling context, whose > > frames are copied each time the delimited continuation is invoked. > > [...] > > I'm also interested in the reasons behind the current design. Is there a > > downside to storing parameter bindings directly on the stack, rather > than > > in a thread cell pointed to by the stack? > > I think I see what you mean here, but I also think that idea would run > into trouble. A (delimited) continuation is invoked every time you > return a value to a continuation, whether or not that continuation was > captured by `call/cc`. Internally, in fact, the current continuation > frequently gets reified and invoked through returns. I think it would > create a bad interaction among features if a distinction were made > between explicit (applying a captured continuation) and implicit > (returning a value) continuation invocations. > > > I'd like to be able to resume that continuation in the same context > > multiple times without observing modifications caused by other > > resumptions. [...] But it looks like dynamic parameters actually rely > > on a shared mutable cell, in this case a thread cell. > > Yes, parameters are based on a mapping > > parameter * thread * paramterizization -> box > > When you set or look up a parameter value, the thread part comes from > `current-thread`, and the parameterization part comes from a > continuation mark. So, that's why capture and restore within a thread > sees the same box, but capture and restore of a continuation in a > different thread gets a different box. > > I think you want to introduce a notion of "resume" that replaces the > thread part of the mapping, plus a replacement notion of > parameterization. That is, each time you resume, the applied > continuation should extend one that maps an internal mark to the > current resume. A replacement for `parameterize` would also install a > mark (with a different key) to identify a "parameterization", while > also mapping the parameter * parameterization * resume to a fresh box. > When you look up a parameter value or mutate a parameter, the current > mark for the resume and the current mark for the parameterization would > let you fin
Re: [racket-users] Re: Re-entrant parameterize modification isolation when using shift/reset
At Sun, 25 Jul 2021 10:35:00 -0700 (PDT), Greg Rosenblatt wrote: > I was surprised that subsequent re-entries can observe modifications from > the earlier ones, since my mental model of dynamic parameters was that > their values were retrieved from a fresh dynamic calling context, whose > frames are copied each time the delimited continuation is invoked. > [...] > I'm also interested in the reasons behind the current design. Is there a > downside to storing parameter bindings directly on the stack, rather than > in a thread cell pointed to by the stack? I think I see what you mean here, but I also think that idea would run into trouble. A (delimited) continuation is invoked every time you return a value to a continuation, whether or not that continuation was captured by `call/cc`. Internally, in fact, the current continuation frequently gets reified and invoked through returns. I think it would create a bad interaction among features if a distinction were made between explicit (applying a captured continuation) and implicit (returning a value) continuation invocations. > I'd like to be able to resume that continuation in the same context > multiple times without observing modifications caused by other > resumptions. [...] But it looks like dynamic parameters actually rely > on a shared mutable cell, in this case a thread cell. Yes, parameters are based on a mapping parameter * thread * paramterizization -> box When you set or look up a parameter value, the thread part comes from `current-thread`, and the parameterization part comes from a continuation mark. So, that's why capture and restore within a thread sees the same box, but capture and restore of a continuation in a different thread gets a different box. I think you want to introduce a notion of "resume" that replaces the thread part of the mapping, plus a replacement notion of parameterization. That is, each time you resume, the applied continuation should extend one that maps an internal mark to the current resume. A replacement for `parameterize` would also install a mark (with a different key) to identify a "parameterization", while also mapping the parameter * parameterization * resume to a fresh box. When you look up a parameter value or mutate a parameter, the current mark for the resume and the current mark for the parameterization would let you find the right box. It may be best to have a "parameterization" specific to each "parameter" (i.e., a separate mark for each parameter), instead of aggregating them in the way `parameterize` does. In the case of threads and parameters, aggregation makes it easier to create a new thread that inherits the parameterization of the creating thread. But if you don't need that, aggregation also works less well with delimited continuation capture, because `parameterize` captures all parameter values and not just the ones that are set in the `parameterize` form. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20210730090404.311%40sirmail.smtps.cs.utah.edu.
