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

[Pharo-project] [update 2.0] #20271

by Marcus Denker

20271 ----- Issue 6594: shortDebugStackOn is TOO short http://code.google.com/p/pharo/issues/detail?id=6594 -- Marcus Denker -- http://marcusdenker.de

Aug. 28, 2012

[Pharo-project] [update 2.0] #20270

by Marcus Denker

20270 ----- Issue 6600: TestRunner >> methodChanged: is wrong http://code.google.com/p/pharo/issues/detail?id=6600 Issue 6598: We have a lot of incorrect CompiledMethods hanging around http://code.google.com/p/pharo/issues/detail?id=6598 -- Marcus Denker -- http://marcusdenker.de

Aug. 28, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by S Krish

It works for most parts. There are few examples I will send in a note that is broken. viz: AthensSurfaceExamples >> #exampleStrokeRect should probably in its subclass AthensCairoSurfaceExamples * #exampleDrawText.. and believe other Text drawing expect FreeTypeFont only as asserted ... but are sent StrikeFont.. * AthensTestRenderTest >> #testWindowRender fails as the PluggableTextMorph >> initialize has a an empty text #setText: '' call.. Need to go down lot more.. and play with it.. seems really neat for external module callout.. Great stuff, need to get down to bottom of it.. incentive enough to re-learn the necessary bits about assembly lang. Will look at integrating this permanently with my works till it fails to live up as stable.. BTW: is it extensible to ARM..? I believe so.. also for Raspberry kind of kits.. Long way off to try that out.. but just interested in knowing.. On Tue, Aug 28, 2012 at 6:48 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 August 2012 23:58, Lawson English <lenglish5(a)cox.net> wrote: > > I get this using Pharo 1.4. Thing is, it was working a few weeks ago and > now > > not. > > > > I was hoping to do a video on how to add simple ultra-fast assembler > methods > > using NB but still can't because the target is moving way too fast. My > usual > > strategy is to show how to load a package in a brief intro video, and > then > > how to use it in the second part. During the time I learned how to use > NB at > > the assembler level, everything that I was doing broke. > > > > I need you to say what is broken. The extension methods which was lost > due to 1.4/2.0 disturbance > is not a big deal (i hope), i am added them back, so things should do > not break out of the box on 1.4. > > And if you have more problems with it, please tell, because there was > not many changes at that level > and in overall most of changes are cosmetic and not functional (like > changing decorate:while: to decorate:during:). All of the code i wrote > works without changes, so if you have different problem just say, > Lawson. And please be more specific, because "everything" is not very > precise word for describing a problem :) > > > Kinda hard to make a video to show how to install and then use it those > > circumstances. > > I trying to keep the installation instructions up to date on project web > site. > > > > > L > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 28, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by StÃ©phane Ducasse

If you do not provide a decent description of what could be the problem how igor can help you? Because if you see each time jan for a precise question he gets an answer or an enhancement. Stef On Aug 27, 2012, at 11:58 PM, Lawson English wrote: > I get this using Pharo 1.4. Thing is, it was working a few weeks ago and now not. > > I was hoping to do a video on how to add simple ultra-fast assembler methods using NB but still can't because the target is moving way too fast. My usual strategy is to show how to load a package in a brief intro video, and then how to use it in the second part. During the time I learned how to use NB at the assembler level, everything that I was doing broke. > > Kinda hard to make a video to show how to install and then use it those circumstances. > > L > > > On 8/27/12 12:01 AM, Nicolas Cellier wrote: >> Pharo 2.0 has implemented & -> bitAnd: and | -> bitOr: >> >> For who is dealing with bits, that's convenient, however it creates >> one more case of false polymorphism, these messages being used for >> Boolean already... >> >> Nicolas >> >> 2012/8/27 S Krish <krishnamachari.sudhakar(a)gmail.com>: >>> On loading up and testing NB: >>> >>> I get possibly a very basic hurdle... Obliged for a heads up.. >>> >>> Can send the stack if its needed.. >>> >>> SmallInteger(Object)>>doesNotUnderstand: #& >>> Receiver: 3 >>> Arguments and temporary variables: >>> aMessage: & 3 >>> exception: MessageNotUnderstood: SmallInteger>>& >>> resumeValue: nil >>> Receiver's instance variables: >>> 3 >>> >>> AJx86Instruction>>emitMod:reg:rm: >>> Receiver: <<error during printing>> >>> Arguments and temporary variables: >>> mod: 3 >>> reg: 37 >>> rm: 36 >>> Receiver's instance variables: >>> name: #mov >>> operands: an Array(EBP ESP) >>> machineCode: a WriteStream >>> position: 1 >>> next: <<error during printing>> >>> >>> On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> To load NativeBoost you can follow an instructions on project page: >>>>> >>>> http://code.google.com/p/nativeboost/wiki/Installation >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >> > > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > >

Aug. 28, 2012

[Pharo-project] Why it takes much more time to load stuff in 2.0 comparing to 1.4?

by Igor Stasenko

I was checking how ConfigurationOfNativeBoost behaves on 1.4 and i noticed that it loads like 3-5 times faster comparing to 2.0.. and i refusing to believe this is because of different network latency, because most time which it spends during loading in 2.0 is showing "compiling / installing" progress but not "downloading". -- Best regards, Igor Stasenko.

Aug. 28, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by Igor Stasenko

On 27 August 2012 23:58, Lawson English <lenglish5(a)cox.net> wrote: > I get this using Pharo 1.4. Thing is, it was working a few weeks ago and now > not. > > I was hoping to do a video on how to add simple ultra-fast assembler methods > using NB but still can't because the target is moving way too fast. My usual > strategy is to show how to load a package in a brief intro video, and then > how to use it in the second part. During the time I learned how to use NB at > the assembler level, everything that I was doing broke. > I need you to say what is broken. The extension methods which was lost due to 1.4/2.0 disturbance is not a big deal (i hope), i am added them back, so things should do not break out of the box on 1.4. And if you have more problems with it, please tell, because there was not many changes at that level and in overall most of changes are cosmetic and not functional (like changing decorate:while: to decorate:during:). All of the code i wrote works without changes, so if you have different problem just say, Lawson. And please be more specific, because "everything" is not very precise word for describing a problem :) > Kinda hard to make a video to show how to install and then use it those > circumstances. I trying to keep the installation instructions up to date on project web site. > > L > -- Best regards, Igor Stasenko.

Aug. 28, 2012

Re: [Pharo-project] [ANN] NativeBoost v 1.3

by Lawson English

I get this using Pharo 1.4. Thing is, it was working a few weeks ago and now not. I was hoping to do a video on how to add simple ultra-fast assembler methods using NB but still can't because the target is moving way too fast. My usual strategy is to show how to load a package in a brief intro video, and then how to use it in the second part. During the time I learned how to use NB at the assembler level, everything that I was doing broke. Kinda hard to make a video to show how to install and then use it those circumstances. L On 8/27/12 12:01 AM, Nicolas Cellier wrote: > Pharo 2.0 has implemented & -> bitAnd: and | -> bitOr: > > For who is dealing with bits, that's convenient, however it creates > one more case of false polymorphism, these messages being used for > Boolean already... > > Nicolas > > 2012/8/27 S Krish <krishnamachari.sudhakar(a)gmail.com>: >> On loading up and testing NB: >> >> I get possibly a very basic hurdle... Obliged for a heads up.. >> >> Can send the stack if its needed.. >> >> SmallInteger(Object)>>doesNotUnderstand: #& >> Receiver: 3 >> Arguments and temporary variables: >> aMessage: & 3 >> exception: MessageNotUnderstood: SmallInteger>>& >> resumeValue: nil >> Receiver's instance variables: >> 3 >> >> AJx86Instruction>>emitMod:reg:rm: >> Receiver: <<error during printing>> >> Arguments and temporary variables: >> mod: 3 >> reg: 37 >> rm: 36 >> Receiver's instance variables: >> name: #mov >> operands: an Array(EBP ESP) >> machineCode: a WriteStream >> position: 1 >> next: <<error during printing>> >> >> On Fri, Aug 24, 2012 at 7:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> To load NativeBoost you can follow an instructions on project page: >>>> >>> http://code.google.com/p/nativeboost/wiki/Installation >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> > -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

Aug. 27, 2012

Re: [Pharo-project] 'self halt' safety net

by Igor Stasenko

On 27 August 2012 17:44, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > Igor Stasenko wrote: >> >> you can open .changes file in another image to rescue your code. >> > > Thanks Igor. I gave that a go but couldn't work it out. I tried the > following: Unzipped a fresh image, copied the .changes file into the folder > to overwrite the existing .changes file, then after starting the image tried > (World > Tools > Recover lost changes...) but I get "Information: this > image has never been saved since changes were compressed." Saving the image > seems to empty the .changes file. I could not find another way. Is there > something else I should be doing? yes, just open .changes file in a file browser. this is what i meant to say.. Or, if you look at ChangeSet (or ChangeBrowser - don't remember the name) code, at class side you can find the methods which actually allow you to browse contents of a .changes file. and you can specify what file to open. you just need to do some research :) > >> also you can patch the image's bytecode to avoid entering an offending >> method >> (like a method which enters the drawing , just see its bytecode in >> another image, >> and the find same byte sequence in crashing image, and put return self >> bytecode) >> > > Thanks, but that is beyond my capability at the moment. Probably wishing > for too much, but ideally some mechanism might use info from the debug.log > to do this automatically. > maybe.. i don't know. need to think about it. >> On 25 August 2012 03:42, Ben Coman <btc(a)openinworld.com> wrote: >> >>> >>> Igor Stasenko wrote: >>> >>>> >>>> On 4 August 2012 04:11, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>>> >>>>> As probably many newbies do from time to time, I am learning the system >>>>> splattering 'self halt' around, and once again slipped one into the >>>>> wrong >>>>> place where I should have used 'haltOnce' and had a massive number of >>>>> pre-debugger windows come up. I managed to get it back this time with >>>>> the >>>>> user interrupt - but not always - and anyhow clearing so many debug >>>>> windows >>>>> is a pain. So..... could 'self halt' be made to monitor the rate that >>>>> the >>>>> halt windows appear, and when more than some value from one of them >>>>> (say >>>>> five per second) it starts getting ignored and shows a dialog asking >>>>> the >>>>> user if they really meant this and enable danger mode, or if they >>>>> screwed >>>>> up >>>>> and want to revert the method containing the suspect 'halt'. >>>>> >>>>> >>>>> >>>> >>>> If we look from user's perspective (not machine perspective), apparently >>>> it is pointless to throw so many messages at the user's face, because >>>> he cannot deal with them >>>> in meaningful manner at such rate. >>>> So, i think there should be something like following: >>>> - if exception requires a user interaction, we do show the popup, but >>>> meanwhile remember >>>> the exception which initiated it. >>>> - if there's next exception incoming and also asks UI manager to show >>>> it to user, we queue it, >>>> letting user to deal with first one.. (or we delay the popup , say 1 >>>> each 5 seconds). >>>> and finally, a queue should have some reasonable limit, after which we >>>> stop queuing , because again, user certainly won't be willing to waste >>>> his time dealing with 10000000 exceptions of same kind one by one. It >>>> doesn't makes sense anyways. >>>> >>>> In such case we can just ignore halt and let program continue (but >>>> increment some counter to show user how many of them are there). >>>> If exception is different (an Error) then on queue overflow, i think >>>> it should terminate the process with exception (but of course, special >>>> care must be taken if process is UI process). >>>> Of course making it too smart is pointless, because it is impossible >>>> to predict whether it is good idea >>>> to terminate process or letting it continue to run in case of exception. >>>> But for that we can have settings and options, to tune that at user's >>>> discretion, as well as default >>>> settings on a per-exception class base. >>>> >>>> >>>> >>>>> >>>>> anyhow, just musing.... -ben >>>>> >>>>> >>>>> >>>> >>>> i know by myself how annoying it can be (up to unresponsive image) >>>> and i think most of us is facing such situation time to time (heh.. >>>> just yesterday we had it with Camillo while hacking ocompletion >>>> stuff). >>>> i learned to be careful and avoid such situations.. but sometimes it >>>> is hard and better tooling support will be helpful, no doubt. >>>> >>>> >>>> >>> >>> >>> Another use case that just happened to me. This is not 'halt' related >>> but >>> just a typo... (which suddenly makes the whole system feel a bit >>> fragile) >>> Working on a small new feature in the drawing loop of Roassal, I would >>> guess >>> "all" that I did was leave out a full stop at the end a line. So the >>> image >>> locked and crashed after about 20 seconds. Unfortunately now the image >>> is >>> crashing every time I try to open it. Some mechanism to throttle and >>> temporarily ignore the error to allow me to rectify the problem would >>> have >>> been immensely useful. In this case, perhaps something like blocking the >>> main UI loop and presenting a modal window of a very basic self contained >>> text editor on the offending method. >>> At this moment, another immensely useful tool would be able to diff the >>> source code between a running image and an offline image, and import the >>> changes. >>> Is there any other way I might recover recent changes? Previously I have >>> not had much luck mixing a new image with the changes file fromt he >>> crashed >>> image. >>> >>> regards -ben >>> >>> > > [Debug logs deleted] > -- Best regards, Igor Stasenko.

Aug. 27, 2012

Re: [Pharo-project] 'self halt' safety net

by Eliot Miranda

On Mon, Aug 27, 2012 at 8:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > Igor Stasenko wrote: > >> you can open .changes file in another image to rescue your code. >> >> > Thanks Igor. I gave that a go but couldn't work it out. I tried the > following: Unzipped a fresh image, copied the .changes file into the > folder to overwrite the existing .changes file, then after starting the > image tried (World > Tools > Recover lost changes...) but I get > "Information: this image has never been saved since changes were > compressed." Saving the image seems to empty the .changes file. I could > not find another way. Is there something else I should be doing? > Ben, your changes were in the .changes file that you overwrote. You should have either a) unpacked the second image/changes in a different directory b) renamed the changes file you wanted to recover before unpacking the second image/changes c) unpacked the second image/changes with different names d) anything else that avoids overwriting the changes file you wanted to recover. its gone now unless you have a recent backup also you can patch the image's bytecode to avoid entering an offending >> method >> (like a method which enters the drawing , just see its bytecode in >> another image, >> and the find same byte sequence in crashing image, and put return self >> bytecode) >> >> > Thanks, but that is beyond my capability at the moment. Probably wishing > for too much, but ideally some mechanism might use info from the debug.log > to do this automatically. > >> On 25 August 2012 03:42, Ben Coman <btc(a)openinworld.com> wrote: >> >> >>> Igor Stasenko wrote: >>> >>> >>>> On 4 August 2012 04:11, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>> >>>>> As probably many newbies do from time to time, I am learning the system >>>>> splattering 'self halt' around, and once again slipped one into the >>>>> wrong >>>>> place where I should have used 'haltOnce' and had a massive number of >>>>> pre-debugger windows come up. I managed to get it back this time with >>>>> the >>>>> user interrupt - but not always - and anyhow clearing so many debug >>>>> windows >>>>> is a pain. So..... could 'self halt' be made to monitor the rate that >>>>> the >>>>> halt windows appear, and when more than some value from one of them >>>>> (say >>>>> five per second) it starts getting ignored and shows a dialog asking >>>>> the >>>>> user if they really meant this and enable danger mode, or if they >>>>> screwed >>>>> up >>>>> and want to revert the method containing the suspect 'halt'. >>>>> >>>>> >>>>> >>>>> >>>> If we look from user's perspective (not machine perspective), apparently >>>> it is pointless to throw so many messages at the user's face, because >>>> he cannot deal with them >>>> in meaningful manner at such rate. >>>> So, i think there should be something like following: >>>> - if exception requires a user interaction, we do show the popup, but >>>> meanwhile remember >>>> the exception which initiated it. >>>> - if there's next exception incoming and also asks UI manager to show >>>> it to user, we queue it, >>>> letting user to deal with first one.. (or we delay the popup , say 1 >>>> each 5 seconds). >>>> and finally, a queue should have some reasonable limit, after which we >>>> stop queuing , because again, user certainly won't be willing to waste >>>> his time dealing with 10000000 exceptions of same kind one by one. It >>>> doesn't makes sense anyways. >>>> >>>> In such case we can just ignore halt and let program continue (but >>>> increment some counter to show user how many of them are there). >>>> If exception is different (an Error) then on queue overflow, i think >>>> it should terminate the process with exception (but of course, special >>>> care must be taken if process is UI process). >>>> Of course making it too smart is pointless, because it is impossible >>>> to predict whether it is good idea >>>> to terminate process or letting it continue to run in case of exception. >>>> But for that we can have settings and options, to tune that at user's >>>> discretion, as well as default >>>> settings on a per-exception class base. >>>> >>>> >>>> >>>> >>>>> anyhow, just musing.... -ben >>>>> >>>>> >>>>> >>>>> >>>> i know by myself how annoying it can be (up to unresponsive image) >>>> and i think most of us is facing such situation time to time (heh.. >>>> just yesterday we had it with Camillo while hacking ocompletion >>>> stuff). >>>> i learned to be careful and avoid such situations.. but sometimes it >>>> is hard and better tooling support will be helpful, no doubt. >>>> >>>> >>>> >>>> >>> >>> Another use case that just happened to me. This is not 'halt' related >>> but >>> just a typo... (which suddenly makes the whole system feel a bit >>> fragile) >>> Working on a small new feature in the drawing loop of Roassal, I would >>> guess >>> "all" that I did was leave out a full stop at the end a line. So the >>> image >>> locked and crashed after about 20 seconds. Unfortunately now the image >>> is >>> crashing every time I try to open it. Some mechanism to throttle and >>> temporarily ignore the error to allow me to rectify the problem would >>> have >>> been immensely useful. In this case, perhaps something like blocking the >>> main UI loop and presenting a modal window of a very basic self contained >>> text editor on the offending method. >>> At this moment, another immensely useful tool would be able to diff the >>> source code between a running image and an offline image, and import the >>> changes. >>> Is there any other way I might recover recent changes? Previously I have >>> not had much luck mixing a new image with the changes file fromt he >>> crashed >>> image. >>> >>> regards -ben >>> >>> >>> >> [Debug logs deleted] > > -- best, Eliot

Aug. 27, 2012

Re: [Pharo-project] Reef examples and documentation

by Oscar E A CallaÃº

Thanks a lot. It would be really useful and a great marketing campaign to have a demo image. Something similar to JQueryMobile for Seaside: http://jquerymobile.seasidehosting.st May be I can work on it later, when I understand how Reef works. Cheers. On Aug 27, 2012, at 7:53 , StÃ©phane Ducasse wrote: > It is powerful > Here are the old documentation. > Esteban started to work on a new version but there is nothing readable. > > Stef > <ReefChapter1.pdf><reefChapter2.pdf> > On Aug 26, 2012, at 8:08 PM, Oscar E A Callau wrote: > >> Hi all, >> >> Do You known where I can find examples and documentation about Reef?. It seems to be quite powerful. I just found the slides and videos from esug 2010 and 2011. >> >> Cheers >> >> Ãscar E A Callau >> >

Aug. 27, 2012