[9fans] corrections to /sys/src/cmd/8l/l.h

[9fans] corrections to /sys/src/cmd/8l/l.h

[lucio]

At the tail end of the module there is a shorter set of "#pragma
varargck"s that repeats the entries earlier in the file, disagreeing
with one of them.  The disagreeing entry matches the #pragma in
/sys/src/cmd/vl/l.h so I'm not sure which ought to be used (or what
effect the conflict has).

I'd like to see these corrected; there are other differences that seem
gratuitous, I won't mind tidying the whole lot up if it's deemed worth
it.

I have 8[acl] and v[acl] compiling error free on p9p (UBUNTU
Jaunty/386 and gNewSense/MIPS respectively) although I'm not sure
where I'm going with it, I have some vague idea of cross-development,
but I can't grasp the full multidimensionality of the exercise and I
fall asleep whenever I try to figure it out :-(

++L

PS: ELF output and other such issues is also on my list of things to
check out, but it adds even more complexity to something that really
confuses me already.

Re: [9fans] corrections to /sys/src/cmd/8l/l.h

[sqweek]

2009/9/30  <lucio@proxima.alt.za>:
> PS: ELF output and other such issues is also on my list of things to
> check out, but it adds even more complexity to something that really
> confuses me already.

http://gsoc.cat-v.org/projects/kencc/

[9fans] kencc, inferno hg, v9fs is big?, porting

[Sam Watkins]

On Thu, Oct 01, 2009 at 06:22:28PM +0800, sqweek wrote:
> http://gsoc.cat-v.org/projects/kencc/

Looks good, I can't seem to find how to download that, is there anonymous hg
access or a tarball at all?

Speaking of hg - I think we should patch it to support empty directories so
that the inferno checkout actually builds.  Or else commit some hidden file in
those directories?

I tried to check out v9fs, but the compressed git repo without checkout is over
300Mb.  The checkout was going to be more than that, but it failed due to my
server running out of disk space.  Why is that project, a filesystem, larger
than the entire linux kernel and several times larger than all of plan 9?
Or am I missing something here?

I want to port some of my programs to plan 9 soon. I'll read some of the plan 9
source, hopefully I can improve my C coding so that my programs don't look like
broken bricks among jewels.

thanks,

Sam

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[Abhishek Kulkarni]

On Thu, Oct 1, 2009 at 9:23 AM, Sam Watkins <sam@nipl.net> wrote:
> On Thu, Oct 01, 2009 at 06:22:28PM +0800, sqweek wrote:
>> http://gsoc.cat-v.org/projects/kencc/
>
> Looks good, I can't seem to find how to download that, is there anonymous hg
> access or a tarball at all?
>

http://gsoc.cat-v.org/hg/kenc

> Speaking of hg - I think we should patch it to support empty directories so
> that the inferno checkout actually builds.  Or else commit some hidden file in
> those directories?
>
> I tried to check out v9fs, but the compressed git repo without checkout is over
> 300Mb.  The checkout was going to be more than that, but it failed due to my
> server running out of disk space.  Why is that project, a filesystem, larger
> than the entire linux kernel and several times larger than all of plan 9?
> Or am I missing something here?
>

What you are checking out is a branch of the linux kernel
tagged v9fs and not just the 9p modules in themselves.
To download the standalone download v9fs modules,
http://github.com/ericvh/9p-sac
is probably what you want.
The linux kernel git branches are getting huge in size wtih
all the associated history.

> I want to port some of my programs to plan 9 soon. I'll read some of the plan 9
> source, hopefully I can improve my C coding so that my programs don't look like
> broken bricks among jewels.
>
> thanks,
>
> Sam
>
>

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[C H Forsyth]

>Or else commit some hidden file in those directories?

there isn't a `hidden file' in either Plan 9 or Inferno.

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[Russ Cox]

On Thu, Oct 1, 2009 at 10:09 AM, C H Forsyth <forsyth@vitanuova.com> wrote:
> there isn't a `hidden file' in either Plan 9 or Inferno.

maybe there are lots of hidden files and we just can't see them.

russ

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[jrm8005]

> On Thu, Oct 1, 2009 at 10:09 AM, C H Forsyth <forsyth@vitanuova.com> wrote:
>> there isn't a `hidden file' in either Plan 9 or Inferno.
>
> maybe there are lots of hidden files and we just can't see them.

I saw an article a while back about how to use dd to hide files
outside the realm of where the fs (I think ext3 was the subject) could
see them, and making sure to protect them from being reaped by an
fsck.  Probably not enough to discourage the FBI, but more than enough
to deter the average geek-squad-level snooper.

>
> russ

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[ron minnich]

On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins <sam@nipl.net> wrote:

> I tried to check out v9fs, but the compressed git repo without checkout is over
> 300Mb.

That's git for you. When you go to git it, you git ALL of it. Kind of
like deciding to download sources and getting the entire venti arena.

ron

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[David Leimbach]

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

On Thu, Oct 1, 2009 at 11:19 AM, ron minnich <rminnich@gmail.com> wrote:

> On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins <sam@nipl.net> wrote:
>
> > I tried to check out v9fs, but the compressed git repo without checkout
> is over
> > 300Mb.
>
> That's git for you. When you go to git it, you git ALL of it. Kind of
> like deciding to download sources and getting the entire venti arena.
>
> ron
>
> Wouldn't Mercurial do the same?  Darcs (a haskell source control system)
let's you get a subset of all the history, and if a patch refers to a really
old revision you don't have, will go get that and its dependencies.  It's
like a lazy-repository.  At least I think that's how it works, or that's how
it's been explained to me.
Is there a way to git a partial repository or hg a partial repository?

Dave

[-- Attachment #2: Type: text/html, Size: 1221 bytes --]

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[David Leimbach]

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

On Thu, Oct 1, 2009 at 11:23 AM, David Leimbach <leimy2k@gmail.com> wrote:

>
>
> On Thu, Oct 1, 2009 at 11:19 AM, ron minnich <rminnich@gmail.com> wrote:
>
>> On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins <sam@nipl.net> wrote:
>>
>> > I tried to check out v9fs, but the compressed git repo without checkout
>> is over
>> > 300Mb.
>>
>> That's git for you. When you go to git it, you git ALL of it. Kind of
>> like deciding to download sources and getting the entire venti arena.
>>
>> ron
>>
>> Wouldn't Mercurial do the same?  Darcs (a haskell source control system)
> let's you get a subset of all the history, and if a patch refers to a really
> old revision you don't have, will go get that and its dependencies.  It's
> like a lazy-repository.  At least I think that's how it works, or that's how
> it's been explained to me.
> Is there a way to git a partial repository or hg a partial repository?
>
> Dave
>


"Darcs 2 replaces the concept of "partial" repositories with "lazy" ones.
There has always been a desire to allow "lightweight" checkouts that don't
include the complete repo history. The darcs 1 solution to this was
"partial" repositories that only checked out history up to a point. This
approach worked to some extent, but didn't play with well with darcs
commands that expected the whole history to be present. The new "lazy"
concept offers similar benefits, and will pull down older remote patches on
demand if some command needs them. Lazy repositories are a great comprise
between features and performance."

There we go.  So I guess you just need Darcs2.

Dave

[-- Attachment #2: Type: text/html, Size: 3113 bytes --]

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[Eric Van Hensbergen]

Actually, you can specify a depth argument and only get the most
recent revision (and/or some number of revisions back) -- it does not,
however, allow you to only grab a subdirectory (that I'm aware of) --
which is why we package 9p-sac in a separate repo.

      -eric

On Oct 1, 2009, at 1:19 PM, ron minnich wrote:

> On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins <sam@nipl.net> wrote:
>
>> I tried to check out v9fs, but the compressed git repo without
>> checkout is over
>> 300Mb.
>
> That's git for you. When you go to git it, you git ALL of it. Kind of
> like deciding to download sources and getting the entire venti arena.
>
> ron
>

Re: [9fans] kencc, inferno hg, v9fs is big?, porting

[Vinu Rajashekhar]

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

>From git FAQ - http://git.or.cz/gitwiki/GitFaq#HowdoIcloneasubdirectory.3F

On Thu, Oct 1, 2009 at 11:56 PM, Eric Van Hensbergen <ericvh@gmail.com>wrote:

> Actually, you can specify a depth argument and only get the most recent
> revision (and/or some number of revisions back) -- it does not, however,
> allow you to only grab a subdirectory (that I'm aware of) -- which is why we
> package 9p-sac in a separate repo.
>
>     -eric
>
>
> On Oct 1, 2009, at 1:19 PM, ron minnich wrote:
>
>  On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins <sam@nipl.net> wrote:
>>
>>  I tried to check out v9fs, but the compressed git repo without checkout
>>> is over
>>> 300Mb.
>>>
>>
>> That's git for you. When you go to git it, you git ALL of it. Kind of
>> like deciding to download sources and getting the entire venti arena.
>>
>> ron
>>
>>
>
>


--
Vinu Rajashekhar,
5th Year Dual Degree Student,
Deptt of Computer Science & Engg,
IIT Kharagpur,
India.

[-- Attachment #2: Type: text/html, Size: 1779 bytes --]

[9fans] inferno from hg does not build out of the box

[Sam Watkins]

On Thu, Oct 01, 2009 at 11:23:24PM +1000, Sam Watkins wrote:
> Speaking of hg - I think we should patch it to support empty directories so
> that the inferno checkout actually builds.

It's a bit sad when a modern OS (inferno) from one of the best labs in the
world does not build (from hg), due to a error that could be avoided with a
tiny patch.  You are losing new users because of this (or aggrevating them).
Why not commit the list of empty directories and add mkdir -p `<empty-dirs`
to makemk.sh or something like that?  It's a 1 minute fix, and could be removed
if anyone fixes hg.  Also there is a standard utility "uname" which could be
used to write a short configure script (for unix; "" would mean plan 9!).
I'm happy to do this if someone is willing to review and commit it.

Sam

Re: [9fans] inferno from hg does not build out of the box

[roger peppe]

2009/10/2 Sam Watkins <sam@nipl.net>:
> could be removed if anyone fixes hg.

from the way the mercurial guys go on about it,
it sounds like the fix might not be trivial.
it does seem like a ridiculous thing, but it
seems to be something of a religious issue with them.

hg doesn't do permissions (other than execute) either AFAIK.

it's no substitute for tar.

Re: [9fans] inferno from hg does not build out of the box

[C H Forsyth]

>it does seem like a ridiculous thing, but it
>seems to be something of a religious issue with them.

that was my impression. we aren't the only ones to find
the restriction irksome, by any means. to avoid this
intransigence spreading, i should say that we'll compensate
for it somehow. i agree with the sentiment of the original
message; i just wasn't sure of the best way to do that.

Re: [9fans] inferno from hg does not build out of the box

[David Leimbach]

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

On Fri, Oct 2, 2009 at 1:44 AM, roger peppe <rogpeppe@gmail.com> wrote:

> 2009/10/2 Sam Watkins <sam@nipl.net>:
> > could be removed if anyone fixes hg.
>
> from the way the mercurial guys go on about it,
> it sounds like the fix might not be trivial.
> it does seem like a ridiculous thing, but it
> seems to be something of a religious issue with them.
>
> hg doesn't do permissions (other than execute) either AFAIK.
>
> it's no substitute for tar.
>
>
Wait, Hg can't deal with a directory with a file like ".keepme" and keep the
directory!?!  That's pretty silly.  Or do the directories have to be 100%
empty for this to work?

[-- Attachment #2: Type: text/html, Size: 1005 bytes --]

Re: [9fans] inferno from hg does not build out of the box

[Tim Newsham]

> It's a bit sad when a modern OS (inferno) from one of the best labs in the
> world does not build (from hg), due to a error that could be avoided with a
> tiny patch.  You are losing new users because of this (or aggrevating them).
> Why not commit the list of empty directories and add mkdir -p `<empty-dirs`
> to makemk.sh or something like that?  It's a 1 minute fix, and could be removed
> if anyone fixes hg.  Also there is a standard utility "uname" which could be
> used to write a short configure script (for unix; "" would mean plan 9!).
> I'm happy to do this if someone is willing to review and commit it.

committing a ".emptydir" file in each directory would be easier.

> Sam

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] inferno from hg does not build out of the box

[Charles Forsyth]

>committing a ".emptydir" file in each directory would be easier.

why bother making it .emptydir (ie, with the dot) when that makes it
invisible on broken host systems (with the ls bug) but visible under inferno itself.
more important, and the reason i didn't do that,
if it's visible under inferno itself, it breaks the point of some of
those directories being there, and empty: you're supposed to be able to enumerate
services by listing names subsequently bound to them.

Re: [9fans] inferno from hg does not build out of the box

[Eric Van Hensbergen]

On Oct 2, 2009, at 1:31 PM, Charles Forsyth wrote:

>> committing a ".emptydir" file in each directory would be easier.
>
> why bother making it .emptydir (ie, with the dot) when that makes it
> invisible on broken host systems (with the ls bug) but visible under
> inferno itself.
> more important, and the reason i didn't do that,
> if it's visible under inferno itself, it breaks the point of some of
> those directories being there, and empty: you're supposed to be able
> to enumerate
> services by listing names subsequently bound to them.
>

Perhaps a rule in the mkfile which would check/create empty directories?
Certainly makes sense for <arch>/lib and whatnot, less certain it
makes perfect
sense for other common empty directories.

        -eric

Re: [9fans] inferno from hg does not build out of the box

[Charles Forsyth]

>Perhaps a rule in the mkfile which would check/create empty directories?

perhaps. there are several alternatives, and no doubt i'll switch
to use a mix as appropriate. the annoying thing is that
previously, whether through tar, replica, or even subversion, a suitable
skeleton would appear without having yet more procedures to know and to document.
now some poxy but popular `control system' has to have its say.

Re: [9fans] inferno from hg does not build out of the box

[Sam Watkins]

Let's fix this now.  Here is a one-line fix, which is simpler and cleaner than
a multi-empty-file commit.  My old fix mkdir -p `<lib/emptydirs` is a bashism I
think, I've reworded it:

  xargs mkdir -p <lib/emptydirs

That will suffice to fix the problem for unix users at least.  xargs might not
be present, we can do it with only the shell; this might be best:

  while read d; do mkdir -p $d; done <lib/emptydirs

Could you please add this fix to makemk.sh?  I put it at the end of the
following stanza which seems appropriate (patch below).

# make sure we start off clean
echo removing old libraries and binaries
rm -f $PLAT/lib/*.a $PLAT/bin/*
rm -f utils/cc/y.tab.?
while read d; do mkdir -p $d; done <lib/emptydirs

A general fix for hg/git/etc would be to keep a list of all directories in the
RCS as a file .hg-dirs or .hg/dirs (but forbidden), and a post-update to
create/remove them as needed.

Is it best to talk about inferno on 9fans or should I use/Cc inferno-list?

thanks,

Sam


--- makemk.sh.orig      2009-10-04 00:55:37.000000000 +1000
+++ makemk.sh   2009-10-04 00:56:10.000000000 +1000
@@ -42,6 +42,7 @@
 echo removing old libraries and binaries
 rm -f $PLAT/lib/*.a $PLAT/bin/*
 rm -f utils/cc/y.tab.?
+while read d; do mkdir -p $d; done <lib/emptydirs

 # libregexp
 cd $ROOT/utils/libregexp || error cannot find libregexp directory

Re: [9fans] corrections to /sys/src/cmd/8l/l.h

[erik quanstrom]

On Wed Sep 30 00:30:19 EDT 2009, lucio@proxima.alt.za wrote:
> At the tail end of the module there is a shorter set of "#pragma
> varargck"s that repeats the entries earlier in the file, disagreeing
> with one of them.  The disagreeing entry matches the #pragma in
> /sys/src/cmd/vl/l.h so I'm not sure which ought to be used (or what
> effect the conflict has).
>

it's okay to have varargchk type's specify different types for the same
format letter, as long as each is valid.  for example, since uintptr and
void* are both valid arguments for #p, libc properly declares both okay.
in your case uint and int are both declared okay.  and it looks good
to me as the argument is used an index into a name array.  in fact,
due to c type promotion rules, one could also declare char, uchar,
short, ushort to be acceptable.  though evidently that's not needed.

duplicate entries should probablly deleted.  while you're at it, add
#pragma	varargck	argpos	diag		1

you will then be magicly informed of a few vararg botches.

- erik