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

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

May 16, 2010

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

by StÃ©phane Ducasse

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. 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

May 16, 2010

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

by Mariano Martinez Peck

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

May 16, 2010

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

by Eliot Miranda

Hi Mariano, 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > 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. > I think Andreas' recent post to squeak-dev<http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150658.html>is most cogent o this topic: > > 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

Re: [Pharo-project] Pharo logo

by Henrik Sperre Johansen

On 16.05.2010 00:47, Geoffroy Couprie wrote: > Hello, > > Where can I find a vectorial version of the Pharo logo? The media > files downloadable on pharo-project.org are only in PNG and TIF. > I would like to use the logo for a custom UITheme :) > > Best regards, > > Geoffroy There's pharo-0.8.1.pdf in pharo-logos.zip, which you can import as svg in f.ex. Inkscape. Cheers, Henry

May 16, 2010

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

by Eliot Miranda

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]! ! > > 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 >

May 16, 2010

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

by Mariano Martinez Peck

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

May 16, 2010

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

by Lukas Renggli

>> Â Â 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. You can resize the window size with the Fenestri plugin, but that does not work if the image is built headless. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 16, 2010

Re: [Pharo-project] ConfigurationOfExternalWebBrowser working in Squeak and Pharo trunk

by StÃ©phane Ducasse

if this is based on applescript you get the answer :) Stef On May 16, 2010, at 2:48 PM, Hilaire Fernandes wrote: > Sean P. DeNigris a Ã©crit : >>> What is an external web browser? >>> What are its goals? >> It's an alternative to Scamper. It forwards urls to the underlying OS's >> browser e.g. on my mac, it opens the URL in a new Safari window. >> And how to we use the code in this package? >> "ExternalWebBrowser openOnUrl: 'www.squeak.org'" > > > Is it portable to different OS? Does it use a VM plugin? > > Hilaire > > > _______________________________________________ > 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] So...we freeze 1.1 ? (next steps?)

by StÃ©phane Ducasse

We are basically ready Waiting for feedback on network. Stef On May 16, 2010, at 3:48 PM, Mariano Martinez Peck wrote: > We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: > > - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image > - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) > - Make publish all new VMs (for each OS) > > Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) > > With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). > > Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. > > now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? > > Cheers > > 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