FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche-4
 

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-fopen
- 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

Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

alistairgrant
 
Hi Markus,

On Mon, 2 Jul 2018 at 09:11, Markus Fritsche <[hidden email]> 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-fopen
> - 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
Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche-4
 
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

Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

alistairgrant
 
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, <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche-4
 

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, <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

alistairgrant
 
Hi Markus,

On Mon, 2 Jul 2018 at 13:05, Markus Fritsche <[hidden email]> 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, <[hidden email]> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche-4
 
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 <[hidden email]> 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, <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

alistairgrant
 
Hi Markus,

On Mon, 2 Jul 2018 at 19:07, Markus Fritsche <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche-4
 
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
Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Ben Coman
 


On 3 July 2018 at 02:03, Markus Fritsche <[hidden email]> 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.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

alistairgrant
 
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
Reply | Threaded
Open this post in threaded view
|

Re: FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux

Markus Fritsche-4
 
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.