- Pharo-dev - lists.pharo.org

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

by Marcus Denker

On Feb 5, 2013, at 1:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 ? > No, it gets an error and claims that they are not there yet they are. Marcus

Feb. 5, 2013

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

by Igor Stasenko

On 5 February 2013 13:13, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > 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! Of course you right. But i am not arguing about that. Can't you understand? If you took initiative about something, don't expect that others will work in same pace as you or automatically/immediately pick up everything you did and integrate it into their working cycle. It takes time and effort (both mental and physical). Ask yourself: - who, except original author knows best how things work? - when you creating a new artefacts, like a bunch of bash scripts for jenkins. Who, you think, should take responsibility about them by _default_? - when you reconfiguring stuff and doing it completely different than it was done before, why you think that rest of the world should immediately jump in and start using it? - and finally, when you creating/releasing new stuff every other day.. how many people is capable of keeping clear track of what you are doing over months (+ doing own tasks)? -- Best regards, Igor Stasenko.

Feb. 5, 2013

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