June 2012 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] What i would like to have instead of progress bar

by Fernando Olivero

I agree, i've implemented in Gaucho a WaitingShape. Which resembles the ones found in the web players (the lines in different angles forming a circle, that rotate an alpha value to denote passage of time). w := WaitingShape on: self. w start. ... w stop. I've used it when importing stored sessions. Fernando On Fri, Jun 1, 2012 at 2:08 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > ah, yeah.. one last thing: > - do not show the progress, in situations when there is no timely > advance is possible, > like waiting for server response: just put a notification line.. but > no stupid empty progress line > which serves no purpose > > > > -- > Best regards, > Igor Stasenko. >

June 1, 2012

Re: [Pharo-project] Pharocasts ... updating and screencasts wanted

by Tudor Girba

Hi, Several short Moose demos are available here (including Mondrian and Glamour): http://www.humane-assessment.com/resources/demos I would be happy to get them on pharocasts.com as well. Cheers, Doru On 31 May 2012, at 10:22, Torsten Bergmann wrote: > Hi all, > > http://www.pharocasts.com/ is a little bit outdated > since it still shows Pharo 1.3 instead of 1.4. > Download linke also goes to 1.3. > > Would also be nice if someone can record some new > screencasts on things like > > - Nautilus > - Roassal > - Zinc/Zodiac > - New Fuel Release with visual debugging support > - Ring > - FileSystem > - NativeBoost > - Nagare logging library > - Artefact PDF library > - Athens > - Working with SS3 > - ... > > and send them to Laurent. > > Any takers? > > Thx > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

June 1, 2012

[Pharo-project] Grid Morph

by HernÃ¡n Morales Durand

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 -- HernÃ¡n Morales Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

June 1, 2012

Re: [Pharo-project] Log framework

by Santiago Bragagnolo

Ok I' think i just need to add test and then is already usable. ( If you think i must add anything, just say it :)* * ) About last changes and configuration: The last add is pragma support: We have 2 pragmas configuration: <logConfiguration> That indicates the class method* *related know how to manage de log configuration There is support to usit this way: ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- configurationOfLog <logConfiguration> ^ [ :builder | builder forClass:LogTestObject useLevel:#info showingLogAs: ('%pih | %tstmp | %tag #%class >> %selector [%log]' asPatternFormatter) into: Transcript asLogWriter holdLogInstances:true. ]. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- and this way ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- configurationOfLog: builder <logConfiguration> builder forClass:LogTestObject useLevel:#info showingLogAs: ('%pih | %tstmp | %tag #%class >> %selector [%log]' asPatternFormatter) into: Transcript asLogWriter holdLogInstances:true. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The other pragma is <logConfigurationAs:#aSymbol > This pragma says 'hey, forme use the #aSymbol configuration!', such as #default. then you can go to LogConfiguration >> configuration class method and add symbols with named configurations and relate with explicit classes with a simple pragma :) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- For other side, the manage of the 'if-the-class-has-not-configuration' is the same, search for the package configuration (that should be added in LogConfiguration >> configuration class method ), and if is not a package configuration, then go for the #default configuration. Tomorrow ill be adding tests and making a post on my blog with all the functionalities: Writers available (Memory, File, Stdout, Transcript, CompositeWriter) Formatters available (Pattern based -the one of the sample- SimpleFormatter and CustomFormatter) Filters available (the one who says how to decides if the log must be showed or just skiped -- CategoryFilter and LevelFilter. ) Holder ( an object which stores LogEntity objects - an object very much richier than the string stored for MemoryWriter) And ill add to the post how to write nice configurations with the existing code and, of course, how to add functionality in the way i thought the framework. *Again, the idea of this framework is to be used for all and have just one logger, so, please, if any one think i must add or change something, share it here. And if any wants to get his hands on the code the same, just say it. *

June 1, 2012