- Pharo-dev - lists.pharo.org

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

by Mariano Martinez Peck

Thanks Sean. This is exactly the type of thing that normal users don't see when they use Pharo. Of course, most people notice the UI refactors, the new tools etc. But only a few notice the work underneath :) On Wed, Jun 5, 2013 at 6:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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. > > > > > -- Mariano http://marianopeck.wordpress.com

June 5, 2013

Re: [Pharo-dev] Necessity of TDD with Smalltalk

by phil＠highoctane.be

Well, at one point, I realized that tests were saving my butt more often than not. Especially with Smalltalk. They also do form basic documentation for the lack of anything better. At least, you can debug them to see what happens. Phil On Thu, Jun 6, 2013 at 12:11 AM, Paul Davidowitz <pdavidow(a)fastmail.fm>wrote: > It seems to me that a big reason for developing via writing tests first > (Test Driven Development) is that the tests serve as a debugging tool -- > if a test breaks, then the last piece of (non-test) code that change is > likely the culprit. But with the powerful debugging environment that > comes with Smalltalk, I am wondering of the utility of TDD (TDD is big > in the Ruby camp perhaps for a reason). After all, writing and > re-writing the tests becomes quite a non-trivial chore (not to mention > that the tests themselves could be buggy). So my question: Is it ok in > Smalltalk to write tests afterwards? Is it even perhaps recommended? > > - Paul > >

June 5, 2013

Necessity of TDD with Smalltalk

by Paul Davidowitz

It seems to me that a big reason for developing via writing tests first (Test Driven Development) is that the tests serve as a debugging tool -- if a test breaks, then the last piece of (non-test) code that change is likely the culprit. But with the powerful debugging environment that comes with Smalltalk, I am wondering of the utility of TDD (TDD is big in the Ruby camp perhaps for a reason). After all, writing and re-writing the tests becomes quite a non-trivial chore (not to mention that the tests themselves could be buggy). So my question: Is it ok in Smalltalk to write tests afterwards? Is it even perhaps recommended? - Paul

June 5, 2013

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