Ios disallows dynamic code generation at runtime - what other environments could Go target with these restrictions?
Native Client, Android, ummm, pretty much any environment that is encapsulated in a sandbox.
Go 1.1 Function Calls
11–20 of 34 posts
Re: Go 1.1 Function Calls
#12Re: Go 1.1 Function Calls
#13OT: if Google thinks you have an account (based on a cookie I guess) it requires you to login to access this document. So you either need to login or delete the cookie or enable incognito/private mode to access the document. Why doesn't google treat non-logged in users the same as those w/o an account?
> Why doesn't google treat non-logged in users the same as those w/o an account? I wager what they actually want to do is treat those without an account the same as those who are not logged in, but realize they can't get away with that quite yet. (That is to say, I suspect that they would like to turn away all users without accounts.)
That's a baseless assertion.
I'd assume (and I have no insider knowledge) that it's because Google assumes if you have a Google account that you probably want to be logged into it when using Google products. Otherwise it would suck if you tried to do something that requires an account and were told "log in" and then had to refresh the page, potentially losing state. The up-front login avoids some usability issues there. (Of course there are many ways to approach this, this is merely my hypothesis.)
Re: Go 1.1 Function Calls
#14Russ Cox is a g'damn genius. You can spend hours being fascinated by his code and writing: http://research.swtch.com/
Not only that, he's really helpful on the Golang Google group in answering questions to all programmers, new & old. What really hooked me onto Go was both the helpfulness of the Google group as well as the nice people on #gonuts.
> What really hooked me onto Go was both the helpfulness of the Google group as well as the nice people on #gonuts
Same here, which is why I like to idle in the channel when possible (and occasionally answer questions when I can).
People often underestimate how much impact the community behind a language has. The Go community has been one of the friendliest, and also one of the most willing to share its knowledge.
FYI, it's #go-nuts, just in case anybody reading this is inspired to check it out.
Re: Go 1.1 Function Calls
#15Earlier quoted context omitted.
> Why doesn't google treat non-logged in users the same as those w/o an account? I wager what they actually want to do is treat those without an account the same as those who are not logged in, but realize they can't get away with that quite yet. (That is to say, I suspect that they would like to turn away all users without accounts.)
That's a baseless assertion. I'd assume (and I have no insider knowledge) that it's because Google assumes if you have a Google account that you probably want to be logged into it when using Google products. Otherwise it would suck if you tried to do something that requires an account and were told "log in" and then had to refresh the page, potentially losing state. The up-front login avoids some usability issues the…
In this case though, it'd really benefit from being visible — all non-editable views into public google docs should be accessible
Re: Go 1.1 Function Calls
#16Ios disallows dynamic code generation at runtime - what other environments could Go target with these restrictions?
[deleted]
Re: Go 1.1 Function Calls
#17Ios disallows dynamic code generation at runtime - what other environments could Go target with these restrictions?
I think Windows 8.0 or 8.1 Store application do not allow it.
Re: Go 1.1 Function Calls
#18Earlier quoted context omitted.
> Why doesn't google treat non-logged in users the same as those w/o an account? I wager what they actually want to do is treat those without an account the same as those who are not logged in, but realize they can't get away with that quite yet. (That is to say, I suspect that they would like to turn away all users without accounts.)
That's a baseless assertion. I'd assume (and I have no insider knowledge) that it's because Google assumes if you have a Google account that you probably want to be logged into it when using Google products. Otherwise it would suck if you tried to do something that requires an account and were told "log in" and then had to refresh the page, potentially losing state. The up-front login avoids some usability issues the…
Both of us have just as much evidence. A baseless suspicion is all that I intended to give.
Re: Go 1.1 Function Calls
#19Earlier quoted context omitted.
Native Client, Android, ummm, pretty much any environment that is encapsulated in a sandbox.
Ah yes, Native Client. I assume Android allows it since it runs V8.
I guess Android has a different kind of sandbox than most typical software fault isolation based sandboxes (e.g. NaCl).
Its more reminiscent of plan9's per process namespaces than anything else. http://plan9.bell-labs.com/sys/doc/names.html
Regardless, the main issue that was preventing Go from running on Android was the linker's inability to link go pkgs as a shared library. Fortunately support for external linking on ARM is scheduled to land in the go1.2 release.
http://tip.golang.org/doc/go1.2#gc_changes
When it comes to go support for NaCl, llgo is imho the most promising solution for that. http://github.com/axw/llgo
Re: Go 1.1 Function Calls
#20Ios disallows dynamic code generation at runtime - what other environments could Go target with these restrictions?
iOS actually doesn't have a restriction as strict as this: you can take a page of memory and map it again without issue. This is the technique used by imp_implementationWithBlock, and current versions of libffi can generate closures based on the technique.