March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] Running tests for auto-built Cog VMs
by Mariano Martinez Peck March 18, 2011

March 18, 2011

On Fri, Mar 18, 2011 at 2:26 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Thu, Mar 17, 2011 at 6:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> On 18 March 2011 01:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > >> > On Thu, Mar 17, 2011 at 10:29 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> Hello all. >> >> >> >> Our next plan is to extend the Hudson build jobs with tests which are >> >> run after VM has built. >> >> >> >> I'd like to ask, what kind of tests we should run for VMs. >> >> >> >> So, here's my questions: >> >> >> >> - do we need a VM specific tests? Or we just use ordinal tests which >> >> are in image(s) by default? >> > >> > SOme of the standard tests in the Squeak 4.2 suite are specifically for >> VM stuff. The entire suite depends on the VM in some way. It seems >> straight-forward to include tests for specific pieces of functionality, for >> example the mirror primitives, cannotInterpret: and objects-as-methods. >> Adding tests that test new VM functionality is clearly more than a good >> idea; it should be de rigueur. >> > >> >> >> >> - in case if we need to run VM-specific tests, is they are available >> >> somewhere or not? do we need to create separate package/repository for >> >> holding them? >> > >> > Check out a 4.2 image and look at the tests. The organization might not >> be perfect but it's there. >> > >> >> You mean non-VM-specific tests, just those which lying in image(s)? >> >> Yes, that's the first thing which comes into mind. And sure thing for >> start it is ok. >> >> For example, Hudson runs tests for PharoCore1.3 image, each time new >> update there. >> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%20Core%201.3/ >> >> It is easy to tweak this config and run it using freshly built VM(s), >> one per each platform * JIT/Stack/MT configs. >> >> But i wonder if we may need to be more focused and create some package(s) >> to group tests around VM or its individual plugins. >> > > Have you looked, as I suggested, in a Squeak 4.2 image? You'll find > Tests-VM, Tests-Finalization, Tests-ObjectsAsMethods > >> >> So maybe we should integrate them in Pharo too ? > >> >> >> >> >> i'd like to brainstorm that a bit. And then we will do that. >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > >

1 0

[Pharo-project] Pharo in San Martin University
by Esteban Lorenzano March 18, 2011

March 18, 2011

Hi, I want to announce that yesterday I started teaching Pharo at University San Martin, so this university is now a proud member of the growing list of universities using this great environment for teaching purposes. One interesting thing is that we are going to explore some not-so-commonly taught capabilities, like Traits and the reflection api :) Cheers, Esteban

5 5

[Pharo-project] [update 1.3] #13094
by StÃ©phane Ducasse March 18, 2011

March 18, 2011

13094 ----- - Issue 3792: PluggableListMorph with a wrapper for display. Thanks Benjamin van Ryseghem. S.

1 0

[Pharo-project] Issue 3792 in pharo: PluggableListMorph with a wrapper for display
by pharo＠googlecode.com March 18, 2011

March 18, 2011

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3792 by Benjamin...(a)gmail.com: PluggableListMorph with a wrapper for display http://code.google.com/p/pharo/issues/detail?id=3792 I now provide a way (or maybe Alain will said it already exists ^^) to change the way item are displayed using the method wrapSelector: aSymbol where aSymbol is the name of a one argument method. That way, you can store real Object (not Strings), and change the way items are displayed ============================================================= Example: buildList list := PluggableListMorph on: self list: #getList selected: #selected changeSelected: #selected:. list wrapSelector: #listWrapper:. ^ list where: listWrapper: anElement ^ anElement name Here anElement is the raw item from the list. Attachments: PluggableListMorphWithWrapper.2.cs 2.2 KB

1 4

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final
by Marcus Denker March 18, 2011

March 18, 2011

On Mar 18, 2011, at 7:09 AM, Lukas Renggli wrote: > Ahh, looks like SimpleMorphic has some (probably unintentional) > overrides of core methods. Unloading the package pretty much breaks > everything :-( > > Lukas > > On 18 March 2011 07:02, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Very good! We then can release the 1.2 Full soon, too. >>> I wonder if we should adopt your OB codebase for that? Or do >>> we wait for 1.2.1? >> >> I would wait a bit. I noticed that the debugger is quite broken. I >> only get the pre-debug window, but clicking on any button opens >> another pre-debug window. I don't have time to investigate, is this >> also in core or some side-effect of loading/unloading packages? I would not unload packaged. Everything not tested is broken, and so if you do things like that I am sure you will have problems. And nobody ever unloaded anything from Core. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 3

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final
by Marcus Denker March 18, 2011

March 18, 2011

On Mar 18, 2011, at 8:24 AM, Marcus Denker wrote: > > On Mar 18, 2011, at 8:16 AM, Lukas Renggli wrote: > >>> I would not unload packaged. >>> >>> Everything not tested is broken, and so if you do things like that I am >>> sure you will have problems. >>> >>> And nobody ever unloaded anything from Core. >> >> You must be joking right? In the mission you say "stable and small >> core", but the numbers say something entirely different: PharoCore 1.0 >> is 11 MB, PharoCore 1.1 is 14 MB, PharoCore 1.2 is 16 MB. I mentioned >> it before in this list, but I already had to unload stuff in PharoCore >> 1.1. Honestly, I don't really see the point of a PharoCore image if it >> contains more and more not unloadable non-core code. >> > Size of the image comes in part from ever growing MC history. 1.2 Core is 15.6MB MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. --> 11.8 MB Delete ScriptLoader class in addition: --> 9.8MB Starting with 1.2Core, doing ScriptLoader new cleanUpForProduction --> 7.5 MB (With MinimalMorphic) So it's not that bad. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final
by Marcus Denker March 18, 2011

March 18, 2011

On Mar 18, 2011, at 8:04 AM, Henrik Sperre Johansen wrote: >> >> >> And nobody ever unloaded anything from Core. >> >> Marcus > I thought the general idea was to remove SimpleMorphic before releases? > Think I read so in an issue, or on the list. Yes, but it was not done for 1.2 and 1.2 is *finished*. If we want to do that, we need to do that *not after the release is released* but before. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Where is squeaksource sources?
by Igor Stasenko March 18, 2011

March 18, 2011

I think i know what is wrong with it. When you uploading a file, it instead of closing connection and saying bye.. starts processing input without releasing other end.. which is simply stupid. I just uploaded VMMaker package.. and now my image freezed, waiting till SqS will calculate diffs and then send mail with it to mailing list.. :( -- Best regards, Igor Stasenko AKA sig.

2 1

[Pharo-project] Issue 3822 in pharo: [Glamoroust] MessageNotUnderstood: receiver of "fullBounds" is nil
by pharo＠googlecode.com March 18, 2011

March 18, 2011

Status: New Owner: ---- New issue 3822 by vonbecm...(a)gmail.com: [Glamoroust] MessageNotUnderstood: receiver of "fullBounds" is nil http://code.google.com/p/pharo/issues/detail?id=3822 Pharo image: Pharo1.2rc2#12324 Virtual machine used: Squeak4.1 of 17 April 2010 [latest update: #9957] Platform Name: unix Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: 1. open workspace and do Gofer it squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. 2. open another workspace and do GTClassicCoder open 3. select package AST-Core 4. select class Behavior 5. select category *System-Object Storage 6. MNU Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image): Attachments: PharoDebug.log 118 KB PharoScreenshot.1.png 159 KB

1 0

[Pharo-project] Cog/FFI Return Values
by Ken Treis March 18, 2011

March 18, 2011

For kicks, I tried running the GemStone tools in a Cog VM. It *almost* works. Apparently this sort of call: > apiGciPerform: anOopType a: aString a: anArray a: anInteger > > <apicall: OopType64 'GciPerform' (OopType64 char* ulong long) > > ^self externalCallFailed ... works differently now. In the old (non-Cog) VM, it return an instance of OopType64. In Cog, it returns a SmallInteger. The function itself returns a uint64_t, so apparently the OopType64 class (a subclass of ExternalStructure) is being used to trick the FFI into automatically wrapping the return value in the way we want. 1. Is this trick no longer supported/legit (assuming it ever was)? 2. Is there a better way to accomplish the same thing, or do we just have to do the wrapping ourselves now? I'm pretty new to the FFI, so forgive me if the premise is wrong. All I know is that it doesn't work the way it used to. :) -- Ken Treis Miriam Technologies, Inc.

4 7