- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 1720: Recompile on a class should only recompile that class, not the whole image
by Stan Shepherd Dec. 30, 2009

Dec. 30, 2009

pharo1.0-10502-rc1web09.12.2 Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: 1.Middle click on any class 2.select refactor, recompile 3. alt-. ORCmdRecompile execute OBWaitRequest block: [ self environment classesAndSelectorsDo: [ :class :selector | class recompile: selector from: class ] ] where self environment = Smalltalk Surely it should only recompile the class we clicked on. ...Stan -- View this message in context: http://n2.nabble.com/Issue-1720-Recompile-on-a-class-should-only-recompile-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
by Stan Shepherd Dec. 30, 2009

Dec. 30, 2009

NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2 Class browser used (if applicable): OR2PackageBrowser. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method navigation: an O2DefaultEdgeNavigation isDropEdge: nil ... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] New class factory for tests (and other use cases)
by Adrian Kuhn Dec. 30, 2009

Dec. 30, 2009

`ClassFactoryForTestCase` is a awesome tool when you need to create throw-away classes for tests. And the new akuhn/SUnit includes a DSL that makes creating anonymous classes even simpler! The new DSL is put in a new class to avoid compatibility issues. To create an anonymous class just do class := ClassFactory newClass. this creates a new subclass of Object. The creates classes is automatically reclaimed by garbage collection when no longer used. That is, tear down of class factory is not required anymore. The class is created without logging and not registered with the system. That is, `Object subclasses` does not include the created class. To create a subclass of a specific class do class := ClassFactory newSubclass: Point. To create a subclass with accessors do class := ClassFactory newSubclass: Point with: [ :f | f compileAccessorsFor: 'color' ]. If you want getters or setters only, use `#compileSetterFor:` or `#compilerGetterFor:`. If you want an instance variable without accessor, use `#declareInstVar:`. To create a subclass with methods do class := ClassFactory newSubclass: Point with: [ :f | f compile: 'answer ^ 42' ]. NB: please note that class factory compiles silently without logging. To create a method on the class side do class := ClassFactory newSubclass: Point with: [ :f | f forClass: [ :cf | cf compile: 'somePoint ^ self x: 2 y: 3' ]]. In fact, the class side factory `cf` supports the same protocol as the instance side factory. Please note that creating instance variables on the class side creates "class instances variables" and not "instance class variables". That is, they are local to the creates class but not to subclasses of the created class. Typically this should not be a limitation since you only create one class without further subclasses. Also, please note that the created classes and all instances created from that class are ment to be thrown away after their use. The created class is not registered with the system, and thus when you change the instance size of its superclass the created instances will not be updated. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load --AA

3 8

[Pharo-project] akuhn/SUnit, chrisma edition :)
by Adrian Kuhn Dec. 30, 2009

Dec. 30, 2009

Cleanup of SUnit is almost done. There are 179 tests with 75% coverage. Missing are tests for the new resource setup and tests for the new history storage. Changes - uses announcements - new class factory DSL - does not print 'unexpected/expected' when empty - factored all assertions into TAssertable - copied Niall's 3-valued setup logic for test resources - new expectation matcher DSL - replaced history dictionary with proper class - keeps history as TestResult in memory - stores history as array in compiled methods - unexpected/expected linked with stored history - migrates #expectedDefects to stored history on the fly - bug fix: 'run failures/errors' updates history - bug fix: coverage is now able to cover itself - added flags for compatibility and deprecation - removed *a lot of* code duplication I tried to run *all* tests in the latest image with akuhn/SUnit and it seems to run fine. There are 5 failures and 2 errors (both with akuhn/SUnit and pharo/SUnit). The new test suite starts faster. You click and tests start running immediately! Progress: numClasses: 13 -> 19 numKLOC: 965 -> 1209 numMethods: 224 -> 291 numStatements: 3086 -> 3903 numTestCases: 51 -> 177 numTestKLOC: 591 -> 1200 numTestStatements: 2175 -> 4663 testCoverage: 61% -> 75% eventually, a SUnit with more test than production code! Give it a try and lemme know whether it runs with your tests. All your tests should still run. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load cheers, AA

7 41

[Pharo-project] [update 1.1] MethodTrailer (really cool).
by StÃ©phane Ducasse Dec. 30, 2009

Dec. 30, 2009

11121 ----- - Issue 1690: New Method Trailer part 1 (cs 1_ and 2_) 11122 ----- - Issue 1690: New Method Trailer part 2 (cs 3 merged) [update 1.1] #11123 11123 ----- - Issue 1690: New Method Trailer part 3 (cs 4 no conflict) Excellent job and big thanks igor. I read (not understood :)) all the code and it looks great! [update 1.1] #11124 11124 ----- - Issue 1690: New Method Trailer part 4 (cs 5) [update 1.1] #11125 11125 ----- - Issue 1690: New Method Trailer part 5 (cs 6 + postscript cs7) Stef

1 0

[Pharo-project] My idea of Metacello configurations for Pharo
by Mariano Martinez Peck Dec. 30, 2009

Dec. 30, 2009

Hi folks. I just wanted to write down my ideas of the Metacello configurations for our Pharo Images. The idea is to use Metacello to manage the dependencies and version of the packages, have a history of the releases and be more modular. You will be able to take a core image and easily load what you want. We will have a ConfigurationOfPharo and that's what you will probably use. However, this conf depends and delegates to another configurations (the conf of each package). So, the first step is to make each little conf to work, and then, we focus in the pharo one. So....lists of points: 1) I have been writing several configurations so far. One configuration per external project that is loaded in Pharo Dev images. Examples: Shout, OCompletion, RefactoringBrowser, OmniBroswer, O2, etc.. The idea is to implement and be sure each of this conf is working before doing the ConfigurationOfPharo. 2) All configurations will be published here: http://www.squeaksource.com/MetacelloRepository This repository is like the ibiblio for maven, or the Universe for the apt-get, or similar. In a near future we will have tools that work with this (Esteban Lorenzano is working in Loader for example). 3) Each configuration must be PERFECTLY loaded in a Pharo Core image without doing or installing nothing. To do this, I have to declare properly the dependencies. This mean, that you will be able to take a core image load the ConfigurationOfShout for exameple, or OCompletion and you will be able to load it. Metacello will take care of all the dependencies. You will also be able to install part of the project and not all (for example, only core or core + tests, or whatever). 4) I started with the Dev packages. We will do this test first to see if Metacello really help us in our project. If this goes well, then, in a second step, we will take care about the Web images. 5) I started with the 1.0 Dev packages. 1.1 is unestable and several external packages even don't load in it. So, will do 1.1 in a second step. 6) As there were no versions of Metacello in all the external projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB 1.0, etc. This has nothing to do with Pharo 1.0. They are just the version number. And after this is released, we really need PLEASE, that the maintainers of those packages also creates the following versions for them. 7) I took as a base, the versions of the 10496 image. I have been using this image since in was release, 12 hours a day, and seems to be very stable to me. I mean, the version 1.0 of ConfigurationOfPharo will be like the 10496 image. When everything is done and working, create a new image will be very easy. 8) We need some features from Metacello which are in the todo list. So, we will have to wait a bit for them. OK, that's all. What do you think? Soon I will send an email for the configurations of all projects and will ask for help and feedback from their developers. Cheers, Mariano

5 9

Re: [Pharo-project] Issue with gofer/metacello
by Dale Henrichs Dec. 30, 2009

Dec. 30, 2009

I've been able to address the problems with Metacello and pharo1.0-10502-rc1dev09.12.2. Version 1.0-beta.18 (just released see: http://groups.google.com/group/metacello/msg/a12918b4bd11c0ef for the announcement) has been tested with both: - pharo1.0-10493-rc1dev09.11.2 - pharo1.0-10502-rc1dev09.12.2 the class-side #ensureMetacello methods for configurations also need to be updated to work with pharo1.0-10502-rc1dev09.12.2. See: http://code.google.com/p/metacello/wiki/EnsureMetacello for a suggested implementation. I plan to update the #ensureMetacello methods for the configurations in MetacelloRepository tonight. Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | The latest Gofer API is not backward compatible with the earlier | versions of the Gofer API. This means that I need to have different | versions of Metacello to use with the different versions of Gofer. | Unfortunately, I can't use Gofer to detect which version of Gofer is | loaded because of the API changes. So I will have to write more code | than I'd like to detect which version of Gofer is pre-installed. The | API changes also impact the bootstrapping code. | | Solving these problems are a larger project than I can undertake on a | Sunday and I _am_ on vacation the coming week as well. | | So until further notice, if you want to use Metacello 1.0-beta.17 (or | earlier) in Pharo you will have to manually ensure Gofer-lr.83 (or | earlier) is loaded into your image before attempting to load any | Metacello configurations. I'm not sure that you use Gofer to load an | earlier version of itself (I'll be finding out in the next few | days)... | | Metacello 1.0-beta.18 works with Gofer-lr.107 (in pharo 1.0-10502). If | you want to use Metacello 1.0-beta.18 (currently in development, so | it's subject to change). You will have to manually bootstrap Metacello | by executing: | | Gofer new | gemsource: 'metacello'; | package: 'ConfigurationOfMetacello'; | load. | (Smalltalk at: #ConfigurationOfMetacello) perform: | #ensureMetacello18. | ((Smalltalk at: #ConfigurationOfMetacello) project version: | '1.0-beta.18') load: 'ALL'. | | before loading your configuration. | | I won't release 1.0-beta.18 until I've resolved the bootstrapping | problem. I'm pretty sure that there is a technical solution, but it | will take several days for me to get it implemented. | | Dale | | ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | | | Version 1.0-beta.18 (development) should have fixes for the latest | | Gofer. 1.0-beta.18 is currently in #development so it is | automatically | | loaded. When I get the chance to test the Metacello fixes with | 10502, | | I'll #release 1.0-beta.18 (and will be automatically loaded). | | | | Dale | | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | | | | | Hi Lukas, | | | | | | In a fresh 10502 I evaluated: | | | -=-=-=-=-=-=-=-=-= | | | [ Gofer gofer load ] | | | on: Error | | | do: [ :err | err retry ]. | | | Gofer gofer recompile. | | | Gofer new | | | squeaksource: 'Mondrian'; | | | addPackage: 'ConfigurationOfMondrian'; | | | load. | | | (Smalltalk at: #ConfigurationOfMondrian) perform: | #loadLastStable. | | | -=-=-=-=-=-=-=-=-= | | | | | | I have the same error. | | | The error comes from: | | | | | | -=-=-=-=-=-=-=-=-= | | | MetacelloMCProject>>updateProject | | | "load the latest version of the configuration package" | | | | | | | mcLoader | | | | (mcLoader := self loader) == nil | | | ifTrue: [ mcLoader := self project loaderClass on: nil ]. | | | mcLoader doingLoads: [ | | | | gofer | | | | gofer := Gofer new. | | | MCWorkingCopy | | | managersForClass: self configuration class | | | do: [:mgr | | | | gofer add: (GoferPackageReference name: mgr packageName | | | repository: mgr repositoryGroup) versionReference. | | | Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' ]. | | | gofer load ]. | | | ^true | | | -=-=-=-=-=-=-=-=-= | | | | | | Cheers, | | | Alexandre | | | | | | On 27 Dec 2009, at 17:27, Lukas Renggli wrote: | | | | | | >> After proceeding these warnings, I have a rollback: MNU | | | >> GoferPackageReference class>>name:repository: | | | > | | | > Can you evaluate | | | > | | | > [ Gofer gofer load ] | | | > on: Error | | | > do: [ :err | err retry ]. | | | > Gofer gofer recompile. | | | > | | | > ? I don't have any senders of #name:repository: to | | | > GoferPackageReference. | | | > | | | > 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 | | | > | | | | | | -- | | | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | | | Alexandre Bergel http://www.bergel.eu | | | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | | | | | | | | | | | | | | | | | | _______________________________________________ | | | 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

1 0

[Pharo-project] Help with a crash
by Mariano Martinez Peck Dec. 30, 2009

Dec. 30, 2009

Hi folks! I am having a crash in Mac OS using Squeak 4.2.2beta1U.app when trying to swap out unactive classes. In the image it appears a windows or something like a console with just a part of the stacktrace. I attach an screenshot. In PharoDebug.log I have nothing. I even tried to run the VM from command line, but nothing is shown in the console.. I opened a MacOS Console and the only thing I see is: "12/29/09 5:54:19 PM Spotlight[217] Invalid kMDItemPath for pharo1.0-10496-rc1dev09.11.5.dbx.changes " So, how can I get the full stacktrace of that ? Thanks Mariano

3 8

Re: [Pharo-project] Pharo-project Digest, Vol 20, Issue 285
by Colin Putney Dec. 29, 2009

Dec. 29, 2009

On 2009-12-28, at 7:10 PM, pharo-project-request(a)lists.gforge.inria.fr wrote: >>> >>> Right now, in our Pharo images we are loading the following packages from >>> http://source.wiresong.ca/ob >> >> AFAIK, the updated code from >> http://source.lukas-renggli.ch/omnibrowser hasn't been merged into the >> repository of Colin yet. I assume that will happen sometime soon. >> >> > > Colin: Right now we are building our official Pharo images using > http://source.wiresong.ca/ob repository, not > http://source.lukas-renggli.ch/omnibrowser > > Do you think that this can be merged ? Yes. I definitely want to have a new release that includes all of Lukas' latest work, pulled from the wiresong repository. I'm just a bit bogged down in Real Life at the moment. :-) Colin

2 1

[Pharo-project] Issue with gofer/metacello
by Alexandre Bergel Dec. 29, 2009

Dec. 29, 2009

Hi! Last week, the following expression was used to load Mondrian. Gofer new squeaksource: 'Mondrian'; addPackage: 'ConfigurationOfMondrian'; load. (Smalltalk at: #ConfigurationOfMondrian) perform: #loadLastStable. With the last version of Pharo (10502), I get few deprecation warnings (package: should be used instead of addPackage: and version: instead of addVersion:). After proceeding these warnings, I have a rollback: MNU GoferPackageReference class>>name:repository: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

7 16