I want to make define* which is just like define except that it has some static information that I can later extract. I think this is what I want:

(define-syntax-parser define* [(_ x:id e:expr) #:with tmp (generate-temporary 'tmp) #`(begin (define tmp e) (define-syntax x #,(make-define*-info #'tmp)))]) where define*-info is a struct that holds static information and has prop:set!-transformer . But this doesn’t really work. It looks like the macroexpander says tmp is unbound. What’s a way to fix this?

Well, it’s also possible to just define total and staticmethod /sta1 at the top level directly, which means we won’t need that set! . My disappointment is that static method as a function clutters the namespace and it is not “packaged” along with the class value.

@sorawee that’s exactly what you should do so I’m not sure what the problem is

the problem is you need to remove the #,

in general Racket doesn’t use values for namespacing other values

Ahhhh! I forgot that define-syntax shifts phase already, and I don’t need to unquote to access make-define*-info at phase 1. Thanks! :slightly_smiling_face:

Oh! I think I finally figured out what was going wrong. It was restoring the wrong vm snapshot! So I think all I have to do is delete all the snapshots I currently have (all named init), and then make a new snapshot to be called init

Nope, still running into problems. Last night I could ssh into it manually, now I can’t anymore

Use case being: Small implementation for a core API, with other collections in the package offering useful recipes with added dependencies.

Just switched rooms from my bedroom to .@gknauth’s wfh office (that’s what I did last night to “fix” ssh-ing manually) and now I can ssh manually again. I do not understand why

anyway restarting run.rkt again now

I don’t think that’s accurate. For example, the typed-racket-lib package has multiple collections

Right, but the name ending in -lib is another package, not a collection, right?

I’m thinking of a directory structure like this, where users get lib1 by default but can specify that they also want lib2 by the time they run raco pkg install package/ collection-lib1 collection-lib2 collection-docs collection-tests

If I’m understanding your message right, the solution is to create another package.

I’m confused about what you are asking.

there are two very separate considerations.

1. What collections should things be in.
2. What packages should things be in.

Let me see if I can phrase it better.

Say I only want to publish one package.

One collection in that package has a core API

Another has a bunch of dependencies and recipes, but also contains implementation code

@alexknauth Thanks for the reminder to try your build setup while at work on my personal MBP. Anyway, when you’re in the other room, not my wfh office, I wonder which wifi you’re on. One ends with a 2 (it’s 2.4GHz), the one that doesn’t is 5GHz. I don’t think that’s it, because even though Ubuntu typically only does 2.4GHz, its connectivity is through your MBP, which handles both. Anyway, I’ll try the setup at work and on my MBP and see what happens.

How would a user install the package to get the core API by default, ~but~ versus opt-in to the extras?

looks like your example is a bunch of packages with names containing “collection,” which is kind of confusing

The way to do that is to publish two packages

Such as “foo” and “foo-extra”

and they might both use the foo collection

in this kind of setup, there’s often a foo package that implies the foo-lib and foo-doc packages, so the user can install foo to get the other two packages installed automatically

and if the user wants they can also install foo-test explicitly, but that isn’t something many users would need unless they’re developing the library

even the foo-test package could contain modules that are in the same collections as the other packages. The collection doesn’t need to be named anything like “foo” except that it might become a little more confusing for people who want to look up what package they need to install to get their require to work

> looks like your example is a bunch of packages with names containing “collection,” which is kind of confusing I’m going off of this: https://docs.racket-lang.org/pkg/Package_Concepts.html?q=multi-collection#%28tech._multi._collection._package%29

> The way to do that is to publish two packages I figured. Was hoping that wasn’t the case.

Why is that a problem?

I wanted to avoid polluting the package index with a bunch of similar names.

Well, still do

There have been a couple of times where I wanted a package to be a “one-stop shop” for all code related to a topic to keep things organized from a high-level. I’m just trying to find ways to do that.

I finally got through the ssh stage, but then it failed with what appears to be a, paren error? VM "racket-pkg-build" has been successfully started. /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'echo hello' hello >> Fixing time at racket-pkg-build /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'sudo date --set="Thu, 19 Dec 2019 12:09:07 -0500"' Thu Dec 19 12:09:07 EST 2019 >> Preparing directory /home/racket/build-pkgs /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'rm -rf "/home/racket/build-pkgs"/*' /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'mkdir -p "/home/racket/build-pkgs"' /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'mkdir -p "/home/racket/build-pkgs/user"' /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'mkdir -p "/home/racket/build-pkgs/built"' /usr/bin/scp /Users/Alex/racket-pkg-build/installer/racket-7.5.0.13-x86_64-macosx.dmg racket@192.168.56.103:/home/racket/build-pkgs racket-7.5.0.13-x86_64-macosx.dmg 100% 117MB 61.4MB/s 00:01 /usr/bin/ssh -R 18333:localhost:18333 racket@192.168.56.103 '/usr/bin/env' 'PLTUSERHOME=/home/racket/build-pkgs/user' 'PLT_PKG_BUILD_SERVICE=1' 'CI=true' 'PLTSTDERR=debug@pkg error' 'PLT_INFO_ALLOW_VARS=;PLT_PKG_BUILD_SERVICE' '/bin/sh' '-c' 'cd "/home/racket/build-pkgs" && sh "racket-7.5.0.13-x86_64-macosx.dmg" --in-place --dest ./racket' racket-7.5.0.13-x86_64-macosx.dmg: 1: racket-7.5.0.13-x86_64-macosx.dmg: Syntax error: "(" unexpected ssh: failed context...: /Users/Alex/Library/Racket/snapshot-7.5.0.13--2019-12-16/pkgs/pkg-build/main.rkt:452:5 /Users/Alex/Library/Racket/snapshot-7.5.0.13--2019-12-16/pkgs/pkg-build/main.rkt:445:2: install /Users/Alex/Library/Racket/snapshot-7.5.0.13--2019-12-16/pkgs/pkg-build/main.rkt:515:2: check-and-install /Users/Alex/Library/Racket/snapshot-7.5.0.13--2019-12-16/pkgs/pkg-build/main.rkt:123:0: build-pkgs "/Users/Alex/racket-pkg-build/run.rkt": [running body] temp35_0 for-loop run-module-instance! perform-require! Stopping VirtualBox machine "racket-pkg-build"

Are there any guides/examples to making a plugin system in Racket? I know Dr.Racket has a signature/unit based system, though my application’s plugins will define their own behaviors - sort of flipping the notion of a plugin system on its head, so this may not be sufficient.

@alexknauth racket-7.5.0.13-x86_64-macosx.dmg doesn’t look right to me

Oh good point. Why is it using the mac installer when ssh-ing into the linux vm?

can you post the content of your table.rtkd

Quickscript has/is a simpler plugin system (for DrRacket) based on the more complex plugin system of DrRacket. Most relevant code portion: https://github.com/Metaxal/quickscript/blob/master/tool.rkt#L142

Some background - I’m set on making a framework for implementing irc bots/interactive clients. The more consideration I did, the clearer it seemed to do well to make each component (user/channel tracking, chat commands, even the irc client) pluggable. This way it becomes easy to enable/disable features at runtime and replace certain components [especially commands]. I envision the entire system will be publish/subscribe, actor, or message bus based.

It’s just #hash(("localhost" . "racket-7.5.0.13-x86_64-macosx.dmg")).

The web-server collection uses signatures and units to allow customization of either servers or the configuration of default implementations. I wouldn’t call it a plugin system, but it does show how each component can be overridden.

https://docs.racket-lang.org/web-server-internal/Web_Servers.html

I see. I probably know what is the problem ..

Thanks, It’s good to see these patterns used in several different collections

Does @ben run the whole process of pkg-build on a linux machine?

It’s super easy to make up mini-protocols as you go.

That’s a mixed blessing.

My wild guess is you have to build a racket installer on a linux machine (via make installers) I forgot to mention that in my comment…

I’m sort of wary of that, with an side-goal of making it very clear upon loading if a plugin using other plugins correctly; originally I was going to implement it in TR, only allowing racket for the actual plugin implementations, but it appears signatures/units and dynamic-rerequire don’t have the best TR support. So I think I may have to accept some “loosey goosey” interfaces

Now I remember why I have two virtualbox vms …

an easier goal might be to add a good amount of fault tolerance, executing each plugin method/implementation with handling exceptions and otherwise handling a bad plugin’s instantiation gracefully

@alexknauth I have changed my comment accordingly

@alexknauth if you run start the pkg server on the machine where you create the installer, make sure that server is accessible from the pkg build vm

I could also run make installers and make site-from-installers on the vm, then copy the folder over to the host to run the server, right?

Yes.

If typed racket is asked to load code from a potentially untyped source during runtime you’re already past the point where you can ask for type safety anyway (If I’m understanding your message). I’d probably use is-a? to check if an object implements an interface, but that’s only because I don’t know of a better alternative.

Just in case, another kind of safety can be obtained through racket/sandbox for plugin systems

wow, annoying.

I’ve been running everything on Linux.

The other day I finished a full build, but the process got stopped & restarted mid-way many times due to ssh errors. I’m trying again now with a 3x longer #:timeout and with 10 #:tries in the call to make-sure-remote-is-ready and so far (overnight) there are no errors

This is a simple example of a DrRacket plugin/tool created by Robby

https://github.com/spdegabrielle/robby-tool-demo\|https://github.com/spdegabrielle/robby-tool-demo

@alexknauth BTW, in theory, you could run macOS on a virtualbox vm to build pkgs, but I haven’t done that before and I have only used VMWare to virtualize macOS.

@alexknauth Where are the instructions you wanted me to follow?

Yep, if plugins were in vanilla racket, and the plugin-based application was in TR, i’d lose some type safetly, but I’d still have an application in TR that should eliminate most classes of bugs I run into ;)

It’s finally running!

is there any built in hash function?

string hash

You might want equal-hash-code

yep, that one works. thanks!

I’ve wanted that too