July 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Fun with symbols

by StÃ©phane Ducasse

tx! On Jul 28, 2013, at 9:49 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?11257 > > Jannik > > On Jul 27, 2013, at 10:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Jannik can you >> - write a test >> - add a bug entry >> >> This would be to align this point. And also verify it in VW, Squeak and other. >> >> Stef >> >> On Jul 26, 2013, at 9:43 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> Something I did not know and I would like to share: >>> what is the result of "#a < #9" ? DNU ! >>> >>> When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. >>> So if I want to compare two symbols, I have to do "#a < #'9' ". >>> >>> Kind of small fun things ! >>> Cheers, >>> >>> Jannik >> >> >

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by StÃ©phane Ducasse

Hello This is nice to see some progress on Socket. - What is the license of the code? - Do you want to give it to the community? - I like the suggestion of igor to have a new class. Stef > Hello, > > I want to share that I wrote a blog post on using Unix domain sockets in > Pharo. > > http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html > > The NetNameResolver bits can be made more Smalltalk-ish. Also, I'll be > looking into the minor changes needed to support SocketStream as well. > > Maybe this is the wrong list to ask, but how do I contribute this to Pharo? > > > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/ > >

July 28, 2013

Re: [Pharo-users] Fun with symbols

by jannik.laval

https://pharo.fogbugz.com/default.asp?11257 Jannik On Jul 27, 2013, at 10:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Jannik can you > - write a test > - add a bug entry > > This would be to align this point. And also verify it in VW, Squeak and other. > > Stef > > On Jul 26, 2013, at 9:43 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: > >> Hi guys, >> >> Something I did not know and I would like to share: >> what is the result of "#a < #9" ? DNU ! >> >> When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. >> So if I want to compare two symbols, I have to do "#a < #'9' ". >> >> Kind of small fun things ! >> Cheers, >> >> Jannik > >

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by Igor Stasenko

On 28 July 2013 03:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: > Hello, > > I want to share that I wrote a blog post on using Unix domain sockets in > Pharo. > > http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html > > The NetNameResolver bits can be made more Smalltalk-ish. Also, I'll be > looking into the minor changes needed to support SocketStream as well. > > Maybe this is the wrong list to ask, but how do I contribute this to Pharo? > Well, pharo-dev list is more appropriate place for discussing contributions. Because users list is mostly about 'how can i ... ' stuff, e.g. to help newcomers with pharo, or clarify things etc (at least this is how i using it). As for the rest, you can read details at this page (and link from it): http://www.pharo-project.org/community/how-to-contribute About unix sockets: i see the changes is not really big and easy to integrate. My only question regarding this, how do you think, maybe it make sense to have a separate class for it, so users can tell: UnixSocket new instead of Socket newIPC i also think that if socket creation failed, the code should throw an error rather than return nil. > > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/ > > -- Best regards, Igor Stasenko.

July 28, 2013

Unix Domain Sockets

by Pierce Ng

Hello, I want to share that I wrote a blog post on using Unix domain sockets in Pharo. http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html The NetNameResolver bits can be made more Smalltalk-ish. Also, I'll be looking into the minor changes needed to support SocketStream as well. Maybe this is the wrong list to ask, but how do I contribute this to Pharo? Cheers. -- Pierce Ng http://samadhiweb.com/blog/

July 28, 2013

Re: [Pharo-users] Fun with symbols

by StÃ©phane Ducasse

Jannik can you - write a test - add a bug entry This would be to align this point. And also verify it in VW, Squeak and other. Stef On Jul 26, 2013, at 9:43 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: > Hi guys, > > Something I did not know and I would like to share: > what is the result of "#a < #9" ? DNU ! > > When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. > So if I want to compare two symbols, I have to do "#a < #'9' ". > > Kind of small fun things ! > Cheers, > > Jannik

July 27, 2013

Re: [Pharo-users] HTTP Header field handling in Zinc

by Sven Van Caekenberghe

Udo, On 27 Jul 2013, at 12:50, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > Hi Sven, > > On 27.07.13 00:57, Sven Van Caekenberghe wrote: >> Be sure to tell the websocketpp guys about this issue ;-) > Already did. Good. > The fact that websocketpp based apps return with 500 is even "funnier" IMHOâ¦ :-) >> A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this: >> >> | request | >> request := ZnRequest get: 'http://foo.com/bar?x=1'. >> request headers headers at: 'FUNy-headER' put: 'test'. >> request writeToTranscript >> >> which would go on the wire like >> >> GET /bar?x=1 HTTP/1.1 >> Accept: */* >> User-Agent: Zinc HTTP Components 1.0 >> FUNy-headER: test >> Host: foo.com >> >> >> It is not perfect, but I guess it would do. > I stumbled about #normalizeHeaderKey: as well and took another route (which is IMHO nicer ... to remove once websocketpp is fixed). > > ZnHeaders class>>#addWebSocketHeaders > CommonHeaders addAll: #('Sec-WebSocket-Version' 'Sec-WebSocket-Key') > > ZnWebSocket already uses these strings with the exact same capitilization - and being in CommonHeaders bypasses #normalizeHeaderKey: for "known" headers. Still a hack but works. Yes, that is an excellent hack. I introduced CommonHeaders quite recently as a performance improvement. But is is no solution either, like you said. >> Thanks for the feedback, make sure to tell me how it goes. > After finding out about this everything else just works fine - Zinc is simply amazing when working with HTTP. For me it's the first framework (not only in Smalltalk) which really models HTTP in an OOP way without being too complicated. > Simple things are easy - hard things possible :-) Thanks a lot ! >> PS: You do know about Zinc-WebSockets, I guess ? > Yep - using them. I wasn't mentioning this explicitly as the headers "problem" applies to ZnClient and might thus be affecting all HTTP based stuff. OK, I thought so, but I wasn't sure. > Best Regards, > > Udo Keep the feedback coming, it is really important. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 27, 2013

GitHub

by phil＠highoctane.be

What exactly is https://github.com/pharo-project about ? It is to test the Monticello Git integration? Give visibility to Pharo? I also see Pharo-VM. Is this the reference repository for the VM? (which used to on Gitorious for the OSX code I know about). Thanks. Phil

July 27, 2013

Re: [Pharo-users] HTTP Header field handling in Zinc

by Udo Schneider

Hi Sven, On 27.07.13 00:57, Sven Van Caekenberghe wrote: > Be sure to tell the websocketpp guys about this issue ;-) Already did. The fact that websocketpp based apps return with 500 is even "funnier" IMHO... > A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this: > > | request | > request := ZnRequest get: 'http://foo.com/bar?x=1'. > request headers headers at: 'FUNy-headER' put: 'test'. > request writeToTranscript > > which would go on the wire like > > GET /bar?x=1 HTTP/1.1 > Accept: */* > User-Agent: Zinc HTTP Components 1.0 > FUNy-headER: test > Host: foo.com > > > It is not perfect, but I guess it would do. I stumbled about #normalizeHeaderKey: as well and took another route (which is IMHO nicer ... to remove once websocketpp is fixed). ZnHeaders class>>#addWebSocketHeaders CommonHeaders addAll: #('Sec-WebSocket-Version' 'Sec-WebSocket-Key') ZnWebSocket already uses these strings with the exact same capitilization - and being in CommonHeaders bypasses #normalizeHeaderKey: for "known" headers. Still a hack but works. > Thanks for the feedback, make sure to tell me how it goes. After finding out about this everything else just works fine - Zinc is simply amazing when working with HTTP. For me it's the first framework (not only in Smalltalk) which really models HTTP in an OOP way without being too complicated. Simple things are easy - hard things possible :-) > PS: You do know about Zinc-WebSockets, I guess ? Yep - using them. I wasn't mentioning this explicitly as the headers "problem" applies to ZnClient and might thus be affecting all HTTP based stuff. Best Regards, Udo

July 27, 2013

Re: [Pharo-users] HTTP Header field handling in Zinc

by Sven Van Caekenberghe

Hi Udo, On 26 Jul 2013, at 22:54, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > All, > > Is there a supported way to change the capitalization of HTTP header fields in Zinc? I'm currently running into problems with a websocketpp (https://github.com/zaphoyd/websocketpp) based backend which expects a specifically capitalized Sec-WebSocket-* header field. E.g. Sec-WebSocket-* works, Sec-Websocket-* does not. > > As far as as I can see Zinc nicely capitalizes HTTP header fields. E.g. even if you provide "Sec-WebSocket-Key" the actual transmitted header is "Sec-Websocket-Key". > > I know that HTTP specified that header fields are case-insensitive. So problem is clearly on the websocketpp side. I just want to know if I can somehow instruct Zinc to not touch the capitalization to make working with non-compliant backends easier. > > Thanks, > > Udo Good analysis: you are completely right. Be sure to tell the websocketpp guys about this issue ;-) A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this: | request | request := ZnRequest get: 'http://foo.com/bar?x=1'. request headers headers at: 'FUNy-headER' put: 'test'. request writeToTranscript which would go on the wire like GET /bar?x=1 HTTP/1.1 Accept: */* User-Agent: Zinc HTTP Components 1.0 FUNy-headER: test Host: foo.com It is not perfect, but I guess it would do. Thanks for the feedback, make sure to tell me how it goes. Sven PS: You do know about Zinc-WebSockets, I guess ? -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

July 26, 2013

HTTP Header field handling in Zinc

by Udo Schneider

All, Is there a supported way to change the capitalization of HTTP header fields in Zinc? I'm currently running into problems with a websocketpp (https://github.com/zaphoyd/websocketpp) based backend which expects a specifically capitalized Sec-WebSocket-* header field. E.g. Sec-WebSocket-* works, Sec-Websocket-* does not. As far as as I can see Zinc nicely capitalizes HTTP header fields. E.g. even if you provide "Sec-WebSocket-Key" the actual transmitted header is "Sec-Websocket-Key". I know that HTTP specified that header fields are case-insensitive. So problem is clearly on the websocketpp side. I just want to know if I can somehow instruct Zinc to not touch the capitalization to make working with non-compliant backends easier. Thanks, Udo

July 26, 2013

Fun with symbols

by jannik.laval

Hi guys, Something I did not know and I would like to share: what is the result of "#a < #9" ? DNU ! When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. So if I want to compare two symbols, I have to do "#a < #'9' ". Kind of small fun things ! Cheers, Jannik

July 26, 2013

[Smalltalks 2013] --- Invitation

by Andres Valloud

The FundaciÃ³n Argentina de Smalltalk (FAST, http://www.fast.org.ar) invites you to the 7th International Conference on Smalltalk Technologies (Smalltalks), to be held from October 30th through November 1st at the Universidad TecnolÃ³gica Nacional, Facultad Regional Rosario, located in Rosario, Argentina. Everyone, including teachers, students, researchers, developers and entrepreneurs, are welcome as speakers or attendees. Registration is free and now open at http://www.fast.org.ar/smalltalks2013. This year we are accepting donations from participants to help fund the conference's costs. Please see the Donate section at FAST's website, http://www.fast.org.ar/smalltalks2013/donate. Contributions are greatly appreciated, and can be received both in pesos for local attendees, as well as via Paypal for those coming from abroad. Donors will receive a set of thank you gifts as well as the conference's shirt. The goal of the Conference is to strengthen the bonds between the Argentine and the international Smalltalk community through the exchange of works, experiences and anecdotes connected with this technology and related matters. As in the previous editions, renowned members of the international Smalltalk community will visit us, and like last year we will have a Research Session with publications reviewed by an international committee. Also, the traditional Industry Track will be available for those who prefer a more practical environment. You can submit papers or talks now through our website at http://www.fast.org.ar/smalltalks2013/technical-session The Industry Track's submission deadline is October 7th. For more information about related events, such as a Pharo Sprint or talks and presentations around the dates of the conference, please visit http://www.fast.org.ar/smalltalks2013/events We will update related event information as we get closer to the conference, so please check for updates. As in previous years, we will have a social dinner during the conference. If you are planning to attend, please reply to this email with a subject of "[Social Dinner]" and indicate how many people will be coming in your party. We will have a variety of dishes available for everyone. If you have special needs other than vegetarian dishes, please let us know. For any additional questions please contact us at info(a)fast.org.ar. See you there!

July 26, 2013

Re: [Pharo-users] Units package

by Marcus Denker

On Jul 26, 2013, at 9:34 AM, phil(a)highoctane.be wrote: > In my application, I need to work with units (which I have to integrate in Seaside-Magritte 3). > > So, I looked around and after a while found > > http://www.smalltalkhub.com/#!/~MarcusDenker/Units > > Tests are green on 2.0 and it looks like it will do what I need. > > Pretty cool package, worth a chapter somewhere. > > Is there any doc on this except the code itself? > No, sadly not. Yes, it should be documentedâ¦ :-) And I need to add a configuration. Marcus

July 26, 2013

Units package

by phil＠highoctane.be

In my application, I need to work with units (which I have to integrate in Seaside-Magritte 3). So, I looked around and after a while found http://www.smalltalkhub.com/#!/~MarcusDenker/Units Tests are green on 2.0 and it looks like it will do what I need. Pretty cool package, worth a chapter somewhere. Is there any doc on this except the code itself? Phil

July 26, 2013

Re: [Pharo-users] Your vm is too oldâ¦.

by Tudor Girba

Oops. Sorry for creating confusions. Doru On Jul 25, 2013, at 1:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 July 2013 12:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> The workaround at the image level was needed only until we got the VM >> working. The details about the workaround are here: >> https://pharo.fogbugz.com/f/cases/10395/ >> >> I was sure that in the meantime, the problem was solved in the VM as well, >> but I cannot trace that information. Perhaps it is not. Esteban? >> > > Last time i discussed with Esteban about it, he said that he don't > knows where the problem in VM, > neither me. > > >> Cheers, >> Doru >> >> >> On Thu, Jul 25, 2013 at 9:13 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> On Jul 25, 2013, at 9:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> This was a problem that we also had (when working in Moose), and Esteban >>> fixed it (first the workaround in the image, and then in the VM). We are >>> using this VM since some months now and the problem did not resurface. >>> >>> That is why I know it is fixed in the latest stable PharoVM. >>> >>> >>> Ok what igor is probably meaning is that we would prefer to get the system >>> running without having to have a workaround at the image level. >>> >>> >>> Cheers, >>> Doru >>> >>> >>> On Thu, Jul 25, 2013 at 9:03 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Doru, >>>> >>>> I'm sorry but I was mistaken somehow. I tried always to use the newest >>>> VM. I just downloaded a new vm a few minutes ago and now I cannot reproduce >>>> the problem anymore. That doesn't mean it won't appear anymore but I'll work >>>> with the pharo vm and see if it comes back. >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> Am 24.07.2013 um 22:46 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >>>> >>>>> Use the latest stable VM. It should solve the problem. >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Jul 24, 2013, at 10:34 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>>> >>>>>> >>>>>> Am 24.07.2013 um 18:21 schrieb StÃ©phane Ducasse >>>>>> <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>>> >>>>>>> On Jul 24, 2013, at 5:13 PM, Norbert Hartl <norbert(a)hartl.name> >>>>>>> wrote: >>>>>>> >>>>>>>> As I cannot work with the pharo VM right now >>>>>>> >>>>>>> what is the problem? >>>>>> >>>>>> I get the DNU SmallInteger>>add: all the time especially when using >>>>>> metacello (Using Versionner I get it nearly every attempt to validate the >>>>>> configuration). This occurred already a few times on the list. >>>>>> >>>>>> >>>>>>> >>>>>>>> I'm back to use Eliots Cog. But If I open a more recent image it >>>>>>>> complains about my vm being to old. What does it really check in order to >>>>>>>> complain? Some just version string/number parsing? Is it always sever? >>>>>>>> >>>>>>>> Norbert >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Quality cannot be an afterthought." >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Tudor Girba

Hi Norbert, In Moose, the configuration also contains a little package that comes with development tools. Among these development tools we have a couple of Moose-specific command lines. You can see a description here: http://www.tudorgirba.com/blog/moose-4-8-on-jenkins Cheers, Doru On Jul 25, 2013, at 5:10 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Cami, > > thanks for the snippet. The commandline handler for tests is a super replacement for one part of my snippet. But how do you do the lint tests? > > Norbert > > Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > >> You use the built-in command line tools and no longer .st files. >> >> Pointers: >> ========= >> curl get.pharo.org | bash >> ./pharo Pharo.image --help >> ./pharo Pharo.image --list >> ./pharo Pharo.image test --help >> # everything should be pretty self explaining >> >> >> A typical script looks like this on jenkins: >> ========================================================================== >> wget --quiet -O - get.pharo.org/20+vm | bash >> >> ./pharo Pharo.image save $JOB_NAME --delete-old >> ./pharo $JOB_NAME.image --version > version.txt >> >> REPO=http://www.squeaksource.com/MetacelloRepository >> ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests >> ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" >> >> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes >> ========================================================================== >> >> >> On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke >>> >>> HDTestReport forPackages: #( â¦) >>> >>> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like >>> >>> >>> myPrefix := 'Emcee-' >>> myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. >>> packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. >>> packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. >>> testPackages := packagesWithTests union: packagesNamedTest. >>> packages := myPackages difference: packagesNamedTest. >>> >>> HDTestReport runPackages: (testPackages collect: #name). >>> HDLintReport runPackages: (packages collect: #name) >>> >>> So I like to ask how you guys are doing it. Thanks in advance for your answers. >>> >>> Norbert >> >> > > -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

July 25, 2013

Re: [Pharo-users] Your vm is too oldâ¦.

by Tudor Girba

I meant stable, but given that I thought Norbert needs to update his local copy, I said "latest stable". Confusing :) Doru On Jul 25, 2013, at 2:00 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Something I do not understand: "Latest stable" means latest or stable ? :). More specifically, How did you download it? > > Because as far as I knew it was not fixed by Esteban in the VM... But maybe one of the latest merges with Eliot's branch fixed it... > > > On Thu, Jul 25, 2013 at 1:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 July 2013 12:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > The workaround at the image level was needed only until we got the VM > > working. The details about the workaround are here: > > https://pharo.fogbugz.com/f/cases/10395/ > > > > I was sure that in the meantime, the problem was solved in the VM as well, > > but I cannot trace that information. Perhaps it is not. Esteban? > > > > Last time i discussed with Esteban about it, he said that he don't > knows where the problem in VM, > neither me. > > > > Cheers, > > Doru > > > > > > On Thu, Jul 25, 2013 at 9:13 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> > >> On Jul 25, 2013, at 9:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> This was a problem that we also had (when working in Moose), and Esteban > >> fixed it (first the workaround in the image, and then in the VM). We are > >> using this VM since some months now and the problem did not resurface. > >> > >> That is why I know it is fixed in the latest stable PharoVM. > >> > >> > >> Ok what igor is probably meaning is that we would prefer to get the system > >> running without having to have a workaround at the image level. > >> > >> > >> Cheers, > >> Doru > >> > >> > >> On Thu, Jul 25, 2013 at 9:03 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > >>> Doru, > >>> > >>> I'm sorry but I was mistaken somehow. I tried always to use the newest > >>> VM. I just downloaded a new vm a few minutes ago and now I cannot reproduce > >>> the problem anymore. That doesn't mean it won't appear anymore but I'll work > >>> with the pharo vm and see if it comes back. > >>> > >>> thanks, > >>> > >>> Norbert > >>> > >>> Am 24.07.2013 um 22:46 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > >>> > >>> > Use the latest stable VM. It should solve the problem. > >>> > > >>> > Doru > >>> > > >>> > > >>> > On Jul 24, 2013, at 10:34 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > > >>> >> > >>> >> > >>> >> Am 24.07.2013 um 18:21 schrieb StÃ©phane Ducasse > >>> >> <stephane.ducasse(a)inria.fr>: > >>> >> > >>> >>> > >>> >>> On Jul 24, 2013, at 5:13 PM, Norbert Hartl <norbert(a)hartl.name> > >>> >>> wrote: > >>> >>> > >>> >>>> As I cannot work with the pharo VM right now > >>> >>> > >>> >>> what is the problem? > >>> >> > >>> >> I get the DNU SmallInteger>>add: all the time especially when using > >>> >> metacello (Using Versionner I get it nearly every attempt to validate the > >>> >> configuration). This occurred already a few times on the list. > >>> >> > >>> >> > >>> >>> > >>> >>>> I'm back to use Eliots Cog. But If I open a more recent image it > >>> >>>> complains about my vm being to old. What does it really check in order to > >>> >>>> complain? Some just version string/number parsing? Is it always sever? > >>> >>>> > >>> >>>> Norbert > >>> >>> > >>> >>> > >>> >> > >>> > > >>> > -- > >>> > www.tudorgirba.com > >>> > > >>> > "Quality cannot be an afterthought." > >>> > > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > >> > >> > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > -- > Best regards, > Igor Stasenko. > > -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by ClÃ©ment Bera

2013/7/25 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-07-25, at 17:10, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Cami, > > > > thanks for the snippet. The commandline handler for tests is a super > replacement for one part of my snippet. But how do you do the lint tests? > > ah sorry, didn't see that last line. I didn't add support for that, so I > guess you're stuck with the script, > > ======================================================================= > ./pharo Pharo.image eval " > ... > your code goes here > ... > " > ======================================================================= > > We have a hacked version that works from the commandline for the lint > rules in 3.0 (might still work for 2.0): > > ======================================================================= > REPO="http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main" > ./pharo Pharo.image config $REPO ConfigurationOfCommandLineMaintenanceTool > --install=stable > > # Run lint rules > ./pharo Pharo.image analyse2 >> maintenancePharo2.xml > ======================================================================= > This tool is a prototype huhum. You can have a look at: https://ci.inria.fr/pharo/job/Pharo-3.0-CodeCritics/ The script is: # install the code critics command line tool REPO="http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main" ./pharo Pharo.image config $REPO ConfigurationOfCommandLineMaintenanceTool --install=stable # Run the analysis ./pharo Pharo.image analyse >> maintenancePharo.xml ./pharo Pharo.image analyse --packages='Kernel*' >> maintenanceKernel.xml ./pharo Pharo.image analyse2 >> maintenancePharo2.xml It uses both the CodeCritics and HDLintReport Of course now Pharo analysis on this build are not run with Manifest so there is a massive number of false positive. > > but I had the impression that there are too many false positives with the > selected rules. To collect the packages you can have a look at the > CommandLineHandler subclasses (I don't remember the name for the test > runner thingy anymore in 2.0). > > > > Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > > > >> You use the built-in command line tools and no longer .st files. > >> > >> Pointers: > >> ========= > >> curl get.pharo.org | bash > >> ./pharo Pharo.image --help > >> ./pharo Pharo.image --list > >> ./pharo Pharo.image test --help > >> # everything should be pretty self explaining > >> > >> > >> A typical script looks like this on jenkins: > >> > ========================================================================== > >> wget --quiet -O - get.pharo.org/20+vm | bash > >> > >> ./pharo Pharo.image save $JOB_NAME --delete-old > >> ./pharo $JOB_NAME.image --version > version.txt > >> > >> REPO=http://www.squeaksource.com/MetacelloRepository > >> ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME > --install=$VERSION --groups='All OS',Tests > >> ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" > >> > >> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes > >> > ========================================================================== > >> > >> > >> On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >>> I'm close to having ported all of our projects to pharo 2.0. Now I'm > asking myself what would be a proper setup to run my jenkins build scripts. > With RPackage there are more packages in the system then before and in the > jenkins scripts you need to invoke > >>> > >>> HDTestReport forPackages: #( â¦) > >>> > >>> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome > to deal with. So I need to figure out the amount of tests programmatically. > The first I came up with (and that would solve my common use case) is > something like > >>> > >>> > >>> myPrefix := 'Emcee-' > >>> myPackages := RPackage organizer packages select: [:each| each name > beginsWith: myPrefix ]. > >>> packagesWithTests := myPackages select: [ :package| package classes > anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. > >>> packagesNamedTest := myPackages select: [ :each| each name > includesSubstring: '-Tests-' ]. > >>> testPackages := packagesWithTests union: packagesNamedTest. > >>> packages := myPackages difference: packagesNamedTest. > >>> > >>> HDTestReport runPackages: (testPackages collect: #name). > >>> HDLintReport runPackages: (packages collect: #name) > >>> > >>> So I like to ask how you guys are doing it. Thanks in advance for your > answers. > >>> > >>> Norbert > >> > >> > > > > > > >

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Camillo Bruni

On 2013-07-25, at 17:10, Norbert Hartl <norbert(a)hartl.name> wrote: > Cami, > > thanks for the snippet. The commandline handler for tests is a super replacement for one part of my snippet. But how do you do the lint tests? ah sorry, didn't see that last line. I didn't add support for that, so I guess you're stuck with the script, ======================================================================= ./pharo Pharo.image eval " ... your code goes here ... " ======================================================================= We have a hacked version that works from the commandline for the lint rules in 3.0 (might still work for 2.0): ======================================================================= REPO="http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main" ./pharo Pharo.image config $REPO ConfigurationOfCommandLineMaintenanceTool --install=stable # Run lint rules ./pharo Pharo.image analyse2 >> maintenancePharo2.xml ======================================================================= but I had the impression that there are too many false positives with the selected rules. To collect the packages you can have a look at the CommandLineHandler subclasses (I don't remember the name for the test runner thingy anymore in 2.0). > Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > >> You use the built-in command line tools and no longer .st files. >> >> Pointers: >> ========= >> curl get.pharo.org | bash >> ./pharo Pharo.image --help >> ./pharo Pharo.image --list >> ./pharo Pharo.image test --help >> # everything should be pretty self explaining >> >> >> A typical script looks like this on jenkins: >> ========================================================================== >> wget --quiet -O - get.pharo.org/20+vm | bash >> >> ./pharo Pharo.image save $JOB_NAME --delete-old >> ./pharo $JOB_NAME.image --version > version.txt >> >> REPO=http://www.squeaksource.com/MetacelloRepository >> ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests >> ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" >> >> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes >> ========================================================================== >> >> >> On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke >>> >>> HDTestReport forPackages: #( â¦) >>> >>> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like >>> >>> >>> myPrefix := 'Emcee-' >>> myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. >>> packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. >>> packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. >>> testPackages := packagesWithTests union: packagesNamedTest. >>> packages := myPackages difference: packagesNamedTest. >>> >>> HDTestReport runPackages: (testPackages collect: #name). >>> HDLintReport runPackages: (packages collect: #name) >>> >>> So I like to ask how you guys are doing it. Thanks in advance for your answers. >>> >>> Norbert >> >> > >

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Norbert Hartl

Cami, thanks for the snippet. The commandline handler for tests is a super replacement for one part of my snippet. But how do you do the lint tests? Norbert Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > You use the built-in command line tools and no longer .st files. > > Pointers: > ========= > curl get.pharo.org | bash > ./pharo Pharo.image --help > ./pharo Pharo.image --list > ./pharo Pharo.image test --help > # everything should be pretty self explaining > > > A typical script looks like this on jenkins: > ========================================================================== > wget --quiet -O - get.pharo.org/20+vm | bash > > ./pharo Pharo.image save $JOB_NAME --delete-old > ./pharo $JOB_NAME.image --version > version.txt > > REPO=http://www.squeaksource.com/MetacelloRepository > ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests > ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" > > zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes > ========================================================================== > > > On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke >> >> HDTestReport forPackages: #( â¦) >> >> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like >> >> >> myPrefix := 'Emcee-' >> myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. >> packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. >> packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. >> testPackages := packagesWithTests union: packagesNamedTest. >> packages := myPackages difference: packagesNamedTest. >> >> HDTestReport runPackages: (testPackages collect: #name). >> HDLintReport runPackages: (packages collect: #name) >> >> So I like to ask how you guys are doing it. Thanks in advance for your answers. >> >> Norbert > >

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Camillo Bruni

You use the built-in command line tools and no longer .st files. Pointers: ========= curl get.pharo.org | bash ./pharo Pharo.image --help ./pharo Pharo.image --list ./pharo Pharo.image test --help # everything should be pretty self explaining A typical script looks like this on jenkins: ========================================================================== wget --quiet -O - get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME --delete-old ./pharo $JOB_NAME.image --version > version.txt REPO=http://www.squeaksource.com/MetacelloRepository ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes ========================================================================== On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke > > HDTestReport forPackages: #( â¦) > > In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like > > > myPrefix := 'Emcee-' > myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. > packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. > packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. > testPackages := packagesWithTests union: packagesNamedTest. > packages := myPackages difference: packagesNamedTest. > > HDTestReport runPackages: (testPackages collect: #name). > HDLintReport runPackages: (packages collect: #name) > > So I like to ask how you guys are doing it. Thanks in advance for your answers. > > Norbert

July 25, 2013

How are you doing your jenkins build scripts?

by Norbert Hartl

I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke HDTestReport forPackages: #( â¦) In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like myPrefix := 'Emcee-' myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. testPackages := packagesWithTests union: packagesNamedTest. packages := myPackages difference: packagesNamedTest. HDTestReport runPackages: (testPackages collect: #name). HDLintReport runPackages: (packages collect: #name) So I like to ask how you guys are doing it. Thanks in advance for your answers. Norbert

July 25, 2013

Re: [Pharo-users] What is the project repository for ci build tools

by StÃ©phane Ducasse

>> >> >> There was Lukas' repository before, and we just loaded that on the build server >> Then this was down for some weeks and we put it here: >> >> http://www.squeaksource.com/PharoHudson.html >> >> then we did put it in the image by default and we changed it for the FilesSystem refactoring >> (maybe other changes?) that where specific to Pharo. >> > OMG I was just too stupid to see that it is already in the image and my older jenkins setup just overwrote it with an older/inappropriate version. > >> We need to improve how to merge to and from external repositories, we now use a lot >> (Opal, Athens, Nativboost, SpecDebuggers) and it gets quite hard to manage. > > Agreed. What annoys me most is the chaos in repositories we got from Lukas server instability then squeaksource instability then short time usage of squeaksource3 and now smalltalkhub. There are so much repositories out there that look nearly the same. So, everyone of you which knows some of the repositories should either shut the obsolete ones down or where possible add a comment with a pointer to the actual repository. Yes I started to do that systematically. And we should all continue. Each time you need something from Squeaksource. We should migrate it to SmalltalkHub. > > Norbert

July 25, 2013

Re: [Pharo-users] What is the project repository for ci build tools

by StÃ©phane Ducasse

When I finish the catalog and the first release of the SystemLogger I will work on the management of Pharo using Metacello I will not do anything beside Morph cleaning because I want to make progress on a minimal image. Stef On Jul 25, 2013, at 2:50 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 25, 2013, at 12:03 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I try to figure out where is the home project location of >> >> HudsonBuildTools20 >> >> I can only see it in pharo20/pharoInbox >> >> > > > > There was Lukas' repository before, and we just loaded that on the build server > Then this was down for some weeks and we put it here: > > http://www.squeaksource.com/PharoHudson.html > > then we did put it in the image by default and we changed it for the FilesSystem refactoring > (maybe other changes?) that where specific to Pharo. > > We need to improve how to merge to and from external repositories, we now use a lot > (Opal, Athens, Nativboost, SpecDebuggers) and it gets quite hard to manage. > > Marcus > >

July 25, 2013