[9fans] ken cc for linux

[9fans] ken cc for linux

[Aharon Robbins]

Thanks for the link to the Google code repo.

I'm currently on x86_64 Ubuntu 12.04. Building was not so smooth, several
files are missing for the Power 64 port.

I did as best I could to build things.  I suppose my expectations aren't
what they should be. I was looking for the usual

	configure && make && make install

experience, and it wasn't there. I like to compile gawk with multiple
compilers and thought I'd try ken's, but it wasn't clear to me which
o.out file to use, or how to install it such that it will get the
system's include files and libraries.

If this is easy to do, I'd appreciate hearing how. If not, then I'm not
going to worry about it. :-)

Much thanks,

Arnold

Re: [9fans] ken cc for linux

[Aram Hăvărneanu]

It doesn't come with a suitable libc that you expect.

-- 
Aram Hăvărneanu

Re: [9fans] ken cc for linux

[Ryan Gonzalez]

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

Warning: this will get messy *fast*.

On Wed, Mar 11, 2015 at 3:30 PM, Aharon Robbins <arnold@skeeve.com> wrote:

> Thanks for the link to the Google code repo.
>
> I'm currently on x86_64 Ubuntu 12.04. Building was not so smooth, several
> files are missing for the Power 64 port.
>

Yup. Comment out the lines in the mkfiles. In src/cmd/mkfile, I commented
out lines 34-36.

I think you already need mk installed; you can grab it from here
<http://swtch.com/plan9port/unix/mk-with-libs.tgz>.


>
> I did as best I could to build things.  I suppose my expectations aren't
> what they should be. I was looking for the usual
>
>         configure && make && make install
>
> experience, and it wasn't there. I like to compile gawk with multiple
> compilers and thought I'd try ken's, but it wasn't clear to me which
> o.out file to use, or how to install it such that it will get the
> system's include files and libraries.
>
>
I doubt the Plan 9 compilers will even get *close* to building gawk.

See, the compilers implement a variant of ANSI C with some C99-ish
extensions. For once, the preprocessor does not work with #if's. You can
only use #ifdef's.

Because of this, 99% of the C standard library headers will NOT work with
the compilers.

Another issue is that it seems that the linker does not read ELF files, so
linking with about anything is out of the question.

As for the compilers you need to invoke...

The directories in src/cmd are formatting like *n*c, *n*a, and *n*l, where
the *c ones are the compiles, *a, the assemblers, and *l, the linkers.

The executable is at src/cmd/<dir>/o.out. For Ubuntu 64-bit, you'll want
src/cmd/6c/o.out to compile and src/cmd/6l/o.out to link. Or, at least you
would...if the files weren't missing. Since half of them are, you'll
instead want src/cmd/8c/o.out to compile and src/cmd/8l/o.out to link.
Those are the 32-bit compilers.

I set up symlinks in ken-cc/bin using bin/8c as an alias for
src/cmd/8c/o.out. Same thing for 8l.

The command lines look something like:

8c tst.c # outputs tst.8
8l -o tst tst.8 # outputs tst

Bottom line: you may be out of luck if you want to use ken-cc as a
general-purpose C compiler. It isn't. At all.

It's fun to toy with, though.

Go had vastly better versions, but it seems they got ripped out recently. I
think Go 1.3 may have had them, in which case you'd do something like:

go tool 6c tst.c
go tool 6l -o tst tst.6

As you can see, Go actually had a working 64-bit compiler.

I have yet to figure out why the hell symlinks to the compilers never get
set up in the bin directory.


> If this is easy to do, I'd appreciate hearing how. If not, then I'm not
> going to worry about it. :-)
>
> Much thanks,
>
> Arnold
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

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

Re: [9fans] ken cc for linux

[Quintile]

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


awl compiles under APE with a little work. someone, sorry I have forgotten who, did Stirling work a few years ago and got many Linux tools ported - to support 3rd party stuff. to my chagrin I never managed to get avn to work on top of this.

the code was in Google code I think, his porting instructions should work for the latest gawk too.

if not put the code somewhere and I will have a go.

-Steve





> On 11 Mar 2015, at 21:04, Ryan Gonzalez <rymg19@gmail.com> wrote:
> 
> Warning: this will get messy *fast*.
> 
>> On Wed, Mar 11, 2015 at 3:30 PM, Aharon Robbins <arnold@skeeve.com> wrote:
>> Thanks for the link to the Google code repo.
>> 
>> I'm currently on x86_64 Ubuntu 12.04. Building was not so smooth, several
>> files are missing for the Power 64 port.
> 
> Yup. Comment out the lines in the mkfiles. In src/cmd/mkfile, I commented out lines 34-36.
> 
> I think you already need mk installed; you can grab it from here.
>  
>> 
>> I did as best I could to build things.  I suppose my expectations aren't
>> what they should be. I was looking for the usual
>> 
>>         configure && make && make install
>> 
>> experience, and it wasn't there. I like to compile gawk with multiple
>> compilers and thought I'd try ken's, but it wasn't clear to me which
>> o.out file to use, or how to install it such that it will get the
>> system's include files and libraries.
>> 
> 
> I doubt the Plan 9 compilers will even get *close* to building gawk.
> 
> See, the compilers implement a variant of ANSI C with some C99-ish extensions. For once, the preprocessor does not work with #if's. You can only use #ifdef's.
> 
> Because of this, 99% of the C standard library headers will NOT work with the compilers.
> 
> Another issue is that it seems that the linker does not read ELF files, so linking with about anything is out of the question.
> 
> As for the compilers you need to invoke...
> 
> The directories in src/cmd are formatting like nc, na, and nl, where the *c ones are the compiles, *a, the assemblers, and *l, the linkers.
> 
> The executable is at src/cmd/<dir>/o.out. For Ubuntu 64-bit, you'll want src/cmd/6c/o.out to compile and src/cmd/6l/o.out to link. Or, at least you would...if the files weren't missing. Since half of them are, you'll instead want src/cmd/8c/o.out to compile and src/cmd/8l/o.out to link. Those are the 32-bit compilers.
> 
> I set up symlinks in ken-cc/bin using bin/8c as an alias for src/cmd/8c/o.out. Same thing for 8l.
> 
> The command lines look something like:
> 
> 8c tst.c # outputs tst.8
> 8l -o tst tst.8 # outputs tst
> 
> Bottom line: you may be out of luck if you want to use ken-cc as a general-purpose C compiler. It isn't. At all.
> 
> It's fun to toy with, though.
> 
> Go had vastly better versions, but it seems they got ripped out recently. I think Go 1.3 may have had them, in which case you'd do something like:
> 
> go tool 6c tst.c
> go tool 6l -o tst tst.6
> 
> As you can see, Go actually had a working 64-bit compiler.
> 
> I have yet to figure out why the hell symlinks to the compilers never get set up in the bin directory.
>  
>> If this is easy to do, I'd appreciate hearing how. If not, then I'm not
>> going to worry about it. :-)
>> 
>> Much thanks,
>> 
>> Arnold
>> 
> 
> 
> 
> -- 
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.
> http://kirbyfan64.github.io/ 

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

Re: [9fans] ken cc for linux

[Ryan Gonzalez]

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

That's ape with ape/pcc, which is ANSI-compliant, not a port of the
non-compliant base compilers (6c, 8c, etc.).

On Wed, Mar 11, 2015 at 4:54 PM, Quintile <steve@quintile.net> wrote:

>
> awl compiles under APE with a little work. someone, sorry I have forgotten
> who, did Stirling work a few years ago and got many Linux tools ported - to
> support 3rd party stuff. to my chagrin I never managed to get avn to work
> on top of this.
>
> the code was in Google code I think, his porting instructions should work
> for the latest gawk too.
>
> if not put the code somewhere and I will have a go.
>
> -Steve
>
>
>
>
>
> On 11 Mar 2015, at 21:04, Ryan Gonzalez <rymg19@gmail.com> wrote:
>
> Warning: this will get messy *fast*.
>
> On Wed, Mar 11, 2015 at 3:30 PM, Aharon Robbins <arnold@skeeve.com> wrote:
>
>> Thanks for the link to the Google code repo.
>>
>> I'm currently on x86_64 Ubuntu 12.04. Building was not so smooth, several
>> files are missing for the Power 64 port.
>>
>
> Yup. Comment out the lines in the mkfiles. In src/cmd/mkfile, I commented
> out lines 34-36.
>
> I think you already need mk installed; you can grab it from here
> <http://swtch.com/plan9port/unix/mk-with-libs.tgz>.
>
>
>>
>> I did as best I could to build things.  I suppose my expectations aren't
>> what they should be. I was looking for the usual
>>
>>         configure && make && make install
>>
>> experience, and it wasn't there. I like to compile gawk with multiple
>> compilers and thought I'd try ken's, but it wasn't clear to me which
>> o.out file to use, or how to install it such that it will get the
>> system's include files and libraries.
>>
>>
> I doubt the Plan 9 compilers will even get *close* to building gawk.
>
> See, the compilers implement a variant of ANSI C with some C99-ish
> extensions. For once, the preprocessor does not work with #if's. You can
> only use #ifdef's.
>
> Because of this, 99% of the C standard library headers will NOT work with
> the compilers.
>
> Another issue is that it seems that the linker does not read ELF files, so
> linking with about anything is out of the question.
>
> As for the compilers you need to invoke...
>
> The directories in src/cmd are formatting like *n*c, *n*a, and *n*l,
> where the *c ones are the compiles, *a, the assemblers, and *l, the linkers.
>
> The executable is at src/cmd/<dir>/o.out. For Ubuntu 64-bit, you'll want
> src/cmd/6c/o.out to compile and src/cmd/6l/o.out to link. Or, at least you
> would...if the files weren't missing. Since half of them are, you'll
> instead want src/cmd/8c/o.out to compile and src/cmd/8l/o.out to link.
> Those are the 32-bit compilers.
>
> I set up symlinks in ken-cc/bin using bin/8c as an alias for
> src/cmd/8c/o.out. Same thing for 8l.
>
> The command lines look something like:
>
> 8c tst.c # outputs tst.8
> 8l -o tst tst.8 # outputs tst
>
> Bottom line: you may be out of luck if you want to use ken-cc as a
> general-purpose C compiler. It isn't. At all.
>
> It's fun to toy with, though.
>
> Go had vastly better versions, but it seems they got ripped out recently.
> I think Go 1.3 may have had them, in which case you'd do something like:
>
> go tool 6c tst.c
> go tool 6l -o tst tst.6
>
> As you can see, Go actually had a working 64-bit compiler.
>
> I have yet to figure out why the hell symlinks to the compilers never get
> set up in the bin directory.
>
>
>> If this is easy to do, I'd appreciate hearing how. If not, then I'm not
>> going to worry about it. :-)
>>
>> Much thanks,
>>
>> Arnold
>>
>>
>
>
> --
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
>
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

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

Re: [9fans] ken cc for linux

[Steve Simon]

> That's ape with ape/pcc, which is ANSI-compliant, not a port of the
> non-compliant base compilers (6c, 8c, etc.).

This is true, however  pcc is just a driver that runs cpp and
pipes its output to 8c (assuming you are on a 386).

	hugo% cd /sys/src/ape/cmd
	hugo%
	hugo% pcc -v -c -D_POSIX_SOURCE kill.c
	cpp -D__STDC__=1 -N -D_POSIX_SOURCE -I/386/include/ape -I/sys/include/ape kill.c | 8c -o kill.8

Gawk has been compiled with APE, I was mearly suggesting it might
be helpful to Aharon if this was repeated to confirm the continued
portability of the gawk code.

-Steve

Re: [9fans] ken cc for linux

[arnold]

Hi All.

Thanks for the clarifications about ken's compiler. I don't know that
I'll bother going to the go dist right now.

> Gawk has been compiled with APE, I was mearly suggesting it might
> be helpful to Aharon if this was repeated to confirm the continued
> portability of the gawk code.

I appreciate and accept your offer. To get the current code:

	git clone http://git.savannah.gnu.org/r/gawk.git
	cd gawk
	git checkout gawk-4.1-stable
	./bootstrap.sh && ./configure && make && make check

If you can't get to git from APE, then on Linux do the above and add

	make dist

to create tarballs.

The bootstrap.sh file merely sets timestamps. No autotools required! :-)

Steve, feel free to continue the discussion with me off list, but
please change the subject line so that your mail won't get squirrelled
off into the 9fans mailbox by accident.

Thanks!

Arnold

Re: [9fans] ken cc for linux

[erik quanstrom]

> the code was in Google code I think, his porting instructions should work for the latest gawk too.

was, as in google code is dead.

- erik

Re: [9fans] ken cc for linux

[Charles Forsyth]

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

On 13 March 2015 at 01:31, erik quanstrom <quanstro@quanstro.net> wrote:

> was, as in google code is dead.


It's a good example of how the cloudy future is seriously unsettled by
services suddenly vanishing,
even from big suppliers. Also, I rather trust the Google storage
infrastructure, but I'm not sure about the other two.

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

Re: [9fans] ken cc for linux

[Ryan Gonzalez]

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

I prefer GitHub. Much nicer, easier to use, has a PR system (no patches!),
etc.

The website also works better on mobile devices. Google Code's source
browser doesn't work on my phone.

I wouldn't say it suddenly vanished, though. A quick search shows some were
predicting this would happen. Lots of major projects have moved to GitHub
or Bitbucket.

On Fri, Mar 13, 2015 at 8:24 AM, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 13 March 2015 at 01:31, erik quanstrom <quanstro@quanstro.net> wrote:
>
>> was, as in google code is dead.
>
>
> It's a good example of how the cloudy future is seriously unsettled by
> services suddenly vanishing,
> even from big suppliers. Also, I rather trust the Google storage
> infrastructure, but I'm not sure about the other two.
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

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

Re: [9fans] ken cc for linux

[Kurt H Maier]

Quoting Ryan Gonzalez <rymg19@gmail.com>:

> I wouldn't say it suddenly vanished, though. A quick search shows some were
> predicting this would happen. Lots of major projects have moved to GitHub
> or Bitbucket.

It was obvious it was dying when every google project started unassing the
site last year.  Google is huge on shoving their devs' faces into their
corporate dogfood; any time a google project abandons a google product you
can bet it's going to be taken out back and drowned in short order.

It's still a pain in the ass, regardless of how much notice they give, but
the really hilarious part was watching all of the googlers pretend they just
suddenly decided their projects would be better off at github.

khm

Re: [9fans] ken cc for linux

[Jeff Sickel]

> On Mar 13, 2015, at 1:19 PM, Kurt H Maier <khm@sciops.net> wrote:
> 
> github


One of these days I’ll get back to finishing the hg-git module for Plan 9.
I wish it weren’t required, but as the world has moved to git either git
needs to run on Plan 9 or we get the hg-git plugin working and a stub to
let go use it when you want to do `{go get github.com/some/big/repo}.

Alas, having git on Plan 9 may not be all that useful for me as git is
the first revision control tool I’ve used where the commands and overall
structure begs for a GUI to make sense of it all.  I guess that’s what all
the web interfaces and forks are for…

-jas

[9fans] using git

[arnold]

Changed the subject line.

Jeff Sickel <jas@corpus-callosum.com> wrote:

> Alas, having git on Plan 9 may not be all that useful for me as git is
> the first revision control tool I’ve used where the commands and overall
> structure begs for a GUI to make sense of it all.  I guess that’s what all
> the web interfaces and forks are for…

I beg to differ. I've been using it for 4+ years now. I can't stand
the git GUI (at least the one on windows).  There is definitely some
learning curve and mindset change, but day-to-day use involves only
a handful of commands.

The O'Reilly book on Git is a reasonable way to learn it.

I haven't used hg or bzr, but compared to svn and cvs, git is light
years ahead.  This is also true of some of the commercial variants
such as Perforce and TFS.

I know some real git fanatics. I'm not one, but I am a "fan". :-)

I'll be happy to continue a discussion with you offline, if you wish.

Thanks,

Arnold

Re: [9fans] using git

[Stanley Lieber]

> I'll be happy to continue a
> discussion with you offline, if you
> wish.

are you asking him to take it outside

Re: [9fans] using git

[Charles Forsyth]

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

On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:

> There is definitely some
> learning curve and mindset change
>

Just what I want from a little servant that's supposed to help me manage
some file changes.

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

Re: [9fans] using git

[Charles Forsyth]

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

Anyway, I moved all my Google Code stuff to mercurial at Bitbucket.
I find both the command and web interfaces less annoying and less
error-prone.

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

Re: [9fans] using git

[Federico Benavento]

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

Same here, https://bitbucket.org/fgb/mac9p <https://bitbucket.org/fgb/mac9p>

—
Federico Benavento
benavento@gmail.com



> On Mar 19, 2015, at 1:36 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> Anyway, I moved all my Google Code stuff to mercurial at Bitbucket.
> I find both the command and web interfaces less annoying and less error-prone.
> 



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

Re: [9fans] using git

[Jeff Sickel]

Any chance of getting mac9p codesigned and usable on 10.10?

-jas

> On Mar 19, 2015, at 11:39 AM, Federico Benavento <benavento@gmail.com> wrote:
> 
> Same here, https://bitbucket.org/fgb/mac9p
> 
> —
> Federico Benavento
> benavento@gmail.com
> 
> 
> 
>> On Mar 19, 2015, at 1:36 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> 
>> Anyway, I moved all my Google Code stuff to mercurial at Bitbucket.
>> I find both the command and web interfaces less annoying and less error-prone.
>> 
> 
> 

Re: [9fans] using git

[Skip Tavakkolian]

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

a 9fan/git-fan should volunteer to take one for the team,  learn git
thoroughly, then hide it behind an fs layer. we will revere such a person,
and nominate him/her for sainthood.

On Thu, Mar 19, 2015 at 9:35 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
>
>> There is definitely some
>> learning curve and mindset change
>>
>
> Just what I want from a little servant that's supposed to help me manage
> some file changes.
>

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

Re: [9fans] using git

[Jeff Sickel]

You can pick up a Cheesehead hat in Wisconsin, or online…
Some groups I’ve worked with would pass the Cheesehead hat to the person
who checked something in that broke the nightly build.  I’m not saying
being sainted by the 9fans community wouldn’t be an honor, but the
recipient might get something more along the lines of a cheesehead hat.


Until then, you can install hg-git for your python2.7 environment on Plan 9:

mkdir -p $home/lib/python2.7/site-packages/docs
bind -bc $home/lib/python2.7/site-packages /$cputype/lib/python2.7/site-packages
bind -bc $home/lib/python2.7/site-packages /sys/lib/python2.7/site-packages 

Grab dulwich (https://pypi.python.org/pypi/dulwich), I pulled the latest master
from github:

% unzip -f dulwich-master.zip
% cd dulwich

To accommodate a strange import error not setting has_mmap correctly, patch
dulwich/pack.py (this is from my hg clone version after installing):

% hg diff -g dulwich/pack.py
diff --git a/dulwich/pack.py b/dulwich/pack.py
--- a/dulwich/pack.py
+++ b/dulwich/pack.py
@@ -59,6 +59,10 @@
     SEEK_CUR,
     SEEK_END,
     )
+# For some reason the above try, except fails to set has_mmap = False
+if os.uname()[0] == 'Plan9':
+    has_mmap = False
+
 import struct
 from struct import unpack_from
 import zlib


Install dulwich:

% python setup.py --pure install


Grab and install hg-git:

% hg clone https://bitbucket.org/durin42/hg-git
% cd hg-git
% python setup.py install


Add ‘hggit =‘ to your $home/lib/hgrc [extensions].

Test it out:

% hg clone git://github.com/schacon/hg-git.git


It isn’t exactly fast, and there are some cases where cloning using https:// instead
of git:// can be an issue, but it works as a brace|cudgel|kludge until a cleaned up
git is made available for Plan 9.

Now to finish a little transmogrifier git script to trick go get...

-jas



> On Mar 19, 2015, at 1:03 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> 
> a 9fan/git-fan should volunteer to take one for the team,  learn git thoroughly, then hide it behind an fs layer. we will revere such a person, and nominate him/her for sainthood.
> 
> On Thu, Mar 19, 2015 at 9:35 AM Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
> There is definitely some
> learning curve and mindset change
> 
> Just what I want from a little servant that's supposed to help me manage some file changes.

Re: [9fans] using git

[Skip Tavakkolian]

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

cool!

just to formalize the 9fans steps of canonization, i think it goes
something like this:
servant of 9fans → loathed → cursed → saint



On Thu, Mar 19, 2015 at 1:31 PM Jeff Sickel <jas@corpus-callosum.com> wrote:

> You can pick up a Cheesehead hat in Wisconsin, or online…
> Some groups I’ve worked with would pass the Cheesehead hat to the person
> who checked something in that broke the nightly build.  I’m not saying
> being sainted by the 9fans community wouldn’t be an honor, but the
> recipient might get something more along the lines of a cheesehead hat.
>
>
> Until then, you can install hg-git for your python2.7 environment on Plan
> 9:
>
> mkdir -p $home/lib/python2.7/site-packages/docs
> bind -bc $home/lib/python2.7/site-packages /$cputype/lib/python2.7/site-
> packages
> bind -bc $home/lib/python2.7/site-packages /sys/lib/python2.7/site-
> packages
>
> Grab dulwich (https://pypi.python.org/pypi/dulwich), I pulled the latest
> master
> from github:
>
> % unzip -f dulwich-master.zip
> % cd dulwich
>
> To accommodate a strange import error not setting has_mmap correctly, patch
> dulwich/pack.py (this is from my hg clone version after installing):
>
> % hg diff -g dulwich/pack.py
> diff --git a/dulwich/pack.py b/dulwich/pack.py
> --- a/dulwich/pack.py
> +++ b/dulwich/pack.py
> @@ -59,6 +59,10 @@
>      SEEK_CUR,
>      SEEK_END,
>      )
> +# For some reason the above try, except fails to set has_mmap = False
> +if os.uname()[0] == 'Plan9':
> +    has_mmap = False
> +
>  import struct
>  from struct import unpack_from
>  import zlib
>
>
> Install dulwich:
>
> % python setup.py --pure install
>
>
> Grab and install hg-git:
>
> % hg clone https://bitbucket.org/durin42/hg-git
> % cd hg-git
> % python setup.py install
>
>
> Add ‘hggit =‘ to your $home/lib/hgrc [extensions].
>
> Test it out:
>
> % hg clone git://github.com/schacon/hg-git.git
>
>
> It isn’t exactly fast, and there are some cases where cloning using
> https:// instead
> of git:// can be an issue, but it works as a brace|cudgel|kludge until a
> cleaned up
> git is made available for Plan 9.
>
> Now to finish a little transmogrifier git script to trick go get...
>
> -jas
>
>
>
> > On Mar 19, 2015, at 1:03 PM, Skip Tavakkolian <
> skip.tavakkolian@gmail.com> wrote:
> >
> > a 9fan/git-fan should volunteer to take one for the team,  learn git
> thoroughly, then hide it behind an fs layer. we will revere such a person,
> and nominate him/her for sainthood.
> >
> > On Thu, Mar 19, 2015 at 9:35 AM Charles Forsyth <
> charles.forsyth@gmail.com> wrote:
> >
> > On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
> > There is definitely some
> > learning curve and mindset change
> >
> > Just what I want from a little servant that's supposed to help me manage
> some file changes.
>
>
>

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

Re: [9fans] using git

[Devon H. O'Dell]

2015-03-19 14:46 GMT-07:00 Skip Tavakkolian <skip.tavakkolian@gmail.com>:
> servant of 9fans → loathed → cursed → saint

It can (as is probably true in my case) also just stop at either
loathed or cursed.

Re: [9fans] using git

[Kurt H Maier]

Quoting "Devon H. O'Dell" <devon.odell@gmail.com>:

> 2015-03-19 14:46 GMT-07:00 Skip Tavakkolian <skip.tavakkolian@gmail.com>:
>> servant of 9fans → loathed → cursed → saint
>
> It can (as is probably true in my case) also just stop at either
> loathed or cursed.

You can skip steps, too!

Non serviam.

khm

Re: [9fans] using git

[arnold]

Charles Forsyth <charles.forsyth@gmail.com> wrote:

> On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
>
> > There is definitely some
> > learning curve and mindset change
>
> Just what I want from a little servant that's supposed to help me manage
> some file changes.

Git is intended for something completely different than RCS.

I really, REALLY, don't want to start a flame war, although this being
9fans, it's probably not possible. More's the pity.

And again, I AM NOT trying to proselytize.  But, if you are curious as
to what value I personally found in git for gawk development, I will be
happy to discuss it in personal email.

If you don't care, then fine.

I do still maintain that if you go to the trouble to learn git,
daily use reduces to around 6 commands, no GUI required, or desirable.

And I agree, an fs layer over git would be a wonderful Plan 9-style
thing to have.

That's all I really have to say about it.  I'll go crawl back under
my rock now.

Arnold

Re: [9fans] using git

[Charles Forsyth]

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

On 19 March 2015 at 18:26, <arnold@skeeve.com> wrote:

> Charles Forsyth <charles.forsyth@gmail.com> wrote:
>
> > On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
> >
> > > There is definitely some
> > > learning curve and mindset change
> >
> > Just what I want from a little servant that's supposed to help me manage
> > some file changes.
>
> Git is intended for something completely different than RCS.
>
> I really, REALLY, don't want to start a flame war, although this being
> 9fans, it's probably not possible. More's the pity.
>
> And again, I AM NOT trying to proselytize.  But, if you are curious as
> to what value I personally found in git for gawk development, I will be
> happy to discuss it in personal email.


Unfortunately, switching between different devices I missed this reply.
I wasn't really comparing it to RCS although I can see that was a
reasonable conclusion from my wording.


It might be worthwhile sending a brief description of what you use and what
you find valuable to the list.
There isn't much traffic at the moment.

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

Re: [9fans] using git

[Paul Lalonde]

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

I'd like to hear it too - much to learn from others' process.
Paul

On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 19 March 2015 at 18:26, <arnold@skeeve.com> wrote:
>
>> Charles Forsyth <charles.forsyth@gmail.com> wrote:
>>
>> > On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
>> >
>> > > There is definitely some
>> > > learning curve and mindset change
>> >
>> > Just what I want from a little servant that's supposed to help me manage
>> > some file changes.
>>
>> Git is intended for something completely different than RCS.
>>
>> I really, REALLY, don't want to start a flame war, although this being
>> 9fans, it's probably not possible. More's the pity.
>>
>> And again, I AM NOT trying to proselytize.  But, if you are curious as
>> to what value I personally found in git for gawk development, I will be
>> happy to discuss it in personal email.
>
>
> Unfortunately, switching between different devices I missed this reply.
> I wasn't really comparing it to RCS although I can see that was a
> reasonable conclusion from my wording.
>
>
> It might be worthwhile sending a brief description of what you use and
> what you find valuable to the list.
> There isn't much traffic at the moment.
>

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

Re: [9fans] using git

[Giacomo Tesio]

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

As I use both git and hg, I really miss the feature-branching in hg
(obviously, you can, if you try hard enough, use feature branching with hg
too, but git makes it so easy that it became my default process whenever I
can use git for development, even on solo projects):

Suppose you have a team of 3 or more people and a "central" git server that
can be used for facility of share (company server, github, bitbucket,
gitorious...): each person start working on a issue (let it be a bug to fix
or a new feature to implement) by doing on his working copy

git checkout -b feature-nickname


than it change anything that he consider relevant, committing whenever he
decides that a change can be described in a sensible way:

git commit -am 'OptimizingVisitor applies DeMorgan laws'

... a few work after...
git commit -am 'OptimizingVisitor detects constants predicates'


At any time, each developer can push the changes to the central server, to
share his progresses and without the pain to merge them until the full
issue has been addressed.

The next day, a different developer could continue his work if it's really
required (rarely, but it happened).

When the feature has been fully implemented, the dev can merge it into the
shared branch (master, or development when a human-driven test process is
required before the production deployment).

We do not use rebase: we want to keep track of which code the dev was
seeing while writing his changes.

At any time, we can see what features have been released, looking at which
branches have been merged in the shared branch.


On medium to large projects (5 to 20 people) this process allows a fast,
painless collaboration.

Still, whenever I can use git, I use it for my solo projects too, and I
find it quite good to keep track of the progress of the project.


My two cents.


Giacomo


2015-03-28 15:00 GMT+01:00 Paul Lalonde <paul.a.lalonde@gmail.com>:

> I'd like to hear it too - much to learn from others' process.
> Paul
>
> On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>>
>> On 19 March 2015 at 18:26, <arnold@skeeve.com> wrote:
>>
>>> Charles Forsyth <charles.forsyth@gmail.com> wrote:
>>>
>>> > On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
>>> >
>>> > > There is definitely some
>>> > > learning curve and mindset change
>>> >
>>> > Just what I want from a little servant that's supposed to help me
>>> manage
>>> > some file changes.
>>>
>>> Git is intended for something completely different than RCS.
>>>
>>> I really, REALLY, don't want to start a flame war, although this being
>>> 9fans, it's probably not possible. More's the pity.
>>>
>>> And again, I AM NOT trying to proselytize.  But, if you are curious as
>>> to what value I personally found in git for gawk development, I will be
>>> happy to discuss it in personal email.
>>
>>
>> Unfortunately, switching between different devices I missed this reply.
>> I wasn't really comparing it to RCS although I can see that was a
>> reasonable conclusion from my wording.
>>
>>
>> It might be worthwhile sending a brief description of what you use and
>> what you find valuable to the list.
>> There isn't much traffic at the moment.
>>
>

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

Re: [9fans] using git

[Giacomo Tesio]

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

Ah, a small addendum: obviously we also use tags a lot to give a specific
commit (and related history) a name.
This is done automatically by build servers for the "official" tags, and
manually by developers whenever they want in their own repository (often
with tags like, "workedhere", "shittorefactortomorrow" and so on).


Giacomo

2015-03-30 11:48 GMT+02:00 Giacomo Tesio <giacomo@tesio.it>:

> As I use both git and hg, I really miss the feature-branching in hg
> (obviously, you can, if you try hard enough, use feature branching with hg
> too, but git makes it so easy that it became my default process whenever I
> can use git for development, even on solo projects):
>
> Suppose you have a team of 3 or more people and a "central" git server
> that can be used for facility of share (company server, github, bitbucket,
> gitorious...): each person start working on a issue (let it be a bug to fix
> or a new feature to implement) by doing on his working copy
>
> git checkout -b feature-nickname
>
>
> than it change anything that he consider relevant, committing whenever he
> decides that a change can be described in a sensible way:
>
> git commit -am 'OptimizingVisitor applies DeMorgan laws'
>
> ... a few work after...
> git commit -am 'OptimizingVisitor detects constants predicates'
>
>
> At any time, each developer can push the changes to the central server, to
> share his progresses and without the pain to merge them until the full
> issue has been addressed.
>
> The next day, a different developer could continue his work if it's really
> required (rarely, but it happened).
>
> When the feature has been fully implemented, the dev can merge it into the
> shared branch (master, or development when a human-driven test process is
> required before the production deployment).
>
> We do not use rebase: we want to keep track of which code the dev was
> seeing while writing his changes.
>
> At any time, we can see what features have been released, looking at which
> branches have been merged in the shared branch.
>
>
> On medium to large projects (5 to 20 people) this process allows a fast,
> painless collaboration.
>
> Still, whenever I can use git, I use it for my solo projects too, and I
> find it quite good to keep track of the progress of the project.
>
>
> My two cents.
>
>
> Giacomo
>
>
> 2015-03-28 15:00 GMT+01:00 Paul Lalonde <paul.a.lalonde@gmail.com>:
>
>> I'd like to hear it too - much to learn from others' process.
>> Paul
>>
>> On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth <
>> charles.forsyth@gmail.com> wrote:
>>
>>>
>>> On 19 March 2015 at 18:26, <arnold@skeeve.com> wrote:
>>>
>>>> Charles Forsyth <charles.forsyth@gmail.com> wrote:
>>>>
>>>> > On 19 March 2015 at 16:09, <arnold@skeeve.com> wrote:
>>>> >
>>>> > > There is definitely some
>>>> > > learning curve and mindset change
>>>> >
>>>> > Just what I want from a little servant that's supposed to help me
>>>> manage
>>>> > some file changes.
>>>>
>>>> Git is intended for something completely different than RCS.
>>>>
>>>> I really, REALLY, don't want to start a flame war, although this being
>>>> 9fans, it's probably not possible. More's the pity.
>>>>
>>>> And again, I AM NOT trying to proselytize.  But, if you are curious as
>>>> to what value I personally found in git for gawk development, I will be
>>>> happy to discuss it in personal email.
>>>
>>>
>>> Unfortunately, switching between different devices I missed this reply.
>>> I wasn't really comparing it to RCS although I can see that was a
>>> reasonable conclusion from my wording.
>>>
>>>
>>> It might be worthwhile sending a brief description of what you use and
>>> what you find valuable to the list.
>>> There isn't much traffic at the moment.
>>>
>>
>

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

Re: [9fans] using git

[Jeff Sickel]

> On Mar 30, 2015, at 4:55 AM, Giacomo Tesio <giacomo@tesio.it> wrote:
> 
> Ah, a small addendum: obviously we also use tags a lot to give a specific commit (and related history) a name.
> This is done automatically by build servers for the "official" tags, and manually by developers whenever they want in their own repository (often with tags like, "workedhere", "shittorefactortomorrow" and so on).

All of those features are available in hg, darcs, and other dscm tools.

But to get back on topic, unless I’ve overlooked a contrib package somewhere, how about we begin with the requirements to get a fully working git installed on Plan 9.  For example,

## the dependencies required for git on a bare-bones FreeBSD install:
# pkg install git
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 18 packages will be affected (of 0 checked):

New packages to be INSTALLED:
        git: 2.3.4
        expat: 2.1.0_2
        p5-Authen-SASL: 2.16_1
        p5-GSSAPI: 0.28_1
        perl5: 5.18.4_11
        p5-Digest-HMAC: 1.03_1
        p5-Net-SMTP-SSL: 1.01_3
        p5-IO-Socket-SSL: 2.012
        p5-Mozilla-CA: 20141217
        p5-Net-SSLeay: 1.68
        p5-Socket: 2.018
        p5-IO-Socket-IP: 0.37
        python27: 2.7.9
        libffi: 3.2.1
        p5-Error: 0.17023
        curl: 7.41.0
        ca_root_nss: 3.18
        cvsps: 2.1_1



I’m not sure what cvsps is for, that seems to have cropped up on the fbsd pkg sometime between git versions 2.3.1 and 2.3.4.  It’s been years^wdecades since I’ve tinkered with perl, and I’m fairly certain the perl 5.8 version available on Plan 9 won’t support the modules included in the above list.  So Plan 9 needs a modern perl to run git effectively with specific attention to the additional modules.  Expat is the “eXpat XML parser library”.  Libffi is something maintained on sources.redhat.com.  Many of those modules depend on OpenSSL, so add that to the list.  It’s also possible a recent port of bash will also be required as the git support scripts may not work with our ape/sh or ape/psh.  We’ve got python 2.7.8 [.9 soon] covered.  

Piece of cake, all that should fit on a coaster.

-jas

Re: [9fans] using git

[Stanley Lieber]

this world sucks

Re: [9fans] using git

[Bakul Shah]

zsh: cd $git-sources
zsh: wc -l **/*.{c,h,sh,py,pl}|tail -1
  318901 total
zsh: for a in c h sh py pl; do echo $a: `wc -l **/*.$a|tail -1`;done
c: 161667 total
h: 16971 total
sh: 133214 total
py: 5634 total
pl: 1415 total

Re: [9fans] using git

[Giacomo Tesio]

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

Actually, Jeff I appreciate a lot your work on mercurial. I know I could
use the bookmarks extension to achieve a similar process with hg (never
tried darcs and bzr seriously, sorry). but I still prefer git to mercurial,
since it has been designed around the features that I like (when working
alone) or need (when working in large team over years long projects).

But this is personal taste, and I'm not a git evangelist. I just replied to
Charles asking for the features we use in git.

Btw, ever heard of http://libgit2.org ?
Plain c89. No external dependencies.

In theory, one could implement a native gitfs over that, in C, using the
network fs available in Plan9.

Compared to hgfs, a bit more design of the fs structure would probably be
needed to capture the concept of branch in a hierarchical filesystem.

How much you would estimate such development?


Giacomo



2015-03-30 18:16 GMT+02:00 Jeff Sickel <jas@corpus-callosum.com>:

>
> > On Mar 30, 2015, at 4:55 AM, Giacomo Tesio <giacomo@tesio.it> wrote:
> >
> > Ah, a small addendum: obviously we also use tags a lot to give a
> specific commit (and related history) a name.
> > This is done automatically by build servers for the "official" tags, and
> manually by developers whenever they want in their own repository (often
> with tags like, "workedhere", "shittorefactortomorrow" and so on).
>
> All of those features are available in hg, darcs, and other dscm tools.
>
> But to get back on topic, unless I’ve overlooked a contrib package
> somewhere, how about we begin with the requirements to get a fully working
> git installed on Plan 9.  For example,
>
> ## the dependencies required for git on a bare-bones FreeBSD install:
> # pkg install git
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> The following 18 packages will be affected (of 0 checked):
>
> New packages to be INSTALLED:
>         git: 2.3.4
>         expat: 2.1.0_2
>         p5-Authen-SASL: 2.16_1
>         p5-GSSAPI: 0.28_1
>         perl5: 5.18.4_11
>         p5-Digest-HMAC: 1.03_1
>         p5-Net-SMTP-SSL: 1.01_3
>         p5-IO-Socket-SSL: 2.012
>         p5-Mozilla-CA: 20141217
>         p5-Net-SSLeay: 1.68
>         p5-Socket: 2.018
>         p5-IO-Socket-IP: 0.37
>         python27: 2.7.9
>         libffi: 3.2.1
>         p5-Error: 0.17023
>         curl: 7.41.0
>         ca_root_nss: 3.18
>         cvsps: 2.1_1
>
>
>
> I’m not sure what cvsps is for, that seems to have cropped up on the fbsd
> pkg sometime between git versions 2.3.1 and 2.3.4.  It’s been
> years^wdecades since I’ve tinkered with perl, and I’m fairly certain the
> perl 5.8 version available on Plan 9 won’t support the modules included in
> the above list.  So Plan 9 needs a modern perl to run git effectively with
> specific attention to the additional modules.  Expat is the “eXpat XML
> parser library”.  Libffi is something maintained on sources.redhat.com.
> Many of those modules depend on OpenSSL, so add that to the list.  It’s
> also possible a recent port of bash will also be required as the git
> support scripts may not work with our ape/sh or ape/psh.  We’ve got python
> 2.7.8 [.9 soon] covered.
>
> Piece of cake, all that should fit on a coaster.
>
> -jas
>
>
>
>
>
>

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

Re: [9fans] using git

[Ryan Gonzalez]

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

Is all that even necessary?

Dulwich is a 100%-complete pure-Python implementation of the Git API, which
optional C extensions for speed. It comes with a simple Git driver remake
that implements the core necessities, a.k.a. it has fetch-pack but no push
and send-pack but no pull. It would still probably easier to extend/finish
that than writing a driver from scratch in C.


On Mon, Mar 30, 2015 at 3:20 PM, Giacomo Tesio <giacomo@tesio.it> wrote:

> Actually, Jeff I appreciate a lot your work on mercurial. I know I could
> use the bookmarks extension to achieve a similar process with hg (never
> tried darcs and bzr seriously, sorry). but I still prefer git to mercurial,
> since it has been designed around the features that I like (when working
> alone) or need (when working in large team over years long projects).
>
> But this is personal taste, and I'm not a git evangelist. I just replied
> to Charles asking for the features we use in git.
>
> Btw, ever heard of http://libgit2.org ?
> Plain c89. No external dependencies.
>
> In theory, one could implement a native gitfs over that, in C, using the
> network fs available in Plan9.
>
> Compared to hgfs, a bit more design of the fs structure would probably be
> needed to capture the concept of branch in a hierarchical filesystem.
>
> How much you would estimate such development?
>
>
> Giacomo
>
>
>
> 2015-03-30 18:16 GMT+02:00 Jeff Sickel <jas@corpus-callosum.com>:
>
>>
>> > On Mar 30, 2015, at 4:55 AM, Giacomo Tesio <giacomo@tesio.it> wrote:
>> >
>> > Ah, a small addendum: obviously we also use tags a lot to give a
>> specific commit (and related history) a name.
>> > This is done automatically by build servers for the "official" tags,
>> and manually by developers whenever they want in their own repository
>> (often with tags like, "workedhere", "shittorefactortomorrow" and so on).
>>
>> All of those features are available in hg, darcs, and other dscm tools.
>>
>> But to get back on topic, unless I’ve overlooked a contrib package
>> somewhere, how about we begin with the requirements to get a fully working
>> git installed on Plan 9.  For example,
>>
>> ## the dependencies required for git on a bare-bones FreeBSD install:
>> # pkg install git
>> Updating FreeBSD repository catalogue...
>> FreeBSD repository is up-to-date.
>> All repositories are up-to-date.
>> The following 18 packages will be affected (of 0 checked):
>>
>> New packages to be INSTALLED:
>>         git: 2.3.4
>>         expat: 2.1.0_2
>>         p5-Authen-SASL: 2.16_1
>>         p5-GSSAPI: 0.28_1
>>         perl5: 5.18.4_11
>>         p5-Digest-HMAC: 1.03_1
>>         p5-Net-SMTP-SSL: 1.01_3
>>         p5-IO-Socket-SSL: 2.012
>>         p5-Mozilla-CA: 20141217
>>         p5-Net-SSLeay: 1.68
>>         p5-Socket: 2.018
>>         p5-IO-Socket-IP: 0.37
>>         python27: 2.7.9
>>         libffi: 3.2.1
>>         p5-Error: 0.17023
>>         curl: 7.41.0
>>         ca_root_nss: 3.18
>>         cvsps: 2.1_1
>>
>>
>>
>> I’m not sure what cvsps is for, that seems to have cropped up on the fbsd
>> pkg sometime between git versions 2.3.1 and 2.3.4.  It’s been
>> years^wdecades since I’ve tinkered with perl, and I’m fairly certain the
>> perl 5.8 version available on Plan 9 won’t support the modules included in
>> the above list.  So Plan 9 needs a modern perl to run git effectively with
>> specific attention to the additional modules.  Expat is the “eXpat XML
>> parser library”.  Libffi is something maintained on sources.redhat.com.
>> Many of those modules depend on OpenSSL, so add that to the list.  It’s
>> also possible a recent port of bash will also be required as the git
>> support scripts may not work with our ape/sh or ape/psh.  We’ve got python
>> 2.7.8 [.9 soon] covered.
>>
>> Piece of cake, all that should fit on a coaster.
>>
>> -jas
>>
>>
>>
>>
>>
>>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

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

Re: [9fans] using git

[arnold]

Hi All.

Giacomo Tesio pretty much expressed the flow.  For me, the cheap
branching and excellent merging are extremely important, esp. as
compared with earlier systems like subversion.

The distribution development is also a huge boon; I have several
contributors with write access to the main git repo; when one of them
has a change that's been reviewed and is ready to go, or a bug fix,
they can just commit it to the main repo and then I can get it.

Like many people (I suspect), my experience was

	RCS -> CVS - Subversion -> Git

I haven't tried the other systems, and I'm sure they all have
their strengthes and that there are things I could learn from
them.

Git has the advantage of currently being the most popular, and
also of being quite fast.

A gitfs for Plan 9 sounds wonderful and there appear to be options
for getting there, but it may be enough for most people to just
use Linux as a bridge.

Thanks,

Arnold

Re: [9fans] using git

[Jeff Sickel]

> On Mar 19, 2015, at 11:09 AM, arnold@skeeve.com wrote:
> 
> I know some real git fanatics. I'm not one, but I am a "fan". :-)
> 
> I'll be happy to continue a discussion with you offline, if you wish.


Don’t worry Arnold, I’ve been using source control systems for decades and have
used git since the early days.  I’m glad it finally dropped the 'git-pull’ syntax
for the cleaner (clearer|easier ?) to type ‘git pull’ implementation.  If git is
the only DVCS tool you’ve used it wouldn’t hurt giving darcs or hg a cursory review
to gain an understanding of alternative ways to slice the pie.

That said, James did have an early port of hg-git and I’ve gotten close to getting
a new version working with the Python 2.7.x build.  Uriel left git 1.5.6 in his
contrib built for 386.  Unfortunately, Uriel didn’t leave build or install instruction
and his version is highly dependent on APE with all the whacked sh and perl scripts of 
git-wrappers needing to go in /usr/glenda/share/git-core/templates or somewhere, so
I’ve never used it.

If someone were to take on a fresh git port, it should definitely include a mkfile
because that git/git/Makefile will take too long to parse and sort out the mess to
get everything up and running on Plan 9.

-jas

Re: [9fans] using git

[Ori Bernstein]

In the past, I have managed to get git-hg to work, but it's been extremely
flaky -- for example, Python would refuse to find modules unless I ran hg
from within the modules directory.

Unfortunately, I've lost the drive with that system since.

On Mar 19, 2015, at 10:00 AM, Jeff Sickel <jas@corpus-callosum.com> wrote:

> 
>> On Mar 19, 2015, at 11:09 AM, arnold@skeeve.com wrote:
>> 
>> I know some real git fanatics. I'm not one, but I am a "fan". :-)
>> 
>> I'll be happy to continue a discussion with you offline, if you wish.
> 
> 
> Don’t worry Arnold, I’ve been using source control systems for decades and have
> used git since the early days.  I’m glad it finally dropped the 'git-pull’ syntax
> for the cleaner (clearer|easier ?) to type ‘git pull’ implementation.  If git is
> the only DVCS tool you’ve used it wouldn’t hurt giving darcs or hg a cursory review
> to gain an understanding of alternative ways to slice the pie.
> 
> That said, James did have an early port of hg-git and I’ve gotten close to getting
> a new version working with the Python 2.7.x build.  Uriel left git 1.5.6 in his
> contrib built for 386.  Unfortunately, Uriel didn’t leave build or install instruction
> and his version is highly dependent on APE with all the whacked sh and perl scripts of 
> git-wrappers needing to go in /usr/glenda/share/git-core/templates or somewhere, so
> I’ve never used it.
> 
> If someone were to take on a fresh git port, it should definitely include a mkfile
> because that git/git/Makefile will take too long to parse and sort out the mess to
> get everything up and running on Plan 9.
> 
> -jas
> 
> 

Re: [9fans] ken cc for linux

[Aram Hăvărneanu]

On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
> Go had vastly better versions, but it seems they got ripped out recently. I
> think Go 1.3 may have had them, in which case you'd do something like:
>
> go tool 6c tst.c
> go tool 6l -o tst tst.6

First, Go did not have "vastly better versions", Go's compilers came
from Inferno and the back-ends were very minimally modified, mainly to
fix bugs. The linkers and other lower level details were modified a
lot, but they make what you want to do harder, not easier.

Second, what you typed will try to link with the Go runtime, which is
definitely not what you want. Third, it will not work, at least not
without further work, main is not the entry point. Fourth, you don't
have a standard library available.

Go's compiler were there for building the Go runtime. To use them for
anything else, you'd need *a lot* of work, much more work than by
starting with the Plan 9/Inferno/Ken-cc directly.

-- 
Aram Hăvărneanu

Re: [9fans] ken cc for linux

[Ryan Gonzalez]

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

On Thu, Mar 12, 2015 at 3:50 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
> > Go had vastly better versions, but it seems they got ripped out
> recently. I
> > think Go 1.3 may have had them, in which case you'd do something like:
> >
> > go tool 6c tst.c
> > go tool 6l -o tst tst.6
>
> First, Go did not have "vastly better versions", Go's compilers came
> from Inferno and the back-ends were very minimally modified, mainly to
> fix bugs. The linkers and other lower level details were modified a
> lot, but they make what you want to do harder, not easier.
>

Well, they worked with ELF files.


> Second, what you typed will try to link with the Go runtime, which is
> definitely not what you want. Third, it will not work, at least not
> without further work, main is not the entry point. Fourth, you don't
> have a standard library available.
>

I know. ken-cc doesn't give you a standard library either.

I'm getting these commands off the top of my head, not a manual somewhere.


>
> Go's compiler were there for building the Go runtime. To use them for
> anything else, you'd need *a lot* of work, much more work than by
> starting with the Plan 9/Inferno/Ken-cc directly.
>
>
Eh...


> --
> Aram Hăvărneanu
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

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

Re: [9fans] ken cc for linux

[Aram Hăvărneanu]

On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
> As you can see, Go actually had a working 64-bit compiler.

Plan 9 and Inferno have working 64-bit compilers. They are used for
the many Plan 9 amd64 kernels. Go's C compilers all came from Inferno,
including 6c.

-- 
Aram Hăvărneanu

Re: [9fans] ken cc for linux

[Charles Forsyth]

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

On 12 March 2015 at 08:51, Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> Plan 9 and Inferno have working 64-bit compilers.


Periodically I pull the Plan 9 and Inferno variants into line, so they
should be about the same.
It's one reason I split off the Thumb implementation, although it handled
ARM/Thumb interlinking better than some.
Looking at the current differences, I think I'm inclined now to keep a
master copy and then pull
from that into the two distributions (could just pull directly for Inferno).
I've used it and lib9 in several other projects where other compilers
couldn't be used for licensing reasons, or because they were awful.
An ANSI cpp is included.

I believe there are small ANSI C libraries available.

It's trickier for Linux work. Not only is there ELF/DWARF to deal with, and
those are both families of a powerset of options, but
there are shared libraries and different run-time conventions.
Just look at the disaster of most implementations of variable length
parameter lists:
thanks to function prototypes, which are now (what?) 30 years old,
we know where they are, and can make a simple array on the stack.
Instead some platforms, even otherwise tasteful ones,
for the caller not relying on the prototype, just in case you don't use
them, 30 years on,
and instead using the complex register-oriented calling convention even for
those,
and  use pages of complex filth to compensate.
(I wouldn't mind using registers a bit more in the calling convention, if
it proved cost-effective,
but I'd still pass variable-length parameter lists on the stack.)

Most things need only a handful of system calls, but overall it looks like
a big effort,
and I'm not sure what the goal would be. I have done wrapper programs that
create
an environment to run Plan 9 a.out programs on Linux and another, but that
was mainly
to assist compiler development on new platforms.

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

Re: [9fans] ken cc for linux

[Charles Forsyth]

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

On 12 March 2015 at 10:06, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I've used it and lib9 in several other projects where other compilers
> couldn't be used for licensing reasons, or because they were awful.
>

I'll add that the compilers are great for kernel and other New World
systems work.
Once stable on a given platform, they've been quite robust (I never suspect
them at the start as a bug cause).
Code quality is rarely a bottleneck for systems work in my experience
(and there's a good reason that removing -O3 is a way to fix bugs with
other compilers).
If I were writing scientific computation, I wouldn't use C anyway, but if I
did, I'd worry
much more about the effectiveness of optimisation. For systems work? It's
really, really low on the list.
The cross-module type checking has also spotted a few things that every
other compiler missed.

Cross-compilation is easy and precise, with next to no configuration
required,
unlike nearly all the others; I rely on that a lot. It's worth the price of
entry for that alone, for me,
having suffered with gcc on an old OS project of mine; I'd never use it
again for anything new.
(Obviously I still use gcc for the 8 hour[!] Linux kernel compiles and
builds.)

lcc used to include all the code generators, so I suppose that would be
just as good, except
that it spits out assembly and you have to rely on external components,
which still leaves you cross when attempting
to cross-compile.

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

Re: [9fans] ken cc for linux

[Brantley Coile]

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

Thanks Charles.  I agree completely and will add that they will pry Ken's compilers, so wonderfully supported by you, from my cold, dead fingers.  South Suite's new kernel will always be compiled with 6c.  As far as performance goes, to paraphrase Chuck Yeager, it's not the compiler, it's the coder.  I'd rather have brilliant coders than idiot savant compilers.  

bwc
iPhone email

> On Mar 12, 2015, at 11:23 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> 
>> On 12 March 2015 at 10:06, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> I've used it and lib9 in several other projects where other compilers
>> couldn't be used for licensing reasons, or because they were awful.
> 
> I'll add that the compilers are great for kernel and other New World systems work.
> Once stable on a given platform, they've been quite robust (I never suspect them at the start as a bug cause).
> Code quality is rarely a bottleneck for systems work in my experience
> (and there's a good reason that removing -O3 is a way to fix bugs with other compilers).
> If I were writing scientific computation, I wouldn't use C anyway, but if I did, I'd worry
> much more about the effectiveness of optimisation. For systems work? It's really, really low on the list.
> The cross-module type checking has also spotted a few things that every other compiler missed.
> 
> Cross-compilation is easy and precise, with next to no configuration required,
> unlike nearly all the others; I rely on that a lot. It's worth the price of entry for that alone, for me,
> having suffered with gcc on an old OS project of mine; I'd never use it again for anything new.
> (Obviously I still use gcc for the 8 hour[!] Linux kernel compiles and builds.)
> 
> lcc used to include all the code generators, so I suppose that would be just as good, except
> that it spits out assembly and you have to rely on external components, which still leaves you cross when attempting
> to cross-compile.
> 
> 
> 
> 

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

Re: [9fans] ken cc for linux

[Charles Forsyth]

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

That reminds me that I've got various small repairs and changes to merge in.
Possibly the best way will be to point to a test version in an announcement
here, and
then people can check that they work for them, so nothing breaks
unexpectedly on
recompilation.

One potential big future change (not yet made) is to switch to strictly
ANSI rules for unsigned+signed
values meeting in "the usual arithmetic conversions". The rules are
horrible, but it's one of the
few ways in which the compiler implements something that's neither an
extension nor a restriction
compared to the standard. You'll never miss most of the others. One
approach there is to have
the compiler consider the type under both systems and warn if the
difference might cause trouble
(typically in comparisons, but there might be other cases). Most of the
Plan 9 source has
been compiled under the ANSI regime in the form of Plan 9 Ports, so I'd
expect that most of the
tricky cases have already been fixed.

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

Re: [9fans] ken cc for linux

[erik quanstrom]

> One potential big future change (not yet made) is to switch to
> strictly ANSI rules for unsigned+signed values meeting in "the usual
> arithmetic conversions".  The rules are horrible, but it's one of the
> few ways in which the compiler implements something that's neither an
> extension nor a restriction compared to the standard.  You'll never
> miss most of the others.  One approach there is to have the compiler
> consider the type under both systems and warn if the difference might
> cause trouble (typically in comparisons, but there might be other
> cases).  Most of the Plan 9 source has been compiled under the ANSI
> regime in the form of Plan 9 Ports, so I'd expect that most of the
> tricky cases have already been fixed.

if this is done, please do add the diagnostic as an error.  i'd rather not
spend any more brain than necessary on "the usual conversions".

- erik

Re: [9fans] ken cc for linux

[Ryan Gonzalez]

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

I know. I'm referring to the ken-cc port.

On Thu, Mar 12, 2015 at 3:51 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
> > As you can see, Go actually had a working 64-bit compiler.
>
> Plan 9 and Inferno have working 64-bit compilers. They are used for
> the many Plan 9 amd64 kernels. Go's C compilers all came from Inferno,
> including 6c.
>
> --
> Aram Hăvărneanu
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/

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