- Pharo-dev - lists.pharo.org

[Pharo-project] Native (OS-level) windows
by Evgeniy Philippov Sept. 3, 2010

Sept. 3, 2010

Hello folks and Todd Blanchard, I have three questions. First question is---what is the current status of Ffenestri, and where can I download some version of Pharo with the most up-to-date Ffenestri support? The second question is---what are the other Pharo OS-level windowing interfaces, and what is their status? And the last question is---what is more complete: Squeak's Ffenestri support, or Pharo's Ffenestri support? My intents. I plan to use some version of Squeak or Pharo system for my project (which is a hobby project), and I am mainly interested in OS-level windowing for Linux (Ubuntu) and to a lesser extent for Win32 too. I studied wxSqueak a bit, and concluded that Ffenestri is overall simpler to develop than wxSqueak, and guessed that Ffenestri moves/will move faster when considering the completeness of it, than wxSqueak. -- Evgeniy

3 5

[Pharo-project] FSPlatformResolver class>>forCurrentPlatform use a deprecated method
by Cyrille Delaunay Sept. 3, 2010

Sept. 3, 2010

In the package Filesystem, FSPlatformResolver class >> forCurrentPlatform | platformName | platformName := SmalltalkImage current platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new should be replaced by FSPlatformResolver class >> forCurrentPlatform | platformName | platformName := OSPlatform platformName. ^ (self allSubclasses detect: [:ea | ea platformName = platformName]) new

4 4

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
by John M McIntosh Sept. 3, 2010

Sept. 3, 2010

On 2010-08-29, at 11:10 AM, stephane ducasse wrote: > John > > What I want to understand is what does it means to use open/GL. > This means that you use open/GL to implement the primitive? > Now I thought that opengl was more vector graphics than bitblt so how does it fit together. > Is it because the mac UI is opengl based too? > > Stef Ok let me give you some background, then talk about open/GL The Squeak drawing logic invokes: http://isqueak.org/displayioShowDisplay Which is to say copy this rectangle of data from the Squeak Display Oops data pointer to something that visually shows the user what is going on, since drawing can require a few Smalltalk based calculations resulting in draw events to compose a final image then we also have, http://isqueak.org/ioForceDisplayUpdate To help the process a bit by allowing the drawing subsystem to compose the bits until we are done, then perform the expensive step of visualization. In general the displayioShowDisplay is really fast but the ioForceDisplayUpdate is slow, displayioShowDisplay may not show the bits, but displayioShowDisplay may now (or later... ) Depending on which VM source code (version and platform dependent) you may find that ioForceDisplayUpdate does nothing, or a operating system flush is done to the hardware on every displayioShowDisplay. Where you can see this issue is if you try. Transcript cr;show: [| b | b _ Pen new. Display fillWhite. b place:(Display boundingBox bottomLeft). b hilbert: 9 side: 2 ] timeToRun. Display restore. If this crawls, like taking 30 seconds, then the implementation is flushing every bit draw to the operating system. Well or if you don't see the bits then maybe neither displayioShowDisplay or ioForceDisplayUpdate does any flushing, and all you see is the Display restore results. Now just to make life harder for the VM implementor the Smaltalk code might not call ioForceDisplayUpdate. Then the VM has to do the ioForceDisplayUpdate internally in order not to leave bit's dangling. How this is done again is different from VM to VM. Usually this shows up as a double menu selection highlight. For the 4.2.x series of Macintosh VM we would trigger a operating system flush if more than 20 ms (a settable value) had elapsed, and I did nothing for ioForceDisplayUpdate. But I change this in 5.x and for the iPhone to make ioForceDisplayUpdate the trigger, with a timer that pops if a ioForceDisplayUpdate is not done within 20ms of the last executed displayioShowDisplay. Now about Open/GL, in the past for os-x carbon VM 4.2.X and earlier we used System 7.5.x technology to draw bits, which was quickdraw and quickdraw quartz. When I moved the logic to the iPhone that is not supported technology, because of the interesting drawing logic on the iPhone it took 6 attempts and a long chat with a graphics engineer at Apple. That resulted in using Core Animation to divide the screen into 16 tiles so when a draw happens we note which Tile(s) are dirty based on the rectangle intersections, then on the ioForceDisplayUpdate we generate images for each of the dirty tiles from the Display Oops and tell Core Animation redraw the new tiles. Bert said this seemed slow on OS-X. At this point the next step in our OS-X/iOS drawing path is drop one step lower down and consider Open/GL. I must admit I've not done any open/GL work before so it was a learning opportunity. Although you think of Open/GL as a vector based graphic language it does support what is know as Textures. So instead of providing vectors, you supply bits. So a chunk of data, stating it's RGB, at this depth and pixel layout and size, etc make a chunk of screen glow that is showing the open/GL viewport. Now there are lots of restrictions but the GPUs and drivers have become more friendly so you can supply arbitrary sized rectangles, this was at one time slow, but GPUs have become extremely fast, so slow is fast... In fact on the mac you can supply a arbitrary sized rectangle taken from a much larger rectangle of data, which fits perfectly into the displayioShowDisplay logic. The only hassle is that you need to figure out how the flush should work. So after 3 days of intense effort I can say the algorithm is... displayioShowDisplay collects the union of the rectangles that are being drawn. Nothing more happens... It's pointless to do the glTexImage2D here because 'b hilbert: 9 side: 2' will kill you. Mind we do still watch for a missing ioForceDisplayUpdate. ioForceDisplayUpdate Then takes the union of the rectangles, set a GL viewpoint, and does the glTexImage2D based on figuring out the start point of the top/left pixel of the rectangle to draw, then setups up the coordinate system and finally flush the data. glViewport( subRect.origin.x,subRect.origin.y, subRect.size.width,subRect.size.height ); char *subimg = ((char*)lastBitsIndex) + (unsigned int)(subRect.origin.x + (r.size.height-subRect.origin.y-subRect.size.height)*r.size.width)*4; glTexImage2D( GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, subimg ); glBegin(GL_QUADS); // The -1 is so we flip the coordinate system as os-x and squeak have different views of where (0,0) is... glTexCoord2f(0.0f, 0.0f); glVertex2f(-1.0f, 1.0f); glTexCoord2f(0.0f, subRect.origin.x.size.height); glVertex2f(-1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, subRect.origin.x.size.height); glVertex2f(1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, 0.0f); glVertex2f(1.0f, 1.0f); glEnd(); glFlush() // Ask the hardware to draw this stuff, don't use the more aggressive glFinish() reset the union of draw rectangles. Hint (a) Oddly some people feel they should re-configure the open/GL graphic context on *every* draw cycle, why? (b) People don't read the Apple guidebooks for best practices for doing glTexImage2D, this I know based on Google searches using certain Apple open/GL extension keywords. Notes: This assumes the Squeak display is 32 bits, other resolutions are an exercise for the reader. Actually if the row width is a multiple of 32 bytes then on the Mac things are *much* faster and no copy is made. This is enforced in 5.7b5 by ensuring window size is divisible by 8. When the graphic context is setup when the window is built there is a bunch of cmds to execute, one important one is glPixelStorei( GL_UNPACK_ROW_LENGTH, self.frame.size.width ); and when the window is resized there are a few things to do to indicate how the context has changed. Some platforms like the iPhone might need to do this instead because it doesn't support the GL extension GL_TEXTURE_RECTANGLE_ARB glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL ); for( int y = 0; y < subRect.size.height; y++ ) { char *row = ((char*)lastBitsIndex) + ((y + subRect.origin.y)*subRect.size.width + subRect.origin.x) * 4; glTexSubImage2D( GL_TEXTURE_2D, 0, 0, y, subRect.size.width, 1, GL_RGBA, GL_UNSIGNED_BYTE, row ); } -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

6 15

[Pharo-project] FSPlatformResolver class>>forCurrentPlatform use a deprecated method
by Torsten Bergmann Sept. 3, 2010

Sept. 3, 2010

Lukas wrote: >Why? OSPlatform doesn't even exist in Pharo 1.1. Pharo includes this class in Pharo-1.1-11411 Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 €/mtl.!* http://portal.gmx.net/de/go/dsl

1 0

[Pharo-project] [update 1.2] #12122
by StÃ©phane Ducasse Sept. 3, 2010

Sept. 3, 2010

12122 ----- - 2904 HelpSystemAPIBuilderFailsOnTraits. Thanks Laurent Laffont. Stef and Gabriel

1 0

[Pharo-project] PluggableShoutMorph >> okToStyle still make a reference to Preferences
by Cyrille Delaunay Sept. 3, 2010

Sept. 3, 2010

PluggableShoutMorph >> okToStyle still make a reference to Preferences, which is no longer present in pharo 1.2. It generate problem when opening a debugger for example (which is a problem :)). I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2905

2 4

Re: [Pharo-project] [Pharo-users] TestSprinter
by StÃ©phane Ducasse Sept. 3, 2010

Sept. 3, 2010

icons to see which tests failed since last run and a summary previous run: current: 150 green 149 green 2 failure 2 failutres 1 errors could be presented differently On Sep 3, 2010, at 12:31 AM, Benjamin Van Ryseghem wrote: > Hello everybody > > I'm now working on a new Test Runner tool and I wonder which behaviours do you want me to implement. > > For now, I want the Test Sprinter to be able to : > - search through packages and classes thanks to search fields. > - browse the hierarchy from packages to test methods (with icons). > - create groups of tests easily re-runnable. > > If you have any ideas, I'm waiting for them ;) > > > Thank you > > > Ben _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

2 3

Re: [Pharo-project] [Moose-dev] Re: load moose in Pharo1.2
by Cyrille Delaunay Sept. 3, 2010

Sept. 3, 2010

Now I have exactly the same problem with 'PluggableShoutMorph' in the package Shout (This package is loaded with ConfigurationOfPetitParser). PluggableShoutMorph (like MOEaselTextEditor) declare the two instance variables 'styler' and 'unstyledAcceptText' which are already declared in the superclass PluggableTextMorph (in Pharo 1.2). Maybe those variable have been integrated in the superclass for pharo 1.2 and are no longer usefull ? Anyone know? 2010/9/2 Alexandre Bergel <alexandre(a)bergel.eu> > Strange indeed. This method is apparently never called. This is related > somehow to the completion (which does not work for me. I will contact > Lukas). > > Alexandre > > > On 2 Sep 2010, at 08:22, Cyrille Delaunay wrote: > > > What is strange, is that there is only one reference to > unstyledAcceptText, without affecting it a value. > > > > 2010/9/2 Cyrille Delaunay <cy.delaunay(a)gmail.com> > > No, same problem now with 'unstyledAcceptText' > > > > > > 2010/9/2 Tudor Girba <tudor.girba(a)gmail.com> > > And does the loading work now? > > > > Doru > > > > > > On 2 Sep 2010, at 13:08, Cyrille Delaunay wrote: > > > > done > > > > 2010/9/2 Tudor Girba <tudor.girba(a)gmail.com> > > Yes, please rename it to shoutStyler. > > > > Cheers, > > Doru > > > > > > > > On 2 Sep 2010, at 12:25, Cyrille Delaunay wrote: > > > > So that means that a 'styler' instance variable has been defined in > PluggableTextMorph between pharo 1.1 and Pharo 1.2? Should we rename the > Mondrian instance variable? > > > > 2010/9/2 Cyrille Delaunay <cy.delaunay(a)gmail.com> > > So a solution is to load in a version of OmniBrowser that is compatible > with 1.2, before loading moose: > > > > (ConfigurationOfOmniBrowser project version: '1.1-baseline') load. > > > > Now, I have another error: > > The class MOEaselTextEditor from Mondrian-Easel re-declare the instance > variable 'styler', which is already defined in its superclass > PluggableTextMorph. > > > > 2010/9/1 Lukas Renggli <renggli(a)gmail.com> > > > > Metacello is loading an ancient version of OB. References to > > Preferences have been removed a long time ago. However there is still > > a problem with the highlighting in Pharo 1.2. You only get a working > > environment if you do not load the package OB-Shout. > > > > Lukas > > > > On 1 September 2010 16:10, Tudor Girba <tudor.girba(a)gmail.com> wrote: > > > Hi Cyrille, > > > > > > That means that OB needs to be fixed :). Could you raise the issue on > the > > > pharo mailing list? > > > > > > Cheers, > > > Doru > > > > > > > > > On 1 Sep 2010, at 14:48, Cyrille Delaunay wrote: > > > > > >> When I try with the configuration, I get an error when loading the > class > > >> OBMercuryPanel (from the package OB-Standard, that seems to be loaded > with > > >> ConfigurationOfMetacello): > > >> The initialize method is using the old class "Preferences" (that is no > > >> longer present in Pharo 1.2). > > >> > > >> 2010/9/1 Tudor Girba <tudor.girba(a)gmail.com> > > >> What do you mean by script? Did you try with the configuration? > > >> > > >> Doru > > >> > > >> > > >> > > >> On Sep 1, 2010, at 11:12, Cyrille Delaunay <cy.delaunay(a)gmail.com> > wrote: > > >> > > >> > Hello, > > >> > Is moose loadable in Pharo 1.2 ? Is there a special script somwhere > to > > >> > that? > > >> > _______________________________________________ > > >> > Moose-dev mailing list > > >> > Moose-dev(a)iam.unibe.ch > > >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> Moose-dev(a)iam.unibe.ch > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> Moose-dev(a)iam.unibe.ch > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > -- > > > www.tudorgirba.com > > > > > > "When people care, great things can happen." > > > > > > > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > Moose-dev(a)iam.unibe.ch > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > www.tudorgirba.com > > > > "When people care, great things can happen." > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > www.tudorgirba.com > > > > "Being happy is a matter of choice." > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

3 5

[Pharo-project] [ANN] SqueakDBX 1.2 release
by Mariano Martinez Peck Sept. 3, 2010

Sept. 3, 2010

Hi folks. We are realeasing SqueakDBX 1.2, just an small release. For those who doesn't know, SqueakDBX is a database driver to connect to most of the existing databases. For more details, please read www.squeakdbx.org The main changes in this release are: - ConfigurationOfSqueakDBX version: 1.2 - Comments: SqueakDBX stable 1.2 - OpenDBX version: 1.5 - New Features - GlorpDBX connection pool for SqueakDBXDriver. Thanks to John Toohey for this contribution. - New support for Firebird 100% green tests in Windows. - New support for MySQL 4. - New tests for PostgreSQL sequences, for bad data settings, large objects, etc. - We now let a platform to set special options ALWAYS before opening the connection. - Packages remodularization and little changes so that to easily support ports, for example to Dolphin. - Start to support large objects. For the moment: Postgresql supports TEXT, MySQL supports TEXT and BLOB, and SQLite CLOB (error with BLOB), Oracle supports CLOB and NCLOB. - Added the possibility to enable or disable automatic release of connections using WeakRegistry. - Notes - Tested with Cog, resulting in an average of 3x increase and 100% green. - Tested in Pharo 1.0 and 1.1. - Updated Metacello configurations To install it: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSqueakDBX'; load. (ConfigurationOfSqueakDBX project version: '1.2') load. In Pharo 1.1 I recommend to evaluate the following: DBXPlatform disableAutomaticConnectionReleaseOnGC Cheers Mariano

1 0

Sept. 3, 2010

seems like we should do something :) Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: September 1, 2010 1:12:28 AM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Fwd: [squeak-dev] The Trunk: System-eem.366.mcz > Reply-To: johnmci(a)smalltalkconsulting.com > > In case this gets overlooked being hidden in a update for The Trunk: System-eem. > > The EndianCache does need to be cleared at shutdown versus in startup. > I can't speak for the SystemChangeNotifier since I'm not sure what the bug is.. > > Of course I'm not quite sure if anyone in the Pharo group looks and the trunk updates and moves things across? > > > Begin forwarded message: > >> From: commits(a)source.squeak.org >> Date: August 31, 2010 5:47:35 PM PDT >> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >> Subject: [squeak-dev] The Trunk: System-eem.366.mcz >> Reply-To: squeak-dev(a)lists.squeakfoundation.org >> >> Eliot Miranda uploaded a new version of System to project The Trunk: >> http://source.squeak.org/trunk/System-eem.366.mcz >> >> ==================== Summary ==================== >> >> Name: System-eem.366 >> Author: eem >> Time: 31 August 2010, 10:47:17.97 am >> UUID: 2126e5d9-4d47-4cc1-921f-daefd935aedd >> Ancestors: System-nice.365 >> >> Make sure system notifications for Smalltalk are up-to-date >> on start-up. >> Fix voiding of Smalltalk's endian cache which needs to be done >> in a timely manner. >> >> =============== Diff against System-nice.365 =============== >> >> Item was changed: >> ----- Method: SmalltalkImage class>>startUp (in category 'class initialization') ----- >> startUp >> + SystemChangeNotifier uniqueInstance notify: Smalltalk ofAllSystemChangesUsing: #event:! >> - "XXXX: This is broken. SmalltalkImage startUp happens quite late in the startup sequence; earlier startups may very well need the information about the endianness of the platform." >> - EndianCache := nil. >> - ! >> >> Item was changed: >> ----- Method: SmalltalkImage>>processShutDownList: (in category 'snapshot and quit') ----- >> processShutDownList: quitting >> + "Send #shutDown to each class that needs to wrap up before a snapshot. >> + Also void the endianness chace; this can't safely be done on start-up because >> + Smalltalk is too late in the start-up sequence." >> - "Send #shutDown to each class that needs to wrap up before a snapshot." >> >> + EndianCache := nil. >> + self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting! >> - self send: #shutDown: toClassesNamedIn: ShutDownList with: quitting. >> - ! >> >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

5 6