Mostowski Collapse:

> Same holds for this website:
> https://www.defprogramming.com/authors/
>
> Its rather a horrible website, can read anything
> unless you have your browser page occupying the
> whole screen. It does some rescaling

Works for me without issue - browser not in full screen. Screenshots:

<https://nextcloud.0x0c.de/s/wd5ms9Lip8SAZTB/preview>
<https://nextcloud.0x0c.de/s/j8FL8GYWj55Ep3k/preview>

For mobile devices the font could be a bit smaller in the author list,
but it generally works and is usable:

<https://nextcloud.0x0c.de/s/NS3AwGaBF8p69Z3/preview>
<https://nextcloud.0x0c.de/s/pbaWFB2JJMb4rMD/preview>

> but I guess it needs some fine tuning. At
> least on an MacBook Air 2019 with Safari
> browser its not usable.

Screenshots? The above screenshots are taken with Windows 10 Pro using
Vivaldi on a 4K display and a Xiaomi Mi 9 Lite with Samsung Internet
browser (which is Chromium based).

--
Arno Welzel
https://arnowelzel.de

Michael Haufe (TNO):

> On Wednesday, May 26, 2021 at 8:21:10 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:
>>> On Wednesday, May 26, 2021 at 1:33:27 AM UTC-5, Mostowski Collapse wrote:
>>>> Hint, if you want to make websites that work
>>>> on mobile and desktop, there are other
>>>> approaches than just having elephant font size.
>>>
>>> The font size is relative to the viewport size.
>> That's a pretty weird thing to do, to be fair.
>
> Uncommon yes, but not that weird:
>
> <https://www.smashingmagazine.com/2016/05/fluid-typography/>
> <https://web.archive.org/web/20200926083516/https://www.csshero.org/css-viewport-units-css-hero/>
> <https://css-tricks.com/viewport-sized-typography/>

I think someone misunderstood the idea of viewport based units. Viewport
based units are ok for the overall layout. But having *text* sized based
on the viewport makes no sense at all besides any demo to show what cool
tricks people found out. Also see the demo on
<https://css-tricks.com/viewport-sized-typography/> with the "I resize."
text which always fits the viewport - nobody needs this for *real*
textual content except a few special use cases to display banners etc..

A font size of 1 em is *always* readable on *any* device since the
browser is designed this way that "1 em" is the normal font size. So
using other font sizes should only be done for a good reason, e.g.
bigger fonts for headlines or using a big font to display a single short
message which fills the viewport. But usually you don't use dynamic font
sizes just because the size of the viewport changes.

For example:

Normally I don't use my desktop browser full screen since most sites
don't need it and don't use a full width view port to display more
information anyway. But in some cases I put the browser to full screen
size to make use of it - e.g. when using an online project management
tool where the additional space can be used to display more columns on
the kanban board etc.. It would be totally stupid if the font then would
be enlarged just because the viewport is bigger.

Or in other words: when I as a user make the viewport bigger or smaller
I don't want to get bigger or smaller text but more or less content.

--
Arno Welzel
https://arnowelzel.de

Michael Haufe (TNO):

> On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:
>> [...]
>> Those articles seem deeply confused, especially the first, which says:
>>
>> This might be because typography is so deeply rooted in the
>> centuries-old history of typesetting. The concept of having “fluid”
>> anything is often at odds with this tradition. In print, dimensions
>> have always been fixed, but they don’t need to be on the web. That’s
>> why I think fluid typography is a perfect match for the web. It’s a
>> different approach for a completely different medium.
>>
>> Using 'viewport width' for the font size *isn't* fluid, it's the
>> exact opposite. It's paper-based thinking in a paperless world.
>> It means the content doesn't format itself appropriately for the
>> page, it just shrinks and expands like a photocopier on 'enlarge'
>> mode.
>
> Given that the common practice is to use breakpoints, are those not the web equivalent of paper based thinking?

No.

Breakpoints are usally only based on the *widht* of a viewport and used
to decide wether there is enough room for two or more columns.

For the mobile version one would only display one column since a
viewport which is only 40em wide may not provide enough room for content
*and* a side bar. On the other hand a desktop viewport with 60em or more
there provides enough space for a 40em wide content area and a 20em wide
sidebar.

But in both cases I would never try to connect the font size to the
viewport width or height. I don't want to get text on a mobile device
way smaller just because the viewport is smaller. Also I want to see
*more* text on a desktop and not *bigger* text. Good responsive layout
will use a *different* layout which fits the smaller viewport and not
just scale everything to become smaller.

--
Arno Welzel
https://arnowelzel.de

Michael Haufe (TNO):

> On Wednesday, May 26, 2021 at 9:15:12 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:
>>> On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:
>>> [...]
>>>> Using 'viewport width' for the font size *isn't* fluid, it's the
>>>> exact opposite. It's paper-based thinking in a paperless world.
>>>> It means the content doesn't format itself appropriately for the
>>>> page, it just shrinks and expands like a photocopier on 'enlarge'
>>>> mode.
>>>
>>> Given that the common practice is to use breakpoints, are those not
>>> the web equivalent of paper based thinking?
>> Why would they be?
>
> Paper has predefined standard sizes, as do viewports. Web developers
> generally use media queries to target those sizes and act accordingly.

Wrong.

Viewports come in many sizes. It's the arrogance of designes who only
work with macOS and iOS to see the world as only three sizes: iPhone,
iPad and macBook.

In reality you have dozens of variations and the media queries are just
there to decide if you use the layout for desktop browsers or for mobile
browsers and sometimes tablets are also a thing to consider, but
nowadays many tables work fine using the desktop layout as well.

Within one layout the design is fluid of course - the mobile version of
a website works fine on a iPhone as well as on a Samsung Android Phone
or Google Pixel even if the viewport on all devices is different. Also
the desktop version does not care if your viewport is 120em wide or just
80em. The "deskop" layout should work for both cases and of course the
font should not become larger just because the viewport is 120em wide
and not just 80em.

--
Arno Welzel
https://arnowelzel.de

On Sunday, June 13, 2021 at 10:55:34 AM UTC-5, Arno Welzel wrote:
> Mostowski Collapse:
> > Nothing wrong with the name Dogelog,
> > Jon Ribbens doesn't like it, so what.
> Well - design is matter of taste (except when violating accessibility
> guidelines). But there are also technical errors:
>
> <https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>

I appreciate the code review. The remaining issues are a problem with jekyll/kramdown parsing of which there is not a trivial workaround currently.

I don't see the relevance to the current thread though.

Frankly I also dont like this website:
http://pointedears.de/scripts/faq/cljs/

It has a background color from Netscape default 25
years ago, neither dark mode nor light mode.

Just joking.

Here is the original charter of comp.lang.javascript

[...]
"The proposed comp.lang.javascript will be open to discussion on all
aspects of JavaScript, as it relates to HTML, Java, Perl, the World
Wide Web in general, and **other related languages**. The scope of
discussion will specifically exclude matters which are *solely*
related to Sun Microsystems, Inc.'s Java language, which should be
discussed in comp.lang.java."
[...]
http://pointedears.de/scripts/faq/cljs/faq_notes/cljs_charter.html

**other related languages** can mean a lot. Java saw the
evolution of JVM language, means the JVM became used
for languages such as Groovy, Kotlin, etc..

I am not sure whether JavaScript does also see such a
trend. There is an interesting technology bundled with
JavaScript, namely WebAssembly.

There was an old prototype of SWI-Prolog ported to
WebAssembly but it didn't have bignum. I tried myself using
CheerpJ to run a Java based Prolog, but the results

werent very satisficing. This is a new try on directly
using the JavaScript platform.

Arno Welzel schrieb am Sonntag, 13. Juni 2021 um 17:55:34 UTC+2:
> Mostowski Collapse:
> > Nothing wrong with the name Dogelog,
> > Jon Ribbens doesn't like it, so what.
> Well - design is matter of taste (except when violating accessibility
> guidelines). But there are also technical errors:
>
> <https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>
> --
> Arno Welzel
> https://arnowelzel.de

The proof of concept already has Prolog bignum support
via primitive JavaScript bignums. You can try and paste the
following into the Dogelog textarea at http://www.dogelog.ch/

and then press the Dogelog "Try it" button:

fact(0, 1) :- !.
fact(N, X) :-
M is N-1, fact(M, Y),
X is N*Y.

:- fact(100, X), write(X), nl.

It will happily show:

93326215443944152681699238856266700490
71596826438162146859296389521759999322
99156089414639761565182862536979208272
23758251185210916864000000000000000000
000000

Enjoy!

Mostowski Collapse schrieb am Sonntag, 13. Juni 2021 um 19:07:57 UTC+2:
> Frankly I also dont like this website:
> http://pointedears.de/scripts/faq/cljs/
>
> It has a background color from Netscape default 25
> years ago, neither dark mode nor light mode.
>
> Just joking.
>
> Here is the original charter of comp.lang.javascript
>
> [...]
> "The proposed comp.lang.javascript will be open to discussion on all
> aspects of JavaScript, as it relates to HTML, Java, Perl, the World
> Wide Web in general, and **other related languages**. The scope of
> discussion will specifically exclude matters which are *solely*
> related to Sun Microsystems, Inc.'s Java language, which should be
> discussed in comp.lang.java."
> [...]
> http://pointedears.de/scripts/faq/cljs/faq_notes/cljs_charter.html
>
> **other related languages** can mean a lot. Java saw the
> evolution of JVM language, means the JVM became used
> for languages such as Groovy, Kotlin, etc..
>
> I am not sure whether JavaScript does also see such a
> trend. There is an interesting technology bundled with
> JavaScript, namely WebAssembly.
>
> There was an old prototype of SWI-Prolog ported to
> WebAssembly but it didn't have bignum. I tried myself using
> CheerpJ to run a Java based Prolog, but the results
>
> werent very satisficing. This is a new try on directly
> using the JavaScript platform.
> Arno Welzel schrieb am Sonntag, 13. Juni 2021 um 17:55:34 UTC+2:
> > Mostowski Collapse:
> > > Nothing wrong with the name Dogelog,
> > > Jon Ribbens doesn't like it, so what.
> > Well - design is matter of taste (except when violating accessibility
> > guidelines). But there are also technical errors:
> >
> > <https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>
> > --
> > Arno Welzel
> > https://arnowelzel.de

I am using a blend of smallint primitive and bignum primitive
to realize the ALU (Arithmetic Logic Unit). Not yet sure

how I will deal with floats, to make the ALU later
ISO core standard Prolog conforming.

Mostowski Collapse schrieb am Sonntag, 13. Juni 2021 um 19:12:25 UTC+2:
> The proof of concept already has Prolog bignum support
> via primitive JavaScript bignums. You can try and paste the
> following into the Dogelog textarea at http://www.dogelog.ch/
>
> and then press the Dogelog "Try it" button:
>
> fact(0, 1) :- !.
> fact(N, X) :-
> M is N-1, fact(M, Y),
> X is N*Y.
>
> :- fact(100, X), write(X), nl.
>
> It will happily show:
>
> 93326215443944152681699238856266700490
> 71596826438162146859296389521759999322
> 99156089414639761565182862536979208272
> 23758251185210916864000000000000000000
> 000000
>
> Enjoy!
> Mostowski Collapse schrieb am Sonntag, 13. Juni 2021 um 19:07:57 UTC+2:
> > Frankly I also dont like this website:
> > http://pointedears.de/scripts/faq/cljs/
> >
> > It has a background color from Netscape default 25
> > years ago, neither dark mode nor light mode.
> >
> > Just joking.
> >
> > Here is the original charter of comp.lang.javascript
> >
> > [...]
> > "The proposed comp.lang.javascript will be open to discussion on all
> > aspects of JavaScript, as it relates to HTML, Java, Perl, the World
> > Wide Web in general, and **other related languages**. The scope of
> > discussion will specifically exclude matters which are *solely*
> > related to Sun Microsystems, Inc.'s Java language, which should be
> > discussed in comp.lang.java."
> > [...]
> > http://pointedears.de/scripts/faq/cljs/faq_notes/cljs_charter.html
> >
> > **other related languages** can mean a lot. Java saw the
> > evolution of JVM language, means the JVM became used
> > for languages such as Groovy, Kotlin, etc..
> >
> > I am not sure whether JavaScript does also see such a
> > trend. There is an interesting technology bundled with
> > JavaScript, namely WebAssembly.
> >
> > There was an old prototype of SWI-Prolog ported to
> > WebAssembly but it didn't have bignum. I tried myself using
> > CheerpJ to run a Java based Prolog, but the results
> >
> > werent very satisficing. This is a new try on directly
> > using the JavaScript platform.
> > Arno Welzel schrieb am Sonntag, 13. Juni 2021 um 17:55:34 UTC+2:
> > > Mostowski Collapse:
> > > > Nothing wrong with the name Dogelog,
> > > > Jon Ribbens doesn't like it, so what.
> > > Well - design is matter of taste (except when violating accessibility
> > > guidelines). But there are also technical errors:
> > >
> > > <https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>
> > > --
> > > Arno Welzel
> > > https://arnowelzel.de

Some more progress. Dogelog got a Prolog dynamic
database. We can now run this example and more:

:- dynamic(memo/2).
fib(N, X) :- memo(N, X), !.
fib(0, 0) :- !.
fib(1, 1) :- !.
fib(N, X) :- M is N-1, fib(M, Y), K is M-1,
fib(K, Z), X is Y+Z, assertz(memo(N, X)).
:- fib(10,X), write(X), nl.
:- fib(100,X), write(X), nl.

Dogelog will show me:

55
354224848179261915075

See also:

Preview: Dogelog got a Prolog dynamic database. (Jekejeke)
https://gist.github.com/jburse/ce2cc49168b637fb0472b3d958999c40#gistcomment-3798277

Pitty it doesn't work in TauProlog, not because of
lack of dynamic database, TauProlog has dynamic database,
but bigint is missing. This is what TauProlog shows me:

?- fib(100,X).
uncaught exception: error(evaluation_error(int_overflow),is/2)

We just completed a time/1 predicate, so as to measure the performance
of Dogelog runtime inside a browser. Just out of curriosity we measured
the performance on our negation as failure based Tic-Tac-Toe game.

Interestingly it takes only ca. 300ms. This means for later moves it
will even take less time. The physiological threshold for fast response
is around 100ms. So it seems feasible to provide a user interface

and deliver a Tic-Tac-Toe game play via Prolog inside the browser.
We quickly found a SELFHTML tutorial about the Tic-Tac-Toe game
and adopted the game board from there.

See also:

Preview: Dogelog plays Tic-Tac-Toe via Prolog. (Jekejeke)
https://gist.github.com/jburse/79c0fcaa23339d2a0968c7d54594facd#gistcomment-3799880

The final game can be found at this URL for toying around:
http://www.dogelog.ch/play.html

Woa! The JavaScript JIT compiler is quite impressive. I now
ported Dogelog runtime to Python as well, so that I can compare
JavaScript and Python, and tested without clause indexing:

between(L,H,L) :- L =< H.
between(L,H,X) :- L < H, Y is L+1, between(Y,H,X).

setup :- between(1,255,N), M is N//2, assertz(edge(M,N)), fail.
setup :- edge(M,N), assertz(edge2(N,M)), fail.
setup.

anc(X,Y) :- edge(X, Y).
anc(X,Y) :- edge(X, Z), anc(Z, Y).

anc2(X,Y) :- edge2(Y, X).
anc2(X,Y) :- edge2(Y, Z), anc2(X, Z).

:- setup.
:- time((between(1,10,_), anc2(0,255), fail; true)).
:- time((between(1,10,_), anc(0,255), fail; true)).

The results are:

/* Python 3.10.0rc1 */
% Wall 188 ms, trim 0 ms
% Wall 5537 ms, trim 0 ms

/* JavaScript Chrome 92.0.4515.159 */
% Wall 5 ms, trim 0 ms
% Wall 147 ms, trim 0 ms

Mostowski Collapse schrieb:
> Dear All,
>
> Needs a decent browser, JavaScript >2015
>
> http://www.dogelog.ch/
>
> Currently swallows errors silently. Everything written
> in Prolog itself, read/1, consult/1, etc.. and then cross
> compiled into JavaScript. Not sure whether it can already
>
> compile itself. But it has a text field and can add the
> clauses in the text field and execute the directives in the
> text field, and it has write/1 and nl/0 into the HTML document.
>
> More care for the good boy upcoming.
>
> Have Fun!
>
> Jan Burse, 24.05.2021 #StaySafe
> http://www.jekejeke.ch/

Thats a factor 37.8 faster! I tested the a variant of
the Albufeira instructions Prolog VM aka ZIP, which
was also the inspiration for SWI-Prolog.

Open Source:

The Python Version of the Dogelog Runtime
https://github.com/jburse/dogelog-moon/tree/main/devel/runtimepy

The Python Test Harness
https://gist.github.com/jburse/bf6c01c7524f2611d606cb88983da9d6#file-test-py

Mostowski Collapse schrieb am Donnerstag, 19. August 2021 um 23:38:09 UTC+2:
> Woa! The JavaScript JIT compiler is quite impressive. I now
> ported Dogelog runtime to Python as well, so that I can compare
> JavaScript and Python, and tested without clause indexing:
>
> between(L,H,L) :- L =< H.
> between(L,H,X) :- L < H, Y is L+1, between(Y,H,X).
>
> setup :- between(1,255,N), M is N//2, assertz(edge(M,N)), fail.
> setup :- edge(M,N), assertz(edge2(N,M)), fail.
> setup.
>
> anc(X,Y) :- edge(X, Y).
> anc(X,Y) :- edge(X, Z), anc(Z, Y).
>
> anc2(X,Y) :- edge2(Y, X).
> anc2(X,Y) :- edge2(Y, Z), anc2(X, Z).
>
> :- setup.
> :- time((between(1,10,_), anc2(0,255), fail; true)).
> :- time((between(1,10,_), anc(0,255), fail; true)).
>
> The results are:
>
> /* Python 3.10.0rc1 */
> % Wall 188 ms, trim 0 ms
> % Wall 5537 ms, trim 0 ms
>
> /* JavaScript Chrome 92.0.4515.159 */
> % Wall 5 ms, trim 0 ms
> % Wall 147 ms, trim 0 ms
> Mostowski Collapse schrieb:
> > Dear All,
> >
> > Needs a decent browser, JavaScript >2015
> >
> > http://www.dogelog.ch/
> >
> > Currently swallows errors silently. Everything written
> > in Prolog itself, read/1, consult/1, etc.. and then cross
> > compiled into JavaScript. Not sure whether it can already
> >
> > compile itself. But it has a text field and can add the
> > clauses in the text field and execute the directives in the
> > text field, and it has write/1 and nl/0 into the HTML document.
> >
> > More care for the good boy upcoming.
> >
> > Have Fun!
> >
> > Jan Burse, 24.05.2021 #StaySafe
> > http://www.jekejeke.ch/

Dogelogs new signature sound:

Led Zeppelin Immigrant song (Racing Beat remix)
https://www.youtube.com/watch?v=oryBBkmIVCc

LoL