Re: [go-nuts] Temporary files in go
linkat() and openat() are posix 2008 standard functions so I wouldn't call this uncommon. As such they are useful to have in Go in one way or the other. The x/unix package is fine for that, though. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I'm not sure whether this way lies madness or whether the madness is the starting point. In a world not corrupted by daily fake news and gratuitous displays of violence and human suffering and animal suffering for the sake of increased profits, the concept of performing some sleight of hand to fool bureaucrats into believing they are buying a "standard" where they are in fact facilitating and promoting lies and deceit, such concept would be revealed for the corrupting norm it is engendering. I certainly would not choose to follow the path suggested here in all earnestness. Lucio. On Friday, 12 October 2018 05:57:39 UTC+2, Beoran wrote: > > So no matter if I say yes or no, both ways are bad? I think is not a very > fair way to argue. > > Anyway, with the Ruby standard you can do either. The Ruby standard > defines that there are strictly conforming Ruby processors, which implement > the standard and conforming Ruby processors which may have any number of > additional implementation defined extensions, alternate syntax and language > features. > > After the standard was written, mruby was implemented to be a strictly > conforming Ruby processor, which doesn't influence or hold back the > development of the other Ruby implementations at all. > > And all other Ruby implementations can be considered confirming, which is > worth millions of $$$ to Ruby developers. The organizations and governments > I mentioned tend to have deep pockets, and the Ruby standard enables us > to gain approval from said bureaucrats. So, we can now use Ruby for these > well funded projects, since now it is an international standard. > > So actually, because the Ruby standard was carefully written to enable > this, it has been win/win for Ruby developers. You can use a strictly > conforming mruby if you like or need to, or use any other Ruby > implementations as conforming ones and please the bureaucrats. > > I consider that we should do the same for Go. When done carefully it will > also be a win/win. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Temporary files in go
Which is not Windows, which is giving up a lot of options, and is important to some people, where as just using tmp files is ok. I am not even sure if windows supports deleting an open file yet. > On Oct 12, 2018, at 3:09 AM, Beoran wrote: > > linkat() and openat() are posix 2008 standard functions so I wouldn't call > this uncommon. As such they are useful to have in Go in one way or the other. > The x/unix package is fine for that, though. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Golang Modules/vgo - local changes push, merge and tags
Hi Guy,
Right now, my understanding is there is not a perfect answer to your
questions.
However, these are very important questions, including I think community
discussion right now can help establish alternative immediate solutions, as
well as help shape how things might work in 1.12 and beyond.
If you haven't already, I would suggest reviewing this thread here:
https://gophers.slack.com/archives/C9BMAAFFB/p1537968235000100
That thread includes comments on some possible current options, some
community tooling that might help, some comments on how one-off tools or
commit hooks might be put together on top of things like 'go mod edit
-json', etc. (That thread also includes a summary of some of the live
discussion issues in the tracker on these topics).
You might then want to comment in that thread (or in this thread) with a
bit more on what might or might not work for you, ideally including some
comments like "gohack doesn't help in our case because X", or "go mod edit
doesn't help us because Y", or "frequent use of semver pre-release tags
doesn't help us because Z". Or maybe you will post "Our solution is A and
B".
Also, towards the end of your post in this thread, you are touching briefly
on some questions of sequencing, and the ordering for publishing two
modules if one module depends on an update in the other module. A brief
comment on that -- one general property of the modules system is 100%
reproducible builds using the information in 'go.mod'. One example of this
is if someone has published module A and module B, and A has a 'require B
v1.2.0', then A will continue to have 100% reproducible builds even if a
newer v1.3.0 of B is later published. An implication of this is that you
can safely publish an update to B without breaking A's build, and then
later publish an update to A that requires the newer B. You can read a bit
more about that in the "High Fidelity Builds" section of the official
proposal (
https://github.com/golang/proposal/blob/master/design/24301-versioned-go.md#update-timing--high-fidelity-builds).
That might or might not help in your situation, but wanted to at least
mention this more general behavior.
In any event, I would encourage you to post more on your topics below,
including because community discussion on these multi-module workflows I
think are an important aspect of working through the current possible
approaches and how the tooling could or should be tweaked in the future.
Best,
--thepudds
On Thursday, October 11, 2018 at 11:31:20 AM UTC-4, Guy Brandwine wrote:
>
> We are trying to use Go-Modules
>
>
>
> We have reusable repo : "github/mycompany/funcs" many repo's use this,
> example : "github/mycompany/eCom/basket.go"
>
>
>
> A new ticket says : "basket should support export to xls" .
>
> In order to do that, we want to :
>
> 1. Add funcs.go a function "StructToXls(interface{})"
>
> 2. basket.go should use funcs.StructToXls(myBasket)
>
>
>
> in the current modules format we need to, push and TAG of funcs and then
> update github/mycompany/eCom dependencies.
>
>
>
> If we have a small bug we would need to repeatedly push and tag funcs,
> update eCom etc.
>
>
>
> Is there a better way (other than go.mod -> replace which is dangerous and
> "developer must remember to use it everytime he changes a basic repo") to
> work locally and when all done push and TAG the 2 repos ?
>
> Moreover, in our current process (git flow style with some modifications)
> the developer only pushes the code to a branch, whereas the TL, approves
> and merges the code.
>
> If the developer tags the library (funcs) locally and does not push that
> (theoretically its not his duty neither he is permitted to do that), that
> may create a false dependency, moreover, two different developer may do
> diff changes in funcs both changing ver from 1.2.3 => 1.2.4 since the
> increment is not centralized (which BTW needs a better tooling anyhow than
> manually inc.).
>
>
>
> A better suggested flow would be greatly appreciated.
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I would not call it deceit, since the Ruby standard does accurately describes a subset of Ruby v1.8. It is more a workaround for institutional rigidity. I guess we would likely be better of without such bureaucracies, but it is utopic to think they will disappear any time soon. The best we can do for now is to enable programmers to use of better programming tools such as Go in such environments. Paperwork is the only language understood there, and that is why a standard would help greatly. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
If Go is to be standardized, it needs to be as late as possible in the development of Go 1. My observations of being involved with some standards is that the participants view it as an opportunity to change or add to whatever is being standardized. Unless the standard was simply a true codification of the existing Go 1 language (e.g., the existing Go compiler is strictly conformant) I think it would do harm to the language. As others have mentioned, it would be best to do this once Go 1 pretty much stops being developed. We certainly don't want a standards organization to essentially define Go++. -Paul On 10/11/18, 10:58 PM, "golang-nuts@googlegroups.com on behalf of Beoran" wrote: So no matter if I say yes or no, both ways are bad? I think is not a very fair way to argue. Anyway, with the Ruby standard you can do either. The Ruby standard defines that there are strictly conforming Ruby processors, which implement the standard and conforming Ruby processors which may have any number of additional implementation defined extensions, alternate syntax and language features. After the standard was written, mruby was implemented to be a strictly conforming Ruby processor, which doesn't influence or hold back the development of the other Ruby implementations at all. And all other Ruby implementations can be considered confirming, which is worth millions of $$$ to Ruby developers. The organizations and governments I mentioned tend to have deep pockets, and the Ruby standard enables us to gain approval from said bureaucrats. So, we can now use Ruby for these well funded projects, since now it is an international standard. So actually, because the Ruby standard was carefully written to enable this, it has been win/win for Ruby developers. You can use a strictly conforming mruby if you like or need to, or use any other Ruby implementations as conforming ones and please the bureaucrats. I consider that we should do the same for Go. When done carefully it will also be a win/win. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
Paul, I fully agree with your ideas on what should be standardized. Either a subset of Go1 or Go1 once Go2 is in full swing. Go++, perish the thought! >_< -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Temporary files in go
If I remember correctly, it would be something like this:
fd = open("/tmp", O_TMPFILE | O_RDWR, 0600);
linkat(fd, "", AT_FDCWD, "/tmp/test", AT_EMPTY_PATH);
This is pretty specific to OS/kernel version and quite possibly the filesystem
too. This could be entirely too much of an edge case to be reasonably done.
- Greg
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
Is an alternate solution to use Go as a source language, then translate to an allegedly "ISO" language? Eric. On Thursday, October 11, 2018 at 8:57:39 PM UTC-7, Beoran wrote: > > So no matter if I say yes or no, both ways are bad? I think is not a very > fair way to argue. > > Anyway, with the Ruby standard you can do either. The Ruby standard > defines that there are strictly conforming Ruby processors, which implement > the standard and conforming Ruby processors which may have any number of > additional implementation defined extensions, alternate syntax and language > features. > > After the standard was written, mruby was implemented to be a strictly > conforming Ruby processor, which doesn't influence or hold back the > development of the other Ruby implementations at all. > > And all other Ruby implementations can be considered confirming, which is > worth millions of $$$ to Ruby developers. The organizations and governments > I mentioned tend to have deep pockets, and the Ruby standard enables us > to gain approval from said bureaucrats. So, we can now use Ruby for these > well funded projects, since now it is an international standard. > > So actually, because the Ruby standard was carefully written to enable > this, it has been win/win for Ruby developers. You can use a strictly > conforming mruby if you like or need to, or use any other Ruby > implementations as conforming ones and please the bureaucrats. > > I consider that we should do the same for Go. When done carefully it will > also be a win/win. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Taking tour.golang.org down for a few minutes
Hi tourists, I have to take the tour down to migrate it to an App Engine service (there is no way to make this change without a minimal amount of downtime). I will follow up when this work has begun. I plan to start it within the hour. It should only be down for a few minutes, but that assumes everything goes smoothly. :) I’ll post updates to this thread. Andy -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
You may need to find a large organization with ISO-only policy to approach the Go team directly, and help staff a standardization effort. If there is already a member of the Go team doing outreach to government and enterprise IT managers, it would be interesting to hear from them re requirements they've heard from this category... On Wednesday, October 10, 2018 at 9:15:30 PM UTC-7, Beoran wrote: > > I understand very well what the risks of standardization can be. Look at > how the C language was maimed during standardization by 104 instances of > undefined behavior. > > But that is not what I am getting at. Five years ago I was somewhat > involved in the effort to make Ruby an ISO standard language. From the get > go it was a largely bureaucratic effort. We specified a common sub set of a > then already old version of Ruby and made enough loopholes to make sure > that any Ruby out there could be considered confirming to the standard. > > Why? You can perhaps not appreciate how powerful the bureaucrats can be in > some countries and corporations. Since Ruby became an ISO standard, I have > been able to convince those bureaucrats to let me use Ruby where I was > barred from doing so before. > > For Go language it is now the same. Bureaucrats don't know Go, and because > it is not standardized, I often encounter a "no go". A Ruby style standard > that would allow developers to check the "ISO standard language" box would > allow us to convince those bureaucrats to let us use Go much more widely. > > Like Michael Jones suggest, we would only standardize Go as it is, and not > use the standardization process to let it decide the language features. And > only update the standard once the new features are settled. That avoids > design by committee as well. > > For these reasons I think, when done properly, the effort will be worth > while in the end. > > Kind Regards, > > B. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Taking tour.golang.org down for a few minutes
This is starting now. On Fri, Oct 12, 2018 at 3:08 PM Andrew Bonventre wrote: > Hi tourists, > I have to take the tour down to migrate it to an App Engine service (there > is no way to make this change without a minimal amount of downtime). > > I will follow up when this work has begun. I plan to start it within the > hour. > > It should only be down for a few minutes, but that assumes everything goes > smoothly. :) > > I’ll post updates to this thread. > > Andy > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Necessity of import constraints for golint
I was wondering if there's a particular reason to enforce importing golint from a certain source (see: https://github.com/golang/lint/commit/9a272034dedb2a3ed05231d5604ce17fb40f0e58). There seems to be a lot of code in "the wild" importing this project from github.com as evinced by a number of closed github issues from users asking why their usual go get isn't working. There's also the issue that the github repo is usually more discoverable by people looking for tooling than the repo(s) at golang.org/x. Given the ease-of-use aspect, is there a compelling reason to prevent people from pulling this from the github mirror? And even if we've already incurred the cost of making this change for golint, is this going to be the standard going forward for everything in golang.org/x? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Taking tour.golang.org down for a few minutes
The migration is complete. Thanks all! On Fri, Oct 12, 2018 at 3:28 PM Andrew Bonventre wrote: > This is starting now. > > On Fri, Oct 12, 2018 at 3:08 PM Andrew Bonventre > wrote: > >> Hi tourists, >> I have to take the tour down to migrate it to an App Engine service >> (there is no way to make this change without a minimal amount of downtime). >> >> I will follow up when this work has begun. I plan to start it within the >> hour. >> >> It should only be down for a few minutes, but that assumes everything >> goes smoothly. :) >> >> I’ll post updates to this thread. >> >> Andy >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Announcing a Fyne GUI toolkit
Hi, Ah I see what you mean. The cross compiled windows file will rely on the efl library, but that can be packaged. This means that it would need to be a bigger distribution than just the exe if you want all deps shipped (I’m not too familiar with the windows terms yet). I’ll try and get a document up about distribution which can explain better and be kept up to date. Thanks, Andrew On 12 Oct 2018, 01:54 +0100, R Srinivasan , wrote: > Thanks a bunch. I will give a serious "go". > > Background - a tool that is command line now. Developed on Linux but typical > user in Windows. Just cross built for windows. Want to add a minimal frontend > - simple dialog. Being like a calculator - don't want to have elaborate > "install" procedures. In the case of the cli - one .exe is all it takes. > > will experiment and report back. > > srini > > On Thursday, October 11, 2018 at 3:54:29 PM UTC-4, Andrew Williams wrote: > > Hi, > > > > Great questions, thanks! > > > > 1. We can bundle in the libraries for Windows and for macOS - but on linux > > probably not (unless your app is LGPL/GPL due to a licensing issue that I > > have not found a better solution to). But distribution on Linux it is > > normal to depend on external libraries :). > > There will be a tool included to package final binaries, but I have not got > > it to a satisfactory level to share yet. > > > > 2. Yes, we should be able to do cross-compilation using the standard Go > > tools. There is the usual challenge of enabling CGO for a GOOS build, but > > beyond that it should be OK. It's easier than, for example, andlabs UI as > > we are not linking to OS specific functionality, just the libefl > > abstraction. > > > > Point 2 may change over time - as we may wish to add certain OS abstraction > > directly which may make cross compilaton harder. > > > > What I was thinking about, however, was creating some app metadata format > > and a centralised build server to work around both build and package > > distribution issues... > > > > I hope that helps, > > Andrew > > > > > On Sat, 6 Oct 2018 at 11:41 R Srinivasan wrote: > > > > 1. What are the "distribution" considerations? > > > > > > > > Considering Windows targets - can we have all the required > > > > libraries bundled in the final executable? > > > > > > > > 2. Can the apps be cross built? i.e. Built on Linux for macOS and > > > > windows`targets? > > > > > > > > thanks for pointers, srini > > > > > > > > > > > > On Friday, September 14, 2018 at 1:17:00 PM UTC-4, Andrew Williams > > > > wrote: > > > > > Hi, > > > > > > > > > > Some time ago I realised that Go was a great language for building > > > > > new applications, as I wanted to use something powerful but fast to > > > > > learn. I also wanted a really simple to use GUI toolkit that worked > > > > > cross platform - this was a little more difficult to satisfy! > > > > > > > > > > The aim was to create an API that was: > > > > > > > > > > • Simple to learn > > > > > • Great looking with theme options > > > > > • Truly cross platform with identical look across platforms > > > > > • Solved all of the complicated GUI challenges (threading, scaling > > > > > etc) > > > > > > > > > > And so the Fyne project was created https://github.com/fyne-io/fyne ! > > > > > The design language is basically material design and the rendering is > > > > > currently EFL with support for Windows, macOS and Linux. > > > > > It's entirely vector based (though you can draw a Raster space if you > > > > > need) and scales beautifully. > > > > > > > > > > For a taste of what that looks like here you go :) > > > > > > > > > > > > > > > It's now well into development and ready for people to get involved. > > > > > There is a long way to go but it feels like a solid base. > > > > > Instructions for getting started, if you need them, are at > > > > > https://github.com/fyne-io/bootstrap/blob/master/README.md . > > > > > If you want to know more we're also in the #fyne channel on the > > > > > gopher Slack server. > > > > > > > > > > Thanks in advance for your thoughts :) > > > > > Andrew > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "golang-nuts" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to golang-nuts...@googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > > -- > > http://andywilliams.me > > http://ajwillia.ms > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nu
Re: [go-nuts] Go language should become an ANSI and ISO standard.
On Fri, Oct 12, 2018 at 12:21 PM, Liam wrote: > > If there is already a member of the Go team doing outreach to government and > enterprise IT managers, it would be interesting to hear from them re > requirements they've heard from this category... That is a fair question. At present the concern expressed here seems to be hypothetical. Does anybody know of any real projects that would prefer to use Go but can't because there is no official international standard? Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Necessity of import constraints for golint
On Fri, Oct 12, 2018 at 11:29 AM, wrote: > > I was wondering if there's a particular reason to enforce importing golint > from a certain source (see: > https://github.com/golang/lint/commit/9a272034dedb2a3ed05231d5604ce17fb40f0e58). > There seems to be a lot of code in "the wild" importing this project from > github.com as evinced by a number of closed github issues from users asking > why their usual go get isn't working. There's also the issue that the github > repo is usually more discoverable by people looking for tooling than the > repo(s) at golang.org/x. Given the ease-of-use aspect, is there a compelling > reason to prevent people from pulling this from the github mirror? And even > if we've already incurred the cost of making this change for golint, is this > going to be the standard going forward for everything in golang.org/x? In Go, packages are determined by their import path. That is, using two different import paths means two different packages, even if the source code is identical. So, as a general rule, it's a good idea for any package to enforce that it is imported under a particular import path. The vendoring and modules support are designed to support this. So I'm going to turn the question around: is there a reason to not do this for golint? Clearly anybody who really wants a separate copy can remove the import comment. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
In my opinion, currently there is no need for Go 'standardization'. There aren't multiple implementation of Go where each vendor is eager to add their own features and promote their own version of Go. In fact, by giving up control to a committee (especially during this early stage of the language - Go is still version 1 and barely version 2), it risks the language development spiralling out of control, becoming the next C++. I say keep it as it is for the time being. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
