- Pharo-users - lists.pharo.org

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

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

by Jose San Leandro

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

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 Jose San Leandro

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

"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 Jose San Leandro

I am one of those that Dimitris Chloupis calls "shortcut guys". Actually, I think using the mouse is a performance killer. I agree with the argument that editing files instead of manipulating the image wouldn't make sense, if I could edit code as fast as I do in Emacs or Vim. In those editors, you have macros. They are explicitly designed to be usable without the mouse. At some point, you manipulate text without thinking. That's nowhere near what you can accomplish with Nautilus (or Calypso, I suspect). Having said that, I don't use Emacs or Vim to edit .st files, but in specific cases when I know what I'm doing and it's not dealing with live objects, but with bootstrapping images. In the past, I felt I was missing Emacs because I wasn't yet fully immersed in a live environment. I was uncomfortable editing code in Pharo, but it was tolerable. Of course, it would have been much more tolerable if I didn't know Emacs, so I wasn't aware of what I was missing. I expect to be able to customize the keybindings (which would be a huge boost for me) in Nautilus or Calypso, and once that happens my life in Pharo would be much much happier. 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. - or, missing the productivity aids that are not present on Pharo. 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? El jue., 24 ene. 2019 a las 17:59, Dimitris Chloupis (<kilon.alios(a)gmail.com>) escribiÃ³: > "Honestly, Pharo without the environment (and the âlive objectsâ approach) > is just another dynamic language without much interest. > Thinking the IDE is just autocompletion is a poor idea of what a live > environment can do for you." > > And I repeat once more, I NEVER said use external editor instead of Pharo, > I said use external editor with Pharo. No idea how to make this any more > clear. With my approach you sacrifice nothing from Pharo. > > "These are all valid points (and I started by saying that everybody is > free to do whatever they want), but wouldn't you agree that the best > experience is" > > Nothing absolutely nothing in my book comes remotely close to how polished > Delphi and amazingly powerful IDE with great GUI design, > No I dont agree emacs is an IDE at all, even setting up its tools is a > huge pain. I tried to set it up for Python coding and it tooks me ages to > reach absolutely zero. Vim is nowhere near to being an IDE. Lispworks I > have no idea never used it , same story with mathematica. I have used > PyCharm which is I think is the equivelant of IntelliJ, well designed IDE > but too weak for my taste. XCode only supports ObjC and Swift and as an IDE > , even though an Apple product it lets a lot to be desired in GUI design > and also not impressive. > > So for me its first Delphi or its open source variant Free Pascal/Lazarus > and then is Pharo. Suprisingly Visual Studio is a nice IDE (just nice) but > not VSCode which I currently use which is 100% code editor. > > To be sincere I have given up on the idea of IDEs mainly because even with > Pharo it was a huge pain to customise them, usual coding problem of lack of > documentation, no code comments etc. Nowdays I design my own dev tools from > scratch, they are not pretty but get the job done partially and at least I > know the code well enough to easily improve it. > > My livecoding lib has become quite usable lately and now I am slowly > venturing into the territory of memory managment and data visualisation. > > The IDE for me is a very personal experience, of course that does not mean > that Pharo and Delphi are not still my idols. Love them both. They are > amazing restaurants, with the best chefs in the world but in the end > nothing is like home made food. > > I dont agree that Smalltalk without an IDE is a Smalltalk, thus I do not > consider GNU Smalltalk a Smalltalk at all. > > "Giving people a subpar entry into our world will probably not convince > them that there is something cool to be seen there." > > I think my video tutorials have given more than enough good reason to use > Pharo and even more to love Pharo. I find it hard to believe that one video > tutorial going to change that. I never hidden my love for Pharo. Also for > me live coding has become mandatory anyway which why I went to such great > extends to implement it in Python and C. Mind you nowhere near the Pharo's > elegance but it works. > > "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 :-(). Also a caveat not to edit *.changes or *.sources though they > look very similar to *.st files." > > I have explicitly said to edit only st files, no idea how to make myself > any more clear. Although sometime making mistakes is a great excuse to > learn something. Because I never intended this to be a replacement for > Pharo , I thought unnecessary to focus on the syntax of the st file format. > > I think I should add a warning to the video "WARNING!!!! THIS IS NO > REPLACEMENT FOR PHARO BUT AN EXTENSION". > > "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, ...)." > > I think you are a bit too optimistic. People if they dont like something > they just give up and move on. When was the last time you saw a post here > by a person saying "I like to use Pharo but I will not because it does not > have X". Rarely if not never, because these type of people you describe are > gone in 50 seconds. > > To be sincere if my video makes them leave, awesome, we dont need people > who dont use Pharo complaining about Pharo. And plus I would love someone > to even mention C, I have like an army of complains about this language and > I have to use it everyday. Well at least is not as bad as C++. Thank God > !!!!! > > By they way we had this discussion before in the community. When I first > mentioned Git and Github (2011) back when using Git with Pharo and > especially an external website to upload code was unthinkable , if not > heretic, I can remember how many told me that this would be an excuse for > people not to learn Pharo. I did not buy it then , I did not buy it now. > > If you search for Pharo you will find Pharo, its that simple. The rest is > just excuses. > > Pharo should not be afraid of other technologies , other technologies > should be afraid of Pharo. Assimilate, resistance is futile. >

Jan. 24, 2019

Re: [Pharo-users] How to embed VSE application into Pharo

by Davide Grandi

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: > How to embed VSE application into Pharo > > Hi, > > I am a very old Smalltalk user; I have developedTONSof applicationwith > Digitalkâs VSE; some of them are used by morehundredsclients. > > Can you tell me ifthere is any possibility toembed my VSE > applicationsinto Pharowithoutrewriting them? > > My goal would be to use Pharo for my new applicationswithoutloosethe > old onesand to interact with old ones in Pharo. > > Many thanks for your answer > > Lorenzo > -- Ing. Davide Grandi email : davide.grandi(a)mclink.it

Jan. 24, 2019

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

by K K Subbu

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] [Pharo-dev] [ANN] Pharo 7.0 released!

by Dimitris Chloupis

64 bit is finally here, amazing work guys, I was thinking making a torrent client of sorts with Pharo using libtorrent library https://www.libtorrent.org/ To anyone who has not tried the FFI , you should even if you dont care about C its amazingly well designed , so kudos to Esteban, Igor and whoever else contributed in this beauty That's my No1 My No2 is GTSpotter, any news on that front ? Does Pharo 7 offer something new ? On Thu, Jan 24, 2019 at 3:04 AM Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Wed, Jan 23, 2019 at 06:43:50PM -0500, Offray Vladimir Luna CÃ¡rdenas > wrote: > > I joined HN just to be able to comment on this thread[1]. Yes, it seems > > [1] https://news.ycombinator.com/item?id=18984409 > > Kudos for a measured response. > > >

Jan. 24, 2019

Re: [Pharo-users] Website is down

by Dimitris Chloupis

Personally I like the idea of turning this into a static web site, static websites can use bootstrap so they can play well with mobile devices too and then its easy to host on Github or Gitlab or whatever and avoid such pains. It will also make it much easier to manage. But hey I am nowhere near to being a web dev so what do I know :D On Thu, Jan 24, 2019 at 3:23 AM john pfersich <jpfersich(a)gmail.com> wrote: > Maybe ask more people to join the Pharo Association to get funds to move > the file server to a infrastructure that can handle a higher volume of > traffic. I know that Iâd be willing to increase my Bountysource > contribution to help cover the cost. I donât use Pharo professionally, but > I try to push Smalltalk, and Pharo specifically as a solution in my work > assignments. > > Sent from my iPhone > https://boincstats.com/signature/-1/user/51616339056/sig.png > See https://objectnets.net and https://objectnets.org > > > On Jan 23, 2019, at 13:57, Todd Blanchard <tblanchard(a)mac.com> wrote: > > > > Is it a static website or does it have code behind it? > > > > Could we use S3 at AWS? > > > >> On Jan 22, 2019, at 9:37 AM, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >> > >> El mar., 22 ene. 2019 a las 14:03, Esteban Lorenzano > >> (<estebanlm(a)gmail.com>) escribiÃ³: > >>> > >>> There is a problem with INRIA servers :( > >>> They does not seems to support high traffic > >>> > >> > >> They don't support high traffic nor high volume either. The download > >> speed was awful then, and it's even worst now. > >> But hey, those who pass all these obstacles to get to know and try > >> Pharo are more likely to continue using it. :) > >> > >> > >>> (supposing public from reddit and yc is high traffic?) > >> > >> Well... with at least a 100:1 ratio of visits:upvotes the hits must be > >> at least two order of magnitude higher than on a regular day. > >> Which makes me wonder... do we have any stats of that? > >> > >> These problems are "good" problems, and are the easiest to solve. > >> > >> > >> Esteban A. Maringolo > >> > > > > > >

Jan. 24, 2019