Can we have a new release please?

[dougransom]

I think the whitespace handing change in #2040 is an important fix for Windows users.

[triska]

Other major improvements since 0.9.2:

• WASM support
• rational numbers correction
• corrections and performance improvements to built-ins and meta-calls
• dif/2 improvements
• corrections and improvements to CLP(ℤ)
• newly available phrase_from_stream/2
• improved ISO conformance
• significantly improved HTTP server, including support for HTTPS
• smaller binaries on several platforms
• Precompiled binary for Ubuntu 22.04

Also, it would be nice to publish the next release on crates.io, I think the new dashu release makes this possible?

[infogulch]

I propose tagging a beta release on a regular cadence (monthly or semi-weekly) so users can get access to new features and downloads earlier, while avoiding implying a level of polish or completeness that is not intended.

You can see what that might look like on my fork: https://github.com/infogulch/scryer-prolog/releases

A tag formatted like v0.9.3-beta.1 would be reasonable imo.

[mthom]

I'd like #1880 to be merged before a new release.

[rujialiu]

My current plan is to wait for #1880 to be merged, then #2012 until the minimal solid API is good enough to implement the toplevel (or variant) on the web comfortably. If #2012 is done nicely, I think it'll be relatively painless to implement the toplevel :D

[pmoura]

Personally, I'm not going to do parsing of a shell command to programmatically verify if a user is running a compatible version.

The two flags mentioned in #84 are not detrimental to compatibility between different Prolog systems as I tried to gently explain several times: Prolog standards are too narrow and there are too many features (that non trivial applications may want to use) that will not be standardized today, tomorrow, or in ten years (e.g. where's the DCGs standard whose draft WG17 inherited from me as editor back in 2010?). Each Prolog system is unique in several ways. From that perspective, each Prolog system, Scryer Prolog included, is a dialect.

The well-intended but naive suggestion that application developers should just test for features ignores that, outside trivial cases, that's not simple, scalable, or what's required (versions often must be certified before deployment). Plenty of experience there that other programming languages can share, in particular outside rosy academic experiments. A system supporting being queried for its name and version are basic reflection features. Reflection is key to developer tools (see e.g. https://logtalk.org/tools.html to begin to understand the scope of what I'm talking about).

I tried to bring here (as I try to bring elsewhere) a life time experience that includes using logic programming for industrial applications (both measured in decades) and pushing de facto Prolog systems interoperability to levels that no one thought possible or accomplished before. Seeing Scryer Prolog described as intended to be an industrial strength production environment give me hope. The feedback (but also the silence from the main developer) I regularly got trying to contribute to that goal squashed it. Time is precious. Mine will no longer be spent here. I wish all the best in this project. Systems evolve and must make their own path. In my case, that means cutting free Scryer Prolog.

[triska]

Thank you a lot for many great test cases you provided and all the work you did for this system!

I greatly appreciate your work, and I hope you return when the system is mature enough for industrial use cases!

[haijinSk]

Not a programmer and if a student is any person young enough at heart to be open to new ideas, I want to be a student, person willing to learn. Unfortunately I know nothing about Prolog, and I have only a vague idea what it means to design and implement a programming language, except one thing I see clearly: it's incredibly hard. Paraphrasing Arthur C. Clarke, any sufficiently advanced programming language is indistinguishable from magic.

Yes, I'm nobody, but I hear it as a sad event, if one of the Prolog magicians, @pmoura, is leaving (in any sense) this great, promising, beautiful project.

[rujialiu]

Yes it's sad, but let's focus on essential/important things now and when Scryer Prolog is ready to tackle those ugly but realistic "industrial strength production problems" seriously, we can have another discussion and invite him back @haijinSk

[dougransom]

Is it risky to merge in #1880? I think it would be better to get something out sooner that a windows user has a good chance of success with.

#2046 might be a windows issue as well that stops users from making progress, or a user error on my part.

Anyway, if you can have a much-improved windows version, I'd suggest releasing right away. If it takes a few weeks to merge and test #1880 then maybe do another release in a few weeks. Is there any reason not to release about once a month if you have small feature enhancements or fixes?

[triska]

One interesting aspect: We garner a great amount of publicity, and hence testing, from new releases when they are comparatively rare occurrences. More frequent releases with minor changes may motivate fewer upgrades, and less interest in new releases.

[dougransom]

Well, you have to figure out what gives the best value for the project. There is value in having new features and bug fixes out on users desks frequently, so we can enjoy them. If someone was paying you it might be different.

Another approach might be to have create a maintenance branch for bug fixes you release monthly and a release branch you release with new features on whatever schedule you select. Whoever takes care of the PRs just has to be careful.

[dougransom]

I think it would be wise to wait until #2046 (comment) is fixed and windows release is stable.

[infogulch]

Note: If you just want to use whatever version of the the code recently built from master (including any potential new bugs), you can find the downloads by going to Actions > CI > select any successful build > scroll down to the Artifacts section. You don't have to wait for an actual release.

To be clear, I wouldn't recommend this for general use (which is why this 'feature' is not posted anywhere, though I'm not particularly opposed), but if the current released version is blocking you for some reason and the fix is on tip, then I think this is a reasonable stop gap to get a binary before next release.

[triska]

This is indeed awesome! One thing worth knowing about this option is that you must be logged in to Github for this to work. (I once recommended this way to get the latest release, and then it turned out that the other person did not have a Github account and so did not see anything in this section.) It seems that actual releases are available for download by everyone, which is especially great.

[rujialiu]

Can we have make some tags manually (much less frequently than "nightly") so that people can test the binary after some important fixes without login? For example now, and right before merging #1880?

[infogulch]

Maybe we could have a beta or release candidate schedule before a release. I don't know how that will interact with notifications re: saturating interest for new releases, but maybe it's worth experimenting with.

[rujialiu]

Yes, I was thinking about these too. Just thought merging #1880 feels too much for something like rc1->rc2 :D But I think many softwares just did that (huge changes between release candidates)