[Pharo-users] Having to press step into twice, to actually step into with debugger?

[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

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

[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  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  On Behalf Of Tim 
> Mackinnon
> Sent: 13 March 2019 10:10
> To: Pharo Users Newsgroup 
> 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
> --
> uptime89h58m32s
> memory409,608,192 bytes
>old400,656,160 bytes (97.81%)
>young3,931,080 bytes (1.0%)
>used317,989,144 bytes (77.61%)
>free86,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
> 
> 

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

[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  On Behalf Of Tim 
Mackinnon
Sent: 13 March 2019 10:10
To: Pharo Users Newsgroup 
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.81%)
young   3,931,080 bytes (1.0%)
used317,989,144 bytes (77.61%)
free86,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

Re: [Pharo-users] Pharo and FPGA

[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
  

BR
Yves



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

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

[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 ()
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" 
> *An:* "Pharo users" 
> *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
>

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

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

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

[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.81%)
young   3,931,080 bytes (1.0%)
used317,989,144 bytes (77.61%)
free86,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

[Pharo-users] MSWindows Keymapping

[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

 

 

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

[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

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

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

>
>
> > On 13 Mar 2019, at 08:15, Richard O'Keefe  wrote:
> >
> > My Smalltalk
>
> Where can I have a look at that ?
>
>

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

[Julien]

Cool!

I added an entry [1] for it to awesome-pharos [2].

Cheers,

Julien

Links:
[1]: https://github.com/pharo-open-documentation/awesome-pharo/pull/56
[2]: https://github.com/pharo-open-documentation/awesome-pharo

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

> Le 13 mars 2019 à 03:18, Esteban Maringolo  a écrit :
> 
> 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

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

[Sven Van Caekenberghe]

> On 13 Mar 2019, at 08:15, Richard O'Keefe  wrote:
> 
> My Smalltalk

Where can I have a look at that ?

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

[Torsten Bergmann]

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" 
An: "Pharo users" 
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

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

[Richard O'Keefe]

Base 256: that's an implementation detail.
Little-endian: that's an implementation detail.
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.)
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
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.


On Wed, 13 Mar 2019 at 17:18, K K Subbu  wrote:

> On 12/03/19 9:25 AM, Richard O'Keefe wrote:
> > Squeak where (20 factorial at: 1) answers 0 (oh dear oh dear oh
> > dear).
>
> Richard,
>
> Could you please elaborate on why this is an error?
>
> Large integers are place value encoded (base 256 little endian) and
> stored in byte arrays, so they need #at:/#at:put: (as private methods).
> Place value encoding is not architecture-specific so it doesn't affect
> portability of an image.
>
> Regards .. Subbu
>
>

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

[Richard O'Keefe]

Let's start with portability.
I have ST/X, VAST, VW, Squeak, Pharo, GST,
Dolphin, and some minor systems.
GST and ST/X do not define #at: on any kind of
integer at all.  Why would they?  #basicAt:
will do the job, will it not?
Dolphin defines #at:[put:] on Integer as
self shouldNotImplement
and so does VW.

In VAST,
20 at: 1 => primitive failed
20 factorial at: 1 => 2192834560

In Squeak and Pharo,
20 at: 1 => not indexable
20 factorial at: 1 => 0

So sending #at: to an integer is not portable
between mainstream Smalltalk systems, and for
those Smalltalks that define it on large
integers, the value is not consistent on the
same machine and operating system.


But it is worse than that.  Maybe you do not
care about any Smalltalk but Pharo, and there
is a case to be made for that.  But this
is not consistent with *itself*.
1 at: 1
fails in a 64-bit VM,
where that is a SmallInteger, but
answers 0 in a 32-bit VM,
where that is a LargePositiveInteger.

But it gets *worse*.  Numbers are not
supposed to be mutable.  But in a 32-bit
VM,
  x := 1.
  x at: 1 put: 77.
  x
=> 10077.

I'm sorry, but I had enough grief with
constants that weren't in Fortran 66.

Again, there isn't the slightest need to
define #at:put: on Large...Integers because
#basicAt:put: exists. Indeed, we have
#{basicAt:,at:,digitAt:}[put:] and surely
with #digitAt:[put:] around we can let
#at:[put:] be unimplemented on integers?

There's a conceptual problem with #at: and
#digitAt: as well.  An integer can be viewed
as a sequence of bits, right enough, but in
a language without silly machine-word limits
on integers, it's an *infinite* sequence.
At least, if you define logical operations on
bignums using a 2s-complement model, a
LargePositiveInteger extends infinitely far
with 0s and a LargeNegativeInteger extends
infinitely far with 1s. GST gets this right.
VW gets it right for large positive integers
but wrong for large negative ones (or at
least works on the absolute value without
bothering to explain that).

Ah heck, the whole thing is a mess.





On Wed, 13 Mar 2019 at 17:18, K K Subbu  wrote:

> On 12/03/19 9:25 AM, Richard O'Keefe wrote:
> > Squeak where (20 factorial at: 1) answers 0 (oh dear oh dear oh
> > dear).
>
> Richard,
>
> Could you please elaborate on why this is an error?
>
> Large integers are place value encoded (base 256 little endian) and
> stored in byte arrays, so they need #at:/#at:put: (as private methods).
> Place value encoding is not architecture-specific so it doesn't affect
> portability of an image.
>
> Regards .. Subbu
>
>

Re: [Pharo-users] UI Frameworks

[Konrad Hinsen]

Bob Cowdery  writes:

> I also found Block and Brick which say they are next generation, Block 
> being for graphics and  Brick for widgets. These are not yet in Pharo 
> and again I couldn't find any info although there is a tutorial for 
> Block but not for Brick. Having forgotten most everything I knew I 
> didn't have much success trying to run the Brick examples.

The best existing illustration of what you can do with Bloc and Bric
is probably GToolkit: https://gtoolkit.com/. It also serves as a warning
that this is not ready for prime time yet. For example, the current
version crashes Pharo rather quickly if you use native windows. It isn't
a tutorial either, of course, but a huge reservoir of examples.

So an important consideration is your development time scale. If you
have a deadline for a usable product, better don't bet on Bloc and Bric
yet.

Konrad.