9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Mathieu" <lejatorn@gmail.com>
To: 9fans@9fans.net
Subject: Re: [9fans] Ogg/Vorbis ported
Date: Thu, 29 Jan 2009 23:47:11 +0100	[thread overview]
Message-ID: <0af685ebe4f62a20a70ae58d427cdaa2@smgl.fr.eu.org> (raw)
In-Reply-To: <13426df10901290827k581268e6i43b213df72b666a4@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

Well, a few trivial tasks could probably be automated. What comes
first to my mind is the removal of the common includes for the non plan
9 headers/libs, namely string.h, stdlib.h, math.h, and stdio.h. I know
this last one is in plan 9 but most of the time the plan 9 one was not
the one needed as the function used were in plan 9's libc, not in stdio.
I did not have to add libc.h and u.h that often, so it wouldn't have
been worth being automated imho.

Then I guess replacing the alloca() calls with malloc() could be done
automatically but one still has to do some carefull searching to place
the free()s, so I'm not sure one would gain much time with this.

As with exit(), it can be replaced automatically with exits() but you
still have to figure out what message you want in your exits().

Honestly, it took me more time to figure out what was wrong and how to
fix it, than to actually do it. Once you have some sort of workflow set
up in your mind, a few Edit lines in a guide file make the repetitive
tasks go much faster. For example, since my sam-foo is weak, it took
me a while to devise that: 'Edit line1,line2x/.*\n/ g/return/p', which
would give me how many return there are in the function I am looking at,
hence helping me not to miss any of the free() to place (without having
to go through all the code).

Cheers,
Mathieu

[-- Attachment #2: Type: message/rfc822, Size: 4246 bytes --]

From: ron minnich <rminnich@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Ogg/Vorbis ported
Date: Thu, 29 Jan 2009 08:27:42 -0800
Message-ID: <13426df10901290827k581268e6i43b213df72b666a4@mail.gmail.com>

>From what you learned, are there some nice general scripts that could
be used to automate some of this for the next hunk of gnu-like code
that comes along?

Thanks for the port ...

ron

  parent reply	other threads:[~2009-01-29 22:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-28 17:53 Mathieu Lonjaret
2009-01-28 18:22 ` hiro
2009-01-29 16:27 ` ron minnich
2009-01-29 20:27   ` [9fans] porting GNU code Steve Simon
2009-01-29 20:30     ` erik quanstrom
2009-01-29 20:35       ` Steve Simon
2009-01-29 22:47   ` Mathieu [this message]
2009-01-30  4:38     ` [9fans] Ogg/Vorbis ported lucio
2009-01-30 16:21       ` erik quanstrom
2009-02-23 10:05 ` lejatorn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0af685ebe4f62a20a70ae58d427cdaa2@smgl.fr.eu.org \
    --to=lejatorn@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).