The above test fails for me. The assert fails since the result of handle size is 5, not 3 as expected. I tested on 32 bit Windows, 32 bit Linux (ext4) and 64 bit Linux (btrfs), and only the 64 bit version fails.
As by
http://stackoverflow.com/questions/13494417/ftruncate-on-file-opened-with-fo... - a file descriptor needs to be flushed before being truncated. It seems to be coincidence that this has worked on 32 bit systems.
The FilePlugin doesn't do that. Should the FileHandle class be changed for this, the Plugin code, or is the test invalid?
Kind regards Markus
Hi Markus,
On Mon, 2 Jul 2018 at 09:11, Markus Fritsche mfritsche@reauktion.de wrote:
The above test fails for me. The assert fails since the result of handle size is 5, not 3 as expected. I tested on 32 bit Windows, 32 bit Linux (ext4) and 64 bit Linux (btrfs), and only the 64 bit version fails.
As by
http://stackoverflow.com/questions/13494417/ftruncate-on-file-opened-with-fo...
- a file descriptor needs to be flushed before being truncated. It seems
to be coincidence that this has worked on 32 bit systems.
The FilePlugin doesn't do that. Should the FileHandle class be changed for this, the Plugin code, or is the test invalid?
The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
Are you able to test on a file system other than btrfs? Or anything else that might be different in your environment?
P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't looked at it, but it would be nice to reproduce the issue first.
Thanks, Alistair
Hi Alistair,
I created a file-based ext4fs in my ram-based /tmp/ and executed the FileHandleTest starting the image out of that file system - the test still fails.
Are you having your file system on rotating rust or in electron-arresting transistors (like me)?
Best regards,
Markus
On 02.07.2018 09:26, Alistair Grant wrote:
Hi Markus,
The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
Are you able to test on a file system other than btrfs? Or anything else that might be different in your environment?
P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't looked at it, but it would be nice to reproduce the issue first.
Thanks, Alistair
Hi Markus,
It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past. I'm using SSDs. I'll check again when I have access.
Cheers, Alistair (on phone, thus the short reply)
On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, mfritsche@reauktion.de wrote:
Hi Alistair,
I created a file-based ext4fs in my ram-based /tmp/ and executed the FileHandleTest starting the image out of that file system - the test still fails.
Are you having your file system on rotating rust or in electron-arresting transistors (like me)?
Best regards,
Markus
On 02.07.2018 09:26, Alistair Grant wrote:
Hi Markus,
The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
Are you able to test on a file system other than btrfs? Or anything else that might be different in your environment?
P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't looked at it, but it would be nice to reproduce the issue first.
Thanks, Alistair
Hello Alistair,
interesting - below is a summary of my installation. I had this issue way back when (vm-beginners, 04/09/2014) with a complete different software setup (last time I've checked I didn't register as a bogon source on the meter, in fact, I take pride in being a clueon source at work).
mfritsche@hawking:~/Pharo$ uname -a Linux hawking 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
mfritsche@hawking:~/Pharo$ cat /proc/cpuinfo | head -n 5 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
mfritsche@hawking:~/Pharo$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836 [default: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836/]
mfritsche@hawking:~/Pharo$ ls -alh /lib/x86_64-linux-gnu/libc-2.27.so -rwxr-xr-x 1 root root 2,0M Apr 16 22:14 /lib/x86_64-linux-gnu/libc-2.27.so
On 02.07.2018 11:57, Alistair Grant wrote:
Hi Markus,
It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past. I'm using SSDs. I'll check again when I have access.
Cheers, Alistair (on phone, thus the short reply)
On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, <mfritsche@reauktion.de mailto:mfritsche@reauktion.de> wrote:
Hi Alistair, I created a file-based ext4fs in my ram-based /tmp/ and executed the FileHandleTest starting the image out of that file system - the test still fails. Are you having your file system on rotating rust or in electron-arresting transistors (like me)? Best regards, Markus On 02.07.2018 09:26, Alistair Grant wrote: > > Hi Markus, > > The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS. > > Are you able to test on a file system other than btrfs? Or anything > else that might be different in your environment? > > P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't > looked at it, but it would be nice to reproduce the issue first. > > Thanks, > Alistair
Hi Markus,
On Mon, 2 Jul 2018 at 13:05, Markus Fritsche mfritsche@reauktion.de wrote:
interesting - below is a summary of my installation. I had this issue way back when (vm-beginners, 04/09/2014) with a complete different software setup (last time I've checked I didn't register as a bogon source on the meter, in fact, I take pride in being a clueon source at work).
mfritsche@hawking:~/Pharo$ uname -a Linux hawking 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
mfritsche@hawking:~/Pharo$ cat /proc/cpuinfo | head -n 5 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
mfritsche@hawking:~/Pharo$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836 [default: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836/]
mfritsche@hawking:~/Pharo$ ls -alh /lib/x86_64-linux-gnu/libc-2.27.so -rwxr-xr-x 1 root root 2,0M Apr 16 22:14 /lib/x86_64-linux-gnu/libc-2.27.so
I tried creating a btrfs ram disk in a docker image (I don't have the btrfs tools installed on my machine) and still didn't reproduce the problem (I do remember sqlite having problems with btrfs, and vaguely remember flushing and/or truncate being involved).
Since you mention flushing being documented as required before truncating, can you try modifying the test and seeing if that makes a difference?
FileSystemHandleTest>>testTruncate | out | out := #(1 2 3 4 5) asByteArray. handle at: 1 write: out startingAt: 1 count: 5. handle flush. handle truncateTo: 3. self assert: handle size = 3
For the record:
$ uname -a Linux alistair-xps13 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836 [default: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836/]
Cheers, Alistair
On 02.07.2018 11:57, Alistair Grant wrote:
Hi Markus,
It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past. I'm using SSDs. I'll check again when I have access.
Cheers, Alistair (on phone, thus the short reply)
On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, mfritsche@reauktion.de wrote:
Hi Alistair,
I created a file-based ext4fs in my ram-based /tmp/ and executed the FileHandleTest starting the image out of that file system - the test still fails.
Are you having your file system on rotating rust or in electron-arresting transistors (like me)?
Best regards,
Markus
On 02.07.2018 09:26, Alistair Grant wrote:
Hi Markus,
The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
Are you able to test on a file system other than btrfs? Or anything else that might be different in your environment?
P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't looked at it, but it would be nice to reproduce the issue first.
Thanks, Alistair
Hello Alistair,
flushing the handle before truncate turns the test green indeed.
truncate does reopen (close, open) - maybe the flush should be put in reopen? How is flushing handles handled in glue-code generally?
https://dynamic.reauktion.de/~mfritsche/ptvm.tar.zst is a kvm based vm (hard disc, xml vm config) (user pharo, password pharo) that shows the problem - at least on my hardware.
Best regards,
Markus
On 02.07.2018 17:27, Alistair Grant wrote:
Hi Markus,
On Mon, 2 Jul 2018 at 13:05, Markus Fritsche mfritsche@reauktion.de wrote:
interesting - below is a summary of my installation. I had this issue way back when (vm-beginners, 04/09/2014) with a complete different software setup (last time I've checked I didn't register as a bogon source on the meter, in fact, I take pride in being a clueon source at work).
mfritsche@hawking:~/Pharo$ uname -a Linux hawking 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
mfritsche@hawking:~/Pharo$ cat /proc/cpuinfo | head -n 5 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
mfritsche@hawking:~/Pharo$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836 [default: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836/]
mfritsche@hawking:~/Pharo$ ls -alh /lib/x86_64-linux-gnu/libc-2.27.so -rwxr-xr-x 1 root root 2,0M Apr 16 22:14 /lib/x86_64-linux-gnu/libc-2.27.so
I tried creating a btrfs ram disk in a docker image (I don't have the btrfs tools installed on my machine) and still didn't reproduce the problem (I do remember sqlite having problems with btrfs, and vaguely remember flushing and/or truncate being involved).
Since you mention flushing being documented as required before truncating, can you try modifying the test and seeing if that makes a difference?
FileSystemHandleTest>>testTruncate | out | out := #(1 2 3 4 5) asByteArray. handle at: 1 write: out startingAt: 1 count: 5. handle flush. handle truncateTo: 3. self assert: handle size = 3
For the record:
$ uname -a Linux alistair-xps13 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836 [default: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836/]
Cheers, Alistair
On 02.07.2018 11:57, Alistair Grant wrote:
Hi Markus,
It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past. I'm using SSDs. I'll check again when I have access.
Cheers, Alistair (on phone, thus the short reply)
On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, mfritsche@reauktion.de wrote:
Hi Alistair,
I created a file-based ext4fs in my ram-based /tmp/ and executed the FileHandleTest starting the image out of that file system - the test still fails.
Are you having your file system on rotating rust or in electron-arresting transistors (like me)?
Best regards,
Markus
On 02.07.2018 09:26, Alistair Grant wrote:
Hi Markus,
The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
Are you able to test on a file system other than btrfs? Or anything else that might be different in your environment?
P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't looked at it, but it would be nice to reproduce the issue first.
Thanks, Alistair
Hi Markus,
On Mon, 2 Jul 2018 at 19:07, Markus Fritsche mfritsche@reauktion.de wrote:
flushing the handle before truncate turns the test green indeed.
Great!
truncate does reopen (close, open) - maybe the flush should be put in reopen?
The FilePlugin primitives are used by multiple classes and from Pharo 7 BinaryFileStream is the main interface to files. While FileHandle reopens the file, BinaryFileStream doesn't. Then Squeak has its own usage. So I think that putting the flush in to the truncate primitive is the right thing to do. Let me know if you disagree.
How is flushing handles handled in glue-code generally?
I'm not sure I understand your question. There's a primitive for flushing open files (primitiveFileFlush(), which calls sqFileFlush()).
https://dynamic.reauktion.de/~mfritsche/ptvm.tar.zst is a kvm based vm (hard disc, xml vm config) (user pharo, password pharo) that shows the problem - at least on my hardware.
I'm not a kvm user, and the descriptions match my understanding well enough. Combined with your tests, I think we've got sufficient justification for the change.
Assuming no other objections are raised before-hand: If you can submit a PR, great! If not, let me know and I'll make the change (although it could take a few weeks - limited time and other changes I want to see incorporated).
Thanks, Alistair
On 02.07.2018 17:27, Alistair Grant wrote:
Hi Markus,
On Mon, 2 Jul 2018 at 13:05, Markus Fritsche mfritsche@reauktion.de wrote:
interesting - below is a summary of my installation. I had this issue way back when (vm-beginners, 04/09/2014) with a complete different software setup (last time I've checked I didn't register as a bogon source on the meter, in fact, I take pride in being a clueon source at work).
mfritsche@hawking:~/Pharo$ uname -a Linux hawking 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
mfritsche@hawking:~/Pharo$ cat /proc/cpuinfo | head -n 5 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
mfritsche@hawking:~/Pharo$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836 [default: /home/mfritsche/Pharo/pharo-vm/lib/pharo/5.0-201805090836/]
mfritsche@hawking:~/Pharo$ ls -alh /lib/x86_64-linux-gnu/libc-2.27.so -rwxr-xr-x 1 root root 2,0M Apr 16 22:14 /lib/x86_64-linux-gnu/libc-2.27.so
I tried creating a btrfs ram disk in a docker image (I don't have the btrfs tools installed on my machine) and still didn't reproduce the problem (I do remember sqlite having problems with btrfs, and vaguely remember flushing and/or truncate being involved).
Since you mention flushing being documented as required before truncating, can you try modifying the test and seeing if that makes a difference?
FileSystemHandleTest>>testTruncate | out | out := #(1 2 3 4 5) asByteArray. handle at: 1 write: out startingAt: 1 count: 5. handle flush. handle truncateTo: 3. self assert: handle size = 3
For the record:
$ uname -a Linux alistair-xps13 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ ./pharo --version 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836 [default: /mnt/p7/pharo-vm/lib/pharo/5.0-201805090836/]
Cheers, Alistair
On 02.07.2018 11:57, Alistair Grant wrote:
Hi Markus,
It looks like it is something else then. I'm away from my PC now, but running the tests in a tmpfs ram disk have worked in the past. I'm using SSDs. I'll check again when I have access.
Cheers, Alistair (on phone, thus the short reply)
On Mon., 2 Jul. 2018, 09:56 Markus Fritsche, mfritsche@reauktion.de wrote:
Hi Alistair,
I created a file-based ext4fs in my ram-based /tmp/ and executed the FileHandleTest starting the image out of that file system - the test still fails.
Are you having your file system on rotating rust or in electron-arresting transistors (like me)?
Best regards,
Markus
On 02.07.2018 09:26, Alistair Grant wrote:
Hi Markus,
The test passes in my Pharo 7 64 bit image with Ubuntu 16.04 on ZFS.
Are you able to test on a file system other than btrfs? Or anything else that might be different in your environment?
P.S. I'm not saying that FilePlugin shouldn't be changed, I haven't looked at it, but it would be nice to reproduce the issue first.
Thanks, Alistair
Hi Alistair et al,
shameless admission of "no-ledge" (a.k.a. ignorance): from which project do I base my PR off of to ensure all flavours will get eventually updated, and is there a contribution guide for that one?
Best regards, Markus
On 02.07.2018 19:58, Alistair Grant wrote:
Assuming no other objections are raised before-hand: If you can submit a PR, great! If not, let me know and I'll make the change (although it could take a few weeks - limited time and other changes I want to see incorporated).
Thanks, Alistair
On 3 July 2018 at 02:03, Markus Fritsche mfritsche@reauktion.de wrote:
Hi Alistair et al,
shameless admission of "no-ledge" (a.k.a. ignorance): from which project do I base my PR off of to ensure all flavours will get eventually updated, and is there a contribution guide for that one?
Best regards, Markus
On 02.07.2018 19:58, Alistair Grant wrote:
Assuming no other objections are raised before-hand: If you can submit a PR, great! If not, let me know and I'll make the change (although it could take a few weeks - limited time and other changes I want to see incorporated).
Thanks, Alistair
Pharo, Squeak, Cuis all build from the OpenSmalltalk VM repo. https://github.com/OpenSmalltalk/opensmalltalk-vm
cheers -ben
Hi Markus,
On Tue, Jul 03, 2018 at 07:48:13AM +0800, Ben Coman wrote:
Pharo, Squeak, Cuis all build from the OpenSmalltalk VM repo. https://github.com/OpenSmalltalk/opensmalltalk-vm
Adding to Ben's reply...
After checking out the source code, there are HowToBuild files in each of the platform directories, e.g. build.linux64x64/HowToBuild.
If you want a list of pre-requisite packages for building, see .travis_install.sh in the root directory.
You need to manually set up the version information hooks once after cloning:
scripts/updateSCCSVersions
Unfortunately the linux build files are not always in sync (I have a ToDo to submit a change for the debug build file). It is probably best to first build a clean normal vm:
cd build.linux64x64/pharo.cog.spur/build ./mvm
and answer y (yes) to the Clean? question.
I think the changes to do the flushing are all in the platform support files, so it shouldn't be necessary to use VMMaker straight off. The main VM code is written in slang and edited and generated from within Squeak. If you think you'll need to modify slang code let me know and I'll find the relevant pages (I'm writing this reply offline).
If you've got any other questions, let me know.
Cheers, Alistair
Hi,
been there, done that. After having a ping pong game with the GL dependencies on ubuntu 18.04, I finally got it to build. The standard version wasn't able to open my images (hung), but I did verify my change using the debug build, which was able to start up properly given my Pharo 6.1 image.
Thanks for the support, Markus
On 03.07.2018 10:36, Alistair Grant wrote:
After checking out the source code, there are HowToBuild files in each of the platform directories, e.g. build.linux64x64/HowToBuild.
vm-dev@lists.squeakfoundation.org
-
Alistair Grant -
Ben Coman -
Markus Fritsche