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

Re: [Pharo-users] doesNotUnderstand: infinit loop

by Denis Kudriashov

And it works in Squeak 2017-03-16 16:56 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I opened issue 19848 > <https://pharo.fogbugz.com/f/cases/19848/Step-over-or-though-expression-with…> > > 2017-03-16 16:36 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> That is sad. It works from workspace but not during debugging tests. >> >> 2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >>> Was this fixed? >>> >>> I'm debugging unit tests and I'm getting an infinte loop everytime a >>> MNU is triggered. >>> >>> MessageNotUnderstood: receiver of "new" is nil >>> UndefinedObject(Object)>>doesNotUnderstand: #new >>> Message>>sentTo: >>> UndefinedObject(Object)>>doesNotUnderstand: #new >>> Message>>sentTo: >>> >>> VM: Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 >>> CoInterpreter VMMaker.oscog-eem.1855 uuid: >>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>> https://github.com/pharo-project/pharo-vm.git Commit: >>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 >>> +0200 Jenkins build #589 >>> >>> Image: 6521 >>> >>> Best regards, >>> >>> Esteban A. Maringolo >>> >>> >>> 2016-09-21 15:01 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: >>> > Hi Guille, >>> > >>> > I was wondering if I could have kill manually this process, but the >>> > process browser does not let you do that mistake. >>> > >>> > Thanks for the tip. >>> > >>> > Hilaire >>> > >>> > Le 21/09/2016 Ã 12:11, Guille Polito a Ã©crit : >>> >> Hi Hilaire, all, >>> >> >>> >> I started digging this morning on this issue, and I see why we can >>> have >>> >> such problems. >>> >> >>> >> Apparently, there is some strange case that produces a bug in >>> UIManager. >>> >> To explain it with code, the UIManager should satisfy allways the >>> >> following invariant. >>> >> >>> >> "If executed from a workspace/playground. i.e., the UI process >>> itself:" >>> >> UIManager default uiProcess == Processor activeProcess. => true >>> >> >>> >> Somehow, in the image you provided me, it is not the case. >>> >> >>> >> I'm still taking a look at what would cause this. And I also think we >>> >> still have this bug in pharo 6 (and thus pharo 5) because I found it >>> >> lately very often. >>> >> >>> >> In the meantime, if you find that your image is causing you these >>> >> problems, you can workaround it by executing: >>> >> >>> >> UIManager default spawnNewProcess. >>> >> >>> >> Once you do that, the ui process should come back to a correct state >>> and >>> >> the debugger should behave as expected. >>> >> >>> >> Guille >>> > >>> > -- >>> > Dr. Geo >>> > http://drgeo.eu >>> > >>> > >>> >>> >> >

March 16, 2017

Re: [Pharo-users] doesNotUnderstand: infinit loop

by Denis Kudriashov

I opened issue 19848 <https://pharo.fogbugz.com/f/cases/19848/Step-over-or-though-expression-with…> 2017-03-16 16:36 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > That is sad. It works from workspace but not during debugging tests. > > 2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > >> Was this fixed? >> >> I'm debugging unit tests and I'm getting an infinte loop everytime a >> MNU is triggered. >> >> MessageNotUnderstood: receiver of "new" is nil >> UndefinedObject(Object)>>doesNotUnderstand: #new >> Message>>sentTo: >> UndefinedObject(Object)>>doesNotUnderstand: #new >> Message>>sentTo: >> >> VM: Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 >> CoInterpreter VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> https://github.com/pharo-project/pharo-vm.git Commit: >> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 >> +0200 Jenkins build #589 >> >> Image: 6521 >> >> Best regards, >> >> Esteban A. Maringolo >> >> >> 2016-09-21 15:01 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: >> > Hi Guille, >> > >> > I was wondering if I could have kill manually this process, but the >> > process browser does not let you do that mistake. >> > >> > Thanks for the tip. >> > >> > Hilaire >> > >> > Le 21/09/2016 Ã 12:11, Guille Polito a Ã©crit : >> >> Hi Hilaire, all, >> >> >> >> I started digging this morning on this issue, and I see why we can have >> >> such problems. >> >> >> >> Apparently, there is some strange case that produces a bug in >> UIManager. >> >> To explain it with code, the UIManager should satisfy allways the >> >> following invariant. >> >> >> >> "If executed from a workspace/playground. i.e., the UI process itself:" >> >> UIManager default uiProcess == Processor activeProcess. => true >> >> >> >> Somehow, in the image you provided me, it is not the case. >> >> >> >> I'm still taking a look at what would cause this. And I also think we >> >> still have this bug in pharo 6 (and thus pharo 5) because I found it >> >> lately very often. >> >> >> >> In the meantime, if you find that your image is causing you these >> >> problems, you can workaround it by executing: >> >> >> >> UIManager default spawnNewProcess. >> >> >> >> Once you do that, the ui process should come back to a correct state >> and >> >> the debugger should behave as expected. >> >> >> >> Guille >> > >> > -- >> > Dr. Geo >> > http://drgeo.eu >> > >> > >> >> >

March 16, 2017

Re: [Pharo-users] doesNotUnderstand: infinit loop

by Denis Kudriashov

That is sad. It works from workspace but not during debugging tests. 2017-03-16 15:11 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Was this fixed? > > I'm debugging unit tests and I'm getting an infinte loop everytime a > MNU is triggered. > > MessageNotUnderstood: receiver of "new" is nil > UndefinedObject(Object)>>doesNotUnderstand: #new > Message>>sentTo: > UndefinedObject(Object)>>doesNotUnderstand: #new > Message>>sentTo: > > VM: Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 > +0200 Jenkins build #589 > > Image: 6521 > > Best regards, > > Esteban A. Maringolo > > > 2016-09-21 15:01 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: > > Hi Guille, > > > > I was wondering if I could have kill manually this process, but the > > process browser does not let you do that mistake. > > > > Thanks for the tip. > > > > Hilaire > > > > Le 21/09/2016 Ã 12:11, Guille Polito a Ã©crit : > >> Hi Hilaire, all, > >> > >> I started digging this morning on this issue, and I see why we can have > >> such problems. > >> > >> Apparently, there is some strange case that produces a bug in UIManager. > >> To explain it with code, the UIManager should satisfy allways the > >> following invariant. > >> > >> "If executed from a workspace/playground. i.e., the UI process itself:" > >> UIManager default uiProcess == Processor activeProcess. => true > >> > >> Somehow, in the image you provided me, it is not the case. > >> > >> I'm still taking a look at what would cause this. And I also think we > >> still have this bug in pharo 6 (and thus pharo 5) because I found it > >> lately very often. > >> > >> In the meantime, if you find that your image is causing you these > >> problems, you can workaround it by executing: > >> > >> UIManager default spawnNewProcess. > >> > >> Once you do that, the ui process should come back to a correct state and > >> the debugger should behave as expected. > >> > >> Guille > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > >

March 16, 2017

Re: [Pharo-users] Specifying library dependencies in UFFI

by Dimitris Chloupis

My point was that anything you do in Pharo will lower performance quite a bit, but it wont be noticable anyway unless its in a big loop or something. Second that Pharo cannot debug such issues which is a huge deal when you work with OS stuff and OS calls. You are far better doing this outside UFFI and straight inside a C IDE because you will have an army of tools that will make your life a ton easier. Hence why I talked about performance, C coding and Pharo crashes. In my case I had to write and test the code in C to port it to UFFI because it was impossible to resolve the bugs from inside Pharo. Also crashing Pharo all the time got really annoying and I managed to corrupt a couple of images too in the process. Of course debugging C code from a C IDE is quite similar to how you work with Pharo. I also got an experience with loading libraries because I worked with Shared memory mapped files which is the technology OS uses to load DLLs. Its really low level stuff that come directly from OS kernel. It was a ton of fun. Also C is easier because obviously there is a ton of docs and all you have to do is copy paste. In case of UFFI you have to first figure out the C code and then how to convert it to UFFI so its double the effort for little gain. Its much better thing to just wrap C code and minimize the usage of UFFI. The benefits of Pharo are lost anyway as soon as you drop so low level. On Thu, Mar 16, 2017 at 3:05 PM <raffaello.giulietti(a)lifeware.ch> wrote: > Indeed, experimenting using some combination of AddDllDirectory(), > SetDllDirectory() and LoadLibraryEx() was in my plan for next week. > > Thanks > > > > On 16/03/17 11:59, Mark Bestley wrote: > > Yes the calling process can alter where these indirect DLLs are loaded > > from and so should be able to be done in UFFI and directly from Smalltalk > > > > The OS will load the DLL specified then it runs DllMain and doing that > > causes the OS to load any DLLs that it calls > > > > MSDN https://msdn.microsoft.com/en-us/library/7d83bc18.aspx says > > > > With both implicit and explicit linking, Windows first searches for > > "known DLLs", such as Kernel32.dll and User32.dll. Windows then searches > > for the DLLs in the following sequence: > > The directory where the executable module for the current process is > > located. > > The current directory. > > The Windows system directory. The GetSystemDirectory function retrieves > > the path of this directory. > > The Windows directory. The GetWindowsDirectory function retrieves the > > path of this directory. > > The directories listed in the PATH environment variable. > > > > > > This can be changed using the call LoadLibraryEx instead of LoadLibrary > > Flags can be set to change the directories used > > > > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).… > > > > > > > > Also see AddDllDirectory > > > https://msdn.microsoft.com/en-us/library/windows/desktop/hh310513(v=vs.85).… > > > > > > Mark > > > > On 15/03/2017 17:22, Raffaello Giulietti wrote: > >> Hi Dimitris, > >> > >> I don't get your point about proper C coding, C performance or Pharo > >> crashes. It is not the focus of this thread. > >> > >> How dependencies between libraries are resolved at load-time is dictated > >> by the OS. If the OS offers a working mechanism to specify folders that > >> the OS uses to search for libraries at load-time, well, I think that > >> Pharo, hence the UFFI, should offer it as well and in a more fashionable > >> format. > >> UFFI is quite elegant in many respects but I wouldn't call it a > >> minimalist design (zero hand holding, if I understand you correctly). > >> But I'm happy the extra elegance is there because it makes life more > >> comfortable. > >> > >> Again, I still have to experiment with SetDllDirectory() in the case of > >> Windows, so I'm not in a position to say something authoritative yet. > >> > >> > >> > >> > >> > >> > >> > >> On 2017-03-15 17:41, Dimitris Chloupis wrote: > >>> Please note the moment you use a FFI of any language you step to a C > >>> territory. VMs tend not to touch the code because the code is already > >>> in machine code format. > >>> > >>> There is zero reason for UFFI to worry about the dependencies of a > >>> library loaded, this must happen at the library level that UFFI does > >>> not focus on. > >>> > >>> What you describe here is standard practice because the vast majority > >>> of libraries depend on other libraries. In the end UFFI or any FFI in > >>> any language is not there to replace proper C coding but rather to > >>> allow you to utilize C libraries. You cannot hope to achieve > >>> performance comparable to C if you try to use a language that is not C > >>> to do standard things like dependency management. > >>> > >>> If the library fail to load it wont be because of UFFI it will be > >>> because the library is buggy at handling its dependencies. That means > >>> that the library will be buggy even if you use it from C directly. > >>> > >>> Even you do not know what you doing at C level, you going to crash > >>> Pharo countless times anyway and the least of your worries will be > >>> handling dependencies which far more obvious than some other nasty C > >>> bugs. > >>> > >>> I think its a great idea that UFFI does zero hand holding. This way it > >>> gives the clear message that if you do not understand C then you > >>> should not be using the UFFI in the first place. > >>> > >>> On Wed, Mar 15, 2017 at 4:51 PM Esteban Lorenzano > >>> <estebanlm(a)gmail.com > >>> <mailto:estebanlm@gmail.com>> wrote: > >>> > >>> > >>> > On 15 Mar 2017, at 15:44, Raffaello Giulietti > >>> <raffaello.giulietti(a)lifeware.ch > >>> <mailto:raffaello.giulietti@lifeware.ch>> > >>> wrote: > >>> > > >>> > On 2017-03-15 15:20, Esteban Lorenzano wrote: > >>> >> > >>> >>> On 15 Mar 2017, at 15:08, Raffaello Giulietti > >>> <raffaello.giulietti(a)lifeware.ch > >>> <mailto:raffaello.giulietti@lifeware.ch>> > >>> wrote: > >>> >>> > >>> >>> Hi Esteban, > >>> >>> > >>> >>> I understand this is the current status of the UFFI, so I can > >>> certainly use the workarounds discussed below. > >>> >>> > >>> >>> But I hope UFFI will soon offer a more "declarative" way to > >>> specify the search folders, kind of LD_LIBRARY_PATH mechanism but > >>> in the UFFI. > >>> >> > >>> >> that will NOT solve the problem of dependencies of libraries > >>> indirectly references. > >>> >> There is no way to do that (indirect reference solving) on an > >>> executing program that I know. > >>> >> So is not âcurrent status of UFFIâ: it will never provide that. > >>> >> > >>> > > >>> > Do you mean that SetDllDirectory() has no influence when invoked > >>> between Pharo's start and the LoadLibrary() call done by the UFFI? > >>> > >>> I really have no idea. You can try to add it to your app. > >>> > >>> Esteban > >>> > >>> > > >>> > > >>> > > >>> > > >>> >> All that, unless someone come and says: "look, Esteban is like > >>> thisâ. > >>> >> > >>> >> I spent last three weeks (not full time of course) trying to do > >>> exactly that for our current linux vm, to force libgit2 to use the > >>> version of libssh2 we want (and not the version on system)â¦ and I > >>> failed. I solved some cases, but not all. So at the end I opted to > >>> change zeroconf to define LD_LIBRARY_PATH before calling pharo. > >>> Only way I found I can force the lookup paths. > >>> >> > >>> >> cheers, > >>> >> Esteban > >>> >> > >>> >>> > >>> >>> > >>> >>> > >>> >>> Greetings > >>> >>> Raffaello > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> On 2017-03-15 14:52, Esteban Lorenzano wrote: > >>> >>>> Hi, > >>> >>>> > >>> >>>> UFFI cannot do what you want. > >>> >>>> If I understand well, you have: > >>> >>>> > >>> >>>> Pharo -> libA.dll -> libB.dll > >>> >>>> > >>> >>>> Pharo does a LoadLibrary(libA.dll), but has no control on how > >>> libA calls libBâ¦ and is not possible for us to influence it more > >>> than the predefined platform ways. > >>> >>>> > >>> >>>> One posible workaround (just possible, no idea if it will > >>> work) is to perform a load of libB before is required by libB. > >>> Then hopefully the loader will understand is same library and will > >>> answer same handler (but not sure, because if it discriminates by > >>> pathâ¦ then youâre in the same position). Anyway, if you want to > >>> try it, it would be something like this: > >>> >>>> > >>> >>>> DynamicLoader loadLibrary: 'path/to/libB.dllâ. > >>> >>>> DynamicLoader loadLibrary: 'path/to/libA.dllâ. > >>> >>>> > >>> >>>> then you can try to execute functions of libAâ¦ > >>> >>>> > >>> >>>> cheers, > >>> >>>> Esteban > >>> >>>> > >>> >>>> > >>> >>>>> On 15 Mar 2017, at 14:32, Raffaello Giulietti > >>> <raffaello.giulietti(a)lifeware.ch > >>> <mailto:raffaello.giulietti@lifeware.ch>> > >>> wrote: > >>> >>>>> > >>> >>>>> On 2017-03-15 13:51, Ben Coman wrote: > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti > >>> >>>>>> > >>> <raffaello.giulietti(a)lifeware.ch > >>> <mailto:raffaello.giulietti@lifeware.ch> > >>> >>>>>> > >>> <mailto:raffaello.giulietti@lifeware.ch > >>> <mailto:raffaello.giulietti@lifeware.ch>>> > >>> wrote: > >>> >>>>>> > >>> >>>>>> Hi Ben, > >>> >>>>>> > >>> >>>>>> my understanding is that SetDllDirectory only affects the > >>> search > >>> >>>>>> path of libraries that are loaded at *run-time* with > >>> LoadLibrary. > >>> >>>>>> > >>> >>>>>> What I'm asking for is a mechanism that works at > >>> *load-time*, when a > >>> >>>>>> library I'm accessing directly depends on another one > >>> which I'm not > >>> >>>>>> targeting directly. > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> I don't quite follow. I'm not intimate with Windows > >>> dynamic loading, so > >>> >>>>>> these questions are an opportunity for me to learn... > >>> >>>>>> > >>> >>>>>> You can't mean when Pharo loads, because it wouldn't know > >>> of OTHER.DLL ? > >>> >>>>>> > >>> >>>>>> Do you mean that LoadLibrary is not called explicitly by > >>> YOUR.DLL before > >>> >>>>>> its uses the function from OTHER.DLL? > >>> >>>>>> > >>> >>>>> > >>> >>>>> During the build of YOUR.DLL, you can specify that it should > >>> depend on OTHER.LIB (kind of binary which lists function headers > >>> and static data declarations for OTHER.DLL). Linking resolution is > >>> then done at load-time of YOUR.DLL, not by invoking > >>> LoadLibrary("OTHER.DLL"). > >>> >>>>> > >>> >>>>> When YOUR.DLL is loaded by UFFI at run-time (here by means > >>> of LoadLibrary(), I guess), Windows (not the UFFI) also attempts > >>> to load OTHER.DLL because of the linking information gathered > >>> during the build. Notice that the linking information does *not* > >>> include a specific path for OTHER.DLL. > >>> >>>>> > >>> >>>>> (You don't have to mention standard *.LIBs like Kernel32.lib > >>> because they are included by default. But of course, Windows knows > >>> where to find the corresponding .dll.) > >>> >>>>> > >>> >>>>> OTHER.DLL is searched using the strategy described in the > >>> MSDN page you mention. My expectation is/was that UFFI has/had an > >>> API for specifying the search paths where to find OTHER.DLL in a > >>> platform-independent way. In other words, I would expect the UFFI > >>> to do the call of SetDllDirectory() or whatever is needed on > >>> Windows for me or to use other mechanisms on other platforms. > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>>> Do you mean you link OTHER.DLL to YOUR.DLL at compile time? > >>> >>>>>> But still, YOUR.DLL it not loaded until called via Pharo > >>> FFI, so neither > >>> >>>>>> is OTHER.DLL, > >>> >>>>>> and Dynamic-Link Library Search Order [1] says... "If a DLL > >>> with the > >>> >>>>>> same module name > >>> >>>>>> is already loaded in memory, the system uses the loaded > >>> DLL, no matter > >>> >>>>>> which directory it is in. > >>> >>>>>> The system does not search for the DLL." > >>> >>>>>> > >>> >>>>>> So maybe before calling any of YOUR.DLL, > >>> >>>>>> do a SetDllDirectory followed by a LoadLibrary(OTHER.DLL) > >>> >>>>>> and later when you call into YOUR.DLL, > >>> >>>>>> OTHER.DLL is already loaded. > >>> >>>>>> > >>> >>>>> > >>> >>>>> Yes, this might work but is rather contrived. > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>>> Otherwise it would seems(?) your options are either > Manifests > >>> >>>>>> or Dynamic-Link Library Redirection, both done outside of > >>> Pharo. > >>> >>>>>> > >>> >>>>> > >>> >>>>> What if neither YOUR.DLL nor OTHER.DLL are under my control? > >>> The only thing I know is where the .dll and the corresponding .lib > >>> + .h are. > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> Thanks for your interest > >>> >>>>> Raffaello > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>>> But I'll try whether SetDllDirectory also affects > >>> load-time searches. > >>> >>>>>> > >>> >>>>>> Anyway, I hope future versions of the UFFI to offer > >>> setting the > >>> >>>>>> search paths more easily. > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> Greetings > >>> >>>>>> Raffaello > >>> >>>>>> > >>> >>>>> > >>> >>>>> > >>> >>>> > >>> >>>> > >>> >>> > >>> >>> > >>> >> > >>> >> > >>> > > >>> > > >>> > >>> > >> > > > > > > >

March 16, 2017

Re: [Pharo-users] doesNotUnderstand: infinit loop

by Esteban A. Maringolo

Was this fixed? I'm debugging unit tests and I'm getting an infinte loop everytime a MNU is triggered. MessageNotUnderstood: receiver of "new" is nil UndefinedObject(Object)>>doesNotUnderstand: #new Message>>sentTo: UndefinedObject(Object)>>doesNotUnderstand: #new Message>>sentTo: VM: Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 Jenkins build #589 Image: 6521 Best regards, Esteban A. Maringolo 2016-09-21 15:01 GMT-03:00 Hilaire <hilaire(a)drgeo.eu>: > Hi Guille, > > I was wondering if I could have kill manually this process, but the > process browser does not let you do that mistake. > > Thanks for the tip. > > Hilaire > > Le 21/09/2016 Ã 12:11, Guille Polito a Ã©crit : >> Hi Hilaire, all, >> >> I started digging this morning on this issue, and I see why we can have >> such problems. >> >> Apparently, there is some strange case that produces a bug in UIManager. >> To explain it with code, the UIManager should satisfy allways the >> following invariant. >> >> "If executed from a workspace/playground. i.e., the UI process itself:" >> UIManager default uiProcess == Processor activeProcess. => true >> >> Somehow, in the image you provided me, it is not the case. >> >> I'm still taking a look at what would cause this. And I also think we >> still have this bug in pharo 6 (and thus pharo 5) because I found it >> lately very often. >> >> In the meantime, if you find that your image is causing you these >> problems, you can workaround it by executing: >> >> UIManager default spawnNewProcess. >> >> Once you do that, the ui process should come back to a correct state and >> the debugger should behave as expected. >> >> Guille > > -- > Dr. Geo > http://drgeo.eu > >

March 16, 2017

Re: [Pharo-users] Specifying library dependencies in UFFI

by raffaello.giulietti＠lifeware.ch

Indeed, experimenting using some combination of AddDllDirectory(), SetDllDirectory() and LoadLibraryEx() was in my plan for next week. Thanks On 16/03/17 11:59, Mark Bestley wrote: > Yes the calling process can alter where these indirect DLLs are loaded > from and so should be able to be done in UFFI and directly from Smalltalk > > The OS will load the DLL specified then it runs DllMain and doing that > causes the OS to load any DLLs that it calls > > MSDN https://msdn.microsoft.com/en-us/library/7d83bc18.aspx says > > With both implicit and explicit linking, Windows first searches for > "known DLLs", such as Kernel32.dll and User32.dll. Windows then searches > for the DLLs in the following sequence: > The directory where the executable module for the current process is > located. > The current directory. > The Windows system directory. The GetSystemDirectory function retrieves > the path of this directory. > The Windows directory. The GetWindowsDirectory function retrieves the > path of this directory. > The directories listed in the PATH environment variable. > > > This can be changed using the call LoadLibraryEx instead of LoadLibrary > Flags can be set to change the directories used > > https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).… > > > > Also see AddDllDirectory > https://msdn.microsoft.com/en-us/library/windows/desktop/hh310513(v=vs.85).… > > > Mark > > On 15/03/2017 17:22, Raffaello Giulietti wrote: >> Hi Dimitris, >> >> I don't get your point about proper C coding, C performance or Pharo >> crashes. It is not the focus of this thread. >> >> How dependencies between libraries are resolved at load-time is dictated >> by the OS. If the OS offers a working mechanism to specify folders that >> the OS uses to search for libraries at load-time, well, I think that >> Pharo, hence the UFFI, should offer it as well and in a more fashionable >> format. >> UFFI is quite elegant in many respects but I wouldn't call it a >> minimalist design (zero hand holding, if I understand you correctly). >> But I'm happy the extra elegance is there because it makes life more >> comfortable. >> >> Again, I still have to experiment with SetDllDirectory() in the case of >> Windows, so I'm not in a position to say something authoritative yet. >> >> >> >> >> >> >> >> On 2017-03-15 17:41, Dimitris Chloupis wrote: >>> Please note the moment you use a FFI of any language you step to a C >>> territory. VMs tend not to touch the code because the code is already >>> in machine code format. >>> >>> There is zero reason for UFFI to worry about the dependencies of a >>> library loaded, this must happen at the library level that UFFI does >>> not focus on. >>> >>> What you describe here is standard practice because the vast majority >>> of libraries depend on other libraries. In the end UFFI or any FFI in >>> any language is not there to replace proper C coding but rather to >>> allow you to utilize C libraries. You cannot hope to achieve >>> performance comparable to C if you try to use a language that is not C >>> to do standard things like dependency management. >>> >>> If the library fail to load it wont be because of UFFI it will be >>> because the library is buggy at handling its dependencies. That means >>> that the library will be buggy even if you use it from C directly. >>> >>> Even you do not know what you doing at C level, you going to crash >>> Pharo countless times anyway and the least of your worries will be >>> handling dependencies which far more obvious than some other nasty C >>> bugs. >>> >>> I think its a great idea that UFFI does zero hand holding. This way it >>> gives the clear message that if you do not understand C then you >>> should not be using the UFFI in the first place. >>> >>> On Wed, Mar 15, 2017 at 4:51 PM Esteban Lorenzano >>> <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>> wrote: >>> >>> >>> > On 15 Mar 2017, at 15:44, Raffaello Giulietti >>> <raffaello.giulietti(a)lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch>> >>> wrote: >>> > >>> > On 2017-03-15 15:20, Esteban Lorenzano wrote: >>> >> >>> >>> On 15 Mar 2017, at 15:08, Raffaello Giulietti >>> <raffaello.giulietti(a)lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch>> >>> wrote: >>> >>> >>> >>> Hi Esteban, >>> >>> >>> >>> I understand this is the current status of the UFFI, so I can >>> certainly use the workarounds discussed below. >>> >>> >>> >>> But I hope UFFI will soon offer a more "declarative" way to >>> specify the search folders, kind of LD_LIBRARY_PATH mechanism but >>> in the UFFI. >>> >> >>> >> that will NOT solve the problem of dependencies of libraries >>> indirectly references. >>> >> There is no way to do that (indirect reference solving) on an >>> executing program that I know. >>> >> So is not âcurrent status of UFFIâ: it will never provide that. >>> >> >>> > >>> > Do you mean that SetDllDirectory() has no influence when invoked >>> between Pharo's start and the LoadLibrary() call done by the UFFI? >>> >>> I really have no idea. You can try to add it to your app. >>> >>> Esteban >>> >>> > >>> > >>> > >>> > >>> >> All that, unless someone come and says: "look, Esteban is like >>> thisâ. >>> >> >>> >> I spent last three weeks (not full time of course) trying to do >>> exactly that for our current linux vm, to force libgit2 to use the >>> version of libssh2 we want (and not the version on system)â¦ and I >>> failed. I solved some cases, but not all. So at the end I opted to >>> change zeroconf to define LD_LIBRARY_PATH before calling pharo. >>> Only way I found I can force the lookup paths. >>> >> >>> >> cheers, >>> >> Esteban >>> >> >>> >>> >>> >>> >>> >>> >>> >>> Greetings >>> >>> Raffaello >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 2017-03-15 14:52, Esteban Lorenzano wrote: >>> >>>> Hi, >>> >>>> >>> >>>> UFFI cannot do what you want. >>> >>>> If I understand well, you have: >>> >>>> >>> >>>> Pharo -> libA.dll -> libB.dll >>> >>>> >>> >>>> Pharo does a LoadLibrary(libA.dll), but has no control on how >>> libA calls libBâ¦ and is not possible for us to influence it more >>> than the predefined platform ways. >>> >>>> >>> >>>> One posible workaround (just possible, no idea if it will >>> work) is to perform a load of libB before is required by libB. >>> Then hopefully the loader will understand is same library and will >>> answer same handler (but not sure, because if it discriminates by >>> pathâ¦ then youâre in the same position). Anyway, if you want to >>> try it, it would be something like this: >>> >>>> >>> >>>> DynamicLoader loadLibrary: 'path/to/libB.dllâ. >>> >>>> DynamicLoader loadLibrary: 'path/to/libA.dllâ. >>> >>>> >>> >>>> then you can try to execute functions of libAâ¦ >>> >>>> >>> >>>> cheers, >>> >>>> Esteban >>> >>>> >>> >>>> >>> >>>>> On 15 Mar 2017, at 14:32, Raffaello Giulietti >>> <raffaello.giulietti(a)lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch>> >>> wrote: >>> >>>>> >>> >>>>> On 2017-03-15 13:51, Ben Coman wrote: >>> >>>>>> >>> >>>>>> >>> >>>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >>> >>>>>> >>> <raffaello.giulietti(a)lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch> >>> >>>>>> >>> <mailto:raffaello.giulietti@lifeware.ch >>> <mailto:raffaello.giulietti@lifeware.ch>>> >>> wrote: >>> >>>>>> >>> >>>>>> Hi Ben, >>> >>>>>> >>> >>>>>> my understanding is that SetDllDirectory only affects the >>> search >>> >>>>>> path of libraries that are loaded at *run-time* with >>> LoadLibrary. >>> >>>>>> >>> >>>>>> What I'm asking for is a mechanism that works at >>> *load-time*, when a >>> >>>>>> library I'm accessing directly depends on another one >>> which I'm not >>> >>>>>> targeting directly. >>> >>>>>> >>> >>>>>> >>> >>>>>> I don't quite follow. I'm not intimate with Windows >>> dynamic loading, so >>> >>>>>> these questions are an opportunity for me to learn... >>> >>>>>> >>> >>>>>> You can't mean when Pharo loads, because it wouldn't know >>> of OTHER.DLL ? >>> >>>>>> >>> >>>>>> Do you mean that LoadLibrary is not called explicitly by >>> YOUR.DLL before >>> >>>>>> its uses the function from OTHER.DLL? >>> >>>>>> >>> >>>>> >>> >>>>> During the build of YOUR.DLL, you can specify that it should >>> depend on OTHER.LIB (kind of binary which lists function headers >>> and static data declarations for OTHER.DLL). Linking resolution is >>> then done at load-time of YOUR.DLL, not by invoking >>> LoadLibrary("OTHER.DLL"). >>> >>>>> >>> >>>>> When YOUR.DLL is loaded by UFFI at run-time (here by means >>> of LoadLibrary(), I guess), Windows (not the UFFI) also attempts >>> to load OTHER.DLL because of the linking information gathered >>> during the build. Notice that the linking information does *not* >>> include a specific path for OTHER.DLL. >>> >>>>> >>> >>>>> (You don't have to mention standard *.LIBs like Kernel32.lib >>> because they are included by default. But of course, Windows knows >>> where to find the corresponding .dll.) >>> >>>>> >>> >>>>> OTHER.DLL is searched using the strategy described in the >>> MSDN page you mention. My expectation is/was that UFFI has/had an >>> API for specifying the search paths where to find OTHER.DLL in a >>> platform-independent way. In other words, I would expect the UFFI >>> to do the call of SetDllDirectory() or whatever is needed on >>> Windows for me or to use other mechanisms on other platforms. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> Do you mean you link OTHER.DLL to YOUR.DLL at compile time? >>> >>>>>> But still, YOUR.DLL it not loaded until called via Pharo >>> FFI, so neither >>> >>>>>> is OTHER.DLL, >>> >>>>>> and Dynamic-Link Library Search Order [1] says... "If a DLL >>> with the >>> >>>>>> same module name >>> >>>>>> is already loaded in memory, the system uses the loaded >>> DLL, no matter >>> >>>>>> which directory it is in. >>> >>>>>> The system does not search for the DLL." >>> >>>>>> >>> >>>>>> So maybe before calling any of YOUR.DLL, >>> >>>>>> do a SetDllDirectory followed by a LoadLibrary(OTHER.DLL) >>> >>>>>> and later when you call into YOUR.DLL, >>> >>>>>> OTHER.DLL is already loaded. >>> >>>>>> >>> >>>>> >>> >>>>> Yes, this might work but is rather contrived. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> Otherwise it would seems(?) your options are either Manifests >>> >>>>>> or Dynamic-Link Library Redirection, both done outside of >>> Pharo. >>> >>>>>> >>> >>>>> >>> >>>>> What if neither YOUR.DLL nor OTHER.DLL are under my control? >>> The only thing I know is where the .dll and the corresponding .lib >>> + .h are. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Thanks for your interest >>> >>>>> Raffaello >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>>> But I'll try whether SetDllDirectory also affects >>> load-time searches. >>> >>>>>> >>> >>>>>> Anyway, I hope future versions of the UFFI to offer >>> setting the >>> >>>>>> search paths more easily. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Greetings >>> >>>>>> Raffaello >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> > >>> > >>> >>> >> > >

March 16, 2017

Re: [Pharo-users] Specifying library dependencies in UFFI

by Mark Bestley

Yes the calling process can alter where these indirect DLLs are loaded from and so should be able to be done in UFFI and directly from Smalltalk The OS will load the DLL specified then it runs DllMain and doing that causes the OS to load any DLLs that it calls MSDN https://msdn.microsoft.com/en-us/library/7d83bc18.aspx says With both implicit and explicit linking, Windows first searches for "known DLLs", such as Kernel32.dll and User32.dll. Windows then searches for the DLLs in the following sequence: The directory where the executable module for the current process is located. The current directory. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory. The directories listed in the PATH environment variable. This can be changed using the call LoadLibraryEx instead of LoadLibrary Flags can be set to change the directories used https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).… Also see AddDllDirectory https://msdn.microsoft.com/en-us/library/windows/desktop/hh310513(v=vs.85).… Mark On 15/03/2017 17:22, Raffaello Giulietti wrote: > Hi Dimitris, > > I don't get your point about proper C coding, C performance or Pharo > crashes. It is not the focus of this thread. > > How dependencies between libraries are resolved at load-time is dictated > by the OS. If the OS offers a working mechanism to specify folders that > the OS uses to search for libraries at load-time, well, I think that > Pharo, hence the UFFI, should offer it as well and in a more fashionable > format. > UFFI is quite elegant in many respects but I wouldn't call it a > minimalist design (zero hand holding, if I understand you correctly). > But I'm happy the extra elegance is there because it makes life more > comfortable. > > Again, I still have to experiment with SetDllDirectory() in the case of > Windows, so I'm not in a position to say something authoritative yet. > > > > > > > > On 2017-03-15 17:41, Dimitris Chloupis wrote: >> Please note the moment you use a FFI of any language you step to a C >> territory. VMs tend not to touch the code because the code is already >> in machine code format. >> >> There is zero reason for UFFI to worry about the dependencies of a >> library loaded, this must happen at the library level that UFFI does >> not focus on. >> >> What you describe here is standard practice because the vast majority >> of libraries depend on other libraries. In the end UFFI or any FFI in >> any language is not there to replace proper C coding but rather to >> allow you to utilize C libraries. You cannot hope to achieve >> performance comparable to C if you try to use a language that is not C >> to do standard things like dependency management. >> >> If the library fail to load it wont be because of UFFI it will be >> because the library is buggy at handling its dependencies. That means >> that the library will be buggy even if you use it from C directly. >> >> Even you do not know what you doing at C level, you going to crash >> Pharo countless times anyway and the least of your worries will be >> handling dependencies which far more obvious than some other nasty C >> bugs. >> >> I think its a great idea that UFFI does zero hand holding. This way it >> gives the clear message that if you do not understand C then you >> should not be using the UFFI in the first place. >> >> On Wed, Mar 15, 2017 at 4:51 PM Esteban Lorenzano >> <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> > On 15 Mar 2017, at 15:44, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>> >> wrote: >> > >> > On 2017-03-15 15:20, Esteban Lorenzano wrote: >> >> >> >>> On 15 Mar 2017, at 15:08, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>> >> wrote: >> >>> >> >>> Hi Esteban, >> >>> >> >>> I understand this is the current status of the UFFI, so I can >> certainly use the workarounds discussed below. >> >>> >> >>> But I hope UFFI will soon offer a more "declarative" way to >> specify the search folders, kind of LD_LIBRARY_PATH mechanism but >> in the UFFI. >> >> >> >> that will NOT solve the problem of dependencies of libraries >> indirectly references. >> >> There is no way to do that (indirect reference solving) on an >> executing program that I know. >> >> So is not âcurrent status of UFFIâ: it will never provide that. >> >> >> > >> > Do you mean that SetDllDirectory() has no influence when invoked >> between Pharo's start and the LoadLibrary() call done by the UFFI? >> >> I really have no idea. You can try to add it to your app. >> >> Esteban >> >> > >> > >> > >> > >> >> All that, unless someone come and says: "look, Esteban is like >> thisâ. >> >> >> >> I spent last three weeks (not full time of course) trying to do >> exactly that for our current linux vm, to force libgit2 to use the >> version of libssh2 we want (and not the version on system)â¦ and I >> failed. I solved some cases, but not all. So at the end I opted to >> change zeroconf to define LD_LIBRARY_PATH before calling pharo. >> Only way I found I can force the lookup paths. >> >> >> >> cheers, >> >> Esteban >> >> >> >>> >> >>> >> >>> >> >>> Greetings >> >>> Raffaello >> >>> >> >>> >> >>> >> >>> >> >>> On 2017-03-15 14:52, Esteban Lorenzano wrote: >> >>>> Hi, >> >>>> >> >>>> UFFI cannot do what you want. >> >>>> If I understand well, you have: >> >>>> >> >>>> Pharo -> libA.dll -> libB.dll >> >>>> >> >>>> Pharo does a LoadLibrary(libA.dll), but has no control on how >> libA calls libBâ¦ and is not possible for us to influence it more >> than the predefined platform ways. >> >>>> >> >>>> One posible workaround (just possible, no idea if it will >> work) is to perform a load of libB before is required by libB. >> Then hopefully the loader will understand is same library and will >> answer same handler (but not sure, because if it discriminates by >> pathâ¦ then youâre in the same position). Anyway, if you want to >> try it, it would be something like this: >> >>>> >> >>>> DynamicLoader loadLibrary: 'path/to/libB.dllâ. >> >>>> DynamicLoader loadLibrary: 'path/to/libA.dllâ. >> >>>> >> >>>> then you can try to execute functions of libAâ¦ >> >>>> >> >>>> cheers, >> >>>> Esteban >> >>>> >> >>>> >> >>>>> On 15 Mar 2017, at 14:32, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>> >> wrote: >> >>>>> >> >>>>> On 2017-03-15 13:51, Ben Coman wrote: >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti >> >>>>>> >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch> >> >>>>>> >> <mailto:raffaello.giulietti@lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>> >> wrote: >> >>>>>> >> >>>>>> Hi Ben, >> >>>>>> >> >>>>>> my understanding is that SetDllDirectory only affects the >> search >> >>>>>> path of libraries that are loaded at *run-time* with >> LoadLibrary. >> >>>>>> >> >>>>>> What I'm asking for is a mechanism that works at >> *load-time*, when a >> >>>>>> library I'm accessing directly depends on another one >> which I'm not >> >>>>>> targeting directly. >> >>>>>> >> >>>>>> >> >>>>>> I don't quite follow. I'm not intimate with Windows >> dynamic loading, so >> >>>>>> these questions are an opportunity for me to learn... >> >>>>>> >> >>>>>> You can't mean when Pharo loads, because it wouldn't know >> of OTHER.DLL ? >> >>>>>> >> >>>>>> Do you mean that LoadLibrary is not called explicitly by >> YOUR.DLL before >> >>>>>> its uses the function from OTHER.DLL? >> >>>>>> >> >>>>> >> >>>>> During the build of YOUR.DLL, you can specify that it should >> depend on OTHER.LIB (kind of binary which lists function headers >> and static data declarations for OTHER.DLL). Linking resolution is >> then done at load-time of YOUR.DLL, not by invoking >> LoadLibrary("OTHER.DLL"). >> >>>>> >> >>>>> When YOUR.DLL is loaded by UFFI at run-time (here by means >> of LoadLibrary(), I guess), Windows (not the UFFI) also attempts >> to load OTHER.DLL because of the linking information gathered >> during the build. Notice that the linking information does *not* >> include a specific path for OTHER.DLL. >> >>>>> >> >>>>> (You don't have to mention standard *.LIBs like Kernel32.lib >> because they are included by default. But of course, Windows knows >> where to find the corresponding .dll.) >> >>>>> >> >>>>> OTHER.DLL is searched using the strategy described in the >> MSDN page you mention. My expectation is/was that UFFI has/had an >> API for specifying the search paths where to find OTHER.DLL in a >> platform-independent way. In other words, I would expect the UFFI >> to do the call of SetDllDirectory() or whatever is needed on >> Windows for me or to use other mechanisms on other platforms. >> >>>>> >> >>>>> >> >>>>> >> >>>>>> Do you mean you link OTHER.DLL to YOUR.DLL at compile time? >> >>>>>> But still, YOUR.DLL it not loaded until called via Pharo >> FFI, so neither >> >>>>>> is OTHER.DLL, >> >>>>>> and Dynamic-Link Library Search Order [1] says... "If a DLL >> with the >> >>>>>> same module name >> >>>>>> is already loaded in memory, the system uses the loaded >> DLL, no matter >> >>>>>> which directory it is in. >> >>>>>> The system does not search for the DLL." >> >>>>>> >> >>>>>> So maybe before calling any of YOUR.DLL, >> >>>>>> do a SetDllDirectory followed by a LoadLibrary(OTHER.DLL) >> >>>>>> and later when you call into YOUR.DLL, >> >>>>>> OTHER.DLL is already loaded. >> >>>>>> >> >>>>> >> >>>>> Yes, this might work but is rather contrived. >> >>>>> >> >>>>> >> >>>>> >> >>>>>> Otherwise it would seems(?) your options are either Manifests >> >>>>>> or Dynamic-Link Library Redirection, both done outside of >> Pharo. >> >>>>>> >> >>>>> >> >>>>> What if neither YOUR.DLL nor OTHER.DLL are under my control? >> The only thing I know is where the .dll and the corresponding .lib >> + .h are. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Thanks for your interest >> >>>>> Raffaello >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>>> But I'll try whether SetDllDirectory also affects >> load-time searches. >> >>>>>> >> >>>>>> Anyway, I hope future versions of the UFFI to offer >> setting the >> >>>>>> search paths more easily. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Greetings >> >>>>>> Raffaello >> >>>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > >> >> > -- Mark

March 16, 2017

Re: [Pharo-users] iceberg

by Damien Pollet

+1 (for some big value of one) On 16 March 2017 at 11:42, Norbert Hartl <norbert(a)hartl.name> wrote: > Sometimes tools change and you feel the change like a quantum leap. For me > it is the case when using iceberg. > > Well done, thank you very much for that. > > If Versionner would be able to edit baselines we would have a really rich > workflow for developing. > > Norbert > > > >

March 16, 2017

iceberg

by Norbert Hartl

Sometimes tools change and you feel the change like a quantum leap. For me it is the case when using iceberg. Well done, thank you very much for that. If Versionner would be able to edit baselines we would have a really rich workflow for developing. Norbert

March 16, 2017

Re: [Pharo-users] snap package can't find vm-display-X11

by Alistair Grant

On 14 March 2017 at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 13 March 2017 at 17:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Guillermo, >> ... >> >> Cairo isn't working yet. It looks like CairoLibrary makes assumptions >> about the location of libcairo.so. I'm in the middle of fixing that >> at the moment. > > I've submitted SLICE-Issue-19833-CairoLibrary-unix-module-location-assumptions-too-restrictive > which resolves the path lookup, so Cairo is now working inside the > snap package. The slice has been incorporated in to Image 60442. I've also updated the snap package: * A new convenience command to copy the image and changes file to the working directory. * A snap-compatible version of xdg-open that allows pharo to open URLs in the user's browser. * The stable 6.0 VM is now built (instead of vmLatest60). See: https://github.com/akgrant43/pharo-snap There's one annoyance: setlocale() failed (check values of LC_CTYPE, LANG and LC_ALL) is displayed in the console on startup. I'm not aware of any negative behaviour at the moment. Running locale from within the snap produces: $ locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE="en_US.UTF-8" LC_NUMERIC=en_AU.UTF-8 LC_TIME=en_AU.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=en_AU.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=en_AU.UTF-8 LC_NAME=en_AU.UTF-8 LC_ADDRESS=en_AU.UTF-8 LC_TELEPHONE=en_AU.UTF-8 LC_MEASUREMENT=en_AU.UTF-8 LC_IDENTIFICATION=en_AU.UTF-8 LC_ALL= I'm still to figure this one out. Cheers, Alistair

March 16, 2017