Re: cannot create an instance of subset type
On 2020-07-10 23:37, Brad Gilbert wrote:
Subset types are not object types.
A subset is basically a bit of checking code and base type associated
with a new type name.
In something like:
my ABC $a .= new;
That is exactly the same as:
my ABC $a = ABC.new;
Well there is no functional `.new` method on any subset types, so
`DEF.new()` isn't going to do anything.
DEF.new # ERROR
---
The worst part of your code is that you are using a `subset` without a
`where` clause. Which is almost completely pointless.
I honestly think that there is an argument to be made that it
shouldn't even be possible to write a `subset` without a `where` clause.
It isn't like other languages where you can create something like a
lightweight clone or lightweight subclass of a type.
It also isn't an alias.
It's whole purpose is to attach a `where` clause as an extra check to
type based things.
If you want an alias, use an alias
my constant DEF = ABC;
my constant DEF = ABC:D;
If you want a lightweight subclass, create a lightweight subclass.
my class DEF is ABC {}
If you want an extra check, then and only then does it make sense to
use a `subset`.
my subset GHI of Int where -10 ≤ $_ ≤ 10;
---
A `subset` without a `where` clause only makes certain
language features become unavailable.
Unless that is exactly what you want to accomplish, use something else.
Thanks very much Brad, for your answer. I understand completely. It was
needed to mimic a C typedef which created a new type name from another.
The example 'my constant DEF = ABC;' above would just do fine. I didn't
thought about 'my class DEF is ABC {}' though, which also would work but
creates more code I presume.
What I understand also now is that a subset is used on places where
variables are assigned or bound like in argument lists and never created
anew. Then, like you said, the where clause is always useful, if not
obligatory, otherwise one could use the original type.
Regards,
Marcel
On Fri, Jul 10, 2020 at 3:18 PM Marcel Timmerman > wrote:
Hi,
Using the next code I get an error on the instantiation of $d2;
---
use v6;
class ABC {
method s ( Int $i ) { say $i + 10; }
}
subset DEF of ABC;
my ABC $a .= new;
$a.s(10); # 20
my DEF $d1 = $a;
$d1.s(11); # 21
my DEF $d2 .= new;
$d2.s(12);
---
Error is
You cannot create an instance of this type (DEF)
in block at xt/subset-test.pl6 line 15
Why is this?
Regards,
Marcel
Re: cannot create an instance of subset type
> On 10 Jul 2020, at 23:37, Brad Gilbert wrote: > I honestly think that there is an argument to be made that it shouldn't even > be possible to write a `subset` without a `where` clause. Making the "where" clause non-optional, is remarkably simple: removing a '?' However, there appear to be quite a lot of tests in roast that depend on this behaviour, so either there *is* a perceived use of subsets without "where" clause, or we need to fix roast first.
Re: cannot create an instance of subset type
It looks like you're trying to create an alias for a type. I'd use a constant for this, not a subset, for reasons Brad has already explained. Your code runs fine for me when DEF is written like my constant DEF = ABC.
Re: Raku-LibCurl:ver<1.0> install error on older MacOS?
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 the following directories, however 'libcurl.so.4' is > conspicuously absent: > > /opt/local/lib/libcurl.4.dylib > /opt/local/lib/libcurl.a > /opt/local/lib/libcurl.dylib > > Are Mac-users able to use (Raku) LibCurl:ver<1.0> on their (newer) > systems? FYI, I've installed curl independently of MacOS via either > MacBrew or MacPorts, and in fact MacBrew reports upon attempting to > update: "Warning: curl 7.71.1 is already installed and up-to-date". > > Any help appreciated, Thx, Bill. >
Re: Raku-LibCurl:ver<1.0> install error on older MacOS?
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 the following directories, however 'libcurl.so.4' is > > conspicuously absent: > > > > /opt/local/lib/libcurl.4.dylib > > /opt/local/lib/libcurl.a > > /opt/local/lib/libcurl.dylib > > > > Are Mac-users able to use (Raku) LibCurl:ver<1.0> on their (newer) > > systems? FYI, I've installed curl independently of MacOS via either > > MacBrew or MacPorts, and in fact MacBrew reports upon attempting to > > update: "Warning: curl 7.71.1 is already installed and up-to-date". > > > > Any help appreciated, Thx, Bill. > > >
