@cong has joined the channel
Is there a command line to invoke a submodule? Something like racket --submod hello a.rkt
, then the submodule hello
will be run.
Something like racket -e "(require (submod my-mod my-submod))"
maybe? (not tested)
@jeffmkungusi has joined the channel
Ah, thanks! That will work for now, though I do hope there’s a dedicate option to do this.
yeah, I wish there was one too. I really like the submodule system, but I think it’s underused currently. For example, I often use a drracket
submodule and configure DrRacket to run this module too, but not the main
submodule. That way I can have plots and pictures in DrRacket and only text on the command line.
Anyone tried to build an APL-like #lang in Racket?
Justin Slepak is working on an APL-like language called Remora. There’s an implementation of a prototype version (IIUC) as a Racket language: https://github.com/jrslepak/Remora/tree/master/remora. Since then I think Justin has been mainly working on a type system for Remora, and I don’t know if there’s a Racket implementation of that.
Regarding this error: instantiate-linklet: mismatch;
reference to a variable that is not exported;
possibly, bytecode file needs re-compile because dependencies changed
Is it possible to automatically recompile what needs to recompile without me needing to do it myself?
today’s XKCD https://xkcd.com/2295/ reminded me of https://github.com/racket/math/issues/35. Kind of cool.
usually what I do with this is raco setup
to check eveything
it’s not always easy to figure out exactly which files are outdated
@deactivateduser60718 you can run raco make
on your application’s entry point. It’ll only compile the things that have changed.
But that’s the thing: When my workflow spans several packages, the ongoing need to run raco make\|setup
commands becomes an interruption. I was just wondering if there was a way to avoid it entirely.
If raco setup
alone checks everything, that’s easier to automate myself
If there are dependencies between the projects, then raco make
will also compile those, I believe.
That’s good to know.
if there are no bytecodes at all (i.e. all compiled/
are deleted), everything should be compiled from source whenever you run the programs
But yes, I agree with you that it would be nice if racket itself just recompiled outdated things instead of failing w/ a linklet error.
In koyo applications, the runner automatically runs raco make
on the entrypoint whenever a file changes:
https://github.com/Bogdanp/koyo/blob/master/koyo-lib/koyo/runner.rkt#L126
@shu—hung Yeah, I used to handle things that way. It was still a manual step of going to the affected directory and running rm
This works out pretty well for web development, although the compilation times can start to add up once an app grows to a certain point.
the thing is that built-in dependency checker has issues getting the right dependency
code with modified dependency should’ve just been loaded from source. the problem is with the broken dependency checker
@deactivateduser60718 Racket won’t automatically create .zo
files unless instructed explicitly via raco make
or raco setup
@shu—hung Does this entail defaulting to raco setup -n
after blowing away compiled
directories in packages I’m working on?
@popa.bogdanp I like that example, thank you.
I mean if compiled
s are blown away, they won’t come back until you run raco setup
or raco make
again
so if the time it takes to compile everything is acceptable, there’s nothing to be done after removing compiled
s
Okay, that works. I thought a JIT compiler would eventually create them again.
What’s in compiled
are bytecode files. Mainly they save work doing expand
. In many projects, expansion of the project of itself isn’t any big deal. You can live without compiled
.
The JIT is separate, and happens whether or not there’s any bytecode. The JIT is making native machine code.
^ Well for classic Racket a.k.a. “BC”, at least.
TL;DR you can avoid raco make or raco setup on many new/small projects unless/until you feel like things are slow to start.
Which generally only happens if you get many require
s, and there is some non-trivial syntax (macros) happening. Then fully-expanding code can become slow.
You can use http://rmculpepper.github.io/custom-load/custom-load.html which makes the problem go away
There are definitely reasons that isn’t the default behavior but I don’t remember what they are.
I isolated something that’s been confusing me.
#lang racket/base ; minimal.rkt
(provide (except-out (all-from-out racket/base)
#%module-begin)
(rename-out [-#%module-begin #%module-begin]))
(require (for-syntax racket/base))
(define-syntax-rule (-#%module-begin body ...)
(#%module-begin (provide data)
(define data (box #f))
body ...))
; In another file
(module blah "minimal.rkt"
(set-box! data 1)
(displayln (unbox data)))
(require 'blah)
Racket complains that data
is undefined in the blah
submodule. Why? How can I do what I mean here, which is to write modules with surrounding boilerplate written for me?
I’m guessing that the lexical info. in the example file causes Racket to look at a different scope. I understand that much, but not how to adjust that. I’ve been able to introduce boilerplate at read time, but I’ve been cautioned against building code before an expand pass. Not sure how to reconcile the advice.
This is really just macro hygiene. module-begin works like any other macro, and so the definition of blah is invisible to the use of blah.
Does this mean that my only option is eval and namespace magic?
I can keep injecting code during a read pass, but that’s all I can think would function besides.
Answered my own question. Yes, if my code is not hygenic, then it can’t use macros anyway. :man-shrugging:
No, you just have to write a non hygenic macro
But better would be to provide blah from minimal.rkt
Ah, sorry. I thought Racket mandated hygenic macros. Thanks much.
Or, I should say I didn’t know there was another way. There’s been a lot of trial-and-error here. :smile: