On Thu, Mar 9, 2017 at 11:09 AM Sven Van Caekenberghe <sven@stfx.eu> wrote:

No it is not a Spotter bug, Spotter uses multi threading very well. So well you did not see it ;-)

UI Monticello actions do indeed block the main UI thread, like almost all other tool actions. That is not necessarily bad, you want to wait for them. Monticello HTTP operations do have proper timeouts on networking.

Frankly I never had an issue with Spotter and my internet connection used to be abysmal, top 200kb/s if I was lucky , sometime dropping down to 10kb/s. Still happen at times but it has been fixed and now I get a usual ��1mb/s and I feel like I am in heaven.

I use monticello and Spotter all the time, Spotter never went cookoo on me.��

Monticello on the other hand has this bad habit when one makes a local commit, I am using only git with pharo for ages now via filetree, of contacting servers which to me at least makes zero sense , after it was explained to me why it became bellow zero sense.�� So basically if the connection is dropped , Monticello fails which is bad , but if connection becomes slow, Monticello freezes which is much worse.��

And to be Frank once more, I have stopped (not completely I still using it part time) using Pharo since I failed to integrate it to my workflow and I am back coding in Python for reasons that are technical and personal. Nonetheless I want to see Pharo succeed and for doing so we live in a time that simplicity of code design is a huge deal to a world of ever evolving more complex code.��

So my object is simple: Do not make Pharo code more complex , please.��

Of course I can be blamed for wanting to turn Pharo into Python, but I do not mind such blame.��