December 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] web site relocation Re: Newbie observations on use of Metacello

by Ben Coman

Thanks for the tip. I was aware of the rename to DBXTalk, but not the change to ConfigurationOfOpenDBXDriver. The new site [1] says "Welcome to SqueakDBX", and [2] refers only to ConfigurationOfSqueakDBX. Further offtopic but perhaps of interest to others... The DBXTalk site was difficult to find. For me google results only show it on the second page. I lament for your sake the loss of the squeakdbx.org domain. You may have had better better results holding on to it for a couple of years coupled with a 301 redirect [3][4]. As well as losing the immediate redirects from the existing links on other web sites, including your own [5], the cybersquatter now on squeakdbx.org may compromise the ranking of your new site, along with additional "content duplication/spam" reasons discussed at [3]. [1] http://dbxtalk.smallworks.com.ar/ [2] http://dbxtalk.smallworks.com.ar/Installation [3] http://www.bigoakinc.com/seo-articles/301-direct-Google.php [4] http://support.google.com/webmasters/bin/answer.py?hl=en&answer=93633 [5] http://marianopeck.wordpress.com/tag/dbxtalk/ cheers, Ben Mariano Martinez Peck wrote: > Hi Ben. Some offtopic, but be aware that ConfigurationOfSqueakDBX is > deprecated. The whole project has been renamed to DBXTalk and what was > SqueakDBX is now DBXTalkOpenDBXDriver. You can find > ConfigurationOfOpenDBXDriver in DBXTalk repo or MetacelloRepository. > > On Mon, Dec 19, 2011 at 6:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > >> wrote: >> > > >> On Dec 19, 2011, at 5:04 PM, Ben Coman wrote: >> >> >>> StÃ©phane Ducasse wrote: >>> >>>> ben thanks for your feedback. >>>> >>>> Normally we should use the monticello repository browser and just click >>>> >> on a ConfigurationOf >> >>> I've been lurking this mail list for 6 - 9 months and had not picked >>> >> that up. That is a big miss. I'm not usually so slow. Can you point me to >> the documentation that describes that process? >> >> >> The problem is that we did not push it to the point the repository for >> 1.0, contains only 1.0 configuration. >> We will check that when esteban will arrive. >> >> >>> In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello >>> >> Browser and look for ConfigurationOfSqueakDBX. I can't see it. I expected >> to since you seemed to indicate it was that simple. >> >>> So I GUESS* my way through. I <Open> the >>> >> http://www.squeaksource.com/MetacelloRepository repository >> >>> (which actually requires a bit of fore knowledge about the url - which >>> >> not all newbies will have) >> >>> This did show ConfigurationOfSqueakDBX but the are many versions and so >>> >> many buttons to choose from. A bit scary for a newbie. >> >>> Anyhow, I'll ASSUME* to select the latest one >>> >> ConfigurationOfSqueakDBX-MarianoMartinezPeck.27 and click <Load>. >> >>> I still can't see any SqueakDBX or OpenDBX classes in System Browser. >>> Do I need to follow up manually doing "ConfigurationOfSqueakDBX project >>> >> latestVersion load." ? >> >>> A mixed procedure part GUI and part non-GUI is not the best - and I've >>> >> not seen it documented anywhere. >> >>> I would have liked to have loaded the package with "just a single click >>> >> on a ConfigurationOf" but there seems to be more to it than that. >> >>> The following still seems easier: >>> >>>> Metacello package: 'SqueakDBX' load >>>> >>> or perhaps some alternatives using existing tools... >>> 1. To the Monticello Browser add a <Metacello> button that opens >>> >> http://www.squeaksource.com/MetacelloRepository. If Metacello is "THE" >> package management tool then it should have a higher profile than just one >> of the 23 listed repositories, of which two others have "Metacello" in >> their title. >> >>> 2. To the World Menu, add a <Metacello Browser> item that jumps straight >>> >> to the Monticello Repository Browser for >> http://www.squeaksource.com/MetacelloRepository. >> >>> 3. The Welcome Text of a fresh pharo-oneclick image should describe how >>> >> to do either 1. or 2. above. >> >>> cheers, Ben >>> >>>> than did you read the forthcoming chapter? >>>> https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old >>>> >> version) >> >>>> >>> Yes I refer to it in point 4 below. Can you point me to where in that >>> >> pdf it specifically describes that loading procedure using Monticello >> Browser. All the examples I can see are code b> below, except using >> (Smalltalk at:.....) rather than the class itself. >> >>> Further, the Pharo-1.3-OneClick opening documentation says to execute >>> >> the following line... >> >>>> DEVImageWorkspaces openExternalProjectWorkspace. >>>> >>> which shows several examples all of the same form as the code b> below. >>> >>> Also, from memory the examples given throughout this mail list tend to >>> >> be of the same form as code b> below - rather than directing people to the >> GUI Monticello Browser - or I probably would have picked that up sooner. >> >>>> Stef >>>> >>>> >>>> >>>> On Dec 19, 2011, at 5:15 AM, Ben Coman wrote: >>>> >>>> >>>> >>>>> Some observations from the perspective of as a newbie on Pharo Package >>>>> >> Management. I'm likely to me missing in the philosophy of the design, but >> from the narrow view of my own usage.... >> >>>>> 1. When I read about Metacello being the package management system, I >>>>> >> expected there to be a "command"(*) Metacallo but instead I see Gopher >> being used. This is a mixed message that lowers my comfort level feeling >> I understand the system as I'm trying to pick up a bundle of new ideas. As >> I now understand it Metacello is more about a system of backend >> configuration than a front end user interface. I am now more comfortable >> using Gopher direct - but I reflect on how I felt the first time. >> >>>>> (*) While technically a "command" is like a verb, and Gopher is like >>>>> >> a noun rather than a verb - I can't yet completely disengage my prior >> learning that considers the first part of the statement to be a "command" - >> and I expect other newbies might find the same. >> >>>>> 2. The strong convention of naming things ConfigurationOfXXXX is >>>>> >> somewhat redundant from a user perspective. >> >>>>> 3. If copy-paste into the Workspace from a web site a sample package >>>>> >> load (for example b> below) and then highlight the whole thing and execute, >> it tells me >> >>>>> "Unknown variable: ConfigurationOfSqueakDBX, please correct, or >>>>> >> cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote >> that down anywhere.... >> >>>>> The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds >>>>> >> further complexity in the eyes of a newbie. >> >>>>> Based on the above points, it would be nice to have... >>>>> >>>>> a> Metacello configuration: 'SqueakDBX' load >>>>> >>>>> rather than... >>>>> >>>>> b> Gofer new >>>>> b> squeaksource: 'MetacelloRepository'; >>>>> b> package: 'ConfigurationOfSqueakDBX'; >>>>> b> load. >>>>> b> ConfigurationOfSqueakDBX project latestVersion load. >>>>> While only a small saving in typing, I think it significant for >>>>> >> newbies in terms of polish and the marketing message that Metacello really >> is the chosen package management system. >> >>>>> A very rough implementation (with much of the syntax likely wrong) >>>>> >> might be just... >> >>>>> c> Metacello class >> package: aPackage >>>>> c> | packageConfig | >>>>> c> packageConfig := 'ConfigurationOf', aPackage; >>>>> c> Gopher new c> squeaksource: >>>>> >> 'MetacelloRepository'; >> >>>>> c> package: packageConfig >>>>> c> load >>>>> c> ^((Smalltalk at: (packageConfig asSymbol)) >>>>> >>>>> >>>>> Now after I've written the above I contemplate that there must have >>>>> >> been an early design decision to not implement a separate Metacello class >> to avoid duplication/overlap with Monticello. However perhaps now that the >> system is implemented as it is, a thin shim can be put over the top to >> assist getting the ConfigurationOfXXX files downloaded. Additional things >> this Metacello class might later provide: a. Improved reliability by >> downloading from a system of package repository mirrors. SqueakSource was >> having some issues and I found [1] a fortunate backup. b. A GUI for >> browsing package versions >> >>>>> c. A GUI for browsing compatibility tables from a continuous >>>>> >> integration system that tries different permutations of Montecello packages >> together. >> >>>>> 4. It seems that every ConfigurationOfXXX has its own category in the >>>>> >> SystemBrowser. Each of these categories has only one class. This seems to >> me like unneeded clutter of the System Browser. It would be neater if >> Metacello specified its configurations to be grouped under a single >> category "MetacelloConfigurations" or similar. >> >>>>> 5. The sample Metacello PBE is very good in the detail for developers >>>>> >> to provide configurations. However there is not much directed clearly at a >> 'mere' user. Even though Smalltalk makes us all developers, newbies all >> start as mere users while exploring the system. [1] Gofer new url: ' >> http://dsal.cl/squeaksource/MonticelloRedirect'; package: >> 'MontiRedirect'; load. MRManager redirectFrom: ' >> http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. >> >>>>> Cheers, Ben >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > > >

Dec. 21, 2011

Re: [Pharo-project] decoupling the vm: UI and interpretation

by Frank Shearar

On 21 December 2011 10:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 December 2011 08:45, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> YES!,the current VM was devised on 90's, maybe its time to alter it a bit now.. >> >> Esteban, in your opinion would this be feasible, in decent amount of >> time? Moving Display to a separate plugin. >> >> Yet remains a question, how would the "UI-pluggable VM" talk with the >> headless vm. >> I will implement a proof of concept, using some kind of IPC (for the >> MAc), so we can measure the responsiveness of such scheme. >> > > .. and probably while inventing this new wheel, you can read about X > server design, > which having such architecture for years. :) > But we need that wheel for sure, even if we need to reinvent it :) If this is going to end up re-inventing X, why not just use X? And I don't mean re-implementing X either, but using someone else's hard work. frank

Dec. 21, 2011

Re: [Pharo-project] Enhancing Athens: about lines caps and joins

by Igor Stasenko

You can check an AthensStrokePaint class which is just a prototype for that capability. Unfortunately , balloon engine does not supports most of these options. But with Cairo i now can reify them nicely. -- Best regards, Igor Stasenko.

Dec. 21, 2011

Re: [Pharo-project] Enhancing Athens: about lines caps and joins

by Igor Stasenko

On 21 December 2011 13:38, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Hi Igor and Stef, > > Im NBCairo i reified CairoLineCaps, and CairoLineJoin. > > In Athens is missing, should AthensLineSegment hold this information?, > so when then canvas visits the line segment, it should change the > cairo context accordingly. > ( AthensCairoCanvas>>visitLineSegment: line) It will be reified, but slightly different. Line caps and joins used only for path strokes, but not for fills. Paths are orthogonal to these options. While paths are built from segments (like moveto, lineto etc), they do not carry any information whether they will be used for fills or for strokes. Like that you can use same path to either stroke it or fill it. In Athens, to stoke path you should use a stoke paint object, by issuing: canvas setStrokePaint: aPaint. and then in resulting object you will be able to set different options like join type and cap style, like: paint := canvas setStrokePaint: Color blue. paint capStyle: #blah. We discussed this before deciding, where to put a difference between 'fill' and 'stroke' and decided that putting it into paint object will be more natural, and like that we don't have to blowup the canvas protocol. So, canvas to render any shape just needs to implement #drawShape: while whether to fill given shape or stroke it, decided by currently selected paint object i.e.: canvas setPaint: myPaint. canvas drawShape: anyShape. -- Best regards, Igor Stasenko.

Dec. 21, 2011

Re: [Pharo-project] Application settings

by StÃ©phane Ducasse

On Dec 21, 2011, at 12:45 PM, Alain Plantec wrote: > Le 21/12/2011 11:09, StÃ©phane Ducasse a Ã©crit : >> alain >> >> did we describe that in the chapter? > I don't think so but we should :) I like when you get my subliminal message > >> >> Stef >> >> On Dec 21, 2011, at 10:59 AM, Alain Plantec wrote: >> >>> Hi Hilaire, >>> >>> If you want a package specific keyword, then your package must add a sepecific method to SettingTreeBuilder. >>> for drgeosettings if should be: >>> >>> SettingTreeBuilder>> drgeosettings >>> <settingPragmaProcessor> >>> "Process a<drgeosettings> pragma" >>> >>> currentPragma methodClass theNonMetaClass perform: currentPragma selector with: self. >>> >>> Cheers >>> Alain >>> >>> >>> >>> Le 21/12/2011 10:49, Hilaire Fernandes a Ã©crit : >>>> I want to use drgeo specific setting and let the user browser >>>> drgeosettings only. >>>> As documented in the SettingBrowser comment, I defined: >>>> >>>> drgeoSettingsOn: aBuilder >>>> <drgeosettings> >>>> (aBuilder group: #drgeo) >>>> label: 'Dr. Geo'; >>>> description: 'All Dr. Geo related settings' translated; >>>> noOrdering; >>>> with: [ >>>> >>>> >>>> Then to browse drgeo specific settings I evaluate; >>>> >>>> (SettingBrowser forKeywords: #('drgeosettings')) open >>>> >>>> I got a MNU SettingTreeBuilder>>drgeosettings >>>> >>>> Do I need to implement it? >>>> >>>> Hilaire >>>> >>> >> > >

Dec. 21, 2011

[Pharo-project] Enhancing Athens: about lines caps and joins

by Fernando Olivero

Hi Igor and Stef, Im NBCairo i reified CairoLineCaps, and CairoLineJoin. In Athens is missing, should AthensLineSegment hold this information?, so when then canvas visits the line segment, it should change the cairo context accordingly. ( AthensCairoCanvas>>visitLineSegment: line) Fernando

Dec. 21, 2011

Re: [Pharo-project] gt inspector

by Esteban Lorenzano

Hi, I'm using it, and I think is great! just one little glitch: you can't edit instVars... Cheers, Esteban El 21/12/2011, a las 5:01a.m., Tudor Girba escribiÃ³: > Hi, > Just out of curiosity: Does any of you use the GTInspector? > For those that wonder what that is, here is a > demo:http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk > This is available in any recent Moose image mapped as Explorer (CMD+I). > You can load it in a Pharo 1.3 image by:Gofer new squeaksource: > 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load.(Smalltalk > at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: > #GTInspector) registerToolsOn: Smalltalk tools. > > Cheers,Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Dec. 21, 2011

Re: [Pharo-project] Application settings

by Alain Plantec

Le 21/12/2011 11:09, StÃ©phane Ducasse a Ã©crit : > alain > > did we describe that in the chapter? I don't think so but we should :) > > Stef > > On Dec 21, 2011, at 10:59 AM, Alain Plantec wrote: > >> Hi Hilaire, >> >> If you want a package specific keyword, then your package must add a sepecific method to SettingTreeBuilder. >> for drgeosettings if should be: >> >> SettingTreeBuilder>> drgeosettings >> <settingPragmaProcessor> >> "Process a<drgeosettings> pragma" >> >> currentPragma methodClass theNonMetaClass perform: currentPragma selector with: self. >> >> Cheers >> Alain >> >> >> >> Le 21/12/2011 10:49, Hilaire Fernandes a Ã©crit : >>> I want to use drgeo specific setting and let the user browser >>> drgeosettings only. >>> As documented in the SettingBrowser comment, I defined: >>> >>> drgeoSettingsOn: aBuilder >>> <drgeosettings> >>> (aBuilder group: #drgeo) >>> label: 'Dr. Geo'; >>> description: 'All Dr. Geo related settings' translated; >>> noOrdering; >>> with: [ >>> >>> >>> Then to browse drgeo specific settings I evaluate; >>> >>> (SettingBrowser forKeywords: #('drgeosettings')) open >>> >>> I got a MNU SettingTreeBuilder>>drgeosettings >>> >>> Do I need to implement it? >>> >>> Hilaire >>> >> >

Dec. 21, 2011

Re: [Pharo-project] gtinspector

by Mariano Martinez Peck

On Wed, Dec 21, 2011 at 9:01 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Just out of curiosity: Does any of you use the GTInspector? > > For those that wonder what that is, here is a demo: > http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk > > I used to use it for my images. And it was pretty nice. Problem was the amount of dependencies it had, the time it took me to install it, and moreover, that since it depends on several dependencies it was always complicated to successfully install it. Apart from that, I really like it. > This is available in any recent Moose image mapped as Explorer (CMD+I). > > You can load it in a Pharo 1.3 image by: > Gofer new squeaksource: 'glamoroust'; package: > 'ConfigurationOfGlamoroust'; load.(Smalltalk at: > #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: #GTInspector) > registerToolsOn: Smalltalk tools. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > -- Mariano http://marianopeck.wordpress.com

Dec. 21, 2011

Re: [Pharo-project] decoupling the vm: UI and interpretation

by Igor Stasenko

On 21 December 2011 08:45, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > YES!,the current VM was devised on 90's, maybe its time to alter it a bit now.. > > Esteban, in your opinion would this be feasible, in decent amount of > time? Moving Display to a separate plugin. > > Yet remains a question, how would the "UI-pluggable VM" talk with the > headless vm. > I will implement a proof of concept, using some kind of IPC (for the > MAc), so we can measure the responsiveness of such scheme. > .. and probably while inventing this new wheel, you can read about X server design, which having such architecture for years. :) But we need that wheel for sure, even if we need to reinvent it :) -- Best regards, Igor Stasenko.

Dec. 21, 2011