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

Re: [Pharo-project] Packages in Inbox

by Simon Denier

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?) 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

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Igor Stasenko

2009/11/3 Lukas Renggli <renggli(a)gmail.com>: >> Well, I can rename the compile: method and post to PharoInbox, if >> anyone is interested. > > Also I agree that it is confusing, but there are tons of projects that > depend on this function. #compile: and #compile:classified: are about > the only two compiler related methods that are available cross > platform. If you rename them you will break any code that compiles > something, including the Refactoring Browser, SmaCC, OmniBrowser, > Seaside (for the file libraries), etc. > You are right , of course. But inner API should be simplified. For instance, take a look at compiler invocation here: self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock. i really don't understand, why compiler would be interested in a method's category? What is the purpose of passing this extra info to compiler? The main purpose of compiler is to produce the CompiledMethod instance, and compiler should not care about anything related to installation of the resulting method into class and its categorization. > 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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Igor Stasenko

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.

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Lukas Renggli

> Well, I can rename the compile: method and post to PharoInbox, if > anyone is interested. Also I agree that it is confusing, but there are tons of projects that depend on this function. #compile: and #compile:classified: are about the only two compiler related methods that are available cross platform. If you rename them you will break any code that compiles something, including the Refactoring Browser, SmaCC, OmniBrowser, Seaside (for the file libraries), etc. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 3, 2009

[Pharo-project] FW: vm on ubuntu

by Schwab,Wilhelm K

-----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 ________________________________________ From: John M McIntosh [johnmci(a)smalltalkconsulting.com] Sent: Tuesday, November 03, 2009 2:21 PM To: Schwab,Wilhelm K Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] vm on ubuntu Well beyond the simple memory access violation (seg fault) type of failure then. (a) if you have configured your vm to use a limited amount of memory and you enter a recursive loop the VM likely will thrash thru the available memory in a small number of milliseconds on a fast machine then exit(). I believe by default it's 1GB, but if there is no paging involved to find 1GB of ram it can happen quite quickly. (b) Older unix/linux vm are susceptible to crashing if they expand image memory over the 2GB address boundary. I can't say exactly what version that would be, but if you supply the build information for your VM SmalltalkImage current getSystemAttribute: 1004 and SmalltalkImage current getSystemAttribute: 1006 That might give a clue to if the fixes for the problem are in the VM you are using. On 2009-11-03, at 11:08 AM, Schwab,Wilhelm K wrote: > John, > > I would be happy to give a reproducible example, but one eludes me at > present. To add to the fun, I have now seen the image quit on a > second Linux box; this time, my laptop. I am fairly certain that it > crashed over a mouse wheel event. > > Both machines are running Ubuntu 9.10, which might be the trigger of > my new-found hassles. > > Bill > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 3, 2009

[Pharo-project] Packages in Inbox

by Torsten Bergmann

Why are some moose packages (Moose-Finder, Moose-OpeningWizard, ...) in the PharoInbox? I dont think they belong to the core? Any ideas? Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Nov. 3, 2009

[Pharo-project] JPEG plugin.

by John M McIntosh

I'm looking at the JPEG plugin and wondering? (a) Should I convert that to using the os-x platforms JPEG implementation, versus our usage of the source from the "Independent JPEG Group's software" ? (b) Should we consider upgrading the VMs from version "6b 27- Mar-1998" to the more current "release 7 of 27-Jun-2009" since we store the source in the VM SVN tree at the moment. I've not looked but (a) Apple might have a private implementation that could be faster since it would likely use hardware vector services. (b) Relying on the system libraries for conversion means fixes for security issues get prompt attention, versus our non-attention now. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Niko Schwarz

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 >

Nov. 3, 2009

Re: [Pharo-project] vm on ubuntu

by Michael Roberts

well i was being slightly rhetorical. I don't think it makes sense to zip the sources, it has no value to me. If you are going to be building VMs then you must learn how that sub-community & process works. We should link the information John has provided somewhere. I would suggest detail on a wiki page, and a link off the pharo-project page for those too curious. cheers, Mike On Tue, Nov 3, 2009 at 6:56 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Mike, > > A link would be great. Â A zip file would no doubt help some too, though > > Â http://squeakvm.org/cgi-bin/viewcvs.cgi/ > > linked from > > Â http://squeakvm.org/unix/ > > is perhaps better than a zip. Â I _think_ users of a zip would want to see an individual file or two to check a theory about a bug or to see how something works; anyone setting out to build a vm would probably want to grab the latest source. > > Thanks! > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Roberts > Sent: Tuesday, November 03, 2009 1:27 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] vm on ubuntu > > The vm sources are in svn. You want them snapshotted in a zip? > > Perhaps just a link to the vm web page would do. > > Cheers mike > > On Tuesday, November 3, 2009, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> 2009/10/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.xn--edu-kla <javascript:_e({}, >> 'cvml', 'bschwab(a)anest.ufl.edu');>> >> >> >> >> >> >> >> Agreed that naming it Pharo would be better, but the name is of less >> interest to me than the vm sources.Â If there are Pharo-specific >> changes, I do not see them anywere?? >> >> +1Â This was discussed in another thread, but I cannot find it right now. It would be VERY useful to have VM sources uploaded to the webpage. The problem is I don't know where to get the VM sources neither the plugins. >> >> I know a lot of people that stands "I won't put something in production if I cannot build it by myself". So, having the sources in the webpage is something good I think. >> >> Cheers >> >> Mariano >> >> >> Bill >> >> >> >> From: >> pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Mariano Martinez Peck >> Sent: Saturday, October 31, 2009 11:44 AM >> To: >> Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] vm on >> ubuntu >> >> >> Hi Doru: In a wonderful world, you would have latest PharoVM in the >> Ubuntu repositories and for all Ubuntu verions. In the real world, >> this is not done. The squeak or Pharo VM that usually are at the >> repositories are old and not for all Ubuntu versions. Thus, I think >> the easiest way to install it, is this (as Dale said): >> >> 1) Download the VM from here >> http://gforge.inria.fr/frs/download.php/22745/pharo-vm-0.15.2d-linux.z >> ip >> >> 2) Unzip it somewhere. >> 3) And then you can just execute VM. Suppose you uncompress the zip in >> /home/doru/pharoVM/pharo-vm-0.15.2d-linux/ >> Then you >> can open a terminal an do >> /home/doru/pharoVM/pharo-vm-0.15.2d-linux/squeak >> Â /home/doru/pharo-images/myxxximage.image >> >> Now I notice that it >> would be better if the executable file is called pharo instead of >> squeak >> >> That's all. >> >> Best >> >> Mariano >> >> On Sat, Oct 31, 2009 at 9:09 AM, Tudor Girba <tudor.girba(a)gmail.com >> <javascript:_e({}, 'cvml', 'tudor.girba(a)gmail.com');>> >> wrote: >> Hi, >> >> What >> Â is the preferred way to install a Pharo vm on >> Â Ubuntu? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "From an abstract enough point of >> Â view, any two things are >> Â similar." >> >> >> >> >> _______________________________________________ >> 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 >

Nov. 3, 2009

Re: [Pharo-project] IRC link in webpage is wrong

by Adrian Lienhard

Torsten, thanks for the link. I added it. Adrian On Nov 3, 2009, at 13:10 , Torsten Bergmann wrote: > We can also link to http://webchat.freenode.net/?channels=pharo- > project > providing access using a browser... > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla > Firefox 3.5 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser > > _______________________________________________ > 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