- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

HernÃ¡n, >From the class comment of ZnUrl: [...] The methods in accessing protocols do not do any encoding, those in printing do. [...] Taking your example: (ZnUrl fromString: 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') pathSegments an OrderedCollection('entrez' 'eutils' 'esearch.fcgi?db=nuccore&term=science[journal]+AND+breast+cancer+AND+2009[pdat]') (ZnUrl fromString: 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') path 'entrez/eutils/esearch.fcgi?db=nuccore&term=science[journal]+AND+breast+cancer+AND+2009[pdat]' (ZnUrl fromString: 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…') printString 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi%3Fdb%3Dnuccore%26…' If you inspect a ZnUrl instance you will notice that the internal Smalltalk representation is unencoded. But its #printString and the argument to #fromString: are. You could programmatically build up a ZnUrl using accessors and supplying unencoded (path) elements. HTH, Sven On 06 Apr 2011, at 22:38, HernÃ¡n Morales Durand wrote: > 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: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 6, 2011

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

by Igor Stasenko

On 6 April 2011 22:54, Tudor Girba <tudor.girba(a)gmail.com> wrote: > And if we are at it, how would it be possible to get vertical resizers between rows? > between rows.. > For example, in the case of GTCoder, I would like to be able to resize the pane with code inside. > i think you'd better do a little different thing. You can put a resizer 'grip' into a corner of code pane, and then resize code using that grip, and parent morph(s) will(or should) adjust themselves accordingly. For example you can take a look how gmail web interface works: for text areas where i currently typing a message there is a resizer grip, using which i can resize the text pane. But there is no sizers every row which representing a separate mail in this thread. I guess you got an idea. > 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 > > "There are no old things, there are only old ways of looking at them." > > > > > -- Best regards, Igor Stasenko AKA sig.

April 6, 2011

Re: [Pharo-project] Actions done in 1.3

by Igor Stasenko

On 6 April 2011 22:32, 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. > 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. Right. That's exactly what i wanted to say. There's no point to make a release of a 'new version' if it doesn't contains a functionality which were planned to include. Maintenance is sufficient for this. -- Best regards, Igor Stasenko AKA sig.

April 6, 2011

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

by Tudor Girba

And if we are at it, how would it be possible to get vertical resizers between rows? For example, in the case of GTCoder, I would like to be able to resize the pane with code inside. 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 "There are no old things, there are only old ways of looking at them."

April 6, 2011

Re: [Pharo-project] Actions done in 1.3

by Casimiro de Almeida Barreto

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. > > best > Eliot > > > (...) > Best regards, CdAB

April 6, 2011

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