Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.prolog > #14615
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Newsgroups | comp.lang.prolog |
| Subject | General Magic didn't predict the Future (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0]) |
| Date | 2025-07-02 10:07 +0200 |
| Message-ID | <1042pba$1kf2i$1@solani.org> (permalink) |
| References | <vrkadh$7arh$1@solani.org> <1042nbf$1kdle$1@solani.org> <1042ngl$1kdle$2@solani.org> <1042oa1$1ke7t$1@solani.org> |
Hi,
They had a bunny-shaped topiary in front
of their offices, must have been swimming
in money, General Magic didn't predict the Future:
https://www.youtube.com/watch?v=N4lqz2OofL0
Now, things don't look exactly how they evisioned.
Bye
Mild Shock schrieb:
>
> Another solution would be to dismiss the whole Java
> ClassLoader thing as humbug, and not strive for a
> Knowlegebase abstraction, and create workers via some
> operating system fork().
>
> This might perfectly well work as well. It only
> breaks down if you want to embed and integrate
> your “workers”, into systems that have something like
> this Java ClassLoader notion.
>
> Either way, “workers” provide a nice new notion
> besides engines, which was never covered by Papers
> of Paul Tarau and the like, and might not have
> existed in older Prolog systems. Because
>
> old papers had a different ontology: Places,
> Sandbox, etc.. workers were simply not on the radar.
> The data isolation allows for non-cooperative
> parallelism among workers, despite the notion of an
>
> engine is rather cooperative. Workers got momentum
> with Web 2.0 and early process isolation of browser
> tabs in 2008 when Chrome debuted. Just after that
> in 2010 they were introduced as part of HTML5 for
>
> thread isolation inside a browser tab.
>
> See for yourself:
>
> Jinni: Intelligent Mobile Agent Programming
> at the Intersection of Java and Prolog
> https://www.researchgate.net/profile/Paul-Tarau/publication/2762429
>
> Mild Shock schrieb:
>> If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
>> wouldn’t be needed at all. You could make Knowledgebase
>> and Engine classes, the C++ compiler would optimize for
>>
>> you passing around GD or LD in the form of a “this”, and
>> a method inside an Engine, could access a Knowledge base,
>> by “this->KB” or simply “KB”. C++ would be even less
>> annoying than Java, since you can do deferred mixin:
>>
>> class Person {
>> [...]
>> }
>>
>> And later:
>>
>> void Person::Print() {
>> [...]
>> }
>>
>> Because I don’t have deferred mixin in Java, my own
>> modularization looks extremly messy, passing around a
>> parameter explicitly, hoping that the usual register
>> file optimization of a Java compiler eliminates
>>
>> most parameter passing. But my C++ knowledge is very
>> limited, so I don’t know whether a PhD in Macro defs
>> was the better solution. Was there never a C++
>>
>> implemenation of SWI-Prolog ?
>>
>> Mild Shock schrieb:
>>>
>>> > The required changes could be fairly limited.
>>>
>>> I don’t know. You never know before you did it.
>>> With the current design you might end up in a
>>> Münchhausen scenario, trying to defy gravity by
>>> pulling your own hair. It seems there is a global switch
>>>
>>> which engine is active? I don’t understand, isn’t
>>> SWI-Prolog able to run truely concurrently on a
>>> multi-core machine. Because such things, wouldn’t
>>> work for threads that distribute themselves over cores.
>>>
>>> I saw an L_THREAD lock somewhere?
>>>
>>> #define GET_LD PL_local_data_t *__PL_ld = GLOBAL_LD;
>>>
>>> In the “worker” scenario, a “worker” can typically grab
>>> a CPU core all for himself, and for its knowledge and
>>> for all the engines that work over this knowlegde base.
>>> Thats the beauty of JavaScript
>>>
>>> isolation through “workers”, and it is also used in
>>> the Ciao Playground. Its very multi core friendly, a
>>> “worker” can also have its own garbage collection etc…
>>>
>>>
>>>
>>>
>>
>
Back to comp.lang.prolog | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Noacore is a Prolog profile that explores various relaxations Mild Shock <janburse@fastmail.fm> - 2025-03-21 19:16 +0100
What about allowing numbers 1e19, etc.. (Re: Novacore is a Prolog profile that explores various relaxations) Mild Shock <janburse@fastmail.fm> - 2025-03-21 19:21 +0100
Re: What about allowing numbers 1e19, etc.. (Re: Novacore is a Prolog profile that explores various relaxations) Mild Shock <janburse@fastmail.fm> - 2025-03-21 19:29 +0100
prolog_file_name/2 was a big mistake [Novacore] Mild Shock <janburse@fastmail.fm> - 2025-05-25 09:22 +0200
The recent extension/1 addition in Dogelog Player (Was: prolog_file_name/2 was a big mistake [Novacore]) Mild Shock <janburse@fastmail.fm> - 2025-05-25 09:33 +0200
Corr.: Typo (Was: The recent extension/1 addition in Dogelog Player) Mild Shock <janburse@fastmail.fm> - 2025-05-25 09:39 +0200
How difficult is a Knowledbase notion? (Was: Novacore is a Prolog profile that explores various relaxations) Mild Shock <janburse@fastmail.fm> - 2025-07-02 09:33 +0200
C++ programming or a PhD in Macro defs (Was: How difficult is a Knowledbase notion?) Mild Shock <janburse@fastmail.fm> - 2025-07-02 09:35 +0200
Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0] (Was: C++ programming or a PhD in Macro defs) Mild Shock <janburse@fastmail.fm> - 2025-07-02 09:49 +0200
General Magic didn't predict the Future (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0]) Mild Shock <janburse@fastmail.fm> - 2025-07-02 10:07 +0200
Antique Programming Style versus Modern Programming Style [SWI-Prolog] (Was: Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0]) Mild Shock <janburse@fastmail.fm> - 2025-07-02 15:54 +0200
Grand mothers kitchen is nevertheless the best, who knows? (Was: Antique Programming Style versus Modern Programming Style [SWI-Prolog]) Mild Shock <janburse@fastmail.fm> - 2025-07-02 16:06 +0200
csiph-web