- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] class HTTPSocket

by Marcus Denker

On 19 Nov 2013, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > HTTPSocket (which is only a facade) was deprecated in 2.0, so I guess it could be completely removed in 3.0 ? > Yes! Marcus

Nov. 19, 2013

class HTTPSocket

by Sven Van Caekenberghe

Hi, HTTPSocket (which is only a facade) was deprecated in 2.0, so I guess it could be completely removed in 3.0 ? Sven

Nov. 19, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Marcus Denker

On 19 Nov 2013, at 16:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 18 Nov 2013, at 23:12, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> The tests pass with this hack PEGInfinity>>adaptToInteger: anInteger andCompare: selector >> "This makes optimized inlining of timesRepeat: work." >> ^#( < <= ~= ) includes: selector > > I asked Marcus for the way to do it, and if you add: > > PEGParser class>>#compiler > ^ super compiler > options: #(- optionInlineTimesRepeat); > yourself > > And do a > > PEGParser recompile > > All tests in Xtreams-ParsingTests should be green. > >> But then they take 10 times longer than Squeak thanks to timesRepeat: inlining "optimization". >> Maybe timesRepeat: inlining should be restricted to the case when receiver is an integer literal... Or just removed. > > I am not sure I understand, that is more for the compiler guys. I do not understand that sentence either, but I guess there is information missing. Marcus

Nov. 19, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Sven Van Caekenberghe

On 18 Nov 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. > It could go into Xtreams-Support... OK, are you going to check this in, or should I ? How are we going to deal with platform specific stuff (like the Opal compiler switch) ? Sven

Nov. 19, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Sven Van Caekenberghe

On 18 Nov 2013, at 23:12, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The tests pass with this hack PEGInfinity>>adaptToInteger: anInteger andCompare: selector > "This makes optimized inlining of timesRepeat: work." > ^#( < <= ~= ) includes: selector I asked Marcus for the way to do it, and if you add: PEGParser class>>#compiler ^ super compiler options: #(- optionInlineTimesRepeat); yourself And do a PEGParser recompile All tests in Xtreams-ParsingTests should be green. > But then they take 10 times longer than Squeak thanks to timesRepeat: inlining "optimization". > Maybe timesRepeat: inlining should be restricted to the case when receiver is an integer literal... Or just removed. I am not sure I understand, that is more for the compiler guys. > 2013/11/18 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. > It could go into Xtreams-Support... > > For PEG parsing test, I think you are right, this is timesRepeat: > They passed in Squeak last time I tried. > But these are advanced features not required for legacy Stream replacement. > > > 2013/11/18 Esteban A. Maringolo <emaringolo(a)gmail.com> > > One more reason to look after Pharo 3 :) > Esteban A. Maringolo > > > 2013/11/18 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > > > This evening I tried to load Nicolas Cellierâs Xtreams (http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost flawless ! > > > > I went for > > > > ConfigurationOfXtreams project bleedingEdge load. > > > > which loaded > > > > a MetacelloFetchingMCSpecLoader(linear load : > > linear load : 1.3-baseline [ConfigurationOfXtreams] > > load : Xtreams-Support-nice.11 > > load : Xtreams-Core-nice.20 > > load : Xtreams-Terminals-nice.31 > > load : Xtreams-Transforms-nice.23 > > load : Xtreams-Substreams-nice.19 > > load : Xtreams-CoreTests-nice.20 > > load : Xtreams-TerminalsTests-nice.17 > > load : Xtreams-TransformsTests-nice.14 > > load : Xtreams-SubstreamsTests-nice.13 > > load : Xtreams-Parsing-cwp.6 > > load : Xtreams-ParsingTests-cwp.5 > > load : Xtreams-TerminalsFileSystem-nice.3 > > load : Xtreams-TerminalsFileSystemTests-nice.2) > > > > There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo). > > > > Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ? > > > > Running the tests resulted in some external semaphore warnings in the Transcript. > > > > I also loaded Nicolasâ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), Iâll have to study that, it sure looks interesting. > > > > In any case: great work, thanks Nicolas ! > > > > Sven > > > > > > >

Nov. 19, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Sven Van Caekenberghe

On 19 Nov 2013, at 16:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi, >> >> It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? >> > RBMessageNode has #isInlined that returns trueâ¦ not all cases where the selector is send it is optimised, so a list would be one of âpossiblyoptimizedâ selectorsâ¦ > maybe #isInlined could check first against that list to quickly return false for all the other selectors. > >> In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. >> > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly re-compiling and executing the ifTrue:, but itâs a bit of work to get it right for all casesâ¦ so we did not finish > that. But it would be possible... > >> Is there a way to tune this ? >> Can it be set at a level higher than in each method ? >> > > Yes, you can do it per class-hierarchyâ¦ you can implement on the class side a method to parametrize the compiler: > > compiler > ^super compiler options: #(- optionInlineTimesRepeat) Thanks, Marcus, that works just great. Sven > Marcus > > >

Nov. 19, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Marcus Denker

On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? > RBMessageNode has #isInlined that returns trueâ¦ not all cases where the selector is send it is optimised, so a list would be one of âpossiblyoptimizedâ selectorsâ¦ maybe #isInlined could check first against that list to quickly return false for all the other selectors. > In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly re-compiling and executing the ifTrue:, but itâs a bit of work to get it right for all casesâ¦ so we did not finish that. But it would be possible... > Is there a way to tune this ? > Can it be set at a level higher than in each method ? > Yes, you can do it per class-hierarchyâ¦ you can implement on the class side a method to parametrize the compiler: compiler ^super compiler options: #(- optionInlineTimesRepeat) Marcus

Nov. 19, 2013

Tuning Opal Optimizations

by Sven Van Caekenberghe

Hi, It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. Is there a way to tune this ? Can it be set at a level higher than in each method ? Sven

Nov. 19, 2013

CodePharo

by Esteban A. Maringolo

Firefox foundation just released a curriculum to get developers acquainted with the process of contributing to Firefox. Which itself guides in the completion and extension of it. http://codefirefox.com/ I know there are some videos guiding Pharo contributors in the process of reporting bugs, submitting patches, etc. It could be great if we could mimic the CodeFirefox initiative with a CodePharo one. I know this requires time, but I shoot the idea to this mailing list, maybe somebody is willing to give it a try, or at least park the domain (or subdomain code.pharo.org) Regards! Esteban A. Maringolo

Nov. 19, 2013

Re: [Pharo-dev] [Pharo-bugtracker] FogBugz (Case [Issue]9) _Inbox - Back In Town

by Camillo Bruni

I presume one of the FogBugz API test cases does this. Though not sure. I currently don't have time to look into it. Sources: http://smalltalkhub.com/#!/~Pharo/ci On 2013-11-19, at 13:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Among the many messages sent automatically by our magic systems, this one strikes me as useless. It basically says that the monkey is doing something, without being specific: no issue number, nothing. > > Begin forwarded message: > >> From: "Pharo Issue Tracker" <do-not-reply(a)pharo.fogbugz.com> >> Subject: [Pharo-bugtracker] FogBugz (Case [Issue]9) _Inbox - Back In Town >> Date: 19 Nov 2013 13:28:23 GMT+1 >> To: "pharo-bugtracker(a)lists.gforge.inria.fr" <pharo-bugtracker(a)lists.gforge.inria.fr> >> >> A FogBugz case was edited by Ulysse The Galactic Monkey From Outer Space. >> >> Case ID: 9 >> Title: Back In Town >> Status: Closed (Invalid) >> Category: Bug >> Project: _Inbox >> Area: Not Spam >> Priority: 3 - Must Fix >> Milestone: Undecided >> Assigned To: CLOSED >> >> URL: https://pharo.fogbugz.com/f/cases/9 >> >> Communicating from Pharo >> >> >> You are subscribed to this case. If you do not want to receive automatic notifications in the future, unsubscribe (https://pharo.fogbugz.com/default.asp?pre=preUnsubscribe&pg=pgEditBug&comma…) from this case. >> >> _______________________________________________ >> Pharo-bugtracker mailing list >> Pharo-bugtracker(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > >

Nov. 19, 2013