Re: [racket-users] Assertion failures in bigfloat package

[Shaobo He]

Thank you guys. I'll start to dig into it after a paper deadline.

Sam Tobin-Hochstadt  于2019年4月19日周五 上午7:29写道：

> On 1: the best thing to do is figure out (probably with logging) which
> call to MPFR and what arguments produce the assertion.
> 2: I don't think there's any intended non-determinism.
>
> Sam
>
> On Fri, Apr 19, 2019 at 12:56 AM  wrote:
> >
> > Hello everyone,
> >
> > I'm using Racket's MPFR bindings to build an application and encountered
> assertions failures like `../../src/get_str.c:153: MPFR assertion failed:
> size_s1 >= m`. Somehow I could not reproduce this error provided I set the
> random seed correctly. So I have two questions here,
> >
> > 1. What should I do to debug the assertion failure if I can reproduce it?
> > 2. Are there any nondeterminism inside the bigfloat package?
> >
> > Thanks,
> > Shaobo
> >
> > --
> > 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] Being a good macro citizen: patterns to follow for good error reporting

[Matthias Felleisen]

> On Apr 21, 2019, at 6:48 AM, zeRusski  wrote:
> 
> I just had an epiphany, or rather a very painful revelation, that if your 
> macro does not report errors in terms of user code, say, when inputs are 
> wrong, you ought to be ostracized by the community if not banished from any 
> social interactions altogether. You don't deserve the good life. Solitary 
> confinement, damn it, until you've repented your sins, for you have sinned!


This was the problem I formulated in slightly more polite words to launch Ryan 
C’s dissertation on his dissertation research in ’03. 


> 
> Every macro has a good path - one that lets us figure what it should expand 
> into. I doubt I'm alone in merrily banging out said expansions without so 
> much as a single thought about all the bad paths the macro can take. It's 
> gotten painfully obvious lately, that if I don't take care to capture such 
> erroneous states and expansions, my macro may as well be broken, as in 
> completely wrong, even if it does the right thing for correct inputs.
> 
> Sadly, I don't think I have any systematic approach to being a good citizen 
> here, nor is my mental model for syntax objects I produce has an entry for 
> good locations and context. First, I noticed that I started to use syntax/loc 
> in place of #' everywhere I produce syntax objects. Then more pain led me to 
> discover a combination of ~describe pattern with #:context syntax-parse 
> option. And, I tell ya they are MAGICAL! Both were learnt through hardship 
> and pain, s


Yeap, this is part of the result of this research. See my second lecture from 
Racket School ’18.


BTW, for all those reading this far, we’re running another Racket School. 
Priomised I’ll lecture less and Jay will do better :) 




> o I wonder if there is a compendium of patterns that I should be cognizant of 
> to avoid at least some of that pain as I push Racket harder?
> 
> Could people maybe share relevant examples, or point out Racket machinery 
> that may not be immediately relevant but one should have at least passing 
> knowledge of to recognize when it may come in handy?
> 
> Is this too broad of a request?


No, even with syntax-parse and define-syntax-class around, we still need guides 
for people who enter Macroland so that they find their way to the good 
waterholes. Kind of like a cross between AppleMap and Yelp. 

— Matthias

-- 
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] SIGSEGV when running Racket

[polarishehn]

Hello everyone,

I observed some exceptions like `SIGSEGV MAPERR si_code 1 fault on addr 
0x7f6f4e30fff0` when running a Racket program. Any ideas why this happens?

Thanks,
Shaobo

-- 
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] Racket News - Issue 6

['Paulo Matos' via Racket Users]

On 18/04/2019 10:25, Alexander Shopov wrote:
> And a bit more popularity - there will be links from
> Linux Weekly News: Announcements -> Newsletters -> Developement to the
> news letter:
> 

Hi Alex,

Many thanks for this. It looks great.

-- 
Paulo Matos

-- 
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] question about matching with "(? ...)"

[Michael Murdock MacLeod]

Match treats `empty` as an identifier to bind, not as a pattern for the empty 
list. This means that the first case will always be matched. You can use 
`(list)` or `'()` to match an empty list.

Also, in the last catch-all case, you pass the function `rest` which returns 
the tail of a list to `filter-odds`. You probably wanted to shadow that binding 
by using `(cons first rest)` instead of `_`.

Here's the version with the fixes above:

(define (filter-odds v)
  (match v
[(list) (list)]
[(cons (? odd? first) rest)
 (cons first (filter-odds rest))]
[(cons first rest) (filter-odds rest)]))

(filter-odds '(1 2 3 4 5)) ; ==> '(1 3 5)

Best,
Michael MacLeod

On Sunday, April 21, 2019 1:19:03 PM PDT Tim Meehan wrote:
> Forgive this naive question, I am having some trouble understanding some
> matching forms. If I wanted to filter out odd numbers like this:
> 
> (filter odd? '(1 2 3 4 5)) => '(1 3 5)
> 
> but I wanted to do this with a match:
> (define (filter-odds v)
>   (match v
> [empty empty]
> [(cons (? odd? first) rest) (cons first (filter-odds rest))]
> [_ (filter-odds rest)]))
> 
> (filter-odds '(1 2 3 4 5)) => '(1 2 3 4 5)


-- 
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] question about matching with "(? ...)"

[Jens Axel Søgaard]

Try

[rest (filter-odds rest]

as the last clause.

søn. 21. apr. 2019 kl. 22.19 skrev Tim Meehan :

> Forgive this naive question, I am having some trouble understanding some
> matching forms. If I wanted to filter out odd numbers like this:
>
> (filter odd? '(1 2 3 4 5)) => '(1 3 5)
>
> but I wanted to do this with a match:
> (define (filter-odds v)
>   (match v
> [empty empty]
> [(cons (? odd? first) rest) (cons first (filter-odds rest))]
> [_ (filter-odds rest)]))
>
> (filter-odds '(1 2 3 4 5)) => '(1 2 3 4 5)
>
>
> --
> 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.
>
-- 
-- 
Jens Axel Søgaard

-- 
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] question about matching with "(? ...)"

[Tim Meehan]

Forgive this naive question, I am having some trouble understanding some
matching forms. If I wanted to filter out odd numbers like this:

(filter odd? '(1 2 3 4 5)) => '(1 3 5)

but I wanted to do this with a match:
(define (filter-odds v)
  (match v
[empty empty]
[(cons (? odd? first) rest) (cons first (filter-odds rest))]
[_ (filter-odds rest)]))

(filter-odds '(1 2 3 4 5)) => '(1 2 3 4 5)

-- 
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] make extensions or replacements

[Robby Findler]

ICFP 2018 should be available to all (and other years too). It was paid for
and I can get the PDF.

Could you send me more info?

Robby

On Sun, Apr 21, 2019 at 12:53 PM Greg Hendershott 
wrote:

> On Sat, Apr 20, 2019 at 12:02 PM Norman Gray 
> wrote:
> > On 20 Apr 2019, at 1:11, 'John Clements' via Racket Users wrote:
> >
> > > There’s a paper at the most recent ICFP from Simon Peyton Jones (et
> > > al., I’m guessing) on make languages, IIRC.
> >
> > Very interesting -- thanks!  The paper is Andrey Mokhov, Neil Mitchell,
> > and Simon Peyton Jones. 2018. Build Systems à la Carte. _Proc. ACM
> > Program. Lang._ 2, ICFP, Article 79 (September 2018), 29 pages.
> > 
>
> From a quick read of the paper:
>
> - Many silly things have happened in the last 10 years due to people
> wanting to believe they have same challenges as Google, Facebook,
> Microsoft. "But is it web scale?" :)
>
> - The Shake "dynamic" example is interesting, but I'm pretty sure I
> recently did the same thing in Make using variables. I tried to follow
> the two links to learn more details, but the RIAA sorry MPAA sorry ACM
> paywall blocked me.
>
> Having said all that, I'm not here to defend Make as a delightful surface
> DSL.
>
> --
> 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] make extensions or replacements

[Greg Hendershott]

On Sat, Apr 20, 2019 at 12:02 PM Norman Gray  wrote:
> On 20 Apr 2019, at 1:11, 'John Clements' via Racket Users wrote:
>
> > There’s a paper at the most recent ICFP from Simon Peyton Jones (et
> > al., I’m guessing) on make languages, IIRC.
>
> Very interesting -- thanks!  The paper is Andrey Mokhov, Neil Mitchell,
> and Simon Peyton Jones. 2018. Build Systems à la Carte. _Proc. ACM
> Program. Lang._ 2, ICFP, Article 79 (September 2018), 29 pages.
> 

>From a quick read of the paper:

- Many silly things have happened in the last 10 years due to people
wanting to believe they have same challenges as Google, Facebook,
Microsoft. "But is it web scale?" :)

- The Shake "dynamic" example is interesting, but I'm pretty sure I
recently did the same thing in Make using variables. I tried to follow
the two links to learn more details, but the RIAA sorry MPAA sorry ACM
paywall blocked me.

Having said all that, I'm not here to defend Make as a delightful surface DSL.

-- 
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] Defeating Racket’s separate compilation guarantee

[Ben Greenman]

One quick thought: I wasn't sure what to expect after reading the current title.

How about changing it to say more about the specific exploit?

"A terrible hack to move state across Racket phases"
"How to smuggle state across phase boundaries"

At least, it would have helped me if "separate compilation" was
replaced with "phase separation"

-- 
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] Being a good macro citizen: patterns to follow for good error reporting

[zeRusski]

I just had an epiphany, or rather a very painful revelation, that if your 
macro does not report errors in terms of user code, say, when inputs are 
wrong, you ought to be ostracized by the community if not banished from any 
social interactions altogether. You don't deserve the good life. Solitary 
confinement, damn it, until you've repented your sins, for you have sinned!

Every macro has a good path - one that lets us figure what it should expand 
into. I doubt I'm alone in merrily banging out said expansions without so 
much as a single thought about all the bad paths the macro can take. It's 
gotten painfully obvious lately, that if I don't take care to capture such 
erroneous states and expansions, my macro may as well be broken, as in 
completely wrong, even if it does the right thing for correct inputs.

Sadly, I don't think I have any systematic approach to being a good citizen 
here, nor is my mental model for syntax objects I produce has an entry for 
good locations and context. First, I noticed that I started to use 
syntax/loc in place of #' everywhere I produce syntax objects. Then more 
pain led me to discover a combination of ~describe pattern with #:context 
syntax-parse option. And, I tell ya they are MAGICAL! Both were learnt 
through hardship and pain, so I wonder if there is a compendium of patterns 
that I should be cognizant of to avoid at least some of that pain as I push 
Racket harder?

Could people maybe share relevant examples, or point out Racket machinery 
that may not be immediately relevant but one should have at least passing 
knowledge of to recognize when it may come in handy?

Is this too broad of a request?

-- 
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] Defeating Racket’s separate compilation guarantee

[Alexis King]

Hello all,

I just published a blog post on defeating Racket’s separate compilation 
guarantee. While I don’t imagine such a thing is actually a good idea, I think 
the path to getting there is interesting anyway, and it touches lots of 
different parts of the Racket system. For those who are interested, the blog 
post is available here:


https://lexi-lambda.github.io/blog/2019/04/21/defeating-racket-s-separate-compilation-guarantee/

Comments welcome,
Alexis

-- 
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] Re: catch and bind an unbound id in a macro

[zeRusski]

On Saturday, 20 April 2019 23:55:50 UTC+1, Stephen Chang wrote:
>
> fwiw, I think here is a working version along the lines of your 
> original attempt. 
>

I see what you did there. This is both icky (as requested) and cute  :0 
Thanks, it's actually illuminating 

-- 
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] From HtDP to Racket

[Luis Sanjuán]

Matthias, thank you very much for taking the time to carefully read the 
whole thing
and for your thoughtful suggestions. Most, if not all of them, put on the
foreground my own doubts and misgivings.


On Saturday, April 20, 2019 at 8:19:31 PM UTC+2, Matthias Felleisen wrote:
>
>
>
> > On Apr 18, 2019, at 12:08 PM, Luis Sanjuán  > wrote: 
> > 
> > The last month or so we all read some interesting posts about the 
> convenience of examples or docs to facilitate the transition from other 
> languages to Racket (from Python to Racket, from R to Racket, ...). Then I 
> thought about another non-Racket languages that no one mention, if I recall 
> well, for which such examples would be more than helpful, *SL languages ;) 
> > 
> > Of course, The Realm is there, but more examples would be beneficial, I 
> guess. I have written something along these lines on my blog: 
> > 
> > 
> https://los-pajaros-de-hogano.blogspot.com/2019/04/from-htdp-to-racket-isbn-extraction-in.html
>  
> > 
> > It might be full of inaccuracies or even errors. So comments, fixes, or 
> suggestions are welcomed. 
>
>
>
>
> Luis, this is great. Thank you for the effort. 
>
> Here are some suggestions on how I’d re-order some of the material: 
>
> 0. Importing all of racketbase and racket/string and racket/file first is 
> questionable. I would create a teachpack 
>
> htdp2racket 
>
> that includes the functions that are needed for writing such excerpts of 
> realistic programs. I’d be happy to collaborate on this and include the 
> teachpack with 2htdp. 


racket/file requirement can be easily replaced with your read-file
(2htdp/batch-io)

As for racket/string, all the functions needed, if not in their full
generality, at least to the extent required by the task, can be
defined in ISL, and replaced with Racket string functions in
a later step.

Regexes pose a more demanding challenge. I really thought of it, and 
even tried to some extent other alternatives too:

(a) Begin with a solution to HtDP ex. 476 (fsm-match) and extend it to
deal with quantifiers. Maybe this reduced regex support would
be enough for the task. The problem with this is that this adds heavy 
burden 
to the task.

(b) Tackle the problem assuming that each ISBN appears in its
own line, as the standard specifies. Under this assumption it is
possible to devise this strategy:

1. Read words per line.

2. Join consecutive words consisting of ISBN letters (digits or 'X').

3. Remove separators from the result.

4. Validate each word.

I think that this should work for the problem without the need of regexes.

>From there on regexes could be introduced as another way of solving
the task in Racket, or I could stick to the initial strategy and 
present it in Racket, using regexes sparingly if needed.

What do you think about these alternatives?

Anyway, a teachpack is another option. I really appreciate your offer
of making it possible :-)
 

>
>
> 1. I’d switch to #lang htdp/isl+ first. Your code should pose no problems 
> for this #lang. (It isn’t production ready yet). 
>
> 2. Still in ISL+, I would add the 2htdp/abstraction teachpack to simplify 
> the ISLcode first. I think its suport of for and match fits. 
>
>
I did so in a prior draft. I can return to that, and show full-fledged
Racket 'for' later.
 

> 3. A re-factoring of code must have the support of a test suite. There are 
> three ways to go about this: 
>
> (a) import rackunit into ISL+ 
> (b) import racket-tests/test-engine into the racket/base program 
> and run (test) at the bottom 
> (c) rewrite the tests into rackunit + submdoule. 
>
> I’d go with (b) and do an optional last step to show people how to write 
> idiomatic rackunit tests. 
>
>
Definitely fair complaint. Exposition order shouldn't affect basic
program design principles.
 

> 4. I would not use define/contract for this transition sequence. See 
> elsewhere for its somewhat complex semantics when it comes to blame 
> assignment. Instead when you use contracts, it might be a good time to 
> split the module into two parts: 
>
> — the main functions 
> — the helpers and the large number of constant definitions plus 
> contracts (yes export the contracts from here if you can keep things 
> opaque) 
>
> You could first show how to move code into a submodule with its own 
> contract-out plus a single require, then move the submodule into a file. 
> (That’s how I proceed and it should be a DrRacket refactoring operation.) 
>
>
I'm aware of define/contract caveats (Guide 7.9.2). Splitting things
into two modules looks indeed the soundest solution here.
 

>
> 5. Years ago, I observed a PhD in our lab using point-free style in 
> Racket. He came from Haskell of course. I tried it. I got close to saying 
> negative things about it in the style guide. 
>
>
That was a Haskellian whim, and I'm going to correct it. Actually, function
composition and curried functions are introduced somewhere else, when