On Fri, 25 Aug 2006 04:12:00 +0200 Roland Mainz wrote:
> I'm just waiting for an answer to the "multiline" issue and then commit
> the matching change - but beyond that I am more or less done.for today
> with any commits...
can you resend the "multiline" issue
thanks
> Yes... and IMO it would be useless to document that because then
> everyone could step-up and demand the documentation of every single
> "easter egg" in ksh93, too. Currently the only purpose of these bits
I'm not sure if I want to even know what other sorts of "easter eggs"
might be present in
> Date: Fri, 25 Aug 2006 04:40:37 +0200
> From: Roland Mainz
> To: Mike Kupfer , "Roger A. Faulkner"
> CC: April.Chin at eng.sun.com, ksh93-integration-discuss at opensolaris.org
> Subject: Re: flag day: 6357230 specfiles should be nuked
>
> Question to Roger:
> Which of those solutions would
> My understanding is that we do not need to include these built-ins in the
> ARC case, since they are not enabled by default.
> However, if we do include them in the case, we need to document them,
> and we did not intend to make this into a documented feature of ksh93.
By enabled by default, you
> "Roland" == Roland Mainz writes:
Roger> If so, you only need one new mapfile, common/mapfile-vers
Roland> Erm... is there any other "common" directory for these files
Roland> except "common/" ? Currently the AST [...] sources live here.
Roland> The idea is that you can simply % rm -Rf lib/
> "Dan" == Dan Price writes:
Dan> To ask a related informational question: will ksh93 be ARC'd as
Dan> External, or Committed? (or something else?)
Good question. The current draft materials say External, which I agree
seems more suited to SFW than ON. But I also think that External
doesn
> "Dan" == Dan Price writes:
Dan> I agree that if we're going to go replace wc, etc. with things from
Dan> ksh, then there may well be a compelling argument to bringing this
Dan> stuff into ON, since the level of mixing will be high.
Dan> But then... wouldn't we be tying the implementation o
My understanding is that we do not need to include these built-ins in the
ARC case, since they are not enabled by default.
However, if we do include them in the case, we need to document them,
and we did not intend to make this into a documented feature of ksh93.
April
> Date: Mon, 21 A
Roland Mainz wrote:
> This option was considered, too - however we would end-up with a new
> library for less than a handfull of functions which I consider a waste
> of both engineering and adminstrative time. AFAIK the right place would
> be libcmdutils.so but I have no clue what will happen if
Dan Price wrote:
> Well, it might then make sense to create a library of libdefutils, ARC
> it appropriately (sun private), and move the rest somewhere else.
>
Check "libdeflt" in star, cdrtools, ...
It is there and under CDDL ;-)
If star is going into /usr/sfw, this library will be present an
Roland Mainz wrote:
>>> The integration into OS/Net is a requirement for the
>>> "migration".
>> Again, why? I don't see why the ksh93 must be in OS/Net to someday deliver
>> the
>> file /usr/bin/ksh.
>
> Why isn't /sbin/sh then in /usr/sfw/bin/ ? Or /usr/bin/csh ? What about
> /usr
Dan Price writes:
> But then... wouldn't we be tying the implementation of wc, etc.
> to the *private interfaces* of something which originates externally?
Yes.
> Is that architecturally sound? Would PSARC accept this (I ask because
> I honestly don't know the answer).
As long as the project te
Dan Price wrote:
> On Thu 24 Aug 2006 at 04:07AM, Roland Mainz wrote:
> > >
> > > ``HORRIBLE'' appears to be a rhetorical overstatement
> >
> > It was not thought as "rhetorical overstatement" - it is what I think
> > how it will end. I've logged a few hundred hours getting various
> > scenarious t
Dan Price wrote:
> On Wed 23 Aug 2006 at 07:59PM, Alan Coopersmith wrote:
> >
> > >What about Solaris 10 ? Would it be possible to make a "flag day" for
> > >that OS release which covers all affected consolidations (e.g. consumers
> > >of libcmd.so) ?
> >
> > Yes - it's trickier, but doable.
>
> O
Alan Coopersmith wrote:
[snip]
> > What about Solaris 10 ? Would it be possible to make a "flag day" for
> > that OS release which covers all affected consolidations (e.g. consumers
> > of libcmd.so) ?
>
> Yes - it's trickier, but doable.
At which costs ? This would involve significant manpower a
Alan Coopersmith wrote:
> Roland Mainz wrote:
> > The current solution for libcmd based on Sun's prefernce for
> > backwards-compatibilty and MANY MANY other issues were addressed this
> > way, too. Just renaming the Solaris version of libcmd.so and annouce a
> > "flag day" isn't even 5% of the wor
Dan Price wrote:
> On Wed 23 Aug 2006 at 05:30PM, Alan Coopersmith wrote:
> > Roland Mainz wrote:
> > >Therefore we choose the solution of "merging" both libraries - we take
> > >the ksh93 version of libcmd and the Solaris libcmd and make one library
> > >from it, avoiding major problems with other
James Carlson wrote:
> Alan Coopersmith writes:
> > You can preserve binary compatibility without doing a full merge.
> > Move the old one to libsuncmd.so.1 and then add filter entries to
> > the mapfile for the ksh libcmd.so.1 to redirect users there.
> > If nothing else it's easier for others to
Dan Price wrote:
> On Thu 24 Aug 2006 at 12:35AM, Roland Mainz wrote:
> > > I have a couple of questions regarding the shape of the
> > > project:
> > >
> > > - What is the nature of the replacing of libcmd.so? If I'm
> > > not mistaken, I noticed that the existing libcmd.so is
>
Alan Coopersmith wrote:
> Roland Mainz wrote:
> > Therefore we choose the solution of "merging" both libraries - we take
> > the ksh93 version of libcmd and the Solaris libcmd and make one library
> > from it, avoiding major problems with other consolidations and even
> > honor binary backwards-com
On Thu 24 Aug 2006 at 12:54AM, Dan Price wrote:
> To take a step back, you've articulated that some of the things I've
> asked about stand in the way of making ksh = ksh93 is script
> compatibility for customers and ISV products (which I don't want to open
> as a question here. I'll leave that to
On Thu, 24 Aug 2006 06:46:32 +0200 Roland Mainz wrote:
> > If that is true, then it's a shame-- as a reference, how do other software
> > distributions (debian, fedora, etc.) handle building a sane ksh93?
> A common practice seems to be that they patch the source and the build
> system to fit the
Dan Price wrote:
> On Wed 23 Aug 2006 at 02:27PM, Felix Schulte wrote:
> > On 8/23/06, Dan Price wrote:
> > >
> > >I've been following this project, although I just joined the
> > >mailing list.
> > >
> > >I have a couple of questions regarding the shape of the
> > >project:
> > >
> > >- W
On Thu 24 Aug 2006 at 06:46AM, Roland Mainz wrote:
> >
> > I think Alan, Jim and I have clearly articulated at least two clean
> > ways to do this with expediency and minimal suffering.
>
> But both proposals do not gurantee the full binary compatibility... ;-/
Binary compatibilty for whom? We'
Glenn Fowler wrote:
> On Mon, 21 Aug 2006 18:58:49 +0200 Roland Mainz wrote:
> > A few days ago Mike Kupfer found a crash while trying to build the
> > ksh93-integration prototype on an AMD64 machine. The "make install"
> > target in usr/src/cmd/ksh/ runs the ksh93/AST test suite which crashed
> >
Felix Schulte wrote:
> On 8/23/06, Dan Price wrote:
> > I've been following this project, although I just joined the
> > mailing list.
> >
> > I have a couple of questions regarding the shape of the
> > project:
> >
> > - What is the nature of the replacing of libcmd.so? If I'm
> >
Dan Price wrote:
>
> I've been following this project, although I just joined the
> mailing list.
>
> I have a couple of questions regarding the shape of the
> project:
>
> - What is the nature of the replacing of libcmd.so? If I'm
> not mistaken, I noticed that the existing l
Chris Quenelle wrote:
>
> Just some thoughts on the subject here:
>
> For the sake of discussion, I'll assume we are dealing with a compiler bug,
> but we won't really know for sure until we see the code-generation
> bug in front of us. Until then it might possibly be a bug in the code
> resulti
28 matches
Mail list logo
