Re: Raku-LibCurl:ver<1.0> install error on older MacOS?
Sorry things broke for you. I filed an issue on GitHub (https://github.com/CurtTilmes/raku-libcurl/issues/16) and copied the emails there. I published a new version 1.1 that will hopefully fix this. Please let me know (either in that issue, or file new issues) for anything broken. Curt On Sat, Jul 11, 2020 at 7:04 PM William Michels via perl6-users wrote: > > Thank you, Vadim, for your kind reply. I wondered if a recent commit > to Raku-LibCurl may have improved installation/loading on Linux > machines, while simultaneously breaking installation/loading on MacOS: > > https://github.com/CurtTilmes/raku-libcurl/commit/6de3338a50cbc43d185c408d965dc2984bcfeaee#diff-7298ce0db5e8b9c63122e5dd725a8d24 > > As for the rest of my installation, I believe the Perl6-Users mailing > list is the best place to hash out these issues. We have a number of > Mac users who frequent this list, and would be able to discuss Mac > file extensions (e.g. the ".dylib" vs ".so" issue). Thank you for > confirming that in your opinion, Raku LibCurl version 1.0 may be > failing to install on MacOS because the installer is looking for > 'libcurl.so.4'. > > I certainly understand symlinking if necessary but as I stated > previously, call-outs to native LibCurl worked fine under Rakudo > 2020.02.1, and presently call-outs to native LibCurl work just fine > under Rakudo 2020.06 (specifically using Raku LibCurl:ver<0.9>). I'll > know if I have real problems if other Mac users are getting Raku > LibCurl:ver<1.0> to work--while I cannot. > > Anyone knowledgeable want to help out and craft a PR for the module's author? > > Best Regards. Bill. > > W. Michels, Ph.D. > > > > > > > On Sat, Jul 11, 2020 at 2:21 PM Vadim Belman wrote: > > > > You have so many things messed up in a single mail, it's hard to choose the > > one to start with. By attempting to install the module myself I suddenly > > spotted it at once: the module is buggy and need fixing. macOS doesn't > > support .so format. Instead, it's using own .dylib. It's hard to tell what > > exactly wrong about the module, but the first guess would be about it using > > explicit full file name when loading a native lib where it should use just > > 'libcurl'. > > > > With regard to other matters, the most crucial one which may affect you in > > the future, is a security feature of macOS which only allows loading of > > dynamic libraries either from system paths like /lib/ or /usr/lib/; or from > > lib/ dir located in the same subdirectory where the program executable is > > located. I.e. whatever is installed in /opt/local/bin have access to > > dynamic libraries in /opt/local/lib. If your rakudo executable is installed > > somewhere else (~/raku/bin for me) it wouldn't see nothing in > > /opt/local/lib. This can be fixed by symlinking the files of libs into a > > location where they're available to raku. I think rakubrew does it > > automatically for a user; or at least the feature was planned. Another way > > is to link the files into ~/lib which is also considered by macOS for > > executables under user's home dir. > > > > Best regards, > > Vadim Belman > > > > > On Jul 10, 2020, at 10:00 PM, William Michels via perl6-users > > > wrote: > > > > > > Hello, > > > > > > I just updated to Rakudo-2020.06, and while updating many of my > > > modules to their latest versions I saw an error installing/updating > > > (Raku) LibCurl. Below, the first few lines of the error seen with > > > LibCurl::Easy (and EasyHandle): > > > > > > ===> Testing: LibCurl:ver<1.0>:auth:api<1> > > > [LibCurl] # Failed test 'LibCurl::EasyHandle module can be use-d ok' > > > [LibCurl] # at t/01-load.t line 6 > > > [LibCurl] # Cannot load native library 'libcurl.so.4' > > > [LibCurl] # Failed test 'LibCurl::Easy module can be use-d ok' > > > [LibCurl] # at t/01-load.t line 8 > > > [LibCurl] # ===SORRY!=== Error while compiling > > > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod > > > (LibCurl::Easy) > > > [LibCurl] # Cannot load native library 'libcurl.so.4' > > > [LibCurl] # at > > > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod > > > (LibCurl::Easy):2 > > > > > > So one caveat is that this install is on an OS which many would > > > consider to be "MacOS.10.ancient" [I'm posting here and not on Github > > > because we seem to have a number of Mac users on this mailing-list]. > > > But the fact of the matter is Raku LibCurl:ver<0.9> worked just fine > > > with Rakudo-2020.02.1. Furthermore, now that I've downgraded back to > > > Raku LibCurl:ver<0.9>, LibCurl::Easy works once again on the latest > > > Rakudo-2020.06. So I really feel the problem is with LibCurl:ver<1.0> > > > on Macs, and not my particular install. > > > > > > Questions for Mac-heads: Do newer versions of MacOS still install > > > LibCurl as part of the OS? Where does that reside? I know I have > > > libcurl in th
Re: Raku-LibCurl:ver<1.0> install error on older MacOS?
I don't know if it's related, but I was just having some trouble with installs of LibCurl on an old linux box, I was getting errors like: # at t/01-load.t6 line 7 # Cannot locate native library 'libcurl.so': libcurl.so: cannot open shared object file: No such file or directory But I had libraries like: /usr/lib/i386-linux-gnu/libcurl.so.3 /usr/lib/i386-linux-gnu/libcurl.so.4 I put in a symlink to alias one of them as "libcurl.so": sudo ln -sf /usr/lib/i386-linux-gnu/libcurl.so.3 /usr/lib/i386-linux-gnu/libcurl.so And the installation worked. On 7/13/20, Curt Tilmes wrote: > Sorry things broke for you. > > I filed an issue on GitHub > (https://github.com/CurtTilmes/raku-libcurl/issues/16) and copied the > emails there. > > I published a new version 1.1 that will hopefully fix this. Please > let me know (either in that issue, or file new issues) for anything > broken. > > Curt > > On Sat, Jul 11, 2020 at 7:04 PM William Michels via perl6-users > wrote: >> >> Thank you, Vadim, for your kind reply. I wondered if a recent commit >> to Raku-LibCurl may have improved installation/loading on Linux >> machines, while simultaneously breaking installation/loading on MacOS: >> >> https://github.com/CurtTilmes/raku-libcurl/commit/6de3338a50cbc43d185c408d965dc2984bcfeaee#diff-7298ce0db5e8b9c63122e5dd725a8d24 >> >> As for the rest of my installation, I believe the Perl6-Users mailing >> list is the best place to hash out these issues. We have a number of >> Mac users who frequent this list, and would be able to discuss Mac >> file extensions (e.g. the ".dylib" vs ".so" issue). Thank you for >> confirming that in your opinion, Raku LibCurl version 1.0 may be >> failing to install on MacOS because the installer is looking for >> 'libcurl.so.4'. >> >> I certainly understand symlinking if necessary but as I stated >> previously, call-outs to native LibCurl worked fine under Rakudo >> 2020.02.1, and presently call-outs to native LibCurl work just fine >> under Rakudo 2020.06 (specifically using Raku LibCurl:ver<0.9>). I'll >> know if I have real problems if other Mac users are getting Raku >> LibCurl:ver<1.0> to work--while I cannot. >> >> Anyone knowledgeable want to help out and craft a PR for the module's >> author? >> >> Best Regards. Bill. >> >> W. Michels, Ph.D. >> >> >> >> >> >> >> On Sat, Jul 11, 2020 at 2:21 PM Vadim Belman wrote: >> > >> > You have so many things messed up in a single mail, it's hard to choose >> > the one to start with. By attempting to install the module myself I >> > suddenly spotted it at once: the module is buggy and need fixing. macOS >> > doesn't support .so format. Instead, it's using own .dylib. It's hard to >> > tell what exactly wrong about the module, but the first guess would be >> > about it using explicit full file name when loading a native lib where >> > it should use just 'libcurl'. >> > >> > With regard to other matters, the most crucial one which may affect you >> > in the future, is a security feature of macOS which only allows loading >> > of dynamic libraries either from system paths like /lib/ or /usr/lib/; >> > or from lib/ dir located in the same subdirectory where the program >> > executable is located. I.e. whatever is installed in /opt/local/bin have >> > access to dynamic libraries in /opt/local/lib. If your rakudo executable >> > is installed somewhere else (~/raku/bin for me) it wouldn't see nothing >> > in /opt/local/lib. This can be fixed by symlinking the files of libs >> > into a location where they're available to raku. I think rakubrew does >> > it automatically for a user; or at least the feature was planned. >> > Another way is to link the files into ~/lib which is also considered by >> > macOS for executables under user's home dir. >> > >> > Best regards, >> > Vadim Belman >> > >> > > On Jul 10, 2020, at 10:00 PM, William Michels via perl6-users >> > > wrote: >> > > >> > > Hello, >> > > >> > > I just updated to Rakudo-2020.06, and while updating many of my >> > > modules to their latest versions I saw an error installing/updating >> > > (Raku) LibCurl. Below, the first few lines of the error seen with >> > > LibCurl::Easy (and EasyHandle): >> > > >> > > ===> Testing: LibCurl:ver<1.0>:auth:api<1> >> > > [LibCurl] # Failed test 'LibCurl::EasyHandle module can be use-d ok' >> > > [LibCurl] # at t/01-load.t line 6 >> > > [LibCurl] # Cannot load native library 'libcurl.so.4' >> > > [LibCurl] # Failed test 'LibCurl::Easy module can be use-d ok' >> > > [LibCurl] # at t/01-load.t line 8 >> > > [LibCurl] # ===SORRY!=== Error while compiling >> > > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod >> > > (LibCurl::Easy) >> > > [LibCurl] # Cannot load native library 'libcurl.so.4' >> > > [LibCurl] # at >> > > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod >> > > (LibCurl::Easy):2 >> > > >> > > So one caveat is that this install is on a
Re: Raku-LibCurl:ver<1.0> install error on older MacOS?
Thank you Curt--and thanks for writing the Raku LibCurl module!! I'll update my module to (Raku) LibCurl:ver<1.1> and see if that fixes everything. I'll report what I see on the Github issue you created. Thanks again, Bill. W. Michels, Ph.D. On Mon, Jul 13, 2020 at 8:21 AM Curt Tilmes wrote: > > Sorry things broke for you. > > I filed an issue on GitHub > (https://github.com/CurtTilmes/raku-libcurl/issues/16) and copied the > emails there. > > I published a new version 1.1 that will hopefully fix this. Please > let me know (either in that issue, or file new issues) for anything > broken. > > Curt > > On Sat, Jul 11, 2020 at 7:04 PM William Michels via perl6-users > wrote: > > > > Thank you, Vadim, for your kind reply. I wondered if a recent commit > > to Raku-LibCurl may have improved installation/loading on Linux > > machines, while simultaneously breaking installation/loading on MacOS: > > > > https://github.com/CurtTilmes/raku-libcurl/commit/6de3338a50cbc43d185c408d965dc2984bcfeaee#diff-7298ce0db5e8b9c63122e5dd725a8d24 > > > > As for the rest of my installation, I believe the Perl6-Users mailing > > list is the best place to hash out these issues. We have a number of > > Mac users who frequent this list, and would be able to discuss Mac > > file extensions (e.g. the ".dylib" vs ".so" issue). Thank you for > > confirming that in your opinion, Raku LibCurl version 1.0 may be > > failing to install on MacOS because the installer is looking for > > 'libcurl.so.4'. > > > > I certainly understand symlinking if necessary but as I stated > > previously, call-outs to native LibCurl worked fine under Rakudo > > 2020.02.1, and presently call-outs to native LibCurl work just fine > > under Rakudo 2020.06 (specifically using Raku LibCurl:ver<0.9>). I'll > > know if I have real problems if other Mac users are getting Raku > > LibCurl:ver<1.0> to work--while I cannot. > > > > Anyone knowledgeable want to help out and craft a PR for the module's > > author? > > > > Best Regards. Bill. > > > > W. Michels, Ph.D. > > > > > > > > > > > > > > On Sat, Jul 11, 2020 at 2:21 PM Vadim Belman wrote: > > > > > > You have so many things messed up in a single mail, it's hard to choose > > > the one to start with. By attempting to install the module myself I > > > suddenly spotted it at once: the module is buggy and need fixing. macOS > > > doesn't support .so format. Instead, it's using own .dylib. It's hard to > > > tell what exactly wrong about the module, but the first guess would be > > > about it using explicit full file name when loading a native lib where it > > > should use just 'libcurl'. > > > > > > With regard to other matters, the most crucial one which may affect you > > > in the future, is a security feature of macOS which only allows loading > > > of dynamic libraries either from system paths like /lib/ or /usr/lib/; or > > > from lib/ dir located in the same subdirectory where the program > > > executable is located. I.e. whatever is installed in /opt/local/bin have > > > access to dynamic libraries in /opt/local/lib. If your rakudo executable > > > is installed somewhere else (~/raku/bin for me) it wouldn't see nothing > > > in /opt/local/lib. This can be fixed by symlinking the files of libs into > > > a location where they're available to raku. I think rakubrew does it > > > automatically for a user; or at least the feature was planned. Another > > > way is to link the files into ~/lib which is also considered by macOS for > > > executables under user's home dir. > > > > > > Best regards, > > > Vadim Belman > > > > > > > On Jul 10, 2020, at 10:00 PM, William Michels via perl6-users > > > > wrote: > > > > > > > > Hello, > > > > > > > > I just updated to Rakudo-2020.06, and while updating many of my > > > > modules to their latest versions I saw an error installing/updating > > > > (Raku) LibCurl. Below, the first few lines of the error seen with > > > > LibCurl::Easy (and EasyHandle): > > > > > > > > ===> Testing: LibCurl:ver<1.0>:auth:api<1> > > > > [LibCurl] # Failed test 'LibCurl::EasyHandle module can be use-d ok' > > > > [LibCurl] # at t/01-load.t line 6 > > > > [LibCurl] # Cannot load native library 'libcurl.so.4' > > > > [LibCurl] # Failed test 'LibCurl::Easy module can be use-d ok' > > > > [LibCurl] # at t/01-load.t line 8 > > > > [LibCurl] # ===SORRY!=== Error while compiling > > > > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod > > > > (LibCurl::Easy) > > > > [LibCurl] # Cannot load native library 'libcurl.so.4' > > > > [LibCurl] # at > > > > /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod > > > > (LibCurl::Easy):2 > > > > > > > > So one caveat is that this install is on an OS which many would > > > > consider to be "MacOS.10.ancient" [I'm posting here and not on Github > > > > because we seem to have a number of Mac users on this mailing-list]. > > > > But
perl streaming framework
Hi Does perl have a stream computing framework? I know Java/python have many, such as spark, flink, beam etc. But I am looking for a perl alternative, since most of our team members have been using perl for data analysis. Thank you.
Re: perl streaming framework
Hi, El mar., 14 jul. 2020 a las 4:35, Warren Pang () escribió: > Hi > > Does perl have a stream computing framework? > I don't really know about Perl. It used to have Perl Data Language, but I don't know its current state. However, this mailing list is about Raku, or Perl 6 as it was called last year. Raku has enough capabilities to process data natively, so I don't think an external framework is really necessary. JJ
