Does someone know a tutorial or something which explains how to get from "tutorial Prolog" to "real project Prolog", because that's not look anything like tutorial Prolog.
Prolog seems interesting, but any time I tried to do anything more than toy examples on my own, I got infinite recursion, unsolvable problems.
I'll second that. Incredibly good quality videos. The precision of the narration is simply amazing. Even if you don't intend to practice Prolog in your programming life, it's worth a listen.
Many people, when they say math, mean continuous math.
At work, my colleagues are almost entirely statisticians and actuaries, and I sometimes joke that my only math course at university was Calculus 1. I have of course done lots more math, but it’s all CS type stuff like logic and discrete structures like graphs and trees which is a very different world from continuous stuff.
I'm hoping one day someone will write a window-manager service for Wayland that replaces the compositor API with a protocol. To once again enable window managers to be implemented in any language, regardless of it having a Wayland/compositor library.
Great news! I'd seen river before (already had it bookmarked) but was unaware (or forgot) that it planned a feature like this. As long as they don't make it to tiling specific, which doesn't look likely given the wording of the Features section, it should be almost exactly what I want. Thanks!
A protocol defines a set of primitives and their interactions, along with prescriptions where necessary, but is otherwise pretty loose generally. Especially in a Postels law world. APIs tend to be highly prescriptive with a highly specific interface and a lot of black box.
Think of the difference between an IETF RFC on say SMTP vs an email API - the RFC describes how clients and servers for mail routing interact through an almost dialog, while a typical email API has highly structured interfaces. Another wat to cut it is an API can be tested as it has inputs and return values dependent on those, while a protocol you can generally only assert compliance with the specification of the protocol.
People often assert protocols have something to so with RPC of some sort but that’s not true. Many language support protocols, which can be very similar to interfaces, but don’t have anything to do with OOP, etc. In language protocols it’s slightly different than network/IPC protocols but the intent is similar.
I'm not the most knowledgeable, but a protocol talks to another process through a specific format.
I personally think its more powerful than writing a new process to replace and existing.
My favorite example is an X11 windows manager implementing in about 18 lines of python.
Obviously there's dependencies to talk to the X server, but the power of a protocol comes from any program written in any la gage communicate with existing code.
I created my own X11 window manager [1] at the start of this year in around 800 lines of C.
I had been using dwm (4000 lines of C) for many years and wished to write my own for a long time, but what made me take the leap was really steveWM [2] and TinyWM [3] which are both super small.
They're both poorly defined, but what I think GP meant is they want something that you use something like a socket instead of FFI to interface with. You need an extra data description layer for a 'protocol' in this context because you can't rely on something like the C data model and calling convention as a given.
The OP wants to decouple the compositor from the window manager and have them talk over a protocol. Totally doable, but not with the current Wayland protocol or (AFAIK) any proposed extension. (Although I guess the shell protocol has the start of something like this?)
So do people use Prolog today? Given it's demonstrable that people use NT4 today, even if only for frivolous nostalgia trips or just an appreciation of _retro_-computing because if we can enjoy a mid-1990s abstract geometric screensaver today then it's no different to appreciating a 1960s Lava Lamp if you lived in the 1990s (presumably sat on the same desk and computer you're trying to install NT4 on).
this looks very impressive. forgive me a stupid question as a prolog outsider:
is this actually using any logical prolog features, or mostly just the 'functional' subset of prolog?
on a cursory look almost all annotated predicates are either 'det' or 'semidet', and none seem to have ? argument modes, so on the surface it looks like this is mostly straight functional code.
am i missing something important?
to be sure, prolog has much to recommend it even as a non-logic functional language: great syntax with probably the most flexible grammar out of all non-research languages (e.g. prolog's operator definition facility makes the ilk of haskell's seem like a toy), homoiconicity, etc.
but at least my expectation is perhaps for prolog code to make use more of the logical facilities.
I actually started hacking on a Prolog X11 WM last year, got distracted by other things but what I started with was a module to define BSP-style partitions using rational constraints, so you would be able e.g. to easily cycle between valid pane layouts.
Are there any WMs that are implemented in JS and CSS? Or at least allow you to use JS/CSS? I’d love to be able to use web technologies to manage and decorate windows.
I did read all the keybindings (as well as the entire README.md) hoping to find a "launch" or similar command but there was nothing relevant. "Increase number of master windows" was most promising but nothing happened. The only command that responded was super+shift+q to quit. Nothing abnormal going on in the Xorg or plwm logs.
Very nice. If you’re used to dwm this should be natural. Unless you use dwm’s tags as more than workspaces, which I do. The author does not, so he implemented workspaces instead of tags. So this can not replace dwm for me.
There was also a virtual large scrolling desktop, and virtual multi-screen "rooms", both purely written in PostScript, which all plugged together with the tabbed windows and pie menus and X window manager seamlessly. They were all independent of each other and could be used separately, but worked together synergistically. Take that, ICCCM! ;)
Also here's a (pre-ICCCM, pre-X11) X10 window manager with pie menus, written in C and scripted in Forth, from around 1986:
>In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
>Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski
Thank you for checking it out! It was fun to write and run. But we couldn't talk Sun into letting us ship it for some reason! ;) Here's some more context and opinions about ICCCM (I39L), TkWM, OWM, xinit, and piewm:
Here's a much better example of NeWS object oriented PostScript user interface code, written as a developer demo with lots of comments, and even a manual entry (which shipped with SVR4):
I just read over the OWM NeWS X11 window manager for the first time in decades, and rediscovered a little easter egg I'd completely forgotten about:
It looks for your X11 XCalc window, and wraps two levels of its sub-windows in ClassXClientCanvas, then puts the window containing the buttons into the list of Framebuffers, so then the window manager wraps all your calculator's buttons in window frames, then you can resize them and move them around and iconify them!
I'll add some comments:
/FrameBuffers [ % Make a list of framebuffers to manage their X11 sub-windows.
% Include all the top level root canvases (screens)
# except the "global root" (which contains all the screens).
rootcanvases {
dup /Parent get globalroot ne { pop } if
} forall
% Loop over all the child windows of the current framebuffer
framebuffer /TopChild get {
dup null eq { pop exit } if % Stop loop when done.
dup null eq { pop } { % Not sure why it's testing the same thing again but there you go.
dup /WM_NAME 0 s xgetproperty { % is it an X window?
pop pop pop % It is! Discard the stuff we don't need.
(Calculator) anchorsearch { % Is it a calculator window?
pop pop % It is! Discard the stuff we don't need.
/new ClassXClientCanvas send % Wrap it so we can play with it from NeWS.
/TopChild get % Get its first child (the inner calculator window that has all the buttons).
/new ClassXClientCanvas send % Wrap it too so we can play with it from NeWS.
dup /Framebuffer 1 index soften put % Poke it so it looks like its parent is a framebuffer.
% Thanks to the "dup" we will leave the calculator sub-window containing all the buttons
% in the list of framebuffers, so the window manager knows about it,
% and wraps all its children (the buttons) in window frames!
% So you get a NeWS window frame wrapping an X Calculator window wrapping an X calculator
% sub-window wrapping NeWS window frames wrapping X window buttons!
exit % My work here is done! MOO HAA HAA!!!
} { pop } ifelse
} if
} ifelse
/CanvasBelow get % Check next window.
} loop
] def
The practical reason I did that was because XCalc would get totally fucked up when you resized it again and again and again and again and again and again, especially small sizes, because the Athena Widget layout manager was a piece of shit, and it repeatedly scaled the initial grid layout in floating point, then rounded the window positions and sizes to integers, so they would drift a little bit each time, especially when small.
That amused us X-Windows hating PostScript programmers on the NeWS team so much that we would laugh and laugh and roll on the floor while repeatedly resizing XCalc again and again until it looked like it got beat up in a street fight. Then we would feel sorry for XCalc, and wanted a way to repair it.
So the obvious solution was to put window frames around all the buttons, so you could resize them and lay them out nicely however you wanted. And if there was a digit or math operation you never needed, you could close it into an icon, and you could even zoom your favorite digits or math operations to "full screen" (the size of the calculator window)!
There is nothing about ICCCM that says you have to run the window manager on a root window. It's actually possible to do that with any ICCCM window manager, you just hack it so you can pass it a window id to manage instead of the root window as a command line argument, figure out the window id of the calculator with some X utility whose name I forgot (xwininfo?), and then it will do its thing on the calculator buttons. I had previously hacked OLWM do to that with a few lines of code, but of course we wanted our user friendly NeWS based X11 window manager to automatically support wrapping NeWS window frames (including tabbed window frames and pie menus) around XCalc buttons.
Does someone know a tutorial or something which explains how to get from "tutorial Prolog" to "real project Prolog", because that's not look anything like tutorial Prolog.
Prolog seems interesting, but any time I tried to do anything more than toy examples on my own, I got infinite recursion, unsolvable problems.
This is one of the best resources for “real” Prolog:
https://www.metalevel.at/prolog
His YouTube videos are also incredibly good.
I'll second that. Incredibly good quality videos. The precision of the narration is simply amazing. Even if you don't intend to practice Prolog in your programming life, it's worth a listen.
I have to concur. Markus Triska is best Prolog resource out there nowaday. Extremely well explained, using modern notations etc.
Thanks.
[flagged]
I'm curious how you figure a language whose central verbs and nouns are logic "isn't math".
Many people, when they say math, mean continuous math.
At work, my colleagues are almost entirely statisticians and actuaries, and I sometimes joke that my only math course at university was Calculus 1. I have of course done lots more math, but it’s all CS type stuff like logic and discrete structures like graphs and trees which is a very different world from continuous stuff.
These cultural differences even determine how you eat your corn: http://bentilly.blogspot.com/2010/08/analysis-vs-algebra-pre...
(I know this is weak evidence that has been debunked by stronger studies.)
Discrete math it's far easier to grasp than continous curves under calculus.
But it sort of is maths.
I'm hoping one day someone will write a window-manager service for Wayland that replaces the compositor API with a protocol. To once again enable window managers to be implemented in any language, regardless of it having a Wayland/compositor library.
have a look at river, theyre currently working on something like this!
https://github.com/riverwm/river#future-plans
Great news! I'd seen river before (already had it bookmarked) but was unaware (or forgot) that it planned a feature like this. As long as they don't make it to tiling specific, which doesn't look likely given the wording of the Features section, it should be almost exactly what I want. Thanks!
I wish more things were protocols instead of APIs.
Could you explain the difference?
A protocol defines a set of primitives and their interactions, along with prescriptions where necessary, but is otherwise pretty loose generally. Especially in a Postels law world. APIs tend to be highly prescriptive with a highly specific interface and a lot of black box.
Think of the difference between an IETF RFC on say SMTP vs an email API - the RFC describes how clients and servers for mail routing interact through an almost dialog, while a typical email API has highly structured interfaces. Another wat to cut it is an API can be tested as it has inputs and return values dependent on those, while a protocol you can generally only assert compliance with the specification of the protocol.
People often assert protocols have something to so with RPC of some sort but that’s not true. Many language support protocols, which can be very similar to interfaces, but don’t have anything to do with OOP, etc. In language protocols it’s slightly different than network/IPC protocols but the intent is similar.
I'm not the most knowledgeable, but a protocol talks to another process through a specific format.
I personally think its more powerful than writing a new process to replace and existing.
My favorite example is an X11 windows manager implementing in about 18 lines of python.
Obviously there's dependencies to talk to the X server, but the power of a protocol comes from any program written in any la gage communicate with existing code.
> My favorite example is an X11 windows manager implementing in about 18 lines of python.
Uh, do you happen to know where to find that project? Sounds pretty comprehensible for most people as an example.
Not sure about that Python project, but years ago I found this very minimal WM in a few hundred lines of C helpful: https://github.com/dylanaraps/sowm
Was a lot easier to understand for me than, say, dwm.
I created my own X11 window manager [1] at the start of this year in around 800 lines of C.
I had been using dwm (4000 lines of C) for many years and wished to write my own for a long time, but what made me take the leap was really steveWM [2] and TinyWM [3] which are both super small.
[1] - https://github.com/ChanderG/cellwm [2] - https://github.com/stodd1031/steveWM [3] - https://github.com/mackstann/tinywm
TinyWM was the starting-point for my wm in Ruby as well. It really drives home just how little you need to get started.
They're both poorly defined, but what I think GP meant is they want something that you use something like a socket instead of FFI to interface with. You need an extra data description layer for a 'protocol' in this context because you can't rely on something like the C data model and calling convention as a given.
A couple ways to look at it:
- Protocols are descriptive, APIs are prescriptive
- Protocols are implemented, APIs implement
A protocol is like the line at Subway where an api is a bar & restaurant.
Sorry, I don’t understand this analogy
Protocol = It defines the whole channe with data structures and commands.
API = how do you connect against.
[flagged]
What? Wayland is a protocol. Not an API.
The OP wants to decouple the compositor from the window manager and have them talk over a protocol. Totally doable, but not with the current Wayland protocol or (AFAIK) any proposed extension. (Although I guess the shell protocol has the start of something like this?)
I mean a higher level, window-manager specific protocol. Skipping all the lower level controls.
I don't know what amazes me more. The fact that someone used prolog to write a window manager, or the fact somone uses prolog at all.
> or the fact somone uses prolog at all.
I'll point your attention to 6 years ago: https://news.ycombinator.com/item?id=19279088
Another fun Prolog fact: Between 1996 and 2000, a Prolog program was distributed to tens of millions of users as part of Windows NT 4: https://web.archive.org/web/20040603192757/research.microsof... (via https://news.ycombinator.com/item?id=29528921 )
So do people use Prolog today? Given it's demonstrable that people use NT4 today, even if only for frivolous nostalgia trips or just an appreciation of _retro_-computing because if we can enjoy a mid-1990s abstract geometric screensaver today then it's no different to appreciating a 1960s Lava Lamp if you lived in the 1990s (presumably sat on the same desk and computer you're trying to install NT4 on).
prett cool to know that. Guest is something you need to be in the middle to really know about. Like cobol.
Looked at the source, it’s so compact, wow.
Not just compact, but it also has lots of clearly written comments, love to see it!
It looks nothing like the Prolog I've seen before.
I'm quite amazed the author took a declarative language meant for logic and turned it on its head for managing windows as an actual application.
Bravo!
Window management and constraints in general are a perfect fit for logic programming.
for x11, there was one written in scheme and used a proper constraint-solver for layout etc.
this looks very impressive. forgive me a stupid question as a prolog outsider:
is this actually using any logical prolog features, or mostly just the 'functional' subset of prolog?
on a cursory look almost all annotated predicates are either 'det' or 'semidet', and none seem to have ? argument modes, so on the surface it looks like this is mostly straight functional code.
am i missing something important?
to be sure, prolog has much to recommend it even as a non-logic functional language: great syntax with probably the most flexible grammar out of all non-research languages (e.g. prolog's operator definition facility makes the ilk of haskell's seem like a toy), homoiconicity, etc.
but at least my expectation is perhaps for prolog code to make use more of the logical facilities.
I actually started hacking on a Prolog X11 WM last year, got distracted by other things but what I started with was a module to define BSP-style partitions using rational constraints, so you would be able e.g. to easily cycle between valid pane layouts.
Oh wow, I gotta try this.
Lots of documentation! Awesome!
Are there any WMs that are implemented in JS and CSS? Or at least allow you to use JS/CSS? I’d love to be able to use web technologies to manage and decorate windows.
Why am I reminded of the all-Erlang HN first page?
Fun fact: the first version of Erlang interpreter was written in Prolog.
Aside from the choice of language, I will be interested in what window managers are similar, or an inspiration for plwm.
I installed all the libs and compiled this on Gentoo, but all I'm getting is a mouse cursor on a black screen.
That is literally most tiling window managers. Check the keybindings. Start a terminal or something.
I did read all the keybindings (as well as the entire README.md) hoping to find a "launch" or similar command but there was nothing relevant. "Increase number of master windows" was most promising but nothing happened. The only command that responded was super+shift+q to quit. Nothing abnormal going on in the Xorg or plwm logs.
You've never used ratpoison, I see
Some of you hold on to X11 harder than Gollum and his ring...
Very nice. If you’re used to dwm this should be natural. Unless you use dwm’s tags as more than workspaces, which I do. The author does not, so he implemented workspaces instead of tags. So this can not replace dwm for me.
Tags are indeed a wonderful idea once it clicks, but I have to admit it took me about a year to get somewhat comfortable with how to work with them.
Time to do one in Scheme, I guess.
Done a while ago: https://en.wikipedia.org/wiki/Scwm
There was also "GWM", based on its own lisp dialect, "WOOL", which was around from at least the early 90s.
On the more popular side, you had sawfish (using an elisp-alike, IIRC) and stumpwm (Common Lisp).
Sawfish (the oficial VM of Gnome for a while) had Lisp plugins (or was it written in Lisp too?)
Here's one in Guile Scheme.
https://wingolog.org/archives/2008/07/31/introducing-griddy
This one is customizable in Lisp, and overall pretty neat: https://sawfish.tuxfamily.org/ - I have been happily using it daily for many years now. :-)
Already exists: https://github.com/mwitmer/guile-wm
There might also be ones in other Schemes, but as FFI hasn't been standardised across Schemes yet I doubt there's an implementation-agnostic one.
Here's an X11 window manager, with pie menus and tabbed windows, entirely written in object oriented NeWS PostScript, from around 1991:
https://donhopkins.com/home/archive/NeWS/owm.ps.txt
And some design notes and emails on that NeWS based window manager for X11 windows:
https://donhopkins.com/home/archive/NeWS/i39l.txt
It incorporated NeWS tabbed windows written in PostScript, which could wrap around X11 windows (and frame NeWS windows too of course):
https://donhopkins.com/home/archive/NeWS/win/tab.ps
And NeWS pie menus written in PostScript, which you could pop up on tabbed window frames and manage X11 windows (and use in NeWS apps too of course):
https://donhopkins.com/home/archive/NeWS/win/pie.ps
There was also a virtual large scrolling desktop, and virtual multi-screen "rooms", both purely written in PostScript, which all plugged together with the tabbed windows and pie menus and X window manager seamlessly. They were all independent of each other and could be used separately, but worked together synergistically. Take that, ICCCM! ;)
Also here's a (pre-ICCCM, pre-X11) X10 window manager with pie menus, written in C and scripted in Forth, from around 1986:
https://donhopkins.com/home/archive/piemenu/uwm/fuwm-main.f
And some of my thoughts on X-Windows and ICCCM window management in general:
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
>Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski
First time I ever get the chance to see object postcript/forth, thank you
Thank you for checking it out! It was fun to write and run. But we couldn't talk Sun into letting us ship it for some reason! ;) Here's some more context and opinions about ICCCM (I39L), TkWM, OWM, xinit, and piewm:
https://www.donhopkins.com/home/catalog/unix-haters/x-window...
Here's a much better example of NeWS object oriented PostScript user interface code, written as a developer demo with lots of comments, and even a manual entry (which shipped with SVR4):
https://donhopkins.medium.com/the-story-of-sun-microsystems-...
https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt
https://www.donhopkins.com/home/archive/NeWS/pizzatool.6.txt
I just read over the OWM NeWS X11 window manager for the first time in decades, and rediscovered a little easter egg I'd completely forgotten about:
It looks for your X11 XCalc window, and wraps two levels of its sub-windows in ClassXClientCanvas, then puts the window containing the buttons into the list of Framebuffers, so then the window manager wraps all your calculator's buttons in window frames, then you can resize them and move them around and iconify them!
I'll add some comments:
The practical reason I did that was because XCalc would get totally fucked up when you resized it again and again and again and again and again and again, especially small sizes, because the Athena Widget layout manager was a piece of shit, and it repeatedly scaled the initial grid layout in floating point, then rounded the window positions and sizes to integers, so they would drift a little bit each time, especially when small.https://www.donhopkins.com/home/catalog/unix-haters/x-window...
That amused us X-Windows hating PostScript programmers on the NeWS team so much that we would laugh and laugh and roll on the floor while repeatedly resizing XCalc again and again until it looked like it got beat up in a street fight. Then we would feel sorry for XCalc, and wanted a way to repair it.
So the obvious solution was to put window frames around all the buttons, so you could resize them and lay them out nicely however you wanted. And if there was a digit or math operation you never needed, you could close it into an icon, and you could even zoom your favorite digits or math operations to "full screen" (the size of the calculator window)!
There is nothing about ICCCM that says you have to run the window manager on a root window. It's actually possible to do that with any ICCCM window manager, you just hack it so you can pass it a window id to manage instead of the root window as a command line argument, figure out the window id of the calculator with some X utility whose name I forgot (xwininfo?), and then it will do its thing on the calculator buttons. I had previously hacked OLWM do to that with a few lines of code, but of course we wanted our user friendly NeWS based X11 window manager to automatically support wrapping NeWS window frames (including tabbed window frames and pie menus) around XCalc buttons.
Didn't Xaw3D solve the issue on xcalc's geometry for a while?
[dead]
[dead]
[dead]
Isn't ".pl" actually used for perl?
Well, there might be a Prolog interpreter written in (a) perl (regex) ...
Prolog was using .pl for a bit over a decade before Perl existed.
My first thought upon reading your comment was "it's used for Poland" ;-)
Then using .prl in stead wouldn’t have helped much…
It's used for both which consistently confuses logic that guess programming language purely based on file extensions.
Prolog is a older than Perl and there doesn't need to be any exclusive claim on file extensions.