November 2013 - Pharo-users

Re: [Pharo-users] Useful (hidden) features in Pharo 3.0

by Juraj Kubelka

Wow, thank you all. So in order to summarize: Cmd+click on instance variable â it opens window âAccesses to variable" Cmd+click on method â it opens implementors of the method Cmd+shift+click on method â it opens senders of the method (on method definition reversely) Cmd+click on Class â it opens new Nautilus with definition of the Class Cmd+shift+click on Class â it opens window âUsers of Class" Cmd+t â Nautilus, when method source code is displayed. It shows context menu related to the position of cursor. Cmd+Shift+p â Nautilus, in method source code, it extends selection according to AST Shift+Enter â Spotlight Great to know :-) Regards, Jura El 18-11-2013, a las 18:15, kilon alios <kilon.alios(a)gmail.com> escribiÃ³: > Or on an instance variable > > > On Mon, Nov 18, 2013 at 11:02 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 18 Nov 2013, at 21:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Cmd+ click on a class jumps there. > > Or on a method. > > > On Nov 17, 2013, at 10:43 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > > >> Hi, > >> > >> this week I have realized a lot of useful (hidden) features I did not know they exists. Those I have learned: > >> > >> Cmd+t â Nautilus, when method source code is displayed. It shows context menu related to the position of cursor. > >> Cmd+Shift+p â Nautilus, in method source code, it extends selection according to AST > >> Shift+Enter â Spotlight > >> > >> Do you know others? > >> Thanks, > >> Jura > > > > > > >

Nov. 19, 2013

Useful (hidden) features in Pharo 3.0

by Torsten Bergmann

Phil wrote: >Not on Windows. Alt-Click doesn't work either. >What works is select the word and Ctrl-Enter to jump. Did you try "Alt" + right mouse click on a class to jump. Works for me. Thx T.

Nov. 18, 2013

Re: [Pharo-users] Useful (hidden) features in Pharo 3.0

by phil＠highoctane.be

Not on Windows. Alt-Click doesn't work either. What works is select the word and Ctrl-Enter to jump. Annoying discrepancy... Phil On Mon, Nov 18, 2013 at 9:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Cmd+ click on a class jumps there. > > On Nov 17, 2013, at 10:43 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> > wrote: > > > Hi, > > > > this week I have realized a lot of useful (hidden) features I did not > know they exists. Those I have learned: > > > > Cmd+t â Nautilus, when method source code is displayed. It shows context > menu related to the position of cursor. > > Cmd+Shift+p â Nautilus, in method source code, it extends selection > according to AST > > Shift+Enter â Spotlight > > > > Do you know others? > > Thanks, > > Jura > > > >

Nov. 18, 2013

Re: [Pharo-users] Useful (hidden) features in Pharo 3.0

by kilon alios

Or on an instance variable On Mon, Nov 18, 2013 at 11:02 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > > On 18 Nov 2013, at 21:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Cmd+ click on a class jumps there. > > Or on a method. > > > On Nov 17, 2013, at 10:43 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> > wrote: > > > >> Hi, > >> > >> this week I have realized a lot of useful (hidden) features I did not > know they exists. Those I have learned: > >> > >> Cmd+t â Nautilus, when method source code is displayed. It shows > context menu related to the position of cursor. > >> Cmd+Shift+p â Nautilus, in method source code, it extends selection > according to AST > >> Shift+Enter â Spotlight > >> > >> Do you know others? > >> Thanks, > >> Jura > > > > > > >

Nov. 18, 2013

Re: [Pharo-users] Useful (hidden) features in Pharo 3.0

by Sven Van Caekenberghe

On 18 Nov 2013, at 21:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Cmd+ click on a class jumps there. Or on a method. > On Nov 17, 2013, at 10:43 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> Hi, >> >> this week I have realized a lot of useful (hidden) features I did not know they exists. Those I have learned: >> >> Cmd+t â Nautilus, when method source code is displayed. It shows context menu related to the position of cursor. >> Cmd+Shift+p â Nautilus, in method source code, it extends selection according to AST >> Shift+Enter â Spotlight >> >> Do you know others? >> Thanks, >> Jura > >

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by StÃ©phane Ducasse

+1 > > One could now start a new discussion on whether this use case is "unit testing" or now, but I guess we can be glad when people write any kind of test ;-) > Not every thing that should be improved can be improved by changing tools. Sometimes it really is a people thing.

Nov. 18, 2013

Re: [Pharo-users] CogVM arguments in Win32

by StÃ©phane Ducasse

quite cool! Stef On Nov 18, 2013, at 11:25 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Ok guys, in the end I implemented a big time clutch that simulates the behaviour I was after: > > I created a tiny app in C++ that starts Pharo, the image reads the --serve flag (that I implemented in DefaultCommandLineHandler), hides itself via NB, and kills the UIManager process to prevent refreshes. > > Then it adds an icon into the tray, with a single context-menu entry (Quit) that kills the Pharo process quits the tiny app itself. > > I know it's ugly, but it does work and, to the end user, it looks like Pharo just started minimized to tray. > > Thanks a lot for your help! :) > > Bernat. > > > 2013/11/13 Igor Stasenko <siguctua(a)gmail.com> > > > > On 13 November 2013 12:02, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Thanks a lot Torsten! > > I'll invest the whole morning tomorrow in trying to get a little bit more of this to work. > > If I don't succeed... there are lots of very good restaurants in Barcelona, Igor ;) > > i can imagine :) I hope i will be able come there once more one day. > Barcelona is very beautiful city. > :) > > > 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > Hi Bernat, > > >how do I translate this into NB code > > Either invite Igor (author of NB) for lunch or try this: > > > Its a C-structure, you convert it by wrapping this in a sublcass > of "NBExternalStructure". See the examples already in a Pharo 3.0 image. > > Basically you need: > > - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... > - define the correct fields in a class side #fieldsDesc method according to the native data types used in the structure > - call "WinNotifyIconData rebuildFieldAccessors" > - setup the types in a shared pool that you can include later: > > - define the pool: SharedPool subclass: #WinTryIconConstants ... > - in a class initialize method you can setup the type > > initialize > > NOTIFYICONDATA := #WinNotifyIconData. > PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. > > - by including the pool you can use "NOTIFYICONDATA" or "PNOTIFYICONDATA" in any native boost call. > > > If you are in Pharo 3.0 load "OS-Windows" package from the config browser. > Check the subclasses of NBExternalStructure there. > > I wrapped many other windows structures already so you can get an idea about > it. For instance have a look at WinConsoleConstants>>initTypeConstants, there you will find > the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in WinConsoleCursor, WinConsoleScreenBuffer classes. > > Compare them with the MSDN struct description. > > >Could the Windows API be any more convoluted and dev-unfriendly in any > >possible sense? > > This question should go to M$ not Pharo-user ;) > > Bye > T. > > > BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I remember correctly > from my Smalltalk/MT and C/C++ times also playing with tray icons. > I guess you need a callback that gets called when the icon is clicked or the tray icon menu > is choosen (see uCallbackMessage member in the struct). > You also need a handle to an icon - either the icon from the EXEs resource section or > by loading one from a bitmap. That means wrapping the icon or bitmap apis too... > > > > > -- > Bernat Romagosa. > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Bernat Romagosa.

Nov. 18, 2013

Re: [Pharo-users] Useful (hidden) features in Pharo 3.0

by StÃ©phane Ducasse

Cmd+ click on a class jumps there. On Nov 17, 2013, at 10:43 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi, > > this week I have realized a lot of useful (hidden) features I did not know they exists. Those I have learned: > > Cmd+t â Nautilus, when method source code is displayed. It shows context menu related to the position of cursor. > Cmd+Shift+p â Nautilus, in method source code, it extends selection according to AST > Shift+Enter â Spotlight > > Do you know others? > Thanks, > Jura

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by jtuchel＠objektfabrik.de

Esteban, good point. I use Tests sometimes as a mixture of design help and living documentation. And there, test cases almost never match classes 1:1. And I also think that is a good thing. Especially when it comes to refactoring and major redesign where the API of some entry points to a certain functional unit must not be changed. One could now start a new discussion on whether this use case is "unit testing" or now, but I guess we can be glad when people write any kind of test ;-) Not every thing that should be improved can be improved by changing tools. Sometimes it really is a people thing. Joachim Am 18.11.13 13:07, schrieb Esteban A. Maringolo: > I don't like having the Unit Tests so coupled with the code. > > Many times I implement Unit Tests that doesn't match 1:1 with a class. > It is... the TestCase subclass doesn't have a corresponding class (eg. > SomeFeatureTest, with no SomeFeature class in the system). > > > Regards, > > Esteban A. Maringolo > > > 2013/11/18 Camille Teruel <camille.teruel(a)gmail.com>: >> On 17 nov. 2013, at 15:16, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> I stumbled across this idea when Markus Gaelli chose it as a PhD topic about >> ten years ago (man, I'm old). The main idea was not to provide tests, but >> examples that happened to have assertions. The goal was twofold: (1) provide >> live documentation with real objects, (2) provide another way of composing >> tests. >> >> The project did not really come to fruition, but I still think this is >> highly interesting topic. Part of the ideas were later implemented in >> Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and >> JExample (http://scg.unibe.ch/research/jexample) >> >> Cheers, >> Doru >> >> >> There was a presentation of the Pyret language at SCRIPT workshop last week. >> This way of coupling unit tests with functions is indeed interesting. >> One the one hand I feel it's like a mixing of concerns, on the other hand >> it's push unit-tests into the language. >> The funny part is that the examples provided are used to type the function: >> >> fun id(x): >> x >> where: >> id(3) is 3 >> id("bla") is "bla" >> end >> >> is typed as 'a -> 'a whereas: >> >> fun id(x): >> x >> where: >> id(3) is 3 >> end >> >> is typed as int -> int >> >> >> On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett >> <andy.burnett(a)knowinnovation.com> wrote: >>> I have just come across the Pyret language. It looks interesting, but the >>> part which particularly caught my interest was the way that they had built >>> the unit tests directly into the classes, rather than having separate test >>> classes. >>> >>> I think this is an interesting idea. It seems as though it would be easier >>> to manage writing tests if everything were in one location. And this - might >>> - mean that people were more likely to write tests. >>> >>> Has anyone else looked at this, and have an opinion on whether it would be >>> a good addition to Pharo 4/5/X? >>> >>> Cheers >>> Andy >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Camille Teruel

On 18 nov. 2013, at 13:07, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I don't like having the Unit Tests so coupled with the code. > > Many times I implement Unit Tests that doesn't match 1:1 with a class. > It is... the TestCase subclass doesn't have a corresponding class (eg. > SomeFeatureTest, with no SomeFeature class in the system). IMO, you're talking about functional tests, not unit tests. While a unit test is done in isolation and is concerned with one "unit" (typically a method), an acceptance test tests a feature of your application that will typically crosscut many units. In Pyret, they have another clause "check" for that purpose. > Regards, > > Esteban A. Maringolo > > > 2013/11/18 Camille Teruel <camille.teruel(a)gmail.com>: >> >> On 17 nov. 2013, at 15:16, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> I stumbled across this idea when Markus Gaelli chose it as a PhD topic about >> ten years ago (man, I'm old). The main idea was not to provide tests, but >> examples that happened to have assertions. The goal was twofold: (1) provide >> live documentation with real objects, (2) provide another way of composing >> tests. >> >> The project did not really come to fruition, but I still think this is >> highly interesting topic. Part of the ideas were later implemented in >> Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and >> JExample (http://scg.unibe.ch/research/jexample) >> >> Cheers, >> Doru >> >> >> There was a presentation of the Pyret language at SCRIPT workshop last week. >> This way of coupling unit tests with functions is indeed interesting. >> One the one hand I feel it's like a mixing of concerns, on the other hand >> it's push unit-tests into the language. >> The funny part is that the examples provided are used to type the function: >> >> fun id(x): >> x >> where: >> id(3) is 3 >> id("bla") is "bla" >> end >> >> is typed as 'a -> 'a whereas: >> >> fun id(x): >> x >> where: >> id(3) is 3 >> end >> >> is typed as int -> int >> >> >> On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett >> <andy.burnett(a)knowinnovation.com> wrote: >>> >>> I have just come across the Pyret language. It looks interesting, but the >>> part which particularly caught my interest was the way that they had built >>> the unit tests directly into the classes, rather than having separate test >>> classes. >>> >>> I think this is an interesting idea. It seems as though it would be easier >>> to manage writing tests if everything were in one location. And this - might >>> - mean that people were more likely to write tests. >>> >>> Has anyone else looked at this, and have an opinion on whether it would be >>> a good addition to Pharo 4/5/X? >>> >>> Cheers >>> Andy >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Esteban A. Maringolo

I don't like having the Unit Tests so coupled with the code. Many times I implement Unit Tests that doesn't match 1:1 with a class. It is... the TestCase subclass doesn't have a corresponding class (eg. SomeFeatureTest, with no SomeFeature class in the system). Regards, Esteban A. Maringolo 2013/11/18 Camille Teruel <camille.teruel(a)gmail.com>: > > On 17 nov. 2013, at 15:16, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I stumbled across this idea when Markus Gaelli chose it as a PhD topic about > ten years ago (man, I'm old). The main idea was not to provide tests, but > examples that happened to have assertions. The goal was twofold: (1) provide > live documentation with real objects, (2) provide another way of composing > tests. > > The project did not really come to fruition, but I still think this is > highly interesting topic. Part of the ideas were later implemented in > Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and > JExample (http://scg.unibe.ch/research/jexample) > > Cheers, > Doru > > > There was a presentation of the Pyret language at SCRIPT workshop last week. > This way of coupling unit tests with functions is indeed interesting. > One the one hand I feel it's like a mixing of concerns, on the other hand > it's push unit-tests into the language. > The funny part is that the examples provided are used to type the function: > > fun id(x): > x > where: > id(3) is 3 > id("bla") is "bla" > end > > is typed as 'a -> 'a whereas: > > fun id(x): > x > where: > id(3) is 3 > end > > is typed as int -> int > > > On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett > <andy.burnett(a)knowinnovation.com> wrote: >> >> I have just come across the Pyret language. It looks interesting, but the >> part which particularly caught my interest was the way that they had built >> the unit tests directly into the classes, rather than having separate test >> classes. >> >> I think this is an interesting idea. It seems as though it would be easier >> to manage writing tests if everything were in one location. And this - might >> - mean that people were more likely to write tests. >> >> Has anyone else looked at this, and have an opinion on whether it would be >> a good addition to Pharo 4/5/X? >> >> Cheers >> Andy > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > >

Nov. 18, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Bernat Romagosa

Ok guys, in the end I implemented a big time clutch that simulates the behaviour I was after: I created a tiny app in C++ that starts Pharo, the image reads the --serve flag (that I implemented in DefaultCommandLineHandler), hides itself via NB, and kills the UIManager process to prevent refreshes. Then it adds an icon into the tray, with a single context-menu entry (Quit) that kills the Pharo process quits the tiny app itself. I know it's ugly, but it does work and, to the end user, it looks like Pharo just started minimized to tray. Thanks a lot for your help! :) Bernat. 2013/11/13 Igor Stasenko <siguctua(a)gmail.com> > > > > On 13 November 2013 12:02, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com > > wrote: > >> Thanks a lot Torsten! >> >> I'll invest the whole morning tomorrow in trying to get a little bit more >> of this to work. >> >> If I don't succeed... there are lots of very good restaurants in >> Barcelona, Igor ;) >> >> i can imagine :) I hope i will be able come there once more one day. > Barcelona is very beautiful city. > :) > > >> 2013/11/13 Torsten Bergmann <astares(a)gmx.de> >> >>> Hi Bernat, >>> >>> >how do I translate this into NB code >>> >>> Either invite Igor (author of NB) for lunch or try this: >>> >>> >>> Its a C-structure, you convert it by wrapping this in a sublcass >>> of "NBExternalStructure". See the examples already in a Pharo 3.0 image. >>> >>> Basically you need: >>> >>> - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... >>> - define the correct fields in a class side #fieldsDesc method according >>> to the native data types used in the structure >>> - call "WinNotifyIconData rebuildFieldAccessors" >>> - setup the types in a shared pool that you can include later: >>> >>> - define the pool: SharedPool subclass: #WinTryIconConstants ... >>> - in a class initialize method you can setup the type >>> >>> initialize >>> >>> NOTIFYICONDATA := #WinNotifyIconData. >>> PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. >>> >>> - by including the pool you can use "NOTIFYICONDATA" or >>> "PNOTIFYICONDATA" in any native boost call. >>> >>> >>> If you are in Pharo 3.0 load "OS-Windows" package from the config >>> browser. >>> Check the subclasses of NBExternalStructure there. >>> >>> I wrapped many other windows structures already so you can get an idea >>> about >>> it. For instance have a look at WinConsoleConstants>>initTypeConstants, >>> there you will find >>> the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in >>> WinConsoleCursor, WinConsoleScreenBuffer classes. >>> >>> Compare them with the MSDN struct description. >>> >>> >Could the Windows API be any more convoluted and dev-unfriendly in any >>> >possible sense? >>> >>> This question should go to M$ not Pharo-user ;) >>> >>> Bye >>> T. >>> >>> >>> BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I >>> remember correctly >>> from my Smalltalk/MT and C/C++ times also playing with tray icons. >>> I guess you need a callback that gets called when the icon is >>> clicked or the tray icon menu >>> is choosen (see uCallbackMessage member in the struct). >>> You also need a handle to an icon - either the icon from the EXEs >>> resource section or >>> by loading one from a bitmap. That means wrapping the icon or >>> bitmap apis too... >>> >>> >> >> >> -- >> Bernat Romagosa. >> > > > > -- > Best regards, > Igor Stasenko. > -- Bernat Romagosa.

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Camille Teruel

On 17 nov. 2013, at 15:16, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests. > > The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample) > > Cheers, > Doru There was a presentation of the Pyret language at SCRIPT workshop last week. This way of coupling unit tests with functions is indeed interesting. One the one hand I feel it's like a mixing of concerns, on the other hand it's push unit-tests into the language. The funny part is that the examples provided are used to type the function: fun id(x): x where: id(3) is 3 id("bla") is "bla" end is typed as 'a -> 'a whereas: fun id(x): x where: id(3) is 3 end is typed as int -> int > On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes. > > I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests. > > Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X? > > Cheers > Andy > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by phil＠highoctane.be

Agreed. And the more I use Pharo, the more I am looking into tests (especially "Debug Test" to understand how things do work) and writing tests first. That's not a natural thing to do in other environments but feels so great to do in Pharo. (Writing this after having looked at a ton of Seaside and Magritte tests :-) ). The image isn't regular when it comes to tests with some things being Tests-XXX at the end and KernelTests-XXX for example. And for my project I do have Project-Tests-XXX which keeps them close to the project categories (otherwise, I have to scroll too much [groups: good!]). It also helps to put everything in a single Project-XXX package when needed (which happened). BTW, how can one use the "Autotest" feature I saw demoed somewhere? Is that Moose-related? Phil On Mon, Nov 18, 2013 at 8:20 AM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Hi, > > the good thing about the current practice of putting tests into another > package/application is that you can separate them from your actual code for > deployment (packaging), but you can also add them to your deliverable. > If you mix code and tests, there may be good points about that, but in the > end the limiting factor is the developer's discipline/motivation. And to > some extent the quality of tools. The current state of test runners in most > Smalltalk environments is not too bad. > > So I guess we need to educate people more towards writing tests, not > change the place where they belong. > Putting tests somewhere else than other Smalltalk's do would also start > build hurdles to portability of tools between them. Would be a pity, > wouldn't it? > > Just my 2 cents > > Joachim > > > Am 17.11.13 19:58, schrieb Andy Burnett: > >> Esteban said >> >> <<< >> Hi, >> >> It does not really matters where you put the test. >> What matters is to have the tools that show them properly, and we are >> going in that direction. We already have ways to "jump to tests" in >> Nautilus, and we will continue improving that to show them together (for >> example). >> But I do not think the tests need to be *in* the class definition to have >> same level of interoperation. >> >> Esteban >> >>> >> >> I agree. The actual architecture doesn't matter. The critical factor is >> making it as easy as possible to write/navigate tests. I didn't know about >> the Nautilus features. I shall have to go and experiment. >> >> Also, thinking about Doru's point. I wonder if we could write >> tests/examples in the comments section of code. It might be an interesting >> addition >> >> > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > >

Nov. 18, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by jtuchel＠objektfabrik.de

Hi, the good thing about the current practice of putting tests into another package/application is that you can separate them from your actual code for deployment (packaging), but you can also add them to your deliverable. If you mix code and tests, there may be good points about that, but in the end the limiting factor is the developer's discipline/motivation. And to some extent the quality of tools. The current state of test runners in most Smalltalk environments is not too bad. So I guess we need to educate people more towards writing tests, not change the place where they belong. Putting tests somewhere else than other Smalltalk's do would also start build hurdles to portability of tools between them. Would be a pity, wouldn't it? Just my 2 cents Joachim Am 17.11.13 19:58, schrieb Andy Burnett: > Esteban said > > <<< > Hi, > > It does not really matters where you put the test. > What matters is to have the tools that show them properly, and we are > going in that direction. We already have ways to "jump to tests" in > Nautilus, and we will continue improving that to show them together > (for example). > But I do not think the tests need to be *in* the class definition to > have same level of interoperation. > > Esteban > >>> > > I agree. The actual architecture doesn't matter. The critical factor > is making it as easy as possible to write/navigate tests. I didn't > know about the Nautilus features. I shall have to go and experiment. > > Also, thinking about Doru's point. I wonder if we could write > tests/examples in the comments section of code. It might be an > interesting addition > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 18, 2013

Useful (hidden) features in Pharo 3.0

by Juraj Kubelka

Hi, this week I have realized a lot of useful (hidden) features I did not know they exists. Those I have learned: Cmd+t â Nautilus, when method source code is displayed. It shows context menu related to the position of cursor. Cmd+Shift+p â Nautilus, in method source code, it extends selection according to AST Shift+Enter â Spotlight Do you know others? Thanks, Jura

Nov. 17, 2013

Help in St. Petersburg?

by HernÃ¡n Morales Durand

I am sorry for the off-topic. A friend of mine was stolen in Sofia and now she is completely out of money going to St. Petersburg in a few days. Anyone there who can help her a little bit would be really appreciated. Cheers, HernÃ¡n

Nov. 17, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Andy Burnett

Esteban said <<< Hi, It does not really matters where you put the test. What matters is to have the tools that show them properly, and we are going in that direction. We already have ways to "jump to tests" in Nautilus, and we will continue improving that to show them together (for example). But I do not think the tests need to be *in* the class definition to have same level of interoperation. Esteban >>> I agree. The actual architecture doesn't matter. The critical factor is making it as easy as possible to write/navigate tests. I didn't know about the Nautilus features. I shall have to go and experiment. Also, thinking about Doru's point. I wonder if we could write tests/examples in the comments section of code. It might be an interesting addition

Nov. 17, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Andy Burnett

Doru said: <<< I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests. The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample) >>> That's really interesting. I had never heard of Phexample - so many interesting projects, so little time! - I like the approach of building on tests. Do you know if this will work in Pharo 3? Also, I may have misunderstood what Pyret was doing. Perhaps it is more about examples.

Nov. 17, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Esteban Lorenzano

Hi, It does not really matters where you put the test. What matters is to have the tools that show them properly, and we are going in that direction. We already have ways to "jump to tests" in Nautilus, and we will continue improving that to show them together (for example). But I do not think the tests need to be *in* the class definition to have same level of interoperation. Esteban On Nov 17, 2013, at 3:08 PM, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes. > > I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests. > > Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X? > > Cheers > Andy

Nov. 17, 2013

Re: [Pharo-users] Pyret: adding tests directly into classes

by Tudor Girba

I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests. The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample) Cheers, Doru On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett < andy.burnett(a)knowinnovation.com> wrote: > I have just come across the Pyret language. It looks interesting, but the > part which particularly caught my interest was the way that they had built > the unit tests directly into the classes, rather than having separate test > classes. > > I think this is an interesting idea. It seems as though it would be easier > to manage writing tests if everything were in one location. And this - > might - mean that people were more likely to write tests. > > Has anyone else looked at this, and have an opinion on whether it would be > a good addition to Pharo 4/5/X? > > Cheers > Andy > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 17, 2013

Pyret: adding tests directly into classes

by Andy Burnett

I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes. I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests. Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X? Cheers Andy

Nov. 17, 2013

Re: [Pharo-users] i18n - Where to start?

by btc＠openinworld.com

Stephan Eggermont wrote: > Here is a demo of the i18n support in QCMagritte. > It supports live editing of the languages and strings used in your application. > > youtu.be/cTut44Xs3_U > > Stephan > > Very impressive.

Nov. 17, 2013

Re: [Pharo-users] i18n - Where to start?

by Stephan Eggermont

In the multi language demo of QCMagritte, a magritte visitor is used that changes all label:, checkboxLabel:, comment: and group: sends in descriptions to automatically use a multilanguagestring. The parameter is used as the key. All unique keys are collected. The default translation is the key. That is used for missing translations. Languages can be added on the fly. The demo has a simple UI to directly add and change translations. The whole translation table can be written to csv, and read back. This is not shown in the video Stephan Verstuurd vanaf mijn iPhone

Nov. 16, 2013

Re: [Pharo-users] Finding references to traits

by Camillo Bruni

I think the #users method return what you want, no? TBehavior users On 2013-11-16, at 18:19, btc(a)openinworld.com wrote: > If I come in cold to a system and see some class using trait, and then I want to find all classes that use that trait. I have tried a few ways but failed to work it out. The most obvious action "Extended search > references of it" doesn't show them, and neither does any other action I try. How is this done? > > cheers -ben >

Nov. 16, 2013