> On Mar 13, 2015, at 1:19 PM, Kurt H Maier 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
Quoting Ryan Gonzalez :
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
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
On 13 March 2015 at 01:31, erik quanstrom 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 othe
> 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
> 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 r
On Thu, Mar 12, 2015 at 3:50 AM, Aram Hăvărneanu wrote:
> On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez 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
>
I know. I'm referring to the ken-cc port.
On Thu, Mar 12, 2015 at 3:51 AM, Aram Hăvărneanu wrote:
> On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez 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
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 ye
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 co
On 12 March 2015 at 10:06, Charles Forsyth
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 gi
On 12 March 2015 at 08:51, Aram Hăvărneanu 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
On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez 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
On Wed, Mar 11, 2015 at 10:04 PM, Ryan Gonzalez 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 versio
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 app
> 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
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 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 L
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 inst
Warning: this will get messy *fast*.
On Wed, Mar 11, 2015 at 3:30 PM, Aharon Robbins 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
It doesn't come with a suitable libc that you expect.
--
Aram Hăvărneanu
20 matches
Mail list logo
