October 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Athens do not work on Image 40316+

by Nicolai Hess

2014-10-23 0:16 GMT+02:00 Jan BlizniÄenko <bliznjan(a)fit.cvut.cz>: > Hello > > On image 40315 everything working. > On image 40316-40320 (latest) parts of Athens do not work, tried by running > Athens Tutorial and Roassal 2, which are both based on Athens. > Problem is on both Windows and Linux (unable to test on any Mac) > Instead of describing the error, here is a link to download the image after > downloading Athens-Tutorial and clicking on "do it" on Step 2 of tutorial: > http://www.mediafire.com/download/va5wbm0qix3aqh2/PharoAthensBugWindows.zip > > Hope it helps > > Jan BlizniÄenko > > > > -- > View this message in context: > http://forum.world.st/Athens-do-not-work-on-Image-40316-tp4786099.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > I think you can skip the first part: "ConfigurationOfAthens loadVersion: '2.0'." because Athens is already in the image and the version on smalltalkhub is not uptodate with the one in the image.

Oct. 22, 2014

Athens do not work on Image 40316+

by Jan BlizniÄenko

Hello On image 40315 everything working. On image 40316-40320 (latest) parts of Athens do not work, tried by running Athens Tutorial and Roassal 2, which are both based on Athens. Problem is on both Windows and Linux (unable to test on any Mac) Instead of describing the error, here is a link to download the image after downloading Athens-Tutorial and clicking on "do it" on Step 2 of tutorial: http://www.mediafire.com/download/va5wbm0qix3aqh2/PharoAthensBugWindows.zip Hope it helps Jan BlizniÄenko -- View this message in context: http://forum.world.st/Athens-do-not-work-on-Image-40316-tp4786099.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 22, 2014

Re: [Pharo-users] How to force FFI to load a library

by Nicolai Hess

2014-10-22 14:50 GMT+02:00 Annick Fron <list(a)afceurope.com>: > Hi, > > I have one library which depends from another one. > How can I force pharo to load the dependent library ? > > Annick > > I don't think it is necessary to force pharo to load the libraries. AFAIR the VM on linux uses dlopen() to load a module and that should load the dependent libraries as well, *if* the library, you are using, is linked against the others. For example, you want to load library "testlib" which depends on "helperlib" you have to compile and link the testlib and helperlib as follows gcc -shared -o libhelperlib.so helperlib.c gcc -shared -o libtestlib.so testlib.c -L. -lhelperlib now you should be able to load testlib from pharo. you can test if your dependent libraries can be automatically found by dlopen with: ldd <testlib> nicolai

Oct. 22, 2014

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by Thierry Goubier

Hi Doru, Le 22/10/2014 23:03, Tudor Girba a Ã©crit : > Hi, > > As for pragmas, they are a better mechanism for describing intent than a > method naming convention is. If nothing else, it lets us freedom in > naming the method. And they add another programming language on top of another, and in most cases are redundant with the method name and protocol. i.e. exampleThis has pragma <example> testThat has pragma <test> Simply because for the method name to be suitable, it has to convey intent one way or another. I can understand if you come and tell me that the pragma is to annotate for stuff that the compiler can't deduce, such as the #openmp pragmas. But I can't say that bringing in that kind of stuff would mean progress ;) > It's true that at this point, pragmas are hard to browse, but this will > not remain like this for long :) Tools may help to overcome limitations of pragmas, yes ;) But this sounds like because pragmas may not be that good to start with :) Thierry

Oct. 22, 2014

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by Tudor Girba

Hi, I also disagree with Alex. Examples will become tests (see the work of Markus Gaelli and Adrian Kuhn) and they should be casually connected with the class and intention they test or provide example for. The other thing is that examples should be composable via code. And of course, they should be browsable. They will be close to the class by default, but it does not mean that in the class will be the only way. For example, we can well imagine having helper classes for holding examples, but most classes would not need that I think. As for pragmas, they are a better mechanism for describing intent than a method naming convention is. If nothing else, it lets us freedom in naming the method. It's true that at this point, pragmas are hard to browse, but this will not remain like this for long :) Cheers, Doru On Wed, Oct 22, 2014 at 9:14 PM, stepharo <stepharo(a)free.fr> wrote: > I agree with Thierry but I disagree with Alex :) > What is cool is that when you browse a widget class that you get all the > examples for this class. > > Stef > > I am also not a big fan of using pragmas. To me, it looks like an ad hoc >> approach to have examples close to the class. In the same spirit: Why not >> having tests in the same class? Would it not be cool? Of course not. >> In Roassal we have a class for examples (similar to TestCase). >> >> Alexandre >> >> Le 22-10-2014 Ã 14:51, Thierry Goubier <thierry.goubier(a)gmail.com> a >>> Ã©crit : >>> >>> Hi all, >>> >>> by principle, I'd be against extending so much the pragmas... from a >>> design point of view they look like #defines and macros, that is an >>> additional language to learn, without a correct support of the tools (no >>> debug on pragmas, non-obvious behavior triggers, search for pragma users >>> difficult, not documented). >>> >>> Alexandre, your idea of infering properties from the source code looks a >>> lot more interesting (and with a lot more potential). >>> >>> Thierry >>> >>> Le 22/10/2014 19:38, Alexandre Bergel a Ã©crit : >>> >>>> Hi! >>>> >>>> I have doubt that #example: will be enough in the case of Roassal. >>>> Having a code example browser is indeed important and having a descent >>>> way to search for the examples is also important. I am thinking to stick to >>>> #example and infer some categories from the source code (e.g., if the >>>> method contains a Zinc class, then it may be categorized in network). >>>> >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> Le 22-10-2014 Ã 7:38, Torsten Bergmann <astares(a)gmx.de> a Ã©crit : >>>>> >>>>> Hi Tudor, >>>>> >>>>> that should be easy now: look at CompiledMethod>>#isExampleMethod >>>>> which can be adopted as needed. >>>>> >>>>> Checking for the <example> pragma could be done this way: >>>>> >>>>> self pragmas anySatisfy: [:pragma | pragma keyword = #example ] >>>>> >>>>> but we should think first if this is enough. >>>>> >>>>> I already proposed to not only annotate with a pragma <example> but >>>>> additionally give a category. >>>>> Like this: >>>>> >>>>> <example: 'Graphics'> >>>>> <example: 'Network'> >>>>> >>>>> This way we can easily build an example browser for our users where >>>>> people can go through >>>>> their point of interest and browse the examples. >>>>> >>>>> Maybe we should also rethink pragmas (in Pharo 5.0?) in general to be >>>>> more Smalltalk >>>>> like: >>>>> >>>>> <Example category: 'Graphics'> >>>>> >>>>> where Example is a real class in the system (!). One can even make it >>>>> more explicit >>>>> then >>>>> >>>>> <ExampleCategory graphics> >>>>> >>>>> with ExampleCategory(class)>>graphics returning a translateable >>>>> string. People can add >>>>> own categories and one easily knows about already available ones. >>>>> >>>>> >>>>> Now that classes can have properties in Pharo 4.0 already I would like >>>>> to see a unification >>>>> for methods and classes here (with the general concept of an >>>>> "Annotation" in our metamodel). >>>>> >>>>> In my opinion a method pragma is just a special form of annotating a >>>>> method. >>>>> >>>>> And annotating classes is usefull as well (for instance you want to >>>>> annotate a class with >>>>> the appropriate Table name in an ORM framework, ...) >>>>> >>>>> A comment (in a method or in a class) is also nothing more than a >>>>> special annotation. >>>>> A class/method category is also an annotation. If unified a method or >>>>> a class could >>>>> be in one or more categories. Even a break point for an expression is >>>>> IMHO just an >>>>> annotation. >>>>> >>>>> Bye >>>>> T. >>>>> >>>>> >>>>> Gesendet: Mittwoch, 22. Oktober 2014 um 10:43 Uhr >>>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>> Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org >>>>> > >>>>> Betreff: Re: [Pharo-dev] Clickable class side example and initialize >>>>> methods in Pharo 4.0 >>>>> >>>>> Hi Torsten, >>>>> >>>>> Thanks for this. This is indeed the way to go. >>>>> >>>>> Just to let you know, the example infrastructure is also being >>>>> developed in the context of GT, so we have a healthy interest overlap which >>>>> is great. Only in our case, the discovery of the example happens through an >>>>> <example> pragma. Would it be possible to change your slice to use this >>>>> pragma instead of the example* convention? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On Wed, Oct 22, 2014 at 9:19 AM, Torsten Bergmann <astares(a)gmx.de> >>>>> wrote:One addition I implemented for Nautilus is that one can run examples >>>>> directly >>>>> in the browser just by clicking on class side example methods icons. >>>>> >>>>> See https://pharo.fogbugz.com/f/cases/13892/Example-methods- >>>>> should-be-runnable-in-Nautilus[https://pharo. >>>>> fogbugz.com/f/cases/13892/Example-methods-should-be- >>>>> runnable-in-Nautilus] >>>>> for a picture. >>>>> >>>>> >>>>> SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON THE >>>>> CLASS SIDE >>>>> AND LET THE SELECTOR START WITH "example". >>>>> >>>>> This way people will easily see that it is an example and can run >>>>> them. Additionally it >>>>> would help to put them into a category like "examples". So be a good >>>>> citized and >>>>> provide not only class comments but also examples for others to study. >>>>> >>>>> >>>>> Side note: >>>>> ========== >>>>> It is also possible to click on the icon of class side initialize >>>>> methods so the >>>>> class get reinitialized (after a confirmation to avoid false clicking). >>>>> >>>>> https://pharo.fogbugz.com/f/cases/13894/Class-side- >>>>> initialize-methods-should-be-runnable-in-Nautilus[https:// >>>>> pharo.fogbugz.com/f/cases/13894/Class-side-initialize- >>>>> methods-should-be-runnable-in-Nautilus] >>>>> >>>>> Both issues are already integrated. >>>>> >>>>> -- >>>>> www.tudorgirba.com[http://www.tudorgirba.com] >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 22, 2014

Issues tagged for starting sprints

by stepharo

Hi guys Some of you would like to organize sprints (or participate to pharo-dev) and this is always difficult to jump into a hard bug. So I started to add glitches/enh that I usually do not log as bug entries. I tagged them as sprint to help you getting started on sprinting. https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=44 Let me know if this is interesting for you. Stef

Oct. 22, 2014

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by Thierry Goubier

Le 22/10/2014 21:14, stepharo a Ã©crit : > I agree with Thierry but I disagree with Alex :) > What is cool is that when you browse a widget class that you get all the > examples for this class. I use browse class refs for that. Works on average pretty well; if it doesn't I throw away the code and reuse something else ;) Thierry > > Stef >> I am also not a big fan of using pragmas. To me, it looks like an ad >> hoc approach to have examples close to the class. In the same spirit: >> Why not having tests in the same class? Would it not be cool? Of >> course not. >> In Roassal we have a class for examples (similar to TestCase). >> >> Alexandre >> >>> Le 22-10-2014 Ã 14:51, Thierry Goubier <thierry.goubier(a)gmail.com> a >>> Ã©crit : >>> >>> Hi all, >>> >>> by principle, I'd be against extending so much the pragmas... from a >>> design point of view they look like #defines and macros, that is an >>> additional language to learn, without a correct support of the tools >>> (no debug on pragmas, non-obvious behavior triggers, search for >>> pragma users difficult, not documented). >>> >>> Alexandre, your idea of infering properties from the source code >>> looks a lot more interesting (and with a lot more potential). >>> >>> Thierry >>> >>> Le 22/10/2014 19:38, Alexandre Bergel a Ã©crit : >>>> Hi! >>>> >>>> I have doubt that #example: will be enough in the case of Roassal. >>>> Having a code example browser is indeed important and having a >>>> descent way to search for the examples is also important. I am >>>> thinking to stick to #example and infer some categories from the >>>> source code (e.g., if the method contains a Zinc class, then it may >>>> be categorized in network). >>>> >>>> >>>> Cheers, >>>> Alexandre >>>> >>>>> Le 22-10-2014 Ã 7:38, Torsten Bergmann <astares(a)gmx.de> a Ã©crit : >>>>> >>>>> Hi Tudor, >>>>> >>>>> that should be easy now: look at CompiledMethod>>#isExampleMethod >>>>> which can be adopted as needed. >>>>> >>>>> Checking for the <example> pragma could be done this way: >>>>> >>>>> self pragmas anySatisfy: [:pragma | pragma keyword = #example ] >>>>> >>>>> but we should think first if this is enough. >>>>> >>>>> I already proposed to not only annotate with a pragma <example> but >>>>> additionally give a category. >>>>> Like this: >>>>> >>>>> <example: 'Graphics'> >>>>> <example: 'Network'> >>>>> >>>>> This way we can easily build an example browser for our users where >>>>> people can go through >>>>> their point of interest and browse the examples. >>>>> >>>>> Maybe we should also rethink pragmas (in Pharo 5.0?) in general to >>>>> be more Smalltalk >>>>> like: >>>>> >>>>> <Example category: 'Graphics'> >>>>> >>>>> where Example is a real class in the system (!). One can even make >>>>> it more explicit >>>>> then >>>>> >>>>> <ExampleCategory graphics> >>>>> >>>>> with ExampleCategory(class)>>graphics returning a translateable >>>>> string. People can add >>>>> own categories and one easily knows about already available ones. >>>>> >>>>> >>>>> Now that classes can have properties in Pharo 4.0 already I would >>>>> like to see a unification >>>>> for methods and classes here (with the general concept of an >>>>> "Annotation" in our metamodel). >>>>> >>>>> In my opinion a method pragma is just a special form of annotating >>>>> a method. >>>>> >>>>> And annotating classes is usefull as well (for instance you want to >>>>> annotate a class with >>>>> the appropriate Table name in an ORM framework, ...) >>>>> >>>>> A comment (in a method or in a class) is also nothing more than a >>>>> special annotation. >>>>> A class/method category is also an annotation. If unified a method >>>>> or a class could >>>>> be in one or more categories. Even a break point for an expression >>>>> is IMHO just an >>>>> annotation. >>>>> >>>>> Bye >>>>> T. >>>>> >>>>> >>>>> Gesendet: Mittwoch, 22. Oktober 2014 um 10:43 Uhr >>>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>> Cc: "Any question about pharo is welcome" >>>>> <pharo-users(a)lists.pharo.org> >>>>> Betreff: Re: [Pharo-dev] Clickable class side example and >>>>> initialize methods in Pharo 4.0 >>>>> >>>>> Hi Torsten, >>>>> >>>>> Thanks for this. This is indeed the way to go. >>>>> >>>>> Just to let you know, the example infrastructure is also being >>>>> developed in the context of GT, so we have a healthy interest >>>>> overlap which is great. Only in our case, the discovery of the >>>>> example happens through an <example> pragma. Would it be possible >>>>> to change your slice to use this pragma instead of the example* >>>>> convention? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On Wed, Oct 22, 2014 at 9:19 AM, Torsten Bergmann <astares(a)gmx.de> >>>>> wrote:One addition I implemented for Nautilus is that one can run >>>>> examples directly >>>>> in the browser just by clicking on class side example methods icons. >>>>> >>>>> See >>>>> https://pharo.fogbugz.com/f/cases/13892/Example-methods-should-be-runnable-… >>>>> >>>>> for a picture. >>>>> >>>>> >>>>> SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON >>>>> THE CLASS SIDE >>>>> AND LET THE SELECTOR START WITH "example". >>>>> >>>>> This way people will easily see that it is an example and can run >>>>> them. Additionally it >>>>> would help to put them into a category like "examples". So be a >>>>> good citized and >>>>> provide not only class comments but also examples for others to study. >>>>> >>>>> >>>>> Side note: >>>>> ========== >>>>> It is also possible to click on the icon of class side initialize >>>>> methods so the >>>>> class get reinitialized (after a confirmation to avoid false >>>>> clicking). >>>>> >>>>> https://pharo.fogbugz.com/f/cases/13894/Class-side-initialize-methods-shoul… >>>>> >>>>> >>>>> Both issues are already integrated. >>>>> >>>>> -- >>>>> www.tudorgirba.com[http://www.tudorgirba.com] >>>>> >>>>> "Every thing has its own flow" >>> >> > > > >

Oct. 22, 2014

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by stepharo

I agree with Thierry but I disagree with Alex :) What is cool is that when you browse a widget class that you get all the examples for this class. Stef > I am also not a big fan of using pragmas. To me, it looks like an ad hoc approach to have examples close to the class. In the same spirit: Why not having tests in the same class? Would it not be cool? Of course not. > In Roassal we have a class for examples (similar to TestCase). > > Alexandre > >> Le 22-10-2014 Ã 14:51, Thierry Goubier <thierry.goubier(a)gmail.com> a Ã©crit : >> >> Hi all, >> >> by principle, I'd be against extending so much the pragmas... from a design point of view they look like #defines and macros, that is an additional language to learn, without a correct support of the tools (no debug on pragmas, non-obvious behavior triggers, search for pragma users difficult, not documented). >> >> Alexandre, your idea of infering properties from the source code looks a lot more interesting (and with a lot more potential). >> >> Thierry >> >> Le 22/10/2014 19:38, Alexandre Bergel a Ã©crit : >>> Hi! >>> >>> I have doubt that #example: will be enough in the case of Roassal. >>> Having a code example browser is indeed important and having a descent way to search for the examples is also important. I am thinking to stick to #example and infer some categories from the source code (e.g., if the method contains a Zinc class, then it may be categorized in network). >>> >>> >>> Cheers, >>> Alexandre >>> >>>> Le 22-10-2014 Ã 7:38, Torsten Bergmann <astares(a)gmx.de> a Ã©crit : >>>> >>>> Hi Tudor, >>>> >>>> that should be easy now: look at CompiledMethod>>#isExampleMethod which can be adopted as needed. >>>> >>>> Checking for the <example> pragma could be done this way: >>>> >>>> self pragmas anySatisfy: [:pragma | pragma keyword = #example ] >>>> >>>> but we should think first if this is enough. >>>> >>>> I already proposed to not only annotate with a pragma <example> but additionally give a category. >>>> Like this: >>>> >>>> <example: 'Graphics'> >>>> <example: 'Network'> >>>> >>>> This way we can easily build an example browser for our users where people can go through >>>> their point of interest and browse the examples. >>>> >>>> Maybe we should also rethink pragmas (in Pharo 5.0?) in general to be more Smalltalk >>>> like: >>>> >>>> <Example category: 'Graphics'> >>>> >>>> where Example is a real class in the system (!). One can even make it more explicit >>>> then >>>> >>>> <ExampleCategory graphics> >>>> >>>> with ExampleCategory(class)>>graphics returning a translateable string. People can add >>>> own categories and one easily knows about already available ones. >>>> >>>> >>>> Now that classes can have properties in Pharo 4.0 already I would like to see a unification >>>> for methods and classes here (with the general concept of an "Annotation" in our metamodel). >>>> >>>> In my opinion a method pragma is just a special form of annotating a method. >>>> >>>> And annotating classes is usefull as well (for instance you want to annotate a class with >>>> the appropriate Table name in an ORM framework, ...) >>>> >>>> A comment (in a method or in a class) is also nothing more than a special annotation. >>>> A class/method category is also an annotation. If unified a method or a class could >>>> be in one or more categories. Even a break point for an expression is IMHO just an >>>> annotation. >>>> >>>> Bye >>>> T. >>>> >>>> >>>> Gesendet: Mittwoch, 22. Oktober 2014 um 10:43 Uhr >>>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >>>> Betreff: Re: [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0 >>>> >>>> Hi Torsten, >>>> >>>> Thanks for this. This is indeed the way to go. >>>> >>>> Just to let you know, the example infrastructure is also being developed in the context of GT, so we have a healthy interest overlap which is great. Only in our case, the discovery of the example happens through an <example> pragma. Would it be possible to change your slice to use this pragma instead of the example* convention? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Wed, Oct 22, 2014 at 9:19 AM, Torsten Bergmann <astares(a)gmx.de> wrote:One addition I implemented for Nautilus is that one can run examples directly >>>> in the browser just by clicking on class side example methods icons. >>>> >>>> See https://pharo.fogbugz.com/f/cases/13892/Example-methods-should-be-runnable-… >>>> for a picture. >>>> >>>> >>>> SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON THE CLASS SIDE >>>> AND LET THE SELECTOR START WITH "example". >>>> >>>> This way people will easily see that it is an example and can run them. Additionally it >>>> would help to put them into a category like "examples". So be a good citized and >>>> provide not only class comments but also examples for others to study. >>>> >>>> >>>> Side note: >>>> ========== >>>> It is also possible to click on the icon of class side initialize methods so the >>>> class get reinitialized (after a confirmation to avoid false clicking). >>>> >>>> https://pharo.fogbugz.com/f/cases/13894/Class-side-initialize-methods-shoul… >>>> >>>> Both issues are already integrated. >>>> >>>> -- >>>> www.tudorgirba.com[http://www.tudorgirba.com] >>>> >>>> "Every thing has its own flow" >> >

Oct. 22, 2014

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by Alexandre Bergel

I am also not a big fan of using pragmas. To me, it looks like an ad hoc approach to have examples close to the class. In the same spirit: Why not having tests in the same class? Would it not be cool? Of course not. In Roassal we have a class for examples (similar to TestCase). Alexandre > Le 22-10-2014 Ã 14:51, Thierry Goubier <thierry.goubier(a)gmail.com> a Ã©crit : > > Hi all, > > by principle, I'd be against extending so much the pragmas... from a design point of view they look like #defines and macros, that is an additional language to learn, without a correct support of the tools (no debug on pragmas, non-obvious behavior triggers, search for pragma users difficult, not documented). > > Alexandre, your idea of infering properties from the source code looks a lot more interesting (and with a lot more potential). > > Thierry > > Le 22/10/2014 19:38, Alexandre Bergel a Ã©crit : >> Hi! >> >> I have doubt that #example: will be enough in the case of Roassal. >> Having a code example browser is indeed important and having a descent way to search for the examples is also important. I am thinking to stick to #example and infer some categories from the source code (e.g., if the method contains a Zinc class, then it may be categorized in network). >> >> >> Cheers, >> Alexandre >> >>> Le 22-10-2014 Ã 7:38, Torsten Bergmann <astares(a)gmx.de> a Ã©crit : >>> >>> Hi Tudor, >>> >>> that should be easy now: look at CompiledMethod>>#isExampleMethod which can be adopted as needed. >>> >>> Checking for the <example> pragma could be done this way: >>> >>> self pragmas anySatisfy: [:pragma | pragma keyword = #example ] >>> >>> but we should think first if this is enough. >>> >>> I already proposed to not only annotate with a pragma <example> but additionally give a category. >>> Like this: >>> >>> <example: 'Graphics'> >>> <example: 'Network'> >>> >>> This way we can easily build an example browser for our users where people can go through >>> their point of interest and browse the examples. >>> >>> Maybe we should also rethink pragmas (in Pharo 5.0?) in general to be more Smalltalk >>> like: >>> >>> <Example category: 'Graphics'> >>> >>> where Example is a real class in the system (!). One can even make it more explicit >>> then >>> >>> <ExampleCategory graphics> >>> >>> with ExampleCategory(class)>>graphics returning a translateable string. People can add >>> own categories and one easily knows about already available ones. >>> >>> >>> Now that classes can have properties in Pharo 4.0 already I would like to see a unification >>> for methods and classes here (with the general concept of an "Annotation" in our metamodel). >>> >>> In my opinion a method pragma is just a special form of annotating a method. >>> >>> And annotating classes is usefull as well (for instance you want to annotate a class with >>> the appropriate Table name in an ORM framework, ...) >>> >>> A comment (in a method or in a class) is also nothing more than a special annotation. >>> A class/method category is also an annotation. If unified a method or a class could >>> be in one or more categories. Even a break point for an expression is IMHO just an >>> annotation. >>> >>> Bye >>> T. >>> >>> >>> Gesendet: Mittwoch, 22. Oktober 2014 um 10:43 Uhr >>> Von: "Tudor Girba" <tudor(a)tudorgirba.com> >>> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >>> Betreff: Re: [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0 >>> >>> Hi Torsten, >>> >>> Thanks for this. This is indeed the way to go. >>> >>> Just to let you know, the example infrastructure is also being developed in the context of GT, so we have a healthy interest overlap which is great. Only in our case, the discovery of the example happens through an <example> pragma. Would it be possible to change your slice to use this pragma instead of the example* convention? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Wed, Oct 22, 2014 at 9:19 AM, Torsten Bergmann <astares(a)gmx.de> wrote:One addition I implemented for Nautilus is that one can run examples directly >>> in the browser just by clicking on class side example methods icons. >>> >>> See https://pharo.fogbugz.com/f/cases/13892/Example-methods-should-be-runnable-… >>> for a picture. >>> >>> >>> SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON THE CLASS SIDE >>> AND LET THE SELECTOR START WITH "example". >>> >>> This way people will easily see that it is an example and can run them. Additionally it >>> would help to put them into a category like "examples". So be a good citized and >>> provide not only class comments but also examples for others to study. >>> >>> >>> Side note: >>> ========== >>> It is also possible to click on the icon of class side initialize methods so the >>> class get reinitialized (after a confirmation to avoid false clicking). >>> >>> https://pharo.fogbugz.com/f/cases/13894/Class-side-initialize-methods-shoul… >>> >>> Both issues are already integrated. >>> >>> -- >>> www.tudorgirba.com[http://www.tudorgirba.com] >>> >>> "Every thing has its own flow" > >

Oct. 22, 2014

Re: [Pharo-users] Citizen example for manipulating a bibtex file

by Sven Van Caekenberghe

> On 22 Oct 2014, at 18:42, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > > Hi, > > Thanks again. I have a small script, using Citezen which does the trick. I can explore and modify the BibTeX File from the playground with this: > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > | bibFile bibliography bibStream bibOutputer | > bibFile := ((FileLocator documents / 'U/Libertadores/Grafoscopio') children > detect: [:each | each basename endsWith: 'bib' ]). > bibliography := CZBibParser parse: bibFile contents. > bibStream := '' writeStream. > 1 to: (bibliography size) do: [:index | > (((bibliography entries at: index) fields at: 2) key = 'shorttitle') > ifTrue: [ > (bibliography entries at: index) > key: ((bibliography entries at: index) fields at: 2) value]. > bibOutputer := CZBibtexOutputer new. > bibStream nextPutAll: > (bibOutputer entryToBibtexString: > (bibliography entries at: index)); cr.]. > bibliography. > bibFile writeStreamDo: [:stream | > stream nextPutAll: bibStream contents withUnixLineEndings ]. > bibStream contents. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Some constructive comments about your code (smaller is always better, especially for interactive snippets): - you can change the #detect: to [ :each | each extension = #bib ] - you can iterate directly over the entries with #do: as in bibliography entries do: [ :each | .. ] which saves you the #at: index - there are handy unary shortcuts for accessing elements, like #first, #second and so on (up to #ninth) which also save you parenthesis - you can also construct strings using the idiom String streamContents: [ :bibStream | .. ] Sorry, these jumped to me when I saw your code, I hope you don't mind ;-) > I will put some functionality inspired by this on my prototype this weekend. > > Cheers, > > Offray > > On 10/21/2014 01:20 AM, stepharo wrote: >> Check in the tools there is a bib writer. >> >> Stef >> >> On 21/10/14 03:33, Offray Vladimir Luna CÃ¡rdenas wrote: >>> Thanks Stef and Damien, >>> >>> I have this small script as a proof of concept: >>> >>> =================================== >>> | bibFile bibliography | >>> bibFile := ((FileLocator documents / 'U/Libertadores/Grafoscopio') >>> children >>> detect: [:each | each basename endsWith: 'bib' ]) contents. >>> bibliography := CZBibParser parse: bibFile. >>> 1 to: (bibliography size) do: [:index | >>> (((bibliography entries at: index) fields at: 2) key = 'shorttitle') >>> ifTrue: [ >>> (bibliography entries at: index) >>> key: ((bibliography entries at: index) fields at: 2) value >>> ]]. >>> bibliography. >>> =================================== >>> >>> Now I want to write back the corrected file to the .bib ... just >>> having problems finding which message does the job. I'll keep searching. >>> >>> Cheers, >>> >>> Offray >>> >>> On 10/16/2014 06:40 AM, Damien Cassou wrote: >>>> from Damien Pollet: >>>> >>>> You will need to load the .bib file from zotero (read the file however >>>> you like, then pass the stream to the CZ parser). You'll get a >>>> CZBibSet (I don't recall the name exactly) which represents the >>>> contents of the file. A Set is composed of entries, each of which has >>>> a key and a set of fields. Finally, fields accept a few different >>>> kinds of values. >>>> >>>> Your processing is just iterating a set then setting the key of each >>>> entry (or possibly removing and re-adding the entry, I don't recall if >>>> it's implemented like a dictionary or more like a list). >>>> >>>> >>>> On Mon, Oct 13, 2014 at 2:57 AM, Offray Vladimir Luna CÃ¡rdenas >>>> <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: >>>> >>>> Hi, >>>> >>>> I'm using a Zotero collection for keeping track of several >>>> references I have >>>> found for my article about the experience of the >>>> outline/tree-like metaphor >>>> for writing inside Pharo (as soon as I have a presentable >>>> working draft I >>>> hope to share it with you). >>>> >>>> Now I want to make a post-processing of the bibtex file exported >>>> from >>>> Zotero. The idea is to use "shorttitle" field instead to replace >>>> the Zotero >>>> auto-generated one and have custom keys. So for example instead of: >>>> >>>> ======= >>>> @misc{_holistic_????, >>>> title = {Holistic software assessment (Uni Zurich - >>>> 2011) on Vimeo}, >>>> shorttitle = {Girba-holistic-2011}, >>>> url = {http://vimeo.com/42073344?__from=outro-local >>>> <http://vimeo.com/42073344?from=outro-local>}, >>>> urldate = {2014-08-19}, >>>> note = {00000} >>>> } >>>> >>>> ======= >>>> >>>> >>>> I would like to have: >>>> >>>> >>>> ======= >>>> >>>> @misc{Girba-holistic-2011, >>>> title = {Holistic software assessment (Uni Zurich - >>>> 2011) on Vimeo}, >>>> shorttitle = {Girba-holistic-2011}, >>>> url = {http://vimeo.com/42073344?__from=outro-local >>>> <http://vimeo.com/42073344?from=outro-local>}, >>>> urldate = {2014-08-19}, >>>> note = {00000} >>>> } >>>> >>>> ======= >>>> >>>> >>>> I have already installed Citizen and open it on the browser to >>>> see the code, >>>> but I can find any place to start with examples. >>>> >>>> Any advice on how to solve this issue will be appreciated. >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> >>>> >>>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> "Success is the ability to go from one failure to another without losing >>>> enthusiasm." >>>> Winston Churchill >>>> >>> >>> >>> >> >> >> > >

Oct. 22, 2014