May 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] What i would like to have instead of progress bar

by Igor Stasenko

If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) how the indication of a progress of some process should look like, here's my potential answer: - a tiny one line in a corner of desktop (instead of huge banner centered in window, sticking on top of everything and obscuring the view) - not blocking user input - no stupid nesting.. i don't care what happens inside of something else happens.. if it is really necessary, i would just replace the title of a task with it's subtask title while it performing. this is just about first rule: it has to be a single line, not a bunch of lines stocking one over another.. i think this is abuse. most of the times, i just need a notion of progress of a whole thing, not progress of it's subthings (if user really wants, he can hover the mouse over progress line to see the details, but by default it should take minimal space on the screen). -- Best regards, Igor Stasenko.

May 31, 2012

Re: [Pharo-project] about cursor: an interesting blog post

by Igor Stasenko

I am completely agree with this post. A showWhile: pattern takes its roots from modal processing, when user is blocked and have to wait till something will give control back to him. This is inacceptable and should be exterminated. It was excusable for 80's , partly excusable in 90's .. and completely inexcusable past 0's. A progress bar is another abomination of same kind. Look at download bars in your internet browser: do they center it in a window on top of everything and preventing you from doing anything? or maybe they just sit in the corner and not interfere? This is a road where we should put our steps on. We should remember once and for eternity: staying responsible to user input is most important task for a system. The rest doesn't matters. On 31 May 2012 21:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&… -- Best regards, Igor Stasenko.

May 31, 2012

Re: [Pharo-project] Question about Athens...

by Igor Stasenko

On 1 June 2012 01:00, Lawson English <lenglish5(a)cox.net> wrote: > Has anyone looked at the design and capabilities of QuickDraw GX? > No. Quickly reading wiki article, it looks quite similar to what i doing in athens. But why asking? Athens goals was never been to open a new era in computer graphics.. We just want to provide similar to what is available and used in other environments for years. > > L > > -- > Squeak from the very start (introduction to Squeak and Pharo Smalltalk for > the (almost) complete and compleate beginner). > https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all > > -- Best regards, Igor Stasenko.

May 31, 2012

Re: [Pharo-project] Nested progress bars

by Martin Dias

On Tue, May 8, 2012 at 2:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi martin > > can you open a bug entry? Okay, sorry for the delay. I opened two issues, 6004 and 6005. MartÃn

May 31, 2012

[Pharo-project] Question about Athens...

by Lawson English

Has anyone looked at the design and capabilities of QuickDraw GX? L -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

May 31, 2012

Re: [Pharo-project] Pharocasts ... updating and screencasts wanted

by Sean P. DeNigris

Fernando olivero-2 wrote > > the release of Gaucho... [will be a]round next week. > Did I interpret that hint correctly?!?! -- View this message in context: http://forum.world.st/Pharocasts-updating-and-screencasts-wanted-tp4632623p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 31, 2012

Re: [Pharo-project] Zinc/Zodiac Documentation

by Mark Smith

On 30 May 2012, at 18:06, Sean P. DeNigris wrote: > > Sven Van Caekenberghe wrote >> >> Now that I have recovered from the intensive Pharo Conference, I found the >> time to publish the Zinc and Zodiac documentation. >> ... >> http://zn.stfx.eu/zn/zinc-http-components-paper.html >> http://zdc.stfx.eu/zodiac-paper.html >> > > Wow, really clear and thorough. The way the raw internet protocols are woven > into the examples is really cool (I always have to be reminded that there's > no magic, just binary turtles all the way down)... And I found > numberOfRetries:, retryDelay:, contentReader:, and #enforceHttpSuccess: > particularly useful in simplifying my code > > A few thoughts: > * ZnClient>>retryDelay: > - it'd be nice if it took aDuration. If I was reading someone else's code, > "client retryDelay: 30" forces me to find the method, but "client > retryDelay: 30 seconds" is clear > - I think it should return self, like enforceHttpSuccess:. Besides > consistency, it will avoid having to send #yourself when configuring a new > client instance. > * JSJsonParser - where does this class live? A reference would be greatâ¦ Hi Sean, I don't know if this is the done thing but I've extracted JSJsonParser from Javascript-Core and removed the dependencies on Seaside and Grease so it loads cleanly into Pharo 1.4 and Pharo 2.0a (and probably 1.3 etc). I'm also planning to write some tests for it but haven't yet. If there's any interest I'd happily push this somewhere :). All the best, Mark > * FileSystem - I remember you mentioned having a problem with FS. Has this > been solved? There is a slice in the inbox which replaces all uases of > FileDirectory and friends with FS. Also, how will this effect portability > (e.g. to Squeak). If you make Zn depend on FS, is the Pharo (renamed > classes) version of FS loadable in Squeak trunk? > * [up/down]load convenience methods - What do you think about adding e.g. > ZnEasy>>download:to: & upload:to: (is POST a good default?) > > -- > View this message in context: http://forum.world.st/Zinc-Zodiac-Documentation-tp4632114p4632508.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 31, 2012

[Pharo-project] about cursor: an interesting blog post

by StÃ©phane Ducasse

http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&…

May 31, 2012

Re: [Pharo-project] Log framework

by Santiago Bragagnolo

2012/5/31 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Thu, May 31, 2012 at 11:50 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> On Thu, May 31, 2012 at 9:21 AM, Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com> wrote: >> >>> Hi again >>> >>> Im already add several classes to the logger. >>> >>> http://ss3.gemstone.com/ss/PaulLePulp >>> >>> the way to use it still primitive, but is a nice draft. >>> >>> >>> If you look at LogConfiguration configuration (class method) you'll find >>> something like this >>> >>> >>> self for:[ :builder | >>> builder forClass:LogTestObject >>> useLevel:#info >>> showingLogAs: ('[%pid | %tstmp | %tag] #%class >> >>> %selector' asPatternFormatter) >>> >> >> > what do you mean by PID? Smalltalk processes do not have a PID. You could > use identityHash but it could not even be unique. > or is it the PID of the process running the VM? > > *Yeah, is the Process identityHash! I called pid cause i get the logic from Zn logger. (as even the file writer and the stdout writter :) ). Must i call it PIH? Can i get the PID? is needed the pid in a log?* > >> >> then, with LogTestObject, if you send it "error", "warn" or "info", all >>> you send there (blocks, strings, symbols or what-understand-value) will be >>> showed at Transcript. (im didnt test on file or stdout yet) >>> >> > would be awesome to have the possibility to log into stdout also. > > > > -- > Mariano > http://marianopeck.wordpress.com > >

May 31, 2012

Re: [Pharo-project] Log framework

by Santiago Bragagnolo

2012/5/31 Guillermo Polito <guillermopolito(a)gmail.com> > On Thu, May 31, 2012 at 9:21 AM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Hi again >> >> Im already add several classes to the logger. >> >> http://ss3.gemstone.com/ss/PaulLePulp >> >> the way to use it still primitive, but is a nice draft. >> >> >> If you look at LogConfiguration configuration (class method) you'll find >> something like this >> >> >> self for:[ :builder | >> builder forClass:LogTestObject >> useLevel:#info >> showingLogAs: ('[%pid | %tstmp | %tag] #%class >> >> %selector' asPatternFormatter) >> > > nice :) > > into: Transcript asLogWriter >> > > What if you want to configure multiple destinies? :D > > * great idea, i just thogh about classes, packages and defaults. I'll > add a class enumeration and a regular expression. (wait, finally it could > be just regular expressions :3, with defaults)* > > > >> retain:true. >> >> builder forKey:'default' useLevel:#error. >> ] >> > > What about moving the configuration elsewhere? :) Having to change the > #configuration method every time is a pain in the ass. > * yes yes, i know, its there cause i didnt think any better place :(. Im all ears. * >> then, with LogTestObject, if you send it "error", "warn" or "info", all >> you send there (blocks, strings, symbols or what-understand-value) will be >> showed at Transcript. (im didnt test on file or stdout yet) >> >> Finally retain:true adds the log to LogHolder, which responds to >> LogHolder instance select:[ :log | log whatYouWantToTest ]. >> > > didn't get this #retain: part. Maybe I should have a look at the code. > * The retain is a flag that say 'hey! i want that logObject to work with it later' then, it's stored on LogHolder instance collection. I'll refact later the mechanism to make a writer strategy of that LogHolder, but i need to extend my writers to a composite solution first, and think a cool way to compose them at configuration ( im all ears here too)* > >> Ill be testing tomorrow and fixing, but, if you want to see and advise >> me, you are welcome :) >> > > And now you have another thing to post on your blog :3. > * Yeah :D * > > >> >> Ok, is 4am, im going to sleep >> >> >> >> >> 2012/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> I would like a logging mechanism that manipulate objects that then are >>> printed in various format. >>> The compiler could use such logger >>> >>> I did not look at the code of toothpick probably extending LoggingEvent >>> should do it. >>> >>> Stef >>> >>> >>> On May 30, 2012, at 3:41 PM, Santiago Bragagnolo wrote: >>> >>> > Ok, i'll take what i need from the marianito's and zn and fork them in >>> an other package, add what i need for massive loggin (like levels of >>> loggin) and make a log-framework. >>> > >>> > Any names? clairvoyant :3? >>> > >>> > Then, is any easy aspect fwk that could i use for the logger? >>> (sometimes i need just trace runtime, or i dont want to add a log line one >>> by one) that works in pharo 2.0 ? :P? >>> > >>> > >>> > 2012/5/30 Sven Van Caekenberghe <sven(a)beta9.be> >>> > >>> > On 30 May 2012, at 01:56, Santiago Bragagnolo wrote: >>> > >>> > > Im looking for a log framework with configurable levels. Theres any >>> stable and useful? I browsed the list and didn't find nothing but >>> something like 'every body has its own logging framework'. >>> > > >>> > > I wrote a small logging fwk for my project, but if is any more >>> complete, it would be great. >>> > >>> > There is one logging framework already in your image: >>> Zinc-HTTP-Logging. >>> > It is based on Announcments. Although it is part of Zn, it is general >>> purpose. >>> > What is special is that it logs the process ID as well, which is >>> useful to debug multiprocess applications. >>> > See the Zn documentation for more info. >>> > >>> > Sven >>> > >>> > >>> > >>> >>> >>> >> >

May 31, 2012