- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo on a chromebook?

by Guillermo Polito

Yes, Iâve heard some other people doing similar stuff. I put in cc Olivier, maybe he can share a bit more if he has time :) Guille > El 1 abr 2020, a las 1:40, tbrunz <wild.ideas(a)gmail.com> escribiÃ³: > > Hi Paul, > > It *is* possible! I've got it running on one of my Chromebooks, a Pixelbook > model. (I gave my 2015 Pixel LS to my wife; I've yet to try it on that > one.) See the attached image. > > You'll likely need to install a Linux container, which is how I got it to > work. (I didn't try to get it running in the native Linux OS, which I > believe is a modified Gentoo.) > > You can have an icon associated with it; if you do, you can pin it to your > icon tray and launch Pharo that way -- which is what I do. (You should be > able to see the icon in my image.) I have a script that generates a > '.desktop' file with an icon, which is how I think I got this to work. (I'm > about to rewrite the script; the first attempt was a hack extracted from a > script suite I wrote, and Pharo deserves better.) > > One thing you'll want to do is correct for the 4K display. I have a script > that automates enlarging the pointer arrow at > https://github.com/tbrunz/pharo-support (which also has the above-mentioned > script), but I just finished it and haven't yet tested it on a Chromebook > install. > > -Ted > > <http://forum.world.st/file/t372161/Pharo-in-Chromebook_2019-0127a.jpg> > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 1, 2020

Re: [Pharo-users] UFFI code problem

by Guillermo Polito

> El 1 abr 2020, a las 9:31, Esteban Lorenzano <estebanlm(a)gmail.com> escribiÃ³: > > There has been a change in how the constant values needs to be declared (because in a 64bit environment, you cannot âguessâ the type by its value: 42 can be (int32)42 or (int64)42. > Hence, you need to be explicit on the time. Parentheses are not needed anymore (yet they are still supported I guess) :) You can now do int -42 Since there is no ambiguity possible, and this is consistent with int x ;) > > Thatâs why @tbrunz suggestion is accurate. > > Now, I remember writing that example years ago, but I do not remember where :P > Can you point me to the source, so I can correct it ? (it should have been done before, but better later than never ;) I wonder if for Pharo9 we should put the UFFI parser in strict mode. Strict mode should - not let people use constants without type declarations (because not doing so is a source of bugs) - not let people use String declarations without declaring encodings (because not doing so is a source of bugs) Of course, strictness is just a flag that people could turn off, at their own risk... > Esteban > >> On 1 Apr 2020, at 06:57, tbrunz <wild.ideas(a)gmail.com> wrote: >> >> Try using this expression: >> >> ^ self ffiCall: #( int abs ( int TheAnswer ) ) module: LibC >> >> i.e., add 'int' to tell Pharo that 'TheAnswer' is to be interpreted as a C >> integer. >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

April 1, 2020

Re: [Pharo-users] UFFI code problem

by Esteban Lorenzano

There has been a change in how the constant values needs to be declared (because in a 64bit environment, you cannot âguessâ the type by its value: 42 can be (int32)42 or (int64)42. Hence, you need to be explicit on the time. Thatâs why @tbrunz suggestion is accurate. Now, I remember writing that example years ago, but I do not remember where :P Can you point me to the source, so I can correct it ? (it should have been done before, but better later than never ;) Esteban > On 1 Apr 2020, at 06:57, tbrunz <wild.ideas(a)gmail.com> wrote: > > Try using this expression: > > ^ self ffiCall: #( int abs ( int TheAnswer ) ) module: LibC > > i.e., add 'int' to tell Pharo that 'TheAnswer' is to be interpreted as a C > integer. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 1, 2020

Re: [Pharo-users] Ballooning image size! Approaching 400MB

by jtuchel＠objektfabrik.de

Tim, out of curiosity: why do you suggest to create hundreds of thousands of Strings instead of become: nil? Does Pharo do two-way become: ? I'be been nilling instances for a little over 2 decades in VAST so far and never had any troubles with it... Other than that: the become: nil (or String new as you suggest) thing was the first that came to my mind for the intermediate solution as well. Of course that doesn't fix the code which doesn't dispose of the objects in the UI or model... Joachim Am 01.04.20 um 08:42 schrieb Tim Mackinnon: > Hi Russ - a quick look at your stats seems to indicate that something > is holding on to your model, I didnât understand the first object > growing by 2, but the second increases by 1 each time, and it looks > like some form of root object holding on Â to the others ? This of > course means the GC canât reclaim the chain of objects if something is > holding on to that root globally. > > Assigning something in the playground will hold onto it (I believe) so > you can continue to reuse and inspect it - so thatâs expected, but > this looks like something in your UI? > > You can break the chain manually (but itâs not a full solution), > simply iterate over your root and become: String new (Save your image > before doing it and see if it works to free up the cycles). Eg try > something like this (havenât tried this in Pharo myself, but worked in > VA, so it should work here) > > MyRootModel allInstances do: [ :m | m become: String new ] > > If this works and reduces your memory usage, you now need to inspect > one of those MyRootModel instances and see who is referencing it, and > explain why. This is Svenâs pointerTo explanation. > > For roots, you sometimes can use a WeakDictionary so that when nothing > is referencing them, they get gcâd if you are doing some caching or > have some factory concept. > > Itâs not uncommon to hit this when you get your system nearing > completion , itâs the downside of not having to worry about memory > referencing - ultimately you have to worry about it at the edges. > > It is possible there is a Pharo bug, as over time I see large Pharo > images but I was just messing around and put it down to failed > experiments. > > Hope this helps. > > Tim > >> On 31 Mar 2020, at 20:47, Russ Whaley <whaley.russ(a)gmail.com> wrote: >> >> ï»¿ >> Here is some additional data - attached - I checked the number of >> instances on select Classes before a UI load, during the UI load and >> after the UI load (and again).Â The class instances grow as expected, >> but do no release.Â I'm doing something wrong.Â I'm going to try a >> fresh image next, however, I expect the same thing to happen, just >> starting over at zero. >> >> >> >> On Tue, Mar 31, 2020 at 12:57 PM Russ Whaley <whaley.russ(a)gmail.com >> <mailto:whaley.russ@gmail.com>> wrote: >> >> Dario, >> Thanks for the reply! >> >> When I closed my image - after running that huge query and >> leaving it in an inspector... my image grew to 1.3GB, lol. >> >> When I closed the inspector, and all the class browsers, did the >> garbage collection, etc., it dropped back to 384MB.Â Still huge, >> and all my Class instances are still there.Â I'm getting ready to >> also drop my Playground - after I copy all the code snippets out >> and see if that has any impact.Â I'm also going to try a fresh >> image and see if there is the same growth pattern as here. >> >> Perhaps I'm doing something wrong with the way I'm creating and >> storing my object instances - which is generally Class new, fill >> out some attributes, then add it to a collection or Dictionary. >> >> All my Object tests create sample data (objects) - over and over >> as well. >> >> >> On Tue, Mar 31, 2020 at 12:20 PM dario.trussardi65 >> <dario.trussardi65(a)gmail.com >> <mailto:dario.trussardi65@gmail.com>> wrote: >> >> Ciao, >> >> >> > My image size keeps growing and growing.Â I've been >> scouring Google and mailing lists, trying to find a solution. >> >> Â Â Â Â i have the same problem with a Pharo 7 image. >> >> Â Â Â Â Maybe it has nothing to do. >> >> Â Â Â Â But after close all the class browser windows the >> image save return to a " valid " size. >> >> Â Â Â Â Dario >> >> >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com <mailto:whaley.russ@gmail.com> >> >> >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com <mailto:whaley.russ@gmail.com> >> <Class instances tests.pdf> -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

April 1, 2020

Re: [Pharo-users] Ballooning image size! Approaching 400MB

by Tim Mackinnon

Hi Russ - a quick look at your stats seems to indicate that something is holding on to your model, I didnât understand the first object growing by 2, but the second increases by 1 each time, and it looks like some form of root object holding on to the others ? This of course means the GC canât reclaim the chain of objects if something is holding on to that root globally. Assigning something in the playground will hold onto it (I believe) so you can continue to reuse and inspect it - so thatâs expected, but this looks like something in your UI? You can break the chain manually (but itâs not a full solution), simply iterate over your root and become: String new (Save your image before doing it and see if it works to free up the cycles). Eg try something like this (havenât tried this in Pharo myself, but worked in VA, so it should work here) MyRootModel allInstances do: [ :m | m become: String new ] If this works and reduces your memory usage, you now need to inspect one of those MyRootModel instances and see who is referencing it, and explain why. This is Svenâs pointerTo explanation. For roots, you sometimes can use a WeakDictionary so that when nothing is referencing them, they get gcâd if you are doing some caching or have some factory concept. Itâs not uncommon to hit this when you get your system nearing completion , itâs the downside of not having to worry about memory referencing - ultimately you have to worry about it at the edges. It is possible there is a Pharo bug, as over time I see large Pharo images but I was just messing around and put it down to failed experiments. Hope this helps. Tim > On 31 Mar 2020, at 20:47, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > ï»¿ > Here is some additional data - attached - I checked the number of instances on select Classes before a UI load, during the UI load and after the UI load (and again). The class instances grow as expected, but do no release. I'm doing something wrong. I'm going to try a fresh image next, however, I expect the same thing to happen, just starting over at zero. > > > >> On Tue, Mar 31, 2020 at 12:57 PM Russ Whaley <whaley.russ(a)gmail.com> wrote: >> Dario, >> Thanks for the reply! >> >> When I closed my image - after running that huge query and leaving it in an inspector... my image grew to 1.3GB, lol. >> >> When I closed the inspector, and all the class browsers, did the garbage collection, etc., it dropped back to 384MB. Still huge, and all my Class instances are still there. I'm getting ready to also drop my Playground - after I copy all the code snippets out and see if that has any impact. I'm also going to try a fresh image and see if there is the same growth pattern as here. >> >> Perhaps I'm doing something wrong with the way I'm creating and storing my object instances - which is generally Class new, fill out some attributes, then add it to a collection or Dictionary. >> >> All my Object tests create sample data (objects) - over and over as well. >> >> >>> On Tue, Mar 31, 2020 at 12:20 PM dario.trussardi65 <dario.trussardi65(a)gmail.com> wrote: >>> Ciao, >>> >>> >>> > My image size keeps growing and growing. I've been scouring Google and mailing lists, trying to find a solution. >>> >>> i have the same problem with a Pharo 7 image. >>> >>> Maybe it has nothing to do. >>> >>> But after close all the class browser windows the image save return to a " valid " size. >>> >>> Dario >> >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com > > > -- > Russ Whaley > whaley.russ(a)gmail.com > <Class instances tests.pdf>

April 1, 2020

Re: [Pharo-users] UFFI code problem

by tbrunz

Try using this expression: ^ self ffiCall: #( int abs ( int TheAnswer ) ) module: LibC i.e., add 'int' to tell Pharo that 'TheAnswer' is to be interpreted as a C integer. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 1, 2020

Re: [Pharo-users] UFFI code problem

by shawon58

that means i cant able to use Theanswer ? i attach my screenshot how i initialize the value in variable . <http://forum.world.st/file/t372453/Capture.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 1, 2020

Re: [Pharo-users] UFFI code problem

by tbrunz

Where did you get this example? The straightforward answer is that "TheAnswer" appears to be undefined. In this context, 'ffiCall:' is expecting a valid C expression that indicates the type of a formal argument, followed by the formal argument. Based on the examples in the UFFI booklet, I would expect that to be something like 'int -42' rather than "TheAnswer". But knowing more of the context of where you got your code would help... -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 1, 2020

UFFI code problem

by shawon58

i am trying UFFI code the code is : FFICContantExamples class>>absMinusFortyTwo ^ self ffiCall: #( int abs ( TheAnswer ) ) module: LibC but it shows error. how to solve this ? <http://forum.world.st/file/t372453/Capture.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 1, 2020

UFFI code problem

by shawon58

I am trying to do "FFICContantExamples class>>absMinusFortyTwo ^ self ffiCall: #( int abs ( TheAnswer ) ) module: LibC" this code but it shows error <http://forum.world.st/file/t372453/Capture.png> <http://forum.world.st/file/t372453/Capture.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 1, 2020