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

R: How to embed VSE application into Pharo

by Lorenzo Schiavina

Hi Davide, nice hearing you! Thank you for your fast answer; as a matter of fact I do not want to transform my VSE code into Pharo code. What I was thinking of was the possibility (from inside Pharo) to call and start VSE, in such a way that VSE is a different task. I have already verified that from VSE I can call Pharo and this is a quite satisfactory solution but I would like to implement something more interactive, starting from Pharo (that should be my first choice programming) instead of VSE. By the way: I have implemented a fuzzy environment for creating expert systems named FuzzyWorld (you can see at my site www.edor.it, unfortunately in Italian) and I have got some interesting, real results both in Italy and abroad. I would like to port it to Pharo; can you address me to somebody who could be interested to applications of this type? Many thanks!! Ciao Lorenzo Da: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] Per conto di Davide Grandi Inviato: giovedÃ¬ 24 gennaio 2019 18:17 A: pharo-users(a)lists.pharo.org Oggetto: Re: [Pharo-users] How to embed VSE application into Pharo Hi Lorenzo, Nice to meet you again, after some tens of years. AS you may remember I've ported, ... 20 years ago ..., a Digitalk VOS/2 big app to Visualage/Windows. Using an Apple Smalltalk as intermediate host. As you can figure, it was mainly a syntax work, i.e. : - working out an Apple Smalltalk loading-only version of VOS2 app - working out an Apple Smalltalk loading-only version of a Visualage app visual components (cw* only) structure - writing all the "stub" classes needed on both sides (VOS2 and Visualage) to load the core components without syntax or hierarchical error - defining, in both sides, a set of class dictionary to let the other side globals at least declare ... - writing 2 set of "switching" methods : one that calls VOS/2 UI building methods, one for Visualage UI building methods (describing it now, it sounds as a daunting task : but I were a young-to-senior programmer, with lot of nights to spare ... to escape from OS/2 ...). It worked with a reasonable effort. Maybe I could avoid the intermediate Apple Smalltalk ... ... but I were very fast at programming with Apple Smalltalk. Back to your migration path : - take _your_ equivalent structure of Pharo application visual architecture (aka the View) - write the Pharo equivalent of VSE Control classes and UI build methods (paired, perhaps. With coinciding names except for some prefix). - fire your simplest app and adapt your classes and methods unless it works - apply the changes to all your View and Control classes until they all work (as an afterthought, with a "modern" eye : is an horror story. Nobody will follow you om my path. But 20 years ago it worked with a 700+ classes app ... still sold today. If there's another path I'm very very interested ...) Best regards, Davide Grandi On 24/01/2019 16:34, Lorenzo Schiavina wrote: Hi, I am a very old Smalltalk user; I have developed TONS of application with DigitalkÂs VSE; some of them are used by more hundreds clients. Can you tell me if there is any possibility to embed my VSE applications into Pharo without rewriting them? My goal would be to use Pharo for my new applications without loose the old ones and to interact with old ones in Pharo. Many thanks for your answer Lorenzo -- Ing. Davide Grandi email : davide.grandi(a)mclink.it

Jan. 25, 2019

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

by Jose San Leandro

There's one thing in our brains called "amigdala". It's the reason we can be efficient. Using the mouse bypasses the amigdala completely. Everything is conscious. Well, unless if you're Rapha playing Quake Champions. I'm not sure if your argument about Visual Coding implies using the mouse. I think maybe what you refer as Visual Coding is an imperfect implementation of Bret Victor's DynamicLand. I think he might be right. Anyway, while coding we do two tasks: thinking, and making changes in the image so that it behaves the way we want. While thinking, and designing, the amigdala is not used. I still think using the mouse to explore is distracting. That's why I use Tiled desktop managers: they save me from the distraction. I have absolutely no interest in organizing the windows on the desktop. The windows are the mean, not the end. Regarding the argument that Visual Coding is winning, that doesn't mean it's good news. Have you read "Bad ass users"? I fully support that approach. Visual coding seems to be great softening the learning curve. But I doubt it makes people better as coders. In my case, I feel I'm improving whenever I understand what it's happening. Many times you get results that seem to contradict your expectations. Whenever that happens, I debug until I find out what's actually happening. If I use Visual Coding, at some point the information must be unhidden. I don't have anything against Visual Coding. But I've benefited a lot from learning touch typing, learning Dvorak, using a letter-less keyboard, and learning the basics of Emacs. A lot. If the promise of Visual Coding is "you don't need any of that", I think it's a false promise. You can move nodes to save space for some time, until you learn a keybinding (or wish it existed) and do it automatically. That's what I want to have in Pharo. "Bad ass users" is the antidote against the UX oversimplification we live by, that confines as first-time users. El vie., 25 ene. 2019 a las 8:12, Dimitris Chloupis (<kilon.alios(a)gmail.com>) escribiÃ³: > I think you got this the wrong way > > Sure emacs and vim are very popular when compared to Pharo. > When compared to IDEs oh boy , that's another story. > There is a reason why their hardcore user are so desperate to call them > IDEs and is not because they like IDEs, they dont. > They hate IDEs. > > Text based coding, has lost .... no my bad , let me correct this, text > coding never stood chance. Smalltalk was like a nuclear bomb that when it > landed it left nothing in its path, > There is no doubt that nowdays IDEs dominating to a vast degree. Obviously > big guns on top are Visual Studio (not Code) and Xcode by far for obvious > reasons. > > Even in the case of my favorite IDE , Delphii its really amazing that even > though its company has long disappeared, the all mighty Borland which one > was the equivalent of Sun/Oracle. > With only diffirent that obviously they were innovator. Even though > outside Delphi absolutely none talks about Delphi. > Delphi is surprisingly strong. Actually Delphis popularity is an > undeniable proof how massively successful Smalltalk has been in its > visual paradigm. Its company went to bankruptcy and the language was > bought by a pretty much , even today, unknown company. The impact was that > it went from 4th most popular to 12th most popular. > Delphi even today is a formidable force for the Windows platform battling > Go and freaking Swift who has the support of the most powerful company on > the planet, Apple.There is no doubt in my mind > that if Delphi was not such a massively loved IDE , being closed source > which is a taboo for todays coding standards especially for a programming > language, it would have been long dead. > > And lets not begin with scripting language which are basically dead. > Python for example may be the 3rd most popular programming language but > scripting wise has pretty much died. > When it comes to the customisation of super advanced programs , the users > has spoken loud and clear. They want visual coding and NOT text coding. > 3 extremely complex fields , 3d graphics , Music and game development are > dominated by Visual Coding languages. In Blender we offer both Python and > Visual coding, > guess what the users pick. > > Essentially one type of Visual Coding , node based visual coding. > > Also the time where visual coding was just for the users and not for the > pros is long gone too after the massive success of Unreal's Blueprints. > Which basically can do everything C++ can. > Unreal's Blueprints is not even the first example of a visual language > that will give a text language a run for its money. Softimage (3d app) ICE > has been doing high performance coding decades ago. > In music software we even have the insanity of visual language going down > to low level, an I am not talking C++ or C , I mean real low level, old > school Assembly code. Again decades ago. > > The users have spoken loud and clear and they have clearly stated they > have no interest into investing the vast amount of wasted time that text > coding requires. > > Even to learn how to code is dominated by Scratch. Just think about it, a > language for kids dominates programming education. > If you told that to a coder or even a user 20 years ago, he would have > called you crazy and for a good reason. > > Text coding is only getting less and less popular by the year. I have no > doubt at some point will completely disappear as did Assembly. > > So the biggest mistake of Smalltalk was not that it supported visual coding > > it was that it did not go visual coding all the way. > > It will have saved us the trouble of not being able to convince people to > learn coding. > Because people do not want to learn coding, > And frankly.... I do not blame them. > > Visual coding is the only future of coding and Emac and Vim are relics of > a past that has long gone. > A despair attempt at nostalgia. > On Fri, Jan 25, 2019 at 1:09 AM HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe (<sven(a)stfx.eu>) >> escribiÃ³: >> >>> >>> >>> > On 24 Jan 2019, at 17:04, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >>> > >>> > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote: >>> >> Everybody is of course totally free to do whatever they want, but >>> >> really, why the hell would you want to do that ? >>> > Because text has many uses other than just feeding into a compiler for >>> translation to machine code? People who come from Unix/Linux world are used >>> to using a rich collection of tools that deal with text in various ways. >>> >>> I am myself a server/linux guy, an emacs user, I know what is all >>> possible and what the unix philosophy is. >>> >>> I also know how to integrate Pharo into that world, and this is super >>> important. >>> >>> >> You lose so much by doing that, I do not even know where to start. >>> > >>> > Live coding (i.e. coding in the presence of instances) is undoubtedly >>> more powerful than edit-compile-run cycle. Text is used to direct IDE to >>> edit live objects. But text has many more uses than just issuing commands. >>> If beginners start using vim just to edit code due to established habits, >>> they will soon realize the ease of live coding and remain in IDE. This is a >>> self-correcting error. >>> >>> Well, I don't think so. >>> >>> The users that you are going to attract in this way (the ones that don't >>> want to leave their own IDE/editor), will look at textual Pharo and find it >>> very strange and ill suited to textual editing (and they are absolutely >>> right), they will not discover the power, will not learn (from this >>> experience alone) what object design/programming/power is, and will ask for >>> more (e.g. give me C style compiler errors, better/easier structure of the >>> file, fixed the !! escape issue, etc, ...). >>> >>> >> We should admit for once text-based programming already won for this age. >> Want a nice proof? Check Mr. Robot series. That's how a new generation of >> devs is getting it. It doesn't matter if we have 30 years of experience >> supporting exploratory UI is the best way, not even if we are fully >> convinced of it. Probably it's time to invert the burden of proof, and let >> people decide how they want to get into Pharo. If they want an >> Objective-Smalltalk mode, let people live and die with it. >> >> And I love the Class Browser, but we cannot assume every coder has >> developed an exploratory mindset. Just ready to jump into a world of new >> tools. "Forcing" on developing it through tools isn't actually nice >> attitude neither. And there are really good devs out there, it may just >> happen that they don't want a shock therapy as someone told above. Or they >> don't have the time+energy for now. Let people themselves discover the >> right tools for them, or stay where they want to. >> >> So IMHO until someone really sits down and figure out a cool Pharo REPL, >> we will get the same print me "Hello World" trolls in forums. >> >> Cheers, >> >> HernÃ¡n >> >> >>> >> Editing a .st file has always been possible, it is masochism.Vim is >>> much more than just a typewriter. It can leverage a whole set of >>> > text-based tools. One could use it to auto generate methods, clean >>> them up and then file into Pharo. >>> > >>> > Regards .. Subbu >>> > >>> >>> >>>

Jan. 25, 2019

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

by eftomi

Dear all, I'm a Pharo novice, in the middle of a self paced Pharo MOOC, with years of experence going from Turbo C on DOS over Visual Studio and Eclipse to Visual Studio Code in last years. Besides, I'm a professor and a researcher of IT adoption, so here's my two cents contributing to this very interesting debate. Developers are users, and (potential) users decide upon four things: - expected performance of a tool (what a tool can do and what it represents) - user effort expectancy while learning (i.e. learning curve) and using the tool - social influence (i.e. what other developers are doing, saying and collaborating with) - facilitating conditions (support, i.e. strong & helping community, tutorials, user manuals) We can discuss and rant about which language or a tool is better of worse in a caffee (like complaining about the weather or our bosses), however for a progress and good decisions it is necessary that we forget about our personal feelings and preferences. There is no doubt, Pharo delivers many new, stunningly innovative and revolutionary approaches, and all the efforts of its developers are worthwhile and greatly appreciated. When there is a question about editing the code, we can look for the philosophies of other editors/IDEs. For instance, authors of VSCode are saying <https://code.visualstudio.com/docs/editor/whyvscode> "First and foremost, it is an editor that gets out of your way. The delightfully frictionless edit-build-debug cycle means less time fiddling with your environment, and more time executing on your ideas." How far away from this idea is Pharo, if we compare both worlds? Pharo is an OS, IDE, editor and a language - but can we make it to get out of our way in the sense of developers' effort expectancy? Maybe we don't need anything special to go into this direction. Just a couple more of keystrokes to directly support edit-build-debug and TDD development cycles and some work on the "console like feeling" when interacting in Pharo. The dark theme is great, btw :-) I think that a wish to directly edit the .st files comes from the fact that other editors and IDEs are "linear" by design - we edit flat files with them, and these files (modules) are longer than a typical method in Pharo. A developer focuses on the method/function at hand, however she just has to scroll up and down to reach other methods/functions within a module, while in Pharo you typically grab your mouse and browse with the class browser. Can a couple of keystrokes be a solution? So, my proposal is that we forget about our personal feelings and preferences, and think outside the box - which is a Pharo domain, after all! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 25, 2019

macOS VM builds with AddressSanitizer/LeakSanitizer

by Manuel Leuenberger

Hi, Anybody has experience building the VM (pharo.cog.spur) on macOS with custom compiler and flags? I am observing a memory leak on macOS Sierra/Pharo 7/GToolkit. I cannot precisely locate the issue, e.g. I cannot reliably reproduce the problem. So I tried to use AddressSanitizer/LeakSanitizer with custom debug builds of the VM and libMoz2D (used by GToolkit). As building on Linux is easier than on macOS, I got myself some help from a colleague and we managed to build those two artifacts on Linux by sprinkling "-g3 -O0 -fsanitize=leak -fsanitize-memory-track-origins" into the CFLAGS wherever they appear or are picked up. This works fine on Debian 9 with "CC=clang-6.0 CXX=clang++-6.0 ./mvm -d" and some on-the-fly patches for other breaking things. Unfortunately, I cannot reproduce the problem on Linux, so it seems to be platform specific. Even more so, I seem to be the only one observing the issue. Other GToolkit users do not report this issue. As these kind of issues are freaking me out, I cannot let go and need to learn what causes them. So, here I am, trying to build the VM on macOS Sierra and miserably failing to include the sanitizer tags with Clang and giving me those tasty leak reports on VM shutdown. The leak is not observable in the image memory, i.e. the image size reported by the VM is not growing, I am suspecting FFI, possibly in Moz2D, to leak. The FFI registry in the VM also does not report many or large surviving objects, so I would assume the problem to be either on the plugin or VM side. My two concrete questions are: 1. Is it even feasible to detect leaks with this approach? E.g., how does the VM behave on shutdown? Will the leaks show up in the report or will they not be covered, as the VM actually frees everything before shutting down? 2. How do I swap compiler and inject flags on macOS builds? On Linux it was fairly easily done by replacing some variables. But on macOS, Xcode seems to like to mess with me. I got myself Clang-6.0 on macOS from MacPorts, the same as version as I took on Linux. I can build the VM with this, but it there is no leak report on VM shutdown. Anybody has an idea how to debug the build? Bonus question: Can the VM provide an inspectable view of all the allocated memory to the image? That would be perfect. I think Luke Gorrie does some magic like this in his Studio for core dumps etc. Cheers, Manuel

Jan. 25, 2019

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

by Dimitris Chloupis

I think you got this the wrong way Sure emacs and vim are very popular when compared to Pharo. When compared to IDEs oh boy , that's another story. There is a reason why their hardcore user are so desperate to call them IDEs and is not because they like IDEs, they dont. They hate IDEs. Text based coding, has lost .... no my bad , let me correct this, text coding never stood chance. Smalltalk was like a nuclear bomb that when it landed it left nothing in its path, There is no doubt that nowdays IDEs dominating to a vast degree. Obviously big guns on top are Visual Studio (not Code) and Xcode by far for obvious reasons. Even in the case of my favorite IDE , Delphii its really amazing that even though its company has long disappeared, the all mighty Borland which one was the equivalent of Sun/Oracle. With only diffirent that obviously they were innovator. Even though outside Delphi absolutely none talks about Delphi. Delphi is surprisingly strong. Actually Delphis popularity is an undeniable proof how massively successful Smalltalk has been in its visual paradigm. Its company went to bankruptcy and the language was bought by a pretty much , even today, unknown company. The impact was that it went from 4th most popular to 12th most popular. Delphi even today is a formidable force for the Windows platform battling Go and freaking Swift who has the support of the most powerful company on the planet, Apple.There is no doubt in my mind that if Delphi was not such a massively loved IDE , being closed source which is a taboo for todays coding standards especially for a programming language, it would have been long dead. And lets not begin with scripting language which are basically dead. Python for example may be the 3rd most popular programming language but scripting wise has pretty much died. When it comes to the customisation of super advanced programs , the users has spoken loud and clear. They want visual coding and NOT text coding. 3 extremely complex fields , 3d graphics , Music and game development are dominated by Visual Coding languages. In Blender we offer both Python and Visual coding, guess what the users pick. Essentially one type of Visual Coding , node based visual coding. Also the time where visual coding was just for the users and not for the pros is long gone too after the massive success of Unreal's Blueprints. Which basically can do everything C++ can. Unreal's Blueprints is not even the first example of a visual language that will give a text language a run for its money. Softimage (3d app) ICE has been doing high performance coding decades ago. In music software we even have the insanity of visual language going down to low level, an I am not talking C++ or C , I mean real low level, old school Assembly code. Again decades ago. The users have spoken loud and clear and they have clearly stated they have no interest into investing the vast amount of wasted time that text coding requires. Even to learn how to code is dominated by Scratch. Just think about it, a language for kids dominates programming education. If you told that to a coder or even a user 20 years ago, he would have called you crazy and for a good reason. Text coding is only getting less and less popular by the year. I have no doubt at some point will completely disappear as did Assembly. So the biggest mistake of Smalltalk was not that it supported visual coding it was that it did not go visual coding all the way. It will have saved us the trouble of not being able to convince people to learn coding. Because people do not want to learn coding, And frankly.... I do not blame them. Visual coding is the only future of coding and Emac and Vim are relics of a past that has long gone. A despair attempt at nostalgia. On Fri, Jan 25, 2019 at 1:09 AM HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe (<sven(a)stfx.eu>) > escribiÃ³: > >> >> >> > On 24 Jan 2019, at 17:04, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> > >> > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote: >> >> Everybody is of course totally free to do whatever they want, but >> >> really, why the hell would you want to do that ? >> > Because text has many uses other than just feeding into a compiler for >> translation to machine code? People who come from Unix/Linux world are used >> to using a rich collection of tools that deal with text in various ways. >> >> I am myself a server/linux guy, an emacs user, I know what is all >> possible and what the unix philosophy is. >> >> I also know how to integrate Pharo into that world, and this is super >> important. >> >> >> You lose so much by doing that, I do not even know where to start. >> > >> > Live coding (i.e. coding in the presence of instances) is undoubtedly >> more powerful than edit-compile-run cycle. Text is used to direct IDE to >> edit live objects. But text has many more uses than just issuing commands. >> If beginners start using vim just to edit code due to established habits, >> they will soon realize the ease of live coding and remain in IDE. This is a >> self-correcting error. >> >> Well, I don't think so. >> >> The users that you are going to attract in this way (the ones that don't >> want to leave their own IDE/editor), will look at textual Pharo and find it >> very strange and ill suited to textual editing (and they are absolutely >> right), they will not discover the power, will not learn (from this >> experience alone) what object design/programming/power is, and will ask for >> more (e.g. give me C style compiler errors, better/easier structure of the >> file, fixed the !! escape issue, etc, ...). >> >> > We should admit for once text-based programming already won for this age. > Want a nice proof? Check Mr. Robot series. That's how a new generation of > devs is getting it. It doesn't matter if we have 30 years of experience > supporting exploratory UI is the best way, not even if we are fully > convinced of it. Probably it's time to invert the burden of proof, and let > people decide how they want to get into Pharo. If they want an > Objective-Smalltalk mode, let people live and die with it. > > And I love the Class Browser, but we cannot assume every coder has > developed an exploratory mindset. Just ready to jump into a world of new > tools. "Forcing" on developing it through tools isn't actually nice > attitude neither. And there are really good devs out there, it may just > happen that they don't want a shock therapy as someone told above. Or they > don't have the time+energy for now. Let people themselves discover the > right tools for them, or stay where they want to. > > So IMHO until someone really sits down and figure out a cool Pharo REPL, > we will get the same print me "Hello World" trolls in forums. > > Cheers, > > HernÃ¡n > > >> >> Editing a .st file has always been possible, it is masochism.Vim is >> much more than just a typewriter. It can leverage a whole set of >> > text-based tools. One could use it to auto generate methods, clean them >> up and then file into Pharo. >> > >> > Regards .. Subbu >> > >> >> >>

Jan. 25, 2019

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

by Pierce Ng

On Thu, Jan 24, 2019 at 08:29:46PM +0530, K K Subbu wrote: > Nice clip - short and sweet. You may want to point people to about chunk > file format in the description to alert people who may break chunk syntax by > accident and get confused when fileIn breaks (been there, done that :-(). Maybe Esteban has already solved the chunk file problem by inventing the Tonel format. People can concat all their Tonel class files into one gigantic text file and knock themselves out with emacs/vim. Say a client-server setup: Headless Pharo runs a Shampoo server. Emacs runs the Shampoo client and talks to the Pharo instance to manipulate whatever Pharo stuff on the Emacs side as text. I'm not seriously suggesting the above by the way. That'll be like making Emacs into an ad-hoc bug-ridden slow implementation of the Smalltalk IDE, to borrow a phrase from a famous person. Pierce

Jan. 25, 2019

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

by Imran Rafique

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). 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. 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. So, in a real sense, does it matter where you enter that dumb, simple, plain text? 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? 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(a)stfx.eu> wrote: > > > > > On 24 Jan 2019, at 12:10, Dimitris Chloupis <kilon.alios(a)gmail.com> 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 > >

Jan. 25, 2019

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

by HernÃ¡n Morales Durand

El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > > > On 24 Jan 2019, at 17:04, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > > > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote: > >> Everybody is of course totally free to do whatever they want, but > >> really, why the hell would you want to do that ? > > Because text has many uses other than just feeding into a compiler for > translation to machine code? People who come from Unix/Linux world are used > to using a rich collection of tools that deal with text in various ways. > > I am myself a server/linux guy, an emacs user, I know what is all possible > and what the unix philosophy is. > > I also know how to integrate Pharo into that world, and this is super > important. > > >> You lose so much by doing that, I do not even know where to start. > > > > Live coding (i.e. coding in the presence of instances) is undoubtedly > more powerful than edit-compile-run cycle. Text is used to direct IDE to > edit live objects. But text has many more uses than just issuing commands. > If beginners start using vim just to edit code due to established habits, > they will soon realize the ease of live coding and remain in IDE. This is a > self-correcting error. > > Well, I don't think so. > > The users that you are going to attract in this way (the ones that don't > want to leave their own IDE/editor), will look at textual Pharo and find it > very strange and ill suited to textual editing (and they are absolutely > right), they will not discover the power, will not learn (from this > experience alone) what object design/programming/power is, and will ask for > more (e.g. give me C style compiler errors, better/easier structure of the > file, fixed the !! escape issue, etc, ...). > > We should admit for once text-based programming already won for this age. Want a nice proof? Check Mr. Robot series. That's how a new generation of devs is getting it. It doesn't matter if we have 30 years of experience supporting exploratory UI is the best way, not even if we are fully convinced of it. Probably it's time to invert the burden of proof, and let people decide how they want to get into Pharo. If they want an Objective-Smalltalk mode, let people live and die with it. And I love the Class Browser, but we cannot assume every coder has developed an exploratory mindset. Just ready to jump into a world of new tools. "Forcing" on developing it through tools isn't actually nice attitude neither. And there are really good devs out there, it may just happen that they don't want a shock therapy as someone told above. Or they don't have the time+energy for now. Let people themselves discover the right tools for them, or stay where they want to. So IMHO until someone really sits down and figure out a cool Pharo REPL, we will get the same print me "Hello World" trolls in forums. Cheers, HernÃ¡n > >> Editing a .st file has always been possible, it is masochism.Vim is > much more than just a typewriter. It can leverage a whole set of > > text-based tools. One could use it to auto generate methods, clean them > up and then file into Pharo. > > > > Regards .. Subbu > > > > >

Jan. 24, 2019

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

by Jose San Leandro

Thank you very much. Just to be clear, even if I'd love to be able to do such things, working in Pharo is far from being a pain. Those things are just "nice to have". Even if I don't find easy ways to do what I'd like to, I can always do it myself, my way. Furthermore, it'd be good for me to do so. That's why I think Pharo (and Smalltalk) is what Paul Graham describes as the Bulb paradox. El jue., 24 ene. 2019 a las 19:54, Dimitris Chloupis (<kilon.alios(a)gmail.com>) escribiÃ³: > yeah the System Browser has some shortcuts that you can find if you click > that down arrow in top right corner of the window > > About getting Window info, that is tricky, all is available through > Morphic but Morphic is kinda messy. So if you are willing to do the hard > work its definetly doable , you can create your own shortcuts etc. > > Finding the leftmost probably you will ask the World morph about all > windows , ask each window whether its opened and if yes where is located > (morph >>position) > I think the focus is in SystemWindow >> isActive , look also at > basicActivate for a better idea what activation means > > For groups there is isEmbeded , also Morph >> embededMorphs > > No idea about the Playground, it keeps timestamped session of whatever you > do so there is definetly something > > Yeah Pharo is not Emacs that's for sure. Mainly because we attract people > who are mouse driven, people who are keyboard driven tend to avoid IDEs. > Its doable , its just not available out of the box. > > I can feel your pain though, this has been an issue for me with Pharo, the > power is there, but its not easy to access. However to be fair Emacs has > been around a lot longer and has far larger community of contributors so > its no wonder it can do these things with ease. Emacs also has amazing > documentation. But sadly is no IDE and its shortcuts is pure insanity, but > then I am a mouse person myself. Ironically I was raised on CLIs and I > always hated them with passion :D > > On Thu, Jan 24, 2019 at 8:32 PM Jose San Leandro <jose.sanleandro(a)osoco.es> > wrote: > >> I don't want to hijack this thread, but it would be useful for me to have >> a cheatsheet to allow me to do the usual operations I do with the mouse, >> programatically. I've had some difficulties with simple things in the past. >> For example, to delete all Transcript or Playground windows, I use calls >> such as >> >> (World submorphs select: [ :w | ((w model printString beginsWith: 'a >>> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ]) >>> do: [ :w | w delete ]. >>> >> >> I'm missing ways to query World submorphs to know exactly my target >> instance. For example: >> - Which is the leftmost window? >> - Which window has the focus? >> - Which windows have "grouping" enabled? >> - Which Playground instance I used more recently? >> >> And operations such as: >> - Maximize morph. >> - Activate "class side" in Nautilus. >> - Select "accessing" protocol. >> - Select package X. >> - Select "Hierarchy". >> - Choose the next child when "hierarchy" is active. >> >>> - Resize the method panel. >>> >> >> Also, basic things like: >> - Move to the next word. >> - Highlight previous word. >> - Highlight current line. >> >> That would be very helpful for me. I'm not saying it's difficult to do, >> I'm just saying for me it'd be helpful. >> That's basically why I love Emacs, because I can do with the keyboard >> anything that can be done with the mouse, and more. >> >> Thanks! >> >> El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis (< >> kilon.alios(a)gmail.com>) escribiÃ³: >> >>> Playground is a REPL inside Pharo so I am not sure I understand what you >>> are asking. Everything in Pharo is just Classes and methods so you can do >>> whatever you want. If you are a bit more descriptive maybe I can help you >>> more. There is no such thing as a bad idea, just an idea that has not >>> mature enough :D >>> >>> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro < >>> jose.sanleandro(a)osoco.es> wrote: >>> >>>> I was aware of that. I was imaging a way to use the tools available in >>>> Pharo, but within a REPL session. >>>> Probably a bad idea anyway. I just think the mouse is useful when >>>> exploring, but it's ridiculously inefficient once you know exactly what you >>>> want to do. >>>> In my 4k monitor I often feel like if I was saying "no, I want to >>>> resize the window, not moving it, not changing the focus, thanks". I have >>>> to waste time being accurate enough with the mouse, because it's the >>>> expected way to communicate with live objects. Mouse, then keyboard. Not >>>> good. >>>> >>>> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (< >>>> kilon.alios(a)gmail.com>) escribiÃ³: >>>> >>>>> "I am sure there will always be skeptics. But my own experience was >>>>> different. For me, the most weird thing about Squeak (and now Pharo) >>>>> IDE >>>>> is its insistence in showing only one method at a time. A method is >>>>> too >>>>> small a chunk of code. It is easy to miss the forest for the trees. In >>>>> Dimitris video, you see lots more code in one glance in vim session. >>>>> So >>>>> there are pragmatic reasons why some coders fallback to using fileOuts >>>>> for browsing classes." >>>>> >>>>> I could not agree more , I find the column GUI weird and a waste of >>>>> space. This is why I have ended up relying a lot on GTSpotter (finder) >>>>> which help me browse classes a lot faster than the class browser. Kinda >>>>> ironic. >>>>> >>>>> I am using Pharo since 2011. I am still dont like Class Browser :D >>>>> >>>>> "In summary, if someone misses Emacs or Vim when working with Pharo, >>>>> it could be due to: >>>>> - being stuck in the file-based way to think of coding. >>>>> " >>>>> Its a common misconception that Pharo does not heavily rely on text >>>>> files, it actually does. Not only the source file makes it possible to view >>>>> the code even the oldest method of version control tha Pharo being a fork, >>>>> inherited from Squeak, the known mcz files they may look small binary files >>>>> like the Pharo image but they are merely zip files with source code text >>>>> files with the st extension. >>>>> >>>>> The image is merely the bytecode, the VMs machine code sort of, the >>>>> actually source works the same way as other languages. Like other languages >>>>> you dont need the source code to execute , only the bytecode. What makes >>>>> the image special is that its one file and its a memory dump which makes it >>>>> easy to store both live code and live state. Which is very helpful, >>>>> technically its mandatory for true live coding, but still Pharo has to rely >>>>> on source code files to make our lives easy. From there on is just a >>>>> question whether you break the source code files in several small ones, or >>>>> keep one large. >>>>> >>>>> "Besides that, is there an easy way to run an image in text-only mode, >>>>> with a REPL or a playground or something like that?" >>>>> >>>>> Yeap its possible and has been around for a very long time. Pharo also >>>>> makes it dead easy to expose any method as command line argument, so its >>>>> possible to code completely from the command line although definitely not >>>>> recommended. >>>>> >>>>> Deep Into Pharo book explains how. >>>>> >>>>> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu <kksubbu.ml(a)gmail.com> >>>>> wrote: >>>>> >>>>>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote: >>>>>> > >>>>>> > >>>>>> >> On 24 Jan 2019, at 17:04, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >>>>>> >> >>>>>> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote: >>>>>> >>> Everybody is of course totally free to do whatever they want, >>>>>> >>> but really, why the hell would you want to do that ? >>>>>> >> Because text has many uses other than just feeding into a compiler >>>>>> >> for translation to machine code? People who come from Unix/Linux >>>>>> >> world are used to using a rich collection of tools that deal with >>>>>> >> text in various ways. >>>>>> > >>>>>> > I am myself a server/linux guy, an emacs user, I know what is all >>>>>> > possible and what the unix philosophy is. >>>>>> >>>>>> >>>>>> No offense intended. Just wanted to point out that text can have >>>>>> different purposes. Historically, Smalltalk presented itself as a >>>>>> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform >>>>>> IDE. >>>>>> >>>>>> > I also know how to integrate Pharo into that world, and this is >>>>>> super >>>>>> > important. >>>>>> Thanks. This is what I intended to bring out. >>>>>> >>>>>> >>> You lose so much by doing that, I do not even know where to >>>>>> >>> start. >>>>>> >> >>>>>> >> Live coding (i.e. coding in the presence of instances) is >>>>>> >> undoubtedly more powerful than edit-compile-run cycle. Text is used >>>>>> >> to direct IDE to edit live objects. But text has many more uses >>>>>> >> than just issuing commands. If beginners start using vim just to >>>>>> >> edit code due to established habits, they will soon realize the >>>>>> >> ease of live coding and remain in IDE. This is a self-correcting >>>>>> >> error. >>>>>> > >>>>>> > Well, I don't think so. >>>>>> > The users that you are going to attract in this way (the ones that >>>>>> > don't want to leave their own IDE/editor), will look at textual >>>>>> Pharo >>>>>> > and find it very strange and ill suited to textual editing (and they >>>>>> > are absolutely right), they will not discover the power, will not >>>>>> > learn (from this experience alone) what object >>>>>> > design/programming/power is, and will ask for more (e.g. give me , >>>>>> > style compiler errors, better/easier structure of the file, fixed >>>>>> the >>>>>> > !! escape issue, etc, ...). >>>>>> >>>>>> I am sure there will always be skeptics. But my own experience was >>>>>> different. For me, the most weird thing about Squeak (and now Pharo) >>>>>> IDE >>>>>> is its insistence in showing only one method at a time. A method is >>>>>> too >>>>>> small a chunk of code. It is easy to miss the forest for the trees. >>>>>> In >>>>>> Dimitris video, you see lots more code in one glance in vim session. >>>>>> So >>>>>> there are pragmatic reasons why some coders fallback to using >>>>>> fileOuts >>>>>> for browsing classes. >>>>>> >>>>>> Regards .. Subbu >>>>>> >>>>>>

Jan. 24, 2019

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

by Dimitris Chloupis

yeah the System Browser has some shortcuts that you can find if you click that down arrow in top right corner of the window About getting Window info, that is tricky, all is available through Morphic but Morphic is kinda messy. So if you are willing to do the hard work its definetly doable , you can create your own shortcuts etc. Finding the leftmost probably you will ask the World morph about all windows , ask each window whether its opened and if yes where is located (morph >>position) I think the focus is in SystemWindow >> isActive , look also at basicActivate for a better idea what activation means For groups there is isEmbeded , also Morph >> embededMorphs No idea about the Playground, it keeps timestamped session of whatever you do so there is definetly something Yeah Pharo is not Emacs that's for sure. Mainly because we attract people who are mouse driven, people who are keyboard driven tend to avoid IDEs. Its doable , its just not available out of the box. I can feel your pain though, this has been an issue for me with Pharo, the power is there, but its not easy to access. However to be fair Emacs has been around a lot longer and has far larger community of contributors so its no wonder it can do these things with ease. Emacs also has amazing documentation. But sadly is no IDE and its shortcuts is pure insanity, but then I am a mouse person myself. Ironically I was raised on CLIs and I always hated them with passion :D On Thu, Jan 24, 2019 at 8:32 PM Jose San Leandro <jose.sanleandro(a)osoco.es> wrote: > I don't want to hijack this thread, but it would be useful for me to have > a cheatsheet to allow me to do the usual operations I do with the mouse, > programatically. I've had some difficulties with simple things in the past. > For example, to delete all Transcript or Playground windows, I use calls > such as > > (World submorphs select: [ :w | ((w model printString beginsWith: 'a >> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ]) >> do: [ :w | w delete ]. >> > > I'm missing ways to query World submorphs to know exactly my target > instance. For example: > - Which is the leftmost window? > - Which window has the focus? > - Which windows have "grouping" enabled? > - Which Playground instance I used more recently? > > And operations such as: > - Maximize morph. > - Activate "class side" in Nautilus. > - Select "accessing" protocol. > - Select package X. > - Select "Hierarchy". > - Choose the next child when "hierarchy" is active. > >> - Resize the method panel. >> > > Also, basic things like: > - Move to the next word. > - Highlight previous word. > - Highlight current line. > > That would be very helpful for me. I'm not saying it's difficult to do, > I'm just saying for me it'd be helpful. > That's basically why I love Emacs, because I can do with the keyboard > anything that can be done with the mouse, and more. > > Thanks! > > El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis (< > kilon.alios(a)gmail.com>) escribiÃ³: > >> Playground is a REPL inside Pharo so I am not sure I understand what you >> are asking. Everything in Pharo is just Classes and methods so you can do >> whatever you want. If you are a bit more descriptive maybe I can help you >> more. There is no such thing as a bad idea, just an idea that has not >> mature enough :D >> >> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro < >> jose.sanleandro(a)osoco.es> wrote: >> >>> I was aware of that. I was imaging a way to use the tools available in >>> Pharo, but within a REPL session. >>> Probably a bad idea anyway. I just think the mouse is useful when >>> exploring, but it's ridiculously inefficient once you know exactly what you >>> want to do. >>> In my 4k monitor I often feel like if I was saying "no, I want to resize >>> the window, not moving it, not changing the focus, thanks". I have to waste >>> time being accurate enough with the mouse, because it's the expected way to >>> communicate with live objects. Mouse, then keyboard. Not good. >>> >>> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (< >>> kilon.alios(a)gmail.com>) escribiÃ³: >>> >>>> "I am sure there will always be skeptics. But my own experience was >>>> different. For me, the most weird thing about Squeak (and now Pharo) >>>> IDE >>>> is its insistence in showing only one method at a time. A method is too >>>> small a chunk of code. It is easy to miss the forest for the trees. In >>>> Dimitris video, you see lots more code in one glance in vim session. So >>>> there are pragmatic reasons why some coders fallback to using fileOuts >>>> for browsing classes." >>>> >>>> I could not agree more , I find the column GUI weird and a waste of >>>> space. This is why I have ended up relying a lot on GTSpotter (finder) >>>> which help me browse classes a lot faster than the class browser. Kinda >>>> ironic. >>>> >>>> I am using Pharo since 2011. I am still dont like Class Browser :D >>>> >>>> "In summary, if someone misses Emacs or Vim when working with Pharo, it >>>> could be due to: >>>> - being stuck in the file-based way to think of coding. >>>> " >>>> Its a common misconception that Pharo does not heavily rely on text >>>> files, it actually does. Not only the source file makes it possible to view >>>> the code even the oldest method of version control tha Pharo being a fork, >>>> inherited from Squeak, the known mcz files they may look small binary files >>>> like the Pharo image but they are merely zip files with source code text >>>> files with the st extension. >>>> >>>> The image is merely the bytecode, the VMs machine code sort of, the >>>> actually source works the same way as other languages. Like other languages >>>> you dont need the source code to execute , only the bytecode. What makes >>>> the image special is that its one file and its a memory dump which makes it >>>> easy to store both live code and live state. Which is very helpful, >>>> technically its mandatory for true live coding, but still Pharo has to rely >>>> on source code files to make our lives easy. From there on is just a >>>> question whether you break the source code files in several small ones, or >>>> keep one large. >>>> >>>> "Besides that, is there an easy way to run an image in text-only mode, >>>> with a REPL or a playground or something like that?" >>>> >>>> Yeap its possible and has been around for a very long time. Pharo also >>>> makes it dead easy to expose any method as command line argument, so its >>>> possible to code completely from the command line although definitely not >>>> recommended. >>>> >>>> Deep Into Pharo book explains how. >>>> >>>> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu <kksubbu.ml(a)gmail.com> wrote: >>>> >>>>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote: >>>>> > >>>>> > >>>>> >> On 24 Jan 2019, at 17:04, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >>>>> >> >>>>> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote: >>>>> >>> Everybody is of course totally free to do whatever they want, >>>>> >>> but really, why the hell would you want to do that ? >>>>> >> Because text has many uses other than just feeding into a compiler >>>>> >> for translation to machine code? People who come from Unix/Linux >>>>> >> world are used to using a rich collection of tools that deal with >>>>> >> text in various ways. >>>>> > >>>>> > I am myself a server/linux guy, an emacs user, I know what is all >>>>> > possible and what the unix philosophy is. >>>>> >>>>> >>>>> No offense intended. Just wanted to point out that text can have >>>>> different purposes. Historically, Smalltalk presented itself as a >>>>> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform >>>>> IDE. >>>>> >>>>> > I also know how to integrate Pharo into that world, and this is super >>>>> > important. >>>>> Thanks. This is what I intended to bring out. >>>>> >>>>> >>> You lose so much by doing that, I do not even know where to >>>>> >>> start. >>>>> >> >>>>> >> Live coding (i.e. coding in the presence of instances) is >>>>> >> undoubtedly more powerful than edit-compile-run cycle. Text is used >>>>> >> to direct IDE to edit live objects. But text has many more uses >>>>> >> than just issuing commands. If beginners start using vim just to >>>>> >> edit code due to established habits, they will soon realize the >>>>> >> ease of live coding and remain in IDE. This is a self-correcting >>>>> >> error. >>>>> > >>>>> > Well, I don't think so. >>>>> > The users that you are going to attract in this way (the ones that >>>>> > don't want to leave their own IDE/editor), will look at textual Pharo >>>>> > and find it very strange and ill suited to textual editing (and they >>>>> > are absolutely right), they will not discover the power, will not >>>>> > learn (from this experience alone) what object >>>>> > design/programming/power is, and will ask for more (e.g. give me , >>>>> > style compiler errors, better/easier structure of the file, fixed the >>>>> > !! escape issue, etc, ...). >>>>> >>>>> I am sure there will always be skeptics. But my own experience was >>>>> different. For me, the most weird thing about Squeak (and now Pharo) >>>>> IDE >>>>> is its insistence in showing only one method at a time. A method is >>>>> too >>>>> small a chunk of code. It is easy to miss the forest for the trees. In >>>>> Dimitris video, you see lots more code in one glance in vim session. >>>>> So >>>>> there are pragmatic reasons why some coders fallback to using fileOuts >>>>> for browsing classes. >>>>> >>>>> Regards .. Subbu >>>>> >>>>>

Jan. 24, 2019