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

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

by Lukas Renggli

What version of Seaside is this? There are several debugger related bugs in Seaside 2.9a4: <http://code.google.com/p/seaside/issues/list?q=debugger>. Lukas 2009/8/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Aug 4, 2009, at 8:33 PM, Johan Brichau wrote: > >> 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.... > > Thanks this is important. > Can you open a bug entry report? > I go some problem with the system not been able to spawn a debugger > but I was waiting to get the beta version. > > Stef > >> >> ---------------------------- >> Johan Brichau >> johan.brichau(a)uclouvain.be >> >> >> >> >> >> _______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Aug. 5, 2009

[Pharo-project] can anyone justify the following comment behaviour?

by StÃ©phane Ducasse

Date: 2009-08-05 03:55:59 GMT (4 hours and 2 minutes ago) Hi All, in ParseNode>>printCommentOn: there is the most perplexing destructive modification of a comment on printing: printCommentOn: aStream indent: indent | thisComment | self comment == nil ifTrue: [^ self]. 1 to: self comment size do: [:index | index > 1 ifTrue: [aStream crtab: indent]. aStream nextPut: $". thisComment := self comment at: index. self printSingleComment: thisComment on: aStream indent: indent. aStream nextPut: $"]. !! self comment: nil The result is that a parse tree can only be printed once before it prints without comments. Can anyone justify this? I would like to remove it; it makes no sense to me. best Eliot

Aug. 5, 2009

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

by StÃ©phane Ducasse

Henrik here is my answer: so I would really like to get enhanced strikefonts in pharo. Now I would like to have the point of view of the font experts. http://code.google.com/p/pharo/issues/detail?id=1037 >> Hi Stef, >> >> StÃ©phane Ducasse wrote: >>> Hi juan >>> >>> Ideally in Pharo I would really like to be able to have really >>> nice fonts without relying >>> on external plugin. Now I do not know too much about fonts. >>> Do you know that we could have the best of both worlds: >>> - your idea >>> - freetype. >>> >>> Stef >> >> Yes, I don't see any reason for not doing so. Load the attached. >> First 'preliminaries', then the big one. >> >> Enjoy! >> >> Cheers, >> Juan Vuletich On Aug 4, 2009, at 8:05 PM, StÃ©phane Ducasse wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2009

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

by StÃ©phane Ducasse

Hi henrik what I suggest is: cut your messages into smaller ones so that we can get multiple and clear thread. Then enter bug items when needed. Stef On Aug 5, 2009, at 12:49 AM, Henrik Sperre Johansen wrote: > 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 >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2009

Re: [Pharo-project] file dialog

by StÃ©phane Ducasse

if you have a fix tag it 1.0 ;) Stef On Aug 5, 2009, at 12:56 AM, Mariano Martinez Peck wrote: > > > On Tue, Aug 4, 2009 at 7:32 PM, Tudor Girba <girba(a)iam.unibe.ch> > wrote: > 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? > > I could reproduce it and debugging I noticed that > > FileDialogWindow>>validExtensions: aList > "Set the filter for the files to be those with the given > extensions." > > aList notEmpty > ifTrue: [self defaultExtension: aList first]. > self fileSelectionBlock: [:de | > de isDirectory > ifTrue: [self showDirectoriesInFileList] > ifFalse: [(self fileNamePattern match: de name) and: [ > aList includes: (FileDirectory extensionFor: > de name asLowercase)]]] > > > I think there can be a problem with this method. Here, aList will be > '*.*' and as you can imagine that string doesn't includes any of the > extensions. Perhaps we can change that include for a match: or > something like that. To see this, remove the line > aList includes: (FileDirectory extensionFor: de name asLowercase > > and you will see that now all the files are shown. > > we should open a ticket but I don't know if this should be 1.0 tag > > best, > > Mariano > > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know > her." > > > > > _______________________________________________ > 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. 5, 2009

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

by StÃ©phane Ducasse

On Aug 4, 2009, at 8:33 PM, Johan Brichau wrote: > 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.... Thanks this is important. Can you open a bug entry report? I go some problem with the system not been able to spawn a debugger but I was waiting to get the beta version. Stef > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2009

Re: [Pharo-project] table widget

by Carlos Crosetti

Blame on me as I go off-topic for a while - I believe some of you are challenged to determine the Smalltalk platform to use when you are in the decision making about what is the most suitable developmenbnt tool to face some new project opportunity. This is not happening to me very often. This is the wiki page about GUI builders for Saqueak http://wiki.squeak.org/squeak/1576 So far I invested some time to find something suitable to my needs and expectations. Maui, from Chris Muller - interesting implementation appproach, have a document that starts well to the newbie but quickly turns to a strong smalltalk practtioner audience - so will be somewhat hard to follow - i am challenging Chris to add more real world samples and deliver a one-click image like Seaside. At this time I am with other priorities so I am behind going with Maui adoption. wxSqueak - hybrid implemenation, but a rich one. You have to deal with an image that has the wxwidgets statically linked, demos are nice, I am not the purist that wont accept to extend C or C++, but in the first attemtpt to clone demo code into something I was going to show to a customer, I stumbled with too many vm crashes - so worried about that.. You may consider the energy to behave defensively all the time. Other links shown broken. I liked polymorph, but lacks of a dataset/grid morph. I combined polymorh with Sgrid but sgrid is not at the level polymorh is. Pharo is loaded with Polymorph, check evaluating UITheme exeampleOtherControls I am fine in spendng time to assemble widegets and models by code, but have to say that I am comfortable with VW and the UIBuilder - so I will stay calm and follow Pharo and Squeak communities to show up with an initiative to incorporate a table layour, grid and dataset morphs unto polymorhp.... dreaming? -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Stephane Ducasse Enviado el: Martes, 04 de Agosto de 2009 11:44 a.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] table widget There is one. ask in the squeak mailing-list because I do not remember. and may be it is not working. On Aug 2, 2009, at 1:57 AM, Tudor Girba wrote: > Hi, > > Is there a table widget in Morphic/Polymorph? > > I would features like: > - add columns > - sort the rows based on a column > - select a row > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > 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 -- Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008 11:07 a.m.

Aug. 5, 2009

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

by Marcus Denker

On 04.08.2009, at 18:58, Marcus Denker wrote: > > On 04.08.2009, at 18:49, Henrik Sperre Johansen wrote: > >> Hmm, so bugs are ok? >> > > Why? Nobody said that we will not mark more issues as to be fixed > for 1.0... > what was said is that we will not have a second stream and start to > add fixes > that are decided to not be included in 1.0 there. Nothing else. > > If you want other reports to be tagges 1.0, add a note in the > bugreport. > If you find new bugs, add a new report and tell the world that you > think > that it needs to be fixed for 1.0. another note: It should be clear that a release always is just a snapshot. There will not be all problems solved. The idea is to just denote one version as "we used this for a while and it seems to work ok for most people". Nothing else. If somebody want to wait for perfection, Pharo is not the place to be. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 4, 2009

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

by Marcus Denker

On 04.08.2009, at 18:49, Henrik Sperre Johansen wrote: > Hmm, so bugs are ok? > Why? Nobody said that we will not mark more issues as to be fixed for 1.0... what was said is that we will not have a second stream and start to add fixes that are decided to not be included in 1.0 there. Nothing else. If you want other reports to be tagges 1.0, add a note in the bugreport. If you find new bugs, add a new report and tell the world that you think that it needs to be fixed for 1.0. Marcus > 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 >> >> >> > > > _______________________________________________ > 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

Re: [Pharo-project] file dialog

by Mariano Martinez Peck

On Tue, Aug 4, 2009 at 7:32 PM, Tudor Girba <girba(a)iam.unibe.ch> wrote: > 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? I could reproduce it and debugging I noticed that FileDialogWindow>>validExtensions: aList "Set the filter for the files to be those with the given extensions." aList notEmpty ifTrue: [self defaultExtension: aList first]. self fileSelectionBlock: [:de | de isDirectory ifTrue: [self showDirectoriesInFileList] ifFalse: [(self fileNamePattern match: de name) and: [ aList includes: (FileDirectory extensionFor: de name asLowercase)]]] I think there can be a problem with this method. Here, aList will be '*.*' and as you can imagine that string doesn't includes any of the extensions. Perhaps we can change that include for a match: or something like that. To see this, remove the line aList includes: (FileDirectory extensionFor: de name asLowercase and you will see that now all the files are shown. we should open a ticket but I don't know if this should be 1.0 tag best, Mariano > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > _______________________________________________ > 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