How about defining a small library that exports pfirst and friends (p for pair), or unsafe-first (but I suspect that those using caddr don’t really like long names)?

Or simply disable car -> first as default, but allow the user of resyntax to enable the rule explicitly.

(perhaps even bundling such rules into a group of rules)

or (define first car) :grin:

Is car faster than first on CS?

(Not relevant to this discussion - but I just thought about it)

Not if it can prove that the value is a list, because in that case, they both turn into unsafe-car

Good point.

Theoretically, list? and pair? take both constant time, but the constant for list? could be much larger than that of pair?

So when it cannot prove, car is going to be faster than first.

*amortized constant time, and there are caveats

What’s unclear to me is how to help the compiler prove that it’s a list. I think the docs are talking about ‘contracts’, but are these the usual contracts like list?

https://www.youtube.com/watch?t=2619&v=mWnlXVEXnPc

Could we have a raco pkg init that populates the current directory with missing files that raco pkg new would produce? That would be pretty helpful, in particular for scribblings, info.rkt, and possibly licenses within a git’ed directory

oh woah, that’s pretty neat.

thanks for the link!

Thank you! That’s what I was looking for. But I can’t see in the Racket library a way to compute an EC point given my self-chosen x. It looks like I will have to do enough EC-arithmetic just to get the point (formatted as a byte-string) and then use datum->pk-key to internalize my desired private key.

If that’s so, then it might be easier for me to compute my desired points “manually, outside Racket” and then encoding them in Racket for my tests. After all, in practice my private keys will all be random and generated by generate-private-key.

I made a silly typo above, racket-indent-line.

@capfredf (put 'lambda 'racket-indent-function 'defun) improves the ident. But please see issue/examples here and let me know: https://github.com/greghendershott/racket-mode/issues/516

I’ve pushed an update so that you can pass #f as the public key component (q) in the call to (datum->pk-key ... 'rkt-private), and the library will recompute the public key from the private key.

Yes, a big thank you to @mflatt - my business is growing increasingly dependent on Racket, so I’m super appreciative of the efforts of both the core team & other contributors. I’m particularly excited about this move to Chez Scheme.

that command should update things

Here’s what I get: %raco pkg update crypto-lib Resolving "crypto-lib" via <https://download.racket-lang.org/releases/7.9/catalog/> Resolving "crypto-lib" via <https://pkgs.racket-lang.org> No updates available

oh, you might have to wait a bit for http://pkgs.racket-lang.org\|pkgs.racket-lang.org to update

Ryan’s message was about an hour ago. Wait longer?

yes, it updates hourly

Alright. Thank you so much for the info. I’ll wait another hour and see.

FWIW, I believe <https://rosettacode.org/wiki/Elliptic_curve_arithmetic#Racket|Rosettacode’s implementation of Elliptic Curve arithmetic> is not quite implemented for point-at-infinity, which seems to be #(0 0). As far as I have tested, the functions work sanely, except for the point at infinity. For instance, multiplication by scalar 0 makes sense ec.rkt> (ec-multiply P 0) '#(0 0) But addition with #(0 0) does not (to me). (Notice both coordinates are fractions.) ec.rkt> (ec-add P #(0 0)) '#(-19608639242699606135035935541852486703407937470111803408613885186901166720384842420481528766437496914350122211742134183098304183548226789634417837720076398230709075238594646456013191947973815182146787680849464367083577414741613024/288574738055216223511846330867668901534996169990110856327626877594963041162079187926900882491382398044239944236075118807774306362818571474414783526725025 96392211076664757152428343540135013798908952331067443582372615908239384546197227002959747073571759678671526233095410998893687600344808776264446392816262578030880566251868806104343928251995804540461485930277164196196269340817931546567134274597606047577052503484938878080505941351646279854360654312704108224/4902159810674901533758983885463121675851984367527950852153471296725291680096216646400599783611410166475185787142623281002368701797056396265525709120210257592799243416413983563346523162701567751755575187402582812364695150865968625)

This produces fractional-coordinates too, which looks weird, but maybe it’s correct and we’re just missing a canonical representation there. Anyway, just sharing these observations. ec.rkt> (ec-multiply P 2) '#(749478414992729926226488388925371130764225526382236367156756584967191973065592223523628192511862173424755992838279417975102304762907824743176803783885411058331965963894542146664668190834114077683290398663035368923668259207080182120529318419771329903973813135904818067153625552186007415416667745729961840385/6041280217592002035937887655234207089735227792655909999698856921249690191158035121974606765321949343225175708113956218878267190216720593800797180565369 -648841611853697034135333333774063928451984862035661263764353906907737345263298356199390726524838679657971567703528269958697927638769816188004861297970569480580240539598378296802283067404976037805564530442049150194457144729679228517291618814085659477961490298000626298517450124417201920263184348187544192367918474185445731513906552507615493948320857947270885205462444754840952211262476472130040683272655889912310060928576353383198268607908263852810518575681663/14848872241968873096735263162857208332522991282391328878557533960688744127686189232138223611447610914699840674602359117081943992492789817378971777332928396883846500778938469473505427312791956678353168647569629557103986985803597) Even though there is some sanity in the code: ec.rkt> (equal? (neg (ec-multiply P 3)) (ec-multiply P -3)) #t

it appears to now be up to date

I see the <https://pkgs.racket-lang.org/package/crypto-lib|checksum has updated on the catalog>, but I still don’t see the updates: %raco pkg update crypto-lib Resolving "crypto-lib" via <https://download.racket-lang.org/releases/7.9/catalog/> Resolving "crypto-lib" via <https://pkgs.racket-lang.org> No updates available %raco pkg show \| *grep crypto-lib crypto-lib 1a91d0136f5a8f6b3458fb80aa... catalog...git?path=crypto-lib %

For the record, now it has updated. I don’t understand it, but the problem is gone. Thank you all! %raco pkg update crypto-lib Resolving "crypto-lib" via <https://download.racket-lang.org/releases/7.9/catalog/> Resolving "crypto-lib" via <https://pkgs.racket-lang.org> Updating: crypto-lib Downloading repository <https://github.com/rmculpepper/crypto.git?path=crypto-lib> The following uninstalled packages are listed as dependencies of crypto-lib: base64-lib Would you like to install these dependencies? [Y/n/a/c/?] a [...]

I’ve run in to a weird situation where using the ffi to call into some assembly code that makes an indirect call to a function results in an infinite loop on Linux, while it seems to work fine on Mac. I can’t tell if there’s something wrong with the assembly or the ffi… I wonder if anyone can spot the problem. Also, if instead of going through the ffi, I just generate a static executable, everything works. :shrug: https://gist.github.com/dvanhorn/670b8ea1a2346ea3675897accd99b85c

I think variables should be relative to got instead of plt for ELF. Also, it appears that an extra indirection is needed — but that one I worked out more by trial and error than understanding/remembering anything.

I see the same looping behavior changing plt to got. The call relative to plt also works (with fewer indirections) if I try to call f instead of ptr_to_f. dvanhorn@starburst:small $ cat try.s global main default rel section .text extern f main: sub rsp, 8 lea rax, [rel f wrt ..plt] call rax add rsp, 8 ret dvanhorn@starburst:small $ nasm -f elf64 try.s -o try.o dvanhorn@starburst:small $ gcc -shared -fPIC f.c try.o -o f.so dvanhorn@starburst:small $ racket ffi-f.rkt 42

(btw, writing (or trying to write) a toy compiler for x64 that works for both macho and elf has given me a new appreciation for the work that has gone into racket “just working” basically everywhere.)

I’ve just read https://blog.racket-lang.org/2021/01/racket-status.html and I have a question about the compilation. In the post, Matthew says: > the CS compilation strategy (ahead-of-time) differs from the BC strategy (bytecode compilation plus a JIT) Does that mean that Racket CS will be compiled ahead of time? How will CS impact running Racket from an interpreter?

Did you already try switching to got and also adding an indirection (i.e., mov rax, [rax] before call [rax])?

Both BC and CS compile on the fly when you load or evaluate code from source. But when you make a “.zo” file with raco make and similar tools, the “.zo” file contains machine code for CS. The file contains bytecode for BC, which further compiles the bytecode to machine code on demand (i.e, using a JIT compiler).

Thank you for answering! I’d like to clarify a few more things, if I may: 1. As far as I understand, running the code interpreted removes the compilation step, but produces some overhead each time the code is called. Does ahead-of-time compilation make the code itself run faster on BC? I was under the impression that there was a speedup. 2. Is this different for CS, now that there is no bytecode to machine code step?

I… thought I did, but apparently not. Yes, this solves it. THANK YOU. I don’t understand, but this works.

CS runs code faster because it generates better machine code overall. You’re right that the JIT in BC adds some extra overhead to compile just in time, but that turns out to be very small, and it only happens the first time a function is used. Then again, one of the reasons that CS generates better code is that it doesn’t have to be so fast in the last compiler step to generate machine code, since it’s not happening just-in-time.

So the main improvement is mostly maintainability, right? End users won’t feel much change and won’t need to change the way they write and run Racket code, will they?

Yes, that’s right.

Cool, thank you!

trying to link to a dll but i dont know why this doesnt work.. the file exists and the path is correct.. (define raylib-dll-path (build-path (current-directory) "raylib")) (define-ffi-definer drl (ffi-lib raylib-dll-path)) ffi-lib: could not load foreign library path: D:\racket-raylib-2d\raylib.dll system error: The specified module could not be found.; win_err=126 the reason isnt related to the file being on D drive either

Just an idea: check 32 vs 64 bit

(could be something completely different though)