- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] basicNew usage pattern

by K K Subbu

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

May 30, 2017

Fwd: [Vm-dev] multiple crashes on macOS Sierra

by Eliot Miranda

---------- Forwarded message ---------- From: Tobias Pape <Das.Linux(a)gmx.de> Date: Mon, May 29, 2017 at 12:09 AM Subject: Re: [Vm-dev] multiple crashes on macOS Sierra To: John McIntosh <johnmci(a)smalltalkconsulting.com> Cc: Squeak Virtual Machine Development Discussion < vm-dev(a)lists.squeakfoundation.org> Hi John, all > On 28.05.2017, at 22:12, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added > > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) > location:[theEvent locationInWindow] > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) > timestamp:[theEvent timestamp] > windowNumber:[theEvent windowNumber] > context:nil > characters:@"" > charactersIgnoringModifiers:@"" > isARepeat:NO > keyCode:[theEvent keyCode]]); > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent That's correct. > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/ library/content/documentation/Cocoa/Conceptual/MemoryMgmt/ Articles/mmRules.html > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() I read this https://developer.apple.com/reference/appkit/nsevent/ 1533943-keyeventwithtype?language=objc and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. I now understand that I should only autorelease alloc/inited stuff. So you may be right here. Fixed in 0f07ffbed Best regards -Tobias > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. [snip]

May 29, 2017

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

by Eliot Miranda

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: >> Hi, >> >> I'm working with DebugSession to see if I can implement something that would step into an execution until a given expression evaluates to a different value than the value it had at the beginning to quickly localise the precise point where an invariant is broken. >> >> But it appears that if the expression always evaluate to the same value, then the VM freezes. >> >> I simplified my program to just stepInto a debugSession indefinitely, and it makes the VM freeze, while I would rather expect an exception to be raised (something like "ReachedEndOfExecution"). >> >> 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 ]. >> >> Is there a way to have an exception be raised when a stepInto message is sent to a debugSession whose execution is finished, instead of just freezing the VM? >> > > I like looking into these sort of things, but right now don't have time. (I'm trying to be disciplined.) > Probably a way does not currently existing, so the way is to change the implementation. > What I'd suggest is debugging into #stepInto to maybe discover how to do it yourself. :) 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. > As a novice I found it really accessible to dig into this stuff, found it quite enlightening and made me feel cool I could do it. > > To be able to debug the debugger, first copy method #stepInto to #myStepInto with a halt at the top, then try... > [ true ] whileTrue: [ debugSession myStepInto ]. > > btw, if you are executing your example from then Playground, note that it executes in the UI thread, which you've blocked from progressing. > Does the Image hang with this...? > [ [ true ] whileTrue: [ debugSession stepInto ] ] forkAt: Processor currentPriority - 1. > > Note the lowered priority since processes are only pre-emptive between priorities. > At the same priority processes are scheduled cooperatively, so require an explicit yield or the tight loop would dominate the UI process. > So you might also try this... > [ [ true ] whileTrue: [ debugSession stepInto. Processor yield. ] ] fork. > > Give it a go and report back what you find and propose how you'd like it to work. > Then we can see what it might break and wider implications I can't think of right now. > (Its a great learning experience for the experts to describe why some things are a bad idea, and maybe alternatives.) > > cheers -ben > > P.S. This might be the sort of thing that MetaLinks is good for, but I'm not much familiar with them.

May 29, 2017

Roassal @ Pharo TechTalk

by Alexandre Bergel

Hello, Tomorrow Roassal will be the topic of the month Pharo TechTalk. When: TechTalk Voice channel @ Discord, Youtube channel When: 4:00 PM (GMT+2, Paris Time), 11:00 (GMT-3, Argentina time) 10:00 AM (GMT-4, Chile time), 7:00 AM (PDT, San Francisco) Length: about 30 minutes How to join: - Youtube Channel for the video: https://www.youtube.com/watch?v=hmnDGbM5vsY - Discord for the sound: http://discord.gg/Sj2rhxn Website of Pharo TechTalk: https://association.pharo.org/event-2489995 Content of the Roassal TechTalk: 1 - General introduction of Roassal 2 - Latest news in Roassal (Theme support, Scatterplot Matrix, Elastic boxes, ...) 4 - Applications based on Roassal (Test Coverage, Memory profiling) 3 - Ongoing effort and future work The presentation of the TechTalk will be essentially demo-based. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 29, 2017

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

by Ben Coman

On Mon, May 29, 2017 at 9:34 PM, <tdupriez(a)ens-paris-saclay.fr> wrote: > Hi, > > I'm working with DebugSession to see if I can implement something that > would step into an execution until a given expression evaluates to a > different value than the value it had at the beginning to quickly localise > the precise point where an invariant is broken. > > But it appears that if the expression always evaluate to the same value, > then the VM freezes. > > I simplified my program to just stepInto a debugSession indefinitely, and > it makes the VM freeze, while I would rather expect an exception to be > raised (something like "ReachedEndOfExecution"). > > 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 ]. > > Is there a way to have an exception be raised when a stepInto message is > sent to a debugSession whose execution is finished, instead of just > freezing the VM? > > I like looking into these sort of things, but right now don't have time. (I'm trying to be disciplined.) Probably a way does not currently existing, so the way is to change the implementation. What I'd suggest is debugging into #stepInto to maybe discover how to do it yourself. :) As a novice I found it really accessible to dig into this stuff, found it quite enlightening and made me feel cool I could do it. To be able to debug the debugger, first copy method #stepInto to #myStepInto with a halt at the top, then try... [ true ] whileTrue: [ debugSession myStepInto ]. btw, if you are executing your example from then Playground, note that it executes in the UI thread, which you've blocked from progressing. Does the Image hang with this...? [ [ true ] whileTrue: [ debugSession stepInto ] ] forkAt: Processor currentPriority - 1. Note the lowered priority since processes are only pre-emptive between priorities. At the same priority processes are scheduled cooperatively, so require an explicit yield or the tight loop would dominate the UI process. So you might also try this... [ [ true ] whileTrue: [ debugSession stepInto. Processor yield. ] ] fork. Give it a go and report back what you find and propose how you'd like it to work. Then we can see what it might break and wider implications I can't think of right now. (Its a great learning experience for the experts to describe why some things are a bad idea, and maybe alternatives.) cheers -ben P.S. This might be the sort of thing that MetaLinks is good for, but I'm not much familiar with them.

May 29, 2017