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

Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux

by Alistair Grant

On 27 March 2017 at 01:37, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Mar 27, 2017 at 5:25 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Trying to use the VM produces: >> >> THERE_BE_DRAGONS_HERE >> Your VM is too old for this image. Please download the latest VM. >> 26 March 2017 10:54:36.099174 pm > > Last night I built the 64-bit pharo-vm on OSX > and then trying to run 60451-64.image gave me the same error. > I didn't have time to look into it. Thanks for the confirmation. In my case it's caused by the VM failing to report the VM, Date and Plugin information (which can be seen from the --version information I supplied previously), which probably also ties back to the "5.0-" directory. So hopefully once that is sorted, it will all magically work. Thanks again, Alistair

March 27, 2017

Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change

by Petr Fischer

Thanks for tips to external Date/Time implementation. I implemented custom #= and #< methods in Date class as extension to solve my issue. It's sad a little, that base Date/Time classes is not enough and external libs existed. pf > > > On 26 Mar 2017, at 21:56, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > Did you check the Zn counterpart because I know that some parts are much better. > > But I do not have them at hand. > > You mean ZTimestamp (but it is not a part of Zinc HTTP Components). > > https://github.com/svenvc/ztimestamp > > This is an UTC, second precision timestamp without TZ info, and a number of interesting tools. > > However, that won't solve the issue raised. Some people think of a date as an abstract calendar date, while for others its a concrete day (my Monday is not your Monday if we are in different time zones). > > I don't think there is only one solution, both roles are needed/useful. > > Note that STON serialises Dates as YYYY-MM-DD which is what you seem to want. > > The ZTimezone class knows about the exact transitions, but that still does not mean that no weird things happen at the transition point, au contraire ;-) > > > Stef > > > > On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer(a)me.com> wrote: > > Hello, > > > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code: > > > > D1 := Date year: 2017 month: 3 day: 26. > > > > Date object is created with instvars: > > start: 2017-03-26T00:00:00+01:00 > > duration: 1:00:00:00 > > > > 2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change): > > > > D2 := Date year: 2017 month: 3 day: 26. > > > > Date instance with this instvars returned: > > start: 2017-03-26T00:00:00+02:00 > > duration: 1:00:00:00 > > > > 3) D1 != D2 > > > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. > > DST change breaks equality of the same date :( > > > > Is it OK? > > > > Thanks! Petr Fischer > > > > > >

March 27, 2017

Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux

by Ben Coman

On Mon, Mar 27, 2017 at 5:25 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Trying to use the VM produces: > > THERE_BE_DRAGONS_HERE > Your VM is too old for this image. Please download the latest VM. > 26 March 2017 10:54:36.099174 pm Last night I built the 64-bit pharo-vm on OSX and then trying to run 60451-64.image gave me the same error. I didn't have time to look into it. cheers -ben > > VM: unix - i686 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2175 > uuid: eb79e804-a80b-4ad3-bd19-9c60a24a14f1 Mar 26 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2174 uuid: > eefef0d3-2df8-4fe7-9f71-2aca68641ba6 Mar 26 2017 > VM: Date: Plugins: > > Image: Pharo6.0 [Latest update: #60447] > > StartupUIManager>>inform: > Receiver: a StartupUIManager > Arguments and temporary variables: > arg1: 'Your VM is too old for this image. Please download the latest VM.' > tmp1: nil > Receiver's instance variables: > doNotQuitOnRestart: false > uiManager: nil > > > DiskStore class(Object)>>inform: > Receiver: DiskStore > Arguments and temporary variables: > arg1: 'Your VM is too old for this image. Please download the latest VM.' > Receiver's instance variables: > superclass: FileSystemStore > methodDict: a MethodDictionary(#=->DiskStore>>#= > #basenameFromEntry:->DiskStore...etc... > format: 65537 > layout: a FixedLayout > instanceVariables: nil > organization: a ClassOrganization > subclasses: {UnixStore. WindowsStore} > name: #DiskStore > classPool: a Dictionary(#CurrentFS->a FileSystem #Primitives->a > FilePluginPrims...etc... > sharedPools: nil > environment: a SystemDictionary(lots of globals) > category: #'FileSystem-Disk' > traitComposition: {} > localSelectors: nil > ... > > > The same thing happens with a V5.0 image. > > FYI: > > $ pharo.ui --version > 5.0- Sun Mar 26 20:48:38 UTC 2017 gcc 5.4.0 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2175 uuid: > eb79e804-a80b-4ad3-bd19-9c60a24a14f1 Mar 26 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2174 uuid: > eefef0d3-2df8-4fe7-9f71-2aca68641ba6 Mar 26 2017 > VM: Date: > Plugins: > Linux 10b18a356b12 4.8.0-41-generic #44~16.04.1-Ubuntu SMP Fri Mar 3 > 17:11:16 UTC 2017 i686 i686 i686 GNU/Linux > plugin path: /snap/pharo/x1/usr/bin/pharo-vm/ [default: > /snap/pharo/x1/usr/bin/pharo-vm/] > > > Given I've only just built the VM, I'm a bit surprised that it is too old. :-) > > I'm basically using Esteban's instructions, i.e.: > > $ git clone https://github.com/pharo-project/pharo-vm.git > $ cd pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build > $ ./mvm > > Once I get this working properly, hopefully I can contribute some > documentation back that makes it easier for the next person. > > More hints please... :-) > > Thanks very much for all you assistance, > Alistair

March 26, 2017

Re: [Pharo-users] Build instructions for building threaded 6.0 VM on linux

by Alistair Grant

Hi Esteban & Ben, On 26 March 2017 at 10:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 26 Mar 2017, at 09:10, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> I haven't used travis, but it looks like it is defining a number of >> environment variables, e.g. ARCH, FLAVOR, SRC_ARCH, HEARTBEAT. If I >> want the 32 bit linux threaded heartbeat, do I need to set these >> manually? > > no, once compiled is done (and your compilation worked). > those variables are for travis consumption, to allow use to pick the right artifact to build, but you already did it by hand :) Thanks for pointing this out, I wouldn't have realised that the compilation succeeded. :-) On 26 March 2017 at 15:20, Ben Coman <btc(a)openinworld.com> wrote: > On Sun, Mar 26, 2017 at 3:10 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> On 26 March 2017 at 04:09, Pierce Ng <pierce(a)samadhiweb.com> wrote: >>> On Sat, Mar 25, 2017 at 07:29:29PM +0100, Alistair Grant wrote: >>>> make[3]: *** No rule to make target >>>> '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.23.0'. >>> >>> Sorry, also >>> >>> % sudo apt-get install libssl-dev:i386 >> >> Thanks, Pierce. >> >> That gets past the previous errors, I'm now getting: >> >> ... >> Installing links > > Is there text cut from the right side of these lines. The next three > lines are repeated, but maybe there was something more to distinguish > them? Also line 5 "squeak/5.0-" seems cut off. There was text cut off from the right side of the lines. I cut-and-pasted this from the terminal, but still not sure how the text was cut, my apologies for the inconvenience. See below for "5.0-". >From my most recent build: Installing links DONE make[1]: Leaving directory '/data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/third-party' /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. make[1]: Entering directory '/data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/third-party' cp -f /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/squeak/5.0- Installing links DONE make[1]: Leaving directory '/data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/third-party' /data/pharo-snap/parts/pharo/build/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build The "squeak/5.0-" directory is no longer present after the build completes, however the path to the final vm is: "parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-" I agree that "5.0-" is a strange directory name, however looking at the version info produced by my vm vs. the version info produced by get.pharo.org/60+vmT, I suspect that there's something missing in my build environment. 60+vmT produces: 5.0-201702221539 Wed Feb 22 15:46:29 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] 201702221539 looks like a timestamp. Not sure why it is missing in my vm. (I assume that squeak/5.0- is renamed to pharo/5.0- in editpharoinstall.sh) >> cp -f /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/.thirdparty-cache/linux/i386/lib/libgit2.so.0.23.0 >> /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/***products***/phcogspurlinuxht/lib/squeak/5.0- > > Check whats under the ***products*** folder I marked above. $ ls -R pharo-vm/opensmalltalk-vm/products parts/pharo/build/pharo-vm/opensmalltalk-vm/products: phcogspurlinuxht parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht: bin lib pharo parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/bin: pharo parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib: pharo parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo: 5.0- parts/pharo/build/pharo-vm/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-: AioPlugin JPEGReadWriter2Plugin libSDL2-2.0.so.0.4.1 libssl.so.1.0.0 vm-display-null B3DAcceleratorPlugin libcrypto.so.1.0.0 libSDL2.so pharo vm-display-X11 EventsHandlerPlugin libgit2.so libssh2.so RePlugin vm-sound-ALSA FT2Plugin libgit2.so.0.23.0 libssh2.so.1 SqueakSSL vm-sound-null InternetConfigPlugin libgit2.so.23 libssh2.so.1.0.1 SurfacePlugin vm-sound-OSS JPEGReaderPlugin libSDL2-2.0.so.0 libssl.so vm-display-fbdev > >> Installing links >> DONE >> /data/pharo-snap/akg-try/pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build >> can't find PharoV50.sources > > PharoV50.sources [1] needs to sit next to the VM or Image files to be found. > "can't find" it, is a standard message from a running VM. > > Could you report if this works for you... > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/79 If I try to view the change ("View changes" button) on github I get: "We went looking everywhere, but couldnât find those commits." However I'd be surprised if it had any affect as PharoV50.sources didn't exist anywhere in the build tree. However it did give me enough of a clue that I've now modified my build script to add the sources file in, so there aren't any obvious errors during the build process (well, obvious to me, I haven't gone through all 7700 lines of the build log). Trying to use the VM produces: THERE_BE_DRAGONS_HERE Your VM is too old for this image. Please download the latest VM. 26 March 2017 10:54:36.099174 pm VM: unix - i686 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2175 uuid: eb79e804-a80b-4ad3-bd19-9c60a24a14f1 Mar 26 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2174 uuid: eefef0d3-2df8-4fe7-9f71-2aca68641ba6 Mar 26 2017 VM: Date: Plugins: Image: Pharo6.0 [Latest update: #60447] StartupUIManager>>inform: Receiver: a StartupUIManager Arguments and temporary variables: arg1: 'Your VM is too old for this image. Please download the latest VM.' tmp1: nil Receiver's instance variables: doNotQuitOnRestart: false uiManager: nil DiskStore class(Object)>>inform: Receiver: DiskStore Arguments and temporary variables: arg1: 'Your VM is too old for this image. Please download the latest VM.' Receiver's instance variables: superclass: FileSystemStore methodDict: a MethodDictionary(#=->DiskStore>>#= #basenameFromEntry:->DiskStore...etc... format: 65537 layout: a FixedLayout instanceVariables: nil organization: a ClassOrganization subclasses: {UnixStore. WindowsStore} name: #DiskStore classPool: a Dictionary(#CurrentFS->a FileSystem #Primitives->a FilePluginPrims...etc... sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'FileSystem-Disk' traitComposition: {} localSelectors: nil ... The same thing happens with a V5.0 image. FYI: $ pharo.ui --version 5.0- Sun Mar 26 20:48:38 UTC 2017 gcc 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2175 uuid: eb79e804-a80b-4ad3-bd19-9c60a24a14f1 Mar 26 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2174 uuid: eefef0d3-2df8-4fe7-9f71-2aca68641ba6 Mar 26 2017 VM: Date: Plugins: Linux 10b18a356b12 4.8.0-41-generic #44~16.04.1-Ubuntu SMP Fri Mar 3 17:11:16 UTC 2017 i686 i686 i686 GNU/Linux plugin path: /snap/pharo/x1/usr/bin/pharo-vm/ [default: /snap/pharo/x1/usr/bin/pharo-vm/] Given I've only just built the VM, I'm a bit surprised that it is too old. :-) I'm basically using Esteban's instructions, i.e.: $ git clone https://github.com/pharo-project/pharo-vm.git $ cd pharo-vm/opensmalltalk-vm/build.linux32x86/pharo.cog.spur/build $ ./mvm Once I get this working properly, hopefully I can contribute some documentation back that makes it easier for the next person. More hints please... :-) Thanks very much for all you assistance, Alistair

March 26, 2017

Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change

by Sven Van Caekenberghe

> On 26 Mar 2017, at 21:56, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Did you check the Zn counterpart because I know that some parts are much better. > But I do not have them at hand. You mean ZTimestamp (but it is not a part of Zinc HTTP Components). https://github.com/svenvc/ztimestamp This is an UTC, second precision timestamp without TZ info, and a number of interesting tools. However, that won't solve the issue raised. Some people think of a date as an abstract calendar date, while for others its a concrete day (my Monday is not your Monday if we are in different time zones). I don't think there is only one solution, both roles are needed/useful. Note that STON serialises Dates as YYYY-MM-DD which is what you seem to want. The ZTimezone class knows about the exact transitions, but that still does not mean that no weird things happen at the transition point, au contraire ;-) > Stef > > On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer(a)me.com> wrote: > Hello, > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code: > > D1 := Date year: 2017 month: 3 day: 26. > > Date object is created with instvars: > start: 2017-03-26T00:00:00+01:00 > duration: 1:00:00:00 > > 2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change): > > D2 := Date year: 2017 month: 3 day: 26. > > Date instance with this instvars returned: > start: 2017-03-26T00:00:00+02:00 > duration: 1:00:00:00 > > 3) D1 != D2 > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. > DST change breaks equality of the same date :( > > Is it OK? > > Thanks! Petr Fischer > >

March 26, 2017

Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change

by Stephane Ducasse

Did you check the Zn counterpart because I know that some parts are much better. But I do not have them at hand. Stef On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer(a)me.com> wrote: > Hello, > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) > with this code: > > D1 := Date year: 2017 month: 3 day: 26. > > Date object is created with instvars: > start: 2017-03-26T00:00:00+01:00 > duration: 1:00:00:00 > > 2) when I create same Date instance with the same code on/after: > 2017/03/26 (after Daylight Saving Time change): > > D2 := Date year: 2017 month: 3 day: 26. > > Date instance with this instvars returned: > start: 2017-03-26T00:00:00+02:00 > duration: 1:00:00:00 > > 3) D1 != D2 > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: > 26) created before DST change is not equal with date instance (Date year: > 2017 month: 3 day: 26) created after DST change. > DST change breaks equality of the same date :( > > Is it OK? > > Thanks! Petr Fischer > >

March 26, 2017

Re: [Pharo-users] Creating Dates before/after Daylight Saving Time change

by Petr Fischer

Even "Date today" and "Date now" is created by DateAndTime. So, due to the DateAndTime internals, one can't persist Date instance (eg. with Fuel) and use it as exact "date/day value" for comparisons later in time (when GST changes back and forth). The same date value (one created before DST change, one created after DST change) will be different even in long run (on the DST change day - Date today in created on 1:00am will be different from Date today created on 2:00 am - weird! it's the same day!). Isn't the usage of "time" component in Date class a bug (at least in comparison #= method)? What about to redefine #= instance method in Date class (it's defined in Timespan super class now)? = comparand ^ self species = comparand species and: [ self translateToUTC = comparand translateToUTC ]. Opinions? pf > Date>>year:month:day: (respectively Date>>#starting:) is using DateAndTime to specify the start, and DateAndTime will of course differ. > > To me it seems like someone was reusing implementation; because Date normally shouldn't have/care about time information, and yet it subclasses from Timespan class, which has/cares about time information. So the Date is actually encoded in Timespan's 'starting' instVar as DateAndTime instance, which is obviously breaking if TimeZone is applied. > > Maybe a fix (apart from not using Time in Date) would be to make sure Date's methods use DateAndTime offset to 0? > Because even without daylight saving, if you create a Date instance in one country, and move to different TZ it should break; so always keeping it UTC/0 would make sense to me. > > Peter > > On Sun, Mar 26, 2017 at 10:17:14AM +0200, Petr Fischer wrote: > > Hello, > > > > 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code: > > > > D1 := Date year: 2017 month: 3 day: 26. > > > > Date object is created with instvars: > > start: 2017-03-26T00:00:00+01:00 > > duration: 1:00:00:00 > > > > 2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change): > > > > D2 := Date year: 2017 month: 3 day: 26. > > > > Date instance with this instvars returned: > > start: 2017-03-26T00:00:00+02:00 > > duration: 1:00:00:00 > > > > 3) D1 != D2 > > > > So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. > > DST change breaks equality of the same date :( > > > > Is it OK? > > > > Thanks! Petr Fischer > > >

March 26, 2017

Re: [Pharo-users] using UFFI in non-crashing way

by Thierry Goubier

Le 26/03/2017 Ã 19:21, Peter Uhnak a Ã©crit : > On Sun, Mar 26, 2017 at 05:45:04PM +0200, Esteban Lorenzano wrote: >> >>> On 26 Mar 2017, at 15:40, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>> Hi, >>> >>> is it possible to use UFFI and avoid crashing the image when the >>> called code segfaults? >>> >>> In other words, can I somehow wrap the call and throw in-image >>> Exception/Error on failure instead of the whole thing crashing? >> >> thatâs not possible, once you segfault, you segfault. > > Ah, ok. > >> >>> Or is the only way to do that have the called thing running as a >>> separate app (e.g. via OSSubProcess) and communicate via pipes or >>> sockets? >> >> thatâs not done. no idea how much effort is required to implement, >> but I imagine is not trivial. > > Nono, I didn't mean making UFFI calls via socket (although that would > be interesting), but rather making a C app that would make the calls, > and that would provide a socket interface. (Which is what I typically > do with other langs). With UFFI and a standard way to marshall types over a socket (ASN.1 or even xml-rpc), this could be generated automatically. Of course, you may have a few performance issues, but you could have a long-lived child to avoid paying the startup time, and mmap / shared memory to lower the cost of moving memory back and forth. Thierry > Thanks, Peter > >

March 26, 2017

Re: [Pharo-users] Installing Voyage ??

by Stephane Ducasse

Add an issue in the Voyage github repo and do a pull request to push esteban releasing a new version. On Sun, Mar 26, 2017 at 1:15 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I get that same problem, too, every time I do "Software update". But never > understood the rationale of dropping a database at this point. I think we > should remove this line > > Norbert > > > Am 25.03.2017 um 22:04 schrieb Hilaire <hilaire(a)drgeo.eu>: > > > > ah yeah, I wrote an internal durty hack to get it rolling > > > > cleanUp: aRepository > > (aRepository isKindOf: Boolean) ifFalse: [ aRepository dropDatabase] > > > > > >> Le 25/03/2017 Ã 21:46, Hilaire a Ã©crit : > >> It occurs in Pharo5, likely not in Pharo4, or may be I fixed in my > >> image, I don't remember. > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > >

March 26, 2017

Re: [Pharo-users] using UFFI in non-crashing way

by Peter Uhnak

On Sun, Mar 26, 2017 at 05:45:04PM +0200, Esteban Lorenzano wrote: > > > On 26 Mar 2017, at 15:40, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > is it possible to use UFFI and avoid crashing the image when the called code segfaults? > > > > In other words, can I somehow wrap the call and throw in-image Exception/Error on failure instead of the whole thing crashing? > > thatâs not possible, once you segfault, you segfault. Ah, ok. > > > Or is the only way to do that have the called thing running as a separate app (e.g. via OSSubProcess) and communicate via pipes or sockets? > > thatâs not done. > no idea how much effort is required to implement, but I imagine is not trivial. Nono, I didn't mean making UFFI calls via socket (although that would be interesting), but rather making a C app that would make the calls, and that would provide a socket interface. (Which is what I typically do with other langs). Thanks, Peter

March 26, 2017