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

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

by Tim Mackinnon

Good point by Norbert - I should have referenced a bug - but interested in others experience and I will annotate that bug. For me, this isnât a recursion thing, itâs a dnu when restarting a method (not sure if many people do this - but itâs a key Smalltalk feature in my mind - so it should work well). Also my image recovers fine when I shut down the debuggers. Interested in others experience and I guess I should try and use 7 more to see if itâs there too. Tim Sent from my iPhone Sent from my iPhone >> On 8 Jun 2018, at 13:10, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> On 08/06/2018 08:30, Tim Mackinnon wrote: >> Hi, Iâve noticed lately when using a reasonably recent Pharo 6.1 setup that if I restart a method in the debugger - particularly from a breakpoint or correcting a dnu issue the environment frequently locks up. Fearing the worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 seconds more it comes back with 30 debugger Windows typically with something like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now corrupt inst bar). >> >> I understand the error, but why does it lockup and require the cmd . Dance? >> >> I dont recall earlier Pharos doing this (and not other smalltalks). >> >> Should I report this? > > > It was reported years ago [1], there was a bug and an issue, and it was > supposedly fixed, apparently it wasn't. > > In some cases that recursion caused a "detachment" of the image from the > changes, it is, the image starts complaining that it can't find the > changes file, so all methods lose the source and you better discard that > image without saving, because if you do, you'll never be able to > "reattach" it. > > I don't know if it is still around in Pharo 7. > > > Regards, > > [1] https://twitter.com/emaringolo/status/603939752098816000 > > > -- > Esteban A. Maringolo >

June 8, 2018

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

by Esteban A. Maringolo

On 08/06/2018 08:30, Tim Mackinnon wrote: > Hi, Iâve noticed lately when using a reasonably recent Pharo 6.1 setup that if I restart a method in the debugger - particularly from a breakpoint or correcting a dnu issue the environment frequently locks up. Fearing the worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 seconds more it comes back with 30 debugger Windows typically with something like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now corrupt inst bar). > > I understand the error, but why does it lockup and require the cmd . Dance? > > I dont recall earlier Pharos doing this (and not other smalltalks). > > Should I report this? It was reported years ago [1], there was a bug and an issue, and it was supposedly fixed, apparently it wasn't. In some cases that recursion caused a "detachment" of the image from the changes, it is, the image starts complaining that it can't find the changes file, so all methods lose the source and you better discard that image without saving, because if you do, you'll never be able to "reattach" it. I don't know if it is still around in Pharo 7. Regards, [1] https://twitter.com/emaringolo/status/603939752098816000 -- Esteban A. Maringolo

June 8, 2018

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

by Norbert Hartl

> Am 08.06.2018 um 13:30 schrieb Tim Mackinnon <tim(a)testit.works>: > > Hi, Iâve noticed lately when using a reasonably recent Pharo 6.1 setup that if I restart a method in the debugger - particularly from a breakpoint or correcting a dnu issue the environment frequently locks up. Fearing the worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 seconds more it comes back with 30 debugger Windows typically with something like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now corrupt inst bar). > > I understand the error, but why does it lockup and require the cmd . Dance? > > I dont recall earlier Pharos doing this (and not other smalltalks). > > Should I report this? > As an exercise for you. If you go to http://bugs.pharo.org <http://bugs.pharo.org/> and enter âdebuggerâ in the search field, please click on the first entry found which should be 22085. Norbert

June 8, 2018

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

by Tim Mackinnon

I should also mention these extra debuggers donât have the stack either, just a single dnu method. Tim Ps thank god for close windows to right. ... Sent from my iPhone > On 8 Jun 2018, at 12:30, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi, Iâve noticed lately when using a reasonably recent Pharo 6.1 setup that if I restart a method in the debugger - particularly from a breakpoint or correcting a dnu issue the environment frequently locks up. Fearing the worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 seconds more it comes back with 30 debugger Windows typically with something like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now corrupt inst bar). > > I understand the error, but why does it lockup and require the cmd . Dance? > > I dont recall earlier Pharos doing this (and not other smalltalks). > > Should I report this? > > Tim > > Sent from my iPhone >

June 8, 2018

Pharo 6, bad debugger behaviour

by Tim Mackinnon

Hi, Iâve noticed lately when using a reasonably recent Pharo 6.1 setup that if I restart a method in the debugger - particularly from a breakpoint or correcting a dnu issue the environment frequently locks up. Fearing the worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 seconds more it comes back with 30 debugger Windows typically with something like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now corrupt inst bar). I understand the error, but why does it lockup and require the cmd . Dance? I dont recall earlier Pharos doing this (and not other smalltalks). Should I report this? Tim Sent from my iPhone

June 8, 2018

[Issue Tracker] Please check issue tracker

by Marcus Denker

Hi, If you -> submitted an issue in the past -> have been involved in some discussion about an issue ===> please check the issue tracker. There are many cases where e.g. - some issue has been fixed but the issue tracker entry is not closed - where a discussion came to a conclusion but no action happened. - you reported issue has been fixed in the meantime but the issue tracker entry is still open. https://pharo.fogbugz.com/f/filters/57/All-newest-first We have right now 471 open issues, I am sure we can get that number down! Marcus

June 8, 2018

Re: [Pharo-users] Why do #select:thenXxx methods not return their result

by Peter UhnÃ¡k

> > It only uses one temp collection, where a #select: followed by a separate > #collect: would need two. > Yeah, be careful with that, because it changes the semantics of the operation. (magine what happens when `thenDo:` operates on the original collection and there's no intermediate collection. (I ran into this issue many times.) Peter

June 8, 2018

Re: [Pharo-users] Why do #select:thenXxx methods not return their result

by monty

Not just more readable. They can also be more efficient. Look at #select:thenCollect: in OrderedCollection: select: selectBlock thenCollect: collectBlock " Optimized version Collection>>#select:thenCollect: " | newCollection element | newCollection := self copyEmpty. firstIndex to: lastIndex do: [ :index | element := array at: index. (selectBlock value: element) ifTrue: [ newCollection addLast: (collectBlock value: element) ]]. ^ newCollection It only uses one temp collection, where a #select: followed by a separate #collect: would need two. ___ montyos.wordpress.com > Sent: Thursday, June 07, 2018 at 8:20 AM > From: "Tim Mackinnon" <tim(a)testit.works> > To: "Pharo Users Newsgroup" <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] Why do #select:thenXxx methods not return their result > > Hi - are the methods like #select:thenCollect: frowned upon? > > They seem quite readable , however in using them Iâve noticed that unlike the core methods they done return the result of evaluation (they are missing a ^). This is a shame, but possibly an oversight? > > Tim > > Sent from my iPhone > >

June 8, 2018

Re: [Pharo-users] Why do #select:thenXxx methods not return their result

by Tim Mackinnon

You are correct Peter - I jumped the gun, as it was #select:thenDo: where I hit the problem - and yes it doesnât make sense to answer a result from Do. I do kind of miss the concept of: #select:thenDo:ifNone: as well as #select:thenCollect:ifNone: but some bracketing sorts it out, and I guess where do you stop. Tim > On 7 Jun 2018, at 13:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > How do you mean? > > (1 to: 10) select: #odd thenCollect: [ :x | x ** 2 ] "-> #(1 9 25 49 81)" > > It wouldn't make sense otherwise to have the collect method if it wouldn't return anything. > > Peter > > On Thu, Jun 7, 2018 at 2:20 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi - are the methods like #select:thenCollect: frowned upon? > > They seem quite readable , however in using them Iâve noticed that unlike the core methods they done return the result of evaluation (they are missing a ^). This is a shame, but possibly an oversight? > > Tim > > Sent from my iPhone > >

June 7, 2018

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

by Norbert Hartl

> Am 07.06.2018 um 21:18 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > > On 07/06/2018 13:59, Sven Van Caekenberghe wrote: >>> On 7 Jun 2018, at 14:42, Norbert Hartl <norbert(a)hartl.name> wrote: >>> And safer. The current implementation of NeoJSONObject is not ver good. It returns nil on any missing key so you mask a lot of errors in your code which I find dangerous. >> >> Haha, it was modelled after a JavaScript object, of course it is worse, but more convenient in scripting code. >> Sure, a plain Dictionary is better. > > Nothing that syntax sugar mapping some convenient property accessor to > #at: couldn't fix. :) > > If you come this point you should realize that you need to have a domain object instead

June 7, 2018