On Thu, 15 Feb 2007, Will Fiveash wrote:
> On Thu, Feb 15, 2007 at 04:11:01PM -0800, Mike Kupfer wrote:
> > >>>>> "sch" == Stephen Hahn <[EMAIL PROTECTED]> writes:
> >
> > sch> I agree with basing the operation on the "putback -n" result,
> > sch> unless Mike was after some specific state from wx?
> >
> > I would rather not re-invent, or even borrow, the code from wx to parse
> > "putback -n" output. I'm fine with doing a "wx update" at the start of
> > the script in order to get the most recent information.
> >
> > While it's true that wx is not required for general ON development, I
> > believe it is widely enough used, and sufficiently robust, that it's
> > reasonable to require its use for this conversion script. If necessary,
> > the script can offer to run "wx init" for the user if there's no wx
> > state.
> >
> > Of course, this is all assuming I write the script. If someone else
> > wants to write it, I certainly have no objections to their parsing
> > the output from "putback -n" in the conversion script.
>
> While I'm not volunteering at this point to write it either I will say
> that wx is not very efficient (a result of hackery and paranoia). It
> would be smart to look at the wx_update() function to see if a more
> efficient way of determining workspace change can be created from wx.
> For example there is a call to deal_ws_renames() which doesn't really
> need to be done if the putback -n is going to happen.
>
> BTW, if I had know the insane about of mods I would end up making to wx
> I would have recoded the whole thing in perl. Something to think about.
There is a cutoff point IMHO, in terms of number of lines of source code,
where developing in other than sh/ksh makes sense. For me, that cutoff is
low and around 120 lines (of ksh).
These days I write Python and find the resulting code far more readable
than Perl. The time to develop in Python or Perl is about the same - but
I've found even my own Perl code difficult to grok (in as little as) 2 or
3 months down the road. My personal experience is that, the more
experienced a Perl developer is, the more difficult the resulting code is
to grok and really good Perl developers produce code that is almost
indecipherable.
I'm not trying to start a Perl/Python war and too busy to participate in
one .... but, please consider alternatives other than Perl.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
OpenSolaris Governing Board (OGB) Member - Feb 2006
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
