Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

I remember tracing entire clone process. It was hanging in a function
(don't remember which, the only one has fsync) what ensures sha key is in
fs. I bypassed it with a rare mess, so if key is there, it works, if not,
fails. In fact fsync changes introduced by Linus was in the line of
ensuring that key is there to decompress package.
Maybe I was wrong. When I'll back to port git for Harvey, I'll see.

Álvaro
El 12/10/2015 13:49, "Charles Forsyth" <charles.fors...@gmail.com> escribió:

>
> On 10 October 2015 at 19:25, Álvaro Jurado <elbingm...@gmail.com> wrote:
>
>> While checking out it looses in any moment some sha key and then fatal.
>> Other times not.
>
>
> Why do  you think that was fsync, and not something else?
>
>

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

Has sense. Thanks Charles.

Álvaro
El 12/10/2015 19:03, "Charles Forsyth" <charles.fors...@gmail.com> escribió:

>
> On 12 October 2015 at 17:49, Álvaro Jurado <elbingm...@gmail.com> wrote:
>
>> what ensures sha key is in fs.
>
>
> The reason many of us are a little sceptical about it being fsync as such
> preventing the data appearing
> is that if the git function that writes the key does a write or pwrite,
> the key will be in the file system on Plan 9: there's no need for an fsync
> just to get it there.
> In fact, in Linux there's no need for an fsync just to get it there: it
> only matters in the case of a crash.
>
> If the file system fails or you reset the machine, the intention of the
> fsync will be frustrated, but
> it shouldn't affect normal operation where no file server crash occurs.
>
> As it happens, a wstat that changes nothing can be interpreted by a file
> server to have a similar effect as fsync (see stat(5)).
>

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

Agree at all. As I said, after some time fighting with it I was bored. I
remember asking you in g+ about fsync issues when I was working on it.

In fact it fails for example, if you clone go repo and then checkout a
branch. While checking out it looses in any moment some sha key and then
fatal. Other times not.

I used an ape libs compiled with gcc and gnu toolchain port, but that means
one can use normal ape to have working. Libs are the same.

Inside, it's hellish. Full of redundant code and configure "tool" does not
make all the work. You will need to tweak adding things in conf file
generated. It uses many shell scripts and it's designed to have many
symlinks to git binary, what does you have many git clones with different
names unless you hack install part of the makefile. If it doesn't detect a
working ln, it does a cp.

I never got 2.x versions working, sha key mess was changed after 2.0.

About fsync, I'm not a fan, I wasn't blaming plan9 in anyway. It can go
jump to a lake.

Álvaro
El 10/10/2015 17:27, "erik quanstrom"  escribió:

> > It works with go get but sometimes it fails miserably retrieving packages
> > because it has an strong dependency of fsync to freeze sha keys in fs
> > during fetching. And that is just a dummy in Plan 9 ape. I used fflush
>
> i believe the problem has been misdiagnosed.  fsync can't be the issue,
> since there are no such buffers on plan 9.
>
> - erik
>
>

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

Yes, it has no sense in Plan 9, I know, thanks. I was talking about ape lib
because is what was used to port git in my case.

I even found a Rob's old mail answering a similar question saying that it's
a matter of file server (I can't remember original question). And there are
many debates around internet about fsync, with fans an detractors.

In previous versions of git, there weren't fsyncs to freeze keys, but Linus
wanted to change old git behaviour at one moment, 1.8 version I think. And
after all, problem is still there in this case, there's no way to ensure if
an fd is in the heaven of bits or in any place in fs at the moment of fopen
issue by git, breaking its behaviour over Plan 9.

Álvaro
El 07/10/2015 18:26, "Charles Forsyth" <charles.fors...@gmail.com> escribió:

>
> On 7 October 2015 at 16:17, Álvaro Jurado <elbingm...@gmail.com> wrote:
>
>> because it has an strong dependency of fsync to freeze sha keys in fs
>> during fetching. And that is just a dummy in Plan 9 ape
>
>
> fsync causes any operating system buffers in the "buffer cache" to be
> flushed to "disk" (not user-space buffers), so nothing should be needed
> with plan 9, which is why fsync is a nop in APE.
>

Re: [9fans] off topic - a good Git reference

[Álvaro Jurado]

Source should be in the same site, just add /files to hostname and look for
tgz. I think 1.5.8.3, last year version.

It was built with gcc 4.8 port for plan9 (static). You'll need some kind of
ksh to use it, git has many shell scripts.
It works with go get but sometimes it fails miserably retrieving packages
because it has an strong dependency of fsync to freeze sha keys in fs
during fetching. And that is just a dummy in Plan 9 ape. I used fflush
trying to make some tweak and disabling one sha check (it does 4 or 5) to
bypass that symptom, but finally I was bored at the end.

I still use it to go get, but it needs a deeply review and an upgrade.

Álvaro
El 07/10/2015 04:37,  escribió:

> > My new employer uses svn but is about to migrate to git so I would
> > be interested in a port, I might even get some cycles to help.
>
> I'm no help here, but one of the Harvey guys (pre-Harvey) apparently
> built git for Plan 9. Unfortunately, only the 386 binaries were made
> available, no source code. I think this may just be because the
> repository I found was not the source repository. Anyway:
>
> http://marcus.biz.tm/hg/gnubin
>
> The git binary seems to run. I'm not sure if it works.
>
> sl
>
>

Re: [9fans] Ports tree for Plan 9

[Álvaro Jurado]

 It is the Plan 9 Way (TM) to avoid  nested inclusion of header files,

$ arch/dat.h includes port/portdat.h in kernel. Exempted too?

Álvaro Jurado Cuevas
http://colmenar.biz.tm
El 30/05/2015 07:11, lu...@proxima.alt.za escribió:

  Which version?
 
  The id_t and pid_t types shall be defined as described in
  sys/types.h. in issue 6
 
  The sys/wait.h header shall define the id_t and pid_t types as
  described in sys/types.h. in issue 7
 
  in the sys/wait.h part of the headers section of base definitions

 I haven't looked at cinap's work, but...

 It is the Plan 9 Way (TM) to avoid nested inclusion of header files,
 although I guess the APE may be exempted.  I also appreciate that
 adding conditional definitions of id_t and pid_t in sys/wait.h that
 match those in sys/types.h could lead to eventual inconsistencies,
 but I would still prefer to follow the Plan 9 guidelines.

 But without a more formal code review structure and the apparent
 absence of guidance from Bell Labs, I suppose I'm just farting in the
 wind.

 Lucio.

Re: [9fans] rc: pwd in $prompt

[Álvaro Jurado]

http://www.plan9.bell-labs.com/wiki/plan9/Tip_o%27_the_day/index.html

To set your prompt in rc to reflect your current directory add this to
your profile part.

Álvaro Jurado Cuevas
colmenar.biz.tm

2015-02-26 10:59 GMT+01:00 Giacomo Tesio giac...@tesio.it:

 Hi, I'm a bit dumb, but reading rc(1) I can't grasp how I can have the
 current dir printed in prompt.

 Is it possible at all?


 Giacomo

Re: [9fans] pkg(1) and tbz2

[Álvaro Jurado]

I don't think it can work with pkg.
Note that it isn't a repo and has only 72 KB/s max uploading rate. So it
means that will be very slow and
none of that packages was set to work with pkg tool. In most cases they are
only sources.
And I think gcc bootstrap will be more complicated that a simple pkg/create.

Álvaro Jurado Cuevas

2015-02-19 12:01 GMT+01:00 Giacomo Tesio giac...@tesio.it:

 Hi, with the hope to port a (complex) tool to plan9 I've found this
 interesting repo with an updated ape + gcc + some other useful
 tools...

 http://marcus.biz.tm/files/

 I tried to set the pkgpath to that url but pkg/list only show the two
 packages named .tbz2 (lighthttp and m4).

 I noted that all files in http://9front.org/pkg/386/ are tbz.

 I'd like to know if (and how) I could install the tar.gz and tar.bz2
 packages from that repo or I have to manually download them, repackage
 as with pkg/create and then install from a local pkgpath.


 Thanks for your help!


 Giacomo

Re: [9fans] pkg(1) and tbz2

[Álvaro Jurado]

First, you need a gcc to compile gcc. There is a complete set here
https://drive.google.com/folderview?id=0B6YNt0aHfaA0am1oNGNSR3pXU1Uusp=sharing#list
(get
more recent), and a clue about configures here
http://marcus.biz.tm/files/configure.txt.
But I'm sure that 9fans list don't want any noise about this. So ask there
where you found that soft.


Álvaro Jurado Cuevas
colmenar.biz.tm

2015-02-19 12:30 GMT+01:00 Giacomo Tesio giac...@tesio.it:

 So have  I any hope to compile them?

 Giacomo

 2015-02-19 12:24 GMT+01:00 Álvaro Jurado elbingm...@gmail.com:
  I don't think it can work with pkg.
  Note that it isn't a repo and has only 72 KB/s max uploading rate. So
 it
  means that will be very slow and
  none of that packages was set to work with pkg tool. In most cases they
 are
  only sources.
  And I think gcc bootstrap will be more complicated that a simple
 pkg/create.
 
  Álvaro Jurado Cuevas
 
  2015-02-19 12:01 GMT+01:00 Giacomo Tesio giac...@tesio.it:
 
  Hi, with the hope to port a (complex) tool to plan9 I've found this
  interesting repo with an updated ape + gcc + some other useful
  tools...
 
  http://marcus.biz.tm/files/
 
  I tried to set the pkgpath to that url but pkg/list only show the two
  packages named .tbz2 (lighthttp and m4).
 
  I noted that all files in http://9front.org/pkg/386/ are tbz.
 
  I'd like to know if (and how) I could install the tar.gz and tar.bz2
  packages from that repo or I have to manually download them, repackage
  as with pkg/create and then install from a local pkgpath.
 
 
  Thanks for your help!
 
 
  Giacomo
 
 

Re: [9fans] C question on struct Biobuf in bio.h

[Álvaro Jurado]

I'm using gcc to compile plan9 code from some time (4.7/4.8) and that
option are masking real behaviour. Do not warns or put out an error about
anonymous structs, but you will have a conflict if to structs in the same
source are including a, for example, Lock; element, and ld could not
assign right the values if declarations are not specified ansi style
(variable initialization it's made by ld, not by the compiler): you will
get some dragons in some cases.
Look at LP49 source code and you will see that authors used your second way.

Álvaro Jurado Cuevas
colmenar.biz.tm

2014-10-07 17:58 GMT+02:00 Carsten Kunze carsten.ku...@arcor.de:

  Otherwise, your change is fine, but hdr would probably be
  a better name than Biobufhdr. Also, don't forget to update
  your code to use b-hdr.fid instead of b-fid, and so on.

 Thanks for all answers!

 (They also helped to find a short documentation in /sys/doc/compiler)

Carsten