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

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

by Norbert Hartl

> Am 01.04.2020 um 12:17 schrieb Richard O'Keefe <raoknz(a)gmail.com>: > > ProtoObject>>become: is two-way in Pharo. > "...Swap the object pointers of the receiver and the argument. > All variables in the entire system that used to point to the > receiver now point to the argument, and vice-versa." > > In the unlikely event that I have understood correctly, > Array>>elementsForwardIdentityTo: > is Pharo's one-way become. > It is #becomeForward: Norbert > On Wed, 1 Apr 2020 at 22:43, jtuchel(a)objektfabrik.de > <jtuchel(a)objektfabrik.de> wrote: >> >> Tim, >> >> okay, so I understand the reason. Thanks for clarifying/confirming? >> >> I don't think VAST has two-way become. IIRC, VW has. At least I can tell you using nil instead of String new has worked for me on VAST versions ever since 3.0 in the early nineties. >> >> What about Pharo? Does it do one-way or two-way become? >> >> >> Joachim >> >> >> >> Am 01.04.20 um 10:29 schrieb Tim Mackinnon: >> >> Yeah, I was taught (and it may be out of date), that as become: is a 2 way operation the identity of nil (as a singleton) would get swizzled, so it was safer to create a simple new object that could be easily gcâd (thatâs what I vaguely recall anyway). (This was in early VA from the OTI guys, but maybe that gets handled better in modern VA, as I think become: is two way in VA right?) >> >> Tim >> >> On 1 Apr 2020, at 08:11, jtuchel(a)objektfabrik.de wrote: >> >> 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> 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> >> >> >> -- >> ----------------------------------------------------------------------- >> 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 >> >> >> >> >> -- >> ----------------------------------------------------------------------- >> 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 Richard O'Keefe

ProtoObject>>become: is two-way in Pharo. "...Swap the object pointers of the receiver and the argument. All variables in the entire system that used to point to the receiver now point to the argument, and vice-versa." In the unlikely event that I have understood correctly, Array>>elementsForwardIdentityTo: is Pharo's one-way become. On Wed, 1 Apr 2020 at 22:43, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > > Tim, > > okay, so I understand the reason. Thanks for clarifying/confirming? > > I don't think VAST has two-way become. IIRC, VW has. At least I can tell you using nil instead of String new has worked for me on VAST versions ever since 3.0 in the early nineties. > > What about Pharo? Does it do one-way or two-way become? > > > Joachim > > > > Am 01.04.20 um 10:29 schrieb Tim Mackinnon: > > Yeah, I was taught (and it may be out of date), that as become: is a 2 way operation the identity of nil (as a singleton) would get swizzled, so it was safer to create a simple new object that could be easily gcâd (thatâs what I vaguely recall anyway). (This was in early VA from the OTI guys, but maybe that gets handled better in modern VA, as I think become: is two way in VA right?) > > Tim > > On 1 Apr 2020, at 08:11, jtuchel(a)objektfabrik.de wrote: > > 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> 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> > > > -- > ----------------------------------------------------------------------- > 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 > > > > > -- > ----------------------------------------------------------------------- > 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] Unicode migration from SmalltalkHub to Github

by Guillermo Polito

Thanks Alistair!! > El 1 abr 2020, a las 11:57, Alistair Grant <akgrant0710(a)gmail.com> escribiÃ³: > > Hi Sven and All, > > We have a need to migrate the Unicode library > (http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release > tagging process). > > I've imported the code, with full history, in to: > https://github.com/feenkcom/pharo-unicode > > If there's no suggestions / objections, I'll request that it be added > to https://github.com/pharo-contributions. > > Thanks, > Alistair >

April 1, 2020

Re: [Pharo-users] Unicode migration from SmalltalkHub to Github

by Sven Van Caekenberghe

Please do, great initiative. > On 1 Apr 2020, at 11:57, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven and All, > > We have a need to migrate the Unicode library > (http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release > tagging process). > > I've imported the code, with full history, in to: > https://github.com/feenkcom/pharo-unicode > > If there's no suggestions / objections, I'll request that it be added > to https://github.com/pharo-contributions. > > Thanks, > Alistair >

April 1, 2020

Unicode migration from SmalltalkHub to Github

by Alistair Grant

Hi Sven and All, We have a need to migrate the Unicode library (http://smalltalkhub.com/#!/~Pharo/Unicode) to github (for our release tagging process). I've imported the code, with full history, in to: https://github.com/feenkcom/pharo-unicode If there's no suggestions / objections, I'll request that it be added to https://github.com/pharo-contributions. Thanks, Alistair

April 1, 2020

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

by jtuchel＠objektfabrik.de

Tim, okay, so I understand the reason. Thanks for clarifying/confirming? I don't think VAST has two-way become. IIRC, VW has. At least I can tell you using nil instead of String new has worked for me on VAST versions ever since 3.0 in the early nineties. What about Pharo? Does it do one-way or two-way become? Joachim Am 01.04.20 um 10:29 schrieb Tim Mackinnon: > Yeah, I was taught (and it may be out of date), that as become: is a 2 > way operation the identity of nil (as a singleton) would get swizzled, > so it was safer to create a simple new object that could be easily > gcâd (thatâs what I vaguely recall anyway). (This was in early VA from > the OTI guys, but maybe that gets handled better in modern VA, as I > think become: is two way in VA right?) > > Tim > >> On 1 Apr 2020, at 08:11, jtuchel(a)objektfabrik.de >> <mailto:jtuchel@objektfabrik.de> wrote: >> >> 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 Tuchelmailto:jtuchel@objektfabrik.de >> Fliederweg 1http://www.objektfabrik.de >> D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > -- ----------------------------------------------------------------------- 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] Pharo on a chromebook?

by kmo

Google have an official linux environment that you can switch on in ChromeOs Settings. Should allow you to switch easily betweeen ChromeOs and Linux. <http://forum.world.st/file/t368903/Screenshot_2020-04-01_at_10.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 1, 2020

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

by Tim Mackinnon

Yeah, I was taught (and it may be out of date), that as become: is a 2 way operation the identity of nil (as a singleton) would get swizzled, so it was safer to create a simple new object that could be easily gcâd (thatâs what I vaguely recall anyway). (This was in early VA from the OTI guys, but maybe that gets handled better in modern VA, as I think become: is two way in VA right?) Tim > On 1 Apr 2020, at 08:11, jtuchel(a)objektfabrik.de wrote: > > 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> <mailto:whaley.russ@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 <mailto:jtuchel@objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

April 1, 2020

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