Beta ptitSeb's Beta Lair


@ptitSeb amazing! I wonder what I did differently. I build all those dependancies from latest sources except for make and I started with a freshly reflashed pandora to make sure no weirdness was going on.

As always, thank you so much!
 
Hi all :)

@ptitSeb : a suggestion for yet another programming language in Code::Blocks:

https://www.erlang.org/

I managed to compile it yesterday (with ~512 MB of swap, and java.pnd):
Code:
git clone https://github.com/erlang/otp
cd otp
./otp_build autoconf
./configure --prefix=/mnt/utmp/codeblocks/usr --with-ssl=/mnt/utmp/codeblocks/usr
make
sudo make install

Cheers, Magic Sam
 
@edgex004 didn't find the time yet to make a pnd out of this yet. I am not sure how to approach this, I tried taking a look at openbox and how it's done there, but everything is being installed from ipk packages, so I can't go that route. copying the files to the fs is not a problem, but how do I make a session that slim can start?
 
@xnopasaranx Honestly, I have no idea. I was stuck on man page generation just like you. I'll try researching it a bit though. I think ratpoison, Icewm, and pandafe might be good examples to look at.
[doublepost=1499018310,1499004328][/doublepost]I'm trying out what ptitSeb posted and noticed that xkb seems to be looking for codeblocks as the default include path. I was able to get around this by using:

Code:
export XKB_CONFIG_ROOT=/usr/share/X11/xkb

Is that the best solution here?

Also, once you get past that, it looks like i3 is working alright! I copied the files to /usr/ in NAND. I then made a script to start it up and saved it as /usr/bin/i3startup

Code:
#!/bin/bash
export XKB_CONFIG_ROOT=/usr/share/X11/xkb
i3

After making that file executable, I added it as an option to the gui switch dialog, I added the following to /etc/pandora/conf/gui.conf:
Code:
i3;i3;i3startup;killall i3

Now I can switch to i3 using the gui switch menu.

For some reason, i3-config-wizard is looking for the prefix folder in order to copy out the config template, but once you get a working config, it seems to do okay.
 
@edgex004 where can I find ratpoison for pandora? I remember seeing it in the past, but can't find it on the repo. Didn't someone also port awesome wm?
[doublepost=1499018424,1499018319][/doublepost]Ah okay, that sounds great. I am trying right now. Are you able to boot into i3 like this as well?

Not so lucky at my attempts. I don't know what I am doing wrong. Copied the files from bin to /usr/bin and created a script such as yours which I then also pointed to in gui.conf. Then I copied the libraries to /usr/lib and my pandora crashed and refused to start. I am reflashing right now.

EDIT: Alright, got it working. I added an LD_LIBRARY_PATH export to the i3startup script and copied the libraries into /usr/lib/i3 which will make it easier to remove the libraries as well on uninstall. No need to remove every file, just rm the directory.

Now we need dmenu and polybar. I'll get onto it right away :D. When I have a configuration that makes sense and is fun to use, I'll release a pnd.

Opening a new thread, so people can try this and come up with cool configurations that we can collect and maybe incorporate.
 
Last edited:
I have updated the CodeBlocks PND. It the new beta (compared to latest beta) is Qt 5.9, QtWebKit 5.9 and Rust 1.18. Look in the spoiler of the 1st post for a more detailed log of changes.
 
Hi all :)

@ptitSeb: silly question (again): I know LLVM is in there, but is Clang part of Code::Blocks ? I couldn't find it :(

Cheers, Magic Sam
 
Nope, I haven't put CLang. You can find it on some old version of codeblocks, but I have removed it some (a long) time ago because of the size/usefullness ratio. Any specific use in mind?
 
@ptitSeb : Multics simulator ;)

http://multicians.org/simulator.html

I managed to compile part of it with GCC (instead of the required Clang), but it fails at some point:
(cd ../decNumber; make)
CC decContext.c
CC decNumber.c
AR decNumber.a
#make zmq
make dps8.sha1.txt
make[2]: 'dps8.sha1.txt' is up to date.
make dps8
CC dps8_absi.c
In file included from dps8.h:55:0,
from dps8_absi.c:22:
dps8_math128.h:17:1: error: unable to emulate ���TI���
typedef int TItype __attribute__ ((mode (TI)));
^~~~~~~
dps8_math128.h:18:1: error: unable to emulate ���TI���
typedef unsigned int UTItype __attribute__ ((mode (TI)));
^~~~~~~
In file included from dps8.h:230:0,
from dps8_absi.c:22:
dps8_hw_consts.h: In function ���SIGNEXT72_128���:
dps8_hw_consts.h:118:37: warning: left shift count >= width of type [-Wshift-count-overflow]
#define SIGN72 ((word72)1U << 71)
^
dps8_hw_consts.h:291:13: note: in expansion of macro ���SIGN72���
if (w & SIGN72)
^~~~~~
dps8_hw_consts.h:293:58: warning: left shift count >= width of type [-Wshift-count-overflow]
return ((int128) w) | (int128) (((uint128) -1ll) << 72);
^~
dps8_hw_consts.h:117:38: warning: left shift count >= width of type [-Wshift-count-overflow]
#define ZEROEXT72 (((word72)1U << 72) - 1U) // mask to zero extend a 72 => 128 int
^
dps8_hw_consts.h:128:25: note: in expansion of macro ���ZEROEXT72���
#define MASK72 ZEROEXT72
^~~~~~~~~
dps8_hw_consts.h:295:16: note: in expansion of macro ���MASK72���
return w & MASK72;
^~~~~~
dps8_hw_consts.h:295:14: warning: conversion to ���int128 {aka int}��� from ���word72 {aka unsigned int}��� may change the sign of the result [-Wsign-conversion]
return w & MASK72;
^
dps8_hw_consts.h: In function ���SIGNEXT36_72���:
dps8_hw_consts.h:325:38: warning: left shift count >= width of type [-Wshift-count-overflow]
return (w | ((word72) DMASK) << 36) & MASK72;
^~
dps8_hw_consts.h:117:38: warning: left shift count >= width of type [-Wshift-count-overflow]
#define ZEROEXT72 (((word72)1U << 72) - 1U) // mask to zero extend a 72 => 128 int
^
dps8_hw_consts.h:128:25: note: in expansion of macro ���ZEROEXT72���
#define MASK72 ZEROEXT72
^~~~~~~~~
dps8_hw_consts.h:325:47: note: in expansion of macro ���MASK72���
return (w | ((word72) DMASK) << 36) & MASK72;
^~~~~~
../Makefile.mk:93: recipe for target 'dps8_absi.o' failed
make[2]: *** [dps8_absi.o] Error 1
Makefile:298: recipe for target 'locallibs_then_dps8' failed
make[1]: *** [locallibs_then_dps8] Error 2
make[1]: Leaving directory '/media/Pandora1/dev/multics/dps8m-code/src/dps8'
Makefile:11: recipe for target 'all' failed
make: *** [all] Error 2
Any ideas ?

Cheers, Magic Sam
 
Mmmm, seems main issue is with
Code:
typedef int TItype __attribute__ ((mode (TI)));
that seems to be used to declare something like "int128_t".
 
@ptitSeb : yes I noticed that. I googled this issue, and it seems to be MinGW related (i.e people trying to compile the Multics simulator from Windows...). Since we're not (AFAIK) using MinGW on the Pandora, I thought maybe my little hacks to use GCC instead of Clang were responsible for that bug...

And one guy managed to compile this Multics simulator on his Raspberry Pi, so this should be ARM compatible IMHO...

Cheers, Magic Sam
 
CLang is 2 days of build, at least, on the Pandora. And weight several hundreds of megabytes. So, not sure I'll do it for now (but it should be a straight forward compile using latest codeblocks beta, at least for the LLVM part, as it's part of Rust for example).
 
@ptitSeb : yes I noticed that. I googled this issue, and it seems to be MinGW related (i.e people trying to compile the Multics simulator from Windows...). Since we're not (AFAIK) using MinGW on the Pandora, I thought maybe my little hacks to use GCC instead of Clang were responsible for that bug...

And one guy managed to compile this Multics simulator on his Raspberry Pi, so this should be ARM compatible IMHO...
Mingw is a suite of tools ported to windows, including GCC, so building using mingw usually means building using gnu make and gcc. So any problems they had may well be transferable.

Also, the Pi's probably run hardfp versions of code. Compiling for other variants can introduce problems some times I would suspect (though I can't think of any legitimate reasons why it would fail).
 
Hi all :)

@ptitSeb and @levi : I received some replies from the multicians community:

Vince Scarafino (who ported the Multics simulator to the Raspberry Pi):
The ARM processor on my Raspberry Pi is 32-bit, so routines had to be created for
the 64-bit math instructions. It appears that is the issue here. I'll see if I can
get some help.

and Charles Anthony (who actually wrote the simulator):
An explanation of what is going on, but not a solution:

The emulator requires the 128 bit integer type to do the DPS8/M 72 bit double precision math.

The 32 bit clang compiler recognizes the 128 bit integer type; the 32 bit GCC compiler does not.

I am not familiar with Open Pandora; would it be feasible to cross-compile from a clang supporting host? Perhaps building the object files on that host and doing the linking on the Open Pandora platform ?

Opinions ? Any secret trick up GCC's sleeves to solve this issue ? What about ARM intrinsics ?

Cheers, Magic Sam
 
Hi all :)

@ptitSeb and @levi : I received some replies from the multicians community:

Vince Scarafino (who ported the Multics simulator to the Raspberry Pi):


and Charles Anthony (who actually wrote the simulator):


Opinions ? Any secret trick up GCC's sleeves to solve this issue ? What about ARM intrinsics ?

Cheers, Magic Sam
Use boost multiprecision maybe?
http://www.boost.org/doc/libs/1_57_...ml/boost_multiprecision/tut/ints/cpp_int.html

With cpp magic of overloaded operator, it might even be plug'n play?
 
Yes, I recall some issue with the way GCC defines longs and so on on ARM causing problems. I forget if NEON on the OMAP3 has 128-bit registers, but that might be worth investigating. Using NEON is pretty much the antithesis of a 'straight port' though, so I could understand if you'd prefer something that can be done with writing a C++ class to wrap up a 128-bit type using 32-bit variables.

Edit: Or using Boost's implementation, as Ptitseb ninja'd me with!
 
Last edited:
Back
Top