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

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Henrik Sperre Johansen

Hmm, so bugs are ok? Does this also include primitive (or plugib) failures which are handled correctly, but cause performance problems? In particular, I'm thinking of primitive 103 in core (used in strikefont rendering), and plugin BitBlt using rule 41 (used in FTFont-rendering), whom (wild guess) both seem to have problem with the String -> ByteString/WideString refactoring... (IE: they fail in Pharo with a ByteString parameter instead of String, and use the strictly smalltalk fallback code resulting in... far worse performance) I tried installing VMMaker to investigate the problems further, but I guess the steps needed to set up an interpreter to properly test exactly what goes wrong in these cases were too advanced for me to figure out in 30 mins.. :( BTW, the Cuis subpixel-rendering looks beautiful (both performance and code-wise) compared to what is done in the FreeType code. Anyone have time to understand/integrate this approach before 1.0 release? Misc ideas: - How about inserting some sort of logging where primitives are called with failure, but Smalltalk code fallback is used for a seemingly successful result. then fixing the code/VM to handle those cases? Font rendering is the prime cultrip, but I'm sure there are other places as well.... Secondary: - How about another instance cache in Color, for transformed colours? Some of these transformed colours are used MANY times during each rendering step, (look at the senders of Color>>lighter f.ex.), it seems silly to create new Color object that have to be GC'd in many of these instances. In Pharo the overhead isn't very noticeable (due to the primitive failures mentioned above sucking up most of the processor time), but in a lean system like Cuis, they did appear on TimeProfiles... I'm not sure how much you can trust the leaf nodes of TimeProfiles though, at least in Cuis/(which I did most of my investigation in), they seemed to be spread at random between items in a block.... (IE: from one to another, it could shift from 90% in one method call to 90% in another method call in the same block). If you read this entire message, you have my condolances, and written permission to ask for clarifications :) Cheers, Henry , On 04.08.2009 16:44, StÃ©phane Ducasse wrote: > ok with me. > > Stef > > On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote: > > >> On Aug 1, 2009, at 18:33 , Marcus Denker wrote: >> >> >>> On 01.08.2009, at 07:06, Serge Stinckwich wrote: >>> >>> >>>> On Sat, Aug 1, 2009 at 2:41 AM, StÃ©phane >>>> Ducasse<stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> So what is the process now? >>>>> Do we focus on 1.0? >>>>> Can we integrate other issues? >>>>> Do we have a separate stream for 1.1 alpha? >>>>> >>>> Maybe the 1.1 alpha should be available after the release of Pharo >>>> 1.0 >>>> so the efforts of the team is not disseminate on two versions. >>>> >>> Yes, I think this is the way to go... we should force everyone to use >>> the >>> beta version for a while. >>> >> Yes. We have 50 open issues for 1.0 and when more people start using >> Pharo, they will find more bugs. So for now we should focus on >> bringing that number down to 0. >> >> Adrian >> >> >>> Marcus >>> >>> >>> >>> >>> -- >>> Marcus Denker - http://marcusdenker.de >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Aug. 4, 2009

[Pharo-project] file dialog

by Tudor Girba

Hi, I need to load a file from the disk. I am invoking: UIManager default chooseFileMatching: '*.mse' label: 'Import model from MSE file.'. The problem is that I do not see any files, even though I have files with .mse ending in the directory. Also, even if I pass '*.*' I still cannot see the files (only the directories). Could anyone tell me what I am doing wrong? Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

Aug. 4, 2009

Re: [Pharo-project] Pharo name format

by Miguel Enrique CobÃ¡ Martinez

El mar, 04-08-2009 a las 11:00 -0700, Chris Cunningham escribiÃ³: > Have you given any thought to how you want the publicly consumable > version of Pharo named? As I understand it, the PharoCore is for the > Pharo development teams consumption; there is another version that is > intended for the end user. Is this correct? If so, a simpler naming > scheme might be nice there. > This is currently managed by Damien Cassou and Torsten Bergman. They generate the public consumption images for unix/mac/windows. I think that as the public ones are derived from the core image, a simplification of the pharo core (that was generated from by adding packages and a nice one-click setup) name could be useful. Pharo-X.Y-#####.zip without the tagname. For example: for unix/mac/image Pharo-0.1-10402.zip for the win32 Pharo-0.1-10402.exe for the 1.0 release: Pharo-1.0-RELEASE_1_0.zip Pharo-1.0-RELEASE_1_0.zip and for the updates: Pharo-1.0-UPDATE_1.zip Pharo-1.0-UPDATE_2.zip Pharo-1.0-UPDATE_1.exe Pharo-1.0-UPDATE_1.exe Or something like that. Keep in mind that the images for public consumption add other packages that might have their own updates/fixes/patches so the names need to consider this too when an update or fix affects a package but no the core image. But this is in the end a decision of the packagers. They may have a better arguments for ther current name formats. Cheers, Miguel CobÃ¡ > Also, is there a desire to create a new sources file for the 1.0 > release? Or at least changing the name from Squeak39.sources to > something like Pharo1.sources? Not critical, but could reduce some > confusion. > > I'd ask the same thing about the VM name, but I suspect that wouldn't > be the best choice - leaving it with the Squeak name on it guides the > user to the conclusion that they might be able to grab any SqueakVM > that have a chance that it will work with Pharo. And they'd probably > be right, if it is a new enough VM. > > This was all triggered by installing the Beta release last night and > noticing the various names floating around, and then seeing this > discussion. > > -Chris > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2009

[Pharo-project] [update] #10405

by Marcus Denker

10405 ----- Issue 1017: Some packages are dirty in the core version 400 Issue 1020: Rename TSetAritmetic in TSetArithmetic -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 4, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by Mariano Martinez Peck

On Tue, Aug 4, 2009 at 2:41 PM, Marcus Denker <denker(a)acm.org> wrote: > > On 01.08.2009, at 18:19, Mariano Martinez Peck wrote: > > > > > > > On Sat, Aug 1, 2009 at 10:28 AM, Marcus Denker <denker(a)acm.org> wrote: > > On Friday, July 31, 2009, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > > > may be we should simply remove that item. > > > menu > > > system > > > keyboard shortcuts > > > > yes > > > > why? is there other way newbie and not so newbie people can see the > > list of shortcuts? Using the mouse is ugly for me and I try to use > > shortcut as much as possible. > > > > Can you add a bugtracker entry for having some documentation/help > menu? The problem with the shortcuts was that in itself, it > was a bit lonly... but mayne a real help menu would make sense. Why you say it is lonely ? because it is wrong to be in "system" and should be under a new menu called "help" ? > > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 4, 2009

[Pharo-project] Pharo responseless when debugger steps into DNU in Seaside app

by Johan Brichau

Hi everyone, I'm getting a problem debugging Seaside applications in latest Pharo. When stepping with the debugger through the execution of a seaside application and encountering a message not understood, the entire Pharo system freezes and is totally unresponsive. It does not show that a DNU occurs, it simply becomes unresponsive when trying to step over the message that does not exist. I have to force quit. The problem can easily be recreated by changing a seaside component's render method such that a DNU occurs. Next, choose to debug the problem and restart the context. Now start stepping through the method and the system freezes when you try to step into the message that is not understood. The system freezes and does not show you a DNU. It seems to be a Pharo-Seaside problem since I do not have the same problem when doing this outside of Seaside applications. I'm using Pharo 09.7.5 (with seaside) and did a system update just now. I'm trying to drill down to the source of the problem but if anyone has any ideas.... ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Aug. 4, 2009

[Pharo-project] Enhanced StrikeFonts (antiAliasing , subPixel AA)

by StÃ©phane Ducasse

From: Juan Vuletich <juan <at> jvuletich.org> Subject: [Ann] Enhanced StrikeFonts (antiAliasing , subPixel AA) Newsgroups: gmane.comp.lang.smalltalk.squeak.general Date: 2009-08-03 21:52:47 GMT (20 hours and 12 minutes ago) Hi Folks, If you update to the latest trunk, you'll load Graphics-jmv.53, Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is set as default. I only included size 9 (reg, italic, bold, bold italic) to avoid using too much space in the image. If people want, more sizes can be added. To do proper antialiasing / subpixel AA _without_ requiring new BitBlt modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule. Text looks very good, in any combination of font and background colors, even at lower Display depths and / or glyphs depths. By default underscore and caret are shown as in standard ASCII. If you prefer the classic ST-80 left and up arrow, evaluate 'StrikeFont useLeftArrow'. To go back to the default, evaluate 'StrikeFont useUnderscore'. I also added 2 preferences #subPixelRenderFonts and #subPixelRenderColorFonts (both default to true). Andreas, thanks for all your help! Comments are welcome. Cheers, Juan Vuletich

Aug. 4, 2009

[Pharo-project] Text cleaning in CUIS

by StÃ©phane Ducasse

From: Juan Vuletich <juan <at> jvuletich.org> Subject: Cuis updated to #0250 Newsgroups: gmane.comp.lang.smalltalk.squeak.general Date: 2009-07-31 22:05:02 GMT (3 days, 19 hours and 58 minutes ago) A new release of Cuis is available at http://www.jvuletich.org/Cuis/Index.html . It includes some bugfixes and more cleanup. Biggest news is a lot of cleanup in the Text system. Gone are the ugly TextConstants pool and the old Paragraph class. TextStyle lost over half its instance variables and over 80% of its methods. I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users. As usual, all the updates starting at #0001 are available separately, and described in http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt . This could be useful for users of other Squeak images wanting some of the bug fixes and enhancements included in Cuis. Comments welcome. Cheers, Juan Vuletich

Aug. 4, 2009

Re: [Pharo-project] Pharo name format

by Chris Cunningham

Have you given any thought to how you want the publicly consumable version of Pharo named? As I understand it, the PharoCore is for the Pharo development teams consumption; there is another version that is intended for the end user. Is this correct? If so, a simpler naming scheme might be nice there. Also, is there a desire to create a new sources file for the 1.0 release? Or at least changing the name from Squeak39.sources to something like Pharo1.sources? Not critical, but could reduce some confusion. I'd ask the same thing about the VM name, but I suspect that wouldn't be the best choice - leaving it with the Squeak name on it guides the user to the conclusion that they might be able to grab any SqueakVM that have a chance that it will work with Pharo. And they'd probably be right, if it is a new enough VM. This was all triggered by installing the Beta release last night and noticing the various names floating around, and then seeing this discussion. -Chris

Aug. 4, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by StÃ©phane Ducasse

It would be nice to check keymapper keybinding package statuses because having a good keymapper is important for the future. Then may be using pragmas to tag methods with short cut would be a nice way to document the default keybdingin. Stef On Aug 4, 2009, at 5:54 PM, Mariano Martinez Peck wrote: > > > On Tue, Aug 4, 2009 at 2:50 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > Just a thought: if all available commands are accessible via a menu > (which they probably should be), and the menu indicates the shortcut > key, then the GUI would be self-explanatory and we would not need a > list of shortcuts. > > That's true, however, not all shortcut are accessible by a menu. As > an example to tab (move right a tab space) a piece of code, you have > to do ctrl + shift + r or ctrl + shift + l to left. Or to write a > ifTrue: (forget about the ugly of ifTrue haha) you can do ctrl + > shift + t .... etc.. and all of those things are useful to do with > shortcuts but there aren't in any menu. > > cheers, > Mariano > > > Adrian > > On Aug 4, 2009, at 17:41 , Marcus Denker wrote: > > > > > On 01.08.2009, at 18:19, Mariano Martinez Peck wrote: > > > >> > >> > >> On Sat, Aug 1, 2009 at 10:28 AM, Marcus Denker <denker(a)acm.org> > >> wrote: > >> On Friday, July 31, 2009, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> may be we should simply remove that item. > >>> menu > >>> system > >>> keyboard shortcuts > >> > >> yes > >> > >> why? is there other way newbie and not so newbie people can see the > >> list of shortcuts? Using the mouse is ugly for me and I try to use > >> shortcut as much as possible. > >> > > > > Can you add a bugtracker entry for having some documentation/help > > menu? The problem with the shortcuts was that in itself, it > > was a bit lonly... but mayne a real help menu would make sense. > > > > Marcus > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2009