Howdy, [snip]
> > I have a few questions: > > * How can I, as a motivated Rakudo application developer, help make Parrot > more stable when something like this occurs in my app? In Rakudo, I can > minimize the failure to a line or two, and the devs have a much easier > time fixing the failures. Here, it seems that the cause of the failure is > the complexity of the app, and thus not reducible to a minimal case. > I know how relatively unhelpful instructions like "build my app and make it > do this" are, compared to "this 10-line PIR file causes problems". Please let us know when you run into these problems, we might be able to tell you something like "hey a branch just got merged that may be causing some funny business" or something like that. If you can bisect the Parrot commit that makes things go wonky, that would be even better. You can use the parrot github mirror [0] to do a git bisect, although you can do svn bisects, they are painfully slow. > > * Are bug reports on these kinds of failures useful? They seem transient, > and go away when conditions change slightly. Often people on other > platforms cannot reproduce them. Somehow, the errors themselves are not > the problem, but the underlying cause which makes them come and go on > a regular basis. Yes, they are useful. Your application is large enough to find bugs that we have not written tests for yet. So when we merge a branch, patting ourselves on the back that our test suite still passes, sometimes HLL devs get the short end of that stick. You are most likely getting bit by changes to our calling conventions and/or tickling bugs in our GC that we haven't run into yet or a combination of both. > > * Is there a plan to eradicate or greatly reduce failures like these by > Parrot 2.0? If so, is there any way I can help? I fear the day might come > when one of these errors prevents me from developing my app, and I'd > like to pre-empt that. Please tell us whenever you feel that you are getting bit by a Parrot bug, our wish is that 2.0 be as stable and fast as possible. No big new features are planned before 2.0, just writing more tests, fixing bugs, improving docs and perhaps a few performance tweaks. We want 2.0 to be a solid base for Rakudo Star, but I think under the current plan, 2.3 will be a supported release and that is probably what Rakudo Star will be targeting. > > I'd love to see these random stability problems related to complexity > bottlenecks go away completely -before- Parrot/Rakudo reach sufficient > traction that other people try to develop applications with the size > and memory usage that makes the current problems manifest themselves. I heartily agree. The more Rakudo and Parrot can help each other, the closer to that vision we will be. Duke > > // Carl > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
