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

[Pharo-project] What about killing PharoWeb images?
by Mariano Martinez Peck Jan. 6, 2010

Jan. 6, 2010

Please, don't say "NOOOOO!" immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are "force" to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? NOOOO. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say "we won't fix" and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called "PharoWeb" which links to the seaside image. However, I would rather call it "PharoSeaside". 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit "different" than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more "similar" to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano

13 34

[Pharo-project] What about having a blog with news in pharo website?
by Mariano Martinez Peck Jan. 6, 2010

Jan. 6, 2010

I know we discuss several times in ways to improve communication and documentation. But know I am being very precise: put a "news" section in the website. The website is written in Pier, so adding Blog should be really easy. Adding the Pier add on for colour highlighting would be even a dream. I think having a "news" section with RSS is a must nowadays in every software project. The mailing list has a lot of traffic (that's really cool) but there are a lot of people who cannot track it. So, having a place to read the news would be helpful. What kind of things we can post ? Examples: - I will announce soon the metacello configurations for external projects and after that the configuration for pharo. - ANN and news for external projects such as: Seaside, Metacello, Moose, Mars...whatever that runs on top of pharo - ANN for new dev images (after passing the beta test stage) - ANN of books - Now for example I can post that we have already started with the translation of PBE to spanish :) - Show progress and comments about Pharo sprints and coding sessions - Big decisions taken. For example if we agree to remove PharoWeb images - Success stories. Projects that goes on production or that have just started with Pharo - Comment lessons, presentations or conference where someone spoke about pharo - A lot of things more. I know the idea of the website is not to be too technical but I think these kind of stuff are not technical at all. Then we should see how and who post. In pier I subclass Blog with a new class that requires authorization for an admin users. Then there is a little component only for admins that let you browse the posts and authorize them. If you want I can send them to you. Cheers Mariano pd: sorry for the amount of "this kind of mails" that I am sending in the last weeks

3 3

[Pharo-project] SplitJoinTest broken by new Regex version
by Adrian Lienhard Jan. 6, 2010

Jan. 6, 2010

After the update of VB-Regex (http://code.google.com/p/pharo/issues/detail?id=1639 ), the test SplitJoinTest>>testSplitStringOnRegex fails. Does somebody know what's wrong and how to fix it? Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

2 1

[Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
by David Li Jan. 5, 2010

Jan. 5, 2010

Hi, I am new to Pharo and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. I am working on a project that requires extension either through itself or via plugins. I have been seeing the mention of VMaker but can't find a good document about it. Thanks a lot for the help. David Li

6 8

[Pharo-project] About documentation
by StÃ©phane Ducasse Jan. 5, 2010

Jan. 5, 2010

Hi guys I discussed with lukas and we could get the same infrastructure than for the seaside book http://book.seaside.st - editable but with editor control. - able to generate latex Now I want to know if some of you want to control that because I cannot. Stef

4 7

[Pharo-project] [update 1.1] #11137
by StÃ©phane Ducasse Jan. 5, 2010

Jan. 5, 2010

11137 ----- - Issue 1737: DNU when opening halo HaloMorph initialize - Issue 207: ImageSegment discoverActiveClasses strange error - Issue 1204: ByteString(Object)>>error:Improper store into indexable object - Issue 1744: WordSize - Issue 1740: remove createMethod:header: from arrayedCollection

1 0

[Pharo-project] Mac VM 5.2b1 ships
by John M McIntosh Jan. 5, 2010

Jan. 5, 2010

I've push the latest cocoa based 32/64bit macintel/powerpc VM to the folder experimental/64bits in the regular places found via http://smalltalkconsulting.com/squeak.html Look for the Squeak 64/32 5.2b1.app This *beta* VM runs in 32 or 64 bit mode on macIntel, and 32bit mode on powerpc to support Squeak 32bit images. I've updated the app so that the extended clipboard support is built in so that you can do cut/copy/paste in the latest Pharo image. At the moment the only supported plugin is the FreeType2 (32/64bit mode) and is also included, I hope to rebuild the mac menu logic in a few weeks/days. It is possible the VM will support other plugins, but only if you run it in 32bit mode via get info. As a reminder I do need more people to use it as their development platform so we can work out any bugs. I'll look at building a 64bit vm/ 64bit images if there is interest... =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

7 10

Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
by Laval Jannik Jan. 5, 2010

Jan. 5, 2010

Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Cheers, Jannik On Jan 4, 2010, at 17:39 , David T. Lewis wrote: > On Mon, Jan 04, 2010 at 05:15:28PM +0100, Andreas Raab wrote: >> Hi Jannik - >> >> A couple of comments. First, If wordSize is a constant, put it into a >> class var. That's the best practice pattern for dealing with constants >> and I see no reason why one would opt to use an ivar for a value that >> never changes. See for example the EndianCache in SmalltalkImage and >> other use of constants throughout the system. >> >> As for caching, if I understand your description correctly, then system >> tracer is storing the correct value for the traced image. When the image >> starts, your cache code invalidates the known to be correct value which >> is later lazily filled in with the same value again. So what observable >> effect does your cache invalidation have? >> >> #startUp isn't the first method sent, not by a very long shot - in >> particular when you mess with the execution machinery you have to be >> aware that a method like #initialPC might be called before you ever get >> to the point where you invalidate that cache (I'm not sure if this can >> happen in this concrete case). In any case you should trace through the >> startup sequence to find out just how much other code is executed before >> getting there. > > John and/or Bert previously pointed out that there is no need to ever > set the cached value from the image, so this would be done from a system > tracer only (and yes this should have a comment). > >> My recommendations would be to make WordSize a class variable, leave the >> lazy initialization in (it might be helpful during install etc) but add >> a nice comment explaining that only system tracer ever modifies that >> value when a 32/64 bit image is written. And leave out the pointless >> cache invalidation :-) > > I think that the change set on Mantis 7430 does what you describe. This > puts the class variable in SystemDictionary in order to retain the current > "Smalltalk wordSize" idiom, and uses the original Dan Ingalls #initialPC > implementation from the "dist3" 64-bit image. > > It's a small change, so I'll copy it here: > > 'From Squeak3.10.2 of 16 December 2009 [latest update: #8496] on 18 December 2009 at 6:08:11 pm'! > "Change Set: Smalltalk-wordSize-dtl-M7430 > Date: 18 December 2009 > Author: David T. Lewis > > Cache Smalltalk wordSize in class var in SystemDictionary.. > > Update CompiledMethod>>initialPC to use #wordSize. This is the method as implemented in the original 64-bit image (author di)."! > > IdentityDictionary subclass: #SystemDictionary > instanceVariableNames: 'cachedClassNames' > classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize' > poolDictionaries: '' > category: 'System-Support'! > > !CompiledMethod methodsFor: 'accessing' stamp: 'di 6/29/2004 12:28'! > initialPC > "Answer the program counter for the receiver's first bytecode." > > ^ (self numLiterals + 1) * Smalltalk wordSize + 1 > ! ! > > > !SystemDictionary methodsFor: 'sources, change log' stamp: 'dtl 12/18/2009 00:32'! > wordSize > "Answer the size (in bytes) of an object pointer." > "Smalltalk wordSize" > > ^ WordSize ifNil: [WordSize := [SmalltalkImage current vmParameterAt: 40] on: Error do: [4]]! ! > > > >

3 6

[Pharo-project] [update] #10504
by Adrian Lienhard Jan. 5, 2010

Jan. 5, 2010

10504 ----- Issue 1741: Gofer broken on PharoCore 1.0 Issue 1719: After running all tests, mac menus for tools and debug are gone ___________________ http://www.adrian-lienhard.ch/

1 0

[Pharo-project] ImageSegment fixes in Inbox
by Mariano Martinez Peck Jan. 5, 2010

Jan. 5, 2010

Hi! After several days of surfing the beatiful ImageSegment code, I fixed several issues. I commit to Inbox the SLICE-FixesToImageSegment. This are the changes in my commit: - Removed Beeper beepPrimitive from ImageSegment >> install - Fix to writeToFile. See issue 1204 http://code.google.com/p/pharo/issues/detail?id=1204 - Now ImageSegment >> discoverActiveClasses answer the number of them - New method ImageSegment >> unActiveClasses - Fix to ImageSegment >> swapOutInactiveClasses. I have to hold the allSymbols and to exclude the Multilingual and Kernel package from the swap. This should fix issues 1203 and 1204. - The errors for wrong states now print the current state and also the expected one. - Fix issue 207. Take a clean image and evaluate: Smalltalk at: #MDFaultDict put: Dictionary new. Then | count | count := ImageSegment discoverActiveClasses. Transcript show: 'Classes forced: ', count asString. Do something And finally evaluate | count | count := ImageSegment activeClasses size. Transcript show: 'Classes active ', count asString. or | count | count := ImageSegment unActiveClasses size. Transcript show: 'Classes active ', count asString. Whit this, there is no trace. Even if puting the dictionary. A simple hack to see this is to change activeClasses to use recoverFromMDFaultWithTrace instead of recoverFromMDFault If you do that, you will be able to inspect Smalltalk at: #MDFaultDict I also fixed the swapOutInactiveClasses. The image have several emergency windows before this.

2 4