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

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