On Thu, Mar 9, 2017 at 11:09 AM Sven Van Caekenberghe <[email protected]> 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.
