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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 2 regressions found. Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 1, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=li… 1 regressions found. Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Oct. 1, 2013

[update 3.0] #30435

by Marcus Denker

Oct. 1, 2013

Re: [Pharo-dev] unexpected lack of Method Version History (due to CI process?)

by Marcus Denker

On Oct 1, 2013, at 3:54 AM, btc(a)openinworld.com wrote: > Marcus Denker wrote: >> >> On Sep 30, 2013, at 5:40 PM, btc(a)openinworld.com wrote: >> >> >>> In the process of reviewing a fix to an issue [1] that I reported with PharoLauncher, I downloaded the latest CI result and browsed to the method I knew had changed [2]. I wanted to directly observe the change in the version history, but was surprised that there was no version history for the method. My uninformed intuition is this relates to some 'clean up for release' run as part of the build process to strip out old versions to compact the image delivered by the CI process, but does it make sense to do this for every build? >>> I can understand not wanting this to grow indefinitely to bloat the image - but perhaps this compaction would be better only for major releases? I guess the downside is that you are then not exercising the 'full release' process every build. However having in image Version History extending a fair way back in time has always seemed to me to be one of the very cool (i.e. useful features of Pharo/Smalltalk). Without this, it feels like 'something' has been lost. The ultimate solution would seem to be linking the method version history to a network resource for the full history only as required per method. Any chance anyone is working on something like that? >>> >>> >> >> Keep in mind that the .changes history and monticello are completely separate. When you load a mc version, you just load *that version*. >> > Thanks Marcus. I guess I have got too used working continuously in the one image and had not explicitly considered that. So obviously this will be the case for all packages that build on top of the Pharo-CI builds. > yes > However my understanding is the Pharo mainline CI is currently a continous load of sequential slices (until its CI build is fully bootstrapped). yes > So each load of a slice would grow the version history - and I guess that might be compacted when 3.0 is released. (??) . yes, because the .changes is already very large again. (ceterum censeo: we need to get rid of .changes and .sources!) > S > o what I'm wondering is if the 3.0 summer/winter maintenance releases shouldn't do the same compaction to discard the version history. Or is this how it works already? Yes, we kill it shortly before the release. >> We really need to have the "versions" of the method go and ask the repo. Now the problem is that Monticello is not really nice: it has complete snapshots per commit in a zip file. >> Getting version out there of a method is not possibleâ¦ without building infrastructure for it. >> >> Marcus >> > > If no one gets to it earlier, that might make a nice GSoC project for next year. > yes. Marcus

Oct. 1, 2013

Re: [Pharo-dev] XMLParser & PharoExtras, XMLWriter, XPath: status?

by HernÃ¡n Morales Durand

El 29/09/2013 11:01, StÃ©phane Ducasse escribiÃ³: > cool is it standalone? Yes > Could you add the catalog metadata and publish it in metarepository like that it will be documented on the catalog. > You can take as example Soup or OSC on PharoExtras > Done. I have added usage example. Let me know if anything is missing. Cheers, HernÃ¡n > Stef > On Sep 29, 2013, at 12:42 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > >> Already migrated >> >> http://www.smalltalkhub.com/#!/~hernan/XMLPullParser >> >> I use it a lot to parse really big XMLs >> >> El 29/09/2013 7:05, StÃ©phane Ducasse escribiÃ³: >>> It would be good to migrate this one >>> XMLPullParser >>> <http://pharo.gemtalksystems.com/book/LanguageAndLibraries/XML/XML-support-i…> : >>> Supports StAX. http://www.squeaksource.com/XMLPullParser.html to >>> smalltalkhub. >>> Does anybody use it? >>> >>> On Sep 28, 2013, at 11:42 PM, HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>> >>>> El 28/09/2013 14:38, phil(a)highoctane.be <mailto:phil@highoctane.be> >>>> escribiÃ³: >>>>> In the Pharo 20 image, I see that we do have XMLParser, XMLPullParser, >>>>> XMLWriter and XPath listed in the configuration (new install with >>>>> ZeroConf). >>>>> >>>>> I am also using Soup. >>>>> >>>>> That's because I am working on some OpenData and screen scraping work >>>>> and wondered what was okay to use. >>>>> >>>>> Is Soup depending on these? (I have XMLReader and Writer in my image but >>>>> don't know from where at the moment - but there are no tests, so only >>>>> something like #Core was loaded. >>>>> >>>>> Also what is different between XMLParser and XMLPullParser? >>>>> >>>> >>>> http://pharo.gemtalksystems.com/pier/book/LanguageAndLibraries/XML/XML-supp… >>>> >>>>> TIA >>>>> Phil >>>> >>>> >>> >> >> > > >

Oct. 1, 2013

Re: [Pharo-dev] Weird issue with removing instance vars from class def: instance vars jumbled

by btc＠openinworld.com

phil(a)highoctane.be wrote: > I guess this has happened to other people. > > In Pharo 20 and while using Seaside, I was adding, removing , changing > components which were making a component and it happened that if I had, let > say: > > a b c d e f > > turned into > > a c f > > Well, c kind of pointed to a b in existing instances and f to old c etc; > > No matter how much I unregister and reregisted my app, this continued. > I got out of the problem by filing out the code and filing it in back, > which recomplied the whole component. > How do you go with just a "Compiler recompileAll" on its own ? > Weird. > > I can understand that some existing bytecode wasn't updated when > rearranging instvars but for someone new to the game, this would really be > weird. > > Clues? > > Phil > >

Oct. 1, 2013

Re: [Pharo-dev] unexpected lack of Method Version History (due to CI process?)

by btc＠openinworld.com

Oct. 1, 2013