¡Hola amigos! There are contracts and static typing. What’s better to use usually? Some racketeers claim that in case when we haven’t complex logic it’s better to use static typing, in case of developing of a prototype module or if we need something more than just type checking then racket/contract is our solution. I’m trying to figure out.

i.e. this generates that error:

#lang scribble/acmart

@title{Surreal Numbers}
@author{Ursula N. Owens}

I ended up creating a custom-acmart.cls with \let\bigtimes\undefined at the end. My Makefile then overwrites the scribble-generated acmart.cls with my custom version and this avoids the issue

if someone has a better fix off the top of there head let me know :wink:

@pnwamk Weird. What command are you using to run scribble?

Has anyone on here noticed that the rsvg package on os x causes Racket to segfault?

In the function cairo_scaled_glyph_page_destroy, which seems to be called from: rsvg_handle_render_cairo.

@leif I see it both when I click “Scribble PDF” in DrRacket and when I try to run xelatex on the result of running scribble --latex ++style style.tex paper.scrbl

Interesting. Can you send us your style.tex file?

it’s just this one line:

\newcommand{\identity}[1]{#1}

Also I don’t think it’s used when you click “Scribble PDF” in DrRacket… so I don’t think it’s a factor (I could be wrong though I suppose)

No, I think you’re correct. Just wanted to double check.

That is very odd. :confused:

So, can I ask what version of Racket you are on?

6.12

Hmm…very odd. I don’t get that error in 6.12:

~/racket-archive/Racket\ v6.12/bin/scribble --pdf foo.scrbl

Do you mind sending me the style file your copy of scribble is using?

@leif

@pnwamk Hmm…your acmart.cls file looks right. How about the style.tex file that is in scribble-lib/scribble/acmart/style.tex?

It depends on the problem, on your problem solving style, on how the solution will be maintained in the future, and on who you’re working with. My suggestion is to try both untill you feel relatively comfortable with both approaches before listening to the advice of others about which is better.

A recent change in Racket causes the python package to no longer build.

The file with the error is: https://github.com/pedropramos/PyonR/blob/master/libpython.rkt

And the particular error is:

raco setup:   void-if-not-available: undefined;
raco setup:    cannot reference an identifier before its definition
raco setup:     in module: "/Users/leif/rsrc/python/libpython.rkt"
raco setup:     internal name: void-if-not-available
raco setup:     compiling: <pkgs>/python/cpy-importing.rkt

@pnwamk I don’t see errors about bigtimes either. Do you get the same error with scribble/manual or scribble/sigplan?

And it looks like the relevant code is: (define-ffi-definer define-function (ffi-lib (and cpyimport-enabled path-to-cpython-lib)) #:default-make-fail void-if-not-available) (define-ffi-definer define-others (ffi-lib (and cpyimport-enabled path-to-others-lib)) #:default-make-fail void-if-not-available) (define-ffi-definer define-c-lang (ffi-lib #f) #:default-make-fail void-if-not-available) (define (void-if-not-available id) (lambda () void))

The problem might go away if you redefine \packageMathabx — but I don’t know what might be conflicting with Mathabx

It looks like there hasn’t been any recent changes to the ffi library (at least not that recent), which makes me think its probably some change with the VM. Any thoughts?

@mflatt ^

@ryanc Could your recent change to ffi/unsafe/define affect evaluation order? The code above doesn’t make sense, but the reference to void-if-not-available probably was previously under a conditional, and maybe’s not anymore. If that’s right, the new behavior is arguably better, as illustrated by the above example. I’m not immediately sure how to balance the improvement against backward compatibility here.

That would seem odd to me because weren’t those changes made several months ago?

@leif

And the error only showed up the last time I pulled. Which was sometime in mid march.

I do not see it with scribble/manual or scribble/sigplan

@pnwamk Hmm…that one also is the same.

I honestly don’t have any more ideas. I can’t seem to reproduce it on my machine. :disappointed:

@mflatt yes. The macro defined by define-ffi-definer used to copy the expression given as the default-make-fail argument to every definition (unless it was overridden). I changed it to bind the expression to a variable and copy the variable reference instead. So if all of the uses of define-function etc were after the definition of void-if-not-available it would work :confused:

@leif @ben what version of TeX are you guys using? I’m on XeTeX 3.14159265–2.6–0.99998 (TeX Live 2017)

Ah, I was forgetting a level of indirection, so I see how the above code can make sense (but also why its behavior changed). Do you think it’s better to wrap the no-longer-copied expression, or is it better to conclude that make-ffi-definer needed to change its behavior?

(I’m observing this both on Ubuntu and MacOS High Sierra)

texlive 2015

@pnwamk On OS X Yosemite, and whatever version comes with homebrew: TeX 3.14159265 (TeX Live 2015) kpathsea version 6.2.1 Copyright 2015 D.E. Knuth.

hhhmmm…. perhaps it’s an issue w/ newer TeX versions?

@mflatt @ryanc Honestly I don’t think its a problem either way. The new behavior seems fine to me, but it should certainly be put in the changes list for the next release announcement.

What version are you using?

(Also adding @ben to the thread)

2017

it looks like you and Ben are on 2015

I’ll try to upgrade tonight & retry.

@mflatt @leif I suppose we could eta-expand to preserve the old evaluation order (when it matters) but avoid the actual expression duplication. I hadn’t expected anyone to be relying on the old behavior when I made the change.

Okay cool. Give it a go and tell us what happened.

Now, I do have an Ubuntu server I can check this out on.

Although it is 16.04…so it might still be way out of date.

Ah yup, sad: pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1 Copyright 2015 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).

I’ve observed it on MacOS High Sierra and Ubuntu 17.10, both of which have TeX 2017 installed

FWIW, this is the only package I have installed that seems to be relying on it. And honestly, its such a small change (move one line 4 lines up), that I don’t think it matters either way.

But eta-expanding would work for me. :slightly_smiling_face:

Hmm…okay.

Well I can set up a 17.10 VM.

(I don’t want to bump my server to 17.10 because its about to be end of lifed)

I’ll put that on my todo list for later this evening. @leif do you know if that code is still maintained?

Last commit was mid 2016. So….not heavily maintained.

I personally only use it fairly sparsely, generally for the lexer/parser.

redex question: redex-match is returning a list of 2 ~results that look identical to me~ equal? results. Should redex-match not be returning 2 results? The docs for redex-match don’t say it returns a list of unique matches, but thats the behavior I’ve been expecting. #lang racket/base (require redex/reduction-semantics) (define-language L (e ::= (+ e e) v (flip e)) (v ::= natural) (EP ::= hole (+ EP e) (+ v EP)) (E ::= EP (+ E e) (+ v E) (flip E))) (redex-match L (in-hole E (flip v)) (term (+ 2 (flip 2)))) ;; (list (match (list (bind 'E '(+ 2 #0=hole)) (bind 'v 2))) ;; (match (list (bind 'E '(+ 2 #0#)) (bind 'v 2))))

It seems I keep having compile-zo errors for other packages after all: https://groups.google.com/forum/#!topic/racket-users/kYk-x5Zn5EE Any ideas?

@ben I think you get 2 matches because there are 2 different ways to match that pattern from the grammar depending on whether E is first matched as an EP or as a (+ E e)

thanks, that makes sense. (I don’t want that first match to be possible, so I’ll think about how to rewrite)

@mflatt Would it be possible to update the version of Cairo we are using in Racket?

The existing version has a known bug with resizing empty glyphs on os x.

But the latest version (or the version that brew has at least), seems to have fixed this bug.

As an example: https://gist.github.com/davenquinn/d2ba1ada38abcc313beb676d81bd6682

@leif I’ll look into upgrading

@mflatt Cool, thanks. It does look like the actual dylibs are stored in a different git repo, but since we split up the repos I’m no longer sure which one. :slightly_smiling_face:

Anyway, thanks.