Re: How to pin down a bug in Rakudo?

2017-05-24 Thread 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.


Re: How to pin down a bug in Rakudo?

2017-05-24 Thread Timo Paulssen
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.


How to pin down a bug in Rakudo?

2017-05-24 Thread Richard Hainsworth
This is to ask advice on how to pin down what appears to be a subtle bug 
in Rakudo so that I can file a bug report.


*Background*

I am updating the work I have down on ModuleCitation, which is not 
efficient at present.


Since I am create a recursive index, that is modules which cite modules, 
etc, there is a chance for a cycle and hence a recursive hole. I avoid 
this by calling another module I wrote called Algorithm::Tarjan.


When passing the new software through a series of unit tests, I get an 
error in the Tarjan module.


I isolated the lines of code and included the whole of the Tarjan 
algorithm in a test program, and got the error to recur. It was 
occurring in a block that started


for %!nodes.values -> $module { # each value is an object with an 
attribute 'name'


}

When trying to work out whether the problem was in the data, I amended 
the line to


for %!nodes.values.sort( { .name } ) -> $module {  # the idea is to 
print trace statements that can be easily  identfied


but then the whole of the new module worked without error. The order of 
the objects should not have any effect on the algorithm.


So then I wondered if this was a bug that had been picked up already, so 
I updated my perl6 to the most recent version of Rakudo.


Now the program with the isolated code and the data samples that I 
prepared works without error and without the .sort kludge.


However, the unit tests of the ModuleCitation module still fail without 
the kludge, but succeed if the kludge in the Tarjan module.


*Conclusion*

The problem does not appear to be a programming error because a change 
that should have no effect on the algorithm cures the error.


The problem seems to be a bug in Rakudo.

The problem seems to be related to the size of a data structure and the 
complexity of the software.



*Advice requested*

In order to be more useful to Rakudo developers, I would like to try to 
find a way to reproduce the error without the specific application I am 
developing. (I would also like to eliminate the possibility that it is a 
programming error of mine). If there is a need to find a work around and 
include it the existing Tarjan algorithm, I would prefer it wasn't 
something like a sort.


Since I don't know what the standard .sort method does, I am not sure 
how to create a sample set of data to reproduce the error.


Any ideas about what to try?

I have been abstract here to get some general ideas about what to try.

If anyone would like to look at the source files, I can mail them. 
However, I think that there may be a problem that is connected to speed 
or memory limitations.


Regards,

Richard