First off, I'm sorry this email thread hasn't received more attention than it has. It turns out that this is a particularly busy week for several parrot hackers.
Having easy-to-use, easy-to-understand compiler tutorials around is an extremely valuable thing. Squaak tends to serve as a nice introduction, when it's working. Considering Jay's frustration and the fact that other users are likely to be similarly frustrated by it, we need to either: 1) Fix squaak and keep it fixed. The best way I can recommend to do this is to move it into the Parrot core repo, and build/test it as part of the normal "test" target. Or, as a similar alternative, move it into the NQP-RX repo as an example and tests, and make sure it gets well-tested from there. 2) Rewrite the tutorial from scratch, if we think that the current state-of-the-art best practices are not well represented by the current tutorial. I can't say which I prefer at this point, I need to re-read the squaak tutorial and see what kind of state it is in before we can make a good judgement one way or the other. I will say that I intend to devote some of my time to this issue in the coming days to see that it does get resolved. Thanks for your patience, Jay. I'm sorry this has been such an uphill battle for you so far. --Andrew Whitworth On Wed, Jun 29, 2011 at 12:05 PM, Jonathan "Duke" Leto <[email protected]> wrote: > Howdy, > > Thanks for your valuable feedback Jay! > > I agree that it is very important that our Squaak tutorial be kept up-to-date. > > We need to think about how we can automate this a bit more, i.e. have actual > tests that will fail if Squaak breaks. > > Again, your feedback on Parrot is extremely valuable to us, please > never feel afraid to tell us about pain points or things that you > think can be improved. > > Also, thanks for volunteering to help us by telling us what you had to > do to get Squaak working on a recent parrot! > > Duke > > PS: Is the R-related parrot stuff that you mentioned available > somewhere public? I would love to take a look and possibly help (if I > can be useful). > > > > On Wed, Jun 29, 2011 at 8:10 AM, Jay Emerson <[email protected]> wrote: >> I wanted to note that I finally did manage to modify squaak >> subroutines (functions) to allow returns, something that I did >> previously in 2.8.0 but struggled with in 3.3.0. This brings up a >> point related to Andrew's post, below. >> >> If I were being paid to work on this, I think that squaak and the >> associated tutorial is high-priority; people new to Parrot will almost >> certainly start here, and people developing a new language will rely >> heavily upon the tutorial. Over the last two years I've worked on a >> bare-bones grammar for the R language, several times. When new >> versions of Parrot evolved, my parser broke. Similarly, older >> versions of squaak were broken by Parrot updates. Frustrating, but >> absolutely necessary: the evolution of Parrot is far more important >> than maintaining backwards compatibility. At the same time, the fast >> evolution of Parrot risks alienating a group of potentially valuable >> contributors. >> >> If the process of updating squaak in parallel with the evolution of >> Parrot were documented, it would be a little friendlier for people >> like me. To this purpose, I hereby volunteer to document what I >> needed to do with function returns in 3.3.0, contrasting this to the >> previously-blogged solution that worked with 2.8.0. How this is used >> (other than a post to this list) is up to you guys. I'll try to do >> this in the next few days. >> >> Jay >> >> ----------------------------------------------------------- >> Howdy, >> >> At the Parrot/Perl 6 BOF at YAPC we are trying to figure out how we can focus >> more on the most important things that need to happen in Parrot. >> >> To facilitate this, please conduct this thought experiment: >> >> If you were being paid to hack on Parrot, which things would you be expected >> to >> work on? >> >> If you can formulate an answer to this, please respond to this email and let >> others know. You won't be held to this, and no one is going to tell anybody >> to >> stop working on their favorite pet project, but we feel that if Parrot >> hackers >> keep this in mind and communicate it, we can better focus our energies on >> the most important things that need to happen. >> >> Duke >> >> -- >> John W. Emerson (Jay) >> Associate Professor of Statistics >> Department of Statistics >> Yale University >> http://www.stat.yale.edu/~jay >> _______________________________________________ >> http://lists.parrot.org/mailman/listinfo/parrot-dev >> > > > > -- > Jonathan "Duke" Leto <[email protected]> > 209.691.DUKE // http://leto.net > NOTE: Personal email is only checked twice a day at 10am/2pm PST, > please call/text for time-sensitive matters. > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
