May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: [Esug-list] Re: Talking to Steve Jobs about Scratch.

by John M McIntosh

Radoslav asked yesterday about progress on the issue of Scratch on the iPad, so it's timely to give everyone an update. I did ask Apple today for an update on the situation and was told: "We're still pondering the issue" So I remain positive and wait. On 2010-05-16, at 3:34 AM, radoslav hodnicak wrote: > > Was there any conclusion to these talks? > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Alexandre Bergel

Mariano, Stef, Adrian, I would like to focus the Pharo sprint this week end on helping Pharo 1.1. In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? Cheers, Alexandre On 16 May 2010, at 18:26, Alexandre Bergel wrote: >> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge > > > I will go over some this week. > > Alexandre > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

[Pharo-project] [Bug] Refactoring does not respect formatting

by Sean P. DeNigris

http://code.google.com/p/pharo/issues/detail?id=2439 We are currently working on version 1.1, so please verify your issue with the latest 1.1 Unstable version before reporting it - we improved a lot the system. Pharo image: Pharo-core Pharo core version: 1.1 #11364 Virtual machine used: Squeak 4.2.4beta1U (mac) Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: 1. Start with clean image 2. Install OB with: 3. Select line "(MCPackage named: 'ProjectNotNamedForRepo') unload." from following method: testFromSqueakSourse "" ImageSetup new installProject: 'ProjectNotNamedForRepo' fromRepository: 'ProjectNamedForRepo'. (MCPackage named: 'ProjectNotNamedForRepo') unload. SystemOrganization removeCategory: 'ProjectNotNamedForRepo'. 4. Extract method via refactor source->extract method 5. Result does not respect whitespace and formatting: testFromSqueakSourse "" ImageSetup new installProject: 'ProjectNotNamedForRepo' fromRepository: 'ProjectNamedForRepo'. self projectShouldBeInstalled. self shouldnt: [ Smalltalk at: #ClassInProjectNotNamedForRepo ] raise: Error. self extracted. SystemOrganization removeCategory: 'ProjectNotNamedForRepo' Issue was discussed in 9/09 at: http://forum.world.st/Is-there-a-way-to-use-rename- refactor-while-preserving-whitespace-formatting-in-refactored-methods- td1302148.html#a1302148 Ideas were: * write your own formatter that formats as you like * implement Gwenael's changes to the RBParser and AST, which preserve code formatting * use tools implemented in OB-Regex Sean -- View this message in context: http://forum.world.st/Bug-Refactoring-does-not-respect-formatting-tp2220567… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Alexandre Bergel

> Now we will not open 1.2 right now because we can just take the time to do 1.1 nice and there are plenty of stuff to do > around 1.1 and to prepare in the calm 1.1 Good decision. We are not racing, but producing quality. Alexandre

May 17, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Alexandre Bergel

> Mariano: what is the state of building a dev image from > the core for 1.1.? Last time I tried the ConfigurationOfPharo with 1.1. > I run into the condense changes problem - which I thing was fixed now. You can easily build a Pharo1.1 from a core. No warning and no deprecation. It just takes time. Moose loads in it. Cheers, Alexandre

May 17, 2010

Re: [Pharo-project] Decoupling Shout and Styler

by Mariano Martinez Peck

I agree, but in such case let me know so that I can update the metacello conf ;) On Mon, May 17, 2010 at 5:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Yes, that makes sende. > > Another possibility would be to use the RB or PetitParser (this is > what I do in Helvetia) parser instead. > > Lukas > > On Monday, May 17, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > can be a good idea. > > > > Stef > > > > On May 17, 2010, at 5:21 PM, Fernando olivero wrote: > > > >> I would like to decouple the Styler Object ( For example SHTextStyler) > from the Shout packages. > >> > >> Since Shout purpose it to add: 'Syntax Highlighting that updates after > each key stroke so that the highlighting remains correct during the editing > of a method'. > >> > >> I think it would be beneficial to style any piece of text, > independently from the editing of a method. > >> > >> For example, when working on the NewTextMorph i do not need any > functionality of the TextMorphForShout or TextMorphForShoutEditor classes, > but only the Styler related classes. And in its current state, these two are > coupled in the same package. > >> > >> I propose Shout could be spitted into 2 packages, that better reflect > the classes intentions. > >> > >> 1. Code Styler: which would include Shout-Parsing, and Shout-Styling. > >> > >> 2. TextMorphShout: Shout-TextSupport, Shout-Windows. > >> > >> What do you think? > >> > >> Fernando > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] condensing changes file

by Mariano Martinez Peck

Hi Laurent: I suffer that too. Actually, much more than everybody as I build the dev images. Stef: condeseChanges is automatically called after installing ConfiguratioOfPharo as the default grouo loads the DEV group which includes all the dev tools an ImageForDevelopers. This, does some cleanUps included condeseChanges. In the past, there was no poblem to do it even if it was not strictly needed. Now, it's different. So, my proposal is: remove the condenseChanges from the cleanUps of ImageForDevelopers, and I add it to my post bash scripts when building the dev image. Do you agree? Cheers Mariano 2010/5/17 laurent laffont <laurent.laffont(a)gmail.com> > It has just finished :) > > Laurent > > > > On Mon, May 17, 2010 at 10:40 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> I'm starting to wonder if this condensing will ever finish ! >> >> Laurent >> >> >> On Mon, May 17, 2010 at 10:37 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> don't bother :) >>> >>> It is taking long but fully working. We will condense it for may be beta >>> or rc depending on the size. >>> >>> Stef >>> >>> >>> > Hi, >>> > >>> > I've just started playing with ConfigurationOfPharo 1.1 and I'm >>> currently experiencing the looooong "condensing changes file". I have >>> currently troubles trying to follow all the traffic of this mailing-list :) >>> but is there some work to make it far less longer ? or optional ? >>> > >>> > Laurent Laffont >>> > >>> > http://pharocasts.blogspot.com/ >>> > http://magaloma.blogspot.com/ >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by Nicolas Cellier

The meaning of my message was don't do it for squeak, but do it for yourself. I don't doubt the mailing list is a mine of information, but even in the best mine you need to dig a lot before extracting the gold nuggets. Of course, I've got no right to control your agenda, who am I ? You can consider the subject close, and I won't find your attitude shocking at all. But next time, consider writing a rationale for your own, it will increase quality of Pharo decision process. Best regards Nicolas 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > nicolas > > all the information is in the metacello mailing-list Â and we already posted many mails on that topics in this mailing list. > I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood > in a nutshell > > one repo per version Pharo1.0, Pharo11 ... MetacelloRepository > Â Â Â Â containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. > > a project > Â Â Â Â contain its single/or whatever configurationOfMyProject > Â Â Â Â people publish the config to their repository and if they want they push from their repository to the version repository > Â Â Â Â a version that they freeze (may be using tags) > > For Pharo core or pharo packages that we maintain we want to maintain it as a project. > with its own repository and packages. > > Then we have a server that load configuration and barks if something wrong happen. And may be we kick out > the configurationofXXX from MetacelloRepositories > >> Steph, >> I understand how boring it may seem: >> - you already discussed the subject over and over >> - you already took decisions >> and now we come later with new proposals, and ask you to reconsider >> the work again... > > more than that. :) > It looks like if we did not talk or think about what we are doing. > > >> As for the Preferences/Settings, Pharo choices are probably very weel thought. >> >> However, every solution will come with trade offs, and it would be >> good to have a rationale justifying the choices you made, and perhaps >> more importantly justifying why you did abandon some solutions, >> because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... >> and find different answers in different context. Note that Squeak >> evolutions might have influence on Pharo too, and it's part of the >> context... >> >> I strongly encourage you to establish your rationale on Pharo grounds >> - independently of Andreas proposals, put it on the Pharo wiki and let >> us know the URL. >> >> You also know that Squeak goals are not exactly those of Pharo w.r.t. >> backward compatibility, so Squeak can't just blindly replicate Pharo >> solutions without a rationale. >> >> The merit of Andreas proposal is to try and establish such a >> rationale. Without it, we're bound to repeat discussions again and >> again, > > So to fix the problem consider that as our proposal. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010

Re: [Pharo-project] condensing changes file

by laurent laffont

It has just finished :) Laurent On Mon, May 17, 2010 at 10:40 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > I'm starting to wonder if this condensing will ever finish ! > > Laurent > > > On Mon, May 17, 2010 at 10:37 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> don't bother :) >> >> It is taking long but fully working. We will condense it for may be beta >> or rc depending on the size. >> >> Stef >> >> >> > Hi, >> > >> > I've just started playing with ConfigurationOfPharo 1.1 and I'm >> currently experiencing the looooong "condensing changes file". I have >> currently troubles trying to follow all the traffic of this mailing-list :) >> but is there some work to make it far less longer ? or optional ? >> > >> > Laurent Laffont >> > >> > http://pharocasts.blogspot.com/ >> > http://magaloma.blogspot.com/ >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

May 17, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Eliot Miranda

On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Ma > > > > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also > uses bits 1 through 4 > > bit 0: 1 => open full screen, 0 => open using width & > height > > bit 1: 1 => image floats are in little-endian format, 0=> > image floats are in big-endian format > > bit 2: 1 => Process's 4th inst var (after myList) is > threadId to be used by the VM for overlapped calls > > > > bit 3: 1 => set the flag bit on methods that the VM will > only interpret (because they're considered too big to JIT) > > bit 4: 1 => preempting a process does not put it to the > back of its run queue > > > I was not clear how to read > bit 3: 1 > this information is not in the compiledMethods? > For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods. It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method. But I still need to know whether my threshold is affecting frequently used methods. So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals. Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient. The effect is that the JIT will set the flag bit on any method it refuses to JIT. I can then browse these in the image and decide whether any are important and adjust the threshold accordingly. Arguably this should be a command line argument, not an image header flag. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 17, 2010