- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Custom user Interrupt handling
by Dale Henrichs Aug. 4, 2009

Aug. 4, 2009

Michael, What's the approved method for unregistering the current user interrupt handler? InputEventFetcher default eventHandlers copy do: [:hndlr | (hndlr isKindOf: UserInterruptHandler) ifTrue: [ hndlr unregister]]. Looks like it would work, but seems a bit fragile. Dale ----- "Michael Rueger" <m.rueger(a)acm.org> wrote: | Dale Henrichs wrote: | | > The class UserInterruptHandler is tantalizingly close, however, | there | > is no obvious way to insinuate myself as an interested | party....It's | > pretty much hard-wired to open a debugger on the interrupted | > process.... | | Just write your own class (e.g. subclass UserInterruptHandler) and | replace the handler (unregister the current one and register your | own). | | That's why I designed it the way it is :-) | | michael

3 2

[Pharo-project] Debbuging problems, FFI
by Javier PimÃ¡s Aug. 4, 2009

Aug. 4, 2009

Hi, I'm having problems with the debugger. Every time I try to debug code that uses FFI, if I step over a message that internally does an FFI call, I get an externalCallFailed error and then I land in MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: If I run the code without debugging, then I have no problems at all. I'm using SqueakPharo v3.11.2 with pharo0.1-10373web09.07.2. To reproduce it you can try this: ScriptLoader loadFFI. then load latest GLMorphic from squeaksource, and uncomment the "self break." in GLCanvas>>displayString:from:to:at:strikeFont:kern: doit World fullDrawOn: GLDisplayScreen testCanvas hit debug and step over until you reach ogl glTexImage2D: GLTexture2d with:... also you'll see wrong values for local vars, like aPoint which will look as #(nil nil nil nil nil) when it'll actually have a point. Is there any other way to set up a break point instead of adding self break to the code?? Thanks, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires

5 14

[Pharo-project] Fix for issue 981 Author class in pharo
by Miguel Enrique CobÃ¡ Martinez Aug. 4, 2009

Aug. 4, 2009

http://code.google.com/p/pharo/issues/detail?id=981 Name: SLICE-ChangeAuthorInitialsAndNameToFullName-MiguelCoba.3 Author: MiguelCoba Time: 25 July 2009, 3:53:41 am UUID: 27a1accc-4f41-4d11-94f5-9bdbb4166bd7 Ancestors: SLICE-ChangeAuthorInitialsAndNameToFullName-MiguelCoba.2 Dependencies: Monticello-MiguelCoba.372, Morphic-MiguelCoba.347, ScriptLoader-MiguelCoba.972, System-Changes-MiguelCoba.11, System-Support-MiguelCoba.62, Tools-MiguelCoba.179 Removes all the code from initials and name on Author class. It is replaced by a new fullName inst var and corresponding methods. The old code it is deprecated and the image contains no more calls to the old code. All the new code should call only the fullName methods in Author This is my first intent to rewrite the Author class to unify the instance variables. Please, check it on a 10392 core image and post your comments/critics. Also, I didn't modify the following methods of Utilities. Tell me what would you like to do with them, please: Utilities fixStamp: Utilities methodsWithInitials: Utilities doesMethod:forClass:bearInitials Cheers, Miguel CobÃ¡

4 4

[Pharo-project] 2 new plugin (for VMPluginOverview)
by Torsten Bergmann Aug. 3, 2009

Aug. 3, 2009

Maybe someone is able to include the following plugins in http://code.google.com/p/pharo/wiki/VMPluginOverview. Thanks Torsten OpenVGPlugin.dll ================ [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-August/137911.h… Cryptography.dll ================ http://leves.web.elte.hu/cryptography/ -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

2 1

[Pharo-project] [update] #10404
by Marcus Denker Aug. 3, 2009

Aug. 3, 2009

10404 ----- Fixes included: Issue 1006: cleanUpForRelease should remove empty methodcategories Issue 1005: ScriptLoader cleanupForRelease asks for initials... Issue 984: RenderBugz tests revised to avoid extraneous timing issues (Mantis 7045) Issue 900: Fix CodeLoader>>#exportCodeSegment:classes:keepSource: closed because not relevant: Issue 327: possible fix for monardig ifNotNil: inlining Open Reports left for 1.0: 49 -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

1 0

[Pharo-project] RFB server again
by Miguel Enrique CobÃ¡ Martinez Aug. 3, 2009

Aug. 3, 2009

Hi Lukas, sometime ago I asked which of the RFB/RemoteFrameBuffer versions should be the one to go for. I choose yours (http://source.lukar-renggli.ch/unsorted) because the one on squeak source hasn't had commits (maybe because they were not necessary) but more importantly, yours has been tailored to Pharo. I want to make some modifications to the code to better support configuration of preferences by scripts and not by GUI prompts (I am working my script to install and configure all I want in a pharo core image, something like Damien's work, but only with my code and its dependencies). For this, I want to share the code. Should I upload to your repo? It is open to upload (I'm almost sure it is)? Wouldn't be better to copy the RFB code from your repo to the Pharo/PharoInbox repo given that it will be used heavily with pharo-web/pharo-dev and more related to pharo than to lukas (I don't have anything against your repo, in fact it is full of good code, but I think that the more projects for pharo are stored in the same place, the better for the final user. Also, I foresee this version as the official one for pharo, not a version with addons/modifications/hacks for lukas' servers. Now the technical: In RFBServer class side: shouldConserveMemory "Answer whether the server should try to conserve memory at all costs." ^true always returns true. Why? this is used in the initializePreferences (class side) self shouldConserveMemory ifTrue: [ConserveMemory := true. EnableDamageFilter := false. EnableRawFilter := false] ifFalse: [ConserveMemory := false. EnableDamageFilter := true. EnableRawFilter := true]. to set the class variables and it doesn't permit other behavior. Shouldn't this be a preference method and when called, assing the apropriate variables values? I can't find users of initialize on RFBServer class side. Where it is called? On loading by Monticello? What is the difference between names initialise (on instance side) and initialize (on class side). Is a typo? I want to make and upload a new version with some modifications. After review, do you agree to copy them to PharoInbox or do you prefer to have it in your repo? Cheers, Miguel CobÃ¡

2 2

[Pharo-project] NetNameResolver class >> useOldNetwork
by Dale Henrichs Aug. 3, 2009

Aug. 3, 2009

Is there a rationale for why one would need to set UseOldNetwork to true in NetNameResolver. Using the 1.0beta on my laptop at home (OpenSuse) NetNameResolver works fine. On my machine at work (Ubuntu) the 1.0beta needs UseOldNetwork set to false to resolve names. It prints 'getaddrinfo: Name or service not known' to standard out unless UseOldNetwork is set to true. I've found a couple of interesting issues when poking around in NetNameResolver (I'll submit bug reports shortly): - UseOldNetwork is a not a a class var in NetNameResolver - instances of SocketAddress fail when printing probably because they are calling NetNameResolver primitives directly and should be calling the 'old' primitives I am using the latest linux vm in both cases and in earlier versions of Pharo I didn't have to monkey with UseOldNetwork to get network connectivity. Dale

1 1

[Pharo-project] 1.0beta Chinese fonts and symbol bugs
by empty Aug. 3, 2009

Aug. 3, 2009

Hi, I tried 1.0 beta on Windows XP to find Chinese Fonts having some problem. * each font can't display this much used common character æ and maybe more * now symbols are automaticallly turned from #ä¸å¥è©± into this:#'ä¸å¥è©±' and that is not needed since Chinese string doesn't contain any spaces * some fonts such as simsun-18030 will add space after each English letter and make things look like t h i s, that's incorrect In fact, as for Chinese fonts, the first test package of Unicode has been the best one. All later versions have problems. Sorry I know too little to contribute to code. Best Regards, Empt ----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://n2.nabble.com/1.0beta-Chinese-fonts-and-symbol-bugs-tp3370936p337093… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 1

[Pharo-project] Inria Mailinglist archive is not up to date
by Torsten Bergmann Aug. 3, 2009

Aug. 3, 2009

Looks like the mailing list archive is not updated: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-August/date.html -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

1 0

Re: [Pharo-project] [squeak-dev] Re: Debbuging problems, FFI
by Mariano Martinez Peck Aug. 3, 2009

Aug. 3, 2009

On Sun, Aug 2, 2009 at 11:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/8/2 Andreas Raab <andreas.raab(a)gmx.de>: > > Mariano Martinez Peck wrote: > >> > >> Javier has done an excellent job and here is his last post. Can someone > >> read what he found and see if we can fix this annoying bug? > > > > The problem is that you can't call #valueWithReceiver:args: since this > would > > both execute the entire method and do it in the wrong context where > instead > > you need to execute *just* the primitive (since you'll simulate the rest > if > > it fails). > > > > Fortunately, external functions have two ways to invoke them; one > implicitly > > as primitive in a method (i.e., prim 120) and another one explicitly (via > > invokeWithArgs:). A variant on the latter that returns > > ContextPart>>primFailToken does the trick nicely. > > > > I've updated both http://source.squeak.org/FFI and > > http://source.squeak.org/trunk with the ncessary bits. > > Andreas, does your change fixes the issue? Because its not clear from > your message - is it solves the problem altogether, or it is just a > first step towards proper fix? > Thanks Igor. I had the same questions as you. However, I downloaded that new version, and tried but I got same results (the behaviour of the first email). I mean, when I did step over in the api call I landed in and in MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > > > Cheers, > > - Andreas > > > >> > >> Thanks, > >> > >> Mariano > >> > >> > >> ---------- Forwarded message ---------- > >> From: *Javier PimÃ¡s* <elpochodelagente(a)gmail.com > >> <mailto:elpochodelagente@gmail.com>> > >> Date: 2009/8/2 > >> Subject: Re: [Pharo-project] Debbuging problems, FFI > >> To: Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> > >> > >> I Think I found where the problem lies, it's just sitting there waiting > to > >> be resolved. > >> > >> To see what was happening I debugged the debuger, which was really > weird. > >> I found the answer when I broke into the step over button by adding a > self > >> break in OTCmdOverDebugger>>execute. After catching it I removed the > break > >> and stepped into everything to see how step over worked. The intresting > part > >> is in MethodContext(ContextPart)>>step, which sends > >> interpretNextInstructionFor: self. The idea is this, instead of > advancing > >> the vm program counter within the vm code, the debugger simulates the > >> execution cycle, step by step. It not so hard as it seems but also not > very > >> simple. The problem comes when the debugger tryies to simulate primitive > >> calls. When the simulator detects a primitive, it issues a > >> MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here you > can > >> see the detection: > >> > >> tryPrimitiveFor: method receiver: receiver args: arguments > >> "..." > >> | primIndex | > >> (primIndex := method primitive) = 0 ifTrue: [^ PrimitiveFailToken]. > >> ^ self doPrimitive: primIndex method: method receiver: receiver args: > >> arguments > >> > >> well, the problem is that doPrimitive doesn't seem to implement all > >> primitives (I recomend you to look it's code), but just a few ones. > Also, as > >> far as I can see, it calls primitive 19, which i found is (by looking vm > C > >> code) primitiveFail, and that primitive just sets a flag that says that > >> something failed. > >> > >> Then, if my calculations are correct, the problem is that the FFI Call > >> primitive needs to be handled by hand. I tryied adding this to > >> ContextPart>>doPrimitive:method:receiver:args: > >> > >> primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate it > and > >> return" > >> [ meth valueWithReceiver: receiver arguments: arguments . ^self]. > >> > >> just before > >> > >> arguments size > 6 ifTrue: [^PrimitiveFailToken]. > >> > >> which I think almost worked. I think the primitive was executed, but > this > >> doesn't handle the execution context that is being simulated, and the > stack > >> gets corrupted. Somebody with more experience in ContextPart, > MethodContext, > >> etc. may give us a hand here, I think the fix is almost there. > >> > >> Bye, > >> Javier. > >> > >> 2009/7/31 Mariano Martinez Peck <marianopeck(a)gmail.com > >> <mailto:marianopeck@gmail.com>> > >> > >> > >> > >> 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com > >> <mailto:elpochodelagente@gmail.com>> > >> > >> Does anybody know if the problem occurs just in Windows or in > >> any OS? this can give a clue of the problem... > >> > >> > >> I don't remember debugging in Windows, but in Linux I have this > >> problem for sure. > >> > >> > >> On Thu, Jul 30, 2009 at 11:28 PM, Javier PimÃ¡s > >> <elpochodelagente(a)gmail.com <mailto:elpochodelagente@gmail.com>> > >> wrote: > >> > >> Well, at least I feel better that I'm not crazy, (or not the > >> only one...). Maybe if someone could give us a clue about > >> it, we could spot where the problem is. Do you think it is a > >> vm problem or something related to the smalltalk code? > >> > >> 2009/7/30 Mariano Martinez Peck <marianopeck(a)gmail.com > >> <mailto:marianopeck@gmail.com>> > >> > >> Yes. This is really annoying for me. I am writing a C > >> library plugin since a year and a half and this is very > >> frustrated :( > >> You cannot debug when using FFI. I mean, you cannot get > >> advantages of one of the best Smalltalk features! What I > >> do is to write a self break before and after the call > >> and use "proceed" but I don't like it at all. > >> > >> Once I tried to see what the problem was, but I was to > >> difficult to me to understand it and fix it. We need a > >> guru here I think hahaha. > >> > >> Best, > >> > >> Mariano > >> > >> 2009/7/30 Javier PimÃ¡s <elpochodelagente(a)gmail.com > >> <mailto:elpochodelagente@gmail.com>> > >> > >> Hi, I'm having problems with the debugger. Every > >> time I try to debug code that uses FFI, if I step > >> over a message that internally does an FFI call, I > >> get an externalCallFailed error and then I land in > >> > MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > >> If I run the code without debugging, then I have no > >> problems at all. > >> > >> I'm using SqueakPharo v3.11.2 with > >> pharo0.1-10373web09.07.2. > >> > >> To reproduce it you can try this: > >> > >> ScriptLoader loadFFI. > >> then load latest GLMorphic from squeaksource, and > >> uncomment the "self break." in > >> GLCanvas>>displayString:from:to:at:strikeFont:kern: > >> > >> doit > >> World fullDrawOn: GLDisplayScreen testCanvas > >> hit debug and step over until you reach > >> ogl glTexImage2D: GLTexture2d with:... > >> > >> also you'll see wrong values for local vars, like > >> aPoint which will look as #(nil nil nil nil nil) > >> when it'll actually have a point. > >> > >> Is there any other way to set up a break point > >> instead of adding self break to the code?? > >> > >> Thanks, > >> Javier. > >> > >> -- Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@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 > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> > >> -- Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> > >> > >> > >> -- Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@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 > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> > >> -- > >> Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> ------------------------------------------------------------------------ > >> > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

1 0