August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] RFB server again

by Miguel Enrique CobÃ¡ Martinez

El lun, 03-08-2009 a las 20:45 +0200, Lukas Renggli escribiÃ³: > > 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. > > Yes, the one in my repository works with the new event system in > Pharo. It does not work in any other image though. > > > 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)? > > Sure, feel free to commit the code to my repository. > > Actually I already patched out most of the annoying GUI prompts > myself. I use the code in many headless production images for years > already and start/stop the server with "RBFServer start: 2" / > "RBFServer stop". Yes, but I want to add accessor to set/get the different preferences by code and not by the menu. This is what I want to add, so we can completly configure a RFB server with a script in a workspace or as a initial script, for booting core-images for production use (the aim of core-images as I remember). > > > 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. > > Feel free to post it to a new repository if you want. I did not commit > my changes to the official repository because the repository is > read-only and because I changed many things that might not be to the > linkings of a wider audience. > > > 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 don't remember. Presumably I changed that because it was the only > reasonable setting. > > > I can't find users of initialize on RFBServer class side. Where it is > > called? On loading by Monticello? > > Yes, class-side initializers are called when the code is loaded. > > > What is the difference between names initialise (on instance side) and > > initialize (on class side). Is a typo? > > #initialize on instance-side is called when the object is instantiated > with #new. Yes, but I mean the name, not the function. Instance side use initiali"s"e and the class side use initiali"z"e, maybe it is just 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? > > I don't think this should go to the PharoInbox, this is not a > core-image package. > > Lukas >

Aug. 3, 2009

Re: [Pharo-project] RFB server again

by Lukas Renggli

> 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. Yes, the one in my repository works with the new event system in Pharo. It does not work in any other image though. > 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)? Sure, feel free to commit the code to my repository. Actually I already patched out most of the annoying GUI prompts myself. I use the code in many headless production images for years already and start/stop the server with "RBFServer start: 2" / "RBFServer stop". > 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. Feel free to post it to a new repository if you want. I did not commit my changes to the official repository because the repository is read-only and because I changed many things that might not be to the linkings of a wider audience. > 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 don't remember. Presumably I changed that because it was the only reasonable setting. > I can't find users of initialize on RFBServer class side. Where it is > called? On loading by Monticello? Yes, class-side initializers are called when the code is loaded. > What is the difference between names initialise (on instance side) and > initialize (on class side). Is a typo? #initialize on instance-side is called when the object is instantiated with #new. > 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? I don't think this should go to the PharoInbox, this is not a core-image package. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 3, 2009

[Pharo-project] RFB server again

by Miguel Enrique CobÃ¡ Martinez

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Ã¡

Aug. 3, 2009

Re: [Pharo-project] NetNameResolver class >> useOldNetwork

by Dale Henrichs

Okay, I see that this is related to http://code.google.com/p/pharo/issues/detail?id=794 and I suppose I am lucky the UseOldNetwork is working for me... Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | 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 | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 3, 2009

[Pharo-project] NetNameResolver class >> useOldNetwork

by Dale Henrichs

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

Aug. 3, 2009

Re: [Pharo-project] 1.0beta Chinese fonts and symbol bugs

by Marcus Denker

Hello, Can you open a bug-report? http://code.google.com/p/pharo/issues/list On 01.08.2009, at 19:10, empty wrote: > > 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 3, 2009

Re: [Pharo-project] Debbuging problems, FFI

by Mariano Martinez Peck

Thanks Javier PimÃ¡s and Andreas Raab for the excellent debugging and work. Andreas propose a fix (based in Javier work) and he has commited to Squeak. I look at the changes and try them in pharo. It works perfect!!! So, here is the ticket I open for pharo: http://code.google.com/p/pharo/issues/detail?id=1029 You have to do 2 things to make it work: 1) download latest ffi (FFI-Kernel-ar.11). You can evaluate "ScriptLoader loadFFI" 2) filein the attached changeset (in ticket) to ContextPart>>doPrimitive: primitiveIndex method: meth receiver: receiver args: Please test it and let me know the results so that this can be integrated. For me it worked perfect. Best, Mariano 2009/8/2 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > 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> > > >> >> 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)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> 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> >>>> >>>> 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> >>>>> >>>>>> 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 >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> 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 >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Henrik Johansen

On Aug 3, 2009, at 3:26 03PM, Mariano Martinez Peck wrote: > > > On Mon, Aug 3, 2009 at 10:15 AM, Serge Stinckwich <serge.stinckwich(a)gmail.com > > wrote: > On Mon, Aug 3, 2009 at 6:05 PM, Henrik > Johansen<henrik.s.johansen(a)veloxit.no> wrote: > > 2 things bugging me on Mac with the beta "dev" image: > > (Not sure if you could call them bugs, since they seem to be > artifacts > > caused in some way by initialization needed but not done by the > build > > script) > > > > - System browsers do not have proper drop-shadows while dragged, > thus > > lag alot. > > Resizing the browser by a moderate amount causes the correct > shadow to > > be used on a case by case basis, if you resize the entire Pharo > window > > by some amount, all new browsers will have the "proper" shadow. > > I don't know if I understood corrrectly but did you try turning on > "fastDragWindowForMorphic" ? No. This is with an image just opened after downloading, nothing changed from default settings. After resizing so the "correct" dropshadow behaviour is initialized, dragging is quite snappy even without fastDrag. (resizing is still slow, of course) I attached two images to 1026, so you can see the visual difference if you want. Cheers, Henry

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Mariano Martinez Peck

On Mon, Aug 3, 2009 at 10:15 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > On Mon, Aug 3, 2009 at 6:05 PM, Henrik > Johansen<henrik.s.johansen(a)veloxit.no> wrote: > > 2 things bugging me on Mac with the beta "dev" image: > > (Not sure if you could call them bugs, since they seem to be artifacts > > caused in some way by initialization needed but not done by the build > > script) > > > > - System browsers do not have proper drop-shadows while dragged, thus > > lag alot. > > Resizing the browser by a moderate amount causes the correct shadow to > > be used on a case by case basis, if you resize the entire Pharo window > > by some amount, all new browsers will have the "proper" shadow. > I don't know if I understood corrrectly but did you try turning on "fastDragWindowForMorphic" ? > > > > > - Close/minimize buttons on windows in the background do not show > > unless you hover over them. > > This can be fixed by changing to another window theme, then back to > > Watery2. > > Yes +1 for this one. > Maybe buttons can be drawn in gray when the focus is not on the > window, as done in mac os X UI. +1 also for this one. > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Henrik Johansen

On Aug 3, 2009, at 1:37 21PM, Damien Cassou wrote: > please report these two bugs on the issue tracker in two different > reports. > > Thank you Done, as issues 1026 and 1027. Cheers, Henry

Aug. 3, 2009