February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20514 (Zinc Update)

by Sven Van Caekenberghe

On 05 Feb 2013, at 13:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > but when I do load update it does not find the file on the server. You mean that one of the versions in not in the inbox ?

Feb. 5, 2013

Re: [Pharo-project] [update 2.0] #20514 (Zinc Update)

by Marcus Denker

No, it does not work I have no clue why not, I could load it just now when filing in directly the update file, but when I do load update it does not find the file on the server. On Feb 5, 2013, at 1:52 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Issue 7375: Zinc Update January 2013 > http://code.google.com/p/pharo/issues/detail?id=7375 > > > Sven explains: > > Since http://code.google.com/p/pharo/issues/detail?id=7180 there were the following changes: > > - support for server routes (session affinity, sticky sessions) > - new API to access the server URL (#url, #serverUrl, #scheme) > - ZnResponse class>>#redirect: and #created: now accept absolute URLs as well (thx Jan van de Sandt) > - New ZnRequest API (all suggested by Jan van de Sandt): > #host to return the Host: header field as ZnUrl > #relativeUrl to explicitely request the request line uri as a relative URL > #absoluteUrl to combine the request line URL with the host URL into an absolute URL > #mergedFields to return a multi value dictionary combining query fields and application url encoded form fields > - ZnClient>>#redirectUrl now uses ZnUrl>>#inContextOf: > - Reimplemented ZnApplicationUrlEncodedEntity>>#addAll: and ZnHeaders>>#addAll: > using ZnMultiValueDictionary>>#addAllMulti: > - fix ZnUtils class>>#signalProgress:total: bug when total was nil: #format: index should be 1 not 0 (Thx Camillo Bruni !) > - added ZnMessage>>#writeToTranscript > - Bugfix to ZnApplicationFormUrlEncodedEntity>>#readFrom: which failed when content-length was not specified (Thx Jan van de Sandt) > - Extended ZnClient>>#url: to accept the new user info (username and password) component of ZnUrl when present > - ZnRequestLine>>#uri: now explicitely calls #enforceKnownScheme > - various refactorings, cleanups > - moved ZnMonticelloServerDelegate from Zinc-HTTP-Client-Server to Zinc-FileSystem and Zinc-FileSystem-Legacy > - ZnServer's #handleRequestProtected: will now also do a #logServerError unless #logServerDetails is false - this gives exception, > signaller context details and a stack trace of depth 8 when an unhandled error occurs > - There is also a new package, Zinc-Resource-Meta-FileSystem, containing bidirectional conversions between ZnUrl and > FileReference using #asZnUrl and #asFileReference. > > > >

Feb. 5, 2013

[Pharo-project] [update 2.0] #20514 (Zinc Update)

by Marcus Denker

Issue 7375: Zinc Update January 2013 http://code.google.com/p/pharo/issues/detail?id=7375 Sven explains: Since http://code.google.com/p/pharo/issues/detail?id=7180 there were the following changes: - support for server routes (session affinity, sticky sessions) - new API to access the server URL (#url, #serverUrl, #scheme) - ZnResponse class>>#redirect: and #created: now accept absolute URLs as well (thx Jan van de Sandt) - New ZnRequest API (all suggested by Jan van de Sandt): #host to return the Host: header field as ZnUrl #relativeUrl to explicitely request the request line uri as a relative URL #absoluteUrl to combine the request line URL with the host URL into an absolute URL #mergedFields to return a multi value dictionary combining query fields and application url encoded form fields - ZnClient>>#redirectUrl now uses ZnUrl>>#inContextOf: - Reimplemented ZnApplicationUrlEncodedEntity>>#addAll: and ZnHeaders>>#addAll: using ZnMultiValueDictionary>>#addAllMulti: - fix ZnUtils class>>#signalProgress:total: bug when total was nil: #format: index should be 1 not 0 (Thx Camillo Bruni !) - added ZnMessage>>#writeToTranscript - Bugfix to ZnApplicationFormUrlEncodedEntity>>#readFrom: which failed when content-length was not specified (Thx Jan van de Sandt) - Extended ZnClient>>#url: to accept the new user info (username and password) component of ZnUrl when present - ZnRequestLine>>#uri: now explicitely calls #enforceKnownScheme - various refactorings, cleanups - moved ZnMonticelloServerDelegate from Zinc-HTTP-Client-Server to Zinc-FileSystem and Zinc-FileSystem-Legacy - ZnServer's #handleRequestProtected: will now also do a #logServerError unless #logServerDetails is false - this gives exception, signaller context details and a stack trace of depth 8 when an unhandled error occurs - There is also a new package, Zinc-Resource-Meta-FileSystem, containing bidirectional conversions between ZnUrl and FileReference using #asZnUrl and #asFileReference.

Feb. 5, 2013

Re: [Pharo-project] Strange behaviour in Spec

by Goubier Thierry

Hi Andrei, I tested with the following code which shows some interesting effects: |list| list := ListComposableModel new. list whenListChanged: [:aList| Transcript crShow: aList = list listItems]. 10 timesRepeat: [ list items: #(1 2). list listItems. "Call listItems to set the cache" list items: #(1 2 3). list listItems]. And I either get true-true-true-true or, true-false-false-false ... When I get true-true-true, in list listHolder announcer registry subscriptions, I have the action [:aList| Transcript crShow: aList = list listItems] set after the action [self refreshListItems]. When I get true-false-false-false ad nauseam, in list listHolder announcer registry subscriptions, I have the action [:aList| Transcript crShow: aList = list listItems] set "before" the action [self refreshListItems]. So, it seems that the use of an identitySet in subscriptions for an announcer has interesting side effects. So, what should be done ? 1- Change subscription in Announcer SubscriptionRegistry from IdentitySet to OrderedCollection : it should keep the same behavior in all users of Announcers, since they have to be order independent (otherwise, they would fall for the same intermittent bug given the chance). 2- Change ListComposableModel to use a private event to update the cache before entertaining a #changedValue event. I have a preference for 1-, because of my soft spot for programs that have a nice, predictable behavior :) I've added a ticket http://code.google.com/p/pharo/issues/detail?id=7420 Thierry Le 05/02/2013 11:31, Andrei Vasile Chis a Ã©crit : > Hi, > > A very simple way to reproduce is to open a transcript and execute this > code: > 50 timesRepeat: [|list| > list := ListComposableModel new. > list items: #(1 2). > list whenListChanged: [:aList| > Transcript crShow: aList = list listItems]. > list listItems. "Call listItems to set the cache" > list items: #(1 2 3) ]. > > If should print both true and false. > Every time it prins false the events were triggered in the wrong order. > > Andrei > > On Tue, Feb 5, 2013 at 9:26 AM, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > Le 04/02/2013 17:27, Andrei Vasile Chis a Ã©crit : > > Hi, > > While playing with spec I started to have some quite random and > strange behaviour. > I'll try to explain what happen, because it might be a nasty/not > that > nasty bug. > > I had a ListComposableModel and some very simple code like: > aListComposableModel whenListChanged: [ :aList | > aListComposableModel setSelectedItem: aList first ]. > > From time to time this code seem to randomly fail because the > selection > wasn't set. > I manage to reduce the error to the following equivalent code: > aListComposableModel whenListChanged: [ :aList | > aList = aListComposableModel listItems ]. > > What happen was that sometimes the list held by the model was the > previous list and not the new list, > which was actually correctly passes to the block. > > This seem to be caused by the way ListComposableModel uses > announcers to > update its internal state. > In ListComposableModel>>__registerEvents there is the code: > listHolder > whenChangedDo: [ self refreshListItems ]. > > This registers an announcement that should clear the cache: > ListComposableModel >>refreshListItems > listItemsCache := nil. > ^ self changed: #listElementAt: > > In my code by using 'aListComposableModel whenListChanged:' I also > register an event that should be executed > when the elements of the list change. > > So by now the listHolder containing the elements of the list has two > registered events. > The problem is that in order for this to work correctly they have to > execute in the order they > were added: first invalidate the cache, then the other events > registered > by the user. > However I do not think that announcers guarantee this. So from > time to > time they > execute in the wrong way. This means that the code in the > whenListChanged: block will > execute in a state in which internaly aListComposableModel still > contains the previous list. > > Does this make sense? > > > Yes. It would mean the two announcers are kept in a Set... Maybe > having private and public events would be the way to go ? A private > one for clearing the cache and public ones, triggered after, for the > whenListChanged: block ? > > It would be nice to have a test case checking that. I'd be > interested to know this can happen with announcements. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Camillo Bruni

> Camillo the Zen Master ! I'm not gonna earn points for that. My outburst of fury about this very topic yesterday burned all the zen there was :(

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Sven Van Caekenberghe

On 05 Feb 2013, at 13:13, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-05, at 13:05, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 5 February 2013 12:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> On 2013-02-05, at 12:52, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 4 February 2013 19:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Igor >>>>> >>>>> I think that camillo made this because NativeBoost is an essential part of our infrastructure >>>>> and this is good to know that it is working. >>>>> So I think that we should thank camillo for the time he spent on that. >>>>> >>>> >>>> It is pretty useless right now. If it would run on all platforms, it >>>> would worth having. >>> >>> then add slaves.... you strike me with laziness again! >>> >> i would.. if i would remember that this job exists, and if you would >> spend some moments >> explaining why _you_ need it so badly, since you set it up. Because >> running tests takes like 5 seconds, >> and i doing it before comitting code, and feel pretty fine with it. > > Ask yourself: > - why do we have tests? > - why do multiple people work together? > - why do we want publicly available artifacts? > - why do we want these artifacts tested publicly? > - why do we write configurations? > - why do we try to following coding standards? > - why do we program in Smalltalk? > - why do we mostly write deterministic code? > - why do we work on Pharo? > - why do we build a jenkins infrastructure? > - why do we write down documentation? > > > After successfully answering these questions you will understand! Camillo the Zen Master ! The point of the infrastructure is: you write code in one specific 2.0 image on your mac, the CI infrastructure makes sure you didn't break stuff on other platforms, other/older pharo versions, all automatically. Of course, you need lots of stuff for that, but creating one build job is the first step. Sven

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Frank Shearar

On 5 February 2013 12:13, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-05, at 13:05, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 5 February 2013 12:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> On 2013-02-05, at 12:52, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 4 February 2013 19:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Igor >>>>> >>>>> I think that camillo made this because NativeBoost is an essential part of our infrastructure >>>>> and this is good to know that it is working. >>>>> So I think that we should thank camillo for the time he spent on that. >>>>> >>>> >>>> It is pretty useless right now. If it would run on all platforms, it >>>> would worth having. >>> >>> then add slaves.... you strike me with laziness again! >>> >> i would.. if i would remember that this job exists, and if you would >> spend some moments >> explaining why _you_ need it so badly, since you set it up. Because >> running tests takes like 5 seconds, >> and i doing it before comitting code, and feel pretty fine with it. Of course you mean "I run my tests before committing my code to a branch, so that someone else can review the code and merge it into master." And then the answer's obvious: the reviewer rejects your code until it passes all tests in a CI environment. Running the tests in CI makes the reviewer's job easier. frank

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Camillo Bruni

On 2013-02-05, at 13:05, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 February 2013 12:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2013-02-05, at 12:52, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 4 February 2013 19:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Igor >>>> >>>> I think that camillo made this because NativeBoost is an essential part of our infrastructure >>>> and this is good to know that it is working. >>>> So I think that we should thank camillo for the time he spent on that. >>>> >>> >>> It is pretty useless right now. If it would run on all platforms, it >>> would worth having. >> >> then add slaves.... you strike me with laziness again! >> > i would.. if i would remember that this job exists, and if you would > spend some moments > explaining why _you_ need it so badly, since you set it up. Because > running tests takes like 5 seconds, > and i doing it before comitting code, and feel pretty fine with it. Ask yourself: - why do we have tests? - why do multiple people work together? - why do we want publicly available artifacts? - why do we want these artifacts tested publicly? - why do we write configurations? - why do we try to following coding standards? - why do we program in Smalltalk? - why do we mostly write deterministic code? - why do we work on Pharo? - why do we build a jenkins infrastructure? - why do we write down documentation? After successfully answering these questions you will understand!

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Igor Stasenko

On 5 February 2013 12:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-05, at 12:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 4 February 2013 19:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Igor >>> >>> I think that camillo made this because NativeBoost is an essential part of our infrastructure >>> and this is good to know that it is working. >>> So I think that we should thank camillo for the time he spent on that. >>> >> >> It is pretty useless right now. If it would run on all platforms, it >> would worth having. > > then add slaves.... you strike me with laziness again! > i would.. if i would remember that this job exists, and if you would spend some moments explaining why _you_ need it so badly, since you set it up. Because running tests takes like 5 seconds, and i doing it before comitting code, and feel pretty fine with it. >> But in current state, It feels like extra micromanagement to me. -- Best regards, Igor Stasenko.

Feb. 5, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by Camillo Bruni

On 2013-02-05, at 12:54, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-05, at 12:52, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 4 February 2013 19:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Igor >>> >>> I think that camillo made this because NativeBoost is an essential part of our infrastructure >>> and this is good to know that it is working. >>> So I think that we should thank camillo for the time he spent on that. >>> >> >> It is pretty useless right now. If it would run on all platforms, it >> would worth having. Adding a windows slaves is easy, just couple of clicks in the ci amanagement panel: https://ci.inria.fr/projects/rmod/show#slaves the macs are on the way (currently being bought and in while available with full virtualization). Until then we have to use our mac slave, you can simply copy the slave configuration from the pharo jenkins...

Feb. 5, 2013