November 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] RC1 image build failure

by Schwab,Wilhelm K

Hello all, Whatever is happening, it keeps happening, and on two different machines, but both Ubuntu 9.10, FWIW. Attached is a shot of the whatever-it's-called window; the promised emergency evaluator does not appear (not that I would know what to do with it<g>). Comparing SharedQueue with SharedQueue2 might be interesting; with luck, there will simply be a missing method?? Bill

Nov. 3, 2009

Re: [Pharo-project] Packages in Inbox

by Mariano Martinez Peck

On Tue, Nov 3, 2009 at 6:34 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > On 3 nov. 2009, at 22:12, Torsten Bergmann wrote: > > > Why are some moose packages (Moose-Finder, Moose-OpeningWizard, ...) > > in the PharoInbox? I dont think they belong to the core? > > Indeed, I guess they were saved here by mistake. They can be safely > deleted (BTW, I dont know how to do that?) > Hi Simon. This is the way I know to remove packages or versions from MC. You must be "admin" of the repository. 1) Go to squeaksource, log in, and go to the project (PharoInbox in this case). 2) Go to "latest" tab 3) Select the package you want to remove from the list. 4) You will see that now, on the left, under the menu "actions" you have "Delete Version" and "Delete Package" actions. You may know what they do ;) Kind regards, Mariano Cyrille, can you check? > > > > > Any ideas? > > > > Bye > > T. > > -- > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 3, 2009

Re: [Pharo-project] Hide some pages from the wiki

by Mariano Martinez Peck

On Tue, Nov 3, 2009 at 3:29 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > I archive them periodically. What is the problem? It shows progress on > the wiki. > > There is no problem with the progress. The only thing is that I wouldn't like the wiki be like the squeak swiki where you have infinite number of pages and it is a mess to find something. Today, if I enter http://code.google.com/p/pharo/w/list I see a lot of pages and it is difficult for me to find what I want. IMHO it would be perfect to have only one page called "TestResults" and there you put all the links to each TestResult page. But I don't know how to achieve this with Google code wiki. Best, Mariano > Cheers > > Mike > > On Tuesday, November 3, 2009, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Hi folks! Is out there some Google Code gurÃº ? The thing is this: > there are a lot of pages for the test results. For example, TestResult10477, > TestResult10481, etc. > > > > So...the amount of pages is too much. It is difficult to find something. > I tried to see if there was a way to hide some pages from > http://code.google.com/p/pharo/w/list but I couldn't find anything. > > > > Does someone have an idea how to fix this? > > > > Best, > > > > Mariano > > > > >

Nov. 3, 2009

Re: [Pharo-project] FW: vm on ubuntu

by Schwab,Wilhelm K

John, I did not compile the vm; it is the second most recent from the Pharo web site. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Tuesday, November 03, 2009 5:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: vm on ubuntu Mmm, well assuming you compiled/linked your own VM, then in the interp.c it would have something like /* Automatically generated from Squeak on 17 September 2009 10:11:02 am by VMMaker 3.11.3 */ at the top, what does the one you have say? Oddly both supplied attributes speak of the image used, when build and compiler but speak nothing about what version the VM is, er like is this one 32/64bit clean, or 32bit address clean... An non-informed answer should be it's ok since it was compiled in feb, but without the VMMaker version number it's an uknown. On 2009-11-03, at 1:23 PM, Schwab,Wilhelm K wrote: > > > -----Original Message----- > From: Schwab,Wilhelm K > Sent: Tuesday, November 03, 2009 4:12 PM > To: johnmci(a)smalltalkconsulting.com > Subject: RE: [Pharo-project] vm on ubuntu > > John, > > My ageing image that did the mouse wheel crash is as follows: > > SmalltalkImage current getSystemAttribute: 1004 > 'Pharo0.1 of 16 May 2008 [latest update: #10074]' > > The system dictionary/error handling failure was the RC1 web image. > > Both quit using the following vm: > > SmalltalkImage current getSystemAttribute: 1006 'Unix built on Feb > 5 2009 19:38:30 Compiler: 4.1.2 (Gentoo 4.1.2 p1.3)' > > I had bad experiences with newer images, but the old image has been > very stable. One could argue that both have been flaky since I > upgraded to 9.10. My laptop chipset seems to like the new kernel, > especially in terms of reliable access to the full native resolution, > and sound works where it did not on 9.04. My desktop did not do so > well. The upgrade was quite slow. It soon presented me with a black > screen. With no response, I finally killed the power, which > apparently corrupted the swap partition. I finally got it back by > removing and re-creating the swap partition, followed by a certain > amount of forced checking that might or might not have > fixed something. Suspecting power management, I disabled putting > the display to sleep, and have not had a problem since. The package > manager crashed once on my laptop, so I do not rule out problems with > the Koala. > > Bill -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

Re: [Pharo-project] FW: vm on ubuntu

by John M McIntosh

Mmm, well assuming you compiled/linked your own VM, then in the interp.c it would have something like /* Automatically generated from Squeak on 17 September 2009 10:11:02 am by VMMaker 3.11.3 */ at the top, what does the one you have say? Oddly both supplied attributes speak of the image used, when build and compiler but speak nothing about what version the VM is, er like is this one 32/64bit clean, or 32bit address clean... An non-informed answer should be it's ok since it was compiled in feb, but without the VMMaker version number it's an uknown. On 2009-11-03, at 1:23 PM, Schwab,Wilhelm K wrote: > > > -----Original Message----- > From: Schwab,Wilhelm K > Sent: Tuesday, November 03, 2009 4:12 PM > To: johnmci(a)smalltalkconsulting.com > Subject: RE: [Pharo-project] vm on ubuntu > > John, > > My ageing image that did the mouse wheel crash is as follows: > > SmalltalkImage current getSystemAttribute: 1004 > 'Pharo0.1 of 16 May 2008 [latest update: #10074]' > > The system dictionary/error handling failure was the RC1 web image. > > Both quit using the following vm: > > SmalltalkImage current getSystemAttribute: 1006 'Unix built on Feb > 5 2009 19:38:30 Compiler: 4.1.2 (Gentoo 4.1.2 p1.3)' > > I had bad experiences with newer images, but the old image has been > very stable. One could argue that both have been flaky since I > upgraded to 9.10. My laptop chipset seems to like the new kernel, > especially in terms of reliable access to the full native > resolution, and sound works where it did not on 9.04. My desktop > did not do so well. The upgrade was quite slow. It soon presented > me with a black screen. With no response, I finally killed the > power, which apparently corrupted the swap partition. I finally got > it back by removing and re-creating the swap partition, followed by > a certain amount of forced checking that might or might not have > fixed something. Suspecting power management, I disabled putting > the display to sleep, and have not had a problem since. The package > manager crashed once on my laptop, so I do not rule out problems > with the Koala. > > Bill -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 3, 2009

Re: [Pharo-project] [Pharo-Project] Merging with Monticello

by Lukas Renggli

For cherry-picking you display the changes from your image to the code to be merged and from the context menu you choose the individual items to load. Afterwards "Adopt" the manually merged version. Lukas 2009/11/3 Gary Chambers <gazzaguru2(a)btinternet.com>: > Not that I've found. Would be nice but goes pretty deep into the guts of > MC's merge processes. If it were easy I'd have done it already. Worth a > go with a small team and/or anyone who's had a go at improving MC.I'd be > happy to help out. > > > > On Tue, 2009-11-03 at 16:07 -0300, Hernan Wilkinson wrote: >> Is there a way to control what the Monticello's Merge tool merges? I >> mean, if there is a conflict you can decide what to do, but sometimes >> there are no conflicts (like for example removing a class) and there >> is no way to tell it not to merge that... >> >> Thanks >> Hernan. >> >> _______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 3, 2009

Re: [Pharo-project] [Pharo-Project] Merging with Monticello

by Gary Chambers

Not that I've found. Would be nice but goes pretty deep into the guts of MC's merge processes. If it were easy I'd have done it already. Worth a go with a small team and/or anyone who's had a go at improving MC.I'd be happy to help out. On Tue, 2009-11-03 at 16:07 -0300, Hernan Wilkinson wrote: > Is there a way to control what the Monticello's Merge tool merges? I > mean, if there is a conflict you can decide what to do, but sometimes > there are no conflicts (like for example removing a class) and there > is no way to tell it not to merge that... > > Thanks > Hernan. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

Re: [Pharo-project] [update] 1.0 #10439

by Peter Hugosson-Miller

I guess this should be 10493, right? /Peter On Tue, Nov 3, 2009 at 10:37 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > - remove tests that depend on current font choice > - Issue 1331: DNU upon file-in of changeset > - Issue 1398: Seaside loading via ScriptManager broken > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Schwab,Wilhelm K

There are a lot of things that are worse in the Squeak image. I'm not saying this is good and should not improve, but if those selectors are spread over suitable classes (acting as entry points) with some convenience methods among the list, it's not necessarily that much worse than Dolphin's organization of it. That's a lot of "ifs" though. +1 (and then some) on the idea of making it easy to create a compiled method w/o installing it, and for making it clear (probably by where the methods are placed the selector/arguments) which versions do nothing but compile, and which versions install the method if successful. Clear comments won't hurt either. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, November 03, 2009 4:24 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Compiler compile: Things is not so easy as it looks at first sight. The problem here, i think, that compiling process is overburden with different other functionality, which not related to compiling per se, but related to recording the method source, and error handling. The compilation should be broken on stages: - creating a compiled method instance (Compiler responsibility) - installing method into class (Behavior responsibility) - announcing the change (system-change framework responsibility) the facilities which should log the change should live in separate layer, and listen for system change announcement, as well as any other tools. Because, if you look at currently the number of selectors which start from 'compile:' #compile: #compile:class: #compile:classified: #compile:classified:notifying: #compile:classified:notifying:trailer:ifFail: #compile:classified:withStamp:notifying: #compile:classified:withStamp:notifying:logSource: #compile:classified:withStamp:notifying:logSource:inClass: #compile:in:classified:notifying:ifFail: #compile:in:notifying:ifFail: #compile:in:requestor: #compile:notifying: #compile:selector: its really terrifying... 2009/11/3 Niko Schwarz <niko.schwarz(a)googlemail.com>: > Well, I can rename the compile: method and post to PharoInbox, if > anyone is interested. > > Niko > > On Tue, Nov 3, 2009 at 5:19 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> +1 too. Fewer side-effects and/or more side-effect free refactoring >> +is >> better. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Igor Stasenko" <siguctua(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, November 03, 2009 3:56 PM >> Subject: Re: [Pharo-project] Compiler compile: >> >> >>> +1 Niko. >>> There should be an easy interface for compiling the source code >>> without installing the result into system. >>> And of course, compiler should answer an instance of compiled method >>> >>> 2009/11/3 Niko Schwarz <niko.schwarz(a)googlemail.com>: >>>> Hi list, >>>> >>>> consider this code: >>>> >>>> c := Compiler compile: 'meth "bla" ^ 2'. >>>> >>> Try using >>> >>> c:= Compiler new >>> Â Â compiledMethodFor: ... >>> >>> >>> The class-side #compile:... method , is method which serves for >>> directly compiling & installing the method into receiver. >>> In the above case - into Compiler class, but you can also do that >>> for any other class: >>> >>> MyClass compile: .... >>> >>>> Here, c will be set to the symbol #meth. And Compiler will be added >>>> a new method "meth". >>>> >>>> This is of course counter-intuitive, but it's kind of wired into >>>> the system. Behavior>compile: does certainly more than compile. It >>>> compiles the code and adds it to itself, then returns the >>>> methodName as a symbol. Without mirrors, it's hard to do it right, though. >>>> >>>> Also, there's an easy method to add a method to a class, but no >>>> easy method to get a CompiledMethod object. I don't want to >>>> strongly advocate for my change, I just want to offer it. Here's >>>> what I did in my system: >>>> >>>> I changed Compiler>compile: to do the following: >>>> class side: >>>> >>>> compile: aString onClass: aClass >>>> ^ self new compiledMethodFor: aString onClass: aClass >>>> >>>> instance side: >>>> >>>> compiledMethodFor: textOrStream onClass: aClass >>>> >>>> | methodNode method | >>>> class := aClass. >>>> self from: textOrStream class: class context: nil notifying: nil. >>>> methodNode := self translate: sourceStream noPattern: false ifFail: >>>> [^self error: 'Compilation failed']. >>>> method := methodNode generate: #(0 0 0 0). >>>> self interactive ifTrue: >>>> [method := method copyWithTempsFromMethodNode: methodNode]. >>>> ^method >>>> >>>> This has its own problem, like: compile: suddenly has different >>>> semantics on Compiler than anywhere else. Best might be renaming >>>> Behavior>compile: to something more intuitive. Like >>>> #compileFromAndAdd:. >>>> >>>> Cheers, >>>> >>>> Niko >>>> >>>> _______________________________________________ >>>> 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. >>> >>> _______________________________________________ >>> 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

[Pharo-project] [update] 1.0 #10439

by Adrian Lienhard

- remove tests that depend on current font choice - Issue 1331: DNU upon file-in of changeset - Issue 1398: Seaside loading via ScriptManager broken ___________________ http://www.adrian-lienhard.ch/

Nov. 3, 2009