September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] shift of -1@0 when clicking a morph

by Tudor Girba

Hi, Apparently, this issue is related to VMs at least on Mac. Try the followings: 1. download sample image: http://dl.dropbox.com/u/18323746/Tmp/moose-drag-issue.zip 2. execute it with the latest Jenkins blessed VM: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Cocoa-blessed/lastSucc… - click on 1 or 3 on the left hand side (repeatedly - sometimes the issue does not appear straightaway) - the pane to the right should be updated with the numbers but it is not. Instead the clicked number slightly moves (due to dragging) 3. now execute the same image with the Elliot's VM: http://www.mirandabanda.org/files/Cog/VM/VM.r2489/Cog.app.tgz - click on 1 or 3 on the left hand side - the pane to the right is updated and the number on the left does not move at all Cheers, Doru On 13 Sep 2011, at 11:57, Mariano Martinez Peck wrote: > > > On Tue, Sep 13, 2011 at 11:27 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Have you checked to morph's bounds in case the origin/corner has non Integer values? > I've seen odd behaviour when they are Floats or Fractions. > > > yes, like putting them into a PointArray. Floats for example will lose the decimal part. > > (just a stab-in-the-dark, worth checking though) > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, September 10, 2011 7:34 PM > Subject: Re: [Pharo-project] shift of -1@0 when clicking a morph > > > > Just to stress this issue a bit more: > > The problem is critical for getting Mondrian to work properly with Glamour (be able to get the interaction from the visualization in the surrounding browser), and it is a show stopper for releasing Moose 4.6. Any help would be appreciated. > > Cheers, > Doru > > > On 10 Sep 2011, at 08:40, StÃ©phane Ducasse wrote: > > > On Sep 10, 2011, at 2:06 AM, Alexandre Bergel wrote: > > Hi! > > In Pharo 1.3 13287 I am experiencing something very strange. Apparently, when I click a morph the mouseOver: event has a x value reduced by 1. This happens only when I click. Subsequent mouseOver: are fine. This triggers an odd behavior in Mondrian. > > Strange indeed. > > > In Pharo 1.4 14112, this strange behavior has disappeared. > > I tried to load some more recent packages of Morphic, Graphics, Polymorph... without success (either I get an emergency debugger or the image freezes). > > Maybe: http://code.google.com/p/pharo/issues/detail?id=4503 ? But I could not find the Slice. > > No I do not think this is related > > Stef > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Sept. 13, 2011

[Pharo-project] Zodiac Alpha - September 13, 2011

by Sven Van Caekenberghe

I uploaded a modified PharoOneClick 1.3 app for Mac OS X, Linux and Windows to make it easier for others to test Zodiac, an as yet unfinished attempt at a better (secure) socket stream, in order to support HTTPS. This is a 40Mb download. The included VM contains the necessary native SSL plugins for each platform. The image itself was built as follows: ---- "Started with a standard Pharo One Click 1.3 #13306" Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; package: 'Zinc-Patch-HTTPSocket'; load. Gofer it squeaksource: 'Zodiac'; package: 'Zodiac-Core'; package: 'Zodiac-Tests'; load. Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-Zodiac'; load. "Switch to the Zn Zodiac socket factory" ZnNetworkingUtils default: ZnZodiacNetworkingUtils new. "Note: all http(s) in the image will now go through Zodiac streams" "** Make sure to use a Mac OS X Cog VM with the SSL plugin **" "Run the units tests, or just try" ZnClient get: 'https://encrypted.google.com'. --- Normally, all tests pass on Mac OS X, on Linux #testGForceInria fails, on Windows additionally #testAmazonAWS and #testPayPal fail. Additionally, #testSlashdotGzipChunked from the regular Zn sometimes fails because the server that is tested sometimes returns an unexpected answer (actually the test is not very good). Sven

Sept. 13, 2011

Re: [Pharo-project] Pharo One Click 1.3 LNK file

by Lukas Renggli

On 13 September 2011 21:00, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > There is a problem with the current Pharo One Click 1.3 LNK (.lnk) file on Windows. > > It refers to non existing paths and thus does not work. > > More specifically the 'Target' and 'Starts In' fields are wrong. > > I know close to nothing about Windows, can somebody else help here ? As far as I observed newer versions of Windows do not support relative references anymore. The only possible solution I see is to move the .exe into the root (with the wrong icon) and to somehow use the .ini file to get it going with the right image. > An additional problem is that these one click artifacts are built on Linux where the .lnk file probably cannot be edited. Yeah, the .lnk file has to be created on Windows. Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 13, 2011

[Pharo-project] Pharo One Click 1.3 LNK file

by Sven Van Caekenberghe

There is a problem with the current Pharo One Click 1.3 LNK (.lnk) file on Windows. It refers to non existing paths and thus does not work. More specifically the 'Target' and 'Starts In' fields are wrong. I know close to nothing about Windows, can somebody else help here ? Ideally these should refer relatively to the right directories, so that when the containing directory changes its name or is moved things don't break. Similar to what the Linux .sh script does. An additional problem is that these one click artifacts are built on Linux where the .lnk file probably cannot be edited. Sven

Sept. 13, 2011

Re: [Pharo-project] What is an abstract method?

by Lukas Renggli

The definition of what is considered an abstract class/method highly depends on the point of view. Therefor I have repeatedly argued that it is a very bad idea to have ClassDescription>>#isAbstractClass, Class>>#isAbstractClass, MetaClass>>isAbstractClass, and CompiledMethod>>#isAbstract. I don't see any users of these methods in my image, everybody correctly implements his own. Lukas On 13 September 2011 20:32, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Sep 13, 2011 at 10:52 AM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >> Hi! >> >> Apparently, the following method is abstract: >> >> ArrayedCollection>>add: newObject >> self shouldNotImplement >> >> If I evaluate: >> (ArrayedCollection>>#add:) isAbstract => true >> >> This is not quite right. A method that is cancelled is not abstract. >> >> I propose to change >> CompiledMethod>>abstractMarkers >> ^ #(subclassResponsibility shouldNotImplement) >> >> into >> CompiledMethod>>abstractMarker >> ^ #shouldNotImplement >> > > CompiledMethod>>abstractMarker > ^ #subclassResponsibility > no? > > >> Does it make sense? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > > -- > best, > Eliot > > -- Lukas Renggli www.lukas-renggli.ch

Sept. 13, 2011

Re: [Pharo-project] Zinc HTTPS

by Guillermo Polito

In Linux/Pharo1.4 I've 2 failing tests: testGForceInria testSlashdotGzipChunked Thank you very much! :) On Tue, Sep 13, 2011 at 9:42 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 12 Sep 2011, at 14:45, Sven Van Caekenberghe wrote: > > > Now, I still have to try the actual SSL tests by moving the plugin inside > the One Click VM's on Linux and Windows. > > I'll report on how that goes later on when I have some more time. > > I took a current Pharo One Click 1.3 (actually #13299) and placed the > matching plugins from > http://squeakssl.googlecode.com/files/SqueakSSL-bin-0.1.4.zip in the right > places (I had to chmod +x the linux one) and tested the latest Zinc and > Zodiac code, like this: > > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-HTTP'; > package: 'Zinc-Tests'; > package: 'Zinc-Patch-HTTPSocket'; > load. > > Gofer it > squeaksource: 'Zodiac'; > package: 'Zodiac-Core'; > package: 'Zodiac-Tests'; > load. > > Gofer it > squeaksource: 'ZincHTTPComponents'; > package: 'Zinc-Zodiac'; > load. > > "Switch to the Zn Zodiac socket factory" > > ZnNetworkingUtils default: ZnZodiacNetworkingUtils new. > > > The good news is that, as I reported before, the non secure socket streams > run without problems on all platforms. > > Also good is that the secure socket streams with the native plugin work, > that is, on all platforms you can now do > > ZnClient get: 'https://encrypted.google.com' > > The bad news is that the 7 ZnHttpsTests behave differently on the different > platforms: > > - Mac OS X: 7 green > - Linux: 1 failure > - Windos: 3 failures > > The problem of course is that this is pretty hard to debug: although the > image, Zodiac and Zinc code is of course identical, the VM and the plugin > differ for each platform. > > People interested in this can try to do this themselves; later on I might > make a customized OneClick download as a second Zodiac Alpha release, where > both the image and VM are ready to test. > > Sven > > >

Sept. 13, 2011

Re: [Pharo-project] What is an abstract method?

by Eliot Miranda

On Tue, Sep 13, 2011 at 10:52 AM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi! > > Apparently, the following method is abstract: > > ArrayedCollection>>add: newObject > self shouldNotImplement > > If I evaluate: > (ArrayedCollection>>#add:) isAbstract => true > > This is not quite right. A method that is cancelled is not abstract. > > I propose to change > CompiledMethod>>abstractMarkers > ^ #(subclassResponsibility shouldNotImplement) > > into > CompiledMethod>>abstractMarker > ^ #shouldNotImplement > CompiledMethod>>abstractMarker ^ #subclassResponsibility no? > Does it make sense? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- best, Eliot

Sept. 13, 2011

Re: [Pharo-project] FS writestream

by StÃ©phane Ducasse

Ok now who will do that? Stef On Sep 13, 2011, at 6:12 PM, Igor Stasenko wrote: > On 13 September 2011 16:41, Lukas Renggli <renggli(a)gmail.com> wrote: >> Then you also need to specify an encoding. Otherwise it does not make >> sense for a FSReadStream to return a String. >> >> Strictly speaking the FSWriteStream shouldn't accept a String as input either. >> > > +1000 > > there should be a clear separation between binary and text. > I think that mixing the code for text and binary modes in single class > is a source of errors and confusion. > > The code: > > stream := (working / 'foo.txt') writeStream. > > should be something like: > > > stream := (working / 'foo.txt') writeStream textStream. > > where textStream should answer the wrapper stream around the original > stream, something like: > > textStream > ^ UnicodeTextWriteStream on: self > > > then when you do: > > stream nextPutAll: 'abc' > > the wrapper stream takes care about converting input string into > bytearray and then passing it further to basic stream. > Of course there could be an optimization, if input string are > bytestring etc , but model should be separated. > > >> Lukas >> >> On 13 September 2011 16:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> or strings and widestrings. >>> >>> Stef >>> On Sep 13, 2011, at 4:11 PM, Alexandre Bergel wrote: >>> >>>> Looks like there is a confusion between binary and text stream >>>> >>>> Alexandre >>>> >>>> On 13 Sep 2011, at 11:09, StÃ©phane Ducasse wrote: >>>> >>>>> | working stream | >>>>> working := FSFilesystem disk workingDirectory. >>>>> stream := (working / 'foo.txt') writeStream. >>>>> stream nextPutAll: 'Hello World'. >>>>> stream close. >>>>> stream := (working / 'foo.txt') readStream. >>>>> stream contents. >>>>> returns >>>>> #[72 101 108 108 111 32 87 111 114 108 100] >>>>> >>>>> instead of 'Hello World' >>>>> >>>>> Does anybody have a fix..? >>>>> >>>>> Stef ( editing FS chapter). >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Sept. 13, 2011

[Pharo-project] What is an abstract method?

by Alexandre Bergel

Hi! Apparently, the following method is abstract: ArrayedCollection>>add: newObject self shouldNotImplement If I evaluate: (ArrayedCollection>>#add:) isAbstract => true This is not quite right. A method that is cancelled is not abstract. I propose to change CompiledMethod>>abstractMarkers ^ #(subclassResponsibility shouldNotImplement) into CompiledMethod>>abstractMarker ^ #shouldNotImplement Does it make sense? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2011

Re: [Pharo-project] MethodContext #tempScopedNames vs #tempAt

by Philippe Marschall

On 12.09.2011 23:11, Eliot Miranda wrote: > Hi Phillipe, > > On Mon, Sep 12, 2011 at 11:06 AM, Philippe Marschall > <kustos(a)gmx.net <mailto:kustos@gmx.net>> wrote: > > Hi > > While trying to debug the debugger in Seaside (hi Mike) I stumbled on > something funny. Seaside the following code to work: > > Semaphore forMutualExclusion critical: [ > | sender | > sender := thisContext sender. > sender tempAt: sender tempScopedNames size ] > > > This just won't work with the Closure compiler. This approach only > worked with old blue-book blocks Squeak. Instead you need to look at > DebuggerMethodMap, tempNamesForContext:, namedTempAt: et al. Ok, I tried implementing it in terms of #tempNamesForContext: (through #tempNames) and #namedTempAt: this works sometimes and in other times I get 'Instances of UndefinedObject are not indexable'. See the attached unit test. Cheers Philippe

Sept. 13, 2011