- Pharo-users - lists.pharo.org

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

by Richard Sargent

On Wed, Feb 27, 2019, 21:50 K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > > 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 ;-). > Or you could model it correctly. Formally define how packages extend classes and allow an arbitrary number of categories for any method. It's not you would be doing anything new. VA Smalltalk has been doing that for more and a quarter of a century. > 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] 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