- Pharo-users - lists.pharo.org

Having to press step into twice, to actually step into with debugger?

by Tim Mackinnon

Has anyone else noticed that you often have to click 2 times, to step into some things in the debugger? I had some code like this: MyClass verify And had a break point on #verify, which the debugger stops on, but then I have to click into, twice to go through the code? Is there something different about this kind of statement, or is this some bug? Tim

March 13, 2019

Re: [Pharo-users] How to get to the bottom of the spinning beach ball when first entering Pharo

by Tim Mackinnon

Hi Peter - yes the beach ball is the mac equivalent of the spinning circle , but it seems to appear more often than I expect - just web browsing or reading email and then flipping back incurs that sane delay? This is on a 16gb MacBook Pro. I donât recall this in Pharo 6 the same, but Iâm doing more hard core development on 7. I did look in the process browser and find an odd looking process that wasnât in my other images, so I terminated it and will see if maybe it was that. But I think Iâve seen it in other images too (Iâm not sure). Iâm wondering if others notice this - however it seems like you do too. Tim Sent from my iPhone > On 13 Mar 2019, at 18:08, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Tim > > I have never seen a spinning beach ball, but I often find, when coming back to Pharo after using some other application, that there is a delay of a few seconds, during which time I see the standard Windows 'hang on a bit' signal, which is a blue ring near the cursor. My assumption is that this is the effect of swapping from virtual memory - my machine has only(!) 4GB of real Ram. Could the beach ball be something generated by your OS in a similar situation? - which OS are you on, by the way? > > HTH > > Peter Kenny > > -----Original Message----- > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Tim Mackinnon > Sent: 13 March 2019 10:10 > To: Pharo Users Newsgroup <pharo-users(a)lists.pharo.org> > Subject: [Pharo-users] How to get to the bottom of the spinning beach ball when first entering Pharo > > Hi guys - this has come up before in the past - but Iâm really noticing it now having worked on a project for a few weeks. Every time I go into my image (by go into - I mean unsuspend my laptop and start using as its the current app, OR flipping to it from say reading email) I get a shining beach ball for 5-10 seconds and then the app is responsive and I can work on it. Itâs not all of the time, but Iâve noticed its not just my laptop warming up - as several times a day I see it when flipping back to it. > > How do I trouble shoot what is going on - does the system reporter tool tell me anything useful? I did notice my image has grown quite large - is it just that? > > Virtual Machine Statistics > -------------------------- > uptime 89h58m32s > memory 409,608,192 bytes > old 400,656,160 bytes (97.80000000000001%) > young 3,931,080 bytes (1.0%) > used 317,989,144 bytes (77.60000000000001%) > free 86,598,096 bytes (21.1%) > > > If it is memory - what would I look at to see why my memory usage is so large on a relatively small app with few dependencies (although I have been doing lots of iceberg commits and running tests, and using the debugger to explore etc) > > Tim > >

March 13, 2019

Re: [Pharo-users] How to get to the bottom of the spinning beach ball when first entering Pharo

by PBKResearch

Tim I have never seen a spinning beach ball, but I often find, when coming back to Pharo after using some other application, that there is a delay of a few seconds, during which time I see the standard Windows 'hang on a bit' signal, which is a blue ring near the cursor. My assumption is that this is the effect of swapping from virtual memory - my machine has only(!) 4GB of real Ram. Could the beach ball be something generated by your OS in a similar situation? - which OS are you on, by the way? HTH Peter Kenny -----Original Message----- From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Tim Mackinnon Sent: 13 March 2019 10:10 To: Pharo Users Newsgroup <pharo-users(a)lists.pharo.org> Subject: [Pharo-users] How to get to the bottom of the spinning beach ball when first entering Pharo Hi guys - this has come up before in the past - but Iâm really noticing it now having worked on a project for a few weeks. Every time I go into my image (by go into - I mean unsuspend my laptop and start using as its the current app, OR flipping to it from say reading email) I get a shining beach ball for 5-10 seconds and then the app is responsive and I can work on it. Itâs not all of the time, but Iâve noticed its not just my laptop warming up - as several times a day I see it when flipping back to it. How do I trouble shoot what is going on - does the system reporter tool tell me anything useful? I did notice my image has grown quite large - is it just that? Virtual Machine Statistics -------------------------- uptime 89h58m32s memory 409,608,192 bytes old 400,656,160 bytes (97.80000000000001%) young 3,931,080 bytes (1.0%) used 317,989,144 bytes (77.60000000000001%) free 86,598,096 bytes (21.1%) If it is memory - what would I look at to see why my memory usage is so large on a relatively small app with few dependencies (although I have been doing lots of iceberg commits and running tests, and using the debugger to explore etc) Tim

March 13, 2019

Re: [Pharo-users] Pharo and FPGA

by Yves Lenfant

For information, you can find a list of old research about smalltalk embedded in hardware: http://www.merlintec.com/swiki/hardware/26.html <http://www.merlintec.com/swiki/hardware/26.html> BR Yves -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 13, 2019

Re: [Pharo-users] [ANN] CouchDB Client for Pharo

by Esteban Maringolo

Well... I wasn't aware such client existed. #facepalm Looking at it, it seems to fulfill the pending features I was talking about, including the option to use Pharo as a View server! (running map/reduce operations) and the Mango Queries (it's not a typo of Mongo, it's a different thing [1]). It is certainly more complete, but also heavier and more complex to use for simple operations. In any case I added a link to it in the README.md of my repository for those looking for the missing parts. Thank you! [1] https://github.com/cloudant/mango Esteban A. Maringolo El miÃ©., 13 mar. 2019 a las 4:30, Torsten Bergmann (<astares(a)gmx.de>) escribiÃ³: > Nice. How does it relate/compare to https://github.com/jmari/SCouchDB ? > > *Gesendet:* Mittwoch, 13. MÃ¤rz 2019 um 03:18 Uhr > *Von:* "Esteban Maringolo" <emaringolo(a)gmail.com> > *An:* "Pharo users" <pharo-users(a)lists.pharo.org> > *Betreff:* [Pharo-users] [ANN] CouchDB Client for Pharo > Hello all, > > I finished polishing the repository a CouchDB client for Pharo that I > forked from an old, and seemingly abandoned, client for VisualWorks. > > I took that code and refactored heavily to use Pharo and Zinc core > classes, and that included renaming the client classes, methods and the > strategy used to map objects to/from JSON. > > It is available at: > https://github.com/eMaringolo/pharo-couchdb > > I'm open to questions or suggestions about this or how to use it. > > Disclaimer: > This is mostly experimental since I'm not using it in production and was > done as a means of exploration of CouchDB itself for a project I'm > prospecting. > > There are a lot of features that could be added to the client, and things > that could be refactored further (such as the class side request methods), > but adding that is simple, and the current state provides almost feature > complete coverage. > > Best regards, > > Esteban A. Maringolo >

March 13, 2019

Re: [Pharo-users] Hmmm sending at:put: to an undefined object (nil) gives a confusing error message

by Richard O'Keefe

Byte arrays are not host specific. True. But integers are not byte arrays. They don't even contain byte arrays. Just like (boxed) Floats are not word arrays and don't contain word arrays. For what it's worth, I find that it's quite unusual for a method to change from private to public or vice versa. The basic problem with putting methods in a "private" category is that it has no actual effect. It was Smalltalk that taught me OO and the importance of encapsulation. But Smalltalk doesn't actually support encapsulation. Every detail of the implementation of Dictionary, for example, is exposed. And the practice of "self-encapsulation" is actually ANTI-encapsulation for this reason. Now there are several ways to implement hashed collections. The one I've had for years is pleasantly fast and pleasantly free of weird restrictions (keys/elements can be nil and why not). I've got a new one I'm working on that uses less space and is faster still. Because my dialect *enforces* encapsulation, when my testing is complete, I'll be able to swap the new version in, knowing that no external code can possibly depend on the implementation details.obj As a particular example, it was only when I implemented serialisation (nowhere up to Fuel's standards, of course) that I implemented #pvtInstVarAt:[put:] and an object is *still* completely and exclusively in charge of its own instance variables. I agree that using a prefix is not the best way to do this, but the eye soon learns to skip over it. It's not that much worse than "Inst" or "Var" or the pervasive and obtrusive use of prefixes on selectors in VisualAge Smalltalk. I think Pharo would be the better for having *some* way to enforce encapsulation, but what the best way is I don't claim to know. On Wed, 13 Mar 2019 at 21:35, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On 13/03/19 12:45 PM, Richard O'Keefe wrote: > > Base 256: that's an implementation detail. > > Little-endian: that's an implementation detail. > > Architecture-specific no. Implementation yes. But that should be fine > for private methods. > > > My Smalltalk uses base 65536 native-endian and > > takes some care not to let Smalltalk code find out. > > (Not least because on 64-bit machines I want to > > use base 2**32.) > > This would make it host-specific. Byte arrays are not host-specific. > > > For *private* methods, depending on otherwise > > hidden implementation details is fair enough. > > My Smalltalk picked up a convention from Squeak > > -- or rather, from the Squeak mailing list -- > > that a 'pvt' prefix on a selector makes it truly > > private and *enforces* that. Pharo does not seem > > pvt prefix is possibly inspired by Hungarian notation. I find that it > impairs readability and maintenance. Should a method change from private > to public or vice versa down the line, maintenance will be a nightmare. > My own preference is placing them in 'private' category (or even > private-* categories). > > > to have anything similar, and #at: is the epitome > > of a selector in extremely wide general use. > > Since #digitAt: exists -- and is what the integer > > classes use -- it is practically certain that #at: > > is sent to an integer only by mistake. > > You make a good point here. Perhaps #at:/#at:put: should throw an error > for all numbers and private methods could use basic versions instead. > > Regards .. Subbu > >

March 13, 2019

How to get to the bottom of the spinning beach ball when first entering Pharo

by Tim Mackinnon

Hi guys - this has come up before in the past - but Iâm really noticing it now having worked on a project for a few weeks. Every time I go into my image (by go into - I mean unsuspend my laptop and start using as its the current app, OR flipping to it from say reading email) I get a shining beach ball for 5-10 seconds and then the app is responsive and I can work on it. Itâs not all of the time, but Iâve noticed its not just my laptop warming up - as several times a day I see it when flipping back to it. How do I trouble shoot what is going on - does the system reporter tool tell me anything useful? I did notice my image has grown quite large - is it just that? Virtual Machine Statistics -------------------------- uptime 89h58m32s memory 409,608,192 bytes old 400,656,160 bytes (97.80000000000001%) young 3,931,080 bytes (1.0%) used 317,989,144 bytes (77.60000000000001%) free 86,598,096 bytes (21.1%) If it is memory - what would I look at to see why my memory usage is so large on a relatively small app with few dependencies (although I have been doing lots of iceberg commits and running tests, and using the debugger to explore etc) Tim

March 13, 2019

MSWindows Keymapping

by Craig Johnson

Hi All, I'm primarily a Windows user and I am finding the default key mapping very un-windows and it's preventing me from becoming immersed in the environment. Because I'm constantly having to reach for the mouse to switch windows etc. How easy would it be to change the key mapping to something that I'm more used to? Craig

March 13, 2019

Re: [Pharo-users] Hmmm sending at:put: to an undefined object (nil) gives a confusing error message

by K K Subbu

On 13/03/19 12:45 PM, Richard O'Keefe wrote: > Base 256: that's an implementation detail. > Little-endian: that's an implementation detail. Architecture-specific no. Implementation yes. But that should be fine for private methods. > My Smalltalk uses base 65536 native-endian and > takes some care not to let Smalltalk code find out. > (Not least because on 64-bit machines I want to > use base 2**32.) This would make it host-specific. Byte arrays are not host-specific. > For *private* methods, depending on otherwise > hidden implementation details is fair enough. > My Smalltalk picked up a convention from Squeak > -- or rather, from the Squeak mailing list -- > that a 'pvt' prefix on a selector makes it truly > private and *enforces* that.Â Pharo does not seem pvt prefix is possibly inspired by Hungarian notation. I find that it impairs readability and maintenance. Should a method change from private to public or vice versa down the line, maintenance will be a nightmare. My own preference is placing them in 'private' category (or even private-* categories). > to have anything similar, and #at: is the epitome > of a selector in extremely wide general use. > Since #digitAt: exists -- and is what the integer > classes use -- it is practically certain that #at: > is sent to an integer only by mistake. You make a good point here. Perhaps #at:/#at:put: should throw an error for all numbers and private methods could use basic versions instead. Regards .. Subbu

March 13, 2019

Re: [Pharo-users] Hmmm sending at:put: to an undefined object (nil) gives a confusing error message

by Richard O'Keefe

It's supposed to be on GitHub but I botched it. On Wed, 13 Mar 2019 at 21:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 13 Mar 2019, at 08:15, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > My Smalltalk > > Where can I have a look at that ? > >

March 13, 2019