- Pharo-users - lists.pharo.org

Re: [Pharo-users] Error: RemoteString past end of file on Pharo 4.0

by Cyril Ferlicot

That wouldn't be faster to save your changes into package-cache and load your .mcz into a new image ? On 4 May 2015 at 00:39, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > Hi, > > I used "Save as" from world menu and I'm pretty sure I have the .image and > .changes with the same name in the same folder. How can I confirm that these > are related properly beyond the name? There is any way to generate a proper > .changes file? > > Cheers, > > Offray > > El 03/05/15 a las 17:25, Carlo escribiÃ³: > >> Hi >> >> My first thought was also to do with the .change file, as I have received >> this error before when creating manual backups of images. >> >> Cheers >> Carlo >> >> On 04 May 2015, at 12:22 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >> wrote: >> >> It happend to me when I renamed some .image without renaming the .change >> file. >> Maybe that's the problem. >> >> On 3 May 2015 at 23:35, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> >> wrote: >>> >>> Hi, >>> >>> I was about to update some changes on my project as a result of this >>> weekend >>> hackathon, but I got this error: >>> >>> Error: RemoteString past end of file >>> >>> I'm using: >>> >>> - Pharo4.0 Latest update: #40611 >>> - OS: 3.12.39-1-MANJARO #1 SMP PREEMPT Sat Mar 21 07:54:52 UTC 2015 >>> x86_64 >>> GNU/Linux >>> >>> I found [1] and [2] for this error, but I can't make sense on any fix I >>> can >>> apply (I don't know about slices) >>> >>> [1] >>> http://forum.world.st/Error-Remote-String-past-end-of-file-td4707766.html >>> [2] https://pharo.fogbugz.com/f/cases/10411/#78632 >>> >>> Any help is appreciated. >>> >>> Cheers, >>> >>> Offray >>> >> >> >> > > -- Cheers Cyril Ferlicot

May 3, 2015

Re: [Pharo-users] Error: RemoteString past end of file on Pharo 4.0

by Carlo

Hi My first thought was also to do with the .change file, as I have received this error before when creating manual backups of images. Cheers Carlo On 04 May 2015, at 12:22 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: It happend to me when I renamed some .image without renaming the .change file. Maybe that's the problem. On 3 May 2015 at 23:35, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > Hi, > > I was about to update some changes on my project as a result of this weekend > hackathon, but I got this error: > > Error: RemoteString past end of file > > I'm using: > > - Pharo4.0 Latest update: #40611 > - OS: 3.12.39-1-MANJARO #1 SMP PREEMPT Sat Mar 21 07:54:52 UTC 2015 x86_64 > GNU/Linux > > I found [1] and [2] for this error, but I can't make sense on any fix I can > apply (I don't know about slices) > > [1] > http://forum.world.st/Error-Remote-String-past-end-of-file-td4707766.html > [2] https://pharo.fogbugz.com/f/cases/10411/#78632 > > Any help is appreciated. > > Cheers, > > Offray > -- Cheers Cyril Ferlicot

May 3, 2015

Re: [Pharo-users] Error: RemoteString past end of file on Pharo 4.0

by Cyril Ferlicot

It happend to me when I renamed some .image without renaming the .change file. Maybe that's the problem. On 3 May 2015 at 23:35, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > Hi, > > I was about to update some changes on my project as a result of this weekend > hackathon, but I got this error: > > Error: RemoteString past end of file > > I'm using: > > - Pharo4.0 Latest update: #40611 > - OS: 3.12.39-1-MANJARO #1 SMP PREEMPT Sat Mar 21 07:54:52 UTC 2015 x86_64 > GNU/Linux > > I found [1] and [2] for this error, but I can't make sense on any fix I can > apply (I don't know about slices) > > [1] > http://forum.world.st/Error-Remote-String-past-end-of-file-td4707766.html > [2] https://pharo.fogbugz.com/f/cases/10411/#78632 > > Any help is appreciated. > > Cheers, > > Offray > -- Cheers Cyril Ferlicot

May 3, 2015

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, I didn't thought about sysadmin jobs on Smalltalk, like Ben, but seems like a good case for having stuff outside the image, but being image friendly. The options explained by Tudor[0] could be a good approach and may be the "..." button on the playground could have a dialog to rename page as file or something that makes the procedure of doble clicking the page name as a way to "communicate" with file system more explicit. [0] http://www.humane-assessment.com/blog/managing-external-pharo-scripts-with-… My approach to give persistence to what I was doing on the workspace/playground was pretty different: After years of using Leo [1] I was very used to its tree-like interface, but I was thinking in something more interactive (like the IPython[2] notebook, but without loosing the trees, that gives context[3]) and more document oriented, like TeXmacs[4] and pandoc. From this kind of sources of inspiration I'm making grafoscopio[5], which is still pretty alpha, but let's you save scripts with context and mix them with documentation or write interactive documentation. The storage format is STON[6] [1] http://leoeditor.com/ [2] http://ipython.org/notebook.html [3] http://mutabit.com/mutabit/default/wiki/ipython-deepness [4] http://texmacs.org/ [5] http://smalltalkhub.com/#!/~Offray/Grafoscopio [6] https://github.com/svenvc/ston/blob/master/ston-paper.md So, it will not let you edit code from vim (by the way, I'm with Ben about more Unix/Internet friendly line endings for storage/exporting on external files), but It will bridge the document/script world, with the object world. Making such bridges with the external world is important for delivering the promises of the dynabook and pharo to more people. Cheers, Offray Ps: I have attached and screenshot of my "apprentice notes" grafoscopio notebook, to illustrate my point :-) El 02/05/15 a las 16:28, phil(a)highoctane.be escribiÃ³: > When some sysadmin has to edit them on servers, you want them in .st files. > > No class. No IDE. Not too much Smalltalk. > > 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 > <mailto:estebanlm@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 >> <mailto:emaringolo@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 <mailto:phil@highoctane.be>" >> <phil(a)highoctane.be <mailto:phil@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 >> <mailto:sergio.fedi@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

Error: RemoteString past end of file on Pharo 4.0

by Offray Vladimir Luna CÃ¡rdenas

Hi, I was about to update some changes on my project as a result of this weekend hackathon, but I got this error: Error: RemoteString past end of file I'm using: - Pharo4.0 Latest update: #40611 - OS: 3.12.39-1-MANJARO #1 SMP PREEMPT Sat Mar 21 07:54:52 UTC 2015 x86_64 GNU/Linux I found [1] and [2] for this error, but I can't make sense on any fix I can apply (I don't know about slices) [1] http://forum.world.st/Error-Remote-String-past-end-of-file-td4707766.html [2] https://pharo.fogbugz.com/f/cases/10411/#78632 Any help is appreciated. Cheers, Offray

May 3, 2015

Issue with GT-Debugger

by Alexandre Bergel

Hi! When tracing the execution in GT-debugger the text selection does not always reflect the real position of the program counter. Consider the following screenshot: I have simply pressed the step-into button, nothing more. The selection is not meaningful. Am I the only one to have noticed this? It would be great to have it fixedâ¦ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 3, 2015

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

by phil＠highoctane.be

On Sun, May 3, 2015 at 10:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I think this is an interesting use case, and it is already supported only > in a less classic way :). > > I just wrote a blog post about it: > > http://www.humane-assessment.com/blog/managing-external-pharo-scripts-with-… > > Let me know if this works for you. > Nice, I need to go to 4.0 to get that Spotter thing :-) One note: scripts are saved with the CR (or ^M) line ending by Pharo. Now, vim in Linux positively hates that (showing a single line with ^M s all over). This also makes diffing files a pain (meld is not recognizing any lines etc). So, I have to mac2unix convert them after they have been saved. I think we should be much better LF (\n) citizens in the Linux world. Phil > > Cheers, > Doru > > > > > On Sun, May 3, 2015 at 3:02 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> >> 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. >> >>>>>> >> >>> >> > >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

May 3, 2015

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

by Tudor Girba

Hi, I think this is an interesting use case, and it is already supported only in a less classic way :). I just wrote a blog post about it: http://www.humane-assessment.com/blog/managing-external-pharo-scripts-with-… Let me know if this works for you. Cheers, Doru On Sun, May 3, 2015 at 3:02 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > 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. > >>>>>> > >>> > > > -- www.tudorgirba.com "Every thing has its own flow"

May 3, 2015

Re: [Pharo-users] Issue with GT-Debugger

by Tudor Girba

Indeed, it's a known issue and Andrei already investigated it. There is a discussion on the Pharo-dev mailing list. Cheers, Doru On Sun, May 3, 2015 at 11:11 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > When tracing the execution in GT-debugger the text selection does not > always reflect the real position of the program counter. Consider the > following screenshot: > > I have simply pressed the step-into button, nothing more. The selection is > not meaningful. > Am I the only one to have noticed this? > It would be great to have it fixedâ¦ > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com "Every thing has its own flow"

May 3, 2015

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