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

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

Re: [Pharo-dev] Do we remove EyeInspector from Pharo 70?

by Stephane Ducasse

Thanks for your information. I do not know but indeed then we will should have a look. On Sun, Feb 11, 2018 at 9:40 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > I sometimes use the Eye Pointer Inspector to find memory leaks ... is there > a replacement for that? > > Peter > > On Sun, Feb 11, 2018 at 9:29 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> I would vote for. >> >> Stef >> >

Feb. 14, 2018

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

by Esteban Lorenzano

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. 14, 2018

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

by Stephane Ducasse

Thanks Pavel this looks quite fast :). Do you have a scenario in mind that could take advantage of this? 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

Re: [Pharo-dev] Ficus question

by Stephane Ducasse

It was a kind of model for epicea. Stef On Wed, Feb 14, 2018 at 8:50 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > What is Ficus? > > Norbert > >> Am 13.02.2018 um 18:23 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi martin >> >> I would like to know what is the API Ficus uses from TClass. >> Do you have an idea? >> >> >> Stef >

Feb. 14, 2018