March 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 8 stability and large images

by Ben Coman

I haven't been very involved in Pharo 8, but its great to hear of your positive experience. To grow Pharo its important to be able to reference positive stories from the trenches. Thanks for sharing. cheers -ben On Sat, 7 Mar 2020 at 03:08, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > I am in the midst of a very long term, in my spare time, project written > in Pharo 7. > > I have at times been very frustrated with various problems. Images > becoming unstable. Images crashing. Images crashing and unopenable after > crashing. With seeming loss of code not yet committed. Images very > unstable with memory greater than 500mb. The larger the worse. I > regularly have images that exceed 1gb. It is without effort to grow > images to such size. These images would increasingly become unstable, > slow and unresponsive. They frequently would crash. I would have to > reopen, save or commit my code and then open a new image and import my > code. So I read threads speaking about large images with great interest. > > However, I persisted as I have a significant amount of code dedicated to > this project. Currently approximately 120 classes. Some of which are > private or proprietary. Over 70 public when I have cleaned up my mess > and get ready to release. And many still to be written. > > As I persist, I also look around at my options. There are few things I > would even consider for a rewrite. > > I this week decided to persist in my attempt to move to Pharo 8. I > generally prefer to use the latest stable. However, the first use cause > an error in saving an image which I did not understand and did not > persist through. > > Currently I name my images for this project as such > SmallTrader-0.00.image as a base image setup like I want. I open up such > image and "Save As" and it automatically increments to the biggest > number in the folder such as SmallTrader-0.59.image. Then I update with > the latest code. However Pharo 8 generated an error (#+ was sent to nil) > when doing "Save As" from an image named SmallTrader-8.000.image. So I > decided to keep on with Pharo 7. However, this week I decided not to let > that stop me and I simply renamed my image to something Pharo 8 did not > complain about, SmallTrader-8-00.image and it now "Save As" renames to > SmallTrader-8-00.1.image. > > Now, I am not writing this email to complain. But rather to praise. Once > I got going on Pharo 8 this week with the latest stable VM and Image, it > has seemed to be very stable and solid. I just ran a backtest and had > naively did not pay attention to my backtest settings. The image ran the > backtest perfectly, without problem. It was stable and consistently > performant. After it completed I decided to look at the OS System > Monitor to check how much memory it was consuming because it had opened > up 252 inspect windows with a dictionary of several thousand objects > each. It was effortlessly sitting at 5.7gb and was nicely responsive in > the UI. I later nil'd the object in the Playground and did a Smalltalk > garbageCollect, and it shrank down to 400mb. Nice! > > Wow. Great job guys. I am impressed. I am exceptionally pleased. > > Thank you. Thank you. Thank you. > > This makes me less afraid to use other time series data which run up my > memory greatly. I would be reading in over 2gb of csv files to create my > objects to operate upon. Previously it made the image incredibly > unstable and unusable. I look forward to giving it a try. > > I just wanted to give you guys and gals (should there be any) a > tremendous thank you and praise report. I am greatly encouraged to > persist in my use of Pharo. And at the same time greatly encouraged to > not look elsewhere because no need. Pharo is meeting my needs with > reasonable performance and stability. > > I look forward to being productively active using Pharo 8 and look > forward to the bright future Pharo 9 and beyond hold. > > Thanks again for this amazing language and environment. I hope someday > to be able to repay the blessing I have received from all who have > contributed to what I enjoy today. > > Jimmie Houchin > > > > > > > >

March 8, 2020

R: [ANN] We have our winners!

by Lorenzo

Hi Rich, great work!! My compliments! Itâs there anyone intersted in fuzzy logic and/or genetic algorithms? If yes, please tell him to contact me. Thank you. Lorenzo Da: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] Per conto di Richard Kenneth Eng Inviato: domenica 8 marzo 2020 05:23 A: pharo-users(a)lists.pharo.org Oggetto: [Pharo-users] [ANN] We have our winners! https://smalltalk.tech.blog/2020/03/07/jrmpc-2020-award-winners/ Time to play this up for all the PR value I can muster. Richard -- Questa e-mail Ã¨ stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

March 8, 2020

PBE8.0 Chapter: Syntax in a Nutshell

by ducasse

Hello In case you want to help Pharo, here is attached the latest version of the Pharo by Example book chapter. The authors thanks the sponsoring of ESUG because updating a book is not just changing 5.0 into 8.0. You can send PRs at https://github.com/SquareBracketAssociates/PharoByExample80 The full pdf is available at https://github.com/SquareBracketAssociates/PharoByExample80/releases If you want to support this effort: - you can sponsor the book - you can get your logo on the book cover and be explicitly mentioned. The money will be split equally among the co-authors. - you can sponsor me directly: https://www.paypal.com/donate/?token=Uoxj9sP4_jgUc6zUmTUc0-0AHbigd2v5CM1Gqx… Stef

March 8, 2020

[ANN] We have our winners!

by Richard Kenneth Eng

https://smalltalk.tech.blog/2020/03/07/jrmpc-2020-award-winners/ Time to play this up for all the PR value I can muster. Richard

March 8, 2020

Re: [Pharo-users] Hi-DPI Support

by tbrunz

I've finished the script I mentioned and put it on GitHub; it's called 'pharo-adjust-cursor'. https://github.com/tbrunz/installer_scripts It will edit the bash scripts that launch Pharo applications (i.e., pharolauncher, pharoiot, etc.) to either enable or disable enlarging the GUI pointer. This is useful on Linux systems with a 4K hi-DPI screen, since currently Pharo can enlarge its fonts and other GUI features, but not the cursor. (I don't have a Mac, so this is maybe not applicable to hi-dpi Macs.) The script can edit the Pharo application scripts "in both directions", to either enlarge the cursor or return it to normal size, depending on the option switch included on the command line. There are no side-effects caused by running the script multiple times in a row. Edits will create a backup file, with a name extension appended that reflects the script version backed up. Restoring a backup must be done manually. If run in a Pharo application directory (such as 'pharolauncher'), it will edit the scripts in just that directory. If run in a directory that contains one or more Pharo app directories, it will edit the scripts in each of them that it finds. (If neither situation is met, it will complain, and will complain if the expected Pharo bash scripts aren't found.) Comments & suggestions for improvements are welcome... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 7, 2020

Re: [Pharo-users] Pharo 8 stability and large images

by tbrunz

I like it when a nail-biter has unexpected plot twists and resolves to a happy ending... This will help me sell Pharo 8 where I work. Thanks! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 6, 2020

Pharo 8 stability and large images

by Jimmie Houchin

I am in the midst of a very long term, in my spare time, project written in Pharo 7. I have at times been very frustrated with various problems. Images becoming unstable. Images crashing. Images crashing and unopenable after crashing. With seeming loss of code not yet committed. Images very unstable with memory greater than 500mb. The larger the worse. I regularly have images that exceed 1gb. It is without effort to grow images to such size. These images would increasingly become unstable, slow and unresponsive. They frequently would crash. I would have to reopen, save or commit my code and then open a new image and import my code. So I read threads speaking about large images with great interest. However, I persisted as I have a significant amount of code dedicated to this project. Currently approximately 120 classes. Some of which are private or proprietary. Over 70 public when I have cleaned up my mess and get ready to release. And many still to be written. As I persist, I also look around at my options. There are few things I would even consider for a rewrite. I this week decided to persist in my attempt to move to Pharo 8. I generally prefer to use the latest stable. However, the first use cause an error in saving an image which I did not understand and did not persist through. Currently I name my images for this project as such SmallTrader-0.00.image as a base image setup like I want. I open up such image and "Save As" and it automatically increments to the biggest number in the folder such as SmallTrader-0.59.image. Then I update with the latest code. However Pharo 8 generated an error (#+ was sent to nil) when doing "Save As"Â from an image named SmallTrader-8.000.image. So I decided to keep on with Pharo 7. However, this week I decided not to let that stop me and I simply renamed my image to something Pharo 8 did not complain about, SmallTrader-8-00.image and it now "Save As" renames to SmallTrader-8-00.1.image. Now, I am not writing this email to complain. But rather to praise. Once I got going on Pharo 8 this week with the latest stable VM and Image, it has seemed to be very stable and solid. I just ran a backtest and had naively did not pay attention to my backtest settings. The image ran the backtest perfectly, without problem. It was stable and consistently performant. After it completed I decided to look at the OS System Monitor to check how much memory it was consuming because it had opened up 252 inspect windows with a dictionary of several thousand objects each. It was effortlessly sitting at 5.7gb and was nicely responsive in the UI. I later nil'd the object in the Playground and did a Smalltalk garbageCollect, and it shrank down to 400mb. Nice! Wow. Great job guys. I am impressed. I am exceptionally pleased. Thank you. Thank you. Thank you. This makes me less afraid to use other time series data which run up my memory greatly. I would be reading in over 2gb of csv files to create my objects to operate upon. Previously it made the image incredibly unstable and unusable. I look forward to giving it a try. I just wanted to give you guys and gals (should there be any) a tremendous thank you and praise report. I am greatly encouraged to persist in my use of Pharo. And at the same time greatly encouraged to not look elsewhere because no need. Pharo is meeting my needs with reasonable performance and stability. I look forward to being productively active using Pharo 8 and look forward to the bright future Pharo 9 and beyond hold. Thanks again for this amazing language and environment. I hope someday to be able to repay the blessing I have received from all who have contributed to what I enjoy today. Jimmie Houchin

March 6, 2020

Re: [Pharo-users] How to recover from a VM crash

by hogoww

Hi, Regardless of the crash, the code should have been preserved through the .changes file. They can attempt to replace the image file with a clean one, and apply those changes (a window should open on startup, otherwise it's accessible through left click in world -> code changes) Pierre On 06/03/2020 17:57, Richard Kenneth Eng wrote: > I have an emergency. One of my JRMPC teams says they can't open the > image. They get a long error message that begins with: > > *Exception code: C0000005 > * > *Exception addr: 000000000041FB6B > * > *Access violation (read access) at 0000000000000007 > * > *RAX:0000000032700000 RBX:0000000000000000 RCX:0000000000000000 > RDX:0000000000000000 > * > *RSI:000000000322f4c0 RDI:000000000322f4f0 RBP:0000000006d04a90 > RSP:0000000000b8f9b0 > * > *R8 :0000000000000001 R9 :0000000031825990 R10:0000000000000000 > R11:0000000000b8f8e0 > * > *R12:0000000020d00000 R13:feffffffffffffff R14:00ffffffffffffff > R15:0000000000000000 > * > *RIP:000000000041fb6b EFL:00010246 > * > *FP Control: 0000037f > * > *FP Status: Â 00000000 > * > *FP Tag: Â Â 00000000 > * > * > * > * > * > *Crashed in the VM thread* > > > They didn't do a backup, so have they lost their code? Is there any > way to recover? > > Thanks, > Richard

March 6, 2020

Re: [Pharo-users] How to recover from a VM crash

by Cyril Ferlicot

Hi, I donât know if they will be able to use the image again but they can take a new image, open Epicea (Tools -> code changes). In Epicea they can locate the Epicea logs from their old image (in /pharo-local/ombu-files IIRC) and then they can replay their changes. On Fri 6 Mar 2020 at 17:58, Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > I have an emergency. One of my JRMPC teams says they can't open the image. > They get a long error message that begins with: > > > *Exception code: C0000005* > > *Exception addr: 000000000041FB6B* > > *Access violation (read access) at 0000000000000007* > > *RAX:0000000032700000 RBX:0000000000000000 RCX:0000000000000000 > RDX:0000000000000000* > > *RSI:000000000322f4c0 RDI:000000000322f4f0 RBP:0000000006d04a90 > RSP:0000000000b8f9b0* > > *R8 :0000000000000001 R9 :0000000031825990 R10:0000000000000000 > R11:0000000000b8f8e0* > > *R12:0000000020d00000 R13:feffffffffffffff R14:00ffffffffffffff > R15:0000000000000000* > > *RIP:000000000041fb6b EFL:00010246* > > *FP Control: 0000037f* > > *FP Status: 00000000* > > *FP Tag: 00000000* > > > *Crashed in the VM thread* > > > They didn't do a backup, so have they lost their code? Is there any way to > recover? > > Thanks, > Richard > -- Cyril Ferlicot https://ferlicot.fr

March 6, 2020

How to recover from a VM crash

by Richard Kenneth Eng

I have an emergency. One of my JRMPC teams says they can't open the image. They get a long error message that begins with: *Exception code: C0000005* *Exception addr: 000000000041FB6B* *Access violation (read access) at 0000000000000007* *RAX:0000000032700000 RBX:0000000000000000 RCX:0000000000000000 RDX:0000000000000000* *RSI:000000000322f4c0 RDI:000000000322f4f0 RBP:0000000006d04a90 RSP:0000000000b8f9b0* *R8 :0000000000000001 R9 :0000000031825990 R10:0000000000000000 R11:0000000000b8f8e0* *R12:0000000020d00000 R13:feffffffffffffff R14:00ffffffffffffff R15:0000000000000000* *RIP:000000000041fb6b EFL:00010246* *FP Control: 0000037f* *FP Status: 00000000* *FP Tag: 00000000* *Crashed in the VM thread* They didn't do a backup, so have they lost their code? Is there any way to recover? Thanks, Richard

March 6, 2020