[racket-users] Re: Pitfall for contracts with serializable structs

On Wednesday, February 6, 2019 at 12:35:11 PM UTC+8, Philip McGrath wrote: > > > Why is this significant in practice? Realistically, I don't expect > programmers would write functions like `corrupt-serialized` in an attempt > to deliberately exploit some library's invariant, and the chance of s

[racket-users] Pitfall for contracts with serializable structs

I was (relatively) recently bitten by an issue with putting contracts on serializable structs. What's worse, once I figured out what was going on, I realized that I'd run into this very issue before and even discussed it on this list

Re: [racket-users] Re: updated Racket-on-Chez status

First, thanks for looking into this. Rather than answer inline, I will just comment a few things: * Unfortunately, the tests use real data because they try to pick up problems with the code, not test the performance, however, some of the tests do run against only data from the repository. I w

Re: [racket-users] Re: Some concern about ChezScheme...

I appreciate the engineering diligence behind Alex's and Paulo's concerns. Given the exemplary track record on Racket, I'm comfortable putting faith in Matthew's assessments (like a trusted engineering colleague, beyond the quantifiable like interim benchmarks), and there's at least some obvio

[racket-users] Re: Some concern about ChezScheme...

I guess I also have some concerns about the move to Chez, and largely for the same reasons: * the Chez community is very small, at least when looking at the chez-scheme Google Group and Github activity. I am glad that I'm not the only one who noticed that. * the "maintainability" angle is qu

Re: [racket-users] Some concern about ChezScheme...

I had a related (but different and small) concern about the new dependency a while ago (this was off-list), but it sounded like that risk was covered, and also that Matthew has really gotten into the Chez code. BTW, sometime around when the move to Chez settles, it would be good if many peopl

Re: [racket-users] Real-world examples of XML usage?

If you're doing JSON that's not totally ephemeral (not like sending a few keystrokes for a live search JS widget is [1]), but something more like returning information from a database, you could do JSON yet get a little closer to some of the benefit of XML (like "what the heck is this data that

Re: [racket-users] Real-world examples of XML usage?

On Tue, Feb 5, 2019 at 11:18 AM Konrad Hinsen wrote: > > David Storrs writes: > > > to type things. In addition, most developers that I've worked / > > talked with will typically reach for the JSON API before the XML one > > given the choice. I think the ground truth suggests that JSON is a > >

Re: [racket-users] Some concern about ChezScheme...

Hi Paulo, Not to discourage other answers to your call for opinions, but here's mine. Granting your point about the structure of the code in Chez Scheme, everything is relative. I still think Chez Scheme is a better starting point than the existing Racket implementation as code to reorganize, doc

[racket-users] Re: Some concern about ChezScheme...

On Tuesday, February 5, 2019 at 2:01:20 PM UTC+1, Paulo Matos wrote: > > > So I am a bit concerned about this. I somehow get the feeling that > what's going to happen is that Chez is going to slowly degenerate to a > Racket sub-project, and nobody is going to really use Chez directly. > > ...

Re: [racket-users] Tensorflow bindings?

Hi all, Is this relevant? https://github.com/charlescearl/DeepRacket Kind regards Stephen On Mon, 4 Feb 2019 at 21:39, Neil Van Dyke wrote: > I had Racket TensorFlow bindings as a possible-TODO for me, but I don't > yet know ML tools I'll use, and what APIs/layers I'll prefer atop tools > tha

Re: [racket-users] Real-world examples of XML usage?

David Storrs writes: > to type things. In addition, most developers that I've worked / > talked with will typically reach for the JSON API before the XML one > given the choice. I think the ground truth suggests that JSON is a Ah, I see, we are working in very different contexts. In a Web API,

Re: [racket-users] Real-world examples of XML usage?

On Tue, Feb 5, 2019 at 2:17 AM Konrad Hinsen wrote: > > David Storrs writes: > > > > I was specifically thinking of JSON. It allows for encoding all the > > essential structure of XML in far fewer characters, meaning there's > > less data to send over the wire. It's more human-readable. There ar

[racket-users] TFPIE 2019

Dear All, It is with great enthusiasm that I write to encourage you to share with the community of CS educators at large your efforts and experiences. Please strongly consider submitting a description of your novel work to Trends in Functional Programming in Education 2019. Below you can find the

Re: [racket-users] Re: updated Racket-on-Chez status

I have been trying a few variations of the code. It would be nice to have a test branch that use only the data in the repository. I used some fake data instead. For the tests, I used the function *get-mean-max-bounds* https://github.com/alex-hhh/ActivityLog2/blob/master/rkt/data-frame/meanmax.rkt

[racket-users] Some concern about ChezScheme...

Hi all, Now that I got your attention... :) Although the title is not purely click-bait, it is motivated by personal requirements. Most of us are happy with the move to Chez (actually haven't heard anyone opposing it), but I would like to point to something I have felt over the past year and to u

Re: [racket-users] Quickscript error on first startup of Racket 7.2

Sounds like you are already in good shape! Robby On Tue, Feb 5, 2019 at 12:57 AM Laurent wrote: > On Mon, Feb 4, 2019 at 9:55 PM Robby Findler > wrote: > >> > Possibly. I'm not sure what would be the best option yet, I'll think >> about it but I welcome suggestions. >> >> I think the main thin

[racket-users] [TFP'19] first call for papers: Trends in Functional Programming 2019, 12-14 June 2019, Vancouver, BC, CA

--- C A L L F O R P A P E R S --- == TFP 2019 == 20th Symposium on Trends in Functional Programming 12-14 June, 2019