Re: [Pharo-project] Vim Keys?
Le 29/11/2012 20:52, ☈king a écrit : Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! —☈ It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. Bad point: I should help with that effort, but given my deadlines for the end of the year, not sure I'll be of much help :(. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-project] [Issue Tracker] Reviews Needed...
There are ready to integrate issues that need to be looked at: http://code.google.com/p/pharo/issues/list?can=2q=milestone=2.0%20status=HumanReviewNeeded http://code.google.com/p/pharo/issues/list?can=2q=milestone%3D2.0+status%3AFixReviewNeeded - Does it make sense? - is the code loadable? - does it what it is supposed to to? Marcus
Re: [Pharo-project] just help :)
My bad I thought it was for bytecode too, my memory played tricks to me. http://rmod.lille.inria.fr/web/pier/software/Fuel From: Marcus Denker marcus.den...@inria.fr To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis theki...@yahoo.co.uk Sent: Friday, 30 November 2012, 9:32 Subject: Re: [Pharo-project] just help :) On Nov 29, 2012, at 11:55 PM, dimitris chloupis theki...@yahoo.co.uk wrote: * Framework for seamless data/object-synchronization. I suggested this a while ago, didn't get much response. I don't blame anyone, there is not much need for this right now. What I would want is to be able to modify certain objects in my image, while offline, and connect to the Internet, and these objects be synchronized between other images. This way Internet-enabled apps could be built on top of Pharo in a better way that web-apps are built now (because, in Pharo you can not hit F5 and get fresh data ;-). But this is low-priority for me. This is a hard problem… but if would be nice to have, yes. There is also Fuel which is a already very well known Pharo library again for serializing bytecode. No, Fuel can serialize *any* objects. byte codes are not that hard to serialize, as they are actually already a serialized representation of the AST... Marcus
Re: [Pharo-project] Vim Keys?
When we are at it... how do shortcuts in Pharo 2 currently work? In Pharo 1.4, in the class browser, I used to hit Ctrl-F to open Find Class, but it has no effect in Pharo 2. 2012/11/30 Goubier Thierry thierry.goub...@cea.fr: Le 29/11/2012 20:52, ☈king a écrit : Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! —☈ It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. Bad point: I should help with that effort, but given my deadlines for the end of the year, not sure I'll be of much help :(. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-project] just help :)
2012/11/30 Marcus Denker marcus.den...@inria.fr: On Nov 29, 2012, at 11:55 PM, dimitris chloupis theki...@yahoo.co.uk wrote: * Framework for seamless data/object-synchronization. I suggested this a while ago, didn't get much response. I don't blame anyone, there is not much need for this right now. What I would want is to be able to modify certain objects in my image, while offline, and connect to the Internet, and these objects be synchronized between other images. This way Internet-enabled apps could be built on top of Pharo in a better way that web-apps are built now (because, in Pharo you can not hit F5 and get fresh data ;-). But this is low-priority for me. This is a hard problem… but if would be nice to have, yes. I think it would make a nice research project ;-) Maybe as an extension(*) to Fuel/Tanker? I guess Fuel/Tanker also has to deal with conflicts, right? * - Extension or on-top-of
Re: [Pharo-project] Vim Keys?
Le 30/11/2012 09:57, Sebastian Nozzi a écrit : When we are at it... how do shortcuts in Pharo 2 currently work? Ouch. I can describe what I know about key event processing, and maybe you will understand what's happening. It will be a good exercise for me to see if I got that stuff right. From first to process to last to process, once the key event is generated and given to the Morph which has the focus: 1 - The morph keymapping dispatch. This one is multilevel in nature. Here, so it goes (simplified, I'm not listing where platform differences are taken in account). The key event is matched against shortcuts defined in keymaps (and a partial match is possible if it is a multi-key shortcut). 1.1 - Direct keymapping : shortcuts added by on: do: to the KMDispatcher of the Morph instance. 1.2 - Named keymaps. Keymaps defined elsewhere and attached to that morph keymap dispatcher. 1.3 - Global named keymaps. Keymaps associated with the morph Class or one of it's superclass (i.e. a Morph class global keymap will apply to all morphs). 1.4 - If no match, go to 1.1 with the owner of the morph and repeat. Do that until you reach the World (Pharo top-level window). There, if keymapping hasn't matched, go to 2. 2 - The morph keyStroke: handling. Normal keys, navigation keys, hardcoded shortcuts (TextMorph for example). -- In some cases (some! No, often :(!) keystrokes are sent to other objects or Morphs: navigation, shortcuts, etc... 3 - The morph eventHandler : here a model can trap any key event or shortcut. If a match happen in any of those, the key event is usually said to be processed and we go out of the processing loop (no more matches) So, for a given shortcut being processed, it may be hard to find where it has been caught. Only the Keymapping dispatch has a debugging feature (with KMLog). In Pharo 1.4, in the class browser, I used to hit Ctrl-F to open Find Class, but it has no effect in Pharo 2. This one is easier. In Nautilus, there is a shortcut browser which lists all the defined shortcuts. I believe that the find class is a multi-key shortcut. 2012/11/30 Goubier Thierry thierry.goub...@cea.fr: Le 29/11/2012 20:52, ☈king a écrit : Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! —☈ It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. Bad point: I should help with that effort, but given my deadlines for the end of the year, not sure I'll be of much help :(. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-project] [update 2.0] #20423
20423 - Issue 7072: Better pop up menu entries aligned with http://code.google.com/p/pharo/issues/detail?id=7072 Issue 7071: Fixing ManifestBrowser http://code.google.com/p/pharo/issues/detail?id=7071 Diff information: http://ss3.gemstone.com/ss/Pharo20/Manifest-CriticBrowser-MarcusDenker.29.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.364.diff
Re: [Pharo-project] just help :)
On Nov 30, 2012, at 9:53 AM, dimitris chloupis theki...@yahoo.co.uk wrote: My bad I thought it was for bytecode too, my memory played tricks to me. http://rmod.lille.inria.fr/web/pier/software/Fuel Yes, CompiledMethods and Classes even… Marcus
Re: [Pharo-project] just help :)
On Nov 30, 2012, at 10:07 AM, Sebastian Nozzi sebno...@gmail.com wrote: 2012/11/30 Marcus Denker marcus.den...@inria.fr: On Nov 29, 2012, at 11:55 PM, dimitris chloupis theki...@yahoo.co.uk wrote: * Framework for seamless data/object-synchronization. I suggested this a while ago, didn't get much response. I don't blame anyone, there is not much need for this right now. What I would want is to be able to modify certain objects in my image, while offline, and connect to the Internet, and these objects be synchronized between other images. This way Internet-enabled apps could be built on top of Pharo in a better way that web-apps are built now (because, in Pharo you can not hit F5 and get fresh data ;-). But this is low-priority for me. This is a hard problem… but if would be nice to have, yes. I think it would make a nice research project ;-) Yes. Marcus
Re: [Pharo-project] [ann] glamorous debugger (alpha)
Hi Doru, that's great news and another sign that Glamour is very powerful. How hard would it be to show the values for the current expression in the list of variables? For example, while debugging the line self doSomething: (value at: 1) with: aStream next I would see in the list of variables the values for the expressions: value at: 1 aStream next On Sun, Nov 25, 2012 at 9:42 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: No so far only for 1.4 Stef On Nov 25, 2012, at 1:48 AM, Camillo Bruni wrote: If you are interested in playing with it, you can either find it in the Moose image, or you can load it in Pharo 1.4 via: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) loadDevelopment is it supposed to load under 2.0? I get an issue with ConfigurationOfRPackage.. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-project] Vim Keys?
On Nov 30, 2012, at 10:25 AM, Goubier Thierry wrote: Le 30/11/2012 09:57, Sebastian Nozzi a écrit : When we are at it... how do shortcuts in Pharo 2 currently work? Ouch. I can describe what I know about key event processing, and maybe you will understand what's happening. It will be a good exercise for me to see if I got that stuff right. From first to process to last to process, once the key event is generated and given to the Morph which has the focus: 1 - The morph keymapping dispatch. This one is multilevel in nature. Here, so it goes (simplified, I'm not listing where platform differences are taken in account). The key event is matched against shortcuts defined in keymaps (and a partial match is possible if it is a multi-key shortcut). 1.1 - Direct keymapping : shortcuts added by on: do: to the KMDispatcher of the Morph instance. 1.2 - Named keymaps. Keymaps defined elsewhere and attached to that morph keymap dispatcher. 1.3 - Global named keymaps. Keymaps associated with the morph Class or one of it's superclass (i.e. a Morph class global keymap will apply to all morphs). 1.4 - If no match, go to 1.1 with the owner of the morph and repeat. Do that until you reach the World (Pharo top-level window). There, if keymapping hasn't matched, go to 2. 2 - The morph keyStroke: handling. Normal keys, navigation keys, hardcoded shortcuts (TextMorph for example). -- In some cases (some! No, often :(!) keystrokes are sent to other objects or Morphs: navigation, shortcuts, etc... 3 - The morph eventHandler : here a model can trap any key event or shortcut. If a match happen in any of those, the key event is usually said to be processed and we go out of the processing loop (no more matches) So, for a given shortcut being processed, it may be hard to find where it has been caught. Only the Keymapping dispatch has a debugging feature (with KMLog). In Pharo 1.4, in the class browser, I used to hit Ctrl-F to open Find Class, but it has no effect in Pharo 2. This one is easier. In Nautilus, there is a shortcut browser which lists all the defined shortcuts. I believe that the find class is a multi-key shortcut. Indeed , cmd+f,c Ben :) 2012/11/30 Goubier Thierry thierry.goub...@cea.fr: Le 29/11/2012 20:52, ☈king a écrit : Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! —☈ It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. Bad point: I should help with that effort, but given my deadlines for the end of the year, not sure I'll be of much help :(. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-project] Indent code
When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). Is this a bug or just handled differently? Thx T.
Re: [Pharo-project] Indent code
on mac: ctrl+alt+r / l On 30.11.2012, at 12:49, Torsten Bergmann asta...@gmx.de wrote: When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). Is this a bug or just handled differently? Thx T.
Re: [Pharo-project] Indent code
When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). I also expected that. Would be cool if this was the default behavior. on mac: ctrl+alt+r / l This makes sense from a language perspective (right/left), but note that not only you have to press more keys, but also is more tedious if you are adjusting the indentation. With this I mean if you want to quickly do left/right operations after another.
Re: [Pharo-project] Vim Keys?
Thanks for the whole information! Actually I just wanted to know the key-combination (I expressed myself wrong), but will keep this info for future reference. 2012/11/30 Benjamin benjamin.vanryseghem.ph...@gmail.com: On Nov 30, 2012, at 10:25 AM, Goubier Thierry wrote: Le 30/11/2012 09:57, Sebastian Nozzi a écrit : When we are at it... how do shortcuts in Pharo 2 currently work? Ouch. I can describe what I know about key event processing, and maybe you will understand what's happening. It will be a good exercise for me to see if I got that stuff right. From first to process to last to process, once the key event is generated and given to the Morph which has the focus: 1 - The morph keymapping dispatch. This one is multilevel in nature. Here, so it goes (simplified, I'm not listing where platform differences are taken in account). The key event is matched against shortcuts defined in keymaps (and a partial match is possible if it is a multi-key shortcut). 1.1 - Direct keymapping : shortcuts added by on: do: to the KMDispatcher of the Morph instance. 1.2 - Named keymaps. Keymaps defined elsewhere and attached to that morph keymap dispatcher. 1.3 - Global named keymaps. Keymaps associated with the morph Class or one of it's superclass (i.e. a Morph class global keymap will apply to all morphs). 1.4 - If no match, go to 1.1 with the owner of the morph and repeat. Do that until you reach the World (Pharo top-level window). There, if keymapping hasn't matched, go to 2. 2 - The morph keyStroke: handling. Normal keys, navigation keys, hardcoded shortcuts (TextMorph for example). -- In some cases (some! No, often :(!) keystrokes are sent to other objects or Morphs: navigation, shortcuts, etc... 3 - The morph eventHandler : here a model can trap any key event or shortcut. If a match happen in any of those, the key event is usually said to be processed and we go out of the processing loop (no more matches) So, for a given shortcut being processed, it may be hard to find where it has been caught. Only the Keymapping dispatch has a debugging feature (with KMLog). In Pharo 1.4, in the class browser, I used to hit Ctrl-F to open Find Class, but it has no effect in Pharo 2. This one is easier. In Nautilus, there is a shortcut browser which lists all the defined shortcuts. I believe that the find class is a multi-key shortcut. Indeed , cmd+f,c Ben :) 2012/11/30 Goubier Thierry thierry.goub...@cea.fr: Le 29/11/2012 20:52, ☈king a écrit : Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! —☈ It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. Bad point: I should help with that effort, but given my deadlines for the end of the year, not sure I'll be of much help :(. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-project] Indent code
On 30.11.2012, at 13:28, Sebastian Nozzi sebno...@gmail.com wrote: When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). I also expected that. Would be cool if this was the default behavior. on mac: ctrl+alt+r / l This makes sense from a language perspective (right/left), but note that not only you have to press more keys, but also is more tedious if you are adjusting the indentation. With this I mean if you want to quickly do left/right operations after another. I didn't say it's good, just how it currently works :) +1 for better shortcuts (but checkout the currently active Vim Keys? thread for that) Max
Re: [Pharo-project] Indent code
on Linux and Windows alt/ctrl + r On 30 November 2012 08:51, Max Leske maxle...@gmail.com wrote: on mac: ctrl+alt+r / l On 30.11.2012, at 12:49, Torsten Bergmann asta...@gmx.de wrote: When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). Is this a bug or just handled differently? Thx T.
Re: [Pharo-project] [ann] glamorous debugger (alpha)
Thanks :). This should not be difficult, and it's a nice idea. Next week, Andrei will be visiting Lille, so perhaps this would be a good opportunity to play with things :). Cheers, Doru On Fri, Nov 30, 2012 at 12:36 PM, Damien Cassou damien.cas...@gmail.comwrote: Hi Doru, that's great news and another sign that Glamour is very powerful. How hard would it be to show the values for the current expression in the list of variables? For example, while debugging the line self doSomething: (value at: 1) with: aStream next I would see in the list of variables the values for the expressions: value at: 1 aStream next On Sun, Nov 25, 2012 at 9:42 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: No so far only for 1.4 Stef On Nov 25, 2012, at 1:48 AM, Camillo Bruni wrote: If you are interested in playing with it, you can either find it in the Moose image, or you can load it in Pharo 1.4 via: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) loadDevelopment is it supposed to load under 2.0? I get an issue with ConfigurationOfRPackage.. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-project] [ann] glamorous debugger (alpha)
Tudor Girba-2 wrote Thanks :). This should not be difficult, and it's a nice idea. Next week, Andrei will be visiting Lille, so perhaps this would be a good opportunity to play with things :). Dolphin does something like that, showing in the debugger a list of all the objects in call/return stack with pseudonames like _stack1 _stack2 _stack3, etc. It is really helpful to see what is going to be passed to a method or what was its response. Regards! -- Esteban. -- View this message in context: http://forum.world.st/ann-glamorous-debugger-alpha-tp4656643p4657433.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] About ArrayedCollection and at:/put:
It says: I am an abstract collection of elements with a fixed range of integers (from 1 to n=0) as external keys. now that leaves me clueless, why then it does not defines (introduces) a protocol: #at: and #at:put: at least as an abstract one , i.e. subclassResponsibility is it because they are already in Object protocol? And because subclasses (like Array) using default #at: implementation? I don't know, but i think Object should not have #at:/#at:put: protocol.. because: - it applicable only to variable subclasses - many classes have own implementation of it - the behavior behind this is to access a variable fields . while other classes use this protocol for higher abstractions (like dictionaries) so, to my thinking, Object should not define this protocol.. for this purpose we having #basicAt:/put: methods. btw, just an idea to clarify things even more, we could rename them to variableAt: [put:] (or any other name which properly tells that method provides an access to variable fields of object). -- Best regards, Igor Stasenko.
Re: [Pharo-project] [ann] glamorous debugger (alpha)
On Fri, Nov 30, 2012 at 3:12 PM, Esteban A. Maringolo emaring...@gmail.comwrote: It is really helpful to see what is going to be passed to a method or what was its response. yes, I should have added the following to the list of expressions I want to see a value for: self doSomething: (value at: 1) with: aStream next -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-project] Indent code
On my Mac ctrl-alt l/r produced @ and ® respectively (MBA 2011, german keyboard). 2012/11/30 Max Leske maxle...@gmail.com: on mac: ctrl+alt+r / l On 30.11.2012, at 12:49, Torsten Bergmann asta...@gmx.de wrote: When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). Is this a bug or just handled differently? Thx T.
Re: [Pharo-project] Indent code
it's actually cmd+shift+r/l Ben On Nov 30, 2012, at 4:04 PM, Sebastian Nozzi wrote: On my Mac ctrl-alt l/r produced @ and ® respectively (MBA 2011, german keyboard). 2012/11/30 Max Leske maxle...@gmail.com: on mac: ctrl+alt+r / l On 30.11.2012, at 12:49, Torsten Bergmann asta...@gmx.de wrote: When I select a few lines of text in Pharo 2.0 code editor and hit TAB it is not indented as in other IDE's. Instead it is deleted similar to when one hits space key. Usually TAB in IDE code editors is used to indent a selected block of text and SHIFT+TAB is used for the reverse (outdent). Is this a bug or just handled differently? Thx T.
Re: [Pharo-project] Indent code
Yep. Thank you! 2012/11/30 Benjamin benjamin.vanryseghem.ph...@gmail.com: it's actually cmd+shift+r/l Ben On Nov 30, 2012, at 4:04 PM, Sebastian Nozzi wrote: On my Mac ctrl-alt l/r produced @ and ® respectively (MBA 2011, german keyboard).
Re: [Pharo-project] Vim Keys?
There is a package (for an ancester of Pharo) that added VIM keys (and Emacs, apparently) to the editors at: http://www.squeaksource.com/SVI.html You may be able to load this in and it will work, or the code may have drifted quite a bit to the point where it just doesn't work anymore. I have not tried using it for years, myself. -Chris On Thu, Nov 29, 2012 at 11:52 AM, ☈king rkingd...@sharpsaw.org wrote: Hi all. I'm extremely new to Smalltalk, but I was wondering if there was a way to make Pharo have vi-keys (or even better, vim-keys)? Thanks! —☈
[Pharo-project] [update 2.0] #20424
20424 - Issue 7078: Do not hard code Browser in Hudson Build Tools http://code.google.com/p/pharo/issues/detail?id=7078 Issue 7073: Inconsistent System Browser selection http://code.google.com/p/pharo/issues/detail?id=7073 Issue 6928: Obsolete class after running all tests http://code.google.com/p/pharo/issues/detail?id=6928 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.993.diff http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.485.diff http://ss3.gemstone.com/ss/Pharo20/System-Tools-MarcusDenker.91.diff http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-MarcusDenker.12.diff
Re: [Pharo-project] Vim Keys?
On 11/30/2012 02:15 AM, Goubier Thierry wrote: It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. I have a radical question that I'd like to float. What about making vi keys not only possible, but the *default* for Pharo? They generally don't conflict with anything, because they're all Namespaced under sequences that you hit Escape for. This means you could continue to edit exactly as you do, but when you hit Esc you get some bonus functionality. And just because vi keys are the most hardcore interface ever of all time, that doesn't mean it has to be for neckbeards-only. We could make it so the text box has a status indicator, with help available and everything. Imagine a bar at the bottom that says, Vi Command Mode, which can be clicked for a full help, then the rest of the bar has hints about common commands. It could even be adaptive, like learn to tell you commands that you haven't used much. The same bar could also say Stop this crazy feature I don't like it. —☈
Re: [Pharo-project] Vim Keys?
On Nov 30, 2012, at 5:41 PM, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 02:15 AM, Goubier Thierry wrote: It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. I have a radical question that I'd like to float. What about making vi keys not only possible, but the *default* for Pharo? I am sure the Emacs user will be violently against it. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? (and no, I am not a vi user. I know one vi command and that is esc : q ! to get out of there…) Marcus
[Pharo-project] CogVM crash code
Hi all, I don't post to lists often, but I thought some of you might be interested in these few lines of code that crash the CogVM on both Linux and Windows. File-in the Smalltalk code below, then evaluate [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or [56+98]. I put the code on nil, but that is not important either. I think the important thing is that the primitive (+ or -) is evaluated but the result is not assigned into any variable. Also important is that the code is put into a loop that I assume has been JIT optimized. The image I used is Pharo 1.4 one-click with latest update #14459. This code does not crash StackVM. Have fun! - Jon. !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM Evaluate [ nil crashCogVM ] | i | i := 20. 1 to: i do: [:d | 1-1 ] ! !
[Pharo-project] Trying Athens
I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB signature.asc Description: OpenPGP digital signature
Re: [Pharo-project] Vim Keys?
On 11/30/2012 10:48 AM, Marcus Denker wrote: I am sure the Emacs user will be violently against it. Actually, that's the thing: Namespacing. You could install vi keys on emacs and an emacs user would never notice without hitting the Escape key. Emacs keys, on the other hand, *do* conflict with existing Pharo bindings. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? Think of modes as a monkey that sits by your keyboard. Every time you bop him on the head (that is, you hit Escape), he obediently reaches over and holds down a special keyboard modifier for you, and continues to do so until you tell him to stop. Since bopping him on the head takes no more time than hitting the modifier key itself, hitting [Bop],[Key] is always going to be an equally concise way of entering a string of commands compared to chording [Modifier+Key]. But generally it's more concise, because you tend to do big sequences of one or the other: edit a bunch, or input a bunch. That is, in real life you do [Bop],[Key],[Key2],[Key],[Key3], which is better than [Modifier1+Key],[Modifier2+Key2],[Modifier1+Key],[Ctrl+Alt+Shift+Modifier+TurboDrive+Footpedal+☝+Key3] The critical point is that users that don't enter command mode would never be bothered by it. Users who do stumble upon it could get an additional leg up with the help text, and they don't even really have to know it's Vi Keys, just that it's a non-chorded interface. I know it's radical, but that's how we roll. (Right?) —☈
Re: [Pharo-project] Trying Athens
most probably https://code.google.com/p/pharo/issues/detail?id=6986 are you behind a proxy? On 2012-11-30, at 14:13, Casimiro de Almeida Barreto casimiro.barr...@gmail.com wrote: I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB
Re: [Pharo-project] CogVM crash code
uuh nasty :), also happens under 2.0 ;) could you open an issue on the cog issue tracker with the contents of this email? https://code.google.com/p/cog/issues/list thanks On 2012-11-30, at 14:07, Jon Anderson jonkander...@gmail.com wrote: Hi all, I don't post to lists often, but I thought some of you might be interested in these few lines of code that crash the CogVM on both Linux and Windows. File-in the Smalltalk code below, then evaluate [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or [56+98]. I put the code on nil, but that is not important either. I think the important thing is that the primitive (+ or -) is evaluated but the result is not assigned into any variable. Also important is that the code is put into a loop that I assume has been JIT optimized. The image I used is Pharo 1.4 one-click with latest update #14459. This code does not crash StackVM. Have fun! - Jon. !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM Evaluate [ nil crashCogVM ] | i | i := 20. 1 to: i do: [:d | 1-1 ] ! !
Re: [Pharo-project] Trying Athens
On 30-11-2012 15:24, Camillo Bruni wrote: most probably https://code.google.com/p/pharo/issues/detail?id=6986 are you behind a proxy? Yes, seems to be the problem just as reported in issues #6986 On 2012-11-30, at 14:13, Casimiro de Almeida Barreto casimiro.barr...@gmail.com wrote: I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB signature.asc Description: OpenPGP digital signature
Re: [Pharo-project] CogVM crash code
On 30 November 2012 18:27, Camillo Bruni camillobr...@gmail.com wrote: uuh nasty :), also happens under 2.0 ;) huh... unbelievable.. how such simple piece of code can do any harm? :) could you open an issue on the cog issue tracker with the contents of this email? https://code.google.com/p/cog/issues/list thanks On 2012-11-30, at 14:07, Jon Anderson jonkander...@gmail.com wrote: Hi all, I don't post to lists often, but I thought some of you might be interested in these few lines of code that crash the CogVM on both Linux and Windows. File-in the Smalltalk code below, then evaluate [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or [56+98]. I put the code on nil, but that is not important either. I think the important thing is that the primitive (+ or -) is evaluated but the result is not assigned into any variable. Also important is that the code is put into a loop that I assume has been JIT optimized. The image I used is Pharo 1.4 one-click with latest update #14459. This code does not crash StackVM. Have fun! - Jon. !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM Evaluate [ nil crashCogVM ] | i | i := 20. 1 to: i do: [:d | 1-1 ] ! ! -- Best regards, Igor Stasenko.
Re: [Pharo-project] Vim Keys?
On 30 November 2012 17:48, Marcus Denker marcus.den...@inria.fr wrote: On Nov 30, 2012, at 5:41 PM, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 02:15 AM, Goubier Thierry wrote: It's underway. The infrastructure is moving to a better (unified) way of specifying and handling shortcuts, and then vi and vim-keys and emacs and others should become available. I have a radical question that I'd like to float. What about making vi keys not only possible, but the *default* for Pharo? I am sure the Emacs user will be violently against it. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? (and no, I am not a vi user. I know one vi command and that is esc : q ! to get out of there…) i know a bit more. but that's my favorite :) as to me, it is ok if pharo could have key bindings for anything, as long as it does not interfere with my workflow and does not forcing me to do it right way. Marcus -- Best regards, Igor Stasenko.
Re: [Pharo-project] Trying Athens
interesting :) can you figure out your proxy configuration? this is very strange :P On 2012-11-30, at 14:33, Casimiro de Almeida Barreto casimiro.barr...@gmail.com wrote: On 30-11-2012 15:24, Camillo Bruni wrote: most probably https://code.google.com/p/pharo/issues/detail?id=6986 are you behind a proxy? Yes, seems to be the problem just as reported in issues #6986 On 2012-11-30, at 14:13, Casimiro de Almeida Barreto casimiro.barr...@gmail.com wrote: I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB
Re: [Pharo-project] Vim Keys?
On 30 November 2012 18:23, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 10:48 AM, Marcus Denker wrote: I am sure the Emacs user will be violently against it. Actually, that's the thing: Namespacing. You could install vi keys on emacs and an emacs user would never notice without hitting the Escape key. Emacs keys, on the other hand, *do* conflict with existing Pharo bindings. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? Think of modes as a monkey that sits by your keyboard. Every time you bop him on the head (that is, you hit Escape), he obediently reaches over and holds down a special keyboard modifier for you, and continues to do so until you tell him to stop. Since bopping him on the head takes no more time than hitting the modifier key itself, hitting [Bop],[Key] is always going to be an equally concise way of entering a string of commands compared to chording [Modifier+Key]. But generally it's more concise, because you tend to do big sequences of one or the other: edit a bunch, or input a bunch. That is, in real life you do [Bop],[Key],[Key2],[Key],[Key3], which is better than [Modifier1+Key],[Modifier2+Key2],[Modifier1+Key],[Ctrl+Alt+Shift+Modifier+TurboDrive+Footpedal+☝+Key3] well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black white color scheme, 80x25 text mode ;) ) etc.. i think, if vi would contest for best obscure editor, i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Also, i going to repeat same over again: we don't need a full-fledged text editor(s) in smalltalk IDE. In smalltalk you will find yourself rarely need to edit more than 10 lines of code at time. From that perspective, do you think it is wise to invest people's energy into that? I think it should be a call for those who miss it: if you want it - make it. After all, you can run vi/emacs/put your favorite in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. Sorry, maybe i miss something and don't see full picture, but i really don't understand what is so cool in having vi/emacs shortcuts in pharo.. The critical point is that users that don't enter command mode would never be bothered by it. Users who do stumble upon it could get an additional leg up with the help text, and they don't even really have to know it's Vi Keys, just that it's a non-chorded interface. I know it's radical, but that's how we roll. (Right?) —☈ -- Best regards, Igor Stasenko.
Re: [Pharo-project] Trying Athens
On 30-11-2012 16:00, Camillo Bruni wrote: interesting :) can you figure out your proxy configuration? this is very strange :P Proxy Test This request appears to have come via a proxy. The proxy host is *ex1.lsi.usp.br* which has ip address 143.107.161.170 The proxy server has announced itself as *1.1 gate.lsi.usp.br (squid/3.0.STABLE18)* The proxy informs us that the client host ip address was 10.0.164.156 The Lagado http://www.lagado.com/ Proxy Test shows details of any proxy servers you are using. It is especially useful to expose transparent proxies. These are proxies inserted between your browser and the web, typically by your ISP, and often without you knowing. Sometimes a proxy will be deliberately hidden so it won't be exposed by this test. In this case you can use the Cache Test http://www.lagado.com/tools/cache-test to expose stealthed transparent proxy caches. The Raw Details Here are the raw details of the request received by this server. *Remote Host* ex1.lsi.usp.br *IP Address* 143.107.161.170 *Request Protocol* HTTP/1.0 *Method* GET *Request Headers* *Host* www.lagado.com *User-Agent*Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.91 Safari/537.11 *Accept*text/html,application/xhtml+xml,application/xml;q=0.9, */*;q=0.8 *Referer* http://www.lagado.com/text/tools_b7f5.htm *Accept-Encoding* gzip,deflate,sdch *Accept-Language* pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 *Accept-Charset*ISO-8859-1,utf-8;q=0.7,*;q=0.3 *Via* 1.1 gate.lsi.usp.br (squid/3.0.STABLE18) *X-Forwarded-For* 10.0.164.156 *Cache-Control* max-age=259200 *Connection*keep-alive *This Server Host* www.lagado.com *IP Address* 210.50.6.232 *Date:* Saturday 1 Dec 2012 5:31:44 GMT+1100 On 2012-11-30, at 14:33, Casimiro de Almeida Barreto casimiro.barr...@gmail.com wrote: On 30-11-2012 15:24, Camillo Bruni wrote: most probably https://code.google.com/p/pharo/issues/detail?id=6986 are you behind a proxy? Yes, seems to be the problem just as reported in issues #6986 On 2012-11-30, at 14:13, Casimiro de Almeida Barreto casimiro.barr...@gmail.com wrote: I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB signature.asc Description: OpenPGP digital signature
Re: [Pharo-project] Vim Keys?
Even though I agree with your Igor , text editing is not per se required by existing smalltalk users, though even that is debatable, introducing vim and emacs mapping, in a completely optional state, will be definitely a motivation for vim and emacs user to join pharo. For example if you enter the pharo channel in irc you will be happy to find one person talking to himself, squeak channel more or less the same. Both #emacs and #vim show how popular both of these text editors are, why not pharo attract that crowd. Let me throw a crazy idea on the table why smalltalk cannot be a more ultimate text editor than those. Sure its ton of work and definetly you or I should not do , but I am sure if we provide minimum means of people to do this we will see more and more people porting vim and emacs features to pharo. Also your point that we dont need text editing that much in pharo , is vaild from one side, however you should not forget that even though vim and emacs might appear radically diffirent from pharo those diffirences are skin deep. All of them have IDE tools , code navigation tools, debuging tools etc ... so I am not that convinced that for example using system browsers via shortcuts cannot be improved. I am actually in the process of learning elisp code to port some of the features of emacs to pharo. From: Igor Stasenko siguc...@gmail.com To: Pharo-project@lists.gforge.inria.fr Sent: Friday, 30 November 2012, 20:13 Subject: Re: [Pharo-project] Vim Keys? On 30 November 2012 18:23, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 10:48 AM, Marcus Denker wrote: I am sure the Emacs user will be violently against it. Actually, that's the thing: Namespacing. You could install vi keys on emacs and an emacs user would never notice without hitting the Escape key. Emacs keys, on the other hand, *do* conflict with existing Pharo bindings. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? Think of modes as a monkey that sits by your keyboard. Every time you bop him on the head (that is, you hit Escape), he obediently reaches over and holds down a special keyboard modifier for you, and continues to do so until you tell him to stop. Since bopping him on the head takes no more time than hitting the modifier key itself, hitting [Bop],[Key] is always going to be an equally concise way of entering a string of commands compared to chording [Modifier+Key]. But generally it's more concise, because you tend to do big sequences of one or the other: edit a bunch, or input a bunch. That is, in real life you do [Bop],[Key],[Key2],[Key],[Key3], which is better than [Modifier1+Key],[Modifier2+Key2],[Modifier1+Key],[Ctrl+Alt+Shift+Modifier+TurboDrive+Footpedal+☝+Key3] well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black white color scheme, 80x25 text mode ;) ) etc.. i think, if vi would contest for best obscure editor, i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Also, i going to repeat same over again: we don't need a full-fledged text editor(s) in smalltalk IDE. In smalltalk you will find yourself rarely need to edit more than 10 lines of code at time. From that perspective, do you think it is wise to invest people's energy into that? I think it should be a call for those who miss it: if you want it - make it. After all, you can run vi/emacs/put your favorite in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. Sorry, maybe i miss something and don't see full picture, but i really don't understand what is so cool in having vi/emacs shortcuts in pharo.. The critical point is that users that don't enter command mode would never be bothered by it. Users who do stumble upon it could get an additional leg up with the help text, and they don't even really have to know it's Vi Keys, just that it's a non-chorded interface. I know it's radical, but that's how we roll. (Right?) —☈ -- Best regards, Igor Stasenko.
Re: [Pharo-project] Vim Keys?
+1 -- Cheers, Peter. On 30 nov 2012, at 19:13, Igor Stasenko siguc...@gmail.com wrote: On 30 November 2012 18:23, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 10:48 AM, Marcus Denker wrote: I am sure the Emacs user will be violently against it. Actually, that's the thing: Namespacing. You could install vi keys on emacs and an emacs user would never notice without hitting the Escape key. Emacs keys, on the other hand, *do* conflict with existing Pharo bindings. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? Think of modes as a monkey that sits by your keyboard. Every time you bop him on the head (that is, you hit Escape), he obediently reaches over and holds down a special keyboard modifier for you, and continues to do so until you tell him to stop. Since bopping him on the head takes no more time than hitting the modifier key itself, hitting [Bop],[Key] is always going to be an equally concise way of entering a string of commands compared to chording [Modifier+Key]. But generally it's more concise, because you tend to do big sequences of one or the other: edit a bunch, or input a bunch. That is, in real life you do [Bop],[Key],[Key2],[Key],[Key3], which is better than [Modifier1+Key],[Modifier2+Key2],[Modifier1+Key],[Ctrl+Alt+Shift+Modifier+TurboDrive+Footpedal+☝+Key3] well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black white color scheme, 80x25 text mode ;) ) etc.. i think, if vi would contest for best obscure editor, i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Also, i going to repeat same over again: we don't need a full-fledged text editor(s) in smalltalk IDE. In smalltalk you will find yourself rarely need to edit more than 10 lines of code at time. From that perspective, do you think it is wise to invest people's energy into that? I think it should be a call for those who miss it: if you want it - make it. After all, you can run vi/emacs/put your favorite in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. Sorry, maybe i miss something and don't see full picture, but i really don't understand what is so cool in having vi/emacs shortcuts in pharo.. The critical point is that users that don't enter command mode would never be bothered by it. Users who do stumble upon it could get an additional leg up with the help text, and they don't even really have to know it's Vi Keys, just that it's a non-chorded interface. I know it's radical, but that's how we roll. (Right?) —☈ -- Best regards, Igor Stasenko.
Re: [Pharo-project] CogVM crash code
thanks, Jon. Good one! On Fri, Nov 30, 2012 at 9:07 AM, Jon Anderson jonkander...@gmail.comwrote: !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM Evaluate [ nil crashCogVM ] | i | i := 20. 1 to: i do: [:d | 1-1 ] ! ! -- best, Eliot
[Pharo-project] Redline Smalltalk on heroku ....
Redline Smalltalk is easily deployed to Heroku, a cloud service. So writing web apps in Smalltalk and deploying them to the could just got a whole let easier. https://stout.herokuapp.com/ Please support the Redline project here: http://www.indiegogo.com/smalltalk/x/1366536 YES - We are providing classes to make deploying Pharo app to Redline a snap. Heroku work was done by Will Leinweber His github repo has the project and code.
Re: [Pharo-project] Vim Keys?
On 11/30/2012 01:25 PM, dimitris chloupis wrote: Both #emacs and #vim show how popular both of these text editors are, why not pharo attract that crowd. Another part of this is just making UIs for editing non-Smalltalk code. If I had a good editor widget available, I could use it to make any number of powerful other tools. —☈
Re: [Pharo-project] Vim Keys?
On 11/30/2012 12:13 PM, Igor Stasenko wrote: well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black white color scheme, 80x25 text mode ;) ) etc.. I know you're joking, but limiting one's self to 80 columns is generally a good way to maximize screen space. Step back and look at code that runs with really long lines, and you'll see a vast emptiness on most lines. i think, if vi would contest for best obscure editor, i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. Monkey-bopping not a compelling argument? I mean, the goal is to make a fluid interface. The subtitle of one of the vim books is Edit at the Speed of Thought. That's the key thing. When I'm coding with vi keys, the text just goes where I want it, and quickly, with very little stopping to think about it. What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Possibly. I'll think about that. After all, you can run vi/emacs/put your favorite in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. This is something that Pentadactyl (a amazing Firefox plugin that makes the browser vim-like) does. You can hit Ctrl+i on any text field, and it pops up a gvim window with that text. Perhaps something like this is sufficient. We'll see. My problem right now is that I have dozens of projects that steal my free time from getting into Smalltalk, but I'll fix that as soon as I can. —☈
Re: [Pharo-project] Redline Smalltalk on heroku ....
On Nov 30, 2012, at 10:08 PM, James Ladd james_l...@hotmail.com wrote: Redline Smalltalk is easily deployed to Heroku, a cloud service. So writing web apps in Smalltalk and deploying them to the could just got a whole let easier. https://stout.herokuapp.com/ Please support the Redline project here: http://www.indiegogo.com/smalltalk/x/1366536 YES - We are providing classes to make deploying Pharo app to Redline a snap. We will see… it's hard to implement a real smalltalk in Java (think about #become:…), but I fear it will be even harder to follow where Pharo is going… (We can discuss that over a beer sometime :-) Marcus
Re: [Pharo-project] Vim Keys?
On 30 Nov 2012, at 23:06, Igor Stasenko siguc...@gmail.com wrote: And here is where shortcuts come in handy.. Igor, you are not even using Command-Enter to search for classes/methods last time we sat together… ;-) Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts ! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] Combining Regular Monticello with Github/FileTree
I have been using both Github/FileTree and Monticello for STON this week, and things have definitively progressed. Thank you, Dale friends. It does seem that I have to save a version to Github/FileTree first and then copy it to Monticello (ss3) and not the other way around - otherwise things seem to get messed up. So Github/FileTree is sticky ;-) Sven PS: in th FileTree code that I am using (from Metacello/Pharo 2.0) there is a small UI problem: SmallInteger/ Jobprogress JobChangeprogress SystemProgressMorph classupdateJob: MessageSendvalue: MessageSendcull: MessageSendcull:cull: AnnouncementSubscriptiondeliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosureon:do: BlockClosureon:fork: in Block: [Processor terminateActive] (The stack isn't any longer ;-) On 27 Nov 2012, at 22:05, Sven Van Caekenberghe s...@stfx.eu wrote: Dale, Max, It might be that I was using an older filetree version, I am just going to overwrite the git files and commit and see from there. It is good to know that it should work. Thx, Sven On 27 Nov 2012, at 21:58, Dale Henrichs dhenr...@vmware.com wrote: Sven, When viewing changes from the Monticello Browser, there are certain circumstances when the Browser doesn't recognize that the package in a FileTree repository is an ancestor (I haven't fully characterized this, but I have seen it happen - I think it usually happens when the package in FileTree is not a direct ancestor of the in-image package) ... This is the type of thing that happens when packages names have been changed in Monticello as well ... In those cases, you be able to _open_ the repository and do a direct comparison of the in-image package and the package in the repository and get a good comparison ... Dale - Original Message - | From: Sven Van Caekenberghe s...@stfx.eu | To: Pharo-project@lists.gforge.inria.fr Development Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, November 27, 2012 11:56:18 AM | Subject: [Pharo-project] Combining Regular Monticello with Github/FileTree | | Hi, | | Before I get too frustrated trying, a quick question: is it possible | to combine regular monticello with github/filetree ? | | I have STON both in ss3 as on github, but it seems I cannot compare | my in-image ss3 version with a filetree/github repository on disk: | it reports everything as changed (maybe due to meta data | differences, I don't know). | | How do I know the difference between the ss3 version and the filetree | version ? | I guess I could just save the filetree version and let git decide ? | But maybe, then everything will be different as well ? | | Sven | | -- | Sven Van Caekenberghe | http://stfx.eu | Smalltalk is the Red Pill | | | | |
Re: [Pharo-project] Combining Regular Monticello with Github/FileTree
On 2012-11-30, at 19:22, Sven Van Caekenberghe s...@stfx.eu wrote: I have been using both Github/FileTree and Monticello for STON this week, and things have definitively progressed. Thank you, Dale friends. It does seem that I have to save a version to Github/FileTree first and then copy it to Monticello (ss3) and not the other way around - otherwise things seem to get messed up. So Github/FileTree is sticky ;-) Sven PS: in th FileTree code that I am using (from Metacello/Pharo 2.0) there is a small UI problem: SmallInteger/ Jobprogress JobChangeprogress SystemProgressMorph classupdateJob: MessageSendvalue: MessageSendcull: MessageSendcull:cull: AnnouncementSubscriptiondeliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosureon:do: BlockClosureon:fork: in Block: [Processor terminateActive] my bad, I have to finish my Job/ProgressBar refactoring :P
Re: [Pharo-project] Vim Keys?
On 30 November 2012 22:16, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 01:25 PM, dimitris chloupis wrote: Both #emacs and #vim show how popular both of these text editors are, why not pharo attract that crowd. Another part of this is just making UIs for editing non-Smalltalk code. If I had a good editor widget available, I could use it to make any number of powerful other tools. But then you started from wrong end, isn't? You're free to implement own full blown text editor using smalltalk, as well as any other language. with any shortcuts you may like.. but you trying to sell it as vi shortcuts for pharo.. which a bit strange. Because what is not clear to me, is where is the gain concretely for Pharo IDE and its tools. And don't take me wrong: i would be happy to have good rich-text editor widget with configurable shortcuts. But i just see key thing: it does not looks like absolute necessity to me (as for smalltalk developer). And if i would be a book writer or html writer you may get different opinion. But that's the point: there's already tons of text editors specialized for anything (but smalltalk).. which you can use right now, without need to wait till someone will implement it. So, why not use them? —☈ -- Best regards, Igor Stasenko.
Re: [Pharo-project] Redline Smalltalk on heroku ....
I am one of those developers coding Java for a living, but day-dreaming of using Smalltalk instead. As such, the Redline project of course cought my attention and took a look at it. I am no authority on Redline, but I think there is some confusion here that I could clarify. 2012/11/30 Marcus Denker marcus.den...@inria.fr: We will see… it's hard to implement a real smalltalk in Java (think about #become:…), but I think Redline is not trying to be a full-fledged Smalltalk (not like the Squeak port to the JVM). It is more in the spirit of Amber. A Smalltalk-to-Java compiler, with some underlying runtime support. It does not aim at supporting the full enchilada :-) Are there some vital things that are impossible if #become: is missing? (no irony in my question, I just don't know) I fear it will be even harder to follow where Pharo is going… Again, I think the comment was meant to mean that Pharo-based projects could be exported to the Redline source format, and made be to run there also. Not that Pharo (core) code will/can run automatically on Redline. Many things just will never run or not make sense at all (Fuel, Monti-/Metacello, Polymorph/Spec, NativeBoost, etc.) I for one welcome the possibility to be able to run Smalltalk in one more runtime-environment. Smalltalk should run everywhere! :-) On the other hand I am also aware that the experience of coding in Maven/Eclipse projects is just not the same as in an environment like Pharo. It is just... different. I found joy and sorrow on both sides ;-) Cheers, Sebastian
Re: [Pharo-project] CogVM crash code
OK, this is fixed. Thanks, Jon. The bug was that the pop of the folded constant did not record the implicit send in the folding, hence pc mapping was wrong. i.e. 1-1 gets folded away to 0, and the code generator marks the result 0 as being the result of a send, but then the result gets discarded (when it is popped) without being noted in the pc map. In the machine code there needs to be at least a nop generated, and in the map there needs to be an entry, to correspond to the send of +, so that when machine code pcs are mapped to bytecode pcs there are the correct number of entries in the map. In the above case, the VM converts the interpreted frame to a machine code frame (coincidently) on the 20th iteration and needs to map the bytecode pc to the correct machine code pc to continue in machine code. But because of the missing entry in the map for 1-1, the pc mapping machinery answered 0, and the VM ended up jumping into the void. Thanks very much for the bug report! On Fri, Nov 30, 2012 at 9:07 AM, Jon Anderson jonkander...@gmail.comwrote: Hi all, I don't post to lists often, but I thought some of you might be interested in these few lines of code that crash the CogVM on both Linux and Windows. File-in the Smalltalk code below, then evaluate [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or [56+98]. I put the code on nil, but that is not important either. I think the important thing is that the primitive (+ or -) is evaluated but the result is not assigned into any variable. Also important is that the code is put into a loop that I assume has been JIT optimized. The image I used is Pharo 1.4 one-click with latest update #14459. This code does not crash StackVM. Have fun! - Jon. !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM Evaluate [ nil crashCogVM ] | i | i := 20. 1 to: i do: [:d | 1-1 ] ! ! -- best, Eliot
[Pharo-project] STON Update
Hi, Based on feedback by Norbert Hartl, Stuart Herring and Dale Hendrichs (thank you) I improved the current STON version a bit. http://ss3.gemstone.com/ss/STON https://github.com/svenvc/ston Changelog: A nasty cycle bug was fixed Performance was improved, especially for large structures. Some implementation changes (recursion done using a stack, stonProcessSubObjects: optimized using stonContainsSubObjects) I did some stress/performance testing/tuning. Using STONTestMap classTreeExtended. to generate a structure mimicing the class hierarchy, with objects for all classes, about 7000 in my image and all methods, about 64000 in my image, with super/subclass and method owner links to create cycles. This results in a 7 Mb .ston file. The normal code, serializes this in 28 seconds and materializes it in 11.5 seconds. The 'fast' versions (using ZnBuffered[Write|Read]Streams and Fuel Large Datastructures) does it in 1.1 and 3.8 seconds respectively. New users are always welcome. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] Vim Keys?
On 30 November 2012 22:17, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 12:13 PM, Igor Stasenko wrote: well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black white color scheme, 80x25 text mode ;) ) etc.. I know you're joking, but limiting one's self to 80 columns is generally a good way to maximize screen space. Step back and look at code that runs with really long lines, and you'll see a vast emptiness on most lines. yeah yeah. I can even remember that Bill Gates once said that 640kb of RAM is more than enough for any application. and, btw do you know that color of a blue sky is bad for your sight? :) i think, if vi would contest for best obscure editor, i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. Monkey-bopping not a compelling argument? In that sense, a software which works is the only compelling argument to me :) But since i knowing a bit about VI style of text editing, what you propose is not quite compelling to me. Once i tried hard to become 'pro' vi user and tried to remember all its commands/shortcuts.. but failed miserably after a while.. It looks like i am too spoiled by modeless text editors.. and nothing can change my brain patterns. Because the very first text editor for coding, which i was using around '86 was like hundred times more convenient comparing to what i seen in vim once first time i tried to learn it around 2000's. I mean, the goal is to make a fluid interface. The subtitle of one of the vim books is Edit at the Speed of Thought. That's the key thing. i am quite happy with the speed at which i editing right now. :) besides 'fluid interface' is too vague, and adding 'vi' label to it sounds even more fuzzy to me. What i understand that you want to see/make certain improvements in Pharo. And i appreciate that. When I'm coding with vi keys, the text just goes where I want it, and quickly, with very little stopping to think about it. same here, except that i don't use vi keys :) What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Possibly. I'll think about that. After all, you can run vi/emacs/put your favorite in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. This is something that Pentadactyl (a amazing Firefox plugin that makes the browser vim-like) does. You can hit Ctrl+i on any text field, and it pops up a gvim window with that text. Perhaps something like this is sufficient. We'll see. My problem right now is that I have dozens of projects that steal my free time from getting into Smalltalk, but I'll fix that as soon as I can. —☈ -- Best regards, Igor Stasenko.
Re: [Pharo-project] Vim Keys?
On 30 November 2012 23:13, Sven Van Caekenberghe s...@stfx.eu wrote: On 30 Nov 2012, at 23:06, Igor Stasenko siguc...@gmail.com wrote: And here is where shortcuts come in handy.. Igor, you are not even using Command-Enter to search for classes/methods last time we sat together… ;-) the explanation is much easier than you think: in my dev image, which i didn't updated for a while, this function is non-existent. i find myself that, time to time i pressing this magic key combination, get nothing.. and then enduring and continue the old way. :) but from other side, i bet you're not using my little patch to treat multiple white-space characters as a single entity for cursor movement, while i enjoying it :) Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts ! yes i like it.. but same issue: i do not change images that often. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill -- Best regards, Igor Stasenko.
[Pharo-project] Fw: Vim Keys?
the bottom line is this, may I as a noob user use system browser without the mouse , just by shortcuts ? How about the debugger and inspector ? Personally I dont care about vim shortcuts, I am an emacs user and guess what I dont care about emacs shortcuts as well. This why there is no way I am going to bother implementing vim shortcuts which by the way I find them bad , and so do I emacs shortcuts as well. So we are not far apart on this point. But I will try to implement a shortcut based interface. I wish I could figure out pharo in a single day and start doing this stuff. But learning takes time. From time being mouse does not bother because I code slow anyway, but I think the faster I start to code in pharo the more it will make sense to rely more on shortcuts and liberate myself from them mouse. Also I think you are unfair calling emacs a text editor. Its not. I know the consensus is calling emacs a text editor but I dont think thats a fair definition. Because taking a look into emacs will immediately show that is not that diffirent from smalltalk. Its a development enviroment. It has its own language, a very capable one, rich library set not just limited to text editing and an array of development tools. If you add to it a common lisp runtime together with slime , it can give pharo easily a run for its money. I am saying this because you talked about shortcuts of making things bold or italic. In any case I don't think its unreasonable from time to time a new user to jump in here and ask for a feature. This also gives a clear idea what people want from pharo, old and new users. Whether a developer will jump in and implement the feature is a completely different matter. After all that's the beauty of a truly democratic system. From: Igor Stasenko siguc...@gmail.com To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis theki...@yahoo.co.uk Sent: Saturday, 1 December 2012, 0:06 Subject: Re: [Pharo-project] Vim Keys? On 30 November 2012 20:25, dimitris chloupis theki...@yahoo.co.uk wrote: Even though I agree with your Igor , text editing is not per se required by existing smalltalk users, though even that is debatable, introducing vim and emacs mapping, in a completely optional state, will be definitely a motivation for vim and emacs user to join pharo. For example if you enter the pharo channel in irc you will be happy to find one person talking to himself, squeak channel more or less the same. Both #emacs and #vim show how popular both of these text editors are, why not pharo attract that crowd. Let me throw a crazy idea on the table why smalltalk cannot be a more ultimate text editor than those. Sure its ton of work and definetly you or I should not do , but I am sure if we provide minimum means of people to do this we will see more and more people porting vim and emacs features to pharo. i am not against it. I just a bit tired of seeing this recurring topic appear again and again and no action. Come on, people. Pharo is open-source project. If you need it so badly, then do it. Don't wait till someone, one day do it for you, and stop wasting time, repeating same arguments over and over again, how good vi/emacs mappings are comparing to what we having now. Also your point that we dont need text editing that much in pharo , is vaild from one side, however you should not forget that even though vim and emacs might appear radically diffirent from pharo those diffirences are skin deep. All of them have IDE tools , code navigation tools, debuging tools etc ... so I am not that convinced that for example using system browsers via shortcuts cannot be improved. it can and should be improved. Absolutely. But pharo environment is much more than text editing, and so, asking if it can provide vi mapping to me sounds similar to can photoshop provide vi/emacs mapping , i.e. makes no sense at all. apart from this is implementing a full-fledged text editor/word processor: it is doable and been done before (like Sophie project did). But this is completely orthogonal to IDE: i simply do not see how shortcuts like making text bold or italic could significantly improve my daily coding experience. For coding i concerned about completely different things: code navigation, browser etc.. And here is where shortcuts come in handy.. Now if someone tell me how senders of it action shortcut (to browse senders of selector) which i often using by pressing 'Cmd-n' can be ton times more convenient to use, once we will use vi shortcut for it (btw, what is default vi shortcut for such action?)... i am all ears. I am actually in the process of learning elisp code to port some of the features of emacs to pharo. -- Best regards, Igor Stasenko.
Re: [Pharo-project] Vim Keys?
On 1 December 2012 01:22, dimitris chloupis theki...@yahoo.co.uk wrote: the bottom line is this, may I as a noob user use system browser without the mouse , just by shortcuts ? How about the debugger and inspector ? Personally I dont care about vim shortcuts, I am an emacs user and guess what I dont care about emacs shortcuts as well. This why there is no way I am going to bother implementing vim shortcuts which by the way I find them bad , and so do I emacs shortcuts as well. So we are not far apart on this point. But I will try to implement a shortcut based interface. I wish I could figure out pharo in a single day and start doing this stuff. But learning takes time. From time being mouse does not bother because I code slow anyway, but I think the faster I start to code in pharo the more it will make sense to rely more on shortcuts and liberate myself from them mouse. Also I think you are unfair calling emacs a text editor. Its not. I know the consensus is calling emacs a text editor but I dont think thats a fair definition. Because taking a look into emacs will immediately show that is not that diffirent from smalltalk. Its a development enviroment. It has its own language, a very capable one, rich library set not just limited to text editing and an array of development tools. If you add to it a common lisp runtime together with slime , it can give pharo easily a run for its money. I am saying this because you talked about shortcuts of making things bold or italic. i know that emacs is not just text editor. but i never used it anyways, so i don't know and don't relly care :) but my bold or italic was about some features would make sense only in certain environment/ for certain purpose. If you need apples but people offer you oranges.. you won't buy them despite how fresh and juicy and low-pricey they are. And even if you buy, it won't fulfill your need in apples. That means that if you blindly port feature(s) from one environment into another, it is not necessary makes sense, despite how good and useful they are. First thing what you should do is to study deeply both of them, and then you'll have an insight whether doing some moves makes sense. In any case I don't think its unreasonable from time to time a new user to jump in here and ask for a feature. This also gives a clear idea what people want from pharo, old and new users. Whether a developer will jump in and implement the feature is a completely different matter. After all that's the beauty of a truly democratic system. yes.. but what makes me sad that most newcomer initiatives look like following: - hi i am new here - lets improve Pharo by porting X features into it, because X is cool. and then they disappear. By analogy, imagine i started using emacs.. a few days later i will have a bright idea, how cooler it would be to have vim shortcuts in it.. and next step, i will jump into emacs dev mailing list and bring that proposal on table! That will give a clear idea where emacs developers should focus their effort for next release. No doubt. :) All i can tell is, that this is not Pharo problem. The problem is that people tend to think that things they already learned or get used to so far is best of best, and anything which does not fits into their world view or using different approach alienating them a lot. The first reaction is to just leave, and second one is to bring as much baggage as they can into new environment, hoping that it will make it less alien. This , of course applicable to everyone, including me, because it is natural behavior of humans :) But here lies a mistake: first you must learn it well. And only then you can judge whether your 'baggage' could make things better or not. -- Best regards, Igor Stasenko.
