Re: [racket-users] Re: Working with JSON using Typed Racket

[Phil Nguyen]

For parsing JSON in Typed Racket, you can check out this library I made: 
https://github.com/philnguyen/json-type-provider .

You can declare structs and field names that match the underlying data, and 
get back a well-typed parser. Don't let the name "type provider" fool you 
though, it's nothing smart like F#'s type provider (there's no inference 
from examples yet), although it's intended to eventually be so.

For your example, you could equivalently do something like below. If you 
omit the default values, then instead of silently failing with `#f`, it'll 
give you error messages pinpointing the location in the JSON stream.

#lang typed/racket/base

(require racket/match
 json-comb)

(define-json-types
 [DTHidden ([Type : String #:default [#f : #f]]
[Data : CDUsers #:default [#f : #f]])]
 [CDUsers ([Type : String #:default [#f : #f]]
   [Data : (Listof String) #:default [#f : #f]])])

(: read-cdusers-data : Input-Port → (U #f (Listof String)))
(define (read-cdusers-data in)
 (match (read-DTHidden in)
   [(DTHidden "DTHidden" (CDUsers "CDUsers" ans)) ans]
   [_ #f]))

(define example
 "{
 \"Type\": \"DTHidden\",
 \"Data\": { \"Type\": \"CDUsers\",
 \"Data\": [\"datum1\", \"datum2\"] }
 }}")

(read-cdusers-data (open-input-string example))


 

On Tuesday, March 31, 2020 at 12:23:07 PM UTC-7, e...@disroot.org wrote:
>
> Thanks Wesley and Matthias! Very helpful advice.
>
> March 31, 2020 2:40 AM, "Wesley Bitomski"  > wrote:
>
> Hello Ed,
> I generally get some mileage out of using custom predicates (those that 
> are made with define-predicate) and pattern matching when tearing into 
> JSON structures in Typed Racket. Occurrence typing seems to work with if, 
> cond and assert, along with match's predicate matcher (? form).
> So, something like this I think could less tedious to produce, and does 
> exactly what your example does:
> (: jsexpr->cd-users-data (JSExpr -> (Option (Listof String
> (define (jsexpr->cd-users-data js)
> (define-predicate names-list? (Listof String))
> (match js
> [(hash-table ['Type "DTHidden"]
> ['Data (hash-table ['Type "CDUsers"]
> ['Data (? names-list? users)])])
> users]
> [_ #false]))
>
> I hope this is what you were looking for.
>
> On Sunday, March 29, 2020 at 8:39:56 AM UTC-4, e...@disroot.org wrote:
>
> Hi everyone,
>
> Recently I've been experimenting with Typed Racket and trying to gradually 
> type my code base.
> One of the functions that I need to write is to extract a list of strings 
> from a JSON object, if it has following form:
>
> {
> "Type": "DTHidden",
> "Data": { "Type": "CDUsers",
> "Data": ["datum1", "datum2"] }
> }
>
> The way I used to structure it in Racket is to have a function 
> `is-cdusers?` with the contract `jsexpr? -> boolean?`, which would check 
> that the JSON object has the right shape; and a separate function 
> `get-cdusers-data` with the contract `is-cdusers? -> listof string?`.
>
> However, after playing a bit with Typed Racket I decided that it was 
> necessary, according to my understanding of occurrence typing, to have a 
> single function `get-cdusers-data` with the type `JSExpr -> (U False 
> (Listof String))`.
> In order to get it to work I ended up writing a long chain of conditionals:
>
>
> (: get-cdusers-data (-> JSExpr (U False (Listof Any
> (define (get-cdusers-data js)
> (if (and (hash? js)
> (equal? DTHidden (hash-ref js 'Type #f)))
> (let ([js (hash-ref-def js 'Data [ann #hasheq() JSExpr])])
> (if (and (hash? js)
> (equal? CdUsers (hash-ref js 'Type #f)))
> (let ([data (hash-ref js 'Data)])
> (if (hash? data)
> (let ([x (hash-ref js 'Data #f)])
> (and (list? x) x))
> #f))
> #f))
> #f))
>
> Needless to say, this is a bit impractical and error-prone to write.
> Does anyone know if there is a better approach to this?
>
> From my experience with typed languages I would get that the most 
> principle approach is to have an algebraic data type that represents all 
> the underlying data structures, something like
>
> type reply = ... | CDUsers of string list | ...
>
> and then have a single function to converts a JSExpr into that data type.
>
> I was hoping to avoid that, because I do enjoy working with the JSExpr 
> type directly in Racket.
>
> Does anyone have advice/experience with problems like this?
>
> Best wishes,
> -Ed
>
> --
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/f85a4a4d-0d0a-47e3-909b-2b378def368a%40googlegroups.com
>  
> 
> .
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving 

[racket-users] JSON type provider (ish) for Typed Racket

[Phil Nguyen]

Github repo: https://github.com/philnguyen/json-type-provider

I read this PLDI 2016 paper 
 about Type Provider 
for F# and attempted to implement it as a Racket macro. Then I realized it 
worked great in F# mostly because of dot notation and IDE auto-completion. 
I ended up implementing something more manual and primitive, but hopefully 
is still useful.

Background: Type Provider statically generates types that describe data 
from external sources (e.g. JSON, XML, CSV, etc.) and parsers that produce 
values of those types, eliminating error-handling boilerplate when parsing 
and coercing the raw inputs. In F#, programmers can provide example inputs 
(such as paths to local files or external links), and the compiler infers 
the shape of the data for them. Thanks to OOP's dot notation and IDE 
auto-completion, programmers can explore the data's shape interactively as 
they program.

Unfortunately, auto-completion doesn't work so well in Racket, so the 
result of example-based type+parser generation will likely be unpredictable 
to humans merely seeing links in the source code.

As a compromise (and maybe a building block for future work), I made a 
library that generates JSON parsers from high-level Typed Racket 
declaration. It's manual, but there are still a few nice things:
* The available types and properties are obvious from the source code
* It eliminates error-handling boilerplate
* By default, it stores JSON objects compactly as structs, only holding the 
fields the programmer cares about
* It allows converting JSON objects to arbitrary types on the fly in 1 pass.
* If it turns out there's a way to make example-based code generation and 
auto-completion work well in Racket's context, hopefully it'll just be 
another step on top of this library, where the macro is generated from 
examples.

-- 
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/aa01bf12-8a56-4ccd-a988-3b0fd800cce9%40googlegroups.com.

[racket-users] Intriguing performance difference between Windows and Linux on `(factorial 100000)`

[Phil Nguyen]

With Racket 7.2, the following program takes >13 seconds to run on Windows, 
and <7 seconds on Linux either on Virtualbox on the same machine, or native 
Linux on another machine with slightly lower-powered processor:

#lang racket/base
(define (fact n)
  (if (zero? n) 1 (* n (fact (- n 1)
(time (void (fact 10)))

; Windows native, i7-7660U
;   cpu time: 13610 real time: 13633 gc time: 4459
; Linux on Virtualbox, i7-7660U
;   cpu time: 6691 real time: 6706 gc time: 1298
; Linux native, i7-8500Y:
;   cpu time: 6894 real time: 6882 gc time: 1129



While the difference is unlikely to matter in practice, given `fact 10` is 
a very large number, I'm curious what accounts for this difference? Is it some 
big-integer library that Racket relies on?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Can I declare opaque type constructor in `require/typed`?

[Phil Nguyen]

I'm attempting to add type bindings for mutable sets. I can't reuse the 
existing `Setof` type constructor because it is covariant. Is it possible 
to declare an opaque new type constructor `Mutable-Setof` in the 
`require/typed` clause?

Thanks.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Surprising slow-down of near tail-call: Potential missed optimization?

[Phil Nguyen]

Actually nvm. Whoever wrote such macro could have just used `begin0` 
instead.

On Monday, October 1, 2018 at 2:34:23 PM UTC-4, Phil Nguyen wrote:
>
> (Racket 7.0) This program runs in no time:
>
> (define (sum n acc)
>   (if (> n 0)
>   (sum (- n 1) (+ acc n))
>   acc))
>
> (collect-garbage) (collect-garbage) (collect-garbage)
> (time (sum 1000 0))
> ; cpu time: 47 real time: 57 gc time: 0
> ; 500500
>
> This slightly modified program runs significantly slower:
>
> (define (sum n acc)
>   (if (> n 0)
>   (let ([ans (sum (- n 1) (+ acc n))])
> ans)
>   acc))
>
> (collect-garbage) (collect-garbage) (collect-garbage)
> (time (sum 1000 0))
> ; cpu time: 1719 real time: 1872 gc time: 1064
> ; 500500
>
> While the call to `sum` in the second program is not in tail position, I 
> wonder if this kind of code happens often enough from macro expansion to 
> benefit from an optimization.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Surprising slow-down of near tail-call: Potential missed optimization?

[Phil Nguyen]

(Racket 7.0) This program runs in no time:

(define (sum n acc)
  (if (> n 0)
  (sum (- n 1) (+ acc n))
  acc))

(collect-garbage) (collect-garbage) (collect-garbage)
(time (sum 1000 0))
; cpu time: 47 real time: 57 gc time: 0
; 500500

This slightly modified program runs significantly slower:

(define (sum n acc)
  (if (> n 0)
  (let ([ans (sum (- n 1) (+ acc n))])
ans)
  acc))

(collect-garbage) (collect-garbage) (collect-garbage)
(time (sum 1000 0))
; cpu time: 1719 real time: 1872 gc time: 1064
; 500500

While the call to `sum` in the second program is not in tail position, I 
wonder if this kind of code happens often enough from macro expansion to 
benefit from an optimization.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] What are most type cases of `=` for?

[Phil Nguyen]

Oh I see!! Propositions were just omitted when pretty printed on my side. 
Thanks Sam!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] What are most type cases of `=` for?

[Phil Nguyen]

The full type of `=` in Typed Racket has lots of cases, whose ranges are 
all `Boolean`. Are all cases before the default one `Number Number Number * 
-> Boolean` useful in any way, or they were just part of some automatic 
generation? It's not obvious to me that the preceding cases are useful, 
because they're all more specific in the domain.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] How to get around unintuitive unwrapping of a seal when passing parametric argument to contract's range-maker?

[Phil Nguyen]

In this example, is it ok for `f`'s contract to be able to inspect argument 
`x`? It's originally sealed with `α`, and the contract takes advantage of 
the unsealing in `g`'s domain to inspect it. Sure the contract is a 
separate party than `f`, but is this ok?

(define/contract f
  (parametric->/c
   (α)
   (α
((and/c α (λ (x) (printf "inspect x: ~a~n" x))) . -> . any/c) . -> . 
any/c))
  (λ (x g) (g x)))

(f 42 add1)

On Thursday, January 18, 2018 at 8:53:03 AM UTC-5, Robby Findler wrote:
>
> On Thu, Jan 18, 2018 at 7:43 AM, Phil Nguyen <philngu...@gmail.com 
> > wrote: 
> > It looks like a more general issue we have is that arguments are 
> sometimes 
> > unexpectedly unsealed and prone to inspection by arbitrary code in 
> > contracts, like `->i`'s range or a second conjunct to `and/c`. 
>
> Well, they are supposed to be unwrapped when they pass "out". The ->i 
> thing is a more general question of "where is 'out', anyway?" and I 
> put to you that this isn't trivial (there are multiple papers on the 
> topic already). 
>
> Can you explain more what you mean about and/c, however? 
>
> Robby 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] How to get around unintuitive unwrapping of a seal when passing parametric argument to contract's range-maker?

[Phil Nguyen]

It looks like a more general issue we have is that arguments are sometimes 
unexpectedly unsealed and prone to inspection by arbitrary code in 
contracts, like `->i`'s range or a second conjunct to `and/c`.

On Wednesday, January 17, 2018 at 11:45:41 AM UTC-5, Philip McGrath wrote:
>
> Of course, it blames the right party only if the party implementing the 
> contract is the same as the party implementing `bad-h`. This example blames 
> `third-party` for what we really want to hold `(definition bad-h)` 
> responsible for:
> #lang racket
>
> (module third-party racket
>   (provide the-contract)
>   (define the-contract
> (parametric->/c
>  {α}
>  (->i ([x α]
>[P (-> α contract?)]
>[f {P} (->d ([x α])
>[_ (P x)])])
>   [_ {P x} (P x)]
> (require 'third-party)
>
> (define/contract bad-h
>   the-contract
>   (λ (x P f)
> (f 'not-α)))
>
> (bad-h 42 (λ _ string?) number->string)
>
> -Philip
>
> On Wed, Jan 17, 2018 at 9:08 AM, Philip McGrath <phi...@philipmcgrath.com 
> > wrote:
>
>> I noticed that this sort of works:
>> (define/contract h
>>   (parametric->/c
>>{α}
>>(->i ([x α]
>>  [P (-> α contract?)]
>>  [f {P} (->d ([x α])
>>  [_ (P x)])])
>> [_ {P x} (P x)]))
>>   (λ (x P f)
>> (f x)))
>>
>> (h 42 (λ _ string?) number->string)
>>
>> The "sort of" part is if you have a violation, e.g.
>> (define/contract bad-h
>>   (parametric->/c
>>{α}
>>(->i ([x α]
>>  [P (-> α contract?)]
>>  [f {P} (->d ([x α])
>>  [_ (P x)])])
>> [_ {P x} (P x)]))
>>   (λ (x P f)
>> (f 'not-α)))
>>
>> (bad-h 42 (λ _ string?) number->string)
>>
>> Here the violation is reported in terms of the call to `P` in the range 
>> of the `->d`, when in principle one would want it to be in terms of calling 
>> `f` with a bad argument. But it does blame the right party.
>>
>> -Philip
>>
>> On Wed, Jan 17, 2018 at 8:52 AM, Robby Findler <
>> ro...@eecs.northwestern.edu > wrote:
>>
>>> My guess is that something more subtle has to happen for the "indy"
>>> part of parameteric contracts (but that really is just a guess).
>>>
>>> Robby
>>>
>>>
>>> On Wed, Jan 17, 2018 at 8:49 AM, Phil Nguyen <philngu...@gmail.com 
>>> > wrote:
>>> > It doesn't seem like an implementation bug to me. I mean if we try to 
>>> follow
>>> > the usual rule of sealing/unsealing, it makes sense. I just can't 
>>> pinpoint
>>> > which part of the contracts I need to fix to be able to express the
>>> > enforcement.
>>> >
>>> > On Wednesday, January 17, 2018 at 9:31:25 AM UTC-5, Robby Findler 
>>> wrote:
>>> >>
>>> >> I am not sure, but my first guess would be that it is a bug in the
>>> >> contract system (due to a lack of understanding of what to do by me),
>>> >> not that it is impossible to do this with dynamic sealing.
>>> >>
>>> >> Robby
>>> >>
>>> >>
>>> >> On Tue, Jan 16, 2018 at 2:34 PM, Phil Nguyen <philngu...@gmail.com> 
>>> wrote:
>>> >> > The following function with its contract will crash because when
>>> >> > composing
>>> >> > the range (P x), the seal around x is already unwrapped:
>>> >> > (define/contract f
>>> >> >   (parametric->/c (α) (->i ([x α]
>>> >> > [P (α . -> . contract?)]
>>> >> > [f (P) (->i ([x α]) (_ (x) (P x)))])
>>> >> >(_ (P x) (P x
>>> >> >   (λ (x P f) (f x)))
>>> >> > (f 42 (λ _ string?) number->string)
>>> >> >
>>> >> > ; f: broke its own contract
>>> >> > ;   promised: α
>>> >> > ;   produced: 42
>>> >> > ;   in: the 1st argument of
>>> >> > ;   the P argument of
>>> >> > ;   (parametric->/c
>>> >> > ;(α)
>>> >> > ;(->i
>>> >> > ; ((x α)
>>> >> > ;  (P (-> α contract?))
>>> >> > ;  (

Re: [racket-users] How to get around unintuitive unwrapping of a seal when passing parametric argument to contract's range-maker?

[Phil Nguyen]

It doesn't seem like an implementation bug to me. I mean if we try to 
follow the usual rule of sealing/unsealing, it makes sense. I just can't 
pinpoint which part of the contracts I need to fix to be able to express 
the enforcement.

On Wednesday, January 17, 2018 at 9:31:25 AM UTC-5, Robby Findler wrote:
>
> I am not sure, but my first guess would be that it is a bug in the 
> contract system (due to a lack of understanding of what to do by me), 
> not that it is impossible to do this with dynamic sealing. 
>
> Robby 
>
>
> On Tue, Jan 16, 2018 at 2:34 PM, Phil Nguyen <philngu...@gmail.com 
> > wrote: 
> > The following function with its contract will crash because when 
> composing 
> > the range (P x), the seal around x is already unwrapped: 
> > (define/contract f 
> >   (parametric->/c (α) (->i ([x α] 
> > [P (α . -> . contract?)] 
> > [f (P) (->i ([x α]) (_ (x) (P x)))]) 
> >(_ (P x) (P x 
> >   (λ (x P f) (f x))) 
> > (f 42 (λ _ string?) number->string) 
> > 
> > ; f: broke its own contract 
> > ;   promised: α 
> > ;   produced: 42 
> > ;   in: the 1st argument of 
> > ;   the P argument of 
> > ;   (parametric->/c 
> > ;(α) 
> > ;(->i 
> > ; ((x α) 
> > ;  (P (-> α contract?)) 
> > ;  (f (P) (->i ... ...))) 
> > ; (_ (P x) (P x 
> > 
> > Is it possible to express this kind of enforcement using parametric 
> > contracts? (For example, a contract that enforces something similar to 
> the 
> > type of a generated induction principle for a datatype in a proof 
> assistant) 
> > 
> > It's possible to construct a term of a corresponding type in a 
> dependently 
> > typed language: 
> > example: ∀ {α : Type} 
> >(x: α) 
> >(P: α → Type) 
> >(f: (∀ (x: α), P x)), 
> >(P x) := 
> > assume _ x _ f, f x 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] How to get around unintuitive unwrapping of a seal when passing parametric argument to contract's range-maker?

[Phil Nguyen]

The following function with its contract will crash because when composing 
the range (P x), the seal around x is already unwrapped:
(define/contract f
  (parametric->/c (α) (->i ([x α]
[P (α . -> . contract?)]
[f (P) (->i ([x α]) (_ (x) (P x)))])
   (_ (P x) (P x
  (λ (x P f) (f x)))
(f 42 (λ _ string?) number->string)

; f: broke its own contract
;   promised: α
;   produced: 42
;   in: the 1st argument of
;   the P argument of
;   (parametric->/c
;(α)
;(->i
; ((x α)
;  (P (-> α contract?))
;  (f (P) (->i ... ...)))
; (_ (P x) (P x

Is it possible to express this kind of enforcement using parametric 
contracts? (For example, a contract that enforces something similar to the 
type of a generated induction principle for a datatype in a proof assistant)

It's possible to construct a term of a corresponding type in a dependently 
typed language:
example: ∀ {α : Type}
   (x: α)
   (P: α → Type)
   (f: (∀ (x: α), P x)),
   (P x) :=
assume _ x _ f, f x

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] TR for fast manipulation of C data

[Phil Nguyen]

Each call in the program shrinked from ~20s to ~0.4s on my computer if I
replaced all the casts with asserts. Given there's a correspondence between
the two for base types, I wonder if existing gradually typed programs would
benefit just from a more optimized expansion of `cast`.

On Sun, Sep 17, 2017 at 9:39 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu>
wrote:

> `cast` uses the contract system, which is harder for the compiler to
> optimize than `assert` which is just an if. At least that's my initial
> impression.
>
> Sam
>
> On Sep 17, 2017 9:27 PM, "Phil Nguyen" <philnguyen0...@gmail.com> wrote:
>
>> (and (cast _ Positive-Fixnum) into (assert (assert _ fIxnum?)
>> positive?)). Somehow these make a huge difference.)
>>
>> On Sun, Sep 17, 2017 at 9:19 PM, Phil Nguyen <philnguyen0...@gmail.com>
>> wrote:
>>
>>> Simply changing all the casts (cast _ Natural) into (assert _
>>> exact-nonnegative-integer?), and (cast _ Positive-Flonum) into (assert
>>> (assert _ flonum?) positive?) speeds up significantly for me.
>>>
>>> On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler <
>>> ro...@eecs.northwestern.edu> wrote:
>>>
>>>> Maybe a first step is to just (unsafely) disable the contract checking
>>>> in order to see what the upper-limit of the improvement is.
>>>>
>>>> Robby
>>>>
>>>>
>>>> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>>>> <us...@plt-scheme.org> wrote:
>>>> > I’m currently unhappy with the speed of rsound’s resampling. This is
>>>> a pretty straightforward interpolation operation; if you’re not already
>>>> familiar, imagine mapping an old vector ‘o' of size M onto a new vector ’n’
>>>> of size N where each point ‘i’ in the new vector is obtained by linearly
>>>> interpolating the two points of the old vector nearest to i*(M/N).
>>>> >
>>>> > Currently, it takes about 10 seconds to resample 60 seconds of audio,
>>>> which I believe could be much much better. I bet that TR would help a lot
>>>> here, but I’ve been poking around, and I don’t see any typed access to
>>>> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
>>>> functions with wrappers would be considerably slower...
>>>> >
>>>> > … well, I shouldn’t guess. I should try.
>>>> >
>>>> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to
>>>> TR. I could probably do better by working with the optimization coach, but
>>>> I’m guessing that interposing the contract boundary on every read and write
>>>> to the s16vector is a big slowdown that could easily be avoided. So: is
>>>> there a good way to use TR for access to cpointers?
>>>> >
>>>> > I’ve attached the code in case anyone wants to see it; I don’t really
>>>> care about the first call to (time …); it’s appallingly slow (20x slower in
>>>> TR), but that’s not the part I’m trying to speed up. It’s the second call
>>>> to (time…), around
>>>> > the resample call.
>>>> >
>>>> > John
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > 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.
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> 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.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] TR for fast manipulation of C data

[Phil Nguyen]

(and (cast _ Positive-Fixnum) into (assert (assert _ fIxnum?) positive?)).
Somehow these make a huge difference.)

On Sun, Sep 17, 2017 at 9:19 PM, Phil Nguyen <philnguyen0...@gmail.com>
wrote:

> Simply changing all the casts (cast _ Natural) into (assert _
> exact-nonnegative-integer?), and (cast _ Positive-Flonum) into (assert
> (assert _ flonum?) positive?) speeds up significantly for me.
>
> On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
>
>> Maybe a first step is to just (unsafely) disable the contract checking
>> in order to see what the upper-limit of the improvement is.
>>
>> Robby
>>
>>
>> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>> <us...@plt-scheme.org> wrote:
>> > I’m currently unhappy with the speed of rsound’s resampling. This is a
>> pretty straightforward interpolation operation; if you’re not already
>> familiar, imagine mapping an old vector ‘o' of size M onto a new vector ’n’
>> of size N where each point ‘i’ in the new vector is obtained by linearly
>> interpolating the two points of the old vector nearest to i*(M/N).
>> >
>> > Currently, it takes about 10 seconds to resample 60 seconds of audio,
>> which I believe could be much much better. I bet that TR would help a lot
>> here, but I’ve been poking around, and I don’t see any typed access to
>> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
>> functions with wrappers would be considerably slower...
>> >
>> > … well, I shouldn’t guess. I should try.
>> >
>> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to TR.
>> I could probably do better by working with the optimization coach, but I’m
>> guessing that interposing the contract boundary on every read and write to
>> the s16vector is a big slowdown that could easily be avoided. So: is there
>> a good way to use TR for access to cpointers?
>> >
>> > I’ve attached the code in case anyone wants to see it; I don’t really
>> care about the first call to (time …); it’s appallingly slow (20x slower in
>> TR), but that’s not the part I’m trying to speed up. It’s the second call
>> to (time…), around
>> > the resample call.
>> >
>> > John
>> >
>> >
>> >
>> > --
>> > 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.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] TR for fast manipulation of C data

[Phil Nguyen]

Simply changing all the casts (cast _ Natural) into (assert _
exact-nonnegative-integer?), and (cast _ Positive-Flonum) into (assert
(assert _ flonum?) positive?) speeds up significantly for me.

On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler 
wrote:

> Maybe a first step is to just (unsafely) disable the contract checking
> in order to see what the upper-limit of the improvement is.
>
> Robby
>
>
> On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
>  wrote:
> > I’m currently unhappy with the speed of rsound’s resampling. This is a
> pretty straightforward interpolation operation; if you’re not already
> familiar, imagine mapping an old vector ‘o' of size M onto a new vector ’n’
> of size N where each point ‘i’ in the new vector is obtained by linearly
> interpolating the two points of the old vector nearest to i*(M/N).
> >
> > Currently, it takes about 10 seconds to resample 60 seconds of audio,
> which I believe could be much much better. I bet that TR would help a lot
> here, but I’ve been poking around, and I don’t see any typed access to
> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
> functions with wrappers would be considerably slower...
> >
> > … well, I shouldn’t guess. I should try.
> >
> > AAGH! Yep, I was right. it goes 7x slower after naive conversion to TR.
> I could probably do better by working with the optimization coach, but I’m
> guessing that interposing the contract boundary on every read and write to
> the s16vector is a big slowdown that could easily be avoided. So: is there
> a good way to use TR for access to cpointers?
> >
> > I’ve attached the code in case anyone wants to see it; I don’t really
> care about the first call to (time …); it’s appallingly slow (20x slower in
> TR), but that’s not the part I’m trying to speed up. It’s the second call
> to (time…), around
> > the resample call.
> >
> > John
> >
> >
> >
> > --
> > 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.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] literals vs datum-literals in syntax-parse

[Phil Nguyen]

On Tuesday, January 10, 2017 at 4:34:41 PM UTC-5, Alexis King wrote:
> Basically, the difference is as follows: #:literals compares
> identifiers using free-identifier=?, but #:datum-literals compares
> them by using syntax-e and eq?.
> 
> You can observe the difference using two extremely simple macros
> that only differ in their use of #:literals or #:datum-literals:
> 
>   (define-syntax lit
> (syntax-parser
>   #:literals [add1]
>   [(_ add1) #'"add1"]
>   [(_ _)#'"something else"]))
> 
>   (define-syntax dat
> (syntax-parser
>   #:datum-literals [add1]
>   [(_ add1) #'"add1"]
>   [(_ _)#'"something else"]))
> 
> Observe the behavior of the `lit` macro:
> 
>   > (lit add1)
>   "add1"
>   > (let ([add1 #f])
>   (lit add1))
>   "something else"
>   > (require (rename-in racket/base [add1 my-add1]))
>   > (lit my-add1)
>   "add1"
> 
> Contrast the results with the same examples using the `dat` macro
> instead:
> 
>   > (dat add1)
>   "add1"
>   > (let ([add1 #f])
>   (dat add1))
>   "add1"
>   > (require (rename-in racket/base [add1 my-add1]))
>   > (dat my-add1)
>   "something else"
> 
> By “recognize symbolically”, it means that #:datum-literals looks
> at the name of the symbol and nothing else. In contrast, #:literals
> is more advanced, since it looks for an identifier with the same
> binding as the one specified.
> 
> In my opinion, when in doubt, prefer #:literals.
> 
> > On Jan 10, 2017, at 11:58 AM, Deren Dohoda
> > wrote:
> > 
> > I am still making most macros using syntax-rules and syntax-case
> > because when I happened to learn macros these were the paths of
> > least resistance. Every once in a while I try to learn a little
> > more of syntax-parse since the few times I've tried it I really
> > liked it.
> > 
> > It appears that, in general, syntax-rules and syntax-case use what
> > syntax-parse considers "datum-literals", which the docs say are
> > recognized "symbolically" versus actual literals which are recognized
> > "by binding." The example in the documents for some reason clarifies
> > nothing since both expressions are the same and give the same output,
> > making this a distinction without an obvious difference.
> > 
> > Can someone explain the intention behind #:literals as opposed to
> > #:datum-literals? In what cases should I consider #:literals? Why
> > would I want to avoid #:datum-literals, or vice versa?
> > 
> > Thanks,
> > Deren

I have a related question: How does #:literals differ from ~literal in the 
left-hand side of syntax-parse? I used to think they were the same but it seems 
that changing from one to another altered my program's behavior...

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] `equal?`'s unintuitive behavior with parametric contracts

[Phil Nguyen]

In the following program, `(p? 1 1)` returns `#t` or `#f` depending on `p?` 
being called from the same or different module:

#lang racket

(module m racket
  (provide
(contract-out
  [p? (parametric->/c (a) (a a . -> . boolean?))]))
  (define p? equal?)
  (p? 1 1))
  
(require 'm)
(p? 1 1)

Module `m` is wrong in the first place for comparing 2 sealed objects, but here 
we don't get an error. Is it practical to make `equal?` aware of parametric 
contracts?

This bit me in practice when I used a hashtable (which had an implicit 
`equal?`). The worse part was that tests passed because they were in the same 
module, and I only got unexpected behavior from outside.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Unit order matters in `define-values/invoke-unit/infer`

[Phil Nguyen]

The program below complains that `x` is used before initialization. But if I 
change the linking order to `x@` before `y@`, it works fine. Is this an 
intended behavior or a bug? This is Racket v6.4.0.7

#lang racket

(define-signature x^ (x))
(define-signature y^ (y))

(define-unit x@
  (import)
  (export x^)
  (define x 42))

(define-unit y@
  (import x^)
  (export y^)
  (define y x))

(define-values/invoke-unit/infer
  (link y@ x@))

-- 
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.
For more options, visit https://groups.google.com/d/optout.