1. Phix on Linux
- Posted by petelomax Apr 25, 2016
- 2701 views
I have finally completed the win64 port of Phix (yay!), and IUP, and got a basic lnx32 port working (much more yay!).
Make no mistake: this is a premature baby clinging onto life in an intensive care incubator, that will die if exposed to the real world.
Who knows how long it will be there, maybe days, maybe weeks, maybe months. The win64 port has been through the worst, it had around 6 really difficult bugs, and hopefully(!?!??!) the lnx32 port will be the same, or at least no worse.
The changes have all been uploaded to my bitbucket repository (see PS), and there are a couple of completely untested files on http://phix.is-great.org/download.php (this one is for the brave and bold only, get any missing files from the repository, plus I just spent all my alloted time running the virus checkers).
known issues (64 bit):
1) You can use a 32 bit compiler to generate a 64 bit executable and doing so works well enough for the compiler itself that any remaining niggles are not deemed particularly important. See ptok.e/setFLOAT() for more details, as mentioned there the file builtins\timestamp.ew currently contains an "#8000*#10000" hack - obviously I really ought to properly investigate that sooner rather than later, but right now I have to write things like this...
2) test\t28prntf.exw: sprintf("%f\n",{4503599627370495}) yields not "4503599627370495.000000\n" but "4503599627370495.004514\n" I have not yet attempted to investigate what is really going on there (it works fine on 32 bit).
3) test\t49ginfo seems unsure whether MIN is -#40000000 or -#FFFFFFFF, and whether MAX is +#3FFFFFFF or +#FFFFFFFF. As above, also it seems there may be some genuine problems lurking in that test on plain 64->64 bit compilation.
4) test\t46ltype has also thrown a couple of wobblies that I've casually glossed over (that thing really is no fun at all).
5) test\trace is not working
known issues(Linux):
1) All that actually works is "./phix -c p" (self-host), "./phix -d xxx" (create list.asm), and "./phix -test". A minor issue is that "./phix -c p" displays "Overwriting phix\n" from a child process and messes up the parent terminal prompt, making it look like it is still working, when in fact it has finished (just press Enter to get a new prompt).
2) test/trace is not working and neither is test/terror or anything else using pGUI. What I have found is that calls to libiup.so routines completely obliterate the Phix heap. Currently builtins\VM\pHeap.e uses sys_brk (see :%pGetMem) which I have read is "old hat" and "mmap with anon mapping" would be better. Replacing about 23 lines of asm (plus same for ELF64) might fix things. Update: I gave mmap a go, and ./phix -cp worked, but it broke ./phix -test, so I commented the changes back out
3) To circumvent some issues with linux directory handling, there is currently a quick hack in place to substitute "./" with getenv("HOME")&"/phix/" (ptok.e, addPath() and includeFile()), so on my system it only works in /home/pete/phix.
4) x86 only, and only Ubuntu32 has been tested. Systems with different syscall numbers or structure layout/padding may not work. Originally I planned to use syscalls for everything; after finding out that dlopen and friends must be done via libdl, and getting that working, I now accept libc as the more portable solution, hence some recent additions need revising to use libc instead of int 0x80/syscall. (Once you have all the docs you need it all turns rather trivial, but sometimes nailing down those docs can be a tad difficult!)
5) ./p -test reports that it has completed all tests in 0.02s, which is quite obviously a blatent, bald-faced and silly little lie. As I write this I realise it is almost certainly down to the simple fact that the current version of time() yields gibberish, and it is neither worth debugging the syscall code nor sensible to launch myself at libc again just yet.
6) "./phix -c -test" gets to t16 before crashing with Z!=2, not investigated yet.
Of course there are several hundred (thousand) other items on my todo list, the above are just the most glaring.
Right now, I am suspending all further work/testing on 64/lnx and resuming my efforts on porting utilities and demos to pGUI(IUP), as hopefully that is the quickest route to running lots more tests, especially test/terror and the demo runner (which was called pgui.exw but will be renamed as pdemo.exw).
I expect the odd comment and question
Pete
PS I think what is supposed to happen is that someone makes a clone of the repository, and when happy with their changes makes a formal "push" request. Failing that you can just email me any modified files or post a link to them on this forum.
2. Re: Phix on Linux
- Posted by bugmagnet May 01, 2016
- 2480 views
Pete
I got the error pasteyd at http://openeuphoria.org/pastey/285.wc when installing on Windows 10 Home, 64 bit. It was with a Phix.exe I downloaded a couple of days ago.
Also, when running PPW.BAT (in ad Admin console) I got the following:
"C:\\Program Files (x86)\\Phix" Cannot open autoinclude VM\pcallfunc.e in C:\Program Files (x86)\Phix\, C:\Program Files (x86)\Phix\builtins\VM\, or C:\Program Files (x86)\Phix\builtins\. Press Enter, or d for diagnostics...
Bugmagnet
3. Re: Phix on Linux
- Posted by petelomax May 01, 2016
- 2379 views
Cannot open autoinclude VM\pcallfunc.e
Thanks, I've added the missing line for that file to the build script.
For now you'll have to manually grab a copy from bitbucket (see above link, it goes in builtins/VM).
I expect there will be several more such omissions (I did warn you ).
Pete
4. Re: Phix on Linux
- Posted by _tom (admin) May 04, 2016
- 2359 views
Success!
- download the archive
- copy all files to /home/phix
- execute as:
$ ./phix ./demo/99bottles
Wanted...hints for a proper Linux install.
To read the chm documentation install the Firefox "ChmFox" add-on.
_tom