- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about cursor: an interesting blog post

by Frank Shearar

On 1 June 2012 13:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> usly mentioned)) that are the abomination. >>>> >>> in smalltalk code & data is the same - it just objects. >>> why you think "changing your brain" should stop you from doing something else? >>> When you coding in browser, you alsos changing systems brain. >> >> Yes, there is no difference between loading a package and entering the >> same code through the browser... except that in the former case >> (without the abominatory modal progress dialogs stopping your) you >> might ALSO be adding code, or be running something, or or or. >> >> So you start loading some package. That package sadly has a bug in its >> replacement of Object >> #printString which accidentally kills the >> image. You're busy debugging something while that package loads. >> You're inspecting something. You inspect it again... and your image >> dies! You know you weren't doing anything crazy, so this time it's not >> your fault. But was it a VM bug? Some weird edge case in the base >> image noone's run into before? Monticello? The package being loaded? > > that can even happen without monticello being blocking... > >> While that package is loading - while you are busy hacking away - the >> image is changing under your feet. That is _never_ safe. Now, in happy >> land, we'd have sandboxes and isolation and atomic loading and all >> sorts of fun stuff so, in happy land, this wouldn't be a problem. But >> _today_ it would be a problem. > > sure it could be, but let's say we make a setting. Cause most of the time > I know exactly what I load in Monticello and still wan to be able to work > on something else. > > It's like having a #become: around, nobody stops you from doing silly > things with it :). At least with #become: you have to actually type out the letters: you KNOW you're doing something dangerous. > - Most of the UI stuff should be written non-blocking, adding blocking support > Â on top is mostly easy. (in MC the only thing that makes sense to be run > Â in blocking mode is indeed loading, but even that necessarily) I should perhaps restate that I _agree_ with Igor that I don't think the UI should ever block (except maybe at shutdown, but the user doesn't care at that point anyway). I just wanted to highlight that changing the system while a large amount of changing the system is already happening is asking for trouble. > - add Options/Settings (maybe with some warnings) so everybody is happy Well, too many settings = nobody happy, because noone's system works the same as anyone else's! frank

June 1, 2012

Re: [Pharo-project] light-table: live programming for python

by Frank Shearar

On 1 June 2012 13:29, Camillo Bruni <camillobruni(a)gmail.com> wrote: > impressive how much support they got: > > http://www.kickstarter.com/projects/ibdknox/light-table > > not much missing in our system, is it? No, definitely not. Most of it is automatically pulling up contextual info (like if you're implementing #myFoo on some object, bring up all the implementors in some no-clicks-needed window (possibly with some classes preferentially highlighted - sub/superclasses and other classes that satisfy similar protocols) and the senders of same in another (with suitable highlighting of the actual send site). The more clever de-abstraction stuff we can get quite easily by manipulating ASTs. (In a Smalltalk-based system, I'd half expect us to keep ASTs attached to method on which the programmer worked.) frank

June 1, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Camillo Bruni

>>> usly mentioned)) that are the abomination. >>> >> in smalltalk code & data is the same - it just objects. >> why you think "changing your brain" should stop you from doing something else? >> When you coding in browser, you alsos changing systems brain. > > Yes, there is no difference between loading a package and entering the > same code through the browser... except that in the former case > (without the abominatory modal progress dialogs stopping your) you > might ALSO be adding code, or be running something, or or or. > > So you start loading some package. That package sadly has a bug in its > replacement of Object >> #printString which accidentally kills the > image. You're busy debugging something while that package loads. > You're inspecting something. You inspect it again... and your image > dies! You know you weren't doing anything crazy, so this time it's not > your fault. But was it a VM bug? Some weird edge case in the base > image noone's run into before? Monticello? The package being loaded? that can even happen without monticello being blocking... > While that package is loading - while you are busy hacking away - the > image is changing under your feet. That is _never_ safe. Now, in happy > land, we'd have sandboxes and isolation and atomic loading and all > sorts of fun stuff so, in happy land, this wouldn't be a problem. But > _today_ it would be a problem. sure it could be, but let's say we make a setting. Cause most of the time I know exactly what I load in Monticello and still wan to be able to work on something else. It's like having a #become: around, nobody stops you from doing silly things with it :). - Most of the UI stuff should be written non-blocking, adding blocking support on top is mostly easy. (in MC the only thing that makes sense to be run in blocking mode is indeed loading, but even that necessarily) - add Options/Settings (maybe with some warnings) so everybody is happy

June 1, 2012

[Pharo-project] light-table: live programming for python

by Camillo Bruni

impressive how much support they got: http://www.kickstarter.com/projects/ibdknox/light-table not much missing in our system, is it?

June 1, 2012

Re: [Pharo-project] Grid Morph

by Ben Coman

HernÃ¡n Morales Durand wrote: > Hi all, > > If it's useful for someone, I've adapted a pretty basic grid morph to Pharo > 1.3. To test: > > GridMorph columnNamesExample. > GridMorph morphInCellExample. > GridMorph columnNamesExample. > GridMorph blocksExample. > > download from http://ss3.gemstone.com/ss/BioSmalltalk/SGrid-hfm.3.mcz > > cheers, > > HernÃ¡n > > That looks really good. I think I'll definitely find a use for it. Is there some way (and maybe an example :) ) to push edits to a cell back into a model ? btw I got it working in 1.4 with the following change: From... CellMorph class >> defaultTextContentsMorph ^CellTextMorph new. To.... CellMorph class >> defaultTextContentsMorph ^ CellTextMorph new setDefaultContentsIfNil This is required since [TextMorph new text] in: 1.3 is a Text for 'abc' 1.4 is nil due to the following change... TextMorph>>relaseCachedState (1.3 BG 11/20/2004) super releaseCachedState. self releaseParagraph; paragraph. TextMorph>>releaseCachedState (1.4 hfm 1/11/2011) super releaseCachedState. self releaseParagraph where previously #setDefaultContentsIfNil was being called from #paragraph. cheers, Ben

June 1, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Frank Shearar

On 1 June 2012 12:25, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 1 June 2012 10:48, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 1 June 2012 00:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> I am completely agree with this post. >>> A showWhile: pattern takes its roots from modal processing, >>> when user is blocked and have to wait till something will give control >>> back to him. >>> This is inacceptable and should be exterminated. It was excusable for 80's , >>> partly excusable in 90's .. and completely inexcusable past 0's. >>> >>> A progress bar is another abomination of same kind. >>> Look at download bars in your internet browser: do they center it in a >>> window on top of everything and preventing you from doing anything? or >>> maybe they just sit in the corner and not interfere? >>> This is a road where we should put our steps on. >> >> "No modes" is something towards which we should strive. However, don't >> forget that downloading a file in a web browser is completely >> different to loading a package into an image: the former changes no >> state, and the latter can do arbitrary things to the image itself. >> >> We need _some_ kind of notification, and in fact Chrome _does_ have a >> progress bar... but it's a little pie-slice thing down on the bottom >> of the screen. I can see it, but it doesn't stop me carrying on >> working. So I'd say it's not so much that progress bars are an >> abomination, but rather progress bars that stop you from working (like >> Monticello's bars (but remember the "you're changing your own brain" >> warning previously mentioned)) that are the abomination. >> > in smalltalk code & data is the same - it just objects. > why you think "changing your brain" should stop you from doing something else? > When you coding in browser, you alsos changing systems brain. Yes, there is no difference between loading a package and entering the same code through the browser... except that in the former case (without the abominatory modal progress dialogs stopping your) you might ALSO be adding code, or be running something, or or or. So you start loading some package. That package sadly has a bug in its replacement of Object >> #printString which accidentally kills the image. You're busy debugging something while that package loads. You're inspecting something. You inspect it again... and your image dies! You know you weren't doing anything crazy, so this time it's not your fault. But was it a VM bug? Some weird edge case in the base image noone's run into before? Monticello? The package being loaded? While that package is loading - while you are busy hacking away - the image is changing under your feet. That is _never_ safe. Now, in happy land, we'd have sandboxes and isolation and atomic loading and all sorts of fun stuff so, in happy land, this wouldn't be a problem. But _today_ it would be a problem. frank >> frank >> >>> We should remember once and for eternity: staying responsible to user >>> input is most important task for a system. The rest doesn't matters. >>> >>> >>> On 31 May 2012 21:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&… >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. >

June 1, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Igor Stasenko

On 1 June 2012 10:48, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 1 June 2012 00:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >> I am completely agree with this post. >> A showWhile: pattern takes its roots from modal processing, >> when user is blocked and have to wait till something will give control >> back to him. >> This is inacceptable and should be exterminated. It was excusable for 80's , >> partly excusable in 90's .. and completely inexcusable past 0's. >> >> A progress bar is another abomination of same kind. >> Look at download bars in your internet browser: do they center it in a >> window on top of everything and preventing you from doing anything? or >> maybe they just sit in the corner and not interfere? >> This is a road where we should put our steps on. > > "No modes" is something towards which we should strive. However, don't > forget that downloading a file in a web browser is completely > different to loading a package into an image: the former changes no > state, and the latter can do arbitrary things to the image itself. > > We need _some_ kind of notification, and in fact Chrome _does_ have a > progress bar... but it's a little pie-slice thing down on the bottom > of the screen. I can see it, but it doesn't stop me carrying on > working. So I'd say it's not so much that progress bars are an > abomination, but rather progress bars that stop you from working (like > Monticello's bars (but remember the "you're changing your own brain" > warning previously mentioned)) that are the abomination. > in smalltalk code & data is the same - it just objects. why you think "changing your brain" should stop you from doing something else? When you coding in browser, you alsos changing systems brain. > frank > >> We should remember once and for eternity: staying responsible to user >> input is most important task for a system. The rest doesn't matters. >> >> >> On 31 May 2012 21:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&… >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

June 1, 2012

[Pharo-project] Smalltalk position at Douai, France

by Luc Fabresse

Hello, Please find below a description for a position in our Smalltalk team. ** 12-months Software Research Engineer Position for Service Robotics ** Context: The RoboShop Project The RoboShop project aims at providing the foundations for using robots as media in the customer relationship management (CRM). This work should provide a hardware and software platform to build experiments about robotic usage scenario related to shopping. This platform must be complete and used in a public demonstration at the end of the project by october 2013. Description The work to be carried out aims at providing a robust infrastructure (hardware and soft- ware) for robotic experiments related to services. The hardware part will mainly rely on an existing robotic platform which already integrate the most common sensors and actuators (Laser, Vision, infra-red, ...). The contribution will consist in integrating some new sensors. The main effort is therefore on the software part. Technologically it will imply to work with ROS (Robot Operating System) [ros08] and Pharo [pha08] as well as some robotic tools and algorithms: simulators (Gazebo, Morse), SLAM, ... [pha08] Pharo: a clean, innovative, open-source smalltalk-inspired environment. http://www.pharo-project.org/, 2008. [ros08] Ros: Robot operating system. http://www.ros.org/, 2008. Expected skills We are looking for a software developer with one or more of the following skills: - Robotics middleware (ROS, ...) - Control architecture for robotic systems - Object-oriented programming - Dynamic languages - Agile methodologies (XP, TDD, ...) Administrative information - Duration: 12 months - Starting date: 2012 October - Salary: 2 887 euros / month before taxes - Location: Douai (Lille area), France (no remote job possible) - Working Language: English or French Application Send a CV by mail to: Noury Bouraqadi (noury.bouraqadi(a)mines-douai.fr) Luc Fabresse (luc.fabresse(a)mines-douai.fr) Luc

June 1, 2012

[Pharo-project] ClassBoxes... bitrotted, or usable?

by Frank Shearar

I mused with a colleague about how I'd like to see "lexically scoped monkey patching", and he pointed me to some guys that want to add that to Ruby (http://timelessrepo.com/refinements-in-ruby) Note the inspiration for their work: ClassBoxes! (http://scg.unibe.ch/research/classboxes) I remember reading the paper years ago, and started working through it again now. Something that's not clear to me is this: does ClassBoxes require VM-side changes? (Because it changes the method lookup, after all, searching packages for methods before working up the inheritance tree.) If so, how invasive are they? If not, do we have a ball-park estimate of how much work it would be to update ClassBoxes to a more recent Squeak/Pharo? I'm more than happy to do the dogwork. I'd just like to know whether I'm signing up for months of work or not. Thanks! frank

June 1, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Frank Shearar

On 1 June 2012 00:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > I am completely agree with this post. > A showWhile: pattern takes its roots from modal processing, > when user is blocked and have to wait till something will give control > back to him. > This is inacceptable and should be exterminated. It was excusable for 80's , > partly excusable in 90's .. and completely inexcusable past 0's. > > A progress bar is another abomination of same kind. > Look at download bars in your internet browser: do they center it in a > window on top of everything and preventing you from doing anything? or > maybe they just sit in the corner and not interfere? > This is a road where we should put our steps on. "No modes" is something towards which we should strive. However, don't forget that downloading a file in a web browser is completely different to loading a package into an image: the former changes no state, and the latter can do arbitrary things to the image itself. We need _some_ kind of notification, and in fact Chrome _does_ have a progress bar... but it's a little pie-slice thing down on the bottom of the screen. I can see it, but it doesn't stop me carrying on working. So I'd say it's not so much that progress bars are an abomination, but rather progress bars that stop you from working (like Monticello's bars (but remember the "you're changing your own brain" warning previously mentioned)) that are the abomination. frank > We should remember once and for eternity: staying responsible to user > input is most important task for a system. The rest doesn't matters. > > > On 31 May 2012 21:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&… > > > > -- > Best regards, > Igor Stasenko. >

June 1, 2012