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

Re: [Pharo-dev] Xtreams in Pharo 3

by Sven Van Caekenberghe

On 19 Nov 2013, at 17:48, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Nov 19, 2013, at 5:40 PM, btc(a)openinworld.com wrote: > >> So does that mean that Xtreams might go into the Pharo 3 Release as a technology preview in parallel with the existing streams, with the aim of replacing existing streams in Pharo 4? The advantage for users would be enhanced certainty that the future is Xtreams. In the year between Pharo3 and Pharo4 users could develop their application against Xtreams such that migrating from Pharo 3 to Pharo 4 is simplified. > > sorry, but no. > we are freezing Pharo 3 this week and we didn't even think before on including Xtream in this version *(bah, we though at the beginning of the year and we discarded because no one was able to take care and spend time on it). > > but... I would really like to have it in Pharo 4 :) For now, the goal should be: âmake it easily loadableâ (using the Configuration Browser) and keep it maintained. Only then can we take the next step (of what will be a long road). > cheers, > Esteban > >> >> cheers -ben >> >> Esteban A. Maringolo wrote: >>> 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] Xtreams in Pharo 3

by btc＠openinworld.com

Nov. 19, 2013

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

by Sven Van Caekenberghe

less noise = better Thx! On 19 Nov 2013, at 17:37, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I think I fixed them by skipping a test. > > On 2013-11-19, at 13:43, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> 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

Re: [Pharo-dev] Pharo Inbox Commits

by Esteban Lorenzano

done :) On Nov 19, 2013, at 5:56 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Hi guys, can someone give me commit permissions to Pharo30Inbox? My sthub username is gcotelli. > > Thanks, Gabriel

Nov. 19, 2013

Pharo Inbox Commits

by Gabriel Cotelli

Hi guys, can someone give me commit permissions to Pharo30Inbox? My sthub username is gcotelli. Thanks, Gabriel

Nov. 19, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Esteban Lorenzano

On Nov 19, 2013, at 5:40 PM, btc(a)openinworld.com wrote: > So does that mean that Xtreams might go into the Pharo 3 Release as a technology preview in parallel with the existing streams, with the aim of replacing existing streams in Pharo 4? The advantage for users would be enhanced certainty that the future is Xtreams. In the year between Pharo3 and Pharo4 users could develop their application against Xtreams such that migrating from Pharo 3 to Pharo 4 is simplified. sorry, but no. we are freezing Pharo 3 this week and we didn't even think before on including Xtream in this version *(bah, we though at the beginning of the year and we discarded because no one was able to take care and spend time on it). but... I would really like to have it in Pharo 4 :) cheers, Esteban > > cheers -ben > > Esteban A. Maringolo wrote: >> >> 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] Convert to Athens

by J.F. Rick

Indeed. I would like to know that. It doesn't seem to be included in the latest Pharo 3.0. Cheers, Jeff On Fri, Nov 15, 2013 at 7:34 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Le 15/11/2013 14:17, Igor Stasenko a Ã©crit : > > > > for transition , i implemented a special morph, AthensWrapMorph > > which wraps (as its name says) its children morphs and forces them to be > > rendered by athens > > (the child morphs will never receive #drawOn: but #drawOnAthensCanvas: > > instead ). > > > I guess Jeff, may want to know where to find this wrapper. > > Hilaire > > > -- > Dr. Geo http://drgeo.eu > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Nov. 19, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by btc＠openinworld.com

Nov. 19, 2013

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

by Camillo Bruni

I think I fixed them by skipping a test. On 2013-11-19, at 13:43, Camillo Bruni <camillobruni(a)gmail.com> wrote: > 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

SHTextStyler>>#styleInBackgroundProcess:

by Sven Van Caekenberghe

In many images that I do real development in (code writing, debugging, ..) I always get a number of processes stuck while waiting for a semaphore in SHTextStyler>>#styleInBackgroundProcess: I am in no way an expert in these areas, but today I tried the following change (waiting on the semaphore with a timeout): SHTextStyler>>#styleInBackgroundProcess: aText self terminateBackgroundStylingProcess. stylingEnabled ifTrue: [ text := aText copy. self monitor critical: [ sem := Semaphore new. [ sem ifNotNil: [ ((sem waitTimeoutMSecs: 250) not and: [ view notNil ]) ifTrue: [ view stylerStyledInBackground: text ] ] ] forkAt: Processor activePriority. backgroundProcess := [ self privateStyle: text. sem signal ] forkAt: Processor userBackgroundPriority ] ] Comments ? Sven

Nov. 19, 2013