September 2017 - Pharo-users

Re: [Pharo-users] How to set library path for UFFI on Linux?

by Dan Wilczak

One obstacle to fixing these problems properly is that handling of library search paths is not centralized, but it really should be. A Pharo package for sqlite or cairo or whatever should provide only the library name; UFFI or some associated package should deal with the search for it. Otherwise there will just be more ad hoc code and fixes in the future. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 30, 2017

Re: [Pharo-users] How to set library path for UFFI on Linux?

by herby＠mailbox.sk

On October 1, 2017 12:33:04 AM GMT+02:00, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >Usually there are a number of names to try but on Linux, there are less >users and more distros, so people are not adding more libs to try. > >So, yes, symlink in the plugin directory works usually. > >Alternative would be to use LD_LIBRARY_PATH or pkg_config support to do >this cleanly (not done at this point). I did use LD_LIBRARY_PATH. But it did not work (it looks like Pharo vm us using it, as it is used and decorated in pharo runner script). Even link in the plugin dir did not work unless I specified simplified name. The library is libsqlite3.so.0. Using that name, it wasn't found ('lib' is probably tried, so it is likely '.0' part that somehow blocked Pharo). Shouldn't this actually be solved somehow? So linux vm loads libs using linux conventions? Or is it preinstalled wrongly in Ubuntu images on Digital Ocean when it does not have symlink named libsqlite3.so ? Herby >Phil > >On Sat, Sep 30, 2017 at 11:19 PM, Herby VojÄÃk <herby(a)mailbox.sk> >wrote: > >> Dan Wilczak wrote: >> >>> Hernan - >>> >>> I haven't opened an issue - how do I do it? (I'm very new to Pharo.) >>> >>> About continuing the search - I only mean continuing the search of >the >>> LD_LIBRARY_PATH directories, not the whole filesystem. Two changes >would >>> be >>> needed to accomplish this: >>> >> >> FWIW, I had problem with loading 'sqlite3' module. Crossposting the >> solution: >> >> It seems FFI for some reason struggles with 'lib' and/or '.so.0' >things in >> linux (even if LD_LIBRARY_PATH is properly set). >> >> I had to do this: >> >> TARGETDIR=`find . -type f -name SqueakSSL.so -print0 | xargs -0 >dirname` >> ln -s `/sbin/ldconfig -p | sed -e 's|[^/]*||' | grep sqlite3` >> ${TARGETDIR}/sqlite3.so >> >> (so, link in plugin directory, and the name is plain 'sqlite3.so'). >With >> that, things work. Maybe, libsqlite.so would do the trick as well, >but I >> got no nerve to play with it more. >> >> But, frankly, do not tell me this is what ppl need to do to load >external >> libs in linux. :-/ >> >> Herby >> >> >>> 1) Athens-Cairo>> CairoLibrary would have to return a list of paths >to >>> all >>> the matching libraries rather than just the first one that it finds. >This >>> part seems easy. >>> >>> 2) UFFI Libraries UnixDynamicLoader>> loadLibrary:flag: would have >to >>> take >>> the list of paths (rather than just one), check them for being >32-bit or >>> 64-bit, and load the first correct one. I can't find any way to >perform >>> that >>> check in Pharo directly. How would you fork or exec the "file" >command >>> from >>> inside Pharo? >>> >>> Dan >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >> >>

Sept. 30, 2017

Re: [Pharo-users] How to set library path for UFFI on Linux?

by phil＠highoctane.be

Usually there are a number of names to try but on Linux, there are less users and more distros, so people are not adding more libs to try. So, yes, symlink in the plugin directory works usually. Alternative would be to use LD_LIBRARY_PATH or pkg_config support to do this cleanly (not done at this point). Phil On Sat, Sep 30, 2017 at 11:19 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Dan Wilczak wrote: > >> Hernan - >> >> I haven't opened an issue - how do I do it? (I'm very new to Pharo.) >> >> About continuing the search - I only mean continuing the search of the >> LD_LIBRARY_PATH directories, not the whole filesystem. Two changes would >> be >> needed to accomplish this: >> > > FWIW, I had problem with loading 'sqlite3' module. Crossposting the > solution: > > It seems FFI for some reason struggles with 'lib' and/or '.so.0' things in > linux (even if LD_LIBRARY_PATH is properly set). > > I had to do this: > > TARGETDIR=`find . -type f -name SqueakSSL.so -print0 | xargs -0 dirname` > ln -s `/sbin/ldconfig -p | sed -e 's|[^/]*||' | grep sqlite3` > ${TARGETDIR}/sqlite3.so > > (so, link in plugin directory, and the name is plain 'sqlite3.so'). With > that, things work. Maybe, libsqlite.so would do the trick as well, but I > got no nerve to play with it more. > > But, frankly, do not tell me this is what ppl need to do to load external > libs in linux. :-/ > > Herby > > >> 1) Athens-Cairo>> CairoLibrary would have to return a list of paths to >> all >> the matching libraries rather than just the first one that it finds. This >> part seems easy. >> >> 2) UFFI Libraries UnixDynamicLoader>> loadLibrary:flag: would have to >> take >> the list of paths (rather than just one), check them for being 32-bit or >> 64-bit, and load the first correct one. I can't find any way to perform >> that >> check in Pharo directly. How would you fork or exec the "file" command >> from >> inside Pharo? >> >> Dan >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > > >

Sept. 30, 2017

Re: [Pharo-users] How to set library path for UFFI on Linux?

by Herby VojÄÃk

Dan Wilczak wrote: > Hernan - > > I haven't opened an issue - how do I do it? (I'm very new to Pharo.) > > About continuing the search - I only mean continuing the search of the > LD_LIBRARY_PATH directories, not the whole filesystem. Two changes would be > needed to accomplish this: FWIW, I had problem with loading 'sqlite3' module. Crossposting the solution: It seems FFI for some reason struggles with 'lib' and/or '.so.0' things in linux (even if LD_LIBRARY_PATH is properly set). I had to do this: TARGETDIR=`find . -type f -name SqueakSSL.so -print0 | xargs -0 dirname` ln -s `/sbin/ldconfig -p | sed -e 's|[^/]*||' | grep sqlite3` ${TARGETDIR}/sqlite3.so (so, link in plugin directory, and the name is plain 'sqlite3.so'). With that, things work. Maybe, libsqlite.so would do the trick as well, but I got no nerve to play with it more. But, frankly, do not tell me this is what ppl need to do to load external libs in linux. :-/ Herby > > 1) Athens-Cairo>> CairoLibrary would have to return a list of paths to all > the matching libraries rather than just the first one that it finds. This > part seems easy. > > 2) UFFI Libraries UnixDynamicLoader>> loadLibrary:flag: would have to take > the list of paths (rather than just one), check them for being 32-bit or > 64-bit, and load the first correct one. I can't find any way to perform that > check in Pharo directly. How would you fork or exec the "file" command from > inside Pharo? > > Dan > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 30, 2017

Re: [Pharo-users] How to make pharo find sqlite?

by Herby VojÄÃk

phil(a)highoctane.be wrote: > Is https://pharo.fogbugz.com/f/cases/19990 showing again? > > What is the module being loaded ? This seems to be the important question. It seems FFI for some reason struggles with 'lib' and/or '.so.0' things in linux (even if LD_LIBRARY_PATH is properly set). I had to do this: TARGETDIR=`find . -type f -name SqueakSSL.so -print0 | xargs -0 dirname` ln -s `/sbin/ldconfig -p | sed -e 's|[^/]*||' | grep sqlite3` ${TARGETDIR}/sqlite3.so (so, link in plugin directory, and the name is plain 'sqlite3.so'). With that, things work. Maybe, libsqlite.so would do the trick as well, but I got no nerve to play with it more. But, frankly, do not tell me this is what ppl need to do to load external libs in linux. :-/ Herby > Phil > > > On Sat, Sep 30, 2017 at 1:28 PM, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > > What about > > LD_LIBRARY_PATH=<sqlite3place>;$LD_LIBRARYPATH ./pharo-ui > some.image > > Phil > > > Thanks for answer, did not help. > > In fact it must be something different. As can be seen in the stack, > it fails during finalizers, and as can be seen by looking at > UDBCSQLite3DatabaseExternalObject class>>finalizeResourceData: code, > the method it calls is sqlite close. It is hardly the first method > that is should call... > > I suspect something around image save / load. Again. Lots of errors > in those parts. But may be something else, as it kicks in only when > SQLite-using tests starts to run. :-( > > Herby > > P.S.: I saw there is a similar thread out there, but it has problems > with 32bit loaded by 64bit vm; but here, I have 32bit linux, so the > vm installed should be 32bit. > > On Thu, Sep 28, 2017 at 7:40 PM, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>> wrote: > > Hello! > > I try to deploy UDBCSQLite-using image in a 32bit ubuntu > 16.04.3. > > I do have libsqlite3: > > root@32bit-agent:~# find / -name '*libsqlite*' -type f > 2>>/dev/null > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 > /var/lib/dpkg/info/libsqlite0.list > /var/lib/dpkg/info/libsqlite3-0:i386.postinst > /var/lib/dpkg/info/libsqlite3-0:i386.md5sums > /var/lib/dpkg/info/libsqlite3-0:i386.shlibs > /var/lib/dpkg/info/libsqlite0.postrm > /var/lib/dpkg/info/libsqlite3-0:i386.symbols > /var/lib/dpkg/info/libsqlite3-0:i386.list > /var/lib/dpkg/info/libsqlite3-0:i386.triggers > /var/cache/apt/archives/libsqlite0_2.8.17-12fakesync1_i386.deb > > but I get this in the output of the CI: > > 17:16:54.233 + ../pharo/pharo ./filmtower.image > conf/run-tests.st <http://run-tests.st> > <http://run-tests.st> > 17:16:54.508 pthread_setschedparam failed: Operation not > permitted > 17:16:54.509 This VM uses a separate heartbeat thread to > update its > internal clock > 17:16:54.509 and handle events. For best operation, this > thread > should run at a > 17:16:54.509 higher priority, however the VM was unable to > change > the priority. The > 17:16:54.509 effect is that heavily loaded systems may > experience > some latency > 17:16:54.509 issues. If this occurs, please create the > appropriate > configuration > 17:16:54.509 file in /etc/security/limits.d/ as shown below: > 17:16:54.509 > 17:16:54.509 cat <<END | sudo tee > /etc/security/limits.d/pharo.conf > 17:16:54.509 * hard rtprio 2 > 17:16:54.509 * soft rtprio 2 > 17:16:54.509 END > 17:16:54.509 > 17:16:54.509 and report to the pharo mailing list whether this > improves behaviour. > 17:16:54.512 > 17:16:54.512 You will need to log out and log back in for > the limits > to take effect. > 17:16:54.512 For more information please see > 17:16:54.512 > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux>> > 17:16:54.785 > 17:16:54.786 TowergameSyncTests > 17:16:54.831 Error: External module not found > 17:16:54.832 ExternalLibraryFunction(Object)>>error: > 17:16:54.832 > ExternalLibraryFunction(Object)>>externalCallFailed > 17:16:54.833 > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > 17:16:54.833 UDBCSQLite3DatabaseExternalObject > class>>finalizeResourceData: > 17:16:54.834 FFICalloutAPI>>function:module: > 17:16:54.834 UDBCSQLite3Library(Object)>>ffiCall:module: > 17:16:54.835 UDBCSQLite3DatabaseExternalObject > class>>finalizeResourceData: > 17:16:54.836 FFIExternalResourceExecutor>>finalize > 17:16:54.836 WeakFinalizerItem>>finalizeValues > 17:16:54.845 [ each finalizeValues ] in [ :each | [ each > finalizeValues ] on: Exception fork: [ :ex | ex pass ] ] in > WeakRegistry>>finalizeValues in Block: [ each finalizeValues ] > 17:16:54.846 BlockClosure>>on:do: > 17:16:54.852 [ Processor terminateActive ] in [ :ex | > 17:16:54.852 | copy onDoCtx process handler bottom thisCtx | > 17:16:54.852 onDoCtx := thisContext. > 17:16:54.852 thisCtx := onDoCtx home. > 17:16:54.852 > 17:16:54.852 "find the context on stack for which this > method's is > sender" > 17:16:54.852 [ onDoCtx sender == thisCtx ] > 17:16:54.852 whileFalse: [ onDoCtx := onDoCtx sender. > 17:16:54.852 onDoCtx > 17:16:54.852 ifNil: [ "Can't find our home > context. seems like we're already forked > 17:16:54.852 and handling another > exception in new thread. In this case, just pass it through > handler." ^ handlerAction cull: ex ] ]. > 17:16:54.852 bottom := [ Processor terminateActive ] asContext. > 17:16:54.853 onDoCtx privSender: bottom. > 17:16:54.853 handler := [ handlerAction cull: ex ] asContext. > 17:16:54.853 handler privSender: thisContext sender. > 17:16:54.853 (Process forContext: handler priority: Processor > activePriority) > 17:16:54.853 resume. > 17:16:54.853 > 17:16:54.853 "cut the stack of current process" > 17:16:54.853 thisContext privSender: thisCtx. > 17:16:54.853 nil ] in BlockClosure>>on:fork: in Block: [ > Processor > terminateActive ] > 17:16:54.989 > > Look like pharo was not able to find the sqlite3 lib. > > Any help? > > Thanks, Herby > > > > > > >

Sept. 30, 2017

Re: [Pharo-users] How to set library path for UFFI on Linux?

by Herby VojÄÃk

Stephane Ducasse wrote: Would you pls care to look at the sibling thread "How to make pharo find SQLite", it seems that it struggles with similar problem, is it supposed to created symlinks on linux, or it should be able to fund the library but somehow fails? Thanks, Herby > https://pharo.fogbugz.com > > On Sat, Sep 30, 2017 at 6:53 PM, Dan Wilczak<dan.g.wilczak(a)gmail.com> wrote: >> Hernan - >> >> I haven't opened an issue - how do I do it? (I'm very new to Pharo.) >> >> About continuing the search - I only mean continuing the search of the >> LD_LIBRARY_PATH directories, not the whole filesystem. Two changes would be >> needed to accomplish this: >> >> 1) Athens-Cairo>> CairoLibrary would have to return a list of paths to all >> the matching libraries rather than just the first one that it finds. This >> part seems easy. >> >> 2) UFFI Libraries UnixDynamicLoader>> loadLibrary:flag: would have to take >> the list of paths (rather than just one), check them for being 32-bit or >> 64-bit, and load the first correct one. I can't find any way to perform that >> check in Pharo directly. How would you fork or exec the "file" command from >> inside Pharo? >> >> Dan >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >

Sept. 30, 2017

Re: [Pharo-users] How to make pharo find sqlite?

by Herby VojÄÃk

Herby VojÄÃk wrote: > phil(a)highoctane.be wrote: >> I am using UDBCSQLite on Windows without problems. > > Me, too; when developing. > > The problem was on Linux, where I deploy. > > Things begin to look as if it was really that the module is not found, > though. Now that I saw into the code CairoLibrary does to try to find the file name, and compose the module name from that, and that in my case the library name used is the plain 'sqlite3', I don't know - am I supposed to make a symlink on the same directory as the image? Is it the thing that is normally needed / done routinely? I may try that... (but on Windows, it just finds the sqlite dll without problems). Herby > > I added more diagnostic output, to ExternalFunction >> > invokeWithArguments:, so it writes to transcript whenever the primitive > fails, writing args used to call and self. The output is suddenly filled > with output: > > 19:48:10.132 + ../pharo/pharo ./filmtower.image conf/run-tests.st > 19:48:10.662 > 19:48:10.662 TowergameServerTests > 19:48:10.781 4 run, 4 passes, 0 skipped, 0 expected failures, 0 > failures, 0 errors, 0 unexpected passes > 19:48:10.781 > 19:48:10.781 TowergameSyncTests > 19:48:10.781 > 19:48:10.782 TowergameSyncTests>>#testPlayerCanHaveDisabledDeviceSaved > 19:48:10.782 ENTER setUp > 19:48:10.804 > 19:48:10.805 an Array('' @ 16r08FF27C0) > 19:48:10.806 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.806 > 19:48:10.806 ENTER tearDown > 19:48:10.807 > 19:48:10.807 TowergameSyncTests>>#testPlayerChecksStateVersion > 19:48:10.807 ENTER setUp > 19:48:10.815 > 19:48:10.815 an Array('' @ 16r08FF1718) > 19:48:10.816 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.816 > 19:48:10.816 ENTER tearDown > 19:48:10.816 > 19:48:10.816 > TowergameSyncTests>>#testPlayerChecksStateVersionAndHasFreshlyInstalled > 19:48:10.817 ENTER setUp > 19:48:10.820 > 19:48:10.820 an Array('' @ 16r08FF2198) > 19:48:10.820 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.820 > 19:48:10.820 ENTER tearDown > 19:48:10.821 > 19:48:10.821 TowergameSyncTests>>#testPlayerChecksStateVersionAndIsBehind > 19:48:10.821 ENTER setUp > 19:48:10.829 > 19:48:10.829 an Array('' @ 16r08FFFAD8) > 19:48:10.829 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.829 > 19:48:10.830 ENTER tearDown > 19:48:10.830 > 19:48:10.830 > TowergameSyncTests>>#testPlayerChecksStateVersionFromDifferentDevice > 19:48:10.830 ENTER setUp > 19:48:10.832 > 19:48:10.832 an Array('' @ 16r08FFFAE8) > 19:48:10.832 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.832 > 19:48:10.832 ENTER tearDown > 19:48:10.832 > 19:48:10.832 > TowergameSyncTests>>#testPlayerChecksStateVersionFromDifferentDeviceAndHasFreshlyInstalled > > 19:48:10.832 ENTER setUp > 19:48:10.839 > 19:48:10.839 an Array('' @ 16r08FFFAF8) > 19:48:10.839 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.840 > 19:48:10.840 ENTER tearDown > 19:48:10.840 > 19:48:10.840 > TowergameSyncTests>>#testPlayerChecksStateVersionFromDifferentExistingDevice > > 19:48:10.840 ENTER setUp > 19:48:10.841 > 19:48:10.841 an Array('' @ 16r08FFFB08) > 19:48:10.841 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> > 19:48:10.842 > 19:48:10.842 ENTER tearDown > 19:48:10.842 > 19:48:10.842 > TowergameSyncTests>>#testPlayerChecksStateVersionFromDisabledDevice > 19:48:10.842 ENTER setUp > 19:48:10.854 > 19:48:10.854 an Array(@ 16r00000000) > 19:48:10.855 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.855 > 19:48:10.855 an Array(@ 16r00000000) > 19:48:10.855 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.856 > 19:48:10.856 an Array(@ 16r00000000) > 19:48:10.856 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.856 > 19:48:10.856 an Array(@ 16r00000000) > 19:48:10.856 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.857 > 19:48:10.857 an Array(@ 16r00000000) > 19:48:10.857 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.857 > 19:48:10.858 an Array(@ 16r00000000) > 19:48:10.861 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.861 > 19:48:10.862 an Array(@ 16r00000000) > 19:48:10.863 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> > 19:48:10.864 Error: External module not found > 19:48:10.865 ExternalLibraryFunction(Object)>>error: > etc. > > So the mystery of "where are LEAVE messages" is solved: both setUp and > tearDown failed between ENTER and LEAVE. > > Now why cannot it find the library (now I am running it in both 32bit > env as well as 64bit env, with appropriate vm installed; but always the > same: sqlite3 module is not found). > > At least it seems it is not mysterious vm bug, but (only) failure to > find an external module. Though I don't know how to solve it, > LD_LIBRARY_PATH did not help... :-/ > >> Phil >> >> On Sat, Sep 30, 2017 at 9:11 PM, Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk>> wrote: >> >> phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> Also, did you try with this VM: >> >> http://get.pharo.org/vmTLatest60 <http://get.pharo.org/vmTLatest60> >> >> >> 18:51:46.191 + curl get.pharo.org/vmTLatest60 >> <http://get.pharo.org/vmTLatest60> >> 18:51:46.207 % Total % Received % Xferd Average Speed Time >> Time Time Current >> 18:51:46.208 Dload Upload Total >> Spent Left Speed >> 18:51:46.208 >> 18:51:46.242 0 0 0 0 0 0 0 0 --:--:-- >> --:--:-- --:--:-- 0 >> 18:51:46.242 100 6126 100 6126 0 0 172k 0 --:--:-- >> --:--:-- --:--:-- 175k >> 18:51:46.253 Downloading the latest pharoVM: >> 18:51:46.253 >> http://files.pharo.org/get-files/60/pharo-linux-threaded-latest.zip >> <http://files.pharo.org/get-files/60/pharo-linux-threaded-latest.zip> >> 18:51:46.305 [pharo-vm/vm.zip] >> 18:51:46.305 End-of-central-directory signature not found. Either >> this file is not >> 18:51:46.305 a zipfile, or it constitutes one disk of a multi-part >> archive. In the >> 18:51:46.305 latter case the central directory and zipfile comment >> will be found on >> 18:51:46.305 the last disk(s) of this archive. >> 18:51:46.305 unzip: cannot find zipfile directory in one of >> pharo-vm/vm.zip or >> 18:51:46.305 pharo-vm/vm.zip.zip, and cannot find >> pharo-vm/vm.zip.ZIP, period. >> >> >> It probably does not exist any more (I tried 70+vm and it failed in >> other aspects, it wasn't able to load git repo). >> >> Tried both 61+vmT and 61+vmI both; in 32vm/32os and 64vm/64os >> combinations. Always ended with same result. >> >> Must be some error in UDBCSQLiteLibrary itself. :-/ >> >> Although the missing transcript output is scary and shows that vm >> may be culprit as well. >> >> Herby >> >> Phil >> >> On Sat, Sep 30, 2017 at 1:28 PM, Herby VojÄÃk <herby(a)mailbox.sk >> <mailto:herby@mailbox.sk> >> <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>> wrote: >> >> phil(a)highoctane.be <mailto:phil@highoctane.be> >> <mailto:phil@highoctane.be <mailto:phil@highoctane.be>> wrote: >> >> What about >> >> LD_LIBRARY_PATH=<sqlite3place>;$LD_LIBRARYPATH ./pharo-ui >> some.image >> >> Phil >> >> >> Thanks for answer, did not help. >> >> In fact it must be something different. As can be seen in >> the stack, >> it fails during finalizers, and as can be seen by looking at >> UDBCSQLite3DatabaseExternalObject >> class>>finalizeResourceData: code, >> the method it calls is sqlite close. It is hardly the first >> method >> that is should call... >> >> I suspect something around image save / load. Again. Lots >> of errors >> in those parts. But may be something else, as it kicks in >> only when >> SQLite-using tests starts to run. :-( >> >> Herby >> >> P.S.: I saw there is a similar thread out there, but it has >> problems >> with 32bit loaded by 64bit vm; but here, I have 32bit >> linux, so the >> vm installed should be 32bit. >> >> On Thu, Sep 28, 2017 at 7:40 PM, Herby VojÄÃk >> <herby(a)mailbox.sk <mailto:herby@mailbox.sk> >> <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>> >> <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk> >> <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>>> wrote: >> >> Hello! >> >> I try to deploy UDBCSQLite-using image in a 32bit >> ubuntu >> 16.04.3. >> >> I do have libsqlite3: >> >> root@32bit-agent:~# find / -name '*libsqlite*' -type f >> 2>>/dev/null >> /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 >> /var/lib/dpkg/info/libsqlite0.list >> /var/lib/dpkg/info/libsqlite3-0:i386.postinst >> /var/lib/dpkg/info/libsqlite3-0:i386.md5sums >> /var/lib/dpkg/info/libsqlite3-0:i386.shlibs >> /var/lib/dpkg/info/libsqlite0.postrm >> /var/lib/dpkg/info/libsqlite3-0:i386.symbols >> /var/lib/dpkg/info/libsqlite3-0:i386.list >> /var/lib/dpkg/info/libsqlite3-0:i386.triggers >> >> /var/cache/apt/archives/libsqlite0_2.8.17-12fakesync1_i386.deb >> >> but I get this in the output of the CI: >> >> 17:16:54.233 + ../pharo/pharo ./filmtower.image >> conf/run-tests.st <http://run-tests.st> >> <http://run-tests.st> >> <http://run-tests.st> >> 17:16:54.508 pthread_setschedparam failed: >> Operation not >> permitted >> 17:16:54.509 This VM uses a separate heartbeat >> thread to >> update its >> internal clock >> 17:16:54.509 and handle events. For best >> operation, this >> thread >> should run at a >> 17:16:54.509 higher priority, however the VM was >> unable to >> change >> the priority. The >> 17:16:54.509 effect is that heavily loaded systems may >> experience >> some latency >> 17:16:54.509 issues. If this occurs, please >> create the >> appropriate >> configuration >> 17:16:54.509 file in /etc/security/limits.d/ as >> shown below: >> 17:16:54.509 >> 17:16:54.509 cat <<END | sudo tee >> /etc/security/limits.d/pharo.conf >> 17:16:54.509 * hard rtprio 2 >> 17:16:54.509 * soft rtprio 2 >> 17:16:54.509 END >> 17:16:54.509 >> 17:16:54.509 and report to the pharo mailing list >> whether this >> improves behaviour. >> 17:16:54.512 >> 17:16:54.512 You will need to log out and log back >> in for >> the limits >> to take effect. >> 17:16:54.512 For more information please see >> 17:16:54.512 >> https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux>> >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux >> >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux>>> >> >> 17:16:54.785 >> 17:16:54.786 TowergameSyncTests >> 17:16:54.831 Error: External module not found >> 17:16:54.832 ExternalLibraryFunction(Object)>>error: >> 17:16:54.832 >> ExternalLibraryFunction(Object)>>externalCallFailed >> 17:16:54.833 >> >> ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: >> 17:16:54.833 UDBCSQLite3DatabaseExternalObject >> class>>finalizeResourceData: >> 17:16:54.834 FFICalloutAPI>>function:module: >> 17:16:54.834 >> UDBCSQLite3Library(Object)>>ffiCall:module: >> 17:16:54.835 UDBCSQLite3DatabaseExternalObject >> class>>finalizeResourceData: >> 17:16:54.836 FFIExternalResourceExecutor>>finalize >> 17:16:54.836 WeakFinalizerItem>>finalizeValues >> 17:16:54.845 [ each finalizeValues ] in [ :each | >> [ each >> finalizeValues ] on: Exception fork: [ :ex | ex >> pass ] ] in >> WeakRegistry>>finalizeValues in Block: [ each >> finalizeValues ] >> 17:16:54.846 BlockClosure>>on:do: >> 17:16:54.852 [ Processor terminateActive ] in [ :ex | >> 17:16:54.852 | copy onDoCtx process handler bottom >> thisCtx | >> 17:16:54.852 onDoCtx := thisContext. >> 17:16:54.852 thisCtx := onDoCtx home. >> 17:16:54.852 >> 17:16:54.852 "find the context on stack for which this >> method's is >> sender" >> 17:16:54.852 [ onDoCtx sender == thisCtx ] >> 17:16:54.852 whileFalse: [ onDoCtx := onDoCtx >> sender. >> 17:16:54.852 onDoCtx >> 17:16:54.852 ifNil: [ "Can't >> find our home >> context. seems like we're already forked >> 17:16:54.852 and >> handling another >> exception in new thread. In this case, just pass >> it through >> handler." ^ handlerAction cull: ex ] ]. >> 17:16:54.852 bottom := [ Processor terminateActive >> ] asContext. >> 17:16:54.853 onDoCtx privSender: bottom. >> 17:16:54.853 handler := [ handlerAction cull: ex ] >> asContext. >> 17:16:54.853 handler privSender: thisContext sender. >> 17:16:54.853 (Process forContext: handler >> priority: Processor >> activePriority) >> 17:16:54.853 resume. >> 17:16:54.853 >> 17:16:54.853 "cut the stack of current process" >> 17:16:54.853 thisContext privSender: thisCtx. >> 17:16:54.853 nil ] in BlockClosure>>on:fork: in >> Block: [ >> Processor >> terminateActive ] >> 17:16:54.989 >> >> Look like pharo was not able to find the sqlite3 lib. >> >> Any help? >> >> Thanks, Herby >> >> >> >> >> >> >> >> >> >> >> > >

Sept. 30, 2017

Re: [Pharo-users] How to set library path for UFFI on Linux?

by Stephane Ducasse

https://pharo.fogbugz.com On Sat, Sep 30, 2017 at 6:53 PM, Dan Wilczak <dan.g.wilczak(a)gmail.com> wrote: > Hernan - > > I haven't opened an issue - how do I do it? (I'm very new to Pharo.) > > About continuing the search - I only mean continuing the search of the > LD_LIBRARY_PATH directories, not the whole filesystem. Two changes would be > needed to accomplish this: > > 1) Athens-Cairo >> CairoLibrary would have to return a list of paths to all > the matching libraries rather than just the first one that it finds. This > part seems easy. > > 2) UFFI Libraries UnixDynamicLoader >> loadLibrary:flag: would have to take > the list of paths (rather than just one), check them for being 32-bit or > 64-bit, and load the first correct one. I can't find any way to perform that > check in Pharo directly. How would you fork or exec the "file" command from > inside Pharo? > > Dan > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 30, 2017

Re: [Pharo-users] How to make pharo find sqlite?

by Herby VojÄÃk

phil(a)highoctane.be wrote: > I am using UDBCSQLite on Windows without problems. Me, too; when developing. The problem was on Linux, where I deploy. Things begin to look as if it was really that the module is not found, though. I added more diagnostic output, to ExternalFunction >> invokeWithArguments:, so it writes to transcript whenever the primitive fails, writing args used to call and self. The output is suddenly filled with output: 19:48:10.132 + ../pharo/pharo ./filmtower.image conf/run-tests.st 19:48:10.662 19:48:10.662 TowergameServerTests 19:48:10.781 4 run, 4 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes 19:48:10.781 19:48:10.781 TowergameSyncTests 19:48:10.781 19:48:10.782 TowergameSyncTests>>#testPlayerCanHaveDisabledDeviceSaved 19:48:10.782 ENTER setUp 19:48:10.804 19:48:10.805 an Array('' @ 16r08FF27C0) 19:48:10.806 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.806 19:48:10.806 ENTER tearDown 19:48:10.807 19:48:10.807 TowergameSyncTests>>#testPlayerChecksStateVersion 19:48:10.807 ENTER setUp 19:48:10.815 19:48:10.815 an Array('' @ 16r08FF1718) 19:48:10.816 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.816 19:48:10.816 ENTER tearDown 19:48:10.816 19:48:10.816 TowergameSyncTests>>#testPlayerChecksStateVersionAndHasFreshlyInstalled 19:48:10.817 ENTER setUp 19:48:10.820 19:48:10.820 an Array('' @ 16r08FF2198) 19:48:10.820 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.820 19:48:10.820 ENTER tearDown 19:48:10.821 19:48:10.821 TowergameSyncTests>>#testPlayerChecksStateVersionAndIsBehind 19:48:10.821 ENTER setUp 19:48:10.829 19:48:10.829 an Array('' @ 16r08FFFAD8) 19:48:10.829 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.829 19:48:10.830 ENTER tearDown 19:48:10.830 19:48:10.830 TowergameSyncTests>>#testPlayerChecksStateVersionFromDifferentDevice 19:48:10.830 ENTER setUp 19:48:10.832 19:48:10.832 an Array('' @ 16r08FFFAE8) 19:48:10.832 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.832 19:48:10.832 ENTER tearDown 19:48:10.832 19:48:10.832 TowergameSyncTests>>#testPlayerChecksStateVersionFromDifferentDeviceAndHasFreshlyInstalled 19:48:10.832 ENTER setUp 19:48:10.839 19:48:10.839 an Array('' @ 16r08FFFAF8) 19:48:10.839 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.840 19:48:10.840 ENTER tearDown 19:48:10.840 19:48:10.840 TowergameSyncTests>>#testPlayerChecksStateVersionFromDifferentExistingDevice 19:48:10.840 ENTER setUp 19:48:10.841 19:48:10.841 an Array('' @ 16r08FFFB08) 19:48:10.841 <cdecl: long 'sqlite3_open' (char* void*) module: 'sqlite3'> 19:48:10.842 19:48:10.842 ENTER tearDown 19:48:10.842 19:48:10.842 TowergameSyncTests>>#testPlayerChecksStateVersionFromDisabledDevice 19:48:10.842 ENTER setUp 19:48:10.854 19:48:10.854 an Array(@ 16r00000000) 19:48:10.855 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.855 19:48:10.855 an Array(@ 16r00000000) 19:48:10.855 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.856 19:48:10.856 an Array(@ 16r00000000) 19:48:10.856 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.856 19:48:10.856 an Array(@ 16r00000000) 19:48:10.856 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.857 19:48:10.857 an Array(@ 16r00000000) 19:48:10.857 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.857 19:48:10.858 an Array(@ 16r00000000) 19:48:10.861 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.861 19:48:10.862 an Array(@ 16r00000000) 19:48:10.863 <cdecl: long 'sqlite3_close' (void*) module: 'sqlite3'> 19:48:10.864 Error: External module not found 19:48:10.865 ExternalLibraryFunction(Object)>>error: etc. So the mystery of "where are LEAVE messages" is solved: both setUp and tearDown failed between ENTER and LEAVE. Now why cannot it find the library (now I am running it in both 32bit env as well as 64bit env, with appropriate vm installed; but always the same: sqlite3 module is not found). At least it seems it is not mysterious vm bug, but (only) failure to find an external module. Though I don't know how to solve it, LD_LIBRARY_PATH did not help... :-/ > Phil > > On Sat, Sep 30, 2017 at 9:11 PM, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: > > Also, did you try with this VM: > > http://get.pharo.org/vmTLatest60 <http://get.pharo.org/vmTLatest60> > > > 18:51:46.191 + curl get.pharo.org/vmTLatest60 > <http://get.pharo.org/vmTLatest60> > 18:51:46.207 % Total % Received % Xferd Average Speed Time > Time Time Current > 18:51:46.208 Dload Upload Total > Spent Left Speed > 18:51:46.208 > 18:51:46.242 0 0 0 0 0 0 0 0 --:--:-- > --:--:-- --:--:-- 0 > 18:51:46.242 100 6126 100 6126 0 0 172k 0 --:--:-- > --:--:-- --:--:-- 175k > 18:51:46.253 Downloading the latest pharoVM: > 18:51:46.253 > http://files.pharo.org/get-files/60/pharo-linux-threaded-latest.zip > <http://files.pharo.org/get-files/60/pharo-linux-threaded-latest.zip> > 18:51:46.305 [pharo-vm/vm.zip] > 18:51:46.305 End-of-central-directory signature not found. Either > this file is not > 18:51:46.305 a zipfile, or it constitutes one disk of a multi-part > archive. In the > 18:51:46.305 latter case the central directory and zipfile comment > will be found on > 18:51:46.305 the last disk(s) of this archive. > 18:51:46.305 unzip: cannot find zipfile directory in one of > pharo-vm/vm.zip or > 18:51:46.305 pharo-vm/vm.zip.zip, and cannot find > pharo-vm/vm.zip.ZIP, period. > > > It probably does not exist any more (I tried 70+vm and it failed in > other aspects, it wasn't able to load git repo). > > Tried both 61+vmT and 61+vmI both; in 32vm/32os and 64vm/64os > combinations. Always ended with same result. > > Must be some error in UDBCSQLiteLibrary itself. :-/ > > Although the missing transcript output is scary and shows that vm > may be culprit as well. > > Herby > > Phil > > On Sat, Sep 30, 2017 at 1:28 PM, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>> wrote: > > phil(a)highoctane.be <mailto:phil@highoctane.be> > <mailto:phil@highoctane.be <mailto:phil@highoctane.be>> wrote: > > What about > > LD_LIBRARY_PATH=<sqlite3place>;$LD_LIBRARYPATH ./pharo-ui > some.image > > Phil > > > Thanks for answer, did not help. > > In fact it must be something different. As can be seen in > the stack, > it fails during finalizers, and as can be seen by looking at > UDBCSQLite3DatabaseExternalObject > class>>finalizeResourceData: code, > the method it calls is sqlite close. It is hardly the first > method > that is should call... > > I suspect something around image save / load. Again. Lots > of errors > in those parts. But may be something else, as it kicks in > only when > SQLite-using tests starts to run. :-( > > Herby > > P.S.: I saw there is a similar thread out there, but it has > problems > with 32bit loaded by 64bit vm; but here, I have 32bit > linux, so the > vm installed should be 32bit. > > On Thu, Sep 28, 2017 at 7:40 PM, Herby VojÄÃk > <herby(a)mailbox.sk <mailto:herby@mailbox.sk> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk> > <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>>> wrote: > > Hello! > > I try to deploy UDBCSQLite-using image in a 32bit > ubuntu > 16.04.3. > > I do have libsqlite3: > > root@32bit-agent:~# find / -name '*libsqlite*' -type f > 2>>/dev/null > /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6 > /var/lib/dpkg/info/libsqlite0.list > /var/lib/dpkg/info/libsqlite3-0:i386.postinst > /var/lib/dpkg/info/libsqlite3-0:i386.md5sums > /var/lib/dpkg/info/libsqlite3-0:i386.shlibs > /var/lib/dpkg/info/libsqlite0.postrm > /var/lib/dpkg/info/libsqlite3-0:i386.symbols > /var/lib/dpkg/info/libsqlite3-0:i386.list > /var/lib/dpkg/info/libsqlite3-0:i386.triggers > > /var/cache/apt/archives/libsqlite0_2.8.17-12fakesync1_i386.deb > > but I get this in the output of the CI: > > 17:16:54.233 + ../pharo/pharo ./filmtower.image > conf/run-tests.st <http://run-tests.st> > <http://run-tests.st> > <http://run-tests.st> > 17:16:54.508 pthread_setschedparam failed: > Operation not > permitted > 17:16:54.509 This VM uses a separate heartbeat > thread to > update its > internal clock > 17:16:54.509 and handle events. For best > operation, this > thread > should run at a > 17:16:54.509 higher priority, however the VM was > unable to > change > the priority. The > 17:16:54.509 effect is that heavily loaded systems may > experience > some latency > 17:16:54.509 issues. If this occurs, please > create the > appropriate > configuration > 17:16:54.509 file in /etc/security/limits.d/ as > shown below: > 17:16:54.509 > 17:16:54.509 cat <<END | sudo tee > /etc/security/limits.d/pharo.conf > 17:16:54.509 * hard rtprio 2 > 17:16:54.509 * soft rtprio 2 > 17:16:54.509 END > 17:16:54.509 > 17:16:54.509 and report to the pharo mailing list > whether this > improves behaviour. > 17:16:54.512 > 17:16:54.512 You will need to log out and log back > in for > the limits > to take effect. > 17:16:54.512 For more information please see > 17:16:54.512 > https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux>> > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux>>> > 17:16:54.785 > 17:16:54.786 TowergameSyncTests > 17:16:54.831 Error: External module not found > 17:16:54.832 ExternalLibraryFunction(Object)>>error: > 17:16:54.832 > ExternalLibraryFunction(Object)>>externalCallFailed > 17:16:54.833 > > ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments: > 17:16:54.833 UDBCSQLite3DatabaseExternalObject > class>>finalizeResourceData: > 17:16:54.834 FFICalloutAPI>>function:module: > 17:16:54.834 > UDBCSQLite3Library(Object)>>ffiCall:module: > 17:16:54.835 UDBCSQLite3DatabaseExternalObject > class>>finalizeResourceData: > 17:16:54.836 FFIExternalResourceExecutor>>finalize > 17:16:54.836 WeakFinalizerItem>>finalizeValues > 17:16:54.845 [ each finalizeValues ] in [ :each | > [ each > finalizeValues ] on: Exception fork: [ :ex | ex > pass ] ] in > WeakRegistry>>finalizeValues in Block: [ each > finalizeValues ] > 17:16:54.846 BlockClosure>>on:do: > 17:16:54.852 [ Processor terminateActive ] in [ :ex | > 17:16:54.852 | copy onDoCtx process handler bottom > thisCtx | > 17:16:54.852 onDoCtx := thisContext. > 17:16:54.852 thisCtx := onDoCtx home. > 17:16:54.852 > 17:16:54.852 "find the context on stack for which this > method's is > sender" > 17:16:54.852 [ onDoCtx sender == thisCtx ] > 17:16:54.852 whileFalse: [ onDoCtx := onDoCtx > sender. > 17:16:54.852 onDoCtx > 17:16:54.852 ifNil: [ "Can't > find our home > context. seems like we're already forked > 17:16:54.852 and > handling another > exception in new thread. In this case, just pass > it through > handler." ^ handlerAction cull: ex ] ]. > 17:16:54.852 bottom := [ Processor terminateActive > ] asContext. > 17:16:54.853 onDoCtx privSender: bottom. > 17:16:54.853 handler := [ handlerAction cull: ex ] > asContext. > 17:16:54.853 handler privSender: thisContext sender. > 17:16:54.853 (Process forContext: handler > priority: Processor > activePriority) > 17:16:54.853 resume. > 17:16:54.853 > 17:16:54.853 "cut the stack of current process" > 17:16:54.853 thisContext privSender: thisCtx. > 17:16:54.853 nil ] in BlockClosure>>on:fork: in > Block: [ > Processor > terminateActive ] > 17:16:54.989 > > Look like pharo was not able to find the sqlite3 lib. > > Any help? > > Thanks, Herby > > > > > > > > > > >

Sept. 30, 2017

Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems

by Igor Stasenko

On 30 September 2017 at 17:51, J.F. Rick <self(a)je77.com> wrote: > Hi Igor et al., > > thanks for taking a look at this. I appreciate it a lot. I've been swamped > with work et al. but I'm back. If I understand it correctly, Igor is still > fighting with drivers to make it work on his system. Let me know when you > want me to try something. > > Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :( Cheers, > > Jeff > > > -- Best regards, Igor Stasenko.

Sept. 30, 2017