September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SUnit improvements need review and feedback

by Mariano Martinez Peck

Guille, Just for the record, there has been some crashes in Pharo using OSSubprocess, but I (we) were never able to reproduce nor found the cause, and even less a fix :( So....any help in this direction is really appreciated as I want OSSubprocess to be robust. Cheers, On Mon, Sep 5, 2016 at 2:53 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I mean crash. > > Somehow my image's processes were killed and I only had the UI process: no > delay process, no finalization, no idle process. Then, when the VM tries to > suspend the current process and change to a second one, it finds none and > it just quits. > > So it's not a VM problem I think but mostly something in the image. > > And in any case, now that I'm with a colder head (because I was mad after > losing a couple of hours of work this afternoon :)) ): > > - first, I could not load OSSubprocess in latest pharo. I saw there were > *two* test watcher processes and *killed* them. > - then, I could load OSSubprocess, but it started crashing the image when > running the tests from nautilus. > - I tested with complex and simple OSSubprocess calls and I got always > the same result > - I even removed the child watcher process to see if that was the > problem, but still crashing. > > In any case, I'm not sure that this is because of this addition, it's just > a hunch for the moment. > > > On Mon, Sep 5, 2016 at 7:47 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> ARgh, since this got integrated I keep crashing images... >>> >> >> >> do you mean real crash or DNU. >> Because indeed I got some crashes too. >> >> >> >> > -- Mariano http://marianopeck.wordpress.com

Sept. 5, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Guillermo Polito

I mean crash. Somehow my image's processes were killed and I only had the UI process: no delay process, no finalization, no idle process. Then, when the VM tries to suspend the current process and change to a second one, it finds none and it just quits. So it's not a VM problem I think but mostly something in the image. And in any case, now that I'm with a colder head (because I was mad after losing a couple of hours of work this afternoon :)) ): - first, I could not load OSSubprocess in latest pharo. I saw there were *two* test watcher processes and *killed* them. - then, I could load OSSubprocess, but it started crashing the image when running the tests from nautilus. - I tested with complex and simple OSSubprocess calls and I got always the same result - I even removed the child watcher process to see if that was the problem, but still crashing. In any case, I'm not sure that this is because of this addition, it's just a hunch for the moment. On Mon, Sep 5, 2016 at 7:47 PM, stepharo <stepharo(a)free.fr> wrote: > > ARgh, since this got integrated I keep crashing images... >> > > > do you mean real crash or DNU. > Because indeed I got some crashes too. > > > >

Sept. 5, 2016

Re: [Pharo-dev] Cycles lost on startup

by Nicolai Hess

2016-09-05 18:37 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi All, > > we are simulating a full block Pharo image derived from Pharo 6. On > startup we see a very sad loss of cycles due to a very slow rebuild of the > selector table in Symbol class. Why is this done at each startup? Here is > the stack: > > 16r107154 M ByteString class(ProtoObject)>identityHash 16r786AE8: a(n) > ByteString class > 16r10716C M ByteString class(Object)>hash 16r786AE8: a(n) ByteString > class > 16r10718C M ByteSymbol(String)>hash 16rE6A5C8: a(n) ByteSymbol > 16r1071B0 M WeakSet>scanForEmptySlotFor: 16r26B968: a(n) WeakSet > 16r1071DC M WeakSet>noCheckNoGrowFillFrom: 16r26B968: a(n) WeakSet > 16r1071FC M WeakSet>growTo: 16r26B968: a(n) WeakSet > 16r10721C M WeakSet>grow 16r26B968: a(n) WeakSet > 16r107234 M WeakSet(HashedCollection)>fullCheck 16r26B968: a(n) WeakSet > 16r10724C M WeakSet(HashedCollection)>atNewIndex:put: 16r26B968: a(n) > WeakSet > 16r107274 M WeakSet>add: 16r26B968: a(n) WeakSet > 16r107294 M [] in Symbol class>(nil) 16r1D319A8: a(n) Symbol class > 16r1072B8 M Array(SequenceableCollection)>do: 16r3C17370: a(n) Array > 16r1072E8 I CompiledMethod class(Behavior)>allInstancesDo: 16r164E260: > a(n) CompiledMethod class > 16r10730C I Symbol class>initSelectorTable 16r1D319A8: a(n) Symbol class > 16r10732C I Symbol class>selectorTable 16r1D319A8: a(n) Symbol class > 16r107350 I Symbol class>internSelector: 16r1D319A8: a(n) Symbol class > 16r10737C I CompiledMethod>selector: 16r26AB58: a(n) CompiledMethod > 16r1073A4 I IRMethod>generate: 16r25A030: a(n) IRMethod > 16r1073CC I FFICalloutMethodBuilder>generateMethodFromSpec: 16r255580: > a(n) FFICalloutMethodBuilder > 16r1073F0 I FFICalloutMethodBuilder>generate 16r255580: a(n) > FFICalloutMethodBuilder > 16r1030C8 I FFICalloutMethodBuilder>build: 16r255580: a(n) > FFICalloutMethodBuilder > 16r1030F4 I FFICalloutAPI>function:module: 16r255568: a(n) FFICalloutAPI > 16r10311C I UnixEnvironment(Object)>ffiCall:module: 16r3816180: a(n) > UnixEnvironment > 16r103144 I UnixEnvironment(OSEnvironment)>getEnv: 16r3816180: a(n) > UnixEnvironment > 16r103168 I UnixEnvironment(OSEnvironment)>at:ifAbsent: 16r3816180: > a(n) UnixEnvironment > 16r10318C M [] in MacOSResolver>(nil) 16r241170: a(n) MacOSResolver > 16r1031A4 M FullBlockClosure(BlockClosure)>on:do: 16r2553F0: a(n) > FullBlockClosure > 16r1031D0 I MacOSResolver(PlatformResolver)> > directoryFromEnvVariableNamed:or: 16r241170: a(n) MacOSResolver > 16r1031F8 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed: > 16r241170: a(n) MacOSResolver > 16r10321C I MacOSResolver>home 16r241170: a(n) MacOSResolver > 16r10323C I MacOSResolver>userLibrary 16r241170: a(n) MacOSResolver > 16r103254 M MacOSResolver>userApplicationSupport 16r241170: a(n) > MacOSResolver > 16r10326C M MacOSResolver(FileSystemResolver)>resolve: 16r241170: a(n) > MacOSResolver > 16r103288 M SystemResolver(FileSystemResolver)>unknownOrigin: > 16r240D30: a(n) SystemResolver > 16r1032A4 M SystemResolver(FileSystemResolver)>resolve: 16r240D30: a(n) > SystemResolver > 16r1032C4 M InteractiveResolver>unknownOrigin: 16r240CF0: a(n) > InteractiveResolver > 16r1032E4 M [] in InteractiveResolver>(nil) 16r240CF0: a(n) > InteractiveResolver > 16r103300 M IdentityDictionary(Dictionary)>at:ifAbsent: 16r240D00: a(n) > IdentityDictionary > 16r103320 M InteractiveResolver>resolve: 16r240CF0: a(n) > InteractiveResolver > 16r10333C M FileLocator>resolve 16r255258: a(n) FileLocator > 16r103354 M FileLocator(AbstractFileReference)>exists 16r255258: a(n) > FileLocator > 16r10337C M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener > 16r103398 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener > 16r1033B0 M FullBlockClosure(BlockClosure)>on:do: 16r255190: a(n) > FullBlockClosure > 16r1033D0 M FullBlockClosure(BlockClosure)>ifError: 16r255190: a(n) > FullBlockClosure > 16r1033EC M PharoFilesOpener>ignoreIfFail: 16rE79FD8: a(n) > PharoFilesOpener > 16r102188 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener > 16r1021AC M Array(SequenceableCollection)>do: 16r2495E8: a(n) Array > 16r1021DC I PharoFilesOpener>openSources:forImage: 16rE79FD8: a(n) > PharoFilesOpener > 16r102204 I PharoFilesOpener>openSources 16rE79FD8: a(n) PharoFilesOpener > 16r102228 I PharoFilesOpener>sourcesFileOrNil 16rE79FD8: a(n) > PharoFilesOpener > 16r10224C I SourceFileArray>ensureOpen 16r8AA128: a(n) SourceFileArray > 16r10226C I SmalltalkImage>openSourceFiles 16rA58A28: a(n) SmalltalkImage > 16r10228C I SmalltalkImage class>startUp: 16rFDA6A8: a(n) SmalltalkImage > class > 16r1022A8 M ClassSessionHandler>startup: 16r8B8978: a(n) > ClassSessionHandler > 16r1022C8 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession > 16r1022EC M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession > 16r102304 M FullBlockClosure(BlockClosure)>on:do: 16r245640: a(n) > FullBlockClosure > 16r102328 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession > 16r10234C M Array(SequenceableCollection)>do: 16r1A47B8: a(n) Array > 16r102370 I WorkingSession>runList:do: 16r1A45D0: a(n) WorkingSession > 16r102398 I WorkingSession>runStartup: 16r1A45D0: a(n) WorkingSession > 16r1023BC I WorkingSession>start: 16r1A45D0: a(n) WorkingSession > 16r1023E8 I SessionManager>snapshot:andQuit: 16r17AA950: a(n) > SessionManager > > You'll see that Symbol class>selectorTable calls Symbol class> > initSelectorTable which then calls CompiledMethod class(Behavior)>allInstancesDo: > to enumerate over all methods. This takes a significant amount of time, > even on a fast machine. For example, on a 2.%GHz machine this takes about > 70 milliseconds. That's a /lot/ of time to squander on startup. And it > will grow the larger the image is. > Hm, I didn't thought about that. > > The selector table seems to be discarded on shut-down, which seems > pointless. If one wants to recompute the table then before or after > methods are added or removed seems like a better choice, not on every image > startup. > I think I wanted to be on the save side and just discard on shutdown and rebuild on startup to be sure to have the correct set of selector symbols. > > In around 2000 we were able to startup VisualWorks images in about 40 > milliseconds on the hardware available at the time. I hope someone > reconsiders this code and a avoids recomputing the selector table on each > startup. > I will take a look and try to find a better way. nicolai > _,,,^..^,,,_ > best, Eliot >

Sept. 5, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

> ARgh, since this got integrated I keep crashing images... do you mean real crash or DNU. Because indeed I got some crashes too.

Sept. 5, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

argh!!!!!! May be we should revert the change. And make the changes optional. > ARgh, since this got integrated I keep crashing images... > > I'm just executing some OSSubprocess like this: > > process := OSSUnixSubprocess new > command: 'ls'; > redirectStdout; > runAndWaitOnExitDo: [ :command :outString | ^ outString ]. > > and my image crashes with a: > > (scheduler could not find a runnable process) > > So this is messing up badly the scheduler. We have to fix this :/ > > > On Sun, Sep 4, 2016 at 9:58 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > And it is worth breaking all the book chapters and videos. > I think that assert: closeTo: kind of solution is > - simple > - regular with the other assert: > - incremental > > So maximum quality. > > Stef > >

Sept. 5, 2016

Re: [Pharo-dev] Can Sound depend on Jobs?

by Sean P. DeNigris

Sean P. DeNigris wrote > it seems a third package (with only one method in it!) is in order. Any ideas on where to commit the JobsSound package? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Can-Sound-depend-on-Jobs-tp4914083p4914210.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 5, 2016

Re: [Pharo-dev] strange FFI behaviour? (or lack of understanding?)

by Ben Coman

On Mon, Sep 5, 2016 at 9:08 PM, Ben Coman <btc(a)openinworld.com> wrote: > Is it a **requirement** that FFI calls have a method all to themselves > like a primitive call? > > I have this definition... > > FFIExternalStructure subclass: #CXString > > CXString class>>fieldsDesc > ^ #( > void *data; > uint private_flags; > ) > > > The instance returned by this... > Xxxx>>getClangVersion > ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang > > has private_flags=1 indicating the library allocated external memory > for *data and to release this I need to call clang_disposeString( > CXString string). However this doesn't guard against being called > twice and double-free()'ing CXString crashing the VM, so I defined the > following... > > CXString>>dispose > self inform: 'debug_dispose1'. > self private_flags = 1 > ifTrue: > [ self inform: 'debug_dispose2'. > self private_flags: 0. > self ffiCall: #( void clang_disposeString ( CXString > self ) ) module: Libclang > ] > ifFalse: > [ self inform: 'debug_dispose3'. > Error signal: 'Cannot dispose twice' ]. > > However something strange, dispose will only execute once. For example for... > > s := Libclang getClangVersion. > s dispose. "==>debug_dispose1, debug_dispose2" > s dispose. "==>nothing at all" > > I would expect the second call to dispose > to result it "==>debug_dispose1, debug_dispose3" > but it does nothing at all. Debugging into "S dispose" displays the > source of dispose and then returns without executing anything. The > image seems fine and displays the updated zero in private_flags -- at > least for a few minutes, then it might crash indicating the > clang_disposeString() has been called twice. > > However it works if I separate out the FFI call to a separate method... > > CXString>>unsafeDispose > self ffiCall: #( void clang_disposeString ( CXString self ) ) > module: Libclang > > CXString>>dispose > self inform: 'dispose1'. > self private_flags = 1 > ifTrue: > [ self inform: 'dispose2'. > self private_flags: 0. > self unsafeDispose. > ] > ifFalse: > [ self inform: 'dispose3'. > Error signal: 'Cannot dispose twice' ]. > > s := Libclang getClangVersion. > s dispose. "==>debug_dispose1, debug_dispose2" > s dispose. "==>debug_dispose1, debug_dispose3" > s dispose. "==>debug_dispose1, debug_dispose3" > s dispose. "==>debug_dispose1, debug_dispose3" > > > Can someone hazard a guess what is behind this behaviour? I would > prefer not to require the unguarded #unsafeDispose. > > cheers -ben I'm also trying to understand the FFI memory footprint. A freshly started image uses this memory (kb)... VIRT RES SHR 118132 108644 5920 Creation and GC of the FFIExternalStructure is no problem... all := OrderedCollection new. 10 000 000 timesRepeat: [ all add: CXString new. ]. all := nil. Smalltalk garbageCollect. VIRT RES SHR 122,268 115,244 5,788 And performing the FFI calls is not too bad (particularly that repeating this doesn't grow memory further)... 10 000 000 timesRepeat: [ Libclang getClangVersion unsafeDispose ]. Smalltalk garbageCollect. VIRT RES SHR 170,404 123,252 12,084 But combining those two... all := OrderedCollection new. 1000000 timesRepeat: [ all add: Libclang getClangVersion ]. all do: [ :s | s unsafeDispose. ]. all := nil. Smalltalk garbageCollect. CXString allInstances size "==> 0". increases memory considerably... VIRT RES SHR 1,029,836 982,336 11,740 But again, repeating that a dozen times doesn't grow memory further. Save/quiting the image and reopening it returns to original memory usage... VIRT RES SHR 118,132 108,620 5,896 . So I'm curious what might be holding onto the memory. cheers -ben P.S. a bit more background info on the library... extern "C" { CXString clang_getClangVersion() { return cxstring::createDup(getClangFullVersion()); } } // https://github.com/llvm-mirror/clang/blob/google/stable/tools/libclang/CInd… CXString createDup(const char *String) { if (!String) return createNull(); if (String[0] == '\0') return createEmpty(); CXString Str; Str.data = strdup(String); Str.private_flags = CXS_Malloc; return Str; } void clang_disposeString(CXString string) { switch ((CXStringFlag) string.private_flags) { case CXS_Unmanaged: break; case CXS_Malloc: if (string.data) free(const_cast<void *>(string.data)); break; case CXS_StringBuf: static_cast<cxstring::CXStringBuf *>( const_cast<void *>(string.data))->dispose(); break; } }

Sept. 5, 2016

Cycles lost on startup

by Eliot Miranda

Hi All, we are simulating a full block Pharo image derived from Pharo 6. On startup we see a very sad loss of cycles due to a very slow rebuild of the selector table in Symbol class. Why is this done at each startup? Here is the stack: 16r107154 M ByteString class(ProtoObject)>identityHash 16r786AE8: a(n) ByteString class 16r10716C M ByteString class(Object)>hash 16r786AE8: a(n) ByteString class 16r10718C M ByteSymbol(String)>hash 16rE6A5C8: a(n) ByteSymbol 16r1071B0 M WeakSet>scanForEmptySlotFor: 16r26B968: a(n) WeakSet 16r1071DC M WeakSet>noCheckNoGrowFillFrom: 16r26B968: a(n) WeakSet 16r1071FC M WeakSet>growTo: 16r26B968: a(n) WeakSet 16r10721C M WeakSet>grow 16r26B968: a(n) WeakSet 16r107234 M WeakSet(HashedCollection)>fullCheck 16r26B968: a(n) WeakSet 16r10724C M WeakSet(HashedCollection)>atNewIndex:put: 16r26B968: a(n) WeakSet 16r107274 M WeakSet>add: 16r26B968: a(n) WeakSet 16r107294 M [] in Symbol class>(nil) 16r1D319A8: a(n) Symbol class 16r1072B8 M Array(SequenceableCollection)>do: 16r3C17370: a(n) Array 16r1072E8 I CompiledMethod class(Behavior)>allInstancesDo: 16r164E260: a(n) CompiledMethod class 16r10730C I Symbol class>initSelectorTable 16r1D319A8: a(n) Symbol class 16r10732C I Symbol class>selectorTable 16r1D319A8: a(n) Symbol class 16r107350 I Symbol class>internSelector: 16r1D319A8: a(n) Symbol class 16r10737C I CompiledMethod>selector: 16r26AB58: a(n) CompiledMethod 16r1073A4 I IRMethod>generate: 16r25A030: a(n) IRMethod 16r1073CC I FFICalloutMethodBuilder>generateMethodFromSpec: 16r255580: a(n) FFICalloutMethodBuilder 16r1073F0 I FFICalloutMethodBuilder>generate 16r255580: a(n) FFICalloutMethodBuilder 16r1030C8 I FFICalloutMethodBuilder>build: 16r255580: a(n) FFICalloutMethodBuilder 16r1030F4 I FFICalloutAPI>function:module: 16r255568: a(n) FFICalloutAPI 16r10311C I UnixEnvironment(Object)>ffiCall:module: 16r3816180: a(n) UnixEnvironment 16r103144 I UnixEnvironment(OSEnvironment)>getEnv: 16r3816180: a(n) UnixEnvironment 16r103168 I UnixEnvironment(OSEnvironment)>at:ifAbsent: 16r3816180: a(n) UnixEnvironment 16r10318C M [] in MacOSResolver>(nil) 16r241170: a(n) MacOSResolver 16r1031A4 M FullBlockClosure(BlockClosure)>on:do: 16r2553F0: a(n) FullBlockClosure 16r1031D0 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 16r241170: a(n) MacOSResolver 16r1031F8 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed: 16r241170: a(n) MacOSResolver 16r10321C I MacOSResolver>home 16r241170: a(n) MacOSResolver 16r10323C I MacOSResolver>userLibrary 16r241170: a(n) MacOSResolver 16r103254 M MacOSResolver>userApplicationSupport 16r241170: a(n) MacOSResolver 16r10326C M MacOSResolver(FileSystemResolver)>resolve: 16r241170: a(n) MacOSResolver 16r103288 M SystemResolver(FileSystemResolver)>unknownOrigin: 16r240D30: a(n) SystemResolver 16r1032A4 M SystemResolver(FileSystemResolver)>resolve: 16r240D30: a(n) SystemResolver 16r1032C4 M InteractiveResolver>unknownOrigin: 16r240CF0: a(n) InteractiveResolver 16r1032E4 M [] in InteractiveResolver>(nil) 16r240CF0: a(n) InteractiveResolver 16r103300 M IdentityDictionary(Dictionary)>at:ifAbsent: 16r240D00: a(n) IdentityDictionary 16r103320 M InteractiveResolver>resolve: 16r240CF0: a(n) InteractiveResolver 16r10333C M FileLocator>resolve 16r255258: a(n) FileLocator 16r103354 M FileLocator(AbstractFileReference)>exists 16r255258: a(n) FileLocator 16r10337C M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener 16r103398 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener 16r1033B0 M FullBlockClosure(BlockClosure)>on:do: 16r255190: a(n) FullBlockClosure 16r1033D0 M FullBlockClosure(BlockClosure)>ifError: 16r255190: a(n) FullBlockClosure 16r1033EC M PharoFilesOpener>ignoreIfFail: 16rE79FD8: a(n) PharoFilesOpener 16r102188 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener 16r1021AC M Array(SequenceableCollection)>do: 16r2495E8: a(n) Array 16r1021DC I PharoFilesOpener>openSources:forImage: 16rE79FD8: a(n) PharoFilesOpener 16r102204 I PharoFilesOpener>openSources 16rE79FD8: a(n) PharoFilesOpener 16r102228 I PharoFilesOpener>sourcesFileOrNil 16rE79FD8: a(n) PharoFilesOpener 16r10224C I SourceFileArray>ensureOpen 16r8AA128: a(n) SourceFileArray 16r10226C I SmalltalkImage>openSourceFiles 16rA58A28: a(n) SmalltalkImage 16r10228C I SmalltalkImage class>startUp: 16rFDA6A8: a(n) SmalltalkImage class 16r1022A8 M ClassSessionHandler>startup: 16r8B8978: a(n) ClassSessionHandler 16r1022C8 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession 16r1022EC M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession 16r102304 M FullBlockClosure(BlockClosure)>on:do: 16r245640: a(n) FullBlockClosure 16r102328 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession 16r10234C M Array(SequenceableCollection)>do: 16r1A47B8: a(n) Array 16r102370 I WorkingSession>runList:do: 16r1A45D0: a(n) WorkingSession 16r102398 I WorkingSession>runStartup: 16r1A45D0: a(n) WorkingSession 16r1023BC I WorkingSession>start: 16r1A45D0: a(n) WorkingSession 16r1023E8 I SessionManager>snapshot:andQuit: 16r17AA950: a(n) SessionManager You'll see that Symbol class>selectorTable calls Symbol class> initSelectorTable which then calls CompiledMethod class(Behavior)>allInstancesDo: to enumerate over all methods. This takes a significant amount of time, even on a fast machine. For example, on a 2.%GHz machine this takes about 70 milliseconds. That's a /lot/ of time to squander on startup. And it will grow the larger the image is. The selector table seems to be discarded on shut-down, which seems pointless. If one wants to recompute the table then before or after methods are added or removed seems like a better choice, not on every image startup. In around 2000 we were able to startup VisualWorks images in about 40 milliseconds on the hardware available at the time. I hope someone reconsiders this code and a avoids recomputing the selector table on each startup. _,,,^..^,,,_ best, Eliot

Sept. 5, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Guillermo Polito

ARgh, since this got integrated I keep crashing images... I'm just executing some OSSubprocess like this: process := OSSUnixSubprocess new command: 'ls'; redirectStdout; runAndWaitOnExitDo: [ :command :outString | ^ outString ]. and my image crashes with a: (scheduler could not find a runnable process) So this is messing up badly the scheduler. We have to fix this :/ On Sun, Sep 4, 2016 at 9:58 AM, stepharo <stepharo(a)free.fr> wrote: > And it is worth breaking all the book chapters and videos. > I think that assert: closeTo: kind of solution is > - simple > - regular with the other assert: > - incremental > > So maximum quality. > > Stef > >

Sept. 5, 2016

Re: [Pharo-dev] [Ann] New Seamless version 0.9.0

by Denis Kudriashov

Hi Sean. 2016-09-05 16:39 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Awesome! Is this "the" Pharo library for sharing live objects between > images? IIUC it's a successor to rST, correct? > Yes, it is new implementation of remote smalltalk. Look at my blog for details and docs http://dionisiydk.blogspot.fr/2016/07/major-seamless-update.html > Are there other remote > communication libraries, and if so how does Seamless compare? > I guess you skipped my previous announcement. Just look at my blog. In short old rST was not flexible enough to solve particular problems. And Nikolaos Papoulias started Seamless to address these issues with better design ideas. I move it forward and now Seamless drives RemoteDebugger project where regular debugger works with remote stack. And in future we will got remote browser too.

Sept. 5, 2016