Re: Compiling Rakudo in parallel

[Timo Paulssen]

Sadly, the majority of rakudo's and nqp's compilation is serialized (due
to the dependencies between the individual pieces).

If you build more than one backend at the same time, i.e. moar + jvm,
you can build both in parallel.

On the other hand, the biggest chunk of time is spent compiling the core
setting, which commonly takes a minute on moarvm.

nqp behaves very similarly.

moarvm on the other hand can compile all .c files at the same time and
use up as many cores as there are .c files, but it compiles so fast that
it's hardly worth anything.

hope that helps
  - Timo

Compiling Rakudo in parallel

[Gabor Szabo]

Hi,

is it possible to run any of the compilation and installation phases
of Rakudo in parallel?  (eg. so the "make" will use all the cores in
my Linux machine)

Gabor

Task::Popular was Re: Task::Star and Panda

[Richard Hainsworth]

On the IRC channel, Zoffix raised a very valid point: currently some of 
the "popular" modules overlap.


I don't want to have any curation, or human intervention in the selection.

But Zoffix is right, both JSON::Tiny and JSON::Fast are "popular" but 
J::Fast is a drop-in replacement for J::Tiny, so purely on a 'popular' 
definition a new user gets two modules that provide effectively 
identical functionality.


However, I suppose I could create an 'exclude' list (just as I am 
creating a Core list) that 'blacklists' one of two essentially similar 
modules. That might cause some friction as to whose to include.


My intuition is that in a year or so, the Ecosystem will change and the 
better module will replace others.


On Thursday, May 25, 2017 05:12 PM, Gabor Szabo wrote:

On Thu, May 25, 2017 at 11:59 AM, Richard Hainsworth
 wrote:


However, for someone new to the Perl6 world, there needs to be some form of
recommendation about useful "first" modules.

Agree, but would go further:

Someone new to Perl 6 should not need to make any decision regarding
modules and should not need to install anything else for the common
tasks. What are common tasks changes with time. These days accessing
SQLite, handling JSON, YAML, INI files, and even XML falls in that
place. Even simple web application development falls in that category.

IMHO if the distribution of Perl 6 (I guess I mean Rakudo Start) does
not come with such capabilities then it won't be able to compete with
languages such as PHP or Python because of
1) Analysis paralyzes
2) Lack of knowledge how to install
3) Lack of rights (technical or legal)

Gabor
http://perl6maven.com/

Re: Task::Star and Panda

[Richard Hainsworth]

Hi Steve,

Thanks.

I read perl6.vip - very interesting and useful.

However, for someone new to the Perl6 world, there needs to be some form 
of recommendation about useful "first" modules.


I have just suggested a Task::Popular module on the IRC channel, and 
feedback so far is positive.


I will work on it at the weekend. Hopefully have a module ready soon.

Basically, I will use my work on the most recursively cited modules in 
the Ecosytem (see http://finanalyst.github.io/ModuleCitation/ )


Then filter for passing modules (as on the modules.perl6.org site).

I will look at the data for recursive citation and see if there is a 
statistically significant top group that can be characterised with a 
recursive citation index threshold, otherwise I'll use the top 20.


Since this can be done programmatically, a fresh module can be generated 
each month based on the most used/useful passing modules of the previous 
month.


Regards,

Richard aka finanalyst


On Thursday, May 25, 2017 04:41 PM, Steve Mynott wrote:

On 25 May 2017 at 08:00, Richard Hainsworth  wrote:


I have not seen a discussion on this Forum about removing Task::Star. It
seems to me to be a bad idea.

The discussion is at https://github.com/tadzik/Task-Star/issues/13


There is the distribution for Rakudo Star and it is useful to have a
sort of basic distribution for new users. If this is Task::Galaxy, then
I suggest reference is made to it.

Rakudo Star didn't contain the same modules as Task::Star which was
one of the reasons it was removed.

Task::Galaxy was basically an experiment to see if gitlab (rather than
github) support worked.  It didn't install when I tried it last night
since one of the modules didn't install.  There really isn't any
guarantee that any Task:: type module will work at any particular time
although volunteers are doing their best.

The only reference to Task::Star in Task::Galaxy was intended to
explain where the name came from.

You may want to use Rakudo Star itself (intended to be more stable and
less subject to change than installing Rakudo directly)  or wait for
something like https://perl6.vip/ if you are interested in module
bundles.

S

Re: Task::Star and Panda

[Steve Mynott]

On 25 May 2017 at 08:00, Richard Hainsworth  wrote:

> I have not seen a discussion on this Forum about removing Task::Star. It
> seems to me to be a bad idea.

The discussion is at https://github.com/tadzik/Task-Star/issues/13

> There is the distribution for Rakudo Star and it is useful to have a
> sort of basic distribution for new users. If this is Task::Galaxy, then
> I suggest reference is made to it.

Rakudo Star didn't contain the same modules as Task::Star which was
one of the reasons it was removed.

Task::Galaxy was basically an experiment to see if gitlab (rather than
github) support worked.  It didn't install when I tried it last night
since one of the modules didn't install.  There really isn't any
guarantee that any Task:: type module will work at any particular time
although volunteers are doing their best.

The only reference to Task::Star in Task::Galaxy was intended to
explain where the name came from.

You may want to use Rakudo Star itself (intended to be more stable and
less subject to change than installing Rakudo directly)  or wait for
something like https://perl6.vip/ if you are interested in module
bundles.

S

Re: Possible zef addition

[Simon Proctor]

Sort of, except you really want it to be done at the end of the current
request. (auto-cleanup doesn't seem to do that, setting it to 0 turns it
off).

When you're building a docker image you really want to make sure the end of
every command only the things the NEED are in the filesystem as a snapshot
is taken at the point. If you're wanting to reduce container size this is
important.

I might take a look at zef today if I have time and see if I can work out a
simple version.

Simon

On Thu, 25 May 2017 at 08:06 Ahmad Zawawi  wrote:

> Something like cpanm's work directory auto-cleanup mechanism?
>
>
> https://metacpan.org/pod/distribution/App-cpanminus/lib/App/cpanminus/fatscript.pm#-auto-cleanup
>
> On Thu, May 25, 2017 at 7:20 AM, Simon Proctor 
> wrote:
>
>> So I'm playing around with Docker files (Perl 5 ATM) and one thing I'm
>> getting quite into is trying to keep them small. An important part of this
>> is deleting any extraneous caching info built up during the build,
>> preferably as part of the RUN step to get intermediate layers small.
>>
>> (So with Perl5 and cpanm `rm -rf ~/.cpanm` is your friend).
>>
>> Anyhoo, my thought was could we add something to zef to do this? Either a
>> flag or a new command to auto clean up the ~./zef folder.
>>
>> Yes I know rm -rf ~/.zef is simple to type but if it was built into the
>> command it would show forward thinking. Or something.
>>
>> It's 5am and I couldn't sleep. This is the kind of idea I get.
>>
>> Simon
>>
>

Re: Possible zef addition

[Ahmad Zawawi]

Something like cpanm's work directory auto-cleanup mechanism?

https://metacpan.org/pod/distribution/App-cpanminus/
lib/App/cpanminus/fatscript.pm#-auto-cleanup

On Thu, May 25, 2017 at 7:20 AM, Simon Proctor 
wrote:

> So I'm playing around with Docker files (Perl 5 ATM) and one thing I'm
> getting quite into is trying to keep them small. An important part of this
> is deleting any extraneous caching info built up during the build,
> preferably as part of the RUN step to get intermediate layers small.
>
> (So with Perl5 and cpanm `rm -rf ~/.cpanm` is your friend).
>
> Anyhoo, my thought was could we add something to zef to do this? Either a
> flag or a new command to auto clean up the ~./zef folder.
>
> Yes I know rm -rf ~/.zef is simple to type but if it was built into the
> command it would show forward thinking. Or something.
>
> It's 5am and I couldn't sleep. This is the kind of idea I get.
>
> Simon
>

Re: Task::Star and Panda

[Richard Hainsworth]

The reference is indeed gone on the Rakudo site.

It seems that you removed the reference after I wrote my first post
(bear in mind I am in Hong Kong, so before most of the USA) because I
wrote when I discovered I was getting an error from zef.

In addition, I download the projects file quite regularly to keep a
record for the ModuleCitations graphs. It would seem that Task::Star has
been missing from the Ecosystem for about a week.

Task::Galaxy refers to Task::Star.

I have not seen a discussion on this Forum about removing Task::Star. It
seems to me to be a bad idea.

I cannot follow all of the discussion on the IRC channel, but I do try
to keep up with discussions here.

There is the distribution for Rakudo Star and it is useful to have a
sort of basic distribution for new users. If this is Task::Galaxy, then
I suggest reference is made to it.

Regards,

Richard


On Wednesday, May 24, 2017 06:58 PM, Timo Paulssen wrote:

I removed the recommendation to install Task::Star yesterday, so as of
writing of your email it shouldn't have been on rakudo's website at
least. did you find a reference to Task::Star somewhere else?

Re: How to pin down a bug in Rakudo?

[Richard Hainsworth]

Ah !!!

I had read about lazy and eager, but not appreciated what effect it 
might have.


So the answer for my Tarjan module, which assumes a static network, is 
to replace '.sort' with '.eager' .


However, ... the point at which I was getting an error in the modules 
was the following code


my $wn = %!nodes{$w};
with $wn.index {

The error message was about accessing attributes in object at the 'with' 
statement. Each value of %$node is a "Algorithm::Tarjan::Node" object 
with an attribute .index. However, even though $wn had type 
'Algorithm::Tarjan::Node', it had no attributes at all. So

say $wn.perl;
printed 'Algorithm::Tarjan::Node', but no attributes. Hence even a test 
for definiteness blows up.


Given that I do not know much about lazy processing, I don't know if 
this is a bug or expected behaviour.


Assuming it is expected behaviour:

$w is always a valid key, and so %!nodes{$w} should (eventually) have a 
value. (If evaluated in an eager manner, then the program correctly 
initialises all the values).


Suppose this is a part of a routine that can be called in a lazy manner, 
what might be an idiomatic perl6 way to ensure that a valid value with 
attributes is available for testing?



On Thursday, May 25, 2017 12:45 AM, Timo Paulssen wrote:

Have you considered the effects of lazy evaluation for the hash's values
method? .sort will eagerly evaluate the whole .values list (i.e.
snapshot it) while iterating over it will include added keys and such.