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

Re: [Pharo-project] About the new release process

by Esteban Lorenzano

Hi, On May 14, 2012, at 8:45 PM, Sean P. DeNigris wrote: > > EstebanLM wrote >> >> our new release process... >> two bug fix releases at month 4 and month 8... >> During this year we'll also release bugfix versions of Pharo 1.4. >> > > This is exciting because as soon as a version is released, everyone starts > pounding on it and inevitably finding bugs. It will be nice to have those > fixes go into the current version instead of instantly starting to focus on > the next major version months or a year away. yep... that's the idea... :) > I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How > do we get fixes into the 1.4 bug release versions? If we make a slice off > the 1.4 package, there may be many conflicts merging into 2.0, but if we > merge in the future version, there will be many 2.0-only changes that have > nothing to do with the fix, won't there? What's the protocol? And now that > we're time-based, what's the date for the first bug fix release? relevant issues for 1.4 are tagged now 2.0/1.4... some others just 1.4 (not many). What we considered non-relevant were re-tagged just 2.0... maybe we made a mistake in our review, but we are willing to retag them if someone has other feelings :) now... the slices can be applied in both versions or be version specific... the bugtracker keeps the information needed to the integration. times, times... we still didn't thought on times for versions release for 1.4 because we are still adjusting all to the process... but I think some time on july is good for first 1.4 release and maybe october for lastest... in any case, we are doing regular 1.4 integrations (weekly), that incorporates some bugfixes. best, Esteban

May 15, 2012

Re: [Pharo-project] About the new release process

by Ben Coman

Sean P. DeNigris wrote: > EstebanLM wrote > >> our new release process... >> two bug fix releases at month 4 and month 8... >> During this year we'll also release bugfix versions of Pharo 1.4. >> >> > > This is exciting because as soon as a version is released, everyone starts > pounding on it and inevitably finding bugs. It will be nice to have those > fixes go into the current version instead of instantly starting to focus on > the next major version months or a year away. > > I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How > do we get fixes into the 1.4 bug release versions? If we make a slice off > the 1.4 package, there may be many conflicts merging into 2.0, but if we > merge in the future version, there will be many 2.0-only changes that have > nothing to do with the fix, won't there? What's the protocol? And now that > we're time-based, what's the date for the first bug fix release? > > I have been considering asking similar questions for a while. First, can someone confirm and clarify my understanding of the purpose of the standard repositories... * Pharo14 - Read Only. I see five admins who presumably are the only integrators who can commit to the repository. I assume that at the time Pharo 1.4 was released, the latest versions in this repository exactly matched loaded into the released image. I assume this is now low traffic, but browsing this repository I see some packages have updates. Are these the ones that will form the basis of a Pharo 1.4.1 maintenance release? * PharoInbox - Read/Write. Anyone can submit packages here to await review by testers and integrators. * PharoTreatedInbox - Read Only. Squeaksource says "Repository for packages from the inbox that are either released or reject by the release team" but I am not clear on whether "released" means items accepted into the mainline Pharo14 repository are copied to PharoTreatedInbox as well as going to the Pharo14 repository. * Pharo20 - Read Only. Active HEAD of Pharo development. What I am not clear on is how the integrators know whether a submission to PharoInbox is based off Pharo 1.4 or 2.0. From previous discussions it seems a possibility that due to limited resources a community submission to fix something in 1.4 might just be consumed into the mainline 2.0 and not backported to 1.4. Not withstanding that I understand and support the desire to push forward as fast as possible, as a business user trying to stabilize a deployed product this would be annoying. Note that I am referring here to user community contributions and not how mainline developers choose which version in which to attack ticketed issues. So then, an uncertain proposal... to create a Pharo14MaintInbox repository for contributions submitted from within a Pharo1.4 image. Optionally, any package accepted from Pharo14MaintInbox into Pharo14 could incrementally copied at that time into the mainline 2.0 PharoInbox, so as not to lose any fixes that might carry over to mainline 2.0. Alternatively, this might be done in one go when a tested 1.4.1 maintenance version is released. cheers -ben

May 15, 2012

Re: [Pharo-project] Problem with Zinc?

by Sven Van Caekenberghe

Damien, On 15 May 2012, at 16:42, Damien Cassou wrote: > ZnClient new > systemPolicy; > multiPartFormDataEntity; > http; > host: 'http://code.google.com'; > path: '/p/pharo/issues/entry.do'; > queryAt: 'summary' put: 'A summary text', Date today asString; > queryAt: 'comment' put: 'A short comment'; > post Please try: ZnClient new logToTranscript; http; host: 'code.google.com'; path: '/p/pharo/issues/entry.do'; formAt: 'summary' put: 'A summary text', Date today asString; formAt: 'comment' put: 'A short comment'; post. It still gives a bad request. I suppose you are trying to submit a form, maybe you did not add enough form fields, maybe you need a session id or cookie, or authentication. The hang occured in my 1.4 image as well and is probably related to the 'http://' in the host field and DNS resolving. I can't say for sure, since I couldn't do an interrupt and debug. HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 15, 2012

Re: [Pharo-project] Pharo Kernel 2.0 Reload by Fuel activated

by Mariano Martinez Peck

On Tue, May 15, 2012 at 4:51 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 15/05/12 3:21 AM, Pavel Krivanek wrote: > >> >> The resultant image is not production-ready because Fuel Package >> Loader currently doesn't work with changes file. >> > > What does this mean? Is Fuel Package Loader supposed to append > corresponding source to the changes file, when compiled methods are loaded > via fuel? Shouldn't that be optional? > > Hi. First, let me say that FuelPackageLoader is just a baby borning. Nothing is decied completly yet. So far, the best design we have in mind is: 1) The user can export/import packages without source code. This serialization goes into a file. Say we call it yourPackage.fuel. The application can be run, deployed, and even browse decompiled code. Nothing go to .changes. 2) The user has ANOTHER possibility to ALSO serialize source code. That does not mean just source code but also timestamp, class commetns, etc. Then during import, we should do kind of waht monticello does: include source code in the system (.changes or whatever). This would be in a differnt file (also serialized with fuel, and also being a binary fuel) called it for example, yourPackage.source So you can distribute your app with or without source code. Well, that's the plans at least we have with Martin so far. 1) is working quite well (but still there are work to do). 2) is not even started (and that's why Martin is in GSoC). is this clear? This setup reminds me of .SLL files used in VSE (Visual Smalltalk > Enterprise). You could start with a "frozen" base image, and on startup, > load all your application code through .SLL "library units". (I can't > remember whether or not you could dynamically link/unlink the .SLL > packages; I think you could.) > > I don't know such details but indeed it looks similar. Cheers -- Mariano http://marianopeck.wordpress.com

May 15, 2012

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

by CÃ©drick BÃ©ler

Salut, Le 14 mai 2012 Ã 19:58, Sven Van Caekenberghe a Ã©crit : > Bonjour CÃ©drick, StÃ©pahane, > > On 14 May 2012, at 19:44, CÃ©drick BÃ©ler wrote: > >> I'll let you know. >> >> CAS seems to be kind of standard for high organization SSO. It's just sad I didn't thought of it for Google Summer of Code. This could have been an opportunity. >> There's also ESUG. But maybe others should say of they find such an implementation useful (and not only me :) ). > > Yes, these are interesting add-on projects. The basis (Pharo+Zn+Zdc) is there, I don't think these are major undertakings, but they can get stuck on some small seemingly insurmountable detail. Step 1 is to understand the specification and the foundation to start from. Looking at implementations in other languages helps. Yes, I've had a look at PHP and Ruby ones but I cannot at this moment dig more into it. > > Regards, > > Sven > > PS: CÃ©drick, I remember the OAuth (Dropbox) stuff that you were trying. Any chance to start that again ? ;-) > Uhm, I fear it hasn't moved from what you've seen + what we've lost (squeaksource versions lost). The upload stuff wasn't working if I remember well. I may start again if useful but I cannot at this time + CAS would be my priority now if I could :( <OT - killers apps ?> Just for background, if I experiment that, it's because in our university, they plan to set up a Numeric Environment (ENT in french). Based on uPortal, called E-Sup. I find it sucks :) + it's expensive to deploy and configure (around 30kâ¬ !!!). This is Java ! What's working now is only CAS+LDAP. If I had CAS in Pharo, I could develop applications say in Seaside that could be integrated in this environment. I think something like E-Sup (uPortal) could be a great project in Pharo but... this is a long one. Maybe ESUG ? ObjectFusion ? :-) For management in uni, they use OS app suite called Coktail (Scholarix and friends...) and these tools are developed in web objects (woa), the Apple no more supported framework ! This is also an opportunity to develop applications in Pharo because Coktail seems alone in this field (being open source) </OT> Cheers, CÃ©drick > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > >

May 15, 2012

Re: [Pharo-project] Pharo Kernel 2.0 Reload by Fuel activated

by Yanni Chiu

On 15/05/12 3:21 AM, Pavel Krivanek wrote: > > The resultant image is not production-ready because Fuel Package > Loader currently doesn't work with changes file. What does this mean? Is Fuel Package Loader supposed to append corresponding source to the changes file, when compiled methods are loaded via fuel? Shouldn't that be optional? This setup reminds me of .SLL files used in VSE (Visual Smalltalk Enterprise). You could start with a "frozen" base image, and on startup, load all your application code through .SLL "library units". (I can't remember whether or not you could dynamically link/unlink the .SLL packages; I think you could.)

May 15, 2012

[Pharo-project] Problem with Zinc?

by Damien Cassou

The following always freezess my Pharo 2.0 image: ZnClient new systemPolicy; multiPartFormDataEntity; http; host: 'http://code.google.com'; path: '/p/pharo/issues/entry.do'; queryAt: 'summary' put: 'A summary text', Date today asString; queryAt: 'comment' put: 'A short comment'; post -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 15, 2012

Re: [Pharo-project] OpenID/Oauth library (was SSO - CAS Client in Smalltalk ?)

by Yanni Chiu

On 15/05/12 3:00 AM, Janko MivÅ¡ek wrote: > Dne 15. 05. 2012 00:01, piÅ¡e StÃ©phane Ducasse: > >>> Just FYI, me and Cloudfork guys are just finishing the OpenID 2.0/OAuth >>> 2.0 support for Iliad and Aida, based on Cloudfork SSO [1]. On Pharo and >>> VW. On Pharo Zync with Zodiak SSL is used. Current goal is to develop a >>> Google Docs API support. >> >> Hi janko >> >> is the library available as a library? I mean not linked to aida or iliad? > > Idea actually is to have WebCloudSSO library as independent as possible, > but not without some web server/web framework, because OpenID/OAuth rely > heavily on HTTP redirects. > > WebCloudSSO library currently works on Aida, now I'll start adapting it > to Iliad, later someone can adapt it to Seaside or even to plain web > server like Zync. Maybe it will even come under Cloudfork trademark at > the end, we will see. Cloudfork otherwise already have a Seaside OpenID > example. Have I understood this right? You started with CloudforkSSO, "ported" it to Iliad and Aida (i.e. WebCloudSSO), and in future WebCloudSSO may merge back into CloudforkSSO. Was it just easier/faster to do it this way, rather than split the Seaside dependent parts out of CloudforkSSO? Is there any additional OpenID/OAuth functionality in WebCloudSSO, beyond what was in CloudforkSSO?

May 15, 2012

Re: [Pharo-project] Nautilus small bug? report

by Fabrizio Perin

Here the attachment :) 2012/5/15 Fabrizio Perin <fabrizio.perin(a)gmail.com> > Hi, > I'm using the latest Moose version and I noticed that the classes in the > Nautilus browser are weirdly indented. I found that in some of my code > classes and also, for instance, in Nutilus itself. In the attachment you > see PluggableThreePhaseButtonMorph that is a subclass of > ThreePhaseButtonMorph, but the nesting suggests that the class > PluggableThreePhaseButtonMorph is a subclass of a subclass of > ThreePhaseButtonMorph. > > Don't know if it is a bug or a wanted behaviour. I believe the first. > > Regards, > Fabrizio >

May 15, 2012

[Pharo-project] Nautilus small bug? report

by Fabrizio Perin

Hi, I'm using the latest Moose version and I noticed that the classes in the Nautilus browser are weirdly indented. I found that in some of my code classes and also, for instance, in Nutilus itself. In the attachment you see PluggableThreePhaseButtonMorph that is a subclass of ThreePhaseButtonMorph, but the nesting suggests that the class PluggableThreePhaseButtonMorph is a subclass of a subclass of ThreePhaseButtonMorph. Don't know if it is a bug or a wanted behaviour. I believe the first. Regards, Fabrizio

May 15, 2012