June 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg v1.1.0

by HernÃ¡n Morales Durand

Hi Guille, Thank you for the update. Can this be installed in Pharo 6.1? How? It was tested on Windows? Cheers, HernÃ¡n 2018-06-11 14:04 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Time for the weekly Iceberg update. > Thanks to all brave users, issue reporters and contributors :). > > Key changes: we have introduced some tag support, a new credential manager > to manage keys and passwords per host or repository, a new version of tonel, > and made a first step towards a simplified contribution to Iceberg by > listing it as Pharo's repository. > > Enjoy, > Guille in behalf of all Iceberg contributors > > Following, the detailed changes log. > > New Features > #842 Adding Credentials Store > #843 Update Tonel to 1.0.7 > #823 Iceberg repository should be listed as Pharo's one > #841 Basic tag support (#372) > > Infrastructure > #787 Add Windows ci with Appveyor (not yet green!) > > Enhancements > #827 Add package dialog has some glitches > #833 replace #asIcon with #iconNamed: > #832 Move Iceberg from MostUsedTools to Tools > #830 Better handling of not github remote urls > #825 Enhance Migrate to tonel commit message > #637 Show tag version instead of "Detached HEAD" > #829 migrate-versions-browser > > Bug Fixes > #835 Compare file definitions by their binary uninterpreted content > #838 Clone from incorrect github repository fails with DNU > #826 Pushing to virgin repository raises a DNU

June 11, 2018

[Ann] Iceberg v1.1.0

by Guillermo Polito

Time for the weekly Iceberg update. Thanks to all brave users, issue reporters and contributors :). Key changes: we have introduced some tag support, a new credential manager to manage keys and passwords per host or repository, a new version of tonel, and made a first step towards a simplified contribution to Iceberg by listing it as Pharo's repository. Enjoy, Guille in behalf of all Iceberg contributors Following, the detailed changes log. New Features #842 <https://github.com/pharo-project/pharo/pull/842> Adding Credentials Store #843 <https://github.com/pharo-project/pharo/pull/843> Update Tonel to 1.0.7 #823 <https://github.com/pharo-project/pharo/pull/823> Iceberg repository should be listed as Pharo's one #841 <https://github.com/pharo-project/pharo/pull/841> Basic tag support ( #372 <https://github.com/pharo-project/pharo/pull/372>) Infrastructure #787 <https://github.com/pharo-project/pharo/pull/787> Add Windows ci with Appveyor (not yet green!) Enhancements #827 <https://github.com/pharo-project/pharo/pull/827> Add package dialog has some glitches #833 <https://github.com/pharo-project/pharo/pull/833> replace #asIcon with #iconNamed: #832 <https://github.com/pharo-project/pharo/pull/832> Move Iceberg from MostUsedTools to Tools #830 <https://github.com/pharo-project/pharo/pull/830> Better handling of not github remote urls #825 <https://github.com/pharo-project/pharo/pull/825> Enhance Migrate to tonel commit message #637 <https://github.com/pharo-project/pharo/pull/637> Show tag version instead of "Detached HEAD" #829 <https://github.com/pharo-project/pharo/pull/829> migrate-versions-browser Bug Fixes #835 <https://github.com/pharo-project/pharo/pull/835> Compare file definitions by their binary uninterpreted content #838 <https://github.com/pharo-project/pharo/pull/838> Clone from incorrect github repository fails with DNU #826 <https://github.com/pharo-project/pharo/pull/826> Pushing to virgin repository raises a DNU

June 11, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Richard O'Keefe

I'm really baffled here. Look at the definition at json.org. â An object is an UNORDERED set of name/value pairs. Or look at ECMA-404, which json.org points to. The JSON syntax does not impose any restrictions on the strings used as names ... and DOES NOT ASSIGN ANY SIGNIFICANCE TO THE ORDERING. When you say that "it is pretty clear that the order is important for that format" I fail to understand you. It is absolutely clear that by design the order is NOT important or even significant for JSON. JSON Pointer does not provide any way to refer to order in an "object": /2 applied to an object will look for the name "2" as a string. JSONPath does not provide any way to refer to order in an "object": [2] applied to an object will look for the name "2" as a string. JSON Schema does not provide any way to constrain or refer to order in an "object". As for databases, Postgres documentation says of JSONB that "Insignificant whitespace is discarded, and the order of object keys is not preserved." If you are communicating with someone else who is using pseudo-JSON that does attach semantics to the order of the name/value pairs, then of course you do whatever you have to in order to communicate successfully. Just don't think of it as JSON. If you have two programs whose protocol you control, again you can use JSON syntax with different semantics all you want. Just don't think of it as JSON. Heck, if it is important to you to distinguish between integer 1 and floating point 1.0, you can add your own semantics if you like, but *JSON* doesn't distinguish them. As for MongoDB, it works with BSON (which is richer than JSON. which is why "MongoDB Extended JSON exists), and does some seriously odd things, like regarding {} and {"a": null} as equal. (According to the 3.6 manual.) Do whatever you have to do to get the job done, but just remember that most JSON tools think they are dealing with *JSON*, not something else that looks like it but has different semantics, and can be relied on to preserve or respect *JSON* semantics, not some other semantics unknown to them.

June 11, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Tim Mackinnon

Yes i was a bit nervous about the ordering, but had also noticed other examples like this - but it is a good reminder for me to double check with the developers that they consciously have done this and to register an interest that it stays that way (particularly as they strangely donât provide access to a schema for your user type definition - and hence could get the ordering from that). On a second note - I did phase out my use of NeoJsonObject after the community warning (and realised how much it had worked into my solution). I think explicitly handling the absent key is better (I do loathe nil checks and am surprised how many languages set this terrible example - of shocked how easily I fell into that trap too). That said - I did miss the #atPath: concept in NeoJson and ended up adding an equivalent (better?) #atPath:ifAbsent: to OrderedDictionary to cope with needing to reach into structures to pull out relevant attributes. It did then remind how much I wish we could sort out some form of namespacing, as I donât like to see my model code have to put prAtPath:ifAbsent: (itâs just gross). Maybe I might subclass OrderedDictionary to get the namespacing on a class and my methods can be safely clean). Appreciate the commentary on this, itâs been a useful exercise. Tim Sent from my iPhone > On 11 Jun 2018, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 11.06.2018 um 08:55 schrieb Richard O'Keefe <raoknz(a)gmail.com>: >> >> The order of key:value pairs in a JSON "object" >> is really NOT supposed to matter. For example, >> if you put {"a":1,"b":2} into a JSON database >> you should not be surprised to get {"b":2,"a":1} >> back. Or vice versa, of course. > But when it does what do you do? It is pretty clear that the order is important for that format. So saying it shouldnât matter does not make it better. If you work with mongo DB you will see the same that for some queries you have to provide proper order of keys. > > Norbert > >>> On 8 June 2018 at 00:16, Tim Mackinnon <tim(a)testit.works> wrote: >>> Thanks guys - it seems like I was on the right track. >>> >>> Making my own NeoJsonObject did work, but I will go back and see if Iâm really using the js nature of the values and if for this, just an OrderedDictionary might be clearer. >>> >>> As an aside, I was doing some experiments with prismic.io (a headless cms) and the order of your content when rendering it on a page(generically) is obviously important. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> > On 7 Jun 2018, at 07:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > >>> > >>> >> On 7 Jun 2018, at 08:16, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >> >>> >> >>> >> >>> >>> Am 07.06.2018 um 07:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>> >>> Tim, >>> >>> >>> >>>> On 7 Jun 2018, at 01:37, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>>> >>> >>>> Hi - Iâve hit some Json where the outputted values (they are field names) are written out in a specific order - and the author hasnât chosen to use an array to represent those fields in a specific order. >>> >>>> >>> >>>> { âfield1â : { â¦.}, âfield2â: { â¦ } } >>> >>>> >>> >>>> I think this is technically incorrect and should be: >>> >>>> >>> >>>> { [ {âfield1â : { â¦.}, âfield2â: { â¦ } ]} >>> >>>> >>> >>>> Anyway - given what Iâve got, would it be a terrible idea to create my own version NeoJsonObject and just make it a subclass of OrderedDictionary? >>> >>>> >>> >>>> I canât see any issues - but then I might be kidding myselfâ¦ >>> >>>> >>> >>>> Tim >>> >>> >>> >>> Yea, I think you could try making a NeoJSONOrderedObject as a subclass of OrderedDictionary, modelled after NeoJSONObject. Just remember it is implemented using DNU, which will surprise you at one point. >>> >>> >>> >> Wouldnât be setting #mapClass: on the reader to OrderedDictionary not enough? Dictionary is the default anyway. >>> >> >>> >> Norbert >>> > >>> > Yes, of course, Norbert, it keeps the order: >>> > >>> > (NeoJSONReader on: '{"BB":1,"CC":2,"AA":3}' readStream) mapClass: OrderedDictionary; next. >>> > >>> > => an OrderedDictionary('BB'->1 'CC'->2 'AA'->3) >>> > >>> > NeoJSONWriter toString: (OrderedDictionary new at: #BB put: 1; at: #CC put: 2; at: #AA put: 3; yourself). >>> > >>> > => '{""BB"":1,""CC"":2,""AA"":3}' >>> > >>> > It is not functionally 100% the same as a hypothetical NeoJSONOrderedObject, but might do. >>> > >>> > Sven >

June 11, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Tim Mackinnon

Sent from my iPhone > On 11 Jun 2018, at 08:02, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 11.06.2018 um 08:55 schrieb Richard O'Keefe <raoknz(a)gmail.com>: >> >> The order of key:value pairs in a JSON "object" >> is really NOT supposed to matter. For example, >> if you put {"a":1,"b":2} into a JSON database >> you should not be surprised to get {"b":2,"a":1} >> back. Or vice versa, of course. >> > But when it does what do you do? It is pretty clear that the order is important for that format. So saying it shouldnât matter does not make it better. If you work with mongo DB you will see the same that for some queries you have to provide proper order of keys. > > Norbert > >>> On 8 June 2018 at 00:16, Tim Mackinnon <tim(a)testit.works> wrote: >>> Thanks guys - it seems like I was on the right track. >>> >>> Making my own NeoJsonObject did work, but I will go back and see if Iâm really using the js nature of the values and if for this, just an OrderedDictionary might be clearer. >>> >>> As an aside, I was doing some experiments with prismic.io (a headless cms) and the order of your content when rendering it on a page(generically) is obviously important. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> > On 7 Jun 2018, at 07:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > >>> > >>> >> On 7 Jun 2018, at 08:16, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >> >>> >> >>> >> >>> >>> Am 07.06.2018 um 07:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>> >>> Tim, >>> >>> >>> >>>> On 7 Jun 2018, at 01:37, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>>> >>> >>>> Hi - Iâve hit some Json where the outputted values (they are field names) are written out in a specific order - and the author hasnât chosen to use an array to represent those fields in a specific order. >>> >>>> >>> >>>> { âfield1â : { â¦.}, âfield2â: { â¦ } } >>> >>>> >>> >>>> I think this is technically incorrect and should be: >>> >>>> >>> >>>> { [ {âfield1â : { â¦.}, âfield2â: { â¦ } ]} >>> >>>> >>> >>>> Anyway - given what Iâve got, would it be a terrible idea to create my own version NeoJsonObject and just make it a subclass of OrderedDictionary? >>> >>>> >>> >>>> I canât see any issues - but then I might be kidding myselfâ¦ >>> >>>> >>> >>>> Tim >>> >>> >>> >>> Yea, I think you could try making a NeoJSONOrderedObject as a subclass of OrderedDictionary, modelled after NeoJSONObject. Just remember it is implemented using DNU, which will surprise you at one point. >>> >>> >>> >> Wouldnât be setting #mapClass: on the reader to OrderedDictionary not enough? Dictionary is the default anyway. >>> >> >>> >> Norbert >>> > >>> > Yes, of course, Norbert, it keeps the order: >>> > >>> > (NeoJSONReader on: '{"BB":1,"CC":2,"AA":3}' readStream) mapClass: OrderedDictionary; next. >>> > >>> > => an OrderedDictionary('BB'->1 'CC'->2 'AA'->3) >>> > >>> > NeoJSONWriter toString: (OrderedDictionary new at: #BB put: 1; at: #CC put: 2; at: #AA put: 3; yourself). >>> > >>> > => '{""BB"":1,""CC"":2,""AA"":3}' >>> > >>> > It is not functionally 100% the same as a hypothetical NeoJSONOrderedObject, but might do. >>> > >>> > Sven >>> >>> >> >

June 11, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Norbert Hartl

> Am 11.06.2018 um 08:55 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > The order of key:value pairs in a JSON "object" > is really NOT supposed to matter. For example, > if you put {"a":1,"b":2} into a JSON database > you should not be surprised to get {"b":2,"a":1} > back. Or vice versa, of course. > But when it does what do you do? It is pretty clear that the order is important for that format. So saying it shouldnât matter does not make it better. If you work with mongo DB you will see the same that for some queries you have to provide proper order of keys. Norbert > On 8 June 2018 at 00:16, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Thanks guys - it seems like I was on the right track. > > Making my own NeoJsonObject did work, but I will go back and see if Iâm really using the js nature of the values and if for this, just an OrderedDictionary might be clearer. > > As an aside, I was doing some experiments with prismic.io <http://prismic.io/> (a headless cms) and the order of your content when rendering it on a page(generically) is obviously important. > > Tim > > Sent from my iPhone > > > On 7 Jun 2018, at 07:46, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > > > > >> On 7 Jun 2018, at 08:16, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >> > >> > >> > >>> Am 07.06.2018 um 07:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > >>> > >>> Tim, > >>> > >>>> On 7 Jun 2018, at 01:37, Tim Mackinnon <tim(a)testit.works> wrote: > >>>> > >>>> Hi - Iâve hit some Json where the outputted values (they are field names) are written out in a specific order - and the author hasnât chosen to use an array to represent those fields in a specific order. > >>>> > >>>> { âfield1â : { â¦.}, âfield2â: { â¦ } } > >>>> > >>>> I think this is technically incorrect and should be: > >>>> > >>>> { [ {âfield1â : { â¦.}, âfield2â: { â¦ } ]} > >>>> > >>>> Anyway - given what Iâve got, would it be a terrible idea to create my own version NeoJsonObject and just make it a subclass of OrderedDictionary? > >>>> > >>>> I canât see any issues - but then I might be kidding myselfâ¦ > >>>> > >>>> Tim > >>> > >>> Yea, I think you could try making a NeoJSONOrderedObject as a subclass of OrderedDictionary, modelled after NeoJSONObject. Just remember it is implemented using DNU, which will surprise you at one point. > >>> > >> Wouldnât be setting #mapClass: on the reader to OrderedDictionary not enough? Dictionary is the default anyway. > >> > >> Norbert > > > > Yes, of course, Norbert, it keeps the order: > > > > (NeoJSONReader on: '{"BB":1,"CC":2,"AA":3}' readStream) mapClass: OrderedDictionary; next. > > > > => an OrderedDictionary('BB'->1 'CC'->2 'AA'->3) > > > > NeoJSONWriter toString: (OrderedDictionary new at: #BB put: 1; at: #CC put: 2; at: #AA put: 3; yourself). > > > > => '{""BB"":1,""CC"":2,""AA"":3}' > > > > It is not functionally 100% the same as a hypothetical NeoJSONOrderedObject, but might do. > > > > Sven > > >

June 11, 2018

Re: [Pharo-users] Is it bad to have an order NeoJsonObject?

by Richard O'Keefe

The order of key:value pairs in a JSON "object" is really NOT supposed to matter. For example, if you put {"a":1,"b":2} into a JSON database you should not be surprised to get {"b":2,"a":1} back. Or vice versa, of course. On 8 June 2018 at 00:16, Tim Mackinnon <tim(a)testit.works> wrote: > Thanks guys - it seems like I was on the right track. > > Making my own NeoJsonObject did work, but I will go back and see if Iâm > really using the js nature of the values and if for this, just an > OrderedDictionary might be clearer. > > As an aside, I was doing some experiments with prismic.io (a headless > cms) and the order of your content when rendering it on a page(generically) > is obviously important. > > Tim > > Sent from my iPhone > > > On 7 Jun 2018, at 07:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > >> On 7 Jun 2018, at 08:16, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> > >> > >>> Am 07.06.2018 um 07:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >>> > >>> Tim, > >>> > >>>> On 7 Jun 2018, at 01:37, Tim Mackinnon <tim(a)testit.works> wrote: > >>>> > >>>> Hi - Iâve hit some Json where the outputted values (they are field > names) are written out in a specific order - and the author hasnât chosen > to use an array to represent those fields in a specific order. > >>>> > >>>> { âfield1â : { â¦.}, âfield2â: { â¦ } } > >>>> > >>>> I think this is technically incorrect and should be: > >>>> > >>>> { [ {âfield1â : { â¦.}, âfield2â: { â¦ } ]} > >>>> > >>>> Anyway - given what Iâve got, would it be a terrible idea to create > my own version NeoJsonObject and just make it a subclass of > OrderedDictionary? > >>>> > >>>> I canât see any issues - but then I might be kidding myselfâ¦ > >>>> > >>>> Tim > >>> > >>> Yea, I think you could try making a NeoJSONOrderedObject as a subclass > of OrderedDictionary, modelled after NeoJSONObject. Just remember it is > implemented using DNU, which will surprise you at one point. > >>> > >> Wouldnât be setting #mapClass: on the reader to OrderedDictionary not > enough? Dictionary is the default anyway. > >> > >> Norbert > > > > Yes, of course, Norbert, it keeps the order: > > > > (NeoJSONReader on: '{"BB":1,"CC":2,"AA":3}' readStream) mapClass: > OrderedDictionary; next. > > > > => an OrderedDictionary('BB'->1 'CC'->2 'AA'->3) > > > > NeoJSONWriter toString: (OrderedDictionary new at: #BB put: 1; at: #CC > put: 2; at: #AA put: 3; yourself). > > > > => '{""BB"":1,""CC"":2,""AA"":3}' > > > > It is not functionally 100% the same as a hypothetical > NeoJSONOrderedObject, but might do. > > > > Sven > > >

June 11, 2018

Re: [Pharo-users] [Pharo-dev] Web Frameworks and "Modern" Features

by HernÃ¡n Morales Durand

Hi Paul, I moved the discussion to pharo-users because this has nothing to do with Pharo developement and people could get upset. 2018-06-09 13:10 GMT-03:00 Paul DeBruicker <pdebruic(a)gmail.com>: > Hi > > I think we're doing OK and that its a "discoverability" problem not a "does > not exist or work" problem. E.g. here is Johan's talk about integrating > ReactJS & Seaside https://www.youtube.com/watch?v=1eSGO7QSz5c > > I think part of the problem is that Facebook/Google/Amazon dominate the 'new > hotness' discussions and no one has problems at their scale so the solutions > that work for them that they advocate that people adopt (so e.g. their > hiring pool is better for them) aren't necessarily necessary/appropriate for > smaller sites with fewer engineers. > > For responsive design if he means sites that look good on big or small > screens we're OK as its mostly a CSS problem which can be handled out of the > box by adopting either Torsten's Twitter Bootstrap library > (http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap) or Cyril's Google > Material Design adaptation (https://github.com/DuneSt/MaterialDesignLite) > if you're using Seaside. Or just setting a few viewport width breakpoints > in your existing css and changing styles appropriately if you don't want to > adopt one of those frameworks or are using Teapot or Iliad or whatever. > So there is no framework refinement, but behavior partitioning into newer tools that require more human training and adoption time. If we don't have the resources of Facebook/Twitter/Google then why we are integrating their solutions? The real value of a framework is evolving to enable new refined instantiations. This is not a problem of being covered by fashioned tools, the problem is we are "buying" solutions from other ecosystems where they don't care at all about Pharo, Seaside, Iliad, etc. We stop building systems to integrate modules. Standard solutions like Bootstrap don't came for free, it has a cost, for example if you have to customize a component, you automatically loose the value of the Smalltalk environment. But this cost is usually hidden behind promotion and noise, the tools survive more than developer investment, and usually after a few years the developer has to invest more time and energy learning and using a newer external library... losing again the chance to gain experience cycles with tools built for its own niche. > > For static-site generators you'd probably want to use Teapot > (http://smalltalkhub.com/#!/~zeroflag/Teapot) and just write the generated > HTML to a file. For Seaside you could make one using WABuilder but would > need to add paths to all of the anchors on your site, which could be done > with a RB transformation rule if you had a ton of links. > I get it, most standard things could be done already. My point is at some point Seaside wasn't easily adaptable to not instantiate web controllers, to define routes programmatically, etc. > > For the multiple competing JS library concern I'm not sure what that means > exactly but also how it could be any different in this community vs e.g. > Ruby/Rails. Just gotta manage the namespaces in the DOM right I think? If > its been a problem for me I've forgotten or haven't noticed. > I mean the time when transition from Prototype/Scriptaculous was promoted in favour first of MooTools (easier syntax, lightweight and more modular than Prototype) and later of jQuery. Not counting other client-side alternatives like Dojo or YUI. It means who's gonna invest time = money, in a small community, building a good adaptor for the next JS libraries? We should really stop assuming someone else will just do it for us. > > > I'd be happy to learn more about the other things he mentions. I know > there's this page that describes how Seaside has some inherent security > protections (http://seaside.st/about/security) but maybe he's referring to > something different? Also testing a Seaside site is pretty straightforward > with https://github.com/SeasideSt/Parasol > > > So anyway, I think its out there. Mostly. Except for buzz. > You're right, the tools could be out there. Except also for the lack of feedback, and (as community) running always behind the big players... > There's definitely a very usable/useful set of things that can be done with > what we have today. > > But no question the Rails or JS communities have more because there are more > engineers/companies/resources in and behind them. > > > Hope this helps. > Thank you, good points. HernÃ¡n > > Paul > > > > Sean P. DeNigris wrote >> Hernan related running into the following limitations with Pharo web >> frameworks. I wonder if these are all still missing or if any are now >> availableâ¦ >> >>> None of them was easily adapted to the emerging web trends for the last >>> years like the >>> appearance of static site generators, adaptive/responsive design, >>> multiple >>> competing JS >>> libraries, semantic web, mobility, etc. not to mention they lack >>> "standard" built-in features >>> such as caching, template, security frameworks. >> >> "adaptive/responsive design" in particular seems like a pretty big >> limitation given current expectationsâ¦ >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

June 9, 2018

Re: [Pharo-users] Pharo 6, bad debugger behaviour

by Tim Mackinnon

Ah thatâs interesting- itâs happened to me 4 or 5 tines in the last 2 days. Recent enough that maybe I can figure out a test case.... Iâll try. Sent from my iPhone > On 8 Jun 2018, at 18:57, Steven Costiou <steven.costiou(a)kloum.io> wrote: > > Concerning the bug 22085, i commented on fogbuzz: > >> I believe it is because when running test cases, it runs through: >> >> runCaseForDebug: aTestCase >> [...call test code...] >> on: self class failure , self class skip, self class warning, self class error >> do: [:ex | ex sunitAnnounce: aTestCase toResult: self. ex pass] >> >> So when you reach a doesNotUnderstand, you have: >> >> doesNotUnderstand: aMessage >> [...stuff...] >> >> resumeValue := exception signal. >> >> ^exception reachedDefaultHandler >> ifTrue: [aMessage sentTo: self] >> ifFalse: [resumeValue] >> >> In normal cases (class of the receiver is not a test case), when you step in the debugger the exception signal blocks the execution right away. In subclasses of TestCase, it does ex pass each time you get to this line, then it enters the aMessage sentTo: self, which is not understood, then you can wait a long time... >> >> >> It is equivalent to doing this in a playground: >> >> [ Object new doStuff ] on: Exception do:[:ex| ex pass] >> >> Then step in the debugger and bye bye. But then it seems to be expected behavior... or maybe not ? I mean voluntarily passing on an exception in a doesNotUnderstand would lead to such problems. >> > > > I have heard at least three different stories about this bug : yours, the one from fogbuzz and one other a bit different from Guille. > > They seem to be different but all of them end up looping ad vitam eternam after a debugger step. > > I am looking for ways to reproduce any of this bugs (well except 22085), but so far i have no success on my own images :'( (pharo 6.1 & 7). > > > > Steven.

June 8, 2018

Re: [Pharo-users] Pharo 6, bad debugger behaviour

by Steven Costiou

Concerning the bug 22085, i commented on fogbuzz: > I believe it is because when running test cases, it runs through: > > runCaseForDebug: aTestCase > [...call test code...] > on: self class failure , self class skip, self class warning, self class error > do: [:ex | ex sunitAnnounce: aTestCase toResult: self. ex pass] > > So when you reach a doesNotUnderstand, you have: > > doesNotUnderstand: aMessage > [...stuff...] > > resumeValue := exception signal. > > ^exception reachedDefaultHandler > ifTrue: [aMessage sentTo: self] > ifFalse: [resumeValue] > > In normal cases (class of the receiver is not a test case), when you step in the debugger the exception signal blocks the execution right away. In subclasses of TestCase, it does ex pass each time you get to this line, then it enters the aMessage sentTo: self, which is not understood, then you can wait a long time... > > It is equivalent to doing this in a playground: > > [ Object new doStuff ] on: Exception do:[:ex| ex pass] > > Then step in the debugger and bye bye. But then it seems to be expected behavior... or maybe not ? I mean voluntarily passing on an exception in a doesNotUnderstand would lead to such problems. I have heard at least three different stories about this bug : yours, the one from fogbuzz and one other a bit different from Guille. They seem to be different but all of them end up looping ad vitam eternam after a debugger step. I am looking for ways to reproduce any of this bugs (well except 22085), but so far i have no success on my own images :'( (pharo 6.1 & 7). Steven.

June 8, 2018