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

Re: [Pharo-project] SSO - CAS Client in Smalltalk ?

by StÃ©phane Ducasse

Hi cedric Let us know because I like to get as protocol and solutions to interact with the world. May be such effort could be supported by esug too. Stef On May 11, 2012, at 2:18 PM, CÃ©drick BÃ©ler wrote: > Hi all, > > I'd like to develop some web apps for our university but one prerequisite is to use the Central Authentication Service [1]. It's an open source authentication service and I wonder if somebody has ever worked with it and if there are any client available. Do you have any experience and/or pointers ? > > If not, I may dog into the protocol and see what I can do. I've spotted PHP implementation and also Ruby [2]. > > I think that could be a nice addition to Zinc even if not as widespread as OAuth/OpenID stuffs. > > TIA > > CÃ©drick > > [1] http://en.wikipedia.org/wiki/Central_Authentication_Service > [2] https://github.com/rubycas/rubycas-client > >

May 12, 2012

Re: [Pharo-project] Short rant on platforms and sessions

by StÃ©phane Ducasse

Thanks for the info. Indeed it is nice. On May 11, 2012, at 2:56 AM, Chris Muller wrote: >> Dolphin shows us the correct path: session awareness. The image "wakes up" >> and decides where it is running - the vm can certainly help in Pharo's >> case. External resources are *not* cleared on image save - the image might >> keep running, so why release and reallocate? Finalization is best-effort. >> External resources are cleared just before exiting, but *after* any >> associated image save. When the image wakes, one of its first duties is to >> clear (not release via calls) any external resources, because they are known >> to be garbage at this point. >> >> It works, and works well. > > I don't have experience with Dolphin, but that does sound like a > clever solution to avoiding the release/reallocate burden on image > save (and not exiting).. >

May 12, 2012

Re: [Pharo-project] [review needed] Do we remove SmartRefStream?

by StÃ©phane Ducasse

On May 11, 2012, at 10:27 AM, Marcus Denker wrote: > > With Fuel, we should take the opportunity to clean up the systm. There are things we need to keep > for a while (DataStream, for example, a it is used by Monticello). > > But what about SmartRefStream? With ImageSegment already gone, does it make sense to keep > it? The code looks horrible. > > One can just remove it and all remaining users like this: > > http://code.google.com/p/pharo/issues/detail?id=5859 > > Can we do that? do we need to formally deprecate it? would be good even if so boringâ¦ :) > > -- > Marcus Denker -- http://marcusdenker.de > >

May 12, 2012

Re: [Pharo-project] DateAndTime hash was: Re: [squeak-dev] true hash

by StÃ©phane Ducasse

On May 11, 2012, at 6:59 AM, Paul DeBruicker wrote: > I made issue 5858: https://code.google.com/p/pharo/issues/detail?id=5858 > > And Nicolas Cellier improved my suggestion as noted in the issue. **Thanks**!!!

May 12, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

got three days meeting this week so crawling to get my brain aligned with fun againâ¦ I will read your article. I will also look at STON because I like the object literal syntax too :). (note that I'm not changing my mind - I still do not get why I need dictionary for method meta data - but we are thinking (and the team should discuss for real and not just during lunches) that having a literal object syntax would be cool). Stef >> I would like to share my quick two cents regarding this subject. >> >> 1st cent. I would stick with JSON. Even though I find STON slick, I would >> not deviate from something that is mainstream and all Smalltalk dialects >> already support. >> >> 2nd cent. A Dictionary literal syntax would be useful too. I would like to >> have it. >> >> It could be something like #{'this' -> 1. 'that' -> 2 }, and keep {1. 2} for >> dynamic arrays. > > I don't want to sound like a broken record - but you do realize that I wrote about this in the article and mentioned this exact syntax? > > I know, the article was a tad long - but just go to planet.smalltalk.org and search down to "Sidestory: Adding literal Dictionaries to Smalltalk?". > > regards, GÃ¶ran >

May 12, 2012

Re: [Pharo-project] We need your successes

by Francisco Garau

If you want a sexy picture... http://sketchfu.com/drawing/3469-sexy-turtle-on-the-prowl :) On 11 May 2012 16:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi everybody > > We really want to build a "vitrine" showroom of Pharo and we would you to > participate. > We want to build a web page with all these successes and show it to the > world. :) > > We would like to get from you a three slides document: > > slide one: > a sexy picture and a teaser / who you are. > > slide two: > what is it how cool is it. > > slide three: > what cool pharo techno you used or developed. > > I did a bad one using DrGeo to give you an idea. > > So can you please send us these three slides. We would like to present > them during the > Pharo conf and after put them on the web. > > Stef and marcus. > >

May 12, 2012

Re: [Pharo-project] on Raspberry Pi

by StÃ©phane Ducasse

On May 10, 2012, at 11:37 AM, Pavel Krivanek wrote: > On Thu, May 10, 2012 at 11:31 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On May 10, 2012, at 11:29 AM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> one my friend got Raspberry Pi yesterday so I have seen it in action. >>> I had almost no time for experiments but I have seen Fedora 17 on it >>> with standard Squeak (3.10) packages for this distro on FullHD >>> display. On that VM (3.10.5) I got about 40M bytecodes/sec and 1M >>> sends/sec. The environment is not extra fast but usable without >>> problems. I will pray for successful GSoC ARM JIT project :-) The >>> device was connected to the professional meter and the power >>> consumption was about 3.5W. >>> >> Very nice! >> >> As soon as we get one we will put it as a build target for Jenkins... >> (sadly even though I got up early that day I am not yet even invited >> to pre-order...). >> >> Marcus > > I will try to borrow it on PharoConf :-) would be nice to have a pic with some pharo logo around. > > -- Pavel > >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >

May 12, 2012

Re: [Pharo-project] [Seaside] Zinc as static file server

by StÃ©phane Ducasse

On May 12, 2012, at 9:52 AM, Sven Van Caekenberghe wrote: > Hi Paul, > > On 12 May 2012, at 02:57, Paul DeBruicker wrote: > >> I added the ability to specify Cache-Control headers for static files served by Zinc and added an API to the ZnZincStaticServerAdaptor that allows you to use the defaults or provide a custom specification. > > Thanks for the contribution (again). I really love to see that happeningâ¦ Continue guys! This is cool. > Yes, this is useful, having an expiration time per mime-type seems a bit heavy, but OK. > > BTW, we (or I) definitively need to add If-Modified-Since and 304 Not Modified behavior to ZnZincStaticServerAdaptor. > > And I know that you know, but let me repeat that in production situations you definitively have to let apache or nginx serve the statis files, to take load of Seaside. > > Your hack in ZnSeasideStaticServerAdaptorDelegate>>#handleRequest: lets Seaside first try and make an error before you consider static file serving, this almost defeats the purpose of not doing it by Seaside itself. Just a hunch, I haven't tested or benchmarked this. > > But I know you want this for easier development setup, and it is instructive code for others as well. > > Thanks again, > > Sven > > > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

May 12, 2012

Re: [Pharo-project] [Seaside] Zinc as static file server

by Sven Van Caekenberghe

Hi Paul, On 12 May 2012, at 02:57, Paul DeBruicker wrote: > I added the ability to specify Cache-Control headers for static files served by Zinc and added an API to the ZnZincStaticServerAdaptor that allows you to use the defaults or provide a custom specification. Thanks for the contribution (again). Yes, this is useful, having an expiration time per mime-type seems a bit heavy, but OK. BTW, we (or I) definitively need to add If-Modified-Since and 304 Not Modified behavior to ZnZincStaticServerAdaptor. And I know that you know, but let me repeat that in production situations you definitively have to let apache or nginx serve the statis files, to take load of Seaside. Your hack in ZnSeasideStaticServerAdaptorDelegate>>#handleRequest: lets Seaside first try and make an error before you consider static file serving, this almost defeats the purpose of not doing it by Seaside itself. Just a hunch, I haven't tested or benchmarked this. But I know you want this for easier development setup, and it is instructive code for others as well. Thanks again, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 12, 2012

Re: [Pharo-project] Parsing HTTP dates

by StÃ©phane Ducasse

+100 > 'It is you Pharo'. > We have to make things better, one little step at a time, for all of us together.

May 12, 2012