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

Re: [Pharo-project] Allow or disable System Update in PharoDev images ?

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > without its own update stream, or section in the update file, I think > the effect of allowing the Pharo image to update itself based on the > core update file would lead to an undefined result? > > Yes. Mostly due to overrides. > If that is the case I would disable it. > > I assume this would be replaced by some Metacello 'update stream' ? > > That's a good idea. I am not sure how to implement it, but for sure, it will be in a future ;) Maybe 1.1 > cheers, > Mike > > 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > It is a simple question. Do we allow that or not. Miguel wrote the pros > and > > cons: > > > > Pros > > - Can fix bugs after release > > - Can aply improvements to the image after release. > > > > Cons > > - Can mess the image of someone by overwriting some overridden method. > > - Can accidentally update more than intended in someone's image > > > > > > We have to take a decision. > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > 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 >

Jan. 10, 2010

Re: [Pharo-project] Allow or disable System Update in PharoDev images ?

by Michael Roberts

without its own update stream, or section in the update file, I think the effect of allowing the Pharo image to update itself based on the core update file would lead to an undefined result? If that is the case I would disable it. I assume this would be replaced by some Metacello 'update stream' ? cheers, Mike 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > It is a simple question. Do we allow that or not.Â Miguel wrote the pros and > cons: > > Pros > - Can fix bugs after release > - Can aply improvements to the image after release. > > Cons > - Can mess the image of someone by overwriting some overridden method. > - Can accidentally update more than intended in someone's image > > > We have to take a decision. > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by Danie Roux

On Sun, Jan 10, 2010 at 5:45 PM, Fernando olivero wrote: > Would be nice to adopt this refactoring into Pharo, i've started to port it and cleaning up the textmorph in the process. But it's still a work in progress. Just a heads up: This will require some work in OB down the line. OBTextMorphEditor inherits from TextMorphEditor. Squeak trunk has this refactoring in, and the default editor is now TextEditor there. Which OB is not making use of, as of yet. -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

Jan. 10, 2010

[Pharo-project] Allow or disable System Update in PharoDev images ?

by Mariano Martinez Peck

It is a simple question. Do we allow that or not. Miguel wrote the pros and cons: Pros - Can fix bugs after release - Can aply improvements to the image after release. Cons - Can mess the image of someone by overwriting some overridden method. - Can accidentally update more than intended in someone's image We have to take a decision. Cheers Mariano

Jan. 10, 2010

[Pharo-project] CUIS new Text Editor Classes

by Fernando olivero

Juan re-factored the smalltalk behavior in the editors, creating the following hierarchy Editor TextEditor SimpleEditor SmalltalkEditor See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html. New text editors. TextEditor provides most of the functionality that used to be in TextMorphEditor. This class is no longer a Controller! SmalltalkEditor is has Smalltalk code specific features. SimpleEditor provides basic functionality for single line text editing. It does not handle fonts and styles, aligning and Smalltalk utilities. It handles one single line. Would be nice to adopt this refactoring into Pharo, i've started to port it and cleaning up the textmorph in the process. But it's still a work in progress. Fernando On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: > Hi, > >> Gary and others >> >> I really think that we should do an audit of Morphic. In 1.1 we are >> going already faster but I'm sure that there is plenty >> of space for improvements. >> >> I see several actions >> - checking squeak toolbuilder enhancements and using it for the tools >> >> - checking CUIS >> - juan did an excellent job remocving a lot of unnecessary code >> - juan optimize scrollbar >> - juan did a new texteditor morph > > Indeed, a text editor that does not hardcode smalltalk specific > behavior would be great :). > >> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >> - integrating better polymorph into the widgets layer. >> >> What do you think? > > > Doru > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] System -> About in Dev images

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 4:34 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > I had imagined the update number of Pharo and PharoCore would be the > same? do you need to know any more about the core image? > > I really don't know. But for example, but happens with after DevImage someone do a System Update and updates the core ? I think that maybe we should take a decision if this system update will be allowed or not in a Pharo image. > ...we could embed the core's SystemVersion in the Pharo image. > version iVar will be deprecated when I get around to it. did you mean > putting behaviour on the instance side? I would not, but do something > like > > "during Pharo build...." > SystemVersion core: SystemVersion current copy. > > "Make image Pharo" > SystemVersion current > type: 'Pharo'; > suffix: 'rc1' > "etc" > > and then in the about dialog you can access SystemVersion core & > SystemVersion current. This is at the expense of a new class > variable. > Ok. > > however, i'm not sure if it's really needed. Me neither. Opinions ? > Could the release notes > tell you where the image comes from? > > I can put in the changelog whatever I want. So, in the changelog I would be able to put something like 'Pharo-1.0-10505-rc1 The problem is that most people don't look at that but to the System -> About cheers, > Mike > > > >> > > >> > Ok...the problem is that I have just checked and this changes are only > >> > in > >> > 1.1 isn't it ? > >> > > >> > :( So...what we do ? we keep like this until 1.1 ? > >> > >> oh sorry yes they are only in 1.1. You just need to change version: > >> string using some string manipulation. If you keep it in the same > >> format it will parse correctly by code that expects the 1.1 format. > >> On principle I did not backport the SystemVersion changes behaviour to > >> 1.0 since it was already at the end of the cycle. However i just > >> migrated the data to work across core branches. > >> > >> > > >> >> > >> >> and you can change the suffix as well, but personally i would not use > >> >> the date in the image name. > >> >> > >> > > >> > For the date you refer to year, month and number of version inside the > >> > month > >> > ? > >> > >> yes I think it is too complicated a version scheme. The dev tag is > >> also synonymous with Pharo. > >> > >> so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 > >> I would call it Pharo-1.0-10505-rc1. This is the same scheme that the > >> core image uses, and Pharo 1.1 will have this behaviour already using > >> #imageVersionString since it is in 1.1. > >> > > > > That's cool. I evaluate: > > > > SystemVersion current version: 'Pharo-1.0-10505-rc1' > > > > And seems to be almost what I want. It would be cool (maybe not for 1.0, > > but for 1.1) if we can see not only the version of Pharo, but also opf > the > > pharoCore...So, SystemVersion could understand: > > > > coreVersion: and version: > > > > Then in System -> About, if I am in a core image I would see: > > > > PharoCore1.0rc1 > > Latest update: #10505 > > > > And if I am in Pharo I would see > > > > Pharo1.0-10505-rc1dev10.01.1 > > PharoCore1.0rc1 > > Latest update: #10505 > > > > > > Right now, with what you told me is enought for 1.0, but maybe for 1.1 > would > > be cool to have that. > > > > what do you think ? > > > > cheers > > > > mariano > > > > > >> > >> thanks, > >> Mike > >> > >> _______________________________________________ > >> 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 >

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 2:13 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Adrian: Most of the failing tests are from OB. Someone said Lukas made > all > > those tests green, but they are commited in his repo. Someone should > merge > > that with the wiresong repo. If no one merge that, I don't know what to > do: > > or remove them or keep them. > > Use the code from my repository. However, there are currently 4 broken > tests as you can see on the build server > < > http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testRepor… > >. > Looks like some kind of a side-effect on the headless linux VM, > because I don't observe them in my image. > Lukas: I had most of the tests in red until I install the package OB-Fake Do you know which packages from OB require OB-Fake? After that I have only two tests failing :) - testPushAlpaBeta - testUpdatesSelection The same it is here: http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testRepor… :) Thanks Mariano > Lukas > > -- > Lukas Renggli > http://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 >

Jan. 10, 2010

Re: [Pharo-project] System -> About in Dev images

by Michael Roberts

I had imagined the update number of Pharo and PharoCore would be the same? do you need to know any more about the core image? ...we could embed the core's SystemVersion in the Pharo image. version iVar will be deprecated when I get around to it. did you mean putting behaviour on the instance side? I would not, but do something like "during Pharo build...." SystemVersion core: SystemVersion current copy. "Make image Pharo" SystemVersion current type: 'Pharo'; suffix: 'rc1' "etc" and then in the about dialog you can access SystemVersion core & SystemVersion current. This is at the expense of a new class variable. however, i'm not sure if it's really needed. Could the release notes tell you where the image comes from? cheers, Mike >> > >> > Ok...the problem is that I have just checked and this changes are only >> > in >> > 1.1 isn't it ? >> > >> > :(Â Â Â So...what we do ? we keep like this until 1.1 ? >> >> oh sorry yes they are only in 1.1. Â You just need to change version: >> string using some string manipulation. Â If you keep it in the same >> format it will parse correctly by code that expects the 1.1 format. >> On principle I did not backport the SystemVersion changes behaviour to >> 1.0 since it was already at the end of the cycle. However i just >> migrated the data to work across core branches. >> >> > >> >> >> >> and you can change the suffix as well, but personally i would not use >> >> the date in the image name. >> >> >> > >> > For the date you refer to year, month and number of version inside the >> > month >> > ? >> >> yes I think it is too complicated a version scheme. The dev tag is >> also synonymous with Pharo. >> >> so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 >> I would call it Pharo-1.0-10505-rc1. This is the same scheme that the >> core image uses, and Pharo 1.1 will have this behaviour already using >> #imageVersionString since it is in 1.1. >> > > That's cool. I evaluate: > > SystemVersion current version: 'Pharo-1.0-10505-rc1' > > And seems to be almost what I want.Â It would be cool (maybe not for 1.0, > but for 1.1)Â if we can see not only the version of Pharo, but also opf the > pharoCore...So, SystemVersion could understand: > > coreVersion: Â and version: > > Then in System -> About, if I am in a core image I would see: > > Â PharoCore1.0rc1 > Latest update: #10505 > > And if I am in Pharo I would see > > Pharo1.0-10505-rc1dev10.01.1 > PharoCore1.0rc1 > Latest update: #10505 > > > Right now, with what you told me is enought for 1.0, but maybe for 1.1 would > be cool to have that. > > what do you think ? > > cheers > > mariano > > >> >> thanks, >> Mike >> >> _______________________________________________ >> 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 >

Jan. 10, 2010

Re: [Pharo-project] problem installing Nile

by Mariano Martinez Peck

I really don't know where the problem is here. If I take an image, both, installing just Nile from Metacello or from Monticello Browser, it loads ok. When I run my full ConfigurationOfPharo from a command line sending the scripts, I always have this errors. But Dale, you said you have the same problems even running the load from a workspace? I don't understand :( I know the package Nile-All loads all the required packages using the Monticello required package feature...maybe there is a conflic here ? Maybe something related to what stef said that the repository is being replaced with another one like pharo ? Cheers Mariano On Sun, Jan 10, 2010 at 8:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > may be there were publsihe in the nile repo and you are trying to load them > from Pharo > > On Jan 10, 2010, at 2:15 AM, Mariano Martinez Peck wrote: > > > I don't know why, but (sometimes) I have errors trying to install > Nile-All in PharoCore. > > > > This is weird becuase it says that it didn't found a version, but the > version really exists. > > > > I attach screenshots. > > > > Any idea? > > > > cheers > > > > mariano > > <Picture 8.png><Picture 7.png><Picture > 6.png>_______________________________________________ > > 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 >

Jan. 10, 2010

Re: [Pharo-project] System -> About in Dev images

by Mariano Martinez Peck

On Sun, Jan 10, 2010 at 3:38 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > Ok...the problem is that I have just checked and this changes are only in > > 1.1 isn't it ? > > > > :( So...what we do ? we keep like this until 1.1 ? > > oh sorry yes they are only in 1.1. You just need to change version: > string using some string manipulation. If you keep it in the same > format it will parse correctly by code that expects the 1.1 format. > On principle I did not backport the SystemVersion changes behaviour to > 1.0 since it was already at the end of the cycle. However i just > migrated the data to work across core branches. > > > > >> > >> and you can change the suffix as well, but personally i would not use > >> the date in the image name. > >> > > > > For the date you refer to year, month and number of version inside the > month > > ? > > yes I think it is too complicated a version scheme. The dev tag is > also synonymous with Pharo. > > so if your Pharo image is currently Pharo1.0-10505-rc1dev10.01.1 > I would call it Pharo-1.0-10505-rc1. This is the same scheme that the > core image uses, and Pharo 1.1 will have this behaviour already using > #imageVersionString since it is in 1.1. > > That's cool. I evaluate: SystemVersion current version: 'Pharo-1.0-10505-rc1' And seems to be almost what I want. It would be cool (maybe not for 1.0, but for 1.1) if we can see not only the version of Pharo, but also opf the pharoCore...So, SystemVersion could understand: coreVersion: and version: Then in System -> About, if I am in a core image I would see: PharoCore1.0rc1 Latest update: #10505 And if I am in Pharo I would see Pharo1.0-10505-rc1dev10.01.1 PharoCore1.0rc1 Latest update: #10505 Right now, with what you told me is enought for 1.0, but maybe for 1.1 would be cool to have that. what do you think ? cheers mariano > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 10, 2010