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

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

by StÃ©phane Ducasse

Yes. It makes sense may be could even have ConfigurationOfXXX freeze which could do that automatically Stef On May 16, 2010, at 6:35 PM, Mariano Martinez Peck wrote: > > > 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 > > _______________________________________________ > 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 StÃ©phane Ducasse

elliot that the format is in the image is good know. Do you know where we can find the information I imagine in VMmaker But sometimes we want to be able to script the image itself without restarting it. Stef

May 16, 2010

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

by StÃ©phane Ducasse

> Argh! Message to self: never program in bed on a Sunday morning on a 1900x1200 display with inadequate spectacles. > > seDisplayExtent: => setDisplayExtent: > > On Sun, May 16, 2010 at 9:42 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > oops iInImageFile: => inImageFile: :) for me this is more never too late after fixing the house, kids, students, excel,,,.... Friday is usually a bad day for heavy coding at night Stef

May 16, 2010

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

by Igor Stasenko

It still strikes me, why not just simply keep it in special objects in a first place? stuff := self splObj: #VariousStuff. fullScreen := stuff at: 1. width:=stuff at: 2 .. etc.. 2010/5/16 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > 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 > > > _______________________________________________ > 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 16, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Traits installer/uninstaller utility

by Johan Fabry

Yes it would be good to have better trait integration. In the mean time TraitsApplication is your man :-) On 16 May 2010, at 04:11, StÃ©phane Ducasse wrote: > this happens also for none trait. > One day we will have to do a large pass on monticello. -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

May 16, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Traits installer/uninstaller utility

by Johan Fabry

On 16 May 2010, at 03:48, Tudor Girba wrote: > I took a quick look and it looks interesting. Thanks :-) > Just a note for discussion. Executing "AspectMapsUI open" installs the traits. One of your trait extension is adding TAMStructuralZoom to FAMIXClass. > > Now, when I browse the FAMIXClass, I get this in the browser: > > ----- > FAMIXType subclass: #FAMIXClass > uses: TAMStructuralZoom > instanceVariableNames: 'isInterface' > classVariableNames: '' > poolDictionaries: '' > category: 'Famix-Core' > ----- > > There are two problems with this: > > 1. So, now if I just want to edit the base class, I have to take care and delete the Trait before, because the Trait is part of the definition. > > This is a limitation of the browser, but we have to pay attention to it. My philosophy here is to not hide anything from the developer, which is why the Trait is part of the definition. What you see is what you get. Delete the Trait when editing the base class and it goes away. What you see is what you get. So just edit the class as you want to, you can even add new Traits manually. You can always remove the TAMStructuralZoom trait (or any other trait actually) using the traits uninstaller. > 2. If you look in Monticello, the base package (FAMIX-Core in this case) is not dirty, but if you explicitly look for Changes, it gets dirty. I do not know how this could be solved. Perhaps we need extension as first class? OK this should not happen. I tried to be as close to how the browser works when redefining a class (the redefinition even gets recorded in changes) because I want to avoid breaking any magic that is going on. But apparently I did not succeed completely. If any Monticello magicians can tell me what incantation to add I would be most happy to oblige! -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

May 16, 2010

[Pharo-project] Decoding bug with XMLParser ?

by Damien Pollet

Hi, I have a failing test to show the problem, but I can't commit to the XMLSupport squeaksource, so I attach the MCZ here. Basically, if I parse an UTF-8 document with an entity like … (ellipsis), I don't get a Character with the correct #codePoint. Cheers, -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 16, 2010

Re: [Pharo-project] [ANN] Traits installer/uninstaller utility

by Johan Fabry

Hi Bill, thanks for the good wishes :-) Regarding rendering times, I dont have any problems, usual interactions are snappy. Have a look at the screencasts to see the tool in action, especially the second one ( http://pleiad.dcc.uchile.cl/research/software/aspectmaps_struct_zoom ) to see what I mean. AspectMaps is built using Moose ( http://www.moosetechnology.org ) and more specifically using an extended FAMIX model of Java as the data structure and the Mondrian ( http://www.moosetechnology.org/tools/mondrian ) visualization engine to do the visualization. I could not have done it without these tools and the guys behind the tools helping me out where I needed :-) So if you want to do some kind of visualization of data I highly recommend you to check this out! On 15 May 2010, at 21:04, Schwab,Wilhelm K wrote: > Johan, > > Best of luck with it! Taking a really quick look at your web site, this looks like something that could take a lot of time rendering graphics. Is drawing time a problem for you? Did you do anything in particular to avoid bottlenecks? I ask because I am starting to port some of my graphical code to Pharo; some of it is going from home-grown to using gnuplot, but elsewhere I was able to simply pass (Windows speak) an HDC into a function in a DLL and do a lot of rendering fairly quickly as a result. I am still looking for how to approach that in Pharo+Linux. I am starting to make my own .so's with success, but have yet to produce graphics that way. > > Bill > -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

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: > 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. Doesn't 'a' mean alpha? Levente > > 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 > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

May 16, 2010

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

by Eliot Miranda

Argh! Message to self: never program in bed on a Sunday morning on a 1900x1200 display with inadequate spectacles. seDisplayExtent: => setDisplayExtent: On Sun, May 16, 2010 at 9:42 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > 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