February 2019 - Pharo-users

Re: [Pharo-users] Why is #findString: in accessing?

by K K Subbu

On 28/02/19 5:23 AM, Richard O'Keefe wrote: > It is surprisingly hard to keep categories consistent.Â If there is > a way to say "here I am browsing method M in category G of class C, > is there an ancestor of C that puts the selector of M in a different > category?" I would love to know it.Â (Adding such a code critic to > my Smalltalk is on the TODO list.) > Richard, There is Browser>>#categorizeAllUncategorizedMethods that works this way in Squeak but for uncategorized methods. But then, a tag-set would be more useful than just single categorization. It doesn't matter how accurate a category is, there will always be someone who will find an equally justifiable reason for putting a method into a different category ;-). Is it possible to have a pragma or dummy method (say tags:) to list tags that could be extracted to facilitate searches? It should not have any runtime impact. Regards .. Subbu

Feb. 28, 2019

Re: [Pharo-users] JSON keys not quoted?

by Richard O'Keefe

If numeric keys are silently written as strings when generating JSON, you can get JSON that is technically legal but practically ambiguous. Start with the obvious: (Dictionary new: 2) at: 1 put true; at: '1' put false; asJson => {"1": true, "1": false}. More subtly, d := Dictionary new: 2. d at: 1.0 put: true. d at: 1.0 successor put: false. FloatPrintPolicy value: InexactFloatPrintPolicy new during: [d asJson] => {"1.0": true, "1.0": false}. All things considered, *not* accepting numeric keys seems like the best thing to do. On Sat, 23 Feb 2019 at 09:23, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > If you convert a Dictionary with numbers as keys it will produce not > valid JSON [1], since all object keys must be quoted. > > E.g. > NeoJSONWriter toString: (Dictionary with: 1->'foo'). > or > (Dictionary with: 1->'foo') asJson > > Should the library generate quoted keys? > > Seaside's WAJsonCanvas is manual, so it is up to the developer to > render the object properly, but NeoJSON does it automatically. > > In Javascript this will throw a syntax error: > > JSON.parse('{1: "foo"}') > > And this would generate a quoted key when serialized: > > JSON.stringify({1: "foo"}) > > {"1": "foo"} > > So my question is: should the library quote whatever you put as key in > order to produce valid JSON syntax? [2] > > Regards. > > [1] https://jsonlint.com/ > [2] https://www.ecma-international.org/publications/standards/Ecma-404.htm > > Esteban A. Maringolo > >

Feb. 28, 2019

Re: [Pharo-users] Teapot or Zinc adding extra node to JSON POST

by BrunoBB

Esteban, You are right !, the client is the culprint :) Regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 27, 2019

Re: [Pharo-users] Why is #findString: in accessing?

by Richard O'Keefe

In my own Smalltalk, a string understands a little over two thousand selectors, of which about 440 are specific to strings, the others being shared by other sequences. That's quite a lot to search through. As it happens, I *do* have a 'searching' category and the #findString:[startingAt:][ignoringCase:][ifAbsent:] methods are in it. The methods defined in the ANSI Smalltalk standard are #indexOfSubCollection:startingAt:[ifAbsent:] and are quite easy to find once you recall that methods for searching in a sequence generally have 'find' or 'indexOf' in their name. It is surprisingly hard to keep categories consistent. If there is a way to say "here I am browsing method M in category G of class C, is there an ancestor of C that puts the selector of M in a different category?" I would love to know it. (Adding such a code critic to my Smalltalk is on the TODO list.) On Tue, 26 Feb 2019 at 00:20, Tim Mackinnon <tim(a)testit.works> wrote: > I always struggle (even after years of casually using smalltalk) to find > the String methods that do the heavy lifting (and are comparable to other > languages). The methods are normally there, but they often have names that > donât compare well with other languages. > > I think that what doesnât help is the categorisation of methods in String > - for example - if I want to do some searching in a String - why is > #findString: in âaccessingâ - I totally didnât think to look in there. To > be honest, I really wanted a protocol called âsearchingâ - but its not > there? > > I find the protocols in the system to be pretty bad in all honesty. Its a > good idea, but I donât think its clear on whether its protocol, or > category. And if the former - where are the tools to help ensure things > conform to a protocol? If the latter - where are the useful, commonly used > categories? > > Are there any plans to do anything in this area - or is it just a lump it > scenario? > > Tim >

Feb. 27, 2019

Re: [Pharo-users] Teapot or Zinc adding extra node to JSON POST

by Esteban Maringolo

I can't speak for Teapot, but I can tell you that the extra "body" container object is not standard for JSON/REST API's. Are you certain that it isn't the client who's adding such container to the request? Regards, Esteban A. Maringolo El miÃ©., 27 feb. 2019 a las 18:56, BrunoBB (<smalltalk(a)adinet.com.uy>) escribiÃ³: > > Hi, > > Using Teapot (which uses Zinc) i found something i do not know if it is a > standard or done on purpose or a bug. > > A Teapot service (POST) accept a JSON entry. In the client the 'body' is set > with the JSON. > > In the server the ZnRequest contents insert a JSON node 'body' to the > original JSON. > > The original JSON POST is: {name: "John", age: 31, city: "New York"} > > At server ZnRequest contents JSON is: {"body":{name: "John", age: 31, city: > "New York"}} > > Is this done on purpose by Zinc ? > > I try to find if it is a standard in JSON communications but with no luck > yet ! > (these are first steps on JSON so maybe is a newbie question :) > > regards, > bruno > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Feb. 27, 2019

Teapot or Zinc adding extra node to JSON POST

by BrunoBB

Hi, Using Teapot (which uses Zinc) i found something i do not know if it is a standard or done on purpose or a bug. A Teapot service (POST) accept a JSON entry. In the client the 'body' is set with the JSON. In the server the ZnRequest contents insert a JSON node 'body' to the original JSON. The original JSON POST is: {name: "John", age: 31, city: "New York"} At server ZnRequest contents JSON is: {"body":{name: "John", age: 31, city: "New York"}} Is this done on purpose by Zinc ? I try to find if it is a standard in JSON communications but with no luck yet ! (these are first steps on JSON so maybe is a newbie question :) regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 27, 2019

Re: [Pharo-users] Mac OS X test [ smaller image ]

by Hilaire

Hi, I have a build script too to build the drgeo bundle from scratch [1], I will take a look yours to add up. In the mean time I built a new mac os bundle with your info.plist. I tested it on a mac, but without privilege to move it to the Applications location. After downloading it to the Desktop folder, I can experiment: 1. Double click on the app does not work 2. From a shell, "Desktop/DrGeo.app/Contents/MacOS/Pharo" starts DrGeo fine, without error, locale is correctly detected 3. Double click again on the app starts it this time, but I got a funny error message: "error with stdout does not exist, force recursive file creation, filename "stdout" Can someone with privilege to the Application location, test this new DrGeo bundle[2]? THANKS ! I own you free meals for the help. [1] https://bazaar.launchpad.net/~drgeo-developers/drgeo/trunk/view/head:/build… [2] https://www.dropbox.com/s/gbey77opzpw143a/DrGeo-mac-19.03a.zip?dl=0 Le 26/02/2019 Ã 21:09, Christophe Demarey a Ã©critÂ : > Basically, it is where you design the UI part of the app. In our case, it is just the menu of the main app. > >> I noted the Info.plist is a lot shorter in PharoLauncher compared to the >> Mac OSX VM zip archive one, though. >> >> Any reason? > I removed useless entries like associations files type / icons > > Also, what I pointed is to build a dmg used to deliver the app. > Building of the application is done through a shell script: https://github.com/pharo-project/pharo-build-scripts/blob/master/build-plat… > > you could use it to package your image / vm / ressources in an app bundle. > > > > -- Dr. Geo http://drgeo.eu

Feb. 27, 2019

Re: [Pharo-users] Pharo consortium selected for GSOC 2019

by N. Bouraqadi

Thank you guys for the energy you put into this :-) Noury > On 26 Feb 2019, at 12:56, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Dear all, > > Pharo Consortium has been selected this year as a Google Summer of Code 2019 mentor organization. This is the first time since 2017. > > I would like to thank other GSOC co-admin Jigyasa Grover and Oleksandr Zaytsev for their commitment and hard work, Peter Uhnak for his help for the website, Alexandre Bergel, Yuriy Tymchuk and StÃ©phane Ducasse for their interactions. > <> > > We will prepare the call for students soon. We have already a website with a list of subject: http://gsoc.pharo.org/ <http://gsoc.pharo.org/> > > More subjects can be added, but we will focus on topics that will have the bigger impact on the Pharo community. > > We will use the #gsoc-planning channel on Discord to discuss. > If you have students that might be interested, please let them know about this opportunity. There is #gsoc-students channel for them. > > Regards, > -- > Serge Stinckwich > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University (SU) > French National Research Institute for Sustainable Development (IRD) > University of YaoundÃ© I, Cameroun > "Programs must be written for people to read, and only incidentally for machines to execute." > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich>

Feb. 27, 2019

Re: [Pharo-users] NeoJSON mapping question

by BrunoBB

Hi Sven, Excellent !!! That exactly what i want. As an excuse i will say i'm one day old with NeoJSON :) mapping decoder: [:x | ] plus #atPath: made my day ! Thanks very much for you clear response. regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 27, 2019

Re: [Pharo-users] The confusing state of SUnit

by Tim Mackinnon

No - my point is, why are the basics for reasonable testing not in the image? Such that tests are easy, and a joy to write where failures are obvious when they occur. We seem to have 2 extremes - assert:equals: does a lovely job of showing what it expects and you got with a nice diff view (that is fab) - then the other extreme of testing an exception message which is unfathomableâ¦. Iâm not asking for all the esoteric combinations - but a good foundation to build tests on should be in the image. Extra bells and wistles should be easy to load for more advanced testing. (We kind of have that, but its spread across multiple projects that might be consolidat-able). SUnit is now 30 years old - advancements have been made, and the other xUnit derivatives now all do a much better job than us which makes me very sad. As mentioned, we do equality (and inequality) well, collection equality looks good too - exception testing is present but not good enough. I also argue that "greater and less than" are common, as are some basic collection checks (notably String begins, ends, contains and regex). I agree with the argument that we donât want to bloat the image - but doing the above well is so important to ensure we can easily write great tests, particularly when we find a problem and want to whip up at test to help understand how to solve it (many of our tests in the image are not as helpful as they could be). Is there at least some agreement to sorting this out? Could we put it on the 8.0 roadmap (its a tiny win, and quite easy to do - although cleaning up the old tests to use better features is a harder job - but worth it IMHO). This all comes out of my casual work on Exercism, which is about teaching people how to use a core language/environment and demonstrate how amazing that environment is. In many respects our advancements show case well : - zero conf lets us get an environment up and running in peoples hands in less than a minute (I donât think many of the other 30 language on there can do this) - git/tonel/zinc lets us play nicely with their cloud based platform - opal/moldable debugger/undeclared variables lets us do TDD as it was meant to be - iceberg (and GitHub) lets us create a project where community contribution is easy I think we still fall a bit short in our IDE (not faulting Calypso - its still work in progress and needs more help), testing (as per above), language documentation (we have too much old out of date stuff). The good far outweighs the needs improvement, but the journey is still ongoing. Tim > On 27 Feb 2019, at 07:29, jtuchel(a)objektfabrik.de wrote: > > So you are suggesting an extension of SUnit. Great. You just forgot to attach your code ;-) > > BTW: I think the current imnplementations of SUnit already carry a large amount of pollution. Just because JUnit and friends introduced special methods for testing equality and such, we also have this noise in SUnit. > This is not to say your suggestion would be useless. Just make a proposal and let's discuss. > > > Joachim > > > Am 27.02.19 um 01:14 schrieb Tim Mackinnon: >> Forgive me father, for I have sinnedâ¦ but when I try to right good tests, that fail in a way I can understand them it seems that SUnit doesnât want to help meâ¦ >> >> Maybe I am missing something, but in 2019 it should be easy to write tests - particularly when we want people to contribute to adding more? >> >> So when I want to right a test to assure that Iâve thrown an exception with the right message, why is it so hard (in the core image)? Am I missing something obvious? >> >> My example model is supposed to throw a DomainException with a message indicating that the strings :are of different lengthsâ - I search Sunit and hit: >> >> >> #should: raise: whoseDescriptionDoesNotInclude: description: >> >> Awesome, so it fails - but does it make it easy to know what damn string I gotâ¦.. nooooo that would be too easy? Its almost impossible to easily see what happened the way it works. >> >> Instead I have to write: >> >> self >> should: [ hammingCalculator distanceStrand1: 'AATG' strand2: 'AAA' ] >> raise: DomainError >> withExceptionDo: [ :ex | >> self assert: ex messageText equals: 'left and right strands must be of equal length' ]. >> >> >> And god forbid if I want to just ensure that the beginning of my error message is correct? >> >> Why do we make this so hard? I know we donât want to pollute the image, but testing is important, it should be easy for obvious cases and it should be more built in and less obscure. Is there something built in that makes this easier? Do I really have to load in more libraries for the easy cases? >> >> Tim >> >> >> > > -- > ----------------------------------------------------------------------- > 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 > > >

Feb. 27, 2019