summary refs log tree commit diff stats
path: root/results/scraper/box64/203
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/scraper/box64/2039
-rw-r--r--results/scraper/box64/20342
-rw-r--r--results/scraper/box64/20398
3 files changed, 19 insertions, 0 deletions
diff --git a/results/scraper/box64/203 b/results/scraper/box64/203
new file mode 100644
index 000000000..0f48ceadc
--- /dev/null
+++ b/results/scraper/box64/203
@@ -0,0 +1,9 @@
+error: unknown type name '__uint128_t'
+When trying to compile using the make -j$(nproc) command, I keep encountering the following error:

+

+error: unknown type name '__uint128_t'

+

+I have followed all of the steps listed on [pymylifeup](https://pimylifeup.com/raspberry-pi-x64/) to the letter and am curious what may be causing this problem. I am currently running Raspbian GNU/Linux 11 (bullseye). 

+

+Please let me know if you need any additional information. I have attached a text version of the compiler output to this issue if that helps.

+[error message.txt](https://github.com/ptitSeb/box64/files/7805909/error.message.txt)

diff --git a/results/scraper/box64/2034 b/results/scraper/box64/2034
new file mode 100644
index 000000000..5bc57b851
--- /dev/null
+++ b/results/scraper/box64/2034
@@ -0,0 +1,2 @@
+[WOW64] Mass Effect 2 EA app crashes
+The game wont open at all with DXVK or OpenGL
\ No newline at end of file
diff --git a/results/scraper/box64/2039 b/results/scraper/box64/2039
new file mode 100644
index 000000000..dfa177b0f
--- /dev/null
+++ b/results/scraper/box64/2039
@@ -0,0 +1,8 @@
+Clarification on the Purpose of Red-Black Trees in Box64
+I have noticed that in `custommem.c`, memory ranges mapped by mmap are simultaneously recorded and removed in multiple red-black trees.

+Each node encapsulate a memory range along with detailed information about that range.

+My question pertains to the necessity of using three distinct red-black tree nodes to record the same memory range. 

+Is this approach taken solely to maintain three separate pieces of information related to each memory range?

+

+ If that's the case, could a bitwise operation be implemented to consolidate the information, potentially reducing the number of trees required?

+