Re: [racket-users] whither `splicing-parameterize`? or am I doing it wrong?

> On Jan 25, 2018, at 16:45, Robby Findler > wrote: > > Isn't the last form already required to not be a definition? In that example, yes, but not always, and splicing-parameterize can’t be sure one way or the other. In this example, containing exclusively

Re: [racket-users] whither `splicing-parameterize`? or am I doing it wrong?

Isn't the last form already required to not be a definition? Robby On Thu, Jan 25, 2018 at 5:59 PM Alexis King wrote: > > On Jan 24, 2018, at 12:57 AM, Ryan Culpepper > > wrote: > > > > It might make sense to `(set! new-parameterization #f)` at the

Re: [racket-users] whither `splicing-parameterize`? or am I doing it wrong?

> On Jan 24, 2018, at 12:57 AM, Ryan Culpepper > wrote: > > It might make sense to `(set! new-parameterization #f)` at the end so > that the parameterization (and the values it holds) can be GC'd sooner > when splicing-parameterize is used at top level or module level. The

Re: [racket-users] Strange window behavior in OSX Yosemite DrRacket

Thanks for the suggestions, guys. Glad to hear it’s a known-and-fixed bug. We’ll poke at it when we’re back in the lab tomorrow, and if we can’t resolve it I’ll follow up with another query here. Thanks again, jmj > On Jan 25, 2018, at 11:42, Robby Findler wrote:

Re: [racket-users] Understanding prop:impersonator-of

This is because `prop:impersonator-of` only applies to two instances that inherit the property from the same structure type. (As the docs put it, "The result value must have the same prop:impersonator-of and prop:equal+hash property values as the original structure, if any, and the property values

[racket-users] Understanding prop:impersonator-of

I'm trying to understand the use of the prop:impersonator-of struct property, but the following program doesn't work the way I would have expected: #lang racket (struct our-impersonate-proc (f orig) #:property prop:impersonator-of (lambda (x) (displayln 'hi) (our-impersonate-proc-orig x))

Re: [racket-users] A very simple #lang

The explanation of the 5-argument read and 6-argument read-syntax is here, starting from the 3rd paragraph of this subsection: https://docs.racket-lang.org/reference/reader.html#%28part._parse-reader%29 The 5 (or 6) arguments version read accepts extra source location information. However, this

Re: [racket-users] Strange window behavior in OSX Yosemite DrRacket

> On Jan 25, 2018, at 12:17 PM, Philip McGrath wrote: > > I took the steps you described and I no longer get the doubled program > contour, but I do get results like the screenshot of my experiment with > text:inline-overview-mixin I sent > earlier (maybe that's

Re: [racket-users] A very simple #lang

Thanks Philip, of course I should have checked for something like this directly. Deren On Thu, Jan 25, 2018 at 3:51 PM, Philip McGrath wrote: > You may just want to use #lang exact-decimal racket (see: > http://docs.racket-lang.org/exact-decimal-lang/index.html). > >

Re: [racket-users] A very simple #lang

You may just want to use #lang exact-decimal racket (see: http://docs.racket-lang.org/exact-decimal-lang/index.html). I have encountered a similar problem with six arguments to read-syntax before, and I remember there being a good reason that was explained in some obscure corner of the

Re: [racket-users] racket/gui and the Cocoa NSRunLoop

Thanks for the response. Since writing this, I've tried to better understand this C code, and my understanding of the problems here might have not been correct. They still probably aren't correct, but I'll try to better articulate the challenge. I tried all of the techniques you suggested, none

Re: [racket-users] Strange window behavior in OSX Yosemite DrRacket

On Thu, Jan 25, 2018 at 2:17 PM, Philip McGrath wrote: > I took the steps you described and I no longer get the doubled program > contour, but I do get results like the screenshot of my experiment with > text:inline-overview-mixin > I sent > earlier (maybe that's what

[racket-users] A very simple #lang

Hi everyone, I am desperately in need of a #lang exact so that decimals are read as exact values. I thought this would be extremely simple: ..\exact\lang\reader.rkt (module reader racket/base (provide (rename-out (exact-read read) (exact-read-syntax read-syntax)))

Re: [racket-users] macro guard on variable type

You may also wish to use format-id from racket/syntax (require (for-syntax racket/syntax)) (define-syntax (lt/log stx) (syntax-case stx (quote) [(_ (quote component) (quote level) msg v ...) (with-syntax ([name (format-id stx "log-sap-~a" (syntax->datum #'level))]) #'(name

Re: [racket-users] macro guard on variable type

I think you need to * remove the `quote`s around the two `(syntax->datum #'level)`s * add `string->symbol` around the two `(format )`s At Thu, 25 Jan 2018 17:26:50 +0100, "'Paulo Matos' via Racket Users" wrote: > Hi, > > I am trying to wrap some logging procedures into macros. I have a

Re: [racket-users] Strange window behavior in OSX Yosemite DrRacket

> On Jan 25, 2018, at 8:48 AM, Jordan Johnson wrote: > > Hi all, > > One of my students is observing some strange behavior involving the Program > Contour pane of DrRacket. He’s using v6.11 on OS X Yosemite 10.10.5. > > This is the top-right corner of his DrR window,

[racket-users] Strange window behavior in OSX Yosemite DrRacket

Hi all, One of my students is observing some strange behavior involving the Program Contour pane of DrRacket. He’s using v6.11 on OS X Yosemite 10.10.5. This is the top-right corner of his DrR window, with Program Contour open: Upon pressing Cmd+U to hide it, this is what happens:

[racket-users] macro guard on variable type

Hi, I am trying to wrap some logging procedures into macros. I have a logger for my application which I define as: (define-logger sap) Then I want to define a macro that possibly receives an extra argument which is the part of the application that's issuing the logging message. So, if logging

Re: [racket-users] Using ffi/unsafe/alloc

Hi Dmitry and Matthew, Thanks for your suggestions, which, although quite different, turned out to be both useful for me. As you can imagine, my real C API is a lot more complicated. There are dependencies between allocated memory blocks, i.e. freeing one can invalidate another one. More