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

Re: [Pharo-project] Pharo core and Seaside 3.0

by Schwab,Wilhelm K

I am trying understand how to cope with yet another change. In my own world, newer is always better (to avoid losing work), and anything more sophisticated than that will only cause trouble. No argument that a package management system is a good thing for complicated projects released to large audiences. But I fail to see how having all of using many lines of code for (what should be for the consumer) simple tasks does any good over Gofer loadSeaside28 with its entrails coded in terms of the correct way to load the thing. The way this is trending, you will end up with people using the wrong version or whatever else is needed to make the package management system do the right thing. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Tuesday, January 12, 2010 4:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo core and Seaside 3.0 El mar, 12-01-2010 a las 14:41 -0500, Schwab,Wilhelm K escribiÃ³: > With stipulation of the fact that helper methods can be taken too far, > what is wrong with something like > > Gofer loadSeaside28? > > Answer: nothing if it hides the details of using the configuration. The problem with the FFI, Seaside, etc. load methods is not that they exist, it is that they use obsolete techniques and/or are broken. > > One question in my mind is how to replace ScriptLoader > class>>loadLatestPackage:fromRepository:. Will > > Gofer new > add:packageName; > repository:aRepository; > load > > take care of that? Have you at least read the tutorial of Metacello, they very clearly show why is necessary a package management tool and not only a packag installer (what gofer is). Remember, one tool for the job. A tool can't do everything. The best is to have gofer to download/install/uninstall/update/remove individual packages inside the image, and metacello keep track of dependencies, configuration, groups of packages loaded together, groups of packages for distinct forks, etc. And again, ScriptLoader, as I understand it, was never intended for public comsumption. It is in the image because the group releasing pharo and squeak was very small and needed a tool for preparing the image in a time when no proper package management tool existed. Now that tool exist and there is no reason to keep the old tools no matter how many pages you find in google pointing to obsolete instructions. They will be substituted by new docs/tutorials/blog posts that use the new tools. Meanwhile, there will be confusion, granted, but in the end it will be better than the mess we have now. Cheers > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > StÃ©phane Ducasse > Sent: Tuesday, January 12, 2010 1:36 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo core and Seaside 3.0 > > > On Jan 12, 2010, at 7:25 PM, Lukas Renggli wrote: > > >> And also the class side install methods of Gofer please. > >> > >> Lets clean the way for Gofer as downloader/installer, Metacello as > >> package management tools. > > > > These are examples to demonstrate how gofer works. They are not > > supposed to be called for loading stuff. > > > > I am just using them all the time to keep my images up to date :-) > > :) > well this was the same for scriptLoader :) I will pay attention to > scriptLoader > > Stef > > > > > Lukas > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 12, 2010

Re: [Pharo-project] [Fwd: Re: [squeak-dev] Re: The Trunk: Morphic-ar.305.mcz]

by Miguel Enrique CobÃ¡ Martinez

El mar, 12-01-2010 a las 21:18 +0100, StÃ©phane Ducasse escribiÃ³: > for 1.1 > > only critical fixes should go in 1.0 and 1.0 should get out of the door :) > >> Ok > > > > The real solution here is to send 'is: #ScriptEditorMorph' and implement > > > > Object >> is: aSymbol > > "A means for cleanly replacing all isXXX like methods. > > Please use judiciously! > > Suggested by Igor Stasenko at > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html" > > > > ^false > > > > ScriptEditorMorph >> is: aSymbol > > ^ aSymbol = #ScriptEditorMorph or: [ super is: aSymbol ] > > > > In this way you easily get rid of all #isXXX methods (at least, all that just answer the true or false constants). Much more interesting: when you unload EToys there is no knowledge about ScriptEditorMorph in unrelated classes (such as Morph or Object). > > > we do not have etoy related is: methods.... > or we can remove it just straight > Now I somehow like the idea. Yes, is only to have a neutral way to test for equality with some given class, be this etoys, seaside or whatever someone want to test an object against. In fact the method does nothing by itself nor changes the image in a given way. It is required that all the code that has methods isXXX is changed to use the new way to test class membership. But 1.1 is ok with me. Cheers > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

Re: [Pharo-project] Monticello gives me new version numbers when I just want to publish a fix to PharoInbox

by Matthias Berth

Gary, Simon, thanks a lot -- I'll do a copy then. Cheers Matthias On Tue, Jan 12, 2010 at 7:10 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > You should open your package cache repository and, for the required version, > choose "copy" then select the PharoInbox repository as destination. > > Might be nice if MC effectively did this for saving working copies of saved > versions that have no changes. > > Regards, Gary > > ----- Original Message ----- > From: "Miguel Enrique CobÃ¡ Martinez" <miguel.coba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, January 12, 2010 6:03 PM > Subject: Re: [Pharo-project] Monticello gives me new version numbers when I > just want to publish a fix to PharoInbox > > >> El mar, 12-01-2010 a las 18:52 +0100, Matthias Berth escribiÃ³: >>> Hi, >>> >>> >>> I was following >>> >>> Â http://code.google.com/p/pharo/wiki/HowToContribute >>> >>> I have saved the patched package into my package-cache, giving >>> Network-Protocols-MatthiasBerth.17.mcz. Then I restarted the image >>> (pharo core 1.0rc 10505). >>> >>> Then I wanted to save to PharoInbox, by selecting PharoInbox in >>> Monticello browser and clicking "save". Monticello asked for my >>> initials (no problem) and then it gave the package a new version >>> number Network-Protocols-MatthiasBerth.18.mcz. Is that expected >>> behavior? I cancelled that because I did not want to increase the >>> version number. >>> >>> I tried again, now by following the instructions to the letter and >>> pressing the +Repository button. Same problem, even worse: now I got >>> version 19 (Network-Protocols-MatthiasBerth.19.mcz). >>> >>> Do others see the same problem? Am I doing something stupid here? >> >> Same happens to me. I don't care for the numbers :) >> >>> >>> >>> Cheers >>> >>> Matthias >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 12, 2010

Re: [Pharo-project] Corrupted Monticello

by Benoit St-Jean

Hope this helps to interrupt : http://wiki.squeak.org/squeak/899 http://wiki.squeak.org/squeak/1542 ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Mariano Martinez Peck <marianopeck(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr Sent: Tue, January 12, 2010 4:02:41 PM Subject: Re: [Pharo-project] Corrupted Monticello Try a system interrupt as Stef said. I don't remember the shortcut.... ctrl . - ? Maybe a problem with the UUID plugin ? You said you have mac os and Linux, it happens in both ? Cheers On Tue, Jan 12, 2010 at 5:57 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >Would CPU be 99% if he were blocking on a semaphore? > >>Cheers, >>Henry > > >>On 12.01.2010 21:54, StÃ©phane Ducasse wrote: >>> when you say freeze do you wait enough for a network time out. >>> Because if you bug is related to a network problem you may be block in a smeaphore >>> Did you try to do command . to get a debugger. >>> >>> Stef >>> >>> On Jan 12, 2010, at 9:47 PM, John Toohey wrote: >>> >>> >>>> Yep. >>>> 1. Download PharoCore. >>>> 2. Install Lukas's development environment via Gofer >>>> 3. Via Gofer install Seasside 3, JQWidgetBox, GlorpDBX, and my apps >>>> 4. Update a method and do do a Gofer commit or: Browse a repo with MC, and click on a package name >>>> Image freezes. >>>> >>>> With 10504, there were failing MC tests, and these errors had appeared in an earlier image, which is why I started to update to the latest images. The tests work in 10506, but somewhere in the process I corrupt MC. >> >>> >>>> On Tue, Jan 12, 2010 at 15:39, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: >>>> this is strange. can you reproduce the problem? >>>> >>>> >>>> Stef >>>> >>>> On Jan 12, 2010, at 4:21 PM, John Toohey wrote: >>>> >>>> >>>>> Rebuilt a new image from scratch, using the rc1 Core image, and everything was fine, until I did a "Save As" in order to rename the image. After that MC stops working again. Just completing another rebuild now, and will try to move the renamed image to another directory, before using MC again. >> >>>> >>>>> >>>>> 2010/1/12 Mariano Martinez Peck<marianopeck(a)gmail.com> >>>>> And what about what I told you about reloading again the two versions? >>>>> >>>>> Sometimes I have problems with my proxy and I have to evaluate: >>>>> >>>>> HTTPSocket stopUsingProxyServer. >>>>> >>>>> >>>>> 2010/1/11 John Toohey<jt(a)parspro.com> >>>>> Did the cleanUpForRelease, but MC still hangs. Do you know what DEV image is the most stable right now, or is there a way to enable debug output from MC? >>>>> >>>>> >>>>> 2010/1/11 Mariano Martinez Peck<marianopeck(a)gmail.com> >>>>> >>>>> Maybe you can reload the Monticello and MonticelloGUI package from the repository Pharo. However, I would check in that 10496 image which were the versions of those two packages and I would download exactly those two versions. >> >>>> >>>>> Maybe you can also try to remove the package cache and also evaluate (backup the image first): >>>>> >>>>> MCFileBasedRepository flushAllCaches. >>>>> MCMethodDefinition shutDown. >>>>> MCDefinition clearInstances. >>>>> >>>>> Or even >>>>> >>>>> ScriptLoader new cleanUpForRelease >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> >>>>> 2010/1/11 John Toohey<jt(a)parspro.com> >>>>> Hi, >>>>> I've just built a new image based on PharoCore1.0rc1 Latest update: #10496, and MC freezes the image whenever I try to open a package. I can view a repo, but not open or load the packages. Is there anyway to rebuild MC, without rebuilding the entire image again? There is no debug file written out, just the CPU pegged at 99% and an unresponsive image. >> >>>> >>>>> -- >>>>> -JT >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> -JT >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> -JT >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> -- >>>> -JT >>>> >>>> >>>> _______________________________________________ >>>> 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 > __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/

Jan. 12, 2010

Re: [Pharo-project] Pharo core and Seaside 3.0

by Miguel Enrique CobÃ¡ Martinez

And to hopefully put an end to the discussion, the current no-package-management-tool situation is akin to the windows world where there are thousands of installers (.cab, .exe, .zip, etc) for each of the available applications. Where we want to get is to the Linux world that have a pair of standardized tools to do *proper* package management that upload a given installation by updating all the appropriate packages and solving the dependencies and conflicts that may occur. This for example, permits to upgrade a debian installation between major releases without need to reinstall everything each time. In this order of ideas, Pharo Debian(deb based) Fedora (rpm based) Metacello aptitude yum Gofer dpkg rpm Monticello .deb package .rpm package SAR/changeset .tar.gz .tar.gz not exactly equivalent but roughly. Cheers > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, January 12, 2010 1:36 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo core and Seaside 3.0 > > > On Jan 12, 2010, at 7:25 PM, Lukas Renggli wrote: > > >> And also the class side install methods of Gofer please. > >> > >> Lets clean the way for Gofer as downloader/installer, Metacello as > >> package management tools. > > > > These are examples to demonstrate how gofer works. They are not > > supposed to be called for loading stuff. > > > > I am just using them all the time to keep my images up to date :-) > > :) > well this was the same for scriptLoader :) I will pay attention to scriptLoader > > Stef > > > > > Lukas > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

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

by StÃ©phane Ducasse

On Jan 12, 2010, at 1:32 PM, Fernando olivero wrote: > Stef, i've started from CUIS. > > This is what i have done so far. > > 1. Added the System-TextAttributes category > 2. Moved the classes from Collections-Text to System-TextAttributes > 3. Added System-Text category > 4. Move Text from Collections-Text to System-Text. > 5. File in CUIS new classes: Editor, SimpleEditor, TextEditor and SmalltalkEditor. > 6. Removed Collections-Text category. > > Problems started here: > > > 7. > Merge CUIS Text class with Pharo Text class. > > (Cuis) Text has an attribute named initialStyle not present in (Pharo) Text. This is the main diff from both images. > > > 8. Merge CUIS NewParagraph with Pharo NewParagraph > > (Pharo) NewParagraph has an attribute named textStyle not present in (Cuis) Pharo. > > In several NewParagraph methods CUIS doesn't care is some strings are isOctetString, and the Pharo NewParagraph does. For example #composeAll. > I've preserved the Pharo behavior. > > > Maybe i should start with the Squeak port then? yes > > > Further steps: > > 9. Merge (cuis) TextMorph and (pharo) TextMorph, making it have a non-smalltalk,TextEditor. > > 10. Create (pharo) CodeMorph, replacing a TextMorph with a SmalltalkEditor. > To my opinion , this will the major contribution, separating TextEditor and SmalltlakEditor concernes and their proper views , TextMorph and CodeMorph. > > > Fernando > > > On Jan 10, 2010, at 10:43 PM, StÃ©phane Ducasse wrote: > >> Excellent fernando! >> Did you start from squeak or cuis >> I was planning to start from Squeak since they ported back CUIS code in the context >> of WideStrings (CUIS is pre unicode support) >> >> Stef >> >>> Juan re-factored the smalltalk behavior in the editors, creating the following hierarchy >>> >>> Editor >>> TextEditor SimpleEditor >>> SmalltalkEditor >>> >>> >>> See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html. >>> >>> New text editors. >>> TextEditor provides most of the functionality that used to be in TextMorphEditor. This class is no longer a Controller! >>> >>> SmalltalkEditor is has Smalltalk code specific features. >>> >>> SimpleEditor provides basic functionality for single line text editing. It does not handle fonts and styles, aligning and Smalltalk utilities. It handles one single line. >>> >>> Would be nice to adopt this refactoring into Pharo, i've started to port it and cleaning up the textmorph in the process. But it's still a work in progress. >>> >>> Fernando >>> >>> On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>>> Gary and others >>>>> >>>>> I really think that we should do an audit of Morphic. In 1.1 we are >>>>> going already faster but I'm sure that there is plenty >>>>> of space for improvements. >>>>> >>>>> I see several actions >>>>> - checking squeak toolbuilder enhancements and using it for the tools >>>>> >>>>> - checking CUIS >>>>> - juan did an excellent job remocving a lot of unnecessary code >>>>> - juan optimize scrollbar >>>>> - juan did a new texteditor morph >>>> >>>> Indeed, a text editor that does not hardcode smalltalk specific >>>> behavior would be great :). >>>> >>>>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>>>> - integrating better polymorph into the widgets layer. >>>>> >>>>> What do you think? >>>> >>>> >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 12, 2010

Re: [Pharo-project] Pharo core and Seaside 3.0

by StÃ©phane Ducasse

+1 > Remember, one tool for the job. A tool can't do everything. The best is > to have gofer to download/install/uninstall/update/remove individual > packages inside the image, and metacello keep track of dependencies, > configuration, groups of packages loaded together, groups of packages > for distinct forks, etc. > > And again, ScriptLoader, as I understand it, was never intended for > public comsumption. It is in the image because the group releasing pharo > and squeak was very small and needed a tool for preparing the image in a > time when no proper package management tool existed. Now that tool exist > and there is no reason to keep the old tools no matter how many pages > you find in google pointing to obsolete instructions. They will be > substituted by new docs/tutorials/blog posts that use the new tools. > > Meanwhile, there will be confusion, granted, but in the end it will be > better than the mess we have now.

Jan. 12, 2010

Re: [Pharo-project] Pharo core and Seaside 3.0

by Miguel Enrique CobÃ¡ Martinez

El mar, 12-01-2010 a las 14:41 -0500, Schwab,Wilhelm K escribiÃ³: > With stipulation of the fact that helper methods can be taken too far, what is wrong with something like > > Gofer loadSeaside28? > > Answer: nothing if it hides the details of using the configuration. The problem with the FFI, Seaside, etc. load methods is not that they exist, it is that they use obsolete techniques and/or are broken. > > One question in my mind is how to replace ScriptLoader class>>loadLatestPackage:fromRepository:. Will > > Gofer new > add:packageName; > repository:aRepository; > load > > take care of that? Have you at least read the tutorial of Metacello, they very clearly show why is necessary a package management tool and not only a packag installer (what gofer is). Remember, one tool for the job. A tool can't do everything. The best is to have gofer to download/install/uninstall/update/remove individual packages inside the image, and metacello keep track of dependencies, configuration, groups of packages loaded together, groups of packages for distinct forks, etc. And again, ScriptLoader, as I understand it, was never intended for public comsumption. It is in the image because the group releasing pharo and squeak was very small and needed a tool for preparing the image in a time when no proper package management tool existed. Now that tool exist and there is no reason to keep the old tools no matter how many pages you find in google pointing to obsolete instructions. They will be substituted by new docs/tutorials/blog posts that use the new tools. Meanwhile, there will be confusion, granted, but in the end it will be better than the mess we have now. Cheers > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Tuesday, January 12, 2010 1:36 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo core and Seaside 3.0 > > > On Jan 12, 2010, at 7:25 PM, Lukas Renggli wrote: > > >> And also the class side install methods of Gofer please. > >> > >> Lets clean the way for Gofer as downloader/installer, Metacello as > >> package management tools. > > > > These are examples to demonstrate how gofer works. They are not > > supposed to be called for loading stuff. > > > > I am just using them all the time to keep my images up to date :-) > > :) > well this was the same for scriptLoader :) I will pay attention to scriptLoader > > Stef > > > > > Lukas > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 12, 2010

Re: [Pharo-project] Corrupted Monticello

by John Toohey

- Can't break out of it. - Where are the plugins stored for an image, should I have a directory for this? 2010/1/12 Mariano Martinez Peck <marianopeck(a)gmail.com> > Try a system interrupt as Stef said. I don't remember the shortcut.... > ctrl . - ? > > Maybe a problem with the UUID plugin ? You said you have mac os and > Linux, it happens in both ? > > Cheers > > > On Tue, Jan 12, 2010 at 5:57 PM, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> Would CPU be 99% if he were blocking on a semaphore? >> >> Cheers, >> Henry >> >> On 12.01.2010 21:54, StÃ©phane Ducasse wrote: >> > when you say freeze do you wait enough for a network time out. >> > Because if you bug is related to a network problem you may be block in a >> smeaphore >> > Did you try to do command . to get a debugger. >> > >> > Stef >> > >> > On Jan 12, 2010, at 9:47 PM, John Toohey wrote: >> > >> > >> >> Yep. >> >> 1. Download PharoCore. >> >> 2. Install Lukas's development environment via Gofer >> >> 3. Via Gofer install Seasside 3, JQWidgetBox, GlorpDBX, and my apps >> >> 4. Update a method and do do a Gofer commit or: Browse a repo with MC, >> and click on a package name >> >> Image freezes. >> >> >> >> With 10504, there were failing MC tests, and these errors had appeared >> in an earlier image, which is why I started to update to the latest images. >> The tests work in 10506, but somewhere in the process I corrupt MC. >> >> >> >> On Tue, Jan 12, 2010 at 15:39, StÃ©phane Ducasse< >> stephane.ducasse(a)inria.fr> wrote: >> >> this is strange. can you reproduce the problem? >> >> >> >> >> >> Stef >> >> >> >> On Jan 12, 2010, at 4:21 PM, John Toohey wrote: >> >> >> >> >> >>> Rebuilt a new image from scratch, using the rc1 Core image, and >> everything was fine, until I did a "Save As" in order to rename the image. >> After that MC stops working again. Just completing another rebuild now, and >> will try to move the renamed image to another directory, before using MC >> again. >> >>> >> >>> >> >>> 2010/1/12 Mariano Martinez Peck<marianopeck(a)gmail.com> >> >>> And what about what I told you about reloading again the two versions? >> >>> >> >>> Sometimes I have problems with my proxy and I have to evaluate: >> >>> >> >>> HTTPSocket stopUsingProxyServer. >> >>> >> >>> >> >>> 2010/1/11 John Toohey<jt(a)parspro.com> >> >>> Did the cleanUpForRelease, but MC still hangs. Do you know what DEV >> image is the most stable right now, or is there a way to enable debug output >> from MC? >> >>> >> >>> >> >>> 2010/1/11 Mariano Martinez Peck<marianopeck(a)gmail.com> >> >>> >> >>> Maybe you can reload the Monticello and MonticelloGUI package from the >> repository Pharo. However, I would check in that 10496 image which were the >> versions of those two packages and I would download exactly those two >> versions. >> >>> >> >>> Maybe you can also try to remove the package cache and also evaluate >> (backup the image first): >> >>> >> >>> MCFileBasedRepository flushAllCaches. >> >>> MCMethodDefinition shutDown. >> >>> MCDefinition clearInstances. >> >>> >> >>> Or even >> >>> >> >>> ScriptLoader new cleanUpForRelease >> >>> >> >>> Cheers >> >>> >> >>> Mariano >> >>> >> >>> >> >>> 2010/1/11 John Toohey<jt(a)parspro.com> >> >>> Hi, >> >>> I've just built a new image based on PharoCore1.0rc1 Latest update: >> #10496, and MC freezes the image whenever I try to open a package. I can >> view a repo, but not open or load the packages. Is there anyway to rebuild >> MC, without rebuilding the entire image again? There is no debug file >> written out, just the CPU pegged at 99% and an unresponsive image. >> >>> >> >>> -- >> >>> -JT >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >>> >> >>> >> >>> -- >> >>> -JT >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >>> >> >>> >> >>> -- >> >>> -JT >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> >> >> >> >> >> -- >> >> -JT >> >> >> >> >> >> _______________________________________________ >> >> 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 > -- -JT

Jan. 12, 2010

Re: [Pharo-project] Error when i try save a image [WAS]Fwd:[BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Mariano Martinez Peck

On Tue, Jan 12, 2010 at 5:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > do we add that to the bug entry? > > Ok....done, but I am not sure at all of that. I was just thinking aloud :) nullPointer can you check also if my commits work ? becasue I have an strange behaviour after that and it is that sometimes when I move the class browser it comes back to the original place instead to the pleace where i let it. > On Jan 12, 2010, at 1:54 PM, Mariano Martinez Peck wrote: > > > Another ugly hack maye replace this: > > > > FT2Handle shutDown: > > > > > > shutDown: quitting > > "we must not save handles (which are pointers) in the image" > > self clearRegistry. > > FreeTypeFace allInstances do:[:i | > > "destroy any faces that are still being referenced" > > i isValid > > ifTrue:[i destroyHandle ]]. > > FT2Handle allSubInstances do: [:h | h beNull]. "if some handle was > not registered" > > > > For this: > > > > shutDown: quitting > > "we must not save handles (which are pointers) in the image" > > self clearRegistry. > > FreeTypeFace allInstances do:[:i | > > "destroy any faces that are still being referenced" > > i isValid > > ifTrue:[[i destroyHandle] on: Error do: ["Log somewhere this > error, but don't throw an error as it wont save the image"] ]]. > > FT2Handle allSubInstances do: [:h | h beNull]. "if some handle was > not registered" > > > > > > > > I mean, if you are executing the shutDown: and the primitive gives an > error, there is not too much you can do about it. So, at least, let me save > the image. > > > > Of course, this is a really ugly huck, not near a fix. But, if there is > no one that can help us... > > > > cheers > > > > mariano > > > > 2010/1/12 Gary Chambers <gazzaguru2(a)btinternet.com> > > Actually, the VM was the string as from SmalltalkImage current vmVersion. > > > > Pharo.exe reports its version (file properties) as 3.11.4.0 > > > > Regards, Gary > > ----- Original Message ----- > > From: Mariano Martinez Peck > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Tuesday, January 12, 2010 11:27 AM > > Subject: Re: [Pharo-project] Error when i try save a image > [WAS]Fwd:[BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 > > > > > > > > 2010/1/12 Gary Chambers <gazzaguru2(a)btinternet.com> > > I am seeing the same behaviour also, on occasion. > > > > > > Which OS do you use ? Mac OS? VM ? maybe there is a problem in the plugin > ? > > > > > > Regards, Gary > > ----- Original Message ----- > > From: Mariano Martinez Peck > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Tuesday, January 12, 2010 11:02 AM > > Subject: Re: [Pharo-project] Error when i try save a image [WAS] > Fwd:[BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 > > > > The problem is that when you save the image, in the shutDown list, there > is freetype and it tries to finish all the handlers. The problem in this > case is that one of those handlers that seems to be trying to finish has > something in nil or some bad parameter which of course, gives a primitive > mail. That's all my idea, maybe I am wrong as it is the first time I look in > this code. > > > > As a work arround, you can install the StrikeFOnts instead of TrueTypes. > It is not > > the real solution, but works. Just take the dev image with trutype and > evaluate: > > > > FreeTypeCache clearCurrent. > > StrikeFont installDejaVu. > > > > > > Cheers > > > > On Mon, Jan 11, 2010 at 5:30 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > I could reproduce the problem. epicfan which OS are you using ? VM > version ? > > > > > > On Mon, Jan 11, 2010 at 5:18 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > yes, actually that's was the mail about. > > > > > > > > On Mon, Jan 11, 2010 at 5:11 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Do Yyou still have the problem with the latest rc version? > > > > Stef > > On Jan 11, 2010, at 5:02 PM, Mariano Martinez Peck wrote: > > > > > Sorry epicfan I have no idea at all. I cc Pharo mailing list that maybe > someone can help you. > > > > > > I was going to cc nullPointer, but I discover it is you!!! hahahahah > > > > > > > > > ---------- Forwarded message ---------- > > > From: <epicfan(a)gmail.com> > > > Date: Mon, Jan 11, 2010 at 4:46 PM > > > Subject: Re: [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 > > > To: marianopeck(a)gmail.com > > > > > > > > > The next error: > > > > > > > http://code.google.com/p/pharo/issues/detail?id=1283&can=7&q=bug%20when%20t… > > > > > > In the last version of developer image that error was fix it. But in > that 10505 image returns :| > > > > > > Regards. > > > > > > > > > > > > > > > PD. Could I do something in my code for delete that problem? > > > > > > Regards again. > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 12, 2010