- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Progress Report] Zinc HTTP Components
by StÃ©phane Ducasse Oct. 1, 2010

Oct. 1, 2010

Cool! Stef On Oct 1, 2010, at 10:04 AM, Sven Van Caekenberghe wrote: > Here is a quick progress report regarding the Zinc HTTP Components project. > Please check the SqueakSource history for a all the details. > The external documentation has not yet been updated ;-) > > I am very pleased that Matt Kennedy joined the project as a developer and > is contributing lots of really important and interesting code - way to go Matt! > > Some highights are: > > - we now have cookie handling, authentication and credential objects > - there is a new ZnUserAgent client that can do advanced authentication > handles cookies, sessions and that can follow redirects > - there is a ZnFixedClient that can reuse a connection to the same host/port > - there is support for client side chunked and gzip decoding > - there is an experimental server that keeps connections alive (unfinised) > - support classes ZnUserAgentSession and ZnUserAgentSession > - lots of refactorings, fixes and portability improvements > - the number of unit tests has increased to 71 > > Sven > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 4

[Pharo-project] [update 1.2] #12163
by StÃ©phane Ducasse Oct. 1, 2010

Oct. 1, 2010

12163 ----- - Issue 3035: Workspace(Object)>>doesNotUnderstand: #spawn:. Thanks mariano Martinez-Peck - Issue 3032: Memory consuption of Objects. Thanks mariano Martinez-Peck - Issue 3037: SpaceTally should use #instancesSizeInMemory. Thanks mariano Martinez-Peck

1 0

[Pharo-project] Multiple finalizers per single object
by Igor Stasenko Oct. 1, 2010

Oct. 1, 2010

Hello, i'd like to raise this subject once more, because i don't like it (or don't understand?). In all scenarios, where i met the need to use finalization, a single finalizer is sufficient. Moreover, there is always a single object who controls a weak reference, and it never leaks it out, to prevent the case, when some other object may obtain a strong reference on it, making it permanently held in object memory. Multiple different finalizers for single object, from design point of view, means that you having two different, not related frameworks, which using same object, and want to do something when it dies. A scenario, where its possible and userful, still don't comes into my mind. In contrary, whenever i see a use of finalizers, its in most cases about graceful control over external resource, such as: - file - socket - external memory and i really don't see how multiple finalizers per single resource could do any good. Suppose one finalizer closing a file handle, while another one flushing it buffer cache. Now, how you going to ensure, that one finalizer will execute first, before another one? And what if third framework comes into play and wants to add another finalizer on top of that, which should do something in the middle between flushing a cache and closing file handle? >From the above, the only conclusion can be made: use a single finalizer, and put all logic & operation ordering into it. And also, prevent leakage of object pointer (such as file handle) outside of your model, otherwise it may cause harm. That's why i think a current WeakRegistry model provoking bad design practices. I think a better behavior would be to raise an error, if something wants to register finalizer twice for a single object. -- Best regards, Igor Stasenko AKA sig.

4 4

[Pharo-project] ToolBuilderTests>>testGetButtonSideEffects seems to be wrong
by Cyrille Delaunay Oct. 1, 2010

Oct. 1, 2010

if you look at the code of ToolBuilderTests>>testGetButtonSideEffects: testGetButtonSideEffects self makeButton. queries := IdentitySet new. self changed: #testSignalWithNoDiscernableEffect. self expectedButtonSideEffects do:[:sym| self assert: (queries includes: sym). queries remove: sym. ]. .... the variable queries is never fill in, therefore I don't understand how the assertion could pass. In pharo 1.2-12159 the test fail for the class MorphicToolBuilderTests for which 'expectedButtonSideEffects' return a non-empty collection (unlike ToolBuilderTests). I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3038

1 0

[Pharo-project] [update 1.2] #12162
by StÃ©phane Ducasse Oct. 1, 2010

Oct. 1, 2010

12162 ----- Issue 2713: Changelist deserves some fixes Issue 3030: Remove Explain... code (again) Issue 3023: change the initial windows position strategy Issue 3028: PluggableListMorphByItem >> getCurrentSelectionIndex access directly a non-initailized instance variable Stef

1 0

[Pharo-project] Issue 3036: SUnit Refactoring
by Sean P. DeNigris Oct. 1, 2010

Oct. 1, 2010

In the course of working through A Mentoring Course on Smalltalk, I applied some small refactorings to SUnit. Issue: http://code.google.com/p/pharo/issues/detail?id=3036 Fix in inbox: SUnit-SeanDeNigris.114 * TestCase now uses class>>suiteClass instead of referencing the class name directly * TestSuite now uses #resultClass instead of referencing the class name directly Also, 114 is a merge of SUnit-StephaneDucasse.113 and SUnit-SeanDeNigris.106 (a package saved in my local cache). Should I upload SUnit-SeanDeNigris.106 also? Thanks. Sean -- View this message in context: http://forum.world.st/Issue-3036-SUnit-Refactoring-tp2914375p2914375.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

[Pharo-project] [update 1.2] #12161
by stephane ducasse Oct. 1, 2010

Oct. 1, 2010

12161 ----- - Issue 3003: handleDisabledKey: is missing in Editor and subclasses - Issue 2963: systemOrganizer fixes. Thanks German Leiva and James Foester Stef

1 0

Oct. 1, 2010

Hi guys sorry for the mess but the weakarray changes are putting the system on his knees. :) we cannot merge anymore. So I suggest that we rollback until 12160 and let igor happily fix it. Stef

1 0

Oct. 1, 2010

Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: > 2010/10/1 Levente Uzonyi <leves(a)elte.hu>: >> On Fri, 1 Oct 2010, Igor Stasenko wrote: >> >>> On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote: >>> On Fri, 1 Oct 2010, Marcus Denker wrote: >>> >>>> Issue 3002: A new finalization code ready for integration in Pharo >>>> Issue 3026: after 12172, sync with repository and reload >>> >>> If you didn't fix the migration code, then WeakFinalizationRegistry is >>> still >>> in the system. Details here: >>> >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400… >>> >> You mean this not work: >> Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. >> >> should be >> Smalltalk forgetClass: WeakFinalizationRegistry logged: false. >> >> right? >> >> >> Yes. >> >> > Thanks for noticing. > >> Levente >> >>> >>> Levente >>> >>>> >>>> -- >>>> Marcus Denker -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > 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

2 1

[Pharo-project] Fix of Create button in Debugger (#3010 and #3011)
by Luc Fabresse Oct. 1, 2010

Oct. 1, 2010

Hi all, We integrate the fix proposed by Hernan for #3010 and #3011. Hernan, thanks a lot for your fix proposal. Next time, just test it before on the latest Pharo (curently 1.2 and not 1.1) to make the integration easier. Thanks, Luc

1 0