January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

by Stephan Eggermont

Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi all, > > After some analysis of current condition of development, we decided to > move the upcoming release to end of the year (and not May, as usual). Thanks for the clear and timely decision. Having to delay is never nice, but with a high innovation rate comes a higher risk. Denial helps noone, keep up the good work! Stephan

Jan. 23, 2018

[Pharo 7.0-dev] Build #440: 21019 remove mc cache repository classdefault

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #440 was: FAILURE. The Pull Request #696 was integrated: "21019 remove mc cache repository classdefault" Pull request url: https://github.com/pharo-project/pharo/pull/696 Issue Url: https://pharo.fogbugz.com/f/cases/21019 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 23, 2018

[ANN] Next Pharo release moved to end of year

by Esteban Lorenzano

Hi all, After some analysis of current condition of development, we decided to move the upcoming release to end of the year (and not May, as usual). The reason is that we are taking more time than expected to finish/polish a quantity of things that needs to be finish to call this a âsuccessful releaseâ to make us feel confortable with a release early this year. Thing isâ¦ we were very ambitious with this version, because a lot of small pieces get into position and we decided to act. Now, to deliver a good version, we need to finish them. For example, along with all the stabilisation phase we need to operate on P7 (an usual task for every version), we still need to finish this important changes: - fullblocks as default - vm 64bits: stabilise and add win64 - stateful traits - calypso (and nautilus removal) - iceberg: fix the UI We (the core team and the community) have a deep commitment with the progress of Pharo, and we will continue get things right to make the continue improvement a pleasant experience. Say that, expect new announcement of things finished and ready to test next weeks :) cheers! Esteban

Jan. 23, 2018

Re: [Pharo-dev] [Vm-dev] Random corrupted data when copying from very large byte array

by Alistair Grant

Hi Eliot, On 23 January 2018 at 01:47, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Alistair, > > On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> >> Hi Eliot, >> >> On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote: >> > Hi Eliot, >> > >> > On 19 January 2018 at 23:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > > Hi Alistair, Hi Cl??ment, >> > > >> > > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <akgrant0710(a)gmail.com> >> > > wrote: >> > >> >> > >> Hi Cl??ment, >> > >> >> > >> On 19 January 2018 at 17:21, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > >> > Hi Cl??ment, >> > >> > >> > >> > On 19 January 2018 at 17:04, Cl??ment Bera <bera.clement(a)gmail.com> >> > >> > wrote: >> > >> >> Does not seem to be related to prim 105. >> > >> >> >> > > >> > > >> > > I suspect that the problem is the same compactor bug I've been trying to >> > > reproduce all week, and have just fixed. Could you try and reproduce with a >> > > VM built from the latest commit? >> > >> > Happy to, but I'm out all day today, so it will be tomorrow or Monday. >> > >> > Cheers, >> > Alistair >> > (on the run...) >> >> >> I've tested this with 2 images and 3 VMs in all 6 >> combinations: >> >> - "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5 >> - "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5 >> - "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0 >> - Clean image: commit id: b28d466f >> - Work image: commit id: eb0a6fb1 >> >> The gcc 5 is only there because I was playing with it. The results may >> be useful, or completely misleading. :-) >> >> Each time I ran "5 timesRepeat: [ self test4 ]" >> with the halts replaced with a count increment. >> test4 is the method provided in Cyrille's original message. >> >> Result summary: >> >> - Old VM + Work image: 5, 5, 5, 0, 0 >> - Old VM + Clean image: 5, 5, 0, 0, 0 >> - New VM + Work image: 5, 0, 5, 5, 5 >> - New VM + Clean image: 0, 0, 1, 5, 5 >> - GCC 5 + Work image: 0, 0, 0, 0, 0 >> - GCC 5 + Clean image: 0, 0, 0, 0, 0 > > > This is strong evidence for the issue being a compiler bug with 4.8.x > If exactly the same input source for the Vm wrks with gcc 5 but not with 4.8.x then there is a small chance it is due to the Vm relying on undefined behavior, but I doubt it. > Assuming it is a gcc bug then > - it should be documented in the HowToBuild files for the relevant platforms > - Ci builds should start using gcc 5 and dispense with gcc 4.8.x > - since the problem is fixed with gcc 5 there seems little point trying to identify which version of gcc introduces the problem and communicating the problem to the gcc maintainers > > What's the status of the bug on Windows and Mac OS X? I can't check MacOS. Clement? I get the problem on Windows (version info below). Note that Max Leske and I have been using gcc 4.8 because of a problem with OSProcess and gcc 5 (it possibly doesn't affect me anymore, I'm currently using OSSubprocess). See: http://lists.squeakfoundation.org/pipermail/vm-dev/2017-May/025216.html I'll try and confirm correct OSSubprocess operation with gcc 5, but it will take a while, I'm battling too many different problems at the moment: - TZ and DST handling on Windows - Windows VM suddenly can't find any of its plugins. Is anyone else seeing strange behaviour here with VMs from the last few days? -- It looks like the plugin handling mechanism is completely different on Windows to Unix, so the VM doesn't report where it is looking and doesn't provide the option to specify the directory. Grrrrrgh. - My linux build environment. - real life :-) Windows version info: OS: Windows 10 Image: Pharo 7.0 Build information: Pharo-7.0+alpha.build.439.sha.481071068244d0484241924f79ba791f80701316 (32 Bit) VM: Win32 built on Nov 27 2017 00:05:44 GMT Compiler: 6.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog- nice.2281 uuid: 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Cheers, Alistair

Jan. 23, 2018

Re: [Pharo-dev] [Vm-dev] Random corrupted data when copying from very large byte array

by Eliot Miranda

Hi Alistair, On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Eliot, > > On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote: > > Hi Eliot, > > > > On 19 January 2018 at 23:04, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > Hi Alistair, Hi Cl??ment, > > > > > > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant < > akgrant0710(a)gmail.com> > > > wrote: > > >> > > >> Hi Cl??ment, > > >> > > >> On 19 January 2018 at 17:21, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > >> > Hi Cl??ment, > > >> > > > >> > On 19 January 2018 at 17:04, Cl??ment Bera <bera.clement(a)gmail.com> > > >> > wrote: > > >> >> Does not seem to be related to prim 105. > > >> >> > > > > > > > > > I suspect that the problem is the same compactor bug I've been trying > to > > > reproduce all week, and have just fixed. Could you try and reproduce > with a > > > VM built from the latest commit? > > > > Happy to, but I'm out all day today, so it will be tomorrow or Monday. > > > > Cheers, > > Alistair > > (on the run...) > > > I've tested this with 2 images and 3 VMs in all 6 > combinations: > > - "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5 > - "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5 > - "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0 > - Clean image: commit id: b28d466f > - Work image: commit id: eb0a6fb1 > > The gcc 5 is only there because I was playing with it. The results may > be useful, or completely misleading. :-) > > Each time I ran "5 timesRepeat: [ self test4 ]" > with the halts replaced with a count increment. > test4 is the method provided in Cyrille's original message. > > Result summary: > > - Old VM + Work image: 5, 5, 5, 0, 0 > - Old VM + Clean image: 5, 5, 0, 0, 0 > - New VM + Work image: 5, 0, 5, 5, 5 > - New VM + Clean image: 0, 0, 1, 5, 5 > - GCC 5 + Work image: 0, 0, 0, 0, 0 > - GCC 5 + Clean image: 0, 0, 0, 0, 0 > This is strong evidence for the issue being a compiler bug with 4.8.x If exactly the same input source for the Vm wrks with gcc 5 but not with 4.8.x then there is a small chance it is due to the Vm relying on undefined behavior, but I doubt it. Assuming it is a gcc bug then - it should be documented in the HowToBuild files for the relevant platforms - Ci builds should start using gcc 5 and dispense with gcc 4.8.x - since the problem is fixed with gcc 5 there seems little point trying to identify which version of gcc introduces the problem and communicating the problem to the gcc maintainers What's the status of the bug on Windows and Mac OS X? Old VM: > 5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 > [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 > Jan 11 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: > 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 > VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm > $ Date: Wed Jan 10 23:39:30 2018 -0800 $ > Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm > $ > Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 > 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux > plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: > /snap/pharo7/x1/usr/bin/pharo-vm32/] > > > > New VM: > 5.0-201801201252 Saturday 20 January 21:24:16 CET 2018 gcc 4.8.5 > [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 > Jan 20 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: > e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 > VM: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm > $ Date: Sat Jan 20 13:52:26 2018 +0100 $ > Plugins: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm > $ > Linux 73cbbaa49451 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 > 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux > plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: > /snap/pharo7/x1/usr/bin/pharo-vm32/] > > > > GCC 5 VM: > 5.0-201801201252 Sun Jan 21 14:41:41 UTC 2018 gcc 5.4.0 [Production Spur > VM] > CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 > Jan 21 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: > e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 > VM: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Date: > Sat Jan 20 13:52:26 2018 +0100 $ > Plugins: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ > Linux ec9d95d2105a 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 > 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux > plugin path: /home/alistair/squeak/opensmalltalk-vm/products/ > phcogspurlinuxht/lib/pharo/5.0-201801201252 [default: > /home/alistair/squeak/opensmalltalk-vm/products/ > phcogspurlinuxht/lib/pharo/5.0-201801201252/] > > > HTH, > Alistair > > > > > > Some details: > > > The SpurPlanningCompactor works by using the fact that all Spur > objects have > > > room for a forwarding pointer. The compactor make three passes: > > > > > > - the first pass through memory works out where objects will go, > replacig > > > their first fields with where they will go, and saving their first > fields in > > > a buffer (savedFirstFieldsSpace). > > > - the second pass scans all pointer objects, replacing their fields > with > > > where the objects referenced will go (following the forwarding > pointers), > > > and also relocates any pointer fields in savedFirstFieldsSpace > > > - the final pass slides objects down, restoring their relocated first > fields > > > > > > The buffer used for savedFirstFieldsSpace determines how many passes > are > > > used. The system will either use eden (which is empty when compaction > > > occurs) or a large free chunk or allocate a new segment, depending on > > > whatever yields the largest space. So in the right circumstances eden > will > > > be used and more than one pass required. > > > > > > The bug was that when multiple passes are used the compactor forgot to > > > unmark the corpse left behind when the object was moved. Instead of > the > > > corpse being changed into free space it was retained, but its first > field > > > would be that of the forwarding pointer to its new location, not the > actual > > > first field. So on 32-bits a ByteArray that should have been collected > > > would have its first 4 bytes appear to be invalid, and on 64-bits its > first > > > 8 bytes. Because the heap on 64-bits can grow larger it could be that > the > > > bug shows itself much less frequently than on 32-bits. When compaction > can > > > be completed in a single pass all corpses are correctly collected, so > most > > > of the time the bug is hidden. > > > > > > This is the commit: > > > commit 0fe1e1ea108e53501a0e728736048062c83a66ce > > > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > > > Date: Fri Jan 19 13:17:57 2018 -0800 > > > > > > CogVM source as per VMMaker.oscog-eem.2320 > > > > > > Spur: > > > Fix a bad bug in SpurPlnningCompactor. > > > unmarkObjectsFromFirstFreeObject, > > > used when the compactor requires more than one pass due to > insufficient > > > savedFirstFieldsSpace, expects the corpse of a moved object to be > > > unmarked, > > > but copyAndUnmarkObject:to:bytes:firstField: only unmarked the > target. > > > Unmarking the corpse before the copy unmarks both. This fixes a > crash > > > with > > > ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: > > > creates > > > lots of files, enough to push the system into the multi-pass > regime. > > > > -- _,,,^..^,,,_ best, Eliot

Jan. 23, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-01-15

by Chris Muller

Getting the serialization working is a big step, good job. If you can get MaClientServerTestCase suite debug to pass, then you should be nearly home free; the rest is mostly just high-level stuff that builds on that so the rest of the port should go fairly smoothly. Wow. On Mon, Jan 22, 2018 at 2:47 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > - continuing on Ring 2 integration > - work on Magma port to Pharo. It's very far from being in a usable > state but some progress has been done: > - make packages from the version 1.6-tests loadable, baseline > - fix tests for collections (except two weak related) are green > - fix indexing tests > - object serialization tests are green except the tests for > serialization of context > > Cheers, > -- Pavel >

Jan. 22, 2018

[Pharo 7.0-dev] Build #439: 21016-Execute-the-condition-of-conditional-breakpoints-as-if-in-the-context-the-breakpoint-has-been-placed

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #439 was: SUCCESS. The Pull Request #693 was integrated: "21016-Execute-the-condition-of-conditional-breakpoints-as-if-in-the-context-the-breakpoint-has-been-placed" Pull request url: https://github.com/pharo-project/pharo/pull/693 Issue Url: https://pharo.fogbugz.com/f/cases/21016 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 22, 2018

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

by Alistair Grant

Hi Eliot, On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote: > Hi Eliot, > > On 19 January 2018 at 23:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Alistair, Hi Cl??ment, > > > > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <akgrant0710(a)gmail.com> > > wrote: > >> > >> Hi Cl??ment, > >> > >> On 19 January 2018 at 17:21, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> > Hi Cl??ment, > >> > > >> > On 19 January 2018 at 17:04, Cl??ment Bera <bera.clement(a)gmail.com> > >> > wrote: > >> >> Does not seem to be related to prim 105. > >> >> > > > > > > I suspect that the problem is the same compactor bug I've been trying to > > reproduce all week, and have just fixed. Could you try and reproduce with a > > VM built from the latest commit? > > Happy to, but I'm out all day today, so it will be tomorrow or Monday. > > Cheers, > Alistair > (on the run...) I've tested this with 2 images and 3 VMs in all 6 combinations: - "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5 - "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5 - "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0 - Clean image: commit id: b28d466f - Work image: commit id: eb0a6fb1 The gcc 5 is only there because I was playing with it. The results may be useful, or completely misleading. :-) Each time I ran "5 timesRepeat: [ self test4 ]" with the halts replaced with a count increment. test4 is the method provided in Cyrille's original message. Result summary: - Old VM + Work image: 5, 5, 5, 0, 0 - Old VM + Clean image: 5, 5, 0, 0, 0 - New VM + Work image: 5, 0, 5, 5, 5 - New VM + Clean image: 0, 0, 1, 5, 5 - GCC 5 + Work image: 0, 0, 0, 0, 0 - GCC 5 + Clean image: 0, 0, 0, 0, 0 Old VM: 5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $ Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-vm32/] New VM: 5.0-201801201252 Saturday 20 January 21:24:16 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 VM: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $ Plugins: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux 73cbbaa49451 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-vm32/] GCC 5 VM: 5.0-201801201252 Sun Jan 21 14:41:41 UTC 2018 gcc 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 VM: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $ Plugins: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Linux ec9d95d2105a 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /home/alistair/squeak/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-201801201252 [default: /home/alistair/squeak/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-201801201252/] HTH, Alistair > > Some details: > > The SpurPlanningCompactor works by using the fact that all Spur objects have > > room for a forwarding pointer. The compactor make three passes: > > > > - the first pass through memory works out where objects will go, replacig > > their first fields with where they will go, and saving their first fields in > > a buffer (savedFirstFieldsSpace). > > - the second pass scans all pointer objects, replacing their fields with > > where the objects referenced will go (following the forwarding pointers), > > and also relocates any pointer fields in savedFirstFieldsSpace > > - the final pass slides objects down, restoring their relocated first fields > > > > The buffer used for savedFirstFieldsSpace determines how many passes are > > used. The system will either use eden (which is empty when compaction > > occurs) or a large free chunk or allocate a new segment, depending on > > whatever yields the largest space. So in the right circumstances eden will > > be used and more than one pass required. > > > > The bug was that when multiple passes are used the compactor forgot to > > unmark the corpse left behind when the object was moved. Instead of the > > corpse being changed into free space it was retained, but its first field > > would be that of the forwarding pointer to its new location, not the actual > > first field. So on 32-bits a ByteArray that should have been collected > > would have its first 4 bytes appear to be invalid, and on 64-bits its first > > 8 bytes. Because the heap on 64-bits can grow larger it could be that the > > bug shows itself much less frequently than on 32-bits. When compaction can > > be completed in a single pass all corpses are correctly collected, so most > > of the time the bug is hidden. > > > > This is the commit: > > commit 0fe1e1ea108e53501a0e728736048062c83a66ce > > Author: Eliot Miranda <eliot.miranda(a)gmail.com> > > Date: Fri Jan 19 13:17:57 2018 -0800 > > > > CogVM source as per VMMaker.oscog-eem.2320 > > > > Spur: > > Fix a bad bug in SpurPlnningCompactor. > > unmarkObjectsFromFirstFreeObject, > > used when the compactor requires more than one pass due to insufficient > > savedFirstFieldsSpace, expects the corpse of a moved object to be > > unmarked, > > but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. > > Unmarking the corpse before the copy unmarks both. This fixes a crash > > with > > ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: > > creates > > lots of files, enough to push the system into the multi-pass regime. > >

Jan. 22, 2018

[JOB] Engineer 1 year: Pharo IoT platform

by Marcus Denker

Inria RMoD are looking for a full-time engineer for helping with developing Pharo in the context of IoT. The focus of this job is "Pharo on embedded and mobile devices for the internet of things" With Pharo, we have developed over the last two years an interactive, remote development environment. It allows embedded, headless software running on typical raspberry pi class hardware to be developed and debugged in an interactive way. It allows programmers to explore and change running headless embedded programs from their desktop development machine. The next step will be to extend this infrastructure to cover the use case of industrial use: Deployment. We want to build a middle-ware to manage, authenticate and script deployed Pharo embedded installations. The engineer will help to develop the Pharo IoT infrastructure, especially with a focus on industrial use: â¢ Improve Pharo for a platform with an industrial focus. â¢ Work on a middleware to manage deployed Pharo instances. â¢ Realize two small demos: First, as an industrial IoT example, a demo deployed on 20+ devices. Demo 2: Pharo deployed on multiple mobile autonomous robots. â¢ Help with creating a website for PharoIOT. We are looking for a candidate with some prior experience with Pharo. In addition: â¢ Knowledge in Dynamic Languages (Pharo is a plus but not required) â¢ Experience with embedded development is a plus but not required â¢ English Work in a research lab, but no paper writing, no teaching, no administration. In addition: â¢ Centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) â¢ Try a lot of good beer (our office is just 10km from the border to Belgium) â¢ Program with Pharo all day! â¢ Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). â¢ Duration: 12 Month â¢ Starting date: As soon as possible (Spring 2018) â¢ Salary: 2600-3200 euros brut / month, depending on experience â¢ Explanation Salary: french brutto = money after social charges (and base health insurance) before income tax, which is max one month income payed yearly, depending on family situation (can be 0 for a family with kids) â¢ Location: Lille (no remote job possible)) More about â¢ Pharo: http://www.pharo.org â¢ PharoThings: https://github.com/pharo-iot/PharoThings â¢ INRIA RMOD: http://rmod.lille.inria.fr â¢ INRIA Lille: http://www.inria.fr/lille â¢ INRIA in General: http://www.inria.fr â¢ Lille: â¢ http://en.wikipedia.org/wiki/Lille â¢ http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. Permanent Link to this call: https://rmod.inria.fr/web/blog/2017-10-20

Jan. 22, 2018

Pavel's ChangeLog week of 2018-01-15

by Pavel Krivanek

Hi, - continuing on Ring 2 integration - work on Magma port to Pharo. It's very far from being in a usable state but some progress has been done: - make packages from the version 1.6-tests loadable, baseline - fix tests for collections (except two weak related) are green - fix indexing tests - object serialization tests are green except the tests for serialization of context Cheers, -- Pavel

Jan. 22, 2018