jesse's Journal http://use.perl.org/~jesse/journal/ jesse's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:04:50+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 jesse's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~jesse/journal/ RT 3.8 is now available http://use.perl.org/~jesse/journal/36910?from=rss <p>Today, we're releasing RT 3.8.0, the first major upgrade to RT in about two years.&nbsp; Over the past two years, we've been working hard to improve RT.&nbsp; We're very proud of RT 3.8 and hope you'll find it a worthy upgrade.</p><p>Many, but not all, of the new features you'll find in RT 3.8 are the direct result of work we did for clients. WYSIWYG email composition, GnuPG email signatures and encryption, ticket relationship graphs and email digests are all enhanced versions of features we originally developed as &quot;custom&quot; extensions for clients.&nbsp; </p><p>When we haven't been busy improving RT for clients, we've spent much of our time tidying and polishing RT. In the past few months,&nbsp; we've resolved over 540 bugs and feature requests. RT's new visual style, &quot;on-line&quot; dashboards, workflow and performance improvements, along with literally hundreds of bug fixes and performance improvements are the direct result of your patches, bug reports and suggestions over the past few years. </p><p>I could easily claim that there are too many new features to list, but the reality is simply that there are more new features I could list than you're willing to read about. If you're interested in the full, sordid history of changes to RT since RT 3.6, you can find the full history in our public subversion repository at svn://svn.bestpractical.com/rt.</p><p> What's new in RT 3.8 A new visual style </p><p> <a href="http://bestpractical.typepad.com/photos/uncategorized/2008/07/14/homepage.png"> </a> </p><p>We've completely overhauled RT's visual style to look a bit more like what you'd expect modern enterprise software to look like. The pleasing blue gradient background and rounded corners will keep you on an even keel when dealing with even the most complex and frustrating issues. (We've also extensively tweaked the fonts, menus and layouts based on feedback from dozens of testers.&nbsp; RT has always been easy for your team to pick up with little or no user training. The usability improvements in RT 3.8 should help keep your team happy and productive. ) </p><p> Richtext email </p><p> <a href="http://bestpractical.typepad.com/photos/uncategorized/2008/07/14/ticket_create.png"> </a> </p><p>RT has been around since before the days of HTML email. We've completely retooled inline RT's email composition system to give your team a &quot;WYSIWYG&quot; composition window for HTML email using FCKEditor.&nbsp; We chose FCKEditor because of its excellent cross-platform support. (It even preserves styles when you copy and paste from your word processor!) When creating, replying to or commenting on tickets, you can now make things <strong>bold</strong>, <em>italic</em>, red or blue (and do all sorts of other things to your text as well).&nbsp; &nbsp; At the same time, we overhauled how RT displays HTML and multipart email messages to work more like desktop email clients.&nbsp; &nbsp;We've always worked hard to make RT a good email citizen. That's more true now than ever.&nbsp; When sending styled email, RT will always send a plain text equivalent along as well.&nbsp; If you don't need rich text support locally, you can disable it from RT's configuration file.</p><p> Email signatures and encryption </p><p>Many organizations around the world use RT to manage the information flow of their mission-critical security applications. Pretty Good Privacy (PGP) is the global standard for inter-organization secure email. We've updated RT with comprehensive support for PGP using the Gnu Privacy Guard. RT can now verify PGP signatures on incoming messages, decrypt encrypted messages and sign and encrypt outgoing mail.</p><p> User preferences </p><p> <a href="http://bestpractical.typepad.com/photos/uncategorized/2008/07/14/display_prefs.png"> </a> </p><p>RT has always been incredibly configurable and flexible. Through version 3.6, however, most of that configurability was in the hands of developers and administrators alone.&nbsp; Starting with version 3.8, we've introduced a new user preference system.&nbsp; For version 3.8.0, we've added the set of preferences we found our users most commonly reaching for, including: </p><ul> <li>Ticket history ordering </li><li>Timezone</li><li>Date and time format </li><li>Username format </li><li>Default queue </li><li>Size of message text boxes</li></ul><p>&nbsp; Dashboards </p><p> <a href="http://bestpractical.typepad.com/photos/uncategorized/2008/07/14/dashboard.png"> </a> </p><p>With RT, it's easy to customize your home page to show you the saved searches and charts which matter to you on a daily basis.&nbsp; Your RT homepage is your personal dashboard.&nbsp; In RT 3.8, we've made it possible for you to build and save dashboards for particular projects or groups.&nbsp; Dashboards can contain saved searches, saved graphs and ticket relationship charts. You can, of course, keep these dashboards to yourself, but you can also share them with the other members of a group you're in.&nbsp; &nbsp;With just a few clicks, you can schedule daily, weekly or monthly delivery of a dashboard.&nbsp; Here at Best Practical, we used this feature to send daily updates on the progress of the RT 3.8 release to the whole team -- complete with a list of open critical issues and a recap of all the issues resolved in the past day.</p><p> Charts of ticket relationships </p><p> <a href="http://bestpractical.typepad.com/photos/uncategorized/2008/07/14/ticket_relationships.png"> </a> </p><p> RT has a rich &quot;relationships&quot; system which lets you link tickets (or just about anything else) together to form larger projects. You can set up &quot;depends on&quot; relationships, &quot;parent child&quot; relationships and simple &quot;refers to&quot; links.&nbsp; It's always been easy to see a single ticket's relationships as a list. Beginning in RT 3.8, you can build clickable diagrams of tickets and all their relationships. With a few clicks, you can customize which ticket attributes are displayed and how the chart will be rendered.&nbsp; You can save charts you build and include them on your homepage or in RT's new dashboards. </p><p> Lots more! </p><ul> <li>Breeze through upgrades with new upgrade tools</li><li>Subscribe to iCalendar feeds of ticket due dates</li><li>Bookmark frequently-used tickets</li><li>Turn off mail from RT when you go on vacation</li><li>Get your mail from RT as a daily or weekly batch</li><li>Delete historical or spam tickets with RT::Shredder (only as a superuser)</li><li>Set up more configurable business rules with new Scrip Conditions and Actions</li><li>Forward tickets to third-parties from within RT</li><li>Enable and Disable RT extensions with the new Plugins system</li><li>Automatically log out inactive users with rt-clean-sessions</li><li>Run faster with less memory, thanks to numerous&nbsp; performance improvements and bug fixes.</li></ul><p> Download RT </p><p>You can download RT 3.8.0 at: <a href="http://download.bestpractical.com/pub/rt/release/rt-3.8.0.tar.gz">http://download.bestpractical.com/pub/rt/release/rt-3.8.0.tar.gz</a> <br>This release of RT has been digitally signed with PGP. You can download the signature file at: <a href="http://download.bestpractical.com/pub/rt/release/rt-3.8.0.tar.gz.sig">http://download.bestpractical.com/pub/rt/release/rt-3.8.0.tar.gz.sig</a> </p><p> Commercial Support </p><p> <a href="http://bestpractical.com/services/support.html">We sell commercial support for RT</a>.&nbsp;&nbsp; If your organization uses RT in production, you should consider buying a support contract to help ensure that your RT instance continues to work well. To celebrate the release of RT 3.8, we're offering:</p><ul> <li> <strong>free upgrade support</strong> to new support contract customers.</li><li>a <strong>20% discount on upgrades</strong> to RT 3.8 from any previous version of RT.</li><li>a<strong> 10% discount on migration</strong> to RT 3.8 from any other ticketing or issue tracking system.</li></ul><p>To find out more about our support options, please contact us at <a href="mailto:sales@bestpractical.com">sales@bestpractical.com</a>.</p><p> 2008 RT Fall Training </p><p>We provide unparalleled instruction in how to get the most out of RT.&nbsp; &nbsp;On October 24, we will be offering&nbsp; an intensive one-day developer and administrator training session taught by the developers who built RT. This is the first training session where we will present new features and changes in RT 3.8.</p><p>This comprehensive session will cover:</p><ul> <li>New features in RT 3.8</li><li>RT's system architecture</li><li>A guided tour of the RT source code</li><li>Extension mechanisms you can use to customize RT</li><li>How to tie RT into your existing authentication infrastructure</li><li>Building your own tools that talk to the RT backend</li><li>Automating common procedures</li><li>Customizing RT's workflow to match your own</li><li>How to write custom reports based on RT's data</li></ul><p>This session will be only be offered in:</p><p>&nbsp; &nbsp; <strong>San Francisco, CA </strong>on <strong>Friday, October 24th, 2008</strong> </p><p> Reservations </p><p>The cost of training is $995 per participant.&nbsp; Discounts are available for organizations sending more than one participant and for academic institutions.&nbsp; To reserve your seat, please send mail to <a href="mailto:training@bestpractical.com">training@bestpractical.com</a> with the names and email addresses of all attendees. Register now to reserve your seat!&nbsp; Space is limited.</p><p> Private training </p><p>Additionally, we offer private training sessions for organizations. If you would like to schedule a private training session, please drop us a line at <a href="mailto:training@bestpractical.com">training@bestpractical.com</a>.</p> jesse 2008-07-14T19:57:46+00:00 releases ADMIN: rt.cpan.org and misdirected mail http://use.perl.org/~jesse/journal/36801?from=rss <p>Just as a heads up, we've discovered that rt.cpan.org has started to send out mail about bugs to CPAN authors who aren't actually maintainers of the distribution.</p><p>The bug is the unintended consequence of some work we've been doing to make rt.cpan.org faster and easier to use.</p><p>I <i>could</i> claim that it's a cool new feature to help better publicize issues in CPAN distributions, but I can't quite bring myself to lie like that.</p><p>We're working on the issue and will get it sorted out as quickly as we possibly can. I'm sorry for the inconvenience.</p> jesse 2008-06-28T03:11:01+00:00 journal Binary data in JSON? http://use.perl.org/~jesse/journal/36332?from=rss JSON doesn't have native support for binary data? Really? Someone, please tell me I'm wrong. (But only if you can back it up with documentation) jesse 2008-05-06T01:54:56+00:00 journal We've released the code used to run rt.cpan.org http://use.perl.org/~jesse/journal/35833?from=rss <p>As part of a recent project to modernize and improve rt.cpan.org, we took the time to clean up and better abstract the various plugins we use on the backend. We've also (finally) moved all the RT extensions that make up the UI to a public SVN repository.</p><p>You can get at the code via svn://svn.bestpractical.com/</p><p>We use the following extensions.</p><p>For authentication:<br>* RT-Authen-PAUSE<br>* RT-Authen-Bitcard<br>* RT-Authen-OpenID</p><p>CPAN specific UI and public bug tracking:<br>* RT-BugTracker<br>* RT-BugTracker-Public<br>* RT-Extension-rt_cpan_org</p><p>Other:<br>* RT-Extension-MergeUsers<br>* RT-Extension-QuickDelete</p><p>We also have a set of tools which import info from the PAUSE and<br>other sources into RT's Database, but we still need to clean those up a bit (removing hardcoded passwords, little things like that) before we can publish them.</p><p>If you've been hankering for a new feature in rt.cpan.org, now's the time to start sending patches. After 3 good patches, we'll grant you a commit bit to the rt.cpan.org extensions. You can start sending your patches to the address listed on the front page of rt.cpan.org</p><p>-jesse</p> jesse 2008-03-04T18:17:13+00:00 journal Shipwright - our new code distribution system http://use.perl.org/~jesse/journal/35658?from=rss <p>Like any opensource software shop, we distribute the source code<br>for our software. How's that for the obvious statement of the decade?</p><p>Actually, I can beat it. It's a pain in the neck for end users to<br>collect and install all of the dependencies for our software.</p><p>And now I'm going to one-up myself again. Customers often build<br>our software against untested versions of libraries, making debugging<br>'frustrating.'</p><p>RT, our flagship product, depends on 124 separate packages, 114 of<br>them CPAN libraries. While CPAN has pretty good support for recursively<br>installing dependencies, it's not perfect and can be time consuming<br>and confusing for end users. And when it doesn't work right, as can<br>happen when a module author makes an incompatible change, debugging<br>requires a wizard.</p><p>We've built a new source (and binary) packaging system called<br>Shipwright. Shipwright allows you to track all of your package's<br>dependencies in a version control repository like SVN or SVK as<br>well as build order and build instructions.</p><p>It comes with tools for importing Perl modules, C libraries and<br>other dependencies from CPAN, upstream version control repositories<br>and tarballs. When it can discover dependency information (as it<br>can for Perl modules), Shipwright will automatically import the<br>current versions of all listed dependencies if the repository doesn't<br>already contain sufficient versions.</p><p>Shipwright can automatically set up build instructions for projects<br>using autoconf as well as projects using Perl's MakeMaker,<br>Module::Install and Module::Build mechanisms. If necessary, you<br>can customize the build instructions and dependency ordering after<br>you import a package.</p><p>When it's time to ship your project to your end users, all you need<br>to do is take a snapshot of your Shipwright repository and send it<br>out. To build your project, an end user just needs to run<br>"./bin/shipwright-build". If they want to, your users can choose<br>to skip certain dependencies (if they want to use system versions)<br>or specify an installation path. By default, Shipwright builds<br>fully relocatable binary distributions into a temporary directory<br>and users can move them into place or copy them to any number of<br>hosts with the same base system libraries -- Shipwright automatically<br>wraps all your binaries and scripts so that they can find the<br>Shipwright versions of their dependencies, no matter where you move<br>the installed distribution. Shipwright also comes with sh and tcsh<br>scripts you can 'source' to add an installed distribution's libraries<br>to your current environment.</p><p>At Best Practical, we've configured most of our Shipwright distributions<br>to bundle everything above libc. Perl, Subversion and GD are just<br>some of the packages we distribute as part of these relocatable<br>builds. We now have a single-command tool to build, link and install<br>Subversion, SVK and all their dependencies (including APR, Neon,<br>Perl and a bunch of others). With a single command, we downloaded,<br>extracted, checked in and tested Tatsuhiko Miyagawa's Plagger Feed<br>Aggregator and all 134 perl modules it depends on. After that, a<br>single command built a full binary distribution of Plagger, ready<br>for deployment on any Mac OS X system.</p><p>I'm quite proud to release Shipwright 1.0 today. I designed Shipwright<br>with sunnavy, one of the hackers here at Best Practical. He's<br>responsible for almost all of the project's implementation to date,<br>though we're eager to have additional developers join us going forward.</p><p>If you're interested in Shipwright, download 1.0 from<br>http://search.cpan.org/dist/Shipwright and subscribe to the Shipwright<br>mailing list by emailing shipwright-subscribe@lists.bestpractical.com</p><p>You can always get the latest version of the Shipwright source code<br>with this command:</p><p>svn co svn://svn.bestpractical.com/Shipwright/trunk</p> jesse 2008-02-14T21:12:17+00:00 newsnews YAPC::Asia, Japan, Taiwan http://use.perl.org/~jesse/journal/35502?from=rss Ok. So looks like I'll be heading to YAPC::Asia in Tokyo this year, with some extra time in Japan and Taiwan afterward.<br><br>So. What should I be submitting talks about for YAPC::Asia? jesse 2008-01-28T17:16:08+00:00 journal Hiveminder Pro launches today! http://use.perl.org/~jesse/journal/35405?from=rss Hiveminder Pro launches today <p>Today, we're releasing Hiveminder Pro, a major update to our online task management system. Here at Best Practical, we're addicted to Hiveminder's slick, simple task tracking and sharing, but that's not too surprising-- we built Hiveminder to be the shared todo list we always wanted. You don't have to take it from us, though. Sarah Linder of the Austin American-Statesman writes:</p><blockquote><div><p>&quot;I am crazy about Hiveminder. I started using the online to-do list a little more than a year ago, and we're very content together. I had been lost, adrift -- trying different ways to track my stuff, but never settling down. Hiveminder made me less flaky, less absent-minded, less likely to wake up at 3 a.m. realizing I had forgotten something important. Hiveminder, you complete me.&quot; </p></div> </blockquote><p>If you've never used Hiveminder, let me take a moment to run through some of what I think are its most interesting features:</p><p> Braindump </p><p>You've got a lot on your mind. Getting all the stuff you need to do out&nbsp; of your head and into a trusted tool like Hiveminder can make the difference between a good day and a day struggling to get anything done. With Braindump, you can just type out a list of what you need to do - just like writing it up on paper or in Notepad. Hiveminder will turn your notes into a todo list, looking for email addresses, due dates, categories and hints that something&nbsp; might be important. There's a braindump box on every page, but you can focus&nbsp; in on braindump at <a href="http://hiveminder.com/braindump">http://hiveminder.com/braindump</a> </p><p> Task Review </p><p>If you're like me, you have a few hundred items on your todo list. Some of them are work tasks that I really need to get to today and some are little home repair tasks that I can put off for another few months. Task Review walks you through everything on your todo list one at a time. You get to make some simple decisions about each task: Is it done? Can I do it today? Can I get someone else to do it? How long should I hide it away for? At the end of the review, you're left with a pared down list of things you can get done today. Do a review and declutter your list:<a href="http://hiveminder.com/review"> http://hiveminder.com/review</a> </p><p> History </p><p>Just as important as knowing what you do is knowing what you've already done. Hiveminder keeps track of all the changes you make to your tasks, so you can get a full history of an individual task later. That means we can also show you what's happened to your tasks today, yesterday or any day in the past. You can get a peek of what your tasks have been up to today at: <a href="http://hiveminder.com/on/today">http://hiveminder.com/on/today</a> </p><p> Sharing </p><p>One of the strengths of any web-based application is how easy it becomes to share things. Hiveminder is no exception. We built it from the ground up to make it easy to share one task or thousands. You can easily assign a task to another person just by setting the task's owner field to their email address. Hiveminder will make sure they get email telling them that you need them to do something. They don't even have to be a Hiveminder user. We'll send them a URL which lets them access their task without signing up. Once you have a few more tasks to share or a few people you regularly share tasks with, you can create a group and invite other users to join you. Everybody in the group can see all the group's tasks (though you can control who can edit them), you can assign tasks to individual users and everybody can share a list of what needs doing.</p><p> Hiveminder integrates with everything </p><p>Whether you're a Googleista using the iGoogle and Google Calendar widgets, a Mac user browsing your todos with our iCal feeds or reading a feed of tasks in Bloglines or Google Reader, your tasks are always at your fingertips. If you live in your IM client, HMTasks is always around to chat with. The friendly little bot can tell you about what you need to do today and take notes when something new comes to mind. Browser search box integration for Firefox and IE7 lets you search Hiveminder and even braindump new tasks, no matter where on the web you are. I haven't even gotten into our commandline tools or Web API, but if that's what you're into, you can find out more at <a href="http://hiveminder.com/tools">http://hiveminder.com/tools</a> </p><p><nobr> <wbr></nobr>...and more </p><p>I haven't mentioned tags, our innovative &quot;but first...and then&quot; organizational system, printing support, incoming email addresses, the mobile and mini user interfaces or any of a host of other features, but if you visit <a href="http://hiveminder.com/">http://hiveminder.com</a> today, you can find out more about them.</p><p>Last February, PC World Magazine ranked Hiveminder as one of the best Todo list apps on the web. Since then, we've been hard at work to make Hiveminder even better:</p><ul> <li> We've improved performance across the board </li><li> We've added new Google Calendar and iGoogle integrations </li><li> We've added new AOL IM and Jabber chat interfaces </li><li> We've significantly improved the API (more on that in the next few weeks) </li><li> We've added integrations with Firefox and IE7 </li><li> We've cleaned up and streamlined the interface </li><li> We've made repeating tasks easier to use<nobr> <wbr></nobr>...and a whole bunch more </li></ul><p>Today, we're launching Hiveminder Pro. It's $30/year (but read on to find out how to save a few bucks.) For your money, you get:</p><p> Reports </p><p>Pretty charts and graphs are a great motivator and they can provide useful input about how you work. One of the folks here at Best Practical found out that he tends to get more work done on Wednesday than on every other day of the week combined and that his most productive times are when everyone else is out of the office at lunch. Of course, Hiveminder Pro reports are also available for your groups, so you can see who's overloaded, who's slacking off and whether you're getting ahead or falling behind. To turn on graphs and charts, visit <a href="https://hiveminder.com/account/upgrade">https://hiveminder.com/account/upgrade</a> </p><p> Attachments </p><p>Many of you who use Hiveminder to collaborate with team members both inside and outside your organization have told us that you'd really like to use Hiveminder to share documents related to your tasks. The wait is over. As of today, each Pro user has a 500MB task attachment quota. You can work with attachments through the Web UI or simply attach them to tasks you create by email. Attachments you sent in before we created Pro accounts will magically appear when you upgrade at <a href="https://hiveminder.com/account/upgrade">https://hiveminder.com/account/upgrade</a> </p><p> Saved lists </p><p>Hiveminder makes it easy to search and sort your task list. But until today, you needed to redo your searches day after day. Hiveminder Pro gives you a &quot;Save list&quot; link on every task list. It's easy to build a list of all items tagged &quot;shopping&quot; or everything you need to do for your boss. We have a bunch more things you'll be able to do with your saved lists soon, too! To start saving your lists, visit <a href="https://hiveminder.com/account/upgrade">https://hiveminder.com/account/upgrade</a> </p><p> SSL Security </p><p> On today's wider web, protecting your information from prying eyes is increasingly important to many of you. Hiveminder has always protected your password when you log in, but today we've enabled SSL (https) encrypted logins for ALL Hiveminder users. Pro users can choose to protect all their interactions with Hiveminder by visiting <a href="https://hiveminder.com/">https://hiveminder.com</a> to log in. To protect your account with SSL, visit <a href="https://hiveminder.com/account/upgrade">https://hiveminder.com/account/upgrade</a> </p><p> with.hm </p><p>I've saved my favorite for last. Hiveminder has always made it easy for you to create incoming addresses so others can send you tasks by email, but until today it was still hard to assign a task to someone else from your email client. Today, we're introducing a never-before-seen way to talk to an application from any email client.</p><p> Once you set up your secret code in your Hiveminder Pro settings, you can send a task to anyone on the planet by appending &quot;.mysecret.with.hm&quot; to their email address. You don't need to do anything to configure your email client.</p><p> If I wanted to ask the president to give me a balanced budget, I'd open up my email client and dash off a note like this:</p><blockquote><div><p>To: president@whitehouse.gov.mysecret.with.hm <br>Subject: Balanced budget, please?<br> <br>It would be great if you could take care of this next week!<br> <br>Thanks, <br>Jesse</p></div> </blockquote><p> Hiveminder Pro will make a task and notify the President that I've assigned him a task. If he's an existing Hiveminder user, the task will pop into his todo list. If not, he'll get an email with a URL to view and reply to the task I assigned him. To get started assigning<br> tasks by email, just visit <a href="https://hiveminder.com/account/upgrade">https://hiveminder.com/account/upgrade</a> </p><p> It's time to go Pro! </p><p> <strong>Hiveminder Pro accounts are just $30/year</strong>, but since you're a friend of ours (or a friend of a friend), we'd like to offer you (and your friends) <strong>an additional $5 discount</strong>. Just enter <strong>LAUNCHCODE</strong> at <a href="https://hiveminder.com/account/upgrade">https://hiveminder.com/account/upgrade</a>. The coupon is good through February 1.</p><p>If you know someone (or many someones) who could use the gift of productivity, you can use your coupon to give them Hiveminder Pro at <a href="https://hiveminder.com/account/gift">https://hiveminder.com/account/gift</a> </p><p>In the coming weeks and months, we'll be adding a number of other really cool features to Hiveminder and Hiveminder Pro. We'd love to hear your feature suggestions. Just drop them in the &quot;feedback&quot; box on the left-hand side of every page on the site.</p><p>Be Productive,</p><p>Jesse, for Hiveminder</p> jesse 2008-01-16T20:11:39+00:00 news Perl 6 Microgrant: Articles on Operators http://use.perl.org/~jesse/journal/34451?from=rss <p>I'm pleased to announce that we've just accepted a Perl 6 Microgrant proposal from Adriano Ferreira to write a series of articles about Perl 6 operators. Adriano's propsal appears below:</p><p>NAME<br> &nbsp; &nbsp; &nbsp; &nbsp; Proposal for a Perl 6 microgrant "A series of micro-articles at ONLamp"</p><p>DESCRIPTION<br> &nbsp; &nbsp; &nbsp; &nbsp; I plan to write a series of blog entries at ONLamp site (which belongs<br> &nbsp; &nbsp; &nbsp; &nbsp; to the O'Reilly Network) on a Perl 6 related subject. The resulting<br> &nbsp; &nbsp; &nbsp; &nbsp; articles will also be integrated into Pugs' documentation and licensed<br> &nbsp; &nbsp; &nbsp; &nbsp; under the same terms. The theme of the series contemplates brief<br> &nbsp; &nbsp; &nbsp; &nbsp; introductions to the myriad of Perl 6 operators to the varied audience<br> &nbsp; &nbsp; &nbsp; &nbsp; that reads the site weblogs.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; O'Reilly weblogs<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://weblogs.oreilly.com/<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ONLamp (blogs show up at the right)<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://www.onlamp.com/<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ONLamp blogs (another view)<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://www.oreillynet.com/onlamp/blog/</p><p> &nbsp; &nbsp; &nbsp; &nbsp; My initial idea is to approach at each micro-article one operator or a<br> &nbsp; &nbsp; &nbsp; &nbsp; group of closely related operators providing the reader with some small<br> &nbsp; &nbsp; &nbsp; &nbsp; doses of Perl 6 at a light pace. This light pace would be three articles<br> &nbsp; &nbsp; &nbsp; &nbsp; per week, ideally at Monday, Wednesday and Friday.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; To enhance the content, each article shall be submitted for review on<br> &nbsp; &nbsp; &nbsp; &nbsp; #perl6 on freenode. This feedback may prevent mistakes and result in<br> &nbsp; &nbsp; &nbsp; &nbsp; more complete discussions of each operator/feature.</p><p>WHO AM I<br> &nbsp; &nbsp; &nbsp; &nbsp; I am a long time lurker at the Perl community, writing ocasionally at my<br> &nbsp; &nbsp; &nbsp; &nbsp; journal at use.perl, releasing modules at CPAN, and strugling to<br> &nbsp; &nbsp; &nbsp; &nbsp; maintain the dual life of a few core modules (namely, Shell, Exporter,<br> &nbsp; &nbsp; &nbsp; &nbsp; and very recently Pod::Perldoc).</p><p> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://use.perl.org/~ferreira/<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://search.cpan.org/~ferreira/</p><p> &nbsp; &nbsp; &nbsp; &nbsp; By the end of 2005, I have shared with David Landgren the fun of writing<br> &nbsp; &nbsp; &nbsp; &nbsp; perl5-porters summaries (but I had to stop for a lack of tuits). Eh, I<br> &nbsp; &nbsp; &nbsp; &nbsp; missed those times.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Some samples:<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://dev.perl.org/perl5/list-summaries/2005/20050915.html<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://dev.perl.org/perl5/list-summaries/2005/20050926.html<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://dev.perl.org/perl5/list-summaries/2005/20051226.html</p><p> &nbsp; &nbsp; &nbsp; &nbsp; I am currently not well versed at the Perl 6 development, but I believe<br> &nbsp; &nbsp; &nbsp; &nbsp; I have what takes to accomplish the simple task proposed in this grant.<br> &nbsp; &nbsp; &nbsp; &nbsp; It is a chance for me to take a closer look at the current state of the<br> &nbsp; &nbsp; &nbsp; &nbsp; Perl 6 art and make something useful at same time for the sake of<br> &nbsp; &nbsp; &nbsp; &nbsp; broadcasting what Perl 6 would look like and mean to developers all<br> &nbsp; &nbsp; &nbsp; &nbsp; around. Of course, in a very humble scale.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; I am an (obscure) ONLamp blogger since May 2007.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://www.oreillynet.com/pub/au/3044<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (See the BLOG handle.)</p><p>WHEN IT WILL BE DONE<br> &nbsp; &nbsp; &nbsp; &nbsp; Well, Perl 6 has many many operators. Some of them are brand new and<br> &nbsp; &nbsp; &nbsp; &nbsp; deserve more attention. Others are well known and standard and could be<br> &nbsp; &nbsp; &nbsp; &nbsp; discussed in a batch. Anyway they are many.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; From the table in Synopsis 3</p><p> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://www.oreillynet.com/pub/au/3044</p><p> &nbsp; &nbsp; &nbsp; &nbsp; I estimate more than 30 articles (which would take more than 10 weeks<br> &nbsp; &nbsp; &nbsp; &nbsp; when publishing 3 per week).</p><p> &nbsp; &nbsp; &nbsp; &nbsp; Well, that does not sound convincing. I have to think harder and maybe<br> &nbsp; &nbsp; &nbsp; &nbsp; stand on a compromise on 8 weeks or 24 articles. Suggestions for<br> &nbsp; &nbsp; &nbsp; &nbsp; defining sharper boundaries to these task welcome.</p><p>PREVIOUS DISCUSSION<br> &nbsp; &nbsp; &nbsp; &nbsp; The idea occurred to me only recently. Fl&#225;vio Glock agreed it could be<br> &nbsp; &nbsp; &nbsp; &nbsp; desirable. And so I submitted this.</p><p>BLOGGING ABOUT PROGRESS<br> &nbsp; &nbsp; &nbsp; &nbsp; The progress can measured by the very publishing of the articles on the<br> &nbsp; &nbsp; &nbsp; &nbsp; site. If preferred, I may report this on my use.perl journal as well.</p><p>A SAMPLE<br> &nbsp; &nbsp; &nbsp; &nbsp; I prepared a first sample of the contents of the first articles on the<br> &nbsp; &nbsp; &nbsp; &nbsp; series and put them online in a private site.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://ferreira.nfshost.com/perl6/proposal.txt<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://ferreira.nfshost.com/perl6/intro.html<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://ferreira.nfshost.com/perl6/zip.html<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; http://ferreira.nfshost.com/perl6/stitching.html</p><p>PREREQUISITES<br> &nbsp; &nbsp; &nbsp; &nbsp; * I've got the thumbs-up of James Turner, the ONLamp editor<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (http://www.oreillynet.com/pub/au/2978) as an O'Reilly<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; representative to use ONLamp.</p> jesse 2007-09-14T15:25:46+00:00 journal A trio of Perl 6 microgrants http://use.perl.org/~jesse/journal/33708?from=rss <p>I'm pleased to announce three new Perl 6 Microgrants.</p><p> <b>Flavio Glock</b> will receive a travel microgrant to help him attend YAPC::EU and evangelize kp6 and the Perl 6 in Perl 6 effort.</p><p> <b>Steve Pritchard</b> will receive a microgrant to complete the RPM packaging of Parrot and Pugs for Fedora and to submit those packages for inclusion in the official Fedora distribution. Steve will be blogging his progress at <a href="http://blog.stevecoinc.com/">http://blog.stevecoinc.com/</a></p><p> <b>Juerd Waalboer</b> is the maintainer of feather.perl6.nl, the primary host for Pugs development. Juerd will receive a microgrant to purchase upgraded hardware for feather.</p><p>If you're interested in submitting a Perl 6 microgrant proposal, you can find more information about how to do so at <a href="http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg122448.html">http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg122448.html</a>.</p> jesse 2007-07-05T21:22:00+00:00 perl6 First Perl 6 Microgrant - Steve Peters on Parrot Portability http://use.perl.org/~jesse/journal/32799?from=rss <p>We're pleased to announce that we've selected Steve Peters as the<br>recipient of the first Perl 6 microgrant. Steve has been instrumental<br>in helping to ensure that Perl 5 has stayed incredibly portable for<br>the past few years. Steve's starting to turn some of his attention<br>to Parrot. You can find details of the project he's planning in<br>the text of his grant application:</p><p> &nbsp; There are several problems currently with Parrot's portability, which<br> &nbsp; may inhibit its adoption as a run anywhere VM. This problem will be a<br> &nbsp; major obsticle in the Perl6-to-Parrot solutions that have been<br> &nbsp; proposed.</p><p> &nbsp; Some of these problems include:</p><p> &nbsp; &nbsp; * Failures to successfully link a Parrot executable with gcc on Cygwin.<br> &nbsp; &nbsp; * Failures to successfully link a Parrot executable with icc or suncc<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; on Linux.<br> &nbsp; &nbsp; * Failures to successfully link a Parrot executable with Borland C++<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; on Windows.</p><p> &nbsp; These are the failures I have personally experienced. I suspect there<br> &nbsp; may be additional problems on other OS's and platforms as well since<br> &nbsp; there seems to be very spotty coverage of HP-UX and Solaris based on<br> &nbsp; results seen on the Parrot smoke report website.</p><p> &nbsp; Having worked with the Perl 5 core for a few years now, I have a good<br> &nbsp; deal of experience in this area. I currently smoke test Perl on four<br> &nbsp; different operating systems with seven different compilers. I have<br> &nbsp; worked to get Intel C++ and Sun Studio compiling Perl without failures<br> &nbsp; on Linux. I am also currently working with Sun in their early access<br> &nbsp; program to test out their new Sun Studio 12 compilers on both Linux<br> &nbsp; and Solaris.</p><p> &nbsp; For completion of this grant, I believe the following would be the<br> &nbsp; bare minimum needed for a successful project.</p><p> &nbsp; &nbsp; * Successful completion of a full Cygwin compile of Parrot and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; application of necessary patches to Parrot. Test failures should be<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; in line with what is observed on Linux or Mac OS X. That is clean<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; up any test failures that seem to be platform specific to Cygwin.</p><p> &nbsp; &nbsp; * Similarly, compiling Parrot with Intel C++ and Sun Studio 12 for Linux,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; application of any necessary patches, and cleanup of compiler specific<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; issues.</p><p> &nbsp; &nbsp; * Compiling Parrot with Borland C++ on Windows with application<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; of necessary patches to the Parrot core. Cleanup of compiler specific<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; issues with necessary additional changes patched in the Parrot core.</p><p> &nbsp; &nbsp; * Investigation into gmake "-j" support to allow for parallel<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; building of Parrot.</p><p> &nbsp; Additional planned work:</p><p> &nbsp; &nbsp; * Additional cleanup for other OS's including (but not limited to)<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; NetBSD, OpenBSD, and FreeBSD.</p><p> &nbsp; &nbsp; * Testing and cleanup for Solaris (x86 and Sparc) and HP-UX if needed.<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; As I only have guest access for the majority of these platforms,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the work is dependent on continued access to these systems. As long<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; as I have the access, though, I plan to treat this deliverable<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; similarly to the others.</p><p>Steve will be blogging about his grant progress at http://<br>use.perl.org/~speters/journal.</p><p>Please join us in wishing him the best of luck with his project.<br>We're really looking forward to seeing the results of this work.<br>If you're interested in submitting a Perl 6 microgrant proposal,<br>you can find details here:</p><p>http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg122448.html</p><p>Best,<br> &nbsp; &nbsp; Jesse and Leon</p> jesse 2007-03-26T17:01:19+00:00 journal Genericish dispatcher/controller logic with Jifty http://use.perl.org/~jesse/journal/31756?from=rss In the past couple days, a few folks from the <a href="http://use.perl.org/~markjugg/journal/31748">CGI::App</a> and <a href="http://use.perl.org/~LTjake/journal/31738">Catalyst</a> communities have posted examples of their dispatcher/controller layout and syntax. Here's what a similar example might look like in Jifty:<blockquote><div><p> <tt>use warnings;<br>use strict;<br> <br>package MyApp::Dispatcher;<br>use Jifty::Dispatcher -base;<br> <br>under '/admin/account' =&gt; run {<br>&nbsp; &nbsp; before '*' =&gt; set object_type =&gt; 'account';<br>&nbsp; &nbsp; before qr'/(\d+)' =&gt; run { set id =&gt; $1; };<br> <br>&nbsp; &nbsp; on '/'&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=&gt; show 'crud/index';<br>&nbsp; &nbsp; on '/create'&nbsp; &nbsp;=&gt; show 'crud/create';<br>&nbsp; &nbsp; on '/*/update' =&gt; show 'crud/update';<br>&nbsp; &nbsp; on '/*'&nbsp; &nbsp; &nbsp; &nbsp; =&gt; show 'crud/view';<br>};</tt></p></div> </blockquote><p> <b>Edit: jibsheet pointed out that I'd misunderstood the Catalyst example. the code above should now be a more faithful implementation</b></p> jesse 2006-11-29T19:02:51+00:00 journal Hiveminder is alive! http://use.perl.org/~jesse/journal/30557?from=rss <p>We've just launched <a href="http://hiveminder.com/">Hiveminder</a>, a shared todo list service. Hiveminder makes it easy to keep track of everything you need to do and to share tasks with the people you love (and those you just need to do things for you.) You can assign tasks to anyone who has an email address. They don't even have to sign up for an account.</p><p>You can defer tasks until tomorrow, next week or next year, with a click of your mouse. "But first" and "and then" links on every task make it easy to procrastinate...er, to model complex projects.</p><p>We wouldn't be Web 2.0&#8482; compliant if we didn't let you tag each task with useful keywords.</p><p>Groups let you share tasks with a set of friends or coworkers (and help keep work out of your way when you're getting stuff done at home).</p><p>We'll be rolling out paid premium services later this year, but basic accounts will always be free.</p><p>Come <a href="http://hiveminder.com/tour">take a tour and sign up for an account</a>.</p><p>And of course, yes, it's built on Perl and <a href="http://jifty.org/">Jifty</a>, our web application framework.</p> jesse 2006-08-07T19:19:25+00:00 journal OSCAL - Scheduling for oscon http://use.perl.org/~jesse/journal/30430?from=rss <a href="http://laughingmeme.org/">Kellan</a> put together a fantastic session scheduler for OSCON: http://oscal.quxx.info Sexy! (Even if it <i>is</i> in rails<nobr> <wbr></nobr>;) jesse 2006-07-26T08:58:12+00:00 journal Hiveminder http://use.perl.org/~jesse/journal/30160?from=rss We're getting close to launching Hiveminder, our new hosted service. I've got 5 beta accounts waiting for the first five people to comment on this post. I'll need your email address, either in the comment or in private mail to jesse@cpan.org. jesse 2006-07-04T04:43:17+00:00 journal Best Practical Solutions Announces SVK Acquisition http://use.perl.org/~jesse/journal/29812?from=rss <p>Best Practical Solutions Announces SVK Acquisition - Total World Domination Plan Proceeding Apace</p><p>Every ticketing system sucks. Here at Best Practical, we're really proud of the fact that RT sucks less than everything else out there and helps many thousands of organizations around the world get their work done with less pain and suffering.</p><p>We're a small software development shop. Between the publicly available versions of RT available and our customer projects, we maintain at least half a dozen active lines of development at any one time. When we first started to do this sort of thing, each merge took about six hours to integrate. That was ok when we were merging two branches once a month....and totally failed when we were trying to merge changes across six branches.</p><p>In 2003, Chia-liang Kao (clkao) took a year off work to create a version control system that would let him hike and explore hot springs in Taiwan's mountains and still be able to be a productive software developer. He ended up creating SVK, an advanced distributed version control system which runs atop Subversion, the industry standard enterprise version control system. SVK let clkao mirror remote Subversion repositories, create local branches, hack while offline and later resynchronize his changes with the upstream Subversion servers. SVK is the best version control system for getting your work done while you're hiking in the mountains. It just so happens that what makes SVK wonderful when you're soaking in the hot springs makes it an excellent platform for getting your work done halfway around the world, on an airplane, in a cafe or in your office.</p><p>SVK's advanced branching and merging revolutionized our development process here at Best Practical. What used to take us days now takes minutes. We can get more work done faster than ever before. We've been rabid supporters of SVK since its birth. When clkao and I started talking about how I bootstrapped RT into a business and how Best Practical might be able to do something similar for SVK, I literally jumped at the opportunity to help. (And by that, I mean that I jumped on a plane to London on a day's notice to talk face to face about SVK's future.)</p><p> &nbsp; I'm pleased to announce that as of today, Chia-liang Kao has joined me as a partner at Best Practical Solutions and we're pleased to announce that SVK is now a Best Practical product. We remain 100% committed to keeping both RT and SVK open source and are excited about about all the cool new functionality we'll be able to offer users of both products.</p><p>Over the next couple months, we'll be announcing new support, consulting and custom development services related to SVK and software revision control. You'll also see SVK's website, mailing list and repository move to Best Practical, where we can offer a higher level of service for all users.</p> jesse 2006-06-05T20:21:05+00:00 journal All together now. http://use.perl.org/~jesse/journal/29406?from=rss It looks like folks are listening. I've been on about <a href="http://jifty.org/">continuations for web programming</a> for a while. (Not as long as <a href="http://smallthought.com/avi">some</a>.<nobr> <wbr></nobr>;) <br> <a href="http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Plugin-Continuation/">Even Catalyst is getting in on the action.</a> jesse 2006-04-21T22:48:05+00:00 journal At OSCON: Smalltalk is the new Ruby [1] http://use.perl.org/~jesse/journal/29381?from=rss <p> <a href="http://conferences.oreillynet.com/os2006/">OSCON</a>'s coming up in Portland in July. I always go to OSCON for the hallway track. (And it's worth it for that alone.) The sessions have never really been my thing. </p><p>But this year, there's actually something that I'm dying to see: <a href="http://conferences.oreillynet.com/cs/os2006/view/e_sess/8942">Avi Bryant's talk on Seaside</a>. </p><p> <a href="http://seaside.st/">Seaside</a> is a somewhat heretical web framework. They generate their HTML. They don't embrace meaningful URLs. They use Smalltalk, of all things. </p><p>Of course, by making these crazy choices, they get insane amounts of power. When we were building <a href="http://jifty.org/">Jifty</a>, we stole liberally from everything that had good ideas. We dragged Rails down a dark alley and rifled through its pockets. We grabbed Catalyst's wallet. </p><p>But really, Seaside's killer features like Continuations and Halos...just stopped me in my tracks. Once we got them into our grubby little perlish hands, I realized: This is the way development is supposed to be. </p><p> So. Now I get to see the master explain the rest of Seaside's magic. That's worth the ticket price right there. Especially because then I'm going to go home and spend the next few weeks stealing the rest.<nobr> <wbr></nobr>;) </p><p> Oh. And I'm <a href="http://conferences.oreillynet.com/cs/os2006/view/e_sess/8661">giving a talk</a> on Jifty, too. </p><p> [1] Really, it's been Ruby since before Ruby was Ruby.</p> jesse 2006-04-20T01:33:11+00:00 journal Jifty http://use.perl.org/~jesse/journal/28124?from=rss <a href="http://jifty.org/">http://jifty.org</a>. It's out. I'm rather tired. You'll get a proper release announcement later today. Enjoy your present. jesse 2005-12-25T09:15:48+00:00 journal Call for Pumpking: Do you want a Ponie? http://use.perl.org/~jesse/journal/27986?from=rss <p>Two and a half years ago, Fotango announced their sponsorship of the Perl 6 effort, in the form of the "Ponie" project to port the Perl 5 runtime to the Parrot Virtual Machine. For the past year, Nicholas Clark has worked as the pumpking for Ponie as part of his work for Fotango. He's recently moved on from Fotango and it's time for Ponie to do so as well. We're currently interviewing for a new pumpking to take over his role.</p><p>The Ponie pumpking needs to manage the route we take to get the Ponie source code from where it is now to its eventual goal: a Perl 5 runtime fully integrated with the Parrot virtual machine.</p><p>You won't start from nothing. Nick and Artur Bergman before him have developed a plan to get us to the glorious future and have made a significant dent in that plan, but there's still a huge amount to do.</p><p>You'll need to be able to work with the existing plan and expand and revise it as necessary, based on feedback and discoveries made while working through the current tasks.</p><p>Ponie is an open source project. While you'll likely be doing a lot of the heavy lifting, you also need to be able to nurture the community and implementation. Contributors will be submitting patches. You'll need to work with them to refine their patches and recruit some of them as core committers.</p><p>This is primarily a C hacking role rather than a Perl hacking role. (That is, you'll be coding Perl, not coding<nobr> <wbr></nobr>/in/ Perl.) You absolutely need a good working knowledge of C and would be well-served to have some experience managing large projects written in C. And yes, an intimate knowledge of Perl's internals would definitely come in handy.</p><p>There's one thing about Ponie that might really appeal to you if you have a pretty good handle on Perl 5's internals. Ponie is the perfect opportunity to clean up and refactor the guts you hate most. It's a huge refactoring project and you'll have more than a little freedom to make things faster, cleaner, saner, more maintainable and generally _better_.</p><p>If you're interested in being the next Ponie pumpking, please submit a brief bio to ponie-pumpking@perl.org. We won't consider applications posted publicly.</p><p>Over the coming weeks, Nicholas Clark and I will work to pick his successor. Nick and I look forward to hearing from you.</p><p> &nbsp; &nbsp; &nbsp; &nbsp; Jesse</p> jesse 2005-12-14T23:00:48+00:00 journal Too Early? Too Often? http://use.perl.org/~jesse/journal/27691?from=rss So. We have this new application. It's not done yet. It's agressively not done yet.<br><br>That's not to say we don't have users. We do. And they're giving us good feedback. There's lots we want to do with this application. It has a bright future. It may or may not displace Google as the epiecenter of the internet. (Ok. we know it won't displace Google. That's not even something we're trying to do.)<br><br>But there are other things in the same space as our application. Some of them are better (for now). Most of them are abysmally bad.<br><br>What we have isn't polished. There are still rough edges here and there. And it's far from feature complete. But it is useful. (Either that or it's so bad that our users take pity on us and lie about it being useful. )<br><br>This thing we're doing is hosted, so it's not a problem to grow it day by day and feature by feature. We've got a nice comprehensive test suite. We aren't afraid to roll new releases every day until it's right.<br><br>So. do we throw open the doors, invite the world in to see what we've got, possibly laugh at us and walk away before we're ready with something we think is great?<br><br>Or do we wait and let the space get even yet more crowded while we hide in our bat-cave with our not-quite-there-but-still-neat application? jesse 2005-11-22T05:51:27+00:00 journal Parrot Sketch - halloween edition http://use.perl.org/~jesse/journal/27400?from=rss <tt>13:09 &lt;jesse&gt; autrijus: how's the threads speccing been going with liz?<br>13:09 &lt;autrijus&gt; jesse: very well; collected use cases<br>13:09 &lt;jesse&gt; (I conned autrijus and liz into trying to figure out how perl6 concurrency might work<nobr> <wbr></nobr>;)<br>13:09 &lt;autrijus&gt; mostly from her Thread::*<br>13:09 &lt;jesse&gt; now if we can get someone to do the same for parrot, we'll be golden<br>13:09 &lt;autrijus&gt; going to implement the low level abstractions (multiplex, posix threads, stm)<br>13:09 &lt;autrijus&gt; which all comes for free with GHC<br>13:10 &lt;autrijus&gt; and then build "is atomic", "is critical", "is throttled" on top of them<br>13:10 &lt;autrijus&gt; and then rebuild her Thread::* (the ones that are _not_ workarounds for p5 warts) on them<br>13:10 &lt;autrijus&gt; to test whether the low level abstractions _feel_ correct enough<br>13:10 &lt;autrijus&gt; the low level ones will be part of S17<br>13:10 &lt;autrijus&gt; and going to demand that from parrot<br>13:11 &lt;autrijus&gt; which according to vienna meeting is part of parrot's "vision" anyway<br>13:11 &lt;autrijus&gt; so should be simple matter of programming.<br>13:11 &lt;autrijus&gt; see my use.perl journal for some of the basic ideas<br>13:12 &lt;autrijus&gt; work in progress doc at http://svn.openfoundry.org/pugs/docs/AES/S17draft.pod<br>13:12 &lt;autrijus&gt; will seek realspace review tomorrow at amsterdam.pm meeting<br>13:12 &lt;jesse&gt; cool<br>13:12 &lt;autrijus&gt; with p5pers such as merijn, tons, juerd, abigail(?) etc<br>13:12 &lt;autrijus&gt; also, it's "Concurrency" not "Threads"<nobr> <wbr></nobr>:)<br>13:12 &lt;autrijus&gt; eog<br>13:13 &lt;autrijus&gt; er, eof.<nobr> <wbr></nobr>:)<br>13:13 &lt;jesse&gt; Ok. hey. no chip, leo, patrick<br>13:13 &lt;jesse&gt; so let's get rolling<br>13:13 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has quit [Quit: Leaving]<br>13:13 &lt;jesse&gt; autrijus, what's new that's not concurrent?<br>13:13 &lt;autrijus&gt; and no chromatic.<br>13:14 &lt;autrijus&gt; object space, mostly<br>13:14 &lt;autrijus&gt; basically, porting the YARV instruction set to p5/hs/js/pir<br>13:14 &lt;autrijus&gt; only the OO-related parts anyway<br>13:15 &lt;autrijus&gt; problem being parrot, p5, js all got kinda rich OO semantics<br>13:15 &lt;autrijus&gt; p6 metamodel can build on either of them "natively" but prior experience shows deviant semantics<br>13:16 &lt;autrijus&gt; hence going to spec out the minimum API required on part of the host runtime to get p6 OO bootstrapped<br>13:16 &lt;autrijus&gt; think of it as PIL for OO stuff.<br>13:16 &lt;autrijus&gt; primary note at http://svn.openfoundry.org/pugs/docs/notes/object_space.txt<br>13:16 &lt;autrijus&gt; s/primary/preliminary/<br>13:16 &lt;autrijus&gt; YARV instruction table at http://www.atdot.net/yarv/insnstbl.html and online compiler at<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;http://www.atdot.net/yc/compile<br>13:16 &lt;autrijus&gt; YC is really good stuff -- recommended for parrot folks<br>13:17 &lt;autrijus&gt; considering targetting YARV as first tier implementation.<br>13:17 &lt;autrijus&gt; will review ParrotObject and report mismatches and/or slow parts.<br>13:17 &lt;jesse&gt; cool<br>13:17 &lt;autrijus&gt; (also, "port" YARV OO instruction is not wholesale port)<br>13:18 &lt;autrijus&gt; and semantics would differ, eg. assigning to an attribute is not done by calling "attr=" method<br>13:18 &lt;autrijus&gt; but the basic idea is sound.<br>13:18 &lt;autrijus&gt; eof on that part.<br>13:18 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>13:18 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has joined #parrotsketch<br>13:18 &lt;jesse&gt; autrijus: is that it for you?<br>13:19 &lt;autrijus&gt; otherwise, not blocking on anything, still comptools.pod in parrot tree would be nice<br>13:19 &lt;jesse&gt; and on that note: allison.<nobr> <wbr></nobr>;)<br>13:19 &lt;autrijus&gt; yeah, the rest are p6c stuff, not directly parrot related.<br>13:20 &lt;autrijus&gt; eof for me<nobr> <wbr></nobr>:)<br>13:20 &lt;jesse&gt; what's new, allison?<br>13:21 &lt;allison&gt; oop, sorry, off looking at other things<br>13:21 &lt;allison&gt; I finished the port of version 0.05 of Luke's Language::AttributeGrammar.<br>13:21 &lt;allison&gt; to PIR<br>13:22 &lt;allison&gt; I made a few changes in the process, such as: made it more purely OO so it's not so dependent on closures,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; use a coroutine to generate unique ids for the nodes as I traverse the tree.<br>13:22 &lt;allison&gt; http://svn.lohutok.net/nam/trunk/parrot/modules/Language/AttributeGrammar/<br>13:<nobr>2<wbr></nobr> 2 &lt;autrijus&gt; ooh svn.lohutok.net<br>13:22 &lt;allison&gt; the next steps are to try it out on more complex trees<br>13:23 &lt;allison&gt; including the output from PGE grammars<br>13:23 &lt;allison&gt; I'm tempted to take a detour, though, and fix the problem with Parrot::Test library paths<br>13:24 &lt;allison&gt; I should probably make a journal entry about it<br>13:24 &lt;jesse&gt;<nobr> <wbr></nobr>:)<br>13:25 &lt;allison&gt; also, still need to make draft compiler tools plan public<br>13:25 &lt;allison&gt; (just so you know it's still on my TODO list<nobr> <wbr></nobr>:)<br>13:25 &lt;allison&gt; next step after more complex trees is to integrate it into Punie<br>13:25&nbsp; * jesse has evil plans for todo lists<nobr> <wbr></nobr>;)<br>13:25 &lt;jesse&gt; I hear a rumor that the compiler tools plan will cause a milestones update to be needed?<br>13:26&nbsp; * allison likes jesse's evil plans for to do lists, when do we see code?<br>13:26 &lt;jesse&gt; the "and make your todo list public" bit is what's currently missing.<br>13:26 -!- leo [~lt@feather.perl6.nl] has joined #parrotsketch<br>13:26 &lt;autrijus&gt; leo!<br>13:26 &lt;leo&gt; hi all<br>13:26 &lt;jesse&gt; I'm not sure I want to subject the perl 6 dev team to my beta toolset<nobr> <wbr></nobr>;)<br>13:26 &lt;jesse&gt; using RT for todo lists is probably saner for now<br>13:26 &lt;leo&gt; meeting early today<nobr> <wbr></nobr>;-)<br>13:27 &lt;chip&gt; I'm here too<nobr> <wbr></nobr>.. since Leo jumped in<br>13:27 &lt;allison&gt; jesse: well, the original milestones called for one level of AST and we now have two, I'm not sure that's a<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; big enough change to be significant<br>13:27 &lt;chip&gt; timezones--<br>13:27 &lt;autrijus&gt; leo: http://perlcabal.org/~autrijus/tmp/today.tmp.txt<br>13:27 &lt;jesse&gt; patrick had said something about your compiler tools plan replacing a chunk of the milestones<br><br>(no chat topic is set)<br>[1:27pm] Nicholas: I'm unconvinced of a need to stick to the old GMT time.<br>[1:27pm] allison: jesse: lemmie look at them...<br>[1:27pm] jesse: I'll take commentary on meeting time by email<br>[1:27pm] jesse: allison: first: blocking on anything?<br>[1:27pm] jesse: if not, I'll move on to harassing others<br>[1:28pm] allison: jesse: all the work I'm doing falls in milestone 2<br>[1:28pm] allison: though, I wouldn't necessarily call it "Parrot AST" now.<br>[1:29pm] allison: re: "blocking" on Parrot::Test<br>[1:29pm] jesse: ok<br>[1:29pm] jesse: but that's an allison-fixes, not an out-of-allison's-hands, right?<br>[1:30pm] allison: I can't write tests for any non-core libraries because test code reads all paths as being relative to the location of Parrot::Test in the working copy of parrot<br>[1:30pm] allison: it could be either allison-fix or, someone else fix<br>[1:31pm] chromatic: Or "don't write non-core libraries outside of the Parrot tree", as in a technical bias for a cultural issue.<br>[1:31pm] allison: depends on how itchy I get about the limitation<br>[1:31pm] chromatic: Just bringing up a final possibility, not suggesting that's the right approach.<br>[1:31pm] jesse: ok.<br>[1:31pm] allison: but that's strange, I mean, yes we should install libraries in a standard location<br>[1:32pm] allison: but, for testing we shouldn't have to install them<br>[1:32pm] allison: (want to test before install)<br>[1:32pm] chip: Parrot::Test shouldn't impose that kind of diretory tree requirement.&nbsp; If nothing else you might want to have multiple Parrot installs with different build options<br>[1:32pm] chromatic: Agreed.&nbsp; Eventually it needs fixing.<br>[1:33pm] Tweety joined the chat room.<br>[1:33pm] Tweety: Hi there.&nbsp; I am Tweety.&nbsp; I am now publically logging this channel.&nbsp; If you don't want to be logged, please leave now.<br>[1:33pm] chip: allison: You'd probably find a quick volunteer if you wrote a p6i message with a provocative subject ("Help save Allison's world")<br>[1:33pm] jesse: Gee, thanks, tweety.<br>[1:34pm] allison: chip: ok, I'll do that, thanks<br>[1:34pm] jesse: cool.<br>[1:34pm] jesse: who should I pick on next?<br>[1:34pm] &amp;#8226; chip waves his hand<nobr> <wbr></nobr>... better to jump than get pushed<br>[1:35pm] pmichaud: makes it easier to control the fall<br>[1:35pm] chip: Actually got some good time over the weekend.&nbsp; THe lexical picture is shaping up.<br>[1:35pm] jesse: cool<br>[1:35pm] chip: I know I've been mumbling about this for a while, but this time I even got a good picture for closures.<br>[1:36pm] chip: Short versoin: the interface for lexicals conforms to Hash, and for Tcl, they actually will be in a Hash.&nbsp; (Tcl is<nobr> <wbr></nobr>... hardly compilable)<br>[1:36pm] pmichaud: yay!<br>[1:36pm] pmichaud: chip, that is *exactly* what I was wishing for this weekend<br>[1:36pm] chip: Perl6 lexicals will be more like a pseudohash (and the shade of Graham smiles)<br>[1:37pm] chromatic: Everyone else grimaces.<br>[1:37pm] chip: The key/value translation belongs to the Sub, while the array thus indexed (the pad) belongs to the call frame<br>[1:37pm] autrijus: actually I wrote Class::PsuedoHash. I like them.<br>[1:37pm] &amp;#8226; mdiep is just happy that chip has taken Tcl into consideration<br>[1:37pm] chip: They're actually a useful abstraction<br>[1:38pm] chip: anyway: I think we can get a leg up on Perl 5 closures.<br>[1:38pm] chromatic: Agreed, I'm just interrupting.&nbsp; Sorry.<br>[1:38pm] chip: In perl 5, eval STRING in a closure can't see any variables that its outer subs didn't specifically mention.&nbsp; I'd rather just capture all the outer pads at closure creation time.<br>[1:39pm] chip: But is that a bad thing WRT object lifetime?<br>[1:39pm] chip: (maybe this is a question period.&nbsp; autrijus think about it)<br>[1:39pm] autrijus: chip: of course that is the way to go.<br>[1:39pm] chip: autrijus: good. so much for that question<br>[1:39pm] autrijus: and I think p6 depends on that as well<br>[1:39pm] chip: Perl 5 doesn't capture all the pads, just the specific variables it's seen<br>[1:40pm] autrijus: as far as I can remember from larry's %MY:: and %OUR:: rants in yapctoronto<br>[1:40pm] autrijus: so pugs is snapping all pads in all its runtimes<br>[1:40pm] autrijus: cool if parrot does that.<br>[1:40pm] chip: ok<br>[1:40pm] pmichaud: I agree, this will be cool<br>[1:41pm] chip: OK then.&nbsp; My key resource is continued free time.&nbsp; Looking promising.<br>[1:41pm] chip: ^Z<br>[1:41pm] jesse: ok. matt?<br>[1:42pm] jesse: wait. blocking on anything, chip?<br>[1:42pm] chip: jesse: the 'resource' comment was meant as an answer to that: "no"<br>[1:43pm] jesse: ok.<br>[1:43pm] jesse: matt, then<br>[1:43pm] mdiep: I finally figured out Tcl's lexical issues this week: Eval'ing in PIR returns a closure.<br>[1:43pm] mdiep: Leo was kind enough to provide a way to get to the underlying Sub PMCs<br>[1:43pm] mdiep: so those issues are still fixed<br>[1:43pm] mdiep: err, s/still<nobr> <wbr></nobr>//<br>[1:44pm] mdiep: we are still blocking on unimplemented functions in charset/unicode.c, however<br>[1:44pm] jesse: who needs to implement those?<br>[1:44pm] jesse: are there tests for them?<br>[1:45pm] mdiep: I'm afraid I don't know much about those failures. coke reported them to me.<br>[1:45pm] autrijus: oh, PGE for nonascii stuff for pugs has been blocking on those too<br>[1:45pm] autrijus: I committed stubs and leo fixed my broken C code<br>[1:45pm] autrijus: but many XXXs are left<br>[1:46pm] pmichaud: mdiep: do you know which specific functions you need?<br>[1:46pm] mdiep: pmichaud: no, I don't. but I could probably compile a list, given a little time.<br>[1:46pm] pmichaud: mdiep:&nbsp; that would probably be helpful.&nbsp; I know that PGE is now currently blocking primarily on the find_cclass ops<br>[1:47pm] mdiep: I'll try to compile a list and send it to p6i<br>[1:47pm] jesse: cool.<br>[1:47pm] jesse: Anything else good in the tcl world?<br>[1:48pm] mdiep: not directly tcl, but I'm also waiting for chip to get back to me about my latest namespace spec draft<br>[1:48pm] mdiep: other than that, no.<br>[1:48pm] jesse: cool<br>[1:48pm] chip: a-firmative<br>[1:48pm] jesse: patrick?<br>[1:49pm] pmichaud: it's been a very busy week for me with parrot stuff<br>[1:49pm] pmichaud: last week I checked in the initial version of a shift-reduce parser, and a few examples in the examples/pge directory<br>[1:49pm] pmichaud: since then I've converted PGE to now use the shift-reduce parser for parsing perl 6 rule expressions (instead of the previous rec-descent parser)<br>[1:49pm] pmichaud: this also changes a number of the internal interfaces, but all for the better; it's a massive cleanup<br>[1:50pm] pmichaud: as a result, the perl 6 rules code is now 30% smaller (was 2100 lines, now 1500 lines)<br>[1:50pm] autrijus: (benchmarked?<br>[1:50pm] pmichaud: not to mention it should be faster<br>[1:50pm] pmichaud: I haven't benchmarked it, no, but there's a TODO item in RT for that<br>[1:51pm] autrijus: nice<br>[1:51pm] pmichaud: one big benefit is that PGE can now be used to parse perl 6 rule expressions;&nbsp; i.e.,&nbsp; &nbsp; &lt;p6rule&gt;&nbsp; will parse out a valid perl 6 rule expression<br>[1:51pm] pmichaud: this makes it easy to embed in grammars<br>[1:52pm] pmichaud: I've also added the ability to define custom &lt;ws&gt; rules (for allison) and next I'll be implementing lookahead and closures<br>[1:53pm] jesse: cool.<br>[1:53pm] pmichaud: checkin is simply waiting for me to get everything sync'd up with the new code interfaces and make sure all the tests pass again<br>[1:54pm] allison: awesome!<br>[1:54pm] jesse: anything you're waiting on?<br>[1:54pm] pmichaud: the biggest thing blocking me at the moment is the need to occasionally sleep<br>[1:54pm] jesse: ice<br>[1:54pm] jesse: nice<br>[1:54pm] jesse: though I hear they have drugs for that.<br>[1:54pm] pmichaud: the other thing we'll have is a nice rich set of trees (and desired transformations) that could serve as test cases for the attribute grammar code<br>[1:55pm] pmichaud: in particular, p6rules could serve as an example, since it has to go from parse tree -&gt; semantic tree -&gt; optimizations -&gt; code gen<br>[1:55pm] autrijus: we have... a tree and AG rules for haskell<br>[1:56pm] autrijus: (it's the place luqui copied the L::AG from)<br>[1:56pm] autrijus: i.e. UUAG/EHC<br>[1:56pm] pmichaud: indeed<br>[1:56pm] pmichaud: so, I'm just continuing on that, and will update the milestones document (again) in a day or two when the new changes are folded in<br>[1:57pm] pmichaud: leo provided some important improvements last week that enabled all of this (thanks again, leo)<br>[1:57pm] pmichaud: $<br>[1:57pm] jesse: ok. leo?<br>[1:57pm] leo:<nobr> <wbr></nobr>.local string report= &lt;&lt;"ZZ"<br>[1:58pm] leo: var-regs hit finally the trunk<br>[1:58pm] leo: all is owrking as expected<br>[1:58pm] chip: *applause*<br>[1:58pm] autrijus: *applause*<br>[1:58pm] autrijus: leo++ leo++ leo++<br>[1:58pm] Nicholas: cool<br>[1:58pm] leo: I had to rewrite tailcall argument passsing a bit<br>[1:59pm] leo: it's not quite trivial to move arge form a-&gt;b, when the register structure changed under that<br>[1:59pm] leo: currently an intermediate array holds arguments<br>[1:59pm] leo: and 2 passes are done<br>[2:00pm] leo: but the nice thing is: this is all statically known at compiletime and can be optimzed<br>[2:00pm] leo: i.e if there would be a conflict moving arguments for the sub<br>[2:00pm] leo: today I ci'ed<br>[2:01pm] leo: r9677 | leo++ | trunk:<br>[2:01pm] leo: 13:59 &lt;+svnbot6&gt; : Variable-sized reg frames 17 - no register limits<br>[2:01pm] leo:&nbsp; * enable 'spill' tests - no spilling of course:<br>[2:01pm] leo: 13:59 &lt;+svnbot6&gt;<nobr> <wbr></nobr>:&nbsp; new P60,<nobr> <wbr></nobr>.Integer&nbsp; # yeah<br>[2:01pm] leo: the PIR line is from one of the tests<br>[2:02pm] chip: cool<br>[2:02pm] leo: ZZ<br>[2:02pm] autrijus: oh I updated wikipedia "Parrot"<br>[2:02pm] autrijus: so it no longer talk about I31<br>[2:02pm] leo: great - thanks<br>[2:03pm] autrijus:<br>[2:03pm] jesse: blocking on anything, leo?<br>[2:03pm] leo: not yet - more cleanup will follow, then is release time<br>[2:03pm] leo: next week a lexical PDD would be nice<br>[2:04pm] jesse: ok. matt?<br>[2:04pm] leo: ah - I forgot one: rafl has debianized Parrot<br>[2:05pm] mdiep: jesse: again? I already went<br>[2:05pm] jesse: oops<br>[2:05pm] jesse: sorry<br>[2:05pm] jesse: chromatic?<br>[2:06pm] chromatic: Lots of little things -- Nick's patch, looking at the configure system, porting parts of Parrot::Test to PIR.<br>[2:06pm] chromatic: I was traveling last week so I didn't have much time.&nbsp; Hopefully this week will be easier.<br>[2:06pm] allison: ah, so I may not even need to mess with the library paths, nice<br>[2:06pm] chromatic: It depends on when you need them.<br>[2:06pm] allison: aye<br>[2:07pm] chromatic: At some point I would also like a sane way to write tests for PIR code (not Parrot), much like Perl 5's bootstrapping tests in t/op.<br>[2:08pm] allison: yeah, that would be good<br>[2:08pm] chromatic: As far as I see now, that's partly cultural, partly a path issue, and partly a "What are the minimum bits we can rely on to write the basic tests?"<br>[2:08pm] chromatic: Of course, it's awfully hard to test some of the libraries I've written... but I suspect we can fake out NCI at some point sometime.<br>[2:09pm] chromatic: I'll probably have more questions about library loading and initialization in the future.&nbsp; It feels somewhat incomplete yet.<br>[2:09pm] chromatic: That's about it.&nbsp; I'm blocking on time and attention span.<br>[2:10pm] jesse: ok<br>[2:10pm] jesse: who'd I miss?<br>[2:10pm] Nicholas: me<br>[2:10pm] jesse: oop<br>[2:10pm] jesse: nick. what's new?<br>[2:10pm] Nicholas: not a huge amount. Failed to get attention span.<br>[2:10pm] Nicholas: I did apply my tweaked version of chromatic's patch<br>[2:11pm] Nicholas: I've not yet gone for a dig to remove the old names in extend.c, and all the files using them in the parrot tree<br>[2:11pm] leo: Nicholas: rafl has cleared dups already<br>[2:11pm] Nicholas: Stig noticed that ponie failed to build today. For some reason now I need libparrot before libponie (to get Parrot_PMC_push_pmc) and afterwards (to give libparrot the parrot config object) so I tweaked the linker line<br>[2:11pm] Nicholas: rafl++<br>[2:12pm] Nicholas: Leo was kind enough to get 2 of the things I mentioned last week done within hours.<br>[2:12pm] Nicholas: leo__<br>[2:12pm] Nicholas: leo++<br>[2:12pm] Nicholas: oops<br>[2:12pm] leo: hashes this week<br>[2:12pm] Nicholas: but he didn't have time for the hash.c change, and I found the source code somewhat daunting to try to understand (cold), so didn't manage to find the calm time to deal with it<br>[2:12pm] Nicholas: I think that that's where I am.<br>[2:13pm] jesse: cool<br>[2:13pm] Nicholas: I seem to be mostly blocking on my ability to get into the right state of mind. Plus work scheduling is not idea - in theory as soon as something I'm blocking on on the staging evironment unblocks, I need to deal with my part of it (at high priority). And I find that unsettles me<br>[2:14pm] Nicholas: I think that's it.<br>[2:15pm] jesse: less cool<br>[2:15pm] jesse: anything else? questions?<br>[2:16pm] Nicholas: Yes. I don't have a good idea of how much time I have, and I find that if I'm not sure i've got 'large wooly amount of time' I don't want to start. Happened this morning where I (deliberately) got up at DST time, and then found that I couldn't really use the extra hour. I might as well go into work, and get the commuting disturbance out of the way.<br>[2:16pm] chip: I have an interface question to float (PIR and lexicals)<br>[2:17pm] chip: (n/m I thought he meant for everyone)<br>[2:17pm] Nicholas: so did I<br>[2:17pm] chip: Nicholas: I'm finding the trick to be relaxing a little.&nbsp; Go into Pogo mode<br>[2:17pm] jesse: Idid<br>[2:17pm] jesse: sorry.<br>[2:18pm] jesse: go for it chip<br>[2:18pm] Nicholas: Pogo mode?<br>[2:18pm] chip: "Don't take {life,Ponie} so serious.&nbsp; It ain't nohow permanent."<br>[2:18pm] chip: is all PIR going to be associated with a registered HLL?<br>[2:18pm] &amp;#8226; chip supposes the answer is 'no'<br>[2:18pm] allison: no<br>[2:19pm] allison: (that is, confirmed, the answer is 'no')<br>[2:19pm] leo: no registered HLL means native parrot semantics I presume<br>[2:19pm] chip: and so lexical policies can be defaulted by HLL, but not tied exclusively to it.&nbsp; Right.<br>[2:19pm] chromatic: A LexPad PMC for each HLL?<br>[2:20pm] chip: chromatic: it seemed a convenient place to put the default, if there was to be one.&nbsp; Yes<br>[2:20pm] leo: it's like a TclInteger which is different<br>[2:20pm] jesse: I need to actually pay full attention to something else<br>[2:20pm] jesse: thanks everybody. I'll grab logs a bit later.<br>[2:20pm] jesse: sorry to have to bail.<br>[2:20pm] jesse: keep asking questions<br>[2:20pm] chip: cya<br>[2:20pm] leo: thanks jesse<br>[2:20pm] Nicholas: thanks jesse<br>[2:21pm] chip: [ditto]<br>[2:21pm] autrijus: thanks<br>[2:22pm] chip: The only complication (such as it is) is that I'd _prefer_ not to have to create a new FooPad PMC for languages where the pad is just a Hash (e.g. Tcl).&nbsp; But it seems I'm going to have to do so, if only so the init methods can be unfiied<br>[2:22pm] chip: unified<br>[2:22pm] chip: in their interface, that is.<br>[2:22pm] chip: See, a Perl6LexPad init method will need to know the Sub it's from, so it can find the key/value pairs.&nbsp; But a Tcl pad can just be a Hash<nobr> <wbr></nobr>... but a plain old Hash init method doesn't expect to find a Sub parameter.<br>[2:23pm] chip: And the naive<br>[2:23pm] chip: "add a level of indirection" solution starts to look bad when it's happening on every function entry.&nbsp; But some optimizations can wait.<br>[2:23pm] leo: I think there will be still a FooPad, and if it's just for it's type name<br>[2:24pm] leo: (if a FooPad is needed of course)<br>[2:24pm] chip: you mean, all pads being named *Pad is a good thing, even if their implementations are thin?<br>[2:24pm] leo: like a TclFloat which afaiks inherits all from Float<br>[2:25pm] chip: ah, now I see what you meant.<br>[2:25pm] chip: That's a good argument, thanks<br>[2:25pm] chip: EOQ<br>[2:25pm] chromatic: Sometimes names aren't just names.<br>[2:25pm] chip: that's what my Mom said when she named me "Stinky"<br>[2:26pm] chip:<nobr> <wbr></nobr>... so, who's up next?&nbsp; questions?&nbsp; anyone?<br>[2:26pm] chip: Bueller?<br>[2:26pm] &amp;#8226; autrijus ponders Float::Tcl<br>[2:26pm] allison: Question: should I just put the tree transformation stuff in the Parrot repository?<br>[2:26pm] chromatic: Is there still an event system/<br>[2:26pm] autrijus: &lt;/bikeshed&gt;<br>[2:26pm] autrijus: allison: now I've discovered svn.lohutok.net I'll point people to it if you don't commit them to parrot tree<br>[2:27pm] autrijus: so to reduce your server load, committing them is probably wise *smile*<br>[2:27pm] allison: Putting it in parrot is the simplest way to solve my immediate problem with library paths so I can write tests.<br>[2:27pm] leo: allison: I think it's as core as PGE is, so yes<br>[2:27pm] allison: It will still change radically over the next month or two, which is why I hesitate, but it is at least useful now.<br>[2:27pm] pmichaud: allison: I vote yes<br>[2:27pm] pmichaud: allison:&nbsp; it's okay if it changes radically -- PGE has done the same<br>[2:27pm] allison: then where? compilers/tte? (Tree Transformation Engine)<br>[2:27pm] allison: (Resisting the urge for a Psittacus joke: Parrot Standardized Interface for Tree Transformations: Abstract, Concrete, and Unnecessarily Silly...<br>[2:27pm] chip: allison: I wouldn't do it if that's the reason.&nbsp; But don't hesitate to show work in progress.&nbsp; And any API changes are liekly to get automagically fixed in your code if it's in svn<br>[2:27pm] leo: allison: all is changing more or less - ci early ci often<br>[2:28pm] autrijus: allison: comptools.pod too<br>[2:28pm] allison: autrijus: okay &lt;sheepish look&gt;<br>[2:28pm] pmichaud: compilers/tte works for me, although I've been thinking that some prototyped tools can start out in examples/ and then move to their proper location when they become less "example-ish" and more "developed-ish"<br>[2:28pm] chip: allison: Never miss a chance to give in to temptation<br>[2:29pm] autrijus: pmichaud: er but languages/* is all prototypes anyway<br>[2:29pm] autrijus: s/all/mostly/<br>[2:29pm] autrijus: so why should compilers/ differ?<br>[2:29pm] pmichaud: autrijus: I don't disagree<br>[2:29pm] autrijus: maybe a COMPILERS file?<br>[2:29pm] autrijus: er<nobr> <wbr></nobr>.STATUS<br>[2:29pm] autrijus: same style as LANGUAGES.STATUS<br>[2:30pm] allison: okay, how's this: I'll push it to the point that it's transforming PGE trees, then check it in as compilers/tte<br>[2:30pm] leo: pmichaud: can you ci the 'newsub' removal code? I'll drop that opcode very likely tomorrow<br>[2:30pm] autrijus: I'd still rather you just commit it -- if only for my sanity of not chasing more svk mirrors<br>[2:30pm] pmichaud: leo:&nbsp; My new version drops 'newsub' -- it should be ci'd in a few hours -- as soon as I can finish debugging tests<br>[2:30pm] leo: great - thanks<br>[2:31pm] allison: EOQ<br>[2:32pm] &amp;#8226; leo is seeing forward allison increasing her purl karma by a steady flow of svnbot6 reports<br>[2:32pm] autrijus: yes, go for the karma<br>[2:33pm] allison: lol<br>[2:34pm] autrijus:<nobr> <wbr></nobr>...and I just mentioned svn.lohutok.net's existence on #perl6<br>[2:34pm] autrijus: (to integral, who has been dying to see them)<br>[2:34pm] allison: I'm just about to post a journal entry I've been writing during the irc session too<br>[2:34pm] autrijus: woot<br>[2:35pm] autrijus: allison++<br>[2:35pm] leo: chip: I small (and premature) lexical Q: are we doing new<nobr> <wbr></nobr>.Undef the lexicals?<br>[2:37pm] chip: ah.<br>[2:39pm] chip: I was planning not.&nbsp; I was planning that they'd be null PMCs on creation.&nbsp; (Though a customized Pad could of course do something else)<br>[2:39pm] leo: okie - PMCNULL is fine<br>[2:39pm] leo: (for me)<br>[2:39pm] pmichaud: I think I prefer pmcnull<br>[2:39pm] chip: Reason being, I imagine that the PMC being null could be a convention that the given variable is out of scope<br>[2:40pm] chip: consider&nbsp; &nbsp; sub foo { eval '$x'; my $x }<br>[2:40pm] leo: or used unitialized - that's the perl5 runtime thingy w/o strict afaik<br>[2:41pm] chip: Hm, I think that's a kind of<nobr> <wbr></nobr>.Undef<br>[2:41pm] chip: but anyway, null is easier &amp; seems OK<br>[2:41pm] chip: (&amp;faster)<br>[2:41pm] leo: you can assign to<nobr> <wbr></nobr>.Undef, doing that with<nobr> <wbr></nobr>.Null throws an exception<br>[2:42pm] chip: yeah, that was my point -&nbsp; sub foo { eval '$x = 1'; my $x }&nbsp; should throw<br>[2:42pm] leo: (but that's just a matter of an appropriate exception handler - I'm still for<nobr> <wbr></nobr>.Null)<br>[2:42pm] chip: }<nobr> <wbr></nobr>// answer<br>[2:43pm] leo: thanks<br>[2:45pm] chip: allison: are you the new boss, even though you're the old boss?<br>[2:45pm] chip: seems like we're kind of done<br>[2:45pm] allison: chip: okay, we're done<br>[2:45pm] allison: Yeah, I<br>[2:45pm] allison: I'm working my way out of boss duties<br>[2:45pm] chip: I'll adjourn to #parrot then<br>[2:45pm] chip: thanks all<br>[2:46pm] leo: bye all<br>[2:46pm] leo left the chat room.<br>[2:46pm] chromatic left the chat room. (Quit: Leaving)<br>[2:46pm] pmichaud left the chat room.<br>[2:47pm] autrijus: bye<br>[2:47pm] autrijus left the chat room.<br>[3:11pm] allison left the chat room. (Quit: Leaving)<br>[6:33pm] mdiep left the chat room. (Quit: mdiep)</tt> jesse 2005-10-31T23:58:17+00:00 journal Parrot Sketch 26 Oct 2005 (since the logbot is down) http://use.perl.org/~jesse/journal/27393?from=rss <tt>13:52 -!- leo [~lt@feather.perl6.nl] has joined #parrotsketch<br>14:01 &lt;Nicholas&gt; The hour is upon us<br>14:01 &lt;chip&gt; meatspace meating will take me away for first 5min or so, sry<br>14:01 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has joined #parrotsketch<br>14:03 -!- chromatic [~chromatic@nat-147-140.oreilly.com] has joined #parrotsketch<br>14:03 &lt;chromatic&gt; Apologies for the delay.<br>14:03 &lt;chromatic&gt; Shall we start?<br>14:03 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has joined #parrotsketch<br>14:03 &lt;pmichaud&gt; okay with me<nobr> <wbr></nobr>:-)<br>14:04 &lt;chromatic&gt; Autrijus, what have you been doing this week?<br>14:05 &lt;chip&gt; (present)<br>14:05 &lt;chromatic&gt; Okay, chip you go then!<br>14:06 &lt;chip&gt; OK then<br>14:07 &lt;chip&gt; I've unconscionably delayed the lexical spec, but the good news is that having learned a lot about what's<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;known about lexicals (and, separately, about Tcl variables *rimshot*), I've planned the points of inflection<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;required to support p6 and tcl both<br>14:08 &lt;chip&gt; So it'll be better when it finally emerges<br>14:09 &lt;chromatic&gt; What's blocking you this week?<br>14:09 &lt;chip&gt; And I've looked over matt's namspace spec and found it a good direction, albeit with some false notes<br>14:09 &lt;chip&gt; (but I'll let him talk further if he likes)<br>14:09 &lt;chip&gt; EOT<br>14:10 &lt;chromatic&gt; What's blocking you this week?<br>14:10 &lt;chip&gt; blocking this week?<nobr> <wbr></nobr>.... nothing external<nobr> <wbr></nobr>:/<br>14:10 &lt;chip&gt; time is all.&nbsp; Oh, and<br>14:11 &lt;chip&gt;<nobr> <wbr></nobr>... meatspace friends regaining patience with seeing me having a laptop on my lap<nobr> <wbr></nobr>:-<br>14:11 &lt;chip&gt;<nobr> <wbr></nobr>:-)<br>14:11 &lt;chip&gt; EOT2<br>14:11 &lt;chromatic&gt; Thanks, chip.&nbsp; Leo?<br>14:11 &lt;leo&gt; - continued variable-sized register frame patches<br>14:12 &lt;leo&gt; - almost done, OTOH amd64 behaves strangely, can't gdb it yet (no bt,<nobr> <wbr></nobr>...)<br>14:12 &lt;leo&gt;&nbsp; &nbsp;(I've to chat with ^conner - it's his machine where I'm testing amd64)<br>14:12 &lt;leo&gt; - recent stuff isn't checked in yet because of a few test failures on ppc<br>14:12 &lt;leo&gt; - spent the weekend in Budapest/Hungary, nice Perl workshop<br>14:12 &lt;leo&gt; - talked with Larry about magic pairs, junctions and possible implications<br>14:12 &lt;leo&gt;&nbsp; &nbsp;e.g. with respect to MMD<br>14:12 &lt;leo&gt;&nbsp; &nbsp;(runtime param binding due to named arguments can currently cause MMD<br>14:12 &lt;leo&gt;&nbsp; &nbsp; redispatch,<nobr> <wbr></nobr>...)<br>14:13 &lt;leo&gt; - fixed a nasty x86/JIT bug in mandel.pir, where due to 80-bit precision<br>14:13 &lt;leo&gt;&nbsp; &nbsp;(caused by keeping intermediates in the x86 FP regstack) wrong 'pixels'<br>14:13 &lt;leo&gt;&nbsp; &nbsp;were calculated see also: $ svn log -v -r 9514<br>14:13 &lt;leo&gt;&nbsp; &nbsp;4 actual patch lines (+ comments, test) done in 8 hrs<nobr> <wbr></nobr>:-(<br>14:13 &lt;leo&gt;<nobr> <wbr></nobr>:wq<br>14:14 &lt;chromatic&gt; What's blocking you this week?<br>14:14 &lt;leo&gt; nothing parrot related<br>14:14 &lt;chromatic&gt; Thanks, Leo.&nbsp; Matt?<br>14:15 &lt;mdiep&gt; spent some time this week waiting for chip to give me feedback on my namespace spec<br>14:15&nbsp; * chip whistles<br>14:16 &lt;mdiep&gt; he's getting back to me now, so I shouldn't be blocking on that any longer<br>14:16 &lt;mdiep&gt; there are also a few points I haven't fully considered<br>14:17 &lt;mdiep&gt; (namespaces are also variables in python)<br>14:17 &lt;mdiep&gt; but I think I'm headed in the right direction<br>14:17 &lt;mdiep&gt; tcl still has failures - some from unimplemented unicode functions<br>14:17 &lt;mdiep&gt; others from lexical pad issues<br>14:18 &lt;mdiep&gt; I'm hoping to come up with a fix for the latter, but it means understand all the changes that coke has made<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; and understanding the current lexical pad implementation<br>14:18 &lt;mdiep&gt; so the new lexical pad implementation and unimplemented unicode functions are blocking<br>14:18 &lt;mdiep&gt; ^D<br>14:19 &lt;chromatic&gt; Thanks, Matt.&nbsp; Is that all that's blocking you?<br>14:19 &lt;mdiep&gt; yes<br>14:20 &lt;chromatic&gt; Great.&nbsp; Nicholas?<br>14:20 &lt;Nicholas&gt; I got less done last week than I hoped. (basically nothing after Monday) because $work's $work consumed<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;more of my time and energy than I initially suspected<br>14:20 &lt;Nicholas&gt; things might be different this week. however<br>14:21 &lt;Nicholas&gt; I tried out your patch for auto-generating extend.c, and mailed an improved version back to the list, but<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;to date I don't think that anyone has commented. They're not *all* writing books, are they?<br>14:21 &lt;Nicholas&gt; and I got some today, but have hit a question about parrot hashes for Chip and Leo that might want to wait<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;until a questions section.<br>14:21 &lt;Nicholas&gt; If so, that's it<br>14:22 &lt;chromatic&gt; What's blocking you?<br>14:22 &lt;Nicholas&gt; well<br>14:22 &lt;Nicholas&gt; 1: answer to today's question<br>14:22 &lt;Nicholas&gt; 2: figuring out how hash iterators work from the C API level, as the docs are thin.<br>14:22 &lt;Nicholas&gt; (that's just brute force work on my part I think)<br>14:22 &lt;Nicholas&gt; indireectly<br>14:23 &lt;Nicholas&gt; 1: I'd hoped that someone would take your patch further<br>14:23 &lt;Nicholas&gt; 2: last week Chip intimated that my question about events and parrot currently grabbing SIGHUP had an easy<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;interim solution, but I don't remember any further comment on that solution<br>14:23 &lt;Nicholas&gt; and<br>14:24 &lt;Nicholas&gt; 3: longer term, I'm wondering about how parrot will do threading, and how long it will to take to get<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;right, as ponie will have to implement/emulate ithreads and ithread cloning atop it<br>14:24 &lt;Nicholas&gt; oh, and I had some other design questions that are in the queue<br>14:24 &lt;Nicholas&gt; so, I think that's it. Nothing short term. But medium term things are not getting resolved<br>14:24 &lt;Nicholas&gt; oops, nothing external short term.<br>14:25 &lt;chromatic&gt; Okay, thanks Nicholas.&nbsp; I don't know if Jesse's here, so Patrick?<br>14:25 &lt;pmichaud&gt; &lt;&lt;EOT<br>14:25 &lt;pmichaud&gt; I'm continuing to forge ahead on the shift/reduce parser<br>14:25 &lt;pmichaud&gt; I finally found a PIR interface that I think I can live with<br>14:26 &lt;pmichaud&gt; and I'm getting the parser to handle significant whitespace issues<br>14:26 &lt;pmichaud&gt; after finishing that I'll be updating the PGE milestones document<br>14:26 &lt;pmichaud&gt; I expect to have all of that done by Wednesday<br>14:26 &lt;pmichaud&gt; I'm only blocking on time+energy at the moment<br>14:27 &lt;pmichaud&gt; I'm a little apprehensive about upcoming changes to the<nobr> <wbr></nobr>:w flag in p6 rules, but will deal with whatever<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;comes from the language side of things<br>14:27 &lt;pmichaud&gt; EOT<br>14:27 &lt;chromatic&gt; Thanks, Patrick.&nbsp; Is Autrijus or Jesse here to report?<br>14:27 &lt;chromatic&gt; I have nothing to report; I had a lot of distractions last week, but hope to review Nicholas' comments on<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; my patch in the next day or two.<br>14:28 &lt;chromatic&gt; Okay, let's move on to questions.&nbsp; Chip had one for Leo.<br>14:30 &lt;chip&gt; leo: argument pairs<br>14:30 &lt;leo&gt; yes?<br>14:30&nbsp; * pmichaud may have the same question as chip<br>14:30 &lt;chip&gt; leo: last I heard from autrijus, all named parameter pairs can be known to _be_ named argument pairs at<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;compile time.&nbsp; Obvoiusly the key values may not be known until runtime.&nbsp; This is true?<br>14:31 &lt;chip&gt; (In other words, it's isomorphic to the Python named param model)<br>14:31 &lt;leo&gt; I think so, yes<br>14:32 &lt;chip&gt; &lt;burns&gt; Eeexcelent. &lt;/burns&gt;&nbsp; That's it for now<br>14:32 &lt;chip&gt; (Modifying the calling convention to support that is eminently doable, but isn't blocking anyone AFAIK.)<br>14:32 &lt;chip&gt; chromatic: I'm good<br>14:33 &lt;chromatic&gt; Nicholas also had a question.<br>14:33 &lt;leo&gt; chip: first we need lexicals anyway then we can bind named args<br>14:33 &lt;chip&gt; quite.&nbsp; can't assign by name without names.<br>14:34 &lt;leo&gt; wrt Nicholas' Qs:<br>14:34 &lt;leo&gt; 1 [extend.c]<br>14:34 &lt;leo&gt; if it works, just commit it<br>14:34 &lt;leo&gt; I don't use extend.c<nobr> <wbr></nobr>;-)<br>14:34&nbsp; * chip concurs on extend patch, having read the mail<br>14:35 &lt;Nicholas&gt; no, there was more than that. including a quesiton about whether/how to remove the old names for some of<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the APIs<br>14:35 &lt;leo&gt; chip?<br>14:35 &lt;Nicholas&gt; it works, but as is it's still a bodge<br>14:35 &lt;chip&gt; Oh.<br>14:35 &lt;Nicholas&gt; and I have no good idea how many external bits of code are relying on those API names. Or even a good way<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;to find/test anything live inside the parrot source tree<br>14:35 &lt;chip&gt; Policy is as Linus:<br>14:36 &lt;chip&gt; When you change an API, it's your responsibility to see to it that consumers of the API are fixed<nobr> <wbr></nobr>... as long<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;as they're in the same source control tree.<br>14:36 &lt;chip&gt; Out-of-tree projects fend for themselves.<br>14:36 &lt;chip&gt; I'll mail to p6i on that now<br>14:36 &lt;Nicholas&gt; OK<br>14:37 &lt;Nicholas&gt; Timing wise parrot hacking proves problematic for me, in that the ponie project timescales were envistaged<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;based on not needing to work on parrot, and I think that we got 'em wrong - ponie is bigger than we<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;estimated.<br>14:37 &lt;leo&gt; my POV: patch it, 'make test', if ok mail to p6i and ci<br>14:37 &lt;Nicholas&gt; So having to do any parrot hacking is<br>14:37 &lt;Nicholas&gt; a: it's eating into ponie's time budget<br>14:38 &lt;Nicholas&gt; b: "my brain hurts" - there's already rather too much I'm trying too keep in it at once, and having to<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;also implement bits of parrot that I need just makes the job longer, and hurts my morale<br>14:38 &lt;leo&gt; ok fair enough<br>14:38 &lt;Nicholas&gt; so whilst in theory I can work on parrot, in practice it will kill ponie<br>14:39 &lt;leo&gt; I think extend.c is a bit different, as ponie is using it I presume heavily<br>14:39 &lt;Nicholas&gt; it's using parts. but it finds more parts that it needs. it's trail blazing there<br>14:39 &lt;chromatic&gt; We have source control.&nbsp; If the patch breaks things on some platforms, won't we get test results?<br>14:40 &lt;Nicholas&gt; because ponie is coming at parrot from a totally odd direction, compared with all the bytecode using<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;projects<br>14:40 &lt;leo&gt; testing extend is a bit tedious, as a) there are just a few extend tests b) ther may be a lot of code outside<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; our tree<br>14:41 &lt;Nicholas&gt; I'm not convinced that make test ran tests on everything in our tree, but I've not checked<br>14:42 &lt;chromatic&gt; Patrick also had a question.<br>14:43 &lt;Nicholas&gt; I actually haven't asked mine yet<nobr> <wbr></nobr>:-)<br>14:43 &lt;leo&gt; Nicholas: the extend code are very thin wrappers around vtables, not much can break there<br>14:43 &lt;pmichaud&gt; I think my question was answered by chip+leo's exchange, which was about named argument handling in<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;parrot.&nbsp; I see what the plan is, like it, and don't have a pressing need for it<br>14:43 &lt;Nicholas&gt; it's changing the names of the wrapper functions that will break things. fortunately at link time I think.<br>14:43 &lt;pmichaud&gt; I was just curious about how it would work and eta to implementation so that I could perhaps take<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;advantage of it from pge.&nbsp; But I'll wait on it for now.<br>14:44 &lt;chip&gt; (afk 5min sry)<br>14:44 &lt;leo&gt; Nicholas: just keep the old interfaces for a while then<br>14:44 &lt;pmichaud&gt; eoq<br>14:45 &lt;chromatic&gt; Alright.&nbsp; Anything else?<br>14:45 &lt;Nicholas&gt; my quesiton was about the parrot hash code<br>14:45 &lt;leo&gt; I got some more answers for nich<br>14:45 &lt;leo&gt; 2 [hash iter from C]<br>14:45 &lt;leo&gt; seems to be untested and underdoced<br>14:46 &lt;leo&gt; but straight forward: it's tested from pasm/pir<br>14:46 &lt;Nicholas&gt; I could see iterator.pod whcih gave a PASM interface<br>14:46 &lt;leo&gt; just run the vtables which are called from PASM<br>14:46 &lt;Nicholas&gt; but digging briefly into iterator.pmc, I saw that it actually uses VTABLE methods on key.pmc to get the<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;next key<br>14:46 &lt;leo&gt; yes<br>14:47 &lt;Nicholas&gt; so I wondered if I could skip having an interator PMC and manipulate the key directly<br>14:47 &lt;leo&gt; the Key holds the state for iteration<br>14:47 &lt;Nicholas&gt; so if I can create a key that is at the start, I only need it to move through the hash?<br>14:47 &lt;leo&gt; I can put together a t/src/hash.t that iters over a hash<br>14:48 &lt;Nicholas&gt; that would be useful, if you can do that easily, beacuse that would make it easier for me to translate to C<br>14:49 &lt;leo&gt; that would be C already - you probably need translation to extend.c only<br>14:49 &lt;Nicholas&gt; ah right<br>14:49 &lt;leo&gt; 3 [sighup]<br>14:49 &lt;leo&gt; I'll disable it RSn<br>14:49 &lt;Nicholas&gt; great<br>14:49 &lt;Nicholas&gt; thanks<br>14:49 &lt;chip&gt; (back)<br>14:49 &lt;leo&gt; 4 [threads] too early to ask<nobr> <wbr></nobr>;-)<br>14:49 &lt;Nicholas&gt;<nobr> <wbr></nobr>:-(<br>14:49 &lt;Nicholas&gt; that's what I feared<br>14:50 &lt;leo&gt; a ParrotThread isa ParrotInterpreter<br>14:50 &lt;leo&gt; which is created by ParrotThread.clone of an interpreter<br>14:50 &lt;Nicholas&gt; but they are evil and pervade everything, hence why the sooner we get the the prototype, the sooner we can<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;throw it away and make the real thing<nobr> <wbr></nobr>:-)<br>14:51 &lt;Nicholas&gt; it's the cloning that's the faff I'm scared of. Threads running are steady state<br>14:51 &lt;Nicholas&gt; and only the ithreads threads::shared needs replacing, and it's a bit pants currently, so whatever<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;replaces it will probably actually be an improvement<br>14:51 &lt;leo&gt; the problem currently is that we don't have shared PMCs (except TQueue)<br>14:52 &lt;Nicholas&gt; mmm, shared PMCs. and shared GC.<br>14:52 &lt;Nicholas&gt; eek.<br>14:52 &lt;chip&gt; is cloning actually necessary?<br>14:52 &lt;leo&gt; shared PMCs need some vtable tweaking<br>14:52&nbsp; * chip would prefer a spawn model for threads, rather than a fork model<br>14:52 &lt;Nicholas&gt; I can't see how cloning can be avoided to correctly implement 5.8.x ithread semantics<br>14:53 &lt;chip&gt; brute force, then?&nbsp; iterate through all namespaces looking for an honest man^W^W^Wshared PMCs?<br>14:54 &lt;leo&gt; no<br>14:54 &lt;Nicholas&gt; it's just the details. the devil being in the details. and how to replace all the clone code from the<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bottom of sv.c with something that does PMCs<br>14:55 &lt;Nicholas&gt; [and I've still not asked my question about hases]<br>14:55 &lt;chip&gt; Nicholas: In short we can't answer it yet.&nbsp; But you have added a use case<br>14:55 &lt;chip&gt; (use cases.&nbsp; slowly I turn...)<br>14:56&nbsp; * chip suggests moving on to the answerable<br>14:56 &lt;Nicholas&gt;<nobr> <wbr></nobr>:-)<br>14:56 &lt;Nicholas&gt; OK. Leo kindly wrote an address registry PMC. and I used it.<br>14:56 &lt;Nicholas&gt; And then I noticed that I already had a hash implenmeted using the itreads ptr_table code to track all<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;SVs, as step 1 of eliminating arenas<br>14:57 &lt;Nicholas&gt; and I thought "this duplicates the address registry. If I can iterate over the address registery, I can<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;kill this ptr_table hash"<br>14:57 &lt;Nicholas&gt; and then I realised/remembed the pain it copes with<br>14:57 &lt;Nicholas&gt; sv.c wants to iterate over all remaining SVs<br>14:57 &lt;Nicholas&gt; and "do stuff" to them.<br>14:57 &lt;Nicholas&gt; if you're going to meet SVs A and B in that ortder during iteration<br>14:57 &lt;Nicholas&gt; the fun comes because<br>14:58 &lt;Nicholas&gt; you can process A, which can cause B to be deleted<br>14:58 &lt;Nicholas&gt; alternatively, processing A can add more SVs, by creating new ones<br>14:58 &lt;Nicholas&gt; so the ptr_table hash code had to be hacked about until it could cope with<br>14:58 &lt;Nicholas&gt; 1: things being deleted mid iteration<br>14:58 &lt;Nicholas&gt; 2: things being added mid iteration. (it doesn't actually matter if you meet them during the iteration)<br>14:59 &lt;Nicholas&gt; IIRC, Leo said that the current src/hash.c implementation can cope with things being deleted mid iteration<br>14:59 &lt;leo&gt; yes<br>14:59 &lt;Nicholas&gt; but before I try to work out from understanidn the source<br>14:59 &lt;Nicholas&gt; can it cope with things being added?<br>14:59 &lt;leo&gt; that depends<br>14:59 &lt;Nicholas&gt; and secondly, is this an "implementation side effect", or is either/both the deletion/addition stuff<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;guaranteed in its "spec"<br>14:59 &lt;leo&gt; you probably want to see these PMCs later in iteration?<br>15:00 &lt;Nicholas&gt; I don't mind if I don't see the added PMCs<br>15:00 &lt;leo&gt; then iteration should still work<br>15:00 &lt;Nicholas&gt; because the existing perl 5 SV iteration code had no idea if it was going to meet newly created PMCs<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;immediately<br>15:00 &lt;Nicholas&gt; I can add to a hash mid iteration, and still see all the keys that were in it before I started iterating?<br>15:01 &lt;Nicholas&gt; [I don't mind it being unspecified whether I see keys I added mid-iteration]<br>15:01 &lt;leo&gt; untested but I thimk yes<br>15:01 &lt;Nicholas&gt; [I do mind that I mustn't "see" keys that I delete prior to reaching them]<br>15:01 &lt;leo&gt; think even<br>15:01 &lt;Nicholas&gt; but I faked that in ptr_table by replacing keys with NULL, and then running a cleanup afterwards to<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;actually delete the NULLs<br>15:02 &lt;Nicholas&gt; does the hash do a "split" if it gets full buckets?<br>15:02 &lt;leo&gt; that's not necessary with parrot hashes as the bucket storeage is inside the hash and not malloced<br>15:03 &lt;Nicholas&gt; ponie has this:<br>15:03 &lt;Nicholas&gt;&nbsp; &nbsp; &nbsp;if (!empty &amp;&amp; tbl-&gt;tbl_items &gt; tbl-&gt;tbl_max &amp;&amp; !tbl-&gt;iteration_nesting)<br>15:03 &lt;Nicholas&gt; Iptr_table_split(tbl);<br>15:03 &lt;Nicholas&gt; where !tbl-&gt;iteration_nesting is the check to disable any split mid-iteration<br>15:03 &lt;leo&gt; if it's getting full it resizes, bucket storage is expanded and bucket pointers are recalced<br>15:03 &lt;pmichaud&gt; (gotta run, see you all next week)<br>15:03 &lt;Nicholas&gt; but an iterator would still be valid across that resize?<br>15:04 &lt;leo&gt; I think so yes<br>15:04 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has left #parrotsketch []<br>15:04 &lt;chip&gt; even if hte iterator is valid, the list of 'future' notes changes with the resize, I should think<br>15:04 &lt;Nicholas&gt; OK. Good. It's not so in perl5, either in hv.c or the ptr_table code before I bodged it<br>15:04 &lt;chip&gt; so some nodes will no longer be visited<br>15:04 &lt;Nicholas&gt; gah. that's not going to suit me. need to visit everything that I started with<br>15:04 &lt;chip&gt; I suspect you'll want to swap hashes.&nbsp; Union hash, so to speak<br>15:04 &lt;Nicholas&gt; yes.<nobr> <wbr></nobr>:-(<br>15:05 &lt;Nicholas&gt; I was starting to think that I'd need a second hash of "things I added"<br>15:05 &lt;Nicholas&gt; union the two during the iteration<br>15:05 &lt;Nicholas&gt; merge it in afterwards<br>15:05 &lt;chip&gt; seems so<br>15:05 &lt;leo&gt; not necssarily<br>15:05 &lt;Nicholas&gt; if chip's answer is "the answer", then that's OK.<br>15:06 &lt;Nicholas&gt; I know that I need to do the work. Rather than wondering<br>15:06 &lt;leo&gt; if delete puts in a DELETED_pmc, all added pmcs go to the end and wil be seen<br>15:06 &lt;Nicholas&gt; I don't mind if the added PMCs don't get seen<br>15:06 &lt;leo&gt; but a few tests can easily verify how it works<br>15:06 &lt;Nicholas&gt; but I do mind if a resize causes some PMCs not to be seen<br>15:06 &lt;chip&gt; leo, it's growth making preexisting entries rearrange to behind the iterator that's the problem<br>15:06 &lt;leo&gt; as said, resize shouldn't cause any problems<br>15:07 &lt;chip&gt; having seen A and B but not C, adding D can put C behind the iterator when it used to be ahead, so C will not<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;be visited.<br>15:07 &lt;leo&gt; not as far as I know<br>15:07 &lt;chip&gt; but the buckets get recalculated.<br>15:07 &lt;leo&gt; bucket pointers<br>15:07 &lt;chip&gt; oh well.&nbsp; I haven't read the code.<br>15:08 &lt;chip&gt; just working on first principels<br>15:08&nbsp; * chip bows out<br>15:08 &lt;chromatic&gt; I need to take off in a few minutes.<br>15:08 &lt;Nicholas&gt; I prefer to understand the code. As my ability to write evil controlled tests is far less than the ability<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of the perl regression tests to throw up unpredictable corner cases that I never envisaged a test for, and<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;so spend some hours (or days)(or weeks once) head scratching<br>15:08 &lt;chromatic&gt; Is there anything else?<br>15:08 &lt;leo&gt;&nbsp; &nbsp; for (b = hash-&gt;bu.bs-i-1; i &lt; (INTVAL)N_BUCKETS(hash-&gt;mask + 1); ++i, --b)<br>15:08 &lt;Nicholas&gt; chip,leo: thanks<br>15:08 &lt;leo&gt; that runs through the bucket store<br>15:09 &lt;chromatic&gt; Leo, can you add tests for that to the iteration tests in hash.t you mentioned earlier?<br>15:09 &lt;leo&gt; yup, I'll do<br>15:09 &lt;chromatic&gt; Chip had another question, though I'm not sure it was a public one.<br>15:09 &lt;chip&gt; chromatic: not Parrot-related<br>15:10 &lt;chromatic&gt; Go ahead.<br>15:10 &lt;chip&gt; er, I meant, not for this channel.&nbsp; I was just wanting you not to run off post-meeting<br>15:10 &lt;chip&gt; until I could ask it<br>15:10 &lt;chip&gt; sry<br>15:10 &lt;chromatic&gt; Ah okay.<br>15:10 &lt;chromatic&gt; I'll send out logs in a little bit.&nbsp; Thank you all.<br>15:11 &lt;Nicholas&gt; given that our logbot isn't here, who will grab the log?<br>15:11 &lt;chromatic&gt; I'm saving it now.<br>15:11 &lt;Nicholas&gt; and was our logbot on london.irc.perl.org? if so, that would explain its absense<br>15:11 &lt;Nicholas&gt; er, absence.<br>15:12 &lt;chromatic&gt; Perhaps irc.perl.org.<br>15:12 &lt;chip&gt; thanks chromatic<br>15:12 &lt;leo&gt; thanks too<br>15:12 &lt;Nicholas&gt; thanks<br>15:14 -!- chromatic [~chromatic@nat-147-140.oreilly.com] has quit [Quit: meeting]<br></tt> jesse 2005-10-31T18:25:51+00:00 journal Syntax http://use.perl.org/~jesse/journal/27103?from=rss <tt>For quite a while, my co-conspirators and I have been bouncing around better syntax for DBIx::SearchBuilder, the object-relational mapper RT's built on.&nbsp; We eventually decided to take the plunge and fork it into Jifty::DBI -- a new tool to do the same thing, just better.<br><br>One of the things that we've spent a fair bit of time on is the syntax for declaring your schema in perl. From this syntax, we can generate a table in the database, viewy bits in our web toolkit (you'll be hearing more about that later), accessors, validators and even automatically upgrade the database schema if you're starting from an older version. A quick copy-and-paste example from some code we're working on is below.<br><br>And no, this doesn't use any source filters.<br><br>package BTDT::Model::Task::Schema;<br>use Jifty::DBI::Schema;<br>use BTDT::Model::TaskTagCollection;<br><br>column complete =&gt;<br>&nbsp; type is 'boolean',<br>&nbsp; default is 'false',<br>&nbsp; since '0.1.1',<br>&nbsp; label is 'Done';<br><br>column summary =&gt;<br>&nbsp; type is 'varchar',<br>&nbsp; label is 'Task',<br>&nbsp; hints is '(Example: &lt;i&gt;Pick up milk at the store&lt;/i&gt;)';<br><br>column description =&gt;<br>&nbsp; type is 'text',<br>&nbsp; render_as 'Textarea',<br>&nbsp; label is 'Details';<br><br>column owner_id =&gt;<br>&nbsp; refers_to BTDT::Model::User,<br>&nbsp; label is 'Owner',<br>&nbsp; render_as 'Combobox';<br><br>column starts =&gt;<br>&nbsp; type is 'date',<br>&nbsp; render_as 'Date',<br>&nbsp; label 'Defer until';<br><br>column due =&gt;<br>&nbsp; type is 'date',<br>&nbsp; render_as 'Date',<br>&nbsp; label is 'Date due';<br><br>column priority =&gt;<br>&nbsp; type is 'integer',<br>&nbsp; since '0.2.11',<br>&nbsp; default is 3,<br>&nbsp; label is 'Priority',<br>&nbsp; valid_values are<br>&nbsp; &nbsp; { display =&gt; 'highest', value =&gt; 5 },<br>&nbsp; &nbsp; { display =&gt; 'high',&nbsp; &nbsp; value =&gt; 4 },<br>&nbsp; &nbsp; { display =&gt; 'normal',&nbsp; value =&gt; 3 },<br>&nbsp; &nbsp; { display =&gt; 'low',&nbsp; &nbsp; &nbsp;value =&gt; 2 },<br>&nbsp; &nbsp; { display =&gt; 'lowest',&nbsp; value =&gt; 1 };<br><br>column tags =&gt;<br>&nbsp; since '0.1.7',<br>&nbsp; label is 'Tags',<br>&nbsp; refers_to BTDT::Model::TaskTagCollection by 'task_id';<br><br>package BTDT::Model::Task;<br>use BTDT::Model::User;<br>use BTDT::Model::Group;<br><br>use base qw( BTDT::Record );<br><br># Methods on your Task object go here<br><br>=head2 text_priority<br><br>Returns the priority as a string, not as a number.<br><br>=cut<br><br>sub text_priority {<br>&nbsp; &nbsp; my $self = shift;<br>&nbsp; &nbsp; my $number = shift || $self-&gt;priority;<br>&nbsp; &nbsp; my %mapping;<br>&nbsp; &nbsp; $mapping{$_-&gt;{value}} = $_-&gt;{display} for @{$self-&gt;column("priority")-&gt;valid_values};<br><br>&nbsp; &nbsp; return $mapping{$number};<br>}</tt> jesse 2005-10-11T01:09:08+00:00 journal Today's Parrot sketch http://use.perl.org/~jesse/journal/27102?from=rss http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200510/irc<nobr>l<wbr></nobr> og.parrotsketch.20051010 jesse 2005-10-11T00:58:57+00:00 journal Parrot Sketch: Sept 19 http://use.perl.org/~jesse/journal/27003?from=rss <tt>14:00 &lt;obra&gt; 'Afternoon<br>14:00 &lt;Nicholas&gt; g'day<br>14:01 &lt;chromatic&gt; Hello.<br>14:01 &lt;mdiep&gt; ahoy<nobr> <wbr></nobr>:-)<br>14:04 &lt;obra&gt; I've poked chip<br>14:05 &lt;Nicholas&gt; transcontinental poking device, or is he still east coast this week?<br>14:05 &lt;obra&gt; transcon<br>14:05 &lt;obra&gt; Unfortunately, I need to vanish at the end of the hour today.<br>14:05 &lt;chromatic&gt; It's past the hour; should we start or wait for others?<br>14:05 &lt;obra&gt; I was hoping that chip, leo and patrick might appear<br>14:05 -!- #parrotske chromatic H&nbsp; &nbsp;2&nbsp; ~chromatic@sub17-30.member.dsl-only.net [chromatic]<br>14:05 -!- #parrotske autrijus&nbsp; H@&nbsp; 2&nbsp; ~autrijus@220-133-92-49.HINET-IP.hinet.net [Autrijus Tang]<br>14:05 -!- #parrotske mdiep&nbsp; &nbsp; &nbsp;H&nbsp; &nbsp;2&nbsp; ~matt@bursley-221-209.reshall.umich.edu [Matt Diephouse]<br>14:05 -!- #parrotske obra&nbsp; &nbsp; &nbsp; H&nbsp; &nbsp;0&nbsp; ~jesse@diesel.bestpractical.com [Jesse]<br>14:05 -!- #parrotske Nicholas&nbsp; H&nbsp; &nbsp;2&nbsp; ~nwc10@colon.colondot.net [Nicholas Clark]<br>14:05 -!- End of<nobr> <wbr></nobr>/WHO list<br>14:07 &lt;obra&gt; But given the time, let's get cracking<br>14:08 &lt;obra&gt; matt. what have you been up to?<br>14:08 &lt;mdiep&gt; I've mostly been dealing with real life. but coke has managed to switch to using exceptions for Tcl in leo-ctx5<br>14:09 &lt;mdiep&gt; before we were returning a status variable (OK, ERROR, BREAK, CONTINUE)<br>14:09 &lt;mdiep&gt; this should give us a chance at interoperability<br>14:10 &lt;obra&gt; Very cool<br>14:10 &lt;obra&gt; Are there things you're currently blocking on?<br>14:10 &lt;mdiep&gt; we've also managed to get a ~20% speed boast between that and the new calling conventions<br>14:11 &lt;mdiep&gt; I have a couple questions for chip/leo regarding namespace stuff<br>14:11 &lt;mdiep&gt; also, we'd really appreciate it if we could merge the leo-ctx5 branch back in<br>14:12 &lt;mdiep&gt; at this point, we pretty much have to maintain two codebases for tcl<br>14:12 &lt;chromatic&gt; Yeah, I'm curious about the status of the merge and the September release.<br>14:12 &lt;obra&gt; I know chip at least started to do the review to get ctx5 merged back in<br>14:12 &lt;obra&gt; Were he here, we'd know more<nobr> <wbr></nobr>;)<br>14:13 &lt;mdiep&gt; exactly.<nobr> <wbr></nobr>:-)<br>14:13 &lt;mdiep&gt; so that's it for now.<br>14:13 &lt;obra&gt; ok<br>14:13 &lt;obra&gt; Nicholas: what's up?<br>14:14 &lt;Nicholas&gt; @work. (pesky xen boxes and ill sysadmins). No ponie at all this week. Done quite a bit of 5.8.8, but that's<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;off topic<br>14:15 &lt;Nicholas&gt; [plus found volunteers to do p5p summaries, got 2 new committers, reorganised the todo]<br>14:15 &lt;obra&gt; all good news for perl5<br>14:15 &lt;Nicholas&gt; No new questions, but was hoping that chip would be here to answer at least my first (about autogenerating<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;extend.c)<br>14:16 &lt;obra&gt; ok. autrijus, you here?<br>14:16 &lt;chromatic&gt; I should just send in my extend.c patch, as incomplete as it is.<br>14:16 &lt;obra&gt; ok, chromatic<br>14:17 &lt;Nicholas&gt; sounds like a good plan<br>14:17 &lt;obra&gt; how close is your extend.c patch?<br>14:17 &lt;chromatic&gt; It appears to generate all of extend.c that's there now from a C API point of view.<br>14:17 &lt;chromatic&gt; It loses comments.<br>14:17 &lt;chromatic&gt; I think it also adds a few things that might not ought to be there.<br>14:17 &lt;chromatic&gt; But it's a first sketch.<br>14:18 &lt;obra&gt; neat<br>14:19 &lt;obra&gt; Any other parrot hacking on your plate recently?<br>14:20 &lt;chromatic&gt; Not for me.<br>14:20 &lt;chromatic&gt; I just returned from vacation to a huge pile of work-related e-mail.<br>14:20 &lt;obra&gt; fun!<br>14:20 -!- #parrotske chromatic H&nbsp; &nbsp;2&nbsp; ~chromatic@sub17-30.member.dsl-only.net [chromatic]<br>14:20 -!- #parrotske autrijus&nbsp; H@&nbsp; 2&nbsp; ~autrijus@220-133-92-49.HINET-IP.hinet.net [Autrijus Tang]<br>14:20 -!- #parrotske mdiep&nbsp; &nbsp; &nbsp;H&nbsp; &nbsp;2&nbsp; ~matt@bursley-221-209.reshall.umich.edu [Matt Diephouse]<br>14:20 -!- #parrotske obra&nbsp; &nbsp; &nbsp; H&nbsp; &nbsp;0&nbsp; ~jesse@diesel.bestpractical.com [Jesse]<br>14:20 -!- #parrotske Nicholas&nbsp; H&nbsp; &nbsp;2&nbsp; ~nwc10@colon.colondot.net [Nicholas Clark]<br>14:20 -!- End of<nobr> <wbr></nobr>/WHO list<br>14:20 &lt;chromatic&gt; The first part, not the second.<br>14:21 &lt;obra&gt; So, absent any late<nobr> <wbr></nobr>/joins, I think that may be it for the day for new reports<br>14:23 &lt;chromatic&gt; Seems like it.<br>14:24 &lt;obra&gt; Right then. Next time, I send out the cattleprods in advance<br>14:24 &lt;Nicholas&gt; and use more 'volts';<br>14:24 &lt;chromatic&gt; use less 'optional';<br>14:25 &lt;obra&gt; It is, after all, an opensource project. "Everything's optional"<br>14:26 &lt;chromatic&gt; Alright Nick, there's your patch.<br> 14:26 &lt;obra&gt; see y'all next week<br>14:27 &lt;Nicholas&gt; indeed<br>14:27 &lt;chromatic&gt; Jesse, are you sending out the logs?<br>14:27 &lt;obra&gt; I will, yes<br>14:35 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has quit [Quit: back to work]<br>14:42 -!- Nicholas [~nwc10@colon.colondot.net] has left #parrotsketch []<br>Day changed to 20 Sep 2005<br>00:41 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has left #parrotsketch []<br>1<br><br></tt> jesse 2005-10-03T22:14:15+00:00 journal Parrot Sketch: Sept 12 http://use.perl.org/~jesse/journal/27002?from=rss <tt>Day changed to 12 Sep 2005<br>13:25 -!- autrijus [~autrijus@220-133-92-49.HINET-IP.hinet.net] has joined #parrotsketch<br>13:43 &lt;autrijus&gt; meeting in 17min?<br>13:43 &lt;@obra&gt; hai<br>13:44 &lt;@obra&gt; (hi)<br>13:47 &lt;autrijus&gt; []<br>13:47 &lt;autrijus&gt; I've recovered from brain and HD burnout<br>13:47 &lt;autrijus&gt; that wasn't fun<nobr> <wbr></nobr>:)<br>13:49 &lt;@obra&gt; I can believe it<nobr> <wbr></nobr>:/<br>13:49 -!- Nicholas [~nwc10@colon.colondot.net] has joined #parrotsketch<br>13:49 &lt;autrijus&gt; greetings Nicholas-san<br>13:50 &lt;Nicholas&gt; Hello<br>13:50 -!- leo_ [~lt@ts3-126.twistspace.com] has joined #parrotsketch<br>13:50 &lt;@obra&gt; Hi leo.<br>13:51 &lt;leo_&gt; hi all, hi jesse<br>13:57 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>13:57 -!- allison [~allison@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>13:59 &lt;chromatic&gt; You copied my hostname!!<br>13:59 &lt;allison&gt; who, me?<br>13:59 &lt;allison&gt; how strange<nobr> <wbr></nobr>;)<br>14:00 &lt;chromatic&gt; "She's in your house.&nbsp; GET OUT NOW!!"<br>14:00 &lt;allison&gt;<nobr> <wbr></nobr>:)<br>14:00 &lt;autrijus&gt; greetings<nobr> <wbr></nobr>:)<br>14:01 &lt;allison&gt; salutations<br>14:01 &lt;@obra&gt; Afternoon, kids.<br>14:01 &lt;chromatic&gt; Jesse, have you talked to Josh McAdams about doing an interview for Perlcast?<br>14:03 &lt;@obra&gt; chromatic: he talked to me at oscon, but we never managed to find the time.<br>14:03 &lt;Nicholas&gt; likewise I never managed to find the time<br>14:03 &lt;autrijus&gt; obra: thanks for sending me the meeting reminder so I won't come to an empty channel with a 24 hours delta again<nobr> <wbr></nobr>:)<br>14:04 &lt;chromatic&gt; He's going to do an RT book giveaway, so now might be a good time.<br>14:04 &lt;@obra&gt; so. I've pinged chip. I don't know if we'll get him today, but let's give him a moment<br>14:04 &lt;@obra&gt; chromatic: oh, cool<br>14:04 &lt;Nicholas&gt; at least in part because I asked him to wait until after I'd done the ponie talk<br>14:04 &lt;@obra&gt; what's his email?<br>14:04 &lt;chromatic&gt; perlcast@gmail.com<br>14:04 &lt;Nicholas&gt; obra: ambigous "he"<nobr> <wbr></nobr>:-)<br>14:04 -!- chip [~chip@ts3-126.twistspace.com] has joined #parrotsketch<br>14:04 &lt;chip&gt; Hey al<br>14:04 &lt;allison&gt; hey<br>14:05 &lt;chip&gt; er, "Hey all".&nbsp; but "al" works too<br>14:05 &lt;allison&gt; yeah, I figured<br>14:05 &lt;leo_&gt; hi chip<br>14:05 &lt;@obra&gt; heya chip<br>14:06 &lt;chip&gt; hi leo<br>14:06 &lt;chip&gt; thanks for the ping Jesse<br>14:06 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has joined #parrotsketch<br>14:06 &lt;@obra&gt; no worries.<br>14:06 &lt;@obra&gt; hey patrick<br>14:06 &lt;pmichaud&gt; greetings<br>14:06 &lt;chip&gt; meatspace move is progressing: just minutes ago, a forklift put three crates of many of my worldly belongings on a truck and drove away with it<br>14:07 &lt;chromatic&gt; The right forklift, or some well-equipped thief?<br>14:07 &lt;@obra&gt; We'll give the last straggler another minute or two and get started<br>14:08 &lt;chip&gt; chromatic: I'm betting he's legit<nobr> <wbr></nobr>.. or else he hit another customer of doortodoor.com before he got to me<br>14:10 &lt;chromatic&gt; I wish *my* mascot were a forklift puppet...<br>14:10&nbsp; * pmichaud makes note of the size of chip's bet<br>14:10 &lt;@obra&gt; Right then.<br>14:11 &lt;@obra&gt; Time to hassle y'all<br>14:11 -!- #parrotske pmichaud&nbsp; H&nbsp; &nbsp;1&nbsp; ~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net [New Now Know How]<br>14:11 -!- #parrotske obra&nbsp; &nbsp; &nbsp; H@&nbsp; 0&nbsp; ~jesse@69.25.201.132 [Jesse]<br>14:11 -!- #parrotske chip&nbsp; &nbsp; &nbsp; H&nbsp; &nbsp;0&nbsp; ~chip@ts3-126.twistspace.com [Chip Salzenberg]<br>14:11 -!- #parrotske allison&nbsp; &nbsp;H&nbsp; &nbsp;2&nbsp; ~allison@sub17-30.member.dsl-only.net [Allison Randal]<br>14:11 -!- #parrotske chromatic H&nbsp; &nbsp;2&nbsp; ~chromatic@sub17-30.member.dsl-only.net [chromatic]<br>14:11 -!- #parrotske leo_&nbsp; &nbsp; &nbsp; H&nbsp; &nbsp;0&nbsp; ~lt@ts3-126.twistspace.com [Leopold Toetsch]<br>14:11 -!- #parrotske Nicholas&nbsp; H&nbsp; &nbsp;2&nbsp; ~nwc10@colon.colondot.net [Nicholas Clark]<br>14:11 -!- #parrotske autrijus&nbsp; H&nbsp; &nbsp;1&nbsp; ~autrijus@220-133-92-49.HINET-IP.hinet.net [Autrijus Tang]<br>14:11 -!- End of<nobr> <wbr></nobr>/WHO list<br>14:11&nbsp; * chip girds his grid for a big one<br>14:11 &lt;@obra&gt; so. Patrick, you're sorting first in my "/who"<br>14:11 &lt;@obra&gt; What's new and exciting?<br>14:11 &lt;pmichaud&gt; "no, not me first!"&nbsp; "Oh, alright"<br>14:12 &lt;pmichaud&gt; Not much exciting here to report; I've been mostly reading up on tree transformation ideas and thinking about how they may integrate into PGE<br>14:12 &lt;pmichaud&gt; I'll be back to bits and code tomorrow morning<br>14:13 &lt;pmichaud&gt; expect various checkins then, as well as some new tests<nobr> <wbr></nobr>:-)<br>14:13 &lt;@obra&gt; Anyone else poking at PGE these days?<br>14:13 &lt;allison&gt; me<br>14:13 &lt;@obra&gt; I haven't actually looked at the milestones doc in a while. Are there updates?<br>14:13 &lt;pmichaud&gt; Mainly Will Coleda (Coke),and apparently allison<nobr> <wbr></nobr>:-)<br>14:14 &lt;pmichaud&gt; I still owe you updates to the milestones doc, yes.&nbsp; In fact, I need to re-review the latest changes to syn/apo/exe<br>14:14 &lt;pmichaud&gt; and we *really* need an update to S05, I fear<br>14:14 &lt;@obra&gt; What does it need to spec?<br>14:14 &lt;pmichaud&gt; afaik S05 still doesn't cover the correct capturing semantics<br>14:15 &lt;@obra&gt; I seem to recall seeing the updates go by in mail though, right?<br>14:15 &lt;@obra&gt; just not in the form of doc patches.<br>14:15 &lt;autrijus&gt; pmichaud: this? http://www.nntp.perl.org/group/perl.perl6.language/20985<br>14:15 &lt;pmichaud&gt; there's the doc that damian put together, but it's a bit long<br>14:15 &lt;pmichaud&gt; yes, that one<br>14:16 &lt;autrijus&gt; I think it's still correct<br>14:16 &lt;autrijus&gt; just $1 needs to be $0 et cetera<br>14:16 &lt;allison&gt; larry's been maintaining the synopses, lately<br>14:16 &lt;pmichaud&gt; right, and it probably belongs in S05<br>14:16 &lt;allison&gt; but he's not the only one<br>14:16 &lt;autrijus&gt; a copy+paste maybe?<br>14:16 &lt;allison&gt; patrick should have commit access them as well<br>14:16 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has joined #parrotsketch<br>14:17 &lt;pmichaud&gt; I have commit access, yes -- what I've lacked is tuits to do the updating<nobr> <wbr></nobr>:)<br>14:17 &lt;autrijus&gt; mdiep: greetings<br>14:17 &lt;mdiep&gt; greetings.<br>14:17 &lt;pmichaud&gt; it could be a copy+paste, but somehow that "feels wrong"<br>14:17 &lt;allison&gt; need an updating intern<br>14:17 &lt;autrijus&gt; it's, I'd think, better than leaving the old incorrect version around<br>14:17 &lt;pmichaud&gt; yeah, the incorrect version is buggin me, which is why I'm thinking of taking some time to fix it<br>14:18 &lt;allison&gt; yeah, the policy is to annotate the A's and E's, and update the S's<br>14:18 &lt;pmichaud&gt; damian had said he would work on it, but I'm guessing it fell off his radar screen (no wonder)<nobr> <wbr></nobr>:-)<br>14:18 &lt;allison&gt; jesse, want to ping him and see if we can still get him to do it? he's probably best<br>14:19 &lt;@obra&gt; allison: will do.<br>14:19 &lt;@obra&gt; ok. anything else on your end, patrick?<br><br>14:19 &lt;pmichaud&gt; that would be great with me.&nbsp; Other than that I'm just waiting to see what ends up happening with parrot parameter passing<br>14:19 &lt;pmichaud&gt; (it's possible something happened and I "missed it" last weekend)<br>14:19 &lt;@obra&gt; well, chip is next on my list<br>14:19 &lt;@obra&gt; so that's a nice transition.<br>14:19 &lt;@obra&gt; chip! what's up? [with parrot parameter passing]<br>14:20 &lt;chip&gt; Well.<br>14:20 &lt;chip&gt; I reviewed Leo's branch, and most of it looked great, including the parameter passing semantics around invocants.<br>14:21 &lt;chip&gt; Leo responded to my review, but I haven't had time to respond until today, what with meatspace move.<br>14:21 &lt;chip&gt; (Stay up until 3, wake up at 7, disassemble the bed you slept on<nobr> <wbr></nobr>... glad that part is over)<br>14:22 &lt;chip&gt; I think the parameter passing will reach stability shortly after the merge.<br>14:22 &lt;autrijus&gt; chip: so, hopefully not OT - is the plan to ship 0.2.4 based on leo-ctx5?<br>14:22 &lt;chip&gt; Named parameters are off the TODO list<br>14:23 &lt;chip&gt; autrijus: That's the plan, yes<br>14:23 &lt;autrijus&gt; great. I'll line up the PIR testing and version req here then.<br>14:23 &lt;@obra&gt; they're off the todo list in that they're done or that they're not to be done?<br>14:24 &lt;chip&gt; The latter.&nbsp; I like the idea that Perl 6's Pair handling might in the end be less magical in parameter passing than we've feared, but it's still not looking like there's enough common ground with Python to make Parrot the right place to find<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;common ground<br>14:25 &lt;@obra&gt; Ok.<br>14:25 &lt;@obra&gt; Anything else up, besides the move?<br>14:26 &lt;chip&gt; Nope.&nbsp; Day job is still fun and Parrot-friendly.<br>14:26 &lt;chip&gt; (not parrot-funding-friendly, but non-parrot-hostile, let's say)<br>14:27 &lt;@obra&gt; and presumably not parrot-using-friendly.<br>14:27 &lt;chip&gt; Cloudmark is actually a mostly C/C++ shop.&nbsp; Which, given that Perl is a huge C program, has left me feeling right at home.<br>14:28 &lt;chip&gt; I don't expect them to be Parrot users and frankly, given Decision Plus, I think that's a good change<br>14:28 &lt;@obra&gt; *nod*<br>14:28 &lt;chip&gt; (at least, not users of parrot for its own sake)<br>14:28 &lt;@obra&gt; Ok. Next on my list is allison, if that's all for your reporty part.<br>14:28 &lt;@obra&gt; There will be question time after reports<nobr> <wbr></nobr>;)<br>14:29 &lt;chip&gt; yes<br>14:30 &lt;allison&gt; over the weekend I started hacking together an AST for Punie, on the principle that I'll have a much better feel for how to write up the spec if I'm also working on an implementation of sorts<br>14:30 &lt;allison&gt; I haven't released the parrot compiler tools architecture plan yet<br>14:30 &lt;allison&gt; it's still pretty rough<br>14:30 &lt;allison&gt; probably time to branch out in my sources for comments though<br>14:31 &lt;allison&gt; would like autrijus' eyes, and anyone he suggests<br>14:31 &lt;autrijus&gt; url?<nobr> <wbr></nobr>:)<br>14:31 &lt;allison&gt; none yet<br>14:32 &lt;autrijus&gt; nod. bounce me a copy then?<br>14:32 &lt;allison&gt; after I fill in some blanks (especially in the PGE description), will put on list, but if I can email it to you before then and get comments would be a good start<br>14:32 &lt;allison&gt; yupt<br>14:32 &lt;autrijus&gt; I don't know what's in it, so it's hard to recommend sources<br>14:32 &lt;allison&gt; yup, that is<br>14:32 &lt;allison&gt; so, read first, then suggest?<br>14:32 &lt;autrijus&gt; yup.<br>14:33 &lt;@obra&gt; is punie in public svn?<br>14:33 &lt;allison&gt; in parrot/languages/punie<br>14:33 &lt;autrijus&gt; obra: http://svn.perl.org/parrot/branches/leo-ctx5/languages/punie/<br>14:34 &lt;@obra&gt; ah. very cool<br>14:34 &lt;@obra&gt; anything else new, allison?<br>14:34 &lt;allison&gt; that's all from the implementation side<br>14:35 &lt;allison&gt; so, I guess that's all that's on topic. back to you<br>14:35 &lt;@obra&gt; chromatic?<br>14:36 &lt;chromatic&gt; Nothing here.&nbsp; I'm on vacation.<br>14:37 &lt;@obra&gt; Nice<br>14:37 &lt;@obra&gt; leo?<br>14:37 &lt;leo_&gt; not much to report<br>14:37 &lt;leo_&gt; back in Austria, I caught a cold with heavy sneezing<br>14:37 &lt;@obra&gt;<nobr> <wbr></nobr>:/ Sorry to hear it.<br>14:37 &lt;leo_&gt; I prefer<nobr> <wbr></nobr>.pt<nobr> <wbr></nobr>:-)<br>14:38 &lt;@obra&gt;<nobr> <wbr></nobr>.pt was quite nice, though I totally failed to find a hotsprings I could visit.<br>14:38 &lt;leo_&gt; anyway, I'm running at 30% or so<br>14:38 &lt;leo_&gt; finished Google SoC final reports<br>14:38 &lt;leo_&gt; both guys passed<br>14:38 &lt;chip&gt; leo_: sorry about that<nobr> <wbr></nobr>... actually I didn't mention that I had a bad cold too last week.&nbsp; Maybe I gave it to you<br>14:39 &lt;leo_&gt; we didn't mail much<nobr> <wbr></nobr>:-)<br>14:39 &lt;allison&gt; leo: that's good news on SoC<br>14:39 &lt;leo_&gt; yup<br>14:39 &lt;leo_&gt; then I fixed the bug in my branch that was bothering mainly TCL<br>14:40 &lt;leo_&gt; a<nobr> <wbr></nobr>:slurpy got promoted to<nobr> <wbr></nobr>:flatten, if the same var was used in a call<br>14:40 &lt;leo_&gt; tcl is now passing 98% of tests<br>14:40 &lt;leo_&gt; (or even more as Coke is working on it)<br>14:40 &lt;mdiep&gt; err, tcl is now passing 100% of tests, actually<br>14:40 &lt;chip&gt; way cool<br>14:41 &lt;@obra&gt; Wow.<br>14:41 &lt;leo_&gt; that's all from here<br>14:41 &lt;@obra&gt; Nicholas: what's up? (as much as I want to go out of order and hear about tcl)<br>14:41 &lt;Nicholas&gt; I have questions for the question bit, and a little to report<br>14:42 &lt;Nicholas&gt; as mailed last week, after a big push last Monday I got the reference counting PMC Leo wrote to work<br>14:42 &lt;Nicholas&gt; "my brane hurts"<br>14:43 &lt;@obra&gt; very cool<br>14:43 &lt;Nicholas&gt; this has the side effect of slowing ponie down. Which isn't surprising, given that all reference count checks are now a hash lookup. This will go *when* reference counting is dropped in favour of regular Parrot GC wherever possible<br>14:43 &lt;Nicholas&gt; however, looking at the code that this other me wrote 6+ months ago I find that there's also already a(nother) hash of all allocated live SV heads<br>14:44 &lt;Nicholas&gt; to cope with the problem that perl 5 expects to be able to access perl 5 SV heads after it's dropped the reference count to zero<br>14:44 &lt;Nicholas&gt; (ie when I switched to directly malloc()ing them rather than puling them from arenas, I couldn't free() them at the point that the reference count hits zero)<br>14:45 &lt;Nicholas&gt; I'm not sure if this hash can go (yet), because after some pain I found I needed to be able to code it to be able to "delete" things from it while iterating over it (for Perl 5 global destruction)<br>14:45 &lt;Nicholas&gt; so I'm a bit stuck<br>14:45 &lt;Nicholas&gt; does the parrot has have the property that you can delete from it midway through iteration?<br>14:45 &lt;Nicholas&gt; [or is that a question for the question section?]<br>14:45 &lt;autrijus&gt; the parrot hash, you mean?<br>14:46 &lt;Nicholas&gt; yes, I mean that<br>14:46 &lt;Nicholas&gt; I can't type this fast, I guess<br>14:46 &lt;leo_&gt; this should be safe, as hashes don't shrink<br>14:47 &lt;Nicholas&gt; OK. You couldn't do it on perl 5 hashes, or the thread clone pointer table hash (which is what I used) because hash elements are allocated and freed<br>14:47 &lt;Nicholas&gt; however, there is still the big mess of quite what "owns" a refernece count, and what just happens to have a point to something else reference counted which it expects never to go away<br>14:47 &lt;chip&gt; in general it will depend, I should think.&nbsp; Some hashes will shrink, as people invent PMCs that suit them<br>14:48 &lt;@obra&gt; let's come back to this? I want to get to autrijus and mdiep<br>14:48 &lt;Nicholas&gt; and I *think* that the optree might need to start "owning" references onto GVs that it points to, rather than the current situation (As I understand it) where it points and prays<br>14:48 &lt;Nicholas&gt; but basically I've been thinking<br>14:48 &lt;Nicholas&gt; and more importantly @work has things that need doing<br>14:48 &lt;Nicholas&gt; so next victim...<br>14:49 &lt;@obra&gt; ok. autrijus?<br>14:49 &lt;autrijus&gt; personally I have a HD meltdown, so nothing much in the past few days<br>14:49 &lt;@obra&gt; anything else pugsy?<br>14:49 &lt;autrijus&gt; however pugs sees some radical changes that may affect parrotskecth<br>14:50 &lt;autrijus&gt; the 'pugs' executable is now a simple perl5 script that exec()'s the appropriate compiler and runtime backends<br>14:50 &lt;autrijus&gt; so "./pugs -Bperl5 hello.pl", "./pugs -Bjs hello.pl" etc all work<br>14:51 &lt;autrijus&gt; previously we would need an embedded libparrot (which doesn't work in win32 due to gcc/vc++ conflicts) to run perl6 thru parrot<br>14:52 &lt;autrijus&gt; now it's much more trivial as the individual stages in the pipeline can be decoupled and the interim results saved.<br>14:52 &lt;chip&gt; a la old style C compilers, then.&nbsp; cpp/cc1/as<br>14:52 &lt;autrijus&gt; chip: exactly.<br>14:53 &lt;autrijus&gt; the focus is now mainly on the perl5 backend. so the faster route to run perl6 on parrot may be thru ponie<nobr> <wbr></nobr>:)<br>14:53 &lt;Nicholas&gt; I get very scared when anyone mentions ponie in the context of being working.<br>14:53 &lt;Nicholas&gt; principally because it still feels like a very BIG job<br>14:53 &lt;@obra&gt; Ok.<br>14:53 &lt;autrijus&gt; fglock is getting the previously-thought-as-improbable-to-implement things like generator arrays.<br>14:54 &lt;Nicholas&gt; and at 1 day per week it doesn't progress rapidly<br>14:54 &lt;autrijus&gt; so it's looking good for the shown-on-the-timeline goal of bootstrapping p6-on-p5 this year.<br>14:55 &lt;autrijus&gt; I'll look at parrot 0.2.4 for the merge; I'd also like to sync the releases again like last month.<br>14:55 &lt;autrijus&gt; end of report.<br>14:55 &lt;Nicholas&gt; at which point you find where all the regexp engine, Unicode and threads bugs in perl 5 are?<nobr> <wbr></nobr>:-)<br>14:55 &lt;autrijus&gt; (the merge = leo-ctx5 merge)<br>14:55 &lt;@obra&gt; ok. matt?<br>14:55 &lt;mdiep&gt; as reported, coke has got tcl passing 100% of tests in leo-ctx5<br>14:55 &lt;autrijus&gt; Nicholas: rules engine is being done on top, instead of compiled to, regexp; what unicode bugs?&nbsp; threads is a real concern.<br>14:56 &lt;@obra&gt; Does that mean that the tcl test suite is incomplete or there's now a real, full, useful tcl on top of parrot?<br>14:56&nbsp; * Nicholas waits for the questions section<br>14:56 &lt;mdiep&gt; obra: the tcl test suite is incomplete (by far)<br>14:56 &lt;@obra&gt; ok.<br>14:57 &lt;@obra&gt; anything else in your camp?<br>14:57 &lt;mdiep&gt; we're hovering around 12% of the actual Tcl tests passing<br>14:57 &lt;@obra&gt; *nod*<br>14:57 &lt;mdiep&gt; my tuit supply has been low with the start of classes last week, so there's not much other than my "HLL Namespace Design" thread on p6i<br>14:58 &lt;mdiep&gt; I was glad to see Larry's reply to that<br>14:58 &lt;@obra&gt; Ok.<br>14:58 &lt;mdiep&gt; I will hopefully get around to understand Parrot's current implementation sometime this week, and then on to a proposal to support all needed features<br>14:59 &lt;mdiep&gt; that's all.<br>14:59 &lt;@obra&gt; So, we've only got a couple minutes left "officially" but I'm happy to run a bit long if people can stick around.<br>14:59 &lt;@obra&gt; Who's got questions?<br>14:59 &lt;Nicholas&gt; I have. but I also need to answer the Unicode question<br>14:59&nbsp; * mdiep has a couple<br>15:00&nbsp; * chip has one<br>15:00 &lt;@obra&gt; let's start with chip<br>15:00 &lt;chip&gt; leo: what was your chosen solution to get around the<nobr> <wbr></nobr>:flatten being conflated with<nobr> <wbr></nobr>:slurpy?<br>15:01 &lt;leo_&gt; moving the call bits into the call structure<br>15:01 &lt;leo_&gt; i.e. pcc_sub-&gt;arg_flags<br>15:01 &lt;leo_&gt; and<br>15:01 &lt;leo_&gt; i.e. pcc_sub-&gt;ret_flags<br>15:01 &lt;chip&gt; neat<br>15:01 &lt;chip&gt; er, nm<br>15:02 &lt;leo_&gt; took just a couple of lines<br>15:02 &lt;chip&gt; the way you did it, will it work OK to have multiple returns in the same sub, or multiple calls using the same reg in different ways from the same sub?<br>15:03 &lt;leo_&gt; yep, because there is one pcc_sub perl call/return/sub<br>15:03 &lt;chip&gt; excellent<br>15:03 &lt;chip&gt; ok, that's my q<br>15:03 &lt;@obra&gt; ok. nicholas, then matt.<br>15:04 &lt;Nicholas&gt; gah. just as the kettle boiled.<br>15:04 &lt;Nicholas&gt; "no tea"<br>15:04 &lt;Nicholas&gt; OK, the unicode bugs comment<br>15:05 &lt;Nicholas&gt; the meta-summary of "Perl 5.8.? is boring" is that we keep finding Unicode bugs<br>15:05 &lt;Nicholas&gt; so anything that runs atop Perl 5 will hit them<br>15:05 &lt;autrijus&gt; allison: I have a couple parrot comptool question, but it may be made redundant if you can mail me the draft plan<br>15:05 &lt;Nicholas&gt; specifically, a recent-ish discovery was a whole class of bugs - basically string overloading with UTF-8 is currently broken<br>15:05 &lt;Nicholas&gt; and no-one has had time to work out how to fix it<br>15:06 &lt;allison&gt; autrijus: ok, if you want to wait til next week when you've read it, that's fine<br>15:06 &lt;Nicholas&gt; because it's messy, and involves fixing broken assumptions in code paths that check SvUTF8(sv)<br>15:07 &lt;Nicholas&gt; because SvUTF8(sv) is not true on an reference. Yet a reference can have overloaded strinification, and in turn overloaded stringification can return UTF-8 encoded data<br>15:07 &lt;autrijus&gt; allison: I was thinking about maybe read it this moment.<nobr> <wbr></nobr>:) I'll ask anyway<br>15:07 &lt;Nicholas&gt; and I suspect that this is where things might hit<br>15:07 &lt;Nicholas&gt; but more generally<br>15:07 &lt;Nicholas&gt; Damian's Perl6::Rules came unstuck bceause of the regepx engine<br>15:07 &lt;Nicholas&gt; and I'm concerned that trying to push Perl 5 too hard will reveal the cracks within<br>15:08 &lt;Nicholas&gt; Serious threads are still likely to be a problem. But I don't think that Perl 6 has a threads spec yet, so that might not be a problem within this timeframe<br>15:08 &lt;Nicholas&gt; was that a sufficient asnswer? does it generate more questions?<br>15:08 &lt;autrijus&gt; nod.<br>15:08 &lt;allison&gt; autrijus: ok, ask now and if I think the answer is too long for IRC, I'll save it and write it into the document<br>15:08 &lt;autrijus&gt; just a quick comment about perl5's cracks<br>15:09 &lt;autrijus&gt; pugs's plan is to solve any problems with an extra level of indirection.<br>15:09 &lt;chip&gt; if Perl6 emulates pos(), it might be able to use pos and \G to execute rules piecewise, rather than trying to create The Ultimate Regex<br>15:09 &lt;autrijus&gt; eg. full CPS on javascript, which does not even have goto().<br>15:09 &lt;autrijus&gt; so we're not going the Perl6::Rules route<br>15:09 &lt;autrijus&gt; rather if there's a rule engine, it will be built like PGE<br>15:09 &lt;chip&gt; (I seem to have stepped on autrijus there, sorry)<br>15:09 &lt;autrijus&gt; chip: np<br>15:09 &lt;Nicholas&gt; but it was an interesting answer<br>15:10 &lt;autrijus&gt; PGE doesn't use parrot's internal rx ops either<br>15:10 &lt;autrijus&gt; or PCRE<br>15:10 &lt;autrijus&gt; which is also builtin to aprrot<br>15:10 &lt;autrijus&gt; rather it compiles to something that disregards the underlying broken regex<br>15:10 &lt;autrijus&gt; so that's what we'll do on both Rules and Unicode.<br>15:10 &lt;Nicholas&gt; but every layer of indirection you find you need because of Perl 5 bugs will make things slower. (I assume)<br>15:10 &lt;autrijus&gt; it's rather hard -- actually provably impossible -- to fake threads this way, so we'll punt.<br>15:10 &lt;Nicholas&gt; so it's only really a stop gap)<br>15:11 &lt;autrijus&gt; Nicholas: not really if the indirection go thru XS.<br>15:11 &lt;autrijus&gt; linking libsyck for example is a good indirection to take.<br>15:11 &lt;autrijus&gt; insteadof working around the very broken YAML.pm.<br>15:11 &lt;autrijus&gt; end of comment<nobr> <wbr></nobr>:)<br>15:12 &lt;@obra&gt; ok.<br>15:12 &lt;autrijus&gt; (the policy so far is: pure perl5 for the core stuff, but advanced things may need C modules like Coro.pm)<br>15:12 &lt;Nicholas&gt; it seems consistent. in a crazy-but-sane way<br>15:12 &lt;@obra&gt; That it? Matt, what's on your list?<br>15:13 &lt;Nicholas&gt; no, not done *asking* questions yet<br>15:13 &lt;Nicholas&gt; but I can wait if that's better<br>15:13 &lt;mdiep&gt; nicholas: go ahead and finish<br>15:14 &lt;@obra&gt; Nick: list off your questions and we can try to get through as many as possible?<br>15:15 &lt;@obra&gt; I'm sorry for not better coordinating last week, all.<br>15:15 &lt;Nicholas&gt; I think I have about 5 questions (related) that I believe are principally for Chip, and he may not have answers off hand<br>15:15 &lt;@obra&gt; I bet we'd have done better with questions had I done so.<br>15:15 &lt;Nicholas&gt; first question is about the extending interface<br>15:15 &lt;Nicholas&gt; some of the vtable calls are exported via C to extenders, but not all, and the naming is not consistent<br>15:16 &lt;Nicholas&gt; there's a thread that ends here: http://www.nntp.perl.org/group/perl.perl6.internals/29422<br>15:16 &lt;Nicholas&gt; where (IIRC) chromatic has a version of a program to generate extend.c (or parts of it) automatically, but we're really waiting on a design call on waht's needed<br>15:16 &lt;chip&gt; I see.&nbsp; Hm.<br>15:16 &lt;Nicholas&gt; I ask, because every so often ponie needs another 1 or 2 vtable calls, and I add them by hand, and it all feels wrong<br>15:17 &lt;Nicholas&gt; so I guess my question is "could you think about what you want, and make a sign that we will recognise?"<nobr> <wbr></nobr>:-)<br>15:17 &lt;chip&gt; OK, a step forward is to automatically generate them.&nbsp; It's a definite decision that anything that requires copy/paste/search/replace from a human being on a regular basis is just Wrong<br>15:18 &lt;Nicholas&gt; we have to remove some inconsistently named ones as part of this<br>15:18 &lt;chip&gt; And given the current flux, I think it's a good idea to expose all the vtable functions, but with an understanding that it's possible we'll decide to unexpose some before 1.0.&nbsp; (just a little CYA on my part there)<br>15:18 &lt;Nicholas&gt; but that short term pain seems best<br>15:18 &lt;Nicholas&gt; seems reasonable<br>15:18 &lt;Nicholas&gt; sort of jumps to fourth question<br>15:19 &lt;chip&gt; yes, we can do (re)naming kludges only after 1.0 when we have an interface to maintain<br>15:19 &lt;Nicholas&gt; are vtable changes likely soon? In particular, Dan was keen on the whole morphing concept, and I wrote the ponie PMC code to start to take advantage of it, but Leo has seemed less keen on the morph idea<br>15:20 &lt;Nicholas&gt; you've (wisely) stated that PIR compatibility is the current priority<br>15:20 &lt;Nicholas&gt; which means that ponie, as an atypical parrot user, isn't sure what might change<br>15:21 &lt;chip&gt; Well, when morphing happens or doesn't happen, that shouldn't break the PMC interface promises (such as they are) either way, so<nobr> <wbr></nobr>... how is Ponie affected by whether a given PMC likes to morph or not?<br>15:21 &lt;Nicholas&gt; well, it's partly<br>15:21 &lt;Nicholas&gt; a: is morph staying?<br>15:21 &lt;Nicholas&gt; b: what might change in the near future in the vtable?<br>15:21 &lt;chip&gt; Consider Perl 5 $$.&nbsp; When someday we have a pid pmc, it won't morph when you assign to it, but an integer pmc assigned a float might do so<br>15:22 &lt;Nicholas&gt; OK<br>15:22 &lt;chip&gt; (_might_, mind you, but not if someone said C&lt;my Int $a&gt;)<br>15:22 &lt;chip&gt; different meaning for 'integer pmc'.&nbsp; more like 'general scalar pmc that happens to contain an integer at the moment')<br>15:22 &lt;Nicholas&gt; for any question "I'll think about it" is fine by me as an answer. I don't want to put you on the spot, or delay mdeip's questions<br>15:22 &lt;Nicholas&gt; OK. that makes sense<br>15:23 &lt;chip&gt; Vtable changes pending: I have none in mind, but maybe leo does.<br>15:23 &lt;leo_&gt; we should consider making assign a MMD instead of a vtable<br>15:23 &lt;Nicholas&gt; OK. that doesn't phase me. I'm not near needing that yet<br>15:24 &lt;Nicholas&gt; question 2 was about PMC bodies. Leo has said that access will continue to work via the offical macros regarless of what happens.<br>15:24 &lt;leo_&gt; and wrt changes - I just expect additions - no changes to vtable functions<br>15:24 &lt;chip&gt; I'd be surprised if that were a priority, but I can understand why it might be handy<br>15:24 &lt;Nicholas&gt; OK. cool<br>15:24 &lt;chip&gt; (wrt MMD assign)<br>15:24 &lt;leo_&gt; e.g. PMC* get_numeric()<br>15:25 &lt;Nicholas&gt; confused. get_numeric() ? and the context<br>15:25 &lt;leo_&gt; INTVAL get_integer() can't handle BigInts<br>15:25 &lt;Nicholas&gt; that is something I'm likely to start visiting soon<br>15:25 &lt;leo_&gt; $a = +$b;<br>15:25 &lt;chip&gt; Vtable entries for getting by conceptual context rather than by the data type expected<br>15:25 &lt;chip&gt; PMC *get_integral() e.g.?<br>15:26 &lt;leo_&gt; I don't care about the name, but it seems to be missing<br>15:26 &lt;chip&gt; I was illustrating the idea not suggesting a name,r eally<br>15:26 &lt;chip&gt; so the pending question is: "pmc body access"<br>15:27 &lt;chip&gt; no opinion on that, I haven't been playing with that<br>15:27 &lt;Nicholas&gt; yes, sorry. I didn't want to get in the way of a useful discussion<br>15:27 &lt;Nicholas&gt; it's just that the generational GC branch changes PMC layout<br>15:27 &lt;Nicholas&gt; and if that gets adopted for the trunk, I'm not sure how it changes what's space efficient and what's not<br>15:28 &lt;Nicholas&gt; given that I'm about to be at the point of figuring out how to shoe-horn Perl 5 data structures into PMCs<br>15:28 &lt;chip&gt; I haven't reviewed the GC branch, just Leo's<br>15:28 &lt;Nicholas&gt; OK. So no answer yet<br>15:28 &lt;chip&gt; right<br>15:28 &lt;leo_&gt; I think we should adapt the PMC* structure part of gmc early<br>15:29 &lt;Nicholas&gt; except that as I understand it it's variable sized bodies<br>15:29 &lt;Nicholas&gt; which moves nicely onto question3<br>15:29 &lt;Nicholas&gt; threads<br>15:29 &lt;Nicholas&gt; in that IIRC Dan said one of the lessons of 5005 threads was that variable sized bodies are a pain<br>15:29 &lt;chip&gt; Threads?&nbsp; "OH LOOK, A HUGE DISTRACTING THING"<br>15:29 &lt;Nicholas&gt; but I'm not sure if I fully understood why, and certainl by now I've forgotten the specifics<br>15:30 &lt;Nicholas&gt; oh yes. SHINY<br>15:30 &lt;Nicholas&gt; question 5 is also likely to summon one<br>15:30 &lt;Nicholas&gt; I mailed perl6-internals a bit ago about parrot and signals Leo says that SIGHUP is claimed on startup for testing<br>15:31 &lt;Nicholas&gt; ponie would like it if parrot were able to be well behaved as an embeddable interpreter<br>15:31 &lt;Nicholas&gt; which would mean beinga ble to not claim any signals by defaul<br>15:31 &lt;chip&gt; AFAICT, the only connection between threads and variable-sized PMCs is cache coherency, and that actually isn't really threads either.&nbsp; So I don't see the connection.&nbsp; The lesson of 5.005 threads is: ONE THREAD PER HLL INTERPRETER.&nbsp; Any other<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;lesson is in lower case.<br>15:31 &lt;Nicholas&gt; Leo said that really it's waiting on an API<br>15:31 &lt;chip&gt; API?&nbsp; Extending the embedding API, you mean?<br>15:31 &lt;Nicholas&gt; OK. \Uunderstood\E<br>15:32 &lt;Nicholas&gt; I'm not sure which bit of API this was<br>15:32 &lt;chip&gt; Hm.&nbsp; Well, it's pretty clear that just like how Linux fork() evolved into clone() with a bunch of options, pretty much every environmental tweak that hte Parrot engine does needs to be controlled from the embed interface<br>15:32 &lt;Nicholas&gt; answer was in 42D6911D.4040309@toetsch.at<br>15:33 &lt;Nicholas&gt; http://groups.google.com/group/perl.perl6.internals/msg/9f76fe495b8cea22?hl=en <br><nobr> <wbr></nobr> 15:33 &lt;Nicholas&gt; aha. Leo - " And yes, there is no interface whatsoever to pass a<br>15:33 &lt;Nicholas&gt; signal on, or some such. "<br>15:34 &lt;chip&gt; "pass it on"<nobr> <wbr></nobr>... ah.&nbsp; Parrot_consider_yourself_signaled(int signum) e.g.<br>15:34 &lt;chromatic&gt; I thought Dan's idea was to unify signals and events.<br>15:34 &lt;Nicholas&gt; I thought too<br>15:35 &lt;leo_&gt; a signal is already converted to a Parrot event<br>15:35 &lt;chip&gt; well, that's an orthogonal question.&nbsp; however Parrot models events, it must be possible to introduce synthetic ones<br>15:35 &lt;chip&gt; and if there is no way to do that, that's bad<br>15:35 &lt;chip&gt; and if there's no way for Parrot to _not_ grab signals, that's also bad<br>15:35 &lt;leo_&gt; but e.g. Ponie installs a sig handler and parrot too - ponie might want a 'signal'<br>15:35 &lt;@obra&gt; [ I've asked nick to hold onto his remaining question so we have something to talk about next week<nobr> <wbr></nobr>;) ]<br>15:35 &lt;chip&gt; Parrot's signal handler installation must be optional.&nbsp; Then both models are possible.<br>15:36 &lt;leo_&gt; yep<br>15:36 &lt;chip&gt; ok<br>15:36 &lt;Nicholas&gt; I agree (in principle). I practice, I'm not to worried about details of how. It's merely that I've had to TODO out some perl 5 regression tests that deal with signals<br>15:36 &lt;Nicholas&gt; and I'd prefer to remove the TODO<br>15:37 &lt;chip&gt; for your purposes, at this time, you want Perl 5 getting the signals, right?<br>15:37 &lt;Nicholas&gt; yes please<br>15:38 &lt;chip&gt; right, clear<br>15:38 &lt;Nicholas&gt; (and I think given how some of POSIX.pm's tests work, it at least needs to fake correctly for IGNORE and DEFAULT<br>15:39 &lt;Nicholas&gt; those were my 5 questions. (or 4 and a distraction device)<br>15:39 &lt;@obra&gt; heh<br>15:39 &lt;@obra&gt; ok.<br>15:39 &lt;@obra&gt; so. matt. still alive?<br>15:39 &lt;Nicholas&gt; thanks<br>15:39 &lt;mdiep&gt; yep, still here.<nobr> <wbr></nobr>:-)<br>15:39 &lt;@obra&gt; what's on your list?<br>15:40 &lt;mdiep&gt; okay, first question: what's happening with "Call for B0rked"? is someone going to go through it?<br>15:41 &lt;leo_&gt; I'd say collect all b0rked in a file in svn first<br>15:43 &lt;leo_&gt; some are TODOs, some need explanation, some are bugs<br>15:43 &lt;leo_&gt; I'll try to answer mails tomorrow<br>15:44 &lt;@obra&gt; mdiep: what's next<br>15:44 &lt;mdiep&gt; the rest can wait till next week.<br>15:44 &lt;@obra&gt; Ok. Thanks<nobr> <wbr></nobr>:)<br>15:44 &lt;@obra&gt; But next week, you're first<nobr> <wbr></nobr>;)<br>15:45 &lt;@obra&gt; So, thanks for hanging on for Parrot Sketch - The Extended Edition.<br>15:45&nbsp; * chip watches for the special edition DVD<br>15:45 &lt;@obra&gt; Tune in next week, same bat-time, same bat-channel.<br>15:45 &lt;Nicholas&gt; mmm. cricket.<nobr> <wbr></nobr>:-)<br>15:45 &lt;@obra&gt;<nobr> <wbr></nobr>..when the regular version returns.<br>15:46 &lt;autrijus&gt;<nobr> <wbr></nobr>:)<br>15:46 &lt;@obra&gt; I'll mail logs out this afternoon<br>15:46 &lt;autrijus&gt; so is the logs up at any url at this moment?<br>15:46 &lt;autrijus&gt; of previous ones that is<br>15:46 &lt;pmichaud&gt; later, all<br></tt> jesse 2005-10-03T22:12:40+00:00 journal Parrot Sketch: Sept 5 http://use.perl.org/~jesse/journal/27001?from=rss <tt>Day changed to 05 Sep 2005<br>13:12 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has joined #parrotsketch<br>13:54 &lt;mdiep&gt; obra: is there a meeting today? (7 minutes from now)<br>13:58 &lt;mdiep&gt; guess not<br>14:00 &lt;@obra&gt; Hello<br>14:00 &lt;@obra&gt; Yes<br>14:01 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>14:16 -!- #parrotske chromatic H&nbsp; &nbsp;1&nbsp; ~chromatic@sub17-30.member.dsl-only.net [chromatic]<br>14:16 -!- #parrotske obra&nbsp; &nbsp; &nbsp; H@&nbsp; 0&nbsp; ~jesse@69.25.201.132 [Jesse]<br>14:16 -!- #parrotske mdiep&nbsp; &nbsp; &nbsp;H&nbsp; &nbsp;2&nbsp; ~matt@bursley-221-209.reshall.umich.edu [Matt Diephouse]<br>14:16 -!- End of<nobr> <wbr></nobr>/WHO list<br>14:16 &lt;@obra&gt; Hey chromatic.<br>14:17 &lt;@obra&gt; I've been off-net for the past 2+ days. looks like failure to send mail caused a cascading failure<br>14:22 -!- Nicholas [~nwc10@colon.colondot.net] has joined #parrotsketch<br>14:22 &lt;Nicholas&gt; chaos at London Bridge station<br>14:22 &lt;Nicholas&gt; signal failure or somesuch<br>14:23 &lt;@obra&gt; Yikes<br>14:23 &lt;@obra&gt; Appears almost entirely quiet here<br>14:23 &lt;Nicholas&gt; not that unusual<br>14:23 &lt;chromatic&gt; I failed to send the summary last week, because of mail server failure and then forgetfulness.<br>14:24 &lt;Nicholas&gt; do you know how the summaries of the conference call were going to be made available publicly? I thought that it was supposed to start by now<br>14:25 &lt;@obra&gt; Nicholas: I believe you want to talk to luke about that.<br>14:25&nbsp; * chromatic agrees<br>14:25 &lt;Nicholas&gt; OK<br>14:30 &lt;@obra&gt; so, nicholas / chromatic / mdiep.<br>14:30 &lt;@obra&gt; anything new with you and perl6?<br>14:31 &lt;Nicholas&gt; hammered away at things last Monday and got Leo's new PMC class to do reference counting<br>14:31 &lt;Nicholas&gt; *that* works<br>14:32 &lt;Nicholas&gt; I now find that I'd already got ponie-specific code to track all the PMCs, to replicated the ability of perl to iterate over the SV heads at destruction time<br>14:32 &lt;Nicholas&gt; and I've rediscovered that I had to code it carefully to allow deleting from a hash that is being iterated over<br>14:33 &lt;Nicholas&gt; so I don't know if I can directly/easily throw it out and iterate over the new PMC-that-does-the-reference-counts<br>14:33 &lt;Nicholas&gt; ideally all this code will go<br>14:33 &lt;Nicholas&gt; but I don't know how parrot does global destruction<br>14:35 &lt;Nicholas&gt; and I've not yet had time to look<br>14:35 &lt;chromatic&gt; I'm not sure Parrot does global destruction yet.<br>14:35 &lt;chromatic&gt; _exit() doesn't count.<br>14:35 &lt;Nicholas&gt; _exit() does not<br>14:36 &lt;Nicholas&gt; if parrot doesn't yet allow the option of global destruction, then I'm going to need to keep some sort of hack until it does<br>14:36 &lt;Nicholas&gt; also, I don't know how weak references are going to translate into parrot<br>14:36 &lt;@obra&gt; ok. sadly, we have no chip and no leo around.<br>14:37 &lt;@obra&gt; Have you sent mail to p6i asking how they cope?<br>14:37 &lt;Nicholas&gt; no, not yet<br>14:37 &lt;@obra&gt; ok<br>14:37 &lt;Nicholas&gt; only just started to think about this sort of stuff<br>14:37 &lt;chromatic&gt; I had an outstanding design issue about finalization (for NCI) several months ago.&nbsp; That should go ok the B0rked list.<br>14:37 &lt;Nicholas&gt; still feeling quite shattered after a week in Braga<br>14:38 &lt;Nicholas&gt; as you have a firmer idea of what you need, are you able to do that?<br>14:38 &lt;Nicholas&gt; I'm not even sure how much of the perl 5 semantics are really necessary<br>14:39 &lt;chromatic&gt; I don't need *reliable* destruction for that, but I do want to release resources at some point.<br>14:40 &lt;chromatic&gt; Sorry, I mean reliable *timely* destruction.<br>14:40 &lt;Nicholas&gt; for the perl 5 case I don't need reliable timley<br>14:40 &lt;Nicholas&gt; It's the "all remaining resouces must be finalised at program exit"<br>14:41 &lt;chromatic&gt; Not even program exit.&nbsp; For NCI, when using unmanaged pointers, it's nice to free them somehow.<br>14:42 &lt;chromatic&gt; This is important when using limited resources such as screen buffers or file descriptors, of course.<br>14:42 &lt;Nicholas&gt; ah right<br>14:43 &lt;Nicholas&gt; they need to be "garbage collected" in some fashion before they run out<br>14:43 &lt;chromatic&gt; I still think separating finalization from garbage collection is important.<br>14:47 &lt;@obra&gt; So. anything else reportish?<br>14:47 &lt;chromatic&gt; Not here.<br>14:47 &lt;Nicholas&gt; yes, I agree on finalization/GC<br>14:48 &lt;Nicholas&gt; and nothing else to report. Last commit I made was about 169 hours ago<br>14:48 &lt;chromatic&gt; I see Matt sent in a HLL proposal.<br>14:58 &lt;@obra&gt; So, I bet that about wraps it up for this week.<br>14:58 &lt;@obra&gt; next week, I'm home, so I'll send reminder mail<br>14:58 &lt;Nicholas&gt; OK<br>14:59 &lt;chromatic&gt; Thanks.&nbsp; Take care, all.<br>14:59 &lt;Nicholas&gt; I should be on time. Barring fire, floods or the usual UK rail system woes<br>14:59 &lt;chromatic&gt; That's why we won the Revolutionary War, you know -- better public transportation, or at least less bad.<br>14:59 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has quit [Quit: Leaving]<br>15:00 &lt;Nicholas&gt; spot the Porland resident.<nobr> <wbr></nobr>:-)<br>15:08 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has left #parrotsketch []<br>15:08 -!- Nicholas [~nwc10@colon.colondot.net] has left #parrotsketch []<br></tt> jesse 2005-10-03T22:09:57+00:00 journal Parrot Sketch: Oct 3 http://use.perl.org/~jesse/journal/26998?from=rss <tt>Day changed to 03 Oct 2005<br>13:33 -!- leo [~lt@feather.perl6.nl] has joined #parrotsketch<br>13:56 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has joined #parrotsketch<br>13:57 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>13:57 &lt;mdiep&gt; I may have just blown our cover in #parrot<br>13:57 &lt;mdiep&gt; for some reason my client sent my<nobr> <wbr></nobr>/join through<br>13:58 &lt;leo&gt; it had a ^P in front it seems<br>13:58 &lt;mdiep&gt; odd<br>14:00 -!- autrijus [~autrijus@feather.perl6.nl] has joined #parrotsketch<br>14:00 &lt;autrijus&gt; greetings gentlefolks.<br>14:01 &lt;leo&gt; hi lambdacamel<br>14:01 &lt;obra&gt; 'afternoon, all.<br>14:01 &lt;autrijus&gt; glad I made it on time<br>14:01 &lt;obra&gt; well, the logs that have been posted all have the channel name<nobr> <wbr></nobr>;)<br>14:02 &lt;mdiep&gt; have they been posted publicly somewhere?<br>14:02 &lt;obra&gt; Not all of them and not consistently<br>14:02 &lt;autrijus&gt; indeed, havn't read about them publicly<br>14:02 &lt;obra&gt; autrijus had some up for a bit. And leon was going to post a couple of them for us at one point<br>14:02 &lt;obra&gt; I've asked robert to automate this for us<br>14:02 &lt;leo&gt; autrijus: you are back @home?<br>14:02 &lt;obra&gt; so we don't have to think about it<br>14:03 &lt;chromatic&gt; obra and I talked once about making this a moderated channel if necessary.<br>14:03 &lt;autrijus&gt; leo: no, at finland<br>14:03 &lt;obra&gt; Yeah. basically, if the peanut gallery starts showing up for meetings, they will keep quiet<nobr> <wbr></nobr>;)<br>14:04 &lt;mdiep&gt; heh<br>14:04 &lt;obra&gt; I have no problem with people watching, but distracting isn't ok<nobr> <wbr></nobr>;)<br>14:04 &lt;obra&gt; We're distracting enough.<br>14:04 &lt;leo&gt; *g*<br>14:04 &lt;obra&gt; We'll give the rest of the gang another 2-3 minutes<br>14:04 &lt;obra&gt; anyone who has questions should list them off now. But NO ANSWERS AND NO DISCUSSION<nobr> <wbr></nobr>;)<br>14:04 &lt;obra&gt; Just a preview<nobr> <wbr></nobr>;)<br>14:04 &lt;obra&gt; while we wait<br>14:05 &lt;chromatic&gt; What's the status of the Ponie and Parrot smoketest systems?<br>14:06 &lt;mdiep&gt; is there a plan to add a event/notification system to Parrot somewhere down the road? http://www.sidhe.org/~dan/blog/archives/000414.html<br>14:06 &lt;autrijus&gt; how is the static lexical pad coming along? what will the PIR level look like and, is it workable or emulatable now?<br>14:07 &lt;mdiep&gt; when do DEPRECATED/DELETED opcodes actually get removed?<br>14:07 &lt;chromatic&gt; How far along is the AST model in Pugs and when is it possible to start porting it to PIR?<br>14:08 &lt;autrijus&gt; who, if any, is going to port UUAG or Luke's L::AG to Parrot?<br>14:08 &lt;mdiep&gt; is there any rubric for determining if something becomes a VTABLE method? there is currently add_method but not add_sub<br>14:09 &lt;chromatic&gt; How far can we push HLL complexity into vtable methods for things such as method dispatch and namespaces?<br>14:09 &lt;chromatic&gt; Wow, abstract.<br>14:10 &lt;obra&gt; Ok.<br>14:10 &lt;autrijus&gt; If each PMC is to carry their own HLL metaobject protocol, how should we encode the existing Perl6-MetaModel protocol?<br>14:10 &lt;obra&gt; anyone else got stuff before we go for reports?<br>14:10 &lt;obra&gt; I'm going to pick on... autrijus first.<br>14:11 &lt;obra&gt; Autrijus: what's new?<br>14:11 &lt;autrijus&gt; yo.<br>14:11 &lt;autrijus&gt; been looking at parrot 0.3.0. breaks plenty of PGE tests pugsside<br>14:12 &lt;autrijus&gt; at least one infinite loop, which has been commented out temporarily<br>14:13 &lt;autrijus&gt; (but pmichaud is not here, so moving right along...)<br>14:13 &lt;autrijus&gt; looked at the new callconv. seems mostly sane. plan to push 6.2.10 asap and focus on the metaobject protocol, aka metamodel.<br>14:14 &lt;autrijus&gt; at which point we'd need to encode them on top of the parrot object model. I assume no design changes on that area yet -- woudl be nice to know if there's any to come.<br>14:15 &lt;autrijus&gt; found a neat way to implement full continuations on non-CPS engines. paper author claims will give traditional exception-only VMs the same speed for continuations as the full-CPS VMs such as parrot<br>14:15 &lt;obra&gt; . o O {But it's a bit too complex to describe on an IRC channel right now}<br>14:15 &lt;autrijus&gt; which is great news to perl5 and javascript backends.<br>14:15 &lt;autrijus&gt; yup.<br>14:16 &lt;autrijus&gt; I think that's it for now.<br>14:16 &lt;autrijus&gt; many more besides, but those are the vaguely parrot related<nobr> <wbr></nobr>:)<br>14:16 &lt;obra&gt; ok.<br>14:16 &lt;obra&gt;&nbsp; leo?<br>14:17 &lt;leo&gt; wellknown: merged the trunk or better: Robrt + clkao + svk did it<br>14:17 &lt;leo&gt; released 0.3.0<br>14:18 &lt;leo&gt; implemented utf8 substr aka get_codepoints ak c = u[i]<br>14:18 &lt;leo&gt; started coding towards variable sized register frames<br>14:18 &lt;leo&gt; update DEPRECATED<br>14:19 &lt;leo&gt; a lot of people are looking for a better config/make/install scheme<br>14:19 &lt;leo&gt; rafl got ci bits for<nobr> <wbr></nobr>/debian<br>14:19 &lt;obra&gt; Does parrot currently use autoconf?<br>14:19 &lt;leo&gt; that's it so far<br>14:20 &lt;obra&gt; ok.<br>14:20 &lt;leo&gt; no autoconf et al - its perl only + make<br>14:20 &lt;obra&gt; mdiep?<br>14:20 &lt;mdiep&gt; tcl's [expr] command, which is a significant portion of the language, is now compiled instead of interpreted<br>14:21 &lt;mdiep&gt; tcl itself is on its way to being compiled as well<br>14:21 &lt;mdiep&gt; code has been checked in, but some tests are failing<br>14:21 &lt;mdiep&gt; some of the failures have to do with confusion over pads<br>14:22 &lt;mdiep&gt; that's "it" for this week<br>14:22 &lt;obra&gt; chromatic: what'snew?<br>14:23 &lt;chromatic&gt; I'm going to clean up the one bit in the embedded function generation patch that Leo pointed out and apply that.<br>14:23 &lt;chromatic&gt; I'm also going to check in the BROKEN document to the repository in the next couple of days.<br>14:24 &lt;chromatic&gt; I haven't heard about anyone running CPD over the C code; I'd like to see that (but I don't really have a box that can do it.)<br>14:24 &lt;leo&gt; CPD?<br>14:25 &lt;chromatic&gt; Copy &amp; Paste Detector.&nbsp; It finds identical or very similar code.<br>14:25 &lt;obra&gt; url?<br>14:26 &lt;chromatic&gt; http://pmd.sourceforge.net/cpd.html<br>14:26 &lt;obra&gt; Thanks<br>14:26 &lt;obra&gt; Anything else exciting?<br>14:27 &lt;chromatic&gt; Not here, unless you want to write a hack.<br>14:27 &lt;obra&gt; I do. But that's neither here nor there<nobr> <wbr></nobr>;)<br>14:27 &lt;obra&gt; Ok. Did I miss anybody?<br>14:27 &lt;obra&gt; Oh. I bet nick's on the erl whirl. As might chip.<br>14:28 &lt;obra&gt; Right then. who asked a question that someone here can anser?<br>14:28 &lt;leo&gt; I just start answering<br>14:28 &lt;obra&gt; Go for it, leo<br>14:28 &lt;leo&gt; first Q during report<br>14:28 -!- autrijus_tw [~autrijus@220-133-92-49.HINET-IP.hinet.net] has joined #parrotsketch<br>14:29 &lt;leo&gt; add autrijus : PGE<br>14:29 &lt;autrijus_tw&gt; hey sorry, my keyboard is drinking tea right now<br>14:29 &lt;autrijus_tw&gt; so&nbsp; lost track of the previous ~5min of discussion<br>14:29 &lt;autrijus_tw&gt; &lt;- using some other laptop<br>14:29 &lt;leo&gt; autrijus_tw: I<br>14:29 &lt;autrijus_tw&gt; so, what about PGE?<br>14:30 &lt;leo&gt; just started your PGE answering<br>14:30 &lt;leo&gt; it works in 0.3.0 and did work in the branch<br>14:30 &lt;leo&gt; that means we are lacking tests<br>14:31 &lt;leo&gt; can pugs PGE-related tests be converted to parrot tests?<br>14:31 &lt;autrijus_tw&gt; nod. there was an effort before that converted the pugs/t/rules/rules.t into spec-based tests<br>14:31 &lt;leo&gt; because that'sa parrot core feature, tests should be in parrot<br>14:31 &lt;autrijus_tw&gt; i.e. instead of coding them as code, code them as data<br>14:31 &lt;leo&gt; yup<br>14:31 &lt;autrijus_tw&gt; I fully agree.<br>14:32 &lt;leo&gt; okie - anymore wrt PGE?<br>14:32 &lt;autrijus_tw&gt; no more... you know who will likely be versed in parrot testing and pge to help with the importing?<br>14:33 &lt;autrijus_tw&gt; or should I simply commit the specs (string, regex, expected) into somewhere (where?) in parrot tree<br>14:33 &lt;leo&gt; drop a request at #pugs, #parrot, and p6i please<br>14:33 &lt;leo&gt; code is still better<nobr> <wbr></nobr>;-)<br>14:33 &lt;chromatic&gt; Perhaps post an example of the data to p6i.<br>14:33 -!- autrijus [~autrijus@feather.perl6.nl] has quit [Ping timeout: 260 seconds]<br>14:33 &lt;autrijus_tw&gt; sure, will do.<br>14:34 -!- autrijus_tw is now known as autrijus<br>14:34 &lt;leo&gt; a short note WRT mdiep / tcl/ pads:<br>14:34 &lt;leo&gt; it's an issue of compile vs. runtime<br>14:34 &lt;leo&gt; the initial pad is/was in the compiler so runtime failed<br>14:35 &lt;leo&gt; autrijus: what's the less 'sane' part of new call conv?<br>14:36 &lt;autrijus&gt; leo: I'm thinking about where nameds will/can fit in.<br>14:36 &lt;autrijus&gt; as you know, the majority of pugs's test case used nameds.<br>14:36 &lt;leo&gt; ok - a todo item, chip is pondering alreay<br>14:37 &lt;leo&gt; and also related to lexical handling<br>14:37 &lt;autrijus&gt; okay, I'll stay tuned. in any case a sane pad is far more important.<br>14:37 &lt;autrijus&gt; right, in a sense named parameters can be seen as prebound slots in pads<br>14:37 &lt;leo&gt; ok - that's what I have from the reports<br>14:37 &lt;leo&gt; general questions now?<br>14:37 &lt;obra&gt; sure!<br>14:37 &lt;chromatic&gt; Unless someone codes the implementation backwards and they end up post-bound slots... d'oh.<br>14:38 &lt;leo&gt; chromatic: smoke tests<br>14:38 &lt;autrijus&gt; chromatic: that is the state now, I gather?<nobr> <wbr></nobr>:)<br>14:38 -!- Nicholas [~nwc10@colon.colondot.net] has joined #parrotsketch<br>14:38 &lt;leo&gt; parrot has some tests now<br>14:38 &lt;leo&gt; $ grep smoke Makefile<br>14:38 &lt;chromatic&gt; No, that was me in Pugs.<br>14:38 &lt;leo&gt; make smoke does it all<br>14:39 &lt;chromatic&gt; Are there automatic smoke reports coming from anywhere?<br>14:39 &lt;Nicholas&gt; Sorry, not able to make meeting porperly this week. I'm on pay-through-the-nose wireless on ship. Sitting in Allison's talk. I assume that she's not making it either<nobr> <wbr></nobr>:-)<br>14:39 &lt;chromatic&gt; We talked somewhere, somewhen about stealing something like the Test::TAP::HTMLMatrix idea from Pugs.<br>14:39 &lt;leo&gt; not yet - or parially<br>14:39 &lt;leo&gt; but it's just a matter of 'make smoke'<br>14:39 &lt;leo&gt; which can easilyrun bycron<br>14:40 &lt;leo&gt; end results are:<br>14:40 &lt;leo&gt; http://smoke.parrotcode.org/smoke/<br>14:40 &lt;autrijus&gt; Nicholas: is the talk fun?<nobr> <wbr></nobr>:)<br>14:40 &lt;chromatic&gt; Excellent.<br>14:41 -!- chip [~chip@feather.perl6.nl] has joined #parrotsketch<br>14:41 &lt;leo&gt; need some refinement still, like more ENV vars<br>14:41 &lt;obra&gt; Heya chip.<br>14:41 &lt;chip&gt; So I've recently discovered that my brain is malfunctioning, and I have to bring it in to the shop<br>14:41 &lt;leo&gt; hi chip, Nicholas<br>14:41 &lt;obra&gt; hey chip. I'll send full logs as soon as we're done.<br>14:41 &lt;chip&gt; sorry guys<br>14:41 &lt;chip&gt; thanks.&nbsp; pls carry on<br>14:41 &lt;obra&gt; in the meantime, let's jump back to reports.<br>14:41 &lt;obra&gt; What's new, chip?<br>14:42 &lt;chip&gt; I'm still on 'go' WRT PDDs.&nbsp; It's still a good plan, I just haven't managed to work it into RL.<br>14:42 &lt;chip&gt; Very hopeful for this week, though.<br>14:42 &lt;obra&gt; ok. what can we do to help?<br>14:43 &lt;chip&gt; I can't think of anything offhand, not for this stage...<br>14:44 &lt;Nicholas&gt; autrijus: I am having trouble staying awake, but that's beacuse I'm jetlagged. I think that Allison is having fun<br>14:44 &lt;chip&gt; Well, Hm.<br>14:45 -!- Nicholas [~nwc10@colon.colondot.net] has left #parrotsketch []<br>14:45 &lt;obra&gt; Ok. if that's it for the last week, we've got 15 more minutes for questions.<br>14:45 &lt;obra&gt; What's on the for-chip list from the start of the cchat?<br>14:45 &lt;leo&gt; the lexical pad PDD<nobr> <wbr></nobr>;-)<br>14:46 &lt;autrijus&gt; and nameds.<br>14:46 &lt;leo&gt; name arguments<br>14:46 &lt;leo&gt; argh named<br>14:46 &lt;obra&gt; Start asking full questions<nobr> <wbr></nobr>;)<br>14:47 &lt;chip&gt; Named arguments didn't have a lot in common between Perl 6 and Python<nobr> <wbr></nobr>... is the request that the arg passing should support the Python style?<br>14:47 &lt;chip&gt; or has Perl 6 moved away from the magical pair handling?<br>14:47 &lt;autrijus&gt; I think the consensus is that magical pair is not parrot's business<br>14:48 &lt;autrijus&gt; it may go away together or become the compiler's burden.<br>14:48 &lt;chip&gt; autrijus: OK<nobr> <wbr></nobr>... would Python style named args be helpful for Perl 6, then?<br>14:48 &lt;autrijus&gt; yes.<br>14:48 &lt;chip&gt; OK then.<br>14:48 &lt;chip&gt; Curious: How?<br>14:49 &lt;autrijus&gt; except for perl6, both named and positionals are to be allowed for regular arguments<br>14:49 &lt;autrijus&gt; so if parrot can do that natively, the better.<br>14:49 &lt;chip&gt; I overhufmanned my question.<br>14:49 &lt;chip&gt; "except for perl6"?<br>14:49 &lt;autrijus&gt; "except for the fact that perl6..."<br>14:50 &lt;chip&gt; Well, no matter.&nbsp; If python style is a better base than perl5 style, then it shall be so.<br>14:51 &lt;autrijus&gt; aye.<br>14:51 &lt;chip&gt; ok<br>14:51 &lt;autrijus&gt; also, is the idea that defaulting is to be handled by the compiler?<br>14:52 &lt;chip&gt; yes, you'll just get a flag that says it was passed or not<br>14:52 &lt;autrijus&gt; I vaguely remember in Leo's place it was said so, not sure if it had changed.<br>14:52 &lt;autrijus&gt; right.<br>14:52 &lt;autrijus&gt; sure, that works.<br>14:52 &lt;chip&gt; ok<br>14:52 &lt;autrijus&gt; so will&nbsp; nameds andpositionals be simply bound into the static lexical pad?<br>14:52 &lt;chip&gt; the existing feature is good for working on that, you can't pass by name, but you can currently generate default-value assignment<br>14:52 &lt;autrijus&gt; our current design is taking that as basic assumption.<br>14:53 &lt;chip&gt; autrijus: I'm still thinking that the pad binding is the compiler's job; the arg passing will go into registers as now.<br>14:53 &lt;autrijus&gt; okay, but then I'd like a way to name those registers<nobr> <wbr></nobr>:)<br>14:53 &lt;chip&gt; autrijus:<nobr> <wbr></nobr>.local<nobr> <wbr></nobr>.param<nobr> <wbr></nobr>... ?<br>14:53 &lt;autrijus&gt; name as in walkable padlike things<br>14:54 &lt;autrijus&gt; but<nobr> <wbr></nobr>::CALLER::* support can wait, I guess.<br>14:54 &lt;chip&gt; well, consider that if you get a bunch of registers, you can store them yourself, and there's no loss (or gain<nobr> <wbr></nobr>:-)) of %CALLER support<br>14:55 &lt;autrijus&gt; ah right, but that kind of requires var-sized register frames<br>14:55 &lt;autrijus&gt; which is the plan already. right.<nobr> <wbr></nobr>:)<br>14:55 &lt;autrijus&gt; that's it for this stage I think... we'll see what comes when during targeetting.<br>14:57 &lt;autrijus&gt; (eof) (but I'd like to ask chromatic what he meant by 'porting' PIL)<br>14:58 &lt;chromatic&gt; Making native Parrot datastructures.<br>14:58 &lt;chromatic&gt; PMCs or PMC Objects.<br>14:58 &lt;obra&gt; (And after that, I'd like to wrap up unless there's something else)<br>14:58 &lt;autrijus&gt; er I did post that.<br>14:59 &lt;chromatic&gt; I must have missed it; I'll look for it again.<br>14:59 &lt;autrijus&gt; I mean, there's a dumper from haskell structure to PIR in pugs tree, and I posted the ParrotObject notation for PIL during YAPCNA<br>15:00 &lt;chromatic&gt; PIL or PIL2 or is there a difference now?<br>15:01 &lt;autrijus&gt; there is. PIL is the one currently targetting JS/P<br>15:01 &lt;autrijus&gt; JS/perl five<br>15:02 &lt;autrijus&gt; it's the "dynamic" part of perl6<br>15:02 &lt;autrijus&gt; and I think I'll not tweak it too much for this current runcore<br>15:02 &lt;autrijus&gt; it does not have the notion of types.<br>15:02 &lt;autrijus&gt; not more than a label, that is<br>15:03 &lt;autrijus&gt; so is insufficient to represent type-annotated perl6<br>15:03 &lt;autrijus&gt; but should otherwise be fine.<br>15:03 &lt;obra&gt; Anybody got anything else burning?<br>15:04 &lt;autrijus&gt; chromatic: even if you get the PIL objects, it's unlikely you can do anything with it<nobr> <wbr></nobr>:)<br>15:05 &lt;chromatic&gt; awwww<br>15:05 &lt;autrijus&gt; without some sort of visitor / tree manipulation engine -- otherwise known as AG<br>15:06 &lt;autrijus&gt; (you can also write them all by hand, but it's not advised)<br>15:06 &lt;autrijus&gt; not with PIR assembly anyway.<br>15:06 &lt;autrijus&gt; but if you'd like to take a try, you can start by adding DrIFT.ParrotObject<br>15:07 &lt;autrijus&gt; so you can take Perl6 code and emit object trees.<br>15:07 &lt;autrijus&gt; that will give the PIR-side something to play with<br>15:07 &lt;autrijus&gt; eof.<br>15:08 &lt;leo&gt; I still have a longish list of answers - should I continue?<br>15:08 &lt;obra&gt; leo: go for it<br>15:08 &lt;obra&gt; We like answers<br>15:08 &lt;leo&gt; chromatic: final note WRT 'make smoke':<br>15:08 &lt;leo&gt; it's of course stolen^Wborrowed from pugs<br>15:09 &lt;leo&gt; and is using Test::TAP::HTMLMatrix<br>15:09 &lt;leo&gt; thx to nothingmuch<br>15:09 &lt;leo&gt; mdiep: events<br>15:10 &lt;leo&gt; parrot has already event handling at least on POSIX<br>15:10 &lt;leo&gt; it's used e.g. for C (NCI) callback functions<br>15:10 &lt;leo&gt; because you don't know, when C calls parrot<br>15:10 &lt;leo&gt; events are also used for C&lt;sleep&gt; and timers<br>15:11 &lt;leo&gt; but it's all experimental<br>15:11 &lt;leo&gt; does that cover it?<br>15:12 &lt;leo&gt; ok next Q in my list:<br>15:13 &lt;leo&gt; mdiep: when will DEPRECATED be resolved<br>15:13 &lt;leo&gt; RSN - that's it<nobr> <wbr></nobr>;-)<br>15:13 &lt;obra&gt; Ok<nobr> <wbr></nobr>:)<br>15:14 &lt;leo&gt; Q: autrijus UUAG ? L::AG - who does it?<br>15:14 &lt;leo&gt; I think it's molstly a compiler thingy<br>15:14 &lt;chromatic&gt; Luke Palmer wrote the P5 version.&nbsp; Patrick and I are watching in anticipation.<br>15:14 &lt;leo&gt; parrot classes are created during runtime<br>15:14 &lt;leo&gt; so whatever the compiler produces, it should work<br>15:14 &lt;autrijus&gt; leo: http://www.cs.uu.nl/wiki/Center/AttributeGrammarSystem<br>15:15 &lt;autrijus&gt; it's the Haskell AG system that luqui is modelling the L::AG after<br>15:15 &lt;leo&gt; I've to go through it<br>15:16 &lt;autrijus&gt; I'm inclined to use it for pugs compilation<br>15:16 &lt;leo&gt; I don't think that folks want to write L::AG in PIR<br>15:16 &lt;leo&gt; I think it's like a lib<br>15:16 &lt;autrijus&gt; because then the compiler code will be more portable to perl6, if it supports AG natively and well.<br>15:16 &lt;chromatic&gt; I prefer to write in PIR than C, for most things.<br>15:16 &lt;autrijus&gt; but you can't link in Perl libraries.<br>15:16 &lt;autrijus&gt; not easily anyway.<br>15:17 &lt;autrijus&gt; I also think linking in C is an attractive optin (there are code in antlr and other plces)<br>15:18 &lt;leo&gt; and runtime in parrot is also compile time, *if* a sub is marked with IMMEDIATE, which could help during compilation<br>15:18 &lt;autrijus&gt; but if chromatic and pmichaud prefers coding it up again with PIR, it's fine with me too, but hopefully we'll get reasonable efficiency.<br>15:18 &lt;autrijus&gt; (we had to recommend against using PGE in ext/* code mostly due to efficiency reasons.)<br>15:18 &lt;chromatic&gt; I think Allison wants the option to have these tools in PIR, at least.<br>15:19 &lt;autrijus&gt; *nod*. I'll leave it at that.<nobr> <wbr></nobr>:)<br>15:19 &lt;leo&gt; I've to look at the p5 code first, but it's probably not too easy to write all in just PIR<br>15:20 &lt;chromatic&gt; Dunno.&nbsp; I've ported well-designed P6 code to PIR and it wasn't too bad in most places.<br>15:21 &lt;leo&gt; yep, but when it comes to expressions it's ugly and boring<br>15:21 &lt;leo&gt; OO code works fine<br>15:21 &lt;leo&gt; ok to go to next Q?<br>15:22 &lt;chromatic&gt; Okay by me.<br>15:22 &lt;leo&gt; mdiep: add_sub vs. add_method - the former doesn't exist, the latter is an opcode<br>15:22 &lt;leo&gt; add_sub is covered by store_global / store_lexical<br>15:23 &lt;leo&gt; and:<br>15:23 &lt;leo&gt;<nobr> <wbr></nobr>.sub foo<br>15:23 &lt;leo&gt; does the right thing<br>15:23 &lt;leo&gt; it stores the sub 'foo' in the active namespace<br>15:23 &lt;leo&gt; I think that should cover all use cases<br>15:24 &lt;leo&gt;<nobr> <wbr></nobr>.sub foo<nobr> <wbr></nobr>:anon<br>15:24 &lt;leo&gt; and you don't get the namespace entry<br>15:25 &lt;leo&gt; I think it's just a compiler issue<br>15:25 &lt;leo&gt; and related final 2 on my list:<br>15:26 &lt;leo&gt; HLL abstraction / MetaModel and such<br>15:26 &lt;leo&gt; parrot's primary target is Perl6<br>15:26 &lt;leo&gt; the metamodel should cover a lot of p6, e.g. MMD<br>15:27 &lt;leo&gt; if we need different core behavior for e.g. p6 vs python, we can still event HLL PMCs where we abstract the differing thingies<br>15:27 &lt;leo&gt; (eof)<br>15:28 &lt;obra&gt; Ok.<br>15:28 &lt;obra&gt; any more?<br>15:29 &lt;obra&gt; Right then.<br>15:29 &lt;leo&gt; s/event/invent/ above pls<br>15:29 &lt;obra&gt; I'll catch you all next week. Same bat-time.<br></tt> jesse 2005-10-03T20:08:13+00:00 journal Parrot Sketch: Aug 29 http://use.perl.org/~jesse/journal/26997?from=rss <tt>13:56 &lt;chip&gt; hi ho<br>13:56 &lt;mdiep&gt; howdy, chip. glad you could make it this week.<br>13:56 &lt;chip&gt; thanks.&nbsp; glad my normality index has increased somewhat<nobr> <wbr></nobr>:-)<br>13:57 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>14:04 &lt;@obra&gt; Hi all<br>14:04 &lt;chromatic&gt; Hello.<br>14:04 &lt;@obra&gt; chromatic has agreed to deal with moderating on my behalf today.<br>14:04&nbsp; * obra is frantically packing for braga<br>14:04 &lt;leo_&gt; hi all<br>14:05 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has joined #parrotsketch<br>14:05 &lt;chip&gt; obra: jealously.&nbsp; I'm packing to move.&nbsp; Much less fun<br>14:05 &lt;chip&gt; s/ly/y/<br>14:06 &lt;chromatic&gt; Cross-country?<br>14:07 &lt;chip&gt; chromatic: Indeed.&nbsp; I'll _almost_ be back in my cellphone's 707 area code.<br>14:07 &lt;chip&gt; chromatic: Instead, I'll be living in the East Bay and commuting to SF<br>14:08 &lt;chromatic&gt; By choice?<br>14:09 &lt;chip&gt; which part?&nbsp;<nobr> <wbr></nobr>:-)&nbsp; I like the SF part, I don't mind the commute, and East Bay has other benefits (GF's old stomping ground, she has<br>plans there)<br>14:09 &lt;chip&gt; Pennsylvania, or as we call it "The Fool's Paradise", will not be missed<br>14:10 &lt;chromatic&gt; I guess you're tired of living in that Precious Moments figurine factory.<br>14:11 &lt;chip&gt; to get to my sister's place, I drive by The Franklin Mint.&nbsp; I can _smell_ the pewter.<br>14:11 &lt;chromatic&gt; Minty fresh.<br>14:11 &lt;chip&gt; So, are we self-organizing today, or is Jesse riding herd?<br>14:11 &lt;chromatic&gt; I'm in charge.&nbsp; It's 10 after, so we have everyone timely.<br>14:11 &lt;@obra&gt; "chromatic has agreed to deal with moderating on my behalf today."<br>14:11 &lt;chip&gt; oh, wait, I missed that big.&nbsp; chromatic's the boss<br>14:12 &lt;chip&gt; s/big/bit/<br>14:12 &lt;chromatic&gt; chip's first in the sorting order.&nbsp; What's new?<br>14:12 &lt;chip&gt; I'm<nobr> <wbr></nobr>... let's see<nobr> <wbr></nobr>... 63% through the diff between trunk and leo-ctx5 branch<br>14:12 &lt;chip&gt; I'm writing up the comments on the way.<br>14:13 &lt;chip&gt; So far, no major surprises<nobr> <wbr></nobr>... I see a merge before 1 sep release.<br>14:13 &lt;pmichaud&gt; oh, that would be *excellent*<br>14:13 -!- mdiep [~matt@c-24-11-80-190.hsd1.mi.comcast.net] has quit [Quit: mdiep]<br>14:13 &lt;chromatic&gt; And soon.<br>14:13 &lt;chromatic&gt; How much breakage will there be in the libraries and tools and docs?<br>14:14 &lt;leo_&gt; python stops working<br>14:14 &lt;leo_&gt; tcl is being worked on - one bug lurking but known<br>14:14 &lt;leo_&gt; PGE is fine<br>14:15 &lt;leo_&gt; that's it as far as I know<br>14:15 &lt;chip&gt; IIRC, for other outside-the-tree code: anything that generates PIR that uses the<nobr> <wbr></nobr>.pcc_* macros for call &amp; return won't even notice<br>the calling convention change.&nbsp; But if it assumes that it knows that P2, P5, etc. have special meanings<nobr> <wbr></nobr>...<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;_boom_<br>14:16 &lt;chip&gt; only a couple PIR things in the branch need changing<br>14:16 &lt;chromatic&gt; How far gone is Python?<br>14:16 &lt;leo_&gt; yep - or PIR code like the 2 failing streams tests, that just assume P2 is unchanged for the next method call<br>14:16 &lt;chip&gt; implicit $self.&nbsp; heh<br>14:16 &lt;leo_&gt; python is a bit of a problem<br>14:17 &lt;leo_&gt; tewk is working on it<br>14:17 -!- mdiep [~matt@c-24-11-80-190.hsd1.mi.comcast.net] has joined #parrotsketch<br>14:17 &lt;mdiep&gt; ack. my keyboard stopped working. I had to restart.<br>14:17 &lt;chromatic&gt; Anything else, chip?<br>14:17 &lt;leo_&gt; but he is more inclined to redo the old code with new calling conventions<br>14:17 &lt;chromatic&gt; When's the move?<br>14:17 &lt;chip&gt; I don't know enough Python to have followed Sam &amp; tewk's comments.&nbsp; Is it all about Python adapting to Parrot, or do we have to do<br>something for them?<br>14:17 &lt;leo_&gt; but Sam didn't use interface code<br>14:18 &lt;leo_&gt; he redid call stuff in his PMCs<br>14:18 &lt;leo_&gt; AFAIK currying i.e. BoundMethod<br>14:18 &lt;chip&gt; chromatic: Right around 15 Sep.&nbsp; This is packing week, next week is moving heavy objects into crates week.&nbsp; door2doormoving++<br>14:18 &lt;mdiep&gt; I think at the end of the thread, Sam's concerns were performance related<br>14:19 &lt;chip&gt; And his currying impl isn't friendly with the new coventions?<br>14:19 &lt;leo_&gt; well, his code runs at 1/10th of speed compare to my Piethon code<br>14:19 &lt;leo_&gt; the currying implementation was basically fine but:<br>14:19 &lt;chip&gt; Sam's going to go for correctness first, and will be uninclined to cheat in any way.&nbsp; Python people by and large apparently don't<br>believe in cheating<nobr> <wbr></nobr>:-,<br>14:20 &lt;leo_&gt; moving P6&lt;-P5, P5&lt;-P2 just doesn't work anymore<br>14:21 &lt;leo_&gt; and most of this stuff was also related to the out-of-band passing of the object<br>14:21 &lt;leo_&gt; but currying needs either an interface (shift_args) or Parrot support<br>14:22 &lt;leo_&gt; f = o.meth<br>14:22 &lt;leo_&gt; f(2)<br>14:22 &lt;leo_&gt; this is a method call<br>14:22 &lt;leo_&gt; o.f(2)<br>14:22 &lt;leo_&gt; in two steps<br>14:22 &lt;chip&gt; OK, so it seems that in the absence of support to make it faster, it's possible to slurp the params, unshift the resulting array,<br>then call with flatten.&nbsp; So there's a way forward without any work on our part (yet)<br>14:23 &lt;leo_&gt; yes - one indirection throug a PIR helper function does it of course too<br>14:23 &lt;chip&gt; OK.&nbsp; chromatic: I have two notes about the PIR language that I could go into a bit, or not, your call<br>14:24 &lt;chromatic&gt; Go ahead.<br>14:24 &lt;chip&gt; OK<br>14:24 &lt;pmichaud&gt; I'd like to hear them<br>14:24 &lt;chip&gt; pmichaud: you and leo were the ones I knew would<br>14:24 &lt;chip&gt; I mentioned a while ago, but I see it hasn't happened yet, that<nobr> <wbr></nobr>:opt_count is a bad semantic for noting that optionals are missing<br>14:25 &lt;chip&gt; I want to remove it in favor of<nobr> <wbr></nobr>:opt_flag, where you get one boolean per optional parameter (that you care about) rather than an<br>integer<br>14:25 &lt;chip&gt; Someday we might have named parameter support, and if we do, the count isn't expressive enough - it doesn't tell you e.g. _which_<br>three optionals are present<br>14:26 &lt;chip&gt; I think this needs to be fixed before release, if not before merge<br>14:26 &lt;chip&gt; pmichaud: AFAICT, this is a SMOP for you<br>14:27 &lt;leo_&gt; I think - if you care which optional is missing, you pass one<nobr> <wbr></nobr>:opt_count per<nobr> <wbr></nobr>:optional<br>14:27 &lt;pmichaud&gt; chip: that's correct -- it doesn't matter much to me which approach is taken; just so long as I know which<nobr> <wbr></nobr>:-)<br>14:28 &lt;chip&gt; leo_: Named parameter passing means that arg processing isn't necessarily sequential - given&nbsp; sub foo(?$a,?$b,?$c), there's no<br>guarantee that $a is processed before $b and $c.&nbsp; Therefore, the left-to-right semantic implied by<nobr> <wbr></nobr>:opt_count is<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;wrong<br>14:29 &lt;chip&gt; So that's the first thing<br>14:29 &lt;chip&gt; The other thing is even easier to fix.&nbsp; I want the attributes on sub definitions to have sigils, not just be plain words.<br>14:30 &lt;leo_&gt; hmm, it might need 2 passes, but I think I still can fill an<nobr> <wbr></nobr>:opt_count correctly<br>14:30 &lt;chip&gt; leo_: I prefer to avoid forcing the introduction of the second pass<br>14:31 &lt;leo_&gt; ok, yes - if it is avoidable, then fine<br>14:31 &lt;chip&gt; what's currently spelled C&lt;<nobr> <wbr></nobr>.sub "foo" @MULTI(_,int) method &gt;&nbsp; should be spelled C&lt;<nobr> <wbr></nobr>.sub "foo"<nobr> <wbr></nobr>:multi(_,int)<nobr> <wbr></nobr>:method &gt;.&nbsp; But for now,the legacy spelling "@MULTI" will continue to work<br>14:32 &lt;leo_&gt; that's fine with me<br>14:32 &lt;chip&gt; oh, the current spelling may require commas between, I don't know, but there shouldn't be any commas<nobr> <wbr></nobr>... the sigils are the visual<br>separation<br>14:33 &lt;chip&gt; Anyway, that's pretty much it for deltas from leo-ctx5's PIR to what I want to see.<br>14:33 &lt;chip&gt; Well, except for the old things not yet done,<br>14:33 &lt;chromatic&gt; Is _ now the "I don't care which parameter this is" marker?<br>14:33 &lt;chip&gt;&nbsp; &nbsp;... like forbidding "$P0 = opcode" when the opcode does _not_ actually set its first parameter<br>14:33 &lt;leo_&gt; yep it's Any<br>14:33 &lt;chromatic&gt; Wow, now i know three languages where that's the case.<br>14:34 &lt;chromatic&gt; Anything else, chip?<br>14:35 &lt;chip&gt; Nope, that's it<br>14:35 &lt;chromatic&gt; leo?<br>14:35 &lt;leo_&gt; progress with SoC<br>14:36 &lt;chromatic&gt; When's the due date?<br>14:36 &lt;leo_&gt; Nattfodd is getting near 100% tests<br>14:36 &lt;leo_&gt; Sept 1th<br>14:36 &lt;chromatic&gt; Is everything on track to make it?<br>14:36 &lt;leo_&gt; but he only now is checking that he did some unneeded stuff in the beginning of the project<br>14:37 &lt;leo_&gt; yes should work out fine<br>14:37 &lt;leo_&gt; the 2nd guy is working on imcc optimizations<br>14:38 &lt;leo_&gt; his recent patch is on the list (p6i) for review<br>14:39 &lt;leo_&gt; not much else - preparing for Braga, leaving tomorrow morning<br>14:39 &lt;leo_&gt; ah and I found the 'last' bug in the branch that is currently killing tcl<br>14:40 &lt;leo_&gt; but it isn't fixed yet<br>14:40 &lt;leo_&gt; eof<br>14:41 &lt;chromatic&gt; Thanks, leo.&nbsp; Matt?<br>14:42 &lt;mdiep&gt; I've mostly been working on catching up on Real Life(tm) after moving in at school. I spent last night understanding the Python<br>thread and today I started compiling the namespace requirement information.<br>14:43 &lt;mdiep&gt; I hope to have an email out to the list in a few days time detailing what information is required from different languages<br>14:43 &lt;mdiep&gt; after that I will begin to work on a proposal for making that information available<br>14:43 &lt;chromatic&gt; Native Parrot support for HLL namespaces?<br>14:44 &lt;mdiep&gt; yes. some of which will be conventions for compiler writers.<br>14:44 &lt;chromatic&gt; Sounds good.<br>14:45 &lt;mdiep&gt; I'm not sure what's currently in place in Parrot or what's going to stay.<br>14:45 &lt;chromatic&gt; It'll be easier to say with an overview of HLL needs.<br>14:45 &lt;mdiep&gt; which leads me to the question I have: what do we know is missing and what do we know has to get redone in Parrot?<br>14:46 &lt;chip&gt; from namespaces, you mean?<br>14:46 &lt;mdiep&gt; I think it was said that the lexical implementation was broken<br>14:46 &lt;mdiep&gt; no, I mean overall<br>14:46 &lt;chip&gt; Jeepers.<br>14:46 &lt;mdiep&gt; it'd be nice to have a list of things we know aren't working<br>14:46 &lt;chip&gt; This is the question I want in writing ahead of time.&nbsp;<nobr> <wbr></nobr>:-/<br>14:46 &lt;chromatic&gt; chip, Autrijus mentioned the lexical stuff at YAPC.<br>14:47 &lt;chromatic&gt; I believe you said "jeepers" there too.<br>14:47 &lt;chip&gt; grr<br>14:47 &lt;chip&gt; That's a different kind of jeepers.<br>14:47 &lt;chromatic&gt; Should there be a "Call for B0rked" message on p6i?<br>14:47 &lt;mdiep&gt; is any of this documented anywhere? can we document them somewhere if it's not? does anyone have a mental list?<br>14:48 &lt;chromatic&gt; A parent RT ticket?<br>14:48 &lt;chip&gt; I have serious concerns about depending on RT<br>14:48 &lt;mdiep&gt; I'd prefer that chip pick where he'd like it to be. (I've heard that he has concerns<nobr> <wbr></nobr>:-)<br>14:48 &lt;chip&gt; It's not that RT is bad, but the interface is bad, in the manner of Bugzilla<br>14:48 &lt;chromatic&gt; Is there a single place for this information that you find preferable?<br>14:49 &lt;chip&gt; I've had three different answers typed &amp; removed.<br>14:50 &lt;chip&gt; RT is good for bugs, as long as someone else is maintaining dependency info<br>14:50 &lt;chip&gt; bug dependency manipulation is a clickfest.<br>14:50 &lt;chromatic&gt; If someone else handles that, is it workable?<br>14:50 &lt;mdiep&gt; something in docs?<br>14:51 &lt;chip&gt; As for missing features and features that might as well be missing (see "lexicals"), RT is OK too, I guess<br>14:51 &lt;chip&gt; Again, if someone else is doing the dep thing<br>14:51 &lt;chromatic&gt; Alright, I'll see if Will Coleda is open to the idea.<br>14:51 &lt;chip&gt; "Call for B0rked" works, as long as it's filtered for redundancy &amp; correctness ("oh, we fixed that")<br>14:52 &lt;mdiep&gt; who is doing the filtering?<br>14:52 &lt;chip&gt; well, whoever posts the question.&nbsp;<nobr> <wbr></nobr>:-)<br>14:52 &lt;chromatic&gt; Presumably anyone who can say "It works now" with authority.<br>14:53 &lt;chip&gt; chromatic: I think that's input to the filtering, right?<br>14:53 &lt;chromatic&gt; You see the finger, I see the moon.<br>14:53 &lt;chip&gt; heh<br>14:53 &lt;chromatic&gt; Anything else, Matt?<br>14:54 &lt;pmichaud&gt; can I throw in a couple of off-the-wall comments here, about RT?<br>14:54 &lt;chromatic&gt; Sure.<br>14:54 &lt;pmichaud&gt; Personally, I find RT to be a bit of a pain to use<br>14:54 &lt;mdiep&gt; seconded.<br>14:54 &lt;chromatic&gt; I believe Jesse has an intern working on upgrading the Perl.org installation to a newer version.<br>14:54 &lt;pmichaud&gt; beyond that, I find myself wishing for the equivalent of pugs' "smoke test", where we can get a graphical view of what needs to<br>be done<br>14:55 &lt;chromatic&gt; The HTML view?<br>14:55 &lt;pmichaud&gt; yeah<br>14:55 &lt;pmichaud&gt; and part of me wonders if we could get somewhere by using the repository as the official ticket log (more)<br>14:55 &lt;pmichaud&gt; i.e., if our "to do list" could in fact be "to do" tests in the repo<br>14:55 &lt;pmichaud&gt; so they'd show up in the smoke test graph<br>14:56 &lt;pmichaud&gt; even if the test isn't code, it could just be a failure marker of some sort ("it's been reported that xyz doesn't work")<br>14:56 &lt;chromatic&gt; It'd have to be easier to write TODO tests, but Parrot::Test does support those.<br>14:56 &lt;chip&gt; "doesn't"?<br>14:56 &lt;chromatic&gt; Filter: I added TODO support to Parrot::Test a couple of months ago.<br>14:57 &lt;chromatic&gt; I think the only necessary part is convincing someone to run nothingmuch's harness against Parrot tests on a regular basis and<br>post the results.<br>14:57 &lt;pmichaud&gt; I'm not sure how we would mark dependencies, and it would mean that new tickets could only be entered by committers, but somehow<br>that just seems like it'd be another way to maintain a task list<br>14:57 &lt;chip&gt; I vote for executable information in the form of TODO tests, rather than human-only info like a TODO doc<br>14:57 &lt;mdiep&gt; I think there may be an issue in that some of our todo list is HLL design issues. for instance, namespaces are a todo item, but I<br>don't think we can really write a test for that currently.<br>14:58 &lt;chip&gt; mdiep: not yet.&nbsp; you need at least the PIR spec for them before you can write a test<br>14:58 &lt;chromatic&gt; fail( "namespaces not designed", todo =&gt; 1 );<br>14:58 &lt;chip&gt; well, there _is_ that.<br>14:58 &lt;leo_&gt; t/pmc/namespace.t<br>14:58 &lt;pmichaud&gt; I'd always prefer an executable TODO test as well, but when that's not available we still need somewhere to record things that<br>need to be done/fixed/whatever<br>14:59 &lt;chromatic&gt; Alright, let's say that we need to talk to #perl6 about stealing their smoke testing ideas.<br>14:59 &lt;chip&gt; pmichaud: quite, but it would seem it _is_ available, so<nobr> <wbr></nobr>...?<br>14:59 &lt;chromatic&gt; Perhaps we can piggyback on that.<br>14:59 &lt;chip&gt; we stole their commitbot, so why not keep going back for more?<br>14:59 &lt;chromatic&gt; Patrick, anything to report?<br>14:59 &lt;pmichaud&gt; it is just a thought I had.&nbsp; Somehow I like working in vi and the repository much better than firefox and rt's web interface<br>15:00 &lt;pmichaud&gt; I interrupted matt -- does matt have anything else first?<br>15:00 &lt;chip&gt; pmichaud: at some point, _someone_ is going to write RT::Mechanize.<br>15:00 &lt;mdiep&gt; no, that covers things for me. I will probably contribute to "Call for B0rked" though. (by the way, who is sending that? me?)<br>15:01 &lt;pmichaud&gt; chip: that's fine -- I'll be fine with using RT if that's the way to do it, but it often just feels like there ought to be a<br>better way.&nbsp; And I would like to be able to more easily see the outstanding issues in some way that is directly<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;tied to the repository.&nbsp; (end of rt diversion)<br>15:01 &lt;chromatic&gt; Matt, if you want to write it feel free.&nbsp; If not, I'll do it.<br>15:01 &lt;mdiep&gt; chromatic: if you're volunteering, go ahead.<nobr> <wbr></nobr>:-)<br>15:02 &lt;chromatic&gt; Well foo.<br>15:03 &lt;pmichaud&gt; so, is it back to me?<br>15:03 &lt;mdiep&gt; yes<br>15:03 &lt;mdiep&gt; yes<br>15:04 &lt;pmichaud&gt; well, not much happened for me parrot-wise in august; I had a (contracted) project that the other team members thought we could<br>finish in 4 days but turned into a 14 day marathon<br>15:04 &lt;pmichaud&gt; plus trips to corpus christi and nasa stennis space center in mississippi<br>15:04 &lt;pmichaud&gt; culminating in the delivery of a trailer full of equipment last wednesday, which is probably on its side as of this morning<nobr> <wbr></nobr>:-(<br>15:04 &lt;chromatic&gt; PUGS... IN... SPACE!&nbsp; (sorry)<br>15:06 &lt;pmichaud&gt; I'm glad to hear that we're getting to the leo-ctx5 merge with the trunk, that will make things a lot simpler (and more stable<br>for me)<br>15:06 &lt;pmichaud&gt; I still have yet to check in the operator-precedence parser (I need to update the docs a bit), and since we have the new calling<br>conventions that changes things slightly there so will update that at the time of the merge<br>15:06 &lt;chromatic&gt; How stable is that parser?<br>15:07 &lt;pmichaud&gt; it should be fairly stable but it needs a lot more testing<br>15:07 &lt;chromatic&gt; Sounds good.<br>15:07 &lt;pmichaud&gt; and its calling interface is likely to change somewhat over the first few revisions<br>15:08 &lt;chromatic&gt; What comes after the parser?<br>15:08 &lt;pmichaud&gt; parsing expressions, and probably a simple p6 expression interpreter<br>15:08 &lt;pmichaud&gt; I think I'll work on a p6 interpreter in parallel with working on the tree transformation language issues for the compiler<br>15:09 &lt;chromatic&gt; Larry's working on the interface side of TTL.&nbsp; I think he'll end up unifying it with rules.<br>15:09 &lt;pmichaud&gt; oh, I missed that in the notes (I'm behind on p6 mailing lists); that will be very very helpful<br>15:09 &lt;pmichaud&gt; I'm glad he's doing it and not me<nobr> <wbr></nobr>:)<br>15:10 &lt;chromatic&gt; Ditto.<br>15:10 &lt;chip&gt; do I want to ask what TTL is?<br>15:10 &lt;chip&gt; transistor-transistor logic, yeah<br>15:10 &lt;pmichaud&gt; TTL -- tree transformation language -- the stuff we talked about on saturday at oscon and then shelved as needing more research<br>15:10 &lt;chip&gt; forgot its name, OK<br>15:11 &lt;pmichaud&gt; I'll be very happy to let the language designer design that part of the language and tool suite<nobr> <wbr></nobr>:-)<br>15:11 &lt;pmichaud&gt; I'll implement it, but it'll be easier to work from a draft language spec than to design the language spec at the same time<br>15:11 &lt;chromatic&gt; Anything else, Patrick or anyone?<br>15:12 &lt;pmichaud&gt; the only other thing I'll look at is using PGE to be able to parse PGE expressions, so that it'll be easier to parse p6 rules<br>from other sources (e.g., pugs)<br>15:12 &lt;pmichaud&gt; i.e., PGE needs a built-in rule that can parse a p6 expression<nobr> <wbr></nobr>:)<br>15:12 &lt;pmichaud&gt; s/p6/p6rule/<br>15:13 &lt;pmichaud&gt; that's it for me<br>15:14 &lt;chromatic&gt; Sounds good.&nbsp; I'll summarize the summaries and the available tasks and send out an e-mail later today.<br>15:14 &lt;chip&gt; thanks<br>15:14 &lt;mdiep&gt; great. thanks, chromatic.<br>15:14 &lt;pmichaud&gt; excellent, thanks<br>15:14 &lt;leo_&gt; thx2<br>15:15 &lt;chromatic&gt; That's all.&nbsp; See you again next week.<br>15:15 &lt;@obra&gt; pmichaud: perl.org is robert spier's RT, not mine<br>15:15 &lt;@obra&gt; rt.cpan is what my interns are updating<nobr> <wbr></nobr>;)<br>15:15 &lt;pmichaud&gt; obra: okay<br>15:16 &lt;chromatic&gt; My mistake.<br>15:16 &lt;@obra&gt; no worries.<br>15:16 &lt;@obra&gt; but tell us what sucks and we'll try to improve it anyway<br>15:16 &lt;@obra&gt; you know there's a CLI for rt.perl.org?<br>15:17 &lt;chip&gt; I don't know why rspier is keeping rt.perl.org back<br>15:17 &lt;chip&gt; If he refuses to update, is the bug database portable to another RT instance?<br>15:23 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has quit [Quit: Chatzilla 0.9.68.5 [Firefox 1.0.6/20050716]]<br>15:30 &lt;@obra&gt; chip: he's amenable to updating.<br>15:30 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has quit [Quit: Leaving]<br>15:31 &lt;chip&gt; ok<br>15:53 -!- mdiep [~matt@c-24-11-80-190.hsd1.mi.comcast.net] has left #parrotsketch []<br>15:59 -!- chip [~chip@ts3-126.twistspace.com] has left #parrotsketch []<br>16:10 -!- leo_ [~lt@ts3-126.twistspace.com] has left #parrotsketch []<br></tt> jesse 2005-10-03T19:52:59+00:00 journal Parrot Sketch: Aug 22 http://use.perl.org/~jesse/journal/26996?from=rss <tt>13:14 -!- autrijus [~autrijus@220-132-132-105.HINET-IP.hinet.net] has joined #parrotsketch<br>13:14 &lt;autrijus&gt; due in 1hr?<br>13:15 &lt;autrijus&gt; obra: hi, btw.<br>13:45 -!- Nicholas [~nwc10@colon.colondot.net] has joined #parrotsketch<br>13:47 &lt;autrijus&gt; greetings Nicholas-san<br>13:48 &lt;Nicholas&gt; hello<br>13:48 &lt;autrijus&gt; I'm finally finishing up gruesome $work tomorrow.<br>13:48 &lt;autrijus&gt; so less workload and more time for pugs.<br>13:49 &lt;Nicholas&gt; and less AIX?<br>13:49 &lt;autrijus&gt; and less AIX. parsec + catalyst proved to be a very effective combination of manipulexity and whipuptitude.<br>13:49 &lt;Nicholas&gt; I just feel shattered<br>13:49 &lt;autrijus&gt; with sqlite3 being the common interchange.<br>13:49 &lt;Nicholas&gt; candice (blech's wife) noticed this afternoon<br>13:49 &lt;autrijus&gt; shattered how?<br>13:49 &lt;Nicholas&gt; I think I need a break. Er, I know I need a break<br>13:49 &lt;Nicholas&gt; tired. burnt out<br>13:49 &lt;autrijus&gt; ^C<br>13:49 &lt;Nicholas&gt; I just need to coax Mark into agreeing<br>13:50 &lt;Nicholas&gt; problem is he seems shattered<br>13:50 &lt;Nicholas&gt; he went home with a cough<br>13:50 &lt;autrijus&gt; oh. you may need ^\ then.<br>13:50 &lt;Nicholas&gt; but he was ill on Friday with a massive headache<br>13:50 &lt;Nicholas&gt; and he's not been seeming very with it recently<br>13:50 &lt;autrijus&gt; yow.<br>13:52 &lt;autrijus&gt; this neko thing helped me put things in perspective.<br>13:52 &lt;Nicholas&gt; in what way? It's another VM, isn't it?<br>13:52 &lt;autrijus&gt; aye, but one with less maturity and forethought<br>13:53 &lt;Nicholas&gt; oh ah right. How so?<br>13:53 &lt;autrijus&gt; I'm also playing with YARV.<br>13:53 &lt;autrijus&gt; well, the author thinks neko is a much higher level vm than parrot<br>13:53 &lt;autrijus&gt; mostly because PIR doesn't handle nested expressions and neko's does.<br>13:53 -!- leo_ [~lt@ts3-126.twistspace.com] has joined #parrotsketch<br>13:53 &lt;Nicholas&gt; a small matter of a parser?<br>13:54 &lt;autrijus&gt; hm, not really, because you need an internal language too.<br>13:54 &lt;autrijus&gt; the rumoured past thing<br>13:54 -!- mdiep_ [~mdiep@cpe-24-194-223-228.nycap.res.rr.com] has joined #parrotsketch<br>13:54 &lt;autrijus&gt; which the python guys said they are working on...<br>13:54 &lt;autrijus&gt; (hi, leo_, mdiep_)<br>13:54 &lt;leo_&gt; hi all<br>13:54 &lt;mdiep_&gt; hello<br>13:55 &lt;autrijus&gt; idly chattering about this neko thing<br>13:55 &lt;autrijus&gt; and how it helped me put things back to perspective (to parrot's advantage)<nobr> <wbr></nobr>:)<br>13:56 &lt;autrijus&gt; hm. we still have 5mins to go till the meetings starts<br>13:56 &lt;autrijus&gt; obra: you there?<br>13:57 &lt;@obra&gt; hi<br>13:57 &lt;@obra&gt; &lt;- Just arrived at the airport<br>13:57 &lt;Nicholas&gt; *At* the airport?<br>13:57 &lt;@obra&gt; Yes.<br>13:57 &lt;Nicholas&gt; you're flying out somewhere else?<br>13:57 &lt;@obra&gt; I've staked out a table in the food court.<br>13:57 &lt;@obra&gt; I'm on my way home from foo<br>13:58 &lt;autrijus&gt; obra: foo fun?<br>13:58 &lt;Nicholas&gt; ah oh right. I'd actually assumed that you flew back last night<br>13:58 &lt;Nicholas&gt; clearly not. THere isa post foo party?<br>13:58 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has joined #parrotsketch<br>13:58 &lt;@obra&gt; Yes. me and a soft bed with a pillow in a hotel room.<br>13:58 &lt;@obra&gt; It was a great party. I slept through the whole thing<nobr> <wbr></nobr>;)<br>14:01 &lt;@obra&gt; So anyway, Hello everyone.<br>14:01 &lt;chromatic&gt; Bonjour.<br>14:01 &lt;@obra&gt; Patrick is travelling for work. And chip is in the middle of an unemployemnt hearing.<br>14:01 &lt;@obra&gt; But both assure me that they'll be here to hassle next week.<br>14:01 &lt;Nicholas&gt; w.r.t. old employer?<br>14:01 &lt;@obra&gt; Nicholas: yes.<br>14:01 -!- #parrotske chromatic H&nbsp; &nbsp;1&nbsp; ~chromatic@sub17-30.member.dsl-only.net [chromatic]<br>14:01 -!- #parrotske obra&nbsp; &nbsp; &nbsp; H@&nbsp; 0&nbsp; ~jesse@69.25.201.132 [Jesse]<br>14:01 -!- #parrotske mdiep_&nbsp; &nbsp; H&nbsp; &nbsp;1&nbsp; ~mdiep@cpe-24-194-223-228.nycap.res.rr.com [Matt Diephouse]<br>14:01 -!- #parrotske leo_&nbsp; &nbsp; &nbsp; H&nbsp; &nbsp;1&nbsp; ~lt@ts3-126.twistspace.com [Leopold Toetsch]<br>14:01 -!- #parrotske Nicholas&nbsp; H&nbsp; &nbsp;1&nbsp; ~nwc10@colon.colondot.net [Nicholas Clark]<br>14:01 -!- #parrotske autrijus&nbsp; H&nbsp; &nbsp;1&nbsp; ~autrijus@220-132-132-105.HINET-IP.hinet.net [Autrijus Tang]<br>14:01 -!- End of<nobr> <wbr></nobr>/WHO list<br>14:02 &lt;Nicholas&gt; Good (I think/hope) as I'd hope it ought to move things onwards. However, that's really sort of off topic<br>14:03 &lt;autrijus&gt; so. topics?<br>14:03 &lt;@obra&gt; So, I guess the thing to do is to run this sort of like the design meetings. Everybody gets a chance to describe what they've been<br>up to for the past week or so and raise issues they're running into.<br>14:04 &lt;@obra&gt; Then a general "other business" section.<br>14:04 &lt;@obra&gt; Somebody, usually me or chromatic will moderate.<br>14:04 &lt;@obra&gt; I'll take it for today<nobr> <wbr></nobr>;)<br>14:04&nbsp; * chromatic naps<br>14:05 &lt;@obra&gt; If there's anything that you need to tell someone here that's not fit for public consumption, it should probably _not_ be done as<br>part of the meeting proper where everyone can see it.<br>14:05 &lt;@obra&gt; If any of the ground rules I'm laying out feel not-ok to someone, bring them up with me and we'll figure out how to fix it.<br>14:05 &lt;@obra&gt; So. Who wants to go first?<br>14:06 &lt;autrijus&gt; roll a 1d4?<br>14:06 &lt;@obra&gt; I pick...Nicholas<br>14:06 &lt;@obra&gt; How's the Ponie?<br>14:06 &lt;Nicholas&gt; very little has happened in the past 2 weeks.<br>14:06 &lt;Nicholas&gt; @work, and that hasn't progressed much either.<br>14:07 &lt;@obra&gt; Aside from work pressure, what's ponie currently stalled out on?<br>14:07 &lt;Nicholas&gt; I have some specific questions I asked to p6i some time ago, that Leo partly answered, but I think we're waitng on the great<br>designer to comment. And he's probably synthesising designs in his head<br>14:08 &lt;Nicholas&gt; The only other specific thing is that I'd like to find some way to make the DOD registry code accessible, so that I can make a<br>PMC (or somesuch) that shares most of the implementation with it, but has 1 additional feature - let you read<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the "reference" count.<br>14:08 &lt;Nicholas&gt; For ponie to track perl's reference counts. (All reference counts currently, external XS code reference counts only in the long<br>term)<br>14:08 &lt;chromatic&gt; What's the minimal design of the DOD registry that you need to make this work?<br>14:08 &lt;@obra&gt; (Other people should feel free to jump in and ask or answer questions during a report, so long as you're not cutting off the<br>speaker. If it gets too off track, I'll say something)<br>14:09 &lt;Nicholas&gt; It's a technical "I can't see how to refactor dod_register_pmc and dod_unregister_pmc (in pmc.c in parrot)<br>14:09 &lt;leo_&gt; Nicholas: interface Parrot_get_dod_registry_hash()<br> 14:09 &lt;Nicholas&gt; cleanly, so that the current code can keep on using interpreter-&gt;DOD_registry<br>14:10 &lt;Nicholas&gt; leo_: where is that?<br>14:10 &lt;leo_&gt; tbd<br>14:10 &lt;leo_&gt; but should be enough<br>14:10 &lt;Nicholas&gt; OK. I'd sort of assumed that I was doing it<br>14:10 &lt;Nicholas&gt; OK. BUt the next bit is that I'm not quite sure of the best (PMC) interface to hang on it.<br>14:11 &lt;Nicholas&gt; niggly detail. I was going to ask Norman today at work, but we he was abducted by meetings<br>14:11 &lt;chromatic&gt; How much of the Ponie code needs to touch the interface?<br>14:11 &lt;leo_&gt; it's a Hash PMC, which has all the access vtables<br>14:12 &lt;leo_&gt; (except that the hash keys are PMC addresses)<br>14:12 &lt;Nicholas&gt; The Ponie code wants to be able to register and unregister PMCs into a hash tracking the number of registers/unregisters. But in<br>a different PMC<br>14:13 &lt;chromatic&gt; Can you do all of this from a single place in Ponie code?<br>14:13 &lt;leo_&gt; so time for a new IdHash PMC?<br>14:13 &lt;chromatic&gt; Or at least behind a single macro?<br>14:13 &lt;Nicholas&gt; leo: I think yes.<br>14:13 &lt;Nicholas&gt; chromatic: yes, it's all going to sit behind SvREFCNT_inc and SvREFCNT_dec and SvREFCNT<br>14:13 &lt;leo_&gt; ok - select a proper name and I hack it in<br>14:13 &lt;Nicholas&gt; leo: gah. yhou would leave *me* with the hard problem<nobr> <wbr></nobr>:-)<br>14:14 &lt;leo_&gt; *g*<br>14:14 &lt;chromatic&gt; I say go for the simplest, easiest to implement interface right now and make it nicer if and when it needs to be nicer.<br>14:14 &lt;leo_&gt; the interface is already there see also classes/hash.pmc<br>14:14 &lt;Nicholas&gt; I agree. But I wasn't sure what vtables I had access to quickly pass in PMCs as keys.<br>14:15 &lt;leo_&gt; get_pmc_keyed, set_pmc_keyed<br>14:15 &lt;Nicholas&gt; ah. OK. D'oh. yes. takes a PMC<br>14:15 &lt;leo_&gt; both take a PMC - the address will be they key<br>14:15 &lt;autrijus&gt; leo_: but wouldn't it just serialize the key PMC with VTABLE_get_string?<br>14:16 &lt;leo_&gt; yes - therefore we need a new hash class<br>14:16 &lt;autrijus&gt; and iirc p5 PMCs doesn't stringify to their addresse<br>14:16 &lt;@obra&gt; (Is this productive? Should we keep going on reports or finish this off?)<br>14:17 &lt;leo_&gt; I think it's done - 'IdHash'<br>14:17 &lt;@obra&gt; Cool.<br>14:17 &lt;@obra&gt; Nicholas: anything else, before I pick on someone else?<br>14:17 &lt;Nicholas&gt; I think it's done<br>14:17 &lt;leo_&gt; or 'NickHash' ?<br>14:17 &lt;Nicholas&gt; I can't think of anything else for this week<br>14:17 &lt;@obra&gt; Ok.<br>14:18 &lt;autrijus&gt; leo_: PtrHash<br>14:18 &lt;autrijus&gt;<nobr> <wbr></nobr>;)<br>14:18 &lt;Nicholas&gt; Sorry for going on a bit<br>14:18 &lt;@obra&gt; mdiep_: What have you been up to?<br>14:19 -!- mdiep_ [~mdiep@cpe-24-194-223-228.nycap.res.rr.com]<br>14:19 -!-&nbsp; ircname&nbsp; : Matt Diephouse<br>14:19 -!-&nbsp; channels : #parrotsketch<br>14:19 -!-&nbsp; server&nbsp; &nbsp;: irc.hellyeah.org [Sporks flying from the west.]<br>14:19 -!- End of WHOIS<br>14:19 &lt;mdiep_&gt; ParTcl's moving along pretty well. I've been rewriting the support for Tcl's [expr] command.<br>14:19 &lt;mdiep_&gt; but<br>14:19 &lt;mdiep_&gt; I have some issues coming up wrt different conventions<br>14:20 &lt;mdiep_&gt; for instance, the proper way to store the list of exportable/imported commands in different namespaces. (basically, how do we storethe info we need in a way that doesn't eliminate interoperability?)<br>14:21 &lt;mdiep_&gt; chip suggested I investigate different languages and come up with a proposal<br>14:21 &lt;autrijus&gt; mm link sets.<br>14:21 &lt;@obra&gt; Is that turning out to be doable?<br>14:21 &lt;mdiep_&gt; obra: allowing interoperability? I don't know<br>14:22 &lt;@obra&gt; I was actually talking about the survey<nobr> <wbr></nobr>;)<br>14:22 &lt;mdiep_&gt; obra: ah.<nobr> <wbr></nobr>:-) it should get done in the next 2 weeks, I hope.<br>14:22 &lt;@obra&gt; Cool.<br>14:22 &lt;autrijus&gt; mdiep_: this is a nice collection of module/export theories: http://readscheme.org/modules/<br>14:23 &lt;@obra&gt; Anything else exciting going on in your ParTcl/parrot hacking?<br>14:24 &lt;mdiep_&gt; I think that's it at the moment.<br>14:25 &lt;@obra&gt; Ok.<br>14:25 &lt;@obra&gt; Autrijus?<br>14:25 &lt;autrijus&gt; well, there's more action on p5/js/hs than on pir<br>14:25 &lt;autrijus&gt; I'll pick the relevant to parrot parts<br>14:26 &lt;autrijus&gt; we've been working on rationalizing the lexical pad and related semantics<br>14:26 &lt;autrijus&gt; previously I found parrot's lexpad implementation to be unworkable<br>14:26 &lt;autrijus&gt; and leo mentioned it'd better be scrapped off and replaced with a directly-point-to-registers scheme on a variable sized registerframe<br>14:27 &lt;leo_&gt; yep<br>14:27 &lt;autrijus&gt; the current design hoists lexical pad off each closure entry<br>14:28 &lt;autrijus&gt; so essentially {<nobr> <wbr></nobr>...; my $a;<nobr> <wbr></nobr>... } lifts $a to top. similarily, "... ; sub foo;<nobr> <wbr></nobr>... " lifts "our &amp;foo" to package entry, which isa closure<br>14:28 &lt;autrijus&gt; however, chip said he'd like to work out an alternate lexical var declaration design<br>14:29 &lt;autrijus&gt; so inner blocks won't need become full closures<br>14:29 &lt;autrijus&gt; since that will affect pir surface syntax, I'd need the general design idea before progressing forward<br>14:29 &lt;autrijus&gt; but no information on that front yet<br>14:29 &lt;Nicholas&gt; however, is it any more than an optimisation in terms of what gets created?<br>14:29 &lt;autrijus&gt; and the varreg frame code is iirc also not yet checked in, so currently we're a bit stalled.<br>14:30 &lt;autrijus&gt; (since the last p6-pir spike stopped on the general brokenness of lexical pads)<br>14:30 -!- #parrotske chromatic H&nbsp; &nbsp;1&nbsp; ~chromatic@sub17-30.member.dsl-only.net [chromatic]<br>14:30 -!- #parrotske obra&nbsp; &nbsp; &nbsp; H@&nbsp; 0&nbsp; ~jesse@69.25.201.132 [Jesse]<br>14:30 -!- #parrotske mdiep_&nbsp; &nbsp; H&nbsp; &nbsp;1&nbsp; ~mdiep@cpe-24-194-223-228.nycap.res.rr.com [Matt Diephouse]<br>14:30 -!- #parrotske leo_&nbsp; &nbsp; &nbsp; H&nbsp; &nbsp;1&nbsp; ~lt@ts3-126.twistspace.com [Leopold Toetsch]<br>14:30 -!- #parrotske Nicholas&nbsp; H&nbsp; &nbsp;1&nbsp; ~nwc10@colon.colondot.net [Nicholas Clark]<br>14:30 -!- #parrotske autrijus&nbsp; H&nbsp; &nbsp;1&nbsp; ~autrijus@220-132-132-105.HINET-IP.hinet.net [Autrijus Tang]<br>14:30 -!- End of<nobr> <wbr></nobr>/WHO list<br>14:30 &lt;@obra&gt; *nod*<br>14:30 &lt;@obra&gt; Anything else?<br>14:31 &lt;autrijus&gt; Nicholas: yes, but chip notes that (if {}) and (for {}) creating closures is suboptimal<br>14:31 &lt;autrijus&gt; but it's currently the only way it can work in pir that I know of. so he said he'd improve it<br>14:31 &lt;chromatic&gt; In P6 or Parrot?<br>14:31 &lt;autrijus&gt; chromatic: in parrot. p6 is just this syntax thing<nobr> <wbr></nobr>:)<br>14:32 &lt;autrijus&gt; chromatic: currently I have &amp;statement:&lt;if&gt; dispatching into closures.<br>14:32 &lt;autrijus&gt; (as the spec demands, in a naive implementation)<br>14:32 &lt;autrijus&gt; he'd like to labelify it or something, but also have lexicals hangable onto labels.<br>14:32 &lt;autrijus&gt; but since chip's not here, not much point digressing further<nobr> <wbr></nobr>:)<br>14:33 &lt;Nicholas&gt; how sweet. a 30 second ADSL outage that then buggers this ssh connection.<br>14:33 &lt;autrijus&gt; ok. in other news, Devel::TypeCheck is fun, I'm working on doing the same for PIL2, and I wonder if PIR can be subjected to a<br>similar treatment.<br>14:34 &lt;autrijus&gt; I'll post to my journal and p6[ic] as usual when I have concrete results.<br>14:34 &lt;@obra&gt; Very neat.<br>14:35 &lt;autrijus&gt; nothing much else wrt parrot. the short term focus is getting p6 compiled to p5 and work with native p5 objects in reasonable<br>speed.<br>14:35 &lt;autrijus&gt; end of briefing<br>14:35 &lt;@obra&gt; Leo, what have you been up to of late?<br>14:35 &lt;leo_&gt; first the two google SoC folks<br>14:36 &lt;leo_&gt; Curtis Rawls is working on imcc &amp; optimizations<br>14:36 &lt;leo_&gt; we have also specced a plan to get register allocation running for the new scheme<br>14:37 &lt;leo_&gt; the other guy is Nattfood - Alexandre Buisse<br>14:37 &lt;leo_&gt; working on a generational mark &amp; compact GC scheme<br>14:38 &lt;leo_&gt; this is a real hard job as this also introduces variable sice PMC bodies<br>14:38 &lt;leo_&gt; AFAIK now make test passes almost again<br>14:38 &lt;@obra&gt; *nod* I'm impressed that students are able to handle things like this over a summer.<br>14:39 &lt;leo_&gt; yeah, it was a bit a slow start with Nattfood but now he is doing well<br>14:39 &lt;leo_&gt; I'm mainly waiting for Chips approval of mergin branches/leo-ctx5 back to trunk<br>14:40 &lt;leo_&gt; and braining the hacks thereafter<br>14:40 &lt;@obra&gt; "braining"?<br>14:40 &lt;leo_&gt; i.e. variable siced register frames, lexicals,<nobr> <wbr></nobr>...<br>14:40 &lt;leo_&gt; pondering<br>14:40 &lt;@obra&gt; *nod*<br>14:41 &lt;leo_&gt; that's it<br>14:41 &lt;chromatic&gt; How scary is the merge?<br>14:42 &lt;leo_&gt; It'll be not a real merge as I've merged all from trunk into the branch<br>14:42 &lt;leo_&gt; tcl needs some work then an py*.pmcs<br>14:42 &lt;@obra&gt; Are you suing svk?<br>14:42 &lt;@obra&gt; using.<br>14:42 &lt;leo_&gt; tewk is working on the latter<br>14:42 &lt;leo_&gt; no svn<br>14:42 &lt;@obra&gt; *nod*<br>14:43 &lt;@obra&gt; That makes the merge case much less trivial.<br>14:43 &lt;mdiep_&gt; coke and I will be jumping on the tcl work as soon as the code is merged.<br>14:44 &lt;@obra&gt; Ok. Chromatic, anything perpl6/parroty from your end?<br>14:44 &lt;leo_&gt; obra: well, if it's simpler with svk someone with svk can merge it<br>14:45 &lt;chromatic&gt; I added test_pass() and test_fail() to Test::Builder::Tester in both Parrot and Perl 6.&nbsp; That should make testing test modules<br>easier.<br>14:45 &lt;chromatic&gt; I have some draft code for Test::More in Perl 6, but I ran into a design issue from my side that I want to think through a<br>little bit more.<br>14:46 &lt;chromatic&gt; The only other bit of Perl 6 I'm waiting for is metamodel visibility so I can do introspection on method attributes, which will<br>allow me to write Test::Class.<br>14:47 &lt;autrijus&gt; chromatic: MM visib as in<nobr> <wbr></nobr>.meta ?<br>14:47 &lt;chromatic&gt; Specifically being able to inspect traits on methods.<br>14:47 &lt;autrijus&gt; you willing to work with runjs/runp5 instead of the default runhs?<br>14:47 &lt;chromatic&gt; method test_ctor is test(4) {<nobr> <wbr></nobr>... };<br>14:48 &lt;chromatic&gt; I could work with runp5 for now.<br>14:48 &lt;autrijus&gt; ok. so you need a "test" role<br>14:48 &lt;autrijus&gt; and we need parse and gen support for trait_auxiliary:is<br>14:48 &lt;autrijus&gt; that's all, right?<br>14:49 &lt;chromatic&gt; Pretty much.<br>14:49 &lt;autrijus&gt; can you write out the test role and check it in to ext as an example?<br>14:49 &lt;autrijus&gt; that way people are better motivated to make things pass<br>14:49 &lt;chromatic&gt; Not without some research.&nbsp; Is there another good example of the syntax somewhere?<br>14:50 &lt;autrijus&gt; I see a t/oo/traits/basic.t and a t/oo/traits/parameterized.t<br>14:50 &lt;autrijus&gt; but really all my knowledge comes from s12.<br>14:50 &lt;chromatic&gt; Mine too.<br>14:50 &lt;chromatic&gt; I understand how to use it, but not the ideas behind how to write it.<br>14:51 &lt;autrijus&gt; oh! but I suppose that was your fault?<br>14:51 &lt;autrijus&gt; I mean the entire role/trait/mixin thing<br>14:51 &lt;@obra&gt; So. We've got about 10 more minutes. Is there anything else that needs to get addressed this week?<br>14:51 &lt;chromatic&gt; Roles yes, traits no.<br>14:51 &lt;autrijus&gt; chromatic: ok. see if the two<nobr> <wbr></nobr>.t in traits is sane, and mockup it with T::C<br>14:51 &lt;autrijus&gt; and I'll try to work with putter, fglock, stevan et al to get it running on runp5<br>14:52 &lt;chromatic&gt; Thanks.<br>14:52 &lt;autrijus&gt; np. you are the most demanding motivation for most 6.28.0 features<nobr> <wbr></nobr>:)<br>14:53 &lt;chromatic&gt; With Test::Class, we can write LambdaCamelMoo, so that's really important.<br>14:53 &lt;Nicholas&gt; "Moo" ?<br>14:54 &lt;chromatic&gt; Like a Mud, but more cow.<br>14:54 &lt;autrijus&gt; Moo, as in unix.<br>14:54 &lt;@obra&gt; So. With luck, next week, we'll have patrick and chip around and all of the "questions for the designer" can be thrown at him<nobr> <wbr></nobr>:)<br>14:54 &lt;leo_&gt; in one hour<nobr> <wbr></nobr>:-)<br>14:54 &lt;Nicholas&gt; although I'm not sure what my connectivity will be like, as I'm in Braga<br>14:54 &lt;@obra&gt; I hope this is/ends up being useful for you guys. If it turns out to be a hassle or just not useful, please do say so.<br>14:55 &lt;autrijus&gt; yeah, I'd love to see the code of the s/r parser pm demo'ed in oscon.<br>14:55 &lt;@obra&gt; leo_: we can help you configure an IRC client to stream questions as fast as your ISDN can carry them.<br>14:55 &lt;mdiep_&gt; getting an hour with chip every week should help.<nobr> <wbr></nobr>:-)<br>14:55 &lt;leo_&gt; obra: np I got DSL already<br>14:55 &lt;autrijus&gt; obra: leo is enjoying pervasive wireless.<br>14:56 &lt;@obra&gt; leo_: nice. then it's a matter of not getting the IRC server to boot you for flooding.<br>14:56 &lt;@obra&gt; I should run along and find food before my flight. anything else before I go?<br>14:56 &lt;@obra&gt; Does someone want to mail out the irc log to the whole CC list (Which I'll get robert to turn into a real list)<br>14:56 &lt;Nicholas&gt; they don't give you food on your flight?<nobr> <wbr></nobr>:-(<br>14:56 &lt;leo_&gt; obra: thanks for organizing the meeting<br>14:57 &lt;@obra&gt; np.<br>14:57 &lt;@obra&gt; Nicholas: not in coach anymore.<br>14:57 &lt;@obra&gt; Nicholas: if I manage an upgrade, I get very good food, though<br>14:57 &lt;autrijus&gt; http://autrijus.org/tmp/ps0.log<br>14:57 &lt;@obra&gt; autrijus: thanks<br>14:57 &lt;Nicholas&gt; interesting. They've learned tricks from the budget airlines<br>14:57 &lt;Nicholas&gt; and yes, thanks for herding everyone to this meeting<br>14:58 &lt;Nicholas&gt; either that or you're flying B.A.<nobr> <wbr></nobr>:-)<br>14:58 &lt;@obra&gt; If it helps, I'll be happy. My "job" is to listen to people tell me what's making it hard for them to create parrot/perl6/etc and<br>then make those obstacles disappear.<br>14:59 &lt;leo_&gt; autrijus: you mentioned Neko at the beginning - and influences on p6/parrot<br>14:59&nbsp; * obra -&gt; gone. *wave*<br>14:59&nbsp; * mdiep_ -&gt; also gone.<br>15:01 -!- chromatic [~chromatic@sub17-30.member.dsl-only.net] has quit [Quit: (lunch)]<br>15:01 &lt;autrijus&gt; leo_: back to #parrot<br>15:02 &lt;leo_&gt; ok<br></tt> jesse 2005-10-03T19:49:50+00:00 journal