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

[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, jtuc...@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….. no 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:jtuc

Re: [Pharo-users] NeoJSON mapping question

[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

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

[N. Bouraqadi]

Thank you guys for the energy you put into this :-)

Noury

> On 26 Feb 2019, at 12:56, Serge Stinckwich  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/ 
> 
> 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 

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

[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/makeDrGeo.sh

[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-platform.sh
>
> you could use it to package your image / vm / ressources in an app bundle.
>
>
>
>
-- 
Dr. Geo
http://drgeo.eu

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

[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

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

[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 () 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
>

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

[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  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
>

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

[BrunoBB]

Esteban,

You are right !, the client is the culprint :)

Regards,
bruno



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[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 
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
>
>

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

[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

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

[Richard Sargent]

On Wed, Feb 27, 2019, 21:50 K K Subbu  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
>
>