thx. changing (send (new (my-plain-mixin object%)) test) to (send (new (my-plain-mixin (class object% (super-new)))) test) makes the second part work.

For the first part, if all init’s or init-fields are optional and I don’t use them during instantiation, this works too. But that’s not really what I wanted to achieve :confused: None of the tests in sealing-contract actually try to instantiate an object. Making the classes works fine for me too.

You may get more helpful responses if you ask a more specific question.

For testing, get-pure-port can use the file protocol for url, which avoids network queries

@joshuahoeflich2021 You could use git-checkout from net/git-checkout. https://docs.racket-lang.org/net/git-checkout.html

It’s implemented in Racket, which means it works on all platforms whether or not git is installed.

Woah! Talk about batteries included, thank you

The honor goes to Flatt, I believe.

Another problem is that the deserialized expansion seems to be missing some things related to imports.

I think we can probably view most of these as bugs to be fixed but perhaps starting an issue where we might discuss them is a good move?

My little example program showing both problems.

OK that makes sense!

Should I make an issue on your repo https://github.com/rfindler/fully-expanded-store ?

SUre!

I was thinking Racket but perhaps my repo is better.

Will do. I suspect someone with the initials M.F. might need to be invited at some point in the discussion. :slightly_smiling_face:

But I’ll start with an issue on your repo.

MRF :wink:

MF might be herr doktor felleisen

I’m preparing my first Racket package for a release. :slightly_smiling_face: If you like, please have a look at https://git.sr.ht/~sschwarzer/todoreport-racket/tree and give me feedback. (By the way, I applied a lot of the review feedback you gave me earlier, thanks again!)

Is the README ok or do you miss anything? Note that the package installation as mentioned in the README won’t work yet, as the package doesn’t exist yet and the tag hasn’t been created either.

I read that libraries and tools should be split into different packages, but first I’d like to publish everything in one package and possibly split it later. Besides, I’m still thinking about creating a file that collects the whole user-public API, although I think changes should still be fine as long as I’m below version 1.0.

Well, most packages have doc written in Scribble

And when you upload it to the package server, the doc will automatically be hosted at https://docs.racket-lang.org/

@sorawee Ah, right. I haven’t used Scribble yet, but yes, that documentation would be nice to have. Do you think it’s ok to publish the package initially without Scribble docs?

That’s totally fine! Many packages are like that.

As it’s my first Racket package and I’m using Racket only in my free time so far, I thought it would be good to publish an “ok” package first instead of raising the bar too high and release nothing.

To create a proper package, you also need info.rkt, I think.

If I remember correctly, I read that’s only needed if you install in multiple collections.

But then, yes, there’s some information in there that would be good to have, so I’ll add the info.rkt.

Really? I thought you need it for the deps information (which should at least contain base — and possibly more like rackunit-lib) and if you don’t have it, the package server will complain when it builds your package

I wonder if raco setup --fix-pkg-deps creates the info.rkt file

@sorawee Yes, I’m already on the info.rkt :slightly_smiling_face:

Added and pushed it.

Just to drop two quick tips

• raco pkg new <your-package-name> will generate a starting template for your package, including Scribble doc and info.rkt.
• raco setup --fix-pkg-deps --pkgs <your-package-name> that @laurent.orseau mentioned is a really nice command. It will add entries to deps in info.rkt automatically for you.

I actually had generated the original info.rkt with raco pkg new. :slightly_smiling_face:

Could it be that raco setup --fix-pkg-deps only works if the package is already installed? I get a stacktrace starting with pkd->collections: package not found

yep, that’s correct

Is it common to have a new collection for a package in info.rkt? Otherwise I’d had some trouble to find an existing collection for the package.

Ok, I installed the package with raco pkg install ../todoreport locally and ran raco setup --fix-pkg-deps todoreport and don’t see anything suspicious in the output.

Oh, I forgot to read the later sections of https://docs.racket-lang.org/pkg/index.html . I’ll need to read this and then modify the package to install todoreport as a binary. Maybe I need to change other stuff as well.

I’m sorry, I’m not very familiar with the workings of the Garbage Collector, but I’m curious: is there a way to tell the GC, “Hey, this object can probably be collected.”? In particular, with the intent of encouraging more deterministic cleanups.

I am not familiar with any API to mark an object ready for collection, but using (collect-garbage 'incremental) might help with reducing the impact of the GC in a timing sensitive application.

@kellysmith12.21 if you can refer to the object then it can’t be collected, presumably. So I feel like I’m misunderstanding something.

I’m considering the hypothetical situation where I’m using an object linearly/uniquely. This means that I can tell the exact point at which the object is no longer reachable.

I can build a type system to track linear/unique objects, but without a way to inform the GC about this, there’s not as much benefit to such a type system.

If this is in your own language, then you could allocate a linearly typed object using the ffi library’s malloc to allocate memory outside of the garbage-collected heap, and you could insert calls to free where the object becomes unreachable.

I’ll have to look into that.