Wao! I love coding so much, maybe should jump
into no-coding. How would I setup my computer
and have myself better skills, so that I would

do no-coding. Like the current project I am
wroking on. A ChatGPT AI would first need to
have a model/context of my current project.

And then maybe I could sit back, ask it:
Please do this for me, please do that for me.
Which would be on second thought quite swell!

Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:11:50 UTC+2:
> Today I had for some minutes a strong feeling
> of obsolence, was even imagining that these could
> be my last days where I write some "program code".
>
> This happened after I saw ChatGPT doing logic.
> Although was reading about "Low Code / No Code"
> already for a while. So which profession gets hit first?
>
> Profiles of the future : an inquiry into the limits of the possible
> Arthur C. Clarke - 1962, Chapter 18: The Obsolence of Man
> https://archive.org/details/profilesoffuture00clar/page/222/mode/2up
>
> Arthur C. Clarke talks
> A Space Odyssey and artificial intelligence, 1968
> https://www.youtube.com/watch?v=zNJbUYD-pfo
> Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:10:34 UTC+2:
> > June, 2023 Update: It might be the case, that ChatGPT has improved
> > in logic. Here it does even modal logic, and you can ask it to produce
> > proofs without LEM. ChatGPT does the following tasks:
> >
> > Here’s how you can translate the proof into natural deduction:
> > Here’s an alternative proof that does not rely on LEM:
> > Here’s the translation of the proof into Fitch-style natural deduction:
> > Here’s the translation of the proof into Gentzen’s tree-style natural deduction:
> > Here’s the translation of the proof into sequent-style natural deduction:
> > https://chat.openai.com/share/79ae4f02-fd07-4786-800b-305bc9eed143

The ChatGPT template above was not done by me. Credits
go to Joseph Vidal-Rosset. That conversations and thus interaction
specific context and mini learnt model extensions can be

shared via share links seems to be a new feature of ChatGPT.
I saw this feature appear only yesterday in ChatGPT.

See also:
https://help.openai.com/en/articles/7925741-chatgpt-shared-links-faq

Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:10:34 UTC+2:
> June, 2023 Update: It might be the case, that ChatGPT has improved
> in logic. Here it does even modal logic, and you can ask it to produce
> proofs without LEM. ChatGPT does the following tasks:
>
> Here’s how you can translate the proof into natural deduction:
> Here’s an alternative proof that does not rely on LEM:
> Here’s the translation of the proof into Fitch-style natural deduction:
> Here’s the translation of the proof into Gentzen’s tree-style natural deduction:
> Here’s the translation of the proof into sequent-style natural deduction:
> https://chat.openai.com/share/79ae4f02-fd07-4786-800b-305bc9eed143

So its just a matter of time, like months or weeks,
and we have ChatGPT integrated in IDEs at
our desktop, coding help at our fingertips:

"In line with our iterative deployment philosophy,
we are gradually rolling out plugins in ChatGPT
so we can study their real-world use, impact, and
safety and alignment challenges—all of which
we’ll have to get right in order to achieve our mission."
https://openai.com/blog/chatgpt-plugins

They are quite on mission. This will suplant GitHub
Copilot? Well doesn't matter GitHub Copilot uses
also OpenAI Codex. But in March 2023, OpenAI shut
down access to Codex, but I guess they didn't do

it for some moratorium, they have a better replacement:

"On March 23rd, we will discontinue support for the
Codex API. All customers will have to transition to a
different model. Codex was initially introduced as a
free limited beta in 2021, and has maintained

that status to date. Given the advancements of our
newest GPT-3.5 models for coding tasks, we will no
longer be supporting Codex and encourage all customers
to transition to GPT-3.5-Turbo.

About GPT-3.5-Turbo GPT-3.5-Turbo is the most
cost effective and performant model in the GPT-3.5
family. It can both do coding tasks while also being
complemented with flexible natural language capabilities."
https://news.ycombinator.com/item?id=35242069

Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:17:48 UTC+2:
> Wao! I love coding so much, maybe should jump
> into no-coding. How would I setup my computer
> and have myself better skills, so that I would
>
> do no-coding. Like the current project I am
> wroking on. A ChatGPT AI would first need to
> have a model/context of my current project.
>
> And then maybe I could sit back, ask it:
> Please do this for me, please do that for me.
> Which would be on second thought quite swell!
> Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:11:50 UTC+2:
> > Today I had for some minutes a strong feeling
> > of obsolence, was even imagining that these could
> > be my last days where I write some "program code".
> >
> > This happened after I saw ChatGPT doing logic.
> > Although was reading about "Low Code / No Code"
> > already for a while. So which profession gets hit first?
> >
> > Profiles of the future : an inquiry into the limits of the possible
> > Arthur C. Clarke - 1962, Chapter 18: The Obsolence of Man
> > https://archive.org/details/profilesoffuture00clar/page/222/mode/2up
> >
> > Arthur C. Clarke talks
> > A Space Odyssey and artificial intelligence, 1968
> > https://www.youtube.com/watch?v=zNJbUYD-pfo
> > Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:10:34 UTC+2:
> > > June, 2023 Update: It might be the case, that ChatGPT has improved
> > > in logic. Here it does even modal logic, and you can ask it to produce
> > > proofs without LEM. ChatGPT does the following tasks:
> > >
> > > Here’s how you can translate the proof into natural deduction:
> > > Here’s an alternative proof that does not rely on LEM:
> > > Here’s the translation of the proof into Fitch-style natural deduction:
> > > Here’s the translation of the proof into Gentzen’s tree-style natural deduction:
> > > Here’s the translation of the proof into sequent-style natural deduction:
> > > https://chat.openai.com/share/79ae4f02-fd07-4786-800b-305bc9eed143

Interestingly there are supposedly ChatGPT
plugins with real-time information integration.
A browser ChatGPT plugin for example:

Unleashing the Power of AI Conversations
https://www.youtube.com/watch?v=L2RW4qx-45Q

Mild Shock schrieb am Samstag, 3. Juni 2023 um 14:20:06 UTC+2:
> So its just a matter of time, like months or weeks,
> and we have ChatGPT integrated in IDEs at
> our desktop, coding help at our fingertips:
>
> "In line with our iterative deployment philosophy,
> we are gradually rolling out plugins in ChatGPT
> so we can study their real-world use, impact, and
> safety and alignment challenges—all of which
> we’ll have to get right in order to achieve our mission."
> https://openai.com/blog/chatgpt-plugins
>
> They are quite on mission. This will suplant GitHub
> Copilot? Well doesn't matter GitHub Copilot uses
> also OpenAI Codex. But in March 2023, OpenAI shut
> down access to Codex, but I guess they didn't do
>
> it for some moratorium, they have a better replacement:
>
> "On March 23rd, we will discontinue support for the
> Codex API. All customers will have to transition to a
> different model. Codex was initially introduced as a
> free limited beta in 2021, and has maintained
>
> that status to date. Given the advancements of our
> newest GPT-3.5 models for coding tasks, we will no
> longer be supporting Codex and encourage all customers
> to transition to GPT-3.5-Turbo.
>
> About GPT-3.5-Turbo GPT-3.5-Turbo is the most
> cost effective and performant model in the GPT-3.5
> family. It can both do coding tasks while also being
> complemented with flexible natural language capabilities."
> https://news.ycombinator.com/item?id=35242069
> Mild Shock schrieb am Donnerstag, 1. Juni 2023 um 23:17:48 UTC+2:

Can SWI-Prolog lean back concerning multi-threading? The
Python store looks like a nice piece of darwinism. So there is some
evolutionary pressure through some selection mechanism:

> Allen Goodman, author of CellProfiler and staff engineer at
Prescient Design and Genentech, describes how the GIL makes
biological methods research more difficult in Python.

So basically Python starts lacking behind as the datascience language.
Oh the irony. But I would not blame it so much on the GIL. Deep down many
programming languages have still a GIL,

for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
because they started optimizing their virtual machine for multi-threaded.

Such optiminzations do not only consists of removing the GIL, you
need optimize malloc(). Some approaches uses thread affine memory
areas, but this is also tricky, since not all objects have a clear thread affinity.

In as far, concerning thread affinity, one has to also watch what happens
concerning JavaScript Worker concept adoptions in Python. Multi-threading
can be optimized even more If you have such isolation concepts.

In this respect there is also PEP 683 – Immortal Objects, which on the
surface might not be related, but it also relates to the effort to better handle
strings and make a GIL per-interpreter, the later could underly Workers.

Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2:
> Can SWI-Prolog lean back concerning multi-threading? The
> Python store looks like a nice piece of darwinism. So there is some
> evolutionary pressure through some selection mechanism:
>
> > Allen Goodman, author of CellProfiler and staff engineer at
> Prescient Design and Genentech, describes how the GIL makes
> biological methods research more difficult in Python.
>
> So basically Python starts lacking behind as the datascience language.
> Oh the irony. But I would not blame it so much on the GIL. Deep down many
> programming languages have still a GIL,
>
> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
> because they started optimizing their virtual machine for multi-threaded.
>
> Such optiminzations do not only consists of removing the GIL, you
> need optimize malloc(). Some approaches uses thread affine memory
> areas, but this is also tricky, since not all objects have a clear thread affinity.

There are a couple of non-GIL Pythons already
around. For example Jython 2.7.3. But they are
currently busy with migrating from Python 2 to Python 3.

For example I cannot use it, it didn’t understand
the “async” keyword. Async/await was introduced in
Python version 3.5. There are more such no-GIL Pythons,

like IronPython (for CLR) and GraalVM Python (for JVM).
GraalVM Python is farther ahead, it supports Python 3.8,
but is slower than PyPy. But with IronPython, one would

also have less luck, its only Python 3.4 now.

Mild Shock schrieb:
> In as far, concerning thread affinity, one has to also watch what happens
> concerning JavaScript Worker concept adoptions in Python. Multi-threading
> can be optimized even more If you have such isolation concepts.
>
> In this respect there is also PEP 683 – Immortal Objects, which on the
> surface might not be related, but it also relates to the effort to better handle
> strings and make a GIL per-interpreter, the later could underly Workers.
>
> Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2:
>> Can SWI-Prolog lean back concerning multi-threading? The
>> Python store looks like a nice piece of darwinism. So there is some
>> evolutionary pressure through some selection mechanism:
>>
>>> Allen Goodman, author of CellProfiler and staff engineer at
>> Prescient Design and Genentech, describes how the GIL makes
>> biological methods research more difficult in Python.
>>
>> So basically Python starts lacking behind as the datascience language.
>> Oh the irony. But I would not blame it so much on the GIL. Deep down many
>> programming languages have still a GIL,
>>
>> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
>> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
>> because they started optimizing their virtual machine for multi-threaded.
>>
>> Such optiminzations do not only consists of removing the GIL, you
>> need optimize malloc(). Some approaches uses thread affine memory
>> areas, but this is also tricky, since not all objects have a clear thread affinity.

Whats quite interesting, is that PyPy, one of the fastest Pythons,
isn’t based on ARC LLVM. i.e. Automatic Reference Counting (ARC).
One effect is that dead objects, might be detected a little later

than via reference counting, so it is recommended to explicitly
close resources such as files, and not rely on reference counting.
Having no reference counting, does also help multi-threading.

So in PyPy there is no PL_register_atom or PL_unregister_atom.
Memory systems without reference counting are usually associated
with tracing garbage collectors, based on two color mark sweep.

But I guess they get more bang out of it, if incremental garbage
collection is deployed and if some escape analysis of the code
is performed as well. Have to find a paper.

Mild Shock schrieb am Samstag, 29. Juli 2023 um 23:16:41 UTC+2:
> There are a couple of non-GIL Pythons already
> around. For example Jython 2.7.3. But they are
> currently busy with migrating from Python 2 to Python 3.
>
> For example I cannot use it, it didn’t understand
> the “async” keyword. Async/await was introduced in
> Python version 3.5. There are more such no-GIL Pythons,
>
> like IronPython (for CLR) and GraalVM Python (for JVM).
> GraalVM Python is farther ahead, it supports Python 3.8,
> but is slower than PyPy. But with IronPython, one would
>
> also have less luck, its only Python 3.4 now.
>
> Mild Shock schrieb:
> > In as far, concerning thread affinity, one has to also watch what happens
> > concerning JavaScript Worker concept adoptions in Python. Multi-threading
> > can be optimized even more If you have such isolation concepts.
> >
> > In this respect there is also PEP 683 – Immortal Objects, which on the
> > surface might not be related, but it also relates to the effort to better handle
> > strings and make a GIL per-interpreter, the later could underly Workers..
> >
> > Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2:
> >> Can SWI-Prolog lean back concerning multi-threading? The
> >> Python store looks like a nice piece of darwinism. So there is some
> >> evolutionary pressure through some selection mechanism:
> >>
> >>> Allen Goodman, author of CellProfiler and staff engineer at
> >> Prescient Design and Genentech, describes how the GIL makes
> >> biological methods research more difficult in Python.
> >>
> >> So basically Python starts lacking behind as the datascience language.
> >> Oh the irony. But I would not blame it so much on the GIL. Deep down many
> >> programming languages have still a GIL,
> >>
> >> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
> >> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
> >> because they started optimizing their virtual machine for multi-threaded.
> >>
> >> Such optiminzations do not only consists of removing the GIL, you
> >> need optimize malloc(). Some approaches uses thread affine memory
> >> areas, but this is also tricky, since not all objects have a clear thread affinity.

Why will this never fly?

https://www.swi-prolog.org/howto/http/

Because its too static. For example the
recent SVG example:

reply_html_page(title('SVG circle'),
Etc...

Looks a little pointless to me. Since its static,
You could store an `.svg` file on the server.
How do you draw 12 circles into SVG?

Computed into a grid of 3 x 4 via Prolog?
Make the number of columns and rows
a parameter to a Prolog predicate.

Mostowski Collapse <bursejan@gmail.com> writes:

> For Scryer Prolog the struggle is minutely documented:
>
> Compiling and running scryer as a WebAssembly binary?
> https://github.com/mthom/scryer-prolog/issues/615

Good news everyone: It's now possible to compile Scryer Prolog to WASM,
the build instructions are here:

https://github.com/mthom/scryer-prolog/pull/1966#issuecomment-1697974614

Enjoy!

All the best,
Markus

--
comp.lang.prolog FAQ: http://www.logic.at/prolog/faq/
The Power of Prolog: https://www.metalevel.at/prolog

What can you demonstrate with your Scryer WASM?

Ok, I just see, I have nevertheless published my new Chinese
Remainder Theorem CLP(FD) solver, it even runs in a web page.
As a Dogelog Player program its a little slower than the 0.5 secs

in formerly Jekejeke Prolog, but its still faster than the ordinary
CLP(FD) in SWI-Prolog, which takes around 5 seconds. The web
page with the new CLP(FD) takes around 3 seconds,

you can try it here in JS FIiddle, it should also use Dogelog Player 1.1.1:

Example 71: Diophantine Modular
X = 216, Y = 52, Z = 217;
X = 52, Y = 216, Z = 217;
fail.
% Zeit 3574 ms, GC 7 ms, Lips 1696084, Uhr 01.09.2023 20:56 true.
https://jsfiddle.net/Jean_Luc_Picard_2021/d2njehtp/3/

Woa! It still runs unchanged, the code from 12 Months ago.

Markus Triska schrieb am Donnerstag, 31. August 2023 um 21:25:51 UTC+2:
> Mostowski Collapse <burs...@gmail.com> writes:
>
> > For Scryer Prolog the struggle is minutely documented:
> >
> > Compiling and running scryer as a WebAssembly binary?
> > https://github.com/mthom/scryer-prolog/issues/615
>
> Good news everyone: It's now possible to compile Scryer Prolog to WASM,
> the build instructions are here:
>
> https://github.com/mthom/scryer-prolog/pull/1966#issuecomment-1697974614
>
> Enjoy!
>
> All the best,
> Markus
>
> --
> comp.lang.prolog FAQ: http://www.logic.at/prolog/faq/
> The Power of Prolog: https://www.metalevel.at/prolog

Yeah today I created a ticket in GitHub issues.
Now I need to take a SPA nap:

Cute Kitten Really Enjoys SPA
https://www.youtube.com/watch?v=L7lVrWY9zQE

P.S.: No wonder Scryer Prolog has 242 tickets:
https://github.com/mthom/scryer-prolog/issues

Mostowski Collapse schrieb:
> Rounding still not fixed in Scryer Prolog. Look
> what a nice test case I am using:
>
> ?- atom_integer(X, 2, 166153499473114502559719956244594689).
> X = '1000000000000000000000000000000000000000
> 000000000000010000000000000000000000000000000
> 000000000000000000000000000000001'.
>
> And whats the result:
>
> $ target/release/scryer-prolog -v
> "v0.9.1-151-g17450520"
> $ target/release/scryer-prolog
> ?- X is float(166153499473114502559719956244594689).
> X = 1.661534994731145e35.
> ?- Y = 1.6615349947311452e+35.
> Y = 1.6615349947311452e35.
> ?- X is float(166153499473114502559719956244594689)-1.6615349947311452e+35.
> X = -3.6893488147419103e19.
> ?-
>
> Its not correctly rounded!
>

Or maybe its a seasonal effect related to Springtime lethargy.
https://en.wikipedia.org/wiki/Springtime_lethargy.

Mild Shock schrieb:
> Yeah today I created a ticket in GitHub issues.
> Now I need to take a SPA nap:
>
> Cute Kitten Really Enjoys SPA
> https://www.youtube.com/watch?v=L7lVrWY9zQE
>
> P.S.: No wonder Scryer Prolog has 242 tickets:
> https://github.com/mthom/scryer-prolog/issues
>
> Mostowski Collapse schrieb:
>> Rounding still not fixed in Scryer Prolog. Look
>> what a nice test case I am using:
>>
>> ?- atom_integer(X, 2, 166153499473114502559719956244594689).
>> X = '1000000000000000000000000000000000000000
>> 000000000000010000000000000000000000000000000
>> 000000000000000000000000000000001'.
>>
>> And whats the result:
>>
>> $ target/release/scryer-prolog -v
>> "v0.9.1-151-g17450520"
>> $ target/release/scryer-prolog
>> ?- X is float(166153499473114502559719956244594689).
>>     X = 1.661534994731145e35.
>> ?- Y = 1.6615349947311452e+35.
>>     Y = 1.6615349947311452e35.
>> ?- X is
>> float(166153499473114502559719956244594689)-1.6615349947311452e+35.
>>     X = -3.6893488147419103e19.
>> ?-
>>
>> Its not correctly rounded!
>>
>

Remembering Joe Armstrong - 20. April 2024:
https://www.heise.de/news/Hello-Mike-hello-Robert-goodbye-Joe-Zum-Tode-von-Joe-Armstrong-4404170.html

Some quote:

"Make it work, then make it beautiful, then
if you really, really have to, make it fast.

90% of the time, if you make it beautiful,
it will already be fast.

So really, just make it beautiful!
-Joe Armstrong, Erlang"

Now I have a couple of questions:
- Was Jekejeke beautiful? [No! LoL]
- Is Trealla beautiful?
- Is Scryer beautiful?
- Is Dogelog beautiful? [Yes! LoL]
- Is SWI-Prolog beautiful?
- Is GNU Prolog beautiful?
- Is ECLiPSe Prolog beautiful?
- Is XSB Prolog beautiful?
- Is SICStus Prolog beautiful?
- Etc..

Hey Scryer Prolog, whats up?
Why the tooltip "Artificial Intelligence" over "AI"

Scryer Prolog Meetup 2024
https://www.digitalaustria.gv.at/eng/insights/Digital-Austria-Events-EN/Scryer-Prolog-Meetup-2024.html

What does AI mean in Austria, Austrian Idiotism?
Why don't you simply write:

Artificial Inteligence (AI) in the first occurence,
then in every other occurence you can write AI.
And then the thingy gets also printable.

Mild Shock schrieb:
> Remembering Joe Armstrong - 20. April 2024:
> https://www.heise.de/news/Hello-Mike-hello-Robert-goodbye-Joe-Zum-Tode-von-Joe-Armstrong-4404170.html
>
>
> Some quote:
>
> "Make it work, then make it beautiful, then
> if you really, really have to, make it fast.
>
> 90% of the time, if you make it beautiful,
> it will already be fast.
>
> So really, just make it beautiful!
> -Joe Armstrong, Erlang"
>
>
> Now I have a couple of questions:
> - Was Jekejeke beautiful? [No! LoL]
> - Is Trealla beautiful?
> - Is Scryer beautiful?
> - Is Dogelog beautiful? [Yes! LoL]
> - Is SWI-Prolog beautiful?
> - Is GNU Prolog beautiful?
> - Is ECLiPSe Prolog beautiful?
> - Is XSB Prolog beautiful?
> - Is SICStus Prolog beautiful?
> - Etc..
>
>
>