Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 memmove fix into a separate CL. The patch sets that you'll need to build Go 1.2 on Plan 9 are: cmd/8g: work around 64-bit bug in 8c for Plan 9 https://codereview.appspot.com/14521056 build: do not use the host's libbio on Plan 9 https://codereview.appspot.com/14604047 runtime: do not use memmove in the Plan 9 signal handler https://codereview.appspot.com/34640045 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: https://code.google.com/p/go-wiki/wiki/PortingPolicy If you want to help with this effort, please join the go-plan9 mailing list (https://groups.google.com/d/forum/go-plan9). Cheers, Anthony
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 demotivation in open source as powerful as a threat. 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? personally, i think a preemtive strike is in order. a lot of time has been spent chasing basic broken-with-merge issues, the rather superfluous libbio macros, the self-inflicted memmove problem, &c. those are just recent issues. given the rate of go development, i would think this is likely to continue. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 threat, only lack of builders is continuous: that the build may break and be neglected for a while is not as serious as knowing that no one is paying attention or, worse, that no one even knows that there is a problem. But the port is also in trouble. I dread the need to reconcile Gorka's work on ARM with the 1.2 release, I don't really know where to start. And as far as 386 and amd64 goes, I don't even know or grasp what ails the Bell Labs release (and I agree with you that the most recent adjustments are feeble at best), nevermind where we're standing with 9atom, 9front and the few other versions out in the wild. The solution is not with "open source" but with rolling up one's sleeves and figuring out how to converge as much as possible the different offerings. I don't think Go needs to be thrown away, I think it is a motivating force itself, but in this particular case we need some leadership to guide short-term development in a better direction. Listing the outstanding issues, technical or political, would be my starting point, but I was not involved in most of the (not so) recent in-fighting and I don't know how that ought to be resolved. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 and lack of perhaps we're seperated by a common language. "standing" in the sense that for each new release does the same condition hold: if it does not pass all the tests, it is evicted from the main line. > The solution is not with "open source" but with rolling up one's > sleeves and figuring out how to converge as much as possible the given that most of the time is spent bailing water out of the boat, and fixing things that weren't previously broken, it seems to me that like anything it's a two-way street. anyway, what's the argument for not just forking? - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 young enthusiastic 9fans to contribute meaningful work in a shorter time that would otherwise be required (e.g. mastering C, etc.). I think, in the long run, the pain of the teething problems are worth the effort. 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. On Mon, Dec 2, 2013 at 6:33 AM, erik quanstrom wrote: > > 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 demotivation in open source as powerful as a threat. > > 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? > > personally, i think a preemtive strike is in order. a lot of time > has been spent chasing basic broken-with-merge issues, the > rather superfluous libbio macros, the self-inflicted memmove > problem, &c. those are just recent issues. given the rate of go > development, i would think this is likely to continue. > > - erik > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 definitely bother me enormously. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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, they hold the fate of Plan 9 in their hands and it may be necessary to snatch it from their grasp. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 patch that let us keep our version of libbio (https://codereview.appspot.com/15750047/) and still pick up the required four new functions that happen to be replicated elsewhere. Neither patch is ideal, and neither has made progress in getting rolled into the release. 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 to keep up again. So either we start posting codereview emails to the 9fans list, or we find a better way to collaborate and make Plan 9 a first tier target for Go. On Dec 2, 2013, at 10:10 AM, Skip Tavakkolian wrote: > 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 > young enthusiastic 9fans to contribute meaningful work in a shorter time that > would otherwise be required (e.g. mastering C, etc.). I think, in the long > run, the pain of the teething problems are worth the effort. > > 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.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 to > keep up again. So either we start posting codereview emails to the 9fans > list, or we find a better way to collaborate and make Plan 9 a first tier > target for Go. 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 development so that we can fill gaps when they arise. For example, I have no idea where Anthony Martin is heading with the notes code, but I am aware that he is probably ahead of the pack in that direction. Should I spot something in golang-dev that I understand may affect coding Plan 9's note handling for Go, I would like to be able to alert him. Not knowing how closely he himself monitors golang-dev, or how much he would appreciate being nagged, right now I err on the side of caution. It will take time to build a team of contributors that is familiar with everyone else's role, but that is a good reason to get cracking now, rather than later. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 development so that we can fill gaps when they arise. > > For example, I have no idea where Anthony Martin is heading with the > notes code, but I am aware that he is probably ahead of the pack in > that direction. Should I spot something in golang-dev that I > understand may affect coding Plan 9's note handling for Go, I would > like to be able to alert him. Not knowing how closely he himself > monitors golang-dev, or how much he would appreciate being nagged, > right now I err on the side of caution. > > It will take time to build a team of contributors that is familiar > with everyone else's role, but that is a good reason to get cracking > now, rather than later. 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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 forking, but losing the code review > by a community of experts will definitely bother me enormously. 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. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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 all of them web based? I'm not asking this idly. I have resources available for projects like this, but I'm tired of wasting them on projects that go nowhere once the developers' attention span shifts to whatever hip new thing is promoted by $COMPANY. khm
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 coordination. > > We will almost certainly need more focus from Bell Labs or at least > less reluctance. More than ever, they hold the fate of Plan 9 in > their hands and it may be necessary to snatch it from their grasp. > > ++L > > > > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 system. is this doable? i have resources to make this happen if > > it is. if so, something's gone very wrong. usually the purpose of automatic build machines it to insure that things build and hopefully pass a few basic tests before the code can be checked in. i'd assumed that this was not working since clearly the plan 9 386 port is broken on a regular basis. if this can't be sorted out, then tracking mainline go is going to be quite hard, maybe even impractical. it's so much harder to get things fixed after code is merged than before. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 du Colombier. My Plan 9 install needs a little love, but it's almost ready for full-time dev. I have some spare cycles to work on the port, too. I feel strongly that we can get the port in shape by the March 1 deadline. -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 have provided systems for this purpose. > > > > > > On Mon, Dec 2, 2013 at 10:33 AM, erik quanstrom < > quans...@labs.coraid.com>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. > > if so, something's gone very wrong. usually the purpose of automatic > build machines it to insure that things build and hopefully pass a few > basic > tests before the code can be checked in. i'd assumed that this was not > working > since clearly the plan 9 386 port is broken on a regular basis. > > if this can't be sorted out, then tracking mainline go is going to be quite > hard, maybe even impractical. it's so much harder to get things fixed > after > code is merged than before. > > - erik >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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, they hold the fate of Plan 9 in > > their hands and it may be necessary to snatch it from their grasp. i don't think that's a contradiction. it's a datapoint. a generalization can't be made without a number of datapoints. the generalization isn't useful though. let's have a list of things that need doing on the plan 9 side, and let's see if those demands on the system are really reasonable. i'm committed to supporting go in 9atom to the extent that it does not compromise or corrupt the system substantially. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 anything changed, to rebuild and mail if there are any essential differences from previous run. Requires no additional cooperation from anyone else and can work for catching breakage early in any third party software. 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 have to track down patches and try merging them individually.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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 anything changed, to rebuild and mail if > there are any essential differences from previous run. > > Requires no additional cooperation from anyone else and can > work for catching breakage early in any third party software. > > 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 have to > track down patches and try merging them individually. > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 > > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 does not. it's on bitbucket. > > - erik > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> > 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 up-to-date binaries (Python 2.7.5 and Mercurial 2.8.1) for Plan 9: http://www.9legacy.org/download/cpython.mkfs.bz2 -- David du Colombier
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 > modern Python port. > > If you are afraid to compile it, I'm providing up-to-date > binaries (Python 2.7.5 and Mercurial 2.8.1) for Plan 9: it won't compile unless you're running 9atom. or have integrated the (extensive) changes to ape, especially in the sockets area. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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 up-to-date > > binaries (Python 2.7.5 and Mercurial 2.8.1) for Plan 9: > > it won't compile unless you're running 9atom. or have integrated > the (extensive) changes to ape, especially in the sockets area. Another reason to break out ports. Ideally they should work any plan9 fork.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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/notes -- David du Colombier
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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' 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 up-to-date > > > binaries (Python 2.7.5 and Mercurial 2.8.1) for Plan 9: > > > > it won't compile unless you're running 9atom. or have integrated > > the (extensive) changes to ape, especially in the sockets area. > > Another reason to break out ports. Ideally they should > work any plan9 fork. i don't see how that follows. changes were needed to ape. the patches are sitting in /n/sources/patch. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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 up-to-date > > > > binaries (Python 2.7.5 and Mercurial 2.8.1) for Plan 9: > > > > > > it won't compile unless you're running 9atom. or have integrated > > > the (extensive) changes to ape, especially in the sockets area. > > > > Another reason to break out ports. Ideally they should > > work any plan9 fork. > > i don't see how that follows. changes were needed to ape. > the patches are sitting in /n/sources/patch. 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 mk any dependencies. One of which can pull in changes for ape. Right now all this seems rather manual. As more changes are merged back in the upstream sources, port diffs can reduce.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 mk any dependencies. One > of which can pull in changes for ape. Right now all this seems > rather manual. As more changes are merged back in the upstream > sources, port diffs can reduce. patches are the plan 9 standard way of doing things. they've been submitted, and can be applied by anyone. or, you can run 9atom. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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 up-to-date > > binaries (Python 2.7.5 and Mercurial 2.8.1) for Plan 9: > > it won't compile unless you're running 9atom. or have integrated > the (extensive) changes to ape, especially in the sockets area. > > - erik > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 Python? :) > > (sorry, couldn't resist) >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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! this is a big difference with go. more details to come. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 neglected. many of these changes were not strictly necessary for the python port. none are really python specific. they fix broken things in ape. go needs new system calls, and makes other demands, like the silly libbio macros. here's a highlevel overview of what was done. stars by the necessary changes: *0. support for ssl was added to ape by importing mp, sec, bio into ape. also compile crypt from /sys/src/libc/port (necessary to avoid using openssl) *1. was moved to /$objtype/include/ape because it's not portable. (necessary for amd64 port) *2. inet_ntop, inet_pton, getaddrinfo (and friends) were added. python doesn't work well with old-style name lookup. *3. all the system calls have had their signatures corrected e.g.: - externint _RENDEZVOUS(unsigned long, unsigned long); + externvoid* _RENDEZVOUS(void*, void*); this is required for amd64. change brk() and _buf() accordingly. *4. fix frexp, modf, (endian issues, subnormal #s) and copysign(). *5. make a lame attempt to deal with wait4() vs rfork. *6. _IO_getc needs to return EOF on eof. *7. fix %p for 64-bit add vfscanf in stdio; use USED() not #pragma ref *8. getsrvbyaddr() remember that htons! *9. further envp rework. *10. socketpair: wrong signature. and unnecessary but helpful fixes: 0. all ape compoents are built with -VTw to prevent simple linker mistakes. snprintf() now always uses the c99 definition to prevent link errors with -T. *1. support for ssl was added to ape by importing mp, sec, bio into ape. (necessary to avoid using openssl) *2. was moved to /$objtype/include/ape because it's not portable. (necessary for amd64 port) 3. ip6 support was added. *4. inet_ntop, inet_pton, getaddrinfo (and friends) were added. python doesn't work well with old-style name lookup. 5. librexexp was fixed in line with fixes to the normal lib. 6. Rune and wchar_t are an uint/int for 21-bit runes. decode 21-bit runes in mbwc.c 7. getcallerpc/getfcr implemented for all arches. 8. make qsort 64-bit safe. 9. fix const in strcspn, strpbrk, strrchr, strspn, strstr, rename, pathconf 10. fix types in setuid, setgid, signal, mkfifo, getgrent, getpwent 11. fix conflict between bind() [libdraw] and bind [socket]. 12. fmt: fix %p; fix %C (21-bit rune) 13. utf: 21-bit runes 14. libv: fix impossible definition of nap(). - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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: Plan 9 is a burden for the developers and lack of > > perhaps we're seperated by a common language. "standing" in the sense > that for each new release does the same condition hold: if it does not > pass all the tests, it is evicted from the main line. Yes. The relevant statement from the new policy is: If a builder fails for more than four weeks or is failing at the time of a release freeze, and a new maintainer cannot be found, the port will be removed from the tree. Due to backwards compatibility concerns, removing a formerly working port should be a last resort. Finding a new maintainer is always preferable. As of now, both Aram and I are willing to be active maintainers. (He's just finishing up the Solaris port). > > The solution is not with "open source" but with rolling up one's > > sleeves and figuring out how to converge as much as possible the > > given that most of the time is spent bailing water out of the boat, > and fixing things that weren't previously broken, it seems to me that > like anything it's a two-way street. > > anyway, what's the argument for not just forking? I think forking would actually *increase* the maintenance burden for us, assuming we want to keep up with point releases. We would still have to track the changes from upstream and we'd no longer even be on the Go team's radar. This would naturally result in more Unix-based assumptions that we'd have to deal with. 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). Anthony
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 them on.
To the best of my knowledge, until now the following are the changes to
Plan 9 and/or Go to support Go on Plan 9. Do these seem onerous?
1. Addition of TSEMACQUIRE system call. Does it have other applications?
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.
3. Modifications to 8g to get around an 8c bug (for the curious, see the
test case from Anthony that reproduces it, below). Go team accepted the
patch to get around this, even though it is a bug in Plan 9's 8c.
4. modification to get around having to use runtime·memmove in
runtime·sighandler
(for the curious, this is because runtime·memmove uses SSE MOVOU
instructions, which touch XMM registers).
* Repro for Plan 9 8c bug:
unsigned long long x;
int f(int);
void
test(void)
{
int a;
a = f(a-x+a);
}
On Mon, Dec 2, 2013 at 1:51 PM, erik quanstrom wrote:
> 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 neglected. many
> of these changes were not strictly necessary for the python port.
> none are really python specific. they fix broken things in ape.
> go needs new system calls, and makes other demands, like the
> silly libbio macros.
>
> here's a highlevel overview of what was done. stars by the necessary
> changes:
>
> *0. support for ssl was added to ape by importing mp, sec, bio into
> ape. also compile crypt from /sys/src/libc/port (necessary to avoid using
> openssl)
>
> *1. was moved to /$objtype/include/ape because it's not
> portable. (necessary for amd64 port)
>
> *2. inet_ntop, inet_pton, getaddrinfo (and friends) were added.
> python doesn't work well with old-style name lookup.
>
> *3. all the system calls have had their signatures corrected e.g.:
> - externint _RENDEZVOUS(unsigned long, unsigned long);
> + externvoid* _RENDEZVOUS(void*, void*);
> this is required for amd64. change brk() and _buf() accordingly.
>
> *4. fix frexp, modf, (endian issues, subnormal #s) and copysign().
>
> *5. make a lame attempt to deal with wait4() vs rfork.
>
> *6. _IO_getc needs to return EOF on eof.
>
> *7. fix %p for 64-bit add vfscanf in stdio; use USED() not #pragma ref
>
> *8. getsrvbyaddr() remember that htons!
>
> *9. further envp rework.
>
> *10. socketpair: wrong signature.
>
> and unnecessary but helpful fixes:
>
> 0. all ape compoents are built with -VTw to prevent simple linker
> mistakes. snprintf() now always uses the c99 definition to prevent link
> errors with -T.
>
> *1. support for ssl was added to ape by importing mp, sec, bio into
> ape. (necessary to avoid using openssl)
>
> *2. was moved to /$objtype/include/ape because it's not
> portable. (necessary for amd64 port)
>
> 3. ip6 support was added.
>
> *4. inet_ntop, inet_pton, getaddrinfo (and friends) were added.
> python doesn't work well with old-style name lookup.
>
> 5. librexexp was fixed in line with fixes to the normal lib.
>
> 6. Rune and wchar_t are an uint/int for 21-bit runes. decode 21-bit
> runes in mbwc.c
>
> 7. getcallerpc/getfcr implemented for all arches.
>
> 8. make qsort 64-bit safe.
>
> 9. fix const in strcspn, strpbrk, strrchr, strspn, strstr, rename,
> pathconf
>
> 10. fix types in setuid, setgid, signal, mkfifo, getgrent, getpwent
>
> 11. fix conflict between bind() [libdraw] and bind [socket].
>
> 12. fmt: fix %p; fix %C (21-bit rune)
>
> 13. utf: 21-bit runes
>
> 14. libv: fix impossible definition of nap().
>
> - erik
>
>
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 binaries (with crypto signatures if you > > care) etc. As part of this it can mk any dependencies. One > > of which can pull in changes for ape. Right now all this seems > > rather manual. As more changes are merged back in the upstream > > sources, port diffs can reduce. > > 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.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 executables seemed a huge plus - I use windows less these days but it would still be handy on ocasion. -Steve
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> > 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? what is lacking in that approach? - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 them on. python's requirements are a proper subset of go's, since building go requires python be installed. > 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|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. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 wholesale because of incompatible Go-specific changes; e.g., disallowing variadic C functions without a #pragma annotation, a different symtab/pclntab format, etc. It would take a fair bit of work to make everything (including libmach) backwards-compatible. Anthony
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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|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. The claim was a bit stronger than that: https://code.google.com/p/go/source/detail?r=1ee3ab13e3b6 but I still agree with you. Anthony
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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, > building Go does not require python, nor mercurial. have you tried in the last couple of months? some changes were made that do some repo checking. building requires hg now. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 mercurial to clone the tree requires python, > > building Go does not require python, nor mercurial. > > have you tried in the last couple of months? some changes were made > that do some repo checking. building requires hg now. The standard way to get around this requirement is by placing a VERSION file in the top-level directory. It can contain any string but it's usually something like: devel +7326da92ff4d Mon Dec 02 09:06:41 2013 +1100 Cheers, Anthony
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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: [9fans] Go and 21-bit runes (and a bit of Go status)
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 somewhere down the line. 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 manner. That said, I’ll gladly change my mind if the p9p, Inferno, and a few other forks of the libbio source give it their blessing. To date, none have chimed in to contribute to the conversation in any way so I’m more than happy to use a patch in Go to still use Plan 9’s libbio but pull in the four new functions and the macros and go from there.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 trolling, genuine question. > > We couldn't adopt the Go ?[acl] toolchain wholesale > because of incompatible Go-specific changes; e.g., > disallowing variadic C functions without a #pragma > annotation, a different symtab/pclntab format, etc. > > It would take a fair bit of work to make everything > (including libmach) backwards-compatible. i think one could avoid the backwards-compatibity. simple change the formats and recompile the system. the other problems in principle are superficial. the real question that needs adressing is what is plan 9, and what makes it useful. for me, i think having a self-contained system that takes over as early as it can in the boot process with all the source in /sys and all the source part of the system, and not subject to forces outside plan 9, is valuable. the code is amazingly stable, and it's not too hard for one person to have a pretty good grasp of the system. this is super powerful. instead of putting mental energy in boxing up hard-to-understand and perhaps not essential bits of the system so one doesn't have to think about how they work, one can know how those bits work and put their quirks to good use. or even change them. instead of building another layer on top (to avoid knowing about lower layers), relatively speaking, plan 9 makes it trivial to get in and do what needs to be done. it may be that replacing the compilers with something externally controlled is not that much of a set back and all told one gains more than one loses. even if that is the case, i'm not sure i'd be okay with the ensuing churn. - erik
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 it would seem to me that even though the platforms are different, we could categorise builders under the plan 9 label. If that's the case, then at least we can get a bird's eye view of progress if enough contributors take part. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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, as Skip points out, that the Go ecosystem is much greater than the language and is itself good cause to adopt the language. In my opinion, very, very good cause. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 all of them web based? > Stop being sarcastic and you may stop seeing defensiveness and hilariousness, too. As for the Go-vs-Python issue, (a) Python was latest-"language-cum-fashion-accessory" itself not too long ago and (b) enough has been written about it elsewhere by more competent people than myself; I'm sure you can refer to that literature rather than expect me to botch a description here. > I'm not asking this idly. I have resources available for projects like this, > but I'm tired of wasting them on projects that go nowhere once the developers' > attention span shifts to whatever hip new thing is promoted by $COMPANY. I guess you would not like me to read "for COMPANY=Google shift span" in the above, but I did and others probably too. The challenge is out there, $COMPANY does not want to allocate funding to the Plan 9 port of Go and Plan 9 and Dragonfly BSD have been found wanting with regard to the support needed by the developers to get their work done. That has caused the entry bar to be raised and I believe that is fair, if inconvenient. If you can contribute resources to the project, we may all be grateful, but if they come with strings attached such as the need to tolerate your sarcasm, I suspect some of us may well prefer to refuse them. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 perspective it was insignificant. Bell Labs are perfectly entitled to choose their projects and I would never had raised this matter had I not been challenged to. What I'm trying to convey is a need for Bell Labs to make it easier for the Go contributors to make progress with the few issues that have arisen (5c's vlong switch labels, libbio, floating point instructions in syscalls, complex expressions in 8c, etc.), but I don't really know how they should do that. Abandoning MIPS development obviously isn't one such option. maybe taking Go more seriously or at least communicating regularly with the Go developers community might well be. Again, no offence intended, I'm just pacing out the territory. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 to _unix.go just now.
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 not going to be "compromised" by anything Go is going to need. You're also overlooking the fact that OSX, the *BSDs and even some Windows flavours are actively supported (and Solaris is threatening) so if anything compromises will be towards generality not specialisation (in other words, no one will try to turn Plan 9 into Linux). But (a) your concerns are reasonable and need to be kept sight of and (b) your idea of listing the necessary changes to Plan 9 dovetails very much with my idea on how to move forwards from here. I do wish we could get Bakul Shah and Anthony Martin to document what they are working on; and Gorka to document or at least describe to me, so I can try to document what his focus was when he was still working on the plan9/arm port. All of the above would be immensely helpful, in my opinion. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 have to > track down patches and try merging them individually. If the Go builders system wasn't already in place, that would have great merit, but as things stand, short of providing a better system for the Go developers to adopt (a dream, but not a very practical one - I'm not in love with Mercurial, Python or any other immense GNU-ish package), we may as well encourage everyone to use what is known to work adequately. If you feel we can do better and you are prepared to defend your case, this (or the go-plan9 google group) will be a reasonable platforms to present it. I, for one, will be willing to hear about any such option. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 Linux almost exclusively. Go can break that pattern. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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. 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. The functions are very readily added to libbio without side effects. The macros, on the other hand, are an embarrassment and trigger dozens of warnings (to the best of my ability to check). There really ought to be no warnings in compiling the Go tool chain for Plan 9; the bison-related stuff deserves some attention, too. > 3. Modifications to 8g to get around an 8c bug (for the curious, see the > test case from Anthony that reproduces it, below). Go team accepted the > patch to get around this, even though it is a bug in Plan 9's 8c. The patch was a bit of a scream. I'm the first to admit that 8c needs a touch of TLC and that an abort() in the middle of a compiler, without the slightest attempt to deal with the problem is at least as embarrassing as the expansion of BGETLE, but the original code that tripped the compiler was also extremely shoddy. And the Go developers' resistance to rewrite a few badly thought out lines of code did come back to bite them in the ass. > 4. modification to get around having to use runtime·memmove in > runtime·sighandler The right answer here is to have a plan9·memmove until Bell Labs figure a way to classify some opcodes as other than floating point and allow them where the architecture permits it. It's a big problem, but it needs to be addressed, the world of CPU extensions is still young and, sadly, not still-born. The Go developers will eventually need to adjust to this reality too. Arm64 is a hint of things to come. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
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 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. 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. > > The functions are very readily added to libbio without side effects. > The macros, on the other hand, are an embarrassment and trigger dozens > of warnings (to the best of my ability to check). There really ought > to be no warnings in compiling the Go tool chain for Plan 9; the > bison-related stuff deserves some attention, too. > > > 3. Modifications to 8g to get around an 8c bug (for the curious, see the > > test case from Anthony that reproduces it, below). Go team accepted the > > patch to get around this, even though it is a bug in Plan 9's 8c. > > The patch was a bit of a scream. I'm the first to admit that 8c needs > a touch of TLC and that an abort() in the middle of a compiler, > without the slightest attempt to deal with the problem is at least as > embarrassing as the expansion of BGETLE, but the original code that > tripped the compiler was also extremely shoddy. And the Go > developers' resistance to rewrite a few badly thought out lines of > code did come back to bite them in the ass. > > > 4. modification to get around having to use runtime·memmove in > > runtime·sighandler > > The right answer here is to have a plan9·memmove until Bell Labs > figure a way to classify some opcodes as other than floating point and > allow them where the architecture permits it. It's a big problem, but > it needs to be addressed, the world of CPU extensions is still young > and, sadly, not still-born. > > The Go developers will eventually need to adjust to this reality too. > Arm64 is a hint of things to come. > > ++L > > > > >
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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" the tool chain, for that I use Python/Mercurial/Codereview on a NetBSD host and, where sometimes git is required, I use my Ubuntu workstation. It's a mess, of course, but I manage to maintain some sort of discipline despite it all. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 am totally with you on this one. But the macros are in , so we may be able to avoid them. They are obscene and trigger many annoying warnings. ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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, how do you resolve the VERSION file problem? Go will not build from a perfectly clean hg clone without a working "hg". ++L
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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
Re: [9fans] Go and 21-bit runes (and a bit of Go status)
> 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 manner. That said, I’ll gladly > change my mind if the p9p, Inferno, and a few other forks of the > libbio source give it their blessing. To date, none have chimed > in to contribute to the conversation in any way so I’m more than > happy to use a patch in Go to still use Plan 9’s libbio but pull > in the four new functions and the macros and go from there. I'd like to hear more from you about the (mis)use of Bgetle* and friends (not the macros, we all agree on these). I think we ought to prepare a submission to Bell Labs for a reasoned inclusion of these functions in the library (and the corresponding B*be ones, which for some reason Go does not need (?!)). As for the macros, I know Russ was never in favour of using them, we may have a case to have them rescinded :-) I suspect that they would all have been dropped, if Russ had known where to look for them. If memory serves, he reverted a CL, but not all pertinent CLs, possibly on request from (members of) the Plan 9 faction. ++L
Re: [9fans] Your message to 9fans awaits moderator approval
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 > From: 9fans-boun...@9fans.net > Date: Tue Dec 3 07:18:48 SAT 2013 > To: lu...@proxima.alt.za > Subject: Your message to 9fans awaits moderator approval > > Your mail to '9fans' with the subject > > Re: [9fans] Go and 21-bit runes (and a bit of Go status) > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Too many recipients to the message > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > http://mail.9fans.net/confirm/9fans/1d04b7466c16626f9c593507ed729dc5596e8f01
