- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Marcus Denker

> On 15 Feb 2018, at 12:56, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > 2018-02-15 11:31 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >>> On 14 Feb 2018, at 21:34, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 14/02/2018 Ã 20:19, Stephane Ducasse a Ã©crit : >>>> Thanks Pavel this looks quite fast :). >>>> Do you have a scenario in mind that could take advantage of this? >>> >>> I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]). >>> >>> If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do). >>> >>> >> Yes, that is the direction to explore :-) > > When I worked on that sort of systems, one of the questions I had was: > what about the GC ? But yes, in today's context, focusing on process > based concurrency can be interesting. > >> This started with me and Pavel discussion about the general idea that it would be interesting if Objects would actually be âreally recursiveâ (and the whole system would be such an Object, too). > > I'm not sure I get the concept. Would you be ready to explain ? I have started to write something about it (I need to make it clearer for myself, too). When it is in some presentable shape (currently just notes) I will forward it. Marcus

Feb. 15, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Thierry Goubier

2018-02-15 11:31 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > >> On 14 Feb 2018, at 21:34, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 14/02/2018 Ã 20:19, Stephane Ducasse a Ã©crit : >>> Thanks Pavel this looks quite fast :). >>> Do you have a scenario in mind that could take advantage of this? >> >> I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]). >> >> If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do). >> >> > Yes, that is the direction to explore :-) When I worked on that sort of systems, one of the questions I had was: what about the GC ? But yes, in today's context, focusing on process based concurrency can be interesting. > This started with me and Pavel discussion about the general idea that it would be interesting if Objects would actually be âreally recursiveâ (and the whole system would be such an Object, too). I'm not sure I get the concept. Would you be ready to explain ? > And then asking the question: what is the minimal thing we need to explore that direction? On a meta-level, I can understand that. Thierry >> >> [1] https://hal.archives-ouvertes.fr/hal-01679052 >> > > I will read that. I talked to Loic about that sort of ideas (his S-DSM could do even more interesting things) but also of the fact we don't have the resources and time to explore it :( Thierry > > Marcus > >

Feb. 15, 2018

Re: [Pharo-dev] Searching for an internship

by phil＠highoctane.be

Is FileOuterNG available? Phil On Feb 15, 2018 12:06, "Maxime Roelandt" <mroelandt(a)gmail.com> wrote: > Hi all, > > I'm searching for an internship as student of Master's 2 degree in > Computer Science at University of Lille1. > > My skills are essentially in Smalltalk and C. > > Minimum 1500 â¬ net salary. > I am available from March : Period 4 to 6 months. > > I've worked for RMoD team, two times : > - 2016 : FileOuterNG -> VisualWorks code converter to Pharo > - 2017 : Pillar reengineering. > > Please find attached my CV if you're interested in > > ++ >

Feb. 15, 2018

[Pharo 7.0-dev] Build #548: 21336-Cleanup-again-in-texteditor

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

There is a new Pharo build available! The status of the build #548 was: SUCCESS. The Pull Request #878 was integrated: "21336-Cleanup-again-in-texteditor" Pull request url: https://github.com/pharo-project/pharo/pull/878 Issue Url: https://pharo.fogbugz.com/f/cases/21336 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2018

Searching for an internship

by Maxime Roelandt

Hi all, I'm searching for an internship as student of Master's 2 degree in Computer Science at University of Lille1. My skills are essentially in Smalltalk and C. Minimum 1500 â¬ net salary. I am available from March : Period 4 to 6 months. I've worked for RMoD team, two times : - 2016 : FileOuterNG -> VisualWorks code converter to Pharo - 2017 : Pillar reengineering. Please find attached my CV if you're interested in ++

Feb. 15, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Marcus Denker

> On 14 Feb 2018, at 21:34, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 14/02/2018 Ã 20:19, Stephane Ducasse a Ã©crit : >> Thanks Pavel this looks quite fast :). >> Do you have a scenario in mind that could take advantage of this? > > I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]). > > If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do). > > Yes, that is the direction to explore :-) This started with me and Pavel discussion about the general idea that it would be interesting if Objects would actually be âreally recursiveâ (and the whole system would be such an Object, too). And then asking the question: what is the minimal thing we need to explore that direction? > > [1] https://hal.archives-ouvertes.fr/hal-01679052 > I will read that. Marcus

Feb. 15, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Tudor Girba

Hi Pavel, This is very cool. Is the code available? Cheers, Doru > On Feb 12, 2018, at 10:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > among other less interesting things, I spent some time on existing > PosixSharedMemory project. It is a UFFI binding for the LibC methods > that provide support for the memory allocation between several > separate processes. I significantly improved the performance by > implementing the block access. Writing of 10MB byte array takes about > 1 millisecond, reading of it from other image took me about 4 > milliseconds. While serialization with Fuel is very fast, it opens > interesting possibilities. > To have a shared memory without synchronization tools is not very > useful so I wrote a basic UFFI interface for the POSIX named > semaphores. They are quite easy to use and work nicely with Pharo. The > VM can all wait on the semaphore or it can check the status of it > periodically in an image thread. It has two small disadvantages. It > requires to dynamically link the next library (pthread) and they must > be cleaned manually. I plan to look at System V alternative in future. > Now we should write a nice framework for inter-image communication on > top of it or/and adopt Seamless for it ;-) > > Cheers, > -- Pavel > -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Feb. 15, 2018

[Pharo 7.0-dev] Build #547: 21340-isReadOnlyObject-should-not-fail-when-VM-do-not-support-write-barrier

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

There is a new Pharo build available! The status of the build #547 was: SUCCESS. The Pull Request #883 was integrated: "21340-isReadOnlyObject-should-not-fail-when-VM-do-not-support-write-barrier" Pull request url: https://github.com/pharo-project/pharo/pull/883 Issue Url: https://pharo.fogbugz.com/f/cases/21340 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 15, 2018

Re: [Pharo-dev] [ANN] Remember tomorrow 15/02 16hUTC tech talk "contributing to Pharo 7"

by Stephane Ducasse

Tx esteban Use big fonts! Stef On Wed, Feb 14, 2018 at 8:31 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Subject says all. > Iâm a bit sick but I will do my best to handle the session :D > > See you all tomorrow!

Feb. 15, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-05

by Thierry Goubier

Le 14/02/2018 Ã 20:19, Stephane Ducasse a Ã©critÂ : > Thanks Pavel this looks quite fast :). > Do you have a scenario in mind that could take advantage of this? I'd be very interested to see that used with image segments for objects migration between images running in different processes (or coupled with a distributed shared memory implementation like [1]). If latency is low enough, I think multi-window applications could be developped as multi-process single window images (and we could get scalability to thousands of cores, if the application design is right. Even code synchronisation between images would be easy to do). Thierry [1] https://hal.archives-ouvertes.fr/hal-01679052 > Stef > > On Mon, Feb 12, 2018 at 10:33 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> among other less interesting things, I spent some time on existing >> PosixSharedMemory project. It is a UFFI binding for the LibC methods >> that provide support for the memory allocation between several >> separate processes. I significantly improved the performance by >> implementing the block access. Writing of 10MB byte array takes about >> 1 millisecond, reading of it from other image took me about 4 >> milliseconds. While serialization with Fuel is very fast, it opens >> interesting possibilities. >> To have a shared memory without synchronization tools is not very >> useful so I wrote a basic UFFI interface for the POSIX named >> semaphores. They are quite easy to use and work nicely with Pharo. The >> VM can all wait on the semaphore or it can check the status of it >> periodically in an image thread. It has two small disadvantages. It >> requires to dynamically link the next library (pthread) and they must >> be cleaned manually. I plan to look at System V alternative in future. >> Now we should write a nice framework for inter-image communication on >> top of it or/and adopt Seamless for it ;-) >> >> Cheers, >> -- Pavel >> > >

Feb. 14, 2018