February 2019 - Pharo-users

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

by jtuchel＠objektfabrik.de

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

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

by Gabriel Cotelli

We have some extensions in Buoy just for that. https://github.com/ba-st/Buoy/blob/release-candidate/docs/SUnit.md On Tue, Feb 26, 2019, 21:15 Tim Mackinnon <tim(a)testit.works> wrote: > 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 > > >

Feb. 27, 2019

The confusing state of SUnit

by 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

Feb. 27, 2019

Re: [Pharo-users] NeoJSON mapping question

by Sven Van Caekenberghe

> On 26 Feb 2019, at 22:23, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > El mar., 26 feb. 2019 a las 17:57, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: > >> PS: Note also that mappings can live on the class side (where they are global), but also inside specific NeoJSONReader instances (where they are local), like here. > > This postscript should be a whole section in the docs, I remember it > took me some time to fully understand this, and how flexible this > could be. > > Also I found confusing the semantics of the selectors and variable for > mapping/mapper, because it is the `mapping` that adds a new mapping > (e.g. #mapAccessor:). > But this might be just me. Well, terminology is hard, to come up with, to communicate, etc. I certainly don't think that the situation is perfect. Both a reader and a writer are a mapper, because they (might) need to convert to/from types called schemas. (They might not need it if they only use Arrays and Dictionaries). A schema is either a real class name, or just an abstract name to refer to (that last use is more for reading, like ArrayOfPoints, because the concept of a typed collection does not exist in Pharo, although there is also #nextPut:as:). When you map a schema, you describe how it is read/written. You do that either with a very general block (custom mapping) or according to the common Pharo model (object mapping: a Pharo object/class with named properties). In that last case, there is indeed a second level of mapping: that of the properties making up the object/class. Here you find mapAccessors, mapInstVars, etc (see the protocol mapping & convenience of NeoJSONObjectMapping). A key issue is that (especially when reading) schema/type information must be passed along (again because the concept of type of an instance variable does not exist in Pharo). Especially collections are hard to map. Some JSON is very dynamic in nature and does not follow a strict static structure of types. > Regards!

Feb. 26, 2019

Re: [Pharo-users] NeoJSON mapping question

by Esteban Maringolo

El mar., 26 feb. 2019 a las 17:57, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > PS: Note also that mappings can live on the class side (where they are global), but also inside specific NeoJSONReader instances (where they are local), like here. This postscript should be a whole section in the docs, I remember it took me some time to fully understand this, and how flexible this could be. Also I found confusing the semantics of the selectors and variable for mapping/mapper, because it is the `mapping` that adds a new mapping (e.g. #mapAccessor:). But this might be just me. Regards!

Feb. 26, 2019

Re: [Pharo-users] NeoJSON mapping question

by Sven Van Caekenberghe

Bruno, What about the following ? json := '{ "id" : 1, "level1" : { "level2" : { "name" : "foo" } } }'. In the JSON above there is a nesting level1.level2.name that you want to skip over. One solution would be: NeoJSONReader new on: json readStream; for: #Foo customDo: [ :mapping | mapping decoder: [ :x | (x at: #id) -> (((x at: #level1) at: #level2) at: #name) ] ]; nextAs: #Foo. The returned type is an Association, but it could be a domain object. #Foo is just an identifier. The disadvantage is that anything deeper is not mapped, but comes in as a plain dictionary, in a sense defeating the concept of mapping (but for leaf like structures this might be what you want). Alternatively, if you use NeoJSONObject instead of Dictionary, it becomes easier to access a nested path: NeoJSONReader new on: json readStream; mapClass: NeoJSONObject; for: #Foo customDo: [ :mapping | mapping decoder: [ :x | (x at: #id) -> (x atPath: #(level1 level2 name)) ] ]; nextAs: #Foo. HTH, Sven PS: Note also that mappings can live on the class side (where they are global), but also inside specific NeoJSONReader instances (where they are local), like here. > On 26 Feb 2019, at 03:50, BrunoBB <smalltalk(a)adinet.com.uy> wrote: > > Hi, > > The following implementation do what i want without the need to create a > class for each level of the JSON, however i really dislike my solution. > neoJsonMapping: mapper "class side" > "Map the receiver to a json with <NeoJSONObjectMapping> <mapper>" > mapper for: self do: [ :mapping | > (mapping mapProperty: 'booking' getter: [:obj | obj locator] setter: [ > :obj :value | obj setLocator: value]) valueSchema: self. > ]. > > mapper for: self do: [ :mapping | > mapping mapProperty: '@locator' getter: [:obj | obj locator] setter: [ > :obj :value | obj locator: value] > ] > > The first part map 'booking' property to the class locator inst var. The > second part have access to the "second json level" and the value i'm looking > for. > > But setLocator: anObject is the ugly thing :( > setLocator: anObject > (anObject class == PmsJsonInput) ifTrue: [^locator := anObject locator]. > locator := anObject > > I'm sure there must be another way to do this. > > regards, > bruno > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Feb. 26, 2019

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

by Christophe Demarey

> Le 26 fÃ©vr. 2019 Ã 20:39, Hilaire <hilaire(a)drgeo.eu> a Ã©crit : > > Thanks, > > Not sure about what is the nib and xib you are mentioning. Will check on > that later. 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.

Feb. 26, 2019

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

by Hilaire

Thanks, Not sure about what is the nib and xib you are mentioning. Will check on that later. I noted the Info.plist is a lot shorter in PharoLauncher compared to the Mac OSX VM zip archive one, though. Any reason? Le 26/02/2019 Ã 09:11, Christophe Demarey a Ã©critÂ : > Pharo Launcher mac packaging is available here: https://github.com/pharo-project/pharo-launcher/tree/development/mac > You can skip the signing part if not needed. > We reuse the app built for opensmalltalk vm but I fear it is a bit outdated. I tried to update the nib file but this format is not used anymore. It is now replaced by xib file (and I do not know much on OS X UI dev). If you do not need to customize it too much, it should be ok. -- Dr. Geo http://drgeo.eu

Feb. 26, 2019

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

by Hilaire

Le 25/02/2019 Ã 21:55, Sven Van Caekenberghe a Ã©critÂ : > prometheus:DrGeo.app sven$ ./Contents/vm/Pharo ../Contents/Resources/drgeo.image > 2019-02-25 21:49:49.816 Pharo[68128:5223153] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting Both Info.plist and NSPrincipalClass are present. Are you sure about the path to the drgeo.image, the '../' should be './' ? > This is not my area of expertise, but you are trying to do this without having a Mac and/or basic Mac developer experience ? Indeed, no Mac no Mac devel experience. This was has this since many year. In my school our 24 seats computer room is mac OS, so I kind have no choice to get it functioning on mac > Those .app bundles are really harder than they look. This is very much related to how macOS works (including virus and malware protection). Yes, I have no idea. The last time I worked with bundled application was with RiscOS, it was transparent. > > Can't you look at the PharoLauncher for how this should be done ? Maybe the developers working on PharoLauncher can help ? Yes good idea, I extracted the dmg archive on linux, its Info.plist is minimal. WIll take a look. Hilaire -- Dr. Geo http://drgeo.eu

Feb. 26, 2019

[Parsing XML] Error calling Shout

by sergio ruiz

Hi, all. I am currently using the AWS S3 plugin to get a list of buckets available. This call sends back a pile of XML.. The XML is coming back valid, but I am getting back something like: XMLDocumentHighlightDefaults errorâ¦. and inside this error, SHTextStylerST80 new <- where ânewâ is being sent to nil.. It looks like SHTextStylerST80 is part of the Shout package, but I cannot get shout to install on 7.01.. anyone have any ideas? Thanks! ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Feb. 26, 2019