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

[Pharo-project] halt in TTFontReader >>processCompositeGlyph:contours:from:

by Cyrille Delaunay

Hello, There is a 'self halt' in the code of TTFontReader >>processCompositeGlyph:contours:from:. Therefore, when I try to import a font from a file, for example by evaluating: TTFontDescription addFromTTFile: FileDirectory default fullName, '/Fonts/DejaVu/DejaVuSans-Bold.ttf' the execution is stoped by this halt (And I don't know why). Now, when I remove the 'self halt', all seems to work correctly.

May 20, 2010

Re: [Pharo-project] Fwd: Pharo1.1 and Pharo1.0 difference when pressing CMD-Q

by Mariano Martinez Peck

2010/5/18 Fernando olivero <oliverof(a)lu.unisi.ch> > The DNU is reported in ISSUE 1876. > Yes, it was complicated to use Man Menu in Pharo 1.1 Alain was working on that....but as he doesn't have a mac... I needed to enable Mac Menu because I was trying to remove it from core and put it in dev or in PharoNonCore, but if it even doesn't work it does not have sense. Cheers Mariano > > Begin forwarded message: > > *From: *Fernando olivero <oliverof(a)lu.unisi.ch> > *Date: *May 18, 2010 4:22:43 PM GMT+02:00 > *To: *"Pharo-project(a)lists.gforge.inria.fr Development" < > Pharo-project(a)lists.gforge.inria.fr> > *Subject: **[Pharo-project] Pharo1.1 and Pharo1.0 difference when pressing > CMD-Q* > *Reply-To: *"Pharo-project(a)lists.gforge.inria.fr" < > Pharo-project(a)lists.gforge.inria.fr> > > Hi, using the MAC OS X VM and pressing CMD-Q in Pharo1.1 sends > InputEventSensor>>processEvent: evt > where the evt received is of type 4, a menu event. (just put a Transcript > show: evt in the processEvent: evt and you'll see). > > Since EventSensorConstants defines: > > "Types of events" > EventTypeKeyboard := 2. > EventTypeMenu := 4. > > But in Pharo1.0 it generates an event of type 2, a keyboard event. > > I assume that this changed because In Mac-OSX the CMD-Q is binded to a > particular action , > and in Pharo1.1 we are using HostSystemMenus. > > But how can i override this behavior? To handle the CMD-Q as any other > Keyboard event? > > By the way there's also a DNU, when pressing CMD-Q. > > Thanks, > Fernando > > > > _______________________________________________ > 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 >

May 20, 2010

Re: [Pharo-project] how to center a workspace in the World ?

by Fernando olivero

morph := Morph new. morph extent: 400@400. centeredPosition := ( RealEstateAgent maximumUsableArea center - ( ( morph width /2) @ ( morph height /2) ) ) rounded . morph position: centeredPosition. morph openInWorld . On May 20, 2010, at 1:31 PM, Mariano Martinez Peck wrote: > How can I do that? For the moment, I am doing: > > openWelcomeWorkspace > > (Workspace new > acceptContents: ' Welcome to pharo...blah blah > > '; > embeddedInMorphicWindowLabeled: 'Welcome to Pharo') > position: 50@120; > extent: 800 @ 500; > openAsIs > > > I want to keep the extent, but the position to be centered. > > Thanks for any hint, > > Mariano > <ATT00001..txt>

May 20, 2010

[Pharo-project] [OT] Rebuild Facebook using Seaside?

by Torsten Bergmann

Maybe we should send a copy of "PBE" and the Seaside book to these four students so they use Seaside for their reimplementation of Facebook. See: http://www.justmeans.com/-Diaspora-Project-Grassroots-Funding-for-an-Altern… Or should we join forces to create the "diaspora" project and send them the final (killer) app. Would be a good marketing since it is already in the news with high interest... ;) Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 20, 2010

[Pharo-project] how to center a workspace in the World ?

by Mariano Martinez Peck

How can I do that? For the moment, I am doing: openWelcomeWorkspace (Workspace new acceptContents: ' Welcome to pharo...blah blah '; embeddedInMorphicWindowLabeled: 'Welcome to Pharo') position: 50@120; extent: 800 @ 500; openAsIs I want to keep the extent, but the position to be centered. Thanks for any hint, Mariano

May 20, 2010

Re: [Pharo-project] UUID on ubuntu 10.04

by David T. Lewis

On Thu, May 20, 2010 at 09:01:11AM +0200, laurent laffont wrote: > Hi, > > Something that I don't understand. If the bug is in libuuid, the crash > should occur even if UUIDPlugin is internal ? What are the differences > between internal and external ? I don't know. There was some speculation in this thread: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004315.html But I am not aware of any definitive conclusion. All of the information that I have is here: http://bugs.squeak.org/view.php?id=7358 Dave

May 20, 2010

Re: [Pharo-project] problem with CompiledMethod equality

by Mariano Martinez Peck

Wow.....the conversation went far away from my understanding and knowledge. I will try to read it slowly and carefully, several times and try to understand what you said. For the moment (just my needs) the solution from Lukas worked: use IdentitityDictionary instead of Dictionary. Now I let you to you to decide if it is a bug or not, if it deserves comment, etc. Thank you very much. Mariano 2010/5/19 Eliot Miranda <eliot.miranda(a)gmail.com> > > > On Wed, May 19, 2010 at 4:58 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Hi Eliot, >> What about super sends ? >> >> Object>>beNasty >> ^self >> >> Collection>>beNasty >> self addLast; 1. >> super beNasty. >> >> OrderedCollection>>beNasty >> self addLast; 1. >> super beNasty. >> > > Good point. I still find the existing #= definition very useful for > compiler verification. > > >> >> Do you think you can remove OrderedCollection>>beNasty ? >> >> Nicolas >> >> 2010/5/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> > Elliot I think that we already took into changes made by nicolas. >> > >> > Stef >> > >> > On May 19, 2010, at 2:35 AM, Eliot Miranda wrote: >> > >> >> Hi Lukas, >> >> >> >> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >> >> > Same method in different classes do not equal eachother though, if >> I've not made a mistake in: >> >> > >> >> > |mrtCp| >> >> > mrtCp := (InstructionClient>>#methodReturnTop) copy. >> >> > mrtCp literalAt: 2 put: #ContextPart->ContextPart. >> >> > (InstructionClient>>#methodReturnTop) = mrtCp >> >> >> >> For methods that send super the behavior changes if you change the >> >> class binding. That's probably why it is not ignored for #=. >> >> >> >> In fact I would suggest to #= from compiled method altogether, in most >> >> cases it doesn't do what one would expect in a given context anyway. >> >> There are too many and possibility completely different >> >> interpretations of #= for CompiledMethod. #== is the only decent >> >> implementation for this class. >> >> >> >> I sympathise but I think there is a reasonable default interpretation >> of #= for CompiledMethod that is what most people want. The intent is to >> answer whether two methods have the same execution semantics and same method >> tags & properties, e.g. if one were to compile the same source code in two >> different classes that had the same inst var offsets for the inst vars in >> the methods, then one would want those methods to be #=. This allows tests >> such as >> >> - checking whether a subclass has a method that is #= to a superclass, >> and is hence redundant. >> >> - checking whether a set of sourceless methods are equivalent so that >> they may be shared under different selectors (e.g. think auto-generated >> accessor methods which can be cached and shared) >> >> So for this informal definition the selector and the class are >> irrelevant, but bytecodes and literals (apart from the selector and method >> class literals) are relevant. Its almost a short-cut comparison of >> error-free decompilation, although there are differences in the bytecode >> that wouldn't show in decompilation (e.g. using long branches for short >> branches). >> >> >> >> The current definition serves for compiler hackers as it tells you >> accurately whether a compiler change has an effect on the bytecode, can be >> used to test whether compilation followed by decompilation followed by >> recompilation has an effect, etc. While it may not be a universal code >> comparison method it has met my needs throughout the closure compiler so at >> least I'm pretty happy with it. >> >> >> >> (pleading for CompiledMethod>>#= to stay the same as the current Squeak >> 4.1 definition, which ever since Nichoas Celier's float compilation changes, >> is pretty darned good). >> >> >> >> best >> >> Eliot >> >> >> >> >> >> >> >> >> >> >> >> Lukas >> >> >> >> > >> >> > At the very least, the branches of >> >> > index = 1 and: [ #(117 120) includes: self primitive ]) >> >> > ifTrue: [ >> >> > >> >> > REALLY deserve some comments... >> >> > >> >> > Cheers, >> >> > Henry >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> 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 >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> _______________________________________________ >> 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 >

May 20, 2010

[Pharo-project] 2449 fixed

by Torsten Bergmann

HelpBrowser with taskbarIcon, simple and ready to be harvested http://code.google.com/p/pharo/issues/detail?id=2449 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 20, 2010

[Pharo-project] inbox cleaning

by Torsten Bergmann

Hi Stephane, the MCZ's for HelpSystem-Core-tbn.45 HelpSystem-Core-tbn.43 were already harvested. So shouldnt this be moved to treated inbox then? Thx T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 20, 2010

Re: [Pharo-project] MetaSource demo app working again

by Mariano Martinez Peck

Cool Torsten. I have just tested in Mac and I got a problem since ExternalWebBrowserMacOS class >> isApplescriptAvailable uses SMSqueakMap cheers mariano 2010/5/20 Torsten Bergmann <astares(a)gmx.de> > MetaSource (a demo seaside app) was moved to Pharo 1.1. > The loading via ConfigurationOfMetaSource/ConfigurationOfPharo > is now working again. > > Image Building is very easy (but slow) - just drop > the attached file onto an up to date (#11367) Pharo 1.1. core > image and select "file in" or evaluate the containted code > in a workspace. > > When finished select "Tools" -> "MetaSource" from the world > menu and then "Start" and "Browse" to open the app in the web browser. > > Tested on Windows. Would be nice if someone has the time to > test a Linux or Mac build. Thanks. > > Bye > T. > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2010