@kellysmith12.21 Maybe I am missing something, but if you have (define foo <large-object>) and at some later point, know that <large-object> is no longer needed, you can simply do (set! foo #f) which removes the reference to <large-object>. If you want it garbage collected right now then you can call (collect-garbage) This of course is under the assumption, that foo is the only reference to <large-object>.
If you are in a situation, where some large object is nice to have around, but only if there is enough memory, you can look at “weak boxes”.
Check the “Show HN: Invoicer” story on Hacker News. Dexter Lagan is showing an invoice billing app made in Racket.
Hi, guys. I have a question about racket’s package version reference. As I have read from the chapter of Package Sources https://docs.racket-lang.org/pkg/Package_Concepts.html#%28part._concept~3asource%29\|https://docs.racket-lang.org/pkg/Package_Concepts.html#%28part._concept~3asource%29 , my understanding is that racket is mainly using git’s commit references and tags to refer difference release of packages. And from header description of Package Concepts https://docs.racket-lang.org/pkg/Package_Concepts.html\|https://docs.racket-lang.org/pkg/Package_Concepts.html , it says a version defined in the info.rkt file is intended to reflect available features of a package. But as I read the doc further, in the chapter of Package Metadata https://docs.racket-lang.org/pkg/metadata.html\|https://docs.racket-lang.org/pkg/metadata.html , it seems I can also define deps as a list in the info.rkt file_,_ and each element of this list is a form of (list package-source-string keyword-and-spec ...), and there is another keyword '#:version for each element. My question is, what is this version used for?
~I think it’s for the version-exception field when you submit a package on http://pkgs.racket-lang.org\|pkgs.racket-lang.org~
@laurent.orseau Oh, you mean this version is only used for specify the racket version? en…that could make sense… but the doc doesn’t seem to specifically say this.
the doc says this:
~Sorry, I misremembered the field name (I should have checked). I was thinking of the Add new version field when creating a package on the server. So basically when you create a package A, you can add a specific version of this package, say A1, by specifying a version name x.y.z , say 1.2.0 along with a particular tag/commit. Now when you make another package B that depends on A and you want the stable version A1 fo A, you can use the #:version "1.2.0" field in the info.rkt to target the particular version A1 of A. Again, I think.~ See Sam’s message below.
@laurent.orseau and where or how can we define this version 1.2.0 It’s not a git tag, right?
~When you create/edit a package on http://pkgs.racket-lang.org\|pkgs.racket-lang.org, at the bottom left there’s a green button Add new version~
Oh. You are saying this. Actually this is my another question, I remember I’ve tried to do this before, but somehow when I click the submit button, it returns wrong without saying more detail reason.
I’ll try this later after I got home and post the screen shot here
Makes me think, regarding stable package, for-real(TM): Say you have a package A that depends on B and C (all of these on github), plus the main distribution.
The following could be automated: • Fetch the current commit number of A, B, and C, giving versions A1, B1, C1, say. • Create a new catalog with A1, B1, and C1, at these particular commits • Create a new package which only purpose is to ‘install’ the new catalog, and then installs A1 with the correct dependencies, with fallback to the main catalog for the main distribution and other unversioned packages • (manual) Upload this package on pkgs. Ideas for refinements?
@laurent.orseau A piece of the puzzle? https://github.com/Bogdanp/racksnaps
I do this for ActivityLog2
… and even wrote a blog post about it: https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html
Racksnaps is great (I’d probably say awesome if I’d used it), but it’s pretty heavy weight. What I propose is much lighter.
I saw that post but I wasn’t ready to understand it :slightly_smiling_face: I still need to look into git submodules to get a better grasp of the implications.
Regarding the main drawback about global packages with global names, there may be a workaround: • when installing A with a commit 12ab34ef, name the collection A–12ab34ef. • Generate a deps.rkt file, specific to the project, and overrides require so that it checks for A/file1 and replaces it with A-12ab34ef/file1 I haven’t tried overriding require yet, but that seems feasible.
The fact that the project is cloned rather than linked is not ideal though. It can make the package significantly larger
and is more likely to lead to discrepancies between the local version and the upstream one. Although the fact that you can fix bugs if the upstream maintainer is unresponsive is a certain advantage.
Or, rather, using make-require-transformer to provide a versioned require transformer whose meaning is specific to the current package
No, what @laurent.orseau said is not correct
You can specify a version for a package in the info.rkt file.
Then if another package needs that version of your package, they can use the #:version specification
Okay, what’s today for the turtle logo? Is it the birthday of Logo/Turtle graphics?
And the package system will ensure that when installing the other package, they get a sufficiently new version of your package
Honu!
I don’t see how using racksnaps is heavyweight
Well, the main aim of my proposed method is to put the application author in control over the versions of the modules used by the application, so of course there will be discrepancies — this is the purpose of it. Also, you can always run a “git submodule foreach git pull” to update to the latest packages in one go, or to update individual packages as needed.
Racksnap itself is heavy weight, and won’t scale up if suddenly the community gets bigger and the number of packages explodes. Not my problem though :smile: It’s just that I find the code duplication not very DRY
Then I’m confused. What’s the use of “Add new version” then?
What code is duplicated?
with regards to the “global” scope, I have a few ideas on how to solve it, but so far it did not create major problems for me. After all, so far, everyone who runs “raco pkg install” will get their packages in a global scope and these packages will be available to all Racket applications for that user.
That’s for version exceptions
… things might be different with xiden, but I didn’t look into too much detail on that.
I think Racksnap keeps multiple full snapshots of all packages, no?
There’s some redundant storage, I agree — I just wouldn’t call that code duplication
Oh wow, that’s very unclear! Could we have at least a <https://docs.racket-lang.org/pkg/getting-started.html#%28part..Version.Exceptions%29|link to the docs> next to the button?
And I think that if the number of packages grew a lot, then eliminating redundant storage would be worthwhile but not that hard
Today is Prince Kuhio Day
It’s just the philosophy of redundancy that doesn’t click for me
Packages in Racksnaps use a content-addressing scheme for de-duplication so most packages don’t actually change on disk between daily snapshots, unless their contents (or the version of Racket used to build them) have changed.
ah ok
Macros without parentheses! IIRC
That’s named for Honu (the Hawaiian word for turtle). Robby’s family is from Hawai’i which is where the Honu thing comes from.
green sea turtle :slightly_smiling_face:
I know, and that’s pretty cool, and I find Racksnap remarkable still :slightly_smiling_face: I just feel we should be able to do better.
Storing all the packages seems pretty fundamental to the problem
@samth I’m struggling to find the docs about how to use the version field in info.rkt
In principle you only need the repository url and the commit/date you’re looking for.
That assumes that the repository stays available and keeps its history with the same hashes though
yes
But the pkgd server also assumes this already
No, it doesn’t, it just assumes that the current entry for the package is available
Thanks! I always struggle to find this page :confused: > A _version-string_ specifies a lower bound on an acceptable https://docs.racket-lang.org/pkg/Package_Concepts.html#%28tech._version%29\|version of the needed package. Ha, so this assumes the package remains backward-compatible (which I’m not ready to assume, apart from the main distribution)
For example, I can change the repository I use, or force-push, and break things if you just kept the old info
There’s a commit field, so it does assume this I guess
Right, that’s a fundamental assumption and discussed in the docs
You can specify a commit if you want, in which case that particular commit has to remain in order for the package to work
@samth so it means, if I have a package named A and its info.rkt has defined version to 0.1, and then I create another package named B and its info.rkt has a deps list includes an element of A with version 0.1. At this time, if I run raco pkg install for package B, it will automatically install package A with version 0.1, is this correct?
Package A with version at least 0.1, so that if package A releases version 0.2, you’ll get that
Oh, I see. So this means the http://pkg.racket-lang.org\|pkg.racket-lang.org website must have recorded the status of every package’s info.rkt after its each updating.
Yes, that’s right
And I just realized that, previously, as my reading the chapter of the package management doc https://docs.racket-lang.org/pkg/metadata.html\|https://docs.racket-lang.org/pkg/metadata.html, I incorrectly have the feeling and impression that the version defined in the info.rkt is only used for some kind of announcement, that probably because of this line of doc: A version is intended to reflect available features of a package, and should not be confused with different releases of a package as indicated by the checksum. But actually the version in the info.rkt is pretty useful. How do you guys think if we improve this and add an explaination that http://pkg.racket-lang.org\|pkg.racket-lang.org will record the updating of info.rkt to make it more understandable?
Racketfest 2021 is just a few hours away! About 70 people signed up.
the Gather space is open, but our capacity reservation only kicks in at 19:30 CET (2.5 hours from now), so the performance might be suboptimal till then
Will you record the discussions as well?
those won’t be recorded, I’m afraid
if someone were to just hang out in the auditorium and screen grab the whole event, that would suffice!
Live blog!
I think, not recording is a good thing. It makes an incentive to participate in the event.
+1
maybe gitter?
OTOH, the Q&A will be by video (though there will be a text-based fallback not unlike what was done at RacketCon),
@yoeskastyle has joined the channel