[lkml]   [2008]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjecttext processing (Re: Google's Summer of Code?)
    Andi Kleen @ Tue, 04 Mar 2008 21:38:46 +0100:
    > Andrew Morton
    >> There are surely many more things we could put there.
    >> I receive a dribble of emails about the setrlimit64/getrlimit64 one, so
    >> people are looking at it, and are looking to do work. (I haven't usefully
    >> responded to those emails, btw - am not sure how my name got on that one -
    >> probably Ulrich would be better).
    > is also a candidate. There are still quite a lot of unconverted
    > drivers over.

    And you've saw first patch there...

    I'd say, that i see similar things here (LKML, kernel), wrt shell usage
    and text processing.

    * checkpatch instead of hard-armed editors (*The* tools of programmers),
    with one's (linux, glibc, bash, whatever) source-friendly capabilities
    (error/coding-style highlight, easy call-graph, param checking, security
    audit(+audit scripts), etc.)

    * linux-2.6/scripts/unifdef.c instead of coding style + simple script
    (reinventing of compilers is a dream of CS professors of all times :)

    * much of te `make` based stuff

    * text processing, which is source code processing, if we are in
    Open Source, has no place in
    + design (super-macro constructs --> C code),
    + auditing (stupid vmsplice() case *and* first ``fix'')
    + testing (writing source in parallel with constructing userspace
    test programs, based on same source; once all is done, script
    generates/constructs kernel part)

    * and perl is everywhere

    On my `sed` scripts i was getting (from Sam):

    "Because your shell script is unreadable by normal human beings[*]
    while the perl script for people with a bit of perl fu can read it
    and fix/modify it.

    We want tools that can be maintained and enhanced by most people.

    [*] Normal human beings are people with same level of shell
    scripting/sed skills that I have just to put that straight."

    "Linecount is down but so is maintainability / extendability."

    So, no tools or perl is better than nothing?

    I don't say, i will solve Andi's quest, i just lost interest. But it is
    damn interesting one! One, that many script kiddies will do in minutes,
    if they would knew `sed` and a bit of UNIX practice, but not perl, C,
    diff, git, etc.

    So, teach youngsters about "maintainability / extendability" and "Normal
    human beings", or what? OTOH, Who are teachers?

    Just two points to show skill mismatch, i.e. for

    + managing/manipulating source,
    + designing, writing, maintaining correct kernel code.

    Latter isn't for n00bs, right?

    * multi-line grep
    Andi Kleen

    * full and correct greping of linux style function definitions
    Linus Torvalds

    All in one shot:

    # print linux-style function definitions

    sed -n '
    s=)$=&= ; t_end ; b_start;
    p}' kernel/*c | pager


    One may not know `sed` at all (but i glad to explain and share
    everything, i know), *patterns* and expressions are key things.

    Once you have approved and try-and-buy tested one, everything else is
    pure technical thing. Maybe somebody outstanding (like Rusty) can do that
    with CPP, i don't know; `sed` is just more familiar thing for this.

    Silence in reply i will understand quite right, i might be wrong. I just
    can't see all that stuff not having much skilled people
    #oo'L O
    <___=E M

     \ /
      Last update: 2008-03-05 02:45    [W:0.024 / U:5.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site