- Pharo-users - lists.pharo.org

Re: [Pharo-users] loading Coral from SmalltalkHub

by stepharo

Thanks Stefan Francisco there is nothing new in Coral we got stalled again because we focused on pillar. Stef Le 4/6/15 11:20, Stephan Eggermont a Ã©crit : > On 04-06-15 01:46, Francisco Garau wrote: >> I've tried loading Coral by following the below instructions in its >> website <http://rmod.lille.inria.fr/coral/getting-started.html> but they >> failed when trying to load Readline. >> >> Gofer new url: 'http://ss3.gemstone.com/ss/coral'; >> package: 'ConfigurationOfCoral'; >> load. >> >> ConfigurationOfCoral loadDevelopment. > > Yes, that is an old configuration. I've updated it > on smalltalkhub: PharoExtras/Coral, but that was before > the release of Pharo4. CDLM, Damien C and Stef have worked > on it this year. > > As PetitParser still uses the > #stable and #development style of symbolic naming, > instead of #release5.1, things can break when a new > version of Moose is released. > >> It seems the project was moved to Smalltalk Hub >> (http://smalltalkhub.com/#!/~PharoExtras/Coral/) >> >> What expressions should I evaluate in a Pharo5 image to get the latest >> Coral project loaded. > > I've added a Pharo 5 build to > https://ci.inria.fr/pharo-contribution/job/Coral/ > The 4 and 5 builds are green > > I've also added a Pharo4 and Pharo5 build to OSProcess > https://ci.inria.fr/pharo-contribution/job/OSProcess/ > The 4 and 5 builds each have 3 failures > > It is possible that some changes to the parser are needed > due to improvements in PetitParser. I ran into that last > time I tried, and forgot whether that got fixed. > > Stephan > > > > >

June 4, 2015

Re: [Pharo-users] Proposed enhancements to get.pharo.org

by stepharo

Hi jason Thanks. > I have a simple suggestion for the ZeroConf Bash scripts. The > suggestion is to automatically discern the image that the scripts use. > E.g. > > For the pharo script: > https://gist.github.com/jacaetevha/7c4206d2cfadd54a492c#file-pharo > > For the pharo-ui script: > https://gist.github.com/jacaetevha/7c4206d2cfadd54a492c#file-pharo-ui > > I tried to bring this up in the IRC channel, but things seem pretty > quiet there. I'm not sure where to post this, so I'm just posting it here. This is the right place :) > > -- > Jason Rogers

June 4, 2015

Proposed enhancements to get.pharo.org

by Jason Rogers

I have a simple suggestion for the ZeroConf Bash scripts. The suggestion is to automatically discern the image that the scripts use. E.g. For the pharo script: https://gist.github.com/jacaetevha/7c4206d2cfadd54a492c#file-pharo For the pharo-ui script: https://gist.github.com/jacaetevha/7c4206d2cfadd54a492c#file-pharo-ui I tried to bring this up in the IRC channel, but things seem pretty quiet there. I'm not sure where to post this, so I'm just posting it here. -- Jason Rogers

June 4, 2015

Re: [Pharo-users] [Pharo-dev] Roassal Camp Smalltalk

by Peter UhnÃ¡k

Hi Alex, is it possible to add some discussion about stuff we did in roassal for dynacase to the list? Because I feel there is some duplication effort and also we could probably contribute some stuff we did back. Or perhaps even more general discussion about using roassal for more dynamic and modifiable visualizations/modeling (e.g. composite shapes, bendable lines, resizable boxes, etc.) Peter On Thu, Jun 4, 2015 at 7:55 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Dear Colleagues and Friends, > > We are happy to announce we will organize a CampSmalltalk about the > Roassal visualization engine, on _Sunday 12 July_. > > As far as we have seen, the interests are multiple. Here is a list of > topics we will happy to work on: > - Port of Roassal on VisualWorks > - Using Roassal on Gemstone > - HTML/JavaScript export > - Improving Grapher, our charting library > > If you wish to participate, get in touch with us. Since we will probably > have a sponsoring of the event, it would be nice to know how many will > attend to ease the logistic and the pizza ordering :-) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

June 4, 2015

Roassal Camp Smalltalk

by Alexandre Bergel

Dear Colleagues and Friends, We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: - Port of Roassal on VisualWorks - Using Roassal on Gemstone - HTML/JavaScript export - Improving Grapher, our charting library If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 4, 2015

Re: [Pharo-users] Visualizing a repository tree

by Peter UhnÃ¡k

Omg I just found out that if I click on the node representing an McVersionInfo it actually opens it in the inspector and I didn't even needed to implement anything special. That's really cool! Peter On Tue, Jun 2, 2015 at 6:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Interesting visualization! Keep going! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jun 2, 2015, at 10:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Interesting. The dominance tree layout is quite interesting for this use >> case. >> > > There were some upward lines at the bottom of the graph for no apparent > reason, not sure what was going on there yet, so I'll look into the layout > when I have more time. > > Alternatively you could also use Sugiyama, however either due to the > choice of heuristics, or some bug it places high priority on last levels > which is really bad (since it is no longer at proper hierarchical layers). > > Peter > > >> Doru >> >> On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> HI Offray, >>> >>> I gave it a quick bash and come up with the following code. It's just a >>> prototype and could be greatly simplified. >>> >>> - MCVersionInfo ancestors for whatever reason returned empty array down >>> the line (so its cut off at the end), but I didn't investigate the problem >>> - edge building and possibly ancestor retrieval could be simplified with >>> builders; I think RTMondrian has methods for it but can't remember exactly >>> (agilevisualization mentioned RTGraphBuilder but that has been removed to >>> my knowledge) >>> >>> ~~~~~~~~~~~~~~~ >>> mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project = >>> 'Roassal2' ]. >>> >>> root := mc versionInfoFromFileNamed: mc readableFileNames first. >>> >>> family := Set new. >>> retriever := nil. >>> retriever := [ :child | >>> family add: child. >>> child ancestors do: [ :a | retriever value: a ] >>> ]. >>> retriever value: root. >>> obs := family asGroup. >>> >>> v := RTView new. >>> es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. >>> v addAll: es. >>> >>> edges := RTEdge >>> buildEdgesFromObjects: obs >>> from: #yourself >>> toAll: #ancestors >>> using: (RTArrowedLine new withShorterDistanceAttachPoint; color: Color >>> red) >>> scope: es. >>> v addAll: edges. >>> >>> es @ RTDraggable. >>> es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). >>> >>> v @ RTDraggableView. >>> v @ RTZoomableView. >>> >>> RTDominanceTreeLayout new >>> verticalGap: 30; >>> horizontalGap: 15; >>> on: es. >>> >>> v open >>> ~~~~~~~~~~~~~~~~ >>> >>> >>> <2015-06-02_12:04:32.png> >>> >>> Cheers, >>> Peter >>> â >>> >>> On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas < >>> offray(a)riseup.net> wrote: >>> >>>> Hi, >>>> >>>> On a closer detail, seems that [1] contains the starting point I'm >>>> looking for. I'll keep you posted and of course any other approach will be >>>> listened. >>>> >>>> [1] >>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> >>>> On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: >>>> >>>>> Hi all, >>>>> >>>>> I had asked a similar question before with no much advances, but today >>>>> I made a discovery that can improve the things a lot: how to export >>>>> timeline data as structured JSON [1] (and of course this open the >>>>> possibility to work with it on Pharo). Now I would like to graph the data >>>>> as a tree with forks, merges and dates and authors of commits. I have seen >>>>> chronia, but seems overkill for this feature (and is integrated with CVS >>>>> only). >>>>> >>>>> [1] >>>>> http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… >>>>> >>>>> As usual, any pointer on how to get this going will be greatly >>>>> appreciated and I will give feedback to the community on how to do it. >>>>> >>>>> Cheers, >>>>> >>>>> Offray >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

June 4, 2015

Re: [Pharo-users] case-insensitive regexp

by Usman Bhatti

Thanks Peter. On Thu, Jun 4, 2015 at 1:51 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > I do not think this is possible. The problem is that the Regex compiles > (parses) the pattern so once it's created you would have to reparse it. > Theoretically speaking you could add ignoreCase accessors to RxMatcher but > it is likely it would break things; or add method to RxMatcher that would > return a new RxMatcher object with the proper settings. > > Also note that regular expressions in Pharo are not the extended versions, > where these things are usually available (alongside lookahead/lookbehind > and other). > And personally I find the Regex library so awkward to use that I always > opt for PetitParser. > > ~~~~ > myParser := 'hello' asParser. > myParser matches: 'Hello'. "false" > myParser caseInsensitive matches: 'Hello'. "true" > ~~~~ > > on the other hand there is no option to turn it back again. So if you > regularly need to switch it back and forth it wouldn't be solution either. > > Peter >

June 4, 2015

Re: [Pharo-users] [ann] moose 5.1

by Alexandre Bergel

Impressive!!!!!!! Wonderful team! Alexande -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 4, 2015, at 4:17 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > We are happy to announce version 5.1 of the Moose Suite: > *http://moosetechnology.org/#install* <http://moosetechnology.org/#install*> > > <moose-5-1.png> > > Description > --- > This is a minor release. The key highlights are: > - It is based on Pharo 4.0. > - Roassal2 comes with several new builder, most notably the new Mondrian builder (RTMondrian) and the chart drawing engine (RTGrapher). > - GTSpotter has preview abilities and was extended for multiple search use cases including the navigation through Moose models. > - GTPlayground was extended with sharing possibilities and transparent backup. > - GTExample now offers support for documenting classes with example instances. > - Moose Finder and GTInspector come with more custom presentations. > - PetitParser has seen performance corrections and has been extended with the ability to parse whitespace languages. > > > Installation > --- > The Moose Suite 5.1 comes for each platform as a separate bundle: > - Moose Suite 5.1 for Mac > http://moosetechnology.org/res/download/moose_suite_5_1-mac.zip <http://moosetechnology.org/res/download/moose_suite_5_1-mac.zip> > - Moose Suite 5.1 for Windows > http://moosetechnology.org/res/download/moose_suite_5_1-win.zip <http://moosetechnology.org/res/download/moose_suite_5_1-win.zip> > - Moose Suite 5.1 for Linux > http://moosetechnology.org/res/download/moose_suite_5_1-linux.zip <http://moosetechnology.org/res/download/moose_suite_5_1-linux.zip> > > The Moose Suite 5.1 can also be loaded in a Pharo 4.0 image either from the Configuration Browser, or by executing the following script: > > Gofer new > smalltalkhubUser: 'Moose' project: 'Moose'; > configuration; > loadStable > > > Enjoy, > The Moose team >

June 4, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by David T. Lewis

On Wed, Jun 03, 2015 at 05:03:18PM +0200, Jose San Leandro wrote: > Unfortunately it doesn't fix it, or at least I get the same sympthoms. Thanks for trying it. Sorry it did not help :-/ Dave > > Sending SIGUSR1 prints this: > > SIGUSR1 Wed Jun 3 16:53:50 2015 > > > /home/chous/toolbox/pharo-4.0/pharo-vm/pharo > pharo VM version: 3.9-7 #1 Thu Apr 2 00:51:45 CEST 2015 gcc 4.6.3 > [Production ITHB VM] > Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > Revision: https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 > 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > plugin path: /home/chous/toolbox/pharo-4.0/pharo-vm/ [default: > /home/chous/toolbox/pharo-4.0/pharo-vm/] > > > C stack backtrace & registers: > eax 0xff981e94 ebx 0xff981db0 ecx 0xff981e48 edx 0xff981dfc > edi 0xff981c80 esi 0xff981c80 ebp 0xff981d18 esp 0xff981d64 > eip 0xff981f78 > *[0xff981f78] > /home/chous/toolbox/pharo/pharo-vm/pharo[0x80a33a2] > /home/chous/toolbox/pharo/pharo-vm/pharo[0x80a3649] > linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf773acc0] > /home/chous/toolbox/pharo/pharo-vm/pharo(signalSemaphoreWithIndex+0x28)[0x809d8c8] > /home/chous/toolbox/pharo/pharo-vm/pharo[0x810868c] > linux-gate.so.1(__kernel_sigreturn+0x0)[0xf773acb0] > /home/chous/toolbox/pharo/pharo-vm/pharo(signalSemaphoreWithIndex+0x5e)[0x809d8fe] > /home/chous/toolbox/pharo/pharo-vm/pharo(aioPoll+0x22f)[0x809f0af] > /home/chous/toolbox/pharo-4.0/pharo-vm/vm-display-X11(+0xe671)[0xf772a671] > /home/chous/toolbox/pharo/pharo-vm/pharo(ioRelinquishProcessorForMicroseconds+0x17)[0x80a1887] > /home/chous/toolbox/pharo/pharo-vm/pharo[0x80767fa] > [0xb4a2fe0c] > [0xb4a2d700] > [0xb53b9382] > [0xb4a2d648] > [0x5b] > > > All Smalltalk process stacks (active first): > Process 0xb6d930c4 priority 10 > 0xff9ad450 M ProcessorScheduler class>idleProcess 0xb4d935c0: a(n) > ProcessorScheduler class > 0xff9ad470 I [] in ProcessorScheduler class>startUp 0xb4d935c0: a(n) > ProcessorScheduler class > 0xff9ad490 I [] in BlockClosure>newProcess 0xb6d92fe8: a(n) BlockClosure > > suspended processes > Process 0xb68e1984 priority 50 > 0xff9a6490 M WeakArray class>finalizationProcess 0xb4d93790: a(n) WeakArray > class > 0xb69beb68 s [] in WeakArray class>restartFinalizationProcess > 0xb68e1924 s [] in BlockClosure>newProcess > > Process 0xb5ced038 priority 80 > 0xff9af490 M DelayMicrosecondScheduler>runTimerEventLoop 0xb5bb6f9c: a(n) > DelayMicrosecondScheduler > 0xb6098314 s [] in DelayMicrosecondScheduler>startTimerEventLoop > 0xb5cecfd8 s [] in BlockClosure>newProcess > > Process 0xb68ec880 priority 40 > 0xff9b2478 M [] in UnixOSProcessAccessor>(nil) 0xb60dc6d0: a(n) > UnixOSProcessAccessor > 0xff9b2490 M BlockClosure>repeat 0xb68ef2d4: a(n) BlockClosure > 0xb68ef278 s [] in UnixOSProcessAccessor>(nil) > 0xb68ec820 s [] in BlockClosure>newProcess > > Process 0xb6d92d78 priority 60 > 0xff98742c M InputEventFetcher>waitForInput 0xb5a09718: a(n) > InputEventFetcher > 0xff987450 M InputEventFetcher>eventLoop 0xb5a09718: a(n) InputEventFetcher > 0xff987470 I [] in InputEventFetcher>installEventLoop 0xb5a09718: a(n) > InputEventFetcher > 0xff987490 I [] in BlockClosure>newProcess 0xb6d92c9c: a(n) BlockClosure > > Process 0xb6f25f94 priority 60 > 0xb6f25fcc s SmalltalkImage>lowSpaceWatcher > 0xb71523e4 s [] in SmalltalkImage>installLowSpaceWatcher > 0xb6f25f34 s [] in BlockClosure>newProcess > > Process 0xb73a4e7c priority 30 > 0xff99b470 M [] in AioEventHandler>handleExceptions:readEvents:writeEvents: > 0xb73a49e4: a(n) AioEventHandler > 0xff99b490 I [] in BlockClosure>newProcess 0xb73a4d90: a(n) BlockClosure > Process 0xb6686c88 priority 40 > 0xffa073d0 M [] in Delay>wait 0xb73a63fc: a(n) Delay > 0xffa073f0 M BlockClosure>ifCurtailed: 0xb73a6614: a(n) BlockClosure > 0xffa0740c M Delay>wait 0xb73a63fc: a(n) Delay > 0xffa07428 M PipeableOSProcess(PipeJunction)>outputOn: 0xb73a0d34: a(n) > PipeableOSProcess > 0xffa07444 M PipeableOSProcess(PipeJunction)>output 0xb73a0d34: a(n) > PipeableOSProcess > 0xffa0746c M [] in MCFileTreeGitRepository class>runOSProcessGitCommand:in: > 0xb611fa88: a(n) MCFileTreeGitRepository class > 0xffa0748c M BlockClosure>ensure: 0xb739d9dc: a(n) BlockClosure > 0xff9e538c M MCFileTreeGitRepository class>runOSProcessGitCommand:in: > 0xb611fa88: a(n) MCFileTreeGitRepository class > 0xff9e53ac M MCFileTreeGitRepository class>runGitCommand:in: 0xb611fa88: > a(n) MCFileTreeGitRepository class > 0xff9e53cc M MCFileTreeGitRepository>gitCommand:in: 0xb612926c: a(n) > MCFileTreeGitRepository > 0xff9e53f4 M MCFileTreeGitRepository>gitVersionsForPackage: 0xb612926c: > a(n) MCFileTreeGitRepository > 0xff9e543c M [] in MCFileTreeGitRepository>loadAllFileNames 0xb612926c: > a(n) MCFileTreeGitRepository > 0xff9e5458 M FileSystemDirectoryEntry(Object)>in: 0xb71b3fe8: a(n) > FileSystemDirectoryEntry > 0xff9e548c M [] in MCFileTreeGitRepository>loadAllFileNames 0xb612926c: > a(n) MCFileTreeGitRepository > 0xffa04310 M BlockClosure>cull: 0xb71b4894: a(n) BlockClosure > 0xffa04338 I [] in Job>run 0xb71b48b4: a(n) Job > 0xffa04350 M BlockClosure>on:do: 0xb71b56b8: a(n) BlockClosure > 0xffa0437c I [] in Job>run 0xb71b48b4: a(n) Job > 0xffa0439c M BlockClosure>ensure: 0xb71b4980: a(n) BlockClosure > 0xffa043c4 I Job>run 0xb71b48b4: a(n) Job > 0xffa043e4 I MorphicUIManager(UIManager)>displayProgress:from:to:during: > 0xb50a8790: a(n) MorphicUIManager > 0xffa04414 I ByteString(String)>displayProgressFrom:to:during: 0xb61238d8: > a(n) ByteString > 0xffa04444 M MCFileTreeGitRepository>loadAllFileNames 0xb612926c: a(n) > MCFileTreeGitRepository > 0xffa04464 I MCFileTreeGitRepository>allFileNames 0xb612926c: a(n) > MCFileTreeGitRepository > 0xffa0448c M MCFileTreeGitRepository>goferVersionFrom: 0xb612926c: a(n) > MCFileTreeGitRepository > 0xff9e238c I > MetacelloCachingGoferResolvedReference(GoferResolvedReference)>version > 0xb71b3134: a(n) MetacelloCachingGoferResolvedReference > 0xff9e23a4 M MetacelloCachingGoferResolvedReference>version 0xb71b3134: > a(n) MetacelloCachingGoferResolvedReference > 0xff9e23bc M [] in > MetacelloFetchingMCSpecLoader>resolveDependencies:nearest:into: 0xb706d83c: > a(n) MetacelloFetchingMCSpecLoader > 0xff9e23e0 M OrderedCollection>do: 0xb71b3234: a(n) OrderedCollection > 0xff9e240c M [] in > MetacelloFetchingMCSpecLoader>resolveDependencies:nearest:into: 0xb706d83c: > a(n) MetacelloFetchingMCSpecLoader > 0xff9e2424 M BlockClosure>on:do: 0xb71b3334: a(n) BlockClosure > 0xff9e244c M > MetacelloFetchingMCSpecLoader>resolveDependencies:nearest:into: 0xb706d83c: > a(n) MetacelloFetchingMCSpecLoader > 0xff9e2490 M [] in > MetacelloFetchingMCSpecLoader>linearLoadPackageSpec:gofer: 0xb706d83c: a(n) > MetacelloFetchingMCSpecLoader > 0xff9ae318 M MetacelloPharo30Platform(MetacelloPlatform)>do:displaying: > 0xb50e8b94: a(n) MetacelloPharo30Platform > 0xff9ae338 M MetacelloFetchingMCSpecLoader>linearLoadPackageSpec:gofer: > 0xb706d83c: a(n) MetacelloFetchingMCSpecLoader > 0xff9ae358 M MetacelloPackageSpec>loadUsing:gofer: 0xb706be54: a(n) > MetacelloPackageSpec > 0xff9ae37c M [] in > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>linearLoadPackageSpecs:repositories: > 0xb706d83c: a(n) MetacelloFetchingMCSpecLoader > 0xff9ae3a0 M OrderedCollection>do: 0xb70c807c: a(n) OrderedCollection > 0xff9ae3c0 M > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>linearLoadPackageSpecs:repositories: > 0xb706d83c: a(n) MetacelloFetchingMCSpecLoader > 0xff9ae3f0 I [] in > MetacelloFetchingMCSpecLoader>linearLoadPackageSpecs:repositories: > 0xb706d83c: a(n) MetacelloFetchingMCSpecLoader > 0xff9ae410 M BlockClosure>ensure: 0xb70c813c: a(n) BlockClosure > 0xff9ae438 I MetacelloLoaderPolicy>pushLoadDirective:during: 0xb706cb7c: > a(n) MetacelloLoaderPolicy > 0xff9ae460 I MetacelloLoaderPolicy>pushLinearLoadDirectivesDuring:for: > 0xb706cb7c: a(n) MetacelloLoaderPolicy > 0xff9ae488 I > MetacelloFetchingMCSpecLoader>linearLoadPackageSpecs:repositories: > 0xb706d83c: a(n) MetacelloFetchingMCSpecLoader > 0xb70c33c0 s MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>load > 0xb706d898 s MetacelloMCVersionSpecLoader>load > 0xb71948d0 s MetacelloMCVersion>executeLoadFromArray: > 0xb719492c s [] in MetacelloMCVersion>fetchRequiredFromArray: > 0xb7194988 s [] in > MetacelloPharo30Platform(MetacelloPlatform)>useStackCacheDuring:defaultDictionary: > 0xb706d96c s BlockClosure>on:do: > 0xb706d2d8 s > MetacelloPharo30Platform(MetacelloPlatform)>useStackCacheDuring:defaultDictionary: > 0xb706d258 s [] in MetacelloMCVersion>fetchRequiredFromArray: > 0xb71949e4 s BlockClosure>ensure: > 0xb706d15c s [] in MetacelloMCVersion>fetchRequiredFromArray: > 0xb706d1e4 s MetacelloPharo30Platform(MetacelloPlatform)>do:displaying: > 0xb706d0e4 s MetacelloMCVersion>fetchRequiredFromArray: > 0xb706ccc0 s [] in MetacelloMCVersion>doLoadRequiredFromArray: > 0xb715327c s BlockClosure>ensure: > 0xb706cc34 s MetacelloMCVersion>doLoadRequiredFromArray: > 0xb71532d8 s MetacelloMCVersion>load > 0xb7153334 s UndefinedObject>(nil) > 0xb7153390 s OpalCompiler>evaluate > 0xb706ab30 s RubSmalltalkEditor>evaluate:andDo: > 0xb706a7f4 s RubSmalltalkEditor>highlightEvaluateAndDo: > 0xb7152edc s [] in > GLMMorphicPharoPlaygroundRenderer(GLMMorphicPharoCodeRenderer)>actOnHighlightAndEvaluate: > 0xb7152f38 s RubEditingArea(RubAbstractTextArea)>handleEdit: > 0xb706a784 s [] in > GLMMorphicPharoPlaygroundRenderer(GLMMorphicPharoCodeRenderer)>actOnHighlightAndEvaluate: > 0xb7152f94 s WorldState>runStepMethodsIn: > 0xb7152ff0 s WorldMorph>runStepMethods > 0xb706a1cc s WorldState>doOneCycleNowFor: > 0xb715304c s WorldState>doOneCycleFor: > 0xb71530a8 s WorldMorph>doOneCycle > 0xb6686f8c s [] in MorphicUIManager>spawnNewProcess > 0xb6686c28 s [] in BlockClosure>newProcess > > Most recent primitives > primCreatePipe > new: > at:put: > at:put: > basicNew > basicNew: > basicNew > basicNew: > primSQFileSetBlocking: > basicNew: > basicAt:put: > basicNew: > basicAt:put: > at:put: > basicNew > primSigPipeNumber > basicNew > wait > at:put: > signal > primForwardSignal:toSemaphore: > wait > at:put: > signal > primCreatePipe > new: > at:put: > at:put: > basicNew > basicNew: > basicNew > basicNew: > primSQFileSetNonBlocking: > basicNew: > basicAt:put: > basicNew: > basicAt:put: > at:put: > basicNew > signal > basicNew: > basicAt:put: > basicNew: > basicAt:put: > at:put: > new: > basicNew > new: > replaceFrom:to:with:startingAt: > basicNew > basicNew: > primSQFileSetNonBlocking: > basicNew > stringHash:initialHash: > primOSFileHandle: > basicNew > wait > at:put: > signal > primAioEnable:forSemaphore:externalObject: > basicNew > objectAt: > basicNew: > stackp: > basicNew > primitiveResume > wait > wait > signal > wait > signal > primAioHandle:exceptionEvents:readEvents:writeEvents: > signal > basicNew: > basicAt:put: > primSQFileSetNonBlocking: > basicNew: > basicAt:put: > basicNew: > basicAt:put: > at:put: > basicNew > basicNew > wait > signal > primUTCMicrosecondsClock > + > >= > + > < > primSignal:atUTCMicroseconds: > wait > signal > wait > wait > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > primUTCMicrosecondsClock > >= > signal > + > primSignal:atUTCMicroseconds: > wait > basicNew > basicNew > basicNew > basicNew > signal > basicNew > signal > basicNew > new: > wait > new: > at:put: > at:put: > at:put: > basicNew: > at:put: > basicNew: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > basicNew > new: > at:put: > new: > basicNew: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > at:put: > basicNew: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > at:put: > at:put: > at:put: > new: > replaceFrom:to:with:startingAt: > primSizeOfPointer > new: > at:put: > at:put: > at:put: > primSizeOfPointer > basicNew: > basicNew > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > new: > basicNew > new: > at:put: > at:put: > at:put: > at:put: > at:put: > at:put: > new: > replaceFrom:to:with:startingAt: > new: > at:put: > at:put: > primGetCurrentWorkingDirectory > basicNew: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir: > primGetPid > primGetPid > primGetPid > basicNew > basicNew > wait > at:put: > signal > wait > shallowCopy > new: > replaceFrom:to:with:startingAt: > signal > wait > replaceFrom:to:with:startingAt: > at:put: > signal > primCloseNoError: > primCloseNoError: > primCloseNoError: > signal > basicNew: > basicNew > basicNew > basicNew > wait > signal > primUTCMicrosecondsClock > + > >= > + > < > primSignal:atUTCMicroseconds: > wait > signal > wait > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > basicNew: > primRead:into:startingAt:count: > basicNew > signal > wait > basicNew: > basicNew > basicNew: > replaceFrom:to:with:startingAt: > replaceFrom:to:with:startingAt: > signal > basicNew > signal > basicNew > new: > wait > signal > wait > signal > primAioHandle:exceptionEvents:readEvents:writeEvents: > signal > wait > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > relinquishProcessorForMicroseconds: > > stack page bytes 4096 available headroom 3300 minimum unused headroom 2152 > > (SIGUSR1) > > > 2015-06-03 14:15 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > > > On Wed, Jun 03, 2015 at 07:05:15AM +0200, Thierry Goubier wrote: > > > Hi Dave, > > > > > > Le 03/06/2015 03:15, David T. Lewis a ?crit : > > > >Hi Thierry and Jose, > > > > > > > >I am reading this thread with interest and will help if I can. > > > > > > > >I do have one idea that we have not tried before. I have a theory that > > > >this may > > > >be an intermittent problem caused by SIGCHLD signals (from the external > > OS > > > >process > > > >when it exits) being missed by the > > UnixOSProcessAccessor>>grimReaperProcess > > > >that handles them. > > > > > > > >If this is happening, then I may be able to change grimReaperProcess to > > > >work around the problem. > > > > > > > >When you see the OS deadlock condition, are you able tell if your Pharo > > VM > > > >process has subprocesses in the zombie state (indicating that > > > >grimReaperProcess > > > >did not clean them up)? The unix command "ps -axf | less" will let you > > look > > > >at the process tree and that may give us a clue if this is happening. > > > > > > I found it very easy to reproduce and I do have a zombie children > > > process to the pharo process. > > > > Jose confirms this also (thanks). > > > > Can you try filing in the attached UnixOSProcessAccessor>>grimReaperProcess > > and see if it helps? I do not know if it will make a difference, but the > > idea is to put a timeout on the semaphore that is waiting for signals from > > SIGCHLD. I am hoping that if these signals are sometimes being missed, then > > the timeout will allow the process to recover from the problem. > > > > > > > > > > Interesting enough, the lock-up happens in a very specific place, a call > > > to git branch, which is a very short command returning just a few > > > characters (where all other commands have longuer outputs). Reducing the > > > frequency of the calls to git branch by a bit of caching reduces the > > > chances of a lock-up. > > > > > > > This is a good clue, and it may indicate a different kind of problem (so > > maybe I am looking in the wrong place). Ben's suggestion of adding a delay > > to the external process sounds like a good idea to help troubleshoot it. > > > > Dave > > > > > >

June 4, 2015

Re: [Pharo-users] case-insensitive regexp

by Peter UhnÃ¡k

I do not think this is possible. The problem is that the Regex compiles (parses) the pattern so once it's created you would have to reparse it. Theoretically speaking you could add ignoreCase accessors to RxMatcher but it is likely it would break things; or add method to RxMatcher that would return a new RxMatcher object with the proper settings. Also note that regular expressions in Pharo are not the extended versions, where these things are usually available (alongside lookahead/lookbehind and other). And personally I find the Regex library so awkward to use that I always opt for PetitParser. ~~~~ myParser := 'hello' asParser. myParser matches: 'Hello'. "false" myParser caseInsensitive matches: 'Hello'. "true" ~~~~ on the other hand there is no option to turn it back again. So if you regularly need to switch it back and forth it wouldn't be solution either. Peter

June 4, 2015