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

[Pharo-project] Managing Pharo external packages with Metacello, please read!
by Mariano Martinez Peck May 19, 2010

May 19, 2010

Hi folks. We have been discussing a lot what to do with the Metacello configurations of all projects and MetacelloRepository. We want several things: - Have an specific catalog of the working and tested packages/projects for each Pharo release (1.0, 1.1, etc). - Be able to have a hudson server running and testing such configurations. - Unified way to load a project. For such objectives, we propose the following scheme: 1) We create a squeaksource repository called Pharo10MetacelloRepository 2) All the Metacello configurations that are known and tested to work perfect in Pharo1.0, are copied to such repository. (this takes 2 minutes) 3) Now, we have the problem of WHICH version from the conf class should be the one that loads and works in Pharo 1.0. So, once you copied the configuration, then you have to implement a class side method "load" that loads the exact version that should work in Pharo1.0. This version may not be the last. And you already may have defined "load" to load the last version. In such case, you can just change it for the version in the Pharo10MetacelloRepository. Otherwise, we can use another message. Give us your opinion. So the idea is that all developers/maintainers of Metacello configurations, do that and publish it. With this, if you want to know which projects work on Pharo 1.0 you just browser Pharo10MetacelloRepository, load the repository you want, and you know that just doing "ConfigurationOfXXX" load will do the job. In addition to this, we are able to have a hudson server that every XX time, it scans the repository, and for each project it tries to load it and report if there is a problem. We can even make that "load" loads also the tests and make Hudson to run the tests. Or if you want we can use another message than load. So...this is just an idea. But we need feedback and hear opinions. Because Pharo 1.1 will be soon and would be great to have this already working for Pharo 1.0. Thanks Mariano

10 36

[Pharo-project] [BUG] in VM perform primitive
by Igor Stasenko May 18, 2010

May 18, 2010

Hello, i just discovered a serious bug, which prevents from performing a methods which having many args (but not too many for compiler and run normally). The problem is, that VM tries to using the currently active context to push all of the arguments on it, and then just do normal send. But a sender context may be not big enough (small frame) to accomodate all pushed values. In the attachment you can find that running any of PerformTest new doPerformXX leads to primitive failure. I think that we could fix that at the image side, by telling the compiler to always use a big stack frame for following method: Object>>perform: selector withArguments: argArray "Send the selector, aSymbol, to the receiver with arguments in argArray. Fail if the number of arguments expected by the selector does not match the size of argArray. Primitive. Optional. See Object documentation whatIsAPrimitive." <primitive: 84> ^ self perform: selector withArguments: argArray inSuperclass: self class so, when prim 84 fails, it will activate this method and then, there should be enough space to push all method's arguments. -- Best regards, Igor Stasenko AKA sig.

1 2

[Pharo-project] Help menu
by laurent laffont May 18, 2010

May 18, 2010

Hi, I put a slice in PharoInbox which adds an Help entry in WorldMenu with Help Browser in. Then I can put ProfStef Browser too. See http://code.google.com/p/pharo/issues/detail?id=2442 Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

2 1

[Pharo-project] how to change the default size of the Pharo host windows?
by Mariano Martinez Peck May 18, 2010

May 18, 2010

I know I already asked this, but I didn't get a working solution. I want to change the default size of the host windows that runs on Pharo. Does someone know how to do that? I attach the 2 screenshots: what I have, and what I want. Thanks mariano

5 24

[Pharo-project] [update 1.1] #11366
by StÃ©phane Ducasse May 18, 2010

May 18, 2010

11366 ----- - merged the changes for Issue 1884 (NetNameResolver doesnt work in PharoCore) Next condense changes and clean stuff reported by torsten Stef

1 0

[Pharo-project] [update 1.1] #11365
by StÃ©phane Ducasse May 18, 2010

May 18, 2010

11365 ----- - Issue 2375: Editor shortcuts in New Editors. Thanks fernando - Issue 2434: Debugger full stack enh from Squeak - UIThemeWatery2 beCurrent. Thanks alain - Issue 2433: Better class comment for CharacterBlock from squeak - Issue 2437: Bypassing the modal dialog when sending Class>>rename: Thanks fernando next one: network rollback next next one: condensechanges

1 0

Re: [Pharo-project] [squeak-dev] Re: [Esug-list] Re: Talking to Steve Jobs about Scratch.
by John M McIntosh May 18, 2010

May 18, 2010

Radoslav asked yesterday about progress on the issue of Scratch on the iPad, so it's timely to give everyone an update. I did ask Apple today for an update on the situation and was told: "We're still pondering the issue" So I remain positive and wait. On 2010-05-16, at 3:34 AM, radoslav hodnicak wrote: > > Was there any conclusion to these talks? > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 1

[Pharo-project] Collection arithmethic method category
by Fernando olivero May 18, 2010

May 18, 2010

In Pharo1.0 Collection organization listAtCategoryNamed: 'arithmethic' #() In PharoCore1.1 Collection organization listAtCategoryNamed: 'arithmetic' #(#* #+ #- #/ #'//' #'\\' #raisedTo:) And the arithmethic is not an extension of any Package. Why are all the methods in that category no present in PharoCore? How and when are they added into Pharo ? Fernando

4 9

[Pharo-project] So...we freeze 1.1 ? (next steps?)
by Mariano Martinez Peck May 18, 2010

May 18, 2010

We said that for middle May we were going to freeze 1.1. This means, no more new features or refactors. Just bug fixes. So, the next steps can be: - Release a PharoCore1.1 with the last version we have so far tagged as alpha1 (please, put this tag in the zip, .image and .changes). This may be, for example: Pharo-1.1-11360-alpha1.image - Build and release a Pharo 1.1 alpha1 based on such core (now we have almost all dev tools working well in 1.1) - Make publish all new VMs (for each OS) Then the idea is that people/developers start to play with Pharo 1.1. It may be quite unstable as this is the first release for 1.1. People should try to load their own packages, adapt them (if necessary) to 1.1, and report all issues they find (and fixes!!). But they should keep in mind this the first alpha ;) With these, we will be testing: new VMs, PharoCore, PharoDev tools, and external packages (from other people). Pharo team at the same time, continues to work, fixing and integrating. We make new versions as we have been doing so far. When we consider, we release an alpha2....then beta, then RC and finally Pharo 1.1. now...do you think there is an issue that is so important to be fixed/included in the first Pharo1.1 even being a first alpha ? Cheers Mariano

8 28

[Pharo-project] Community Supported Packages
by Torsten Bergmann May 18, 2010

May 18, 2010

Hi, I tried to follow the discussion on both lists regarding supported packages and how/where to manage them by using Metacello. I can not give complete feedback since I go with GÃ¶ran here who said "I need to read your thoughts once more before giving proper feedback." and I think we all should take the time to think about all the implications the different approaches have. With this discussion we set up the base for the future of package maintenance but also for collaboration amongst the communities, how images are built, ...! I'm sure we all want to blur the line between in and out of the (whatever) image and share/reuse as many code/packages as possible within the broader community (Squeak, Pharo, Cuis, Gemstone, ...). So: Goal Nr. 1 is: if it is not in my environment then just load it. Goal Nr. 2 is: if it is loaded it should work in my environment since it brings in anything it needs to work Currently the discussion and actions seem to focus on where to put the configurations (into the image vs. in repositories per version). I'm in favour of the latter since that is easier to handle and share between platforms while having them in the image would limit people who work on various platforms, it would not scale and eat more resources for maintenance. My fear is also that if you have the configurations within the image then we all will end up with something similar to the unmaintained SqueakMap registrations. With external repos we can also feed CI-Tools (Hudson build server, ...) The only benefit from the "maintining configs in-image" would be that it would be easy to build a UI similar to SqueakMap/Universe Browser. This is something that has to be solved - especially for Pharo since loading/browsing it is not very "user friendly" today, but AFAIK work already started with the "Loader" project. Agree with Andreas that Metacello needs more work and a good browser of available configs would be a plus. But thats not the main question. Even if Squeak decides to have the configurations "in-image" and Pharo decides for external configs one can mix them: An in-image ConfigurationOfMyApp just loads the ConfigurationOfMyAppExternal where the last one is maintained in an external repo and the internal config is for convenience to just load it. However - I have to reread all the arguments and think about all this. <warning> But with a better acceptance of Metacello there will be more to come and to discuss! </warning> Lets think about the implications for anything above the virtual machine: Squeak is currently maintained as a "full image" using the trunk process while Pharo already switched to a "small core + external packages" model. The "pharo core" image (which is not Pharo!) is getting stable and hopefully smaller and one can already create a Pharo image right from the "ConfigurationOfPharo". That is there and working. I'm not saying that Squeak is not getting stable (I'm still a Squeak AND Pharo guy) but it is a different approach to build the end result that we later announce on our websites. If Squeak jumps on the Metacello config bandwagon it may also have to think about jumping onto the "small core + external packages" model. At least to me this would be the next logical step. This leads to several questions: - could this small core could be the same for all of us - especially since we currently fix stuff in Cuis, Squeak and Pharo mostly the same way - could this small core be reduced to a minimum set of objects and a loader that is able just suck in the things defined in package configurations of packages that work together - would any specific assembled/deployed image not just be a special distro of the "small kernel" + selected packages (similar to the linux world) So "Squeak" may later be the distro with media/fun/experimental packages or etoys and "Pharo" may later be the distro with packages oriented towards commercial development. However then the lines are blurred then and if you have the common core on your disk you can even create your own distro with Seaside and Etoys ... Pharo will follow the path "kernel" + selected packages" and external config path anyway since this is already discusssed and prepared. >From what I understand so far a repo for Pharo 1.1. will appear soon with freezed/working configs and a build structure will be set up. So lets see how this works out and if successfull if Squeak will adapt it too. Just my 2 cents. Expect additionally cents after getting more time to think about all this ... Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

4 3