Another XS type of thing: Orchard/C
--- start of forwarded message --- From: Ken MacLeod [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Orchard/C 0.2.3 preview release available Date: 15 Nov 2000 09:38:56 -0600 Half of the Perl interface into Orchard/C is complete, you can now call C functions and return C objects to Perl. (The other half is Orchard/C calling Perl.) ftp://orchard.sourceforge.net/pub/orchard Included examples are an Expat node-based SAX wrapper and two sets of XML objects (one optimized for in-memory usage, one not). Orchard/C is comparible to SWIG, as it's intended to make interfacing C to Perl (and Python and Tcl) very easy and portable. SWIG is intended for wrapping existing C/C++ libraries and must contend with C data types. Orchard/C, on the other hand, is intended for writing new C code as performance enhancements for Perl/Py/Tcl. Because Orchard/C code is written with scripting languages in mind, several things have been done to make this easier, including a fast OO-like runtime (pure C, albeit preprocessed), object attribute accessors, garbage collection (Boehm GC), and transparent interfacing (no code or interface files) of Orchard/C classes to Perl/Py/Tcl classes. Orchard/C requires Expat 1.95.x and Boehm GC (see the README), both of which are very easy to compile (on Unix, anyway). The Perl interface is in 'perlif/' and is compiled as a second step after compiling Orchard/C, and it compiles like a standard Perl module. The Perl interface includes wrapper modules for the main C classes: Orchard::SAXDriver::Expat, Orchard::TreeBuilder, Orchard::XML::FastSmall, etc. Adding the ability for Orchard/C to call Perl code is up next. Future enhancements include dynamic loading of Orchard/C modules (currently all Orchard/C code must be preprocessed at the same time), implementation of Python and Tcl interfaces, and design patterns for writing Perl/Py/Tcl cross-compatible Orchard/C modules. -- Ken --- end of forwarded message ---
Re: Guidelines for internals proposals and documentation
Using the IBM article that Jarkko found as an example, core implementations of different languages may have more in common with each other than implemetations of the same language, I think PPC is actually significant enough so that it should not be painted into a perl-only corner. Seeing that the majority of the debate or confusion in PCC is at the germination level, I am proposing a more nebulous level... BS ( for brain storming ) which would precede development. It would be open enough to allow any developer (perl or no) to contirubute while hopefully spinning off the perl component into their own lang's direction. An example for this would be what I learned at the NYPC/LinuxSociety demo last night. In the 2.4 compile, you now use "make xconfigure" rather than "make configure". Its a TK app that makes the process more fun than work and it should be ported to every configure esp perl. On our side, there is notion in of eliminating "make" (a good idea IMHO) by updating the cons modules. It would then be a piece of cake for anyone on these lists to bring these two together, where the PPC would guide the feature set... (I'm just wondering how to do this in HTML/CPANTS ;) Anyone who wants can start a BS list w/ GNU/Mailman on http://puny.vm.com just email me an I will make a link;) John
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 04:20:58PM -0500, Dan Sugalski wrote: I want perl 6's internal API to have the same sort of artistic integrity that the language has. That's not, unfortunately, possible with everyone having equal say. I'd like it to be otherwise, but that's just not possible with people involved. There are many people who have good taste and experience where the Perl API is concerned. Forcing those people to come to a majority vote on every PDD isn't going to fly. The answer isn't to reduce that set of people to one person; Larry doesn't scale exponentially. The point is definitely *not* to do any sort of consolidation of power. Anyone reasonably sane, capable, and interested is welcome to chair any of the internals design lists and/or be responsible for shepherding a PDD to solidity. That's fine with me. (In fact I'd be thrilled if the design was handled by a host of folks that weren't me) There are only a small number of people who can bless/unbless a PDD into a standard or forcibly withdraw it from consideration. It's good that there's a small number (1) is involved, but it's bad that each of those people can singlehandedly bless/unbless something. From p5p, we saw that if 2 or 3 people objected to a proposal/idea/patch, it was probably flawed in some way. OTOH, if 3 or 4 of those same people saw merit in a proposal/idea/patch, then it was probably worthy of consideration[*]. This is one of the ways where p5p worked well (and where the RFC process failed). We should formalize this for the Perl6 API process. The first order of business should be to determine the process by which PDDs become accepted/rejected/mentored/etc. Next, we find the people with good taste and spare tuits to accept/reject/mentor proposals through the process. Z. *: This is the audience-participation variant of "throw it at the pumpking and see if he accepts it."
Re: Guidelines for internals proposals and documentation
Nat and I argued parts of this (I think this is included) at some length. Actually, I think I drove him crazy getting specifics out of this. Adam Turoff [EMAIL PROTECTED] wrote: On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote: 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or Larry, or our replacements) can mark a PDD as developing, standard, or superceded. This doesn't sound right. I'm still waiting to find out whether a group will be submitting a) a single PDD, b) multiple PDD's, or c) multiple PDD's merged into a single PDD. case pdd a) this makes sense as stated, I think b) this makes no sense submitters would control their own PDD's except only leader could stamp accepted c) submitters would control their own PDD's except only leader could stamp PDD accepted and only leader could stamp master PDD anything esac Okay, my bash is a bit off, but you get the idea. If anyone is interested, I think that within groups, b or c sounds like a logical approach to solving the problems at hand, since each person would likely have a very very very specific problem area in mind. Method a sounds a bit like a ... hmmm ... cluster-Muck, with everybody trying to come up with bits and pieces of the same document rather than coming up with ideas that end up in a single (or multiple) PDD to be submitted even higher outside the working group. I'm thinking project management terms here. All PDDs (like RFCs) need to start with 'Status: Developing' by default. Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), there should be some review in place (by a WGC, principal, etc.). Statuses like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. FWIU, "Developing" would be after an initial proposal, and means it wasn't tossed out at the first mention of it. It makes sense that it's a status of its own. The RFC process accidentally required single-authorship for all RFCs. We should allow RFCs to be maintained by a group of collaborating authors (without forcing them to start a mailing list first). Any of these authors should be able to make updates and update the status as appropriate (e.g. Developing, Withdrawn, Superceded). I think this is similar to what I'm suggesting with my a-b-c's above. I do agree that single-authorship would be a management problem. But then, multiple management could cause tangenting, but (according to EFNet #perl) there's nothing wrong with discussing winnie the pooh from time to time when burnout sets in. ;-)) Maybe sub PDD's (SPDDs) can be conceived of as "discussion", but I think that perhaps in groups with big jobs, actual proposals about how minutiae might be accompilshed could help set ideas in stone more than just discussion, then discussion could have its proper place. If SPDD's are used, it would be the responsibility of a team leader to collect the ideas and come up with a main one that everyone needed to agree on, which should be a simple diplomatic process and less overall work for the team leader himself, and more thoughtful (full of thoughtoutedness) effort from the team members. This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a core team that will be responsible for the API design, whereby a vote of 3/10 is needed to reject a PDD and a vote of 5/10 is needed to accept a PDD? (The numbers 3, 5 and 10 are arbitrary, and used to demonstrate that this doesn't need to degenerate into review by committee.) This is where Nat and I, I think, had a hurdle, and is the reason for my reponse to this email. The concern that was expressed was the development of the interests of a small group overriding the interests of the whole, the creation of another perl-elite caste, etc. Nate, correct me if I have it wrong PLEASE... It is, within a single group, the responsibility of the team leader to moderate discussion and lead the team to a unanymous decision. Within the team, the leader could be removed by majority appeal, but otherwise has authority in that area, and could not override the group. With the groups as a collective, general election of a core team was shot down (I proposed that), and I'm agreeing to the reasons for it... it's potentially caste-building (that wasn't the reason, but I have my own reason too). Since one team would not be familiar with issues within another group, it would be a tremendous thing to ask of a "core team" to decide on all PDD's including both their own and ones they aren't directly working with. All in all, I think Dan's doing a good job making this make sense. I'm just curious about the inner workings of a group.
Re: Guidelines for internals proposals and documentation
On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote: On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote: 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or Larry, or our replacements) can mark a PDD as developing, standard, or superceded. This doesn't sound right. All PDDs (like RFCs) need to start with 'Status: Developing' by default. Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), there should be some review in place (by a WGC, principal, etc.). Statuses like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. They don't need to start with "Developing" if they start with status "Experimental" or "Proposed" This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a If PDDs start as "Proposed" without needing any approval does this remove the problem of a small group having a stranglehold? Nicholas Clark
