June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Screencast]: Pharo Smalltalk's New TxText: The Power of Clean Code

by Sven Van Caekenberghe

On 05 Jun 2013, at 22:52, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > https://vimeo.com/67752734 > > Very short and simple video describing my experience while implementing > replacing a text morph's cursor with a block cursor to signify vim normal > mode. Shows how I was able to accomplish something in a few minutes which > seemed impossible with TextEditor and friends. Cool. > Things are getting really exciting around here :) Yes ! > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Screencast-Pharo-Smalltalk-s-New-TxText-The-Power-of-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 5, 2013

Re: [Pharo-dev] WhatsUp from: 2013-06-03 until: 2013-06-16

by Sean P. DeNigris

Denis Kudriashov wrote > - different kind of Span's like Morphs and Tab-symbols. Now *that* will open up a lot of fun possibilities... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-WhatsUp-from-2013-06-03-until-2013-06-16-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 5, 2013

[Screencast]: Pharo Smalltalk's New TxText: The Power of Clean Code

by Sean P. DeNigris

https://vimeo.com/67752734 Very short and simple video describing my experience while implementing replacing a text morph's cursor with a block cursor to signify vim normal mode. Shows how I was able to accomplish something in a few minutes which seemed impossible with TextEditor and friends. Things are getting really exciting around here :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Screencast-Pharo-Smalltalk-s-New-TxText-The-Power-of-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 5, 2013

Re: [Pharo-dev] SOAP in Pharo

by Norbert Hartl

Am 05.06.2013 um 15:41 schrieb S Krish <krishnamachari.sudhakar(a)gmail.com>: > In our works ( VA).. we had the "Document-Literal" SOAP wrapper approach and generally works easy and fine. > > I would say it is order more easier than what I see Norbert mention, unless I miss something in deference to his better experience in Pharo. > Can you elaborate on your explanation? I would like to know how your approach works and how it is different to what I do. > With XMLRPC in Pharo I could do a lot Java - Smalltalk experimentally... and I believe it should not be very tough to cobble up the simplest workable SOAP interface bi-directional with Document/Literal approach > > http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ > > The namespace complication, which we have avoided/ I would avoid till the reasons are high enough to justify. > I'm sorry but I don't understand what you are saying. I think to build any generic interface for SOAP you need to parse and generate XML properly according to the WSDL spec (I answered Svens email right now explaining it). I would like to see another approach that is simple and smarter than mine. Norbert > ******************** > > Not tested.. but did see this... at some time.. all squeak based.. > > http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html > > http://wiki.squeak.org/squeak/1399.diff?id=29 > > http://wiki.squeak.org/squeak/1228.diff?id=33 > > http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html > > > > On Wed, Jun 5, 2013 at 6:48 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Thanks for all the feedback! > > The SoapOpera library is using XMLSupport and I think it is a basic generate/parse library for SOAP messages. > Given the time constraints and the limited number of soap calls we need to implement, I think we will roughly go for Norbert's approach (using XMLSupport) and see if we can/need to work on the SoapOpera library in the future. Or maybe we make a 'lightweight soap' library... I don't know. > > Johan > > > On 03 Jun 2013, at 19:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 03 Jun 2013, at 18:08, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> In order to use SOAP properly you need a full namespace aware xml parser, a xml schema parser, a WSDL parser plus code generator and the will to abuse HTTP completely . > >> Even if you build a perfect tool you'll maybe face the not so perfect responses from the remote side. > > > > Even using the Java stack with all its tools and frameworks, SOAP is still terrible. Especially if you have to interface with Microsofts' idea of SOAP and web services. > > > > But Johan implied already that it would not be fun. > > > > On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO. > > > > Sven > > > > PS: In another life I did http://common-lisp.net/project/cl-soap/ - it was never perfect but it kind of worked to talk to Google AdWords. > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > >

June 5, 2013

Re: [Pharo-dev] SOAP in Pharo

by Norbert Hartl

Am 03.06.2013 um 19:31 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > On the other hand, I think that XML Support _is_ namespace aware. So it would not be too hard to actually generate/parse SOAP messages for real. You could get already pretty far with that, IMHO. I would say XMLSupport has namespaces. With full namespace aware I meant dealing with things like elementFormDefault/attributeFormDefault. Without having that properly implemented and parsed you will have trouble generating something generic. I see this essential because I saw a few WSDLs that did wildly mix the modes. I think this is due the fact that WSDLs are generated with a GUI and people don't know much about the underlying things. Norbert

June 5, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Camillo Bruni

On 2013-06-05, at 16:14, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 05/06/2013 16:04, Marcus Denker a Ã©crit : >> >> On Jun 5, 2013, at 4:03 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> Le 05/06/2013 15:56, Marcus Denker a Ã©crit : >>>> >>>> On Jun 5, 2013, at 2:39 PM, no-reply(a)ci.inria.fr wrote: >>>> >>>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… >>>>> >>>>> 3 regressions found. >>>>> FileSystem.Tests.Disk.FileHandleTest.testTruncate >>>>> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment >>>>> Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload >>>>> >>>> >>>> Hhmmâ¦ not good. >>>> >>>> Marcus >>>> >>>> >>> Hey, did something went wrong on integration? >> >> I guess so... > > If I add the correction of 10415/10411, I solve the last two. However, there is nothing on the path of the testTruncate which explains an effect of 10411/10415. Has the test machine been updated and now exhibits the same libc behavior as an ubuntu 13.04 ? yes, we're running in barely-alive-emergency-mode, and the backup slave is running 13.04 :/

June 5, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Goubier Thierry

Le 05/06/2013 16:04, Marcus Denker a Ã©crit : > > On Jun 5, 2013, at 4:03 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 05/06/2013 15:56, Marcus Denker a Ã©crit : >>> >>> On Jun 5, 2013, at 2:39 PM, no-reply(a)ci.inria.fr wrote: >>> >>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… >>>> >>>> 3 regressions found. >>>> FileSystem.Tests.Disk.FileHandleTest.testTruncate >>>> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment >>>> Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload >>>> >>> >>> Hhmmâ¦ not good. >>> >>> Marcus >>> >>> >> Hey, did something went wrong on integration? > > I guess so... If I add the correction of 10415/10411, I solve the last two. However, there is nothing on the path of the testTruncate which explains an effect of 10411/10415. Has the test machine been updated and now exhibits the same libc behavior as an ubuntu 13.04 ? Thierry >> The flush I added are not there in in the latest 2.0 image? >> >> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment >> >> Of course, this one fail :( >> >> Adding the flush where they are supposed to be solve that one... >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 5, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Goubier Thierry

Le 05/06/2013 15:56, Marcus Denker a Ã©crit : > > On Jun 5, 2013, at 2:39 PM, no-reply(a)ci.inria.fr wrote: > >> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… >> >> 3 regressions found. >> FileSystem.Tests.Disk.FileHandleTest.testTruncate >> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment >> Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload >> > > Hhmmâ¦ not good. > > Marcus > > Hey, did something went wrong on integration? The flush I added are not there in in the latest 2.0 image? Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment Of course, this one fail :( Adding the flush where they are supposed to be solve that one... Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 5, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Marcus Denker

On Jun 5, 2013, at 4:03 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 05/06/2013 15:56, Marcus Denker a Ã©crit : >> >> On Jun 5, 2013, at 2:39 PM, no-reply(a)ci.inria.fr wrote: >> >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… >>> >>> 3 regressions found. >>> FileSystem.Tests.Disk.FileHandleTest.testTruncate >>> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment >>> Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload >>> >> >> Hhmmâ¦ not good. >> >> Marcus >> >> > Hey, did something went wrong on integration? I guess so... > The flush I added are not there in in the latest 2.0 image? > > Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment > > Of course, this one fail :( > > Adding the flush where they are supposed to be solve that one... > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 5, 2013

Re: [Pharo-dev] [ANN] MonticelloFileTree-Git

by Goubier Thierry

Le 05/06/2013 15:02, Esteban A. Maringolo a Ã©crit : > Thierry, > > Let's say I want to start using a bit based Monticello repository (in > order to push everyting to Bitbucket). > > Where should I start? What else should I install? On the git side: git init or git clone On the Pharo side: The following sequence should load everything... mkdir pharo cd pharo; wget -O- get.pharo.org/20+vm | bash cd pharo; ./pharo Pharo.image config http://ss3.gemstone.com/ss/FileTree ConfigurationOfFileTree --install=1.0.2 cd pharo; ./pharo Pharo.image config http://ss3.gemstone.com/ss/MetaRepoForPharo20 ConfigurationOfOSProcess --install=stable cd pharo; ./pharo Pharo.image eval --save "Gofer new url: 'http://smalltalkhub.com/mc/ThierryGoubier/MonticelloFileTree-Git/main/'; package: 'MonticelloFileTree-Git'; load" And then, in the Monticello gui, you do +Repository, choose gitfiletree:// and select the directory inside the git repo where you want to store your packages (creation and git commit upon repository creation included!). After that, it will work as any other repository. If you want to import whole package history, the best is probably to use the Gofer scripts posted here to move a project to smalltalkhub. Just have a look into your git repo as things are done (git status or git log) to see the commits being done; preparing this mail has shown me a very problematic bug in my code :( :( but already corrected :) And if you see it doesn't do what you expect, tell me! Thierry > Regards! > > Esteban A. Maringolo > > > 2013/6/5 Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> > > Thanks StÃ©phane, > > it's just that this effort is at the point where I can't do anything > more, because my use of git doesn't require much else. I would drop > to the command line anyway to handle branches, pull/push etc... > including the fact that the git repo in my case is usually a "larger > than smalltalk" system, and so contradicting the need for a closer > integration inside Pharo. > > As it is now, it's equivalent to using, say, a Smalltalkhub or a ss3 > repo (except for the need to push changes). > > Thierry > > Le 05/06/2013 13:57, StÃ©phane Ducasse a Ã©crit : > > thanks for keeping us posted. > > Stef > > On Jun 5, 2013, at 1:50 PM, Goubier Thierry > <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> wrote: > > Hi All, > > my small extension to filetree for git users, i.e. > gitfiletree:// repos, has now reached an interesting point, > which is the ability to scan a filetree repository inside a > git repository and recover (and load, and browse, and > etc...) all git-recorded versions of Monticello packages > stored in it. > > As before, it's at > > http://smalltalkhub.com/#!/~__ThierryGoubier/__MonticelloFileTree-Git/ > <http://smalltalkhub.com/#!/~ThierryGoubier/MonticelloFileTree-Git/> > > and relies on MonticelloFileTree and OS-Process for the > underlying magic. It works perfectly on a pre-existing > filetree inside git repo, except for corrupted smalltalk > packages (it tries to avoid them, with no guarantees of > success). > > Enjoy, > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 5, 2013