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

Re: [Pharo-dev] Xtreams in Pharo 3

by Nicolas Cellier

I don't like the Squeak encoders with all the basicNext & co complications, it cries for rewriting. In Xtreams, I just included a compatibility layer for legacy text converters, because it was the fastest ROI. But in my pre-Xtreams attempt, I previously started rewriting the most common (UTF8 & UTF16) - see http://www.squeaksource.com/XTream.html. I saw that you did the same in Zn, so I agree that it is the way to go. I'd just like those classes to loose their XT or Zn prefix, they are common stuff... 2013/11/20 Frank Shearar <frank.shearar(a)gmail.com> > On 20 November 2013 16:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Nicolas, > > > > On 19 Nov 2013, at 23:50, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > >> For the OpalCompiler support, I have simply added the compiler method > in Xtreams-Parsing because it does not conflict with anything else, I have > the feeling that this is bearableâ¦ > > > > OK > > > >> I have also added a NotFoundError subclass of NotFound in > Xtreams-support. > >> It's not ideal. That also means that bleeding-edge will not load in > Squeak 4.4 or older, and maybe not elder version of Pharoâ¦ > >> Maybe I could have changed NotFoundError reference into NotFound? > > > > NotFound is in Pharo 2.0 as well. > > > > I wonder if it is really necessary to use the VW name/alias, as it is > not referenced, but OK, it could be. I donât think it is as much part of > the API as Incomplete is. > > > >> In the future, or if we really want a bleeding edge in elder images, we > may have to fork the Xtreams-support, but as long as we can, it's better to > avoid it. > > > > I think that it would be good to keep this a cross platform project (as > it spans multiple platforms already). But that requires effort (at least, > basic interest, maintenance from multiple people on different platforms). > Fuel proves that it can be done. > > Indeed! > > > I think it is unavoidable to have some specific code per platform, > especially in Support. But indeed, not for the sake of it. > > > > I was looking around in the source code and saw some places where I > could imagine things being done differently (ZnCharacterEncoders in Pharo > are properly Character <> Binary). > > > > BTW, does TerminalsFileSystem work on Squeak or is it Pharo specific. > Because FileUrl is on its way out (replaced by ZnUrl). The #reading, > #writing, #appending messages on FileUrl, in their current implementation, > strike me as a bit out of place (as far as I can see, they are not in the > VW code either). I mean, I could image #reading or #writing am HTTP Url as > well, though that would not necessarily the best design. Doing a > #asFileReference in between is acceptable and clearer. > > It's Pharo specific at the moment AFAICT because it refers to > FileHandle and FileReference, while the upstream repo uses > FSFileHandle and FSFileReference. The conversation's partly at > https://code.google.com/p/xtreams/issues/detail?id=2 > > > Are there any areas in the port of Xtreams that need more work, or do > you consider the current situation as complete enough ? In other words, is > there a todo list ? > > > > Are there version differences with the VW code, and how do you see that > evolving ? > > Without answering for Nicolas, > https://code.google.com/p/xtreams/issues/detail?id=3 has Martin > Kobetic saying > > <quote> > Regarding integration, I'd say getting the agreement of the > Squeak/Pharo group should suffice to get it into the Pharo/Squeak > port. Hopefully we will get a reasonable setup for crosspolination > among the dialects eventually, but until then I'd hate to see > evolution hampered because e.g. VW is declared the reference > implementation and nothing is "officially" accepted until VW has it or > some silly rule like that. > > I would only suggest to exercise restraint and avoid uncontrolled > growth of the core framework as a general principle. Only things that > are generally useful and that provide more than a marginal benefit > should be added to the core. It's perfectly fine to make special > purpose streams, and the core framework must always preserve the ease > of doing that, but those streams themselves should live in their > respective projects. > </quote> > > frank > > > Sven > > > >> 2013/11/19 Sven Van Caekenberghe <sven(a)stfx.eu> > >> > >> 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. 20, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Nicolas Cellier

The only thing that annoyed me is that I failed to discover the incantation thru sender/implementor chain because some messages are constructed... I tried the senders of timesRepeat: then the senders of corresponding visitor message (no image near my keyboard to check the name). Of course, once you've learned the incantation, it's OK... 2013/11/20 Igor Stasenko <siguctua(a)gmail.com> > > > > On 19 November 2013 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) >> >> > .. and i feel really glad that Marcus armed my idea of option > specification e.g. > > #(+ optionToEnable1 - optionToDisable anotherOptionToDisable + > optionToEnable2 ) > > :) > > >> Marcus >> >> >> >> > > > -- > Best regards, > Igor Stasenko. >

Nov. 20, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Sven Van Caekenberghe

On 20 Nov 2013, at 17:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sven Van Caekenberghe-2 wrote >> Are there version differences with the VW code, and how do you see that >> evolving ? > > When we looked a few years ago at ESUG in Ghent, the port was out-of-date > with the VW code. We were able to patch filetree to bring the code > round-trip to/from VW, mapping namespaces to prefixes. I have our > experimental image somewhere if that would be helpfulâ¦ Well, years, not last ESUG but the one before, August 2012, and yes I remember, sitting next to you when you were hacking away. Maybe, you and Nicolas should sync up a bit. > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Xtreams-in-Pharo-3-tp4723225p4723773.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 20, 2013

Re: [Pharo-dev] Spotlight behaviour

by phil＠highoctane.be

Oooooohhhh --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Wed, Nov 20, 2013 at 2:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > :) > > > I'm slowly working in a darktheme... problem is the INCREDIBLE amount of > hardcode colors and silly code. > So it will take some time until is ready (also because I work on it when > I'm bored and not wanting to do what I should do... like today :P) > > Esteban > > > On Nov 20, 2013, at 2:34 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > yes I can confirm that this work also on windoom 7. Indeed Sven your Pharo > looks a bit more sexy than mine. > > the code you posted works also like a charm for me , thank you. Now If I > could get also a dark theme working with pharo that would be awesome. All > this white hurts my eyes. But I guess I will have to compromise for the > time being :) > > thank you > > > On Wed, Nov 20, 2013 at 2:58 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> >> On 20 Nov 2013, at 13:46, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> > Sven. >> > >> > What version are YOU using? Fonts and windows look so clean an sharp! :) >> >> ;-) >> >> Yes they are. >> >> Like I said, Pharo version #30582 >> >> defaultFont Source Sans Pro Normal points: 12 height: 21 >> listFont Source Sans Pro Normal points: 12 height: 21 >> menuFont Source Sans Pro Normal points: 12 height: 21 >> windowTitleFont Source Sans Pro Bold points: 12 height: 21 >> balloonFont Source Sans Pro Normal points: 9 height: 16 >> codeFont Source Code Pro Normal points: 11 height: 19 >> buttonFont Source Sans Pro Normal points: 12 height: 21 >> haloFont Source Sans Pro Normal points: 9 height: 16 >> >> Installed with a script from our local look and feel guru, Doru: >> >> #('SourceCodeProRegular' 'SourceCodeProBold' 'SourceSansProRegular' >> 'SourceSansProBoldâ) >> do: [ :each | >> Smalltalk globals >> at: each asSymbol >> ifAbsent: [ >> Gofer new >> smalltalkhubUser: 'girba' project: 'FreeFonts'; >> package: each; >> load ]. >> (Smalltalk at: each asSymbol) new install ]. >> FreeTypeSystemSettings loadFt2Library: true. >> FreeTypeFontProvider current updateFromSystem. >> >> StandardFonts >> setAllStandardFontsTo: (LogicalFont familyName: 'Source Sans Pro' >> pointSize: 12); >> haloFont: (LogicalFont familyName: 'Source Sans Pro' pointSize: 9); >> windowTitleFont: (LogicalFont familyName: 'Source Sans Pro Bold' >> pointSize: 12); >> balloonFont: (LogicalFont familyName: 'Source Sans Pro' pointSize: 9); >> codeFont: (LogicalFont familyName: 'Source Code Pro' pointSize: 11). >> >> And then I finally make the window font bold, manually. >> >> The screenshot was done on Mac OS X 10.9 >> >> HTH, >> >> Sven >> >> > Esteban A. Maringolo >> > >> > >> > 2013/11/20 Sven Van Caekenberghe <sven(a)stfx.eu> >> > What version are you using ? >> > >> > In #30582 it does work: >> > <Screen Shot 2013-11-20 at 13.34.46.png> >> > >> > You can always try typing a space after Objectâ¦ >> > >> > Sven >> > >> > On 20 Nov 2013, at 13:23, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> HI, >> >> >> >> do you know why search behaves like this? I was expecting Object to >> show up >> >> >> >> <Screenshot 2013-11-20 13.20.40.png> >> >> >> >> >> >> Cheers >> >> Uko >> > >> > >> >> >> > >

Nov. 20, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Are there version differences with the VW code, and how do you see that > evolving ? When we looked a few years ago at ESUG in Ghent, the port was out-of-date with the VW code. We were able to patch filetree to bring the code round-trip to/from VW, mapping namespaces to prefixes. I have our experimental image somewhere if that would be helpful... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-in-Pharo-3-tp4723225p4723773.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

by Sean P. DeNigris

Sean P. DeNigris wrote > Ping ;) I'm stuck... Perhaps Igor prefers "bump"... ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Frank Shearar

On 20 November 2013 16:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Nicolas, > > On 19 Nov 2013, at 23:50, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> For the OpalCompiler support, I have simply added the compiler method in Xtreams-Parsing because it does not conflict with anything else, I have the feeling that this is bearableâ¦ > > OK > >> I have also added a NotFoundError subclass of NotFound in Xtreams-support. >> It's not ideal. That also means that bleeding-edge will not load in Squeak 4.4 or older, and maybe not elder version of Pharoâ¦ >> Maybe I could have changed NotFoundError reference into NotFound? > > NotFound is in Pharo 2.0 as well. > > I wonder if it is really necessary to use the VW name/alias, as it is not referenced, but OK, it could be. I donât think it is as much part of the API as Incomplete is. > >> In the future, or if we really want a bleeding edge in elder images, we may have to fork the Xtreams-support, but as long as we can, it's better to avoid it. > > I think that it would be good to keep this a cross platform project (as it spans multiple platforms already). But that requires effort (at least, basic interest, maintenance from multiple people on different platforms). Fuel proves that it can be done. Indeed! > I think it is unavoidable to have some specific code per platform, especially in Support. But indeed, not for the sake of it. > > I was looking around in the source code and saw some places where I could imagine things being done differently (ZnCharacterEncoders in Pharo are properly Character <> Binary). > > BTW, does TerminalsFileSystem work on Squeak or is it Pharo specific. Because FileUrl is on its way out (replaced by ZnUrl). The #reading, #writing, #appending messages on FileUrl, in their current implementation, strike me as a bit out of place (as far as I can see, they are not in the VW code either). I mean, I could image #reading or #writing am HTTP Url as well, though that would not necessarily the best design. Doing a #asFileReference in between is acceptable and clearer. It's Pharo specific at the moment AFAICT because it refers to FileHandle and FileReference, while the upstream repo uses FSFileHandle and FSFileReference. The conversation's partly at https://code.google.com/p/xtreams/issues/detail?id=2 > Are there any areas in the port of Xtreams that need more work, or do you consider the current situation as complete enough ? In other words, is there a todo list ? > > Are there version differences with the VW code, and how do you see that evolving ? Without answering for Nicolas, https://code.google.com/p/xtreams/issues/detail?id=3 has Martin Kobetic saying <quote> Regarding integration, I'd say getting the agreement of the Squeak/Pharo group should suffice to get it into the Pharo/Squeak port. Hopefully we will get a reasonable setup for crosspolination among the dialects eventually, but until then I'd hate to see evolution hampered because e.g. VW is declared the reference implementation and nothing is "officially" accepted until VW has it or some silly rule like that. I would only suggest to exercise restraint and avoid uncontrolled growth of the core framework as a general principle. Only things that are generally useful and that provide more than a marginal benefit should be added to the core. It's perfectly fine to make special purpose streams, and the core framework must always preserve the ease of doing that, but those streams themselves should live in their respective projects. </quote> frank > Sven > >> 2013/11/19 Sven Van Caekenberghe <sven(a)stfx.eu> >> >> 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. 20, 2013

Loading Xtreams in Pharo

by Sven Van Caekenberghe

Hi, If anyone else is interested, you can load Xtreams using this expression: Gofer new squeaksource: 'Xtreams'; configuration; loadVersion: #bleedingEdge. I tested this only in Pharo 3.0, but it should work in 2.0 as well. Since all tests are green, it might be a good idea to set up a CI job. We could make a new stable config to put in the Configuration Browser repos. Sven

Nov. 20, 2013

Re: [Pharo-dev] Is Coral still alive?

by Sean P. DeNigris

philippeback wrote > Rha, no windows. > >> which already exists and it's named LIMBO :) Cool! But yes, supporting beyond Mac will be a must. Out of curiosity, why does it require a plugin? It has seemed to me that one of the purposes of NB is to bring code into the image, and out of the VM... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Is-Coral-still-alive-tp4723551p4723766.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013

Re: [Pharo-dev] Smalltalks 2013 video now available

by Sean P. DeNigris

Thanks Andres! This is sooooo important to share the conferences beyond the slice of our community attending :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Smalltalks-2013-video-now-available-tp4723610p4723764… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013