Skip Tavakkolian once said:
> is this the patch set you're referring to?
> https://codereview.appspot.com/download/issue9796043_58001.diff
>
> if so, is there a diff set for go1.2?
Hi Skip,
There were a few problems with that CL that I'm just now
starting to iron out so I extracted out the memm
> The Go tree is still in a code freeze but I'll have those
> CLs submitted as soon as it reopens.
>
> Also, we have three months (until the Go 1.3 code freeze) to
> get the Plan 9 port passing all tests on the build dashboard
> or it will have to move outside the main repository:
there is no dem
> is the threat standing? that is, if the plan 9 port is broken again
> when 1.5 rolls around in just a few more months, does the plan 9
> port get booted then, too?
The threat is real: Plan 9 is a burden for the developers and lack of
feedback is a valid cause for dismissal. Of the two-prong th
On Mon Dec 2 10:01:48 EST 2013, lu...@proxima.alt.za wrote:
> > is the threat standing? that is, if the plan 9 port is broken again
> > when 1.5 rolls around in just a few more months, does the plan 9
> > port get booted then, too?
>
> The threat is real: Plan 9 is a burden for the developers an
Quoting lu...@proxima.alt.za:
I don't think Go needs to be thrown away, I think it is a motivating
force itself,
Why?
khm
It would be very hard to replicate what Go can do for Plan 9 with something
else. There is a large and growing collection of packages that make it
possible to deal with the dizzying number of protocols and APIs that are
today's WWW. Another advantage of Go is that, like Limbo, it enables the
youn
> anyway, what's the argument for not just forking?
I like Go's portability across platforms. Having a version for Plan 9
that is inconsistent in this respect is exactly the opposite of what I
want. Nothing stops anyone from forking, but losing the code review
by a community of experts will defi
> This current situation is not insurmountable; it seems that we have enough
> people who are interested and a handful who are contributors that we can
> make this happen with some coordination.
We will almost certainly need more focus from Bell Labs or at least
less reluctance. More than ever,
> Quoting lu...@proxima.alt.za:
>
>> I don't think Go needs to be thrown away, I think it is a motivating
>> force itself,
>
> Why?
>
It's my opinion. Do you have a problem with that?
++L
Contributions would be great, but we’re swimming upstream to spawn and die.
The libbio changes are a good example. More than a month before the release
candidates started rolling out there was one patch
(https://codereview.appspot.com/14604047/)
to try and reconcile the changes. I also added a
> It takes time, more than effort, to keep up with the various Go developer
> lists where changes actually take place. The case of libbio changes happened
> at a time when no one in the Plan 9 community was really looking at the
> threads until it was too late to comment. Now we’re caught trying
> I know that David and I are monitoring golang-dev pretty closely. By
> the same token, I suspect that Gorka and Nemo don't (I don't know this
> for a fact, I'm speculating). What would help immensely would be if
> we could advertise each of the willing contributors' own interest in
> the develo
On Mon Dec 2 12:22:09 EST 2013, lu...@proxima.alt.za wrote:
> > anyway, what's the argument for not just forking?
>
> I like Go's portability across platforms. Having a version for Plan 9
> that is inconsistent in this respect is exactly the opposite of what I
> want. Nothing stops anyone from
Quoting lu...@proxima.alt.za:
Quoting lu...@proxima.alt.za:
I don't think Go needs to be thrown away, I think it is a motivating
force itself,
Why?
It's my opinion. Do you have a problem with that?
Why do you hold this opinion? While your defensiveness is hilarious, it's a
simple matt
Please explain this assertion (e.g. TSEMACQUIRE contradicts it).
On Mon, Dec 2, 2013 at 9:25 AM, wrote:
> > This current situation is not insurmountable; it seems that we have
> enough
> > people who are interested and a handful who are contributors that we can
> > make this happen with some
I believe one or two 9fans have provided systems for this purpose.
On Mon, Dec 2, 2013 at 10:33 AM, erik quanstrom wrote:
>
>
> all this is moot unless we can get plan 9 integrated into go's automatic
> build system. is this doable? i have resources to make this happen if
> it is.
>
> - erik
>
On Mon Dec 2 14:17:04 EST 2013, skip.tavakkol...@gmail.com wrote:
> I believe one or two 9fans have provided systems for this purpose.
>
>
> On Mon, Dec 2, 2013 at 10:33 AM, erik quanstrom
> wrote:
> >
> >
> > all this is moot unless we can get plan 9 integrated into go's automatic
> > build s
On Mon, Dec 2, 2013 at 10:33 AM, erik quanstrom
wrote:
> all this is moot unless we can get plan 9 integrated into go's automatic
> build system. is this doable? i have resources to make this happen if
> it is.
>
> - erik
It's definitely doable. I have a builder key that I've provided to
David
let me preface my original statement with the following legalese weasel
clause: "at some point in the past, i was let to believe that..."
On Mon, Dec 2, 2013 at 11:26 AM, erik quanstrom wrote:
> On Mon Dec 2 14:17:04 EST 2013, skip.tavakkol...@gmail.com wrote:
>
> > I believe one or two 9fans
On Mon Dec 2 14:13:51 EST 2013, skip.tavakkol...@gmail.com wrote:
> Please explain this assertion (e.g. TSEMACQUIRE contradicts it).
>
> On Mon, Dec 2, 2013 at 9:25 AM, wrote:
>
> > > This current situation is not insurmountable; it seems that we have
> > enough
> > > people who are interested
On Mon, 02 Dec 2013 13:33:34 EST erik quanstrom
wrote:
> all this is moot unless we can get plan 9 integrated into go's automatic
> build system. is this doable? i have resources to make this happen if
> it is.
One simple thing that can be done is to set up a cron job to
fetch updates and if a
Some coordination among people who are 9fan-gonut, 9fan-godev or 9dev would
be helpful; at least it will reduce unnecessary head-scratching.
On Mon, Dec 2, 2013 at 11:37 AM, Bakul Shah wrote:
> On Mon, 02 Dec 2013 13:33:34 EST erik quanstrom
> wrote:
> > all this is moot unless we can get plan
python on plan9 can't even handle the codereview extension.
On Mon, Dec 2, 2013 at 10:39 AM, Kurt H Maier wrote:
> Specifically: how will Go enable good things
> that, say, python has not?
>
> khm
>
>
>
On Mon Dec 2 15:10:29 EST 2013, skip.tavakkol...@gmail.com wrote:
> python on plan9 can't even handle the codereview extension.
i believe that's false. jas' port does a lot of things the
prior port does not. it's on bitbucket.
- erik
The Go builder is now up and running, thanks to the build keys
offered by Chris and Lucio today.
We'll see how it goes over time.
--
David du Colombier
i'm getting it now. thanks.
On Mon, Dec 2, 2013 at 12:11 PM, erik quanstrom wrote:
> On Mon Dec 2 15:10:29 EST 2013, skip.tavakkol...@gmail.com wrote:
>
> > python on plan9 can't even handle the codereview extension.
>
> i believe that's false. jas' port does a lot of things the
> prior port d
> > python on plan9 can't even handle the codereview extension.
>
> i believe that's false. jas' port does a lot of things the
> prior port does not. it's on bitbucket.
I agree with Erik. Jeff Sickel did a very good job on the
modern Python port.
If you are afraid to compile it, I'm providing
On Mon Dec 2 15:25:33 EST 2013, 0in...@gmail.com wrote:
> > > python on plan9 can't even handle the codereview extension.
> >
> > i believe that's false. jas' port does a lot of things the
> > prior port does not. it's on bitbucket.
>
> I agree with Erik. Jeff Sickel did a very good job on the
On Mon, 02 Dec 2013 15:38:21 EST erik quanstrom
wrote:
> On Mon Dec 2 15:25:33 EST 2013, 0in...@gmail.com wrote:
> > > > python on plan9 can't even handle the codereview extension.
> > >
> > > i believe that's false. jas' port does a lot of things the
> > > prior port does not. it's on bitbuc
> it won't compile unless you're running 9atom. or have integrated
> the (extensive) changes to ape, especially in the sockets area.
Yes, I had to replace /sys/src/ape and /sys/include/ape with
9atom versions to compile Python. I've put my notes here:
http://www.9legacy.org/9legacy/doc/python/not
On Mon Dec 2 15:44:27 EST 2013, ba...@bitblocks.com wrote:
> On Mon, 02 Dec 2013 15:38:21 EST erik quanstrom
> wrote:
> > On Mon Dec 2 15:25:33 EST 2013, 0in...@gmail.com wrote:
> > > > > python on plan9 can't even handle the codereview extension.
> > > >
> > > > i believe that's false. jas'
On Mon, 02 Dec 2013 15:45:53 EST erik quanstrom
wrote:
> On Mon Dec 2 15:44:27 EST 2013, ba...@bitblocks.com wrote:
> > On Mon, 02 Dec 2013 15:38:21 EST erik quanstrom
> wrote:
> > > On Mon Dec 2 15:25:33 EST 2013, 0in...@gmail.com wrote:
> > > > > > python on plan9 can't even handle the code
> I am suggesting breaking out just the diffs and new mkfiles in
> a separate tree so that one can do
>
> mk all && mk install
>
> This can fetch the necessary bits, apply patches, build, test,
> create downloadable binaries (with crypto signatures if you
> care) etc. As part of this it can
wait! so, you had to make changes to Plan 9 to support Python? :)
(sorry, couldn't resist)
On Mon, Dec 2, 2013 at 12:38 PM, erik quanstrom wrote:
> On Mon Dec 2 15:25:33 EST 2013, 0in...@gmail.com wrote:
> > > > python on plan9 can't even handle the codereview extension.
> > >
> > > i believe
Well, not Plan 9 per se, but APE, yes. APE was crusty, old, and
not supporting the bulk of the POSIX APIs that all the current
systems are using.
So yes, changes to APE are required.
On Dec 2, 2013, at 3:06 PM, Skip Tavakkolian wrote:
> wait! so, you had to make changes to Plan 9 to support P
On Mon Dec 2 16:46:10 EST 2013, j...@corpus-callosum.com wrote:
> Well, not Plan 9 per se, but APE, yes. APE was crusty, old, and
> not supporting the bulk of the POSIX APIs that all the current
> systems are using.
>
> So yes, changes to APE are required.
but only insofar as ape is wrong! thi
On Mon Dec 2 16:08:20 EST 2013, skip.tavakkol...@gmail.com wrote:
> wait! so, you had to make changes to Plan 9 to support Python? :)
>
> (sorry, couldn't resist)
i'll take the bait.
the changes were very different from the changes for go. python
is an ape program, and ape has been very neglec
erik quanstrom once said:
> On Mon Dec 2 10:01:48 EST 2013, lu...@proxima.alt.za wrote:
> > > is the threat standing? that is, if the plan 9 port is broken again
> > > when 1.5 rolls around in just a few more months, does the plan 9
> > > port get booted then, too?
> >
> > The threat is real: P
At a high level it is about excess baggage that needs to be carried to
provide a familiar environment for either language. Python needs Posix, so
we have to carry its APE baggage, whereas Go brings its own Plan9-ish
baggage (?[cl], lib9, libbio, etc.) and you'll need to give it some hooks
to hang
On Mon, 02 Dec 2013 16:03:54 EST erik quanstrom
wrote:
> > I am suggesting breaking out just the diffs and new mkfiles in
> > a separate tree so that one can do
> >
> > mk all && mk install
> >
> > This can fetch the necessary bits, apply patches, build, test,
> > create downloadable binari
Whne I looked at Go - maybe 2 years ago, I could not see why
plan9 would not adopt go's 8c/8l and libbio.
obviously others disagree as they have not been back-ported,
but why not? - I'am not trolling, genuine question.
For me, at the time, go's ability to produce (limited) windows 32bit
executabl
> > patches are the plan 9 standard way of doing
> > things. they've been submitted, and can be
> > applied by anyone.
>
> Right but clearly this is not working well. Anyway, I'll try
> to find time to whip up a prototype of what I am talking
> about.
does applying patches oneself not work? wha
> At a high level it is about excess baggage that needs to be carried to
> provide a familiar environment for either language. Python needs Posix, so
> we have to carry its APE baggage, whereas Go brings its own Plan9-ish
> baggage (?[cl], lib9, libbio, etc.) and you'll need to give it some hooks
Steve Simon once said:
> Whne I looked at Go - maybe 2 years ago, I could not see why
> plan9 would not adopt go's 8c/8l and libbio.
>
> obviously others disagree as they have not been back-ported,
> but why not? - I'am not trolling, genuine question.
We couldn't adopt the Go ?[acl] toolchain wh
erik quanstrom once said:
> > 2. Use of Go's libbio, rather than Plan 9's. Alternatively libbio on Plan 9
> > can be changed. It's not clear to me why this would be a bad thing.
>
> i object to the macros they have been adding. they haven't been included
> in p9p, either. adding B(put|get)(le|b
On Tue, Dec 3, 2013 at 1:12 AM, erik quanstrom wrote:
> python's requirements are a proper subset of go's, since building go requires
> python be installed.
No, it doesn't. Using mercurial to clone the tree requires python,
building Go does not require python, nor mercurial.
--
Aram Hăvărneanu
On Mon Dec 2 19:51:11 EST 2013, ara...@mgk.ro wrote:
> On Tue, Dec 3, 2013 at 1:12 AM, erik quanstrom wrote:
> > python's requirements are a proper subset of go's, since building go
> > requires
> > python be installed.
>
> No, it doesn't. Using mercurial to clone the tree requires python,
> bu
erik quanstrom once said:
> On Mon Dec 2 19:51:11 EST 2013, ara...@mgk.ro wrote:
> > On Tue, Dec 3, 2013 at 1:12 AM, erik quanstrom
> > wrote:
> > > python's requirements are a proper subset of go's, since building go
> > > requires
> > > python be installed.
> >
> > No, it doesn't. Using mer
On Mon, Dec 2, 2013 at 5:52 PM, erik quanstrom wrote:
> have you tried in the last couple of months? some changes were made
> that do some repo checking. building requires hg now.
If you put a VERSION file in place manually, it will skip the hg
identify you're talking about.
RE: VERSION file
Even if you do stuff a file in to trick the build process into not
searching for hg, you’re still only a partial participant as you
can’t use the codereview.py scripts to synchronize your source and
submit upstream changes.
I’d really appreciate a Go implementation of git/hg some
On Mon Dec 2 19:16:55 EST 2013, al...@pbrane.org wrote:
> Steve Simon once said:
> > Whne I looked at Go - maybe 2 years ago, I could not see why
> > plan9 would not adopt go's 8c/8l and libbio.
> >
> > obviously others disagree as they have not been back-ported,
> > but why not? - I'am not trol
> all this is moot unless we can get plan 9 integrated into go's automatic
> build system. is this doable? i have resources to make this happen if
> it is.
Let's take note of this, because 9atom certainly deserves attention in
this situation. I'm trying to wrap my mind around the Go builder and
> i thought the language had become more ossified. as time goes on
> this is less and less of a concern. i see more performance changes than
> anything these days.
This is intentional when a release is being prepared. Real changes
will take place once 1.2 (now) is released. Also, keep in mind,
> Why do you hold this opinion? While your defensiveness is hilarious, it's a
> simple matter of curiosity. I'm trying to understand the fervor
> behind another
> language-cum-fashion-accessory. Specifically: how will Go enable good things
> that, say, python has not? Which good things? Are
> Please explain this assertion (e.g. TSEMACQUIRE contradicts it).
This is not intended to offend Bell Labs or anyone at Bell Labs, it
just exposes the difference in focus that may cost us valuable support
from Google: the MIPS port of Plan 9. Personally, I found it quite
exciting, but from a Go
> For example, I've seen many examples of code that calls certain
> functions in the syscall package and just assumes that, e.g.,
> Getrusage is defined everywhere. This is even present in the
> new Go Performance Dashboard code (written by the Go team).
not anymore. the getrusage code was split t
> i'm committed
> to supporting go in 9atom to the extent that it does not compromise
> or corrupt the system substantially.
I can't assist with the details of kernel requirements, but we all
know that Russ, Rob and Ken will know better and be somewhat committed
so that at least Plan 9 release is
> Another thing that can be done is to maintain a separate
> "ports" repository, where you keep patches required to build
> but that are not yet integrated in any upstream repo + any
> other bits to a s/w package in a platform specific manner.
> This is how FreeBSD ports work. Everyone shouldn't ha
> Some coordination among people who are 9fan-gonut, 9fan-godev or 9dev would
> be helpful; at least it will reduce unnecessary head-scratching.
Is there one each of these?! And now go-plan9?!
Do mad people ever scratch their heads?
++L
> python on plan9 can't even handle the codereview extension.
I'll defend Kurt on this one: nor can Go, yet :-)
But I don't know Python, nor care to know it and I happen to like both
Go and Plan 9. To take your side, Skip, Python is very much a
GNU-ism, like a lot of other products that target L
> 1. Addition of TSEMACQUIRE system call. Does it have other applications?
I missed this; is there any documentation that clarifies this issue?
I think it's important to provide a rationale for structural changes
and Bell Labs are a little too glib with their patch releases, in my
opinion.
> 2.
BTW, another big item that I forgot to mention, which ironically has been
the Subject of this thread, is the support for 21bit runes.
On Mon, Dec 2, 2013 at 11:10 PM, wrote:
> > 1. Addition of TSEMACQUIRE system call. Does it have other applications?
>
> I missed this; is there any documentat
> python's requirements are a proper subset of go's, since building go requires
> python be installed.
Not at all, I have no Python installed on any of my Plan 9 equipment
and can build Go and most of its ecology on each of them (there are
other issues, of course). What I can't do is "develop" th
> i object to the macros they have been adding. they haven't been included
> in p9p, either. adding B(put|get)(le|be)(Biobufhdr *b, int width) might
> be an interesting convienence, but what they've got for the sake of 1% on
> micro benchmarks seems to run counter to the plan 9 culture to me.
I
> On Tue, Dec 3, 2013 at 1:12 AM, erik quanstrom wrote:
>> python's requirements are a proper subset of go's, since building go requires
>> python be installed.
>
> No, it doesn't. Using mercurial to clone the tree requires python,
> building Go does not require python, nor mercurial.
>
Actually
> BTW, another big item that I forgot to mention, which ironically has been
> the Subject of this thread, is the support for 21bit runes.
That's water under the mill, is it not?
++L
> And for the libbio changes, I’m more opposed to the four functions
> Bgetle2, Bgetle4, Bputle2, and Bputle4 and the odd use of the
> BPUTC && BPUTLE4 macros. Those implementations are found in other
> portions of the code, not specific to libbio, and seem to be
> grafted on in a slightly off man
Does anyone know what this is about? It makes me think that I forgot
to delete the "9fans" recipient when replying to all, where my
intention was to reply only to Erik, but I can't be sure. If that was
the case, then the moderator may as well just drop the message, it was
somewhat personal.
++L
68 matches
Mail list logo
