- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3406 in pharo: Standard images from downloads page do not implement Object #clone

by pharo＠googlecode.com

Comment #2 on issue 3406 by stephane.ducasse: Standard images from downloads page do not implement Object #clone http://code.google.com/p/pharo/issues/detail?id=3406 You should update the sound package as follow: - either use shallowCopy but better use copy (which calls shallowCopy). then if you need something else than the shallowCopy specialize the postCopy method on your objects. Clone default semantics was shallowCopy, now you can decide.

Dec. 13, 2010

Re: [Pharo-project] Issue 1042 in pharo: documentation/help menu

by pharo＠googlecode.com

Comment #6 on issue 1042 by marianopeck: documentation/help menu http://code.google.com/p/pharo/issues/detail?id=1042 Tony, one of your frases is the Pharo philosofy: "If we wait for perfection in all things we will never achieve anything. ". EXACTLY. We really appreacite your work. Go ahead, give it a first shoot, and then we can integrate it. After....we can improve it.

Dec. 13, 2010

Re: [Pharo-project] About using pragma for help like in setting

by laurent laffont

Thanks Torsten for this detailed view. I think nothing stop for having the CustomHelp approach (for writing overviews) AND the pragmas approach (to extract documentation from code / tests). Indeed a complete help on a package will surely mix the two. Actually for the Help I write I have some Help books + PackageAPIHelpBuilder. Another example is ProfStef: with last ConfigurationOfProfStef, all tutorials are automatically available in HelpSystem, thanks to HelpBuilder. You will also find in http://www.squeaksource.com/LaurentLSandbox.html the package API-Help wich build the help of all classes in Pharo (warning: slow, but has been helpful for me several times :) PS:I added the cool IRC example here: http://www.pharocasts.com/2010/09/document-with-helpsystem.html Laurent On Mon, Dec 13, 2010 at 2:34 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > OK, just read the IRC meeting notes and the last posts/threads on the help > discussions. > Unfortunately the discussion is scattered and I try to catch up/summarize > here > even for people who are new to the topic. Excuse the length of this post in > advance. > If the pragma help is interesting to you only then jump to section "D": > > > A. Pharo once lacked a "help system", so I wrote one. It was and still is > more oriented > towards "end user help" or "browsable manuals" with written text content > in form of > nestable books. I had no need for the next JavaDoc in Smalltalk with > just an API reference > - I wanted real help text which gives a big picture overview to people > on various topics. > > The design of HelpSystem is simple and should be easy to understand, we > have a > HelpBrowser that displays (nestable) HelpTopics. To display something > you have to > convert it into such a help topic instance. > > Click on "Help" -> "HelpBrowser" in your Pharo image and have a look at > the book > "Help on Help" to get more details or try a few examples. > > > B. I think you all agree that a "help system" without content is not very > useful. > Different people have different ideas and what could be used as "help > contents" > should be up to you. > > The HelpSystem itself is not and should not be bound to where and how > (format, etc.) > the content is stored. You can convert from any source and format into > nested HelpTopics. > > To demonstrate this I once provided an example [1] to query and display > the IRC archive. > You will also find this example with IRC as one possible external source > in the "Help on help" > book. > > So the content could be defined in any format you like and the contents > source could be > internal or external to the image. You should declare the help contents > the way you like. > > C. When you want to provide help to a user you may find it nice to include > and manage > the contents directly within the image. Nice - since you can deploy it > with your app or > unload if it is not needed. > > There are many solutions here - on squeak-dev it was discussed to use a > specific class > comment format or store the contents in methods returning an XML string, > etc. > I expected this discussion since I thought long enough about formats, > storage and I > didnt want to limit anyone. > > Therefore HelpSystem is open to any of these solutions - one can > implement a custom > help builder (see class HelpBuilder) that does the necessary conversion > into help topic > instances. > > One of the many possible solution is to use "pragma annotated" classes > that hold the > contents. Looks like this is getting more attention now again since > pragmas are used > in various places now (like the settings framework). > > And yes, I followed the pragma path already. But after initial > experiments with pragmas > I found it much more convenient to map a tutorial/the help book > structure directly to > the class hierarchy. > > This "class to book" mapping is more natural, one can use the usual > class browsers and > tools to manage the contents (including references, implementors, > senders, ...) > and you can easily have extensible books/tutorials (which is complicated > with pragmas) > > If you want to follow this "class to book" approach then HelpSystem > provides a class > called "CustomHelp" that you can subclass and that has all the necessary > support > (even for editing and saving by using a workspace) - so you can easily > implement your > help books. Some projects use this already and there is even a Pharocast > on how to > to this. > > Through the class CustomHelp in the HelpSystem we have a commonality > with SUnit - > where you have TestCase as a superclass and implement hook methods. > > This class "CustomHelp" is the one "under fire" that leads to scathing > criticism from > Lukas. > > Maybe it is exactly this commonality with SUnit that makes some of you > think HelpSystem > forces you to subclass "CustomHelp" or forces you to have a dependency > on the help system > if you want to declare your help content. > > => But yet again: nobody has to use the provided "class to book" > mapping or subclass > "CustomHelp" if you want to define your help > contents! > > Maybe I should not ship HelpSystem with this support class "CustomHelp" > as the (currently sole) > default but I wanted to at least provide a way to get you started. Still > it is an utility class > and also categorized as such. > > I for myself have no problem with this additional class since when > subclassed I know that > I have a dependency on it's package and I treat the help packages > similar to test > in SUnit (only loaded when HelpSystem is there, etc.) > > However the "CustomHelp" approach has pros and cons and you have to > decide if it is the > right for you: > > Maybe you like: - easy mapping of classes to books > - easy browsing/managing in standard code tools > - familarity with SUnit (common superclass) > - no "copy/paste" methods as in Metacellos > ConfigurationOfXXX > > Maybe you dislike: - the dependency on the superclass CustomHelp and > - therefore the dependency on the help package > > Typical use case is that you display the help contents in the browser > anyway and > therefore this dependency may not hurt you. > > Looks like Lukas has a use-case where he requires his help contents only > - but > not the help system itself. Similar to a loaded test without any SUnit > support in the image... > > D. As I already said I designed HelpSystem to stay independent from the > way the contents is > defined. So I'm definitely open to a pragma based solution too. In the > long term I would like to see > support for different "content definition styles" anyway. > > Lukas can store his blog posts/help texts the way he likes and without > any dependency on HelpSystem. > > After the discussion in May we all agreed [2] that it is a good > direction to check out the > pragma/builder approach too and see how far we can go here. I provided > an example how one > can easily add this "pragma approach" to to the HelpSystem ([3] and [4] > for the code) but I left > out the builder part since I dont know what Lukas expects here. > > So no real feedback/adoption so far ... at least it would help if I get > an example > on how the contents should be defined in an annotated #buildHelpOn: > method. > > However, the pragma approach has pros and cons: > > Maybe you like: - no dependency on a common superclass or package > dependency on a class in HelpSystem > - may therefore seem "cleaner" depending on POV > > Maybe you dislike: - even with pragmas one has an implicit dependency > on the builders interface > which also has to be stable very early > - by using pragmas (loose coupling) you have to > deal with the problem that > your parent topic may not be there/not be loaded > since it can be defined > somewhere else in the class hierarchy. > > E. After the initial release people asked on how to integrate typical > "Smalltalk documentation" > to include browsable reference documentation (API doc) like class and > method comments in the > HelpSystem too. This was easy to add since again I just had to write a > custom help builder that does the > necessary conversion. > > If you load the "Pharo-Project-Help" you can browse the complete > reference on anything that > is already documented: > > > Gofer new > squeaksource: 'HelpSystem'; > package: 'Pharo-Project-Help'; > load. > HelpBrowser open. > > In the help browser click on "Pharo" and "API Reference". This is more > "reference documentation" and > only a "poor" way to easily fill up the help system ;) > > I would like to see people writing more tutorials/manuals about parts of > the system so one could get the big > picture, but the idea of Stef [5] to get fully documented classes and > methods is also nice. For the > reference docu: > > > Maybe you like: - no dependency on anything, just comment your > classes and methods > as you may know from any other smalltalk system > > Maybe you dislike: - you dont need the help system, you can look at > it in the standard browser > - its only a basic API documentation system > (compared to JavaDoc and others) > > > ----------------------------------------------------------------------------------------------------------------- > And now some comments on IRC/posts I've seen: > > Lukas on IRC see [6]: > >[3:14pm] renggli: HelpSystem is not useable for me and obviously not for > anybody else (otherwise > >it wouldn't be empty) > > Lukas, nobody forces you to follow the "define help contents via class to > book mapping" approach. > If you want a "define help content via pragmas" approach then help moving > this issue forward or define > your help contents the way you like and implement a custom help builder. > > For the other point: HelpSystem is not empty - look at an updated core 1.2 > and it is already > used in many external packages as Laurent already pointed out. [7] > > > Lukas wrote on [8]: > >> Couldn't you just add another loop to your script to "unload all help" > just > >> like unload all tests > >Sure, but that means I have to package help text separately. This is > >the contrary to what Java, Ruby, Python, Javascript, ... are doing; > >keeping code and documention as close together as possible. > > No - you dont have to package documentation seperately. A class/method > comment is still a > class/method comment and its packaged with the code. There is no dependency > on HelpSystem > here - although the HelpBrowser can display it too. > > You still keep code and documentation close as in any other language. > > But if you write a "big picture" help manual or tutorial on how things > interact it would > be good to package it seperately. Either using CustomHelp, pragmas, or ... > > > Lukas wrote on [8]: > >I think, the fact that there is no single external package with help > >system documentation proves this, no? > > There are quite a few. Maybe you should look more often on Squeaksource. > Again I point to [7] > > > Stef wrote on [9] > >Now I was thinking that torsten would reply to this mail but in 1.3 will > take a decision because I want a really better help > >and documentation inside the right class and package. > > I still think that we should in minimum have the "code" - "tests" - "help" > package triade, where the code package > includes the class and method documentation as any Smalltalker is used to. > The test package should include unit tests > covering the code. And the help package should give a high level overview > on how to use the code or tests. > > If the dependency from "help" packages to "help system" due to the class > CustomHelp is a problem then > we can easily convert them once we have a good "pragma based" approach in > place. > > Removing packages or classes that are not documented is too hard ... but we > should use Lint rules to check the > "completeness/basic quality" of package. > > Similar to checkstyle for Java in Eclipse - if there are problems in a > package then you have a different icon for > the package and you work until it's clean because it hurts your eyes (see > [10] for a screenshot) > > > Hope I could at least bring some light into the whole discussion and I > would really like > the see if also the pragma approach would move forward. > > Bye > Torsten > > > [1] > http://forum.world.st/Preview-Help-System-with-new-model-now-also-for-Squea… > [2] http://forum.world.st/Help-System-td2131748.html > [3] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/026148.html > [4] > http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100505/c… > [5] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/036952.h… > [6] http://pastebin.com/Y7MFaddK > [7] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037507.h… > [8] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037485.h… > [9] > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037499.h… > [10] > http://www.ibm.com/developerworks/java/library/j-ap01117/checkstyle-eclipse… > > > > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > >

Dec. 13, 2010

Re: [Pharo-project] Issue 3406 in pharo: Standard images from downloads page do not implement Object #clone

by pharo＠googlecode.com

Updates: Status: Invalid Comment #1 on issue 3406 by renggli: Standard images from downloads page do not implement Object #clone http://code.google.com/p/pharo/issues/detail?id=3406 Use #shalloCopy, #clone has been intentionally removed (Issue 2018).

Dec. 13, 2010

Re: [Pharo-project] About using pragma for help like in setting

by David T. Lewis

On Mon, Dec 13, 2010 at 02:34:58AM +0100, Torsten Bergmann wrote: > > If you want to follow this "class to book" approach then HelpSystem provides a class > called "CustomHelp" that you can subclass and that has all the necessary support > (even for editing and saving by using a workspace) - so you can easily implement your > help books. Some projects use this already and there is even a Pharocast on how to > to this. FWIW, I recently put the old Squeak Terse Guide into a subclass of CustomHelp. For me, I was just trying to find a way to make the Terse Guide easily available, and after messing around with loading it into a workspace, it suddenly (d'oh!) occurred to me that I could just load it as a help book, so that is what I did. The important thing for me is that I found class CustomHelp, and that is what I used. It worked fine, so now we have the Terse Guide in a help book. I don't know if this is the ultimate best help system to end all help systems, and I'm all in favor of a pragma based approach, but I have to say that any documentation system that actually gets used is better than even the most perfect documentation system that does not get used, so my hat is off to Torsten for providing a simple, accessible, and usable help system. Dave p.s. You can load the terse guide for Pharo from http://source.squeak.org/Trunk package Help-Squeak-TerseGuide

Dec. 13, 2010

[Pharo-project] About using pragma for help like in setting

by Torsten Bergmann

Hi, OK, just read the IRC meeting notes and the last posts/threads on the help discussions. Unfortunately the discussion is scattered and I try to catch up/summarize here even for people who are new to the topic. Excuse the length of this post in advance. If the pragma help is interesting to you only then jump to section "D": A. Pharo once lacked a "help system", so I wrote one. It was and still is more oriented towards "end user help" or "browsable manuals" with written text content in form of nestable books. I had no need for the next JavaDoc in Smalltalk with just an API reference - I wanted real help text which gives a big picture overview to people on various topics. The design of HelpSystem is simple and should be easy to understand, we have a HelpBrowser that displays (nestable) HelpTopics. To display something you have to convert it into such a help topic instance. Click on "Help" -> "HelpBrowser" in your Pharo image and have a look at the book "Help on Help" to get more details or try a few examples. B. I think you all agree that a "help system" without content is not very useful. Different people have different ideas and what could be used as "help contents" should be up to you. The HelpSystem itself is not and should not be bound to where and how (format, etc.) the content is stored. You can convert from any source and format into nested HelpTopics. To demonstrate this I once provided an example [1] to query and display the IRC archive. You will also find this example with IRC as one possible external source in the "Help on help" book. So the content could be defined in any format you like and the contents source could be internal or external to the image. You should declare the help contents the way you like. C. When you want to provide help to a user you may find it nice to include and manage the contents directly within the image. Nice - since you can deploy it with your app or unload if it is not needed. There are many solutions here - on squeak-dev it was discussed to use a specific class comment format or store the contents in methods returning an XML string, etc. I expected this discussion since I thought long enough about formats, storage and I didnt want to limit anyone. Therefore HelpSystem is open to any of these solutions - one can implement a custom help builder (see class HelpBuilder) that does the necessary conversion into help topic instances. One of the many possible solution is to use "pragma annotated" classes that hold the contents. Looks like this is getting more attention now again since pragmas are used in various places now (like the settings framework). And yes, I followed the pragma path already. But after initial experiments with pragmas I found it much more convenient to map a tutorial/the help book structure directly to the class hierarchy. This "class to book" mapping is more natural, one can use the usual class browsers and tools to manage the contents (including references, implementors, senders, ...) and you can easily have extensible books/tutorials (which is complicated with pragmas) If you want to follow this "class to book" approach then HelpSystem provides a class called "CustomHelp" that you can subclass and that has all the necessary support (even for editing and saving by using a workspace) - so you can easily implement your help books. Some projects use this already and there is even a Pharocast on how to to this. Through the class CustomHelp in the HelpSystem we have a commonality with SUnit - where you have TestCase as a superclass and implement hook methods. This class "CustomHelp" is the one "under fire" that leads to scathing criticism from Lukas. Maybe it is exactly this commonality with SUnit that makes some of you think HelpSystem forces you to subclass "CustomHelp" or forces you to have a dependency on the help system if you want to declare your help content. => But yet again: nobody has to use the provided "class to book" mapping or subclass "CustomHelp" if you want to define your help contents! Maybe I should not ship HelpSystem with this support class "CustomHelp" as the (currently sole) default but I wanted to at least provide a way to get you started. Still it is an utility class and also categorized as such. I for myself have no problem with this additional class since when subclassed I know that I have a dependency on it's package and I treat the help packages similar to test in SUnit (only loaded when HelpSystem is there, etc.) However the "CustomHelp" approach has pros and cons and you have to decide if it is the right for you: Maybe you like: - easy mapping of classes to books - easy browsing/managing in standard code tools - familarity with SUnit (common superclass) - no "copy/paste" methods as in Metacellos ConfigurationOfXXX Maybe you dislike: - the dependency on the superclass CustomHelp and - therefore the dependency on the help package Typical use case is that you display the help contents in the browser anyway and therefore this dependency may not hurt you. Looks like Lukas has a use-case where he requires his help contents only - but not the help system itself. Similar to a loaded test without any SUnit support in the image... D. As I already said I designed HelpSystem to stay independent from the way the contents is defined. So I'm definitely open to a pragma based solution too. In the long term I would like to see support for different "content definition styles" anyway. Lukas can store his blog posts/help texts the way he likes and without any dependency on HelpSystem. After the discussion in May we all agreed [2] that it is a good direction to check out the pragma/builder approach too and see how far we can go here. I provided an example how one can easily add this "pragma approach" to to the HelpSystem ([3] and [4] for the code) but I left out the builder part since I dont know what Lukas expects here. So no real feedback/adoption so far ... at least it would help if I get an example on how the contents should be defined in an annotated #buildHelpOn: method. However, the pragma approach has pros and cons: Maybe you like: - no dependency on a common superclass or package dependency on a class in HelpSystem - may therefore seem "cleaner" depending on POV Maybe you dislike: - even with pragmas one has an implicit dependency on the builders interface which also has to be stable very early - by using pragmas (loose coupling) you have to deal with the problem that your parent topic may not be there/not be loaded since it can be defined somewhere else in the class hierarchy. E. After the initial release people asked on how to integrate typical "Smalltalk documentation" to include browsable reference documentation (API doc) like class and method comments in the HelpSystem too. This was easy to add since again I just had to write a custom help builder that does the necessary conversion. If you load the "Pharo-Project-Help" you can browse the complete reference on anything that is already documented: Gofer new squeaksource: 'HelpSystem'; package: 'Pharo-Project-Help'; load. HelpBrowser open. In the help browser click on "Pharo" and "API Reference". This is more "reference documentation" and only a "poor" way to easily fill up the help system ;) I would like to see people writing more tutorials/manuals about parts of the system so one could get the big picture, but the idea of Stef [5] to get fully documented classes and methods is also nice. For the reference docu: Maybe you like: - no dependency on anything, just comment your classes and methods as you may know from any other smalltalk system Maybe you dislike: - you dont need the help system, you can look at it in the standard browser - its only a basic API documentation system (compared to JavaDoc and others) ----------------------------------------------------------------------------------------------------------------- And now some comments on IRC/posts I've seen: Lukas on IRC see [6]: >[3:14pm] renggli: HelpSystem is not useable for me and obviously not for anybody else (otherwise >it wouldn't be empty) Lukas, nobody forces you to follow the "define help contents via class to book mapping" approach. If you want a "define help content via pragmas" approach then help moving this issue forward or define your help contents the way you like and implement a custom help builder. For the other point: HelpSystem is not empty - look at an updated core 1.2 and it is already used in many external packages as Laurent already pointed out. [7] Lukas wrote on [8]: >> Couldn't you just add another loop to your script to "unload all help" just >> like unload all tests >Sure, but that means I have to package help text separately. This is >the contrary to what Java, Ruby, Python, Javascript, ... are doing; >keeping code and documention as close together as possible. No - you dont have to package documentation seperately. A class/method comment is still a class/method comment and its packaged with the code. There is no dependency on HelpSystem here - although the HelpBrowser can display it too. You still keep code and documentation close as in any other language. But if you write a "big picture" help manual or tutorial on how things interact it would be good to package it seperately. Either using CustomHelp, pragmas, or ... Lukas wrote on [8]: >I think, the fact that there is no single external package with help >system documentation proves this, no? There are quite a few. Maybe you should look more often on Squeaksource. Again I point to [7] Stef wrote on [9] >Now I was thinking that torsten would reply to this mail but in 1.3 will take a decision because I want a really better help >and documentation inside the right class and package. I still think that we should in minimum have the "code" - "tests" - "help" package triade, where the code package includes the class and method documentation as any Smalltalker is used to. The test package should include unit tests covering the code. And the help package should give a high level overview on how to use the code or tests. If the dependency from "help" packages to "help system" due to the class CustomHelp is a problem then we can easily convert them once we have a good "pragma based" approach in place. Removing packages or classes that are not documented is too hard ... but we should use Lint rules to check the "completeness/basic quality" of package. Similar to checkstyle for Java in Eclipse - if there are problems in a package then you have a different icon for the package and you work until it's clean because it hurts your eyes (see [10] for a screenshot) Hope I could at least bring some light into the whole discussion and I would really like the see if also the pragma approach would move forward. Bye Torsten [1] http://forum.world.st/Preview-Help-System-with-new-model-now-also-for-Squea… [2] http://forum.world.st/Help-System-td2131748.html [3] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-May/026148.html [4] http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100505/c… [5] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/036952.h… [6] http://pastebin.com/Y7MFaddK [7] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037507.h… [8] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037485.h… [9] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-December/037499.h… [10] http://www.ibm.com/developerworks/java/library/j-ap01117/checkstyle-eclipse… -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Dec. 13, 2010

[Pharo-project] Issue 3406 in pharo: Standard images from downloads page do not implement Object #clone

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3406 by musicartscience: Standard images from downloads page do not implement Object #clone http://code.google.com/p/pharo/issues/detail?id=3406 Hi, I downloaded the one-click install and the Windows installer of 1.1 image and when I ran the "AbstractSound bachFugue play" example, I found that Object did not understand #clone which was fired from PluckedSound. I fixed the problem by implementing #clone on Object with the following code: clone <primitive: 148> self primitiveFailed I think you need to check the default image and include this implementation of #clone for Object, it fixed the problem for me, but I had to download two images, both which didn't have it and were marked as "stable". Cheers!

Dec. 13, 2010

Re: [Pharo-project] Issue 1042 in pharo: documentation/help menu

by pharo＠googlecode.com

Comment #5 on issue 1042 by tony.fleig: documentation/help menu http://code.google.com/p/pharo/issues/detail?id=1042 Ok. I will take the list below and for each shortcut determine whether it is working in Pharo 1.1.1 in Windows 7, OSX Snow Leopard, and Ubuntu Linux 9.10. I then post the results as a comment to this issue. I will attempt to do this by close of business tomorrow Pacific Time. FWIW, IMHO a list of maybe-working shortcuts with a warning that not all may be working is very much better than no list at all. (I speak from recent experience.) If we wait for perfection in all things we will never achieve anything. Here is the list I will work from. (I do not know what "Recognizer" refers to. The shortcut does nothing in my Ubuntu 9.10 Pharo 1.1 environment. Maybe you can help me there?) I have casually tested most of them in Pharo 1.1 Ubuntu Linux 9.10 and the majority seem to be fully functional. Lower-case command keys (use with Cmd key on Mac and Alt key on other platforms) a Select all b Browse it (selection is a class name or cursor is over a class-list or message-list) c Copy selection d Do it (selection is a valid expression) e Exchange selection with prior selection f Find g Find again h Set selection as search string for find again i Inspect it (selection is a valid expression, or selection is over an inspect-ilst) j Again once (do the last text-related operation again) k Set font l Cancel m Implementors of it (selection is a message selector or cursor is over a class-list or message-list) n Senders of it (selection is a message selector or cursor is over a class-list or message-list) o Spawn current method p Print it (selection is a valid expression) q Query symbol (toggle all possible completion for a given prefix) r Recognizer s Save (i.e. accept) t Finds a Transcript (when cursor is over the desktop) u Toggle alignment v Paste w Delete preceding word (over text); Close-window (over morphic desktop) x Cut selection y Swap characters z Undo Note: for Do it, Senders of it, etc., a null selection will be expanded to a word or to the current line in an attempt to do what you want. Also note that Senders/Implementors of it will find the outermost keyword selector in a large selection, as when you have selected a bracketed expression or an entire line. Finally note that the same cmd-m and cmd-n (and cmd-v for versions) work in the message pane of most browsers. Upper-case command keys (use with Shift-Cmd, or Ctrl on Mac or Shift-Alt on other platforms; sometimes Ctrl works too) A Advance argument B Browse it in this same browser (in System browsers only) C Compare argument to clipboard D Duplicate E Method strings containing it F Insert 'ifFalse:' G fileIn from it (a file name) H cursor TopHome: I Inspect via Object Explorer J Again many (apply the previous text command repeatedly until the end of the text) K Set style L Outdent (move selection one tab-stop left) M Select current type-in N References to it (selection is a class name, or cursor is over a class-list or message-list) O Open single-message browser (in message lists) P Make project link R Indent (move selection one tab-stap right) S Search T Insert 'ifTrue:' U Convert linefeeds to carriage returns in selection V Paste author's initials W Selectors containing it (in text); show-world-menu (when issued with cursor over desktop) X Force selection to lowercase Y Force selection to uppercase Z Capitalize all words in selection Other special keys Backspace Backward delete character Del Forward delete character Shift-Bksp Backward delete word Shift-Del Forward delete word Esc Pop up the Desktop Menu \ Send top window to back Cursor keys left, right, up, down Move cursor left, right, up or down Ctrl-left Move cursor left one word Ctrl-right Move cursor right one word Home Move cursor to begin of line or begin of text End Move cursor to end of line or end of text PgUp, Ctrl-up Move cursor up one page PgDown, Ctrl-Dn Move cursor down one page Note all these keys can be used together with Shift to define or enlarge the selection. You cannot however shrink that selection again, as in some other systems. Other Cmd-key combinations (not available on all platforms) Return Insert return followed by as many tabs as the previous line (with a further adjustment for additional brackets in that line) Space Select the current word as with double clicking Enclose the selection in a kind of bracket. Each is a toggle. (not available on all platforms) Ctrl-( Enclose within ( and ), or remove enclosing ( and ) Ctrl-[ Enclose within [ and ], or remove enclosing [ and ] Crtl-{ Enclose within { and }, or remove enclosing { and } Ctrl-< Enclose within < and >, or remove enclosing < and > Ctrl-' Enclose within ' and ', or remove enclosing ' and ' Ctrl-"" Enclose within "" and "", or remove enclosing "" and "" Note also that you can double-click just inside any of the above delimiters, or at the beginning or end of a line, to select the text enclosed. Text Emphasis (not available on all platforms) Cmd-1 10 point font Cmd-2 12 point font Cmd-3 18 point font Cmd-4 24 point font Cmd-5 36 point font Cmd-6 color, action-on-click, link to class comment, link to method, url Brings up a menu. To remove these properties, select more than the active part and then use command-0. Cmd-7 bold Cmd-8 italic Cmd-9 narrow (same as negative kern) Cmd-0 plain text (resets all emphasis) Cmd-- underlined (toggles it) Cmd-= struck out (toggles it) Shift-Cmd-- (aka :=) negative kern (letters 1 pixel closer) Shift-Cmd-+ positive kern (letters 1 pixel larger spread)

Dec. 12, 2010

Re: [Pharo-project] SmaCC

by Tudor Girba

Indeed, this was a mistake. It's fixed now. Cheers, Doru On 12 Dec 2010, at 03:42, Damien Pollet wrote: > On Tue, Jun 15, 2010 at 13:43, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> If you want to load PetitParser with all required >> dependencies you do it via this script: >> >> Gofer new >> renggli: 'petit'; >> package: 'ConfigurationOfPetitParser'; >> load. >> (Smalltalk at: #ConfigurationOfPetitParser) perform: #loadDefault. > > â¦ but loadDefault does not load anything! Shouldn't it rather be like > in ConfigurationOfPetitParser-tg.6 ? > > loadDefault > (self project version: 'default') load > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Dec. 12, 2010

[Pharo-project] Redline: Smalltalk in 'small talks' ...

by Sven Van Caekenberghe

On 12 Dec 2010, at 04:08, James Ladd wrote: > The series of posts on implementing Redline Smalltalk for the Java Virtual Machine has begun. > You can code along and influence the direction of Redline. > > http://blog.redline.st/2010/12/12/redline-smalltalk-in-%E2%80%9Csmall-talks… > > Rgs, James. I will be reading too. Sven

Dec. 12, 2010