should the group be archived?

[jfmc]

Hi everyone.

Is there any way to fix the spam problem in this group?

It makes it completely unusable and hides all the interesting discussions that happened in the past.

What is the recommended forum for (multi-system) Prolog discussions nowadays?

Cheers,

[Mostowski Collapse]

Hi,

There was a ISO Prolog (core) standard mailing list in the
past. Isn't ISO Prolg aimed at "multi-system". Whats your
definition of "multi-system"?

A forum where multiple Prolog systems are represented?
But sometimes I have the feeling that SWI-Prolog thinks
that it is some standard, when I read:

Making ProB Compatible with SWI-Prolog
https://www.doi.org/10.1017/S1471068422000230

But then now SWI-Prolog isn't really a friend of
Ciao Prolog anymore, I see on Twitter:
thank you for these great suggestions!

looks like ciao-lang online is an even better
fit than swish with has an overly complex UI
https://twitter.com/rzeta0/status/1557288636315484160

LoL, how much popcorn should I order?
The next years will be really fun!

Bye

[A. K.]

jfmc schrieb am Donnerstag, 11. August 2022 um 10:51:57 UTC+2:

Group should be closed. And open a write-only group for top spammer burs..
Or just rename the bin for him.

[Mostowski Collapse]

I think this project is dead, when was the last commit:

andrewtholt committed Mar 9, 2015
https://github.com/andrewtholt/minforth

Envy a comp.lang.prolog that isn't dead?

A. K. schrieb:

[Mostowski Collapse]

Does Mini Forth have partial strings? Looks like Scryer
Prolog is currently keeping itself busy with partial strings
for weeks and months.

?- read(T).
[a|b].
thread 'main' panicked at 'internal error: entered unreachable code', src/machine/machine_state_impl.rs:871:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
read/1 crash #1627
https://github.com/mthom/scryer-prolog/issues/1627

Quite amazing. So this idea by Ulrich Neumerkel has not
yet lead to a stable Scryer Prolog? Whats insurmountable
difficulty for partial strings?

[Mostowski Collapse]

Aren't partial strings base on chars just simple pattern
matching. You only need to pattern match two cases:

[c1,..,cn]

[c1,..,cn|X]

Where c1,..,cn are chars and X is a variable. Its just
as easy as this proposal here:

Feature request indirect implementation of new built-ins #68
I think detection and dedicated compilation of the
following pattern would solve the issue:
Expr /\ (1 << N)
https://github.com/trealla-prolog/trealla/issues/68

Partial strings is only detection and dedicated compilation of
two patterns, still it takes already years to make Scryer Prolog
stable. What would happen if Scryer Prolog would

implement getbit/2 this way? Would this ever work?
Maybe they use the wrong framework for their interpreter
and compiler building? A framework that has what

kind of disadvantage? I don't know. What is the inherent
problem that detection and dedicated compilation becomes
a wall of problems. A big big wall, a kind of columb-wall

that might an outside believe, its an inpenetrable wall?
https://en.wikipedia.org/wiki/Coulomb_barrier

LMAO!

[Mostowski Collapse]

There is a lot of experimenting how to increase quality
assurance of Scryer Prolog. Of course continous integration (CI)
and continuous deployment (CD) could be key, especially

if you have a setup as in Scryer Prolog with many experts to
few programmers. There are like a dozend experts swirling
around and only very few programmers. So these experts

even don't have local forks, or could do some bug fixing
by themselves, which would be much more efficient. So they
need to communicate bugs and wait for new release and

do retesting, and communicate findings again. Very slow
process and not very effective because problem solving
pairs are separated. Its not that the same engineer indentifies

and fixes a problem. Here is what they are struggling with:

GitHub runners bla bla
https://github.com/mthom/scryer-prolog/discussions/966

[Mostowski Collapse]

I do not have a lot of CI/CD on my side, but I have a new
test case runner, which can show multi column test results
side by side, test results that come from different sources.

I already use it to show test results from these 3 systems
side by side. It was quite some work over the last 10 days
to mirgate formerly Jekejeke Prolog to the new testing framework:

1. Dogelog Player JavaScript [column name "js"]
2. Dogelog Player Python [column name "py"]
3. Formerly Jekejeke Prolog [column name "j"]

The new testing framework is ultra simple and 100% written
in Prolog. It requires a very minimal subset of Prolog. Mabye
will add further columns in the near future, like

a SWI-Prolog column or a Trealla Prolog column. The
Logtalk Testing Framework is probably a dead horse. Its
the opposite of minimal, if you first need Logtalk to

test Prolog systems. Its one more Lognonsense. I am
also phasing out the old formerly Jekejeke Prolog testing
framework. Its already phased out concerning test results

itself, what survies so far is a coverage tool. But sooner
or later this tool will also go, and be replaced by something
simpler. Also the beautifer should be replaced.

P.S.: Here are the current results, you see columns "js",
"py" and "j", its split over two test suites:

http://pages.xlog.ch/littab/doclet/docs/10_samples/04_doge_comply/reference_result/package.html

http://pages.xlog.ch/littab/doclet/docs/10_samples/04_doge_comply/frequent_result/package.html