- Pharo-users - lists.pharo.org

Re: [Pharo-users] name selector

by stepharo

On 26/5/14 19:19, Sven Van Caekenberghe wrote: > Object>>#name should be removed, +1 > it is possible, I tried it once. > Most senders of #name are asking for the name of a class. > > On 26 May 2014, at 18:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Do I understand correctly that name is to be understood as inspectorName >> and so should never be implemented as subclass responsibility? >> >> Stephan >> > >

May 28, 2014

Re: [Pharo-users] NeoJSON mapping of nil properties

by Sven Van Caekenberghe

Hi Esteban, Your wish is my command ;-) In #bleedingEdge you can now do: String streamContents: [ :stream | (NeoJSONWriter on: stream) writeNil: true; mapAllInstVarsFor: Point; nextPut: Point new. which will give you: {"x":null,"y":null} instead of: {} which remains the default. === Name: Neo-JSON-Core-SvenVanCaekenberghe.28 Author: SvenVanCaekenberghe Time: 28 May 2014, 8:52:57.799163 pm UUID: d6927f86-5b87-4ba2-99c1-cfe5b58ed22f Ancestors: Neo-JSON-Core-SvenVanCaekenberghe.27 Added NeoJSONWriter #writeNil property, defaulting to false; when true, nil instance variables will be written as null by NeoJSONPropertyMapping, else they will be skipped === Name: Neo-JSON-Tests-SvenVanCaekenberghe.25 Author: SvenVanCaekenberghe Time: 28 May 2014, 8:54:10.767617 pm UUID: f1479d45-8d24-4bf6-b29a-aaf9f984c084 Ancestors: Neo-JSON-Tests-SvenVanCaekenberghe.24 Added NeoJSONWriterTests>>#testPointWriteNil Added NeoJSONWriter #writeNil property, defaulting to false; when true, nil instance variables will be written as null by NeoJSONPropertyMapping, else they will be skipped === I hope this works for you. Regards, Sven On 28 May 2014, at 18:06, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi all... and Sven ;-) > > I'm mapping my objects with NeoJSONWriter, and I found it is not writing the properties whose values are null. > > NeoJSONPropertyMapping>>#writeObject: anObject on: jsonMapWriter > | value | > value := getter value: anObject. > value > ifNotNil: [ jsonMapWriter writeKey: propertyName value: value as: valueSchema ] > > > It is a good default (saves space, and cpu cycles). But in my case the consumer of the JSON objects expect the objects to have all the attributes previously defined. > > Is there a way I can configure the mapper or the mapping to write null when the value is nil? > > Thank you! > > > Esteban A. Maringolo

May 28, 2014

Re: [Pharo-users] [smallwiki] Pillar annotations for Latex

by Ben Coman

Ben Coman <mailto:btc@openInWorld.com> 24 May 2014 4:51 pm I discovered that instead of modifying PRLaTeXCommand>>name: , that in PRLaTeXWriter>>visitAnnotatedParagraph: I could do... 'dothis' = anAnnotatedParagraph annotation asLowercase ifTrue: [ canvas newLine. "<----THIS LINE ADDED" ^ canvas command name: 'dothis' ; parameter: [ super visitAnnotatedParagraph: anAnnotatedParagraph ] ]. which seems better, but maybe still not the best. cheers -ben > Damien Cassou <mailto:damien.cassou@gmail.com> > 24 May 2014 8:24 pm > > > > that's the right way I guess, thank you for your contribution. Please > add related unit tests. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > I started looking into the unit tests and it is interesting how the tests seem to be structured to align with the visitor pattern, with PRDocumentWriterTest defining many tests once which refer to methods returning requirements-strings that are overridden in subclasses. Now PRDocumentWriterTest currently has no test for annotations, and PRMarkdown>>visitAnnotatedParagraph: says "Pier seems to lack consistency here ...", so I thought I might have a go at ironing that out. To learn a bit more about the system I tried each of the exporters and found a problem with comments where they break lists, which is a bit constraining. This can be demonstrated with the following file "test.pier"... nesting test # item 1 ## item 11 ## item 12 % comment 1 ## item 13 with the shell command... pharo pillar.image pillar export --to=pillar test.pier which produces... nesting test # item 1 ## item 11 ## item 12 % comment 1 # ## item 13 which is different from the original with the addition of the second last line. I would expect the output to be the same. Tracing through, I observe the #add: in the last line of... PRCommentedLine class >> parse: aString with: aParser | stream content | stream := aString readStream. stream next: self markup size. content := stream upToEnd. ^ aParser add: (self content: content) puts the CommentedLine under the first level of the PRDocument and a new OrderedList is created (Figure 1 - Before). Now by changing that last line to... ^ aParser addNested: (self content: content) the CommentedLine is placed under the ListItem and a new OrderedList is not created (Figure 1 - After), and --to=pillar produces... nesting test # item 1 ## item 11 ## item 12 % comment 1 ## item 13 identical to the original. In the attached MCZ I added... PRDocumentParser >> addNested: anObject self addNested: anObject to: self document PRDocumentParser >> addNested: anObject to: aGroup aGroup children isEmpty ifTrue: [ ^ aGroup add: anObject ]. aGroup children last isGroup ifTrue: [ ^ self addNested: anObject to: aGroup children last ] . ^ aGroup add: anObject. PRDocumentItem >> isGroup ^false PRDocumentGroup >> isGroup ^true For completeness, here are the other output formats. --to=markdown before produces... nesting test 1. item 1 1. item 11 2. item 12 1. 1. item 13 --to=markdown after produces... nesting test 1. item 1 1. item 11 2. item 12 3. item 13 --to=text before produces... nesting test 1. item 1 1. item 11 2. item 12 1. 1. item 13 --to=text after produces... nesting test 1. item 1 1. item 11 2. item 12 3. item 13 --to=latex before produces... \begin{document} nesting test \begin{enumerate} \item item 1 \begin{enumerate} \item item 11 \item item 12 \end{enumerate} \end{enumerate} \begin{enumerate} \item \begin{enumerate} \item item 13 \end{enumerate} \end{enumerate} \end{document} --to=latex after produces... \begin{document} nesting test \begin{enumerate} \item item 1 \begin{enumerate} \item item 11 \item item 12 \item item 13 \end{enumerate} \end{enumerate} \end{document} --to=html before produces... <div class="container"> <p>nesting test</p> <ol><li> item 1 <ol> <li>item 11</li> <li>item 12</li> </ol> </li></ol> <ol><li> <ol><li>item 13</li></ol> </li></ol> </div> --to=html after produces... <div class="container"> <p>nesting test</p> <ol><li>item 1 <ol> <li>item 11</li> <li>item 12</li> <li> item 13</li> </ol> </li></ol> </div> So, thats a small start. Anything obvious it might break? cheers -ben

May 28, 2014

Re: [Pharo-users] Two suggestions for the new pharo website

by Arturo Zambrano

Stef sent me this url https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? I think it cover part of your second point. regards art On Mon, May 26, 2014 at 7:52 AM, kmo <voxkmp(a)gmail.com> wrote: > I think the new pharo website could be improved by the addition of two new > pages. > > Firstly, the site badly needs a "Success Stories" page. The old web site > had > one of these so presumably that can be added easily. You have to show > newcomers that pharo can be used for something real. Look at the/ meteor/ > website https://www.meteor.com/main. Meteor isn't even at version 1.0 yet > but already boasts a impressive gallery of applications. > > Secondly, a list of all the packages in the Configuration Browser with a > proper description of what they do would be helpful. It would give > newcomers > the idea that pharo is a comprehensive solution to their development needs. > it also would provide newcomers with some kind of guide to the pharo > ecosystem - how is anybody supposed to know what Aconacqua or Chalten is > meant to do? Pharo has quite an impressive list of add-ons in the > configuration browser but what's the point if no one knows what they do? > > > > > > -- > View this message in context: > http://forum.world.st/Two-suggestions-for-the-new-pharo-website-tp4760379.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

May 28, 2014

NeoJSON mapping of nil properties

by Esteban A. Maringolo

Hi all... and Sven ;-) I'm mapping my objects with NeoJSONWriter, and I found it is not writing the properties whose values are null. NeoJSONPropertyMapping>>#writeObject: anObject on: jsonMapWriter | value | value := getter value: anObject. value ifNotNil: [ jsonMapWriter writeKey: propertyName value: value as: valueSchema ] It is a good default (saves space, and cpu cycles). But in my case the consumer of the JSON objects expect the objects to have all the attributes previously defined. Is there a way I can configure the mapper or the mapping to write null when the value is nil? Thank you! Esteban A. Maringolo

May 28, 2014

Re: [Pharo-users] the mystery of dirty package

by Goubier Thierry

Hi Usman, look if the loaded package has overrides on other packages. If yes, it will dirty them, and looking for changes will clean them. Thierry Le 28/05/2014 15:59, Usman Bhatti a Ã©crit : > Hi, > > It is second time in a week that I have to analyze a problem related to > a package getting dirty because of loading another package. But when > looking for changes, the first package becomes clean again. > > > One occurrence of the problem can be seen in the latest moose image: > - download the latest image here:https://ci.inria.fr/moose/job/moose-5.0/ > - monticello browser -> Collections-Abstract -> changes and the package > becomes clean. > > Any idea how to determine which method(s) from the incoming package > might be causing changes in the loaded package? Or generally, how to go > about correcting this problem? > > usman > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 28, 2014

the mystery of dirty package

by Usman Bhatti

Hi, It is second time in a week that I have to analyze a problem related to a package getting dirty because of loading another package. But when looking for changes, the first package becomes clean again. One occurrence of the problem can be seen in the latest moose image: - download the latest image here:https://ci.inria.fr/moose/job/moose-5.0/ - monticello browser -> Collections-Abstract -> changes and the package becomes clean. Any idea how to determine which method(s) from the incoming package might be causing changes in the loaded package? Or generally, how to go about correcting this problem? usman

May 28, 2014

Re: [Pharo-users] Finding methods sending shouldBeImplemented within a package

by Camille Teruel

Here is the bug entry & the fix: https://pharo.fogbugz.com/f/cases/13281/Wrong-environment-when-browsing-sco… On 28 mai 2014, at 14:08, Camille Teruel <camille.teruel(a)gmail.com> wrote: > You can right click on your package and select "browse scoped". > Then senders/implementors queries and refactorings will be scoped to your package (modulo a bug that includes unrelated trait methods that I need to fix :) ). > > > On 28 mai 2014, at 13:57, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > >> Hi, >> >> I am working on some NativeBoost bindings to a library. I am organizing >> my work along the API of a java binding of the same library. As nights >> go by, I created some methods that I didn't have yet use for as "self >> shouldBeImplemented", writing the others with test first. >> >> What is the easiest way to find all methods sending shouldBeImplemented >> in my package? >> >> Best regards, >> Markus >> >

May 28, 2014

Re: [Pharo-users] Finding methods sending shouldBeImplemented within a package

by Camille Teruel

You can right click on your package and select "browse scoped". Then senders/implementors queries and refactorings will be scoped to your package (modulo a bug that includes unrelated trait methods that I need to fix :) ). On 28 mai 2014, at 13:57, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > Hi, > > I am working on some NativeBoost bindings to a library. I am organizing > my work along the API of a java binding of the same library. As nights > go by, I created some methods that I didn't have yet use for as "self > shouldBeImplemented", writing the others with test first. > > What is the easiest way to find all methods sending shouldBeImplemented > in my package? > > Best regards, > Markus >

May 28, 2014

Re: [Pharo-users] Finding methods sending shouldBeImplemented within a package

by Benjamin

Open Nautilus, right click on your package, âChoose Open restricted browserâ It would open a new Nautilus scoped to your package. Then in the code pane, just type âshouldBeImplementedâ, select the text and right click, and finally select 'Implementors' Ben On 28 May 2014, at 13:57, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > Hi, > > I am working on some NativeBoost bindings to a library. I am organizing > my work along the API of a java binding of the same library. As nights > go by, I created some methods that I didn't have yet use for as "self > shouldBeImplemented", writing the others with test first. > > What is the easiest way to find all methods sending shouldBeImplemented > in my package? > > Best regards, > Markus >

May 28, 2014