Beta ptitSeb's Beta Lair


@ptitSeb and @levi: thanks guys :)

I just found this wikipedia article about libraries serving a similar purpose:

https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software

Is Boost the simplest one ? I'm not a developer, and I'm really bad at maths :p

EDIT: the Multics simulator is written in C, not C++. Maybe GMP would be better for the job ?

Cheers, Magic Sam
Well, GMP is what GCC use. It's certainly stable and precise, but for ease of use, I guess C++ with it's overloaded operator cannot be beaten (you just write stuff naturaly, like "int128_t a = b * 2;", and boost/c++ will apply the correct operators. with GMP, you will have to rewrite every mathematical operation using gmp functions.
 
Hi all :)

@ptitSeb : I tried to compile (with cmake) clang 3.4 this afternoon, but failed miserably...

I set CLANG_PATH_TO_LLVM_BUILD to /mnt/utmp/codeblocks/usr, but cmake complained that "include could not find load file: AddLLVM". Same error message for "TableGen".

What did I do wrong ?

@levi : I told the author about the boost multiprecision library, and he seemed concerned about it being C++, while his simulator is written in C...

Cheers, Magic Sam

P.S: on a side note, I compiled the simulator on my Debian 8 x86_64 box, installed the latest Multics release, booted the system then logged in from my Pandora over telnet ! That was really fun :)
 
Hi all :)

@ptitSeb : I tried to compile (with cmake) clang 3.4 this afternoon, but failed miserably...

I set CLANG_PATH_TO_LLVM_BUILD to /mnt/utmp/codeblocks/usr, but cmake complained that "include could not find load file: AddLLVM". Same error message for "TableGen".

What did I do wrong ?
You need to compile LLVM too. the minimum is llvm+clang. There is no proper llvm build in codeblocks (the llvm part in rust are static libs already linked to rust, so not useable).
It would be better to not use libcxx, and try to use standard libstdc++ from the GNU suite if possible.
 
Hi all :)

@ptitSeb: I'm sorry to bother you with this again, but it looks like your wxWidgets package is no longer compatible with one of your latest Code::Blocks release (GCC 7.1) :(

I compiled a new version of Odamex this afternoon (git from April 12th 2017, forced SDL 1.2 with -DUSE_SDL12=1), and it failed to start with the following error message:
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.6,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.6,compatible with 2.8).
/usr/pandora/scripts/pnd_run.sh: line 528: 2342 Aborted "./$EXENAME" $ARGUMENTS "$@"
Could you please have a look ?

EDIT: just tested the standalone SDL 1.2 odamex client (without the odalaucher which depends on wxWidgets), and it did run correctly with @notaz' improved SDL :) You can expect a new Odamex release as soon as this ABI issue is sorted out :)

Cheers, Magic Sam
 
Last edited:
Hi all :)

@ptitSeb : I stumbled on this error while recompiling Odamex with your latest Code::Blocks PND:
[ 93%] Building CXX object odalaunch/CMakeFiles/odalaunch.dir/__/odalpapi/net_packet.cpp.o
In file included from /mnt/utmp/codeblocks/usr/include/c++/7.1.0/vector:69:0,
from /media/Pandora1/dev/odamex-github/odamex/odalpapi/net_packet.h:33,
from /media/Pandora1/dev/odamex-github/odamex/odalpapi/net_packet.cpp:31:
/mnt/utmp/codeblocks/usr/include/c++/7.1.0/bits/vector.tcc: In member function ���void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&}; _Tp = std::__cxx11::basic_string<char>; _Alloc = std::allocator<std::__cxx11::basic_string<char> >]���:
/mnt/utmp/codeblocks/usr/include/c++/7.1.0/bits/vector.tcc:454:5: internal compiler error: Segmentation fault
}
^
0x66da73 crash_signal
/media/sda1/sources/gcc-6.2.0/gcc/toplev.c:337
0x52ab77 sparseset_bit_p
/media/sda1/sources/gcc-6.2.0/gcc/sparseset.h:147
0x52ab77 mark_pseudo_regno_live
/media/sda1/sources/gcc-6.2.0/gcc/ira-lives.c:289
0x52b61f process_bb_node_lives
/media/sda1/sources/gcc-6.2.0/gcc/ira-lives.c:1079
0x510843 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
/media/sda1/sources/gcc-6.2.0/gcc/ira-build.c:1806
0x52c44b ira_create_allocno_live_ranges()
/media/sda1/sources/gcc-6.2.0/gcc/ira-lives.c:1564
0x5122d3 ira_build()
/media/sda1/sources/gcc-6.2.0/gcc/ira-build.c:3422
0x50a443 ira
/media/sda1/sources/gcc-6.2.0/gcc/ira.c:5302
0x50a443 execute
/media/sda1/sources/gcc-6.2.0/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [odalaunch/CMakeFiles/odalaunch.dir/build.make:116: odalaunch/CMakeFiles/odalaunch.dir/__/odalpapi/net_packet.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:290: odalaunch/CMakeFiles/odalaunch.dir/all] Error 2
make: *** [Makefile:150: all] Error 2
I didn't have this issue before. Any idea what I'm doing wrong ?

Cheers, Magic Sam
 
It's an internal error of GCC. Not much you can do.
You can try to lower the optim level off that particular file it crashed on (net_packet.cpp) by adding "#pragma GCC optimize 0" as 1st line of the file.. It may solve the issue.
 
Ok, it should be fixed now. The size is correct now at least.
[doublepost=1504979081,1504969444][/doublepost]I have added OpenRA to the 1st post.

I have (super quickly) tried it on CC, and you'll need a Swapfile for it to run (no idea on the speed, I haven't tried to download any media).
Also, on CC, I had to disabled BGRA texture or the game would fail tried to create a Framebuffer with a large (2048x2048) BGRA texture. It's ok on Gigahertz (with 4.10 driver), so I only disabled BGRA Texture on CC. If the game crash for you, check the /tmp/pndrun_openra.out as usual, but you can also look inside appdata/openra/home/.openra/Logs for more logs.
 
I have removed Retroarch, as Canseco has a better and up-to-date version on the repo, this one is obsolete.

I have updated Revenge of the Titans. The latest version of gl4es makes the games playable on a Gigahertz model, even if still on the slow side.
Also, I tried with ES1.1 or ES2.0 backend and didn't found notable difference. By default I kept ES1.1 backend but you can select ES1/ES2 by creating a file named ".es" without the quotes in "appdata/revengeoftitans" with 1 or 2 inside to select the backend.
 
Back
Top