- Pharo-dev - lists.pharo.org

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

by Mariano Martinez Peck

On Thu, May 13, 2010 at 8:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > On my 30 inches screen > opening in full show some little square due to the limit of the png :) > Ok...I guess it's a limit of the png format in particular, but THIS file. I mean, even if I convert it, I will get same results I gues... Now, I don't know where this image came from. Samuel Morello ? Can we ask someone for a new one with better resolution ? Thanks mariano > > 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 > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

May 13, 2010

Re: [Pharo-project] RB and OB in Pharo 1.1 [WAS] Re: [Seaside] Loading Seaside 3.0 in Pharo 1.1

by Mariano Martinez Peck

On Thu, May 13, 2010 at 7:18 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Now, playing a little with RB I found a deprecated method send: > > > > hasSpecialSelector: aSymbol ifTrueSetByte: > > > > You are using it in: > > > > RBClass >> existingMethodsThatReferTo: > > > > here: > > > > special := self realClass environment > > hasSpecialSelector: aSymbol > > ifTrueSetByte: [ :value | byte := value ]. > > > > the thing is that self realClass environment answer SystemDirectory but > we > > should use Smalltalk / SmalltalkImage > > You must be using a very old version of Refactoring-Core, this was > fixed quite some time ago. > Thanks Lukas. Yes, indeed I have a problem with my confs... Now I saw a new package: AST-Semantic Which are the dependecies of that package? and who depends on it ? So far I had: package: 'AST-Core'; package: 'AST-Tests-Core' with: [ spec requires: 'AST-Core' ]; package: 'Refactoring-Core' with: [ spec requires: 'AST-Core' ]; package: 'Refactoring-Tests-Core' with: [ spec requires: 'Refactoring-Core' ]; package: 'Refactoring-Spelling' with: [ spec requires: 'Refactoring-Core'. spec postLoadDoIt: #postLoadRBSpelling ]; package: 'Refactoring-Tests-Spelling' with: [ spec requires: 'Refactoring-Spelling'. ]. > > > In addition, is there a way to automatically check all the sends of > > deprecated methods? because there may be a lot...I just tried a Class > Rename > > refactor and I found this one, but I am sure there are more.. > > SmallLint finds some of them, but the rule should probably be improved. > > Also running the tests can show you problems (given that the code is > all covered). > > As I said, we fixed all the deprecated calls in Seaside 3.0, OB, RB, > eCompletion, Shout and PetitParser you just need to take the very > latest Pharo 1.1 and the very latest code of each package. > Ok..perfect. Thanks! Mariano > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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] No autocompletion in ScriptManager

by Mariano Martinez Peck

Ahh and ConfigurationOfScriptManager doesn't include Help package. Maybe we can add a new group and define that ? Thanks! Mariano On Thu, May 13, 2010 at 8:42 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Torsten: seems OCompletion doesn't work in the script panel of > ScriptManager. > > Cheers > > Mariano >

May 13, 2010

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