July 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14028

by Marcus Denker

14028 ----- Issue 4503: Suggested fix using directly the Display canvas, and some low-level drawing http://code.google.com/p/pharo/issues/detail?id=4503 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 7, 2011

Re: [Pharo-project] Pharo Announcements and WADynamicVariable do not play nice

by Igor Stasenko

On 7 July 2011 16:43, Danie Roux <lists+pharo(a)danieroux.com> wrote: > Hi all, > > We use Announcements in our Seaside app. I've upgraded our Pharo image > (from an ancient one) and the upgraded image looses the user's > session. > > This issue is here: > > AnnouncementSubscription>>deliver: anAnnouncement > Â Â Â Â " deliver an announcement to receiver. In case of failure, it will be > handled in separate process" > > Â Â Â Â ^ (self handles: anAnnouncement class ) ifTrue: [ > Â Â Â Â Â Â Â Â [action cull: anAnnouncement cull: announcer] > Â Â Â Â Â Â Â Â Â Â Â Â on: Exception fork: [:ex | ex pass ]] > > Because of the catch-all, WARequestContext can't do its fancy footwork > to manage thread-local variables. > > What is the rationale behind this? I removed the error handling. > The rationale is that failing handling an announcement by one subscriber should not prevent it from receiving announcement by another subscriber. Consider that you have two subscribers for same announcement. and one subscriber is broken and throwing an exception(s) during handling it. This could prevent other subscriber from receiving announcement, and therefore in the end you will have a 'lost events' effect. To prevent it, there are #on:fork: which guards against any exceptions and guarantees that execution at this point will continue normally , no matter what handler does. Maybe Exception is too strict and we should handle only Errors there. But consider to not use exceptions in announcement handling code, because this leads to the described scenario, which is certainly adds fragility to announcements. Since we want to use announcements in mission critical places, like delivering system events and logging compiled sources, and managing package info, it is important that for system announcer , any buggy subscribers won't put system on its knees. Because from the point of view of subscriber , there nothing should prevent it from receiving an announcement. There should be no interference between multiple subscribers subscribed for same announcement, because they could even don't know about each other. > -- > Danie Roux *shuffle* Adore Unix - http://danieroux.com > > -- Best regards, Igor Stasenko AKA sig.

July 7, 2011

[Pharo-project] Pharo Announcements and WADynamicVariable do not play nice

by Danie Roux

Hi all, We use Announcements in our Seaside app. I've upgraded our Pharo image (from an ancient one) and the upgraded image looses the user's session. This issue is here: AnnouncementSubscription>>deliver: anAnnouncement " deliver an announcement to receiver. In case of failure, it will be handled in separate process" ^ (self handles: anAnnouncement class ) ifTrue: [ [action cull: anAnnouncement cull: announcer] on: Exception fork: [:ex | ex pass ]] Because of the catch-all, WARequestContext can't do its fancy footwork to manage thread-local variables. What is the rationale behind this? I removed the error handling. -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

July 7, 2011

[Pharo-project] [update 1.3] #13283

by Marcus Denker

13283 ----- Issue 4503: Suggested fix using directly the Display canvas, and some low-level drawing http://code.google.com/p/pharo/issues/detail?id=4503 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 7, 2011

Re: [Pharo-project] WindowOrganizer integration problems

by laurent laffont

Another big thank you Gary ! In last TWM version there's a first (almost) working prototype of DockingWindowMorph. DockingWindowMorph new openInWorld. Now I need to make window/tab activation nice and fix a bug when the first tab is closed. Laurent. On Thu, Jul 7, 2011 at 12:09 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > ** > Hi Laurent > > The GroupWindowMorph does fill the window, however it has no layout policy > to the tab group within doesn't fill. > > In GroupWindowMorph initialize, either do a self changeProportionalLayout > or self changeTableLayout (making the fullFrame: bit redundant). > > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Wednesday, July 06, 2011 10:34 PM > *Subject:* [Pharo-project] WindowOrganizer integration problems > > Hi, > > As work from Gary about grouping windows has been integrated in 1.4, I try > to use it for TWM. > > If you load: > > Gofer it > squeaksource: 'TilingWindowManager'; > package: 'TWM'; > load. > > StandardWindow new > addMorph: GroupWindowMorph new fullFrame: (LayoutFrame fractions: (0@0corner: > 1@1)); > openInWorld. > > > You can drag and drop windows in the GroupWindowMorph to tab them. > > But I cannot find why GroupWindowMorph does not fill all the window....... > Gary ? > > Then I want to use GroupWindowMorph in a DockingBar. There's some initial > work in DockingWindowMorph but I'm stuck with the space fill problem. > > Cheers, > > Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > >

July 7, 2011

Re: [Pharo-project] WindowOrganizer integration problems

by Gary Chambers

Hi Laurent The GroupWindowMorph does fill the window, however it has no layout policy to the tab group within doesn't fill. In GroupWindowMorph initialize, either do a self changeProportionalLayout or self changeTableLayout (making the fullFrame: bit redundant). Regards, Gary ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Wednesday, July 06, 2011 10:34 PM Subject: [Pharo-project] WindowOrganizer integration problems Hi, As work from Gary about grouping windows has been integrated in 1.4, I try to use it for TWM. If you load: Gofer it squeaksource: 'TilingWindowManager'; package: 'TWM'; load. StandardWindow new addMorph: GroupWindowMorph new fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)); openInWorld. You can drag and drop windows in the GroupWindowMorph to tab them. But I cannot find why GroupWindowMorph does not fill all the window....... Gary ? Then I want to use GroupWindowMorph in a DockingBar. There's some initial work in DockingWindowMorph but I'm stuck with the space fill problem. Cheers, Laurent Laffont - @lolgzs Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by Pavel Krivanek

On Thu, Jul 7, 2011 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote: > > > Hi Marcus, > > > > add this line to the initCore.st script on CI server: > > > > ActiveHand instVarNamed: #targetOffset put: 0@0. > > > Done and build started: > > https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/ Works! only one failing test left :-) -- Pavel

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by Pavel Krivanek

On Thu, Jul 7, 2011 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote: > > > Hi Marcus, > > > > add this line to the initCore.st script on CI server: > > > > ActiveHand instVarNamed: #targetOffset put: 0@0. > > > Done and build started: > > https://ci.lille.inria.fr/pharo/job/Pharo%ckages now have already > two sets of du20Kernel%20Reload/<https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/> > > > > this will fix the testTargetPoint. The second and last failing tests is > related to compressed unicode tables in the kernel image. I will prepare the > code that will regenerate this tables. > > > > The second option is to disable call of privShrinkUnicodeTables method in > privShrinkingProcess. The resultant kernel and gofer images will be bigger. > The question is if we will shrink this tables by default. > > I am in general not happy how resources are right now stored in the > image... the only way right now is to either have them just there as > objects, non-recreateble or people store stuff (fonts, bitmaps) > as strings (or ByteArrays) in methods. This is not nice... but of course MC > can store it and so its the only option. > > We should think about having an in-image, virtual file-system with all the > static stuff... maybe this could even be per package and serialized with MC > as part of the package? > It is quite easy to extend data stored in MC packages, for example for the original versions of the KernelImage I extended packages with preamble and postcript files. The only problem was with versioning of this extensions. Life would me more easy if MC would provide general interface for versioning of all kinds of files in the package. > The MC packages now have already two sets of duplicated data: source (in > the .st file) and the MC History data... which should not be underestimated: > MC wastes right now 4MB of 13.5 MB in 1.4, > In addtion, the fact that we have to wirite to .changes when loading a > package is far from nice... it would be better of packages would be > self-contained and the system would get the source > from them. > Interesting idea. The good start would be introduction of general pluggable source managers. -- Pavel > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by Marcus Denker

On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote: > Hi Marcus, > > add this line to the initCore.st script on CI server: > > ActiveHand instVarNamed: #targetOffset put: 0@0. > Done and build started: https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/ > this will fix the testTargetPoint. The second and last failing tests is related to compressed unicode tables in the kernel image. I will prepare the code that will regenerate this tables. > > The second option is to disable call of privShrinkUnicodeTables method in privShrinkingProcess. The resultant kernel and gofer images will be bigger. The question is if we will shrink this tables by default. I am in general not happy how resources are right now stored in the image... the only way right now is to either have them just there as objects, non-recreateble or people store stuff (fonts, bitmaps) as strings (or ByteArrays) in methods. This is not nice... but of course MC can store it and so its the only option. We should think about having an in-image, virtual file-system with all the static stuff... maybe this could even be per package and serialized with MC as part of the package? The MC packages now have already two sets of duplicated data: source (in the .st file) and the MC History data... which should not be underestimated: MC wastes right now 4MB of 13.5 MB in 1.4, In addtion, the fact that we have to wirite to .changes when loading a package is far from nice... it would be better of packages would be self-contained and the system would get the source from them. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 7, 2011

[Pharo-project] [PBE-Spanish] Status update 2011-07-06

by NicolÃ¡s Paez

Hello everyone, Here is the weekly update of the Spanish translation of Pharo By Example book. During this past week, we didn't do any important progress, we still have 2 chapters under translations. We started the review process and we have publish a new preview containing 9 chapters. You can download this preview from this location: https://gforge.inria.fr/frs/download.php/28711/PBE1-Spanish-Draft-2011-07-0… Regards, Nico Saludos! Nico. blog: nicopaez.wordpress.com

July 7, 2011