Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.prolog > #14558 > unrolled thread

Java and OpenJFX or JavaScript and WHATWG?

Started byMild Shock <janburse@fastmail.fm>
First post2025-06-17 10:47 +0200
Last post2025-06-19 17:47 +0200
Articles 9 — 1 participant

Back to article view | Back to comp.lang.prolog


Contents

  Java and OpenJFX or JavaScript and WHATWG? Mild Shock <janburse@fastmail.fm> - 2025-06-17 10:47 +0200
    Why do IDEs have Power Save mode? (Was: Java and OpenJFX or JavaScript and WHATWG?) Mild Shock <janburse@fastmail.fm> - 2025-06-17 10:49 +0200
      Dog Shit: Call my name "jan.ai" (Was: Why do IDEs have Power Save mode?) Mild Shock <janburse@fastmail.fm> - 2025-06-17 16:17 +0200
        There is no flesh and blood async Prolog! (Was: Dog Shit: Call my name "jan.ai") Mild Shock <janburse@fastmail.fm> - 2025-06-19 14:04 +0200
          When did the Dogelog Player Quantum Leap happen? (Was: There is no flesh and blood async Prolog!) Mild Shock <janburse@fastmail.fm> - 2025-06-19 14:11 +0200
            Main problem with simulated “threads” (Was: When did the Dogelog Player Quantum Leap happen?) Mild Shock <janburse@fastmail.fm> - 2025-06-19 14:26 +0200
              Time Sharing: Martin Richards, Ken Thompson and Linus Torvalds Mild Shock <janburse@fastmail.fm> - 2025-06-19 14:38 +0200
                <parallel> Ant Task doesn't need threads (Was: Time Sharing: Martin Richards, Ken Thompson and Linus Torvalds) Mild Shock <janburse@fastmail.fm> - 2025-06-19 14:54 +0200
            Corr.: wrong date, should read 2021 (Was: When did the Dogelog Player Quantum Leap happen?) Mild Shock <janburse@fastmail.fm> - 2025-06-19 17:47 +0200

#14558 — Java and OpenJFX or JavaScript and WHATWG?

FromMild Shock <janburse@fastmail.fm>
Date2025-06-17 10:47 +0200
SubjectJava and OpenJFX or JavaScript and WHATWG?
Message-ID<102ra2b$u1kq$1@solani.org>
Somebody wrote:

 > noticeable lag waiting for completion candidates

A lag wouldn’t be a problem. I guess the problem
is that the GUI gets blocked, right? If your GUI
has tasks and timers, you could try the follow:

- Debouncing Timer: To start ghost after lets
   say 1000 ms, the debouncing is to assure that
   the ghost appears after the last edit and not
   after the first edit.

- Abortable Task: The ghost is then computed
   asynchronously via a task. But this task is
   again tied to the debouncing, means the task
   gets aborted if the end-user shows impatience.

I checked a couple of GUI tools to do that. Had
rather bad experience with Java and OpenJFX, so I
am returning back to the JavaScript and WHATWG
with my ongoing research.

SVG tags were not working out the box
https://wiki.openjdk.org/display/OpenJFX/Main

No runLater(), any task can any time modify the DOM!
https://whatwg.org/

But maybe there are other GUI frameworks which
can do it. If tasks are also used for highlighting
I belive they can be also run asynchronously without
explicitly juggling with some queues,

just await the asynchrous routine that the task
would execute, in a instrumentation loop, and ignore
the aborts, since an abort is now good news and not
bad news, it only indicates that

the end user did an edit and that the task
will be restartet.

[toc] | [next] | [standalone]


#14559 — Why do IDEs have Power Save mode? (Was: Java and OpenJFX or JavaScript and WHATWG?)

FromMild Shock <janburse@fastmail.fm>
Date2025-06-17 10:49 +0200
SubjectWhy do IDEs have Power Save mode? (Was: Java and OpenJFX or JavaScript and WHATWG?)
Message-ID<102ra6v$u1kq$2@solani.org>
In reply to#14558
The restart maybe explains why IntelliJ has a
Power Safe mode, but I am not 100% sure about
the details. But if the end-user behaviour is
not compatible with the chosen delays, he might

tear down the tasks again and again. This could
use compute power. Some incremental tasks or tasks
that block (i.e. the "lag") could be a solution.
Incremental tasks that do only small work and

not big work, are less perceived as blocking
(i.e. the lag). But a ghost text that maybe
involves calling an Artificial Intelligence API
is probably in nature not a small work task,

in the sense that it would occupy a short work
time, the Artificial Intelligence API server
might be busy and cause a task slow down.

Disclaimer: I am doing some brain writing here...

Mild Shock schrieb:
> Somebody wrote:
> 
>  > noticeable lag waiting for completion candidates
> 
> A lag wouldn’t be a problem. I guess the problem
> is that the GUI gets blocked, right? If your GUI
> has tasks and timers, you could try the follow:
> 
> - Debouncing Timer: To start ghost after lets
>    say 1000 ms, the debouncing is to assure that
>    the ghost appears after the last edit and not
>    after the first edit.
> 
> - Abortable Task: The ghost is then computed
>    asynchronously via a task. But this task is
>    again tied to the debouncing, means the task
>    gets aborted if the end-user shows impatience.
> 
> I checked a couple of GUI tools to do that. Had
> rather bad experience with Java and OpenJFX, so I
> am returning back to the JavaScript and WHATWG
> with my ongoing research.
> 
> SVG tags were not working out the box
> https://wiki.openjdk.org/display/OpenJFX/Main
> 
> No runLater(), any task can any time modify the DOM!
> https://whatwg.org/
> 
> But maybe there are other GUI frameworks which
> can do it. If tasks are also used for highlighting
> I belive they can be also run asynchronously without
> explicitly juggling with some queues,
> 
> just await the asynchrous routine that the task
> would execute, in a instrumentation loop, and ignore
> the aborts, since an abort is now good news and not
> bad news, it only indicates that
> 
> the end user did an edit and that the task
> will be restartet.

[toc] | [prev] | [next] | [standalone]


#14560 — Dog Shit: Call my name "jan.ai" (Was: Why do IDEs have Power Save mode?)

FromMild Shock <janburse@fastmail.fm>
Date2025-06-17 16:17 +0200
SubjectDog Shit: Call my name "jan.ai" (Was: Why do IDEs have Power Save mode?)
Message-ID<102rtdc$ubej$1@solani.org>
In reply to#14559
Hi,

The fukkers stole my name:

Jan - Local AI Assistant
https://github.com/menloresearch/jan

Bye

P.S.: Meanwhile I am struggling with Quantum Paper
whille doing a dark/light CSS. Look my light olive turned dark
olive, that is somewhere near chocolate or is it dog shit?

P.P.S.: Just figured out yesterday that some browser defaults
are more Motif/OSF than Material/Google, aka Quantum Paper.

Mild Shock schrieb:
> 
> The restart maybe explains why IntelliJ has a
> Power Safe mode, but I am not 100% sure about
> the details. But if the end-user behaviour is
> not compatible with the chosen delays, he might
> 
> tear down the tasks again and again. This could
> use compute power. Some incremental tasks or tasks
> that block (i.e. the "lag") could be a solution.
> Incremental tasks that do only small work and
> 
> not big work, are less perceived as blocking
> (i.e. the lag). But a ghost text that maybe
> involves calling an Artificial Intelligence API
> is probably in nature not a small work task,
> 
> in the sense that it would occupy a short work
> time, the Artificial Intelligence API server
> might be busy and cause a task slow down.
> 
> Disclaimer: I am doing some brain writing here...
> 
> Mild Shock schrieb:
>> Somebody wrote:
>>
>>  > noticeable lag waiting for completion candidates
>>
>> A lag wouldn’t be a problem. I guess the problem
>> is that the GUI gets blocked, right? If your GUI
>> has tasks and timers, you could try the follow:
>>
>> - Debouncing Timer: To start ghost after lets
>>    say 1000 ms, the debouncing is to assure that
>>    the ghost appears after the last edit and not
>>    after the first edit.
>>
>> - Abortable Task: The ghost is then computed
>>    asynchronously via a task. But this task is
>>    again tied to the debouncing, means the task
>>    gets aborted if the end-user shows impatience.
>>
>> I checked a couple of GUI tools to do that. Had
>> rather bad experience with Java and OpenJFX, so I
>> am returning back to the JavaScript and WHATWG
>> with my ongoing research.
>>
>> SVG tags were not working out the box
>> https://wiki.openjdk.org/display/OpenJFX/Main
>>
>> No runLater(), any task can any time modify the DOM!
>> https://whatwg.org/
>>
>> But maybe there are other GUI frameworks which
>> can do it. If tasks are also used for highlighting
>> I belive they can be also run asynchronously without
>> explicitly juggling with some queues,
>>
>> just await the asynchrous routine that the task
>> would execute, in a instrumentation loop, and ignore
>> the aborts, since an abort is now good news and not
>> bad news, it only indicates that
>>
>> the end user did an edit and that the task
>> will be restartet.
> 

[toc] | [prev] | [next] | [standalone]


#14562 — There is no flesh and blood async Prolog! (Was: Dog Shit: Call my name "jan.ai")

FromMild Shock <janburse@fastmail.fm>
Date2025-06-19 14:04 +0200
SubjectThere is no flesh and blood async Prolog! (Was: Dog Shit: Call my name "jan.ai")
Message-ID<1030ubj$10imb$1@solani.org>
In reply to#14560
Hi,

Somebody wrote:

 > Right, but what I’m saying is that with the
 > current implementation as a separate process,
 > running independently of the editor and only
 > communicating over the channel defined by the
 > protocol, the ability to have fine-grained
 > asynchronous communication is limited.

Not my problem not seeking the state of the art. You
need of course a Prolog system that is all flesh
and blood cooperative multitasking. If you want

to do a GUI in Prolog similar like JavaScript
does it now, or a native GUI adapter. And I don't
count Tau-Prolog, although they showed amazing

stuff. But not amazing enough, still based
on continuations, and not based on promises. Or then
async/await. I am not sure what SWI WASM now delivers?

SWI Tinker shows me errors talking about threads when
I use the query background execution feature and if I
abort. But people from cooperative multitasking tend

to not use the terminology "thread", they prefer to
talk about "tasks". Ciao Playground doesn't count either,
since their channels to a background worker can even

not process an interrupt correctly.

Bye

Mild Shock schrieb:
> Hi,
> 
> The fukkers stole my name:
> 
> Jan - Local AI Assistant
> https://github.com/menloresearch/jan
> 
> Bye
> 
> P.S.: Meanwhile I am struggling with Quantum Paper
> whille doing a dark/light CSS. Look my light olive turned dark
> olive, that is somewhere near chocolate or is it dog shit?
> 
> P.P.S.: Just figured out yesterday that some browser defaults
> are more Motif/OSF than Material/Google, aka Quantum Paper.

[toc] | [prev] | [next] | [standalone]


#14563 — When did the Dogelog Player Quantum Leap happen? (Was: There is no flesh and blood async Prolog!)

FromMild Shock <janburse@fastmail.fm>
Date2025-06-19 14:11 +0200
SubjectWhen did the Dogelog Player Quantum Leap happen? (Was: There is no flesh and blood async Prolog!)
Message-ID<1030ups$10ir8$1@solani.org>
In reply to#14562
Hi,

When did the quantum leap happen in Dogelog Player?
Well very early on: The first binary release was here:

ANN: Dogelog Player 0.9.7
The new version 0.9.7 of the Dogelog
player now masters DCG.
Admin User, created 09/06/2025

And '$YIELD'/1 stuff came 9 months (sic!) later:

ANN: Dogelog Player 0.9.8
The Dogelog Player supports a new interpreter
that can relinquish control.
Admin User, created 21/03/2022

See for your self:

https://www.xlog.ch/izytab/doclet/home/12_news/package.html

9 months, like Homo sapiens gestation period. (*)

LoL

Bye

(*) To be frank, it was the perfect pass time during
the COVID-19 pandemic.

Mild Shock schrieb:
> Hi,
> 
> Somebody wrote:
> 
>  > Right, but what I’m saying is that with the
>  > current implementation as a separate process,
>  > running independently of the editor and only
>  > communicating over the channel defined by the
>  > protocol, the ability to have fine-grained
>  > asynchronous communication is limited.
> 
> Not my problem not seeking the state of the art. You
> need of course a Prolog system that is all flesh
> and blood cooperative multitasking. If you want
> 
> to do a GUI in Prolog similar like JavaScript
> does it now, or a native GUI adapter. And I don't
> count Tau-Prolog, although they showed amazing
> 
> stuff. But not amazing enough, still based
> on continuations, and not based on promises. Or then
> async/await. I am not sure what SWI WASM now delivers?
> 
> SWI Tinker shows me errors talking about threads when
> I use the query background execution feature and if I
> abort. But people from cooperative multitasking tend
> 
> to not use the terminology "thread", they prefer to
> talk about "tasks". Ciao Playground doesn't count either,
> since their channels to a background worker can even
> 
> not process an interrupt correctly.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> The fukkers stole my name:
>>
>> Jan - Local AI Assistant
>> https://github.com/menloresearch/jan
>>
>> Bye
>>
>> P.S.: Meanwhile I am struggling with Quantum Paper
>> whille doing a dark/light CSS. Look my light olive turned dark
>> olive, that is somewhere near chocolate or is it dog shit?
>>
>> P.P.S.: Just figured out yesterday that some browser defaults
>> are more Motif/OSF than Material/Google, aka Quantum Paper.

[toc] | [prev] | [next] | [standalone]


#14564 — Main problem with simulated “threads” (Was: When did the Dogelog Player Quantum Leap happen?)

FromMild Shock <janburse@fastmail.fm>
Date2025-06-19 14:26 +0200
SubjectMain problem with simulated “threads” (Was: When did the Dogelog Player Quantum Leap happen?)
Message-ID<1030vm8$10j9c$1@solani.org>
In reply to#14563
I wasted a half dozen months with simulated
“threads” by using CheerpJ. This was a very
interesting experience, I could run formerly
Jekejeke Prolog written in Java inside JavaScript.

Main problem a simulation of “threads” cannot
use certain GUI programming patterns from
JavaScript. Because then you have still pre-emptive
yield, like if you do it with auto-yield.

But in JavaScript you have critical regions
for free, just between two awaits, there will
be no yield. Such properties might impact how
you model your “concurrent” logic.

This puts some weight on having a shield/1
primitive. The CheerpJ threads were not that
bad, I added auto yield, but shield/1 is a
later invention from Dogelog Player.

Mild Shock schrieb:
> Hi,
> 
> When did the quantum leap happen in Dogelog Player?
> Well very early on: The first binary release was here:
> 
> ANN: Dogelog Player 0.9.7
> The new version 0.9.7 of the Dogelog
> player now masters DCG.
> Admin User, created 09/06/2025
> 
> And '$YIELD'/1 stuff came 9 months (sic!) later:
> 
> ANN: Dogelog Player 0.9.8
> The Dogelog Player supports a new interpreter
> that can relinquish control.
> Admin User, created 21/03/2022
> 
> See for your self:
> 
> https://www.xlog.ch/izytab/doclet/home/12_news/package.html
> 
> 9 months, like Homo sapiens gestation period. (*)
> 
> LoL
> 
> Bye
> 
> (*) To be frank, it was the perfect pass time during
> the COVID-19 pandemic.
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Somebody wrote:
>>
>>  > Right, but what I’m saying is that with the
>>  > current implementation as a separate process,
>>  > running independently of the editor and only
>>  > communicating over the channel defined by the
>>  > protocol, the ability to have fine-grained
>>  > asynchronous communication is limited.
>>
>> Not my problem not seeking the state of the art. You
>> need of course a Prolog system that is all flesh
>> and blood cooperative multitasking. If you want
>>
>> to do a GUI in Prolog similar like JavaScript
>> does it now, or a native GUI adapter. And I don't
>> count Tau-Prolog, although they showed amazing
>>
>> stuff. But not amazing enough, still based
>> on continuations, and not based on promises. Or then
>> async/await. I am not sure what SWI WASM now delivers?
>>
>> SWI Tinker shows me errors talking about threads when
>> I use the query background execution feature and if I
>> abort. But people from cooperative multitasking tend
>>
>> to not use the terminology "thread", they prefer to
>> talk about "tasks". Ciao Playground doesn't count either,
>> since their channels to a background worker can even
>>
>> not process an interrupt correctly.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> The fukkers stole my name:
>>>
>>> Jan - Local AI Assistant
>>> https://github.com/menloresearch/jan
>>>
>>> Bye
>>>
>>> P.S.: Meanwhile I am struggling with Quantum Paper
>>> whille doing a dark/light CSS. Look my light olive turned dark
>>> olive, that is somewhere near chocolate or is it dog shit?
>>>
>>> P.P.S.: Just figured out yesterday that some browser defaults
>>> are more Motif/OSF than Material/Google, aka Quantum Paper.
> 

[toc] | [prev] | [next] | [standalone]


#14565 — Time Sharing: Martin Richards, Ken Thompson and Linus Torvalds

FromMild Shock <janburse@fastmail.fm>
Date2025-06-19 14:38 +0200
SubjectTime Sharing: Martin Richards, Ken Thompson and Linus Torvalds
Message-ID<10310cj$10jlf$1@solani.org>
In reply to#14564
Hi,

Threads are just a variant of processes that
share a heap, which can be the bottleneck. Processes
are good for time sharing systems. Some history:

How it started, support small CPUs:

TRIPOS (TRIvial Portable Operating System)
https://en.wikipedia.org/wiki/TRIPOS

How it is going, more small CPUs excitement:

The Origins of Linux—Linus Torvalds
https://www.youtube.com/watch?v=WVTWCPoUt8w

But what about GUI programming, or even web
servers database access? Threads have massively
fallen back with other models mainly through

JavaScript, in the GUI via the browser and
on the server via node.js. So don't be fooled
by multi-threading Prolog systems,

could be a complete nonsense...

Mild Shock schrieb:
> 
> I wasted a half dozen months with simulated
> “threads” by using CheerpJ. This was a very
> interesting experience, I could run formerly
> Jekejeke Prolog written in Java inside JavaScript.
> 
> Main problem a simulation of “threads” cannot
> use certain GUI programming patterns from
> JavaScript. Because then you have still pre-emptive
> yield, like if you do it with auto-yield.
> 
> But in JavaScript you have critical regions
> for free, just between two awaits, there will
> be no yield. Such properties might impact how
> you model your “concurrent” logic.
> 
> This puts some weight on having a shield/1
> primitive. The CheerpJ threads were not that
> bad, I added auto yield, but shield/1 is a
> later invention from Dogelog Player.
> 
> Mild Shock schrieb:
>> Hi,
>>
>> When did the quantum leap happen in Dogelog Player?
>> Well very early on: The first binary release was here:
>>
>> ANN: Dogelog Player 0.9.7
>> The new version 0.9.7 of the Dogelog
>> player now masters DCG.
>> Admin User, created 09/06/2025
>>
>> And '$YIELD'/1 stuff came 9 months (sic!) later:
>>
>> ANN: Dogelog Player 0.9.8
>> The Dogelog Player supports a new interpreter
>> that can relinquish control.
>> Admin User, created 21/03/2022
>>
>> See for your self:
>>
>> https://www.xlog.ch/izytab/doclet/home/12_news/package.html
>>
>> 9 months, like Homo sapiens gestation period. (*)
>>
>> LoL
>>
>> Bye
>>
>> (*) To be frank, it was the perfect pass time during
>> the COVID-19 pandemic.
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Somebody wrote:
>>>
>>>  > Right, but what I’m saying is that with the
>>>  > current implementation as a separate process,
>>>  > running independently of the editor and only
>>>  > communicating over the channel defined by the
>>>  > protocol, the ability to have fine-grained
>>>  > asynchronous communication is limited.
>>>
>>> Not my problem not seeking the state of the art. You
>>> need of course a Prolog system that is all flesh
>>> and blood cooperative multitasking. If you want
>>>
>>> to do a GUI in Prolog similar like JavaScript
>>> does it now, or a native GUI adapter. And I don't
>>> count Tau-Prolog, although they showed amazing
>>>
>>> stuff. But not amazing enough, still based
>>> on continuations, and not based on promises. Or then
>>> async/await. I am not sure what SWI WASM now delivers?
>>>
>>> SWI Tinker shows me errors talking about threads when
>>> I use the query background execution feature and if I
>>> abort. But people from cooperative multitasking tend
>>>
>>> to not use the terminology "thread", they prefer to
>>> talk about "tasks". Ciao Playground doesn't count either,
>>> since their channels to a background worker can even
>>>
>>> not process an interrupt correctly.
>>>
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> The fukkers stole my name:
>>>>
>>>> Jan - Local AI Assistant
>>>> https://github.com/menloresearch/jan
>>>>
>>>> Bye
>>>>
>>>> P.S.: Meanwhile I am struggling with Quantum Paper
>>>> whille doing a dark/light CSS. Look my light olive turned dark
>>>> olive, that is somewhere near chocolate or is it dog shit?
>>>>
>>>> P.P.S.: Just figured out yesterday that some browser defaults
>>>> are more Motif/OSF than Material/Google, aka Quantum Paper.
>>
> 

[toc] | [prev] | [next] | [standalone]


#14566 — <parallel> Ant Task doesn't need threads (Was: Time Sharing: Martin Richards, Ken Thompson and Linus Torvalds)

FromMild Shock <janburse@fastmail.fm>
Date2025-06-19 14:54 +0200
Subject<parallel> Ant Task doesn't need threads (Was: Time Sharing: Martin Richards, Ken Thompson and Linus Torvalds)
Message-ID<103119s$10k4j$1@solani.org>
In reply to#14565
Hi,

I find fewer and fewer use cases for threads.
Here some fun with <parallel> Ant Task:

     <target name="dogelog_transpile">
         <parallel>
             <ant dir="../player/cross"
                  antfile="run.xml"/>
             <ant dir="../playerpy/cross"
                  antfile="run.xml"/>
             <ant dir="../playerj/cross"
                  antfile="run.xml"/>
         </parallel>
     </target>

Transpiling Dogelog Player in parallel. Except
for a totally broken Ant log file, works
smooth and shows a solid speed up. Although everything

is heavily forked and possibly processes. I assume
Ant offers tries to use threads, back from the time
Java people were proud of their threads,

but it nowadays with high speed solid state disks
and large memory capacity, it doesn't make a dent anymore.

LoL

Bye

P.S.: No GitHub Actions nonsense allowed here. Although
matrix build looks interesting. Its possibly to uniform
paralleliz. Unfortunately I have cases where I mix <parallel>

with <sequential> in ant task. And for the lazy ones there
is <macrodef> . What I didn't try yet is a better logger,
it seems Gradel would provide that? One could have a DOM

as Log datastructure, before the log gets committed.
Simulating the mailboxes of SWI-Prolog message system.
But the idea of "mailboxes" already indicate messages would

leave process borders. Thank god I have delegated everything
to Ant, don't need to make my hands dirty here.


Mild Shock schrieb:
> Hi,
> 
> Threads are just a variant of processes that
> share a heap, which can be the bottleneck. Processes
> are good for time sharing systems. Some history:
> 
> How it started, support small CPUs:
> 
> TRIPOS (TRIvial Portable Operating System)
> https://en.wikipedia.org/wiki/TRIPOS
> 
> How it is going, more small CPUs excitement:
> 
> The Origins of Linux—Linus Torvalds
> https://www.youtube.com/watch?v=WVTWCPoUt8w
> 
> But what about GUI programming, or even web
> servers database access? Threads have massively
> fallen back with other models mainly through
> 
> JavaScript, in the GUI via the browser and
> on the server via node.js. So don't be fooled
> by multi-threading Prolog systems,
> 
> could be a complete nonsense...
> 
> Mild Shock schrieb:
>>
>> I wasted a half dozen months with simulated
>> “threads” by using CheerpJ. This was a very
>> interesting experience, I could run formerly
>> Jekejeke Prolog written in Java inside JavaScript.
>>
>> Main problem a simulation of “threads” cannot
>> use certain GUI programming patterns from
>> JavaScript. Because then you have still pre-emptive
>> yield, like if you do it with auto-yield.
>>
>> But in JavaScript you have critical regions
>> for free, just between two awaits, there will
>> be no yield. Such properties might impact how
>> you model your “concurrent” logic.
>>
>> This puts some weight on having a shield/1
>> primitive. The CheerpJ threads were not that
>> bad, I added auto yield, but shield/1 is a
>> later invention from Dogelog Player.
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> When did the quantum leap happen in Dogelog Player?
>>> Well very early on: The first binary release was here:
>>>
>>> ANN: Dogelog Player 0.9.7
>>> The new version 0.9.7 of the Dogelog
>>> player now masters DCG.
>>> Admin User, created 09/06/2025
>>>
>>> And '$YIELD'/1 stuff came 9 months (sic!) later:
>>>
>>> ANN: Dogelog Player 0.9.8
>>> The Dogelog Player supports a new interpreter
>>> that can relinquish control.
>>> Admin User, created 21/03/2022
>>>
>>> See for your self:
>>>
>>> https://www.xlog.ch/izytab/doclet/home/12_news/package.html
>>>
>>> 9 months, like Homo sapiens gestation period. (*)
>>>
>>> LoL
>>>
>>> Bye
>>>
>>> (*) To be frank, it was the perfect pass time during
>>> the COVID-19 pandemic.
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> Somebody wrote:
>>>>
>>>>  > Right, but what I’m saying is that with the
>>>>  > current implementation as a separate process,
>>>>  > running independently of the editor and only
>>>>  > communicating over the channel defined by the
>>>>  > protocol, the ability to have fine-grained
>>>>  > asynchronous communication is limited.
>>>>
>>>> Not my problem not seeking the state of the art. You
>>>> need of course a Prolog system that is all flesh
>>>> and blood cooperative multitasking. If you want
>>>>
>>>> to do a GUI in Prolog similar like JavaScript
>>>> does it now, or a native GUI adapter. And I don't
>>>> count Tau-Prolog, although they showed amazing
>>>>
>>>> stuff. But not amazing enough, still based
>>>> on continuations, and not based on promises. Or then
>>>> async/await. I am not sure what SWI WASM now delivers?
>>>>
>>>> SWI Tinker shows me errors talking about threads when
>>>> I use the query background execution feature and if I
>>>> abort. But people from cooperative multitasking tend
>>>>
>>>> to not use the terminology "thread", they prefer to
>>>> talk about "tasks". Ciao Playground doesn't count either,
>>>> since their channels to a background worker can even
>>>>
>>>> not process an interrupt correctly.
>>>>
>>>> Bye
>>>>
>>>> Mild Shock schrieb:
>>>>> Hi,
>>>>>
>>>>> The fukkers stole my name:
>>>>>
>>>>> Jan - Local AI Assistant
>>>>> https://github.com/menloresearch/jan
>>>>>
>>>>> Bye
>>>>>
>>>>> P.S.: Meanwhile I am struggling with Quantum Paper
>>>>> whille doing a dark/light CSS. Look my light olive turned dark
>>>>> olive, that is somewhere near chocolate or is it dog shit?
>>>>>
>>>>> P.P.S.: Just figured out yesterday that some browser defaults
>>>>> are more Motif/OSF than Material/Google, aka Quantum Paper.
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]


#14567 — Corr.: wrong date, should read 2021 (Was: When did the Dogelog Player Quantum Leap happen?)

FromMild Shock <janburse@fastmail.fm>
Date2025-06-19 17:47 +0200
SubjectCorr.: wrong date, should read 2021 (Was: When did the Dogelog Player Quantum Leap happen?)
Message-ID<1031be5$11fjh$1@solani.org>
In reply to#14563
Corr.: wrong date, should read 2021 here:

 > ANN: Dogelog Player 0.9.7
 > The new version 0.9.7 of the Dogelog
 > player now masters DCG.
 > Admin User, created 09/06/2025

The date was this:

Admin User, created 09/06/2021

Mild Shock schrieb:
> Hi,
> 
> When did the quantum leap happen in Dogelog Player?
> Well very early on: The first binary release was here:
> 
> ANN: Dogelog Player 0.9.7
> The new version 0.9.7 of the Dogelog
> player now masters DCG.
> Admin User, created 09/06/2025
> 
> And '$YIELD'/1 stuff came 9 months (sic!) later:
> 
> ANN: Dogelog Player 0.9.8
> The Dogelog Player supports a new interpreter
> that can relinquish control.
> Admin User, created 21/03/2022
> 
> See for your self:
> 
> https://www.xlog.ch/izytab/doclet/home/12_news/package.html
> 
> 9 months, like Homo sapiens gestation period. (*)
> 
> LoL
> 
> Bye
> 
> (*) To be frank, it was the perfect pass time during
> the COVID-19 pandemic.
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Somebody wrote:
>>
>>  > Right, but what I’m saying is that with the
>>  > current implementation as a separate process,
>>  > running independently of the editor and only
>>  > communicating over the channel defined by the
>>  > protocol, the ability to have fine-grained
>>  > asynchronous communication is limited.
>>
>> Not my problem not seeking the state of the art. You
>> need of course a Prolog system that is all flesh
>> and blood cooperative multitasking. If you want
>>
>> to do a GUI in Prolog similar like JavaScript
>> does it now, or a native GUI adapter. And I don't
>> count Tau-Prolog, although they showed amazing
>>
>> stuff. But not amazing enough, still based
>> on continuations, and not based on promises. Or then
>> async/await. I am not sure what SWI WASM now delivers?
>>
>> SWI Tinker shows me errors talking about threads when
>> I use the query background execution feature and if I
>> abort. But people from cooperative multitasking tend
>>
>> to not use the terminology "thread", they prefer to
>> talk about "tasks". Ciao Playground doesn't count either,
>> since their channels to a background worker can even
>>
>> not process an interrupt correctly.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> The fukkers stole my name:
>>>
>>> Jan - Local AI Assistant
>>> https://github.com/menloresearch/jan
>>>
>>> Bye
>>>
>>> P.S.: Meanwhile I am struggling with Quantum Paper
>>> whille doing a dark/light CSS. Look my light olive turned dark
>>> olive, that is somewhere near chocolate or is it dog shit?
>>>
>>> P.P.S.: Just figured out yesterday that some browser defaults
>>> are more Motif/OSF than Material/Google, aka Quantum Paper.
> 

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.prolog


csiph-web