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

Re: [Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

by Alexandre Bergel

> pd: Alex, SMx is SimpleMorph, an older version of the cleaned up > Morphic from the CUIS image. Ok, thanks Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 6, 2011

Re: [Pharo-project] Transcript rant

by Igor Stasenko

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 6, 2011

[Pharo-project] Decode url form with Zinc-HTTP

by HernÃ¡n Morales Durand

Hi Sven, In WebUtils one can decode an URL this way ( WebUtils decodeUrlEncodedForm: 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' ) keys anyOne resulting in 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=nuccore&term=s…' In Zinc-HTTP I didn't find a method for decoding an encoded HTTP address: ( ZnUrl fromString: 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' ) .... ? but there is #unescapePercents in Network package (by the way if it's the opposite of #encodeForHTTP shouldn't be #decodeFromHTTP ?) 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' unescapePercents 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=nuccore&term=s…' but I want to maximize package dependency and not system dependency. Is there a way to decode url's in Zinc-HTTP without use #unescapePercents ? Cheers, -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

April 6, 2011

Re: [Pharo-project] Actions done in 1.3

by Eliot Miranda

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. 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 6, 2011

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

by Tudor Girba

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 6, 2011

[Pharo-project] Issue 3967 in pharo: Announcement enhancement

by pharo＠googlecode.com

Status: Accepted Owner: stephane...(a)gmail.com New issue 3967 by stephane...(a)gmail.com: Announcement enhancement http://code.google.com/p/pharo/issues/detail?id=3967 Both solutions lead to remaining subscribers being notified when an error occurs. So which is decided upon, depends on which of their respective benefits are valued more. For that, it'd be nice if more than 2 people chimed in on. :) Short summary (not guaranteed to be 100% objective) Curtailing -> - Your image may crash in some cases, more specifically if you: 1) have errors in subscribers to announcements made in system-critical processes, as they will be suspended while debugging. 2) deliver announcements in a separate thread from where they're announced, and the announcing thread does so regularily. + Easy to debug. Entire call-chain available, no modification to state caused by subsequent subscribers. Restart should always lead in bug being reproduceable. The remove-from-subscriptions part of Error-handling and ifCurtailed could be combined as well, in which case #2 no longer applies. Error handling -> - Hard/impossible to debug because: 1) If your error was in ordering, debugger will step through flawlessly if restarted. 2) You start at the context of the subscriptions action, no idea where it came from. + More robust, none of the cases mentioned in Curtailing will crash your image. With the different pros/cons mentioned above in mind, here are .cs with example implementations for what both Igor / I would like. (minus remove-from-subscriptions for ifCurtailed: ) Attachments: AnnouncementErrorHandling.zip 1.7 KB

April 6, 2011

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

by Nicolas Petton

Le mercredi 06 avril 2011 Ã 20:30 +0200, Noury Bouraqadi a Ã©crit : > Cool! I guess you didn't you use JTalkST (too young), did you? No, it's too young to be used in real world apps. Maybe in the future ;) cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr

April 6, 2011

Re: [Pharo-project] Import Package from VW to Pharo

by StÃ©phane Ducasse

Hi glenn What were your problems exactly? We port regularly code from VW for Moose. Now soemtimes we need some manual tweaking. Did you check the mailing-list because this topic was raised recently? Stef > I have a package in VW7.6 that I want to move to Pharo (Windows 7). I tried Fileout30 but could not get it to work. I was thinking of reading the .PST file using the XML parser and then programmatically add classes and methods to Pharo. I've looked at various classes related to Class and am having difficulty getting started. Can anyone provide some pointers? > > Regards, > Glenn

April 6, 2011

Re: [Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

by StÃ©phane Ducasse

Thanks fernando! this is cool to see some work on this front. We should work step by step. What I wanted to say is that while I value some part of CUIS. Other parts are still old and odd like its ancestor. Pharo is moving on a lot of front and people may not notice it but soon we will have a lot of pieces of the puzzle ready to get real benefit of the infrastructure we are steadily building :). Stef > Thanks Ben and Stef, the answer was in concordance with what i was thinking. > > CUIS already has the TextModel class, and the PluggableTextModel > class. So together with the menu pragma builders of Pharo, they > provide the foundations for the implementation you just nicely > explained. > > Next week, once i finish writing something for my research, i will > finish the initial port. And hopefully provide a working example of > SMx in Pharo, applying the ideas here discussed. A somehow initial > port, which can get expanded gradually, from the list of widgets we > mentioned in previous emails: MorphTreeMorph, etc.. > (and at a final stage Polymorph). > > Fernando > pd: Alex, SMx is SimpleMorph, an older version of the cleaned up > Morphic from the CUIS image. > > > On Wed, Apr 6, 2011 at 6:19 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> YES!YES!YES! >> It is cool to see your impact on them. Excellent it will really helps >> bringing pharo IDE to the next level. >> >> Stef >> >> On Apr 6, 2011, at 2:11 PM, Igor Stasenko wrote: >> >>> On 6 April 2011 13:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Because once people are dependent and drug addict then they will spend time fixing it :) >>>> >>>> No seriously this is mega hyper hyper important that we get >>>> - solid scalable listMorph and treeMorph >>>> So the best way is to stress it. >>>> >>>> The second answer is that nautilus is cool and needs tree :) >>>> >>> i second that. >>> trees and lists are basic widgets which could be used for different means. >>> So why we should limit ourselves and use some crappy lists to mimic >>> tree, instead of using trees, and improving this widget and making it >>> work well. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >

April 6, 2011

Re: [Pharo-project] Metacello chapter

by StÃ©phane Ducasse

> Cool. BTW, I have a pending pull request on the Socket chapter. what is it? what do you mean? what do you need? Stef

April 6, 2011