@lexi.lambda I think your comments on Reddit are more about the issue of how to support backwards incompatible changes, which I think is a separate issue (although one that ties into some of these). Do you disagree? But overall I think we mostly agree about the shape of things.

As for DrRacket, it’s a compromise in some ways but not in others. The way DrRacket works is that it’s fundamentally part of your program, not something separate, as you say. That means that it can’t be using some different set of packages than your program does. And thus the potential need for multiple DrRackets. But the in process aspect isn’t going away. It is admitting that you need multiple versions of things, so Racket is the OS and not DrRacket.

One other observation is that the current package system is (intentionally) more like Linux package management than like modern language-specific tools. Everyone gets the latest version (usually), there’s one global hierarchical namespace, multiple versions are handled with numbers in package names, and conflicts are resolved socially.

It depends what you want it to do — expand does indeed produce a syntax error there, but depending on what you want there might be some information you can get

@alexharsanyi your <https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html|Dependency Management> post is super helpful for managing my development machine. Are you also deploying to an external server? If so, what have you found to be the best way to do that? I suppose I could simply rsync my personal catalog to the server, but if there are other methods I should consider, I’d love to hear about them. That question goes to anyone else using the “personal catalog” approach and deploying to a server.

It might be worth setting up a small AWS EC2 server to manage a set of catalogs I suppose.

@sanchom mentioned using Docker to solve this, but I’d rather not introduce a Docker-like component into the picture if possible.

Hmm… after thinking about this for a bit more, I suppose people are using the “vendor everything” approach i.e. just embedding the personal catalog in the source tree for the app and deploying the entire huge thing.

That would easily allow each project to have it’s own specific versions of packages.

I think using a local directory and rsync is probably the easiest thing to do

It would be really handy if all Racket packages used git. If people have a problem with github in particular, there are other git services, or hosting a git repository is about as trivial as hosting a zip file.

I think the large majority do

Ah, I misread the output of raco pkg show since I saw a couple ending in .git, I assumed the others were not using git, but not so. And then I just happened to check one at random, csv-reading, and it wasn’t using git. Regardless, I suppose racksnap can handle the problem of “an update just broke my app, and I need the previous version of the package” problem.

I just looked, and 1572/1733 packages have a github source, and 47 of the others are gitlab or bitbucket

of the 114 others, 51 are packages that supply binary libraries that are part of the basic racket install, and are not likely to go anywhere

I appreciate all the comments/suggestions from everyone above. I think I have all the pieces & procedures to feel confident enough in production deployment now, so I guess @mflatt is right after all, I’m not interested in writing a package manager at the moment, just stirring up trouble :wink:

35 of the others are by neilvandyke, who hosts all his packages himself. 10 are binaries that @popa.bogdanp hosts specific versions of.

Just kidding of course, if I had contributed as much to open source over as many years as Matthew, I might be cynical on occasion when observing a lot of talk and no work. I really do have packages in the pipeline though! :slightly_smiling_face:

I’m looking forward to your web framework

Let’s start calling it a modest collection of useful packages to make developing web applications in Racket easier. The amount of built-in functionality is pretty amazing.

I agree, and the trick is to compile it together into something that’s easy to use. @popa.bogdanp has a nice post on this, and @jesse’s book as well.

I have experienced a bit of the “lisp curse” i.e. it’s pretty easy to develop a nice web app in an ad-hoc manner due to the ease of coding in Racket; however, I’m convinced that finishing the other 80% of the 80/20 is an important prereq. to wider adoption. Time will tel …

Yes, and I think the result is that everyone develops their own little set of abstractions.

Have there been any racket related papers, posters, etc at PLDI20 ?

Yes, @mflatt and Kent Dybvig had a paper on continuation marks.

Thanks. Will post on reddit

Thanks for your help @samth

I’m using drracket/check-syntax to annotate such things as unused requires, as in the first screenshot. But I can’t currently use it if the file contains an unbound identifier (or any syntax error), I have to bail out. I can show the syntax error of course, as in the second screenshot.

What I would like to do is have both annotations (where possible) for minor syntax errors (such as unbound identifiers).

Youtube link https://www.youtube.com/watch?v=zkU8WyqWO-Q&amp;feature=youtu.be&amp;t=2830

The problem is that there is not a notion of “minor syntax errors” in Racket, and there’s no expanded syntax to look at in that case.

OK. So my idea of playing around with #%top would be a dead-end? I’m OK with that. The experience will be closer to DrRacket, which is fine.

You can’t really inject #%top into people’s programs in general.

What’s needed is a more IDE-oriented expander and compiler for Racket, but it’s not that easy to turn the current expander into that.

A perhaps-easier approach is what @greg does which is expand a simplified program to get more information.

Cool, I won’t waste any time on the #%top idea.

Alternatively, keep the old program and use the results of expansion there.

I suppose injecting #%top might work in enough cases that it would actually help, even if not in general.

OK, I can try out those approaches.

In Racket Mode I’ve found it generally works well to retain old annotations in the buffer, until a check-syntax produces a no-errors result (which is one of Sam’s suggestions). Of course there is some risk they’ll be misleading, but generally not, indeed they can be useful for the user to resolve the error. (And the annotations use overlays and/or Emacs markers, so the positions tend to update correctly in the face of edits.)

I also retain completion candidates for the same reason (likely to be handy when editing to resolve the error).

(Note that check-syntax doesn’t give imported completion candidates; I discover those by walking fully-expanded syntax for #%require forms. But there are some limits, e.g. a file with submodules will have various set of completions — but currently I only try to discover them for the file module.)

Check-syntax produces completion candidates currently via the documentation, so that ought to be made accessible somehow.

I edited my comment while you posted yours. :slightly_smiling_face: I meant imports.

I think check syntax gives only those kind of completion candidates

It provides local bindings, which are a wonderful source of completion candidates. It also tells you about imports that are already used. But not those you might want to use. And those are helpful, too. :slightly_smiling_face: Those I get from #%require.

No, we are talking about different things. If you open up DrRacket, and you do Ctrl-/, then you get completion candidates generated from the same data that produces the blue boxes in the upper right.

Right I’m talking about this use case. I add e.g. (require net/url) and type get-. I would like completion to work for things I’m not already using from net/url. Having it help me type those is kind of the whole point (in that use case).

That’s what it does. It’s perhaps not accessible from the drracket/check-syntax API, which would then be something to fix.

Cool. I’ll double-check but when I was looking at this a few months ago I only saw sources of information about bindings already present/used (not all potential).

via drracket/check-syntax

That feature has been there a long time, but I don’t remember exactly where the API is.

I think this is what you want: https://docs.racket-lang.org/framework/Text.html?q=completion#%28def._%28%28lib._framework%2Fmain..rkt%29._text~3aget-completions%2Fmanuals%29%29

Hah. I just came back here to share that same link. (It takes me awhile to navigate among all the classes and mixins in DrR code, alas.)

The real code is in framework/private/text-autocomplete, on line 742

and is quite short

A couple drawbacks to this: 1. It doesn’t get all exported symbols, just those with documentation. (So, not as handy for say your own project that’s still being developed, but not yet documented.) 2. It requires the GUI framework, which puts it off the table for Racket mode.

I think the very small amount of code starting at 742 could just go somewhere else

and I agree on 1 — it also doesn’t get local bindings. but it seems like a useful additional source of bindings, and probably returns quickly

Yes, my point 2 which I was typing while you replied, would be N/A just copying the essence of the code.

yeah, I think copying those 20 lines makes sense, or maybe putting them in drracket-tool-lib somewhere

I think that would be a good approach for @aymano.osman if they want to add completions (which I brought up, and caused this whole digression, I’m not sure they even care — sorry!). I think for Racket Mode, using the documented symbols is a subset of what I’m finding already by examining #%require forms. And that works quite fast (modulo expansion itself, which is already happening for drracket/check-syntax, and I feed it the same already-expanded syntax, so no extra cost). So I think I will probably just keep on doing that?

I think you’re likely to get that source of completions quickly even if expansion hasn’t finished yet, so that might be an advantage. The other potential advantage is that the bluebox data has a bunch more info than just the name, so you could show the contract or complete the number of arguments.

Good points.

Great suggestions! I’ll look into it.

Sorry to continue to flog this wounded, if not dead, horse. What is the best/easiest way to create a personal catalog that represents my current Racket package environment as of now? It appears raco pkg archive deals with one package at a time. Looking at the output of raco pkg show -d -l -a it appears there are two directories being used - an installation wide one and user specific one. Should I simply copy those two directories to another location. Are the pkgs directories already in a catalog format?

@badkins you can supply multiple packages to raco pkg archive, or you can create a single package that’s all the dependencies of your app

And the pkgs directories are not in the catalog format

Oh right - I think someone already mentioned the “uber package” idea, and I forgot. That seems like the sensible way to go.

You can also use raco pkg catalog-archive to copy a whole catalog (that’s how racksnaps works)

Right, but I just want what I’ve installed vs. the world. I also forgot I was thinking of making my app a package, then I can just raco pkg archive that.