- Pharo-users - lists.pharo.org

Re: [Pharo-users] About generating chapters with Pillar/Pier tools

by HernÃ¡n Morales Durand

2015-06-22 9:59 GMT-03:00 Damien Cassou <damien.cassou(a)inria.fr>: > > Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> writes: > > > Le 21/06/2015 05:21, HernÃ¡n Morales Durand a Ã©crit : > >> About instructions given here > >> > >> > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > >> > >> you do not need MinGW to export a Pier chapter. See here > >> https://github.com/biosmalltalk/biopharo/blob/develop/doc/pier2tex.bat > >> for an example > > > > We know that Pillar is not easy to use on Windows and we need to > > improve that, but for now we have a lot of work to do with Pillar and > > not enough time to do it. Using MinGW is only a temporary solution. > > > I asked Cyril to work on integrating what's currently in Bash scripts > inside Pillar itself (e.g.,, iterating over input files, generating pdf > from latex). This should make porting much easier (as well as creating > new Pillar-based projects). > > > >> Another (worst) situation happened when I wanted to convert a generated > >> LaTeX to PDF. I had to remove all tables, annotations and notes from the > >> .pier file because errors reported in pdfLaTeX . > >> > >> For tables : > >> > >> ! Undefined control sequence. > >> > >> l.176 \toprule > >> > > > > I'll try to take a look at that one. > > Can you send me a pillar file that raise this please ? > > > this one is related to a missing latex package in your latex template. > Add this to your LaTeX template (or use the default template Pillar > provides or use the template from > https://github.com/SquareBracketAssociates/EnterprisePharo/) > > \usepackage{booktabs} > > > My knowledge of LaTeX is minimal, so I didn't configured any template to generate my LaTeX file (I am using the stable build for 4.0). The .tex file is generated from Pillar code and I don't know what template is using. I just evaluated: Pharo.exe Pillar.image export --to=latex BioPharo.pier I will be happy to make it work for now, but it would be much better if anyonce could modify the generated .tex with needed packages so they are included by default in the .tex file and users like me can work with Pillar in an easier way. > >> For notes (i.e. @@note ) > >> > >> ! LaTeX Error: Environment note undefined. > >> > >> > >> See the LaTeX manual or LaTeX Companion for explanation. > >> > >> Type H <return> for immediate help. > >> > >> ... > >> > >> l.178 \begin{note} > > > each time you use @@XXXX, the LaTeX document will contain a > \begin{XXXX}. This means you have to create the environments you need. > So, if you write @@note in your Pillar document, you must add something > like this to your LaTeX template: > > > > \newenvironment{note}{\begin{center}\begin{minipage}{8cm}\hrule\vspace{0.2cm} > \textbf{Note:}}{\vspace{0.3cm}\hrule\end{minipage}\end{center}} > > Look here for what we use in EnterprisePharo: > > https://github.com/SquareBracketAssociates/EnterprisePharo/blob/master/supp… > > I will try to add it or switch to Linux, but as I said above if anyone with better knowledge of Pillar could check with the Pillar build it would be really cool :) Thank you Damien, HernÃ¡n > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

June 23, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Peter UhnÃ¡k

Thank you all for your answers (For whatever reason all replies by Torsten to this thread ended up as separate threads.. maybe mail client issues?) It seems that <sample> is then the go-to naming for now. I also like that the word starts differently so it's easy to differentiate them at a glance. On Mon, Jun 22, 2015 at 5:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > It is important to note that these methods COULD BUT > MUST NOT RETURN an instance. Usually such a method is only there to > demonstrate code. > I'm not sure I understand the purpose of this restriction. For example BorderedMorph>>exampleGradient could on top of opening a morph also return the instance. If you are running it from Nautilus it makes no difference, but when you run it manually you could also inspect the instance, so you could further manipulate with it... in a sense two-in-one. :) Otherwise you would have to get it via inspecting morph halos. Or in another sense you could either inspect <sample> and then manually run it, or execute <example> that would on top of that also return inspectable value of the <sample>. 2. returning examples > ===================== > While some example methods just demo code and code usage (like "Job > example" or "BorderedMorph exampleGradient") > a subset of them directly return an instance of the method defining > class (like LabelMorph>>example). > > The idea of the GT Tools is to call these methods and display the return > value as inspectable "instances" in the tools, > so for instance if you inspect class VirtualMachine or Character you get > a tab entitled "E.g." where you can click on > these sample instances. > > GT and (because GT )now latest Pharo currently still uses "gtExample" > method prefix or <gtExample> pragma to mark such methods and there > is also to wish to remove the "gt" prefix. But with this we would have a > clash with the other "exampleXXX" usage. > > => I would propose to mark the code examples that return an instance > with an <exemplar> method. > > According to Google definition of <exemplar> noun - "a person or > thing serving as a typical example or excellent model." > > Urban dictionary defines <exemplar> as "a typical or standard model > or specimen" > As a side note... I think it's best to use urban dictionary for slang, and not Pharo dev. :) Looking up the name of it there shows at least a bit of self-reflection. :) Peter

June 23, 2015

Re: [Pharo-users] About generating chapters with Pillar/Pier tools

by HernÃ¡n Morales Durand

2015-06-22 5:35 GMT-03:00 Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com>: > Le 21/06/2015 05:21, HernÃ¡n Morales Durand a Ã©crit : > > Hello, > > > > I have experimented several dissapointing errors when working with > > updated Pillar tools. I am not doing anything special besides working > > under Windows. > > > > Apparently the Pillar CommandLineHandler is not working because > > OSEnvironment exception (Windows 8.1). When executing > > > > Pharo.exe Pillar.image export --to=html BioPharo.pier > > > > The attached exception raises. > > This happens in all the images from: > > > > > https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=40,VERSION=stable,V… > > Pharo4.0 (Latest update: #40614) > > > https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=40,VERSION=developm… > > Pharo4.0 (Latest update: #40614) > > > https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=50,VERSION=stable,V… > > Pharo5.0 > > Latest update: #50124 > > > > Changing the method #baseDirectory to use %CD% environment variable > > doesn't fix it even when it works in command line: > > > > c:\MySmalltalkProjects\Pillar\pharo-vm>echo %PWD% > > %PWD% > > c:\MySmalltalkProjects\Pillar\pharo-vm>echo %CD% > > c:\MySmalltalkProjects\Pillar\pharo-vm > > > > The solution I found was to replace the OSEnvironment line with > > FileSystem workingDirectory as suggested at: > > > https://pharo.fogbugz.com/f/cases/15356/Pillar-command-line-script-doesn-t-… > > > > About instructions given here > > > > > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > > > you do not need MinGW to export a Pier chapter. See here > > https://github.com/biosmalltalk/biopharo/blob/develop/doc/pier2tex.bat > > for an example > > Hi! > We know that Pillar is not easy to use on Windows and we need to improve > that, but for now we have a lot of work to do with Pillar and not enough > time to do it. > Using MinGW is only a temporary solution. > > > > > Another (worst) situation happened when I wanted to convert a generated > > LaTeX to PDF. I had to remove all tables, annotations and notes from the > > .pier file because errors reported in pdfLaTeX . > > > > For tables : > > > > ! Undefined control sequence. > > > > l.176 \toprule > > > > I'll try to take a look at that one. > Can you send me a pillar file that raise this please ? > > > Sure, this is it : https://github.com/biosmalltalk/biopharo/blob/develop/doc/BioPharo.pier > > > > For notes (i.e. @@note ) > > > > ! LaTeX Error: Environment note undefined. > > > > > > See the LaTeX manual or LaTeX Companion for explanation. > > > > Type H <return> for immediate help. > > > > ... > > > > l.178 \begin{note} > > > > > > Same here, can you send me a file because I never saw this error with > @@note. > > Same file as above > > > Finally generated PDF looks different from previous versions. > > > > Previous Pillar version: > > > https://github.com/biosmalltalk/biopharo/blob/develop/doc/BioPharo.pier.pdf > > > > Current Pillar version (>= 0.56) : > > https://github.com/biosmalltalk/biopharo/blob/develop/doc/BioPharo.pdf > > > > This one is normal. We changed the way extensions was generated because > the previous way wasn't right. When we export a .tex to a .pdf we don't > want to have a file .tex.pdf, so when we want to export a .pillar to a > .tex we don't want to get a .pillar.pdf! > So we changed that. > It's ok, I was talking about the text appearance like fonts and code formatting. In previous version the code was formatted inside a grey box. > > > Now I am the only one generating PDF with Pillar in Windows? > > I do it but I use some script with MinGW for now or I use Pillar > directly from Pharo because the windows environment is not good for now. > > Thank you for the feedback, Cheers, HernÃ¡n

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Tudor Girba

Hi Torsten, By we, I mean the GT team. I thought this should have been quite clear given the gt prefix and where this code is packaged :). We do not want to keep it a secret, but we only go to the community when we have something significant to say. Sometimes the reaction takes a short time, sometimes it takes longer. In this case, it is longer. I promised to provide a summary of what we have in mind with examples, and I will do that. I just need a bit more time. Cheers, Doru On Mon, Jun 22, 2015 at 7:53 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Tudor Girba wrote: > >We are working on a more elaborate model for examples, but we need a bit > >more time to get to a rounder solution. > > Hi Doru, > > Sorry - but I think this is not acceptable as a satisfying answer: > > Remember that the GT extension <gtExample> was developed in parallel a > little too bit hidden. It got > then integrated as <example> shortly before release although Nautilus > already honored <example> similar > to exampleXXX methods. > > We ended up with the broken icon behavior, (over)heated discussion, > conflicting code and disagreement. > During the discussion you also requested that we should not treat GT as an > "Alien". But that requires > from your side to involve the community - also in future plans and ideas. > Pharo is yours the same as > any others. > > So please elaborate who is "we" and what you are working on/what is the > model looking > like. Making a plan or contributing to a discussion does not mean to have > something instantly > ready in good quality to prove own points ... > > > Ben wrote: > >Sorry. I'm going to have to play the native english speaker card here. > >I could live with it, but "examplar" just doesn't sound right for this. > > The word comes from latin "exemplum". I'm fine similar to Damien if > "sample" better fits english > language for the method name prefix and/or pragma: > > sampleA > ^ $A > > or > > characterSample > <sample> > ^ $A > > > Thanks > T. > > -- www.tudorgirba.com "Every thing has its own flow"

June 22, 2015

Re: [Pharo-users] Moose

by Tudor Girba

Hi, from/to are derived properties and they should describe the association. For example: FAMIXAccess>> from ^ self accessor FAMIXAccess>> to ^ self variable next/previous denote the position of the association in the code with respect to the other associations. For example, imagine this Pharo code: self doSomething. self doSomethingElse. you will get two FAMIXInvocations, and these can be linked through the previous property (next is derived). Does this make sense? Btw, these questions are better suited for the Moose mailing list: http://www.moosetechnology.org/#twitter Cheers, Doru On Mon, Jun 22, 2015 at 5:06 PM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: > Hi everybody, > > when working with the FAMIX meta model, one must implement the previous, > next, from and to methods for each class extending FAMIXAssosiation. > What is the diffence between previous/from and next/to? > if I make > MyFamixClass>>from > ^previous > the same information is displayed twice in the Moose panel (because both > methods are annotated with the MSEProperty in the superclass) > Who can one avoid that? > > Regards > > Abdelghani > -- www.tudorgirba.com "Every thing has its own flow"

June 22, 2015

<example> pragmas and example* methods use-cases

by Torsten Bergmann

Tudor Girba wrote: >We are working on a more elaborate model for examples, but we need a bit >more time to get to a rounder solution. Hi Doru, Sorry - but I think this is not acceptable as a satisfying answer: Remember that the GT extension <gtExample> was developed in parallel a little too bit hidden. It got then integrated as <example> shortly before release although Nautilus already honored <example> similar to exampleXXX methods. We ended up with the broken icon behavior, (over)heated discussion, conflicting code and disagreement. During the discussion you also requested that we should not treat GT as an "Alien". But that requires from your side to involve the community - also in future plans and ideas. Pharo is yours the same as any others. So please elaborate who is "we" and what you are working on/what is the model looking like. Making a plan or contributing to a discussion does not mean to have something instantly ready in good quality to prove own points ... Ben wrote: >Sorry. I'm going to have to play the native english speaker card here. >I could live with it, but "examplar" just doesn't sound right for this. The word comes from latin "exemplum". I'm fine similar to Damien if "sample" better fits english language for the method name prefix and/or pragma: sampleA ^ $A or characterSample <sample> ^ $A Thanks T.

June 22, 2015

Re: [Pharo-users] Moose

by Alexandre Bergel

Hi! I have never used the previous and next. No idea whether this is used or not. What are you trying to achieve? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 22, 2015, at 12:06 PM, abdelghani ALIDRA <alidrandco(a)yahoo.fr> wrote: > > Hi everybody, > > when working with the FAMIX meta model, one must implement the previous, next, from and to methods for each class extending FAMIXAssosiation. > What is the diffence between previous/from and next/to? > if I make > MyFamixClass>>from > ^previous > the same information is displayed twice in the Moose panel (because both methods are annotated with the MSEProperty in the superclass) > Who can one avoid that? > > Regards > > Abdelghani

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Ben Coman

On Tue, Jun 23, 2015 at 12:59 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Jun 22, 2015 at 11:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Peter, >> >> there was no agreement - so we rolled back for Pharo 4 to discuss/decide for Pharo 5. >> >> I communicated already how I would solve it to get IMHO a consistent and >> easy understandable solution: >> >> 1. executable example >> ===================== >> We talk about executable code here: an "example" in the traditional Smalltalk sense >> means ONLY a runnable piece of code to demonstrate something. Since a long time and not only in Pharo this >> is typically done in methods with prefix "example". It is important to note that these methods COULD BUT >> MUST NOT RETURN an instance. Usually such a method is only there to demonstrate code. >> >> These methods with the "example" in the name are currently honored by Nautilus with the >> clickable icon. See SystemProgressMorph>>exampleChangeLabel or others. >> >> => To not be limited to the prefix in the method name I proposed to be able >> to additionally use the <example> pragma to mark example methods. >> This way you can choose the method name freely to give an example to others >> on how to use them. >> >> 2. returning examples >> ===================== >> While some example methods just demo code and code usage (like "Job example" or "BorderedMorph exampleGradient") >> a subset of them directly return an instance of the method defining class (like LabelMorph>>example). >> >> The idea of the GT Tools is to call these methods and display the return value as inspectable "instances" in the tools, >> so for instance if you inspect class VirtualMachine or Character you get a tab entitled "E.g." where you can click on >> these sample instances. >> >> GT and (because GT )now latest Pharo currently still uses "gtExample" method prefix or <gtExample> pragma to mark such methods and there >> is also to wish to remove the "gt" prefix. But with this we would have a clash with the other "exampleXXX" usage. >> >> => I would propose to mark the code examples that return an instance with an <exemplar> method. >> >> According to Google definition of <exemplar> noun - "a person or thing serving as a typical example or excellent model." >> Urban dictionary defines <exemplar> as "a typical or standard model or specimen" >> >> So I proposed and still propose >> - "exampleXXX" prefixed methods and <example> pragma for traditional examples as used in other Smalltalks and Pharo before >> - "exemplarXXX" prefixed methods and <exemplar> pragma (mark code that return an instance always) for the future inspection >> of exemplars in the tools > > Sorry. I'm going to have to play the native english speaker card here. > I could live with it, but "examplar" just doesn't sound right for this. > > * Dictionary meanings are useful, but meaning can be skewed without > contemporary context. > * Dictionaries cover a lot of corner cases, some inherited from a > hundred years ago, and language evolves. They may remain technically > correct and understandable, but not sound "right". > * I've probably only seen the word used couple of times in my life, > never in this context. > * I notice its also a German word. I expect its hard to disassociate > from its common German usage. Sorry, after English stole it from > German, it probably corrupted it. > * Check its synonyms: "epitome, perfect example, shining example, > model, paragon, ideal...". This is its contemporary meaning and I > guess the returned sample won't be expected to be the "best most > perfect sample". It will just be "some sample" or a "basic sample" > for you to inspect. > * "Sample" is 2 characters shorter than "Exemplar" to fit in label of > the GT tab. I presume its useful to match the tab label with the > pragma. > > cheers -ben btw, I bumped into an interesting resource (which incidentally supports my case but is probably generally useful)... http://sentence.yourdictionary.com/exemplar

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Ben Coman

On Mon, Jun 22, 2015 at 11:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Peter, > > there was no agreement - so we rolled back for Pharo 4 to discuss/decide for Pharo 5. > > I communicated already how I would solve it to get IMHO a consistent and > easy understandable solution: > > 1. executable example > ===================== > We talk about executable code here: an "example" in the traditional Smalltalk sense > means ONLY a runnable piece of code to demonstrate something. Since a long time and not only in Pharo this > is typically done in methods with prefix "example". It is important to note that these methods COULD BUT > MUST NOT RETURN an instance. Usually such a method is only there to demonstrate code. > > These methods with the "example" in the name are currently honored by Nautilus with the > clickable icon. See SystemProgressMorph>>exampleChangeLabel or others. > > => To not be limited to the prefix in the method name I proposed to be able > to additionally use the <example> pragma to mark example methods. > This way you can choose the method name freely to give an example to others > on how to use them. > > 2. returning examples > ===================== > While some example methods just demo code and code usage (like "Job example" or "BorderedMorph exampleGradient") > a subset of them directly return an instance of the method defining class (like LabelMorph>>example). > > The idea of the GT Tools is to call these methods and display the return value as inspectable "instances" in the tools, > so for instance if you inspect class VirtualMachine or Character you get a tab entitled "E.g." where you can click on > these sample instances. > > GT and (because GT )now latest Pharo currently still uses "gtExample" method prefix or <gtExample> pragma to mark such methods and there > is also to wish to remove the "gt" prefix. But with this we would have a clash with the other "exampleXXX" usage. > > => I would propose to mark the code examples that return an instance with an <exemplar> method. > > According to Google definition of <exemplar> noun - "a person or thing serving as a typical example or excellent model." > Urban dictionary defines <exemplar> as "a typical or standard model or specimen" > > So I proposed and still propose > - "exampleXXX" prefixed methods and <example> pragma for traditional examples as used in other Smalltalks and Pharo before > - "exemplarXXX" prefixed methods and <exemplar> pragma (mark code that return an instance always) for the future inspection > of exemplars in the tools Sorry. I'm going to have to play the native english speaker card here. I could live with it, but "examplar" just doesn't sound right for this. * Dictionary meanings are useful, but meaning can be skewed without contemporary context. * Dictionaries cover a lot of corner cases, some inherited from a hundred years ago, and language evolves. They may remain technically correct and understandable, but not sound "right". * I've probably only seen the word used couple of times in my life, never in this context. * I notice its also a German word. I expect its hard to disassociate from its common German usage. Sorry, after English stole it from German, it probably corrupted it. * Check its synonyms: "epitome, perfect example, shining example, model, paragon, ideal...". This is its contemporary meaning and I guess the returned sample won't be expected to be the "best most perfect sample". It will just be "some sample" or a "basic sample" for you to inspect. * "Sample" is 2 characters shorter than "Exemplar" to fit in label of the GT tab. I presume its useful to match the tab label with the pragma. cheers -ben

June 22, 2015

Re: [Pharo-users] <example> pragmas and example* methods use-cases

by Tudor Girba

Hi, We are working on a more elaborate model for examples, but we need a bit more time to get to a rounder solution. Cheers, Doru On Mon, Jun 22, 2015 at 12:49 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-06-22 12:03 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hi, >> >> there was a long discussion about the meaning of example* methods and >> <example> pragmas, however I do not know what was the final resolution. >> >> Basically I am interested in two use-cases >> >> 1. executable example (the one where Nautilus shows nice play icon) >> This is as I understand only through example* naming (on class-side). >> > > Yes, but I would like to use a pragma again and don't rely naming > convention, we just wasn't able to agree on one. > > >> >> 2. returning examples (example that returns some value that I can reuse) >> Is this what <example> pragma is for? How would I go about naming it >> considering that having play icon there would be counter-productive (user >> would be clicking on it and nothing would happen). >> > > Inspector and spotter use gtExample* names in addition to an <gtExample> > pragma. > <gtExample> -> for finding those methods > gtExample*name -> for not getting the play icon. > > This is less than perfect. > > >> >> Thanks, >> Peter >> > > -- www.tudorgirba.com "Every thing has its own flow"

June 22, 2015