- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [Moose-dev] feenk log

by Tudor Girba

Hi, > On Jan 21, 2018, at 10:37 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > On 21 January 2018 at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> There is a difference in performance. The Announcement is slower (about 2-3x slower). However, for 1M events the difference is measured in a 200-400ms, which is very small. > > So you mean each event <1ms difference? > btw, what is the biggest usage of events? I guess mouse movements? > How many such events typically in 1 second of movement? > How is performance on StackInterpreter VM? > I guess we should keep that performant for platforms lacking JIT like > iPads, etcâ¦ It depends on the scene. We are still looking into how to evaluate this. Thatâs why we still have both implementations around. >> The benefit of using Announcement is that we can reuse the tooling around Announcement, such as blogging and debugging. > > This looks really useful. Can you describe the difference between the > red and blue lines in the picture of the first link? Each event goes through two passes, like in JavaScript: - The first is called âcapturingâ (or filtering) and goes from the root to the leaf. This is to allow a parent to prevent a child to react to an event. - The second one is called âbubblingâ (or handling) and goes from the leaf to the root. This is to find the most specific element to handle the event. Cheers, Tudor > cheers -ben > >> >> Still, the way it is used in Bloc is different from the typical usage in that Bloc registers to all Events (which are Announcements) and then dispatches through them to specific Element method (like BlEventListener>>clickEvent:). Still the cool thing is that you also can still register from the outside to a specific event using a normal when:do:. >> >> We will write a piece of doc about it. >> >> Cheers, >> Tudor >> >> >>> On Jan 21, 2018, at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> this looks really cool. >>> For the event I remember the discussion with glenn about the difference and I forgot. >>> >>> Stef >>> >>>> On 21 Jan 2018, at 15:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> Here is an update of the work on Bloc and GT. As always, please do let us know what you think. >>>> >>>> Bloc: >>>> - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: >>>> https://twitter.com/feenkcom/status/955086133519618048 >>>> https://twitter.com/feenkcom/status/946482609680539649 >>>> - Embedding Bloc elements in Morphic is even easier now: >>>> https://twitter.com/feenkcom/status/946676667002556416 >>>> - We continued the work towards an interactive creation of a graphical scene: >>>> https://twitter.com/feenkcom/status/948492946541858816 >>>> - Theme experiment >>>> >>>> GT: >>>> - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: >>>> https://twitter.com/feenkcom/status/939394586115563520 >>>> - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. >>>> >>>> Have fun, >>>> The feenk team >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Obvious things are difficult to teach." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr >>> http://www.synectique.eu / http://www.pharo.org >>> 03 59 35 87 52 >>> Assistant: Julie Jonas >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Beauty is where we see it." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

Jan. 21, 2018

Re: [Pharo-dev] [Pharo-users] ZnClient in Pharo 6.1 not working for Https on Windows

by phil＠highoctane.be

Back from the grave on this one but the current 6.1 is not fixed on that front and the antivirus (Defender) does not delete anything. This makes 6.1 an unusable target on Windows and 70 is also unusable. So, the only viable thing is a 50. This is not really serious. What's the point of piling features upon features if basic stuff is not working? Phil On Fri, Oct 6, 2017 at 6:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > both now I do not see what we can do if a third party tools consider > that we are a virus. > > On Fri, Oct 6, 2017 at 6:09 PM, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com> wrote: > > Le 06/10/2017 Ã 13:02, kmo a Ã©crit : > >> I was trying to Soup on Windows 7 and found I could not access https > sites > >> > >> On windows 7 and 10 the following code fails: > >> > >> ZnEasy get:'https://genius.com/Alice-nuvole-lyrics'. > >> > >> This works fine in Pharo 5 on Windows. Also works fine with Pharo 6.1 > (32 > >> bit) on Linux. > >> > >> The problem is Pharo 6.1 on Windows. > >> > >> The error is: > >> > >> "SSL/TLS plugin initialization failed (VM plugin missing ? OS libraries > >> missing ?)" > >> > >> I know that his has been seen on Linux in the past - see > >> http://forum.world.st/SSL-TLS-plugin-initailization-failed- > VM-plugin-missing-OS-libraries-missing-td4945857.html > >> > >> I'm running the latest vm and 6.1 image. > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > I just saw that Windows Defender consider this plugin as a Trojan and > > delete it. > > > > Name of the menace: Trojan:Win32/Azden.A!cl > > > > Should this be reported on Pharo's issue tracker or on opensmalltalk one? > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > > 59650 Villeneuve d'ascq France > > > >

Jan. 21, 2018

Re: [Pharo-dev] [Moose-dev] Re: feenk log

by Ben Coman

On 21 January 2018 at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > There is a difference in performance. The Announcement is slower (about 2-3x slower). However, for 1M events the difference is measured in a 200-400ms, which is very small. So you mean each event <1ms difference? btw, what is the biggest usage of events? I guess mouse movements? How many such events typically in 1 second of movement? How is performance on StackInterpreter VM? I guess we should keep that performant for platforms lacking JIT like iPads, etc... > The benefit of using Announcement is that we can reuse the tooling around Announcement, such as blogging and debugging. This looks really useful. Can you describe the difference between the red and blue lines in the picture of the first link? cheers -ben > > Still, the way it is used in Bloc is different from the typical usage in that Bloc registers to all Events (which are Announcements) and then dispatches through them to specific Element method (like BlEventListener>>clickEvent:). Still the cool thing is that you also can still register from the outside to a specific event using a normal when:do:. > > We will write a piece of doc about it. > > Cheers, > Tudor > > >> On Jan 21, 2018, at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> this looks really cool. >> For the event I remember the discussion with glenn about the difference and I forgot. >> >> Stef >> >>> On 21 Jan 2018, at 15:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Here is an update of the work on Bloc and GT. As always, please do let us know what you think. >>> >>> Bloc: >>> - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: >>> https://twitter.com/feenkcom/status/955086133519618048 >>> https://twitter.com/feenkcom/status/946482609680539649 >>> - Embedding Bloc elements in Morphic is even easier now: >>> https://twitter.com/feenkcom/status/946676667002556416 >>> - We continued the work towards an interactive creation of a graphical scene: >>> https://twitter.com/feenkcom/status/948492946541858816 >>> - Theme experiment >>> >>> GT: >>> - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: >>> https://twitter.com/feenkcom/status/939394586115563520 >>> - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. >>> >>> Have fun, >>> The feenk team >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Obvious things are difficult to teach." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 21, 2018