Certainly not something one can dive into! Any one else tried it?
I’ve never used Prolog or any other logic or functional language, but I suspect I could figure things out with a decent ‘primer’. I assume more established languages have such, but all the documentation here starts with expecting you to know all that! It wan’t clear to me for quite a while that – even though it runs from a Terminal – most of the language needs to be written into a script to be loaded. Only “queries” can be typed at the prompt.
And I was totally cofused by the fact that one can type “X = 1+2” and see the answer, but if you then try to “print(X)” it has no value! Nowhere did I see it mentioned that – as I eventually discovered – ending a statement with a comma maintains the environment… for that line only. Backslash doesn’t work to continue a line!
I’d probably have to find some really neat use to continue.
I agree. It is confusing. In the long run, IMHO, Haiku’s future lies in x86_64 and the nomencalture will be simplified a lot. But if we moved there today, we’d lose all the old BeOS apps for which we have no source code.
I have an interest in dynamic programming and constraint satisfaction solving, so I have a particular interest in Picat. The developers of Picat also developed Prolog-B, and refer to it heavily in Picat documentation. So I am going back and re-reading the Prolog I learned and forgot a long time ago. I hope to write up a simple primer for using Picat on Haiku, and also some programming examples.
I do think that Picat is EXTREMELY powerful as a programming language. I think it is worth learning the principles.
…and I guess I’m still confused. I thought that the point of a hybrid build is that it runs both gcc2 and gcc4/5 executables without worries. The same gcc5 executable should work on both a hybrid and a gcc5 only build shoudn’t it? Whenever I’ve compiled under gcc5, I’ve never given a thought to what it was supposed to run under. I notice that essentially everything in my ‘packages’ directory is tagged “x86_gcc2”; are they all gcc5?
That would be superb! It does look like a very interesting language, even though, as I said, I’m not familiar with the genre. The docs often completely lost me.
Several years ago I ported SWI Prolog. The recipe is in haikuports but I am not sure if it is still working. I’ll try and check tomorrow and fix it if there are any issues.
Great to get another language to code in on haiku!
EDIT: It works as long as you install readline_x86_devel and gmp_x86_devel manually first. Not sure why they aren’t being picked up automatically but will do some more digging.
while the binaries themselves should run, there are several differences between the architectures, first in terms of system paths (libraries in /boot/system/lib/x86 instead of /boot/system/lib, for example), and because of this, we need to build some packages twice.
As a result, the packages for gcc2-hybrid and gcc5-hybrid are not in sync, which means you don’t always have the same version of libraries, etc.
So, we must have two independant set of packages.
This is indeed rather confusing, so what I would suggest (and the current plan for beta1) is:
Deprecate the gcc5hybrid
Keep gcc2hybrid as the only variant which supports BeOS apps, with maximal compatibility
Keep x86_64 as the variant for people who don’t care about BeOS compatible apps
Eventually, we could build an x86_64 system with some gcc2-32-bit wrapper so it can still run BeOS apps. But there is some more work needed before we get to that, so it is likely that this will happen only in R2, or we may just give up on it if gcc2 support becomes too irrelevant.
gcc2hybrid is anachronism, is there really is point for keeping it in highest position?
I think it is time to separate BeOS compatibility layer from Haiku, that layer can have separate beos directory (like in original BeOS).
Haiku should use new gcc, and gcc2 only for BeOS apps compatibility layer.
Eventually, we could build an x86_64 system with some gcc2-32-bit
wrapper so it can still run BeOS apps. But there is some more work
needed before we get to that, so it is likely that this will happen only
in R2, or we may just give up on it if gcc2 support becomes too
irrelevant.
Yes it should be handled as under windows, where you can install and use 32 bit applications with the 64 bit system?
