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

Re: [Pharo-project] About Zinc to replace HTTPClient

by Norbert Hartl

Am 16.04.2011 um 15:13 schrieb GermÃ¡n Arduino: > I would like to know exactly what features will provide Zn and which not. > What do you mean with features? > As I remember form the past was not planned to support for example > https, which prevent to use OAuth and OpenID, very needed to develop > any interaction against any modern web site. > Zinc is http handling components. Https is just a http request over a transparently initiated SSL connection. So if you have SSL you have https. It is not the duty of an http component to support SSL. A url handler needs to integrate existing SSL. As far as I remember the cloudfork guys have OAuth running. So they must have SSL. So it shouldn't be to hard to do the same with zinc. Just exchange the http handling routines. Norbert > 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: >> >> Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: >> >>> Hi guys >>> >>> we discuss with sven about strategies to get a better infrastructure and the HTTP level. >>> Sven would like to have feedback on Zinc before pushing it in Pharo :) >>> So can you let us know. What we could do it to have it in a preview in 1.3 >>> then in 1.4 remove HTTPClient (or friend). >> >> This is really good. To me (meaning IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. >> I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. >> And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! >> And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. >> >> my two cents, >> >> Norbert >> >> >> >

April 16, 2011

[Pharo-project] Order in the Hudson for CogVMs

by Mariano Martinez Peck

Hi...I love what you are doing in Hudson, but the Cog part it is quite a mess right now. I would love to see some organization. 1) Not all VMs have both: the build and the sources. Example, https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/ has only the sources. But https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Carbon/ has both. If someone follows this: http://code.google.com/p/cog/wiki/CMakeVMMaker then such info is incorrect. 2) We are mixing "Release" VMs from experiments. I would create two Hudson tabs 2.1) one for Cog, where we have the "release" VMs. This means, things like Cog Mac Carbon, Cog Mac Cocoa, Cog Unix, CogMT Mac Cocoa, MT Cog Unix, Stack VM Unix, StackVM Mac Carbon, StackVM Mac Cocoa, etc. 2.2) One for experiments, like: Check cogvm.unthinkable.org, Cog Git Tracker (cog-osx), Cog Git Tracker (sig-cog), Cog.FreeBSD.unthinkable,Sista Only if we do that, we will be able to use Hudson like a place to say to users to download a VM. Otherwise, we cannot. There are several targets and they are confusing. Cheers -- Mariano http://marianopeck.wordpress.com

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by Mariano Martinez Peck

I have a couple of question, not about Zn but the process: 1) Stef, you are talking about just to put Zn in the image or REPLACE all uses of HTTP to use Zn? 2) It may be difficult to replace that since Monticello use it -> be carfeul ! 3) How are you going to depreacate HTTP? 4) Does Zn mantains the same API as HTTP ? what happen with external packages? will the API change? Cheers Mariano On Sat, Apr 16, 2011 at 3:13 PM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > I would like to know exactly what features will provide Zn and which not. > > As I remember form the past was not planned to support for example > https, which prevent to use OAuth and OpenID, very needed to develop > any interaction against any modern web site. > > Cheers. > GermÃ¡n. > > > 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: > > > > Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: > > > >> Hi guys > >> > >> we discuss with sven about strategies to get a better infrastructure and > the HTTP level. > >> Sven would like to have feedback on Zinc before pushing it in Pharo :) > >> So can you let us know. What we could do it to have it in a preview in > 1.3 > >> then in 1.4 remove HTTPClient (or friend). > > > > This is really good. To me (meaning IMHO) it is one of the most missing > functionalities in pharo. Zinc is really great and so much better than > _anything_ in pharo that pretends to do HTTP. I would like to see it that we > don't talk about HTTP but about proper MIME based communication. I think the > very core that is in there is the structured and flexible mime media > handling and communication. And this is not only true for HTTP but also for > email. > > I would like to see that Zinc creeping into the image bringing the mime > stuff along. Than the mime stuff should break loose of the Zinc components > and should replace the mime handling that is in the image. Than we have it > for http and for mail sending and for every other transport protocol you can > imagine. > > And now that Paul ported zinc to gemstone you can develop good http > handlers that are easily ported to gemstone. What a wonderful world! > > And seaside? Well, if the current http adaptors are much faster than zinc > than there should be shortcut path through zinc that allows fast handling of > the minimal stuff seaside needs. The same problem goes for the WARequest > stuff. Using zinc you can get access to the mime parts. Now WARequest is a > strange request object that contains a dictionary for request parameters and > a raw message body. If only compatibility is important than a zinc to old > WARequest handling is needed. But I would like to see the mime based > handling to be the "normal" way of doing and not vice versa. But I can see > that it must be a special treatment as seaside is ported to so many > platforms that don't have zinc. Probably one reasone more to extract the > mime stuff. It might be a promininent candidate other platforms adopt. > > > > my two cents, > > > > Norbert > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 16, 2011

Re: [Pharo-project] Desktop application with Pharo

by Schwab,Wilhelm K

Laurent, I don't know that what I have done is better than anything else; the basic idea is adapted (aka shamelessly stolen<g> from a wiki entry. Below is the class comment from something that I have successfully deployed as a "desktop app" using Pharo. Using StandardWindow (thanks again to Pinesoft!!), it can #openInWorld (as part of the IDE) or #openFullScreen (when deployed), can be dragged only by the title bar, etc. Is there a way to get an image to save a copy of itself and its change log in another folder? Suppose the image is happily running in /home/me/Pharo-1.1.1/Pharo-dev-nnnn.image,changes /home/me/Pharo-1.1.1/Pharo-dev-nnnn.image,changes and the goal is to do the steps below in /home/Software/CoolGizmo/programName.image /home/Software/CoolGizmo/programName.changes Can the running image do that and continue to run in the Pharo-1.1.1 directory as though nothing happened? That might make it possible to take the bumps out of the deployment process. Bill "To test in the IDE" Equalize new asMorph openInWorld. "To deploy - copy the image somewhere, and then do all of the following." Preferences disable:#showWorldTaskbar. 10-09 - one-shot do-it to deploy Equalize; copy the image somewhere first!!" Preferences disable:#showWorldTaskbar. SystemWindow allSubInstances do:[ :each | each delete. ]. "Then do this as one do-it" SmalltalkImage current snapshot: true andQuit: false. Equalize new asMorph openFullscreen. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of laurent laffont [laurent.laffont(a)gmail.com] Sent: Saturday, April 16, 2011 5:55 AM To: An open mailing list to discuss any topics related to an open-source Smalltalk Subject: [Pharo-project] Desktop application with Pharo I'm searching for a way to create desktop applications with Pharo (no multiple window). Here's the current snippet that do what I want. Improvements / better code is really really welcome. How I can change the title of the window ? The snippet to evaluate in Workspace: counter := Class new superclass: Object; addInstVarNamed: 'counter'; compile: 'initialize counter := 0'; compile: 'counterString ^ counter asString'; compile: 'increment counter := counter + 1. self changed:#counterString'; compile: 'decrement counter := counter - 1. self changed:#counterString'; new. panel := UITheme builder newPanel. panel layoutPolicy: ProportionalLayout new. panel addMorph: (UITheme builder newLabelFor: counter getLabel: #counterString getEnabled: nil) fullFrame: (LayoutFrame fractions: (0@0 corner: 1(a)0.5)) panel addMorph: (UITheme builder newButtonFor: counter action: #increment label: '+' help: nil) fullFrame: (LayoutFrame fractions: (0(a)0.5 corner: 0.5@1)). panel addMorph: (UITheme builder newButtonFor: counter action: #decrement label: '-' help: nil) fullFrame: (LayoutFrame fractions: (0.5(a)0.5 corner: 1@1)). World submorphs do: [:aMorph| aMorph delete]. World layoutPolicy: ProportionalLayout new; addMorph: panel fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)). Laurent Laffont - @lolgzs<http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by GermÃ¡n Arduino

I would like to know exactly what features will provide Zn and which not. As I remember form the past was not planned to support for example https, which prevent to use OAuth and OpenID, very needed to develop any interaction against any modern web site. Cheers. GermÃ¡n. 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: > > Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: > >> Hi guys >> >> we discuss with sven about strategies to get a better infrastructure and the HTTP level. >> Sven would like to have feedback on Zinc before pushing it in Pharo :) >> So can you let us know. What we could do it to have it in a preview in 1.3 >> then in 1.4 remove HTTPClient (or friend). > > This is really good. To me (meaning Â IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. > I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. > And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! > And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. > > my two cents, > > Norbert > > >

April 16, 2011

[Pharo-project] Desktop application with Pharo

by laurent laffont

I'm searching for a way to create desktop applications with Pharo (no multiple window). Here's the current snippet that do what I want. Improvements / better code is really really welcome. How I can change the title of the window ? The snippet to evaluate in Workspace: counter := Class new superclass: Object; addInstVarNamed: 'counter'; compile: 'initialize counter := 0'; compile: 'counterString ^ counter asString'; compile: 'increment counter := counter + 1. self changed:#counterString'; compile: 'decrement counter := counter - 1. self changed:#counterString'; new. panel := UITheme builder newPanel. panel layoutPolicy: ProportionalLayout new. panel addMorph: (UITheme builder newLabelFor: counter getLabel: #counterString getEnabled: nil) fullFrame: (LayoutFrame fractions: (0@0 corner: 1(a)0.5)) panel addMorph: (UITheme builder newButtonFor: counter action: #increment label: '+' help: nil) fullFrame: (LayoutFrame fractions: (0(a)0.5 corner: 0.5@1)). panel addMorph: (UITheme builder newButtonFor: counter action: #decrement label: '-' help: nil) fullFrame: (LayoutFrame fractions: (0.5(a)0.5 corner: 1@1)). World submorphs do: [:aMorph| aMorph delete]. World layoutPolicy: ProportionalLayout new; addMorph: panel fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)). Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by Norbert Hartl

Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: > Hi guys > > we discuss with sven about strategies to get a better infrastructure and the HTTP level. > Sven would like to have feedback on Zinc before pushing it in Pharo :) > So can you let us know. What we could do it to have it in a preview in 1.3 > then in 1.4 remove HTTPClient (or friend). This is really good. To me (meaning IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. my two cents, Norbert

April 16, 2011

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by laurent laffont

Done Laurent. On Sat, Apr 16, 2011 at 6:41 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Mariano, > > can you change my text to > > "Independent Consultant. Contributed the Cog VM ( > http://www.mirandabanda.org/cog) originator of method tags." > > and my picture to the attached? > > TIA > > > On Thu, Apr 14, 2011 at 6:46 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> if true...then what are you wainting for? >> >> http://www.pharo-project.org/community/contributors >> >> Send you data and nice picture :) >> >> Seriously, it is important for marketing among other things. Imagine you >> arrive to a new project...it is good to see that there are several >> contributing to it. Probably this page is not the best, but is something >> more. >> >> Mariano >> >> >> >> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont < >> laurent.laffont(a)gmail.com> wrote: >> >>> Added ! >>> >>> Laurent. >>> >>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org>wrote: >>> >>>> Hi Laurent, >>>> >>>> I'd like to be added to >>>> http://www.pharo-project.org/community/contributors . My picture is >>>> attached. Description text could be "Contributed the default anti-aliased >>>> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org >>>> ". >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

April 16, 2011

Re: [Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by laurent laffont

Done. Have I really read "Treasurer of ESUG and ***Pharo Association***" ? Laurent On Fri, Apr 15, 2011 at 10:00 PM, Luc Fabresse <luc.fabresse(a)gmail.com>wrote: > Hi Guys, > > Please add me too. > > ---- > Luc Fabresse > Permanent researcher at *Ecole des Mines de Douai> > http://www.mines-douai.fr*. > Use Pharo for teaching and research projects. > > Treasurer of ESUG and Pharo Association. > ----- > > #Luc > > > > 2011/4/14 laurent laffont <laurent.laffont(a)gmail.com> > >> Done ! >> >> Laurent >> >> >> >> >> On Thu, Apr 14, 2011 at 10:07 PM, Diogenes Moreira < >> diogenes.moreira(a)gmail.com> wrote: >> >>> i forget the picture [image: photo.jpg] >>> >>> >>> On Thu, Apr 14, 2011 at 5:05 PM, Diogenes Moreira < >>> diogenes.moreira(a)gmail.com> wrote: >>> >>>> Ok.. Well >>>> >>>> DiÃ³genes Alberto Moreira >>>> CTO at Ilon S.A. and CTO at Sociadad Anonima para la Salud S.A. ( >>>> www.ilon.com.ar) >>>> Contributor on DBXTalk (http://squeakdbx.org) and other projects. >>>> >>>> Smalltalker And Pharo's lover :) >>>> >>>> Best >>>> >>>> >>>> On Thu, Apr 14, 2011 at 10:46 AM, Mariano Martinez Peck < >>>> marianopeck(a)gmail.com> wrote: >>>> >>>>> if true...then what are you wainting for? >>>>> >>>>> http://www.pharo-project.org/community/contributors >>>>> >>>>> Send you data and nice picture :) >>>>> >>>>> Seriously, it is important for marketing among other things. Imagine >>>>> you arrive to a new project...it is good to see that there are several >>>>> contributing to it. Probably this page is not the best, but is something >>>>> more. >>>>> >>>>> Mariano >>>>> >>>>> >>>>> >>>>> On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont < >>>>> laurent.laffont(a)gmail.com> wrote: >>>>> >>>>>> Added ! >>>>>> >>>>>> Laurent. >>>>>> >>>>>> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org>wrote: >>>>>> >>>>>>> Hi Laurent, >>>>>>> >>>>>>> I'd like to be added to >>>>>>> http://www.pharo-project.org/community/contributors . My picture is >>>>>>> attached. Description text could be "Contributed the default anti-aliased >>>>>>> fonts and the SimpleMorphic UI framework. Web page at >>>>>>> www.jvuletich.org". >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Cheers, >>>>>>> Juan Vuletich >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.com >>>>> >>>>> >>>> >>> >> >

April 16, 2011

Re: [Pharo-project] Making OB / RB / OCompletion / Shout to work on Pharo 1.3

by Lukas Renggli

> OBCodeBrowserÂ >> subscribe > Â Â Â "We want to be notified first about changes of the definition, so that > we can replace it with a custom one." > > Â Â Â | actions | > Â Â Â super subscribe. > Â Â Â actions := announcer subscriptions > Â Â Â Â Â Â at: OBDefinitionChanged > Â Â Â Â Â Â ifAbsent: [ ActionSequence new ]. > Â Â Â announcer subscriptions > Â Â Â Â Â Â at: OBDefinitionChanged > Â Â Â Â Â Â put: (actions copyWithFirst: (MessageSend > Â Â Â Â Â Â Â Â Â receiver: self > Â Â Â Â Â Â Â Â Â selector: #definitionChanged:)) > > to: > > OBCodeBrowserÂ >> subscribe > Â Â Â "We want to be notified first about changes of the definition, so that > we can replace it with a custom one." > > Â Â Â | actions | > Â Â Â super subscribe. > Â Â Â announcer on: OBDefinitionChanged send: #definitionChanged: to: self. This change breaks the undo/redo mechanism of class definitions and subsequently the undo/redo mechanism of all other code changes and refactorings. > And from: > > OBTextMorphWithShout >> editorClass > Â Â Â "Answer the class used to create the receiver's editor" > > Â Â Â ^OBTextMorphEditorWithShout > > to: > > OBTextMorphWithShout >> editorClass > Â Â Â "Answer the class used to create the receiver's editor" > > Â Â Â ^SmalltalkEditor This breaks OB in various ways. Not every editor is a Smalltalk editor, there are lots of editors that don't need Smalltalk semantics (editing comments, editing organization, displaying lint results, displaying diffs, ...). Furthermore, OBTextMorphWithShould should be gone. It is not needed any longer and was removed to make OB properly work in Pharo 1.2. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 16, 2011