- Pharo-dev - lists.pharo.org

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

by Janko MivÅ¡ek

Hi Stef, You obviously didn't read Andreas post. Please do it, it is really good idea, which includes Metacello, it is simple and very similar to Mariano's proposal. This means that a common solution for both Squeak and Pharo is around a corner and that's what we all want! Best regards Janko On 16. 05. 2010 18:26, StÃ©phane Ducasse wrote: >> >> 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 -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

May 16, 2010

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

by StÃ©phane Ducasse

which is cool because you can learn fast :) I like to try to answer questions because this is a good way to learn. Thanks for having this cool attitude too. Stef > Hi guys. No, it doesn't work for me neither. I have checked in Pharo 1.0 and 1.1 with both: useOldNetwork as true and false. > > I have debugged a little the: > > Socket ping: 'localhost' > > And the problem I found is that after calling "connectNonBlockingTo: hostAddress port: port" > > self primSocketConnectionStatus: socketHandle. > > should answer something different thanUnconnected ( 0 ), like WaitingForConnection (1) or Connected (2) > check Socket class >> initialize > > So....I should see in VM side why primSocketConnectionStatus: socketHandle. may be returning 0 (unconnected). > > Now...if I ping > > Socket ping: 'www.google.com' > > The result is different as I get WaitingForConnection (1) instead of 0....but it loops forever as I always get 1 and never 2....see the loop > > [(status = WaitingForConnection) and: [(msecsEllapsed := Time millisecondsSince: startTime) < msecsDelta]] > whileTrue: [ > semaphore waitTimeoutMSecs: msecsDelta - msecsEllapsed. > status := self primSocketConnectionStatus: socketHandle]. > > in the method waitForConnectionFor: timeout ifTimedOut: timeoutBlock > > I will continue to check, but my knowledge in this area is almost nil. > > Cheers > > Mariano > > On Sun, May 16, 2010 at 8:30 PM, RickT <Rick(a)emarysville.com> wrote: > > Hi Stefan, > > Mariano asked me to try using that method to set UseOldNetwork. > > I only was testing the class method Socket>>ping: from the workspace, and it > always timed out. > > It also did not work in the Pharo1.1 image that Mariano asked me to try. > > Thanks! > -- > 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

May 16, 2010

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

by Mariano Martinez Peck

Hi guys. No, it doesn't work for me neither. I have checked in Pharo 1.0 and 1.1 with both: useOldNetwork as true and false. I have debugged a little the: Socket ping: 'localhost' And the problem I found is that after calling "connectNonBlockingTo: hostAddress port: port" self primSocketConnectionStatus: socketHandle. should answer something different thanUnconnected ( 0 ), like WaitingForConnection (1) or Connected (2) check Socket class >> initialize So....I should see in VM side why primSocketConnectionStatus: socketHandle. may be returning 0 (unconnected). Now...if I ping Socket ping: 'www.google.com' The result is different as I get WaitingForConnection (1) instead of 0....but it loops forever as I always get 1 and never 2....see the loop [(status = WaitingForConnection) and: [(msecsEllapsed := Time millisecondsSince: startTime) < msecsDelta]] whileTrue: [ semaphore waitTimeoutMSecs: msecsDelta - msecsEllapsed. status := self primSocketConnectionStatus: socketHandle]. in the method waitForConnectionFor: timeout ifTimedOut: timeoutBlock I will continue to check, but my knowledge in this area is almost nil. Cheers Mariano On Sun, May 16, 2010 at 8:30 PM, RickT <Rick(a)emarysville.com> wrote: > > Hi Stefan, > > Mariano asked me to try using that method to set UseOldNetwork. > > I only was testing the class method Socket>>ping: from the workspace, and > it > always timed out. > > It also did not work in the Pharo1.1 image that Mariano asked me to try. > > Thanks! > -- > 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] 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