A follow-up to my previous message https://racket.slack.com/archives/C06V96CKX/p1621079039098700. The absence of Racket highlighting in Pandoc-flavored markdown bothered me a great deal so I wrote a Pandoc-compatible Racket syntax definition. Using it is as easy as passing a command-line argument --syntax-definition=racket.xml to Pandoc when generating an HTML or LaTeX document. The XML file with usage instructions and an example is at https://github.com/Fyrbll/pandoc-highlight-racket. Feedback is more than welcome.
FWIW if you need a list of builtin operations or a (large) regular expression to match numbers, then look here: https://github.com/soegaard/racket-highlight-for-github
Thanks! I got a list of builtins from a file in racket-mode. My strategy for numbers on the other hand, is “quick and dirty” and more or less only cares about recognizing a number’s beginning and end. I have assumed that if you’re publishing your code you have probably checked its syntactic correctness using the Racket interpreter. Long story short: thanks for the regex! It’ll surely improve the clarity and reliability of the highlighter.
@k4rtik It’s the one used on Github now (I believe). There are a test suite for the syntax colorer in DrRacket. These files test quite a lot: https://github.com/racket/syntax-color/tree/master/syntax-color-test/tests/syntax-color
The numbers are in scheme-lexer.rkt starting at line 467.
I see. The tests ought to be handy in the future. I appreciate you sharing those as well.
Some of my students are seeing a strange FASL-related error message, and I’m not sure what’s the cause: fasl-read: incompatible fasl-object machine-type ’ta6osx found in #<binary input port bytevector>
Context: I’m giving my students compiled zo files for libraries they can use for their assignment. I created the zo files on Mac OS. I’ve had students/TAs get that error on both Ubuntu and Windows, but I haven’t seen anyone on Mac get it. And one of my TAs on Windows did not get it either, so not all Windows system seem to have issues, though I’m not sure how his system was different.
We’re all running on Racket 8.0, and I’m assuming all CS. (At least one of them I know was CS.) I’ve used that compiled zo trick in previous quarters, and it worked fine. I’m assuming something changed with CS, but I imagine zo files are still intended to be portable?
Is it possible that the student on CS has an M1?
In which case, they would have a different machine type because that’s an ARM processor
We’re all on CS (AFAIK), but it’s the people not on Mac OS who are seeing the error,.
I also just reproduced it on Debian.
For reliably distributing compiled files you need to use machine-independent zo file
Cool, how can I get one of those?
From a bit of docs reading, sounds like zos generated from BC are machine-independent. So is the solution to just compile them from a BC install?
no, zo’s generated on BC are machine-indepenent for BC, they won’t work on CS
you need to use the -M flag to racket
When generating the zos, or when running a program that requires them?
Thank!!
I think you want to do something like racket -M -l raco -- make foo.rkt
Gotcha. Yeah, it doesn’t look like raco make supports that switch directly. Could be nice.
yes I think that would be a good addition, but I’m not 100% confident yet that what I suggested works
Trying it now.
It’s taking a while to compile.
The resulting zos work on mac so far, but they’re incredibly slow.
Yes they will definitely be slower, since they basically need to be compiled
Gotcha. They’re pretty fast on my debian machine, though. And I’m not sure it’s more powerful overall.
Is one of those bc?
No, all CS.
So I guess I can use these platform-independent zos as a backup, and provide the ones I had before for people on mac, and probably produce some other platform-specific ones for windows and linux. That can probably do for now.
What’s the medium/long term zo portability plan/story?
CS zos are not portable, and can’t be, and BC zos can’t run on CS.
The machine independent zo files you generated are the portability story
If they’re really slow on Mac compared to Linux that sounds like a bug
Ok, I’ll file a bug, then.
The difference is definitely noticeable.
Are these machine-independent zos here to stay, or are they just a stopgap?
I agree @popa.bogdanp, I still haven’t gone very far with macros, but Racket is by far my favorite programming language. However, in my case, I think it has much to do with strongly preferring Scheme’s aesthetic over Common Lisp, so that may not help @massung I suppose.
Having said that, the robustness of the language & ecosystem, batteries included, tail call recursion, built-in web server, Dr Racket, community, and many other things are very attractive.
It’s nice to know there is even more awaiting with macros :)
I can’t overemphasize the responsiveness of the core team, and the quality of the implementation. Other lisps I’ve looked into just seemed to suffer from a lot of bit rot in the ecosystem.
Using racket -M -l- raco make in your normal distribution is not a good idea.
Did the result load slowly on the machine where you used racket -M and quickly elsewhere?
Machine-independent .zos are here to stay, but there should be better tool support, possibly via raco cross.
It did load slowly locally, and everything else got slow afterwards. Running a regular raco make on a random file brought things back to normal.
Something like raco cross sounds like a good idea. In the meantime, would you recommend I keep a separate install for this kind of cross-compilation?
Or instead of a separate tool, would a flag for raco make make sense? That was the first place I looked.
A flag for make is tricky, because the problem is knowing where to stop when looking at dependencies. Adding to the new raco cross (which is implemented in the raco-cross package) is relatively straightforward.
Right, I see the issue. And that explains the behavior I was seeing; sounds like the whole tree was being recompiled machine-independent.
Thanks!
Yes, exactly.
I’ve added --target any support to raco cross, so the updated package will be available after as the package server notices.
Fantastic! Thanks!
@mflatt #lang racket
(struct test (a))
(define tbl (make-hasheq))
(hash-set! tbl (test 1) 42)
(hash-set! tbl (test 2) 1024)
(for ([(k v) (in-mutable-hash tbl)])
(eprintf "k ~v v ~v ~n" k v)) I understand the iteration order of hash tables is not specified, but it seems the result of the program above with BC is consistent and yet the one with CS is relatively random
Yes, unfortunately (or fortunately) this is one consequence of the CS implementation
More repairs today, so hopefully tomorrow.