- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

2010/5/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > 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. Eliot, i beg you, instead of using an obscure flags in image header, just add (or reserve unused) splObject indice and read/write whatever you want from there. I guess that Cog having substantial changes all around places, so adding a convenient API for VM flags and removing a bit fiddling from image header, would make things transparent and easy to use from language side. >> >> Stef >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 18, 2010

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

by Miguel Enrique CobÃ¡ Martinez

El lun, 17-05-2010 a las 09:49 +0200, StÃ©phane Ducasse escribiÃ³: > I like the idea of tags. > Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD > with all the code included. But look at Debian for example. They release a stable release, lets say 5.0 on January 15th. This is a iso image that includes a given set of package versions, lets say Package A version 1.1 Package B version 2.0 Package C version 2.1 then they continue working on testing and unstable versions of the distro. Of course as the software is used all around the world, the users report bugs and the developers push new versions with the fixes to the debian repositories. The fixes can be bug fixes, security fixes and new features. Only the security fixes and severe bug fixes are pushed to the stable release (as well as to the testing and unstable branches of course). This security fixes are part of the security updates for stable installations of the distro. But.. after a given number of security fixes and severe bug fixes are collected, they release an update for the stable release, even generating new .iso files. Suppose that they release an update in May 1st. They could call it Debian GNU/Linux stable 5.0.1. The point is, even if I downloaded the stable release on January 15th, it is different from the version you download on May 1st. They are both called debian 5.0 stable and nobody expect that they are bitwise identical. But, when you install from the version from January and after updating it from the update stream, I get the same packages that the person that install its server from the version of May 1st. I think the same can happen to Pharo. You release a given set of versions (in the form of configurationOfXXX) but that doesn't means that those are inmutable. They will be updated to match the packages that fix bugs in a given external package. Now for the generation of the release, you simply script it to use the latest #released version of a configuration. That is the way that Metacello works currently, installing the latest released version by default. Cheers > > Stef > > > > I was thinking about the "folders" to store copies of ConfigurationOfXXX > > for a given release. I think that this will have problems, for example > > for the simplest package that load fine in 3 consecutive release we will > > have exactly 3 copies of the ConfigurationOfXXX package (not that the > > disk space is a problem). On the other side, if a package has 19 > > versions for a given release (lets say RFB has 19 version methods in the > > ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a > > copy of it will be made. This copy will be full, having the 19 version > > methods, or you just take the last version method. Also, what about the > > pre/post do its, they will likely be similar or exactly equal between > > releases of Pharo. > > If you delete the methods, you also lost the history and the opportunity > > that new users can learn or use the previous versions. > > > > Some time ago I proposed the idea that Metacello should have tags to > > mark that a version method has been tested in a given fork/release. As > > the time pass, the tags in a method will grow to mark the version has > > been tested on. > > But for this to work, Metacello or the tools (I would prefer Metacello) > > must honor this tags and before loading the code in a given image by > > comparing what image is being installed on. > > > > Lets put an example: > > > > 1. Initial creation of the configuration for package Package for Pharo > > 1.0 uploaded to MetacelloRepository: > > > > ConfigurationOfPackage>>baseline01 > > "initial baseline" > > > > ConfigurationOfPackage>>version01: spec > > <version: '0.1'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: 'Pharo1.0' > > ... ]. > > > > 2. A new version for Pharo 1.0 (lets say a bug fix): > > > > ConfigurationOfPackage>>version02: spec > > <version: '0.2'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: 'Pharo1.0' > > ... ]. > > > > 3. A new Pharo release is made, no changes to the package are needed, > > that is, it works correctly in Pharo1.0 and Pharo 1.1 > > > > ConfigurationOfPackage>>version03: spec > > <version: '0.3'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) > > ... ]. > > > > At this point the ConfigurationOfPackage has four methods: baseline and > > three versions. Also, before loading, Metacello checks the worksIn: > > list against a standard release string in the image is working on. If > > it match it install the package. That is, if I start with a Pharo1.1 > > image and load the configuration, the only possible candidate version > > to install is the 0.3, because is the only one marked to work in Pharo1.1. > > > > 4. A port to Squeak 5 is made. This likely will need a new baseline > > because will need squeak specific packages to be included > > (compatibility packages) and also maybe a Pharo compatibility package > > will be made. Anyway, a new baseline indicating new packages > > relationships will be made: > > > > ConfigurationOfPackage>>baseline02 > > "second baseline, it accounts for install in Pharo and Squeak" > > > > ConfigurationOfPackage>>version04: spec > > <version: '0.4'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) > > ... ]. > > spec for: #squeak do: [ > > ... ]. > > spec for: #pharo do: [ > > ... ]. > > > > At this point the ConfigurationOfXXX is capable of install the last > > version in Squeak and Pharo. > > > > If I start on Squeak 4.0 then even if I load the > > ConfigurationOfPackage, no package will be installed because nobody has tested this. > > > > If I start on Squeak 5.0 only version 0.4 can be installed. > > > > If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed > > > > If I start on Pharo 1.3 no package will be installed > > > > 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases > > but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1 > > > > ConfigurationOfPackage>>baseline08 > > "second baseline, it accounts for install in Pharo and Squeak" > > > > ConfigurationOfPackage>>version09: spec > > <version: '0.9'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) > > ... ]. > > spec for: #pharo do: [ > > ... ]. > > > > 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0: > > > > ConfigurationOfPackage>>baseline04 > > "third baseline, it accounts for install in Pharo and Squeak" > > > > ConfigurationOfPackage>>version10: spec > > <version: '1.0'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) > > ... ]. > > spec for: #squeak do: [ > > ... ]. > > spec for: #pharo do: [ > > ... ]. > > > > So the tags come and go as the support for given forks and releases are > > tested. > > Different versions of the Package package can work in different forks > > and in different releases of those forks. > > It is always the job of the interested parties to add support (that is > > version methods and baselines, or simply tags to the worksIn: list) for > > a package in a given combination. > > > > What do you think? > > > > Cheers > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 18, 2010

[Pharo-project] I really miss a binary bitOr: selector for integers

by Igor Stasenko

Hello, C world using bitor-s extensively for passing various flags and options. And porting the code looks really awful with #bitOr: , because it requires braces when you combining more than 2 flags. Can we , please , please, include #| as an alternative selector for bitor-ing integers into a kernel? Btw, Alien alredy adds it as extension. But i would really like to get it into the core, so any other may use it. Meanwhile, i defined own awfull extension selector - #++ -- Best regards, Igor Stasenko AKA sig.

May 18, 2010

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