Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 3 participants
- 144622 messages
The Pharo Advantage: what is it for you?
by phil@highoctane.be
Hello,
As part of the defense of a budget and technology choices, what would you
guys list as a key advantage of using Pharo for creating software solutions?
My current stack is:
Pharo 2.0
Seaside 3 (including Seaside-REST)
Magritte 3
Twitter Bootstrap
+ a couple of data storage stuff (DBXTalk, Phriak, Voyage)
+ STOMP
+ Amber if needed
I've been test driving the whole stack for a while and even if there are
some quirks, it looks like good enough for what I want to achieve.
Now, my question: what is the Pharo advantage you would put forward vs
other choices (like LAMP, Java, Rails etc).
I am aware of what those could be but I am more looking for what makes you
tick when using the technology (like: "it is fun to work with", "no more
Java for me, due to ...", "speeds dev time by ...", "not
NSA-backdoor-enabled")
This is the kind of thing we should have in stock for helping the
Consortium members get buy in from people giving a yes on budgets.
Thanks in advance for your help! (BTW, I am going to use this on monday
morning for defending our position on a significant project).
Phil
Aug. 23, 2013
Re: [Pharo-dev] Debugger recursion
by Stéphane Ducasse
HI jan
we cannot see your code
Ideally we would like to have a better handling of deep recursion but we are focusing on more important issues.
Stef
> Hi,
> try this:
>
>
>
> This will start opening infinite number of debuggers, because of
> A>>doesNotUnderstand: #halt.
> Ok, so, if I replace /self halt/ with /Halt signal/, it will do the same,
> but now because of A>>doesNotUnderstand: #inspector.
> But in both cases, after successfully (before stack is full) interrupting
> the recursion with Alt+., only the Process Browser is full of
> "Morphic UI
> process:MorphicUIManager>>openDebuggerOn:context:label:contents:fullView:"
> no real debugger is visible...
>
> My question: How to debug code inside DNU method? Bug? Feature?
> I know, the full stack issue can be solved by a watchdog, is it planned? And
> it was discussed before here on mailinglist, but with different code
> examples.
> Or one can limit the total count of opened...
>
>
>
> -----
> Save The World!
> --
> View this message in context: http://forum.world.st/Debugger-recursion-tp4704703.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
Aug. 23, 2013
-= First Visualization Contest with Roassal =-
by Alexandre Bergel
Dear colleagues and friends,
We are happy to announce the First Visualization Contest with Roassal.
What can I win?
- 150 euros, sponsored by ObjectProfile
- a über-cool ObjectProfile T-shirt and some wonderful stickers
- maximum publicity of your work
- a nice award certificate, delivered during ESUG
How can I win?
- you have to produce a visualization with Roassal. You can use the Pharo, VisualWorks or VAST version of Roassal. Here is an example of what we expect http://bit.ly/sunburstDemo
- making a video is mandatory. The video will weight the most in our decision. The video could be of any length and has to include your name and say that is was made (partly or completely) with Roassal. No need to talk, just show off!
- making your code available and easy to install will help you get more points
How can I submit?
- send the links of your video and other material (if needed) to info(a)objectprofile.com Every email you will send to this email will be acknowledged. If you do not receive a 'Ok' from us, it means we haven't read it, in that case send your email again after a few days.
- the deadline for submitting is September 4, 2013
Mini FAQ?
- Is the object-profile team allowed to participate? No
- Should my visualization or code be open source? No need for this, whatever license is fine. However your video should be made public.
- How can I get more information? Just comment on the facebook https://www.facebook.com/ObjectProfile or using Twitter @ObjectProfile or send email to info(a)objectprofile.com
- What I submit twice? Yes, no problem with that
- How will judge the videos? both the esug community and the object profile team. The Esug community will have 30% of the final grade, object profile the remaining 70%
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://ObjectProfile.com
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Aug. 23, 2013
Debugger recursion
by jan.struz
Hi,
try this:
This will start opening infinite number of debuggers, because of
A>>doesNotUnderstand: #halt.
Ok, so, if I replace /self halt/ with /Halt signal/, it will do the same,
but now because of A>>doesNotUnderstand: #inspector.
But in both cases, after successfully (before stack is full) interrupting
the recursion with Alt+., only the Process Browser is full of
"Morphic UI
process:MorphicUIManager>>openDebuggerOn:context:label:contents:fullView:"
no real debugger is visible...
My question: How to debug code inside DNU method? Bug? Feature?
I know, the full stack issue can be solved by a watchdog, is it planned? And
it was discussed before here on mailinglist, but with different code
examples.
Or one can limit the total count of opened...
-----
Save The World!
--
View this message in context: http://forum.world.st/Debugger-recursion-tp4704703.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Aug. 23, 2013
Re: [Pharo-dev] How do diagnose image locks up (cpu 100%) on save?
by Paul DeBruicker
So when you open the image I posted and in the workspace run
RFBServer start.
Smalltalk snapshot: true andQuit: false.
Everything works fine? It doesn't go to 100% cpu use?
--
View this message in context: http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-tp4704…
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Aug. 23, 2013
Re: [Pharo-dev] How do diagnose image locks up (cpu 100%) on save?
by Igor Stasenko
looks quite healthy to me. image is idle doing nothing.
On 22 August 2013 20:21, Paul DeBruicker <pdebruic(a)gmail.com> wrote:
> Paul DeBruicker wrote
> > In this instance, that doesn't output anything. Specifically:
> >
> >
> > $ ps -A | grep pharo
> > 6001 pts/0 00:00:45 pharo
> > $ kill -s SIGUSR1 6001
> > $
>
>
> Oh no wait. I'm an idiot. It spits out this in the terminal where the
> pharo process is running:
>
> stack page bytes 4096 available headroom 3300 minimum unused headroom 3504
>
> (SIGUSR1)
>
> SIGUSR1 Thu Aug 22 11:18:58 2013
>
>
> pharo VM version: 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3
> Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> Revision: git://gitorious.org/cogvm/blessed.git Commit:
> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100
> By:
> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535
> Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4
> 11:26:59 UTC 2012 x86_64 GNU/Linux
> plugin path: /home/paul/Downloads/pharo2.0/bin [default:
> /home/paul/Downloads/pharo2.0/bin/]
>
>
> C stack backtrace:
> /home/paul/Downloads/pharo2.0/bin/pharo[0x80a0c0c]
> /home/paul/Downloads/pharo2.0/bin/pharo[0x80a0e67]
> [0xf7771410]
> /home/paul/Downloads/pharo2.0/bin/vm-display-X11(+0x10d51)[0xf7765d51]
>
> /home/paul/Downloads/pharo2.0/bin/pharo(ioRelinquishProcessorForMicroseconds+0x14)[0x809e674]
> /home/paul/Downloads/pharo2.0/bin/pharo[0x8081a0a]
> [0xb7010d11]
> /home/paul/Downloads/pharo2.0/bin/pharo(interpret+0x7a6)[0x8094f36]
> /home/paul/Downloads/pharo2.0/bin/pharo(main+0x2b3)[0x80a18b3]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0xf7554935]
>
>
> All Smalltalk process stacks (active first):
> Process 0xb899e15c priority 10
> 0xfff24370 M ProcessorScheduler class>idleProcess 0xb7347240: a(n)
> ProcessorScheduler class
> 0xfff24390 I [] in ProcessorScheduler class>startUp 0xb7347240: a(n)
> ProcessorScheduler class
> 0xfff243b0 I [] in BlockClosure>newProcess 0xb899e080: a(n) BlockClosure
>
> Process 0xb856be14 priority 50
> 0xfff263b0 I WeakArray class>finalizationProcess 0xb7347450: a(n) WeakArray
> class
> 0xb85ce458 s [] in WeakArray class>restartFinalizationProcess
> 0xb856bdb4 s [] in BlockClosure>newProcess
>
> Process 0xb85ced20 priority 80
> 0xfff29350 M Delay class>handleTimerEvent 0xb7349a3c: a(n) Delay class
> 0xfff29370 I Delay class>runTimerEventLoop 0xb7349a3c: a(n) Delay class
> 0xfff29390 I [] in Delay class>startTimerEventLoop 0xb7349a3c: a(n) Delay
> class
> 0xfff293b0 I [] in BlockClosure>newProcess 0xb85cec44: a(n) BlockClosure
>
> Process 0xb899dc7c priority 60
> 0xfff2a344 I InputEventFetcher>waitForInput 0xb7326fd8: a(n)
> InputEventFetcher
> 0xfff2a370 I InputEventFetcher>eventLoop 0xb7326fd8: a(n) InputEventFetcher
> 0xfff2a390 I [] in InputEventFetcher>installEventLoop 0xb7326fd8: a(n)
> InputEventFetcher
> 0xfff2a3b0 I [] in BlockClosure>newProcess 0xb899dba0: a(n) BlockClosure
>
> Process 0xb899df90 priority 60
> 0xfff1c370 I SmalltalkImage>lowSpaceWatcher 0xb764de94: a(n) SmalltalkImage
> 0xfff1c390 I [] in SmalltalkImage>installLowSpaceWatcher 0xb764de94: a(n)
> SmalltalkImage
> 0xfff1c3b0 I [] in BlockClosure>newProcess 0xb899deb4: a(n) BlockClosure
>
> Process 0xb74c5848 priority 40
> 0xfff282fc M [] in Delay>wait 0xb8ae610c: a(n) Delay
> 0xfff2831c M BlockClosure>ifCurtailed: 0xb8ae6348: a(n) BlockClosure
> 0xfff28338 M Delay>wait 0xb8ae610c: a(n) Delay
> 0xfff28358 M WorldState>interCyclePause: 0xb7182620: a(n) WorldState
> 0xfff28374 M WorldState>doOneCycleFor: 0xb7182620: a(n) WorldState
> 0xfff28390 M PasteUpMorph>doOneCycle 0xb7173150: a(n) PasteUpMorph
> 0xfff283b0 I [] in MorphicUIManager>? 0xb7186a5c: a(n) MorphicUIManager
> 0xb74c57e8 s [] in BlockClosure>?
>
> Most recent primitives
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
> relinquishProcessorForMicroseconds:
>
> stack page bytes 4096 available headroom 3300 minimum unused headroom 3504
>
> (SIGUSR1)
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-tp4704…
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>
--
Best regards,
Igor Stasenko.
Aug. 22, 2013
Re: [Pharo-dev] How do diagnose image locks up (cpu 100%) on save?
by Paul DeBruicker
Sven Van Caekenberghe-2 wrote
> On 22 Aug 2013, at 19:34, Paul DeBruicker <
> pdebruic@
> > wrote:
>
>> Hi -
>>
>> The plain Pharo 20619 + RFB image in my dropbox here:
>> https://dl.dropboxusercontent.com/u/4460862/pharo2RFB.zip freezes when
>> you save it while the RFB server is running. The freeze occurs in the
>> #snapshotPrimitive.
>>
>>
>> This is the VM info I'm using:
>>
>> 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3
>> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
>> git://gitorious.org/cogvm/blessed.git Commit:
>> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100
>> By: Esteban Lorenzano <
> estebanlm@
> > Jenkins build #14535
>> Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59
>> UTC 2012 x86_64 GNU/Linux
>> plugin path: /home/paul/pharo/pharo2.0/bin [default:
>> /home/paul/pharo/pharo2.0/bin/]
>>
>>
>> How can I diagnose/fix what is going wrong?
>>
>>
>> I'm reluctant to make it stop and start the RFB server through the
>> snapshot because it will kick off all attached clients. Of which there
>> is at most one and its me, so it wouldn't be too bad but its not
>> desirable.
>>
>> It freezes whether there is a client connection or not.
>
> Paul,
>
> Zinc HTTP Server are stopped/started on each image save. For HTTP 1.1 that
> is OK, protocol wise. I think that RFB should do something similar to
> prevent issues like the one you are reporting (and there have been many in
> the past as well).
>
> Consider this: if you save but do not quit, and you later abort the image
> hard, you would expect the saved image to work, right. That can only be
> with a fresh server socket.
>
> Sven
>
>> Thanks
>>
>> Paul
>>
I think the 'abort the image hard' problem is taken care of in the #startUp:
method on the RFBServer. It checks if the image is resuming and the server
is/was running and if so stopping then restarting the RFB server. I don't
want to stop and restart the server every time there is a save. I'm fine
doing it on startup after a quit or abort as you describe.
Anyway, from the stack dump I posted I cannot tell for sure but it seems
like a VM bug.
--
View this message in context: http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-tp4704…
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Aug. 22, 2013
Re: [Pharo-dev] [Pharo-fuel] Fuel API bug
by Stéphane Ducasse
hi henrik
do you have an implementation for when:do:for: because I do not see it?
https://pharo.fogbugz.com/default.asp?11316
Stef
>>>> #when:do: is there already ;)
>>>
>>> even better then :)
>>>
>>>> #when:send:to: and #when:do:for: should be added though.
>>
>> what would be when:do:for: ?
>
> Its use is to specify a non-standard subscriber.
> In VW it is pretty much mandatory when using weak subscription, as VW subscribes the block.
> In Pharo it's much less useful, both because the at the moment weak when:do: doesn't work, but also since Pharo subscribes the block's receiver by default, which is what you want in 95% of cases.
> Still nice to have around in the edge cases one might still need it though.
>
> Cheers,
> Henry
Aug. 22, 2013
Re: [Pharo-dev] How do diagnose image locks up (cpu 100%) on save?
by Sven Van Caekenberghe
On 22 Aug 2013, at 19:34, Paul DeBruicker <pdebruic(a)gmail.com> wrote:
> Hi -
>
> The plain Pharo 20619 + RFB image in my dropbox here:
> https://dl.dropboxusercontent.com/u/4460862/pharo2RFB.zip freezes when
> you save it while the RFB server is running. The freeze occurs in the
> #snapshotPrimitive.
>
>
> This is the VM info I'm using:
>
> 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3
> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> git://gitorious.org/cogvm/blessed.git Commit:
> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100
> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535
> Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59
> UTC 2012 x86_64 GNU/Linux
> plugin path: /home/paul/pharo/pharo2.0/bin [default:
> /home/paul/pharo/pharo2.0/bin/]
>
>
> How can I diagnose/fix what is going wrong?
>
>
> I'm reluctant to make it stop and start the RFB server through the
> snapshot because it will kick off all attached clients. Of which there
> is at most one and its me, so it wouldn't be too bad but its not
> desirable.
>
> It freezes whether there is a client connection or not.
Paul,
Zinc HTTP Server are stopped/started on each image save. For HTTP 1.1 that is OK, protocol wise. I think that RFB should do something similar to prevent issues like the one you are reporting (and there have been many in the past as well).
Consider this: if you save but do not quit, and you later abort the image hard, you would expect the saved image to work, right. That can only be with a fresh server socket.
Sven
> Thanks
>
> Paul
>
Aug. 22, 2013
Re: [Pharo-dev] How do diagnose image locks up (cpu 100%) on save?
by Paul DeBruicker
Paul DeBruicker wrote
> In this instance, that doesn't output anything. Specifically:
>
>
> $ ps -A | grep pharo
> 6001 pts/0 00:00:45 pharo
> $ kill -s SIGUSR1 6001
> $
Oh no wait. I'm an idiot. It spits out this in the terminal where the
pharo process is running:
stack page bytes 4096 available headroom 3300 minimum unused headroom 3504
(SIGUSR1)
SIGUSR1 Thu Aug 22 11:18:58 2013
pharo VM version: 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3
Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
Revision: git://gitorious.org/cogvm/blessed.git Commit:
412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By:
Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535
Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4
11:26:59 UTC 2012 x86_64 GNU/Linux
plugin path: /home/paul/Downloads/pharo2.0/bin [default:
/home/paul/Downloads/pharo2.0/bin/]
C stack backtrace:
/home/paul/Downloads/pharo2.0/bin/pharo[0x80a0c0c]
/home/paul/Downloads/pharo2.0/bin/pharo[0x80a0e67]
[0xf7771410]
/home/paul/Downloads/pharo2.0/bin/vm-display-X11(+0x10d51)[0xf7765d51]
/home/paul/Downloads/pharo2.0/bin/pharo(ioRelinquishProcessorForMicroseconds+0x14)[0x809e674]
/home/paul/Downloads/pharo2.0/bin/pharo[0x8081a0a]
[0xb7010d11]
/home/paul/Downloads/pharo2.0/bin/pharo(interpret+0x7a6)[0x8094f36]
/home/paul/Downloads/pharo2.0/bin/pharo(main+0x2b3)[0x80a18b3]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0xf7554935]
All Smalltalk process stacks (active first):
Process 0xb899e15c priority 10
0xfff24370 M ProcessorScheduler class>idleProcess 0xb7347240: a(n)
ProcessorScheduler class
0xfff24390 I [] in ProcessorScheduler class>startUp 0xb7347240: a(n)
ProcessorScheduler class
0xfff243b0 I [] in BlockClosure>newProcess 0xb899e080: a(n) BlockClosure
Process 0xb856be14 priority 50
0xfff263b0 I WeakArray class>finalizationProcess 0xb7347450: a(n) WeakArray
class
0xb85ce458 s [] in WeakArray class>restartFinalizationProcess
0xb856bdb4 s [] in BlockClosure>newProcess
Process 0xb85ced20 priority 80
0xfff29350 M Delay class>handleTimerEvent 0xb7349a3c: a(n) Delay class
0xfff29370 I Delay class>runTimerEventLoop 0xb7349a3c: a(n) Delay class
0xfff29390 I [] in Delay class>startTimerEventLoop 0xb7349a3c: a(n) Delay
class
0xfff293b0 I [] in BlockClosure>newProcess 0xb85cec44: a(n) BlockClosure
Process 0xb899dc7c priority 60
0xfff2a344 I InputEventFetcher>waitForInput 0xb7326fd8: a(n)
InputEventFetcher
0xfff2a370 I InputEventFetcher>eventLoop 0xb7326fd8: a(n) InputEventFetcher
0xfff2a390 I [] in InputEventFetcher>installEventLoop 0xb7326fd8: a(n)
InputEventFetcher
0xfff2a3b0 I [] in BlockClosure>newProcess 0xb899dba0: a(n) BlockClosure
Process 0xb899df90 priority 60
0xfff1c370 I SmalltalkImage>lowSpaceWatcher 0xb764de94: a(n) SmalltalkImage
0xfff1c390 I [] in SmalltalkImage>installLowSpaceWatcher 0xb764de94: a(n)
SmalltalkImage
0xfff1c3b0 I [] in BlockClosure>newProcess 0xb899deb4: a(n) BlockClosure
Process 0xb74c5848 priority 40
0xfff282fc M [] in Delay>wait 0xb8ae610c: a(n) Delay
0xfff2831c M BlockClosure>ifCurtailed: 0xb8ae6348: a(n) BlockClosure
0xfff28338 M Delay>wait 0xb8ae610c: a(n) Delay
0xfff28358 M WorldState>interCyclePause: 0xb7182620: a(n) WorldState
0xfff28374 M WorldState>doOneCycleFor: 0xb7182620: a(n) WorldState
0xfff28390 M PasteUpMorph>doOneCycle 0xb7173150: a(n) PasteUpMorph
0xfff283b0 I [] in MorphicUIManager>? 0xb7186a5c: a(n) MorphicUIManager
0xb74c57e8 s [] in BlockClosure>?
Most recent primitives
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
relinquishProcessorForMicroseconds:
stack page bytes 4096 available headroom 3300 minimum unused headroom 3504
(SIGUSR1)
--
View this message in context: http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-tp4704…
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Aug. 22, 2013