- Pharo-users - lists.pharo.org

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

by Todd Blanchard

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. 7, 2015

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

by horrido

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.

Dec. 7, 2015

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

by Martin BÃ¤hr

Excerpts from Thierry Goubier's message of 2015-12-07 09:33:37 +0100: > > > There are versions already for methods. So the functionality is there. > > only if i save them in monticello though, and i can't just switch the > > version of a single method, only the whole changeset at once. in git i can > > limit browsing to a specific file, and then copy an old version of a file > > into the current workspace. it is a bit crude, but it can be done. i don't > > see that kind of functionality in pharo. the data is there, but the tools > > to use the data in this specific manner are not. > They are there: I implemented and demoed what you describe as a need over > git a few years ago when I started GitFileTree [1]. > http://forum.world.st/Pharo-dev-Versions-Browser-over-gitfiletree-tp4695490… oh, i had no idea. that looks great. i hope i can find some time to look at this soon. > Then, probably over more than a year ago, Dale Henrich implemented a lot > more in his environment (tode). > > Now, what we may conclude is that the need may not be that great. well, part of the problem may be that things like these are hard to find. worse, unless you know that such functionality exists, you would not think to look for it. now i know, and now (well, soon :-) i will look! then the next question is, how do we get more people to be aware of this. adding it to pharo core would be one way, but probably a better solution would be to further improve the catalog browser so that i can see categories and drill those down. (i see that there are quite some improvements already in pharo 5, so maybe someone is already working on that) greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Dec. 7, 2015

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

by Dimitris Chloupis

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(a)openinworld.com> wrote: > On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > 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(a)gmail.com> > > 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. > >

Dec. 7, 2015

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

by Ben Coman

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. 7, 2015

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

by horrido

I don't understand people today. They seem so brittle and inflexible, unwilling to open their minds and learn. When I was fresh out of university, my only programming experience was with FORTRAN on mainframes. My first job was on the newest technology of the day: DEC PDP-11 <https://www.wikiwand.com/en/PDP-11> . Subsequently, I had jobs working on Tandem NonStop computers (GUARDIAN OS and TAL programming language), Modcomp systems and their assembler, Unix and C, VAX and DCL, AS/400, Windows, Smalltalk and Seaside, Python and web2py, Java and Android, Objective-C and iOS, etc. Each and every job was an exciting, stimulating learning opportunity. It was **fun** diving into unexplored territory. These various environments were quite different from one another. But I had no trouble adapting. The various programming languages had *substantially* different syntaxes. But I wasn't bothered. It took little time for me to get comfortable with each new language. So why is Smalltalk giving people conniptions? Are they really so spoiled? Re: today's IDEs (Eclipse, IntelliJ, Visual Studio, etc.). The problem isn't that they are so resource-hungry. It's that they're so damn complex. The file-based underpinnings, the "plumbing" if you will, is what have caused the design of these tools to evolve into complex behemoths. When you start with a clean slate, you can design a clean, elegant IDE without compromise. And that's what we have in Pharo. marten wrote > When we switched from VisualWorks/ENVY to C# around 2003 we were surprised > to see how bad source code management was in the Microsoft area those days > - and asking around in the usual community groups those days made one > think very clear: the world is thinking in files and noone will not be > able to force these large numbers of developers to change their behaviour. > That's the base problem. > > But we will also not be able to change these large numbers to Smalltalkers > anyway (mostly because it uses "." and NOT ";" or "[","]" instead of "{", > "}" - strange, that so many younger programmers have then problems with > this syntax - seems to come a monoculture of programmers ). > > These days we have git and svn and the quality of tools has improved very, > very much - but limitations of the file based process are still there, BUT > instead of changing the users: the tools available today (e.g. > VisualStudio) do a huge work in the background to give an intelligent view > on these files (where .NET is much better here than Java). So the users > have their loved files and still have some intelligent repository-like > view on the source code - they do not see the difference any more. The > drawback of this approach is the huge-memory-demand of these tools - where > Smalltalk's memory usage is more or less still there where is was 18 years > ago. That's also message. -- View this message in context: http://forum.world.st/Stop-Thinking-in-Terms-of-Files-tp4865614p4865800.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 7, 2015

Name change: Mushroom ( was Re: evolutions of squeakelib & crypto)

by Robert Withers

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. 7, 2015

Re: [Pharo-users] About GTSpotter matching

by Peter Uhnak

On 12/07, Juraj Kubelka wrote: > Hi, > > #<anything> is a category filter. Try #class, #instance, etc. Oh... right. I've been using this for long time, my brain just didn't connect the dots. In either case, once you dive in the category filter is no longer applicable. So normally I would do "#i selector", then dive in, and then filter it. > Then I have learnt that people are not aware of [...] any other kind of wild-characters. People don't know what wild-chars are? I would understand that someone might be uncomfortable with regexps, because there are many variations, but wildchars... > > > On Dec 5, 2015, at 20:40, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > are there some wildcards in GTSpotter matching? > > > > Currently it searches anywhere in the (method) name, which makes it hard > > for shorter names, because it will match a lot of junk. > > > > I've also discovered (by accident), that I can use '>>#selector' to > > anchor the start of the selection. ('#selector' for some reason doesn't > > work). > > But I would like to also search by a simple ? (any character), * (any > > characters) wildcard. Is that possible? > > > > Additionally constraining it from the end would be also nice. > > For example I want to look through #default methods, however 90% of the > > matches will be junk, so I would like to write '#default$' and it will > > not match '#defaultIcon', etc. > > > > Is this possible? > > > > Thanks, > > -- > > Peter > > > > -- Peter

Dec. 7, 2015

Re: [Pharo-users] About GTSpotter matching

by Johan Fabry

Itâs cool that you have this, category filters are very useful. But itâs not discoverable from the user interface so itâs very unlikely that people will know they exist (except if they are reading this message ;-) ). How about adding a âfiltersâ UI element at the top, that adds the #<relevant> expression to the search string when a filter is selected? > On Dec 7, 2015, at 09:52, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > Hi, > > #<anything> is a category filter. Try #class, #instance, etc. > > Wild characters are not possible to use. We are aware of this. But the case is not that simple. If I remember well, there were some performance issues. Then I have learnt that people are not aware of regular expressions or any other kind of wild-characters. Even such simple thing like #<category name> is confusing. We need to find out different way having this feature apparent. > > Cheers, > Juraj > >> On Dec 5, 2015, at 20:40, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> are there some wildcards in GTSpotter matching? >> >> Currently it searches anywhere in the (method) name, which makes it hard >> for shorter names, because it will match a lot of junk. >> >> I've also discovered (by accident), that I can use '>>#selector' to >> anchor the start of the selection. ('#selector' for some reason doesn't >> work). >> But I would like to also search by a simple ? (any character), * (any >> characters) wildcard. Is that possible? >> >> Additionally constraining it from the end would be also nice. >> For example I want to look through #default methods, however 90% of the >> matches will be junk, so I would like to write '#default$' and it will >> not match '#defaultIcon', etc. >> >> Is this possible? >> >> Thanks, >> -- >> Peter >> > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Dec. 7, 2015

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

by Ben Coman

On Mon, Dec 7, 2015 at 3:37 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> 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(a)gmail.com> > 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.

Dec. 7, 2015