Behold Pharo: The Modern Smalltalk
Locked
1 ...
6789
1 ...
6789
 
|
We often get suggestions for such bindings. While in general it would be a great thing and I often promote lowering barriers of entry, I feel in this context "pure text mode" developers are more likely to find many other barriers with Pharo not fitting their familiar development paradigm. Such bindings are not the low hanging fruit for enticing developer to try Pharo and a better market is targeting those needing a better IDE. The more likely path to emacs/vim is pharo as a shell command which leaves a user's workflow around editing unchanged. cheers -ben On 9 December 2017 at 05:35, Kjell Godo <[hidden email]> wrote:
|
|
|
In reply to this post by Stephane Ducasse-3
Pharo: The Next Ten Minutes
<https://medium.com/@richardeng/pharo-the-next-ten-minutes-a17899dc9a58> . Feedback welcome. I will be leaving for vacation on Sunday for two weeks. Feedback should be given to me asap. Thanks. Stephane Ducasse-3 wrote > Hi Richard > > Thanks this is nice. I like Greeter :) > The suggestion of Ben are fun for the next one. > I will add a link to your article. > > Stef > > On Thu, Dec 7, 2017 at 11:35 PM, horrido < > horrido.hobbies@ > > wrote: >> Done. Class #Hello is now #Greeter in package "HelloDemo". >> >> I presume we're good to go, then? >> >> >> >> Offray Vladimir Luna Cárdenas-2 wrote >>> May be the class name could be changed a little bit to allow more >>> flexibility using the Pharo Quick Start as a base. Something like >>> "Greeter" and "Greeter new say: 'Hello world!'" or "Greeter new sayIt" >>> could be implemented from there. Nice to see more and more documentation >>> around Pharo, including this one. >>> >>> That being said, I have always felt that hello world is kind of a >>> strange introduction to programming: >>> >>> http://mutabit.com/offray/blog/en/entry/dumb-hello-world >>> >>> Cheers, >>> >>> Offray >>> >>> >>> On 07/12/17 15:31, horrido wrote: >>>> I've revised the draft slightly for the comments given here: >>>> https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2 >>>> >>>> Yes, it's a definite improvement. Thanks. >>>> >>>> >>>> >>>> Richard Sargent wrote >>>>> Excellent work, Richard! >>>>> >>>>> May I offer the small criticism against using #initialize for the >>>>> method >>>>> name? I think a name like #sayIt (for example) and invocation like >>>>> "Hello >>>>> new sayIt" would make it explicit. >>>>> >>>>> This will be a great help for people who drop by out of curiosity. >>>>> >>>>> >>>>> On Thu, Dec 7, 2017 at 11:38 AM, horrido < >>>>> horrido.hobbies@ >>>>> > wrote: >>>>> >>>>>> I've completed the first draft of my Pharo Quick Start guide >>>>>> <https://medium.com/@richardeng/pharo-quick-start-5bab70944ce2> >>>>>> . >>>>>> I >>>>>> decided >>>>>> to forge ahead anyway. >>>>>> >>>>>> Feedback welcome. >>>>>> >>>>>> Note that I chose wget instead of curl because many Linux distros do >>>>>> not >>>>>> have curl installed. >>>>>> >>>>>> I've tested the guide for various Linux distros including Mint 18.3 >>>>>> (Ubuntu-based), Debian 9.2.1, Manjaro 17.0.6 (Arch-based), Solus 3, >>>>>> and >>>>>> Fedora 27. So it should be good for all the popular distros (Top 10). >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>> >>>> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: Behold Pharo: The Modern Smalltalk
|
In reply to this post by Kjell Godo
Nope , nothing to do with Emacs GNU Smalltalk is Smalltalk without.... welll... Smalltalk Which is why almost none is using it. There is a project to use Pharo from inside Emacs called Shamoo. Frankly you will be sacrificing a lot of IDE goodies leaving Pharo. Neither Emacs or vim are proper IDEs , they are text editors pretending to be IDEs and failing miserably at it. On the other hand Pharo IS an IDE playing ball with big boys. Making shortcuts in Pharo is no big deal, if 10% of people asking for Emacs or vim shortcuts bothered creating just 10 shortcuts each we would have by now at least 100 Emacs shortcuts in Pharo. When one say that needs something that He or she is not willing to do even 1% of its work, then he does not need it enough for others to bother. It’s the difference between hype and actual desire. On Fri, 8 Dec 2017 at 23:35, Kjell Godo <[hidden email]> wrote:
|
Re: Behold Pharo: The Modern Smalltalk
|
|
On 9 Dec 2017, at 07:44 , Dimitris Chloupis <[hidden email]> wrote: In September, I posted an Issue on pharo.fogbuz: making keyboard shortcuts for the Pharo Smalltalk editor is not easy, but should be. No one has responded to that issue saying that it really is easy, and explaining how to do it. So if you know, I invite you to work on this issue. tl;dr: I though that it was easy too, but after spending a couple of days trying to figure it out, gave up. If 10% of the energy expended in this thread had gone into fixing open issues, then Pharo would be getting better every day.
|
Re: Behold Pharo: The Modern Smalltalk
|
|
Envoyé de mon iPhone
+1 Less talk more Pharo ! |
|
|
In reply to this post by horrido
An extra thing for the first article, maybe change the package name from "HelloDemo" to "HelloWorld" On 9 December 2017 at 11:37, horrido <[hidden email]> wrote: Pharo: The Next Ten Minutes I see you have auto-update-process turned on, but you didn't tell users to do this. (I think it is useful to have on. @all, I'm curious why its not on by default) Double "little" in first sentence. You should describe how you enter the second method over the top of the first. People sometimes get stuck thinking they'll be altering the #sayIt method. In hindsight, when readers go to experiment themselves, some may drop the #wait to see how fast it can generate messages which will lock up the UI due to co-operative scheduling within a priority. It will be better to use... [...] #forkAt: 30 named: 'Count de Money' > How do you like it? maybe... How do you like it? The implication is that in the early stages of protoyping, you don't need to slow down to build an object/relational mapping. Just design with pure objects and persist sample data in the Image. ----------------- The article is good but feels too short. One additional demonstration would look good. To facilitate this, change the demo code to use two methods. sayCount: anInteger self inform: anInteger printString. counter | count | count := 0. [1000 timesRepeat: [count := count + 1. self sayCount: count. 2 seconds wait]] forkNamed: 'Count de Money' Then after the existing end of the article... Now consider your current language of choice... Say you are part of the Testing Team and a unit test errors intermittently, or you're in Operations where an intermittent error occurs in a production system. Typically the program exits, maybe dumping state but losing the live context where the error occurred. What would it take to reproduce the exact error context for Developers to analyze? Lets see how Pharo handles this by introducing an error into a running 'Count de Money' process. (If its not running, evaluate "Greeter new counter") Make this modification... sayCount: anInteger self inform: anInteger * 10 printString. Immediately after you save this, a pre-debug window pops up... [screen snapshot pre-debug top of stack] Scroll down and click on "sayCount:" and you should see the debugger... [screen snapshot full debugger on sayCount with "* 10 printString" highlighted] Now as before, you can record the execution state of all running threads by saving a Pharo Image. Later when you reopen Pharo you can continue debugging the faulted thread. So give this a try. Save and quit Pharo now. (You could even transfer the .image file together with its paired .changes file to another machine with Pharo.) Open the Pharo Image again. Now we are ready to fix the error. To explain the error, one thing Pharo newcomers need to adapt to is that arithmetic operators are just normal message sends with no special precedence. Pharo has simple semantics with just three precedence rules, evaluated right to left. Unary messages like "printString" are always evaluated first. Binary messages like " * " are evaluated second. Keyword messages like "inform:" are evaluated last. So the error here is that we multiplied an integer with a string. Easily fixed... sayCount: anInteger self inform: (anInteger * 10) printString. After saving, click <Proceed> and observe the running process continues rather than needing to restart it. In many situations, continuing from errors like this rather than waiting for a restarted program to progress to the same state facilitates a very quick "debug->edit->compile->run" development loop. For a similar demonstration, check out [PharoLambda Serverless Debugging, https://www.youtube.com/watch?v=bNNCT1hLA3E ] HTH cheers -ben |
Re: Behold Pharo: The Modern Smalltalk
|
|
In reply to this post by Prof. Andrew P. Black
The beginner way ------ 1. Open Pharo 62. Go to Welcome window 3. Go to Keymap Browser tab 4. Right click on a shortcut entry (for example global shortcut for close window) 5. Choose Inspect Action 6. Go to Source Code tab 7. Profit The Pharo coder way ---- Or go to SystemWindow class >> buildShortcutsOn: or got to NautilusWindow class >> build....ShortcutsOn: (any method will do) or search for any method using the <keymap> pragma On Sat, Dec 9, 2017 at 12:06 PM Prof. Andrew P. Black <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |