Hello!

:wave:

a couple of days ago this worked: raco pkg install --binary --no-docs sql but today I get: root@81a47c27c53a:/# raco pkg install --binary --no-docs sql Resolving "sql" via <https://download.racket-lang.org/releases/7.7/catalog/> Resolving "sql" via <https://pkg-build.racket-lang.org/server/built/catalog/> Downloading <https://pkg-build.racket-lang.org/server/built/pkgs/sql.zip> raco pkg install: package content is not compatible with the requested conversion package: sql requested conversion: binary package content: built content for version: 7.8 I am working inside the racket/racket:7.7 docker image

Do I interpret this to mean that --binary is only available for the latest 7.8 Racket version?

That explains a lot! Ok, so indeed this requires modifying the compiler to be aware of continuation marks. I thought this was already kind of automatic (i.e., magical).

Or a more general question about raco pkg install… I’m working on my own package which has sql as a dependency. Since my package is currently “source” only, when I install my package I think it installs sql as a source package as well, because it installs all the build-deps of sql, and the build-deps of those deps… which is a lot of stuff that’s irrelevant to using the library.

Is there a way to control this behaviour?

This is explained in words here, but was this proven formally elsewhere?

Yes, --binary is only available for whatever version the package catalog build server uses, which is usually the latest released version. I haven’t gotten around to adding the 7.8 docker image yet, I will eventually. If you’d like to fix the issue right away, send a pull request to https://github.com/jackfirth/racket-docker\|https://github.com/jackfirth/racket-docker that adds 7.8 to the list of versions in the build.sh script. There’s other pull requests for previous versions that you can copy off of.

not as far as I know, unfortunately

Was what proven formally?

But probably the answer is no.

The most formal treatment of continuation marks is in John Clements’ papers and dissertation about them

Thanks, I should take a look at John’s papers then (really just out of curiosity). The what is “a modification of the optimizer to incorporate continuation marks such that the new optimizer provably preserves tail recursion and most importantly the equivalence of the program’s outputs and return values, depending on the application context (assuming the old optimizer does that already of course)”. It just seemed to me that it shouldn’t be too difficult to prove (in Redex probably?), and the above text seems to hint at such a proof.

(and again, I currently don’t have the tools to understand all the formalism, not to mention judging them, so it’s just that I’m curious about the extent of what can be dealt with formally)

From the Stepper paper https://www2.ccs.neu.edu/racket/pubs/esop2001-cff.pdf

I just made a #theory channel in case anyone is interested.

The purpose is to avoid discussing abstract matters in the general channel, which could discourage some new ‘normal’ users

Definitely no formal proofs were done about the chez optimizer. What that text means is that Matthew and Kent added some checks in the optimizer to avoid disturbing tail positions unless the optimzer knows that it doesn’t matter.

I see, thanks.

Perhaps the thing that should be done is adding examples

I think there’s an introduction on how to read these grammars somewhere in the guide? Not sure though

The problem here I suppose is that if you don’t know about this subtlety, you won’t know that you need to look for some information somewhere

https://racket.slack.com/archives/C09L257PY/p1596693811361300

But I mean, that won’t really help much

Indeed. I thought there was a better example somewhere, but maybe I’m misremembering. Could be worth adding a good example then

@mflatt I made some changes to the expander. Following the instructions from src/README.txt, I ran make in racket/src/expander/, but got open-output-file: error opening file path: /Users/capfredf/code/racket/racket/src/expander/../../src/racket/src/startup.inc system error: No such file or directory; errno=2

I think there’s a path wrong in the Makefile post chez-as-default

Yes, the racket in that path should be bc. Also, the instructions need to be updated to say to make in racket/src/cs to rebuild .scm files.

I can make those improvements, but later today.

Got it. Thanks!

We’ve talked about this before. It sure would be nice to have binary packages for a couple versions back. Perhaps someone who is hosting an alternative catalog could possibly help support that (maybe they already are?) @popa.bogdanp?

I guess it doesn’t matter much, just seems unnecessary

maybe fetching build-deps of deps should be a special case you have to ask for?

@mflatt I added print expressions, say (printf "hello") , to the beginning of the function eval in expander/eval/main.rkt, or to several places I thought were the possible entrance of eval. I thought one of the debug messages would show up every time I ran an expression at REPL, but none of them did. I think I am misunderstanding how an expression is evaluated internally……

Adding a printf in eval of expander/eval/main.rkt should indeed be noisy — lots out printouts while making the expander itself with make, for example, and make demo should produce failures in the sanity-checking demos. But you do mean (printf "hello\n") or something that includes a newline (to trigger buffer flushing), right?

Yes, I added a newline to each of those messages and some of them, like the one I added to eval , popped up during make under src/cs

a quick question: why does making the expander call eval? do we run racket program to schemify the expander?

The expander is used to expand itself when you make.in src/expander. The schemify layer is used when you make in src/cs, but not for BC.

The expander is also used to expand itself when you make in src/cs.

But if you’re running make in src/cs, you also make in src/build/cs/c or run make or make cs from the repo checkout top level, right? (One of those is needed to actually rebuild racketcs or racket.)

Not to bike shed, but, I feel like the grammar brackets should be italic, as well as a different color.

That would make them stand out more, for people with “normal” vision.

Not to mention people who have difficulty distinguishing dark red from black.

I’ve thought about supporting a couple versions of built packages on Racksnaps but haven’t done it yet because it’s not something I need. One concern there would be storage space because I don’t think built packages across Racket versions would deduplicate well (at all?) under my content-addressing scheme.

What about making them bigger?

I pushed a revised “racket/src/expander/README.txt”. You may have thoughts on how it could be improved.

Ah, I missed out make or make as-is at the top level.

I will take a look at the README.

@greg @laurent.orseau

which one looks better?

Current one, bigger, and italic respectively

@robby and @mflatt might have opinion?

If there’s no objection, I will go with italic. It doesn’t change line height significantly, while look distinctive enough.

I am sympathetic to the idea that color is fraught but I don’t find the italic brackets beautiful…. that said I don’t really have a strong opinion. As for the problem that motivated this example, maybe a better idea is to change the way new-based constructors print out in the docs to avoid the semantically-different brackets?

Maybe it could look more like how function calls work, with a default value appearing to mean it is optional?

Or some other outofband annotation to indicate that one of the arguments was optional somehow.

> Maybe it could look more like how function calls work, with a default value appearing to mean it is optional? But function call also has the “optional bracket”.

In fact, the new constructor leaves the rendering job to defproc, so they are already rendered in the same way.

Hm.

Maybe we should change new so that it parses keywords and do the moral equivalent of adding those parens in. Then we can fix the docs.

> Maybe we should change new so that it parses keywords and do the moral equivalent of adding those parens in. Then we can fix the docs. I’m not sure if I understand this

Here’s another possibility (I’m stilling playing with paren styling because it seems to need the least amount of work)

My suggestion was to change the new form so that one can write (new timer% #:notify-callback f #:just-once? #t) and have it be same as if one had written (new timer% [notify-callback f] [just-once #t]) (well, but with error messages that match the notation used).

Then, we could change the documentation rendering to always use the keyword based form.

That would also solve the problem and probably isn’t too too much work :slightly_smiling_face:

Don’t we still need to maintain backward compatibility, though? I mean, we can document the additional one, but we still need to keep the old one, too, correct?

we need to make the old one still work but we don’t need the documentation to use the old one.

And I guess the parsing could look to see if there is a square bracket/paren or a keyword and then go into one of the two specialized parsers. It could be all keywords or no keywords to make error checking easier

I’m ok with italic brackets. In the original, uglier documentation, the tt and non-tt brackets looked more different. But going back to a more generally ugly font combination is probably not the right solution. :slightly_smiling_face: I wouldn’t stand in the way of a keyword-based new, but it’s not the layer where I think the syntax needs to change to improve.

Is there a fancy Unicode bracket that would stand out and render well, such as 〖 〗?

From my experience: not really. But I will try a couple of them and report the result