On Fri, 17 Oct 2003, Melvin Smith wrote:
> At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote:
> >On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> >
> > > Why not this way:
> > >
> > > Have a small number of _real_ core.ops which have fixed assigned
> > > numbers below say 256. This ops never change during the lifetime of
> > > parrot. All other libs are inited (not necessary loaded) at byte-code
> > > loadtime. The bytecode has a list of needed oplibs with the acompaning
> > > base offset. The ops of that oplib are added to core starting at base
> > > offset.
> >
> >Yep, that's the plan. (And has been for years, though it has been quite a
> >while since the discussion came up last)
>
> I know we've had these discussions before but refresh my memory:
>
> I am confused between:
>
> a) Dynamic oplibs that are "on-demand" but always included in Parrot
> b) Dynamic oplibs that are add-ons and not included in Parrot
The only difference is that opcodes in the a) set are in libraries on-disk
that we build when we build parrot, and the ops in the b) set are in
libraries on disk that we installed potentially after the fact.
Which op libs are in which set depends on the distribution you're running.
It's definitely possible that we'll ship an all-in-one distrib with a big
set of optional ops, just as it's possible we'll ship a small one and
you'll need to install one or more langauge-specific sets of ops after the
fact.
Dan
