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

Re: [Pharo-project] Help testing Pharo 1.1 in big screens!

by StÃ©phane Ducasse

On my 30 inches screen opening in full show some little square due to the limit of the png :) Thanks mariano. On May 13, 2010, at 8:39 PM, Mariano Martinez Peck wrote: > Hi folks. I re-try (yes, yes, I re-insist hahaha) to have a background picture for the PharoDev 1.1. The last time I tried, we had a problem with the picture because in big screens instead of making it bigger, it put it several times, or it cut it. Now, thanks to Gary, it should work well. > > So, if you are a lucky guy an have a big screen, can you please take the latests PharoCore 1.1 image, for example this: > > https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… > > > How to test it ? > > - Download this in the same directory where the .image is: > https://gforge.inria.fr/frs/download.php/26996/pharoBackground.png > > Then evaluate: > > World backgroundMorph: > ((UITheme builder > newAlphaImage: (ImageReadWriter formFromFileNamed: 'pharoBackground.png') help: nil) > autoSize: false; > layout: #scaled; > lock) > > > What to test ? > > - You should stretch the pharo image, make it very big, and the background picture should stretch also together with the image. > - If you notice a performance decrease with it (I don't think so) > - If you like it or not. > - If the resolution is good enough in big screens > > > Thanks! > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 13, 2010

[Pharo-project] No autocompletion in ScriptManager

by Mariano Martinez Peck

Hi Torsten: seems OCompletion doesn't work in the script panel of ScriptManager. Cheers Mariano

May 13, 2010

[Pharo-project] Help testing Pharo 1.1 in big screens!

by Mariano Martinez Peck

Hi folks. I re-try (yes, yes, I re-insist hahaha) to have a background picture for the PharoDev 1.1. The last time I tried, we had a problem with the picture because in big screens instead of making it bigger, it put it several times, or it cut it. Now, thanks to Gary, it should work well. So, if you are a lucky guy an have a big screen, can you please take the latests PharoCore 1.1 image, for example this: https://gforge.inria.fr/frs/download.php/26995/PharoCore-1.1-11357-UNSTABLE… How to test it ? - Download this in the same directory where the .image is: https://gforge.inria.fr/frs/download.php/26996/pharoBackground.png Then evaluate: World backgroundMorph: ((UITheme builder newAlphaImage: (ImageReadWriter formFromFileNamed: 'pharoBackground.png') help: nil) autoSize: false; layout: #scaled; lock) What to test ? - You should stretch the pharo image, make it very big, and the background picture should stretch also together with the image. - If you notice a performance decrease with it (I don't think so) - If you like it or not. - If the resolution is good enough in big screens Thanks! Mariano

May 13, 2010

Re: [Pharo-project] Remove developing with Pharo

by John M McIntosh

Ok, well this would be in the squeak V5 macintosh cocoa VM. In general the smalltalk code alters bits in the special object TheDisplay At some point the Smalltalk code calls primitiveShowDisplayRect or primitiveForceDisplayUpdate to move the bits from TheDisplay Oops to the host supporting platform's UI. This invokes the platform code ioShowDisplay(), *some* platforms who are multiple window aware may turn that into ioShowDisplayOnWindow() Now the intent of the logic is that the bits, rectangle of interest and target rectangle in the host platform display are given to the platform for visual display, and in theory the smalltalk side should issue a ioForceDisplayUpdate to sync a "Frame" from time to time this has then intent of *buffering* data between frame updates. To complicate things the Frame Sync might not happen so you always have to think about flushing data. Also the platform may transform the data from one color depth and color ordering to another to mediate between what the Squeak image thinks it is using versus what the hardware supports. I think the Unix side always flushes every byte accepted by the ioShowDisplayOnWindow immediately, this ensures you have no dangling flushes, but means there is no buffering of display writes between ioForceDisplayUpdate The older carbon macintosh VM writes every byte to the carbon window backing store (very fast), but on every X milliseconds flushes to the os-x display manager (very slow), or every Y milliseconds as it checks for dangling drawing as a result of a missing ioForceDisplayUpdate. The newer cocoa V5 VM Is modelled on the iPhone logic and uses 16 animation layers. On a ioShowDisplayOnWindow we record what rectangles are dirty. When the ioForceDisplayUpdate happens either by the Smalltalk code or forced as a timer pop we copy the data from TheDisplay based on the dirty rectangles, create a CGImageRef and update the animation layer tile. That triggers the GPU to do the right thing. Based on an Apple Engineering ticket I opened the methodology here is the fastest way to get bitmapped data to the iPhone display, and benchmarking shows the same solution gives better performance on os-x than the older obsolete carbon code. It *might* be possible to get better performance using OpenGL, but benchmarking on the iPhone shows the time taken in ioShowDisplay is near zero so it's hard to justify the work, as an example the frame rate of Scratch was tied up in the Scratch drawing logic, not the platform logic under ioShowDisplay. On 2010-05-13, at 3:14 AM, Henrik Sperre Johansen wrote: > On 12.05.2010 20:13, Andrei Stebakov wrote: >> That's right, looks like it sends full-blown images (not the delta, not the commands to x-server) and re-drawing takes forever. I wonder if it's a Pharo issue or x-server's? My xterm works pretty fast compared to Pharo though... > AFAIK, this is a consequence of the rendering method used in Squeak/Pharo image/VM's. > If I've understood the Mac platform-rendering code correctly, the way it works, is that a special Display bitmap is kept accessible to both image and VM. > When rendering image side, all draws end up on the Display bitmap. (Using bitBlt as a context, rather than using f.ex. a HostGraphicsContexts to draw using the equivalent x-server/quartz/directDraw commands) > > Then, when it comes time to actually display, the VM takes the registered damage rects, and sends the contents of the Display bitmap in those areas for display. > (In the Mac VM, this is actually folded down to one of 16 regions which are marked dirty or not, not sure how it works on other platforms). > So yes, full-blown images is ever only sent. > > The advantages I can see is that: > 1. All rendering logic is actually written in smalltalk. (Well, as part of the platform-independent, compiled-to-C VM sources at least) > 2. It will render exactly the same on all platforms, due to #1. > 3. The platform support code for rendering is really simple, all you need is the ability to display bitmap regions to the screen. > > Cheers, > Henry. > > _______________________________________________ > 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 ===========================================================================

May 13, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by StÃ©phane Ducasse

mariano i just released a fix could you stress the system? Stef On May 13, 2010, at 2:31 PM, Mariano Martinez Peck wrote: > > > On Thu, May 13, 2010 at 1:17 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Thu, May 13, 2010 at 10:56:17AM +0300, Igor Stasenko wrote: > > On 13 May 2010 10:33, St??phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > oops > > > Igor do you have more information? > > > how do we do that? > > > > > just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. > > > > As far as i can tell, everything else should work fine after that. > > This is not my contribution , so i don't know all nuances, sorry. > > > > I just made things which allow source pointers > 32Mb to be stored in > > method trailers, while others put this in use in various places :) > > That is probably all that is needed, yes. But be sure to test it. > When I did this for trunk, I tested by loading some big Monticello > package endlessly in a loop until I got the changes file up to > a couple hundred megabytes. You should be able to do this, save > and restart the image, browse all old methods is the sources file > and so forth. Then modify some method and make sure your change > appears at the end of the huge changes file, and that you can > revert your most recent change. And of course you should get no > warning dialog about the changes file size. > > Somebody with a fast computer should volunteer to test this. I > recall that it took a long time on my slow laptop computer with > slow disk drive ;) > > > > Thanks Dave. In my case, I accidently did something similar: I installed Seaside 3.0 a couple of times: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside'; > load. > > And then evaluate: > > ConfigurationOfSeaside project latestVersion load: #( 'Seaside 3.0' 'Magritte2' 'Pier2' 'Pier2 AddOns' ). > > > There will be some errors and deprecated...just proceed them as this is only to increase the .changes > > Cheers > > Mariano > > Dave > > > _______________________________________________ > 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

May 13, 2010

[Pharo-project] [update 1.1] #11360

by StÃ©phane Ducasse

11360 ----- - Issue 2120: ExpandedSourceFileArrayTest - Issue 2426: Size limit of Changes

May 13, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by StÃ©phane Ducasse

thanks mike indeed we should find a better way to tests network problems. Stef On May 13, 2010, at 7:53 PM, Michael Roberts wrote: > I have tried to load Magma in Pharo1.1 but have not yet succeeded. I > don't have a lot of time i'm afraid. the existing Metacello config > doesn't load the right packages, nor the list on the wiki page (using > installer) it seems. I am missing an implementation of a method > maAt:ifPresent:ifAbsent: on Smalltalk. > > anyone with a spare moment might like to figure that out. The > underscores need fixing in dependent packages (write barrier tests) > as well > > so we should maybe do something simpler to test the network. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 13, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by StÃ©phane Ducasse

Ok was confused I browse two different classes.... Stef On May 13, 2010, at 8:01 PM, Igor Stasenko wrote: > checkOKToAdd: size at: filePosition

May 13, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by Igor Stasenko

On 13 May 2010 20:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>> just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. > > this is exactly the same in pharo and squeak trunk > Huh? In Pharo-1.1.-11343 CompiledMethod>>checkOKToAdd: size at: filePosition "Issue several warnings as the end of the changes file approaches its limit, and finally halt with an error when the end is reached." | fileSizeLimit margin | fileSizeLimit := 16r2000000. 3 to: 1 by: -1 do: [:i | margin := i*100000. (filePosition + size + margin) > fileSizeLimit ifTrue: [(filePosition + margin) > fileSizeLimit ifFalse: [self inform: 'WARNING: your changes file is within ' , margin printString , ' characters of its size limit. You should take action soon to reduce its size. You may proceed.']] ifFalse: [^ self]]. (filePosition + size > fileSizeLimit) ifFalse: [^ self]. self error: 'You have reached the size limit of the changes file. You must take action now to reduce it. Close this error. Do not attempt to proceed.' > >>>>> CompiledMethod>>checkOKToAdd: size at: filePosition >>>>> Â Â Â "Issue several warnings if the end of the changes file is approaching >>>>> Â Â Â a fixed size limit, and finally halt with an error if the limit is reached." >>>>> >>>>> Â Â Â ^ SourceFiles checkOKToAdd: size at: filePosition >>>>> >>>>> looks like Pharo didn't integrated this method. >>>>> >>>>> also, make sure you using a proper Â source file array.. >>>>> >>>>> SourceFiles class == ExpandedSourceFileArray > > SourceFiles class > Â Â Â Â -> Â ExpandedSourceFileArray > > I integrated the squeak squeak and they are all green. > so I'm puzzled > > > > > >>>> >>>> >>>> >>>> >>>>> >>>>> On 13 May 2010 03:10, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> 2010/5/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>>> Hi. I have the following error: >>>>>>> >>>>>>> Â 'You have reached the size limit of the changes file. >>>>>>> You must take action now to reduce it. >>>>>>> Close this error. Â Do not attempt to proceed.' >>>>>>> >>>>>>> I know this is a known error, but I thought that with Igor's new method >>>>>>> trailer this was fixed. >>>>>>> >>>>>> >>>>>> Seems like a leftovers of old stuff, with precautions once you >>>>>> reaching the size limit. >>>>>> >>>>>> Close this error. Â And attempt to proceed. >>>>>> >>>>>> :) >>>>>> >>>>>>> Tested in 11355 >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Mariano >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 13, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Michael Roberts

I have tried to load Magma in Pharo1.1 but have not yet succeeded. I don't have a lot of time i'm afraid. the existing Metacello config doesn't load the right packages, nor the list on the wiki page (using installer) it seems. I am missing an implementation of a method maAt:ifPresent:ifAbsent: on Smalltalk. anyone with a spare moment might like to figure that out. The underscores need fixing in dependent packages (write barrier tests) as well so we should maybe do something simpler to test the network. thanks, Mike

May 13, 2010