- Pharo-dev - lists.pharo.org

[Pharo-project] Cross compile Window from Unix/Mac os

by Jean Baptiste Arnaud

Since the last Igor ( thank ) update it 's possible to cross compile windows VM(last version) from MacOs and Unix. Using Mingw and cmake. Now, i do for Cog, and for ARM9 processor. My process imply to fix some window file cause some include are wrong, then it the cross compiler don't find some include beginning by Uppercase(cause the file isn't beginning by uppercase). In /Platform/win32/vm/sqWin32Intel.c #include <float.h> instead #include <Float.h> in /Platform/win32/plugin/SocketPlugin/sqWin32NewNet.c #include <ws2tcpip.h> instead #include <Ws2tcpip.h> Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

July 7, 2011

[Pharo-project] inheritence

by Hilaire Fernandes

With Pharo 1.3, one behavior I am not sure it is a bug or not, In the browser, in a method, when I click on the inheritence button I only get a list of the ascendant no the descendant. Is the normal behavior? Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by StÃ©phane Ducasse

On Jul 7, 2011, at 10:52 AM, Pavel Krivanek wrote: > > > 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/ > > > > 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. Yes! > 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

[Pharo-project] would be good to have a presence there

by StÃ©phane Ducasse

http://www.openworldforum.org/rfp/code-osdc.html

July 7, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by StÃ©phane Ducasse

Hi guys I'm in town. Now I want to make clear the following: This idea is much more on having an effort to collect todo and manage to kill some of them regularly than to engage to for long task. As an example for the UI I would like - layout fixed so that glamour IDE can work - in place edit in list items (for example to be able to directly edit the protocol of a method in a sender list) - an option to get list showing only elements matching an input on the fly What you see is that we should have list of "simple" tasks that people can sign in for. The idea is that we should coordinate a bit to make progress. Stef On Jul 1, 2011, at 10:40 AM, StÃ©phane Ducasse wrote: > Dear Pharoers > > I think that we are doing a great work: when I look at the work on the theme, better widgets, network.....Excellent! and thanks. > Now we were discussing with Doru about how we as community could coordinate and structure ourselves better to create more energy. > > Analysis of the current situation: > Right now we have individuals doing great projects, sometimes we have a group of people but this is often not visible. > Now often happens a bit in ad-hoc way. Because someone ask something, then somebody replies and we integrate the replies. > > What I would like to see emerging are First Class Tasks with > a name > a topic > a coordinator > a group of interested participants, > a set of identified clients (because clients are the ones that often make us deliver more), > a little agenda, > a web presence on the web page > > > If we look at what we have right now that are potential Tasks and really important clients > > - The Z connection: > Network/Socket > Coordinator (proposed): Sven > Socket: Noury Luc Jannik Olivier > Clients: Seasiders, Clouders, > > - Morphic 2: > UI: Alain Gary Igor > Coordinator (proposed): ? > Presenty framework > VoidNullPointer UIBuilder > Athens > Clients: Moose, Pharo IDE > > - Pharo IDE: > Coordinator (proposed): Doru > work around TWM Laurent > Nautilus: Benjamin Laurent > Glamourous: Doru Damien > > - OPAL: > Compiler tool chain > Coordinator (proposed): Marcus? > Jb, Jorge, Marcus, > Helvetia lukas > Niko Schwarz? > > - Package: > Stef, Cyrille > Coordinator (proposed): Stephane > Client: Nautilus, Doru Moose, > > - Metacello > Dale Mariano > Coordinator (proposed): Dale? > Client: Stef with the idea of distribution, Torsten don't you want to help here? > > - Coral: > Coordinator (proposed): Damien? > Damien, Luc, Adrien, Stef, > Client: Damien, Olivier? > > So what would be good is to have the identification on the web site of these groups. > More discussions and concentration with a set of little tasks to be performed > We could tag the mails with [Task-UI], [Task-OPAL], have a little visible agenda. > > What do you think? I think that it is important. > > > > Stef >

July 7, 2011

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

by Henrik Johansen

Couldn't Danie's problem also be stated as "forked processes don't inherit their parents environment"? Or is there more stopping WARequestContext from working? Apart from the fact that they currently don't, is there a good reason they shouldn't? Cheers, Henry On Jul 7, 2011, at 4:56 55PM, Igor Stasenko wrote: > 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] [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