from:"⚛"

[go-nuts] Deploying Translated Golang Tour on AppEngine: Questions

2024-06-13 Thread Daniel Castillo



Hello everyone,

I am currently working on translating the Golang Tour (Introduction Guide 
to Golang) into Spanish. As part of this project, I have a couple of 
questions regarding the deployment pipeline of the Golang Tour on AppEngine:

   1. Is anyone familiar with the deployment pipeline for the Golang Tour 
   on AppEngine?
   2. When the tour is deployed, does it remain within some kind of free 
   tier?

I appreciate any insights or advice you can offer.

Thank you!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/07349e45-f3cd-44c4-89fb-a8dd94c78bd6n%40googlegroups.com.

[go-nuts] Re: `go fix ./...` in go1.22.4 is reporting invalid go version

2024-06-13 Thread David Ševčík

Ok, I was searching in wrong branch, I found the cause, it's caused by the 
custom 
version parsing 

 
in the 1.22 branch, in the main it's fixed

On Wednesday, June 12, 2024 at 3:54:10 PM UTC+2 David Ševčík wrote:

> Hello guys,
> when I run locally or in CircleCI  command `go fix 
> ./...` it reports this error multiple times:
> go fix ./...
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
> invalid -go=go1.22.0
> exit status 2
>
> When digging deeper, it shows that the underlying tool is reporting this 
> error:
> go tool fix -go=go1.22.0 .
> invalid -go=go1.22.0
>
> When I omit the path, it works:
> go tool fix -go=go1.22 .
> (no error, no output)
>
> In source code, it looks like it uses standard go validation for the 
> version:
>
> https://github.com/golang/go/blob/b788e91badd523e5bb0fc8d50cd76b8ae04ffb20/src/cmd/fix/main.go#L75
>
> I tried to run this validation in a test and it works:
> func Test(t *testing.T) {
> require.True(t, version.IsValid("go1.22.0"))
> }
> // Output
> === RUN   Test
> --- PASS: Test (0.00s)
> PASS
> So I'm confused, why it fails.
>
> Local machine:
> Apple M3 Pro
> macOS Sonoma (Version 14.5 (23F79))
>
> Installed go is:
> go version go1.22.4 darwin/arm64
> In go.mod is:
> go 1.22.0
>
> toolchain go1.22.4
>
> This tool fails also in the CircleCI, used image is:
> cimg/go:1.22 
> 
>  
> where is probably also go1.22.4
>
> Do anybody know why it's happening and how to fix it?
> Looks like a bug to me 樂
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7db14153-0201-4c0b-ac69-eb9c6baa0739n%40googlegroups.com.

[go-nuts] `go fix ./...` in go1.22.4 is reporting invalid go version

2024-06-12 Thread David Ševčík

Hello guys,
when I run locally or in CircleCI  command `go fix 
./...` it reports this error multiple times:
go fix ./...
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2
invalid -go=go1.22.0
exit status 2

When digging deeper, it shows that the underlying tool is reporting this 
error:
go tool fix -go=go1.22.0 .
invalid -go=go1.22.0

When I omit the path, it works:
go tool fix -go=go1.22 .
(no error, no output)

In source code, it looks like it uses standard go validation for the 
version:
https://github.com/golang/go/blob/b788e91badd523e5bb0fc8d50cd76b8ae04ffb20/src/cmd/fix/main.go#L75

I tried to run this validation in a test and it works:
func Test(t *testing.T) {
require.True(t, version.IsValid("go1.22.0"))
}
// Output
=== RUN   Test
--- PASS: Test (0.00s)
PASS
So I'm confused, why it fails.

Local machine:
Apple M3 Pro
macOS Sonoma (Version 14.5 (23F79))

Installed go is:
go version go1.22.4 darwin/arm64
In go.mod is:
go 1.22.0

toolchain go1.22.4

This tool fails also in the CircleCI, used image is:
cimg/go:1.22 

 
where is probably also go1.22.4

Do anybody know why it's happening and how to fix it?
Looks like a bug to me 樂

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/daa7f469-de6d-4e3f-9d3d-d0a9f64c45d0n%40googlegroups.com.

[go-nuts] Re: Failed to compile apptainer on Ubuntu 22.04.4 LTS.

2024-06-11 Thread Hongyi Zhao



On Tuesday, June 11, 2024 at 9:23:19 PM UTC+8 Hongyi Zhao wrote:

On Ubuntu 22.04.4 LTS, I tried to compile the latest GitHub version of 
apptainer using the guidance [here](
https://github.com/apptainer/apptainer/blob/main/INSTALL.md), but failed at 
the `make` step:

```shell
$ go version
go version devel go1.23-62711d61e5 Thu May 23 03:44:19 2024 + 
linux/amd64
$ sudo apt-get install -y build-essential libseccomp-dev 
pkg-config uidmap squashfs-tools fakeroot cryptsetup 
tzdata curl wget git

$ cd "/home/werner/Public/repo/github.com/apptainer/apptainer.git" 
$ proxychains-ng-country-control go mod download
$ ./mconfig
$ cd builddir
$ make
 GEN GO DEP /home/werner/Public/repo/
github.com/apptainer/apptainer.git/builddir/starter.deps
 GEN GO DEP /home/werner/Public/repo/
github.com/apptainer/apptainer.git/builddir/apptainer.deps
 GEN GO DEP /home/werner/Public/repo/
github.com/apptainer/apptainer.git/builddir/starter.deps
 GO apptainer
[+] GO_TAGS "containers_image_openpgp sylog oci_engine apptainer_engine 
fakeroot_engine apparmor selinux seccomp"
package github.com/apptainer/apptainer/cmd/apptainer
imports github.com/apptainer/apptainer/cmd/internal/cli
imports github.com/apptainer/apptainer/internal/app/apptainer
imports github.com/apptainer/apptainer/internal/pkg/runtime/engine/oci
imports 
github.com/apptainer/apptainer/internal/pkg/runtime/engine/config/starter: 
build constraints exclude all Go files in /home/werner/Public/repo/
github.com/apptainer/apptainer.git/internal/pkg/runtime/engine/config/starter
make: *** [Makefile:181: apptainer] Error 1
```

Any tips for fixing this problem? See here [1] for the related discussion.


I found that the issue was due to using the self-compiled latest git commit 
version of Go. Switching to the latest stable version of Go solved the 
problem.


[1] https://github.com/apptainer/apptainer/issues/2265

Regards,
Zhao

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2f1f787b-0150-4add-8206-b5d2b149aeffn%40googlegroups.com.

[go-nuts] Failed to compile apptainer on Ubuntu 22.04.4 LTS.

2024-06-11 Thread Hongyi Zhao

On Ubuntu 22.04.4 LTS, I tried to compile the latest GitHub version of 
apptainer using the guidance 
[here](https://github.com/apptainer/apptainer/blob/main/INSTALL.md), but 
failed at the `make` step:

```shell
$ go version
go version devel go1.23-62711d61e5 Thu May 23 03:44:19 2024 + 
linux/amd64
$ sudo apt-get install -y build-essential libseccomp-dev 
pkg-config uidmap squashfs-tools fakeroot cryptsetup 
tzdata curl wget git

$ cd "/home/werner/Public/repo/github.com/apptainer/apptainer.git" 
$ proxychains-ng-country-control go mod download
$ ./mconfig
$ cd builddir
$ make
 GEN GO DEP 
/home/werner/Public/repo/github.com/apptainer/apptainer.git/builddir/starter.deps
 GEN GO DEP 
/home/werner/Public/repo/github.com/apptainer/apptainer.git/builddir/apptainer.deps
 GEN GO DEP 
/home/werner/Public/repo/github.com/apptainer/apptainer.git/builddir/starter.deps
 GO apptainer
[+] GO_TAGS "containers_image_openpgp sylog oci_engine apptainer_engine 
fakeroot_engine apparmor selinux seccomp"
package github.com/apptainer/apptainer/cmd/apptainer
imports github.com/apptainer/apptainer/cmd/internal/cli
imports github.com/apptainer/apptainer/internal/app/apptainer
imports github.com/apptainer/apptainer/internal/pkg/runtime/engine/oci
imports 
github.com/apptainer/apptainer/internal/pkg/runtime/engine/config/starter: 
build constraints exclude all Go files in 
/home/werner/Public/repo/github.com/apptainer/apptainer.git/internal/pkg/runtime/engine/config/starter
make: *** [Makefile:181: apptainer] Error 1
```

Any tips for fixing this problem? See here [1] for the related discussion.

[1] https://github.com/apptainer/apptainer/issues/2265

Regards,
Zhao

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1dc36f6c-7de2-485e-8a7f-6989e1d3de91n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

2024-06-10 Thread Daniel Lepage

>
>  But I think this is not really worth arguing. If you change fundamental
> things like this in the language, then you'll suggesting turning Go into
> something that looks like Rust. In which case, you may as well just use
> Rust.

I don't think I'm proposing a fundamental change, or to turn Go into Rust -
there are good reasons why Go (and the majority of other languages) don't
force us to null-check every single pointer access, because there are lots
of use cases for pointers besides "this can be null" (e.g. for mutability
or performance reasons). I'm proposing a fairly specific syntax to solve a
fairly specific (but, at least in projects I've worked on, incredibly
common) problem. That said, I do agree that #57644
 subsumes this problem (as do a
number of other proposals for union or variant types), and if this feature
were to be implemented it would definitely be preferable to do so en route
to a fuller variant type solution.

-- 
Dan

On Thu, Mar 21, 2024 at 11:04 PM Mike Schinkel  wrote:

> Hi Axel,
>
> Thank you for that link. I had not seen it before, but it is rather
> insightful.
>
> -Mike
>
> On Wednesday, March 20, 2024 at 10:29:20 AM UTC-4 Axel Wagner wrote:
>
> FWIW I believe (as Brian sort of points out) this proposal is fully
> subsumed under #57644 . Under
> that proposal, the proposed type `int | nil` would be spelled `interface{
> int }`. The other syntactical constructs are, as far as I can tell,
> identical - you'd have to use a type-assertion to use an `interface{ int }`
> as an integer (e.g. to do arithmetic), you can use it with type-switches,
> and any `int` as well as `nil` would be assignable to it.
>
> I think the one difference would be that `x == 42` would work on
> `interface{ int }`, but would (presumably) not work on `int | nil`. I
> personally doubt that this difference would justify an extra construction,
> but I'm mentioning it for completeness sake.
>
> The "nice to have" of type guards is, I think, an easy idea to mention,
> but not an easy idea to add to Go. Note that the other languages mentioned,
> that do that, use a function-scoped type-inference (as far as I know) -
> that is, they look at an identifiers use over the entire function and then
> infer the most general type it would have.
> Go has so far tried to avoid doing anything like that, limiting any
> inference to the statement (or expression) a value appears in. And this
> idea effectively means an identifier would change its type over its
> lifetime (from `interface{ int }` - does not allow arithmetic - to `int` -
> does allow arithmetic), which would create numerous problems for existing
> tooling, as it violates assumptions made by the `go/*` packages.
>
> On Wed, Mar 20, 2024 at 11:26 AM Mike Schinkel wrote:
>
> On Wednesday, March 20, 2024 at 5:47:00 AM UTC-4 Brian Candler wrote:
>
> If you change fundamental things like this in the language, then you'll
> suggesting turning Go into something that looks like Rust. In which case,
> you may as well just use Rust.
>
>
> Agreed.  Which is why I was asking if using interfaces as type constraints
> would address the concern.
>
> And as discussed, probably not.
>
> But it is an interesting thought exercise. If an interface-based solution
> could be found, it would address the concern without turning us effectively
> into Rust programmers. ¯\_(ツ)_/¯
>
> -Mike
>
> --
>
> 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.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com
> 
> .
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b13c0f3c-2f87-4270-bc57-a22c577473d9n%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANtoCQ_ATPoPxbDvCbj30yN0RvS_W8c4qKfQYRpBbTcuEdObiw%40mail.gmail.com.

[go-nuts] Re: Guidance on techniques that can help me write a comprehensive test for my go library.

2024-06-08 Thread Amnon

https://research.swtch.com/testing

On Friday 7 June 2024 at 14:26:35 UTC+1 Guilherme Henrique wrote:

> You want to make a mock of the Google API calls, the same ones you use in 
> your project, and that's it?
>
> Em quarta-feira, 5 de junho de 2024 às 10:41:03 UTC-3, Ai Readone escreveu:
>
>> Hello Everyone,
>>
>> I am currently writing a go library that Integrates various Google cloud 
>> services.
>>
>> The aim of the library is to eliminate duplicate implementations across 
>> various services of the same software.
>>
>>
>> I am having challenges on how to write a comprehensive test for my 
>> library, the main challenges are coming from testing function and methods 
>> that performs remote call to Google cloud APIs
>>
>> I want to be able to mock every function in my library.
>>
>> I am familiar with majorly table-testing technique but I am open 
>> to suggestions that requires me to learn new technologies too.
>>
>> Thanks in advance for your time and help.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/319e668f-20a7-46d4-8172-91ef87c62e02n%40googlegroups.com.

[go-nuts] Re: Guidance on techniques that can help me write a comprehensive test for my go library.

2024-06-07 Thread Guilherme Henrique

You want to make a mock of the Google API calls, the same ones you use in 
your project, and that's it?

Em quarta-feira, 5 de junho de 2024 às 10:41:03 UTC-3, Ai Readone escreveu:

> Hello Everyone,
>
> I am currently writing a go library that Integrates various Google cloud 
> services.
>
> The aim of the library is to eliminate duplicate implementations across 
> various services of the same software.
>
>
> I am having challenges on how to write a comprehensive test for my 
> library, the main challenges are coming from testing function and methods 
> that performs remote call to Google cloud APIs
>
> I want to be able to mock every function in my library.
>
> I am familiar with majorly table-testing technique but I am open 
> to suggestions that requires me to learn new technologies too.
>
> Thanks in advance for your time and help.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4c713822-0faf-499d-8aa9-243597a1f00cn%40googlegroups.com.

[go-nuts] [x/term] Adding history save/restore/clear/etc and some small issues

2024-06-06 Thread Dragos Vingarzan

Hey folks,

I recently embedded the golang.go/x/term into my application and I love the
simplicity and effectiveness of having such a terminal.

The history part of it is also great to have, but even better if one could
save/restore the history over application restarts. I did some changes and
a proof-of-concept and I'm wondering if this would be worth merging. So any
developers/maintainers/users here which I could maybe ping ideas with,
before submitting a patch for review?

I also found a couple of slightly annoying issues which I'd also like to
fix:
1. Terminal.ReadPassword() allows the auto-complete callback; I don't see
why that would be helpful, other than making TABs harder to use in
passwords :-p. Of course, once could simply unset/set the callback around
the calls to Terminal.ReadPassword(), but feels like I shouldn't need that
(e.g. some users might leak partial password unintentionally).
2. I redirected all my stdout logs through Terminal.Write(), but still, I'm
getting some funky wrapped lines when (I guess) my go-routines write things
in parallel or maybe when the prompt is "refreshed"... not sure.

Cheers,
-Dragos

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/bb138fc1-9cd4-4d0e-8590-1f17a861a89en%40googlegroups.com.

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 49529 matches

Mail list logo