Re: [9fans] programs from UNI*x

[Jens Staal]

Yeah if libwtf could get feature complete for wchar stuff (not a port, made
from scratch, remapping wchar stuff to libutf) that might also help with a
bunch of ports.

No idea if that would be acceptable in upstream APE even.

Den lör 1 juli 2023 13:15Conor Williams  skrev:

> great stuff Jens... keep the requests coming in boyos, i have until at
> least September
> before the new term starts... this will be good for the CV, not least a
> bit of
> banter in an interview situation at the very least...
> you know:
> interviewer: well, mr. X, what did you do for the summer and why
> should we give
>you the mega bucks...
> interviewee: well mr. Q, i sunned my self in the garden...
> interview: great, you look tanned, you interested in out catwalk
> program...
> interviewee: hmmm, no... i have another a interviews lined up, c
> ya wouldn't want
> to be ya...
> interviewer: great, i will get out leggy blond excommunicadoator to
> throw you out... laters...
>
> like that lados...
> /c: ps: keep em comin'... only 1c per hour...
>
> On Sat, Jul 1, 2023 at 5:51 AM Jens Staal  wrote:
>
>> Hmmm perhaps was regex also a dependency (a long time ago I worked on
>> this). I remember using pcre to get regex.h for other stuff
>>
>> https://github.com/users/staalmannen/projects/1
>>
>> https://github.com/staalmannen/pcre
>>
>> also some attempts at shim headers that may be needed
>> https://github.com/staalmannen/ape-headers-extra
>>
>>
>> BTW I had apparently done some attempts at gawk. I don't know if those
>> will help you:
>> https://github.com/staalmannen/gawk
>>
>>
>> On Fri, Jun 30, 2023 at 11:26:09AM +0100, Conor Williams wrote:
>> > https://conorwilliams.in/nh4.png
>> >
>> > now looking in win?? /c early friday yay lie in 2morow
>> >
>> > On Fri, Jun 30, 2023 at 6:48 AM Jens Staal  wrote:
>> >
>> > Are you using my mkfiles under the plan9 directory? Should not
>> define
>> > Linux.
>> >
>> > Where I got stuck were some bitfields. It is a 2 step build. Check
>> the
>> > stuff I already did
>> >
>> > Den fre 30 juni 2023 00:26Conor Williams 
>> skrev:
>> >
>> > hey Jens...
>> >
>> > any quick advice like the udders on NH: lua?
>> > kr:/c
>> >
>> > -
>> > O O beep
>> >/
>> > /
>> > -
>> >
>> > On Thu, Jun 29, 2023 at 7:10 PM Luis  wrote:
>> >
>> > On Thu, 2023-06-29 at 06:25 -0600, arn...@skeeve.com wrote:
>> > > Conor Williams  wrote:
>> > >
>> > > > well Arnold?, 1. is the LINE pre processor directive
>> supported
>> > by
>> > > > p9
>> > > > and also i2s _*that*_ function declared properly (&+3
>> is that
>> > > > definitely
>> > > > the source that compiled
>> > > > properly on SM. Windows et. Al?)
>> > >
>> > > I completely don't understand this.
>> > >
>> > > No need to continue on gawk.
>> > >
>> > > Arnold
>> >
>> > I second this. No Idea what this Guy Conor is talking about.
>> >
>> > So, Conor, do your ports as you may but you are on your own.
>> >
>> >
>> > --
>> > 9fans: 9fans
>> > Permalink: https://9fans.topicbox.com/groups/9fans/
>> > T3e60a159b1280462-Ma67bad465f924b58f16b4016
>> > Delivery options: https://9fans.topicbox.com/groups/9fans/
>> > subscription
>> >
>> > 9fans / 9fans / see discussions + participants + delivery options
>> Permalink
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M42fa77e180ac842b0f73b7cb>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M7dd648e0d48c52f6aee9850a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] programs from UNI*x

[Jens Staal]

Hmmm perhaps was regex also a dependency (a long time ago I worked on
this). I remember using pcre to get regex.h for other stuff

https://github.com/users/staalmannen/projects/1

https://github.com/staalmannen/pcre

also some attempts at shim headers that may be needed
https://github.com/staalmannen/ape-headers-extra


BTW I had apparently done some attempts at gawk. I don't know if those
will help you:
https://github.com/staalmannen/gawk


On Fri, Jun 30, 2023 at 11:26:09AM +0100, Conor Williams wrote:
> https://conorwilliams.in/nh4.png
> 
> now looking in win?? /c early friday yay lie in 2morow
> 
> On Fri, Jun 30, 2023 at 6:48 AM Jens Staal  wrote:
> 
> Are you using my mkfiles under the plan9 directory? Should not define
> Linux.
> 
> Where I got stuck were some bitfields. It is a 2 step build. Check the
> stuff I already did
> 
> Den fre 30 juni 2023 00:26Conor Williams  skrev:
> 
> hey Jens...
> 
> any quick advice like the udders on NH: lua?
> kr:/c
> 
> -
> O O beep
>/ 
> /
> -
> 
> On Thu, Jun 29, 2023 at 7:10 PM Luis  wrote:
> 
> On Thu, 2023-06-29 at 06:25 -0600, arn...@skeeve.com wrote:
> > Conor Williams  wrote:
> >
> > > well Arnold?, 1. is the LINE pre processor directive supported
> by
> > > p9
> > > and also i2s _*that*_ function declared properly (&+3 is that
> > > definitely
> > > the source that compiled
> > > properly on SM. Windows et. Al?)
> >
> > I completely don't understand this.
> >
> > No need to continue on gawk.
> >
> > Arnold
> 
> I second this. No Idea what this Guy Conor is talking about.
> 
> So, Conor, do your ports as you may but you are on your own.
> 
> 
> --
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/
> T3e60a159b1280462-Ma67bad465f924b58f16b4016
> Delivery options: https://9fans.topicbox.com/groups/9fans/
> subscription
> 
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-Mc9773693de8e7edc3b6e7e5b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] programs from UNI*x

[Jens Staal]

Wine will not work (no dynamic libraries etc). Chromium would also be
extremely difficult (you would need c++ first + a ton of dependencies).

Netsurf has been ported and is quite good!

Den fre 30 juni 2023 14:19gnufan42 via 9fans <9fans@9fans.net> skrev:

> The top two softwares I want on Plan9 are chromium and winehq.
>
> But that would be way too hard, I guess.
>
> --- Original Message ---
> On Wednesday, June 28th, 2023 at PM 10:55, Conor Williams <
> conor.willi...@gmail.com> wrote:
>
>
> > hello there 9fans.ers
> > anyone need any UniX programs transferred (port.ed) to Plan9
> >
> > will give u a good price 1cent an hour iff i can get it going...
> >
> > textual programs mostly...
> >
> > Kind Regards
> > will51 (conor.williams@ yada yada c. reply address)
> > ps: I am currently catching up on some good dickens novels and would
> >  love some diversionary tactics my the fans of de plan9 oses
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-Mb4ee494ea89b65c5bad4086d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] programs from UNI*x

[Jens Staal]

Are you using my mkfiles under the plan9 directory? Should not define Linux.

Where I got stuck were some bitfields. It is a 2 step build. Check the
stuff I already did

Den fre 30 juni 2023 00:26Conor Williams  skrev:

> hey Jens...
>
> any quick advice like the udders on NH: lua?
> kr:/c
>
> -
> O O beep
>/
> /
> -
>
> On Thu, Jun 29, 2023 at 7:10 PM Luis  wrote:
>
>> On Thu, 2023-06-29 at 06:25 -0600, arn...@skeeve.com wrote:
>> > Conor Williams  wrote:
>> >
>> > > well Arnold?, 1. is the LINE pre processor directive supported by
>> > > p9
>> > > and also i2s _*that*_ function declared properly (&+3 is that
>> > > definitely
>> > > the source that compiled
>> > > properly on SM. Windows et. Al?)
>> >
>> > I completely don't understand this.
>> >
>> > No need to continue on gawk.
>> >
>> > Arnold
>> 
>> I second this. No Idea what this Guy Conor is talking about.
>> 
>> So, Conor, do your ports as you may but you are on your own.
>> 
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M01a8d5ca5759fb67b258d238
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] programs from UNI*x

[Jens Staal]

Yes Lua was already working. On vanilla plan9 one might have to revert one
of my commits (I removed a custom implementation of log2 that I had made
when this got introduced in 9front APE)

Den fre 30 juni 2023 03:08Conor Williams  skrev:

> lua is now compiling perfect (see attached screenshot)
> PDCurses now compiling fully... (see nh1.png previous attacment to last
> email)
> NetHack not quite there...
> /bed...
>
> On Fri, Jun 30, 2023 at 1:54 AM Conor Williams 
> wrote:
>
>> sorry two images the same the nh2.png supercedes nh1.png attached/c
>>
>> i wonder is it a 9front v plan9 issue...
>>
>> On Fri, Jun 30, 2023 at 1:39 AM Conor Williams 
>> wrote:
>>
>>> hey Jens...
>>> lua nearly there...
>>> libcurses.a: a.ok
>>> nh stalling...
>>> /c s___q
>>>
>>> On Thu, Jun 29, 2023 at 11:23 PM Conor Williams <
>>> conor.willi...@gmail.com> wrote:
>>>
 hey Jens...

 any quick advice like the udders on NH: lua?
 kr:/c

 -
 O O beep
/
 /
 -

 On Thu, Jun 29, 2023 at 7:10 PM Luis  wrote:

> On Thu, 2023-06-29 at 06:25 -0600, arn...@skeeve.com wrote:
> > Conor Williams  wrote:
> >
> > > well Arnold?, 1. is the LINE pre processor directive supported by
> > > p9
> > > and also i2s _*that*_ function declared properly (&+3 is that
> > > definitely
> > > the source that compiled
> > > properly on SM. Windows et. Al?)
> >
> > I completely don't understand this.
> >
> > No need to continue on gawk.
> >
> > Arnold
> 
> I second this. No Idea what this Guy Conor is talking about.
> 
> So, Conor, do your ports as you may but you are on your own.
> 
 *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-Mb4473385b9da6a4bd920ac27
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] programs from UNI*x

[Jens Staal]

If you want to have a go at NetHack, it would be cool.

Here was my attempt before I gave up (real life too busy atm):
https://github.com/staalmannen/NetHack

It depends on
PDCursesMod:
https://github.com/Bill-Gray/PDCursesMod

Lua:
https://github.com/staalmannen/Lua


On Wed, Jun 28, 2023 at 03:55:59PM +0100, Conor Williams wrote:
> hello there 9fans.ers
> 
> anyone need any UniX programs transferred (port.ed) to Plan9
> 
> will give u a good price 1cent an hour iff i can get it going...
> 
> textual programs mostly...
> 
> Kind Regards
> will51 (conor.williams@ yada yada c. reply address)
> ps: I am currently catching up on some good dickens novels and would
>  love some diversionary tactics my the fans of de plan9 oses
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M6779dadb65593a8928ce12a6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] porting projects...

[Jens Staal]

On Mon, Sep 20, 2021 at 01:23:05AM +, Conor Williams wrote:
> nethack:
> d in 32-bit code (0x7bc511f9).

I am confused. Why did you attach a WINE debugger screenshot on
Peppermint Linux?


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M4de15c568b96084f0f35fd00
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] porting projects...

[Jens Staal]

Den lör 4 sep. 2021 01:50Conor Williams  skrev:

> anyone got a list/one project to work on...
> i'm not too shoddy at the auld porting etc...cw
>

I really wanted to get NetHack work (using the upstreamed PDCursesMod port).

Been too busy and side-tracked by other stuff to try again.

*9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-Ma5b96b6a9c9a6131689df4cf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] patches from 9front

[Jens Staal]

On Thu, Feb 11, 2021 at 09:24:38AM +0200, Lucio De Re wrote:
> On 2/11/21, o...@eigenstate.org  wrote:
> > Quoth David du Colombier <0in...@gmail.com>:
> >> 9legacy patches are available as "unified diff" format and
> >> are generated with "ape/diff -Nru".
> >
> > Alright, noted for the future.
> >
> 
> Here's what I' ve been thinking about that may be worth sharing: I'd
> like to have working 9legacy, 9pi (which I'd like to call 9muller,
> frankly, if only for clarity, but also because it is what I run on my
> i386 workstation, not yet the network server), 9atom and last, just to
> emphasise it is NOT least, 9front. Each of those have useful
> differences and even though I never really make any progress, I like
> to think that there is "One plan 9" struggling to be born from these
> variations.
>

That would be great. One could even think of a model where there is a
common repository for the "common base" (sort of like illumos) and that
the current OSes remain with their own identities as "distros" or
"spins" from that common base.

It is not bad per se that people have differing visions and/or community
cultures, and that these can be cultivated in different ways. With a
common base/upstream, improvements to one could easily also be
implemented by the others.

Personally I would love to see a "spin" that takes Sigrid's 9front rio
modifications for workspaces and theming and make them default. For me
that has become a huge improvement in the UI of Plan9. Hopefully that
work will continue and improve further.

> Would the Plan 9 Foundation be interested in proposing to this
> community that such a concept be pursued and properly maintained and
> laying down a project path to achieve this objective? Could there be
> much smaller portions of such an objective that could be progressively
> achieved in a distributed, centrally managed manner?
> 

Hosting the common base at the foundation would be logical, I think.

> Lucio

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc82939f1fda0e479-M172301466cce16502dcd2993
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] PDCursesMod 4.2 released with upstream plan9 support

[Jens Staal]

https://github.com/Bill-Gray/PDCursesMod/releases/tag/v4.2.0

PDCursesMod is a fork of PDCurses and we managed to bring fgb's old (3.0)
PDCurses port to the current PDCursesMod.

Why would you need curses?
Lots of fun little curses-based things out there and PDCursesMod can build many
things that are typically claimed to depend on ncurses (not stuff depending on
termcap though).

Some examples:

nbsdgames:
https://github.com/abakh/nbsdgames

tetris: (replace "ncurses.h" with "curses.h")
https://github.com/brenns10/tetris

I aim to port BSDgames and NetHack, but currently real life is taking all my
time.

https://github.com/staalmannen/BSDGames
https://github.com/staalmannen/NetHack



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te27021add8ec4894-M7383f84cd38543861616cb1f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Re: [9front] git/serve, git/compat

[Jens Staal]

Awesome! I just tried to package lufia's libressl but got stuck on that a
script needed "real" git. Will try this!

Den sön 6 sep. 2020 23:47  skrev:

> Hey,
>
> I try not to be too verbose about new features landing in git9, but
> I think these warrant some  noise. Both git/compat and git/serve
> have landed in the last few days.
>
> Git/compat is a script that drops you into a new rc shell with
> a 'git' script in $path. This git script provides enough of the
> upstream git interface that 'go get' and friends work out of the
> box, as long as you're in a git repository. Thanks to halfwit
> for doing the work on this!
>
> % git/compat
> nested% cd $gorepo
> nested% go get ./...
>
> Git/serve is exactly what it sounds like: A git server that runs
> on plan 9. It supports both read-only and read-write access.
>
> # read-only git://$host server, works with git
> % aux/listen1 'tcp!*!9418' git/serve
>
> Once that's running, you can clone from it using any git client
> that supports the git:// protocol
>
> unix$ git clone git://host/path/to/repo.git
> p9% git/clone git://host.com/path/to/repo
>
> You can also tunnel it over TLS with plan 9 auth, if you want
> authenticated pushes:
>
> % aux/listen1 -t 'tcp!*!9418' tlsclient -a git/serve -wr`{pwd}
>
> With this, you currently need a plan 9 git client, since unix
> git doesn't know how to tunnel over tlsclient or authenticate
> with an auth server:
>
> p9% git/clone hjgit://host.com/path/to/repo
>
> But we can probably get a simple remote helper for unix git that
> will dial using a plan9port copy of tlsclient:
>
> https://rovaughn.github.io/2015-2-9.html
>
> There are still rough edges:
>
> Git/compat only works under a git repository. There are some
> commands that 'go get' invokes when run outside of a repository
> that need some work.
>
> Git/serve does not currently support bare repositories, so
> all repositories served must have a '.git' directory inside
> them:
>
> % ls /usr/ori/srv/git9
> .git/
>
> It's acceptably fast for small repositories, but there's a lot
> of low hanging fruit to pick. And of course, it's only been
> tested rather lightly.
>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T84d29caee16bc66a-Mac7c733466ba70a612ac2207
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] missing isblank (/sys/include/ape/ctype.h)

[Jens Staal]

Dear all,

is there a reason for that isblank(c) is missing from /sys/include/ape/ctype.h 
when
_ISblank is defined in the segment above?

best regards,
Jens


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8e0acad580bf0312-M1ff913348bd60800b3a83de7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] adding -i flag to ignore in /rc/bin/ape/ls

[Jens Staal]

Dear all,

A lot of configure scripts fail on "ls -di" where the easy solution often is to
just edit it to "ls -d" but is there a reason the "-i" flag is not added to the
list of flags that are ignored in /rc/bin/ape/ls ?


Best regards,
Jens


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5f20bcb34a86d41e-Mced3655241efdf0c32848573
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] python2.7.6 and pip

[Jens Staal]

I remember that there was an old openssl port too. With that, can the most
recent 2.7.18 and even 3.x be built?

On Fri, Jun 19, 2020 at 03:45:05PM +0900, kokam...@hera.eonet.ne.jp wrote:
> Ok, thanks
> I'll write to you.
> 
> Kenji
> Date: Thu, 18 Jun 2020 22:32:14 -0400
> From: j...@corpus-callosum.com
> To: 9fans <9fans@9fans.net>
> Topicbox-Policy-Reasoning: allow: sender is a member
> Topicbox-Message-UUID: 160a0076-b1d5-11ea-8b80-0dc6212d11b0
> Topicbox-Delivery-ID: 
> 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:f46adda4-eb83-11e9-92f5-7ab8f5b1d025:M597edfb83f7d30f60951427f:1:cQQ8sfFcN3j7E4cX6nVTY_T6ffs2dPToR6DZjO_yQEk
> Subject: Re: [9fans] python2.7.6 and pip
> 
> Not sure why this text/plain message is marked invalid given it is, well,  a 
> plain text message.  Here are the details:
> 
> Kenji,
> 
> TCP_NODELAY should be enabled in the 2.7.6 build.
> 
> Make sure you have all the APE patches from 9legacy or check the sources:
> 
> https://9p.io/sources/contrib/jas/cpython-src.arch.bz2
> https://9p.io/sources/contrib/jas/src/cmd/cpython-src.arch.bz2
> https://9p.io/sources/contrib/jas/src/ape-source.arch
> 
> Python 2.7.6 is the last viable release on Plan 9 until a rewrite of the 
> _p9ssl.c version of the ssl module is completed.  After 2.7.6 the Python 
> group back ported the openssl module from Python 3 to the 2.7 branch and it 
> broke the underlying ssl module hooks used in the Plan 9 Python 2.7.6 port 
> that leveraged libsec instead of openssl.
> 
> Feel free to contact me off list if you need additional help.
> 
> Jeff

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta10c6b46f1dfa71e-M00d4cd3b05b072e84df36875
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan9 vs aout

[Jens Staal]

I have now added 2 more branches for reference from the updated port of gcc and
binutils to i386-plan9 from https://marcus.biz.tm/jail/ :

binutils-2_22-plan9

gcc-4.8-plan9

Hopefully there are some clues there to help making a working current 
i386-plan9 cross
compiler.


On Tue, Jun 02, 2020 at 02:36:38PM +0200, Jens Staal wrote:
> Dear all,
> 
> First a bit of background:
> I am currently attempting to update the old i386-plan9 target for binutils/gcc
> in order to generate a modern cross compiler targeting plan9.
> 
> I have extracted the changes done to gcc 3.0 and binutils 2.11.2 from:
> https://9p.io/sources/extra/gcc/
> 
> My binutils and gcc attempts can be found at:
> 
> https://github.com/staalmannen/gcc
> branch plan9 : porting attempt to current gcc (10)
> branch gcc-3.0-plan9 : original port added to the 3.0 branch
> 
> https://github.com/staalmannen/binutils-gdb
> branch plan9: porting attempt to current binutils (2.34)
> branch binutils-2_11-plan9 : original port added to the 2.11 branch
> 
> Definitely not just a copy-and-paste endeavour unfortunately. The old port
> almost 20 years old and some style and structure changes have happened in that
> time.
> 
> I have built a binutils variant but when I try to compile a "Hello.S" with
> i386-lucent-plan9-as and execute it under i386 9front, I get an error about
> incorrect file header, so something is wrong.
> 
> What I learned from looking at the old port and trying to adapt it to compile 
> in
> a modern binutils background is that a lot of it is basically copied from the
> generic aout target (I have some uncommitted changes where I am updating the
> obj-plan9 files to modern modified obj-aout files with the original changes
> applied).
> 
> So to my question: what are the differences between the plan9 file format and
>  what binutils would see as generic aout?
> 
> PS. If someone would be interested to help out, you are more than welcome ;) 
> DS.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0d486ca41e37210d-M8f436975b50638e15cf50fdd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] plan9 vs aout

[Jens Staal]

Dear all,

First a bit of background:
I am currently attempting to update the old i386-plan9 target for binutils/gcc
in order to generate a modern cross compiler targeting plan9.

I have extracted the changes done to gcc 3.0 and binutils 2.11.2 from:
https://9p.io/sources/extra/gcc/

My binutils and gcc attempts can be found at:

https://github.com/staalmannen/gcc
branch plan9 : porting attempt to current gcc (10)
branch gcc-3.0-plan9 : original port added to the 3.0 branch

https://github.com/staalmannen/binutils-gdb
branch plan9: porting attempt to current binutils (2.34)
branch binutils-2_11-plan9 : original port added to the 2.11 branch

Definitely not just a copy-and-paste endeavour unfortunately. The old port
almost 20 years old and some style and structure changes have happened in that
time.

I have built a binutils variant but when I try to compile a "Hello.S" with
i386-lucent-plan9-as and execute it under i386 9front, I get an error about
incorrect file header, so something is wrong.

What I learned from looking at the old port and trying to adapt it to compile in
a modern binutils background is that a lot of it is basically copied from the
generic aout target (I have some uncommitted changes where I am updating the
obj-plan9 files to modern modified obj-aout files with the original changes
applied).

So to my question: what are the differences between the plan9 file format and
what binutils would see as generic aout? 


PS. If someone would be interested to help out, you are more than welcome ;) DS.





--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T0d486ca41e37210d-M9cbbb545155e2a1fd2addc16
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Software preservation in the post-hg era

[Jens Staal]

Den tors 7 maj 2020 16:17Dave MacFarlane  skrev:

>
> On Mon, Mar 30, 2020 at 9:12 PM Sean Hinchee  wrote:
>
>> As a footnote, there's a decent git client written in Go that works
>> alright on plan9 [4], but it's slow and memory intensive at the
>> moment.
>>
>>
> [...]
>
> [4] https://github.com/driusan/dgit
>
> This (and the fact that the speed of Go on Plan9/amd64 seems to be finally
> be useable enough to do development again as of 1.14..) finally gave me the
> kick I needed to fix some of the hacks that were causing performance
> problems on clone. The self-clone time went from ~160s to ~13s on my
> machine (compared to ~8s with "real" git) If there's other parts that you
> were referring to as being slow and memory intensive let me know (or if you
> still find it's memory intensive, I didn't benchmark that part..)
>
> - Dave
>


How does it compare performance wise with git9 ?

https://github.com/oridb/git9


*9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M9c55a9ba9a94eef7fa085c7f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Is the vanilla Plan 9 still alive?

[Jens Staal]

Den fre 22 nov. 2019 kl 09:55 skrev Skip Tavakkolian
:
>
> It's not dead; it's resting.
>

The whole "thing" about Plan9 was bringing back the dead so it is
thematically on point.

> On Thu, Nov 21, 2019 at 10:29 PM  wrote:
>>
>> The site hasn't been updated since 2014-2015. If it's dead, is there any 
>> chance of it coming back into development?
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb6b3aefeebeb526d-M05083e8d812fd8d1314a518a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Someone made a Wayland compositor based on Rio, Wio

[Jens Staal]

Den sön 5 maj 2019 16:15  skrev:

> > I have a fun issue where 9front resolution depends on EFI boot method.
> Via
> > firmware interface, I get 1600x900 but via bootloader (EFI file copied to
> > esp) I get low resolution.
>
> not so surprising. pure EFI without legacy CSP does not have a VESA BIOS.
> all you get is what the bootloader could figure out about the framebuffer
> that the firmware set up for us. thats is what we have to work with until
> you invoke a native driver to set up a proper mode.
>
> > I can not set resolution via aux/vga so the resolution at boot is the one
> > that sticks.
>
> what graphics card is this? when its intel, we have a native driver. it
> might just not know about your specific card yet.
>

http://sysinfo.9front.org/src/269/body

so amd/radeon


> > btw: is anyone working on additional WiFi firmware (for example atheros)
> > support?
>
> not that i know of.
>
> --
> cinap
>
>

Re: [9fans] Someone made a Wayland compositor based on Rio, Wio

[Jens Staal]

Den sön 5 maj 2019 14:34  skrev:

>
> the boot process is nothing special. we have a bootloader that loads
> the kernel. the loader uses BIOS/EFI calls to get the kernel from the
> boot media so that it does not need drivers. once the kernel
> is taking over, it needs a driver.
>


I have a fun issue where 9front resolution depends on EFI boot method. Via
firmware interface, I get 1600x900 but via bootloader (EFI file copied to
esp) I get low resolution.

I can not set resolution via aux/vga so the resolution at boot is the one
that sticks.

btw: is anyone working on additional WiFi firmware (for example atheros)
support?

Re: [9fans] Someone made a Wayland compositor based on Rio, Wio

[Jens Staal]

>
>
> On the actual thread topic, I guess Wio is cool.  If it works as well as I
> think it does, I shall have to improve my opinion of Wayland.
>

The developer of wio is the same that wrote sway (an i3-like Wayland
compositor) and wlroots, which is now used by many projects. Sway is
definitely a really nice environment to work in.


> Stray thought:  Why didn't the suckless folk ever use Xnest instead of
> mucking about with things which require application support?  Not that
> Xnest has worked 100% for years, but they could have tried to fix it.  I
> mentioned it to them but they were already hyped up about tabbed.
>

I would say that I prefer a tabbed+tiled environment and would love a Rio
variant that behaves like i3 or DWM with workspaces and tiling (dmenu does
not make sense on Plan9 due to namespaces - so execution from terminal
windows like in Rio would still be the same).

If I am making a "laundry list" of wishes I would also love such an
interface to be based on the solarized colour schemes (dark, light).


>

Re: [9fans] user interface questions

[Jens Staal]

Den lör 27 apr. 2019 08:21Lucio De Re  skrev:

> On 4/26/19, Kurt H Maier  wrote:
> >
> > It's here now:  https://bellard.org/TinyGL/
> >
> > khm
> >
> Let me add this correction to that document, this is where my
> curiosity found VReng:
>
> http://www.vreng.enst.fr/
>
> Thank you, Kurt.
>
> Lucio.
> >
>
>
>
> If I remember correctly, there is an SDL port on Plan9, and there is a
> tinygl-on-sdl so perhaps it is already possible.
>
>
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
>
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824
> FAX: +27 58 653 1435
>
>

Re: [9fans] Git client

[Jens Staal]

Den mån 22 apr. 2019 12:54Lucio De Re  skrev:

> On 4/22/19, Jens Staal  wrote:
> >
> > speaking of backporting ape stuff : has anyone looked into Harvey's
> "apex"
> > [1] for 9{atom,front,legacy}?
> >
> 9^(atom front legacy)
>
> I did not note anything that would put apex above any of those you
> mention, do you have something in mind other than providing a common
> base?
>
> Lucio.
>

I just know that it has been quite actively developed especially in the
beginning of Harvey. I have not kept up though so I can not say for sure
exactly what it could provide in addition to what is available in the 9*
distributions.

>
>

Re: [9fans] Git client

[Jens Staal]

>
> Nice.  It looks like testing it out on 9front will involve a bit of
> backporting of ape stuff, but I may take a look
>

speaking of backporting ape stuff : has anyone looked into Harvey's "apex"
[1] for 9{atom,front,legacy}?


[1] https://github.com/Harvey-OS/apex


>
>

Re: [9fans] There is no fork

[Jens Staal]

There is also one additional fork that has diverged quite significantly
from its Plan9 roots: Harvey OS.

One thing that might be interesting to back port from Harvey is the
modernized APE.

Den 10 feb. 2018 03:51 skrev "Benjamin Huntsman" <
bhunts...@mail2.cu-portland.edu>:

> Just curious as to the state of the union.  Is 9front pretty much the
> de facto "official" Plan 9 these days, or does anyone still use or maintain
> any of the following:
>
>
> 9atom
>
> NIX
>
> 9legacy
>
> The original Bell Labs distribution
>
>
> Thanks for your input!
>
>
> -Ben
>
>
>

Re: [9fans] Update APE

[Jens Staal]

https://github.com/Harvey-OS/apex



Den 21 feb. 2017 23:28 skrev <cigar562hfsp952f...@icebubble.org>:

> Jens Staal <staal1...@gmail.com> writes:
>
> > If someone could backport apex from Harvey, that would be cool.
>
> I've seen this "Harvey" thing mentioned here and there, but does it
> really exist?  I tried subscribing to the "Harvey" mailing list, but my
> subscription request was rejected.  So I just assumed it was a secret,
> dark project hidden to all but a select inner circle of digital ninjas.
>
>

Re: [9fans] Update APE

[Jens Staal]

If someone could backport apex from Harvey, that would be cool.

Den 20 feb. 2017 19:50 skrev "Charlie Lin" :

> Since the POSIX standard is updated to POSIX.1-2008 with the 2016 TC, the
> commands should be updated as well.
>
> Also, how to submit either a patch or a contribution?
>

Re: [9fans] NetSurf (browser) and Duktape (javascript)

[Jens Staal]

2016-02-18 15:26 GMT+01:00 :

> NetSurf (http://www.netsurf-browser.org/) is a browser written in C. And
> Duktape is a javascript engine written in C too.
>
> Has anybody given them a look?
>

Several NetSurf libraries (used to) build fine under APE. I probably should
try again sometime and upload to the 9front-ports project.

What would be really cool is if  the LibNSFB (netsurf framebuffer
abstraction library) would be ported to Plan9, since this would mean that
it might be possible to run a NetSurf port natively (if all the other parts
compile well)

Re: [9fans] pthreads

[Jens Staal]

On Tuesday 01 September 2015 12.26.54 Nick Owens wrote:
> https://bitbucket.org/mveety/9front-ports/src/9de20d22612a/ape-libs/pth/?at=
> default
> 
> i have no idea if it works. ymmv.

it used to work (at least the tests that comes with pth, and the oracle/
sleepycat db ...)
I was once curious to try to re-compile python using pth but never did.

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Thursday 09 July 2015 02:49:53 arn...@skeeve.com wrote:
 However, I'm happy to incorporate portability changes to make porting
 to Plan 9 easier, if they're reasonable.

For portability changes, I think not much is needed. 

There was an issue with a duplciate case in posix/gawkmisc.c ,(S_IFSOCK 
S_IFIFO, S_IFIFO is defined as S_IFSOCK in APE).
I also did a hack patch to builtin.c because it somehow forgot the 
definition of uint32_t and I could not figure out why.

Other than that, most of the work was manual generation of config.h, mkfile 
which are things that also should work with configure/make (but I have not 
tried it). I added  inttypes.h and  sys/time.h  in config.h because some 
source files assumed that those headers would be pulled in via other headers. 
That hack would probably be better to put in custom.h.

As external dependency, we need some extra gnulib functions (wchar related 
stuff). If we can get the dlopen thing to work by using this libdynld 
(apparently from inferno origin, but once ported to nix-os), that would be 
very cool.

As a porter, my prime aim is to stay as true as possible to the intent of the 
developer and the expectations of the users. Basically, I do porting as a 
simple mental task to relax (like puzzles, cross word or soduko). For most 
of you real programmers the stuff I do most likely seems menial and pointless.
My process
1. can the porting be done?
2. does it work as expected?
3. (bonus) does anyone find it useful?

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Thursday 09 July 2015 11:19:33 Steve Simon wrote:
 FWIW: fgb did a stirling script called config which sets up some
 environment and runs configure under ape. It doesn't always work but often
 gets close to generating a config.h as linux intended.

part of that script is already fixed since I managed to get  -plan9* '  
added to the list of OSes in config.sub upstream some years ago. 

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Tuesday 07 July 2015 16:45:59 Charles Forsyth wrote:
 The loaders support creating a module, with the -u and -x options, with
 import and export tables,
 which are type-checked, to be dynamically loaded. If the program you're
 working with won't compile and load
 statically with the -T option (external type checking), it's probably not
 worth pursuing. The type checking can spot bugs that other
 systems miss, as it did with Python. (A #define was present for one include
 of an #ifdef'd structure but not for another,
 so functions had different ideas about the layout.) There's an auxiliary
 library libdynld that's needed to load a module,
 that doesn't seem to be part of the distribution, but I probably have got
 the bits.

This sounds very interesting. If it is availiable, it would be interesting to 
spin in to a independent lib that could be re-used for various software that 
expect/depend on dlopen.

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Tuesday 07 July 2015 06:27:55 arn...@skeeve.com wrote:
 Hi.
 
 Jens Staal staal1...@gmail.com wrote:
  There was a recent discussion about that it would be nice to have gawk on
  Plan9.
  
  The latest upstream version of gawk can now be built via 9front-ports. I
  think/hope I built/ported it correctly, but it would be nice with
  critique/feedback/testing.
 
 Majorly cool! The first thing to check is that 'make check' passes.
 Some tests depend on locales; those are OK if they fail, assuming you
 don't have locale data for them. Others are only run if gawk was built
 with the MPFR library, so those should be OK too if they're not run. If
 there are failures in other tests, they should be investigated.


OK thanks - I will look at that and try to make a mk file for check :)
I will also look at mpfr some time
 
 I assume you built from the released tarball? Version 4.1.3?
 

Yes 4.1.3
below is the ports entry:

https://bitbucket.org/mveety/9front-ports/src/0bf6695dcad94d32c34a73ed3d71010bbdf2a66b/textproc/gawk/?at=default

I used an external gnulib which apart from the gnulib-derived object files 
usually supplied in gawk also takes care of the wchar-related dependencies.
 
I also used a custom/manual config.h and a semi-automatically generated mk-
file (mkmk and manual editing) rather than the standard configure/make.
For the actual source, there were just a few things that needed patching so 
configure/make under APE might also work.

  I noticed in the Arch linux package that gawk comes with a couple of
  dynamic libraries and a header. Are those also interesting to include in
  the Plan9 package (then as static libraries ofcourse)?
 
 Supplyinig them as static libraries would serve no purpose. Those
 dynamic libraries are extensions (or plug-ins, if you will). Gawk
 loads them vial dlopen() if requested to via an @load directive in
 the source or the via the -l command line option.
 
 I hope that dlopen works on Plan 9; if so it's necessary to build
 the libraries in whatever way will work to support dlopen.

most likely not since the whole system is static...

 
 The extension facility is something we (the gawk developers) put a
 lot of work into for the 4.1 release. I can supply pointers to doc
 for anyone who is interested. Here's a simple example:
 
   $ gawk -lreaddir '{ print }' .
   2814749767529876/./d
   281474977052502/../d
   2814749767530561/.bashrc/f
   281474976885114/.bash_history/f
   14355223812503808/.bash_profile/f
   1407374884183439/.bzr.log/f
   281474976885116/.ex-sgml-rc/f
   281474976885117/.exrc/f
   ...
 
 The readdir extension returns directory entries as records in an
 easily-parsed format: '/' is the field separator and the fields are
 the inode, the name, and an optional single-letter file type indicator.
 
 The doc has more examples.
 
 I hope this helps. Please feel to contact me off-list if you need
 more info / help.
 
 Thanks!
 
 Arnold

[9fans] Gawk in 9front-ports

[Jens Staal]

There was a recent discussion about that it would be nice to have gawk on
Plan9.

The latest upstream version of gawk can now be built via 9front-ports. I
think/hope I built/ported it correctly, but it would be nice with
critique/feedback/testing.

I noticed in the Arch linux package that gawk comes with a couple of
dynamic libraries and a header. Are those also interesting to include in
the Plan9 package (then as static libraries ofcourse)?

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

Den 30 maj 2015 08:41 skrev lu...@proxima.alt.za:

  does anyone want to help test pap's native awk?

 Build it and they'll come :-)

 URL?  Is it portable?  How carefully was it ported?

 It may be worth twisting Aaron's arm, he may well have a test suite
 for GAWK that can be used here?

 Lucio.



I was going to attempt a new gawk port sometime later.

I am also interested in seeing how compatible the ported m4 is with GNU m4
if there are good tests. A plan is to attempt bison/flex porting some time.

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

Den 30 maj 2015 10:23 skrev Charles Forsyth charles.fors...@gmail.com:


 On 30 May 2015 at 08:21, Jens Staal staal1...@gmail.com wrote:

 am also interested in seeing how compatible the ported m4 is with GNU m4
if there are good tests


 GNU m4 is insane, and completely missed the point about GPM (and thus m4).

 My m4 port is based on Ritchie's m4, although I might re-do a few things
to make it a Plan 9 program
 and account for a few changes in the C environment. You could put gnu m4
in APE I suppose, but
 since it's mainly used for autotools which won't work anyway because they
aren't portable, I'm not sure what's the point.

I was talking about quasar m4 in ports

https://bitbucket.org/mveety/9front-ports/src/devel/m4/

Which apparently is a modified BSD m4 specifically aiming for GNU
compatibility.

I am not saying that they are the ideal or good tools - just that most 3rd
party source expect certain behavior and a compatibility environment
(like APE) has as first priority to deal with 3rd party stuff. Enabling as
much as possible without judgement is at least to me desirable.

All the ports are optional so nobody needs to feel violated by my heresy
;)

[9fans] ... and ##' stuff with pcc?

[Jens Staal]

Hi all.

I tried using the following shim header to satisfy err.h in a package I
want to build.

https://raw.githubusercontent.com/libressl-portable/portable/master/include/err.h

It looked pretty neat since it does everything in the header.

It did however not work (I guess the ... and ## are to blame?) so now I
wonder how/if it is possible with the posix compiler on plan9?

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

On Friday 15 May 2015 07:53:39 cinap_len...@felloff.net wrote:
 commited the fix.

Playing with the ports has so far uncovered 3 bugs (hget, zip and the one 
below) so rather fruitful playing :)

A potential bug in APE sys/wait.h : the header does not make sure that pid_t 
has been defined.
Compiling sbase on Plan9/APE ended up in situations where there were lots of 
compilation faliures simply because sys/wait.h was included without 
sys/types.h being included before.

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

On Friday 15 May 2015 07:53:39 cinap_len...@felloff.net wrote:
 fixed, its a bug in gunzip. the extra-len field in the gzip header has two
 byte length field instead of one byte.
 
 commited the fix.

awesome!
now it works

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

On Thursday 14 May 2015 16:37:05 cinap_len...@felloff.net wrote:
 pretty sure this is apache bug/misconfiguration. googled for it
 and the issue seems to be known problem.

The zlib archive works fine now :)
by the way, did you try the mksh archive after hget was fixed? I still get the 
same error as before

gunzip: stdin: inflate failed: corrupted data
/bin/tar: EOF reading archive ...

https://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz

but now the md5sums match between the linux-downloaded and the 9front-
downloaded archive.

Also sbase archives (.zip, tar.gz and tar.bz2) suffer from the same issue.
http://git.suckless.org/sbase/snapshot/sbase-master.zip
http://git.suckless.org/sbase/snapshot/sbase-master.tar.gz
http://git.suckless.org/sbase/snapshot/sbase-master.tar.bz2

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

On Thursday 14 May 2015 12:52:48 cinap_len...@felloff.net wrote:
 i just tried this and it works all fine:
 
 hget http://bitbucket.org/9front/plan9front/get/tip.tar.gz | gunzip | tar t
 
 so please give a example command with a url that gives you issues.

Hi
sorry about the lack of details before (I was on my phone so no urls handy)

I tried 2 low hanging fruit (=no source changes) packages for the ports - 
zlib and mksh.

http://zlib.net/zlib-1.2.8.tar.gz
https://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz

I remembered wrong... both were gzipped. I had other archives that were bz2

now when I was at my computer I took the opportunity to compare md5sums 
between the archives downloaded on 9front and on Linux and they differed. 
Before I just assumed that there was an issue with tar.

 This might be a vbox bug (known for flaky network? I use the recommended 
settings from 9front wiki), so I will try in qemu instead.

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

On Thursday 14 May 2015 13:10:20 Jens Staal wrote:
  This might be a vbox bug (known for flaky network? I use the recommended 
 settings from 9front wiki), so I will try in qemu instead.

I just tried with the archives in qemu too and got the same error (and the 
same deviant md5sum) - so hget is weird?

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

Den 12 maj 2015 07:47 skrev mve...@mveety.com:

 Thanks Jens!  I can add you to the bitbucket if you wish so you can
 contribute at your leisure. Also, if anyone else wants commit access,
 just ask.  :) (I think bitbucket has some dumb limited commit bit
 thing though.  Hopefully I'll get off it soon.)

 --
 Veety



I just set up a clean 9front VM (vbox, will see if the same issue exists on
qemu/kvm) and I have an issue where tar fails on every archive downloaded
with hget.

Any ideas what the issue may be? Need to get that resolved to validate my
ports before uploading them :)

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

Both tar.gz (zlib official site) and tar.bz2 (mksh official site). I just
wonder if they get corrupted during transfer with hget or if there is a
different issue.
Den 14 maj 2015 10:49 skrev cinap_len...@felloff.net:

 could you be more specific what files fail to unpack with tar?

 --
 cinap

Re: [9fans] Ports tree for Plan 9

[Jens Staal]

Den 12 maj 2015 04:13 skrev mve...@mveety.com:

 Hey 9fans,
 I wrote a ports tree for 9front, but it should work fine on
 labs Plan 9. It's a bit light on software and probably has bugs,
 so I would really love comments on it and mkfiles for new software.
 Take a look at the code, try it out, tell me what you think!

 Ports repo: https://bitbucket.org/mveety/9front-ports , install it by
 running install.rc . It installs to /sys/ports/ .

 --
 Veety

Awesome!

Just before I had to stop playing with porting to Plan9 (family/kids taking
time), I tried to bootstrap pkgsrc. That was probably doomed to fail. This
got a better chance of success.

As soon as time allows, I will try to migrate my old ports

Re: [9fans] xz compression?

[Jens Staal]

On Wednesday 14 January 2015 08:08:23 lu...@proxima.alt.za wrote:
 Even though at the back of my mind there is a nagging desire to
 implement gccgo in a Plan 9 fashion (for OpenLDAP, if anyone cares), I
 think the bccgo approach, useful as it is, should be limited to
 obsolete software.  But that's philosophy, rather than pragmatism.

There is a new-ish GCC port (4.8.3) to Plan9 made by Alvaro
http://marcus.biz.tm/jail/comment?threadid=62title=GNU+port+for+Plan9+upgraded
http://marcus.biz.tm/jail/comment?threadid=64title=GCC+4.8.3+and+Lighttpd+in+Plan9

I mirrored one older (gcc 4.5) version at
http://plan9.bell-labs.com/sources/contrib/staal1978/gcc/

Basically it is the APE libs built with GCC. It should apparently support many 
languages (it does not mention which ones). It might be possible to use to 
rebuild GCC that supports go (if it is not included by default). The new 
version uses another directory structure, but similar to regular APE it 
basically is a sepparate environment from the typical Plan9 (probably to treat 
more like linuxemu rather than as APE since GCC-compiled libraries can not be 
mixed with the native system libraries).

I have personally looked at kerberos/heimdall + ldap before... do not remember 
for what and then I tried building in vanilla APE (I think it was for 
quagga). I have also had thoughts about a Tor client (needs libevent) and/or 
one of the distributed DNS things. Right now no time to play however :(

Now that I saw this updated 4.8 port of GCC I am  eager to play around with it 
again some time...

Re: [9fans] xz compression?

[Jens Staal]

On Tuesday 13 January 2015 11:56:57 Steve Simon wrote:
 Anyone ported the xz compressor/decompressor which
 is gaining traction these days?
 
 -Steve

http://plan9.bell-labs.com/sources/contrib/staal1978/pkg/xz-5.0.4b.tbz

I have not done much testing of it however... 
Would be cool to hear if it works for you.

Re: [9fans] xz compression?

[Jens Staal]

On Tuesday 13 January 2015 14:13:37 lu...@proxima.alt.za wrote:
  Anyone ported the xz compressor/decompressor which
  is gaining traction these days?
 
 Have you checked the Go packages?  Something tells me you may find a
 portable version there.
 
 Lucio.

found this... looks interesting but not ready yet according to the description
https://github.com/uli-go/xz

the most recent suggestion of using xz from go was basically to call the xz 
binary from the go code:
http://stackoverflow.com/questions/19555373/read-xz-files-in-go

[9fans] FUSE on Plan9

[Jens Staal]

This might not be popular among most Plan9 users, but I started thinking about 
the possibility of FUSE on Plan9 after seeing the FUSE on WebDAV [1] project.
At least on 9front, WebDAV should be integrated in webfs.

Would this theoretically work? The advantage of FUSE is access to a number of 
popular file systems (most notably ext4, NTFS, ZFS) and also many special-
purpose file systems. 

It feels a bit round-about and wasteful to go via webfs, so I guess the most 
appropriate method would be to implement a FUSE library directly on top of 9P 
instead of the kernel VFS - possibly by porting the NetBSD 
librefuse/libperfused [2] or the OpenBSD libfuse [3]. The disadvantage with 
this approach is that I am far too inexperienced and have far too little time 
to actually attempt this.

What are your thoughts? Should I try to get the fuse-on-webdav working on 
Plan9? Any other attempts with a more proper port/implementation already 
ongoing?

1. https://github.com/rianhunter/davfuse
2. http://netbsd.gw.com/cgi-bin/man-cgi?perfused+8+NetBSD-6.0
3. http://undeadly.org/cgi?action=articlesid=20131108082749

Re: [9fans] FUSE on Plan9

[Jens Staal]

On Friday 12 December 2014 17:36:52 cinap_len...@felloff.net wrote:
 steve quintile wrote a webdav filesystem (that uses webfs).
 
 see /n/sources/contrib/steve/wdfs.tbz
 
 i dont see why webdav should be integrated in webfs. webfs
 is plan9's low-level http library.

OK then I just mis-understood something I read as a striked-out action point 
on a 9front todo-list.

I will definitely look at that webdav fs. I will see if I try something with 
the davfuse - at least as a learning experience. I do however expect progress 
to be slow.

If I can access some files put in some NTFS and ext4 test-images directly from 
Plan9 that would be cool...

Re: [9fans] Porting plan9

[Jens Staal]

On Tuesday 02 December 2014 09:32:22 Richard Miller wrote:
 It's easier just to be
 lazy and let u-boot do it.

Sorry for hijacking a bit. There was a mention on this list a couple of months 
ago about work on getting Plan9 working on UEFI/GPT machines... 

whoever that was - any progress?

Re: [9fans] silly question

[Jens Staal]

On Tuesday 02 September 2014 02:46:12 arn...@skeeve.com wrote:
 Steve Simon st...@quintile.net wrote:
  I want to process some dated logfiles in awk.
  
  gawk has date, strftime and mktime but Brian's does not.
  
  plan9 has date(1) but there is no tm2sec(1), unless it
  is called somthing I didn't expect.
  
  Anyone found somting I could not in the plan9 distribution?
  
  -Steve
 
 I'd be happy to know the results of attempting a gawk port via APE. :-)
 
 Thanks,
 
 Arnold

There is one

http://ports2plan9.googlecode.com/files/gawk-4.0.0b.pkg.tbz

or
/n/sources/contrib/staal1978/pkg/gawk-4.0.0b.pkg.tbz

[9fans] GPT partitions

[Jens Staal]

Dear all,

I am interested in moving from running Plan9 in a VM to (try to) running on 
bare metal but since I am on a laptop with a single HDD and I play around with 
a couple of different things, I need to use GPT instead of MBR to avoid the 
silly 4 partition limit (since Plan9 can not be on an extended partition).

Does any of the Plan9 variants support booting from a GPT partition nowadays? 
I have not experimented with EFI boot yet on my primary OS but as far as I 
have read, this could also avoid chainloading bootloaders - any experience 
with this? 

I am also interested in the 64-bit HDD image from 9atom, but was never able to 
load that one with syslinux - so if anyone got any tips and tricks there that 
would also be cool.

Re: [9fans] Alternative Plan 9 Logo

[Jens Staal]

It somehow makes me think about Alice in wonderland falling down the rabbit
hole... Will she meet a Glenda nervously looking at the clock?

PS. Sorry abort top post... Android's fault
Den 6 jan 2014 19:27 skrev Nicolas Bercher nberc...@yahoo.fr:

 On 05/01/2014 19:09, Shane Morris wrote:

 Plan 9 Inside?


 No, it's just Plan 9 inside 9 inside 9 inside 9 inside 9. (-;

 Nicolas

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

[Jens Staal]

On Wednesday 04 December 2013 06:25:33 lu...@proxima.alt.za wrote:
 
 For a more Posix-y environment, lib9 and libbio are also required to
 provide features that Plan 9 has natively.  Lib9 mirrors libc and
 libbio is analogous to the real thing.  My contention is that we
 ought to keep these differences to an absolute minimum and,
 specifically, we ought to avoid libbio diverging from the Plan 9
 native version - at the cost of altering the latter, if necessary - so
 that the two systems are kept closer together.
 

Sorry for hijacking - but out of interest, has anyone approached an 
implementation of SIGCHLD either in the go - plan9 reconciliation effort or 
in any of the fix APE efforts (if I remember correctly, it would be needed 
for 
an APE pthreads implementation)?

My personal interest in this is that this is the only thing left to have 
MirBSD Ksh fully functional (potentially an up-to-date and actively maintained 
sh for APE instead of the current pdksh).

-- 

Re: [9fans] f2c issue

[Jens Staal]

On Thursday 21 November 2013 22:37:06 Fausto Saporito wrote:
 Hi Jens,
 
 thanks a lot!!! that site is wonderful :-D
 
 regards,
 Fausto
 
 

Thanks :)

If you want more language support (and more up-to-date fortran, but also ObjC, 
COBOL, C++ ...) it is highly recommended to check out the GCC 4.5.4 port made 
by Alvaro

http://marcus.biz.tm/jail/

he offers a binary download via Hg. A disadvantage is that the site is somewhat 
slow. He will upload a tarball mirror to ports2plan9 soon :)

The disadvantages with gcc are that the libraries need to be built for gcc, so 
the real system and the gcc stuff are completely sepparate. Another current 
disadvantage is that it is i386 only.

Re: [9fans] f2c issue

[Jens Staal]

On Thursday 21 November 2013 17:50:50 Fausto Saporito wrote:
 Hello all,
 
 i'm trying to compile f2c (downloaded from NETLIB), under latest Plan9
 installed under VirtualBox.
 Running arithchk I receive:
 
 arithchk 283: suicide: sys: fp: stack overflow fppc=0xbfff
 status=0x pc=0x12ea
 
 The emulated CPU is the same of the host CPU: INTEL i7.
 
 Was somebody able to compile f2c under plan9?
 
 thanks,
 Fausto


Hi

check the one found at

/n/sources/contrib/staal1978/pkg

to compile stuff you probably also need the libf2c

you can also download it on ports2plan9
https://code.google.com/p/ports2plan9/downloads/detail?name=libf2c.pkg.tbz
https://code.google.com/p/ports2plan9/downloads/detail?name=f2c.pkg.tbz

Re: [9fans] VMware and 9atom

[Jens Staal]

On Sunday 06 October 2013 17:10:47 Jacob Todd wrote:
 On Sun, Oct 6, 2013 at 5:08 PM, Christopher Nielsen cniel...@pobox.com 
wrote:
  Sadly, no. That would have been my first choice, if it were an option.
  I know ahci works great in 9atom. I'll give virtualbox a whirl.
 
 You would probably be better off using qemu than virtualbox.

Last when I installed 9atom I had to do it in virtualbox and then convert that 
image for qemu. The 9atom iso failed during boot (after selecting boot/install 
option).

Re: [9fans] Newbie questions

[Jens Staal]

On Wed, 18 Sep 2013 09:02:04 +0100
Richard Miller 9f...@hamnavoe.com wrote:

  Should I just reinstall plan9, fixing the partition problem and
  the plan9.ini problem?
 
 Yes.  But set up the partitions first with a non-plan 9 tool.  The
 current version of disk/fdisk (used in the installer) does not respect
 boundaries of existing partitions.  If you allow it to edit the plan 9
 partition, it is likely to rewrite the other partitions to align with
 its notion of cylinder size.
 
 

Now when we are on topic. Does recent Plan9 (or any of the forks)
support GPT?

Re: [9fans] incompatible type signature

[Jens Staal]

On Thu, 12 Sep 2013 11:16:31 -0400
erik quanstrom quans...@quanstro.net wrote:

  On 9atom 1 out of two type signature conflicts got resolved when I
  tried to build GNU nano (using FGB's PDcurses, rebuilt on 9atom to
  avoid that character width or something might be an issue).
  
  The resolved issue was some sort of internal conflict in libbsd
  bind. The remaining issue gives the following linking error (for
  nano) and is a conflict between libbsd and libdraw:
  
  ??none??: incompatible type signatures 50220469 
  (/386/lib/ape/libdraw.a(screen)) and
  9bbe58(/386/lib/ape/libbsd.a(bind)) for bind
 
 when did you last sync your source?  i believe this has been fixed:
 
 minooka; nm (/386/lib/ape /n/atom/plan9`{pwd})^/libdraw.a | grep bind
 
 i just applied the patch 9diff to 9atom which includes adiff (see
 9diff(1)) which should make tracking differences easier.
 
 - erik
 

This was indeed the issue: I had done a recent pull but not rebuilt the
libraries.

Now nano builds on APE with PDCurses and sort of works : can open
text files and fast commands work.
what does not work: 
- line change by enter
- saving a file (related to my mkstemp hack?)

... however it was just a test to see whether I could build stuff with
the pdcurses so not critical as such :) Now I can at least try to
figure out what goes wrong with the rest :)

Re: [9fans] incompatible type signature

[Jens Staal]

On Fri, 13 Sep 2013 14:30:37 +0200
Jens Staal staal1...@gmail.com wrote:

 Now nano builds on APE with PDCurses and sort of works : can open
 text files and fast commands work.
 what does not work: 
 - line change by enter
 - saving a file (related to my mkstemp hack?)

scratch that... everything works. Just a very weird behavior that
enter = ctrl+M

will upload it to contrib later if anyone is interested

sorry for the noise...

Re: [9fans] incompatible type signature

[Jens Staal]

On Thursday 12 September 2013 01:21:38 erik quanstrom wrote:

 
 i believe all the type signature problems in 9atom's ape have been sorted
 out. if you find something that does not work, it will be fixed.
 
 - erik

On 9atom 1 out of two type signature conflicts got resolved when I tried to 
build GNU nano (using FGB's PDcurses, rebuilt on 9atom to avoid that character 
width or something might be an issue).

The resolved issue was some sort of internal conflict in libbsd bind. The 
remaining issue gives the following linking error (for nano) and is a conflict 
between libbsd and libdraw:

??none??: incompatible type signatures 50220469 
(/386/lib/ape/libdraw.a(screen)) and 9bbe58(/386/lib/ape/libbsd.a(bind)) for 
bind

Re: [9fans] libbsd: incompatible type signatures

[Jens Staal]

On Mon, 26 Aug 2013 23:32:00 -0400
erik quanstrom quans...@quanstro.net wrote:

 On Tue Aug 20 03:21:29 EDT 2013, staal1...@gmail.com wrote:
  On Mon, 19 Aug 2013 13:04:26 -0400
  erik quanstrom quans...@quanstro.net wrote:
  
   it looks like 9atom doesn't do this properly.  i'll submit
   a 9atom patch, but simply adding it to /sys/src/ape/lib/9/libc.h
   doesn't work, so give me a bit.  it's a rats' nest of defines...
   
   the sloppy way to get this done would be to add
   -Dbind=_BIND to draw's mkfile.
   
   - erik
   
  
  Will the 9atom patch normally apply cleanly to vanilla Plan9? (I run
  vanilla Plan9 under kvm/qemu) - alternatively, is there a way to
  switch repositories and update to 9atom to get the improvements
  from within an existing install?
 
 in this case /n/atom/patch/applied/lib9bindconst will apply cleanly to
 either.  this should be the normal case.
 
 - erik
 

sorry if I have missed the obvious: how/where do I mount /n/atom ?

(btw: tried to install 9atom under qemu and failed (the plan9 bootloader
would not give the CD as boot option) - is this a known problem? )

Re: [9fans] libbsd: incompatible type signatures

[Jens Staal]

On Mon, 19 Aug 2013 13:04:26 -0400
erik quanstrom quans...@quanstro.net wrote:

 it looks like 9atom doesn't do this properly.  i'll submit
 a 9atom patch, but simply adding it to /sys/src/ape/lib/9/libc.h
 doesn't work, so give me a bit.  it's a rats' nest of defines...
 
 the sloppy way to get this done would be to add
 -Dbind=_BIND to draw's mkfile.
 
 - erik
 

Will the 9atom patch normally apply cleanly to vanilla Plan9? (I run
vanilla Plan9 under kvm/qemu) - alternatively, is there a way to
switch repositories and update to 9atom to get the improvements
from within an existing install?

[9fans] libbsd: incompatible type signatures

[Jens Staal]

Dear all,

I just hit the following compilation error and I wonder if this is some
sort of bug in the APE libraries and how to trace down what is really
wrong:

??none??: incompatible type signatures
50220469(/386/lib/ape/libdraw.a(screen)) and
9bbe58(/386/lib/ape/libbsd(bind)) for bind

htonl: incompatible type signatures
617952a3(/386/lib/ape/libbsd.a(bind)) and ac7c45d0
(/386/lib/ape/libbsd.a(ntohs)) for ntohs

Version: I did a pull this morning so everything should be up-to-date.

any hints about how to fix this?

Re: [9fans] libbsd: incompatible type signatures

[Jens Staal]

On Mon, 19 Aug 2013 17:30:52 +0200
lu...@proxima.alt.za wrote:

  I just hit the following compilation error and I wonder if this is
  some sort of bug in the APE libraries and how to trace down what is
  really wrong:
 
 I had a similar situation when compiling the entire userland.  I
 hacked each as seemed appropriate, but somebody ought to go in there
 with a shovel...  Thing is, BSD isn't very consistent either and
 sometimes socket_t * is preferable to uint *, whereas sometimes void *
 is better than char *.  A shovel, indeed.
 
 From memory, don't call me a liar :-)
 
 ++L
 
 

Heh.. that does not sound too encouraging... 

For both errors, they seem to be blaming bind in libbsd.a so I guess
that is where one would have to look first. I have no idea at all how
to do anything about it though. normal compilation issues where the
corresponding code can be traced down are definitely easier ;)

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Jens Staal]

On Fri, 26 Jul 2013 08:59:30 +0200
Jens Staal staal1...@gmail.com wrote:

 Dear all,
 
 From yesterday upstream mksh (cvs and future R48 and onwards) builds
 out of the box on Plan9 simply by:
 
 ape/psh
 ./Build.sh
 
 One issue remains and that is that the shell will get stuck after
 executing an external command. To build a working shell, there is a
 temporary work-around by issuing:
 
 CFLAGS=-DMKSH_NOPROSPECTOFWORK ./Build.sh
 
 This disables a number of features in the shell.
 
 I have uploaded an R47 build with the modified Build.sh (with
 -DMKSH_NOPROSPECTOFWORK)
 at /n/sources/contrib/staal1978/pkg/mksh-R47.tbz.
 
 In order to get a fully-functional mksh, something needs to be fixed
 host-side. A good guess is that it is the way APE handles SIGCHLD,
 since the same freezing has occurred on a number of other ports of
 mksh:
 
 http://www.mail-archive.com/miros-mksh@mirbsd.org/msg00215.html
 
 Is there interest in fixing SIGCHLD on APE and if so, what would be
 the best approach?
 
 If there is interest, it would thus be entirely possible to have an
 upstream, modern and mantained ksh shell which builds unmodified for
 APE (possibly as replacement of the old pdksh port now acting as
 sh). The mksh shell is used in many different contexts, most
 notably as shell in the more modern versions of Android.

The R48 of mksh is now released, so from now on one should basically be
able to download the latest tarball at any given time from
https://www.mirbsd.org/MirOS/dist/mir/mksh/
and build it on Plan9 by

ape/psh
./Build.sh

and until the SIGCHLD thing gets resolved, just build with
CFLAGS=-DMKSH_NOPROSPECTOFWORK ./Build.sh

[9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Jens Staal]

Dear all,

From yesterday upstream mksh (cvs and future R48 and onwards) builds out
of the box on Plan9 simply by:

ape/psh
./Build.sh

One issue remains and that is that the shell will get stuck after
executing an external command. To build a working shell, there is a
temporary work-around by issuing:

CFLAGS=-DMKSH_NOPROSPECTOFWORK ./Build.sh

This disables a number of features in the shell.

I have uploaded an R47 build with the modified Build.sh (with
-DMKSH_NOPROSPECTOFWORK)
at /n/sources/contrib/staal1978/pkg/mksh-R47.tbz.

In order to get a fully-functional mksh, something needs to be fixed
host-side. A good guess is that it is the way APE handles SIGCHLD,
since the same freezing has occurred on a number of other ports of
mksh:

http://www.mail-archive.com/miros-mksh@mirbsd.org/msg00215.html

Is there interest in fixing SIGCHLD on APE and if so, what would be the
best approach?

If there is interest, it would thus be entirely possible to have an
upstream, modern and mantained ksh shell which builds unmodified for APE
(possibly as replacement of the old pdksh port now acting as sh).
The mksh shell is used in many different contexts, most notably as
shell in the more modern versions of Android.

Re: [9fans] MirOS ksh (mksh) building out-of-the box on Plan9/APE

[Jens Staal]

On Fri, 26 Jul 2013 13:01:16 -0400
erik quanstrom quans...@quanstro.net wrote:

 On Fri Jul 26 12:30:20 EDT 2013, cinap_len...@gmx.de wrote:
  plan9 kernel doesnt send notes on process exit to the parent. i do
  not see any trivial way to emulate SIGCHLD as ape might spawn also
  native processes so we cannot just add code to ape to emit the
  signal on exit.
  
  we might handle wait records in a separate process tho using the
  devproc's wait file (that means also we would need to reimplement
  the various wait functions in ape as one would get a Einuse error
  on wait() when someone reads your wait file, ugh) and also generate
  a signal.


Would it be interesting to know how the other mksh ports (I think
Syllable and Win32) implemented SIGCHLD emulation? I also saw after
some googling that some tests in Go had to be ignored due to SIGCHLD
issues on Plan9, so I guess there are more use-cases than this one.
Unfortunately I know too little to actually give input on the actual
solution - most of it will come out as hot air (which hopefully won't
stink...).

 
 we may also have to do this if we wish to support pthreads with
 processes. pthreads allow one thread to wait for the children started
 by a second thread.
 
 - erik
 

A native APE pthread implementation would be awesome! I have been using
Gnu Pth some, but getting a proper APE variant would be much more
preferrable :)

Re: [9fans] more plan9 software

[Jens Staal]

On 2013-06-04 02:00, Serge Ziryukin wrote:

3) https://bitbucket.org/ftrvxmtrx/readtags

Reads tags from mp3 (id3v1, id3v2, utf16, iso8859-1), flac, oggvorbis
and writes them to stdout. Has a pretty printer, useful when you want
to see what's playing on ogg radio stream while actually playing it.



If someone is interested, I just uploaded the following:

http://plan9.bell-labs.com/sources/contrib/staal1978/pkg/xz-5.0.4.tbz

unfortunately i386 only, since it was built with gcc (for more 
architectures, either the native pcc or ape/cc need to get fixed or gcc 
need not be updated/adapted to build for other targets).


I have not done much testing yet, so I do not know how well it works (it 
is fresh off the presses, only tested with --help and --version on the 
different utilities).

Re: [9fans] more plan9 software

[Jens Staal]

On 2013-06-04 16:38, Jens Staal wrote:

On 2013-06-04 02:00, Serge Ziryukin wrote:

3) https://bitbucket.org/ftrvxmtrx/readtags

Reads tags from mp3 (id3v1, id3v2, utf16, iso8859-1), flac, oggvorbis
and writes them to stdout. Has a pretty printer, useful when you want
to see what's playing on ogg radio stream while actually playing it.



If someone is interested, I just uploaded the following:

http://plan9.bell-labs.com/sources/contrib/staal1978/pkg/xz-5.0.4.tbz

unfortunately i386 only, since it was built with gcc (for more
architectures, either the native pcc or ape/cc need to get fixed or gcc
need not be updated/adapted to build for other targets).

I have not done much testing yet, so I do not know how well it works (it
is fresh off the presses, only tested with --help and --version on the
different utilities).




Sorry there seems to be some issues still. Running unxz or xz -d on a 
.tar.xz archive gives an error about the archive being corrupt.


no idea where to find the error. If anyone is interested to help finding 
what might be wrong, that would be cool.

Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin

[Jens Staal]

On 2013-04-29 21:11, Aram Hăvărneanu wrote:

This looks like a reasonable list:




Alternatively, one can implement rc(1) or awk(1) in Go, rather than
implementing all the base tools.

--
Aram Hăvărneanu



The oh shell is (or used to be) an rc-like implementation in go so if 
that one (with modifications) got included in goblin, that is one more 
that can be scratched from the list.


https://github.com/michaelmacinnis/oh

The bad stuff for Plan9 would be the external dependencies of libtecla 
and ncurses (still have not been able to get ncurses to work :( ), so 
there would have to be lots of modifications probably.

Re: [9fans] APE libsec

[Jens Staal]

Sorry if this may sound ignorant and clueless, but would a similar port of the 
Plan9 thread(2) to APE be possible - in particular in a form where stuff are 
exposed through the headers as a standard pthreads solution?

Right now I have noticed that I use GNU Pth extensively under APE, but a more 
native pthread implementation would be cool.

Re: [9fans] trying to populate arm tree

[Jens Staal]

On Monday 28 January 2013 14.46.38 James Chapman wrote:

 
 The build fails with a lot of cpp errors about /sys/include/ape/openssl/*.h
 
 about unknown object type.
 
 How can i exclude openssl from the build?
 
 I'm assuming I won't be able to build it. I can put up with cpuing in to run
 the extra stuff I have installed.
 
 I tried adding openssl to BUGGERED in /sys/src/cmd/mkfile but this didn't
 help.
 
 James

specifically for this reason, I have repackaged a couple of ports and put non 
core packages/ports under /sys/src/pkg/$packagename. Because of this, my 
/sys/src/ape/lib is clean and I could without problems build for all supported 
architectures (could come in handy if I ever want to cross-compile one of my 
ports to another architecture) with mk installall - with one exception:
/sys/src/ape/lib/ap/mips/lock.c contained functions where the compiler 
complained about missing return values.

I have a tarball on my Plan9 machine where I repackaged fgb's openssl to put 
the sources in /sys/src/pkg/openssl (and 
added a #pragma lib to libssl and libcrypt in a header I think). 

My initial plan was to try to build a newer openssl but it was far too 
complicated (the tarball contains symlinks that disappear on Plan9 and 
Configure required Perl).

If you want I could upload this one.
for libz and libbz2 I can also offer updated ports
can be found at /n/sources/contrib/staal1978/pkg/

Re: [9fans] a jmp_buf in APE question

[Jens Staal]

måndagen den 7 januari 2013 05.31.44 skrev  erik quanstrom:
 the structure within jmp_buf is entirely determined by the code in setjmp.s
 
 i don't think it would be wise to rely on the structure of jmp_buf.

Do you mean by this that it would be unwise to do something like

variable that needs to be = sp = (jmp_buf) jb[0]
variable that needs to be = pc = (jmp_buf) jb[1]


this is how other similar ports of this package (GNU portable threads) have 
been made, for example for win32

variant 4, variant 5 and variant X in the file pth_mctx.c are examples 
of this strategy.*


*
for reference:
http://www.opensource.apple.com/source/ChatServer/ChatServer-37.1/jabberd-
src/jabberd/pth-1.4.0/pth_mctx.c?txt

Re: [9fans] a jmp_buf in APE question

[Jens Staal]

måndagen den 7 januari 2013 06.15.08 skrev  erik quanstrom:

 
 yes, i think it would be unwise.  i think you mean
 
   sp = ((uintptr*)jb)[0]
   pc = ((uintptr*)jb)[1]
 

yeah sorry I did not mean it to look like C-code and the paranthesis was meant 
to indicate that jb got #defined to jmp_buf.

  this is how other similar ports of this package (GNU portable threads)
  have
  been made, for example for win32
 
 it's just my opinion.  i would see such code as peeking through
 an deliberately-opaque interface.  and to me that's almost always
 a bad idea.  even if it works, and even if other people do it.
 
 others might have other thoughts.
 
 - erik

I thank you for your feedback and help I did the build despite your warnings, 
and the result can be found either at:

http://code.google.com/p/ports2plan9/downloads/list

or:

/n/sources/contrib/staal1978/pkg

Tests and pre-compiled test binaries can also be found at:

/n/sources/contrib/staal1978/pkg/pth_test

There are some scary stuff in there, like the test_sig result, but others seem 
to work...

[9fans] a jmp_buf in APE question

[Jens Staal]

Hi all. Perhaps I have been looking at completely the wrong places and perhaps 
I am just not grasping it at all.

For a package that I want to build under APE, I need to put in the stack 
pointer (sp) and the program counter (pc) part of jmp_buf specific for Plan9 
(since APE does not expose any stack-related functions that could have been 
used)

according to /sys/include/ape/setjmp.h, jmp_buf is an array of 10 int:s.

I then went to check out /sys/src/ape/lib/ap/$objtype/setjmp.s
but I could not really understand anything in those files

luckily, I also looked at the GAS-formatted setjmp.s in the GCC-port of the 
APE libs.
There, it seems that each function with a jmp_buf variable as an argument has 
a set of 10 rows of operations (which I guess correspond to the 10 values in 
jmp_buf). Based on that, it would seem that the value for sp is in jmp_buf[2] 
and for pc in jmp_buf[3].

Am I correct or have I totally misunderstood how these things work? I am a 
self-taught hobbyist so sometimes really basic stuff can have eluded me.

The second question would be, is the position of those two values in jmp_buf 
architecture-specific so that I should make a note of that it is working on 
i386 only?

Re: [9fans] ape/errno.h

[Jens Staal]

fredagen den 21 december 2012 12.38.01 skrev  Jeff Sickel:
 Given all the Plan 9 spinoffs that still include APE, it might
 be worth the effort at some point to bring APE up to SUSv3 or
 SUSv4 to ease in porting code that's heavily POSIX-dependent.
 
 Though there might not be enough time or energy to take on
 such an endeavor.
 
 -jas

Just recently, I copied a few files from the newlib libc into an application 
to make it compile under APE.

I guess that the low road to take might be to basically do the same but to 
generate a temporary APE extension library with kernel-independent libc code 
copied from other projects (basially similar to what gnulib does). 

Newlib and Musl libc are both permissively licensed so they should not be a 
problem to use. Musl is currently linux-specific but perhaps there are kernel-
independent parts that could be used. I guess the most important thing is to 
make sure that the things included in the extension library does not overlap 
with the APE libraries.

The advantage with this approach could be that the real APE keeps clean and 
can be developed at its own pace depending on what the needs are (and stuff 
found useful from the extension library could be merged back to real APE after 
being re-written according to the standards of Plan9).

Re: [9fans] ape/errno.h

[Jens Staal]

In my porting of stuff using APE, I often notice that many applications
assume more members of the struct stat in sys/stat.h, especially
st_blocksize. Is there any reasonable similar information available
elsewhere in the system that could be used in a local rpl_stat struct for
those ports?

other annoying stuff are normally related to malloc/alloca and sys/mtio.h
stdint.h is normally easily just redirected to inttypes.h and stdbool.h can
also easily included.


2012/12/18 erik quanstrom quans...@quanstro.net

 On Mon Dec 17 17:38:33 EST 2012, j...@corpus-callosum.com wrote:
  I'm not familiar with the full history of /sys/include/ape/errno.h, but
 it looks like EISCON should be EISCONN to fit with other systems that at
 least pretend to be POSIX compliant.  SunOS 5.11 did have EISCON, but...

 makes sense to me; there are no references to EISCON
 on the system other than the include file.

 - erik

[9fans] GAS front-end for 8a?

[Jens Staal]

Hi

I just wondered if anyone has made some sort of wrapper similar to the posix c 
compiler (pcc) front end for 8c, but for ASM?

The reason I ask is that some projects have mixed .c and .S code and the ASM 
is mostly GAS syntax.

Alternative ways of dealing with GAS ASM and still get native object files are 
also welcome :)

Re: [9fans] GAS front-end for 8a?

[Jens Staal]

Thanks!

I will check it out. I mostly made a shot at ffi since it is listed as a 
dependency for a couple of packages I would be interested in building (or at 
least try to build).

On a more general note though, being able to convert GAS ASM to Plan9 ASM (and 
possibly also the other way around) would be quite handy sometimes, I guess.

måndagen den 3 december 2012 08.23.29 skrev  Tassilo Philipp:
 Hi,
 
 I noticed you were asking on the libffi mailing list for Plan9 support, so I
 guess your question is related to getting libffi to run on Plan9? If you
 just need a ffi, dyncall is running on Plan9 already (x86, only calls, not
 callbacks, though), supporting Plan9's calling convention. Check out
 dyncall.org
 
 Hope this helps,
 Tassilo
 
 
 On Mon, 03 Dec 2012 11:02:49 +0100
 
 Jens Staal staal1...@gmail.com wrote:
  Hi
  
  I just wondered if anyone has made some sort of wrapper similar to the
  posix c compiler (pcc) front end for 8c, but for ASM?
  
  The reason I ask is that some projects have mixed .c and .S code and the
  ASM is mostly GAS syntax.
  
  Alternative ways of dealing with GAS ASM and still get native object files
  are also welcome :)

Re: [9fans] Apache portable runtime

[Jens Staal]

måndagen den 19 november 2012 10.05.16 skrev  Steve Simon:
 Somone was working on a port of the apache portable
 runtime a while back but I have lost their email.
 
 could they contact me please?
 
 Thanks,
 
 -Steve

Hi

you can find my apr port at:

http://code.google.com/p/ports2plan9/


there is a binary download for i386, but I realized that it was broken during 
compilation of iconv so you are probably better off with a hg checkout.

I have unfortunately not had much time playing with porting stuff to plan9 
lately after I became a father in May. Got some fun ideas that I would like to 
explore though.

anyone wanting to join or take over governance of above project is free to do 
so.

also another warning: I am a total amateur (molecular biologist as a day job) 
so do not expect beatiful solutions ;)

[9fans] asm question

[Jens Staal]

Hi

I am currently attempting to build up-to-date APE libs for gnu/gcc
(the port found in /n/sources/extra/gcc). The APE libs there are from
2002 and there are some significant additions after that that I would
like to exploit.

The .c parts of the library builds nicely and I have a near-complete port.
The only issues I have is that .s files seem to be assembler-specific.
crt0.s can only be processed by gnu/as and the .s files in ap/386/ and
9/386/ can only be processed by 8a. I actually naively tried making
APE libraries with the .s files processed by 8a and renamed them from
.8 to .o and built the libraries. That failed during linking of a
test-compile (with clear error messages pointing to those .s-derived
object files) so apparently asm is compiler-specific (which sort of
demonstrates how little I know on this level...).

The only solution I can see is to try to manually translate those .s
files from Plan9 assembly to GNU assembly. The best reference
comparison I have found is libc/386/setlongjmp.s from the old port
in /n/sources/extra/gcc and the current APE libs ap/386/setlongjmp.s.
The two files look quite similar, appart from that the first is GNU
style and the other Plan9 style.

It is however still pretty unclear to me what the different things
actually say and especially carry over that info to translate the rest
of the .s files.

What I wonder is whether there is any good documentation/info
somewhere that could help me translate the rest of the .s files?

Re: [9fans] asm question

[Jens Staal]

 The only solution I can see is to try to manually translate those .s
 files from Plan9 assembly to GNU assembly. The best reference
 comparison I have found is libc/386/setlongjmp.s from the old port
 in /n/sources/extra/gcc and the current APE libs ap/386/setlongjmp.s.
 The two files look quite similar, appart from that the first is GNU
 style and the other Plan9 style.

sorry it should be setjmp.s

Re: [9fans] Plan 9 technical docs and man pages - licensed or public domain?

[Jens Staal]

2012/7/25 Skip Tavakkolian skip.tavakkol...@gmail.com:
 For a dead OS, Plan 9 sure gets around ;)

 Plan 9, a nurse-log of modern computing.

 -Skip

 On Jul 24, 2012, at 9:10 PM, erik quanstrom quans...@quanstro.net wrote:

 that's the joke :) plan9 has been considered a dead operating system
 for a long time.

 h.  don't tell my employer.

 - erik



It must be Eros stimulating its  pituitary and pineal glands. ;)

(http://en.wikipedia.org/wiki/Plan_9_from_Outer_Space)

Re: [9fans] I will buy laptop pre-installed with plan9!!!

[Jens Staal]

torsdagen den 10 maj 2012 12.19.51 skrev  tlaro...@polynum.com:
   Really? Wonderful..
   Is there some docs for install Plan 9(more detail)?
   x201 doesn't have a CD-ROM..
 
Installing Plan9 without a CD reader or a PXE boot.
 
 Abstract


Wow! Thanks. I probably need to look at this. I recently tried (and failed) to 
boot a plan9 iso via syslinux and memdisk to circumvent the issue with my 
CD/DVD reader failing at a certain point in the boot proces.

If anyone has instructions on making a bootable (install) usb for Plan9 (using 
syslinux + iso or other method), I would be very interested in this!. 
Preferrably a method that does not require Plan9 to already be installed...

Alternatively, a bootable usb (install) image that can be dd:ed to a usb would 
also work...

Re: [9fans] Mercurial port is official

[Jens Staal]

fredagen den 27 april 2012 08.04.16 skrev  Steven Stallion:
 All,
 
 I'm happy to report that the official Mecurial port is complete and
 has been accepted upstream. Starting with version 2.2, Mercurial will
 support Plan 9 and friends out of the box.

Awesome! does this mean that the hg-git plugin will work out-of-the-box too?


-- 
Dr.ir. Jens Staal, Post Doc
http://www.researcherid.com/rid/B-7383-2008
http://scholar.google.com/citations?user=dFoQi0QJ

* Department of Molecular Biology, Ghent University
* Dept. for Molecular  Biomedical Research, Unit of Molecular Signal
Transduction in Inflammation, VIB

Technologiepark 927,   9052 GENT - Zwijnaarde
Tel: +32-484-981058 (cell)
url:  http://www.dmbr.ugent.be/ 

Re: [9fans] some pcc questions

[Jens Staal]

 The second issue that I have been meaning to ask the list is about pcc
 and bitfields - are they supported or is this some sort of can of
 worms I have stepped into?


I have just hit another pcc can not initialize bitfields problem
with netsurf libcss. If anyone know how to tackle that issue (or if it
even CAN be tackled) it would be greatly appreciated.
The broken build of libcss can be found either at
/n/sources/contrib/staal1978/pkg/libcss-alpha1.tbz or [1].

[1] http://code.google.com/p/ports2plan9/downloads/detail?name=libcss-alpha1.tbz

I hope by solving this issue I might be able to make a native APE
build of GNU m4 pretty easily afterwards if the bitfield issue is the
same ;)

[9fans] some pcc questions

[Jens Staal]

Hi all

I have some problems that I sometimes run into while trying to port
stuff. One is that some files just freezes the compilation process
(but load goes down to 0 so it is not just labour intensive, but
rather that it just sticks there without doing anything) and when I
exit the compilation (by pressing delete) I get different error
messages every time.

Is there a way to track down what is really happening in those cases
in order to solve them?


The second issue that I have been meaning to ask the list is about pcc
and bitfields - are they supported or is this some sort of can of
worms I have stepped into?

Here I have a more specific issue with compiling GNU m4: Compiling the
gnulib and all other files except src/builtin.c works fine with APE
libs and pcc, but builtin.c fails due to bitfields.
At the other side of the spectrum, a modern GNU m4 (including
src/builtin.c) can be compiled with the old GCC port, but there the
GCC-ported APE-libs are too old (vsnprintf etc not supported), so it
fails at the final linking phase since lots of stuff are not provided
by the C library.

Personally, I would prefer to crack that particular nut with pcc than
to go for an updated APE libs port to GCC so if there are specific
changes that can be done to bitfields in order to get it working, it
would be very interesting to hear about them...

some more details on why I even would bother doing such a thing:
http://code.google.com/p/ports2plan9/wiki/GNUonPlan9

[9fans] upstreaming a port of gawk -tips and opinions?

[Jens Staal]

The author of gawk is interested in getting the changes needed to 
compile on Plan9 upstream. The port [1] has been slightly updated again 
and the Hg repository will be updated with the last changes as soon as I 
got time (main.c now vanilla).


Since I most likely will have to backport my (rather limited) changes 
to a complete source distribution since my own repo has lots of 
un-needed stuff (m4, po directories etc) deleted which would show up on 
a diff, I wanted to take the opportunity to ask the list what the best 
organization of a Plan9 port would be when sent upstream.


Should I make an effort to make the (mkmk-generated) mkfiles explicitly 
$objtype-independent or stay i386 since that is the only platform I have 
tested on?


How would the addition of mkfiles and rc-files to the source 
distribution be as un-intrusive as possible?
One possiblility might be to have a plan9 directory like in perl, where 
the mkfiles are located. Other ideas?


[1] http://ports2plan9.googlecode.com/files/gawk-4.0.0b.pkg.tbz

Re: [9fans] current python hg support

[Jens Staal]

2012/2/10 John Floren j...@jfloren.net:
 On Thu, Feb 9, 2012 at 6:06 PM, Jeff Sickel j...@corpus-callosum.com wrote:
 A quick question for everyone, is there interest in getting a more current 
 version of hg working for Plan 9  NIX?  If so, given I've spent way too 
 much time in the past getting both working for other platforms, I could 
 devote a little time to get both prepped for future work.

 Python 2.5.1 is stable, but it wouldn't hurt us to be a little closer to the 
 2.7.1 release.
 Hg has made significant strides since 1.0.2.

 Neither of these updates might help the oddities people are finding while 
 using Hg, but if we're looking forward then keeping current should be 
 addressed.

 -jas


 That would be really great... Ideally, if you update Python, you could
 get patches put in to officially support Plan 9. If I remember
 correctly, there was at least one Python developer who was interested
 in helping with that.

 John


The same is actually also true for the Perl guys. I asked around a bit
there just recently when I noticed that the Plan9 install instructions
do not work for recent versions (the official Perl sources ship with a
script to prep the Perl sources and an mkfile under the plan9/
directory). They seem interested in getting it up to date if anyone is
interested.

I tried looking at it but did not really figure it out...

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-02/msg00069.html

Re: [9fans] ape compiler error, IND CHAR and INT

[Jens Staal]

I get the same error no matter which BASIC file that gets generated to C 
and it is put in the generated header file (at different row numbers, 
ofcourse. I used test1 as use case to try to track it down), so there is 
some sort of typedef inconsistency in there somewhere. I believe that it 
has something to do with strndup and the switch function in the 
generated header, but I am not sure exactly what.


2012-01-23 09:13, steve skrev:

I must have missed that one,
 From your old report it seems tr problem is at line 432 of test1.bac.h

Can you reproduce the error?

-Steve

On 23 Jan 2012, at 06:47 AM, Jens Staalstaal1...@gmail.com  wrote:


2012/1/18 John Florenj...@jfloren.net:

On Wed, Jan 18, 2012 at 10:46 AM, Martin Harrissmar...@princeton.edu  wrote:

John Floren wrote:

I figured I'd try building Python from the source on their website
just for kicks. Configure went ok, but when I went to run make, it
soon bailed out with this error:

cc -c -OPT:Olimit=0 -g -DNDEBUG -O  -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c
cc: flag -P ignored
cc: flag -: ignored
cc: can't find library for -l
/usr/john/Python-2.7.2/Parser/grammar.c:46[stdin:12906] incompatible
types: IND CHAR and INT for op AS
/usr/john/Python-2.7.2/Parser/grammar.c:108[stdin:12968] incompatible
types: IND CHAR and INT for op AS
cc: cpp: 8c 896765: error
*** Error code 1
#

The offending lines are these:

d-d_name = strdup(name);
and
lb-lb_str = strdup(str);

d_name and lb_str are both defined as char*, and strdup is supposed to
return a char*. However, if I'm reading that error message correctly,
it thinks strdup is trying to return a char*. Does anyone recognize
what's going on?


No declaration in scope for the string functions, compiler thinks they
return INT?

Martin


Yup, I r dum, needed a -D_BSD_EXTENSION in my flags to make string.h
behave right.


I have a similar issue with BaCon (a ksh script converting BASIC code
to C), a modified version running under APE sh can be found here:

http://code.google.com/p/ports2plan9/source/browse/BaCon

Also this one has the problem 'incompatible types IND CONST CHAR and
INT for op AS'

and I have not been able to track down exactly where in the script
that the erroneous code gets generated.

issue described here:
http://code.google.com/p/ports2plan9/issues/detail?id=1

I have already added the -D_BSD_EXTENSION in the CFLAGS in the script.

Re: [9fans] ape compiler error, IND CHAR and INT

[Jens Staal]

Thanks for the feedback!

The dlerror was indeed the culprit and now my errors have jumped to:


eof syntax error, last name: 0
pcc: cpp: 469: error


, presumably in the generated .c file.

Where can I find info about the 469 error and how do I know where
the error occurred? (previously I have had more informative last
names to jump to...)

I also added the -+ to CFLAGS. I have no idea if this may help with
the problems with // comments.

2012/1/23 erik quanstrom quans...@quanstro.net:
 The line number is off-by-one, for some reason, but since the operation is
 AS (assign), and since the assignment from dlerror is on the next line, and
 dlerror won't be declared anywhere, that's most likely to be the problem.

 i think the compiler eats the newline sometimes when there's a // comment
 on a preprocessor line.

 i thought i submitted a fix for this.

 - erik

Re: [9fans] ape compiler error, IND CHAR and INT

[Jens Staal]

2012/1/18 John Floren j...@jfloren.net:
 On Wed, Jan 18, 2012 at 10:46 AM, Martin Harriss mar...@princeton.edu wrote:
 John Floren wrote:

 I figured I'd try building Python from the source on their website
 just for kicks. Configure went ok, but when I went to run make, it
 soon bailed out with this error:

 cc -c -OPT:Olimit=0 -g -DNDEBUG -O  -I. -IInclude -I./Include
 -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c
 cc: flag -P ignored
 cc: flag -: ignored
 cc: can't find library for -l
 /usr/john/Python-2.7.2/Parser/grammar.c:46[stdin:12906] incompatible
 types: IND CHAR and INT for op AS
 /usr/john/Python-2.7.2/Parser/grammar.c:108[stdin:12968] incompatible
 types: IND CHAR and INT for op AS
 cc: cpp: 8c 896765: error
 *** Error code 1
 #

 The offending lines are these:

    d-d_name = strdup(name);
 and
    lb-lb_str = strdup(str);

 d_name and lb_str are both defined as char*, and strdup is supposed to
 return a char*. However, if I'm reading that error message correctly,
 it thinks strdup is trying to return a char*. Does anyone recognize
 what's going on?


 No declaration in scope for the string functions, compiler thinks they
 return INT?

 Martin


 Yup, I r dum, needed a -D_BSD_EXTENSION in my flags to make string.h
 behave right.


I have a similar issue with BaCon (a ksh script converting BASIC code
to C), a modified version running under APE sh can be found here:

http://code.google.com/p/ports2plan9/source/browse/BaCon

Also this one has the problem 'incompatible types IND CONST CHAR and
INT for op AS'

and I have not been able to track down exactly where in the script
that the erroneous code gets generated.

issue described here:
http://code.google.com/p/ports2plan9/issues/detail?id=1

I have already added the -D_BSD_EXTENSION in the CFLAGS in the script.

Re: [9fans] miau, an IRC bouncer

[Jens Staal]

That error is very common where ls -di is called in the configure
script (strange that it did not complain on your other system).

a nice fix is fgb's config script
http://plan9.bell-labs.com/sources/contrib/fgb/rc/config

another common problem is grep, where the easiest is to write

GREP=grep
at the top of the configure script.

2012/1/12 John Floren j...@jfloren.net:
 On Wed, Jan 11, 2012 at 3:03 PM, John Floren j...@jfloren.net wrote:
 Back when I had my FreeBSD server, I used to run a tmux session and
 irssi to keep myself connected to IRC at all times.  This let me
 access it from any computer with an SSH client.

 Now I only run a Plan 9 server, but I missed the simplicity and
 convenience of having just one nickname on IRC at all times.  I
 finally got fed up and did a very crude port of Miau, an IRC bouncer.
 A bouncer stays connected to your selected servers and channels while
 serving the IRC protocol itself.  You then point an IRC client at your
 bouncer, which instantly restores for you all the channels you had
 open.

 This serves essentially the same purpose as ircfs, but with the
 advantage that you don't need Plan 9 or Inferno to access it--any
 computer with an IRC client can connect.  In fact, you can just use
 Mibbit to connect as long as you have a web browser.

 Porting Miau was pretty easy; the configure script actually ran
 properly and I only had to do a little bit of hacking to account for
 things like the lack of crypt() (so yes, you have to type in a
 plaintext password in the config file rather than giving it a hash).
 There's a tar at /n/sources/contrib/john/miau9.tgz, or you can check
 out the bitbucket repo from http://bitbucket.org/floren/miau9
 (preferred).

 Known bugs: It's really easy to type maui instead of miau.


 John


 Oddly, I can't get this to compile on my home Plan 9 system; there, it
 bails out like all other configure scripts I've ever tried to use:

 # ./configure
 ln: conf115166.dir destination exists
 usage: ls [-ACFHLRUacdflprstu1] [file ...]
 configure: error: working directory cannot be determined
 #

 I'll have to try and figure out the difference.


 John

[9fans] fake tty or other trick?

[Jens Staal]

Hi all

I have been playing with trying to get the current MirOS ksh (mksh) to
compile and run under APE. It now compiles but as it is executed it
complains about no /dev/tty and crashes as soon as I try to write a
command to it.

Since the pdksh was ported as the generic APE 'sh' I guess the
tty-issue has been solved once before. Any pointers?

current source and temporary (ugly) solutions can be seen here:
http://code.google.com/p/ports2plan9/source/browse/#hg%2Fmksh

Re: [9fans] fun with replica and pull

[Jens Staal]

2011-12-20 17:09, Federico Benavento skrev:

On Dec 20, 2011, at 12:57 PM, ron minnich wrote:

it reminds me of why we went with hg on the NIX tree.


because at the time you did it things like bitbucket and the hg port came to 
exist?

so what one should do, use replica to sync with sources and move the all the 
contribs
to bitbucket google code?




That sounds like a pretty good idea :)

I played with a similar idea with the
http://code.google.com/p/ports2plan9/

I am however still a beginner (I hope to improve my Plan9 skills and 
learn as I go along with various (increasingly advanced) porting efforts 
without actually having an agenda or aim as such), but if people want 
to upload their contribs to that repository they are free to do so.


By the way - is someone working on an update of the Python2 port? and 
what about the hg-git plugin? Just wondering if I should start playing 
with those or leave that to someone else.

[9fans] announcing my first ports :)

[Jens Staal]

For those interested, pcre and re2c can be downloaded in binary (386)
form from and in source form using hg from:

http://code.google.com/p/ports2plan9/

I got a number of other things in pipeline that I am interested in
trying to put up there. Many of them will most likely not be
interesting for most of the 9fans. On the other hand, I thought that
some people might be interested in playing with it already anyway.

If anyone is interested in pushing their ports to this repository they
are more than welcome :)

Re: [9fans] mkmk

[Jens Staal]

2011-12-05 14:26, Steve Simon skrev:

mkmk is in the contrib package contrib/mkmk

http://man.cat-v.org/plan_9_contrib/1/mkmk

I would say mkmk was an interesting experiment rather than a resounding success.

The idea was to simplify re-porting foreign code to plan9 by autogenerating the
mkfile from just the C source and some heuristics. Also important to me is that
the generated mkfiles should be simple and cleanly formatted.

I use an rc(1) script (called 9port) per package which would tidy it and run 
mkmk
with the apropriate args - it somtimes needs a bit of help. The script may then
be reused to quickly re-port the latest version of the code to plan9.

Examples here:
http://plan9.bell-labs.com/sources/contrib/steve/root/sys/src/cmd/mkmk/9port/

The lack of success came when trying to port bigger projects like the
Apache portable runtime, or up to date ghostscript.

-Steve



Personally I have found mkmk very impressive and I have been using it 
for some attempted ports that I am working with in my spare time.

Re: [9fans] 9vx instability

[Jens Staal]

On 11/27/11 14:39, yy wrote:

2011/11/21 Jens Staalstaal1...@gmail.com:

What I would like to know is if you can boot a plan9 system from iso via 9vx
as persistent partition whereas changes are saved to another directory (so
basically setting up a union mount between the iso and a directory) -
alternatively specifying an alternative path for $home using 9vx booting
from an iso.


I've written a small script to help with this. From the comments:

# Usage: 9vxi [9vx options]
#   If set, $localroot is used as root,
#   and $home as the home directory.
#   If localroot is not set. search for it:
#   first in the cwd, then at $HOME.
#   initrc is ignored. Other options are
#   just passed to 9vx.
#
#   If found, $home/lib/profile is used,
#   else a default profile is supplied.

If you have a plan9.iso file in your $HOME directory, running 9vxi
without arguments should be enough to boot from that iso file with an
usable environment: $HOME is used as your home directory, ramdisk
provides a writable /tmp and the plumber uses glenda's rules. If you
need something fancier (for example, binding a writable source tree
from a sysfromiso repository), create a lib/profile file.



Awesome! Thanks!

I will look into it.