- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by Esteban Lorenzano

> On 11 Aug 2017, at 13:48, TedVanGaalen <tedvga(a)gmail.com> wrote: > > since 1.8.2017 there was no response, did already anyone thought/worked to > solve this problem? > Thank you, > Ted not yet. Iâm on holidays so I cannot test anything. in a couple of weeks, maybeâ¦ but Iâm guessing this is a VM problemâ¦ maybe someone on vm-dev can help here? Esteban > > TedVanGaalen wrote >> Very very wild guess: it could have to do with GPU<-> Open GL? <-> Pharo >> call time out issues because the Intel HD 4000 GPU is working at its >> (officially allowed) upper performance limits with 3840 x 2160 at 30 Hz >> refresh rate (maximum). >> OTOH however: >> 1. I am not a GPU Guru.. >> 2. It works flawlessly with Pharo 5.0 and before. >> 3. All other macOS applications also work OK. >> >> If it is a VM issue, Squeak would have the same problem >> but I don't want to spend time to try this as well. >> >> TedvG > > > > > > -- > View this message in context: http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p… <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p…> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com <http://nabble.com/>.

Aug. 11, 2017

Re: [Pharo-users] VM dev and compilation

by Esteban Lorenzano

> On 11 Aug 2017, at 12:08, Bruno Durin <bruno.durin(a)gmail.com> wrote: > > Hi, > > I have been tinkering with Pharo and Squeak for a few weeks and I am very enthusiastic with these great pieces of software! I would like to ask questions to check my understanding. I am refering from time to time to Squeak as it runs on the same VM as Pharo but my questions are focused on Pharo. > > As an exercice to learn, I am trying to compile Pharo VMs and get the VM simulator run in a Pharo image (first a 32-bit image+VM and later a 64-bit image+VM). > I am doing this both under Ubuntu 14.04 LTS and Mac OS X 10.12.6. > What I succeeded in doing: > - compiling the squeak and pharo VM using the state of their respective git repo as of about 20 July 2017: on Mac both 32 and 64 bits, on Linux only 64 bits (mainly because I did not want to spend the time to fix the 32-bit libraries which do not coexist well with their 64-bit counterparts) > - on Mac, generating the VM development image (SpurVMMaker) for Squeak on top a (32 bits) V5 image, launch it and run the VM simulator, > - on Mac, generating the VM development image (generator.image) for Pharo on top of a (32 bits) V5 image, launch it and starting to run a CogVMSimulator (which currently fails, but I am debugging it and learning along the way.) > > So, my questions: > 1) About the Pharo VM compilation (Below "the" Pharo VM means the official VMs that are published on the Pharo website but if VM developers use a different process between 2 releases I would be happy to know the differences.) > a) is it correct that the Pharo VM is built using the github pharo-vm repository? yes and no. - the officially distributed pharo-vm is built on opensmalltalk/opensmalltalk-vm and published into our servers. - we keep pharo-vm (in which opensmalltalk-vm is a subtree) repo as a CI/testing platform (that produces the ânightly-builtâ VMs from files.pharo.org/vm/nigthtly-builds <http://files.pharo.org/vm/nigthtly-builds>), but this is used just for testing results, etc. the VMs that people should use are produced in the main repository. > b) in the pharo-vm tree, is it correct that "build" and "results" directories are remnant of the build process before Pharo reunited with Squeak on opensmalltalk vm and that the builder classes in the generator.image (PharoVMSpur32Builder and co) do not create the build.sh script in the "build" directory any more. yes. > c) is it correct that the Pharo VM is now built with the pharo.cog.spur (for example) make process in the various build sub-directories of the "opensmalltalk-vm" directory? yes. > 2) When running a Pharo VM compiled on Mac, the GUI was noticeably slower that the official VM downloaded from pharo.org <http://pharo.org/>. (I compared running the official image.) I did not see such slow down when compiling a Squeak VM. My educated guess is that it is related to libcairo and dependencies. Are there compiler optimisations that I should have manually added? Should I generate a XCode project with cmake and compile in XCode (I currently use ./mvm make script)? I have not had this problem under Linux. no. I have no idea why you have a slower UI but - it is not related to cairo since standard pharo does not use it (just athens does) - you should not need to do anything manually (besides executing ./mvm -f) - you do not need to generate an Xcode project eitherâ¦ > 3) On Mac, is the difference between having the plugins as Mach-O bundle in Squeak and as dylib libraries in Pharo only a packaging choice or does it have deeper implications? (Does it change for example the way FFI is done?) it's just a packaging choice. > 4) Do I understand well that currently the simplest way to convert a 32-bit image to a 64-bit one is to use Spur32to64BitBootstrap class in a VM development image? (As far as I understand, the other way is to use SystemTracer.) yes. I donât even know if it is *possible* with system tracer right now :) > A remark: when manually compiling a Pharo VM in the pharo-vm repo following Eliot's instructions, the updateSCCSVersions script does not work (because it is one level down with respect to the top of the git tree as compared to the opensmalltalk-vm repository). I eventually understood that the correct build procedure is in the travis scripts but as I do not know well the CI tools, it took a long time before I thought of looking into these scripts. If pharo-vm is used to build the Pharo VM (see question 1.a) I think it would be good to update the build process in README.md in pharo-vm tree (and I can do it). yes, thatâs right :) cheers, Esteban > > Thanks, > Bruno > >

Aug. 11, 2017

Re: [Pharo-users] FLSerializer in Pharo 6.1

by jb

No, that cannot be the problem. The following works without problems: | working stream | working := FileSystem disk workingDirectory. stream := (working / 'foo.txt') writeStream. stream nextPutAll: 'Hello World'. stream close. -- View this message in context: http://forum.world.st/FLSerializer-in-Pharo-6-1-tp4959960p4959973.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 11, 2017

Re: [Pharo-users] FLSerializer in Pharo 6.1

by webwarrior

jb wrote > Hi everyone, > > the FLSerializer in Pharo 6.1 doesnât work. I tried the example from the > class comment and I always get > > FileException: cannot open file: example.FL. > > Is that a known problem? > > Johannes Probably that's because you don't have write permission in working directory. -- View this message in context: http://forum.world.st/FLSerializer-in-Pharo-6-1-tp4959960p4959964.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 11, 2017

FLSerializer in Pharo 6.1

by Johannes Brauer

Hi everyone, the FLSerializer in Pharo 6.1 doesnât work. I tried the example from the class comment and I always get FileException: cannot open file: example.FL. Is that a known problem? Johannes

Aug. 11, 2017

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

by monty

> Sent: Friday, August 11, 2017 at 6:36 AM > From: "Denis Kudriashov" <dionisiydk(a)gmail.com> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo) > > What package you explore? I not find fileTypes method in Pharo 7. Like I said, it's a hypothetical example. But I'm sure you could find similar examples of unsafe class state initialization in the image and in popular libraries. > 2017-08-11 8:53 GMT+02:00 monty <monty2@programmer.net[mailto:monty2@programmer.net]>:Here's a hypothetical broken class method that does lazy initialization of a class inst var: > > fileTypes > fileTypes ifNil: [ > fileTypes := Dictionary new. > fileTypes > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > at: 'pdf' put: 'Portable Document Format File'; > at: 'doc' put: 'Microsoft Word Document']. > ^ fileTypes. > > Because the assignment is done first and the initialization is done after with a cascade of interruptable sends of #at:put:, there's a window after the assignment where 'fileTypes' is not nil but also not fully initialized--a race condition. > > The fix is simple. Do the initialization before the atomic assignment takes place, so the var is only ever bound to nil or a fully initialized object: > > fileTypes > fileTypes ifNil: [ > fileTypes := > Dictionary new > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > at: 'pdf' put: 'Portable Document Format File'; > at: 'doc' put: 'Microsoft Word Document'; > yourself]. > ^ fileTypes. > > The fixed code is still vulnerable to duplicate initialization, because the initialization sequence is interruptable and 'fileTypes' is nil during it, but as long as the initialization is cheap enough, has no side effects that restrict how often it can be done, and it's enough that the initialized objects are equal (but not identical), that's OK. > > If it's too complex for a single statement, you can use a temp vars or put it in a separate factory method: > > fileTypes > fileTypes ifNil: [ > fileTypes := self newFileTypes]. > ^ fileTypes. > > Similar precautions (given how easy) might as well be taken with explicit initialization of class state too. Of course if the object is mutated later (in other methods), then Mutexes or other constructs are needed to guard access. But for immutable class state, ensuring initialization is done before assignment should be enough. > > > Sent: Tuesday, August 01, 2017 at 7:36 AM > > From: "Stephane Ducasse" <stepharo.self@gmail.com[mailto:stepharo.self@gmail.com]> > > To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]> > > Subject: Re: [Pharo-users] Threads safety in Pharo > > > > I would love to have an analysis of assumptions made in some code. > > Because my impression is that the concurrent code is sometimes defined > > knowing the underlying logic of scheduler and this is not good. > > As I said to abdel privately in french it would be great to start from > > my french squeak book (Yes I wrote one long time ago) chapter on > > concurrent programming and turn it into a pharo chapter. > > > > Stef > > > > On Tue, Aug 1, 2017 at 1:31 PM, Ben Coman <btc@openinworld.com[mailto:btc@openinworld.com]> wrote: > > > Not sure I'll have what you're looking for, but to start, do you mean > > > Pharo's green threads or vm native threads? > > > cheers -ben > > > > > > On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani via Pharo-users > > > <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]> wrote: > > >> > > >> > > >> > > >> ---------- Forwarded message ---------- > > >> From: Alidra Abdelghani <alidrandco@yahoo.fr[mailto:alidrandco@yahoo.fr]> > > >> To: pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org] > > >> Cc: "StÃ©phane Ducasse" <stephane.ducasse@inria.fr[mailto:stephane.ducasse@inria.fr]>, farid arfi > > >> <arfi_f@hotmail.com[mailto:arfi_f@hotmail.com]> > > >> Bcc: > > >> Date: Mon, 31 Jul 2017 01:38:58 +0200 > > >> Subject: Threads safety in Pharo > > >> Hi, > > >> > > >> Somebody once evoked the problem of threads safety in Pharo. With a friend > > >> of mine who is expert in formal methods and process scheduling, we would > > >> like to have a look on it. > > >> Does anyone knows a good document describing the problem of Pharo with > > >> threads safety or at least any document that we can start with? > > >> > > >> Thanks in advance, > > >> Abdelghani > > >> > > >> > > >> > > > > > >

Aug. 11, 2017

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

by monty

> Sent: Friday, August 11, 2017 at 5:51 AM > From: "Tim Mackinnon" <tim(a)testit.works> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo) > > Interesting, your example was subtle enough that I had to read it a few times to understand the issue. (I was caught up on the ifNil and not the contents). That's the problem. They're close enough that someone could mistakenly refactor the correct code into the incorrect code--and that code would be perfectly fine for lazy initialization of instance state in a non-concurrent class. That's why I always insert a small comment before explaining why it was written that way. > Actually, thinking about it - isn't the real issue the #ifNil - you want an atomic version. > > It strikes me you could wrap the whole concept into something like an AtomicLazyVariable? E.g. > > initialise > fileTypes := AtomicLazyVariable using: [ > > Dictionary new > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > yourself ]. > > Then have something > > fileTypes > ^fileTypes value > > Where you have a critical section in #value? > > Tim > > Sent from my iPhone > On 11 Aug 2017, at 07:53, monty <monty2@programmer.net[mailto:monty2@programmer.net]> wrote: > > Here's a hypothetical broken class method that does lazy initialization of a class inst var: > > fileTypes > fileTypes ifNil: [ > fileTypes := Dictionary new. > fileTypes > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > at: 'pdf' put: 'Portable Document Format File'; > at: 'doc' put: 'Microsoft Word Document']. > ^ fileTypes. > > Because the assignment is done first and the initialization is done after with a cascade of interruptable sends of #at:put:, there's a window after the assignment where 'fileTypes' is not nil but also not fully initialized--a race condition. > > The fix is simple. Do the initialization before the atomic assignment takes place, so the var is only ever bound to nil or a fully initialized object: > > fileTypes > fileTypes ifNil: [ > fileTypes := > Dictionary new > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > at: 'pdf' put: 'Portable Document Format File'; > at: 'doc' put: 'Microsoft Word Document'; > yourself]. > ^ fileTypes. > > The fixed code is still vulnerable to duplicate initialization, because the initialization sequence is interruptable and 'fileTypes' is nil during it, but as long as the initialization is cheap enough, has no side effects that restrict how often it can be done, and it's enough that the initialized objects are equal (but not identical), that's OK. > > If it's too complex for a single statement, you can use a temp vars or put it in a separate factory method: > > fileTypes > fileTypes ifNil: [ > fileTypes := self newFileTypes]. > ^ fileTypes. > > Similar precautions (given how easy) might as well be taken with explicit initialization of class state too. Of course if the object is mutated later (in other methods), then Mutexes or other constructs are needed to guard access. But for immutable class state, ensuring initialization is done before assignment should be enough. > Sent: Tuesday, August 01, 2017 at 7:36 AMFrom: "Stephane Ducasse" <stepharo.self@gmail.com[mailto:stepharo.self@gmail.com]>To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]>Subject: Re: [Pharo-users] Threads safety in Pharo I would love to have an analysis of assumptions made in some code.Because my impression is that the concurrent code is sometimes definedknowing the underlying logic of scheduler and this is not good.As I said to abdel privately in french it would be great to start frommy french squeak book (Yes I wrote one long time ago) chapter onconcurrent programming and turn it into a pharo chapter. Stef On Tue, Aug 1, 2017 at 1:31 PM, Ben Coman <btc@openinworld.com[mailto:btc@openinworld.com]> wrote:Not sure I'll have what you're looking for, but to start, do you meanPharo's green threads or vm native threads?cheers -ben On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani via Pharo-users<pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]> wrote: ---------- Forwarded message ----------From: Alidra Abdelghani <alidrandco@yahoo.fr[mailto:alidrandco@yahoo.fr]>To: pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]Cc: "StÃ©phane Ducasse" <stephane.ducasse@inria.fr[mailto:stephane.ducasse@inria.fr]>, farid arfi<arfi_f@hotmail.com[mailto:arfi_f@hotmail.com]>Bcc:Date: Mon, 31 Jul 2017 01:38:58 +0200Subject: Threads safety in PharoHi, Somebody once evoked the problem of threads safety in Pharo. With a friendof mine who is expert in formal methods and process scheduling, we wouldlike to have a look on it.Does anyone knows a good document describing the problem of Pharo withthreads safety or at least any document that we can start with? Thanks in advance,Abdelghani

Aug. 11, 2017

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

by TedVanGaalen

since 1.8.2017 there was no response, did already anyone thought/worked to solve this problem? Thank you, Ted TedVanGaalen wrote > Very very wild guess: it could have to do with GPU<-> Open GL? <-> Pharo > call time out issues because the Intel HD 4000 GPU is working at its > (officially allowed) upper performance limits with 3840 x 2160 at 30 Hz > refresh rate (maximum). > OTOH however: > 1. I am not a GPU Guru.. > 2. It works flawlessly with Pharo 5.0 and before. > 3. All other macOS applications also work OK. > > If it is a VM issue, Squeak would have the same problem > but I don't want to spend time to try this as well. > > TedvG -- View this message in context: http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 11, 2017

Re: [Pharo-users] Thread-safe initialization of class state (was Re: Threads safety in Pharo)

by Denis Kudriashov

What package you explore? I not find fileTypes method in Pharo 7. 2017-08-11 8:53 GMT+02:00 monty <monty2(a)programmer.net>: > Here's a hypothetical broken class method that does lazy initialization of > a class inst var: > > fileTypes > fileTypes ifNil: [ > fileTypes := Dictionary new. > fileTypes > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > at: 'pdf' put: 'Portable Document Format File'; > at: 'doc' put: 'Microsoft Word Document']. > ^ fileTypes. > > Because the assignment is done first and the initialization is done after > with a cascade of interruptable sends of #at:put:, there's a window after > the assignment where 'fileTypes' is not nil but also not fully > initialized--a race condition. > > The fix is simple. Do the initialization before the atomic assignment > takes place, so the var is only ever bound to nil or a fully initialized > object: > > fileTypes > fileTypes ifNil: [ > fileTypes := > Dictionary new > at: 'txt' put: 'Text File'; > at: 'html' put: 'Web Page'; > at: 'pdf' put: 'Portable Document Format > File'; > at: 'doc' put: 'Microsoft Word Document'; > yourself]. > ^ fileTypes. > > The fixed code is still vulnerable to duplicate initialization, because > the initialization sequence is interruptable and 'fileTypes' is nil during > it, but as long as the initialization is cheap enough, has no side effects > that restrict how often it can be done, and it's enough that the > initialized objects are equal (but not identical), that's OK. > > If it's too complex for a single statement, you can use a temp vars or put > it in a separate factory method: > > fileTypes > fileTypes ifNil: [ > fileTypes := self newFileTypes]. > ^ fileTypes. > > Similar precautions (given how easy) might as well be taken with explicit > initialization of class state too. Of course if the object is mutated later > (in other methods), then Mutexes or other constructs are needed to guard > access. But for immutable class state, ensuring initialization is done > before assignment should be enough. > > > Sent: Tuesday, August 01, 2017 at 7:36 AM > > From: "Stephane Ducasse" <stepharo.self(a)gmail.com> > > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > > Subject: Re: [Pharo-users] Threads safety in Pharo > > > > I would love to have an analysis of assumptions made in some code. > > Because my impression is that the concurrent code is sometimes defined > > knowing the underlying logic of scheduler and this is not good. > > As I said to abdel privately in french it would be great to start from > > my french squeak book (Yes I wrote one long time ago) chapter on > > concurrent programming and turn it into a pharo chapter. > > > > Stef > > > > On Tue, Aug 1, 2017 at 1:31 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > Not sure I'll have what you're looking for, but to start, do you mean > > > Pharo's green threads or vm native threads? > > > cheers -ben > > > > > > On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani via Pharo-users > > > <pharo-users(a)lists.pharo.org> wrote: > > >> > > >> > > >> > > >> ---------- Forwarded message ---------- > > >> From: Alidra Abdelghani <alidrandco(a)yahoo.fr> > > >> To: pharo-users(a)lists.pharo.org > > >> Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>, farid arfi > > >> <arfi_f(a)hotmail.com> > > >> Bcc: > > >> Date: Mon, 31 Jul 2017 01:38:58 +0200 > > >> Subject: Threads safety in Pharo > > >> Hi, > > >> > > >> Somebody once evoked the problem of threads safety in Pharo. With a > friend > > >> of mine who is expert in formal methods and process scheduling, we > would > > >> like to have a look on it. > > >> Does anyone knows a good document describing the problem of Pharo with > > >> threads safety or at least any document that we can start with? > > >> > > >> Thanks in advance, > > >> Abdelghani > > >> > > >> > > >> > > > > > > >

Aug. 11, 2017

VM dev and compilation

by Bruno Durin

Hi, I have been tinkering with Pharo and Squeak for a few weeks and I am very enthusiastic with these great pieces of software! I would like to ask questions to check my understanding. I am refering from time to time to Squeak as it runs on the same VM as Pharo but my questions are focused on Pharo. As an exercice to learn, I am trying to compile Pharo VMs and get the VM simulator run in a Pharo image (first a 32-bit image+VM and later a 64-bit image+VM). I am doing this both under Ubuntu 14.04 LTS and Mac OS X 10.12.6. What I succeeded in doing: - compiling the squeak and pharo VM using the state of their respective git repo as of about 20 July 2017: on Mac both 32 and 64 bits, on Linux only 64 bits (mainly because I did not want to spend the time to fix the 32-bit libraries which do not coexist well with their 64-bit counterparts), - on Mac, generating the VM development image (SpurVMMaker) for Squeak on top a (32 bits) V5 image, launch it and run the VM simulator, - on Mac, generating the VM development image (generator.image) for Pharo on top of a (32 bits) V5 image, launch it and starting to run a CogVMSimulator (which currently fails, but I am debugging it and learning along the way.) So, my questions: 1) About the Pharo VM compilation (Below "the" Pharo VM means the official VMs that are published on the Pharo website but if VM developers use a different process between 2 releases I would be happy to know the differences.) a) is it correct that the Pharo VM is built using the github pharo-vm repository? b) in the pharo-vm tree, is it correct that "build" and "results" directories are remnant of the build process before Pharo reunited with Squeak on opensmalltalk vm and that the builder classes in the generator.image (PharoVMSpur32Builder and co) do not create the build.sh script in the "build" directory any more. c) is it correct that the Pharo VM is now built with the pharo.cog.spur (for example) make process in the various build sub-directories of the "opensmalltalk-vm" directory? 2) When running a Pharo VM compiled on Mac, the GUI was noticeably slower that the official VM downloaded from pharo.org. (I compared running the official image.) I did not see such slow down when compiling a Squeak VM. My educated guess is that it is related to libcairo and dependencies. Are there compiler optimisations that I should have manually added? Should I generate a XCode project with cmake and compile in XCode (I currently use ./mvm make script)? I have not had this problem under Linux. 3) On Mac, is the difference between having the plugins as Mach-O bundle in Squeak and as dylib libraries in Pharo only a packaging choice or does it have deeper implications? (Does it change for example the way FFI is done?) 4) Do I understand well that currently the simplest way to convert a 32-bit image to a 64-bit one is to use Spur32to64BitBootstrap class in a VM development image? (As far as I understand, the other way is to use SystemTracer.) A remark: when manually compiling a Pharo VM in the pharo-vm repo following Eliot's instructions, the updateSCCSVersions script does not work (because it is one level down with respect to the top of the git tree as compared to the opensmalltalk-vm repository). I eventually understood that the correct build procedure is in the travis scripts but as I do not know well the CI tools, it took a long time before I thought of looking into these scripts. If pharo-vm is used to build the Pharo VM (see question 1.a) I think it would be good to update the build process in README.md in pharo-vm tree (and I can do it). Thanks, Bruno

Aug. 11, 2017