Re: Missing NullPointerException

2020-12-01 Thread Patrick R. Michaud
The difference is between the result of "Nil.c"  and "Any.c".

On my current version of Rakudo, "Nil.c" returns Nil, while Any.c throws the 
"No such method" exception.  In fact, Nil.any_non_existent method always seems 
to return Nil.  I'm not sure where this is documented, but it's likely the 
reason you don't get an error with "a.b.c".

In your example code, "a.b" returns Nil, so "a.b.c" invokes "Nil.c" which 
results in Nil and no error.

However, assigning Nil to a scalar reverts it to the type otject -- in this 
case Any.  Thus with

   my $b = a.b;

the Nil value coming from "a.b" causes $b to revert to its type object (Any).  
Then "$b.c" is the same as "(Any).c", which results in the "No such method" 
exception.

See the docs at https://docs.raku.org/type/Nil , in the section that talks 
about what happens when Nil is assigned to a container.

Hope this helps,

Pm


On Tue, Dec 01, 2020 at 08:34:31AM +0100, Konrad Bucheli via perl6-users wrote:
> Hi
> 
> I miss an error on my first invocation of `c` below:
> 
> $ raku
> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
> 
> To exit type 'exit' or '^D'
> > class a { method b {return}}
> (a)
> > say a.b.c
> Nil
> > my $b = a.b
> (Any)
> > say $b.c
> No such method 'c' for invocant of type 'Any'
>   in block  at  line 1
> 
> >
> 
> Is there an explanation for that behavior?
> 
> Cheers
> 
> Konrad
> 


Missing NullPointerException

2020-12-01 Thread Konrad Bucheli via perl6-users

Hi

I miss an error on my first invocation of `c` below:

$ raku
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.

To exit type 'exit' or '^D'
> class a { method b {return}}
(a)
> say a.b.c
Nil
> my $b = a.b
(Any)
> say $b.c
No such method 'c' for invocant of type 'Any'
  in block  at  line 1

>

Is there an explanation for that behavior?

Cheers

Konrad



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Raku modules in Gentoo's Portage

2020-12-01 Thread Brad Gilbert
I suspect that the right way to do this may be to do something like having
a subclass of
CompUnit::* which does things the Gentoo way.

I would assume that the lock is so that only one copy of Rakudo is changing
the repository at a time.
Presumably Gentoo already prevents more than one thing installing at a time.
So that would be one thing that a Gento specific subclass would change.

On Tue, Dec 1, 2020 at 4:15 AM p.spek via perl6-users 
wrote:

> Hi, fellow Rakoons,
>
> I've been looking into the creation of a Portage tree for Gentoo, to allow
> installation of Raku modules through the default package manager.
>
> There's currently two issues I need to iron out, and I have no clue how to
> fix
> either at this point. The first one deals with the installation mechanics
> of
> Raku, which I don't grasp completely yet. The other issue isn't really
> relevant
> if I can't get a module installed in the first place, so I'm going to
> stick to
> just the first problem.
>
> I'm using this small bit of Raku code to handle the actual installation:
>
> my $repository =
> CompUnit::RepositoryRegistry.repository-for-name('site');
> my $meta-file = $path.add('META6.json');
> my $dist = Distribution::Path.new($path, :$meta-file);
>
> $repository.install($dist, :$force);
>
> This works in general, but it fails when enabling the sandbox feature on
> Portage. This is a feature I generally have enabled, and seems to be
> common to
> have enabled among Gentoo users.
>
> When installing the module this way, it tries to access
> /usr/local/share/perl6/site/repo.lock. It is not allowed to leave it's
> installation sanbox at /var/tmp/portage/dev-raku/io-path-xdg-0.2.0 (I'm
> testing
> with IO::Path::XDG).
>
> I'm assuming it's making this lock file in order to ensure it can do a
> certain
> operation without interference from other installations. Which operation is
> this, and is it possible to work around this somehow?
>
> With Perl (and most other languages, really), it's just dropping some
> files in
> the right directory, which then gets merged into the root filesystem. I'd
> preferably use a similar approach with Raku modules.
>
> I've seen that installed modules generally have hashed filenames. If I can
> just
> generate the "right" hashes and drop them into the right directory, that
> would
> be good enough for me. If there's more to it, I would greatly appreciate
> some
> explanation on how this works, so I can consider if it's worth my time.
>
> Thanks in advance for any help!
>
> --
> With kind regards,
>
> Patrick Spek
>
>
> www:  https://www.tyil.nl/
> mail: p.s...@tyil.nl
> pgp:  1660 F6A2 DFA7 5347 322A  4DC0 7A6A C285 E2D9 8827
>
> social: https://soc.fglt.nl/tyil
> git:https://home.tyil.nl/git
>


Raku modules in Gentoo's Portage

2020-12-01 Thread p.spek via perl6-users
Hi, fellow Rakoons,

I've been looking into the creation of a Portage tree for Gentoo, to allow
installation of Raku modules through the default package manager.

There's currently two issues I need to iron out, and I have no clue how to fix
either at this point. The first one deals with the installation mechanics of
Raku, which I don't grasp completely yet. The other issue isn't really relevant
if I can't get a module installed in the first place, so I'm going to stick to
just the first problem.

I'm using this small bit of Raku code to handle the actual installation:

my $repository = CompUnit::RepositoryRegistry.repository-for-name('site');
my $meta-file = $path.add('META6.json');
my $dist = Distribution::Path.new($path, :$meta-file);

$repository.install($dist, :$force);

This works in general, but it fails when enabling the sandbox feature on
Portage. This is a feature I generally have enabled, and seems to be common to
have enabled among Gentoo users.

When installing the module this way, it tries to access
/usr/local/share/perl6/site/repo.lock. It is not allowed to leave it's
installation sanbox at /var/tmp/portage/dev-raku/io-path-xdg-0.2.0 (I'm testing
with IO::Path::XDG).

I'm assuming it's making this lock file in order to ensure it can do a certain
operation without interference from other installations. Which operation is
this, and is it possible to work around this somehow?

With Perl (and most other languages, really), it's just dropping some files in
the right directory, which then gets merged into the root filesystem. I'd
preferably use a similar approach with Raku modules.

I've seen that installed modules generally have hashed filenames. If I can just
generate the "right" hashes and drop them into the right directory, that would
be good enough for me. If there's more to it, I would greatly appreciate some
explanation on how this works, so I can consider if it's worth my time.

Thanks in advance for any help!

-- 
With kind regards,

Patrick Spek


www:  https://www.tyil.nl/
mail: p.s...@tyil.nl
pgp:  1660 F6A2 DFA7 5347 322A  4DC0 7A6A C285 E2D9 8827

social: https://soc.fglt.nl/tyil
git:https://home.tyil.nl/git


signature.asc
Description: PGP signature