- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Thanks Danny :)
by StÃ©phane Ducasse Jan. 5, 2010

Jan. 5, 2010

Hi guys I can tell you that seeing this letter in my mailbox was ***really*** cool. Thanks danny this is a great license agreement. Stef

4 6

Re: [Pharo-project] about DependencyBrowser
by Mariano Martinez Peck Jan. 5, 2010

Jan. 5, 2010

On Sat, Dec 26, 2009 at 10:06 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Mariano! > Nice to see you liked the Dependency Browser, let's clarify some > points about it then, > > 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi HernÃ¡n: First let me say that this tool is really great and useful. It > is > > helping me a lot to build the metacello configurations. Now, I have a > couple > > of questions: > > > > 1) What do the colors mean ? (red, orange, etc). I read here > > > http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php > > but found nothing :( > > Colors were originally for idenfitying dependency types of external > packages, but the package infos names aren't normalized, E.g. > Normalized name = "Collections", Un-normalized name = > "Collections-Strings", hence you will see a lot of false external > packages colorized. > > Orange -> Dependecy of class reference of "external" package, or class > reference in un-normalized package name. > Brown -> Dependency of external package loose method, or loose method > in un-normalized package name. > Red -> Dependency of inheritance, or inheritance in un-normalized package > name. > Blue -> Dependency of a unsolved binding (like a class not present in > the image). > Thanks for the explanation. Now, as a good programmer you can reuse this explanation and put it in the website :) > > > > > 2) It would be EXCELLENT to be able to distinguish between PharoCore or > > exernal packages. Suppose you are building a tool or whatever, it would > be > > useful to know if it all what it is required is already on a PharoCore or > if > > it is external (it will require to install also another packages). > However, > > I am not sure how implement this :( > > Yes, it would be cool for a new package system to implement a protocol > for asking if a package is distributed originally in a release or not, > like: > > aPackage isOfficial > > With so many forks around, I found difficult to find a single way to > detect official packages installed in an image, and there should be an > easier solution than scanning though all package dates. Maybe this has > changed now? > I really don't know. Maybe we can send a separate thread asking about this. Hey! I have more questions :) 3) Please, take a Pharo dev image and you will see that the package OCForOB for example, only depends on OmniBrowser and OB-Standard (using dependency browser). However, that package also depends on OCompletion I think. Look for example the method OBTextPanel >> createCompletionController (category ocforob) and you will see that it uses the class OController which is from the package OCompletion....So, shouldn't be OCompletion a dependency ? 4) There are certain packages that are not listed in the dependency browser. Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them (maybe all) seem to have the pattern XXX-YYY. Do you know what can be the problem here? Maybe something related to what you told me about normalized and un-normalized? I would really like to see these packages also. 5) Why there are some packages that have their self as dependency ? For example, take OmniBrowser and you will see that has a dependency OmniBrowser also (as Inheritance and Reference). Thank you very much. Mariano > Kind regards, > > HernÃ¡n > > > > > Thank you very much. > > > > Mariano > > >

5 9

[Pharo-project] Gofer broken in PharoCore 1.0
by Miguel CobÃ¡ Jan. 5, 2010

Jan. 5, 2010

Reported as http://code.google.com/p/pharo/issues/detail?id=1741 Gofer is broken on PharoCore 1.0. Can't run code like: Gofer it renggli: 'unsorted'; package: 'RFB'; load. and when updated with: Gofer gofer update. fails with an error. The fix is the same as http://code.google.com/p/pharo/issues/detail?id=1680

1 0

[Pharo-project] [ANN] SystemTracer on SqueakSource
by David T. Lewis Jan. 5, 2010

Jan. 5, 2010

I have created a SqueakSource project called SystemTracing to serve as a repository for the various SystemTracer implementations that have appeared in and around Squeak images since Squeak 1.22. The intent is to make these implementations loadable in modern images, and to provide a Monticello repository for new development. MCHttpRepository location: 'http://www.squeaksource.com/SystemTracing' user: 'squeak' password: 'squeak' All classes and package extension methods have been recategoried to SystemTracing but are otherwise unmodified to the extent possible. The recategorizing was done by hand-editing the original change sets. The archive includes historical versions that appeared in early Squeak images, as well as loadable versions of the SystemTracer2 that is catalogued on SqueakMap. There is an entry for the SystemTracer64 that was used to produce the first 64-bit Squeak image, and recent updates that will enable 64-bit images to be traced from modern Squeak and Pharo images (there is more work to be done here). Developer access is provided for Stephen Pair, John M McIntosh, Andreas Raab, Eliot Miranda, Jannik Laval, Ian Piumarta. If anyone else should be added as developer, please speak up. All future contributions to this archive are required to be MIT licensed. Dave

3 3

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

Jan. 4, 2010

On Jan 5, 2010, at 3:24 AM, pharo-project-request(a)lists.gforge.inria.fr wrote: > On Mon, Jan 4, 2010 at 7:19 PM, David Li <taweili(a)yahoo.com> wrote: > Hi, > > I am new to Pharo > > Hi and welcome! > > and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. > > The only thing I am aware of is http://code.google.com/p/pharo/wiki/BuildingAVMOnPharo Thanks. I have come across that document as well. I kind of got stuck on figuring how how I can install VMMaker. >> I am working on a project that requires extension either through itself > > what do you mean "trought itself" ? You just need to write a plugin or change the VM ? Why you need to tho that ? I ask because maybe someone has even a better solution or advice for you. I am experimenting with Scratch and planning to integrate several native library into it. It seems that I can accomplish most of what I need via plugins. But it would be nice to get a clear pictures about how to build the VM and how the codes are structure in case I need to get in there. > > Cheers > > Mariano > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2