@samth on yesterdays discussion of dynamic require… it takes the 20secs:

Timing - Dynamically requiring arch-info: real: 19356 ms, process: 19286 ms, gc: 4182 ms

Then you suggested raco make so:

raco make archs/riscv/arch-info.rkt

and…

Timing - Dynamically requiring arch-info: real: 99 ms, process: 98 ms, gc: 24 ms

errr… :slightly_smiling_face: Thanks.

Is there a reason why dynamic-require doesn’t automatically compile the module? From the above conversation it seemed to me that was the case.

woah! from 20 sec down to 0.1 sec that’s a huge difference

@abmclin not sure. i actually hoped racket to be compiling a module before running, but that doesn’t seem to be the case. It seems an explicit raco make is necessary before hand.

Indeed, I was surprised to see that from your observations

@pocmatos I also noticed that your issues were arising from your ongoing efforts in porting Chez Scheme to RISCV, how’s that going?

Partly but not only…. I have two projects going on with regards to riscv. The one with regards to the port is going slow as I have very little knowledge of chez so I am just poking around and getting the general architectural files setup. However, I should get my linux riscv board next month or so and hope by then to be able to do native testing.

By that I meant that I am making slow progress but enough to be able to do some native testing in 4–6 weeks… fingers crossed

However, I am not really interested in Chez, the whole point is really to have Racket 7 running on the riscv once it’s released.

very nice! I’m psyched to hear that. my working knowledge of RISC-V is only from reading the manuals so it’ll be cool to see it in action

right that makes sense, Chez Scheme is just the means to an end, I’ve tried studying its source code, but like you, have found it to be a challenge. Made some progress in understanding how its incremental compilation technology works but the lack of documentation other than postings to the user mailing list is really putting a damper on it

That’s right, lack of docs is my issue as well so I just focusing on what is needed for a new arch.

If I’m recalling correctly RISC-V is broken down into the base integer instruction set and several standard extensions for multiplication, floating point operations, etc, have you already made a determination of which extensions in addition to the base would be needed to get Racket7 working?

that’s correct

the 64bit base is rv64i

for the port i am targetting rv64imafd

which includes multiplication, atomic instructions, floating point and double.

makes sense

are you currently maintaining a public repository with your work to date? Would love to see the code if you have it available

I’m also wondering if the J extension would be helpful, but guess that’s for future experimenting

since it doesn’t seem to be yet implemented

my idea was to get something working before I push the changes, which are currently in a company internal branch. I can make them public if you want to see the progress.

sure, only if it’s not too inconvenient for you

I will push them here: https://github.com/LinkiTools/ChezScheme

ok!

I will tag what I have an push to a branch, probably wip-riscv.

ok cool, am looking forward to it

yes, the J extension might be interesting but the working group was just created so it might take a while to get something stable for the port. Certainly nothing will come out of it before the racket7 release. However, I will be in the RISCV workshop in may and have more info.

ok, I’ll be also looking for the workshop’s published materials whenever they come out

I assume your RISCV board is HiFive?

yes, i got a free pass on a hifive unleashed ’cause i run the gcc buildbot, so I got it for gcc riscv continuous integration purposes.

advantages of being in the right places with right contacts :wink:

true.

well thank you for sharing information about your RISCV progress, appreciate it

no worries, I will try to get it pushed later after work. Will let you know.

Want to clean up a few nasty comments beforehand. :slightly_smiling_face:

> i actually hoped racket to be compiling a module before running, but that doesn’t seem to be the case. It seems an explicit raco make is necessary before hand.

Someone will surely correct me but IIUC the steps are ~= 1. read 2. expand 3. emit bytecode 4. JIT compile to native code

Generally the slowest step by far can be 2 (esp with many transitive requires and/or non-trivial macro expansion e.g. Typed Racket) raco make caches through step 3, in a .zo file

However in many of my projects 1–3 is negligible and I don’t even bother with raco make (either directly or indirectly as called by raco setup). But in some projects it’s significant.

I’m at NE Scala 2018, but the reason people talk to me is my Racket stickers.

Hurray! :D

@greg @pocmatos Greg is correct in general. Racket does compile before running, but does not update .zo files automatically unless you tell it to

@samth shame. So, if you never run raco make, no zos are ever created?

@pocmatos raco setup also generates zo files

you can also use this package: https://pkgs.racket-lang.org/package/custom-load

Ah… Makes sense. And then they are only updated with raco make, fair enough.

Will take a look at it…

Hum, I’m stumbling with something here. How can I unsplice a (~seq) head-pattern into the resulting syntax? If I just use the syntax-class like #'(struct maybe-super), it renders as (struct (one two)) and I’d like (struct one two).

Formulating web searches with terms like ‘unsplice’ and ‘splicing-syntax-class’ does not help x)

@jerome.martin.dev at the moment, you need to (require syntax/parse/experimental/template) and then you can write this: (template (struct (?@ . maybe-super))). I hope to merge that feature into the main implementation of syntax (#') soon.

So I’m not crazy, it’s not possible yet \o/

I tried #,@maybe-super but it doesn’t work because maybe-super is already a pattern variable.

try #,@ #'maybe-super