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

Re: [Pharo-project] First commit to Pharoinbox. Need advice.

by Igor Stasenko

On 26 January 2011 08:13, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > > My last package is Balloon-hjo.72.mcz. > It is small testing & refactoring on Ballloon supporting collections. > > I wonder this type of work is acceptable? Are you joking? Any contribution is acceptable. Of course if its pass the quality test :) And anything which improves functionality & cleans the code is acceptable. Can i ask you to make life easier for review? Please create entry in issue tracker , put a link to file there and a little description of your changes. This is to make life easier for people who will review your code and integrate it. :) Also, this will make integration process visible to all people. > > Best Regards > -- > View this message in context: http://forum.world.st/First-commit-to-Pharoinbox-Need-advice-tp3237535p3237… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Jan. 26, 2011

[Pharo-project] Smalltalk and the Canvas

by Fernando Olivero

Being the Canvas so popular these days, (HTML5, CairoGraphics, etc..),i wonder if its correct to state that it was introduced together with Smalltalk? Does someone know if this claim is correct? Fernando

Jan. 26, 2011

[Pharo-project] First commit to Pharoinbox. Need advice.

by HwaJong Oh

My last package is Balloon-hjo.72.mcz. It is small testing & refactoring on Ballloon supporting collections. I wonder this type of work is acceptable? Best Regards -- View this message in context: http://forum.world.st/First-commit-to-Pharoinbox-Need-advice-tp3237535p3237… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 26, 2011

[Pharo-project] Issue 3595 in pharo: problem starting up with a script on windows

by pharo＠googlecode.com

Status: Accepted Owner: tudor.gi...(a)gmail.com Labels: Milestone-1.2 Milestone-1.3 Type-ReportDefect New issue 3595 by tudor.gi...(a)gmail.com: problem starting up with a script on windows http://code.google.com/p/pharo/issues/detail?id=3595 Pharo image: Dev Pharo core version: <copy from World/System/About> Virtual machine used: Cog 2316, 2348 There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. The problem seems to be in CodeLoader>>installSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. The debug log is listed below. I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). Attachments: PharoDebug.log 7.8 KB

Jan. 26, 2011

Re: [Pharo-project] problem starting up with a script on windows

by Tudor Girba

Done: http://code.google.com/p/pharo/issues/detail?id=3595 Doru On 25 Jan 2011, at 21:43, StÃ©phane Ducasse wrote: > Thanks doru. > Can you open a ticket? > > Stef > >> I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. >> >> Ah, one more detail: I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). >> >> It would be great if someone else could confirm. >> >> Cheers, >> Doru >> >> >> On 25 Jan 2011, at 14:04, Tudor Girba wrote: >> >>> Hi, >>> >>> There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. >>> >>> The problem seems to be in CodeLoader>>installSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. I attached the debug.log. >>> >>> I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. >>> >>> I cannot debug well because I do not have a Windows machine (the situation happens on a server that I cannot access easily). Can someone take a look to see if the problem can be reproduced? >>> >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "The coherence of a trip is given by the clearness of the goal." >>> >>> >>> <PharoDebug.log> >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that happen. They both matter." >> >> >> >> >> >> > > -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

Jan. 26, 2011

Re: [Pharo-project] debugger problems?

by Eliot Miranda

On Tue, Jan 25, 2011 at 2:58 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > yes as Adrian pointed out debugger highlighting is broken in Pharo. > Has been since the very beginning. what we need ideally is a set of > test cases describing the desired behaviour. i struggled to simulate > this, i am not sure what a good test harness is for the debugger. > ideally the highlighting can be tested without the debugger (i.e > without the necessary processes and activations), just triggering the > necessary execution machinery that calculates highlight offsets > (intervals). With a good set of tests we could then better compare > Squeak and Pharo implementations because a lot of fixes go into squeak > and we need to harvest them over here. any help of course welcome in > this area. I poke at it now and then.... > Take a look at the ClosureCompilerTest>>testSourceRangeAccessForClosureBytecodeInjectInto which tests the source ranges (that the debugger uses to highlight) for all pcs in the inject:into: method. > cheers, > Mike > > On Tue, Jan 25, 2011 at 2:20 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Jan 25, 2011, at 14:05 , Tudor Girba wrote: > > > >> I am not alone! :) > >> > >> Anyone else noticed this? > > > > yes > > > > Is it http://code.google.com/p/pharo/issues/detail?id=709 ? > > > > Adrian > > > > > >

Jan. 26, 2011

Re: [Pharo-project] debugger problems?

by Michael Roberts

yes as Adrian pointed out debugger highlighting is broken in Pharo. Has been since the very beginning. what we need ideally is a set of test cases describing the desired behaviour. i struggled to simulate this, i am not sure what a good test harness is for the debugger. ideally the highlighting can be tested without the debugger (i.e without the necessary processes and activations), just triggering the necessary execution machinery that calculates highlight offsets (intervals). With a good set of tests we could then better compare Squeak and Pharo implementations because a lot of fixes go into squeak and we need to harvest them over here. any help of course welcome in this area. I poke at it now and then.... cheers, Mike On Tue, Jan 25, 2011 at 2:20 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > On Jan 25, 2011, at 14:05 , Tudor Girba wrote: > >> I am not alone! :) >> >> Anyone else noticed this? > > yes > > Is it http://code.google.com/p/pharo/issues/detail?id=709 ? > > Adrian > >

Jan. 25, 2011

Re: [Pharo-project] why does monticello updates accessing web when i save on dir?

by HwaJong Oh

Why on earth does Pharo thinks me as professional? I am not at that level yet. :-) So the waiting is needed for saver save. I should endure this, but I makes harder for my micro commit habbit. I try to commit as small as refactoring operation defined in the book "Refactoring-M. Fowler" so the reader of my code will clearly see the change. The commit cycle 1. refactor 2. run test 3. read package change 4. commit with comment with refactoring name followed by extra info: "ExtractMethod: #refreshLayoutsFor: " The waiting distracts my focus applying this. Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2011

Re: [Pharo-project] why does monticello updates accessing web when i save on dir?

by HwaJong Oh

Why on earth does Pharo thinks me as professional? I am not at that level yet. :-) So the waiting is needed for saver save. I should endure this, but I makes harder for my micro commit habbit. I try to commit as small as refactoring operation defined in the book "Refactoring-M. Fowler" so the reader of my code will clearly see the change. The commit cycle 1. refactor 2. run test 3. read package change 4. commit with comment with refactoring name followed by extra info: "ExtractMethod: #refreshLayoutsFor: " The waiting distracts my focus applying this. Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2011

[Pharo-project] Weird behavior in a package loaded with Monticello?

by simondenier

Recently I took a look at the Global Keys project of Tony Fleig and noticed something strange. The package GlobalKeys makes some class extensions to the HandMorph class, extensions which are accessors to an instance variable. Since instance variable can't be included in class extensions, the variable appears as undeclared instead. HandMorph>>globalKeystrokeHandler "class extension" ^globalKeystrokeHandler "is an undeclared variable" HandMorph>>globalKeystrokeHandler: aOneArgBlock globalKeystrokeHandler := aOneArgBlock However, when loading the package, class side initialization uses the mutator #globalKeystrokeHandler: to set a default behavior for 'World activeHand' (an instance of HandMorph) and... it works! No error, it just works as if the instance variable is well defined and can be accessed without problem. GlobalKeys class>>setHandMorphHook "called by class initialization" World activeHand globalKeystrokeHandler: [ :ev | | retval | retval := false. "..." ] How can it be that the first invocation of #globalKeystrokeHandler: in #setHandMorphHook does not crash? Try the following: Gofer new squeaksource: 'GlobalKeys'; version: 'GlobalKeys-TonyFleig.9'; load Print it: World activeHand globalKeystrokeHandler ---> print the source of a code block Now debug the above snippet and proceed *into* globalKeystrokeHandler Print it again ----> print nil as if the code was recompiled once processed by the debugger You can also add the instance var globalKeystrokeHandler, recompile, it will be set to nil. -- View this message in context: http://forum.world.st/Weird-behavior-in-a-package-loaded-with-Monticello-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2011