Another XS type of thing: Orchard/C

[Nathan Torkington]

--- 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.)

  

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

[Adam Turoff]

On Wed, Nov 15, 2000 at 04:42:58PM +, Nicholas Clark wrote:
> On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote:
> > 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"

The real issue is that there needs to be at least one default status that
the author can assign.  With RFCs, Developing referred to the RFC, and
with PDDs, they refer to the underlying design/interface/implementation.
I think I misread Dan's re-interpretation of 'Developing'.

> > 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?

No, because Dan has proposed a 'core team' of sorts, where any one
of the (at least) three team members cast a final vote (towards
'standard' or 'rejected').

Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's),
but "Our Perl API".  I'd be more comfortable if at least two people
(from a group of >4) were involved in making any decision that
carries weight, or if there were a process of rotating the WGC as
necessary to avoid Pumpking Burnout (tm).

Z.

Re: Guidelines for internals proposals and documentation

[John van V]

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

[Dan Sugalski]

At 12:38 PM 11/15/00 -0500, Adam Turoff wrote:
>On Wed, Nov 15, 2000 at 04:42:58PM +, Nicholas Clark wrote:
> > On Wed, Nov 15, 2000 at 11:35:56AM -0500, Adam Turoff wrote:
> > > 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"
>
>The real issue is that there needs to be at least one default status that
>the author can assign.  With RFCs, Developing referred to the RFC, and
>with PDDs, they refer to the underlying design/interface/implementation.
>I think I misread Dan's re-interpretation of 'Developing'.

Probably. I don't think I was clear enough the first time around.

> > > 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?
>
>No, because Dan has proposed a 'core team' of sorts, where any one
>of the (at least) three team members cast a final vote (towards
>'standard' or 'rejected').

Yup.

>Keep in mind that this isn't "Dan's Perl API" (or Nat's, or Larry's),
>but "Our Perl API".  I'd be more comfortable if at least two people
>(from a group of >4) were involved in making any decision that
>carries weight, or if there were a process of rotating the WGC as
>necessary to avoid Pumpking Burnout (tm).

This only holds while the primary design takes place--what happens when 
perl 6 hits maintenance/extended development is still up in the air. (read: 
That's *not* my problem... :)

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.

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)

My job is to play the Larry role for the backstage stuff. Luckily for me 
the task is reasonably partitionable, so I don't have nearly the burden of 
consolidating things that Larry does at the language level, and what I'm 
trying (perhaps clumsily) to do is farm out pieces to people while making 
sure we don't start with the sort of mess we have now with perl 5.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Guidelines for internals proposals and documentation

[Adam Turoff]

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

[David Grove]

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

[Nicholas Clark]

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

Re: Guidelines for internals proposals and documentation

[Adam Turoff]

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.

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).

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.)

Z.