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

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

DebugSession: no exception raised when stepping out of the execution?

by tdupriez＠ens-paris-saclay.fr

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? Thomas

May 29, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Christophe Demarey

Hi Doru, > Le 28 mai 2017 Ã 10:40, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > > Hi, > > I just had the issue again while typing code. > > I actually cannot work. Is it really only me, or is it that others just got used to living with this and not report the issue? I have exactly the same problem. It happens at least once a day for me. It is very annoying. It always happens when typing, and I would I say when I press many keys within a very small delay. Here is a crash dump I experienced (OS X 10.11.4): Segmentation fault Fri May 19 11:28:42 2017 VM: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 08:52:41 2017 -0700 $ Plugins: 201705021552 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ C stack backtrace & registers: eax 0x7a653640 ebx 0x7c27b010 ecx 0x97f8ab12 edx 0xe0000000 edi 0x97f6e93f esi 0x97f6e93f ebp 0xbff35558 esp 0xbff35318 eip 0x97f6ecaf 0 libobjc.A.dylib 0x97f6ecaf objc_msgSend + 31 1 Pharo 0x00118233 reportStackState + 819 2 Pharo 0x00118597 sigsegv + 129 3 libsystem_platform.dylib 0x9346d79b _sigtramp + 43 4 ??? 0xffffffff 0x0 + 4294967295 5 CoreFoundation 0x9a1e969f _CFAutoreleasePoolPop + 47 6 HIToolbox 0x94cdb2c1 IMKInputSessionProcessEventRefWithCompletionHandler + 142 7 HIToolbox 0x94cda4ac InputMethodInstanceProcessEventRef_WithCompletionHandler + 115 8 HIToolbox 0x94cc37f9 __TSMEventToInputMethod_WithCompletionHandler_block_invoke + 122 9 HIToolbox 0x94cc89be __TrySendLockEvent_BeforeEventToInputMethod_WithContinuationHandler_block_invoke + 33 10 HIToolbox 0x94cc8a87 __SendTSMDocumentLockEvent_WithCompletionHandler_block_invoke + 120 11 HIToolbox 0x94a7512f __SendTSMEvent_WithCompletionHandler_block_invoke + 73 12 HIToolbox 0x94a7841d __SendEventToEventTargetWithCompletionHandler_block_invoke + 25 13 HIToolbox 0x94a783fd ___ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec_block_invoke + 127 14 AppKit 0x98539bb2 ___NSTSMEventHandler_block_invoke + 25 15 AppKit 0x98532e83 -[NSTextInputContext handleTSMEvent:completionHandler:] + 1253 16 AppKit 0x98532942 _NSTSMEventHandler + 302 17 HIToolbox 0x94a7c2ff _Z22_InvokeEventHandlerUPPP25OpaqueEventHandlerCallRefP14OpaqueEventRefPvPFlS0_S2_S3_E + 36 18 HIToolbox 0x94a247b0 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1832 19 HIToolbox 0x94a239c4 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 402 20 HIToolbox 0x94a2382a SendEventToEventTargetWithOptions + 40 21 HIToolbox 0x94a74d9a SendTSMEvent_WithCompletionHandler + 435 22 HIToolbox 0x94cc3736 TrySendLockEvent_BeforeEventToInputMethod_WithContinuationHandler + 409 23 HIToolbox 0x94cc351b TSMEventToInputMethod_WithCompletionHandler + 152 24 HIToolbox 0x94a72d96 TSMProcessRawKeyEventWithOptionsAndCompletionHandler + 4060 25 AppKit 0x98d1bb7b __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke999 + 147 26 AppKit 0x98531778 -[NSTextInputContext tryTSMProcessRawKeyEvent:dispatchCondition:setupForDispatch:furtherCondition:dispatchWork:continuation:] + 129 27 AppKit 0x985313d3 -[NSTextInputContext _handleEvent:options:completionHandler:] + 1715 28 AppKit 0x98530cff -[NSTextInputContext handleEvent:] + 128 29 AppKit 0x98530bfe -[NSView interpretKeyEvents:] + 205 30 Pharo 0x0011455e -[sqSqueakOSXOpenGLView keyDown:] + 310 31 AppKit 0x9853015e -[NSWindow _handleKeyDownEvent:] + 569 32 AppKit 0x98c05c22 -[NSWindow _reallySendEvent:isDelayedEvent:] + 2303 33 AppKit 0x9859c96f -[NSWindow sendEvent:] + 567 34 AppKit 0x98517cdd -[NSApplication sendEvent:] + 2919 35 Pharo 0x0010cdcb -[SqueakOSXApplication sendEvent:] + 163 36 Pharo 0x0010e9a4 -[sqSqueakOSXApplication(events) pumpRunLoopEventSendAndSignal:] + 115 37 Pharo 0x0010ea42 -[sqSqueakOSXApplication(events) pumpRunLoop] + 76 38 Pharo 0x0011688a nativeIoProcessEvents + 208 39 Pharo 0x001168de ioProcessEvents + 35 40 Pharo 0x000aa470 checkForEventsMayContextSwitch + 880 41 Pharo 0x000abcea ceCheckForInterrupts + 16 42 ??? 0x0483e09b 0x0 + 75751579 43 Pharo 0x000981bc interpret + 647 44 Pharo 0x001196ad -[sqSqueakMainApplication runSqueak] + 476 45 Foundation 0x931b65b9 __NSFirePerformWithOrder + 416 46 CoreFoundation 0x9a24e90e __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 47 CoreFoundation 0x9a24e86e __CFRunLoopDoObservers + 398 48 CoreFoundation 0x9a22bf92 __CFRunLoopRun + 946 49 CoreFoundation 0x9a22b976 CFRunLoopRunSpecific + 390 50 CoreFoundation 0x9a22b7db CFRunLoopRunInMode + 123 51 HIToolbox 0x94a482f1 RunCurrentEventLoopInMode + 267 52 HIToolbox 0x94a47fc5 ReceiveNextEventCommon + 201 53 HIToolbox 0x94a47eec _BlockUntilNextEventMatchingListInModeWithFilter + 99 54 AppKit 0x9837844e _DPSNextEvent + 1053 55 AppKit 0x983779c7 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1057 56 AppKit 0x9837759e -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 121 57 AppKit 0x9836acb3 -[NSApplication run] + 1063 58 AppKit 0x983315a9 NSApplicationMain + 1630 59 libdyld.dylib 0x954466ad start + 1 Smalltalk stack dump: 0xbff3b910 M ProcessorScheduler class>idleProcess 0x5058868: a(n) ProcessorScheduler class 0xbff3b930 I [] in ProcessorScheduler class>startUp 0x5058868: a(n) ProcessorScheduler class 0xbff3b950 I [] in BlockClosure>newProcess 0x81e08c0: a(n) BlockClosure Most recent primitives < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock >= signal >= signal + primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue millisecondClockValue signal primUTCMicrosecondsClock + >= + < primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue yield wait millisecondClockValue signal primUTCMicrosecondsClock + < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock >= signal >= signal + primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue millisecondClockValue signal primUTCMicrosecondsClock + >= + < primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue yield wait millisecondClockValue signal primUTCMicrosecondsClock + < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock >= signal >= signal + primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated **StackOverflow** **StackOverflow** replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue millisecondClockValue signal primUTCMicrosecondsClock + >= + < primSignal:atUTCMicroseconds: wait millisecondClockValue @ actualScreenSize millisecondClockValue replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: @ truncated replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: millisecondClockValue yield wait millisecondClockValue signal primUTCMicrosecondsClock + < >= + < primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: stack page bytes 4096 available headroom 2788 minimum unused headroom 2296

May 29, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Stephane Ducasse

I got it from time to time (but may be once a week) but I was in the Bloc image and it crashed in other ways. I'm on sierra with latest vm and image. On Sun, May 28, 2017 at 8:27 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 28/05/2017 Ã 10:50, Esteban Lorenzano a Ã©crit : > > > > > > yes, but I never had it (and I use mac and I type fairly fast too). > > > > Same, never had it and I type fast. > > > Esteban > > > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

May 28, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Cyril Ferlicot D.

Le 28/05/2017 Ã 10:50, Esteban Lorenzano a Ã©crit : > > > yes, but I never had it (and I use mac and I type fairly fast too). > Same, never had it and I type fast. > Esteban > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 28, 2017

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

by Milan Vavra

> I am actually running under a VM I built because that one is not > mysteriously crashing and as I have an assert and debug version, I hope > to find the reason why this happens. If you have mysterious crashes in a release build that stop when you switch to a debug build, the compiler optimization options could be the problem. Best Regards, Milan Vavra -- View this message in context: http://forum.world.st/Re-Vm-dev-multiple-crashes-on-macOS-Sierra-tp4948481p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2017