- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Hackathon IoT. I used Pharo.

by Serge Stinckwich

Great ! What did you exactly, I'm interested by details ;-) 2016-02-22 14:42 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > http://geeko.lesoir.be/2016/02/22/hackapost-un-hackathon-sur-les-applis-iot… -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Feb. 22, 2016

Re: [Pharo-dev] Smalltalkhub scheduled maintenance today (February, 22nd)

by Stephan Eggermont

On 22-02-16 13:42, Christophe Demarey wrote: > Smalltalkhub is now back on line! Thanks for taking care! Stephan

Feb. 22, 2016

Hackathon IoT. I used Pharo.

by phil＠highoctane.be

http://geeko.lesoir.be/2016/02/22/hackapost-un-hackathon-sur-les-applis-iot…

Feb. 22, 2016

Re: [Pharo-dev] Any download statistics for Pharo

by Marcus Denker

> On 20 Feb 2016, at 11:15, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Hi, > > do we have any download statistics for Pharo? > > No. Marcus

Feb. 22, 2016

Re: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

by Sven Van Caekenberghe

> On 20 Feb 2016, at 12:34, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > Ah, test testMetaclass. Somehow I only read testClass.... > > Moving those two methods from Metaclass to TApplyingOnClassSide should make the test happy. Well, that looked strange at first, but I studied it a bit further and you are most probably right. I decided to move the methods. Thx > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe > Sent: Saturday, February 20, 2016 11:58 AM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules > > If I add (in #50591) my methods to the exception set in the middle, the test is green > > self > assert: > (Metaclass localSelectors difference: ClassTrait localSelectors) > = > {#externalTypeAlias:. > #baseClass. > #basicLocalSelectors:. > #basicLocalSelectors. > #classClass. > #isClass. > #stonName. "<<<" > #stonOn:. "<<<" > #environment. > #fileOutOn:. > #fileOutOn:initializing:. > #postCopy. > #traitComposition. > #traitComposition:. > #veryDeepCopyWith:} asSet. > > I don't know about the other failures. > >> On 20 Feb 2016, at 11:37, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >> >> The issue should be unrelated: >> >> https://pharo.fogbugz.com/f/cases/17616/CI-Server-Failing-tests-related-to-… >> >> Best regards, >> Henrik >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe >> Sent: Saturday, February 20, 2016 11:05 AM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules >> >> Hi, >> >> I am trying to load a new version of STON in Pharo 5 >> >> https://pharo.fogbugz.com/f/cases/16893/Update-STON >> >> One of the tests that fails is MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules >> >> More specifically, (Metaclass localSelectors difference: ClassTrait localSelectors) is no longer equal to the exceptions defined in the test because #stonName and #stonOn: were added to Metaclass >> >> What should I do ? Did I do something wrong ? >> >> Should I add to the exceptions defined in the test or should I add them to ClassTrait ? >> >> I think the first sounds the most correct. >> >> Thx, >> >> Sven >> >> > > >

Feb. 22, 2016

Re: [Pharo-dev] Yet again, wrong tempvars in debuggers context variables list

by Marcus Denker

> On 22 Feb 2016, at 10:27, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Hmm, I know that the Spur bootstrap does a lot of changes "in the background". For example, it replaces literals in methods (Float->BoxedFloat64), plus it inlines all immediate characters. > > I do not know if it is related, but this could be a side effect, and it would explain why there is no evident change causing this. > We should have recompiled the whole image afterâ¦ lets do this soon and see. > > On 02/22/2016 09:08 AM, Nicolai Hess wrote: >> >> >> 2016-02-20 20:31 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com> <mailto:nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>>: >> >> >> >> 2016-02-20 19:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com> >> <mailto:nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>>: >> >> This is not an issue with GTDebugger, but the way opal >> generates the tempvar >> index or the way, debuggerMap tries to access the context vars >> >> 17660 >> <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger>> >> wrong tempvar values in debugger >> >> >> This is a really special case, I wasn't able yet to create an >> easier example for reproducing this bug: >> - put a self haltOnce in >> RAbstractClass>>#directlyDefinesLocalMethod: >> - enable halt once >> - select any other method in Nautilus and choose >> "Rename method (all)" from method panes context menu >> - enter a new name and push "OK" >> -> the debugger pops up in method >> directlyDefinesLocalMethod: >> - select the first "allClassesDo:" context from top of the stack >> -> the debugger shows that we are in the evalBlock context >> The "seen" variable is a Set, but if you look at the >> "Variables"-pane, it is shown >> as a block (this is actually the parameter aBlock) >> >> >> again, this is caused by a change for spur migration >> >> This worked up to pharo 50496 >> starting with pharo 50497, the order of variables has changed. >> >> see >> http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html <http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html> >> <https://pharo.fogbugz.com/f/cases/17241/ffi-nb-is-not-cleaning-compiled-met… <https://pharo.fogbugz.com/f/cases/17241/ffi-nb-is-not-cleaning-compiled-met…>> >> >> >> Any idea what has changed? >> I could not spot a change that could be responsible for this. >> The order of tempvars in a block context somehow changed, and the way the debugger accesses the temps >> by name (get an index and access the context temp vars by index) somehow changed. >> Recompiling the affected methods helps, but I would like to know if this change (where is it?) was on purpose.

Feb. 22, 2016

Re: [Pharo-dev] [Pharo-users] Who is using Pharo Launcher and for what

by Damien Cassou

Tudor Girba <tudor(a)tudorgirba.com> writes: > I use it for writing documentation and blog posts. what is the relationship between Pharo Launcher and your documentation and blog posts? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 22, 2016

Re: [Pharo-dev] Fuel bug. Array class substitution is not working

by Max Leske

No, this is definitely not intended to fail. Weâll take a look. > On 22 Feb 2016, at 13:07, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > And maybe it is not issue and behaviour is correct. > > We want to substitute class with some object but full object graph includes instance of that class. In such case Fuel will use substitution as reference to class of serializable instance. And on materialisation substitution can not understand #fuelNew: protocol. > > 2016-02-22 11:36 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > Hi. > > I detect strange bug. Substitution Array class is not working. Try this: > > s := ByteArray new writeStream. > serializer := FLSerializer newDefault. > serializer analyzer > when: [ :o | o==Array ] > substituteBy: [ :o | #instead ]. > serializer serialize: {Array} on: s > . > s2 := s contents readStream. > > > object := (FLMaterializer newDefault materializeFrom: s2) root. > > > Interesting that other classes are working correctly. > I open issue 17669 <https://pharo.fogbugz.com/f/cases/17669/Fuel-substitution-for-Array-class-i…>

Feb. 22, 2016

Re: [Pharo-dev] CI locked up

by Max Leske

Thanks Christophe. > On 22 Feb 2016, at 12:16, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Max, > > 2 slaves were off line. > I put them back on line and purged the queue. > > > Le 20 fÃ©vr. 2016 Ã 23:05, Max Leske a Ã©crit : > >> Hey, >> >> The queue on the CI is overflowing. Not sure whatâs wrong but builds donât seem to finish. >> >> Cheers, >> Max > >

Feb. 22, 2016

Re: [Pharo-dev] Smalltalkhub scheduled maintenance today (February, 22nd)

by Christophe Demarey

Smalltalkhub is now back on line! Le 22 fÃ©vr. 2016 Ã 10:59, Christophe Demarey a Ã©crit : > Hello, > > Smalltalk will be down today (february, 22nd) from 12:30 to 13:30 (french local time). > IT will add storage to the root partition (last maintenance finally did not take place). > > Regards, > Christophe

Feb. 22, 2016