- Pharo-dev - lists.pharo.org

[Pharo-project] this is a test...should work now
by StÃ©phane Ducasse Dec. 8, 2008

Dec. 8, 2008

1 0

[Pharo-project] Fwd: [squeak-dev] [Ann] Monticello15 File support (alpha)
by Damien Cassou Dec. 8, 2008

Dec. 8, 2008

---------- Forwarded message ---------- From: Keith Hodges <keith_hodges(a)yahoo.co.uk> Date: Sun, Dec 7, 2008 at 6:03 AM Subject: [squeak-dev] [Ann] Monticello15 File support (alpha) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Seasons Greetings Everyone, Monticello 1.5 "FINALLY" supports files. I have set LevelPlayingField to load this new version of MC1.5 If anyone has any problems with it do let me know asap. Keith ======== PackageInfo comment reads: External Files Support ================ The default implementation of the two methods below considers all files and directories (with their contents) matching the package name to be part of the package. #externalFiles #externalFilesMatches e.g. package name 'Release'. files matching would include: Release.text Release/Introduction.text Release/Tutorial/ch1.text External Files Support - Monticello ======================================== *Only file based repositories (i.e. .mcz files) are supported at present Since your external files will change far less than your code, it is recommended that you use a separate package to manage files in order to save space and time. Files are included in the .mcz (which is a standard zip archive) as files/* according to the pattern files/<uuid>/<path>/<to>/<file> *note: the uuid will change with every snapshot, it is unique to that file in that snapshot *note: in changes browsers the file is considered to be changed if the fileSize has changed. Snapshotting a package with files uses a temporary directory in package-cache/files The #flushCachedVersions menu item deletes this directory. -- Damien Cassou http://damiencassou.seasidehosting.st

1 0

[Pharo-project] Change in HandMorph and HandMorphForReplay causing primitive error
by Hilaire Fernandes Dec. 7, 2008

Dec. 7, 2008

Hello, I am using a modified version of the EventRecorderMoprh to record learners activities. With latest Pharo (#183) I am facing several problems (compatibilty ones as I expected it). The most serious one is about primitive error with something related to hardware cursor throught the VM. The enclosed debug log may be more meaning full. Does it recall something to the Pharo hackers I can dig into? -- http://blog.ofset.org/hilaire

1 0

[Pharo-project] Alien on powerpc
by John M McIntosh Dec. 7, 2008

Dec. 7, 2008

I've check in a number of changes into the main SVN tree, and into the Alien MC to start to providing support for PowerPC. I do have a somewhat functional api on the cpu type now, we are still working some details about how to deal with Float/Double versus integer, and I've yet to tackle the callback logic assembler. Tomorrow if I make more progress I'll check in the assembler/glue code for the PowerPC call pattern. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

Re: [Pharo-project] Magma + FreeType font
by Andrew Tween Dec. 6, 2008

Dec. 6, 2008

Hi Hilaire,> Date: Sat, 6 Dec 2008 12:42:16 +0100> From: hilaire(a)ofset.org> To: amtween(a)hotmail.com; pharo-project(a)lists.gforge.inria.fr> Subject: Magma + FreeType font> > I am now using Pharo with FreeType fonts + Magmar41.1.> > The font I am using use the LogicalFont class (this is how I declare in > my code the TT font I am using).> > I have extended LogicalFont to get it persisted:> > First with a new way to instantiate it:> > LogicalFont class>>familyName: familyName pointSize: pointSize emphasis: > code> > ^ (self familyName: pointSize pointSize: pointSize) emphasis: code; yourself> > Then three methods for persistence, I copied the existing TType class > persistence methods:> > maAsStorageObject> "I am about to be written on an object file. Write a> reference to a known FontSet in the other system instead."> "a path to me"> ^ DiskProxy> global: #LogicalFont> selector: #familyName:pointSize:emphasis:> args: {> (self familyName).> (self pointSize).> (self emphasis)> }> Have a look at LogicalFont>>#objectForDataStream: It is doing something similar to your method, and is creating a DiskProxy for DataStreams... DiskProxy global: #LogicalFont selector: #familyName:fallbackFamilyNames:pointSize:stretchValue:weightValue:slantValue: args: {self familyName. self fallbackFamilyNames. self pointSize. self stretchValue. self weightValue. self slantValue}. Your code looks ok to me and should work fine; but you might try creating a DiskProxy in the manner above, and see if that cures your problem. If that doesn't fix it, then do you have an image (+ database) that you can share so I can investigate further? Thanks, Andy > maUsesStandardStorage> > ^ false> > maWantsPreSerialization> ^ true> > > Basically these methods are used when I am persisting in the Magma > Database a morph with some text.> > Now when I am fetching such Morph from the Magma data base in another > image (with the same code extension) I got a Segmentation fault (the > trace is included there).> > The crash is clearly happening in FreeType code, in the primitive > called from FT2Face>setPixelWidth:height:> > Probably I got something wrong in my persistence code, I will be more > than happy with any kind of tips.> > Thanks,> > Hilaire _________________________________________________________________ Imagine a life without walls.Â See the possibilities. http://clk.atdmt.com/UKM/go/122465943/direct/01/

2 2

[Pharo-project] Removing a trait from a class
by Hilaire Fernandes Dec. 5, 2008

Dec. 5, 2008

I can't remove a trait from a class using UI tools. (pharo 10050) How can I remove it programmatically ? Next with this same class, message from this trait are not reachable, the MNU is raised but the hierarchy is not right as IFIETayage1 is not a subclass of IFIExoMorph. However IFIExoMorph is using the same trait as IFIEtayage. It looks like there is mismatch in the classes with traits. (see screenshot) Now I realize my last istoa release suffer from this problem :) Hilaire -- http://blog.ofset.org/hilaire

3 11

[Pharo-project] about merge tool
by StÃ©phane Ducasse Dec. 5, 2008

Dec. 5, 2008

Hi I got some problems with the new merge tool - I do not succeed to say which changes I want to keep and reject all the actions are grey - when I click on the small green arrow in bteween the two panes I get an error - the modal interaction make difficult to copy and paste changes in case we want to do that. Stef

1 0

Re: [Pharo-project] Inspector Gadget
by David Pennell Dec. 5, 2008

Dec. 5, 2008

[this bounced yesterday] OK - where is the agreement? The link on http://code.google.com/p/pharo/wiki/LicenseAgreement is broken. On Thu, Dec 4, 2008 at 4:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > +1 > send the code and sign the agreement :) > > Stef > On Dec 4, 2008, at 1:32 AM, David Pennell wrote: > > > We currently have both "inspect" and "explore". It would be nice to > > have one tool. I'd vote for "explore" as a base with some > > enhancements to pick up the useful features from "inspect". > > > > -david > > _______________________________________________ > > 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 >

2 1

Dec. 5, 2008

Hi I would like to ask you if you do not get the same proble, as me. When I do not know an application I try to clik on the pane to see if there is a menu and it is like blind testing... It would be great if the mouse would change when the pane can display a menu. Stef

1 0

Dec. 5, 2008

Begin forwarded message: > From: "Igor Stasenko" <siguctua(a)gmail.com> > Date: December 5, 2008 9:37:30 AM CEST > To: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > Subject: Fwd: [Pharo-project] UIMananger > > i got strange error 'relay not permitted' when sending this mail to > pharo list. > So, i sending it to you. > > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua(a)gmail.com> > Date: 2008/12/4 > Subject: Re: [Pharo-project] UIMananger > To: pharo-project(a)gforge.inria.fr > > > 2008/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Igor >> >> I was thinking about what you propose. I do not understand why a >> simple extension >> is not better. >> >> I do not understand why we should involved Smalltalk > > it can be different class playing as access point to tools registry. > why its better - because your code does not rely on specific classes, > which can be missing in image. > The idead is, that to get a service (or tool) you need to send a > message, without referring to specific class(es). > Then any installed packages may add/remove/replace entries in registry > and can be used directly by your code without any specific knownledge > about who or what is standing behind it. > >>> you write >>> >>> Smalltalk tools UIManager >>> >>> instead of >>> UIManager default >>> >>> or >>> Smalltalk tools browser >>> >>> instead of >>> SystemBrowser default >>> >>> it would be nice to see similar in UIManager, e.g. >>> >>> manager registerTool: #colorPicker class: MyCoolColorPicker. >>> >>> and then simply use: >>> >>> manager colorPicker new openInWorl >> >> I do not understand the gain of your approach. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- > Best regards, > Igor Stasenko AKA sig. >

1 0