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

Re: [Pharo-project] [ANN] Video Course on Smalltalk

by Geert Claes

Yep, do let us know when the English version is available! -- View this message in context: http://n2.nabble.com/ANN-Video-Course-on-Smalltalk-tp4454395p4459336.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 26, 2010

Re: [Pharo-project] new mac menu code :)

by Adrian Lienhard

Great! I updated http://code.google.com/p/pharo/issues/detail?id=1323 Adrian On Jan 26, 2010, at 00:26 , John M McIntosh wrote: > Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email. > > The problem is related to what InputEventSensor>>processEvent: does. > > Normally the expectation is that this method takes the existing event and does some type of post processing. > to set state or twiddle the event data, then return the modified event. > > However the EventTypeMenu is different and doesn't follow expectations. Instead generates > three synthetic keyboard events which are pushed to the queue and returns nil. > > Now the problem then is triggered if someone calls InputSensor>>peekEvent with just the right timing to > see the menu event on the queue. If that happens from Morph's desired to peek ahead to make decision on > mouse movement or keyboard interaction, then the side effect of the peek is to generate a duplicate set of > synthetic keystrokes. > > The fix is to alter peekEvent so that we ignore for EventTypeMenu > > peekEvent > "Look ahead at the next event." > | nextEvent | > nextEvent := eventQueue peek. > ^((nextEvent isNil not) and: [(nextEvent at: 1) ~= EventTypeMenu]) > ifTrue: [self processEvent: nextEvent] > > > > As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and > I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years. > > > On 2010-01-25, at 12:14 PM, StÃ©phane Ducasse wrote: > >>> File in Michael's change first, then mine > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 26, 2010

Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?

by HernÃ¡n Morales Durand

Hi Alex, Notice that you don't need files to save workspaces, you may like the ScriptManager package, to install simply evaluate: Gofer new squeaksource: 'DeveloperWorkspace'; package: 'ScriptManager'; load. and open it from Tools -> More -> Script Manager Cheers, HernÃ¡n 2009/12/16 alesch <alex(a)schenkman.info>: > > I remember I used a menu item in Squeak, but I cannot find in Pharo. > > Thanks! > -- > View this message in context: http://n2.nabble.com/newbee-How-do-I-save-the-contents-of-a-Workspace-tp417… > 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 >

Jan. 26, 2010

Re: [Pharo-project] new mac menu code :)

by John M McIntosh

Ok, I figured it out, well I think I did.. Mariano is confirming... But I'll post the expected fix in this email. The problem is related to what InputEventSensor>>processEvent: does. Normally the expectation is that this method takes the existing event and does some type of post processing. to set state or twiddle the event data, then return the modified event. However the EventTypeMenu is different and doesn't follow expectations. Instead generates three synthetic keyboard events which are pushed to the queue and returns nil. Now the problem then is triggered if someone calls InputSensor>>peekEvent with just the right timing to see the menu event on the queue. If that happens from Morph's desired to peek ahead to make decision on mouse movement or keyboard interaction, then the side effect of the peek is to generate a duplicate set of synthetic keystrokes. The fix is to alter peekEvent so that we ignore for EventTypeMenu peekEvent "Look ahead at the next event." | nextEvent | nextEvent := eventQueue peek. ^((nextEvent isNil not) and: [(nextEvent at: 1) ~= EventTypeMenu]) ifTrue: [self processEvent: nextEvent] As for the changes earlier posted, we should run with those. Michael altered them to make the logic cleaner, and I had to change the cmd-key to synthetic key generation to meet expectations based on changes done in the last 5 years. On 2010-01-25, at 12:14 PM, StÃ©phane Ducasse wrote: >> File in Michael's change first, then mine -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 25, 2010

Re: [Pharo-project] help with removing a file

by John M McIntosh

I *think* you can run into problems if your evil windows virus package has the file OPEN has it's trying to figure out which of the 100 million viruses could exist in the file. This can cause your delete to fail. Maybe you have to wait 1000 milliseconds? for Norton to catch up? The windows code runs the following code, and there is a FAIL check to see if there is a duplicate file name based on case sensitivity. sqInt sqFileDeleteNameSize(char* fileNameIndex, sqInt fileNameSize) { WCHAR win32Path[MAX_PATH+1]; int sz; /* convert the file name into a null-terminated C string */ sz = MultiByteToWideChar(CP_UTF8, 0, fileNameIndex, fileNameSize, NULL, 0); if(sz > MAX_PATH) FAIL(); MultiByteToWideChar(CP_UTF8, 0, fileNameIndex, fileNameSize, win32Path, sz); win32Path[sz] = 0; if(hasCaseSensitiveDuplicate(win32Path)) FAIL(); if(!DeleteFileW(win32Path)) FAIL(); return 1; } On 2010-01-25, at 2:07 PM, Mariano Martinez Peck wrote: > Hi folks. I don't want other than green tests in dev images, thus, I started to fix them as much as possible. There are a lot of failing tests of Nile (only fail in windows). The test is NSCompressedSourceStreamTest and I noticed something weird. If you look to tearDown method, it tries to remove two files that it actually were created in the setUp method. > > But it is weird because it tries to remove a file that actually exist and it is not being removed. > > If I debug in DosFileDirectory >> deleteFileNamed: localFileName ifAbsent: failBlock > > everything looks ok, but the file is not removed and the failBlock is executed :( > > localFileName -> 'testCompressedSourceStream.stc' > > (self fullNameFor: localFileName) asVmPathName -> 'C:\mariano\squeak\imagenes\Pharo1.0-10508-rc2dev10.01.2\testCompressedSourceStream.stc' > > And that file exist, as you can see in screenshot that I attach. > > Can someone help me with this ? > > Cheers > > Mariano > <Picture 2.png>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 25, 2010

Re: [Pharo-project] Failing Gofer test in windows [WAS] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Lukas Renggli

> Just make a bug report and put the version in the inbox (and make sure it's mergable, that is, > provide all nececary intermediate versions) It probably won't merge because I splitted the package into a Core and a Test package, so the tests don't have to be present as well. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 25, 2010

Re: [Pharo-project] Failing Gofer test in windows [WAS] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Marcus Denker

On Jan 25, 2010, at 10:59 PM, Mariano Martinez Peck wrote: > hahahahahahahah > > BTW...do you know who/when merges your latest gofer code into PharoCore? > Just make a bug report and put the version in the inbox (and make sure it's mergable, that is, provide all nececary intermediate versions) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 25, 2010

Re: [Pharo-project] Failing Gofer test in windows [WAS] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Dale Henrichs

On second thought .. I don't have too... I want to push Metacello 1.0-beta.22 today... Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | | | BTW...do you know who/when merges your latest gofer code into | | PharoCore? | | I'll hold off ConfigurationOfGofer until the bugfix is merged into | Pharo repository... | | Dale | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 25, 2010

Re: [Pharo-project] Failing Gofer test in windows [WAS] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Dale Henrichs

----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | BTW...do you know who/when merges your latest gofer code into | PharoCore? I'll hold off ConfigurationOfGofer until the bugfix is merged into Pharo repository... Dale

Jan. 25, 2010

[Pharo-project] help with removing a file

by Mariano Martinez Peck

Hi folks. I don't want other than green tests in dev images, thus, I started to fix them as much as possible. There are a lot of failing tests of Nile (only fail in windows). The test is NSCompressedSourceStreamTest and I noticed something weird. If you look to tearDown method, it tries to remove two files that it actually were created in the setUp method. But it is weird because it tries to remove a file that actually exist and it is not being removed. If I debug in DosFileDirectory >> deleteFileNamed: localFileName ifAbsent: failBlock everything looks ok, but the file is not removed and the failBlock is executed :( localFileName -> 'testCompressedSourceStream.stc' (self fullNameFor: localFileName) asVmPathName -> 'C:\mariano\squeak\imagenes\Pharo1.0-10508-rc2dev10.01.2\testCompressedSourceStream.stc' And that file exist, as you can see in screenshot that I attach. Can someone help me with this ? Cheers Mariano

Jan. 25, 2010