I’ve published a TUI library.
I did the design/prototyping/optimization of the MVP. Then worked with Claude Code to add features and polish before publishing.
@jan: swipl pack publish https://github.com/z5h/prolog_tui.git registered the pack, but reported Pack prolog_tui at version 0.1.0 failed for unknown reason (false).
The repo name (prolog_tui) differs from the pack name in pack.pl (tui). For a git URL, pack_default_options/4 takes the pack name from the URL (git_url(URL, Pack)). register_downloads/2 then looks for prolog_tui-Result in the server’s reply, which is keyed tui, so it reports failure although the server registered the pack.
The installation plan shows the same confusion: “Install prolog_tui at version 0.0.0”.
What’s the best course of action here?
Settle a name that is both the pack name and repository name and publish. I can delete a pack and change the registered source on the server. Deleting will do the job if you prefer a new pack name. If you change the repo, I can change the registered source, so you can push again.
Amazing
Is your library compatible with swi-prolog make/0 hot-reloading features ?
One thing that was kind of impressive when I last tried to write a text editor in swi-prolog was to edit the source code of the editor through the editor and have shortcut call make and then the live editor instance would pick up the changes on the fly !
I have approved all the pending posts here. Weird. You are at a high trust level and I can’t find anything wrong with it. It was flagged by Discourse itself. Hope it learns …
So you renamed the repo to “tui.git”? You want me to delete the current or change the source URL?
I updated the URL to drop the prolog_. Packs are bound to a source location. If this is a git repo, it is simply that repo. Otherwise the directory must match and the file name should properly reflect the pack and version. Anything else is rejected. This restricts updating the package to the original publisher. GIT repos are by far preferred (maybe we should block anything else?).
I just did a quick test of the async example that uses the ports and subscription feature for multithreaded support. (As I thought this would be the most fragile).
It works!
The only catch is it has to be run with 2> /dev/null or however your shell discards stderr, because make prints a warning to the terminal.
Well, you can define user:message_hook/3 to capture the messages and display them where they belong. That is precisely why the print_message/2 stuff is meant for,