December 2015 - Pharo-users

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by phil＠highoctane.be

Whoever works with Hadoop tech would find names like: Hadoop Spark Cassandra HBase Accumulo Hive Pig Impala Oozie YARN Kafka Flume Sqoop ... Go datascience and you'll get: R Shiny Jupyter Pandas Bokeh D3 And in JS: Node Angular Express descriptive names? Not at all. What matters is not the name, it is its description. And, know what, put a generic name and it will be ungooglable. Try with Visual Studio Code ... Pfah, descriptive project names... As if these were descriptive: Ubuntu 15.10 (Wily Werewolf) Ubuntu 15.04 (Vivid Vervet) Ubuntu 14.04.3 LTS (Trusty Tahr) Ubuntu 12.04.5 LTS (Precise Pangolin) Oh yeah super descriptive names: Oracle Communications Diameter Signaling Router Have a clue? Enjoy, they have a bunch and renamed a few: https://www.oracle.com/products/oracle-a-z.html Want to know? Pay the dues. Phil On Tue, Dec 8, 2015 at 10:20 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > I would need to disagree with you as inquiry is possible by description, > rather than by name, through conversation with those who don't have to > inquire, due to their knowledge [see Meno's Paradox...]. So, a third > possibility exists through communal association. Do you know Kevin Bacon? > ;-) > > I've used that language! > > On 12/08/2015 04:02 PM, EuanM wrote: > >> The philosophical issue behind the disutility of project names like >> these is "Meno's Paradox" >> >> On 8 December 2015 at 21:01, EuanM <euanmee(a)gmail.com> wrote: >> >>> "I wish people would choose descriptive names for their projects" - Todd >>> >>> I agree. >>> >>> I went looking for the current state of dbxtalk recently. It seemed >>> to ba apackage designed for my needs - to X[-over] from a DB to >>> [small]talk. >>> >>> I went there and the the page started talking about "Glorp" and >>> "Garage". Neither are mnemonic or meaningful >>> >>> These projects are just the tip of the iceberg. >>> >>> Pharo project names have publisher-only project names. The project >>> name equivalent of write-only computer languages, like Brain-F**k. >>> >>> >>> On 7 December 2015 at 17:52, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> >>>> Sigh. >>>> >>>> I wish people would choose descriptive names for their projects. I >>>> went looking on Smalltalkhub for some capability and what I found are >>>> thousands of packages with names that mean nothing and no description >>>> entered either. If you want to make sure nobody ever uses your code you've >>>> just taken a giant step in the right direction. But if you hope to make >>>> something lots of people benefit from - nobody is going to look for >>>> "mushroom" when they want crypto capabilities. >>>> >>>> Sorry, this has been really bugging me lately. We, as a community, do >>>> a lousy job of making our code easy to find. >>>> >>>> -Todd Blanchard >>>> >>>> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >>>>> >>>>> I like it, but it seems you missed my point :) >>>>> mushroom --> 117,000,000 is two orders of magnitude more hidden. >>>>> Anyway, maybe I overplay its significance. >>>>> cheers -ben >>>>> >>>>> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >>>>> <robert.w.withers(a)gmail.com> wrote: >>>>> >>>>>> I renamed the project to Mushroom and I also dumped the encoding work >>>>>> to >>>>>> focus on shutdown, optimization and serialization. Here's the wiki: >>>>>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>>>>> >>>>>> thanks,Robert >>>>>> >>>>>> >>>>>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>>>> >>>>>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> >>>>>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>>>> >>>>>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Now I think you are right on with your observation. Additionally, >>>>>>>>>> the >>>>>>>>>> number >>>>>>>>>> of dialects could increase further with Fuel serialization, just >>>>>>>>>> port >>>>>>>>>> SecureSession and bits. >>>>>>>>>> >>>>>>>>>> Alright, I came up with a name and it may border on the egregious >>>>>>>>>> ... >>>>>>>>>> presenting ... >>>>>>>>>> >>>>>>>>>> "Maelstrom" >>>>>>>>>> >>>>>>>>> Great sounding name. However some general advice for the >>>>>>>>> community, >>>>>>>>> since I see a lot of great sounding project names drowned out in >>>>>>>>> the >>>>>>>>> noise of our web-search-centric universe. A litmus test for >>>>>>>>> project >>>>>>>>> naming is using google search to find which return low search >>>>>>>>> results. >>>>>>>>> Today, its more important to be unique than any other attribute of >>>>>>>>> a >>>>>>>>> name. So in general, *dictionary* english words are not the best. >>>>>>>>> One technique is to intentionally mispell the word you like. Here >>>>>>>>> are >>>>>>>>> some comparative examples (note, the surrounding quotes are >>>>>>>>> required >>>>>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>>>>> >>>>>>>>> "maelstrom" --> 7,480,000 >>>>>>>>> "maelstroom" --> 6,200 >>>>>>>>> "maelstrum" --> 2,280 >>>>>>>>> "maelstruum" --> 7 >>>>>>>>> >>>>>>>>> Lots of interesting other techniques can be found by searching on: >>>>>>>>> techniques to generate brand names or domain names. >>>>>>>>> >>>>>>>>> cheers -ben >>>>>>>>> >>>>>>>> >>>>>>>> I would be happy to change the names to something more unique, >>>>>>>> though it >>>>>>>> may >>>>>>>> take a few. Are you suggesting "maelstruum"? >>>>>>>> >>>>>>>> cheers, >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>>>>> >>>>>>> I think maelstruum is certainly memorable with the double "u", but >>>>>>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>>>>>> associate it with "zoom". I wouldn't necessarily go for the absolute >>>>>>> lowest results. I have an entirely unsubstantiated belief that >>>>>>> anything less than 10,000 gives a reasonable chance to compete once a >>>>>>> user's browsing history is taken into account. Finally you need to >>>>>>> check existing results don't return something abhorrent (I didn't do >>>>>>> this). >>>>>>> >>>>>>> I'd encourage to play around testing on google search. Its quick and >>>>>>> easy to generate and test alternatives. I've added a few more below. >>>>>>> "maelstra" --> 3,560 >>>>>>> "maelstram" --> 504 >>>>>>> "maelstrim" --> 1200 >>>>>>> "maelstroon" --> 58 >>>>>>> "maelstroomi" --> 4 >>>>>>> >>>>>>> btw, I wouldn't swap the order of the "ae" since that would be >>>>>>> susceptible to real typing errors. >>>>>>> >>>>>>> cheers -ben >>>>>>> >>>>>>> >>>>>> >>>> > > >

Dec. 8, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by Robert Withers

Well, it seems I've more to say though I wouldn't want to test your patience . If folks have NO idea what they want, then Meno's Paradox would apply. People tend to have a descriptive ability, or a gut feeling at the least. "It kinda needs to be a camera that like hovers to longer observation times can be maintained" enter the quadcopter. So I thought to addd the third possibility, which is partial descriptive knowledge, communal connectivity, expert availability/receptivity, and descriptive inquiry. Best, Robert On 12/08/2015 04:20 PM, Robert Withers wrote: > I would need to disagree with you as inquiry is possible by > description, rather than by name, through conversation with those who > don't have to inquire, due to their knowledge [see Meno's Paradox...]. > So, a third possibility exists through communal association. Do you > know Kevin Bacon? ;-) > > I've used that language! > > On 12/08/2015 04:02 PM, EuanM wrote: >> The philosophical issue behind the disutility of project names like >> these is "Meno's Paradox" >> >> On 8 December 2015 at 21:01, EuanM <euanmee(a)gmail.com> wrote: >>> "I wish people would choose descriptive names for their projects" - >>> Todd >>> >>> I agree. >>> >>> I went looking for the current state of dbxtalk recently. It seemed >>> to ba apackage designed for my needs - to X[-over] from a DB to >>> [small]talk. >>> >>> I went there and the the page started talking about "Glorp" and >>> "Garage". Neither are mnemonic or meaningful >>> >>> These projects are just the tip of the iceberg. >>> >>> Pharo project names have publisher-only project names. The project >>> name equivalent of write-only computer languages, like Brain-F**k. >>> >>> >>> On 7 December 2015 at 17:52, Todd Blanchard <tblanchard(a)mac.com> wrote: >>>> Sigh. >>>> >>>> I wish people would choose descriptive names for their projects. I >>>> went looking on Smalltalkhub for some capability and what I found >>>> are thousands of packages with names that mean nothing and no >>>> description entered either. If you want to make sure nobody ever >>>> uses your code you've just taken a giant step in the right >>>> direction. But if you hope to make something lots of people >>>> benefit from - nobody is going to look for "mushroom" when they >>>> want crypto capabilities. >>>> >>>> Sorry, this has been really bugging me lately. We, as a community, >>>> do a lousy job of making our code easy to find. >>>> >>>> -Todd Blanchard >>>> >>>>> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >>>>> >>>>> I like it, but it seems you missed my point :) >>>>> mushroom --> 117,000,000 is two orders of magnitude more hidden. >>>>> Anyway, maybe I overplay its significance. >>>>> cheers -ben >>>>> >>>>> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>> I renamed the project to Mushroom and I also dumped the encoding >>>>>> work to >>>>>> focus on shutdown, optimization and serialization. Here's the wiki: >>>>>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>>>>> >>>>>> thanks,Robert >>>>>> >>>>>> >>>>>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>>>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>>> Now I think you are right on with your observation. >>>>>>>>>> Additionally, the >>>>>>>>>> number >>>>>>>>>> of dialects could increase further with Fuel serialization, >>>>>>>>>> just port >>>>>>>>>> SecureSession and bits. >>>>>>>>>> >>>>>>>>>> Alright, I came up with a name and it may border on the >>>>>>>>>> egregious ... >>>>>>>>>> presenting ... >>>>>>>>>> >>>>>>>>>> "Maelstrom" >>>>>>>>> Great sounding name. However some general advice for the >>>>>>>>> community, >>>>>>>>> since I see a lot of great sounding project names drowned out >>>>>>>>> in the >>>>>>>>> noise of our web-search-centric universe. A litmus test for >>>>>>>>> project >>>>>>>>> naming is using google search to find which return low search >>>>>>>>> results. >>>>>>>>> Today, its more important to be unique than any other >>>>>>>>> attribute of a >>>>>>>>> name. So in general, *dictionary* english words are not the >>>>>>>>> best. >>>>>>>>> One technique is to intentionally mispell the word you like. >>>>>>>>> Here are >>>>>>>>> some comparative examples (note, the surrounding quotes are >>>>>>>>> required >>>>>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>>>>> >>>>>>>>> "maelstrom" --> 7,480,000 >>>>>>>>> "maelstroom" --> 6,200 >>>>>>>>> "maelstrum" --> 2,280 >>>>>>>>> "maelstruum" --> 7 >>>>>>>>> >>>>>>>>> Lots of interesting other techniques can be found by searching >>>>>>>>> on: >>>>>>>>> techniques to generate brand names or domain names. >>>>>>>>> >>>>>>>>> cheers -ben >>>>>>>> >>>>>>>> I would be happy to change the names to something more unique, >>>>>>>> though it >>>>>>>> may >>>>>>>> take a few. Are you suggesting "maelstruum"? >>>>>>>> >>>>>>>> cheers, >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>>>>> >>>>>>> I think maelstruum is certainly memorable with the double "u", but >>>>>>> maybe jarring next the the "m". I'm inclined to maelstroom, >>>>>>> since I >>>>>>> associate it with "zoom". I wouldn't necessarily go for the >>>>>>> absolute >>>>>>> lowest results. I have an entirely unsubstantiated belief that >>>>>>> anything less than 10,000 gives a reasonable chance to compete >>>>>>> once a >>>>>>> user's browsing history is taken into account. Finally you need to >>>>>>> check existing results don't return something abhorrent (I >>>>>>> didn't do >>>>>>> this). >>>>>>> >>>>>>> I'd encourage to play around testing on google search. Its >>>>>>> quick and >>>>>>> easy to generate and test alternatives. I've added a few more >>>>>>> below. >>>>>>> "maelstra" --> 3,560 >>>>>>> "maelstram" --> 504 >>>>>>> "maelstrim" --> 1200 >>>>>>> "maelstroon" --> 58 >>>>>>> "maelstroomi" --> 4 >>>>>>> >>>>>>> btw, I wouldn't swap the order of the "ae" since that would be >>>>>>> susceptible to real typing errors. >>>>>>> >>>>>>> cheers -ben >>>>>>> >>>>>> >>>> >

Dec. 8, 2015

Re: [Pharo-users] When a metaclass is initialised by the system ?

by Thierry Goubier

Le 08/12/2015 16:53, Christophe Demarey a Ã©crit : > yes, we miss a package initialize method ... FileTree, GitFileTree and probably Monticello have support for a package initialize method. Now, when I was doing my browser, I wondered about giving access to such code... turns out nobody uses it. Thierry > > Le 8 dÃ©c. 2015 Ã 16:35, Mariano Martinez Peck a Ã©crit : > >> Dimitris, >> >> Relying in class side initialize is not very cool. Mostly, because >> it's hard to know EXACTLY when Monticello will send it. For sure it's >> the first time you load that class. But then it could be if such >> method changes again. But maybe too if you clear some Monticello caches... >> Also, you may have dependencies (of order execution) with other class >> side initialize. So...another approaches you can take (depending on >> your needs) is lazy class var getters with ifNil: or if you have a >> ConfigurationOfYourApp, you can define #postLoadDoIts in which you can >> perform the whole initialization of your app. Or ...from the >> #postLoadDoIts simply delegate to a class MyAppInitialize. >> >> I do a bit of all of them hahaha. >> >> Cheers, >> >> On Mon, Dec 7, 2015 at 9:11 PM, Dimitris Chloupis >> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> ok that means I cannot rely on it and I will have to initialize >> my class variables in specific methods. No problem, ifNil here I >> come :) >> >> On Tue, Dec 8, 2015 at 12:24 AM Sven Van Caekenberghe >> <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> Hi Dimitris, >> >> > On 07 Dec 2015, at 23:12, Dimitris Chloupis >> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> > >> > I have read that a metaclass (class side of the class) is >> initialised when its loaded to the image by monticello, Are >> there any other cases when the initialize method of the the >> metaclass is being called ? >> >> Correct: a class #initialize is called when its code is >> loaded, but only if it is not yet present or different in >> source code from what is already present (this last point will >> bite you one day ;-). >> >> Else, the #initialize should be called manually (for example >> to reload some caches, or reset some system state). This >> sometimes happens in #postLoads or install scripts. >> >> I am not aware of any automatic invocations. >> >> Sven >> >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >

Dec. 8, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by Robert Withers

On 12/08/2015 04:20 PM, Robert Withers wrote: > I would need to disagree with you as inquiry is possible by > description, rather than by name, through conversation with those who > don't have to inquire, due to their knowledge [see Meno's Paradox...]. > So, a third possibility exists through communal association. Do you > know Kevin Bacon? ;-) > > I've used that language! Well, no, I haven't, but there is high affinity. > > On 12/08/2015 04:02 PM, EuanM wrote: >> The philosophical issue behind the disutility of project names like >> these is "Meno's Paradox" >> >> On 8 December 2015 at 21:01, EuanM <euanmee(a)gmail.com> wrote: >>> "I wish people would choose descriptive names for their projects" - >>> Todd >>> >>> I agree. >>> >>> I went looking for the current state of dbxtalk recently. It seemed >>> to ba apackage designed for my needs - to X[-over] from a DB to >>> [small]talk. >>> >>> I went there and the the page started talking about "Glorp" and >>> "Garage". Neither are mnemonic or meaningful >>> >>> These projects are just the tip of the iceberg. >>> >>> Pharo project names have publisher-only project names. The project >>> name equivalent of write-only computer languages, like Brain-F**k. >>> >>> >>> On 7 December 2015 at 17:52, Todd Blanchard <tblanchard(a)mac.com> wrote: >>>> Sigh. >>>> >>>> I wish people would choose descriptive names for their projects. I >>>> went looking on Smalltalkhub for some capability and what I found >>>> are thousands of packages with names that mean nothing and no >>>> description entered either. If you want to make sure nobody ever >>>> uses your code you've just taken a giant step in the right >>>> direction. But if you hope to make something lots of people >>>> benefit from - nobody is going to look for "mushroom" when they >>>> want crypto capabilities. >>>> >>>> Sorry, this has been really bugging me lately. We, as a community, >>>> do a lousy job of making our code easy to find. >>>> >>>> -Todd Blanchard >>>> >>>>> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >>>>> >>>>> I like it, but it seems you missed my point :) >>>>> mushroom --> 117,000,000 is two orders of magnitude more hidden. >>>>> Anyway, maybe I overplay its significance. >>>>> cheers -ben >>>>> >>>>> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>> I renamed the project to Mushroom and I also dumped the encoding >>>>>> work to >>>>>> focus on shutdown, optimization and serialization. Here's the wiki: >>>>>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>>>>> >>>>>> thanks,Robert >>>>>> >>>>>> >>>>>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>>>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>>> Now I think you are right on with your observation. >>>>>>>>>> Additionally, the >>>>>>>>>> number >>>>>>>>>> of dialects could increase further with Fuel serialization, >>>>>>>>>> just port >>>>>>>>>> SecureSession and bits. >>>>>>>>>> >>>>>>>>>> Alright, I came up with a name and it may border on the >>>>>>>>>> egregious ... >>>>>>>>>> presenting ... >>>>>>>>>> >>>>>>>>>> "Maelstrom" >>>>>>>>> Great sounding name. However some general advice for the >>>>>>>>> community, >>>>>>>>> since I see a lot of great sounding project names drowned out >>>>>>>>> in the >>>>>>>>> noise of our web-search-centric universe. A litmus test for >>>>>>>>> project >>>>>>>>> naming is using google search to find which return low search >>>>>>>>> results. >>>>>>>>> Today, its more important to be unique than any other >>>>>>>>> attribute of a >>>>>>>>> name. So in general, *dictionary* english words are not the >>>>>>>>> best. >>>>>>>>> One technique is to intentionally mispell the word you like. >>>>>>>>> Here are >>>>>>>>> some comparative examples (note, the surrounding quotes are >>>>>>>>> required >>>>>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>>>>> >>>>>>>>> "maelstrom" --> 7,480,000 >>>>>>>>> "maelstroom" --> 6,200 >>>>>>>>> "maelstrum" --> 2,280 >>>>>>>>> "maelstruum" --> 7 >>>>>>>>> >>>>>>>>> Lots of interesting other techniques can be found by searching >>>>>>>>> on: >>>>>>>>> techniques to generate brand names or domain names. >>>>>>>>> >>>>>>>>> cheers -ben >>>>>>>> >>>>>>>> I would be happy to change the names to something more unique, >>>>>>>> though it >>>>>>>> may >>>>>>>> take a few. Are you suggesting "maelstruum"? >>>>>>>> >>>>>>>> cheers, >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>>>>> >>>>>>> I think maelstruum is certainly memorable with the double "u", but >>>>>>> maybe jarring next the the "m". I'm inclined to maelstroom, >>>>>>> since I >>>>>>> associate it with "zoom". I wouldn't necessarily go for the >>>>>>> absolute >>>>>>> lowest results. I have an entirely unsubstantiated belief that >>>>>>> anything less than 10,000 gives a reasonable chance to compete >>>>>>> once a >>>>>>> user's browsing history is taken into account. Finally you need to >>>>>>> check existing results don't return something abhorrent (I >>>>>>> didn't do >>>>>>> this). >>>>>>> >>>>>>> I'd encourage to play around testing on google search. Its >>>>>>> quick and >>>>>>> easy to generate and test alternatives. I've added a few more >>>>>>> below. >>>>>>> "maelstra" --> 3,560 >>>>>>> "maelstram" --> 504 >>>>>>> "maelstrim" --> 1200 >>>>>>> "maelstroon" --> 58 >>>>>>> "maelstroomi" --> 4 >>>>>>> >>>>>>> btw, I wouldn't swap the order of the "ae" since that would be >>>>>>> susceptible to real typing errors. >>>>>>> >>>>>>> cheers -ben >>>>>>> >>>>>> >>>> >

Dec. 8, 2015

Re: [Pharo-users] Roassal: Multiple Nesting

by Alexandre Bergel

Hi Leonel, Currently, a roassal element is not composed. So, this means you need to all the elements to the view, and then define the nesting. >From your script, you do not gain much by directly talking to Roassal. You should better use a builder, such as Mondrian. I think your script can be: -=-=-=-=-=-=-=-= packages := { 'Roassal2GT' . 'Trachel' } collect: [ :name | RPackageOrganizer default packageNamed: name ]. b := RTMondrian new. b nodes: packages forEach: [ :pak | b nodes: pak classes forEach: [ :cls | b nodes: cls methods. b layout grid ]. b layout grid ]. b -=-=-=-=-=-=-=-= Here is a version of what you try to do using plain Roassal: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Packages to visualize" packages := { 'Roassal2GT' . 'Trachel' } collect: [ :name | RPackageOrganizer default packageNamed: name ]. palette := RTPalette c10. v := RTView new. packagesElements := (RTBox new color: palette first) elementsOn: packages. v addAll: packagesElements. packagesElements @ RTPopup. packagesElements do: [ :pakEl | clsElements := (RTBox new color: palette second) elementsOn: pakEl model classes. v addAll: clsElements. clsElements do: [ :clsEl | mtdElements := (RTBox new color: palette third) elementsOn: clsEl model methods. v addAll: mtdElements. mtdElements @ RTPopup. RTGridLayout on: mtdElements. RTNest new on: clsEl nest: mtdElements. ]. RTGridLayout on: clsElements. RTNest new on: pakEl nest: clsElements. clsElements @ RTPopup. ]. RTGridLayout on: packagesElements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= With the colors: Cheers, Alexandre > On Dec 8, 2015, at 1:35 PM, Leonel Merino <merino(a)iam.unibe.ch> wrote: > > Hi all, > > I want to visualise three nested levels of a model. I am not sure if I am doing it right, since I had to add a reference to the view to the nested elements manually to make it work. The problem I face now is that elements in the deepest level do not react to interactions. In the example below, popup is only shown for the elements in the first two levels. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > v := RTView new. > es := (RTBox new > color: Color white; > borderColor: Color lightGray) > elementsOn: (Array with: RTLayout with: RTShape with: RTBuilder). > v addAll: es. > es @ RTPopup. > RTNest new > for: es > add: > [ :group :model | > elements := (RTBox new color: (Color red alpha: 0.1)) elementsOn: model withAllSubclasses. > group addAll: elements. > elements @ RTPopup. > elements do: [ :e | e view: v ]. > RTNest new > for: elements > add: > [ :group2 :model2 | > els := (RTBox new color: Color blue) elementsOn: model2 methods. > group2 addAll: els. > els @ RTPopup. > RTTreeLayout on: els edges: edges ]. > RTGridLayout on: elements ]. > RTGridLayout on: es. > v > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Any hint would be much appreciated. > > Best regards, > Leonel -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 8, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by Robert Withers

I would need to disagree with you as inquiry is possible by description, rather than by name, through conversation with those who don't have to inquire, due to their knowledge [see Meno's Paradox...]. So, a third possibility exists through communal association. Do you know Kevin Bacon? ;-) I've used that language! On 12/08/2015 04:02 PM, EuanM wrote: > The philosophical issue behind the disutility of project names like > these is "Meno's Paradox" > > On 8 December 2015 at 21:01, EuanM <euanmee(a)gmail.com> wrote: >> "I wish people would choose descriptive names for their projects" - Todd >> >> I agree. >> >> I went looking for the current state of dbxtalk recently. It seemed >> to ba apackage designed for my needs - to X[-over] from a DB to >> [small]talk. >> >> I went there and the the page started talking about "Glorp" and >> "Garage". Neither are mnemonic or meaningful >> >> These projects are just the tip of the iceberg. >> >> Pharo project names have publisher-only project names. The project >> name equivalent of write-only computer languages, like Brain-F**k. >> >> >> On 7 December 2015 at 17:52, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> Sigh. >>> >>> I wish people would choose descriptive names for their projects. I went looking on Smalltalkhub for some capability and what I found are thousands of packages with names that mean nothing and no description entered either. If you want to make sure nobody ever uses your code you've just taken a giant step in the right direction. But if you hope to make something lots of people benefit from - nobody is going to look for "mushroom" when they want crypto capabilities. >>> >>> Sorry, this has been really bugging me lately. We, as a community, do a lousy job of making our code easy to find. >>> >>> -Todd Blanchard >>> >>>> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >>>> >>>> I like it, but it seems you missed my point :) >>>> mushroom --> 117,000,000 is two orders of magnitude more hidden. >>>> Anyway, maybe I overplay its significance. >>>> cheers -ben >>>> >>>> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >>>> <robert.w.withers(a)gmail.com> wrote: >>>>> I renamed the project to Mushroom and I also dumped the encoding work to >>>>> focus on shutdown, optimization and serialization. Here's the wiki: >>>>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>>>> >>>>> thanks,Robert >>>>> >>>>> >>>>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>>> Now I think you are right on with your observation. Additionally, the >>>>>>>>> number >>>>>>>>> of dialects could increase further with Fuel serialization, just port >>>>>>>>> SecureSession and bits. >>>>>>>>> >>>>>>>>> Alright, I came up with a name and it may border on the egregious ... >>>>>>>>> presenting ... >>>>>>>>> >>>>>>>>> "Maelstrom" >>>>>>>> Great sounding name. However some general advice for the community, >>>>>>>> since I see a lot of great sounding project names drowned out in the >>>>>>>> noise of our web-search-centric universe. A litmus test for project >>>>>>>> naming is using google search to find which return low search results. >>>>>>>> Today, its more important to be unique than any other attribute of a >>>>>>>> name. So in general, *dictionary* english words are not the best. >>>>>>>> One technique is to intentionally mispell the word you like. Here are >>>>>>>> some comparative examples (note, the surrounding quotes are required >>>>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>>>> >>>>>>>> "maelstrom" --> 7,480,000 >>>>>>>> "maelstroom" --> 6,200 >>>>>>>> "maelstrum" --> 2,280 >>>>>>>> "maelstruum" --> 7 >>>>>>>> >>>>>>>> Lots of interesting other techniques can be found by searching on: >>>>>>>> techniques to generate brand names or domain names. >>>>>>>> >>>>>>>> cheers -ben >>>>>>> >>>>>>> I would be happy to change the names to something more unique, though it >>>>>>> may >>>>>>> take a few. Are you suggesting "maelstruum"? >>>>>>> >>>>>>> cheers, >>>>>>> Robert >>>>>>> >>>>>>> >>>>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>>>> >>>>>> I think maelstruum is certainly memorable with the double "u", but >>>>>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>>>>> associate it with "zoom". I wouldn't necessarily go for the absolute >>>>>> lowest results. I have an entirely unsubstantiated belief that >>>>>> anything less than 10,000 gives a reasonable chance to compete once a >>>>>> user's browsing history is taken into account. Finally you need to >>>>>> check existing results don't return something abhorrent (I didn't do >>>>>> this). >>>>>> >>>>>> I'd encourage to play around testing on google search. Its quick and >>>>>> easy to generate and test alternatives. I've added a few more below. >>>>>> "maelstra" --> 3,560 >>>>>> "maelstram" --> 504 >>>>>> "maelstrim" --> 1200 >>>>>> "maelstroon" --> 58 >>>>>> "maelstroomi" --> 4 >>>>>> >>>>>> btw, I wouldn't swap the order of the "ae" since that would be >>>>>> susceptible to real typing errors. >>>>>> >>>>>> cheers -ben >>>>>> >>>>> >>>

Dec. 8, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by EuanM

The philosophical issue behind the disutility of project names like these is "Meno's Paradox" On 8 December 2015 at 21:01, EuanM <euanmee(a)gmail.com> wrote: > "I wish people would choose descriptive names for their projects" - Todd > > I agree. > > I went looking for the current state of dbxtalk recently. It seemed > to ba apackage designed for my needs - to X[-over] from a DB to > [small]talk. > > I went there and the the page started talking about "Glorp" and > "Garage". Neither are mnemonic or meaningful > > These projects are just the tip of the iceberg. > > Pharo project names have publisher-only project names. The project > name equivalent of write-only computer languages, like Brain-F**k. > > > On 7 December 2015 at 17:52, Todd Blanchard <tblanchard(a)mac.com> wrote: >> Sigh. >> >> I wish people would choose descriptive names for their projects. I went looking on Smalltalkhub for some capability and what I found are thousands of packages with names that mean nothing and no description entered either. If you want to make sure nobody ever uses your code you've just taken a giant step in the right direction. But if you hope to make something lots of people benefit from - nobody is going to look for "mushroom" when they want crypto capabilities. >> >> Sorry, this has been really bugging me lately. We, as a community, do a lousy job of making our code easy to find. >> >> -Todd Blanchard >> >>> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> I like it, but it seems you missed my point :) >>> mushroom --> 117,000,000 is two orders of magnitude more hidden. >>> Anyway, maybe I overplay its significance. >>> cheers -ben >>> >>> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >>> <robert.w.withers(a)gmail.com> wrote: >>>> I renamed the project to Mushroom and I also dumped the encoding work to >>>> focus on shutdown, optimization and serialization. Here's the wiki: >>>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>>> >>>> thanks,Robert >>>> >>>> >>>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>>> >>>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>> >>>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>>> >>>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>>> >>>>>>>> Now I think you are right on with your observation. Additionally, the >>>>>>>> number >>>>>>>> of dialects could increase further with Fuel serialization, just port >>>>>>>> SecureSession and bits. >>>>>>>> >>>>>>>> Alright, I came up with a name and it may border on the egregious ... >>>>>>>> presenting ... >>>>>>>> >>>>>>>> "Maelstrom" >>>>>>> >>>>>>> Great sounding name. However some general advice for the community, >>>>>>> since I see a lot of great sounding project names drowned out in the >>>>>>> noise of our web-search-centric universe. A litmus test for project >>>>>>> naming is using google search to find which return low search results. >>>>>>> Today, its more important to be unique than any other attribute of a >>>>>>> name. So in general, *dictionary* english words are not the best. >>>>>>> One technique is to intentionally mispell the word you like. Here are >>>>>>> some comparative examples (note, the surrounding quotes are required >>>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>>> >>>>>>> "maelstrom" --> 7,480,000 >>>>>>> "maelstroom" --> 6,200 >>>>>>> "maelstrum" --> 2,280 >>>>>>> "maelstruum" --> 7 >>>>>>> >>>>>>> Lots of interesting other techniques can be found by searching on: >>>>>>> techniques to generate brand names or domain names. >>>>>>> >>>>>>> cheers -ben >>>>>> >>>>>> >>>>>> I would be happy to change the names to something more unique, though it >>>>>> may >>>>>> take a few. Are you suggesting "maelstruum"? >>>>>> >>>>>> cheers, >>>>>> Robert >>>>>> >>>>>> >>>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>>> >>>>> I think maelstruum is certainly memorable with the double "u", but >>>>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>>>> associate it with "zoom". I wouldn't necessarily go for the absolute >>>>> lowest results. I have an entirely unsubstantiated belief that >>>>> anything less than 10,000 gives a reasonable chance to compete once a >>>>> user's browsing history is taken into account. Finally you need to >>>>> check existing results don't return something abhorrent (I didn't do >>>>> this). >>>>> >>>>> I'd encourage to play around testing on google search. Its quick and >>>>> easy to generate and test alternatives. I've added a few more below. >>>>> "maelstra" --> 3,560 >>>>> "maelstram" --> 504 >>>>> "maelstrim" --> 1200 >>>>> "maelstroon" --> 58 >>>>> "maelstroomi" --> 4 >>>>> >>>>> btw, I wouldn't swap the order of the "ae" since that would be >>>>> susceptible to real typing errors. >>>>> >>>>> cheers -ben >>>>> >>>> >>>> >>> >> >>

Dec. 8, 2015

Re: [Pharo-users] [squeak-dev] Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by EuanM

"I wish people would choose descriptive names for their projects" - Todd I agree. I went looking for the current state of dbxtalk recently. It seemed to ba apackage designed for my needs - to X[-over] from a DB to [small]talk. I went there and the the page started talking about "Glorp" and "Garage". Neither are mnemonic or meaningful These projects are just the tip of the iceberg. Pharo project names have publisher-only project names. The project name equivalent of write-only computer languages, like Brain-F**k. On 7 December 2015 at 17:52, Todd Blanchard <tblanchard(a)mac.com> wrote: > Sigh. > > I wish people would choose descriptive names for their projects. I went looking on Smalltalkhub for some capability and what I found are thousands of packages with names that mean nothing and no description entered either. If you want to make sure nobody ever uses your code you've just taken a giant step in the right direction. But if you hope to make something lots of people benefit from - nobody is going to look for "mushroom" when they want crypto capabilities. > > Sorry, this has been really bugging me lately. We, as a community, do a lousy job of making our code easy to find. > > -Todd Blanchard > >> On Dec 7, 2015, at 07:38, Ben Coman <btc(a)openInWorld.com> wrote: >> >> I like it, but it seems you missed my point :) >> mushroom --> 117,000,000 is two orders of magnitude more hidden. >> Anyway, maybe I overplay its significance. >> cheers -ben >> >> On Mon, Dec 7, 2015 at 11:11 PM, Robert Withers >> <robert.w.withers(a)gmail.com> wrote: >>> I renamed the project to Mushroom and I also dumped the encoding work to >>> focus on shutdown, optimization and serialization. Here's the wiki: >>> https://github.com/SqueakCryptographySquad/Mushroom/wiki >>> >>> thanks,Robert >>> >>> >>> On 12/06/2015 01:42 AM, Ben Coman wrote: >>>> >>>> On Sun, Dec 6, 2015 at 10:42 AM, Robert Withers >>>> <robert.w.withers(a)gmail.com> wrote: >>>>> >>>>> On 12/05/2015 09:24 PM, Ben Coman wrote: >>>>>> >>>>>> On Fri, Dec 4, 2015 at 11:57 PM, Robert Withers >>>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>>> >>>>>>> Now I think you are right on with your observation. Additionally, the >>>>>>> number >>>>>>> of dialects could increase further with Fuel serialization, just port >>>>>>> SecureSession and bits. >>>>>>> >>>>>>> Alright, I came up with a name and it may border on the egregious ... >>>>>>> presenting ... >>>>>>> >>>>>>> "Maelstrom" >>>>>> >>>>>> Great sounding name. However some general advice for the community, >>>>>> since I see a lot of great sounding project names drowned out in the >>>>>> noise of our web-search-centric universe. A litmus test for project >>>>>> naming is using google search to find which return low search results. >>>>>> Today, its more important to be unique than any other attribute of a >>>>>> name. So in general, *dictionary* english words are not the best. >>>>>> One technique is to intentionally mispell the word you like. Here are >>>>>> some comparative examples (note, the surrounding quotes are required >>>>>> to avoid google trying to be helpful and correct the spelling)... >>>>>> >>>>>> "maelstrom" --> 7,480,000 >>>>>> "maelstroom" --> 6,200 >>>>>> "maelstrum" --> 2,280 >>>>>> "maelstruum" --> 7 >>>>>> >>>>>> Lots of interesting other techniques can be found by searching on: >>>>>> techniques to generate brand names or domain names. >>>>>> >>>>>> cheers -ben >>>>> >>>>> >>>>> I would be happy to change the names to something more unique, though it >>>>> may >>>>> take a few. Are you suggesting "maelstruum"? >>>>> >>>>> cheers, >>>>> Robert >>>>> >>>>> >>>> *Suggesting* yes, but the choice is yours ;) You need to own it. >>>> >>>> I think maelstruum is certainly memorable with the double "u", but >>>> maybe jarring next the the "m". I'm inclined to maelstroom, since I >>>> associate it with "zoom". I wouldn't necessarily go for the absolute >>>> lowest results. I have an entirely unsubstantiated belief that >>>> anything less than 10,000 gives a reasonable chance to compete once a >>>> user's browsing history is taken into account. Finally you need to >>>> check existing results don't return something abhorrent (I didn't do >>>> this). >>>> >>>> I'd encourage to play around testing on google search. Its quick and >>>> easy to generate and test alternatives. I've added a few more below. >>>> "maelstra" --> 3,560 >>>> "maelstram" --> 504 >>>> "maelstrim" --> 1200 >>>> "maelstroon" --> 58 >>>> "maelstroomi" --> 4 >>>> >>>> btw, I wouldn't swap the order of the "ae" since that would be >>>> susceptible to real typing errors. >>>> >>>> cheers -ben >>>> >>> >>> >> > >

Dec. 8, 2015

Re: [Pharo-users] When a metaclass is initialised by the system ?

by Dimitris Chloupis

What about slots ? Do they have any special initialiazation ? On Tue, 8 Dec 2015 at 17:54, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > yes, we miss a package initialize method ... > > Le 8 dÃ©c. 2015 Ã 16:35, Mariano Martinez Peck a Ã©crit : > > Dimitris, > > Relying in class side initialize is not very cool. Mostly, because it's > hard to know EXACTLY when Monticello will send it. For sure it's the first > time you load that class. But then it could be if such method changes > again. But maybe too if you clear some Monticello caches... > Also, you may have dependencies (of order execution) with other class side > initialize. So...another approaches you can take (depending on your needs) > is lazy class var getters with ifNil: or if you have a > ConfigurationOfYourApp, you can define #postLoadDoIts in which you can > perform the whole initialization of your app. Or ...from the #postLoadDoIts > simply delegate to a class MyAppInitialize. > > I do a bit of all of them hahaha. > > Cheers, > > On Mon, Dec 7, 2015 at 9:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> ok that means I cannot rely on it and I will have to initialize my class >> variables in specific methods. No problem, ifNil here I come :) >> >> On Tue, Dec 8, 2015 at 12:24 AM Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> Hi Dimitris, >>> >>> > On 07 Dec 2015, at 23:12, Dimitris Chloupis <kilon.alios(a)gmail.com> >>> wrote: >>> > >>> > I have read that a metaclass (class side of the class) is initialised >>> when its loaded to the image by monticello, Are there any other cases when >>> the initialize method of the the metaclass is being called ? >>> >>> Correct: a class #initialize is called when its code is loaded, but only >>> if it is not yet present or different in source code from what is already >>> present (this last point will bite you one day ;-). >>> >>> Else, the #initialize should be called manually (for example to reload >>> some caches, or reset some system state). This sometimes happens in >>> #postLoads or install scripts. >>> >>> I am not aware of any automatic invocations. >>> >>> Sven >>> >>> >>> >>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com > > >

Dec. 8, 2015

Re: [Pharo-users] Stop Thinking in Terms of Files

by EuanM

I think it's potentially could be provided using Monticello as a basis, rather than "technically already available through Monticello", In many ways, you are describing the Catalog Browser / Configurstion Browser of Pharo, which is built on top of Monticello, Metacello, and Versionner. On 7 Dec 2015 22:09, "Dimitris Chloupis" <kilon.alios(a)gmail.com> wrote: > And this "victory of dead code and date" that files usually promote can > further benefit Pharo . > > For example lets take one of the main problems of the Pharo image, its > size. There is already an effort to modularilise the image to make it small > and everything else installable and unistallable. > > But why not go a step further and have dead zone files. So you end up with > a tiny image containing just the basics (few kbs if possible) even no GUI > and IDE tools and instead you have a collection of files that can be read > by the image , each file contains a diffirent project, you can view their > code and their data but not install them in the image to do so. And only > when you decide that "sure I could use this project" then you instruct the > image to import the file and make the code and the data live and part of > the image. This way the pharo system can keep growing without growing the > image at all and let the users decide how much they want to grow the image > themselves. > > Technically speaking this functionality is already available through > monticello , where monticello allow you to view a local or remote > repository of code without loading the code to the image (via the "open > button"). So its not even a new concept. Though in my mind I imagine all > this happening from inside the System Browser. > > Thats just one scenario how dead data and code can greatly benefit the > Pharo system. I can keep brainstorming forever for the usefulness of files > for Pharo. > > > On Mon, Dec 7, 2015 at 9:20 PM horrido <horrido.hobbies(a)gmail.com> wrote: > >> You make a convincing argument. Files are useful. >> >> In modern circumstances, Smalltalk has to coexist with a file-based world. >> As Joachim wrote earlier, we are well-equipped to deal with files, but we >> do >> not think in terms of files when we code our applications. We are not >> obliged to use a file-based toolchain. The point of my article was to >> persuade other developers that letting their obsession with file-based >> tools >> prevent them from adopting Smalltalk is short-sighted and >> counter-productive. Files have their uses, but they should look beyond >> files >> for other software creation possibilities. Smalltalk has much to offer. >> >> And, yes, it would be very good to have 64-bit support in Smalltalk. >> >> >> >> kilon.alios wrote >> > The devil is in the details ;) >> > >> > It matters to me, I just came across the need to share data between >> > multiple images. So I was pointed by the good people here to the Fuel >> > library that , surprise surprise , it generates binary files that >> contain >> > objects in their live state that helps you move and share code and data >> > between images. Works well and I really like its design :) >> > >> > We are not talking here about something sophisticated, we are talking >> here >> > super basic functionality. Images sharing data and code. What we use ? >> > Files. The image by itself has no functionality to even cover this super >> > basic scenario because as a format is made to be self contained. >> > >> > How you cant even care for such basic functionality ? Of course you will >> > at >> > some point. Its unavoidable. >> > >> > The nice thing about files is that they have one very big advantage over >> > the image. That is, specialization. When an app find a specific file , >> > just >> > by looking at its extension it immediately knows the structure of the >> data >> > and the code that it may contain. >> > >> > On other hand when you have an object system like the image is, such >> > specifications go outside the window meaning you have to deal with the >> > fact >> > and trust that those that made those images have adhered to specific >> > guidelines so you can make sure that your code wont run in front of some >> > very nasty surprises. >> > >> > But since the image itself allow you hack so deeply as the syntax of the >> > language , you can't be sure how the data and code will be presented. >> Sure >> > they will objects, but the format does not really matter so much as the >> > structure itself. >> > >> > In those cases files win hands down because they tend to be far more >> > restricted on how they are structured. Not because there is anything >> > special to these files, apart from the fact that their authors made sure >> > to >> > follow the specific structure to ensure compatibility with third party >> > apps. >> > >> > So not only Files are not on the Stone Age but they have evolved the >> level >> > of specification to a whole new level that have made the foundation of >> our >> > every day lives. >> > >> > Sure you could probably replace files with a new way that is more >> > Smalltalk >> > friendly and still retain all the advantages of files and file system >> but >> > , >> > Smalltalk has not presented such solution to my knowledge. Hence we the >> > smalltalkers we will still keep relying heavily on files for our every >> day >> > needs until such solution is presented to us. Also with the huge wealth >> of >> > file formats it would be a pain in the ass to replace them with a >> > smalltalk >> > solution. >> > >> > In the mean time there are even more pressing matter that the image file >> > has to attend to, which is far more stone age , to use your remark , >> than >> > files. That is the ability to use full memory of the system and the >> > ability >> > to deal with large data without any large hits on performance. In short >> > good support for 64 bit and big data. >> > >> > >> > "But these are implementation details...implementation of the base >> system. >> > /From the perspective of a programmer writing an application/, none of >> > this >> > matters. >> > >> > As I said earlier, the only reason why Smalltalk has to deal with files >> at >> > all is because we live in a file-based culture. And the reason our >> culture >> > is so entrenched with files is because we are too heavily invested in >> > them, >> > and we aren't going to budge. *Files are about as low a storage >> > abstraction >> > as you can get*, and they pre-date even Unix. Yes, files belong in the >> > Stone >> > Age!" >> > >> > On Mon, Dec 7, 2015 at 6:45 PM horrido < >> >> > horrido.hobbies@ >> >> > > wrote: >> > >> >> But these are implementation details...implementation of the base >> system. >> >> /From the perspective of a programmer writing an application/, none of >> >> this >> >> matters. >> >> >> >> As I said earlier, the only reason why Smalltalk has to deal with files >> >> at >> >> all is because we live in a file-based culture. And the reason our >> >> culture >> >> is so entrenched with files is because we are too heavily invested in >> >> them, >> >> and we aren't going to budge. *Files are about as low a storage >> >> abstraction >> >> as you can get*, and they pre-date even Unix. Yes, files belong in the >> >> Stone >> >> Age! >> >> >> >> >> >> >> >> kilon.alios wrote >> >> > That's the thing you can't take the argument further without >> >> diminishing >> >> > the value of you argument precisely for the fact that the vm is far >> >> closer >> >> > related to the image than it is to 0s and 1s. That tight relation is >> >> > fundamental to the behavior and existence of the image. It defines >> its >> >> > functionality, purpose and limitations. >> >> > >> >> > The image itself is a file and the fact that it can store live state >> in >> >> a >> >> > binary format does not make it unique or any less of a file. In my >> case >> >> I >> >> > use blender files, they store the entire live state of the blender >> >> window >> >> > including images and even Python scripts. Similar examples are >> >> countless >> >> > out there. >> >> > >> >> > So the answer to the question what makes the image file format unique >> >> is >> >> > simply.... Nothing >> >> > What's the advantage of using the image format compared to other >> files >> >> ? >> >> > None >> >> > >> >> > On Mon, 7 Dec 2015 at 15:14, Ben Coman < >> >> >> >> > btc@ >> >> >> >> > > wrote: >> >> > >> >> >> On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis < >> >> >> >> > kilon.alios@ >> >> >> >> > > >> >> >> wrote: >> >> >> > "A Smalltalk Image is your entire system. The Image includes all >> the >> >> >> tools >> >> >> > required to interact, customize and add functionality to your >> >> system, >> >> >> so >> >> >> > Smalltalkâs IDE is a very Integrated Development Environment." >> >> >> > >> >> >> > >> >> >> > Thats not the case even for someone like me that has been working >> >> with >> >> >> > smalltalk for only 2 years. The Image is not even the engine that >> >> >> drives >> >> >> > smalltalk . Thats the job of the VM that exists in a completely >> >> >> different >> >> >> > universe than smalltalk. It exists in the same universe than many >> >> other >> >> >> > languages do exists and thats the C universe, the universe of the >> >> OS. >> >> >> > Essentially what drives your system is not smalltalk is C. The >> >> >> diffirence is >> >> >> > that for a part of it that is high level enough, Slang is used, a >> >> >> Hybrid >> >> >> > language between C and Smalltalk that compiles to C. So while in >> the >> >> >> image >> >> >> > everything is , well almost everything, an object all the way >> down, >> >> in >> >> >> the >> >> >> > VM everything is C all the way down. >> >> >> >> >> >> To take that argument further, the VM is not even the thing driving >> >> >> the image ;). Essentially what drives it are the 1's and 0's of >> >> >> machine code. Further, what drives that are the electrons flowing >> >> >> through the chip. I think its fair to say that we *code* in Pharo >> >> >> without files. Files relate to Pharo only to the same extent that a >> >> >> database like Oracle or Postgres can be said to use files. That is, >> >> >> when you do SQL queries, are you *thinking* in terms of files, even >> >> >> though files are used by the server to store the data? Its just a >> >> >> matter of where you draw the line of abstraction. >> >> >> >> >> >> cheers -ben >> >> >> >> >> >> > Ironically an image misses the most important tool to even >> generate >> >> >> this >> >> >> C >> >> >> > code and thats the VMMaker that has to be installed separately. >> And >> >> of >> >> >> > course there are parts of the system that are coded in pure C, >> like >> >> >> some >> >> >> > core functionalities of the VM and of course plugins and external >> >> >> libraries >> >> >> > that the image has to rely on make things happen. >> >> >> > >> >> >> > Of course the image is still fairly powerful, you can change the >> >> >> syntax, >> >> >> > implement high level libraries, IDE tools and much more. But its >> not >> >> >> the >> >> >> > core of the system just another essential part of it. >> >> >> > >> >> >> > >> >> >> > On Mon, Dec 7, 2015 at 9:24 AM Dimitris Chloupis < >> >> >> >> > kilon.alios@ >> >> >> >> > > >> >> >> > wrote: >> >> >> >>> >> >> >> >>> >> >> >> >>> well, i wouldn't need or even want it in memory, so on disk is >> >> fine. >> >> >> the >> >> >> >>> problem is more likely management of the same. browsing the >> >> changes >> >> >> is >> >> >> >>> not >> >> >> >>> really convenient. ideally i'd like to see versions in the >> >> >> class-browser >> >> >> >>> and >> >> >> >>> in the debugger, where on error i could then take a look at >> older >> >> >> >>> versions for >> >> >> >>> comparison, and switch to them to see if maybe the last change >> was >> >> >> the >> >> >> >>> cause of >> >> >> >>> the error. >> >> >> >>> >> >> >> >>> greetings, martin. >> >> >> >>> >> >> >> >> >> >> >> >> There are versions already for methods. So the functionality is >> >> there. >> >> >> >> >> >> >> >> I disagree however with you, I think that changes file was >> created >> >> for >> >> >> the >> >> >> >> precise scenarios of an image crash/ lockdown. In that case you >> may >> >> >> want to >> >> >> >> go back through the code and dont remember which method was >> >> triggered >> >> >> or >> >> >> >> what else was defined and created. In the case going >> >> chronologically >> >> >> which >> >> >> >> is how the changes file is already organised is far more useful >> >> than >> >> >> going >> >> >> >> method and class based. >> >> >> >> >> >> >> >> But I do agree it would be useful to extend the tools working >> with >> >> >> changes >> >> >> >> , but then none stop anyone from doing so and is not that hard to >> >> do. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> >> http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865820.html >> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865872.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>

Dec. 8, 2015