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

Re: [Pharo-project] [ANN] Pharo 1.2.1. Setup for Win32 (including CogVM)

by Marcus Denker

On Apr 6, 2011, at 7:02 PM, HernÃ¡n Morales Durand wrote: > Hi, > > Installing O2 gives me a MNU, I've evaluated: > > "- If you want to use another System Browser than the default > (OmniBrowser), you can install O2 browser: " > > Gofer new > squeaksource: 'MetacelloRepository'; > package:'ConfigurationOfO2'; > load. > > ((Smalltalk at: #ConfigurationOfO2) project version: '1.2') load: 'Dev'. > > bug report attached. > It's noted to be fixed for 1.2.2: http://code.google.com/p/pharo/issues/detail?id=3831 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 7, 2011

[Pharo-project] Issue 3968 in pharo: ByteArray>>#asInteger

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3968 by sven.van...(a)gmail.com: ByteArray>>#asInteger http://code.google.com/p/pharo/issues/detail?id=3968 Pharo 1.2.1 (proposal for 1.3) Since the methods #asByteArray and #asByteArrayOfSize: (part of System-Hashing-Core) exist, it would be logical that the inverse exists as well: ByteArray>>#asInteger | integer | integer := 0. self withIndexDo: [ :each :index | integer := integer + (each bitShift: (bytes size - index) * 8) ]. ^ integer Granted, these methods pick the most common ordering (network byte order, most significant byte first, big endian). We should note that in the comments. Adding endianness as a parameter would unnecessarily complicate the interface. Maybe a littleEndian variant could be provided (#asIntegerLittleEndian, #asByteArrayLittleEndian, #asByteArrayLittleEndianOfSize:) ? I've written this already in two projects, anybody else thinks this would be handy ? Sven

April 7, 2011

Re: [Pharo-project] Transcript rant

by Fernando Olivero

I propose some modifications to the Transcript as a (singleton) class, and revert to the use of TranscriptModel. See the latest post on 3948: Transcript and ThreadedTranscript needs to be merged. Fernando On Wed, Apr 6, 2011 at 10:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 April 2011 20:24, Â <csrabak(a)bol.com.br> wrote: >> Em 06/04/2011 09:07, Igor Stasenko <siguctua(a)gmail.com> escreveu: >>> > On 6 April 2011 13:54, Fernando Olivero <fernando.olivero(a)usi.ch> >> Â Â wrote: >> >>> > Hi Stef, i will as an initial step take Igor's suggestion and make >>> > Transcript a global wich Â points to an instance of TranscriptModel >>> > ( the new name i propose for the current class taken from CUIS). >>> > I still Â believe that composition Â is better then Â inheritance for >>> > handling different behaviors of the Transcript, so i argue against >>> > making it a subclass of WriteStream and making it polymorphic with >>> > a write stream instead. >>> > >>> Â That's totally Â not my concern. As Â long as thing Â which sits there >>> Â responds to writestream protocol , i don't care about rest. >>> >> >> Would it make sense then to lift the methods from {write}stream and >> put then in a Trait so the composition is made through reuse of code? >> >> My 0.0199999.... > > hehe.. yes, but if to follow this road every time you need to do small > improvement, > then at some day you will discover that you rewriting whole system > from scratch :) > >> >> -- >> Cesar Rabak > > > -- > Best regards, > Igor Stasenko AKA sig. > >

April 7, 2011

Re: [Pharo-project] Issue 3948 in pharo: Transcript and ThreadedTranscript needs to be merged

by pharo＠googlecode.com

Comment #2 on issue 3948 by fernando...(a)gmail.com: Transcript and ThreadedTranscript needs to be merged http://code.google.com/p/pharo/issues/detail?id=3948 I've replaced the Transcript class with an equal TranscriptModel instance, reverting to the use of a global Transcript, according to Igors suggestion. I also modified a bit the TranscriptMorph, to denote the read-only nature of the text. (Igor suggested to be able to select the text as well, not yet there); and changed all the uses ( in Core) to go through StandardToolSet openTranscript. First load the changeset, then evaluate the contents of the saved workspace. Attachments: TranscriptModelLoad.1.cs 14.0 KB TranscriptPostLoad.ws 404 bytes

April 7, 2011

Re: [Pharo-project] Actions done in 1.3

by Marcus Denker

On Apr 7, 2011, at 9:17 AM, StÃ©phane Ducasse wrote: > I do not have specific stance on that this is why I hear both arguments. > > Now agility is not something that we claim but that we do. > I think that not having releases that drag on forever is important. > I prefer to have > - 3/4 releases full of energy that are time based vs. 2 that are slugglish and ends up in few fixes over a long period. > - this would avoid to have an accumulation of code to integrate and laucnh beta too early to reduce the pressure. > - In addition since people do not understand what is a release candidate, then having more frequent release would mean > that people port more often if they want. > So we will see. For now the good point is that we can release 1.3 tomorrow and this will not be a release maintenance because > lot of changes are already done. > The next steps are: -> go over the bug tracker and tag as 1.3 just the real important entries -> Fix the easy to fix failing tests (just 25 to go) -> Do another iteration on the build server for complete auto-build to the artififact we ship. and: -> Do another iteration on Cog builds so we can move to Cog only. I want a 1.3 that is in "we could release today if we wanted" 90% of the time. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 7, 2011

Re: [Pharo-project] SmalltalkHub going beta in a week

by Nicolas Petton

Le mercredi 06 avril 2011 Ã 19:38 -0700, Randal L. Schwartz a Ã©crit : > >>>>> "Serge" == Serge Stinckwich <serge.stinckwich(a)gmail.com> writes: > > Serge> Yes, but this SmalltalkHub not PharoHub ;-) > > Oh, did I miss the parallel announcement on squeak-dev? Sorry. Hi Randal, You should blame me for that. Cheers, Nicolas -- Nicolas Petton http://www.nicolas-petton.fr

April 7, 2011

Re: [Pharo-project] On fixed release planning [was: Actions done in 1.3]

by StÃ©phane Ducasse

On Apr 7, 2011, at 8:21 AM, laurent laffont wrote: > > On Wed, Apr 6, 2011 at 10:32 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Planning is also important. > > Time is good, but another thing is i think we should think about, > what features we want to be in new release, and do not release until > they delivered. > > I don't really like this. I prefer rhythm, agility. Timeboxing enables maximum value in each release. If a feature is really important, it will be on time. If not on time, it means it was no so important. > > I couldn't disagree more. Especially with VisualWorks time-boxing has caused problems with quality and delivery of functionality. Fundamentally there is no point putting out a release for the sake of it. A release is about functionality, both new functionality and bug fixes. Without either of these there is absolutely no point in releasing anything beyond marketing. Yes, during a release one can make the call that because a subset of the functionality will arrive much later than the rest of the functionality it makes sense for that late functionality to slip the release and arrive in a later one. But that doesn't imply putting out an essentially empty release for the sake of promptness. > > > Let me talk about my experience. Quality may suffer with timeboxing without continuous integration and good test coverage. > > CI + tests enable timeboxing because I can maintain high quality level. And now we have CI it's wonderful. > > As a user, I like software developed with fixed iterations because I know exactly when it wil be released, plan upgrades and validations. I'm easily in sync. > > As a developer I like fixed iterations because > 1/ We care more about quality. Cannot develop all this feature in the iteration ? do only a part and check that it works well - write missing tests. Not enough time left to integrate this feature ? Just work on the many details that we need to fix and integrate the new feature soon in next iteration. this is exactly what is happening with the introduction of RPackage :) > > 2/ We maintain energy. No long waiting period of stuff xxxx to be done without realeasing. The more we wait, the less productive we are. > > 3/ I like to change the planning from "what features this version can't be released without ?" to "what can we develop in 1 / 3 / 6 months (with high quality) ?". > > 4/ ok I stop here. > > Even every day at work I'm timeboxing with 25mn iterations (Pomodoro technique) for several years - I cannot live without now. That makes me deliver a lot of energy. > > > I've never seen empty release because of fixed iterations. And even if the release contains only fixed bugs, details adjustment and no new big feature it's great. Details matters a lot. > > In a former job my team was doing a new features iteration, then a "care about details iteration", then a new features iteration, and so on.... it was a lot of fun and worked. > > Indeed I would like try and see if it works with Pharo. I also would like Pharo to be a reference of modern agile development - that would be a step forward. > > > Laurent. > > > One thing I do approve of is maintennance releases, where some time after an initial release one puts out a maintennance release that only contains bug fixes and no new functionality and I think there are good arguments for and positive experience with scheduling the maintennance release to arrive at some fixed time after the first release, e.g. 4 to 6 months. But major releases must IMO be driven by content. > > best > Eliot > > > Always green test is a must-have. > > > Besides bug fixing and minor improvements, there should be some > functionality which we want to have in new release, > > That should be a goal, but don't delay a release because the feature is not here. If releases are often ( for example every 3 months), shorter, it won't be a big problem to wait for the next one. > > I prefer to have a release *now* without my feature and wait 3 months for the next release than no release and waiting for 3 months more with less and less energy. > > > Laurent. > > so then you could say: 1.x is better than previous because of A,B,C, > but not because a,b,c ( capital letters is major stuff, while regular > ones is for minor stuff ) :) > > > On 6 April 2011 10:01, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont > > <laurent.laffont(a)gmail.com> wrote: > >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >>> > >>> Yes!!! totally agree. Now that we release 1.2, I would freeze and release > >>> PharoCore 1.3 beta. Update the link to stable pharo to that, and start > >>> trying to load the dev tools there. > >> > >> +10 > >> And propose a fixed date for release - no compromise, will be release at > >> this date. > > > > +1 > > Timeboxing sounds great. > > Podomoro for software development ;-) > > > > Regards, > > -- > > Serge Stinckwich > > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > > Every DSL ends up being Smalltalk > > http://doesnotunderstand.org/ > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > >

April 7, 2011

Re: [Pharo-project] Metacello chapter

by StÃ©phane Ducasse

and so what? I still do not understand it. may be noury should be added to the project. On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote: > https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3 > > On Thu, Apr 7, 2011 at 3:10 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>> Cool. BTW, I have a pending pull request on the Socket chapter. >> >> what is it? >> what do you mean? >> what do you need? >> >> Stef >> >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/

April 7, 2011

Re: [Pharo-project] Actions done in 1.3

by StÃ©phane Ducasse

I do not have specific stance on that this is why I hear both arguments. Now agility is not something that we claim but that we do. I think that not having releases that drag on forever is important. I prefer to have - 3/4 releases full of energy that are time based vs. 2 that are slugglish and ends up in few fixes over a long period. - this would avoid to have an accumulation of code to integrate and laucnh beta too early to reduce the pressure. - In addition since people do not understand what is a release candidate, then having more frequent release would mean that people port more often if they want. So we will see. For now the good point is that we can release 1.3 tomorrow and this will not be a release maintenance because lot of changes are already done. Stef On Apr 6, 2011, at 11:40 PM, Eliot Miranda wrote: > > > On Wed, Apr 6, 2011 at 1:52 PM, Casimiro de Almeida Barreto <casimiro.barreto(a)gmail.com> wrote: > Em 06-04-2011 17:32, Eliot Miranda escreveu: >> >> >> >> (...) >> >> >> I couldn't disagree more. Especially with VisualWorks time-boxing has caused problems with quality and delivery of functionality. Fundamentally there is no point putting out a release for the sake of it. A release is about functionality, both new functionality and bug fixes. Without either of these there is absolutely no point in releasing anything beyond marketing. Yes, during a release one can make the call that because a subset of the functionality will arrive much later than the rest of the functionality it makes sense for that late functionality to slip the release and arrive in a later one. But that doesn't imply putting out an essentially empty release for the sake of promptness. > +1 Here > >> >> One thing I do approve of is maintennance releases, where some time after an initial release one puts out a maintennance release that only contains bug fixes and no new functionality and I think there are good arguments for and positive experience with scheduling the maintennance release to arrive at some fixed time after the first release, e.g. 4 to 6 months. But major releases must IMO be driven by content. > +1 Here but... > > I think that maintenance releases must be presented in the form of "software updates" (meaning, no need to install a new image & reinstall everything in it). Ideally it should be possible to upgrade fixes without breaking what's working. > > Agreed. What I said about maintennance releases was rather 20th century of me. Forget I ever mentioned it :) > >> >> best >> Eliot >> >> (...) >> > Best regards, > > CdAB >

April 7, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by StÃ©phane Ducasse

Indeed this is really important to improve key infrastructure widgets. They are enablers of the future. This is why SM and polymorph are important. Stef On Apr 6, 2011, at 10:30 PM, Tudor Girba wrote: > Excellent job :). And very highly appreciated. > > Cheers, > Doru > > > On 6 Apr 2011, at 22:06, StÃ©phane Ducasse wrote: > >> Good! I'm happy. Igor and Ben are doing a great job. >> >> Stef >> >>> This is great! >>> >>> I tested it on Glamour and it looks pretty cool. And, it is definitely snappier. >>> >>> I tested LazyMorphTreeMorph it on a list with 1 million items in the context of Glamour with a pagination of 50 items I got: >>> - before: 6414 ms >>> - after: 3526 ms >>> >>> The code I used is (works in a Moose image, or after you load Glamour): >>> >>> Time millisecondsToRun: [ >>> | browser | >>> browser := GLMTabulator new. >>> browser column: #one. >>> browser transmit to: #one; andShow: [ :a | >>> a tree >>> tags: [ :each | {each even printString} ]; >>> showOnly: 50 ]. >>> browser openOn: (1 to: 1000000) >>> ] >>> >>> Cheers, >>> Doru >>> >>> >>> On 6 Apr 2011, at 18:01, Igor Stasenko wrote: >>> >>>> okay.. i found one bug >>>> >>>> forgot to add cellPositioning: #leftCenter; for colum wrapper morph >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> <Tree2.3.cs> >>> >>> -- >>> www.tudorgirba.com >>> >>> "What we can governs what we wish." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > >

April 7, 2011