May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] XMLParser GTInspector extensions

by Tudor Girba

Hi, Sorry for the slow reaction. Indeed, we would like to encourage the packaging of GT extensions in the same project as the code they extend. So, in this case, GT-InspectorExtensions-XML would be better suited to be in the PharoExtras/XMLParser repository under XML-Parser-GT-InspectorExtensions. Actually, given that most of these extensions are not more complicated than a printOn:, I would even argue that in many cases it would be more suitable to have them in the same package as the class they extend. I know it sounds like bad dependency management, but the GT-Inspector is here to stay (and the API will likely remain compatible in the future), so the risk is minimal and I think in many situations you will this approach more pragmatic. So, Ben: could you push the package as you described (only call it please XML-Parser-GT-InspectorExtensions)? Cheers, Doru On Sun, May 3, 2015 at 4:30 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sun, May 3, 2015 at 4:28 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi ben >> >> we could update the configurationOfXMLReader. >> But the right solution is to define a new configuration loading GT-Tools, >> XMLReader and your extensions. >> In pharo 40 we could consider that GT-Tools is loaded. >> Now I think that making the dependencies explicit is important. >> >> >> So what do you think of... >> * Updating ConfigurationOfXMLParser to automatically load the extensions >> for Pharo4. >> * Moving the package into the XML-Parser repository so it sits next to >> other compatibility packages like XML-Parser-GemstoneCompatability -- and >> possibly renaming it something like XML-Parser-GT-Extensions. >> >> The package I maintain with monty is in PharoExtras so I would prefer not >> to change its location. >> > > I meant moving GT-InspectorExtensions-XML..mcz from Smalltalkhub > Moose/GToolkit > to Smalltalkhub PharoExtras/XMLParser renamed > XML-Parser-GTExtensions..mcz , > but that might not suit the GT Team. > > Actually in off-list correspondence with monty I learnt of > XMLPluggableElementFactory, which seems to suit my need better than my > proposed GT extensions for XMLParser. > cheers -ben > > > >> >> Stef >> >> >> >> >>> I would prefer to qualify the extensions by the tool they refer to: >>> GT-InspectorExtensions-*, GT-SpotterExtensions-* etc. >>> >>> gtDisplayOn: should be more in the inspector, but probably some were >>> added mostly in the spotter so they ended up in the less optimal package. >>> >> >> okay. good to understand. >> cheers -ben >> >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> I happened to need to use and XML Parser for the first time and found >>>> inspecting the structure awkward, so I added some GTInspector extensions to >>>> XML-Parser. This is uploaded as XML-Parser-BenComan.304 to >>>> http://smalltalkhub.com/#!/~PharoExtras/XMLParser. Could someone who >>>> uses XML regularly check if these are reasonable? >>>> >>>> Now should these methods be packaged separately somehow, since they >>>> are likely not of interest to other Smalltalk flavours? >>>> >>>> btw I gave them a protocol of "GT-Extensions" - but I also considered >>>> "moldable-tools" and "tools-extensions". If there a preference? This will >>>> likely be a common occurrence across the community, so we should try for a >>>> consistent convention across the community for such extensions. >>>> >>>> btw2, I notice that #gtDisplayOn: implementors are fairly evenly >>>> split between [GT-InspectorExtensions-Core] and >>>> [GT-SpotterExtensions-Core]. Are they really separated like this in their >>>> use? >>>> >>>> cheers -ben >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

May 3, 2015

Re: [Pharo-users] Can we have NeoCSV, and NeoJSON included in the base image?

by Alexandre Bergel

Hi Andy, I personally almost solely use Moose, as it contains many of the tools I need. Let us know about your experience with Moose. Cheers Alexandre > Le 2 mai 2015 Ã 17:02, Andy Burnett <andy.burnett(a)knowinnovation.com> a Ã©crit : > > Thanks Ben, and Cyril. > > I liked Mariano's approach, and I will play with that. However, I think the suggestion about using Moose may be exactly what I need. > > I have been playing with Mathematica a lot lately, and I really appreciated the fact that you got the kitchen sink with it. > > What I was wondering - taking Cyril's comment into account - is whether there is an argument for producing a kitchen sink image which contains the stable versions of all the key tools. Obviously, that requires some discussion/analysis of what the key tools are, but it shouldn't be impossible to do. > > In the meantime, I am off to play with Moose :-) > > Cheers > Andy

May 3, 2015

Re: [Pharo-users] Reading rows in a database table (select * from ...)

by Pierce Ng

On Fri, May 01, 2015 at 04:23:26AM -0700, Sanjay Minni wrote: > however in your notes below you mentioned that you used a dump of large > size. My question is when faced with such large row sets how do you limit > the size of data read in the select statement . This web page suggests how to deal with this: https://www.sqlite.org/cvstrac/wiki?p=ScrollingCursor > another doubt I had was from the example code below from the NBSQLite3. > is rs close at the right place - would it be closing the connection ? > > res := db beginTransaction. > > rs := db execute: '...'. > rs close. > > res := db commitTransaction. rs holds an NBSQLite3ResultSet instance. Closing it does not close the the database connection object which is an NBSQLite3Connection instance. In my example I had failed to close the result set object. :-P Resource finalization is still tricky at times. I have a few broken images lying around, mostly due to that. Pierce

May 3, 2015

Re: [Pharo-users] XMLParser GTInspector extensions

by Ben Coman

On Sun, May 3, 2015 at 4:28 AM, stepharo <stepharo(a)free.fr> wrote: > Hi ben > > we could update the configurationOfXMLReader. > But the right solution is to define a new configuration loading GT-Tools, > XMLReader and your extensions. > In pharo 40 we could consider that GT-Tools is loaded. > Now I think that making the dependencies explicit is important. > > > So what do you think of... > * Updating ConfigurationOfXMLParser to automatically load the extensions > for Pharo4. > * Moving the package into the XML-Parser repository so it sits next to > other compatibility packages like XML-Parser-GemstoneCompatability -- and > possibly renaming it something like XML-Parser-GT-Extensions. > > The package I maintain with monty is in PharoExtras so I would prefer not > to change its location. > I meant moving GT-InspectorExtensions-XML..mcz from Smalltalkhub Moose/GToolkit to Smalltalkhub PharoExtras/XMLParser renamed XML-Parser-GTExtensions..mcz , but that might not suit the GT Team. Actually in off-list correspondence with monty I learnt of XMLPluggableElementFactory, which seems to suit my need better than my proposed GT extensions for XMLParser. cheers -ben > > Stef > > > > >> I would prefer to qualify the extensions by the tool they refer to: >> GT-InspectorExtensions-*, GT-SpotterExtensions-* etc. >> >> gtDisplayOn: should be more in the inspector, but probably some were >> added mostly in the spotter so they ended up in the less optimal package. >> > > okay. good to understand. > cheers -ben > > > >> >> Cheers, >> Doru >> >> >> >> On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> I happened to need to use and XML Parser for the first time and found >>> inspecting the structure awkward, so I added some GTInspector extensions to >>> XML-Parser. This is uploaded as XML-Parser-BenComan.304 to >>> http://smalltalkhub.com/#!/~PharoExtras/XMLParser. Could someone who >>> uses XML regularly check if these are reasonable? >>> >>> Now should these methods be packaged separately somehow, since they >>> are likely not of interest to other Smalltalk flavours? >>> >>> btw I gave them a protocol of "GT-Extensions" - but I also considered >>> "moldable-tools" and "tools-extensions". If there a preference? This will >>> likely be a common occurrence across the community, so we should try for a >>> consistent convention across the community for such extensions. >>> >>> btw2, I notice that #gtDisplayOn: implementors are fairly evenly split >>> between [GT-InspectorExtensions-Core] and [GT-SpotterExtensions-Core]. Are >>> they really separated like this in their use? >>> >>> cheers -ben >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > >

May 3, 2015

Re: [Pharo-users] mac address on windows

by Pierce Ng

On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote: > 1/ OSProcess: I tried (PipeableOSProcess command: 'ipconfig /all') output. I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper successfully back when I was on Windows using some now-ancient version of Pharo. Pierce

May 3, 2015

Re: [Pharo-users] Pharo 4 Playground open file menu

by phil＠highoctane.be

Le 3 mai 2015 12:28, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > > >> On 02 May 2015, at 23:28, phil(a)highoctane.be wrote: >> >> When some sysadmin has to edit them on servers, you want them in .st files. >> >> No class. No IDE. Not too much Smalltalk. > > > but then > - if not smalltalk, the scripts should not be in the imageâ¦ even in workspaces > - if the sysadmin has to edit them, he can always do something like: > > #! /bin/bash > > pharo MyImage.image eval â > my > multilined > more or less smalltalk > scriptâ > > - you can always see and edit your scripts by doing: > > 'play-cache' asFileReference inspect > > (instead âplay-cacheâ you can put: âmy-script-folderâ, whatever) > > and you will have a complete inspector that allows you to see and edit your scripts (who are in the file system, where a sysadmin can find them, and not in an obscure workspace). > > also I bet you would take no more than 5â to add functionality to gtinspector (it is designed to be moldable, after all) to add new scripts, and no matter what other functionality you needâ¦ and the result will be a lot more âpharoishâ than storing it in a workspace. I agree to these things for the Pharoish experience. Just that those scripts are to be edited with Vim on remote boxes. I don't want to convert a sysadmin to pharo. I want pharo to be used as any other tool in the lineup. My image builder is fullly in a class etc. Also I am using Sebastian Sastre's ConfigurationFiles that do load conf/SomeConfFile.st I have several such files: - email addresses - mongodb conf - seaside ports, debug level.. - API config - configuration file for a tree structure - preferences These are using code that get eval'd because it is practical to use variables etc. e.g. defaultBandwidth := 50 megabitsPerSecond. .... #(10 20 30 40) do: [:id | config add: SomeModule new bandwidth: defaultBandwidth; id: id asString; label: 'SomeLab', is asString; picture:'some.jpg'; geoLocation: 45.55(a)44.42; yourself] .... ^config I am preparing them in with Playground etc. So nothing wrong with Playground. I just like the simple workspace too. I also added a : prefix in Spotlight to execute what I do type. Going 4.0 is not yet done here. I am using 3.0 with GToolkit. Phil > > Esteban > > >> Just the DSL on an as needed to know basis to configure things. >> >> That's better that XML/YAML/JSON... >> >> So, that's the case. >> >> Startup scripts same story. >> >> Phil >> >> Le 2 mai 2015 17:56, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : >>> >>> wellâ¦ IMO those scripts also should be in a method. >>> Probably under a class named: MyCoolProjectRunScripts or something like thatâ¦ but in a class. >>> If they are in a class you can: >>> - save them with your project >>> - version them >>> - if you add <script> pragma, you can even execute them by clicking on it (Pharo 4). >>> >>> soâ¦ even if you might have a case where you want the save/loadâ¦ you actually have (what I consider) a better option. >>> >>> Esteban >>> >>>> On 02 May 2015, at 15:17, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>> Ditto here. >>>> >>>> I have cron tasks that fire a smalltak script, the startup script itself or a small import script that doesn't belong to a class. All those are my cases for the workspace. >>>> >>>> El may 2, 2015 4:38 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> escribiÃ³: >>>>> >>>>> playground cache is actually not nice when scripts are to be part of a project with a name etc. And I have a ton of files in it. I can't remember which is which. >>>>> >>>>> I have scripts to do lots of cli things and I like the save as of the workspace. >>>>> >>>>> But I have done extra key bindings for getting the ws or the playground. >>>>> >>>>> Phil >>>>> >>>>> Le 2 mai 2015 06:49, "Sergio Fedi" <sergio.fedi(a)gmail.com> a Ã©crit : >>>>>> >>>>>> Oh! That link gives a GREAT explanation! Thanks. >>>>>> >>>>>> On the subject of how to show it better, I'm not a graphic designer (although I'm working with one) >>>>>> so I'll ask him for some insights on the matter. >>>>>> >>>>>> >>>>>> For now, he pointed out some issues like lack of consistency on some interfaces >>>>>> and some other details. >>>>>> >>> >

May 3, 2015

Re: [Pharo-users] Help required for understanding a project on smalltalk hub

by Sergio Fedi

âHi, if you want we can do a Skype call today so I can help you in your first steps.

May 3, 2015

Re: [Pharo-users] accessing themed colors from morph

by Stephan Eggermont

On 03/05/15 12:45, Peter UhnÃ¡k wrote: > Yes, that is what I was looking for. > I used the self theme backgroundColor and it works for the time being. In your application you probably want to centralize this. Stephan

May 3, 2015

Re: [Pharo-users] accessing themed colors from morph

by Peter UhnÃ¡k

> > Yes but, 'self theme' is 'the theme engine that defines all theme > settings' and > 'self theme backgroundColor' is > 'what this theme defines as general backgroundColor' > It does not mean that self (the morph) is actually using this theme > setting for anything. > > I know, I don't care if the morph itself uses it somewhere or not, I wanted color that _should_ be used as a background, so I can apply it to some part of the morph myself. it is the general background color (that should be applied *by default* to > all morphs that recognises the background property), as Nicolai pointed. > Yes, that is what I was looking for. I used the self theme backgroundColor and it works for the time being. Peter

May 3, 2015

Help required for understanding a project on smalltalk hub

by Jigyasa Grover

Hello All ! I have just started with Pharo and still grasping it features. I have come across a project on Smalltalk Hub http://smalltalkhub.com/#!/~BenjA/FullTextSearch ; a search application for Pharo. I wish to explore this project and enhance/improvise it further. It would be great if the author of this project, any of its contributors or simply a Pharo enthusiast would guide me on how to go about understanding the project. I am keen on broadening it further. Thanks Jigyasa

May 3, 2015