From scratchcomputing at gmail.com Wed Oct 1 18:44:59 2008 From: scratchcomputing at gmail.com (Seven till Seven) Date: Wed, 1 Oct 2008 18:44:59 -0700 Subject: [Pdx-pm] Hands on Perl 6 -- getting setup for next week's meeting Message-ID: <200810011845.00006.ewilhelm@cpan.org> Wed. October 8th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. This month's meeting will be a hands-on session of running Perl 6. Jerry Gay of Rakudo Consulting Group will be visiting from Seattle. Jerry is a key contributor to parrot/rakudo and will be very helpful in understanding what rakudo can do right now and diagnosing any troubles that come up. We will have a short walk-through at the beginning covering some key differences between Perl 5 and Perl 6, followed by a short session of essential questions (and hopefully answers.) This will be a very hands-on learning session and we'll probably be working in pairs or small groups as well as spending some time reading documentation and going around sharing what we've learned. For information on getting setup and links for those who like to study before coming to class: http://pdx.pm.org/kwiki/index.cgi?October2008Meeting And the vitally important part: have rakudo running before you get to the meeting. This is "Hands on Perl 6", not "Hands on the parrot build system." If you are having trouble getting it running, please mail me, the list, or ask in the #pdx.pm channel on irc.perl.org. The fewer build/install problems we have during the meeting, the better. If your shy friend does not have a laptop or is having trouble building parrot, please send me their e-mail address and I will see what I can do. If your shy friend has a spare laptop, definitely send me their e-mail address. If you do not have time to build parrot before the meeting, I can probably help with that too if you mail me to tell me what platform and OS you're using. As always, social hour at the lucky lab afterwards. --Eric -- http://pdx.pm.org From marvin at rectangular.com Wed Oct 1 21:20:13 2008 From: marvin at rectangular.com (Marvin Humphrey) Date: Wed, 1 Oct 2008 21:20:13 -0700 Subject: [Pdx-pm] IP Lawyer Recommendations Message-ID: <20081002042013.GA26854@rectangular.com> Greets, The Eugene IP lawyer I usually use for reviewing contracts seems to have become unavailable, and it turns out I need someone to look over an employment contract. The job involves working on open source code some of the time, and IP rights are my principle concern. FWIW, the job is in California. Any recommendations? Marvin Humphrey Rectangular Research http://www.rectangular.com/ From joshua at keroes.com Wed Oct 1 22:18:03 2008 From: joshua at keroes.com (Joshua Keroes) Date: Wed, 1 Oct 2008 22:18:03 -0700 Subject: [Pdx-pm] IP Lawyer Recommendations In-Reply-To: <20081002042013.GA26854@rectangular.com> References: <20081002042013.GA26854@rectangular.com> Message-ID: E.J. Simmons is an IP lawyer I've known for years. http://simmonstrialpractice.com/ -Joshua On Wed, Oct 1, 2008 at 9:20 PM, Marvin Humphrey wrote: > Greets, > > The Eugene IP lawyer I usually use for reviewing contracts seems to have > become unavailable, and it turns out I need someone to look over an > employment > contract. The job involves working on open source code some of the time, > and > IP rights are my principle concern. FWIW, the job is in California. > > Any recommendations? > > Marvin Humphrey > Rectangular Research > http://www.rectangular.com/ > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison at perl.org Thu Oct 2 08:21:06 2008 From: allison at perl.org (Allison Randal) Date: Thu, 02 Oct 2008 17:21:06 +0200 Subject: [Pdx-pm] IP Lawyer Recommendations In-Reply-To: References: <20081002042013.GA26854@rectangular.com> Message-ID: <48E4E6E2.8000308@perl.org> Roberta Cairney (http://www.cairneylawoffices.com/) is the goto IP expert (open source and otherwise) for O'Reilly, The Perl Foundation, and the new Parrot Foundation. She was also the primary lawyer on the Artistic License 2.0 revision. Allison Joshua Keroes wrote: > E.J. Simmons is an IP lawyer I've known for years. > http://simmonstrialpractice.com/ > > -Joshua > > On Wed, Oct 1, 2008 at 9:20 PM, Marvin Humphrey > wrote: > > Greets, > > The Eugene IP lawyer I usually use for reviewing contracts seems to have > become unavailable, and it turns out I need someone to look over an > employment > contract. The job involves working on open source code some of the > time, and > IP rights are my principle concern. FWIW, the job is in California. > > Any recommendations? > > Marvin Humphrey > Rectangular Research > http://www.rectangular.com/ > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list From gorthx at gmail.com Thu Oct 2 09:09:51 2008 From: gorthx at gmail.com (gabrielle) Date: Thu, 2 Oct 2008 09:09:51 -0700 Subject: [Pdx-pm] This month's books - Fwd: Newsletter from O'Reilly UG Program, October 1 Message-ID: <48bb92b0810020909o46a5e65eq42adeded9b5d007e@mail.gmail.com> ---------- Forwarded message ---------- From: Marsee Henon Date: Wed, Oct 1, 2008 at 4:32 PM Subject: Newsletter from O'Reilly UG Program, October 1 To: gorthx at gmail.com For book review writing tips and suggestions, go to: Apache 2 Pocket Reference Build Your Own ASP.NET 3.5 Website Using C# & VB, Third Edition (SitePoint) Hadoop: The Definitive Guide: Rough Cuts Version Head First Physics How Wikipedia Works (No Starch) iPhone Forensics iPhone UK: The Missing Manual, Second Edition Learning OpenCV Mac OS X for Unix Geeks, Fourth Edition MAKE: Technology on Your Time Volume 15 Maven: The Definitive Guide Practical HDRI (Rocky Nook) Pragmatic Thinking and Learning (Pragmatic Bookshelf) Programming Flex 3 Programming Ruby, Third Edition (Pragmatic Bookshelf) Quicken 2009: The Missing Manual Rails Pocket Reference SOA Cookbook: Rough Cuts Version Take Control of Buying a Mac (TidBITS) Take Control of Podcasting on the Mac (TidBITS) The Art of Capacity Planning The Art of Debugging with GDB, DDD, and Eclipse (No Starch) The Canon EOS Digital Rebel XSi/450D Companion Ubuntu Kung Fu (Pragmatic Bookshelf) Version Control with Subversion, Second Edition From chromatic at wgz.org Thu Oct 2 22:18:28 2008 From: chromatic at wgz.org (chromatic) Date: Thu, 2 Oct 2008 22:18:28 -0700 Subject: [Pdx-pm] Hands on Perl 6 -- getting setup for next week's meeting In-Reply-To: <200810011845.00006.ewilhelm@cpan.org> References: <200810011845.00006.ewilhelm@cpan.org> Message-ID: <200810022218.28433.chromatic@wgz.org> On Wednesday 01 October 2008 18:44:59 Seven till Seven wrote: > And the vitally important part: ?have rakudo running before you get to > the meeting. ?This is "Hands on Perl 6", not "Hands on the parrot build > system." ?If you are having trouble getting it running, please mail me, > the list, or ask in the #pdx.pm channel on irc.perl.org. ?The fewer > build/install problems we have during the meeting, the better. Anyone in #parrot on irc.perl.org is happy to help as well, unless you're running something exotic on your laptop such as VMS. -- c From igal at pragmaticraft.com Fri Oct 3 11:52:40 2008 From: igal at pragmaticraft.com (Igal Koshevoy) Date: Fri, 03 Oct 2008 11:52:40 -0700 Subject: [Pdx-pm] Hands on Perl 6 -- getting setup for next week's meeting In-Reply-To: <200810022218.28433.chromatic@wgz.org> References: <200810011845.00006.ewilhelm@cpan.org> <200810022218.28433.chromatic@wgz.org> Message-ID: <48E669F8.1080404@pragmaticraft.com> chromatic wrote: > On Wednesday 01 October 2008 18:44:59 Seven till Seven wrote: > > >> And the vitally important part: have rakudo running before you get to >> the meeting. This is "Hands on Perl 6", not "Hands on the parrot build >> system." If you are having trouble getting it running, please mail me, >> the list, or ask in the #pdx.pm channel on irc.perl.org. The fewer >> build/install problems we have during the meeting, the better. >> > > Anyone in #parrot on irc.perl.org is happy to help as well, unless you're > running something exotic on your laptop such as VMS. > I can confirm that the instructions provided earlier at http://pdx.pm.org/kwiki/index.cgi?October2008Meeting were easy to follow and let me compile a perl6 interpreter in about five easy commands. See you at the meeting. -igal From schwern at pobox.com Fri Oct 3 12:26:15 2008 From: schwern at pobox.com (Michael G Schwern) Date: Fri, 03 Oct 2008 15:26:15 -0400 Subject: [Pdx-pm] Perl 6 Docs and Differences Message-ID: <48E671D7.2090709@pobox.com> The most up to date Perl 6 specification and docs can be found here: http://perlcabal.org/syn/ These are pulled straight from the repository (and thus Larry's brain). Another really useful doc is this outlining the differences between Perl 5 and Perl 6. http://perlcabal.org/syn/Differences.html -- 54. "Napalm sticks to kids" is *not* a motivational phrase. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/ From erik at hollensbe.org Fri Oct 3 15:27:40 2008 From: erik at hollensbe.org (Erik Hollensbe) Date: Fri, 3 Oct 2008 15:27:40 -0700 Subject: [Pdx-pm] Perl 6 Docs and Differences In-Reply-To: <48E671D7.2090709@pobox.com> References: <48E671D7.2090709@pobox.com> Message-ID: <200810031527.40605.erik@hollensbe.org> On Friday 03 October 2008 12:26:15 Michael G Schwern wrote: > The most up to date Perl 6 specification and docs can be found here: > http://perlcabal.org/syn/ > > These are pulled straight from the repository (and thus Larry's brain). > > Another really useful doc is this outlining the differences between Perl 5 > and Perl 6. > http://perlcabal.org/syn/Differences.html I'm reading the differences page, and some things seem familiar from other languages; I was hoping that in lieu of having to pour through the spec (which still appears to be a moving target) I could just ask and maybe someone involved more than I would know. A lot of this looks very neat.. I'm just curious about a few things: It seems like ~~ is a more primitive ocaml match/ruby case, where there is the concept of "match equality" (I'm thinking of the file tests and regexes particularly) that may be different from standard equality. Is that correct? Does ~~ provide a direct syntax for multiple possible matches, or is that expected to be provided by the boolean operators, e.g., to test if a file is a directory or a file: $fn ~~ :f | :d # I doubt this is right but I hope this gets the point across or is there something more along the lines of: match $fn with :f with :d which could potentially express the same thing. Another curiosity is the change in how code refs are used in method calls. Does this apply to the soft reference special case as well? e.g., perl 5: $foo = "bar"; $self->$foo("something"); # calls $self->bar("something"); Also, unless I'm missing something, the whole concept of soft references seems unaddressed. Are these disappearing entirely? While 99% of the time they are something to avoid, the 1% of the time they're handy... they're really handy. Anyways, the progress that's being made and seeing it take shape is a very exciting thing; thanks for linking these documents. -Erik From schwern at pobox.com Fri Oct 3 20:13:18 2008 From: schwern at pobox.com (Michael G Schwern) Date: Fri, 03 Oct 2008 23:13:18 -0400 Subject: [Pdx-pm] Perl 6 Docs and Differences In-Reply-To: <200810031527.40605.erik@hollensbe.org> References: <48E671D7.2090709@pobox.com> <200810031527.40605.erik@hollensbe.org> Message-ID: <48E6DF4E.8020602@pobox.com> Erik Hollensbe wrote: > It seems like ~~ is a more primitive ocaml match/ruby case, where there is the > concept of "match equality" (I'm thinking of the file tests and regexes > particularly) that may be different from standard equality. Is that correct? > Does ~~ provide a direct syntax for multiple possible matches, or is that > expected to be provided by the boolean operators, e.g., to test if a file is > a directory or a file: > > $fn ~~ :f | :d # I doubt this is right but I hope this gets the point across > > or is there something more along the lines of: > > match $fn > with :f > with :d > > which could potentially express the same thing. Using given/when you'd write that like: given $m { when :f | :d { ... } } but I'm not entirely sure how the file test operators work. See http://perlcabal.org/syn/S03.html#Smart_matching for the full power of ~~. I do know they're always futzing with ways to eliminate the need for: if( $foo eq 'bar' or $foo eq 'baz' or $foo eq 'wibble' ) > Another curiosity is the change in how code refs are used in method calls. > Does this apply to the soft reference special case as well? > > e.g., perl 5: > > $foo = "bar"; > > $self->$foo("something"); # calls $self->bar("something"); I suspect it's supposed to, but it's not implemented. $ ./perl6 -e 'my $foo = "foo"; $foo("bar")' invoke() not implemented in class 'Perl6Str' > Also, unless I'm missing something, the whole concept of soft references seems > unaddressed. Are these disappearing entirely? While 99% of the time they are > something to avoid, the 1% of the time they're handy... they're really handy. References appear to have been completely replaced by "Capture objects" which is news to me. I'm not going to pretend to know about them, read this. http://svn.pugscode.org/pugs/docs/Perl6/FAQ/Capture.pod > Anyways, the progress that's being made and seeing it take shape is a very > exciting thing; thanks for linking these documents. Here is a slightly out of date but more complete set of Perl 6 docs that might prove more user friendly. http://search.cpan.org/dist/Perl6-Doc/ -- 52. Not allowed to yell "Take that Cobra" at the rifle range. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/ From ben.hengst at gmail.com Fri Oct 3 20:18:18 2008 From: ben.hengst at gmail.com (benh) Date: Fri, 3 Oct 2008 20:18:18 -0700 Subject: [Pdx-pm] Perl 6 Docs and Differences In-Reply-To: <48E6DF4E.8020602@pobox.com> References: <48E671D7.2090709@pobox.com> <200810031527.40605.erik@hollensbe.org> <48E6DF4E.8020602@pobox.com> Message-ID: <85ddf48b0810032018i61b0dc0dmcdf2e5822b47fcb3@mail.gmail.com> the pugscode link is dead for me but I was able to find this: http://moritz.faui2k3.org/pugs/docs/Perl6/FAQ/Capture.pod.html On Fri, Oct 3, 2008 at 8:13 PM, Michael G Schwern wrote: > Erik Hollensbe wrote: >> It seems like ~~ is a more primitive ocaml match/ruby case, where there is the >> concept of "match equality" (I'm thinking of the file tests and regexes >> particularly) that may be different from standard equality. Is that correct? >> Does ~~ provide a direct syntax for multiple possible matches, or is that >> expected to be provided by the boolean operators, e.g., to test if a file is >> a directory or a file: >> >> $fn ~~ :f | :d # I doubt this is right but I hope this gets the point across >> >> or is there something more along the lines of: >> >> match $fn >> with :f >> with :d >> >> which could potentially express the same thing. > > Using given/when you'd write that like: > > given $m { > when :f | :d { > ... > } > } > > but I'm not entirely sure how the file test operators work. > See http://perlcabal.org/syn/S03.html#Smart_matching for the full power of ~~. > > I do know they're always futzing with ways to eliminate the need for: > > if( $foo eq 'bar' or $foo eq 'baz' or $foo eq 'wibble' ) > > >> Another curiosity is the change in how code refs are used in method calls. >> Does this apply to the soft reference special case as well? >> >> e.g., perl 5: >> >> $foo = "bar"; >> >> $self->$foo("something"); # calls $self->bar("something"); > > I suspect it's supposed to, but it's not implemented. > > $ ./perl6 -e 'my $foo = "foo"; $foo("bar")' > invoke() not implemented in class 'Perl6Str' > > >> Also, unless I'm missing something, the whole concept of soft references seems >> unaddressed. Are these disappearing entirely? While 99% of the time they are >> something to avoid, the 1% of the time they're handy... they're really handy. > > References appear to have been completely replaced by "Capture objects" which > is news to me. I'm not going to pretend to know about them, read this. > http://svn.pugscode.org/pugs/docs/Perl6/FAQ/Capture.pod > > >> Anyways, the progress that's being made and seeing it take shape is a very >> exciting thing; thanks for linking these documents. > > Here is a slightly out of date but more complete set of Perl 6 docs that might > prove more user friendly. > http://search.cpan.org/dist/Perl6-Doc/ > > > -- > 52. Not allowed to yell "Take that Cobra" at the rifle range. > -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army > http://skippyslist.com/list/ > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -- benh~ http://three.sentenc.es/ From erik at hollensbe.org Fri Oct 3 22:11:21 2008 From: erik at hollensbe.org (Erik Hollensbe) Date: Fri, 3 Oct 2008 22:11:21 -0700 Subject: [Pdx-pm] Perl 6 Docs and Differences In-Reply-To: <48E6DF4E.8020602@pobox.com> References: <48E671D7.2090709@pobox.com> <200810031527.40605.erik@hollensbe.org> <48E6DF4E.8020602@pobox.com> Message-ID: <200810032211.21425.erik@hollensbe.org> On Friday 03 October 2008 20:13:18 Michael G Schwern wrote: > Here is a slightly out of date but more complete set of Perl 6 docs that > might prove more user friendly. > http://search.cpan.org/dist/Perl6-Doc/ Schwern and benh: thanks! -Erik From pagaltzis at gmx.de Sat Oct 4 00:06:03 2008 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Sat, 4 Oct 2008 09:06:03 +0200 Subject: [Pdx-pm] Perl 6 Docs and Differences In-Reply-To: <200810031527.40605.erik@hollensbe.org> References: <48E671D7.2090709@pobox.com> <200810031527.40605.erik@hollensbe.org> Message-ID: <20081004070603.GD11411@klangraum.plasmasturm.org> * Erik Hollensbe [2008-10-04 00:30]: > It seems like ~~ is a more primitive ocaml match/ruby case, > where there is the concept of "match equality" (I'm thinking of > the file tests and regexes particularly) that may be different > from standard equality. Is that correct? Based on a quick reading up on `match` in Ocaml, yes. I wouldn?t call it primitive, though. I?m pretty sure a 1:1 implementation of `match` will be possible in Perl?6 in user code, although I don?t think it will be amenable to compile-time guarantees in the same way. In that view, `~~` is just a convenient predefined `match` expression that you use in common cases so you don?t have to repeat all the time how you want the match to work. > Does ~~ provide a direct syntax for multiple possible matches, > or is that expected to be provided by the boolean operators, > e.g., to test if a file is a directory or a file: > > $fn ~~ :f | :d # I doubt this is right but I hope this gets the point across Actually, that is exactly right. The multiple-match syntax is courtesy of junctions, though, not a feature of smart match itself, and is available to other operations as well. > Also, unless I'm missing something, the whole concept of soft > references seems unaddressed. Are these disappearing entirely? > While 99% of the time they are something to avoid, the 1% of > the time they're handy... they're really handy. I think the idea is that any time soft references were the best way to do something in Perl?5, you?d use the meta-object protocol in Perl?6. Regards, -- Aristotle Pagaltzis // From jd at commandprompt.com Tue Oct 7 10:47:04 2008 From: jd at commandprompt.com (Joshua Drake) Date: Tue, 7 Oct 2008 10:47:04 -0700 Subject: [Pdx-pm] Pg Conference: West, bigger than last year! Message-ID: <20081007104704.56a03b33@jd-laptop> On October 20th 2007 the first annual PostgreSQL Conference: West commenced. It was a single day, single room event. On March 29th and 30th the first annual PostgreSQL Conference: East commenced. It was a two day, three room event which. On October 10-12th the second annual PostgreSQL Conference: West will commence. A three day, three room event with PostgreSQL training, a code sprint, a Internals track, a web track and multiple talks on high availability, performance, and community. The West conference is set to overshadow the East conference as the most popular conference in the series (until East 09 that is). If you haven't registered, now is the time. Come and experience what PostgreSQL is all about. The fun, the education, the technical savvy! No other database, open source or propreitary has such a vibrant, diverse and dedicated community as PostgreSQL! Register here: http://www.postgresqlconference.org/west08/register See a list of talks here: http://www.postgresqlconference.org/west08/talks/ And of course, thank you to our sponsors: Command Prompt: http://www.commandprompt.com/ EnterpriseDB: http://www.enterprisedb.com/ Afilias : http://www.afilias.info/ HP: http://www.hp.com/ Xtuple: http://www.xtuple.com/ Emma : http://www.myemma.com/ Continuent : http://www.continuent.com/ Endpoint : http://www.endpoint.com/ OTG : http://www.otg-nc.com/ EFF: http://www.eff.org/ Google: http://www.google.com/ All proceeds from the conference benefit the United States (PgUS) PostgreSQL Association. -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ From scratchcomputing at gmail.com Wed Oct 8 09:42:10 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Wed, 8 Oct 2008 09:42:10 -0700 Subject: [Pdx-pm] Hands on Perl 6 -- meeting tonight Message-ID: <200810080942.10945.ewilhelm@cpan.org> Wed. October 8th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. Tonight's meeting will be a hands-on session of running Perl 6. Jerry Gay of Rakudo Consulting Group will be visiting from Seattle. Jerry is a key contributor to parrot/rakudo and will be very helpful in understanding what rakudo can do right now and diagnosing any troubles that come up. We will have a short walk-through at the beginning covering some key differences between Perl 5 and Perl 6, followed by a short session of essential questions (and hopefully answers.) This will be a very hands-on learning session and we'll probably be working in pairs or small groups as well as spending some time reading documentation and going around sharing what we've learned. Information on getting setup and links for those who like to study before coming to class: http://pdx.pm.org/kwiki/index.cgi?October2008Meeting As always, social hour at the lucky lab afterwards. --Eric -- http://pdx.pm.org From jaleto at gmail.com Sun Oct 12 13:01:00 2008 From: jaleto at gmail.com (Jonathan Leto) Date: Sun, 12 Oct 2008 13:01:00 -0700 Subject: [Pdx-pm] New version of Math::GSL soon Message-ID: <9aaadf9c0810121301h701ddc9cud8b805178a9557b8@mail.gmail.com> Howdy Folks, I wanted to let you know that I just uploaded a dev Release of Math::GSL to CPAN (0.13_02), it is being shoveled onto dump trucks and being sent down multifarious tubes to get to a CPAN mirror near you. This will turn into 0.14 sometime next week if none of you can make it break too badly. Enjoy! http://search.cpan.org/~leto/Math-GSL-0.13_02/ Changes since 0.12: - Chebyshev Series Approximation, with tests and docs - Improved Deriv, Integration, Chebyshev, Combination and Roots docs - Improved introduction examples in Math::GSL - Improved Minimization subsystem tests, but it is not functional - Added example/deriv/basic This shows the simple fact that d/dx(sin(x)) = cos(x) - Added example/sf/erfc_check (thanks to Keith Lofstrom) Script which tests the erfc() special function against computing the integral definition with gsl_integration_qagiu() - Added example/vector/speed This shows a considerable performance boost using Math::GSL::Vectors instead of List::Util when searching for the min and max elements of large sets of random numbers. - Fixed return signature of gsl_deriv_* functions to return a flat list - Fix location of shared objects (Sisyphus) - Added raw() method to RNG objects Cheers, -- [---------------------] Jonathan Leto jaleto at gmail.com From gorthx at gmail.com Tue Oct 14 16:00:08 2008 From: gorthx at gmail.com (gabrielle) Date: Tue, 14 Oct 2008 16:00:08 -0700 Subject: [Pdx-pm] Fwd: UG News-O'Reilly wants your ideas about live workshops In-Reply-To: References: Message-ID: <48bb92b0810141600r4096de2ax9b9fc947427537@mail.gmail.com> In case you haven't seen this yet. ---------- Forwarded message ---------- From: Marsee Henon Date: Tue, Oct 14, 2008 at 11:37 AM Subject: UG News-O'Reilly wants your ideas about live workshops To: gorthx at gmail.com Hi Can you please share this with your members if you think they might be interested in helping out? Thanks, Marsee O'Reilly Media is conducting research about in-person, live workshops on software and business topics, and we'd really like your opinion. If you live in the United States and work in the tech industry, please consider taking our 19 question survey to help us understand what you look for in a live training course ? what motivates you, what you expect to get out of a workshop, what topics you'd like to see, and so forth. To participate, please go to: https://www.surveymonkey.com/s.aspx?sm=3bFGXzVnXige7WrPdJ0wAQ_3d_3d To show our appreciation, we'll select 10 people at random to receive a free book of your choice. The drawing will happen on Friday, October 17, so you'll need to complete the survey by that date to enter. The last question on the survey will ask for your e-mail ? we'll use that only to contact the randomly selected winners ? and your responses will remain anonymous. Thank you! Marsee Henon ================================================================ O'Reilly 1005 Gravenstein Highway North Sebastopol, CA 95472 http://ug.oreilly.com/ Follow us on Twitter at http://twitter.com/OReillyMedia You are receiving this email because you are a User Group contact with O'Reilly Media. If you would like to stop receiving these newsletters or announcements from O'Reilly, send an email to marsee at oreilly.com ================================================================ From gorthx at gmail.com Tue Oct 14 16:00:08 2008 From: gorthx at gmail.com (gabrielle) Date: Tue, 14 Oct 2008 16:00:08 -0700 Subject: [Pdx-pm] Fwd: UG News-O'Reilly wants your ideas about live workshops In-Reply-To: References: Message-ID: <48bb92b0810141600r4096de2ax9b9fc947427537@mail.gmail.com> In case you haven't seen this yet. ---------- Forwarded message ---------- From: Marsee Henon Date: Tue, Oct 14, 2008 at 11:37 AM Subject: UG News-O'Reilly wants your ideas about live workshops To: gorthx at gmail.com Hi Can you please share this with your members if you think they might be interested in helping out? Thanks, Marsee O'Reilly Media is conducting research about in-person, live workshops on software and business topics, and we'd really like your opinion. If you live in the United States and work in the tech industry, please consider taking our 19 question survey to help us understand what you look for in a live training course ? what motivates you, what you expect to get out of a workshop, what topics you'd like to see, and so forth. To participate, please go to: https://www.surveymonkey.com/s.aspx?sm=3bFGXzVnXige7WrPdJ0wAQ_3d_3d To show our appreciation, we'll select 10 people at random to receive a free book of your choice. The drawing will happen on Friday, October 17, so you'll need to complete the survey by that date to enter. The last question on the survey will ask for your e-mail ? we'll use that only to contact the randomly selected winners ? and your responses will remain anonymous. Thank you! Marsee Henon ================================================================ O'Reilly 1005 Gravenstein Highway North Sebastopol, CA 95472 http://ug.oreilly.com/ Follow us on Twitter at http://twitter.com/OReillyMedia You are receiving this email because you are a User Group contact with O'Reilly Media. If you would like to stop receiving these newsletters or announcements from O'Reilly, send an email to marsee at oreilly.com ================================================================ From kellert at ohsu.edu Wed Oct 15 10:40:27 2008 From: kellert at ohsu.edu (Thomas Keller) Date: Wed, 15 Oct 2008 10:40:27 -0700 Subject: [Pdx-pm] open source scheduling system in perl Message-ID: Greetings, Does anyone know of an open source scheduling system written in perl? thanks, Tom kellert at ohsu.edu 503-494-2442 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scratchcomputing at gmail.com Fri Oct 17 09:56:34 2008 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Fri, 17 Oct 2008 09:56:34 -0700 Subject: [Pdx-pm] culturedperl.org Message-ID: <200810170956.34160.ewilhelm@cpan.org> Hi all, Dave Cross is looking for articles for http://culturedperl.org. Dave is also to blame for http://proudtouseperl.org/. "Culturedperl.org is intended to be a blog about Perl culture. I don't have any strong ideas of exactly what that covers except that it should promote what we think is best about the Perl community." --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From jaleto at gmail.com Wed Oct 22 08:24:53 2008 From: jaleto at gmail.com (Jonathan Leto) Date: Wed, 22 Oct 2008 08:24:53 -0700 Subject: [Pdx-pm] Math::GSL 0.14 Message-ID: <9aaadf9c0810220824t41c8ebfxe5878003d681b2f8@mail.gmail.com> Howdy, There is a new release of Math::GSL available, some highlights are: * Expanded documentation in many subsystems * Chebyshev Series * Math::GSL::RNG objects now have a ->raw() method More details at: http://leto.net/code/Math-GSL/ Get it now: http://search.cpan.org/~leto/Math-GSL-0.14/ Cheers, -- [---------------------] Jonathan Leto jaleto at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From scratchcomputing at gmail.com Wed Oct 29 15:34:09 2008 From: scratchcomputing at gmail.com (Seven till Seven) Date: Wed, 29 Oct 2008 15:34:09 -0700 Subject: [Pdx-pm] Sitter for Cisco Syslogs -- Meeting in 2 weeks Message-ID: <200810291534.09795.ewilhelm@cpan.org> November2008Meeting Wed. November 12th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. Speaker: Gabrielle Roth Topic: A Sitter for Cisco Syslogs Syslog is a handy troubleshooting tool, but only if you actually read what's logged. I wrote a Cisco syslog parser & reporter as part of our network fault-management system. We'll go over: * network management basics * why we needed this specific tool * why I created my own tool from scratch (instead of using an off-the-shelf solution) * how I did it & what the results were, and * what I'm going to do next. You don't need to be a Cisco engineer or even know much Perl to get something out of this talk. As always, the meeting will be followed by social hour at the Lucky Lab. -- http://pdx.pm.org From igal at pragmaticraft.com Wed Oct 29 18:02:49 2008 From: igal at pragmaticraft.com (Igal Koshevoy) Date: Wed, 29 Oct 2008 18:02:49 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace Message-ID: <490907B9.1000004@pragmaticraft.com> Tomorrow's the first public meeting of the group organizing a regional, community-run open source conference to replace OSCON. I realize this isn't much notice, but they'll have many more meetings in the future. Please subscribe to their blog's feed for future meeting announcements and information. Thanks! Details on this town hall meeting: http://calagator.org/events/1250456028 Conference homepage and blog: http://www.bridgepdx.org/ Open Source Bridge will be a completely volunteer-run, community effort to connect developers working with open source. Open Source Bridge will bring together the diverse tech communities of the greater Portland area and showcase our unique and thriving open source environment. We will show how well Portland does open source and share our best practices for development, community and connectedness with the rest of the world. We're kicking things off with a town hall discussion and planning meeting on October 30th, 7:30pm at CubeSpace (located at 622 SE Grand Avenue in Portland). We'll talk about overall goals for the conference, then break into small working groups to start tackling the event planning needs. If you can, bring an audio or video recorder to help document the discussion. Please let us know if you can attend. If October 30 doesn't work for you, let us know as we will be having a second meeting on the west-side. We'd very much like to have your participation in making this conference a fun, educational experience. You can RSVP by filling in the form at http://spreadsheets.google.com/viewform?key=p1ZDddPXGskYFX5NnM9FaXA&hl=en From joshua at keroes.com Wed Oct 29 18:10:14 2008 From: joshua at keroes.com (Joshua Keroes) Date: Wed, 29 Oct 2008 18:10:14 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: <490907B9.1000004@pragmaticraft.com> References: <490907B9.1000004@pragmaticraft.com> Message-ID: On Wed, Oct 29, 2008 at 6:02 PM, Igal Koshevoy wrote: > Tomorrow's the first public meeting of the group organizing a regional, > community-run open source conference to replace OSCON. Can't speak for the other languages out there but isn't YAPC going pretty strong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at petdance.com Wed Oct 29 18:55:47 2008 From: andy at petdance.com (Andy Lester) Date: Wed, 29 Oct 2008 20:55:47 -0500 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: References: <490907B9.1000004@pragmaticraft.com> Message-ID: <88A89162-DAF8-440E-BBD4-A5E9C7DF0B9C@petdance.com> On Oct 29, 2008, at 8:10 PM, Joshua Keroes wrote: > Can't speak for the other languages out there but isn't YAPC going > pretty strong? 10 year anniversary in Pittsburgh 2009. -- Andy Lester => andy at petdance.com => www.petdance.com => AIM:petdance From selenamarie at gmail.com Wed Oct 29 19:01:40 2008 From: selenamarie at gmail.com (Selena Deckelmann) Date: Wed, 29 Oct 2008 19:01:40 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: References: <490907B9.1000004@pragmaticraft.com> Message-ID: <2b5e566d0810291901k268c234w3e447de5cecae24e@mail.gmail.com> On Wed, Oct 29, 2008 at 6:10 PM, Joshua Keroes wrote: > On Wed, Oct 29, 2008 at 6:02 PM, Igal Koshevoy > wrote: >> >> Tomorrow's the first public meeting of the group organizing a regional, >> community-run open source conference to replace OSCON. > > > Can't speak for the other languages out there but isn't YAPC going pretty > strong? Indeed it is! I heard a rumor that we were going to try to bid for a YAPC Portland in 2010. :) -- Selena Deckelmann PDXPUG - http://pugs.postgresql.org/pdx Me - http://www.chesnok.com/daily From schwern at pobox.com Wed Oct 29 19:05:44 2008 From: schwern at pobox.com (Michael G Schwern) Date: Wed, 29 Oct 2008 19:05:44 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: References: <490907B9.1000004@pragmaticraft.com> Message-ID: <49091678.2030607@pobox.com> Joshua Keroes wrote: > On Wed, Oct 29, 2008 at 6:02 PM, Igal Koshevoy > wrote: > > Tomorrow's the first public meeting of the group organizing a regional, > community-run open source conference to replace OSCON. > > Can't speak for the other languages out there but isn't YAPC going > pretty strong? Regional, as in Pacific NW region. Also not just Perl, that's what the "Bridge" part is about. -- 24. Must not tell any officer that I am smarter than they are, especially if it's true. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/ From allison at perl.org Wed Oct 29 19:09:58 2008 From: allison at perl.org (Allison Randal) Date: Wed, 29 Oct 2008 19:09:58 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: <2b5e566d0810291901k268c234w3e447de5cecae24e@mail.gmail.com> References: <490907B9.1000004@pragmaticraft.com> <2b5e566d0810291901k268c234w3e447de5cecae24e@mail.gmail.com> Message-ID: <49091776.2060609@perl.org> Selena Deckelmann wrote: > > Indeed it is! I heard a rumor that we were going to try to bid for a > YAPC Portland in 2010. :) Sounds like an excellent idea! Allison From keithl at kl-ic.com Wed Oct 29 19:55:28 2008 From: keithl at kl-ic.com (Keith Lofstrom) Date: Wed, 29 Oct 2008 19:55:28 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: <490907B9.1000004@pragmaticraft.com> References: <490907B9.1000004@pragmaticraft.com> Message-ID: <20081030025528.GA10616@gate.kl-ic.com> (reply just to Igor and perlmongers ...) On Wed, Oct 29, 2008 at 06:02:49PM -0700, Igal Koshevoy wrote: > Tomorrow's the first public meeting of the group organizing a regional, > community-run open source conference to replace OSCON. I realize this > isn't much notice, but they'll have many more meetings in the future. > Please subscribe to their blog's feed for future meeting announcements > and information. Thanks! I won't be there, but here's a suggestion: Get some advice from the local science fiction convention folk, at www.osfci.org . They have been running Orycon for 30 (!) years, averaging 1500 attendees. They have also hosted four Westercons (Western US/Canada), with 2500 attendees, and many other conventions. Although the cast changes, there is a lot of accumulated experience. Some of the OSFCI people are also open source people, and many are programmers. And some may be looking for jobs; a convention with corporate booths is a good opportunity. OFSCI probably won't run a convention for you, but they could advise. On the other hand, the Detroit Michigan area science fiction fans have combined with the Linux/Open Source people to put on six Penguicons ( http://www.penguicon.org/ ) so far, and they are still going strong. If approached correctly and enthusiastically, this might be a winning combination. The next Orycon is November 21 to 23 at the waterfront Marriott. Hence, the principals will be very busy until then, and burned out for a few weeks after. If you sign up to attend the convention, uou can meet some of them (often known as "SMOF", Secret Masters Of Fandom). Yes, there may be a few Wookies, and 300 pound women in Princess Leia costumes - but treat them with respect, some might be open source project managers at Intel. On the other hand, anyone dressed as Jar-Jar Binks can be ridiculed. Keith -- Keith Lofstrom keithl at keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From igal at pragmaticraft.com Wed Oct 29 20:48:40 2008 From: igal at pragmaticraft.com (Igal Koshevoy) Date: Wed, 29 Oct 2008 20:48:40 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: <20081030025528.GA10616@gate.kl-ic.com> References: <490907B9.1000004@pragmaticraft.com> <20081030025528.GA10616@gate.kl-ic.com> Message-ID: <49092E98.1000107@pragmaticraft.com> Keith, I appreciate the suggestion. I've CC'ed Audrey and Selena from Bridge so they know about this. Could you get Audrey and Selena in touch with the Orycon organizers, and see if they'd be willing to go to lunch (I'll buy) and chat with the Bridge team? Thanks! -igal Keith Lofstrom wrote: > I won't be there, but here's a suggestion: > > Get some advice from the local science fiction convention folk, at > www.osfci.org . They have been running Orycon for 30 (!) years, > averaging 1500 attendees. They have also hosted four Westercons > (Western US/Canada), with 2500 attendees, and many other conventions. > Although the cast changes, there is a lot of accumulated experience. > Some of the OSFCI people are also open source people, and many are > programmers. And some may be looking for jobs; a convention with > corporate booths is a good opportunity. > > OFSCI probably won't run a convention for you, but they could advise. > On the other hand, the Detroit Michigan area science fiction fans have > combined with the Linux/Open Source people to put on six Penguicons > ( http://www.penguicon.org/ ) so far, and they are still going strong. > If approached correctly and enthusiastically, this might be a winning > combination. > > The next Orycon is November 21 to 23 at the waterfront Marriott. > Hence, the principals will be very busy until then, and burned out > for a few weeks after. If you sign up to attend the convention, > uou can meet some of them (often known as "SMOF", Secret Masters Of > Fandom). Yes, there may be a few Wookies, and 300 pound women in > Princess Leia costumes - but treat them with respect, some might be > open source project managers at Intel. On the other hand, anyone > dressed as Jar-Jar Binks can be ridiculed. > > Keith > > From spinnerin at gmail.com Wed Oct 29 20:52:21 2008 From: spinnerin at gmail.com (Audrey Eschright) Date: Wed, 29 Oct 2008 20:52:21 -0700 Subject: [Pdx-pm] Fwd: Open Source Bridge Conference town hall meeting - Thursday, October 30th, 7:30pm, CubeSpace In-Reply-To: <20081030025528.GA10616@gate.kl-ic.com> References: <490907B9.1000004@pragmaticraft.com> <20081030025528.GA10616@gate.kl-ic.com> Message-ID: <8D740FB2-D8FF-4C69-9C0A-CF52C1938C64@gmail.com> Yes, I definitely agree that local sf conventions are a good resource. I was on one of the program committees for Norwescon several years ago. It's an impressive example of what a volunteer organization can do. Audrey On Oct 29, 2008, at 7:55 PM, Keith Lofstrom wrote: > Get some advice from the local science fiction convention folk, at > www.osfci.org . They have been running Orycon for 30 (!) years, > averaging 1500 attendees. They have also hosted four Westercons > (Western US/Canada), with 2500 attendees, and many other conventions. > Although the cast changes, there is a lot of accumulated experience. > Some of the OSFCI people are also open source people, and many are > programmers. And some may be looking for jobs; a convention with > corporate booths is a good opportunity. From enobacon at gmail.com Thu Oct 30 13:07:37 2008 From: enobacon at gmail.com (Eric Wilhelm) Date: Thu, 30 Oct 2008 13:07:37 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding Message-ID: <200810301307.37695.enobacon@gmail.com> Hi all, I'm working on adding .dwg support to VectorSection (http://vectorsection.org/), which will involve a lot of twiddly bitwise navigation, seeks, unpacks and such of the binary format. It is also likely to hit a wall on speed rather quickly in Perl, but the code is also likely to be forced into looking like "C with dollar signs" because of the low-level nature of the task. I'm thinking that perhaps the way to go is to implement small parts in C, probably involving Inline to hook them into the Perl code. Keep in mind that I don't like C well enough to convince myself that I "know" it. Or rather, I don't want to spend all of my development time dealing with memory allocation. And just to keep things interesting, almost all of the data involved is going to be arrays and arrays of arrays. I'm wondering if someone can give me some feedback on how this would work and/or point me at some examples or reading material. My thought is that the C functions would all have one of the following signatures: bool gets_complex_data(source_struct, dest_struct); int gets_simple_data(source_struct); Where 'source_struct' is a pointer to a struct which essentially contains just the filehandle and maybe a bit of positional data (the input is stateful.) Then dest_struct is block allocated. The HLL binding would then be doing all of the memory allocation (part of the plan being to minimize the memory footprint, but also to make a 'Perlish' API.) I suppose this same scheme could be applied to a streaming processor in C. As I'm currently imagining it, the XS for extracting a polygon would resemble: int i; int points; pointstruct a_point; points = get_polygon_point_count(input); for(i=0; i < points; i++) { if(get_polygon_point(input, i, a_point)) { // do something with a_point } else { // fail, retry, whatever } } Where "do something" in this case is to create an AV and push it to the 'points' AV in the HV which gets returned. Thus, the library only sets values in the pre-allocated temporary 'a_point' struct and the rest of the memory management happens within the Perl interpreter. Thus, the Perl code will be somewhat buffered from the fine-grained details of "$pts = number_of_points" and "foreach (0..$pts) {...}". Now remember, I only know enough C to be dangerously amusing. But, I have never heard of a C library being created specifically for binding to an HLL interpreter, so I might be lacking the vocabulary needed to clarify what I think I'm trying to do. Part of the goal here would be to allow it to be easily bound to various other interpreters - hence not simply a big XS library. So, is this making any sense? Seem like a reasonable approach? Can anyone point me to a codebase which does something similar? And possibly a Perl binding? Thanks, Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From chromatic at wgz.org Thu Oct 30 13:30:44 2008 From: chromatic at wgz.org (chromatic) Date: Thu, 30 Oct 2008 13:30:44 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding In-Reply-To: <200810301307.37695.enobacon@gmail.com> References: <200810301307.37695.enobacon@gmail.com> Message-ID: <200810301330.44836.chromatic@wgz.org> On Thursday 30 October 2008 13:07:37 Eric Wilhelm wrote: > Keep in mind that I don't like C well enough to convince myself that > I "know" it. Or rather, I don't want to spend all of my development > time dealing with memory allocation. And just to keep things > interesting, almost all of the data involved is going to be arrays and > arrays of arrays. > > I'm wondering if someone can give me some feedback on how this would > work and/or point me at some examples or reading material. > > My thought is that the C functions would all have one of the following > signatures: > > bool gets_complex_data(source_struct, dest_struct); > int gets_simple_data(source_struct); > > Where 'source_struct' is a pointer to a struct which essentially > contains just the filehandle and maybe a bit of positional data (the > input is stateful.) Then dest_struct is block allocated. As long as those pointers are opaque to the bindings, this should be fine. Two things make life difficult for HLL extension writers: - memory management of shared library components - access to struct members of shared library components (especially if those structs change between *versions* of the shared library) > The HLL > binding would then be doing all of the memory allocation (part of the > plan being to minimize the memory footprint, but also to make > a 'Perlish' API.) This makes the HLL binding do a lot more work. It has to know how much memory to allocate (which can vary from platform to platform), so you'll end up recompiling the HLL binding every time the shared library changes. As well, you may have to keep track of what the shared library manages and what the bindings manage, so you free to the right place and don't leak. If you always treat the data structures used by the shared library as opaque outside of the shared library, you don't have these problems. Any decent HLL binding should be able to represent a raw C pointer as a pointer and pass it around appropriately, without allowing direct memory access to the pointer itself or what it contains. Think inside-out objects where you don't have method dispatch, and you'll have the idea. > Now remember, I only know enough C to be dangerously amusing. But, I > have never heard of a C library being created specifically for binding > to an HLL interpreter, so I might be lacking the vocabulary needed to > clarify what I think I'm trying to do. Part of the goal here would be > to allow it to be easily bound to various other interpreters - hence > not simply a big XS library. Reentrancy is an issue then too. No static data (unless it's compile time static). > So, is this making any sense? Seem like a reasonable approach? Can > anyone point me to a codebase which does something similar? And > possibly a Perl binding? I can point you to codebases that do it wrong. libcurl's memory management lifecycle for strings passed in to set URL paths is shudderworthy. -- c From enobacon at gmail.com Thu Oct 30 15:13:08 2008 From: enobacon at gmail.com (Eric Wilhelm) Date: Thu, 30 Oct 2008 15:13:08 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding In-Reply-To: <200810301330.44836.chromatic@wgz.org> References: <200810301307.37695.enobacon@gmail.com> <200810301330.44836.chromatic@wgz.org> Message-ID: <200810301513.08745.enobacon@gmail.com> # from chromatic # on Thursday 30 October 2008 13:30: >> The HLL >> binding would then be doing all of the memory allocation (part of >> the plan being to minimize the memory footprint, but also to make a >> 'Perlish' API.) > >This makes the HLL binding do a lot more work. That's actually part of the plan. Given that making a perlish API for any non-trivial data requires some manipulation of HV's and AV's (aka "a lot of work"), and that I have to write everything from a blank slate, I was figuring on keeping the shared library rather dumb. >It has to know how > much memory to allocate (which can vary from platform to platform), The goal there was "none". The temporary structs are lexically scoped by the caller (this is called an "automatic variable"?) and pointers to them are passed into the shared functions, so nothing in the shared library deals with memory. // in sharedthingy.h struct pointstruct { float x; float y; float z; }; // in Inline::C code: SV* next_polygon(SV* obj) { filedatastruct* fds = (filedatastruct*) SvIV(SvRV(obj)); ... HV * hash = newHV(); int i; int p; pointstruct * a_point; ... p = get_polygon_point_count(fds); for(i=0; ix); av_push(pt, newSVnv(a_point->y); av_push(pt, newSVnv(a_point->z); ... return(newRV_noinc((SV*) hash)); } At least, that's what I have in my head thus far. Am I correct in my reading that there's nothing to malloc/free here outside of what the perlapi calls are doing for me? > so you'll end up recompiling the HLL binding every time the shared > library changes. Assuming that I *want* some part of this to be in XS, you have to do that anyway, right? At least, I think I want the loop over e.g. get_polygon_point() to be happining in the XS. Meaning, that for e.g. 1000 polygons you would have 4000+ function calls between the XS and C code but only 1000 calls to the XS function (each of these returns a hash reference such as "{points => [[$x0,$y0],[$x1,$y1],[$x2,$y2]], color => 0xFF0000, ...}".) The alternative seems to be writing a lot of repetitive perl code, or a lot of C code which deals with memory management which will have to then be done over again in XS to get a binding. So, I'm thinking there would be no next_polygon() function in the shared library. This would mean that the low-level stuff in the shared library could stick to just dealing with the bitwise twiddly stuff, while the binding would mostly deal with assembling Perl data structures and error handling. Now of course this assumes that the interpreter is implemented in C. What would something like this mean in parrot? Thanks, Eric -- "Everything should be made as simple as possible, but no simpler." --Albert Einstein --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From chromatic at wgz.org Thu Oct 30 16:06:03 2008 From: chromatic at wgz.org (chromatic) Date: Thu, 30 Oct 2008 16:06:03 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding In-Reply-To: <200810301513.08745.enobacon@gmail.com> References: <200810301307.37695.enobacon@gmail.com> <200810301330.44836.chromatic@wgz.org> <200810301513.08745.enobacon@gmail.com> Message-ID: <200810301606.03390.chromatic@wgz.org> On Thursday 30 October 2008 15:13:08 Eric Wilhelm wrote: > >This makes the HLL binding do a lot more work. > That's actually part of the plan. Given that making a perlish API for > any non-trivial data requires some manipulation of HV's and AV's > (aka "a lot of work"), and that I have to write everything from a blank > slate, I was figuring on keeping the shared library rather dumb. You're not going to avoid the HV/AV problem, unless your HLL can manipulate C data structures directly (Parrot can, and Perl 5 can, if you want to use tie magic from XS, which I don't). > >It has to know how > > much memory to allocate (which can vary from platform to platform), > The goal there was "none". The temporary structs are lexically scoped > by the caller (this is called an "automatic variable"?) and pointers to > them are passed into the shared functions, so nothing in the shared > library deals with memory. That means if the struct size ever changes (or alignment, or padding, or compiler, or ... okay, that's about it), the HLL bindings have to change, and then you have versioning questions, and that's yucky. > // in sharedthingy.h > struct pointstruct { > float x; > float y; > float z; > }; > > // in Inline::C code: > SV* next_polygon(SV* obj) { > filedatastruct* fds = (filedatastruct*) SvIV(SvRV(obj)); > ... > HV * hash = newHV(); > int i; > int p; > pointstruct * a_point; There's a crash waiting to happen. You've just asked C to allocate room a pointer on the stack. That's fine, but it doesn't point to anything, and you're about to pass an unintialized pointer to code that presumably will dereference it and get garbage values (or, if it *writes* to struct members through the pointer, will overwrite other locations in memory that may contain other data you cared about). Instead: pointstruct a_point; > p = get_polygon_point_count(fds); > for(i=0; i ... > get_polygon_point(fds, i, a_point); ... and then: get_polygon_point(fds, i, &a_point); > At least, that's what I have in my head thus far. Am I correct in my > reading that there's nothing to malloc/free here outside of what the > perlapi calls are doing for me? That's right, as long as you fix the initialization code so that the C compiler initializes the right amount of memory (sizeof( pointstruct ) rather than sizeof (poinstruct *)). Like I said though, if sizeof( pointstruct ) ever changes, you'll have to recompile this XS against the new headers (for Perl 5 bindings) or regenerate the PIR code that builds a pointstruct from the headers and a ManagedStruct PMC in Parrot. If you instead wrote: pointstruct *p = new_pointstruct(); ... free_pointstruct(p); ... and kept that API the same, and never allowed anyone to access struct members directly, you wouldn't have to recompile and you'd be free to rearrange and manipulate struct members between versions of your library all you want. > > so you'll end up recompiling the HLL binding every time the shared > > library changes. > Assuming that I *want* some part of this to be in XS, you have to do > that anyway, right? Only if any of the details the XS rely on change. If function signatures don't change (even if you *add* functions), then you shouldn't have to recompile (unless you change compilers or the compilers change their ABIs). > This would mean that the low-level stuff in the shared library could > stick to just dealing with the bitwise twiddly stuff, while the binding > would mostly deal with assembling Perl data structures and error > handling. That's generally what you want. > Now of course this assumes that the interpreter is implemented in C. > What would something like this mean in parrot? If the Parrot bindings had to handle anything other than an opaque pointer, I would summon an army of righteousness to march on your house (I know where you live) and convince you of the error of your ways -- not because Parrot can't do it, but because it's 2008, by gum, and I know you can spell "encapsulation". -- c From paull at peak.org Thu Oct 30 22:16:30 2008 From: paull at peak.org (paull at peak.org) Date: Thu, 30 Oct 2008 22:16:30 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding In-Reply-To: <200810301307.37695.enobacon@gmail.com> References: <200810301307.37695.enobacon@gmail.com> Message-ID: <1225430190.6575.15.camel@pavillion> On Thu, 2008-10-30 at 13:07 -0700, Eric Wilhelm wrote: > I'm wondering if someone can give me some feedback on how this would > work and/or point me at some examples or reading material. Hey Eric I have written maybe half a dozen very similar modules for various EDA formats like GDSII, Lef, Def, Edif, Verilog, and spice. These formats have nice grammars, so the typical approach is a flex/bison pair where major (interesting) grammatical productions brew up a HV/AV complex data structure and pass it to a user defined (Perl) callback. A C library specifically for binding to a HLL interpreter. This architecture makes it very easy to implement "filter" scripts that grep out salient bits or create new content. The closest analog I have seen in CPAN modules is that of HTML::Parser. You setup callbacks for what you want to catch and press GO. Mucho gusto. The best in class of my modules parses Cadence Design Exchange Format (Def). Def is a textual description of a place and route database for an integrated circuit. The files are honking big and just complex enough to make parsing with regexps uncomfortable. I can't release the full code but maybe these snippets will be useful. -Paul -------------- next part -------------- NAME Local::Def - Parser for Cadence DEF files SYNOPSIS use Local::Def; $obj = new Local::Def; $obj->callback( => codeRef, ... ); $obj->parse( "def_filename" ); $obj->terminate; $was = $obj->select( [ globRef ] ); $was = $obj->autoPrint( [ Boolean ] ); $obj->autoFormat; $obj->p( args ); DESCRIPTION This module implements a parser for Cadence DEF files. As the parser works its way through a file it recognizes various grammatical productions. Each recogintion can trigger a callback to a user defined (Perl) sub. In order for the callback to occur, the sub (coderef) must be registered with callback. When the parser encounters an unregistered production, the production is skipped. autoPrint is a mode where these unregistered productions are copied to the select?ed filehandle instead of being skipped. The module provides print methods for each production. The print methods have the same argument signature as the callback for the corresponding production. The print methods all target the select?ed filehandle, but differ from the autoprint output in that they reformat the data. Creation of DEF filters can be accomplished by intercepting, manipulating, and then printing productions of interest. PRODUCTIONS The DEF being parsed is broken up into bite sized chunks known as productions. For example, each instance in a design (like NAND2FF) is detailed in the "components" section. The DEF grammar describes a "components" section as having three parts: a Begin production, any number of Body productions, and an End production. COMPONENTS 3 ; # Begin - clkgen_/U124 NINVEE ; # -+ - clkgen_/U125 THIGH # ? + FIXED ( 123780 633650 ) FS # + Body + WEIGHT 10 ; # ? - clkgen_/U126 NINVEE ; # -+ END COMPONENTS # End The parser considers this snippet to contain five productions. The callback for BeginComponents is invoked once. As BeginComponents only has one piece of data (the number of components, "3" in this case) it is referred to as a scalar callback. The Components callback is invoked three times, once for each component. Note that each component brings along several pieces of data. Some of these data fields are optional and will not be specified for every component. What we need is a dynamic data structure to house this data. A hash is a good choice. The parser builds up a hash, with whatever fields are present in the production, and provides the callback with a reference to this hash. The possible keys of the hash, and their meanings, are detailed below. This type is referred to as a hashref callback. Finally, EndComponents gets called once. There is no ancillary data with any EndComponents production, so it is referred to as a null callback. Begin-Body-End productions Each of the following names a production. For each name there also exist Begin and End productions. So, for "Components", there exist three productions: BeginComponents, Components and EndComponents. Components Constraints DefaultCap Groups IOTimings Nets PinProperties Pins PropertyDefinitions Regions ScanChains SpecialNets Vias Stand alone productions Each of these productions are single entities. Unlike the Begin-Body- End productions they do not have an ordering relative to other productions. BusBitChars Design DieArea DividerChar EndDesign GCellGrid History NamesCaseSensitive Row Technology Tracks Units Version This parser is built for version 5.1 of the DEF grammar. An earlier version of the DEF grammar included a SITE production. This module supports the deprecated "SITE" production as a degenerate case of a ROW - a Row without a row-name. If a SITE is encountered it will trigger the Row callback. CALLBACKS A callback is a Perl sub (code reference) that you "register" with the parser by associating it with a production. When the parser has completed the recognition of a production it invokes your sub, passing it any arguments relevant to the production. The parser always provides callbacks with the Local::Def object itself, as the first argument. Having this object reference provides callbacks access to object methods. Here is an example that counts the number of instances for each type of cell in a design: use Local::Def; $obj = new Local::Def; $obj->callback( Components => \&countModels, EndComponents => \&showCounts, ); $obj->parse( $ARGV[0] ); sub countModels { my( $self, $comp ) = @_; my( $model ); $model = $comp->{ Model }; ++$counts{ $model }; } sub showCounts { my( $self ) = @_; my( $key ); foreach $key (sort keys %counts ) { printf("\t%-23s %5d\n", $key, $counts{$key} ); } $self->terminate(); } METHODS Once an Local::Def object has been created (using new()) you can begin using any of the methods. Local::Def::new() new() creates an Local::Def object. This object contains state information relevant to the parsing process such as callback registration, selected output file handle etc. It does NOT include flex(1) input buffers or yacc(1) stack, so re-entrancy is NOT supported. You may create multiple Local::Def objects in a single program, they will maintain separate lists of callbacks etc., but you cannot have the callback of one invoke the parse action of another. $obj->callback() The callback method takes any number of Production => codeRef pairs as arguments. Callback registration can be changed on-the-fly (from within a callback) if desired. An active callback can be disabled by registering undef as the codeRef. A subroutine name (string scalar) can be used in lieu of a codeRef. $obj->parse() parse() requires a file name for input. It cannot use Perl filehandles, or read from stdin. parse() may be called repeatedly (on different files), but not recursively (from a callback). $obj->terminate() By calling $obj->terminate from within a callback, you are sending a message to the parser telling it to forego processing of any further input. After a callback has completed, the parser checks to see if termination has been requested and returns from $obj->parse() if it has. If you are extracting data from just the Pins productions (for example), you could call $obj->terminate from within EndPins in order to speed up overall processing by skipping the remainder of the file: $obj->callback( EndPins => sub { $_[0]->terminate; } ); $obj->autoPrint() Sometimes it is desired to filter a DEF file, changing only certain sections. autoPrint() is provided as an efficient mechanism to print all portions of the file that are not otherwise being recognized for construction of callback arguments. Here is a slow cat(1): $obj = new Local::Def; $obj->autoPrint(1); $obj->parse( $file ); Here is a much slower one: $obj = new Local::Def; $obj->callback( BeginComponents => \&Local::Def::pBeginComponents, BeginConstraints => \&Local::Def::pBeginConstraints, ... Tracks => \&Local::Def::pTracks, Units => \&Local::Def::pUnits, Version => \&Local::Def::pVersion, Vias => \&Local::Def::pVias ); $obj->parse( $file ); Note that this second version, while logically equivalent to the original file, may have different ordering for optional constructs, and different indentation and use of whitespace. autoPrint() without any arguments returns the current state; autoPrint() with an argument sets the new state and returns the old one. $obj->autoFormat() It turns out that the "much slower cat(1)" is quite handy. A shorthand for making all the callback assignments at once is: $obj->autoFormat; This overwrites all existing callbacks, setting them to the corresponding print methods. The common use is to invoke autoFormat to initialize all the methods, then set selective intercepts using callback. $obj->select() When autoPrint is enabled, or when you invoke one of the p methods, your output is directed to a filehandle. The output filehandle is initialized to STDOUT when the object is constructed. By providing select() with a filehandle globRef you redirect the autoPrint and p output. $outFile = "output.def"; open( DEFOUT, ">$outFile" ) or die "$outFile: $!\n"; $previous = $obj->select( \*DEFOUT ); select() without any arguments returns a globRef to the current filehandle. select() with an argument sets the new filehandle and returns the previous filehandle?s globRef. Note that to use the returned globRef as a filehandle for print you will need to wrap it in a block. See the documentation on print in perlfunc(1) for more details. if ( $obj->autoPrint ) { print { $obj->select } "\n# Adding comments here"; } $obj->p() In our "even slower cat(1)" example we registered "print" actions for every callback. Just as every production in the Def grammar has a callback, every production also has a corresponding "print" method that takes the same argument list as the callback. These print methods are named by prepending a "p" to the production. Consider the "BeginNets" callback, for example. When the parser invokes the callback associated with the BeginNets production, it passes two arguments: an object reference and a scalar. The corresponding method, Local::Def::pBeginNets(), exists and expects an object reference and a scalar as arguments. Here is a snippet that does no parsing at all, it uses only the printing methods to create a Def file that will have consistent syntax. $obj = new Local::Def; $obj->pDesign( "Venom" ); $obj->pBeginPins( scalar( @ports ) ); foreach $pin ( @ports ) { $obj->pPins( { Pin => $pin, Net => $pin } ); } $obj->pEndPins; CALLBACK and pPRODUCTION ARGUMENTS As mentioned earlier, there are three different argument conventions used by the parser when invoking callbacks: $obj # Null, no additional data $obj, $scalar # A single piece of information $obj, $hashRef # A complex data structure Many aspects in the DEF grammar are optional. A Component, for example, may or may not have been assigned a location (placed). If an optional attribute is not present then the hash passed to the callback will not have the corresponding key. DieArea : HashRef LLX => Number, Required LLY => Number, Required URX => Number, Required URY => Number, Required GCellGrid : HashRef X => -+ Y => -+- HashRef, Optional { Origin => Number, Required Num => Number, Required Step => Number, Required } "X" and "Y" keys have identical HashRef structures. History : scalar Row : HashRef RowName => String, Required RowType => String, Required OriginX => Number, Required OriginY => Number, Required Orient => String, Required NumX => Number, Required NumY => Number, Required StepX => Number, Required StepY => Number, Required Properties => HashRef, Optional { "prop" => "value", ... } Note that if the deprecated SITE production is encountered then this Row callback will be triggered, but the RowName key will contain the string "SITE". The pRow will output the older SITE form if the rowname is "SITE". Technology : scalar Tracks Direction => String, Required Origin => Number, Required Num => Number, Required Step => Number, Required Layer => ArrayRef, Required [ "layer", ... ] The Direction String will be either "X" or "Y". Units : scalar This is the UNITS DISTANCE MICRONS setting, typically 100. Design : scalar EndDesign : NULL BeginComponents : scalar EndComponents : NULL Components : HashRef Component => String, Required Model => String, Required Connections => ArrayRef, Optional [ String # NetName ... ] Generator => String, Optional Parameters => ArrayRef, Optional [ String # Parameter ... ] Source => String, Optional ForeignName => String, Optional ForeignX => Number, Optional ForeignY => Number, Optional ForeignOrient => String, Optional PlacementType => String, Optional PlacementX => Number, Optional PlacementY => Number, Optional PlacementOrient => String, Optional RegionName => String, Optional Region => HashRef, Optional { LLX => Number, Required LLY => Number, Required URX => Number, Required URY => Number, Required } Properties => HashRef, Optional { "prop" => "value", ... } The "Connections" NetNames will be in implicit port order. The "Parameters" are parameters to the generator. The "Source" String will be either "NETLIST", "DIST", "USER" or "TIMING". The "ForeignOrient" and "PlacementOrient" Strings will be one of "N","S", "E","W","FN","FS","FE" or "FW". The "PlacementType" String will be either "FIXED","COVER","PLACED" or "UNPLACED". BeginConstraints : scalar EndConstraints : NULL Constraints : HashRef WiredLogic => String, Optional MaxDist => Number, Optional RiseMin => Number, Optional RiseMax => Number, Optional FallMin => Number, Optional FallMax => Number, Optional Net => String, Optional Path => HashRef, Optional { FromComponent => String, Required FromPin => String, Required ToComponent => String, Required ToPin => String, Required } Sum => ArrayRef, Optional [ # One or more of any of these... [ "Net", String ] [ "Path", HashRef ] [ "Sum", ArrayRef ] ] BeginDefaultCap : scalar EndDefaultCap : NULL DefaultCap : HashRef MinPins => Number, Required WireCap => Number, Required BeginGroups : scalar EndGroups : NULL Groups : HashRef Name => String, Required Component => ArrayRef, Required [ String, ... ] Soft => HashRef { MaxHalfPerimeter=> Number, Optional MaxX => Number, Optional MaxY => Number, Optional } Region => HashRef, Optional { LLX => Number, Required LLY => Number, Required URX => Number, Required URY => Number, Required } RegionName => String, Optional Properties => HashRef, Optional { "prop" => "value", ... } BeginIOTimings : scalar EndIOTimings : NULL IOTimings : HashRef Component => String, Required Pin => String, Required RiseVariable => Number, Optional FallVariable => Number, Optional RiseSlewRate => Number, Optional FallSlewRate => Number, Optional Capacitance => Number, Optional BeginNets : scalar EndNets : NULL Nets : HashRef Name => String, Required Connections => ArrayRef [ [ String, String, Flag ] ... ] Xtalk => Number, Optional NonDefaultRule => String, Optional Source => String, Optional Original => String, Optional Use => String, Optional Pattern => String, Optional EstCap => String, Optional Weight => String, Optional Fixed => -+ Routed => +- ArrayRef, Optional Cover => -+ [ # Each Branch in the net [ # Each layer change in the branch { Layer => String, Required Taper => Flag, Optional TaperRule => String, Optional Path => ArrayRef [ # Each turn on the layer [ Number, Number, Number ], # X, Y, Ext starting # one or more of the following [ Number, Number, Number ] # X, Y, Ext [ Number, String, Number ] # X, "STAR", Ext [ String, Number, Number ] # "STAR", Y, Ext [ String ] # Via ] } ] ] Properties => HashRef, Optional { "prop" => "value", ... } The [ String, String, Flag ] sub-arrays contain the Component as the first element and Pin-name as the second element. If a third element is present, no matter the contents, then "Synthesized" is implied. The Component can be "PIN" or "VPIN". "ROUTED", "FIXED" and "COVER" keys all have similar ArrayRef structures. The third element in the path sub-arrays "Ext" is an optional wire extension; arrays will commonly have only two elements. If either of the first two is the string "STAR" then the corresponding X or Y coordinate from the previous point is to be replicated - an orthogonal turn is implied. Existence of the "Taper" key implies a tapered path, regardless of the value. "TaperRule" tags a tapering rule name. BeginPinProperties : scalar EndPinProperties : NULL PinProperties : HashRef Component => String, Required Pin => String, Required Properties => HashRef, Required { "prop" => "value", ... } BeginPins : scalar EndPins : NULL Pins : HashRef Pin => String, Required Net => String, Required Special => Flag, Optional Direction => String, Optional Use => String, Optional PlacementType => String, Optional PlacementX => Number, Optional PlacementY => Number, Optional PlacementOrient, String, Optional Layer => String, Optional LLX => Number, Optional LLY => Number, Optional URX => Number, Optional URY => Number, Optional "Direction" is one of "INPUT", "OUTPUT", "INOUT" or "FEEDTHRU". "PlacementOrient" will be one of "N","S", "E","W","FN","FS","FE" or "FW". "PlacementType" will be one of "FIXED", "PLACED" or "COVER". "Use" will be one of "SIGNAL", "POWER", "GROUND", "CLOCK" "TIEOFF" or "ANALOG". Existence of the "Special" key implies SPECIAL, regardless of value. BeginPropertyDefinitions : NULL EndPropertyDefinitions : NULL PropertyDefinitions : HashRef ObjectType => String, Required PropName => String, Required PropType => String, Required Range => ArrayRef, Optional [ Number, # Min Number # Max ] Value => Number or String, Optional "ObjectType" is one of "DESIGN", "COMPONENT", "NET", "SPECIALNET", "GROUP", "ROW", "PIN" or "REGION". "PropType" is one of "INTEGER", "REAL", "STRING" or "NAMEMAPSTRING". BeginRegions : scalar EndRegions : NULL Regions : HashRef Name => String, Required Regions => ArrayRef, Required [ { LLX => Number, Required LLY => Number, Required URX => Number, Required URY => Number, Required } ... ] BeginScanChains : scalar EndScanChains : NULL ScanChains : HashRef Name => String, Required CommonScanPins => HashRef { In => String, Optional Out => String, Optional } Start => HashRef, Optional { Component => String, Required Out => String, Optional } Ordered => -+ Floating => -+- ArrayRef, Optional [ { Component => String, Required In => String, Optional Out => String, Optional } ... ] Stop => HashRef, Optional { Component => String, Required In => String, Optional } The "Ordered" and "Floating" keys have identical ArrayRef structures The "Component" in either "Start" or "Stop" can be "PIN" to imply a pin. BeginSpecialNets : scalar EndSpecialNets : NULL SpecialNets : HashRef Name => String, Required Connections => ArrayRef [ [ String, String, Flag ] ... ] Width => Number, Optional Voltage => Number, Optional Spacing => HashRef, Optional { "layer" => HashRef, Required { Spacing => Number, Required Range => ArrayRef, Optional [ Number, Number ] } ... } Source => String, Optional Original => String, Optional Use => String, Optional Pattern => String, Optional EstCap => String, Optional Weight => String, Optional Fixed => -+ Routed => +- ArrayRef, Optional Cover => -+ [ # Each Branch in the net [ # Each layer change in the branch { Layer => String, Required Width => Number, Required Shape => String, Optional Path => ArrayRef, Required [ # Each turn on the layer [ Number, Number, Number ], # X, Y, Ext starting # one or more of the following [ Number, Number, Number ] # X, Y, Ext [ Number, String, Number ] # X, "STAR", Ext [ String, Number, Number ] # "STAR", Y, Ext [ String ] # Via ] } ] ] Properties => HashRef, Optional { "prop" => "value", ... } In "Connections" the [ String, String, Flag ] sub-arrays contain Component and Pin names in the first two elements. If a third element is present, no matter the contents, then the "Synthesized" attribute is implied. The third element in the path sub-arrays "Ext" is an optional wire extension; arrays will commonly have only two elements. If either of the first two is the string "STAR" then the corresponding X or Y coordinate from the previous point is to be replicated - an orthogonal turn is implied. The "Spacing" hash is indexed by layer name. "ROUTED", "FIXED" and "COVER" keys all have similar ArrayRef structures. "Use" will be "SIGNAL", "POWER", "GROUND", "CLOCK" "TIEOFF" or "ANALOG". "Pattern" will be "STEINER", "BALANCED", "WIREDLOGIC" or "TRUNK". "Shape" will be "RING", "STRIPE", "FOLLOWPIN", "IOWIRE", "COREWIRE", "BLOCKWIRE", "FILLWIRE" or "BLOCKAGEWIRE". BeginVias : scalar EndVias : NULL Vias : HashRef Name => String, Required Patterns => ArrayRef, Optional [ { Pattern => String, Optional Rects => ArrayRef, Optional [ { Layer => String, Optional LLX => Number, Optional LLY => Number, Optional URX => Number, Optional URY => Number, Optional } ] } ] NamesCaseSensitive : scalar Version : scalar BusBitChars : scalar DividerChar : scalar SEE ALSO LEF/DEF Language Reference, perllol(1), perldsc(1), perlmod(1), perl(1) -------------- next part -------------- I like to create one large typedef that contains all the callbacks and any parser state. This will become my Perl object. Something like: typedef struct { /* callbacks */ SV *cbBeginComponents; SV *cbBeginConstraints; SV *cbBeginDefaultCap; SV *cbBeginGroups; SV *cbBeginIOTimings; SV *cbBeginNets; SV *cbBeginPinProperties; ... int switchToAnyText; int switchToName; int switchToNotNewName; int switchToPropDef; int switchToValue; int print; int terminate; int callbackOnDefMinus; SV *self; SV *gv; PerlIO *ofp; int lineno; char hold[ 256 ]; char *filename; } DefObj; new() looks something like this: static SV * new( SV *class ) { DefObj init; DefObj *obj; size_t len; SV *self; init.cbBeginComponents = &sv_undef; init.cbBeginConstraints = &sv_undef; init.cbBeginDefaultCap = &sv_undef; init.cbBeginGroups = &sv_undef; init.cbBeginIOTimings = &sv_undef; init.cbBeginNets = &sv_undef; init.cbBeginPinProperties = &sv_undef; ... init.switchToAnyText = 0; /* False */ init.switchToName = 0; /* False */ init.switchToNotNewName = 0; /* False */ init.switchToPropDef = 0; /* False */ init.switchToValue = 0; /* False */ init.print = 0; /* False */ init.terminate = 0; /* False */ init.callbackOnDefMinus = 0; /* False */ init.ofp = PerlIO_stdout(); init.lineno = 1; init.filename = (char*) 0; init.hold[0] = '\0'; init.gv = newRV( *hv_fetch( gv_stashpv( "main", 0 ), "STDOUT", 6, 0 )); self = newRV( newSVpv( (char *)&init, sizeof( DefObj ))); obj = (DefObj*) SvPV( SvRV( self ), len ); obj->self = self; return sv_bless( self, gv_stashsv( class, 0 )); } What I did here was to initialize a C auto variable (init) and then make a Perl string (newSVpv) to hold a copy of it. This only works if Perl aligns SVpv storage to worst-case boundaries (double on 8 byte for my platforms at work), which it appears to do. I bless this string and it becomes my object. I generally spend a lot of effort in the scanner to skip over large chunks, if there is no callback that needs to be fed. Most of the XS is dirt simple because I only pass Perl types back and forth. void parse(self,fname) SV *self SV *fname PROTOTYPE: $$ void autoFormat(self) SV *self PROTOTYPE: $ SV * new(class) SV *class PROTOTYPE: $ void callback(self, ...) SV *self PREINIT: DefObj *dg; size_t i; size_t len; CODE: if ( 1 != ( items % 2 )) { /* 1 for self */ croak( "callback(): Odd number of arguments" ); } dg = (DefObj*)SvPV( SvRV( self ), len ); for( i = 1; i < items; i += 2 ) { insertCallback( dg, ST( i ), ST( i + 1 )); } PROTOTYPE: $@ Manufacturing all the HV/AV stuff though, is lotsa work. I found that once I settled on a set of conventions for how I passed complex data back to the user I could encapsulate most of the work into a mini language built up of macros. Here is a typical production from the parser: propDefs /* %type */ : /* Empty */ | propDefs /* $1 */ objectType /* $2 */ { BeginNAME; } DEF_NAME /* $4 */ propType /* $5 */ range /* $6 */ propValue /* $7 */ DEF_SEMICOLON /* $8 */ { DeclareArgs; TagStore( args, TAG_OBJECTTYPE, $2 ); TagStore( args, TAG_PROPNAME, $4 ); TagStore( args, TAG_PROPTYPE, $5 ); ErtStore( args, TAG_RANGE, $6 ); if ( $7 ) { TagStore( args, TAG_VALUE, $7 ); } CallBack1Arg( PropertyDefinitions, argsRef ); BeginPROPDEF; } ; The helper macros look like this: #define DeclareArgs \ HV *args = newHV(); \ SV *argsRef = newRV( (SV*)args ); \ SvREFCNT_dec( (SV*)args ) #define TagStore(h,t,v) \ hv_store( h, TagName(t), TagLen(t), v, 0 ) #define CallBack1Arg(CB,arg1) \ if ( &sv_undef != defGlobal->cb##CB ) { \ dSP; \ PUSHMARK(sp); \ XPUSHs( defGlobal->self ); \ XPUSHs( arg1 ); \ PUTBACK; \ perl_call_sv( defGlobal->cb##CB, G_DISCARD | G_SCALAR ); \ } \ SvREFCNT_dec( arg1 ); \ if ( defGlobal->terminate ) return 0 From enobacon at gmail.com Thu Oct 30 23:30:22 2008 From: enobacon at gmail.com (Eric Wilhelm) Date: Thu, 30 Oct 2008 23:30:22 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding In-Reply-To: <1225430190.6575.15.camel@pavillion> References: <200810301307.37695.enobacon@gmail.com> <1225430190.6575.15.camel@pavillion> Message-ID: <200810302330.22270.enobacon@gmail.com> # from paull at peak.org # on Thursday 30 October 2008: >These formats >have nice grammars, so the typical approach is a flex/bison pair where >major (interesting) grammatical productions brew up a HV/AV complex > data structure and pass it to a user defined (Perl) callback. > >A C library specifically for binding to a HLL interpreter. Hi Paul, Thanks, that definitely helps my thinking. The mini-language of macros trick might come in particularly handy given the repetitive nature of some of the unpacking. Aside: One of my references for this project is going to be the python code which Art Haas did as a first-attempt based on the ODA published findings of the format. I'm not sure whether there was code generation involved here, but starting around line 213 there is a very unsettling pattern: http://vectorsection.org/svn/trunk/python/lib/acad/dwg15.py --Eric -- "If you only know how to use a hammer, every problem begins to look like a nail." --Richard B. Johnson --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From enobacon at gmail.com Thu Oct 30 23:55:33 2008 From: enobacon at gmail.com (Eric Wilhelm) Date: Thu, 30 Oct 2008 23:55:33 -0700 Subject: [Pdx-pm] Designing a C library specifically for HLL binding In-Reply-To: <200810301606.03390.chromatic@wgz.org> References: <200810301307.37695.enobacon@gmail.com> <200810301513.08745.enobacon@gmail.com> <200810301606.03390.chromatic@wgz.org> Message-ID: <200810302355.33176.enobacon@gmail.com> # from chromatic # on Thursday 30 October 2008: >> ? ? pointstruct * a_point; > >There's a crash waiting to happen. Ah, that's good to know. >????????pointstruct a_point; >... >????????get_polygon_point(fds, i, &a_point); >Like I said though, if sizeof( pointstruct ) ever changes, you'll have > to recompile this XS against the new headers (for Perl 5 bindings) or > regenerate the PIR code that builds a pointstruct from the headers > and a ManagedStruct PMC in Parrot. What if I forgo the "shared library" bit and just go with something like "#include foo.c"? Can I then sidestep the encapsulation police? :-) >If you instead wrote: >????????pointstruct *p = new_pointstruct(); >????????... >????????free_pointstruct(p); >... and kept that API the same, and never allowed anyone to access > struct members directly, you wouldn't have to recompile and you'd be > free to rearrange and manipulate struct members between versions of > your library all you want. Given that the "library" is only intended as an organizing principle to provide sanity to the binding, is it worth the run-time penalty for this encapsulation? I'm assuming here that there must be a non-zero number of operations (which would also include accessors to each of the x,y,z members of the struct, no?) and that there's not somehow a magically zero cost to this encapsulation. What is the trade-off in making it a truly "shared" library? Some memory savings when more than one app is linked to that .so (and not simply more than one perl process because that XS is itself a .so, right?)? Unless I'm missing something in that set of factors (which is quite possible), it hardly seems worth running (and writing) the extra code to encapsulate access to the structs which only exist to keep the thing from being a (lexical) monolith of XS. And yes I'm trading everything I can for speed, or at least at this point trying to figure out where it can be had. There's another line of thought brewing which might involve source filters or similar dirty words, but I'll save this heresy for later. --Eric -- The only thing that could save UNIX at this late date would be a new $30 shareware version that runs on an unexpanded Commodore 64. --Don Lancaster (1991) --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------