- Pharo-users - lists.pharo.org

Re: [Pharo-users] pillar remove numbering from some headings

by Cyril Ferlicot

Hi Peter, for now Pillar doesn't manage this. I'll take a look at it when I'll work on the Beamer exporter. On 3 June 2015 at 03:20, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is there a way to remove heading numbering for some headings? > > Basically I'm looking for an equivalent of Latex' \subsection*{...}. > > Thanks, > Peter -- Cheers Cyril Ferlicot

June 3, 2015

RWView signalUpdate

by Lusa Nicolas

Hi, I noticed that with the recent changes that you made the view isn't updating anymore so I would like to update it by myself. I saw that in RWView there is the method called signalUpdate which is supposed to update the view but when I call it actually nothing happens. The situation that I have when I use it: - I have some objects in gray color displayed in my view. - I change the color and update the element. At this point the view doesn't update automatically so they stay gray even though I changed the color - I call signalUpdate on my view but nothing refreshes, the objects stay gray. At first I thought the problem was that the instance variable signalUpdateCallback was not initialised since in the initialisation is set to be nothing. But then I noticed it is actually initialised in RWViewWindow so that should be fine. I also have to say that my focus is not on the window that displays my objects but on another window in the same pharo image (just beside the window that contains the objects). Might that be the problem? Even though I have this situation I really would like to update the view even though the focus is not on that window. Any idea on how to make it work? Thanks Nicolas. P.S. any news on the possibility to distinguish different buttons interactions (i.e. distinguish left from right click of the mouse)?

June 3, 2015

Pharo Video Tutorial: Package Tags

by Dimitris Chloupis

In this Episode of "Pharo Video Tutorial" we take a look at "Package tags" and how we can use them to organise our classes and packages to make our lives easier https://www.youtube.com/watch?v=Q2Vwg_0RMVU&list=PLqbtQ7OkSta0ULYAd7Qdxof85…

June 3, 2015

Re: [Pharo-users] PUngLite can't query large database

by riverdusty

Hi Paul Yes, the query works on smaller databases. I've created quite a few, one of them was 200MB and that worked! I believe this is some memory/size limit. I'm curious if there is a suitable way to overcome/override this limit. I'm working on another project today but I'll try those suggestions perhaps later or tomorrow and get back with the results. Thanks for the reply and suggestions. KR -- View this message in context: http://forum.world.st/PUngLite-can-t-query-large-database-tp4829931p4830136… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 3, 2015

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

by Jose San Leandro

Sending the SIGUSR1 signal prints this: 0xb84e2a7c s NonInteractiveUIManager(UIManager)>defer: 0xb84e29f4 s PharoCommandLineHandler class>activateWith: 0xb84f5e08 s [] in BasicCommandLineHandler>activateSubCommand: 0xb84e2e98 s BlockClosure>on:do: 0xb84e2970 s BasicCommandLineHandler>activateSubCommand: 0xb84e2914 s BasicCommandLineHandler>handleSubcommand 0xb84f5e64 s BasicCommandLineHandler>handleArgument: 0xb84e281c s [] in BasicCommandLineHandler>activate 0xb84e2878 s BlockClosure>on:do: 0xb84e27a0 s BasicCommandLineHandler>activate 0xb84f5cf4 s [] in BasicCommandLineHandler class>startUp: 0xb84f5d50 s BlockClosure>cull: 0xb84f5dac s [] in SmalltalkImage>executeDeferredStartupActions: 0xb84e2ef4 s BlockClosure>on:do: 0xb84e0ee4 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0xb84e0e1c s SmalltalkImage>executeDeferredStartupActions: 0xb84e0c1c s SmalltalkImage>startupImage:snapshotWorked: 0xb84e0170 s SmalltalkImage>snapshot:andQuit: 0xb84e04ac s [] in WorldState class>saveAndQuit 0xb84e0508 s BlockClosure>ensure: 0xb84d3274 s CursorWithMask(Cursor)>showWhile: 0xb84d3208 s WorldState class>saveAndQuit 0xb84e0564 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xb84e05c0 s BlockClosure>ensure: 0xb84d3198 s CursorWithMask(Cursor)>showWhile: 0xb84d30c8 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xb84d306c s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: 0xb84e061c s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: 0xb84e0678 s MouseButtonEvent>sentTo: 0xb84e06d4 s ToggleMenuItemMorph(Morph)>handleEvent: 0xb84e0730 s MorphicEventDispatcher>dispatchDefault:with: 0xb84e078c s MorphicEventDispatcher>handleMouseUp: 0xb84e07e8 s MouseButtonEvent>sentTo: 0xb84e0844 s [] in MorphicEventDispatcher>dispatchEvent:with: 0xb84e08a0 s BlockClosure>ensure: 0xb84d2fec s MorphicEventDispatcher>dispatchEvent:with: 0xb84e08fc s ToggleMenuItemMorph(Morph)>processEvent:using: 0xb84d2f08 s MorphicEventDispatcher>dispatchDefault:with: 0xb84d2f64 s MorphicEventDispatcher>handleMouseUp: 0xb84e01cc s MouseButtonEvent>sentTo: 0xb84e0228 s [] in MorphicEventDispatcher>dispatchEvent:with: 0xb84e0284 s BlockClosure>ensure: 0xb84d2e88 s MorphicEventDispatcher>dispatchEvent:with: 0xb84e02e0 s MenuMorph(Morph)>processEvent:using: 0xb84e033c s MenuMorph(Morph)>processEvent: 0xb84e0398 s MenuMorph>handleFocusEvent: 0xb84e03f4 s [] in HandMorph>sendFocusEvent:to:clear: 0xb84e0450 s BlockClosure>on:do: 0xb84d2d88 s WorldMorph(PasteUpMorph)>becomeActiveDuring: 0xb84d2d10 s HandMorph>sendFocusEvent:to:clear: 0xb84d2e00 s HandMorph>sendEvent:focus:clear: 0xb84d2c9c s HandMorph>sendMouseEvent: 0xb84e0958 s HandMorph>handleEvent: 0xb84e09b4 s HandMorph>processEvents 0xb84e0a10 s [] in WorldState>doOneCycleNowFor: 0xb84e0a6c s Array(SequenceableCollection)>do: 0xb84e0ac8 s WorldState>handsDo: 0xb84d2ba4 s WorldState>doOneCycleNowFor: 0xb84e0b24 s WorldState>doOneCycleFor: 0xb84e0b80 s WorldMorph>doOneCycle 0xb84a0b60 s [] in MorphicUIManager>spawnNewProcess 0xb84a0adc s [] in BlockClosure>newProcess Most recent primitives [..] On Wed, Jun 3, 2015 at 8:32 AM, Jose San Leandro <jose.sanleandro(a)osoco.es> wrote: > Hi Dave, Thierry, > > Here's what I get in all recent attempts: > > [..] > /2.3/lib/gradle-launcher-2.3.jar org.gradle.launcher.GradleMain assemble > 18620 pts/5 S+ 0:00 | \_ bash > /home/chous/toolbox/pharo/pharo Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 18635 pts/5 R+ 5:07 | \_ > /home/chous/toolbox/pharo/pharo-vm/pharo --nodisplay Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 32741 pts/5 Z+ 0:00 | \_ [git] <defunct> > > > > > 2015-06-03 7:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> 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. >> >> 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. >> >> Thanks, >> >> Dave >> >> Thanks! >>> >>> Dave >>> >>> >>> >>> >> >> > 2015-06-03 8:32 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > Hi Dave, Thierry, > > Here's what I get in all recent attempts: > > [..] > /2.3/lib/gradle-launcher-2.3.jar org.gradle.launcher.GradleMain assemble > 18620 pts/5 S+ 0:00 | \_ bash > /home/chous/toolbox/pharo/pharo Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 18635 pts/5 R+ 5:07 | \_ > /home/chous/toolbox/pharo/pharo-vm/pharo --nodisplay Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 32741 pts/5 Z+ 0:00 | \_ [git] <defunct> > > > > > 2015-06-03 7:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> 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. >> >> 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. >> >> Thanks, >> >> Dave >> >> Thanks! >>> >>> Dave >>> >>> >>> >>> >> >> >

June 3, 2015

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

by Jose San Leandro

Hi Dave, Thierry, Here's what I get in all recent attempts: [..] /2.3/lib/gradle-launcher-2.3.jar org.gradle.launcher.GradleMain assemble 18620 pts/5 S+ 0:00 | \_ bash /home/chous/toolbox/pharo/pharo Pharo.image config gitfiletree:///home/chous/osoco/open-badges/game-core ConfigurationOfGameCore --install=bleedingEdge 18635 pts/5 R+ 5:07 | \_ /home/chous/toolbox/pharo/pharo-vm/pharo --nodisplay Pharo.image config gitfiletree:///home/chous/osoco/open-badges/game-core ConfigurationOfGameCore --install=bleedingEdge 32741 pts/5 Z+ 0:00 | \_ [git] <defunct> 2015-06-03 7:05 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > 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. > > 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. > > Thanks, > > Dave > > Thanks! >> >> Dave >> >> >> >> > >

June 3, 2015

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

by Ben Coman

On Wed, Jun 3, 2015 at 1:05 PM, Thierry Goubier <thierry.goubier(a)gmail.com> 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. > > 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. As a workaround and investigation, can you wrap the "git banch" in a script and experiment with extending the time. #!/usr/local/mygitbranch git branch $@ STATUS=$? # sleep 1 exit STATUS http://www.tldp.org/LDP/abs/html/exit-status.html http://stackoverflow.com/questions/18492443/pass-all-parameters-of-one-shel… cheers -ben

June 3, 2015

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

by Thierry Goubier

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. 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. Thanks, Dave > Thanks! > > Dave > > >

June 3, 2015

Timezone offset in Date, why?

by Esteban A. Maringolo

I'm debugging the PostgresV3 driver for GLORP, and among other test failures, there is a kind that particularly bugs me: two identical dates do not match, the reason? The internal "start" of aDate (Timespan) is a DateAndTime, and as such has a timezone offset. Is this conceptually right? Esteban A. Maringolo

June 3, 2015

pillar remove numbering from some headings

by Peter UhnÃ¡k

Hi, is there a way to remove heading numbering for some headings? Basically I'm looking for an equivalent of Latex' \subsection*{...}. Thanks, Peter

June 3, 2015