>> Göran, >> >> I think before we adopt anything, it should have the "left running" scenario >> addressed in some way. Pharo is supposed to be robust. > > That mean losing the silent failures, and doing so in a way that the new > > information does not bring the system to its knees. > > First - I did not bring this up, so feel free to fix any flaws you see/find > :). The code base is very small. > > Secondly - my impression of Pharo so far is not really "robust", and don't > get me wrong here - it is not criticism, but my feeling every time I have > used Pharo is that it is smack full of new stuff (completion, OB browsers etc > etc) which quite often seems to break and also makes it painful to develop on > my old trusty kinda slow Dell laptop.
Where are your feedback? When did you mention that? And yes the system should change because I can list a lot of skeletons and paper tape that make the system believe it is working but is brittle. > It seems to me that "progress" (new shiny stuff!) has been put in favor of > robustness, Apparently all the bugs we close do not count? Come on goran... > which probably is why Pharo is attractive to a lot of people. Perhaps Pharo > changed focus for next release? > > Sorry for that little rant, don't really "mean" anything with it, just > curious to see if I am the only one with this feeling. >> On Windows, OutputDebugString() is probably good enough. Since I am doing >> everything I can to ditch said platform, I might not be the best person to >> ask. Certainly, it is where I would go for a live view, and a file-based >> log would then cover everything else - I think. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
