Support SWIPL 9.1.2 ?

[JBThiel]

Is it possible to make this work with swi-prolog-9.1.2 ? Gentoo seems to be stuck at this version for a while. It's not far back from the 9.1.22 minimum mentioned in README. But installing via pack_install, I get the log below.

Alternately, is there a way to tell pack_install to grab an older version of clpBNR that might be compatible?

Thanks for your work making this powerful solver available on the SWIPL platform.

-- JBThiel

?- pack_install(clpBNR).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
Install clpBNR@0.11.5 from GIT at https://github.com/ridgeworks/clpBNR.git Y/n?
% Cloning into '/home/jbthiel/.local/share/swi-prolog/pack/clpBNR'...
ERROR: Type error: `dependency' expected, found `prolog:rational' (a compound)
ERROR: In:
ERROR:   [29] throw(error(type_error(dependency,...),_110676))
ERROR:   [24] prolog_pack:'__aux_maplist/3_valid_info_arg+0'([dependency],[prolog:rational]) at /usr/lib64/swipl/library/prolog_pack.pl:275
ERROR:   [22] prolog_pack:'__aux_maplist/2_valid_info_term+0'([requires(...)]) at /usr/lib64/swipl/library/prolog_pack.pl:851
ERROR:   [13] prolog_pack:pack_install_from_url(https,'https://github.com/ridgeworks/clpBNR.git','/home/jbthiel/.local/share/swi-prolog/pack',clpBNR,[git(true),...|...]) at /usr/lib64/swipl/library/prolog_pack.pl:1003
ERROR:    [9] toplevel_call('<garbage_collected>') at /usr/lib64/swipl/boot/toplevel.pl:1173
ERROR:
ERROR: Note: some frames are missing due to last-call optimization.
ERROR: Re-run your program in debug mode (:- debug.) to get more detail.

[ridgeworks]

Sorry for the inconvenience - changes for checking dependencies were added to facilitate a version that runs on SWISH. The error message is confusing, I'm guessing that is the 9.1.2 behaviour and out of date.

I think the easiest way around this is to bypass the pack install system and download a local copy of 0.11.4 from here. The modules for clpBNR and clpBNR_toolkit are in directory prolog for explicit loading (like any user project file).

This isn't ideal but may get you through until a more up-to-date version of SWIP is available to you. (9.1.2 was released in Dec. 2022 so it's a fair ways behind the current release.)

[JBThiel]

Thanks for speedy reply and suggestions. I have got it working with the yet older release 0.10.4, from the tarfile snapshots at that releases url, https://github.com/ridgeworks/clpBNR/releases/

clpBNR version 0.10.4 on SWIPL 9.1.2, LOG, WORKS:

$ swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 9.1.2)

?- pack_install('file:///usr/local/src/clpBNR-0.10.4').
true.

?- use_module(library(clpBNR)).
% *** clpBNR v0.10.3 ***.
%   Arithmetic global flags set to prefer rationals and IEEE continuation values.
true.

?- I::integer, [J,K]::integer(-1,1).
I::integer(-72057594037927936, 72057594037927935),
J::integer(-1, 1),
K::integer(-1, 1).

?- [X,Y]::real, {1==X + 2*Y, Y - 3*X==0}.
X:: 0.142857142857142...,
Y:: 0.428571428571428... .

The 0.11.4 (and .2, .0) releases are requiring SWIP 9.1.5 with a version check. 9.1.5 is very close to 9.1.2, is there really some crucial difference in 9.1.5 that clpBNR needs? I could patch the version check to try making it run on 9.1.2, but of course wouldn't want some non-obvious mathematical breakage.

Also, it seems like the version check is not actually executing, rather the error msg is about some other structural problem with the module, at the point where the version check is.

clpBNR version 0.11.4 on SWIPL 9.1.2 LOG:

?- pack_install('file:///usr/local/src/clpBNR-0.11.4').
true.

?- use_module(library(clpBNR)).
ERROR: /home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl:30:
ERROR:    Domain error: `module_header' expected, found `:-print_message(error,history(expanded("This version of clpBNR requires SWIP 9.1.5 or greater")))'
ERROR:    In:
ERROR:      [34] throw(error(domain_error(module_header,...),_4718))
ERROR:      [31] '$first_term'((:-print_message(error,...)),_4750,'/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',state(true,_4772,true,false,'/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',-),[if(not_loaded),...]) at /usr/lib64/swipl/boot/init.pl:3156
ERROR:      [30] '$load_file'('/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl','/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',_4824,[if(not_loaded),...]) at /usr/lib64/swipl/boot/init.pl:3098
ERROR:      [29] setup_call_catcher_cleanup(system:'$start_consult'('/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',1716394724.7975945),system:'$load_file'('/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl','/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',_4898,...),_4870,system:'$end_consult'('/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',...,user)) at /usr/lib64/swipl/boot/init.pl:679
ERROR:      [25] '$do_load_file_2'(library(clpBNR),'/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',user,compiled,[if(not_loaded),...]) at /usr/lib64/swipl/boot/init.pl:2712
ERROR:      [22] '$qdo_load_file'(library(clpBNR),'/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',user,[if(not_loaded),...]) at /usr/lib64/swipl/boot/init.pl:2633
ERROR:      [20] setup_call_catcher_cleanup(system:with_mutex('$load_file',...),system:'$mt_do_load'(<clause>(0x55ac7f993930),...,'/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',user,...),_5044,system:'$mt_end_load'(<clause>(0x55ac7f993930))) at /usr/lib64/swipl/boot/init.pl:679
ERROR:      [18] <meta call>
ERROR:      [17] sig_atomic(setup_call_cleanup(with_mutex('$load_file',...),'$mt_do_load'(<clause>(0x55ac7f993930),...,'/home/jbthiel/.local/share/swi-prolog/pack/clpBNR/prolog/clpBNR.pl',user,...),'$mt_end_load'(<clause>(0x55ac7f993930)))) <foreign>
ERROR:      [14] '$load_file'(library(clpBNR),user,[if(not_loaded),...]) at /usr/lib64/swipl/boot/init.pl:2423
ERROR:       [9] toplevel_call(user:user: ...) at /usr/lib64/swipl/boot/toplevel.pl:1173
ERROR:
ERROR:    Note: some frames are missing due to last-call optimization.
ERROR:    Re-run your program in debug mode (:- debug.) to get more detail.

[ridgeworks]

. The 0.11.4 (and .2, .0) releases are requiring SWIP 9.1.5 with a version check. 9.1.5 is very close to 9.1.2, is there really some crucial difference in 9.1.5 that clpBNR needs?

My bad. SWIP 9.1.5 introduces the mathematically correct comparison function cmpr/2. The standard comparison functions convert non-floats to floats before comparing; in some (corner) cases this yields an incorrect result. clpBNR 0.11.0 onwards uses these mathematically functions (including maxr/2 and minr/2 ).

So I fear version 0.10.4 will be the latest version that will run on 9.1.2. Functionally, there have been just a few minor additions since that release. The more significant enhancements are structural changes and cleanups to support execution on the SWISH platform.

[JBThiel]

Very good, thanks much. So Swipl 9.1.5 is a hard req for the improved correctness.

Then clpBNR 0.10.4 will be plenty suitable to get started for now, and hopefully Gentoo will update to newer Swipl version within the coming months.

[JBThiel]

btw, I was reading the manual at https://ridgeworks.github.io/clpBNR/CLP_BNR_Guide/CLP_BNR_Guide.html Very nice, almost a textbook level document, with many wide-ranging constraint solving examples, and illustrative diagrams.

Seems like it uses some custom reader/formatter (MYW), which unfortunately is coloring most of the text as shades-of-grey-on-white, which looks rather washed-out, very tiring and hard to read on my screen. I would prefer a crisp black-on-white, better contrast. I recommend adjusting the color defaults in that formatter, or maybe there is some end-user control setting for it?

(I could open this as a separate issue, here or on the MyWord site? Looks like that is a separate product, possibly also developed by you?)

[ridgeworks]

Very good, thanks much. So Swipl 9.1.5 is a hard req for the improved correctness.

Then clpBNR 0.10.4 will be plenty suitable to get started for now, and hopefully Gentoo will update to newer Swipl version within the coming months.

That's correct. I don't expect you will have any problems related to not having the latest version. If you suspect something, SWISH runs an up-to date version (see https://swish.swi-prolog.org/example/clpBNR_quickstart.swinb). I hadn't appreciated that there are situations where updating SWIP can be problematical.

Seems like it uses some custom reader/formatter (MYW), which unfortunately is coloring most of the text as shades-of-grey-on-white, which looks rather washed-out, very tiring and hard to read on my screen. I would prefer a crisp black-on-white, better contrast. I recommend adjusting the color defaults in that formatter, or maybe there is some end-user control setting for it?

That's a little odd because it renders fine on any MacOS browser (also IOS and Android browsers) I've tried. The default text color (defined in CSS) for the document (local copy of the Guide in the pack in docs/CLP_BNR_Guide/MyWordDocStyle.mmk) text has color #505050 which looks like quite a dark gray to me; chosen because it's a little easier on the eyes IMO than black. If you can figure out the root cause for what you're observing, I'll try to accommodate. (Does it have anything to do with UI themes?)

[JBThiel]

I expect I'm seeing your greyscale as intended, because it's similar/same on both Thinkpad/Gentoo/Firefox and iPhone/Safari. Hard to read on both.

It's probably some combination of individual eyesight, hardware, and current vogue UI themes/conventions. Mac laptops do have particularly radiant high-contrast screens, vs Thinkpad pretty good but not great. Also I note a variety of apps/themes nowadays are coming with default UI themes that seem to me horribly muted. Lots of muted colors and earth tones on dark grey/browns. Nigh illegible, and I think objectively. But if everything is washed out, then maybe it all balances out, or users are compensating by turning up their overall brightness.

The old IBM color themes were doing white/yellow/cyan on dark black/blue backgrounds for a reason, highly legible. Or the white background emulating paper, which needs sharp crisp solid black/pigment inks. I have most of my editors, terminals and apps configured either bright colors on black/darkblue, or sharp pure black on light white/cream/pastels. Anything with grey/brown/tan tones immediately looks very muted. Not easier to read at all, very tiring, at least for me.

The effect with the MyWord clpBNR manual is compounded by that the many nice examples are an even lighter shade of grey, on yet another shade of grey background. So exactly where the reader is trying to really focus on some example, it's even harder to see! The overall effect is the whole document is "fading out", and a struggle just to view it.

(note: I am somewhat hyperbolizing for purpose of illustration. The manual is readable, and if you just look for a couple minutes probably fine. But if you are trying to extended study, it rapidly becomes tiring and apparent how it's dimmed out.)

Just giving the constructive feedback. I actually first noticed about the MyWord renderer, because I was examining the page source, searching for CSS settings to adjust the colors. (Very rare, I hardly ever do that, just this exceptional combination of a less-legible document involving extended focus and perusal.)

Might there be a PDF of the manual available? or a way to static render it, with adjustable settings? I will followup your CSS lead if I get a chance to further investigate the MyWord rendering system.

[ridgeworks]

Anything with grey/brown/tan tones immediately looks very muted. Not easier to read at all, very tiring, at least for me.

We're either seeing different things or getting different impressions of the same thing. For example, the example background is essentially the same as GitHub uses when rendering MarkDown. Do you have the same issues with that?

Most browsers support developer tools that permit you to override style info in the document. This can be used, for example, to change the text color. When I use this to disable the color, i.e., set text to black, I see a small but perceptible difference in rendering. I assume you would see a more significant change.

The source for the Guide is in the docs folder in the pack which you should have locally. Default CSS for the body element is in the file MyWordDocStyle.mmk:

[MyWordDocStyle] <- <style type="text/css"> is
        body {
            font-family: 'Helvetica Neue', Helvetica, Arial, serif;
            font-size: 1em;
            line-height: 1.5;
            color: #505050;
        }

Change the color to desired value (or delete it) and save. Then load CLP_BNR_Guide.html into a browser. All rendering is done with JavaScript running in the browser which is loaded with the document source.

You can print/save a pdf from most browsers but I'm not sure how that will help.

[JBThiel]

Exactly so! Github has a terrible UI theme! same kind of soft greyscales all over the place. The first quoted text in your message above for example is light grey (rgb(99, 108, 118)) , on a white background -- that is objectively a barely legible color combination. The regular text is darkgrey-on-white, Firefox reports rgb(31, 35, 40), versus why not pure black rgb(0,0,0).

The bulk of black-on-white text (that is intended for reading) should be the sharpest, blackest, highest contrast you can get. Any softening should be the alternate setting, tailored by the end-user to their viewing conditions. A key R&D/design limit of video tech is maximizing the available deep black contrast, and then these soft greyscale themes are cavalierly throwing away 30% the fruit of decades of research.

If you are testing on mainly Mac laptop and recent phones, bear in mind those are state-of-art highest end display tech. If you have contrast ratio to spare, that does not necessarily extend to the bulk of viewing hardware out in the wild. My Thinkpad is only a few years old, but even max contrast pure-black-on-white is not really good enough.

I was going into all this background, because I'm an extensive user of many markup languages. MyWord was new to me, and the clpBNR doc looks pretty nice, so I'm interested to investigate it further. But the greyscaling is a significant flaw to my mind/eyes; I don't know any other doc generator that does that by default. (referring to mostly print engines).

I was thinking a PDF option might have an alternate output path, optimized for black-on-white printing, but I guess you're saying it would just reproduce the current view greyscale colors, as actuated via the browser Print.

So the MyWord mmk/CSS option sounds like the avenue to explore for now. Thanks for detailed recipe. I gave that a try, editing to color: #000000.

However, the local file is not loading in browser. Attempt to view in Firefox file:////usr/local/src/clpBNR-0.10.4/docs/CLP_BNR_Guide/CLP_BNR_Guide.html shows error:

Rendering CLP_BNR_Guide.myw
NetworkError when attempting to fetch resource.
*** x-markup.js error:Worker

A similar error in Opera:
Rendering CLP_BNR_Guide.myw
Failed to fetch

What do you make as the issue? And why is it trying to network fetch in the first place, instead of using the local files?

(Edit: Is MyWord something I need to have installed separately, or in SWIPL? I haven't done anything like that, I was just using the files in the clpBNR subdir.)

[ridgeworks]

If you are testing on mainly Mac laptop and recent phones, ...

My desktop monitor is a 5 year old Dell (~$500) so I wouldn't consider that state-of-the-art.

But the greyscaling is a significant flaw to my mind/eyes; I don't know any other doc generator that does that by default. (referring to mostly print engines).

MyWord is completely agnostic on that front (zero defaults). Styling is completely defined by the user (one example being MyWordDocStyle.mmk which contains the defaults I chose to define for the Guide). Markup labels are also user-defined, but a minimal default subset is provided by lib/x-markup.mmk and additionally in pkgs/*. Absent any such user data, the browser defaults will be in effect.

What do you make as the issue? And why is it trying to network fetch in the first place, instead of using the local files?

The "fetches" are all to relative URL's so they should reference the local files since the original URL starts with file:///. The problem is that modern browsers restrict access to the local file system for security reasons. There used to be a way of enabling this capability but I can't remember the details. (Google may have suggestions for current technology, e.g., https://tomaskulhanek.github.io/blog/enable-fetch-local-file.) I just start up a server on localhost and serve it from there.

(Edit: Is MyWord something I need to have installed separately, or in SWIPL? I haven't done anything like that, I was just using the files in the clpBNR subdir.)

As long as you use the files in the pack docs/CLP_BNR_Guide directory, nothing else is required; rendering software is in lib directory and loading is initiated by CLP_BNR_Guide.html. As previously noted, all rendering, including translation of MyWord content to html, is done in the browser.

[JBThiel]

Ok, thanks for hint, that seems to be the problem. I dug into it more, with some findings: That link from 2020-jun says "in Firefox, open about:config and set privacy.file_unique_origin to false"

In my version of Firefox 115.11.0esr (64-bit), there is no config setting by that name, nor anything obviously similar in the 140 other privacy options. A search on "origin", turns up another 20 options, revealing the magic token now at: security.fileuri.strict_origin_policy

Set this option to false, from the default true, then MyWord renderer works on the local files. With the adjusted .mmk configuration, color: #000000, then I have the greyscale back to black. Docs: https://kb.mozillazine.org/Security.fileuri.strict_origin_policy https://kb.mozillazine.org/Links_to_local_pages_do_not_work

This is way too much complication, and just fixes 1 browser version. (plus requires a global setting change, with security implications.) I can't bother tracking down how to config this for myriad other browsers. And I can't bear to peer through that greyscale gauze. So I reexamined the PDF output approach.

Good news is Firefox PDF printing ignores the greyscale setting and makes solid black text. Tested with both the Firefox Print Dialog, and the System Print dialog callout, from both my patched #000000 version and the online greyscale version. So I have made a readable PDF with solid black text, yet still preserves the colored lines in graphs, etc.

It would be nice if you can get this greyscale/black option more easily configurable in MyWord from the enduser perspective (ie. not able to tinker with the .myw/.mmk options or run local servers). Thinking of a menu/toolbar with dynamic rendering options. Or just change the default black to #000000 instead of #505050 as currently all over (also in the MyWord docs). Good that it is settable at least, and not hard-baked into the MyWord format.

Btw, I noticed in the PDF, the TOC links are all absolute links, pointing to ridgeworks.github.io, or the full local file:/// path, so if you click them in the PDF viewer, they open in the browser. It would be better if they were relative links that just hopped inside the PDF. (unknown at what stage they are made absolute, whether in MyWord or the browser page render, or the PDF rendering. Maybe that's a byproduct of the PDF saving, not something MyWord can affect.)

I should have opened a separate issue for this topic under MyWord. Perhaps we ought move these comments there for reference? I don't mind doing that, or you can, if is possible, not too complicated? Or could make a stub issue under MyWord project, pointing here.

[ridgeworks]

This is way too much complication, and just fixes 1 browser version.

The main intended use case for MyWord is publishing on the Web where content resides on the server. Initially it was fairly easy to render local file content but that became overly complicated with the introduction of CORS. So I abandoned that approach and just fire up a local server (Apache) for testing - that's the environment where it eventually resides anyway.

MyWord was an experiment to focus on two main issues. First, it tries to be a self contained extensible markup language (user defined markup notation and a simple file based modularity scheme) , so the author can control everything - the document contains the configuration. Second, while a copy of the MyWord software and document is present on the server, the software and document are downloaded to the client and rendering occurs in the browser. So the only GUI is the one defined in the document (and any used MyWord packages). This is all described in the MyWord repo README and its all open source.

Regarding the TOC links, they are all relative links as rendered by MyWord to the DOM (as seen by browser developer tools) , so the absolute links must be generated for the PDF; not sure why.

I haven't touched MyWord in many years and have no current intentions to do so. But it is open source so feel free to poke it yourself. There's a lot to chew on, but if you have a broader interest in the topic, it might be worth your effort. (I'll try to respond to any issues you might have on that repo.)

BTW, I think it's a bit unfortunate if the Firefox PDF generator chooses to ignore grey scale.