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

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

by Mariano Martinez Peck

On Tue, May 18, 2010 at 9:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/5/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > this is cool > > We could then build tools for you :) > > Boxes are packages, little squares are classes > > > > > > Blue: classes with no instances > > Green: classes with instances, but no used > > Red: classes with instances and at least one used > > > > just brainstorming with mariano > > > Interesting. > Could it draw with pink, the ones who has no instances, but having a > methods invocations > (an abstract superclasses can have no instances, but can be under heavy > use). > Sorry I forgot to change the colors. Look above to see the references. Cheers Mariano > > > > > > > > > > > > > On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > > > >> > >> > >> 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 > >> > >> _______________________________________________ > >> 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. > > _______________________________________________ > 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

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

by Adrian Lienhard

Yes, we should probably do that. It requires some work because of changes in 1.1. Adrian On May 18, 2010, at 09:24 , Michael Roberts wrote: > I am surprised too. would it not be safer to just apply the same > reversion of the code so that 1.1 is the same as 1.0? Then when > someone has the time to do a full review, a "new" network can be > applied to the start of a dev cycle, with some form of integration > tests. > > cheers, > Mike > > On Tue, May 18, 2010 at 6:31 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Hi Alex, >> >> One thing that bothers me is the network code. Although nobody reported problems I cannot believe that it suddenly works without that we fixed it. The new implementation that is in 1.1 has been reverted in 1.0 and since then we haven't had any complaints. Now in 1.1 I guess that there are not that many people using it yet. >> >> If there are people at the sprint with different OS and configurations (Linux vs Mac; IPv4 vs. IPv6), you could try to reproduce the problems that were reported earlier (check the issue tracker). >> >> Another valuable help would be to (manually) test the tools, especially the ones loaded into Pharo to make sure we don't have any obvious problems there. >> >> Hope you have a productive weekend! >> >> Cheers, >> Adrian >> >> On May 18, 2010, at 02:49 , Alexandre Bergel wrote: >> >>> 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 >>> >>> >>> _______________________________________________ >>> 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 18, 2010

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

by Igor Stasenko

2010/5/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this is cool > We could then build tools for you :) > Boxes are packages, little squares are classes > > > Blue: classes with no instances > Green: classes with instances, but no used > Red: classes with instances and at least one used > > just brainstorming with mariano > Interesting. Could it draw with pink, the ones who has no instances, but having a methods invocations (an abstract superclasses can have no instances, but can be under heavy use). > > > > > > On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > >> >> >> 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 >> >> _______________________________________________ >> 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

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

by StÃ©phane Ducasse

> > > send code with a nice comments and a test and it will be in 1.1 :) > > Stef > > On May 18, 2010, at 3:26 AM, Igor Stasenko wrote: > >> 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] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

Alex Can you tell me the french time of the sprint because I would like to help people focusing on some good fixes to produce I want to try to be online. Stef On May 18, 2010, at 2:49 AM, Alexandre Bergel wrote: > 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 > > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

this is cool We could then build tools for you :) Boxes are packages, little squares are classes Blue: classes with no instances Green: classes with instances, but no used Red: classes with instances and at least one used just brainstorming with mariano On May 17, 2010, at 10:40 PM, Eliot Miranda wrote: > > > 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 > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

two points - let us try something simple that we can understand - second the latest only works if nobody publish a broken code in his repository. or you will have to publish the packages tagged 'latest but for stream pharo1.0' So for now let us keep it simple and learn. Stef On May 18, 2010, at 4:17 AM, Miguel Enrique CobÃ¡ Martinez wrote: > 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 > > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple ========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load. A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. We can use automatic build server to validate the status or migration between different repositories ========================================================== Stef On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: > 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 >> > > _______________________________________________ > 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

Re: [Pharo-project] condensing changes file

by StÃ©phane Ducasse

I will do a condense changes in the beta like that it will clean up the problems. Stef On May 18, 2010, at 12:33 AM, Mariano Martinez Peck wrote: > 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 > > _______________________________________________ > 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

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

by Michael Roberts

I am surprised too. would it not be safer to just apply the same reversion of the code so that 1.1 is the same as 1.0? Then when someone has the time to do a full review, a "new" network can be applied to the start of a dev cycle, with some form of integration tests. cheers, Mike On Tue, May 18, 2010 at 6:31 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Alex, > > One thing that bothers me is the network code. Although nobody reported problems I cannot believe that it suddenly works without that we fixed it. The new implementation that is in 1.1 has been reverted in 1.0 and since then we haven't had any complaints. Now in 1.1 I guess that there are not that many people using it yet. > > If there are people at the sprint with different OS and configurations (Linux vs Mac; IPv4 vs. IPv6), you could try to reproduce the problems that were reported earlier (check the issue tracker). > > Another valuable help would be to (manually) test the tools, especially the ones loaded into Pharo to make sure we don't have any obvious problems there. > > Hope you have a productive weekend! > > Cheers, > Adrian > > On May 18, 2010, at 02:49 , Alexandre Bergel wrote: > >> 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 >> >> >> _______________________________________________ >> 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 18, 2010