January 2019 - Pharo-users - lists.pharo.org

PetitParser question

by Konrad Hinsen

Dear parsing experts, I have been working on a medium-size parser using the PetitParser framework, which so far has been a very productive environment. But now I have a problem to which I could not find the solution in "Deep into Pharo", nor by searching around in the code. One of my production rules requires several parsed items to be equal. It should accept expressions such as 1 + 3 + 2 + 6 2 * 9 * 3 * 6 0 - 8 - 5 - 3 but not expressions that mix different operators (because my grammar has no precedence rules and thus requires parentheses for disambiguation). In various other parsing frameworks, I do this by parsing up to the first operator, retrieving it, and permitting only that same string in the following. But I haven't found a way to do this in PetitParser, nor any other obvious solution. The only solution I see right now is to have one production rule per operator, but that makes for a huge grammar. Is there another way? Thanks in advance, Konrad

Jan. 26, 2019

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

by Dimitris Chloupis

"Abusing an external text editor is a slap in the face of anyone building good tooling support into Smalltalk over many years. I know Dimitris tried to help people (as often) - but I guess this video really gives a false impression and guides people the wrong way." Abusing ? Wait what on earth you talking about ? How is using an external editor , abusing ? Who is all mighty authority that says all these things ? Is there a coder out there that can predict the needs and preferences of every single coder ? Last time I checked we edit text inside pharo , not bytecode. Since when Smalltlak was not about source code, since when Smalltalk is not about text ? Oh sorry I forgot Pharo is not Smalltalk. Yeah I guess I have never been religiously enslaved to any ideology or belief and is true I do guide people the wrong way instead of taking something at face value, because some authority says so, to use their critical thinking and learn from their mistakes. Yeah I guess my slap in the face of people build good tooling , is a stream of videos that took me hours and hours to produce, that take newcomers by hand and teach them step by step how to make tools in Pharo. Or contributing to documentation because apparently building a good tooling will magically transmit the knowledge to user heads. My video is a problem and is not a problem that our documentation is still lagging behind even when the most basic book is concerned Pharo By Example ? My video is a problem and is not a problem that the vast majority of the code inside Pharo does not even have class comments ? My video is a problem and is not a problem that the image has been ridden with feature creep and accumulating complexity that serves no purpose ? My video is a problem and is not a problem that every time we talk about new technologies everything , we have to be informed again and again absolutely everything is inferior to Smalltalk ? My video is a problem and is not a problem that every time one dares to criticize Pharo or Smalltalk apparently we do not understand Smalltalk while they understand other technologies ? But worry not, the chances of me posting another video which were already extremely low have certainly reached absolute zero. I was planning to integrated an IPFS like system using bittorent protocol inside Pharo so I can interconnect images of our entire community into one universal virtual p2p image as a proof of concept for a commercial project I am developing for Blender. Main use there will be to unify asset management and code distribution in an image like fashion like happens in Pharo. https://ipfs.io/ But I guess this is also inferior to Smalltalk standards and a slap in the face of anyone making good tooling in Pharo. My hand got tired of slapping, I think I will take a break. On Sat, Jan 26, 2019 at 10:10 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 25 Jan 2019, at 20:52, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > Maybe Pharo's switch to Tonel remind people now on Java or C# class > files and thats why they ask for the "traditional editingâ. > > Nah, people talk about this time to time. > Tonel format is just a readable format that yes, cool be used to edit in > text files (but that was doable with chunk format too). > > For all the rest, +1 :) > > > But remember that Kent Beck once said: "I mean, source code in files; > how quaint, how seventies!". Tonel is a readable storage format, > > you could have the source code even in a database (with an ENVY and > STORE like approach) > > > > And ouch .... that video really hurts and I think it will be more > disturbing than helpful especially to many newbees > > now trying to use their favourite text editor for Pharo coding instead > of really learning about a very flexible IDE and workflow with > > browsing, interactively inspecting and refactorings. > > > > Abusing an external text editor is a slap in the face of anyone building > good tooling support into Smalltalk over many years. > > I know Dimitris tried to help people (as often) - but I guess this video > really gives a false impression and guides people the wrong way. > > > > Sorry - but I'm reminded on pictures like this: > > > > > https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagem… > > > > Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and > others are nice, I use them too for other languages or tasks. Nicely done - > but still > > too static. Often I wished only half of the money invested into such > IDE's could have been spend on better Smalltalk tooling. > > > > Remember: once VisualAge for Java got a price as the first usuable Java > IDE (when people used Notepad to write *.java files) - but underneath it was > > fully coded in Smalltalk and the Java debugger was the Smalltalk > debugger running the java subset of bytecodes. At that time VisualAge for > Smalltalk > > was the base for the full VisualAge series (VisualAge for Java, Visual > Age for C++ and others). > > > > But Smalltalk at that time unfortunately was expensive, licensing a > problem and big vendors had to prove one can do deliver similar things with > Java too - leading > > to Eclipse and others. But the best part on Eclipse was not Java - it > was the pluggability concept. The extension point mechanisms of the > platform provide > > a clear separation leading to a nice ecosystem of available plugins - > but still it is hard to write and debug a custom extension. > > > > A Smalltalk environment is still more dynamic, more lively where you can > browse, inspect and adjust nearly anything. And yes - you can even shoot > yourself in the foot. > > And yes we know Pharo does not provide fancy widgets yet or latest text > editing features - but this is a tribute to community resources. > > > > From my experience: if one free's his mind and gives up traditional > programming habits learned in mainstream languages he will enjoy the Pharo > journey > > much more. > > > > Bye > > T. > > > > > > >

Jan. 26, 2019

Re: [Pharo-users] Corrupted fonts in P7 after loading Glamorous Toolkit

by Esteban Lorenzano

I donât think is related to GToolkit, it is an ongoing bug we are having (and we still do not understand why it happens, but we are looking at it). In the mean time, saving the image will âfixâ the problem (because it will reset the font caches). Esteban > On 25 Jan 2019, at 17:43, Hilaire <hilaire(a)drgeo.eu> wrote: > > I did got this effect with GToolkit. I am not sure it is related to > GToolkit as I installed immediately this package, though. > > Hilaire > > Le 25/01/2019 Ã 16:55, Tim Mackinnon a Ã©crit : >> Hi - I just noticed that when I loaded the Glamorous toolkit and was playing around, when I went to look in the Pharo menus they are all corrupted (the odd character is some type of glyph). Opening a playground and doing some code completion shows that method names have the same random character glyphed. >> >> Anyone else seen this? Is is it something about loading GT? >> >> This is on OSX >> >> Tim > > -- > Dr. Geo > http://drgeo.eu > > >

Jan. 26, 2019

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

by Esteban Lorenzano

> On 25 Jan 2019, at 21:45, eftomi <tomaz.turk(a)ef.uni-lj.si> wrote: > > Well, who am I to judge, but developers nowadays use tools which engage > "muscle memory" to jump from one functionality of the editor to the other > and developer brains are used to work on the problem at hand. All this to > the extent that the mouse cannot be grasped with muscle memory alone and > then the brain is interrupted. Roughly speaking. cmd+h, then search for what you want (jump panels, execute commands, everything you can do in calypso you can find it there). > > I have a very practical question - is it possible to open Calypso, browse > for a package that I forgot the name but will recall it when I see it, > choose one of its classes, jump to its class methods, and start to edit one > of them - all with the keyboard, without the mouse? I searched for all > possible keystrokes but didn't find all the necessary keys to do all that. > > I believe going into a more attractive direction for today's developers > would not need too many resources, only a well thought set of shortcut > commands and a couple of tiny details would do. If time permits me to > contribute on that, I will. > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 26, 2019

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

by Esteban Lorenzano

> On 25 Jan 2019, at 20:52, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > Maybe Pharo's switch to Tonel remind people now on Java or C# class files and thats why they ask for the "traditional editingâ. Nah, people talk about this time to time. Tonel format is just a readable format that yes, cool be used to edit in text files (but that was doable with chunk format too). For all the rest, +1 :) > But remember that Kent Beck once said: "I mean, source code in files; how quaint, how seventies!". Tonel is a readable storage format, > you could have the source code even in a database (with an ENVY and STORE like approach) > > And ouch .... that video really hurts and I think it will be more disturbing than helpful especially to many newbees > now trying to use their favourite text editor for Pharo coding instead of really learning about a very flexible IDE and workflow with > browsing, interactively inspecting and refactorings. > > Abusing an external text editor is a slap in the face of anyone building good tooling support into Smalltalk over many years. > I know Dimitris tried to help people (as often) - but I guess this video really gives a false impression and guides people the wrong way. > > Sorry - but I'm reminded on pictures like this: > > https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagem… > > Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and others are nice, I use them too for other languages or tasks. Nicely done - but still > too static. Often I wished only half of the money invested into such IDE's could have been spend on better Smalltalk tooling. > > Remember: once VisualAge for Java got a price as the first usuable Java IDE (when people used Notepad to write *.java files) - but underneath it was > fully coded in Smalltalk and the Java debugger was the Smalltalk debugger running the java subset of bytecodes. At that time VisualAge for Smalltalk > was the base for the full VisualAge series (VisualAge for Java, Visual Age for C++ and others). > > But Smalltalk at that time unfortunately was expensive, licensing a problem and big vendors had to prove one can do deliver similar things with Java too - leading > to Eclipse and others. But the best part on Eclipse was not Java - it was the pluggability concept. The extension point mechanisms of the platform provide > a clear separation leading to a nice ecosystem of available plugins - but still it is hard to write and debug a custom extension. > > A Smalltalk environment is still more dynamic, more lively where you can browse, inspect and adjust nearly anything. And yes - you can even shoot yourself in the foot. > And yes we know Pharo does not provide fancy widgets yet or latest text editing features - but this is a tribute to community resources. > > From my experience: if one free's his mind and gives up traditional programming habits learned in mainstream languages he will enjoy the Pharo journey > much more. > > Bye > T. > >

Jan. 26, 2019

Re: [Pharo-users] Updated README for PasswordCrypt

by Sven Van Caekenberghe

Good, this is important. > On 26 Jan 2019, at 03:22, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > Hi all, > > I've updated the README for PasswordCrypt as part of my objective to > write proper READMEs for my Github repos in 1Q2019. > > https://github.com/PierceNg/PasswordCrypt > > Pierce >

Jan. 26, 2019

How to find out the version of a loaded package

by Sanjay Minni

How can I find out the version of any package loaded in the image (generically / conventionally), e.g. seaside, grease, voyage ... versions loaded in my image e.g. I am getting a conflict and want to know the version of grease already loaded <http://forum.world.st/file/t368721/version.jpg> ----- cheers, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 26, 2019

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

by Imran Rafique

Imran said: > No matter how you setup your smalltalk, at some point, you have to > talk to your system. Tell it to subclass Object because I want to add > a new class. Or add a new method to an existing class. Or just execute > this code right now, as is (Workspace/Playground). Etc, etc. Richard said: > The "system" isn't an object. It is a collaborative network of objects. You > don't tell the /system/ to subclass Object, you tell /Object/ to define the > subclass. Huh? Thats not what I said (I realise this is getting close to pedantic bikeshedding at this stage, but anyway ...): 1. System = the entire programming runtime 2. Tell it = send some text to that system, to consider it for execution 3. The "system" receives the text (somehow), parses it, and realises its a message send to Object. 4. It sends the message to Object, and Object figures out what to do (create a new class) I wasn't trying to imply anything different. The important thing I was getting at was "tell it". Thats where the whole breakdown comes in this internal vs external editing debate. And thats why I highlighted it. That "tell it" part is just the transmission, by any means possible, of dumb text to ... the system. Too often that gets intertwined with "live objects all the way", when in reality, I don't think it has anything to do with that aspect. At this point, you're just flinging ascii/unicode bytes around. Its only once the "system" gets those bytes, and parses it as "oh, you want to send this message, with these arguments, to that object? Ok, gotcha!" The advantage of initially creating that "dumb text" from tools running inside the image is that there should be a near-zero usabilty delay in delivering this "dumb text" to the system. No saving to disk. No loading from disk. Etc. But as long as you realise that, at this stage, you **are** just dealing with dumb text, then its equally plausible to create methods of creating and delivering that dumb text, from outside the image, to the system (inside the image). Without having to save to disk. Reload from disk. Etc. In other words - meet the same usability requirements. That "dumb text" only has anything to do with objects, liveness etc **once** the system gets it and parses it. Everything I was talking about is **before** that stage. Ok, so all of the above is pedantantry-gone-wild. But I think the following gets to the crux of it. Imran said: > So, in a real sense, does it matter where you enter that dumb, simple, > plain text? Richard said: > Yes, it does matter. When every keystroke changes the meaning of that "dumb, > simple, plain text", yes, it matters. > > There are Smalltalk text editors that insert annotations into the text being > presented to communicate information to you, You're bringing up advanced code completion as a difference. Well, err, no. You just need a constantly available backchannel of communication with the system. To send a potentially incomplete chunk of text and ask it "hey, what do you think he meant to say here?". Take that, and present it to the user. Upon every keystroke (if you like, that would drive me batty but to each his own). Lisp runtimes do this kind of thing all the time. Smalltalk can do this too. Why can't it? Recall the example I gave originally. It wasn't a braindead: Write in this editor. Save it. Go to the image. Load it. Rinse. Repeat. It was more: Write in this editor. Save it. It gets sent automatically to the system. System does something. Thats not confined to a single pseudo-file (with fuse or other pseudo-filelike systems, the file metaphor is just an abstraction over disk-less, instant communication between different processes). You can have multiple pseudo-files giving and sending msgs about various aspects. Including "hey, based on what you're typing, I think this is the full name". Or more complex reporting (variables, that method you just referenced has the following arguments, etc) None of this, absolutely NONE of this, requires having the text editor be INSIDE the system to start with. Of course, it **does** require an editor with more smarts than notepad. But: - acme (my preference, so easy to integrate with out-of-process tools) - emacs (but it likes pulling as much as possible inside its own process) - even neovim, with is asynchronous communication facilities (but still somewhat clunky, compared to the other two) They're all capable. Whats needed is the tooling to facilitate the ongoing communications to and from the smalltalk system. Like Craig Latta's webdav interface, as one example. Why bother? Well, it depends on how you look at it, I suppose. Is it easier to provide the background interface, and let others connect it to a multitude of programmable editors who are capable on ongoing asynchronous comms while editing? All I'm saying is that its a valid approach, which doesn't (IMO, of course) contravenes the "live environment" paradigm. > The people at feenk.com have shown an entirely new level of liveliness that > I find simply fascinating Agreed. -- Regards, Imran Sher Rafique On Fri, 25 Jan 2019 at 13:08, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > isr wrote > > I'm a long-time lurker on this list, and still more of an > > intermediate-squeaker (is that a word?) rather than pharo (although I > > have used this off and on since pharo-5), so I feel like a bit of an > > imposter jumping into this thread (long-time lisper). > > Like you, I am primarily a lurker in the Pharo lists. Some of your comments > below I agree with and some I don't. I hope can explain clearly enough why I > don't. I've been fortunate enough to work in Smalltalk exclusively since > late 1991. Each year that goes by sees me gain a new and deeper > understanding. Things I thought I new well turn out to have much more to > them than I previously thought, even after multiple "rinse and repeat" > cycles. > > > > That said, and without wishing to ruffle any feathers nor cause any > > rancour (if I do, I apologise), may I humbly disagree with some of the > > opinions mentioned by some certainly more accomplished Smalltalkers > > than me. > > > > Sven said: > >> Everybody is of course totally free to do whatever they want, but really, > >> why the hell would you want to do that ? > >> You lose so much by doing that, I do not even know where to start. > >> A big part of what makes Pharo (or any Smalltalk) special is the IDE > >> written in itself. > > > > Esteban said: > >> Honestly, Pharo without the environment (and the âlive objectsâ approach) > >> is just another dynamic language without much interest. > > > > There's a distinction between "how you enter source code" and "the > > full live object environment" paradigm. > > > > No matter how you setup your smalltalk, at some point, you have to > > talk to your system. Tell it to subclass Object because I want to add > > a new class. Or add a new method to an existing class. Or just execute > > this code right now, as is (Workspace/Playground). Etc, etc. > > The "system" isn't an object. It is a collaborative network of objects. You > don't tell the /system/ to subclass Object, you tell /Object/ to define the > subclass. > > To help provide a more complete context, let's go back to the beginning to > what Goldberg and Robson said in their preface to /Smalltalk-80 The Language > and Its Implementation/. > "Smalltalk is designed so that every component in the system that is > accessible to the user can be presented in a meaningful way for observation > and manipulation." > > As developers, we are users and subject to the same goals and ambitions. > Observation for us is navigating the code to understand while manipulation > for us is producing new code (or changed code). But, keep in mind that the > word manipulation means a lot more than just writing. > > > > > There are numerous text editor widgets sprinkled throughout > > squeak/cuis/pharo's set of "tools" which enable you to do exactly that > > - talk to the system. > > > > These various editor widgets distinguish themselves slightly by > > binding Self to something convenient (in the browser, for example), > > but other than that - they're just text widgets. > > > > The magic only happens once you take the text, and tell the system to > > **do something with it**. Save, Do-it, print-it, etc. > > > > Up to that point, its just text. Dumb, simple, plain text. > > That's only true because you have chosen it to be. And that is the crux of > this whole discussion. Dead bits are useless. Smalltalk is about live > objects. (As I said, it took me a long time to really, deeply understand > that. And I still see someone come along and prove me wrong. Wrong in the > sense that I didn't understand it nearly as well as I thought. Someone shows > the world an idea and my understanding takes an octave jump.) > > > > > So, in a real sense, does it matter where you enter that dumb, simple, > > plain text? > > Yes, it does matter. When every keystroke changes the meaning of that "dumb, > simple, plain text", yes, it matters. > > There are Smalltalk text editors that insert annotations into the text being > presented to communicate information to you, from as simple as indicating a > declared variable is unused or an expression references an undefined > variable, to more complex concepts. > > There are Smalltalk editors that know what potential receivers implement > selectors and variables (including globally accessible objects) matching > what you have typed so far and can offer you suggestions, including spelling > corrections, as you type. > > > > > As long as there is an immediate, simple, failsafe way to sending that > > text to the system to "do something with me", then you still have the > > same live environment. Surely? > > How can it be? Live, yes, for some definition of live. But, lively? Not so. > > (The people at feenk.com have shown an entirely new level of liveliness that > I find simply fascinating. Each new thing rings with an echo of "What will > they think of next?" coupled with "I can't wait to see what they think of > next!".) > > > > > At that point, it doesn't matter (from the point of view of having a > > "live system") whether the dumb, simple, plain text was initially > > entered, from keyboard to screen, via the smalltalk process or another > > external process. > > > > One can certainly argue that simple fileouts, editing, and filingin is > > too clunky a process. But, for example, having a fuse filesystem > > exporting the live contents of the class hierarchy: > > > > - every time you read "/Class-as-Dir/Method-as-file", the current > > source is queried from the live smalltalk system > > > > - every time you write to that file the smalltalk system is updated > > > > Surely this would keep much of the same "liveness-in-spirit"? With the > > added advantages of: > > > > - spreading a little of the cpu burden around the various cores > > (although this isn't really a cpu-intensive task anyway, but this > > might apply more if we had out-of-image graphical inspectors which > > also communicated via fuse) > > > > - taking advantage of the **vastly** more advanced text editing > > widgets available outside of pharo > > > > Certainly, this is what Craig Latta webdav system is trying to get at. > > I think its an interesting area to explore, and does not in any way > > distract from "liveness" or "smalltalk'iness". > > > > Ok, rant over :) > > > > > > -- > > Regards, > > Imran Sher Rafique > > > > On Thu, 24 Jan 2019 at 05:54, Sven Van Caekenberghe < > > > sven@ > > > > wrote: > >> > >> > >> > >> > On 24 Jan 2019, at 12:10, Dimitris Chloupis < > > > kilon.alios@ > > > > wrote: > >> > > >> > Often we have users of emacs and vim that request a way to use their > >> favorite shortcuts or features. Some even ask "Would not be nice if I > >> could use my favorite code editor with Pharo ?" > >> > > >> > Actually not only you can do it, its also very easy. So the following > >> video tutorial explains in the first 3 minutes how to do this and then > >> spends another 10 min talking about how this could be automated to be > >> completely automatic and instantaneous. > >> > > >> > https://youtu.be/3YfRhDafIxs > >> > >> Everybody is of course totally free to do whatever they want, but really, > >> why the hell would you want to do that ? > >> > >> You lose so much by doing that, I do not even know where to start. > >> > >> A big part of what makes Pharo (or any Smalltalk) special is the IDE > >> written in itself. > >> > >> Editing a .st file has always been possible, it is masochism. > >> > >> There is for example https://github.com/dmatveev/shampoo-emacs which > >> already makes a bit more sense (but even then). > >> > >> Really, why do you think all these big IDE environments exist in the > >> first place ? > >> > >> Sven > >> > >> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 26, 2019

Updated README for PasswordCrypt

by Pierce Ng

Hi all, I've updated the README for PasswordCrypt as part of my objective to write proper READMEs for my Github repos in 1Q2019. https://github.com/PierceNg/PasswordCrypt Pierce

Jan. 26, 2019

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

by Richard Sargent

isr wrote > I'm a long-time lurker on this list, and still more of an > intermediate-squeaker (is that a word?) rather than pharo (although I > have used this off and on since pharo-5), so I feel like a bit of an > imposter jumping into this thread (long-time lisper). Like you, I am primarily a lurker in the Pharo lists. Some of your comments below I agree with and some I don't. I hope can explain clearly enough why I don't. I've been fortunate enough to work in Smalltalk exclusively since late 1991. Each year that goes by sees me gain a new and deeper understanding. Things I thought I new well turn out to have much more to them than I previously thought, even after multiple "rinse and repeat" cycles. > That said, and without wishing to ruffle any feathers nor cause any > rancour (if I do, I apologise), may I humbly disagree with some of the > opinions mentioned by some certainly more accomplished Smalltalkers > than me. > > Sven said: >> Everybody is of course totally free to do whatever they want, but really, >> why the hell would you want to do that ? >> You lose so much by doing that, I do not even know where to start. >> A big part of what makes Pharo (or any Smalltalk) special is the IDE >> written in itself. > > Esteban said: >> Honestly, Pharo without the environment (and the âlive objectsâ approach) >> is just another dynamic language without much interest. > > There's a distinction between "how you enter source code" and "the > full live object environment" paradigm. > > No matter how you setup your smalltalk, at some point, you have to > talk to your system. Tell it to subclass Object because I want to add > a new class. Or add a new method to an existing class. Or just execute > this code right now, as is (Workspace/Playground). Etc, etc. The "system" isn't an object. It is a collaborative network of objects. You don't tell the /system/ to subclass Object, you tell /Object/ to define the subclass. To help provide a more complete context, let's go back to the beginning to what Goldberg and Robson said in their preface to /Smalltalk-80 The Language and Its Implementation/. "Smalltalk is designed so that every component in the system that is accessible to the user can be presented in a meaningful way for observation and manipulation." As developers, we are users and subject to the same goals and ambitions. Observation for us is navigating the code to understand while manipulation for us is producing new code (or changed code). But, keep in mind that the word manipulation means a lot more than just writing. > There are numerous text editor widgets sprinkled throughout > squeak/cuis/pharo's set of "tools" which enable you to do exactly that > - talk to the system. > > These various editor widgets distinguish themselves slightly by > binding Self to something convenient (in the browser, for example), > but other than that - they're just text widgets. > > The magic only happens once you take the text, and tell the system to > **do something with it**. Save, Do-it, print-it, etc. > > Up to that point, its just text. Dumb, simple, plain text. That's only true because you have chosen it to be. And that is the crux of this whole discussion. Dead bits are useless. Smalltalk is about live objects. (As I said, it took me a long time to really, deeply understand that. And I still see someone come along and prove me wrong. Wrong in the sense that I didn't understand it nearly as well as I thought. Someone shows the world an idea and my understanding takes an octave jump.) > So, in a real sense, does it matter where you enter that dumb, simple, > plain text? Yes, it does matter. When every keystroke changes the meaning of that "dumb, simple, plain text", yes, it matters. There are Smalltalk text editors that insert annotations into the text being presented to communicate information to you, from as simple as indicating a declared variable is unused or an expression references an undefined variable, to more complex concepts. There are Smalltalk editors that know what potential receivers implement selectors and variables (including globally accessible objects) matching what you have typed so far and can offer you suggestions, including spelling corrections, as you type. > As long as there is an immediate, simple, failsafe way to sending that > text to the system to "do something with me", then you still have the > same live environment. Surely? How can it be? Live, yes, for some definition of live. But, lively? Not so. (The people at feenk.com have shown an entirely new level of liveliness that I find simply fascinating. Each new thing rings with an echo of "What will they think of next?" coupled with "I can't wait to see what they think of next!".) > At that point, it doesn't matter (from the point of view of having a > "live system") whether the dumb, simple, plain text was initially > entered, from keyboard to screen, via the smalltalk process or another > external process. > > One can certainly argue that simple fileouts, editing, and filingin is > too clunky a process. But, for example, having a fuse filesystem > exporting the live contents of the class hierarchy: > > - every time you read "/Class-as-Dir/Method-as-file", the current > source is queried from the live smalltalk system > > - every time you write to that file the smalltalk system is updated > > Surely this would keep much of the same "liveness-in-spirit"? With the > added advantages of: > > - spreading a little of the cpu burden around the various cores > (although this isn't really a cpu-intensive task anyway, but this > might apply more if we had out-of-image graphical inspectors which > also communicated via fuse) > > - taking advantage of the **vastly** more advanced text editing > widgets available outside of pharo > > Certainly, this is what Craig Latta webdav system is trying to get at. > I think its an interesting area to explore, and does not in any way > distract from "liveness" or "smalltalk'iness". > > Ok, rant over :) > > > -- > Regards, > Imran Sher Rafique > > On Thu, 24 Jan 2019 at 05:54, Sven Van Caekenberghe < > sven@ > > wrote: >> >> >> >> > On 24 Jan 2019, at 12:10, Dimitris Chloupis < > kilon.alios@ > > wrote: >> > >> > Often we have users of emacs and vim that request a way to use their >> favorite shortcuts or features. Some even ask "Would not be nice if I >> could use my favorite code editor with Pharo ?" >> > >> > Actually not only you can do it, its also very easy. So the following >> video tutorial explains in the first 3 minutes how to do this and then >> spends another 10 min talking about how this could be automated to be >> completely automatic and instantaneous. >> > >> > https://youtu.be/3YfRhDafIxs >> >> Everybody is of course totally free to do whatever they want, but really, >> why the hell would you want to do that ? >> >> You lose so much by doing that, I do not even know where to start. >> >> A big part of what makes Pharo (or any Smalltalk) special is the IDE >> written in itself. >> >> Editing a .st file has always been possible, it is masochism. >> >> There is for example https://github.com/dmatveev/shampoo-emacs which >> already makes a bit more sense (but even then). >> >> Really, why do you think all these big IDE environments exist in the >> first place ? >> >> Sven >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 25, 2019