most probably :( I will check tomorrow and provide a fix. Esteban On 11 Jan 2014, at 20:16, Sebastian Sastre <sebastian@flowingconcept.com> wrote:

Hi Michael,

sounds good but what script do you mean I should edit?

I mean, all I'm seen is that wget and curl

It's a bug in the hosted scripts?

sebastian

o/

On Jan 11, 2014, at 2:26 AM, Michael J. Forster <mike@sharedlogic.ca> wrote:

...

On 14-01-10 07:54 PM, Sebastian Sastre wrote:

...

Hi guys,

I'm new to ZeroConf, sounds really great.

In OS X worked fine for me but on an ubuntu machine it said this:

Hi Sebastian,

mktemp(3) on Linux requires at least 6 Xs in the directory template. Edit the script to add one more X to the template and try it again.

Cheers,

Mike

-- Michael J. Forster, B.Sc. (Hons.), B.Sc. COO, Programmer Shared Logic Inc.

On 14-01-11 04:34 PM, Esteban Lorenzano wrote:

but I wonder why it does not fail for more people (me included)… we use a lot linux (for ci, etc.).

Esteban [...]

Like so many corners of Unix/Linux/Darwin, the design of mktemp(3) permits too many arbitrary and incompatible implementations. We're not the only ones to suffer here: https://github.com/Homebrew/linuxbrew/issues/26 Cheers, Mike -- Michael J. Forster, B.Sc. (Hons.), B.Sc. COO, Programmer Shared Logic Inc.

On 01/10/2014 09:15 PM, Martin McClure wrote:

I saw this a time or two in Pharo 2.0, and now I've seen it in Pharo 3.0 -- I launch my working image and all my windows display, but it doesn't respond to mouse clicks. Keystrokes don't seem to do anything either, other than alt-., which dumps the text below to the terminal, but doesn't seem to do anything else.

Any ideas how to debug this?

I'm running on Linux. Pharo 3.0 last updated on Jan 7.

Ouch! Now it's doing this with the virgin 3.0 image. That didn't happen before with 2.0. -Martin

Hi Martin, I don’t use Linux but on Mac OS I had similar problems. That have been „fixed“ by putting the sources file to the vm folder. There was a discussion a few days ago. I don’t remember the exactly when. As I am on a low bandwidth connection at the moment I cannot search for it. Hope that helps you on Linux, too. Best regards, Andreas Am 11.01.2014 um 07:35 schrieb Martin McClure <martin@hand2mouse.com>:

On 01/10/2014 09:20 PM, Martin McClure wrote:

...

On 01/10/2014 09:15 PM, Martin McClure wrote:

...

I saw this a time or two in Pharo 2.0, and now I've seen it in Pharo 3.0 -- I launch my working image and all my windows display, but it doesn't respond to mouse clicks. Keystrokes don't seem to do anything either, other than alt-., which dumps the text below to the terminal, but doesn't seem to do anything else.

Any ideas how to debug this?

I'm running on Linux. Pharo 3.0 last updated on Jan 7.

Ouch! Now it's doing this with the virgin 3.0 image. That didn't happen before with 2.0.

Reboot doesn't fix it. Can't run Pharo 2.0 *or* 3.0. I did upgrade my system five days ago; this *could* be the first time I've tried to launch an image since then (might have already been running before). I run Gentoo stable.

Any hints on how to debug this would be *very* welcome!

Thanks,

-Martin

On 01/11/2014 06:26 PM, J.F. Rick wrote:

Try just hitting Alt without anything else. That has worked for me on Linux.

Thanks for the suggestion. Hitting Alt alone doesn't seem to do anything either. I'm beginning to suspect that delays are not expiring at the OS level -- I'll be getting some traces later to see whether that hunch is a reasonable one. But right now I have to (get to!) go dance for a few hours. :-) Regards, -Martin

Hi Andres, Could you describe in some detail how to make something clearly fail related to this issue ? There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable. Thx, Sven On 12 Jan 2014, at 04:41, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc.

BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds.

On 1/11/14 19:29 , Martin McClure wrote:

...

I'm beginning to suspect that delays are not expiring at the OS level

Hi Andres, Pharo (Cuis) does not exit… I suppose you are talking about the vm from Pharo, used with a Cuis image… can you confirm that same problem exists in pharo-vm with pharo-image? Esteban On 13 Jan 2014, at 09:37, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

Try the following on OS X...

1. Launch Pharo (Cuis).

2. Go to the System Settings time panel.

3. Disable automatic time updates.

4. Bump the clock forward by 1 minute.

5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen).

6. Wait one minute.

7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again).

As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute.

If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward.

I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images.

On 1/13/14 0:22 , Sven Van Caekenberghe wrote:

...

Hi Andres,

Could you describe in some detail how to make something clearly fail related to this issue ?

There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable.

Thx,

Sven

On 12 Jan 2014, at 04:41, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

...

Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc.

BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds.

On 1/11/14 19:29 , Martin McClure wrote:

...

I'm beginning to suspect that delays are not expiring at the OS level

.

(of course, make sure you're online when you re-enable automatic time keeping so that NTP bumps the clock backwards... if not, do it manually) On 1/13/14 4:10 , Andres Valloud wrote:

My friend, you need to believe :)...

Ok, so with Cuis the image hangs (unresponsive to input) when the clock goes forward. With Pharo 2.0 (just checked), the image hangs when the clock goes backwards. To verify, simply create a new process that periodically writes something to the Transcript, such as

p := [ [ (Delay forSeconds: 1) wait. Transcript cr; show: Time now seconds printString ] repeat ] newProcess. p resume

then go to the system settings panel, time section, uncheck the automatic time keeping, bump the clock up by one minute, save (note the skew in the Transcript output), then re-enable automatic time keeping, make sure the settings are saved... and now the image is unresponsive. Alt+. does nothing etc. Wait one minute. After that time, you will get a debugger and things will start happening again.

If you can't immediately reproduce it, I really suspect that if you play with the time for a bit you will get some weird behavior too.

On 1/13/14 1:18 , Esteban Lorenzano wrote:

...

Hi Andres,

Pharo (Cuis) does not exit… I suppose you are talking about the vm from Pharo, used with a Cuis image… can you confirm that same problem exists in pharo-vm with pharo-image?

Esteban

On 13 Jan 2014, at 09:37, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

...

Try the following on OS X...

1. Launch Pharo (Cuis).

2. Go to the System Settings time panel.

3. Disable automatic time updates.

4. Bump the clock forward by 1 minute.

5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen).

6. Wait one minute.

7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again).

As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute.

If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward.

I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images.

On 1/13/14 0:22 , Sven Van Caekenberghe wrote:

...

Hi Andres,

Could you describe in some detail how to make something clearly fail related to this issue ?

There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable.

Thx,

Sven

On 12 Jan 2014, at 04:41, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

...

Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc.

BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds.

On 1/11/14 19:29 , Martin McClure wrote:

...

I'm beginning to suspect that delays are not expiring at the OS level

.

.

.

My friend, you also need to believe :)... Checked with Pharo 3.0, misbehavior reproduced. I'm done hanging various versions of Pharo and Cuis on my machine. It's someone else's turn now :D. On 1/13/14 4:17 , Marcus Denker wrote:

On 13 Jan 2014, at 13:10, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

...

My friend, you need to believe :)...

Ok, so with Cuis the image hangs (unresponsive to input) when the clock goes forward. With Pharo 2.0 (just checked),

It might be better to check in Pharo3… there where changes e.g.

7444 Synchronizing DateAndTime with system OS date and time https://pharo.fogbugz.com/f/cases/7444

Marcus

https://pharo.fogbugz.com/f/cases/12639/Image-hangs-on-clock-changes On 13 Jan 2014, at 13:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Confirmed, I turn it into an issue.

Thanks for reporting this, Andres.

On 13 Jan 2014, at 13:23, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

...

My friend, you also need to believe :)...

Checked with Pharo 3.0, misbehavior reproduced.

I'm done hanging various versions of Pharo and Cuis on my machine. It's someone else's turn now :D.

On 1/13/14 4:17 , Marcus Denker wrote:

...

On 13 Jan 2014, at 13:10, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:

...

My friend, you need to believe :)...

Ok, so with Cuis the image hangs (unresponsive to input) when the clock goes forward. With Pharo 2.0 (just checked),

It might be better to check in Pharo3… there where changes e.g.

7444 Synchronizing DateAndTime with system OS date and time https://pharo.fogbugz.com/f/cases/7444

Marcus

Whoops, it was an old bug after all! :( On 1/13/14 4:51 , Nicolai Hess wrote:

Yes, chaging the system time is a known issue for pharos linux-vm:

11324 <https://pharo.fogbugz.com/default.asp?11324> Image freeze when changing system time

Didn't tried myself but there is a tracing library for X called xscope. Is not included by default in most distros. http://xorg.freedesktop.org/archive/individual/app/xscope-1.4.tar.gz Don't bother with xev, does not capture clicks inside Pharo. Hernán 2014/1/11 Martin McClure <martin@hand2mouse.com>

I saw this a time or two in Pharo 2.0, and now I've seen it in Pharo 3.0 -- I launch my working image and all my windows display, but it doesn't respond to mouse clicks. Keystrokes don't seem to do anything either, other than alt-., which dumps the text below to the terminal, but doesn't seem to do anything else.

Any ideas how to debug this?

I'm running on Linux. Pharo 3.0 last updated on Jan 7.

Thanks,

-Martin

---------

User Interrupt Delay>>wait in Block: [ delaySemaphore wait ] BlockClosure>>ifCurtailed: Delay>>wait WorldState>>interCyclePause: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: [ ... BlockClosure>>newProcess in Block: [ ...

2014/1/11 Martin McClure <martin@hand2mouse.com>

On 01/11/2014 12:17 AM, Hernán Morales Durand wrote:

...

Didn't tried myself but there is a tracing library for X called xscope. Is not included by default in most distros.

http://xorg.freedesktop.org/archive/individual/app/xscope-1.4.tar.gz

Don't bother with xev, does not capture clicks inside Pharo.

Thanks for the replies.

Adding the sources file to the bin dir -- no change. I'll try xscope and see if any interesting info surfaces.

I looked at what libs are loaded by Pharo, and which ones of those are ones I upgraded last week. The intersection appears to be related to one package: I upgraded glibc from 2.16 to 2.17. At this point this seems to be the likeliest cause. However, I think I've run Pharo 3.0 on another very similar machine (at work) with glibc 2.17 successfully. Hmm.

Where can I find instructions on how to build my own VM from source? Or alternative VMs to try?

Regards,

-Martin

This instructions are very good: https://github.com/pharo-project/pharo-vm I build my own vm because I am using a rather old ubuntu version (10.04) and the current vm does not work with my glibc version. Feel free to ask if you have any questions or problems with building the vm. Nicolai

On 01/11/2014 10:21 AM, Martin McClure wrote:

On 01/11/2014 08:55 AM, Nicolai Hess wrote:

...

This instructions are very good: https://github.com/pharo-project/pharo-vm

I build my own vm because I am using a rather old ubuntu version (10.04) and the current vm does not work with my glibc version. Feel free to ask if you have any questions or problems with building the vm.

Thanks for the pointer! I'll try it...

Well, I built a VM. No joy, same symptoms. I had to generate the sources on a different machine, one that agrees to still run Pharo. I then rsynced the whole thing to the machine with the trouble and built there. The first time it faild the cmake since vmVersionInfo.h was not present. I fixed build/build.sh, which was trying to execute ../codegen-scripts/extract-commit-info.sh which did not exists. After changing it to execute ../scripts/extract-commit-info.sh it completed and the resulting VM works just like the downloaded binary, which is to say that it displays windows but does not respond to mouse clicks or to keyboard input except alt-.. Ideas for where to go next? Regards, -Martin

Still completely unable to run any Pharo on my main development machine. I tried running with --trace. It would appear that no Smalltalk is being run on mouse clicks or on keystrokes, with the exception of Alt-., which generates the output shown below. Regards, -Martin PharoUserPermissions>canDebug User Interrupt Delay>>wait in Block: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushInstVar: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>returnReceiver IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: CompiledMethodTrailer>encodeNoTrailer [ delaySemaphore wait ] BlockClosure>>ifCurtailed: Delay>>wait WorldState>>interCyclePause: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle MorphicUIManager>>spawnNewProcess in Block: CompiledMethodTrailer>decodeEmbeddedSourceZip ZipReadStream(InflateStream)>processDynamicBlock OCASTTranslatorForValue>emitWhileFalse: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>storePopIntoLiteralVariable: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>returnReceiver IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: CompiledMethodTrailer>encodeNoTrailer [ ... BlockClosure>>newProcess in Block: CompiledMethodTrailer>decodeEmbeddedSourceZip ZipReadStream(InflateStream)>processDynamicBlock IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: CompiledMethodTrailer>encodeNoTrailer [ ... IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>storePopTemp: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>storePopTemp: CompiledMethodTrailer>encodeNoTrailer OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCASTTranslatorForEffect(OCASTTranslator)>emitIfFalseIfTrue: OCASTTranslatorForEffect>emitIfTrue: OCASTTranslatorForValue>emitAnd: OCASTTranslatorForEffect>emitIfTrue: OCASTTranslatorForValue>emitAnd: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushInstVar: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>storePopTemp: IRBytecodeGenerator>pushInstVar: IRBytecodeGenerator>storePopTemp: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>storePopInstVar: IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>storePopIntoLiteralVariable: IRBytecodeGenerator>returnReceiver IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: CompiledMethodTrailer>encodeNoTrailer OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushLiteralVariable: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>returnReceiver CompiledMethodTrailer>encodeNoTrailer OCTempVariable(OCAbstractLocalVariable)>name OCTempVariable(OCAbstractLocalVariable)>name IRBytecodeGenerator>pushInstVar: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>returnReceiver CompiledMethodTrailer>encodeNoTrailer Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* Float>* OCASTTranslatorForValue>emitIfTrue: OCASTTranslatorForValue>emitIfFalse: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>pushInstVar: IRBytecodeGenerator>pushReceiver IRBytecodeGenerator>pushLiteral: IRBytecodeGenerator>storePopInstVar: IRBytecodeGenerator>returnReceiver IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>closureFrom:to:copyNumCopiedValues:numArgs: IRBytecodeGenerator>from:if:goto:otherwise: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: IRBytecodeGenerator>from:goto: CompiledMethodTrailer>encodeNoTrailer

On 01/12/2014 02:33 AM, Marcus Denker wrote:

It is storage that the compiler is running… do you have some kind of startup scripts defined?

No, I'm just launching a virgin image, in a clean unzip of the download. Regards, -Martin

i remember there was similar problem last year with ubuntu unity desktop: you starting image from command line - nothing respond, but if you start from desktop, everything works well. which then later was cured without any changes from our side, by some ubuntu update Best regards, Igor Stasenko.

That sounds really weird. Having to launch from GUI to start a working image is not very convenient. Let us know if you have any other findings. Cheers, Hernán 2014/1/13 Martin McClure <martin@hand2mouse.com>

On 01/12/2014 05:22 PM, Igor Stasenko wrote:

...

i remember there was similar problem last year with ubuntu unity desktop: you starting image from command line - nothing respond, but if you start from desktop, everything works well. which then later was cured without any changes from our side, by some ubuntu update

Thanks, Igor!

It would never occur to me to launch from GUI rather than command line.

...OK, this is *completely* weird. Yes, launched from desktop (KDE 4.11 Dolphin) it works. What's more, it *also* works from shells launched from a Konsole instance launched yesterday. But it still fails to work for shells launched from a Konsole instance launched shortly after reboot on Friday night. I haven't yet been able to find any significant difference between those shells. Their environments differ in a few variables, but manually setting those in a shell where Pharo works to the values from a shell where Pharo doesn't work -- Pharo still works. Examining /proc from a working Pharo and a non-working Pharo has not turned up anything.

I'll chase this a bit more later, but at least now I *can* run Pharo. For the moment. Who knows what will happen next time I need to reboot?

Thanks again,

-Martin

Very interesting insights all along the way. Phil On Monday, January 13, 2014, Martin McClure wrote:

On 01/12/2014 10:18 PM, Hernán Morales Durand wrote:

...

That sounds really weird. Having to launch from GUI to start a working image is not very convenient. Let us know if you have any other findings.

Thanks. After some digging, I think I've got it.

The pharo executable is launched by the bash shell via a fork followed by an execve. The signal mask is inherited from the parent process, and preserved across the execve. Pharo does not modify the signal mask except once:

rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0

which only appears to deal with one real-time signal.

In my case, somehow one set of shells has SIGALRM masked, and another set of shells does not have it masked. Pharo seems to rely on SIGALRMs from the interval timer to wake it up periodically (every 2 ms) presumably to see whether it has any work to do.

So no SIGALRMS delivered, not much happens.

I have no idea why my shells are masking various signals, but it seems clear that it would be a good idea for the VM to initialize its signal mask explicitly rather than depending on the parent process to have it set sanely.

So I count this one as a VM bug. If someone better connected with the VM community would report it as such, I'd appreciate it.

Thanks for all the suggestions while I dug to the bottom of this one.

Regards,

-Martin

-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Thanks, Martin. I added this to issue tracker: https://pharo.fogbugz.com/f/cases/12641/VM-signal-handling-on-nix should be trivial to fix. On 13 January 2014 07:50, Martin McClure <martin@hand2mouse.com> wrote:

On 01/12/2014 10:18 PM, Hernán Morales Durand wrote:

...

That sounds really weird. Having to launch from GUI to start a working image is not very convenient. Let us know if you have any other findings.

Thanks. After some digging, I think I've got it.

The pharo executable is launched by the bash shell via a fork followed by an execve. The signal mask is inherited from the parent process, and preserved across the execve. Pharo does not modify the signal mask except once:

rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0

which only appears to deal with one real-time signal.

In my case, somehow one set of shells has SIGALRM masked, and another set of shells does not have it masked. Pharo seems to rely on SIGALRMs from the interval timer to wake it up periodically (every 2 ms) presumably to see whether it has any work to do.

So no SIGALRMS delivered, not much happens.

I have no idea why my shells are masking various signals, but it seems clear that it would be a good idea for the VM to initialize its signal mask explicitly rather than depending on the parent process to have it set sanely.

So I count this one as a VM bug. If someone better connected with the VM community would report it as such, I'd appreciate it.

Thanks for all the suggestions while I dug to the bottom of this one.

Regards,

-Martin

-- Best regards, Igor Stasenko.

2014/1/13 Martin McClure <martin@hand2mouse.com>

On 01/13/2014 10:47 AM, Igor Stasenko wrote:

...

Thanks, Martin.

Happy to help.

...

I added this to issue tracker: https://pharo.fogbugz.com/f/cases/12641/VM-signal-handling-on-nix

should be trivial to fix.

Thanks! Yes, I'd think this fix would be easy.

Just in case, note that I forwarded the message to vm-dev and that Eliot already fixed it in his svn cog branch for linux case. (I mean unmasking SIGALRM, not the absolute time problem) Regards,

-Martin

xscope is difficult to set up. I wonder if you have started another X server in the background and which xscope parameters you've used? So you may want to give a shoot to xtruss: http://www.chiark.greenend.org.uk/~sgtatham/xtruss/ It is used like strace. $ xtruss pharo Pharo.image When you move the mouse over the image window, you should get this type of output: --- MotionNotify(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=573, root-y=320, event-x=14, event-y=266, detail=Normal, state=0x0010, time=0x2D840279) --- MotionNotify(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=572, root-y=320, event-x=13, event-y=266, detail=Normal, state=0x0010, time=0x2D8402F5) --- MotionNotify(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=571, root-y=320, event-x=12, event-y=266, detail=Normal, state=0x0010, time=0x2D8402F5) When you enter focus in the Pharo window's area: --- EnterNotify(root=w#000000DC, event=w#03000001, child=w#03000002, mode=Normal, same-screen=True, focus=False, root-x=1153, root-y=705, event-x=582, event-y=614, detail=NonlinearVirtual, state=0x0010, time=0x2D894A60) When you make a click to bring the world menu, this is the event sequence: --- EnterNotify(root=w#000000DC, event=w#03000001, child=None, mode=Grab, same-screen=True, focus=False, root-x=1169, root-y=397, event-x=598, event-y=306, detail=Inferior, state=0x0110, time=0x2D8C440F) --- Expose(window=w#03000002, x=0, y=0, width=581, height=2, count=1) --- Expose(window=w#03000002, x=0, y=2, width=582, height=660, count=0) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=581, height=2, dst-x=0, dst-y=0, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=582, height=112, dst-x=0, dst-y=2, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=582, height=112, dst-x=0, dst-y=114, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=582, height=112, dst-x=0, dst-y=226, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=582, height=112, dst-x=0, dst-y=338, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=582, height=112, dst-x=0, dst-y=450, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=582, height=100, dst-x=0, dst-y=562, left-pad=0, format=ZPixmap, image-data=FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:FFEFEFEF:...) --- PropertyNotify(window=w#000000DC, atom=a#324, state=NewValue, time=0x2D8C4416) --- PropertyNotify(window=w#000000DC, atom=a#325, state=NewValue, time=0x2D8C4416) --- FocusIn(event=w#03000001, mode=Normal, detail=Nonlinear) SetInputFocus(focus=w#03000002, revert-to=None, time=CurrentTime) --- ButtonPress(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=1169, root-y=397, event-x=598, event-y=306, detail=1, state=0x0010, time=0x2D8C440F) --- PropertyNotify(window=w#000000DC, atom=a#324, state=NewValue, time=0x2D8C4417) --- PropertyNotify(window=w#000000DC, atom=a#325, state=NewValue, time=0x2D8C4417) --- PropertyNotify(window=w#000000DC, atom=a#239, state=NewValue, time=0x2D8C4418) --- PropertyNotify(window=w#000000DC, atom=a#239, state=NewValue, time=0x2D8C4418) --- PropertyNotify(window=w#000000DC, atom=a#324, state=NewValue, time=0x2D8C4419) --- PropertyNotify(window=w#000000DC, atom=a#325, state=NewValue, time=0x2D8C4419) --- PropertyNotify(window=w#000000DC, atom=a#239, state=NewValue, time=0x2D8C441B) --- PropertyNotify(window=w#000000DC, atom=a#239, state=NewValue, time=0x2D8C441B) --- PropertyNotify(window=w#000000DC, atom=a#282, state=NewValue, time=0x2D8C4423) --- FocusOut(event=w#03000002, mode=Normal, detail=Pointer) --- FocusOut(event=w#03000001, mode=Normal, detail=Inferior) --- FocusIn(event=w#03000002, mode=Normal, detail=Ancestor) PutImage(drawable=wp#03000002, gc=g#03000003, depth=24, width=155, height=267, dst-x=596, dst-y=275, left-pad=0, format=ZPixmap, image-data=FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:FFACACAC:...) --- ButtonRelease(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=1169, root-y=397, event-x=598, event-y=306, detail=1, state=0x0110, time=0x2D8C44F5) Are you getting similar output? Cheers, Hernán 2014/1/11 Martin McClure <martin@hand2mouse.com>

On 01/11/2014 12:17 AM, Hernán Morales Durand wrote:

...

Didn't tried myself but there is a tracing library for X called xscope. Is not included by default in most distros.

http://xorg.freedesktop.org/archive/individual/app/xscope-1.4.tar.gz

Don't bother with xev, does not capture clicks inside Pharo.

Well, I tried xscope. I'm not really familiar with the X protocol, but what I see looks reasonable. Pharo is getting notified of events, and is not responding, except when the mouse enters, then it requests focus. And Alt-. generates output on stdout, so these events are clearly getting to Pharo, just not producing any X output.

Anything else I should be looking for?

Regards,

-Martin

2014/1/12 Martin McClure <martin@hand2mouse.com>

On 01/12/2014 07:46 AM, Hernán Morales Durand wrote:

...

xscope is difficult to set up. I wonder if you have started another X server in the background and which xscope parameters you've used?

Thanks for the detailed reply!

Xscope seemed reasonably easy to set up.

./xscope -i1

then set DISPLAY to :1 before launching Pharo.

I don't think there's another X server involved -- the Pharo window is displayed on the correct screen, with the correct initial contents, and events are being delivered to it (as evidenced by it responding to Alt-. through output to the terminal) and the mouse pointer is the proper Pharo shape. But no other visual indication that it knows I'm trying to interact with it.

The fact that I'm accessing to X remotely through XRDP and Xvnc could make my set up more difficult. Nice to hear it is easier for local display.

...

So you may want to give a shoot to xtruss: http://www.chiark.greenend.org.uk/~sgtatham/xtruss/

It is used like strace.

$ xtruss pharo Pharo.image

OK, tried this. It is indeed easier.

...

When you move the mouse over the image window, you should get this type of output:

--- MotionNotify(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=573, root-y=320, event-x=14, event-y=266, detail=Normal, state=0x0010, time=0x2D840279) --- MotionNotify(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=572, root-y=320, event-x=13, event-y=266, detail=Normal, state=0x0010, time=0x2D8402F5) --- MotionNotify(root=w#000000DC, event=w#03000002, child=None, same-screen=True, root-x=571, root-y=320, event-x=12, event-y=266, detail=Normal, state=0x0010, time=0x2D8402F5)

Yes, I'm seeing these.

...

When you enter focus in the Pharo window's area:

--- EnterNotify(root=w#000000DC, event=w#03000001, child=w#03000002, mode=Normal, same-screen=True, focus=False, root-x=1153, root-y=705, event-x=582, event-y=614, detail=NonlinearVirtual, state=0x0010, time=0x2D894A60)

When you make a click to bring the world menu, this is the event sequence:

Here's the sequence I get, after all the initial setup. Moving the mouse into the Pharo window, click, release, and move the mouse out of the window. Note that I held the mouse button down for a bit -- it wasn't a quick click.

--- FocusOut(event=w#05600001, mode=Normal, detail=Inferior) --- FocusIn(event=w#05600002, mode=Normal, detail=Ancestor) --- PropertyNotify(window=w#0000028E, atom=a#360, state=NewValue, time=0x07C13BCF) --- PropertyNotify(window=w#0000028E, atom=a#360, state=NewValue, time=0x07C13BCF) --- EnterNotify(root=w#0000028E, event=w#05600001, child=w#05600002, mode=Normal, same-screen=True, focus=False, root-x=1465, root-y=684, event-x=263, event-y=661, detail=NonlinearVirtual, state=0x0000, time=0x07C141F6) --- MotionNotify(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1465, root-y=684, event-x=263, event-y=661, detail=Normal, state=0x0000, time=0x07C141F6) --- MotionNotify(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1465, root-y=683, event-x=263, event-y=660, detail=Normal, state=0x0000, time=0x07C1422D) --- MotionNotify(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1465, root-y=682, event-x=263, event-y=659, detail=Normal, state=0x0000, time=0x07C14266) --- MotionNotify(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1465, root-y=683, event-x=263, event-y=660, detail=Normal, state=0x0000, time=0x07C1453E) --- MotionNotify(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1466, root-y=683, event-x=264, event-y=660, detail=Normal, state=0x0000, time=0x07C14865) --- ButtonPress(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1466, root-y=683, event-x=264, event-y=660, detail=1, state=0x0000, time=0x07C148CE) --- ButtonRelease(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1466, root-y=683, event-x=264, event-y=660, detail=1, state=0x0100, time=0x07C1514D) --- MotionNotify(root=w#0000028E, event=w#05600002, child=None, same-screen=True, root-x=1466, root-y=684, event-x=264, event-y=661, detail=Normal, state=0x0000, time=0x07C153C5) --- FocusOut(event=w#05600002, mode=Normal, detail=Nonlinear) --- FocusOut(event=w#05600001, mode=Normal, detail=NonlinearVirtual)

It seems you're missing XPutImage() calls. This is low level but to check if Xlib is initializing the image structures you can comment out the stub /* if (!XInitImage(stImage)) fprintf(stderr, "XInitImage failed (but we don't care)\n"); */ in the frightening https://github.com/pharo-project/pharo-vm/blob/master/platforms/unix/vm-disp... and recompile? Does Gentoo provide a README for updates? Regards, Hernán

but there is something wrong because I have the same version and it works… grrrr…. I hate incompatibility version problems :( On 12 Jan 2014, at 15:55, Sebastian Sastre <sebastian@flowingconcept.com> wrote:

Ubuntu 12.04.3 LTS

Until it's patched, can you tell me how do I load manually the things it should load using zeroconf?

On Jan 12, 2014, at 8:32 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

and which ubuntu are you talking about?

Esteban

On 11 Jan 2014, at 02:54, Sebastian Sastre <sebastian@flowingconcept.com> wrote:

...

Hi guys,

I'm new to ZeroConf, sounds really great.

In OS X worked fine for me but on an ubuntu machine it said this:

--2014-01-10 23:48:30-- http://get.pharo.org/30+vm Resolving get.pharo.org (get.pharo.org)... 128.93.162.72 Connecting to get.pharo.org (get.pharo.org)|128.93.162.72|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2713 (2.6K) [text/html] Saving to: `STDOUT'

100%[========================================================================================>] 2,713 --.-K/s in 0s

2014-01-10 23:48:30 (331 MB/s) - written to stdout [2713/2713]

Downloading the latest 30 Image: http://files.pharo.org/image/30/latest.zip mktemp: failed to create directory via template `image.XXXXX': Permission denied

doing sudo or not has the same effect

Any idea of what to do?

sebastian

o/

On 13 Jan 2014, at 02:01, Michael J. Forster <mike@sharedlogic.ca> wrote:

On 14-01-12 09:13 AM, Esteban Lorenzano wrote:

...

but there is something wrong because I have the same version and it works… grrrr…. I hate incompatibility version problems :(

[...]

Hi Esteban,

The problem is that the call to "mktemp ... 'image.XXXXX'" is incorrect. mktemp(3) requires six Xs in the directory name template, but only five Xs are used by the zeroconf script. That it works on some platforms is misleading--those platforms aren't implementing mktemp(3) exactly. To make it work on all platforms, the mktemp(3) call must be as specified in the man page.

On my machine, there is no mention of a minimal number: MKTEMP(1) BSD General Commands Manual MKTEMP(1) NAME mktemp -- make temporary file name (unique) SYNOPSIS mktemp [-d] [-q] [-t prefix] [-u] template ... mktemp [-d] [-q] [-u] -t prefix DESCRIPTION The mktemp utility takes each of the given file name templates and overwrites a portion of it to create a file name. This file name is unique and suitable for use by the application. The template may be any file name with some number of `Xs' appended to it, for example /tmp/temp.XXXX. The trailing `Xs' are replaced with the current process number and/or a unique letter combination. The number of unique file names mktemp can return depends on the number of `Xs' provided; six `Xs' will result in mktemp selecting 1 of 56800235584 (62 ** 6) possible file names. It might be needed for portability, but who says "those platforms aren't implementing mktemp(3) exactly", against which spec ?

Best regards,

Mike

-- Michael J. Forster, B.Sc. (Hons.), B.Sc. COO, Programmer Shared Logic Inc.

On 13 Jan 2014, at 13:04, Michael J. Forster <mike@sharedlogic.ca> wrote:

On 14-01-13 12:27 AM, Sven Van Caekenberghe wrote: [...]

...

It might be needed for portability, but who says "those platforms aren't implementing mktemp(3) exactly", against which spec ?

Hi Sven,

It's the library function mktemp(3), not the command mktemp(1), that specifies the template length, and it conforms to both BSD and POSIX:

http://man7.org/linux/man-pages/man3/mktemp.3.html http://www.openbsd.org/cgi-bin/man.cgi?sektion=3&query=mktemp

Accordingly, "mktemp -d foo.XXXXXX" should work on all POSIX/BSD platforms, and it does on my various FreeBSD, OpenBSD, Slackware, and Ubuntu boxes. Likewise, "mktemp -d foo.XXXXX" _could_ fail, and it does on three of my boxes.

OK, than we better change the script. Camillo, where do we change this best ?

Cheers,

Mike

-- Michael J. Forster, B.Sc. (Hons.), B.Sc. COO, Programmer Shared Logic Inc.