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

Re: [Pharo-project] [Seaside] Installing and testing Seaside 2.8.4, Magritte and Pier in Pharo 1.1

by Lukas Renggli

On Sunday, May 16, 2010, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sun, 16 May 2010, Lukas Renggli wrote: > > > Seaside 2.8 and repective versions of Magritte and Pier are not > actively developed anymore. I suugest to drop support for Pharo 1.1. > > > It's a bit strange that the latest Seaside release is not supported anymore. The latest Seaside release is Seaside 3.0a5. Lukas > > > Levente > > > > Lukas > > On Sunday, May 16, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi seasideers. I was loading all this stuff of PharoCore 1.1 and see if everything seems to be working. At this is the case :) > However, I have 2 tests with errors and this is due to send to BlockClosure >> fixTemps which is deprecated in Pharo 1.1 > The fix is easy, just remove the send of fixTemps, but I am not sure the impact of this in other dialects. But would be cool not to have the deprecated warning when loading. > > The places are Amb >> oneOf: aCollection > and Amb >> valueOfOneOf: blockCollection > > Then I have two failing but I don't understand why: > > WABacktrackingTest >> testOrderedCollection > > I don't know why here, but after "original removeLast."Â snapshot has the elements "1" and "nil" instead of "1" and "2", and thus, it fails in self assert: original asArray = #(1 2) > > The other is: > > WABacktrackingTest >> testDictionary > > It is failing in "self assert: (original at: 1 ifAbsent: []) = #a." > because original shows ->Â Â a Dictionary(2->#b 3->#d ) > > I know your effort is now in Seaside3 but having all green tests with Pharo 1.1 would be really cool :) > > Last thing, if you want to test it, just take a PharoCore 1.1 image, for example: > > https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… > > And then evaluate: > > (Smalltalk at: #Gofer) new > Â Â Â squeaksource: 'MetacelloRepository'; > Â Â Â package: 'ConfigurationOfSeaside'; > Â Â Â load. > > > ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. > > and run tests :) > > Thanks > > Mariano > > > > > > -- > 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 > > -- Lukas Renggli www.lukas-renggli.ch

May 16, 2010

Re: [Pharo-project] [Seaside] Installing and testing Seaside 2.8.4, Magritte and Pier in Pharo 1.1

by Levente Uzonyi

On Sun, 16 May 2010, Lukas Renggli wrote: > Seaside 2.8 and repective versions of Magritte and Pier are not > actively developed anymore. I suugest to drop support for Pharo 1.1. It's a bit strange that the latest Seaside release is not supported anymore. Levente > > Lukas > > On Sunday, May 16, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi seasideers. I was loading all this stuff of PharoCore 1.1 and see if everything seems to be working. At this is the case :) >> However, I have 2 tests with errors and this is due to send to BlockClosure >> fixTemps which is deprecated in Pharo 1.1 >> The fix is easy, just remove the send of fixTemps, but I am not sure the impact of this in other dialects. But would be cool not to have the deprecated warning when loading. >> >> The places are Amb >> oneOf: aCollection >> and Amb >> valueOfOneOf: blockCollection >> >> Then I have two failing but I don't understand why: >> >> WABacktrackingTest >> testOrderedCollection >> >> I don't know why here, but after "original removeLast."Â snapshot has the elements "1" and "nil" instead of "1" and "2", and thus, it fails in self assert: original asArray = #(1 2) >> >> The other is: >> >> WABacktrackingTest >> testDictionary >> >> It is failing in "self assert: (original at: 1 ifAbsent: []) = #a." >> because original shows ->Â Â a Dictionary(2->#b 3->#d ) >> >> I know your effort is now in Seaside3 but having all green tests with Pharo 1.1 would be really cool :) >> >> Last thing, if you want to test it, just take a PharoCore 1.1 image, for example: >> >> https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… >> >> And then evaluate: >> >> (Smalltalk at: #Gofer) new >> Â Â Â squeaksource: 'MetacelloRepository'; >> Â Â Â package: 'ConfigurationOfSeaside'; >> Â Â Â load. >> >> >> ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. >> >> and run tests :) >> >> Thanks >> >> Mariano >> >> >> > > -- > 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 16, 2010

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

by Eliot Miranda

oops iInImageFile: => inImageFile: On Sun, May 16, 2010 at 9:39 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Sun, May 16, 2010 at 9:19 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> On May 16, 2010, at 5:52 PM, Eliot Miranda wrote: >> >> > >> > >> > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> >> > >> > >> > On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >> > I asked the same question a few weeks back and the only working >> > solution I found was to patch the window size in the image file. The >> > actual implementation is from Max Leske: >> > >> > >> http://github.com/renggli/builder/blob/master/scripts/resize-window.sh >> > >> > >> > OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing >> could work...but in fact, it does! >> > >> > It is sad this cannot be done with Smalltalk, just evaluating something >> in the image. >> > >> > ? Why do you assume it can't be done in Smalltalk? >> > >> > shrinkDisplayInImageFile: imageFileName >> > >> > | fs | >> > fs := StandardFileStream fileNamed: imageFileName. >> > fs binary. >> > [fs position: 24. >> > SmalltalkImage current isLittleEndian >> > ifTrue: >> > [fs nextLittleEndianNumber: 4 put: (1024 >> bitShift: 16) + 768. "Display size" >> > fs nextLittleEndianNumber: 4 put: 0. >> "full-screen flag (off)"] >> > ifFalse: >> > [self error: 'not yet implemented']] >> > ensure: [fs close]! ! >> >> What is fun with smalltalk is that now I understand that this information >> is encoded in the image format :) >> Now eliot do you think that the vm could expose an API of primitives so >> that we could script the size of the host window >> without having to restart the image. because I imagine that we have to. >> > > I don't understand. The VM has the relevant functionality. It is easy to > construct a special save-as that resizes the screen (or puts it into full > screen mode), saves, and then restores the display to what it was. The > above is useful when one wants to change an image file after the fact. And > again it is easy to construct a special save-as that saves and then rewrites > the image header, which would allow one e.g. to save a large display image > file on a small display machine. The KISS principle agues against modifying > the VM to take a series of variables that overrode the actual display size > on save. If the iage header is well-defined (it hasn't changed in a loooong > time) ten the above is fine, no? > > BTW, since Cog is using a number of other bits in the full-screen flag word > for other values (platform-dependent float order, whether process preemption > yields, etc) the above should read something like > > seDisplayExtent: extent fullScreen: fullScreenFlag iInImageFile: > imageFileName > > | fs flags | > fs := StandardFileStream fileNamed: imageFileName. > fs binary. > [fs position: 28. > flags := fs nextLittleEndianNumber: 4. > flags := fullScreenFlag ifTrue: [flags bitOr: 1] ifFalse: [flags > bitClear: 1]. > fs position: 24. > SmalltalkImage current isLittleEndian > ifTrue: > [fs nextLittleEndianNumber: 4 put: (extent x bitShift: 16) + extent y. > "Display size" > fs nextLittleEndianNumber: 4 put: flags.] > ifFalse: > [self error: 'not yet implemented']] > ensure: [fs close] > > Find attached on SmalltalkImage class. > > >> Stef >> > >> > >> > Thanks! >> > >> > Mariano >> > >> > >> > >> > Lukas >> > >> > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > > I know I already asked this, but I didn't get a working solution. I >> want to >> > > change the default size of the host windows that runs on Pharo. Does >> someone >> > > know how to do that? >> > > >> > > I attach the 2 screenshots: what I have, and what I want. >> > > >> > > Thanks >> > > >> > > mariano >> > > >> > > _______________________________________________ >> > > 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 >> > >> > >> > _______________________________________________ >> > 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 16, 2010

Re: [Pharo-project] [Pharo-users] Newbie: Does Socket ping: 'addr' work in Pharo3.11.8 ?

by Mariano Martinez Peck

On Sun, May 16, 2010 at 6:36 PM, RickT <Rick(a)emarysville.com> wrote: > > I am loving the Smalltalk environment and language very much, thanks! (But > I > remain an ignorant newbie nonetheless.) I hope to later explore Seaside > with > Pharo as well. > > Excellent. Just in case you don't know: http://pharobyexample.org/ http://book.seaside.st/book and in progress: http://book.pharo-project.org/ > To my problem: > > With the Pharo 1.0 image, the classVarNamed:put: message was not > understood. > (Same for Linux version of Pharo 1.0). > Ups...sorry. Actually that was for breaking encapsulation as NetNameResolver does not have a setter for such class variable. To do a quick test just implement a class side method in NetNameResolver like this: useOldNetwork: aBoolean UseOldNetwork := aBoolean And then evaluate: NetNameResolver useOldNetwork: true. > With the Pharo 1.1 image you linked me to, the message was understood, but > had no effect. > > I still cannot get Socket>>ping: to work; it always times out. > > Ok...the network package is not the best in Pharo and we had several problems :( > And yes, I meant the OS command window ping worked. For Windows XP it is > what you would call the DOS command line. I also downloaded and tried the > Pharo1.0 in my VirtualBox VM running Ubuntu. I have the same problem: I > can ping localhost from the Linux command line, but Pharo 1.0 ping always > times out. > > Ok...I know very little about network but maybe someone can help you. cheers mariano > (I am running on a Dell M90 Precision laptop. FWIW) > > Thanks very much for your help. > > > Mariano Martinez Peck wrote: > > > > On Sun, May 16, 2010 at 4:28 AM, RickT <Rick(a)emarysville.com> wrote: > > > >> > >> I installed the one-click version on Windows (XP) recently and am > >> learning > >> Smalltalk. > > > > > > Welcome! we hope you enjoy :) > > > > > >> I am under the impression that in a Shout Workspace I can > >> execute the line > >> > >> Socket ping: 'localhost' > >> > >> (or some valid address). But I always get a message that it timed out. > >> I > >> can successfully ping the same address in a command window. > > > > > > Sorry I don't understand. Where you can successfully ping ? what's is a > > command window? do you mean DOS or somehow outside Pharo? > > > > Can you try the same after evaluating: > > > > NetNameResolver classVarNamed: 'UseOldNetwork' put: true > > > > Can you try also the same but using a PharoCore 1.1 image (you can use > the > > same VM): > > > > > https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… > > > > Thanks! > > > > Mariano > > > > > >> Any guidance > >> would be appreciated. > >> > >> -- > >> View this message in context: > >> > http://forum.world.st/Newbie-Does-Socket-ping-addr-work-in-Pharo3-11-8-tp22… > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> Pharo-users mailing list > >> Pharo-users(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >> > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > -- > View this message in context: > http://forum.world.st/Newbie-Does-Socket-ping-addr-work-in-Pharo3-11-8-tp22… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

May 16, 2010

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

by Eliot Miranda

On Sun, May 16, 2010 at 9:19 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On May 16, 2010, at 5:52 PM, Eliot Miranda wrote: > > > > > > > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > > > > On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > > I asked the same question a few weeks back and the only working > > solution I found was to patch the window size in the image file. The > > actual implementation is from Max Leske: > > > > > http://github.com/renggli/builder/blob/master/scripts/resize-window.sh > > > > > > OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing > could work...but in fact, it does! > > > > It is sad this cannot be done with Smalltalk, just evaluating something > in the image. > > > > ? Why do you assume it can't be done in Smalltalk? > > > > shrinkDisplayInImageFile: imageFileName > > > > | fs | > > fs := StandardFileStream fileNamed: imageFileName. > > fs binary. > > [fs position: 24. > > SmalltalkImage current isLittleEndian > > ifTrue: > > [fs nextLittleEndianNumber: 4 put: (1024 > bitShift: 16) + 768. "Display size" > > fs nextLittleEndianNumber: 4 put: 0. > "full-screen flag (off)"] > > ifFalse: > > [self error: 'not yet implemented']] > > ensure: [fs close]! ! > > What is fun with smalltalk is that now I understand that this information > is encoded in the image format :) > Now eliot do you think that the vm could expose an API of primitives so > that we could script the size of the host window > without having to restart the image. because I imagine that we have to. > I don't understand. The VM has the relevant functionality. It is easy to construct a special save-as that resizes the screen (or puts it into full screen mode), saves, and then restores the display to what it was. The above is useful when one wants to change an image file after the fact. And again it is easy to construct a special save-as that saves and then rewrites the image header, which would allow one e.g. to save a large display image file on a small display machine. The KISS principle agues against modifying the VM to take a series of variables that overrode the actual display size on save. If the iage header is well-defined (it hasn't changed in a loooong time) ten the above is fine, no? BTW, since Cog is using a number of other bits in the full-screen flag word for other values (platform-dependent float order, whether process preemption yields, etc) the above should read something like seDisplayExtent: extent fullScreen: fullScreenFlag iInImageFile: imageFileName | fs flags | fs := StandardFileStream fileNamed: imageFileName. fs binary. [fs position: 28. flags := fs nextLittleEndianNumber: 4. flags := fullScreenFlag ifTrue: [flags bitOr: 1] ifFalse: [flags bitClear: 1]. fs position: 24. SmalltalkImage current isLittleEndian ifTrue: [fs nextLittleEndianNumber: 4 put: (extent x bitShift: 16) + extent y. "Display size" fs nextLittleEndianNumber: 4 put: flags.] ifFalse: [self error: 'not yet implemented']] ensure: [fs close] Find attached on SmalltalkImage class. > Stef > > > > > > Thanks! > > > > Mariano > > > > > > > > Lukas > > > > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > I know I already asked this, but I didn't get a working solution. I > want to > > > change the default size of the host windows that runs on Pharo. Does > someone > > > know how to do that? > > > > > > I attach the 2 screenshots: what I have, and what I want. > > > > > > Thanks > > > > > > mariano > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > > 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 16, 2010

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

by Mariano Martinez Peck

On Sun, May 16, 2010 at 6:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Mariano > > I really want to have a separate folder for each version. > If this does not work then we will try something else. Why because I would > like to have distribution. > Dale implemented a kind of freeze mechanism that copies all the dependent > package of a project. > Then publishing to a given folder is a publication act and I like that it > is explicit. It take less than a minute to copy > the given file to the 10 and 1.1 repository. > > Now about you last point. Yes we need to freeze the version because loading > the latest will not work and you want that people > just say load and not load: 14.2 here and load: 0.25 there. I'm correct? > Yes...imagine today you copy your Conf to Pharo10MetacelloConfiguration ... today the working version for Pharo 1.0 is 1.4.5. Then...you continue to develop. Of course, using the same conf. Then you have version 1.5, 1.6, 1.6.2 , etc Suppose that now we have Pharo1.1 and you do the same: you copy your new version of the conf to Pharo11MetacelloConfiguration. How do people know WHICH version of the conf work for EACH pharo version ? That's why I had the idea that every developer implement load to instead of loading the last version, to load the last version that WORKS for that Pharo version. So probably, the conf you copy to Pharo10MetacelloRepository may be load self version: '1.0.xx' load and in Parho11MetacelloRepository it would be load seld version: '1.6.xxx' this is just an example. Having this, it also gives us an API: Everybody will know how to install it: just evaluate load. And "us" can be extended to a bot -> continuous integration. > What is the alternative? > > Stef > > > > Hi folks. We have been discussing a lot what to do with the Metacello > configurations of all projects and MetacelloRepository. > > We want several things: > > > > - Have an specific catalog of the working and tested packages/projects > for each Pharo release (1.0, 1.1, etc). > > - Be able to have a hudson server running and testing such > configurations. > > - Unified way to load a project. > > > > For such objectives, we propose the following scheme: > > > > 1) We create a squeaksource repository called Pharo10MetacelloRepository > > 2) All the Metacello configurations that are known and tested to work > perfect in Pharo1.0, are copied to such repository. (this takes 2 minutes) > > 3) Now, we have the problem of WHICH version from the conf class should > be the one that loads and works in Pharo 1.0. So, once you copied the > configuration, then you have to implement a class side method "load" that > loads the exact version that should work in Pharo1.0. This version may not > be the last. And you already may have defined "load" to load the last > version. In such case, you can just change it for the version in the > Pharo10MetacelloRepository. Otherwise, we can use another message. Give us > your opinion. > > > > So the idea is that all developers/maintainers of Metacello > configurations, do that and publish it. With this, if you want to know which > projects work on Pharo 1.0 you just browser Pharo10MetacelloRepository, load > the repository you want, and you know that just doing "ConfigurationOfXXX" > load will do the job. > > > > In addition to this, we are able to have a hudson server that every XX > time, it scans the repository, and for each project it tries to load it and > report if there is a problem. We can even make that "load" loads also the > tests and make Hudson to run the tests. Or if you want we can use another > message than load. > > > > So...this is just an idea. But we need feedback and hear opinions. > Because Pharo 1.1 will be soon and would be great to have this already > working for Pharo 1.0. > > > > Thanks > > > > 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 >

May 16, 2010

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

by Mariano Martinez Peck

2010/5/16 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> On Sun, May 16, 2010 at 4:42 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >>> I asked the same question a few weeks back and the only working >>> solution I found was to patch the window size in the image file. The >>> actual implementation is from Max Leske: >>> >>> >>> http://github.com/renggli/builder/blob/master/scripts/resize-window.sh >>> >>> >> OMG. WHAT A HACK!!!! but works hahahah. I cannot believe such thing >> could work...but in fact, it does! >> >> It is sad this cannot be done with Smalltalk, just evaluating something in >> the image. >> > > ? Why do you assume it can't be done in Smalltalk? > Just because we didn't get an answer before ;) > > shrinkDisplayInImageFile: imageFileName > > | fs | > fs := StandardFileStream fileNamed: imageFileName. > fs binary. > [fs position: 24. > SmalltalkImage current isLittleEndian > ifTrue: > [fs nextLittleEndianNumber: 4 put: (1024 bitShift: > 16) + 768. "Display size" > fs nextLittleEndianNumber: 4 put: 0. "full-screen > flag (off)"] > ifFalse: > [self error: 'not yet implemented']] > ensure: [fs close]! ! > > >> >> Cool. It works, but ONLY appling it to another image....which in such case I rather shell :( I tried: | fs | fs := StandardFileStream fileNamed: (SmalltalkImage current imageName). fs binary. [fs position: 24. SmalltalkImage current isLittleEndian ifTrue: [fs nextLittleEndianNumber: 4 put: (1024 bitShift: 16) + 768. "Display size" fs nextLittleEndianNumber: 4 put: 0. "full-screen flag (off)"] ifFalse: [self error: 'not yet implemented']] ensure: [fs close] Notice the (SmalltalkImage current imageName). but didn't work. Is this expected? Is there a way to change the current image? Thanks! Mariano > Thanks! >> >> Mariano >> >> >> >> >>> Lukas >>> >>> 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> > I know I already asked this, but I didn't get a working solution. I >>> want to >>> > change the default size of the host windows that runs on Pharo. Does >>> someone >>> > know how to do that? >>> > >>> > I attach the 2 screenshots: what I have, and what I want. >>> > >>> > Thanks >>> > >>> > mariano >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> _______________________________________________ >> 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 16, 2010

Re: [Pharo-project] [Seaside] Installing and testing Seaside 2.8.4, Magritte and Pier in Pharo 1.1

by StÃ©phane Ducasse

+1 We do not have the engineer force to support that many old versions. Stef On May 16, 2010, at 6:22 PM, Lukas Renggli wrote: > Seaside 2.8 and repective versions of Magritte and Pier are not > actively developed anymore. I suugest to drop support for Pharo 1.1. > > Lukas > > On Sunday, May 16, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi seasideers. I was loading all this stuff of PharoCore 1.1 and see if everything seems to be working. At this is the case :) >> However, I have 2 tests with errors and this is due to send to BlockClosure >> fixTemps which is deprecated in Pharo 1.1 >> The fix is easy, just remove the send of fixTemps, but I am not sure the impact of this in other dialects. But would be cool not to have the deprecated warning when loading. >> >> The places are Amb >> oneOf: aCollection >> and Amb >> valueOfOneOf: blockCollection >> >> Then I have two failing but I don't understand why: >> >> WABacktrackingTest >> testOrderedCollection >> >> I don't know why here, but after "original removeLast." snapshot has the elements "1" and "nil" instead of "1" and "2", and thus, it fails in self assert: original asArray = #(1 2) >> >> The other is: >> >> WABacktrackingTest >> testDictionary >> >> It is failing in "self assert: (original at: 1 ifAbsent: []) = #a." >> because original shows -> a Dictionary(2->#b 3->#d ) >> >> I know your effort is now in Seaside3 but having all green tests with Pharo 1.1 would be really cool :) >> >> Last thing, if you want to test it, just take a PharoCore 1.1 image, for example: >> >> https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… >> >> And then evaluate: >> >> (Smalltalk at: #Gofer) new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfSeaside'; >> load. >> >> >> ConfigurationOfSeaside project latestVersion load: 'Seaside 2.8'. >> >> and run tests :) >> >> Thanks >> >> Mariano >> >> >> > > -- > 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 16, 2010

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

by StÃ©phane Ducasse

> > I think Andreas' recent post to squeak-dev is most cogent o this topic: Eliot believe me we talk a lot of metacello since at least ESUG last year :) We support and appreciate dale's effort (even when people bashed metacello a while ago). So I think that we have a solution that looks ok for us. We started to see how we can manage pharoCore to produce pharoMini using metacello and what hamper us to remove more aggressively package is the speed of load monticello packages. Stef

May 16, 2010

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

by StÃ©phane Ducasse

Mariano I really want to have a separate folder for each version. If this does not work then we will try something else. Why because I would like to have distribution. Dale implemented a kind of freeze mechanism that copies all the dependent package of a project. Then publishing to a given folder is a publication act and I like that it is explicit. It take less than a minute to copy the given file to the 10 and 1.1 repository. Now about you last point. Yes we need to freeze the version because loading the latest will not work and you want that people just say load and not load: 14.2 here and load: 0.25 there. I'm correct? What is the alternative? Stef > Hi folks. We have been discussing a lot what to do with the Metacello configurations of all projects and MetacelloRepository. > We want several things: > > - Have an specific catalog of the working and tested packages/projects for each Pharo release (1.0, 1.1, etc). > - Be able to have a hudson server running and testing such configurations. > - Unified way to load a project. > > For such objectives, we propose the following scheme: > > 1) We create a squeaksource repository called Pharo10MetacelloRepository > 2) All the Metacello configurations that are known and tested to work perfect in Pharo1.0, are copied to such repository. (this takes 2 minutes) > 3) Now, we have the problem of WHICH version from the conf class should be the one that loads and works in Pharo 1.0. So, once you copied the configuration, then you have to implement a class side method "load" that loads the exact version that should work in Pharo1.0. This version may not be the last. And you already may have defined "load" to load the last version. In such case, you can just change it for the version in the Pharo10MetacelloRepository. Otherwise, we can use another message. Give us your opinion. > > So the idea is that all developers/maintainers of Metacello configurations, do that and publish it. With this, if you want to know which projects work on Pharo 1.0 you just browser Pharo10MetacelloRepository, load the repository you want, and you know that just doing "ConfigurationOfXXX" load will do the job. > > In addition to this, we are able to have a hudson server that every XX time, it scans the repository, and for each project it tries to load it and report if there is a problem. We can even make that "load" loads also the tests and make Hudson to run the tests. Or if you want we can use another message than load. > > So...this is just an idea. But we need feedback and hear opinions. Because Pharo 1.1 will be soon and would be great to have this already working for Pharo 1.0. > > Thanks > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 16, 2010