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

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

by Goubier Thierry

Le 06/06/2013 11:17, Marcus Denker a Ã©crit : >> Now, 606 isn't available, no? I use get.pharo.org/20 > > Ah, then that is the problemâ¦ normally it is pushed automatically, but this seems to have failed. > I think we should just wait till the infrastructure is back and then redo the build. > > Marcus Ok, 606 is available now. 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 6, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… 1 regressions found. Zodiac.Tests.ZdcSecureSocketStreamTests.testIsNativeSSLPluginPresent

June 6, 2013

Jenkins build is back to stable : Pharo-2.0 #320

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0/320/>

June 6, 2013

Re: [Pharo-dev] Lowecase class names

by Frank Shearar

On 6 June 2013 10:37, kilon <thekilon(a)yahoo.co.uk> wrote: > When I was coding with python I used underscore instead of camel case. > > MorphWindow -> morph_window > > and I also like common lisp approach > > MorphWindow -> morph-window This is my favourite naming scheme. It's problematic from a Smalltalk syntax point of view because whitespace isn't required around binary selectors. So "morph-window" means "send #- to morph with argument window". Fun and games ensue when you consider subtraction and negation - is "3--4" "subtract -4 from 3" or "send #-- to 3 with argument 4"? (Squeak requires you to rewrite the code to either "3 -- 4" or "3 - -4"). frank > I always found camel case very weird , since back in 1996 that i saw it used > in C++. And even though I have grown up reading it , I am still find it > difficult especially with lenghty code. > > Of course what happens in pharo should be a democratic decision, but I dont > think allowing for freedom to choose is a bad thing. > > Thats how python works, and most programming languages. Only pharo / squeak > than I know of foces usage of Camel case, and capitalisation of first letter > in classes . Cant say i find it a good thing. > > > > -- > View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691925.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 6, 2013

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

by plantec

On 6 juin 2013, at 12:23, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 June 2013 11:14, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> 2013/6/6 Sean P. DeNigris <sean(a)clipperadams.com> >>> >>> https://vimeo.com/67752734 >> >> >> Cool. Did you publish code? >> >>> >>> >>> >>> 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 :) >> >> >> We talk with Alain about Rubric and in near future we will have selection as >> morph's. So we can tune selection border width, color, present it with >> ellipse and etc. > > umm? text selection? what ellipse if it can span multiple lines/pages of text? no, the selection can be a PolygonMorph (as shown in my last Rubric screencast). Then we can think of different ways to present this polygon but the basic presentation does not differs from what we have today. Cheers Alain > >> >>> >>> >>> >>> >>> ----- >>> 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. >>> >> > > > > -- > Best regards, > Igor Stasenko. >

June 6, 2013

Re: [Pharo-dev] SOAP in Pharo

by S Krish

The approach taken is to simply put the more or less fixed prefix - suffix Soap Envelope Message to the Document/ Literal XML content. It is the receiving Server that then does the task of unmarshalling the XML content and then custom interpreting it for actions.. messageName is the operation to be executed.. <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Body> <tns:messageName xmlns:tns="http://api.ws.liq.misys.com/"> ----- the document literal XML--- </tns:messageName t> </soap:Body> </soap:Envelope> On Wed, Jun 5, 2013 at 10:02 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > 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 6, 2013

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

by kilon

I dont think a debugger can ever replace TDD for two reason a) Tests are faster way to find bugs that don't want to be found ;) b) Tests are more than debugging tools (A) If you have already created a large suite of tests then all it takes is to fire those tests and just wait for the result to come out. Much fastert than going one by one bug. Also I dont know if the same applies for smalltalk but when i was coding for python not all code was executed and so I did not see all the bugs my code contains. So I had to test the app myself in many diffirent ways and I quickly found out that writing tests was way faster in the long run. (B) tests also make sure that your code behaves the way you want to behave and produces the result you want to produce. It may not be a bug per se, just a weird behavior. They also set a design pattern for your code to follow in the future. Generally speaking I use TDD for long code or code that is going to be maintained in the long run and get larger and larger. I think in that scenario TDD really excells. TDD is very popular in python, its part of the main library cpython(unittesting.py) comes with and there is also a third party library called "Nose" that even offer more features. I think TDD helps you keep your sanity in the long run especially with big projects and complex code. Debuggers are more like microscopes while i see TDD more like Satelites on orbit. ;) -- View this message in context: http://forum.world.st/Pharo-dev-Necessity-of-TDD-with-Smalltalk-tp4691867p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

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

by Igor Stasenko

On 6 June 2013 11:14, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/6/6 Sean P. DeNigris <sean(a)clipperadams.com> >> >> https://vimeo.com/67752734 > > > Cool. Did you publish code? > >> >> >> >> 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 :) > > > We talk with Alain about Rubric and in near future we will have selection as > morph's. So we can tune selection border width, color, present it with > ellipse and etc. umm? text selection? what ellipse if it can span multiple lines/pages of text? > >> >> >> >> >> ----- >> 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. >> > -- Best regards, Igor Stasenko.

June 6, 2013

Re: [Pharo-dev] Lowecase class names

by kilon

When I was coding with python I used underscore instead of camel case. MorphWindow -> morph_window and I also like common lisp approach MorphWindow -> morph-window I always found camel case very weird , since back in 1996 that i saw it used in C++. And even though I have grown up reading it , I am still find it difficult especially with lenghty code. Of course what happens in pharo should be a democratic decision, but I dont think allowing for freedom to choose is a bad thing. Thats how python works, and most programming languages. Only pharo / squeak than I know of foces usage of Camel case, and capitalisation of first letter in classes . Cant say i find it a good thing. -- View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691925.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

Re: [Pharo-dev] Lowecase class names

by Esteban Lorenzano

Hi, On Jun 6, 2013, at 9:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jun 6, 2013, at 9:29 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> On 03/06/13 12:18, Marcus Denker wrote: >>> >>> On Jun 3, 2013, at 1:13 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >>> >>>> I thought so. Attached hack removes it. >>>> >>> >>> Of course a complete rewrite of the class builder is ready for integrationâ¦ >>> >>> https://ci.inria.fr/pharo-contribution/job/Slot/ >>> >>> So the question is if it makes sense to add this one? >> >> Hm...I'm not sure what you mean. > > I mean that we should not change ClassBuilder now if it is replaced next week. > (man power is limited). > >> Let put it this way? Any chance >> 2.0 will allow lowercase class names? well... since allowing lowercase class names does not exactly qualify as "bugfix", I would say it will not be there in 2.0. The idea is that the trunk development moves each year (with each version) and older version becomes just bugfix supported. Otherwise we will be ever-maintaining older versions, something that not even apple does (with all the capacity they have). So I would vote also "no" :) > > The problem with changing 2.0 is that all change always has side-effect impacting > othersâ¦ often in very non-expected ways. > > So I am a bit skeptical to change 2.0, especially anything in the dark places like the class > builder. > > If it is a change that is for the good of all users, is makes sense to invest time and effort. > But changing the class builder in 2.0 just for an experiment of one person? I would tend to > argue to not do it. > > The current development version is another story. There we can break things, have time to stabilize. > > Marcus

June 6, 2013