May 2017 - Pharo-dev - lists.pharo.org

[ANN] Zeroconf stable will be moved tomorrow to 6.0 (as part of the release process)

by Esteban Lorenzano

Hi, We will move stable to 6.0 and alpha to 7.0. So if you depend on something that can be affected by this, is the moment to update your scripts. cheers, Esteban

May 31, 2017

please test download for Pharo 6.0

by Esteban Lorenzano

Hello, we are getting ready for release. please take a minute to review: http://pharo.org/STAGE.download <http://pharo.org/STAGE.download> (notice that zerconf download will not work because it is not yet movedâ¦ so #stable will download current stable version which is 5.0) cheers, Esteban

May 31, 2017

Re: [Pharo-dev] DebugSession: no exception raised when stepping out of the execution?

by Guillermo Polito

On Mon, May 29, 2017 at 6:07 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Thomas, > > > On May 29, 2017, at 7:41 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Mon, May 29, 2017 at 9:34 PM, <tdupriez(a)ens-paris-saclay.fr> wrote: > > [...] > >> Here is my example code. Beware, running it will freeze the VM. >> >> | program process context debugSession | >> program := [1+2]. >> process := program newProcess. >> context := process suspendedContext. >> debugSession := process newDebugSessionNamed: 'StepIntoForever' >> startedAt: context. >> [ true ] whileTrue: [ debugSession stepInto ]. >> >> [...] > In particular, your use of stepInto: will soon step into the process > termination code. See newProcess. You have to stop simulating before you > stop the current process by mistake. > > Yes, I explained yesterday to Thomas that this would end up terminating the UIProcess where the debugger is running on, instead of terminating the process that is being debugged. But, it looks like a bug... It would make sense to me that "Processor activeContext" yields the debugged context in the simulated code instead of the real active context. And I believe that this change should not break any existing code. Actually, thinking a bit more about this, similar problems may happen if we try to execute in the debugger Semaphore code in the debugger. So probably, in general terms, the debugger should handle specially all code that messes up with the Process machinery. -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 31, 2017

Recording TechTalk Roassal available

by Marcus Denker

Hello! The recording of the Roassal Techtalk of yesterday is available here: https://www.youtube.com/watch?v=-Pk4q5oMdLo (start at 7:35) A PDF with all the code of the demos shown: http://files.pharo.org/media/techtalk/RoassalTechTalk.pdf

May 31, 2017

Re: [Pharo-dev] basicNew usage pattern

by Ben Coman

Thanks for the additional perspective Guille. Now reading back I see that I was not explicit. I was proposing the following changes might be preferred... Example1 -- DAPackageRelationGraph>>addMessageSendDependencies: aPackage analyser := DAMessageSendAnalyzer newWith: aPackage; yourself. Example 2 -- FreeTypeFontProvider>>#updateFromFile: aFile face := FreeTypeFace newWithFileContentsExternalMemory: externalMem . since I'm guessing the above aren't performance sensitive. Example 3, same idea, but maybe its performance critical, but as you say, sista should fix that. cheers -ben On Tue, May 30, 2017 at 2:40 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi Ben, > > Just to complete Sven's answer: #new will send #initialize to the new > instance. Some frameworks may not want that to avoid extra initializations > or side-effects. Think for example about any kind of serializer like Fuel > or Glorp: the object they serialize/deserialize already have state, there > is no need to execute the #initialize method on them. > > Now, checking the cases you show in the first email: > > - Case 1: could probably call #new > - Case 2: I don't know without checking the code :) > - Case 3: could probably call #new > > I think Cases 1 and 3 are just optimizations. They avoid #new to avoid the > extra (empty) call to #initialize. Sista should fix this by smartly > inlining the #initialize methods thus avoiding extra overhead for these > cases... > > That said, I'd say that > - people should not use #basicNew, unless they know what they are doing > and why. > - corollary: if you do not know what to use, use #new > > That will avoid headaches like "My object is not initialized Ã±aaÃ±aÃ±a" :) > > Guille > > On Tue, May 30, 2017 at 8:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Tue, May 30, 2017 at 2:05 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> >>> On Sunday 28 May 2017 02:09 PM, Ben Coman wrote: >>> >>>> Thanks Subbu. That is a useful insight for me, but is about the >>>> implementation. >>>> My query was more about senders of basicNew, so is still open if you >>>> have an opinion there, or anyone else. >>>> >>> >>> It is just a private primitive for creating new instances. I don't think >>> there is any restriction in the language that it should only be sent only >>> from class-side methods. Only methods which are part of language >>> implementation will send this selector and it so happens that most callers >>> fall on the class side. You will also find instance side methods >>> (operators) in non-trivial basic types like Colors or DateAndTime sending >>> #basicNew. >>> >>> Regards .. Subbu >>> >>> >> Cool. Sounds like I was being over-eager then. >> cheers -ben >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

May 30, 2017

[TECHTALK] Roassal TechTalk will be live in 15 min !

by Esteban Lorenzano

So, Alex will start the TechTalk in 15min Youtube: https://www.youtube.com/c/AlexandreBergel/live <https://www.youtube.com/c/AlexandreBergel/live> Discord: http://discord.gg/Sj2rhxn <http://discord.gg/Sj2rhxn> and the book: http://agilevisualization.com/ <http://agilevisualization.com/> See you there! Esteban

May 30, 2017

crash on laptop wake up with external screen

by Christophe Demarey

Hi, I just want to share that I experience regular crashes but I did not managed to determine exact circumstances. Here is the case: I run a Pharo image on my laptop with a screen connected to the laptop, leave to home (work with the laptop screen), then going back to work (with external screen plugged before logging back, still the same session) => pharo / vm crash. I attached the crash dump. Hope this helps, Christophe

May 30, 2017

[ANN] Pharo Sprint June 2

by Marcus Denker

Hi! This Friday will be the next Pharo Sprint! We will organize a Pharo sprint / Moose dojo June 02, starting at 10:00am. (Local Time Paris). For more infos, see: https://association.pharo.org/event-2492490 Marcus

May 30, 2017

Re: [Pharo-dev] basicNew usage pattern

by Guillermo Polito

Hi Ben, Just to complete Sven's answer: #new will send #initialize to the new instance. Some frameworks may not want that to avoid extra initializations or side-effects. Think for example about any kind of serializer like Fuel or Glorp: the object they serialize/deserialize already have state, there is no need to execute the #initialize method on them. Now, checking the cases you show in the first email: - Case 1: could probably call #new - Case 2: I don't know without checking the code :) - Case 3: could probably call #new I think Cases 1 and 3 are just optimizations. They avoid #new to avoid the extra (empty) call to #initialize. Sista should fix this by smartly inlining the #initialize methods thus avoiding extra overhead for these cases... That said, I'd say that - people should not use #basicNew, unless they know what they are doing and why. - corollary: if you do not know what to use, use #new That will avoid headaches like "My object is not initialized Ã±aaÃ±aÃ±a" :) Guille On Tue, May 30, 2017 at 8:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Tue, May 30, 2017 at 2:05 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > >> On Sunday 28 May 2017 02:09 PM, Ben Coman wrote: >> >>> Thanks Subbu. That is a useful insight for me, but is about the >>> implementation. >>> My query was more about senders of basicNew, so is still open if you >>> have an opinion there, or anyone else. >>> >> >> It is just a private primitive for creating new instances. I don't think >> there is any restriction in the language that it should only be sent only >> from class-side methods. Only methods which are part of language >> implementation will send this selector and it so happens that most callers >> fall on the class side. You will also find instance side methods >> (operators) in non-trivial basic types like Colors or DateAndTime sending >> #basicNew. >> >> Regards .. Subbu >> >> > Cool. Sounds like I was being over-eager then. > cheers -ben > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 30, 2017

Re: [Pharo-dev] basicNew usage pattern

by Ben Coman

On Tue, May 30, 2017 at 2:05 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Sunday 28 May 2017 02:09 PM, Ben Coman wrote: > >> Thanks Subbu. That is a useful insight for me, but is about the >> implementation. >> My query was more about senders of basicNew, so is still open if you >> have an opinion there, or anyone else. >> > > It is just a private primitive for creating new instances. I don't think > there is any restriction in the language that it should only be sent only > from class-side methods. Only methods which are part of language > implementation will send this selector and it so happens that most callers > fall on the class side. You will also find instance side methods > (operators) in non-trivial basic types like Colors or DateAndTime sending > #basicNew. > > Regards .. Subbu > > Cool. Sounds like I was being over-eager then. cheers -ben

May 30, 2017