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

Re: [Pharo-project] [Moose-dev] pharo sprint / moose dojo - october 23-24, bern

by Laval Jannik

Hi, Some guys from North of France cannot come to Bern. So we propose to make a shared session with you, but localized at LIFL, Villeneuve d'Ascq. We can do it during the two days. http://code.google.com/p/pharo/wiki/PharoSprints Cheers, Jannik On Sep 27, 2010, at 22:36 , Tudor Girba wrote: > Hi, > > We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). > > Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): > http://www.moosetechnology.org/events/2010-10-22-dojo > > For planning purposes, please let me know if you will attend. > > Cheers, > Doru > > p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) > http://choose.s-i.ch/events/forum2010 > > > -- > www.tudorgirba.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Oct. 11, 2010

Re: [Pharo-project] 12186 image quit problem

by StÃ©phane Ducasse

I integrate Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. http://code.google.com/p/pharo/issues/detail?id=3086 Igor can you have a look and let me know: 1- if we should rollback Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. 2- if we should integrate Issue 3048: MC method cache fix http://code.google.com/p/pharo/issues/detail?id=3048 I will integrate http://code.google.com/p/pharo/issues/detail?id=3091 Stef > Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 > > The patch works for me, Thank you Igor. > > Cheers, > -- Pavel > > On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > Have you thought about using a Mutex? Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are wonderful for #wait/#signal. But for #critical:, I use Mutex which won't deadlock a thread with itself. > > > > yes, i thought about it. It wont help in this situation, > because if you start modifying dictionary inside a loop, which > scanning its elements (like #do:) > you'll have very unpleasant results. > > All HostSystemMenusProxy doing during #finalize is removing itself > from weakregistry (which is complete nonsense, since weak registry > cleaning itself from dead stuff anyways). > So, > self protected: [ > valueDictionary expiredValuesDo: [:finItem | > finItem finalizeValues ]. > ]. > > actually triggers a bug/mistake in HostSystemMenusProxy , which leads > to deadlock. > :) > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > > Sent: Sunday, October 10, 2010 7:56 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] 12186 image quit problem > > > > OKay, now i see what the problem: > > > > <weak registry protected> > > <finalize items> > > <HostSystemMenusProxy>>finalize> > > .... > > <HostSystemMenusProxy class>>unregister> > > <weak registry protected> > > > > > > In my WeakRegistry, a #finalize message sent while registry semaphore locked, > > so, in case if object in #finalize trying to manipulate with registry > > then it going to deadlock. > > > > Then following piece: > > > > WeakRegistry>>finalizeValues > > > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | > > finItem finalizeValues ]. > > ]. > > > > should be rewritten as: > > > > | expired | > > expired := OrderedCollection new. > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] > > ]. > > expired do: #finalizeValues. > > > > > > But either way, HostSystemMenusProxy should not attempt remove itself > > from registry during #finalize (and causing a deadlock), > > since its pointless. > > > > > > -- > > 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. > > _______________________________________________ > 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

Oct. 11, 2010

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Adrian Lienhard

For convenience, this is the link to the issue: http://code.google.com/p/pharo/issues/detail?id=3090 I suspect that this bug is related to the new block closures. Adrian On Oct 11, 2010, at 07:15 , Sheridan Mahoney wrote: > I've just re-entered the Pharo world after a long(ish) absence, and wanted to report a > new bug submission; here's the breakdown: > > Pharo image: dev > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > Virtual machine used: 4.0.3.2202 Unix VM > OS: Ubuntu Lucid Lynx 10.04 > Class browser used if applicable: SystemBrowser default > > > Steps to reproduce: > > 1. start pharo > 2. open a Shout workspace > 3. select the just-opened workspace > 4. Ctrl-right button to get the meta-click window > 5. select 'save morph in file' > 6. hit 'ok' to proffered name for file > 7. a message box comes up that reads 'please wait while objects are > counted'. > 8. shortly after that an error is generated: > 'Error: this context was not included in the ImageSegment' > > > > I'm planning on doing more research, but wanted to get the issue reported. > > Cheers, > Sheridan > > PS - so far I really like 1.1.1 !!! Good work, gang! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

[Pharo-project] [update 1.2] #12188

by StÃ©phane Ducasse

12188 ----- - Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. - Issue 2875: PharoKernel Part 11. Thanks Pavel Krivanek and Nicolas Paes Stef

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

> > > ? > In any way, passing anything else than block literal as argument should work. You mean in the implementation or in the semantics? Read my mail. This is a question of semantics. The argument of iftrue:ifFalse: are thunk (piece of code with frozen execution). > This is smalltalk, not C with static types. consistency and elegance as nothing to do with absence of static types. With such a change we can break a lot of uniformity and break potential type inferencers. And I do not see the advantage, beside having a clunky system. Stef

Oct. 11, 2010

Re: [Pharo-project] another little OB "bug"

by Mariano Martinez Peck

On Mon, Oct 11, 2010 at 10:18 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > I investigated PluggableListMorph and ListMorph, the problem you > describe is there (likely this should be fixed in Pharo). In > > Name: OB-Morphic-lr.149 > Author: lr > Time: 11 October 2010, 10:17:53 am > UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e > Ancestors: OB-Morphic-lr.148 > > - more efficient fix for list updating > > I try to remember the current scroll position before updating any OB > list, so I guess this works around the problem (indeed the UI feels > better after the change). > Indeed, it works perfect :) Thanks lukas > > I am not sure if this fix is safe. It works well in my images, but it > might break some assumption of Morphic and destroy your image in the > worst case. > I like to be betatester and be in the bleeding edge :) > > Lukas > > On 10 October 2010 18:39, Lukas Renggli <renggli(a)gmail.com> wrote: > > I am not sure if I understand your question correctly, but presumably > > your method is too long or you have too many methods in one class or > > protocol. OB punishes you for this :-) > > > > Lukas > > > > 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no > >> problem then ;) > >> > >> Suppose you are working with a method that it is in the half of the > method > >> pane of OB. Once you save it or run test on it for example, the "scroll" > and > >> the method pane is updated so that THAT method is first, above. And > >> sometimes this is quite annoying for me. > >> > >> Cheers > >> > >> Mariano > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > -- > 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 >

Oct. 11, 2010

Re: [Pharo-project] 12186 image quit problem

by Pavel Krivanek

Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 <http://code.google.com/p/pharo/issues/detail?id=3091>The patch works for me, Thank you Igor. Cheers, -- Pavel On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > Have you thought about using a Mutex? Maybe I'm missing something in > life, but long ago I decided the #forMutualExclusion is *beyond* private. > Semaphores are wonderful for #wait/#signal. But for #critical:, I use > Mutex which won't deadlock a thread with itself. > > > > yes, i thought about it. It wont help in this situation, > because if you start modifying dictionary inside a loop, which > scanning its elements (like #do:) > you'll have very unpleasant results. > > All HostSystemMenusProxy doing during #finalize is removing itself > from weakregistry (which is complete nonsense, since weak registry > cleaning itself from dead stuff anyways). > So, > self protected: [ > valueDictionary expiredValuesDo: [:finItem | > finItem finalizeValues ]. > ]. > > actually triggers a bug/mistake in HostSystemMenusProxy , which leads > to deadlock. > :) > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [ > siguctua(a)gmail.com] > > Sent: Sunday, October 10, 2010 7:56 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] 12186 image quit problem > > > > OKay, now i see what the problem: > > > > <weak registry protected> > > <finalize items> > > <HostSystemMenusProxy>>finalize> > > .... > > <HostSystemMenusProxy class>>unregister> > > <weak registry protected> > > > > > > In my WeakRegistry, a #finalize message sent while registry semaphore > locked, > > so, in case if object in #finalize trying to manipulate with registry > > then it going to deadlock. > > > > Then following piece: > > > > WeakRegistry>>finalizeValues > > > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | > > finItem finalizeValues ]. > > ]. > > > > should be rewritten as: > > > > | expired | > > expired := OrderedCollection new. > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | expired add: finItem > ] > > ]. > > expired do: #finalizeValues. > > > > > > But either way, HostSystemMenusProxy should not attempt remove itself > > from registry during #finalize (and causing a deadlock), > > since its pointless. > > > > > > -- > > 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

Re: [Pharo-project] another little OB "bug"

by Lukas Renggli

I investigated PluggableListMorph and ListMorph, the problem you describe is there (likely this should be fixed in Pharo). In Name: OB-Morphic-lr.149 Author: lr Time: 11 October 2010, 10:17:53 am UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e Ancestors: OB-Morphic-lr.148 - more efficient fix for list updating I try to remember the current scroll position before updating any OB list, so I guess this works around the problem (indeed the UI feels better after the change). I am not sure if this fix is safe. It works well in my images, but it might break some assumption of Morphic and destroy your image in the worst case. Lukas On 10 October 2010 18:39, Lukas Renggli <renggli(a)gmail.com> wrote: > I am not sure if I understand your question correctly, but presumably > your method is too long or you have too many methods in one class or > protocol. OB punishes you for this :-) > > Lukas > > 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no >> problem then ;) >> >> Suppose you are working with a method that it is in the half of the method >> pane of OB. Once you save it or run test on it for example, the "scroll" and >> the method pane is updated so that THAT method is first, above. And >> sometimes this is quite annoying for me. >> >> Cheers >> >> Mariano >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by Sven Van Caekenberghe

Hi Nicolas, You have been working quite quickly, great! I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. I have been trying some of the examples from the doc pages (google code project), this simple one still fails: ((1 to: 10) reading collecting: [:x | x * x]) rest The readline example is using the non-existing #slicer: method, this simpler version seems to work: |text| text := 'line1\line2\line3\line4' withCRs reading. text := text ender: [ :char | char = Character cr ]. text collect: [ :line | line rest ]. That is a documentation bug though. Sven On 10 Oct 2010, at 22:09, Nicolas Cellier wrote: > Hi again, > I now have ported two more packages > - Xtreams-Transforms > - Xtreams-Substreams > and their tests > > I did not have any portability problem with those... > But that's because I did not handle the Character encoder/decoder. > Consequently, I have 8 tests failing (the Base64 related tests) > Plus 4 other tests failing because of my poor implementation of > #after:do: (forking processes in a SUnit TestCase can't be that > obvious). > > Now, the easy part of the port (copy/paste) is almost ended. > Once we manage a compatible way to handle pragmas, PEG Parser should > port quite easily too. > > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding > - Compression/Decompression > > If you think you can help in any of these, please tell. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Fernando olivero

Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. ISSUE 2653. http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… I did a test, maybe a good start would be to see if its failing now. Fernando On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > Hi Folks, > > Cuis doesn't include #autoEnclose, so I don't know how it should behave. > > Cheers, > Juan Vuletich > > Mariano Martinez Peck wrote: >> Guille, if I remember correctly (not sure), these new classes like >> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >> think he is in the mailing list but not read it so frequently. So, for >> this issues maybe you can cc'ed him. >> >> Cheers >> >> Mariano >> >> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> >> >> Here is the piece of code that's behaving weird >> >> TextEditor>>dispatchOn: >> >> ... >> ... >> char := aKeyboardEvent keyCharacter. >> openers := '([{'. >> closers := ')]}'. >> ( closers includes: char) ifTrue: [ self blinkPrevParen: >> char ]. >> result := self normalCharacter: aKeyboardEvent. >> (self class autoEnclose and: [ openers includes: char ]) >> not ifTrue: [ ^ result ]. >> suffix := closers at: (openers indexOf: char). >> paragraph text append: suffix asString. >> self moveCursor: [ : position | position ] forward: true >> specialBlock: [ : pos | "no special behavior" ] event: >> aKeyboardEvent . >> self userHasEdited. >> >> ------------------------------------- >> >> So, if I evaluate "TextEditor autoEnclose: false", it is stops >> behaving like that :) >> >> What should be the desired behavior? Having it configurable as it >> is today but fix the strange bracket adding? remove this behavior? >> I can't find now how ParagraphEditor did this. >> >> Guille >> >> >> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Yes, the issue can be reduced to: >> >> open parenthesis (or brackets), then something else (anywhere >> in the editor). >> >> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >> <mailto:marianopeck@gmail.com>> >> >> I detected a similar problem: >> >> once you type an opening parenthesis, and then something >> else, it adds a new one at the END of the code >> >> check http://code.google.com/p/pharo/issues/detail?id=2939 >> >> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> >> >> http://code.google.com/p/pharo/issues/detail?id=3069 >> >> if you type: >> >> [] -> []] >> >> () -> ()) >> >> {} -> {}} >> >> >> >> >> Bye! >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@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 >> <mailto:Pharo-project@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 >> <mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010