[go-nuts] How to use cflag -flto?
So I'm trying to compile a test program with the cflag -flto and it failed
to build with the message:
>
> cannot load DWARF output from $WORK/b001//_cgo_.o: decoding dwarf section
> info at offset 0x0: too short
I feel like I'm doing something wrong so I posed here instead of on github.
Even tried building with -ldflags "-linkmode=external"
package main
/*
#cgo CFLAGS: -flto
#cgo CXXFLAGS: -flto
*/
import "C"
import "fmt"
func main() {
fmt.Println("Hello World", C.int(0))
}
--
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] What's the best way to maintain a package repository that have the major version in the import path?
vgo suggested that package developers put the major version into the import path e.g. foo/v1. However dealing with a VCS like git, this thought occur to me, what would it look like when the project needs to move from v1 to v2? In git we can rename the file in the entire history which messes things up for everyone so that's a bad thing to do. We can also copy paste v1 into the v2 folder, but then we lose the entire history of the files and would need to refer to the history of the other folder so this is a huge pain. We can also create a dummy repository that just submodules v1 and v2 to the actual source repository but this isn't pretty and feels kinda hackish. I also thought maybe do all development on v0 and then have v1/v2/etc... just be wrappers to v0. The last one makes the most sense to me, so I guess question is, is there a better way to handle multiple API version paths? Especially when there are many sub packages in the same repository. -- 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] What's the best way to maintain a package repository that have the major version in the import path?
I don't think changing the module name would be a good idea for singletons tho. And having a v0 has the added benefit of using newer codes while maintaining backwards compatible API. So no more backporting and all the mess of having multiple branches. On Thursday, February 22, 2018 at 1:49:53 PM UTC+8, Sam Whited wrote: > > On Wed, Feb 21, 2018, at 22:35, alex@gmail.com wrote: > > vgo suggested that package developers put the major version into the > import > > path e.g. foo/v1. > > However dealing with a VCS like git, this thought occur to me, what > would > > it look like when the project needs to move from v1 to v2? > > This wasn't clear to me either, but it was pointed out that you can just > change the "module" line in your go.mod file, eg. > > module "example.net/mypackage/v2" > > and you don't have to actually create a /v2 tree or move your code around > at all. > > —Sam > -- 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] What's the best way to maintain a package repository that have the major version in the import path?
On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote: > > Have you read https://research.swtch.com/vgo-import? It talks about > singletons and also how to solve that with different import paths. > Note, that this is also independent of *how* the different import paths > are represented and distributed; for singletons it only matters what import > paths the compiler sees, whether they are committed physical directories or > whether the vgo tool automatically resolves them. > Yup, the package I'm working on really cannot have 2 instances even in different import paths as it deals with a shared resource and code that must be run on the main thread. So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a central v0 where all the v1, v2, etc.. packages import. Daisy chaining would mean I would only have to code API translations for the latest API but then it's debug hell and if one version in the chain breaks, it means fixing all the newer versions. Also there's a performance hit going through many translations. Having a v0 means non of all the daisy chaining problems but it means more work when there's a breaking change as then I'll have to update all versions. Also it means that all version packages have to be from the same release or it breaks. If I just have one module at the root, is it right to assume all sub packages would be of the same commit and that there will be only one version of the module? -- 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] What's the best way to maintain a package repository that have the major version in the import path?
On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote: > > Daisy chaining would mean I would only have to code API translations for >> the latest API but then it's debug hell and if one version in the chain >> breaks, >> it means fixing all the newer versions. Also there's a performance hit >> going through many translations. >> > > I don't believe so. There's may be an increase in compile time though. > I was thinking of cases where the behavior is so different it needed to emulate old behavior so over time all the emulation adds up and would be more complex than just emulating based on v0/latest. > The real question though, is how other package management semantics would > solve this better. Is this actually accidental complexity or just > systematic complexity caused by "I need to both break compatibility *and* > have different versions coexist *and* still share Singleton state between > them? > The vgo blogs talk about coexistence of multiple versions so was just figuring out if it makes sense and how would that look like. I just like to be prepared for worst case scenarios, so stuff I was worried about may or may not actually happen. But better be safe than sorry. -- 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: Go Games
To those talking about using game engines like unity etc... you can build go as c-shared and use it as a normal C/C++ plugin. The only thing to note is that you can't unload it without restarting the program and multiple c-shared go libraries wouldn't work together. As for what I'm using go for, I'm experimenting with coding a mostly go game engine (mostly cuz graphical input/output libraries are all in C/C++). -- 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: Go Games
Yup, as long as you build the go package as a c-shared you can basically do anything a C/C++ plugin can do. This contains a simple hello world for building a c-shared you can load in any C/C++ program. http://blog.ralch.com/tutorial/golang-sharing-libraries/ On Tuesday, March 13, 2018 at 4:15:25 PM UTC+8, nicolas...@yahoo.fr wrote: > > Do you mean we can for example build a GO .dll wich declare an entry point > usable by C/C++ game ? > > I can give it a try easily with ARMA game wich load those kind of > extension. > > Le mardi 13 mars 2018 08:39:02 UTC+1, alex@gmail.com a écrit : >> >> To those talking about using game engines like unity etc... you can build >> go as c-shared and use it as a normal C/C++ plugin. >> The only thing to note is that you can't unload it without restarting the >> program and multiple c-shared go libraries wouldn't work together. >> >> As for what I'm using go for, I'm experimenting with coding a mostly go >> game engine (mostly cuz graphical input/output libraries are all in C/C++). >> > -- 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: CGO linker issues
Have you already checked for another declaration in sm_sdk.h?
btw which go version are you on? The error message doesn't seem like the
latest release.
Also can you provide a self contained buildable example and build commands?
On Friday, 13 April 2018 12:45:39 UTC+8, r...@soulmachines.com wrote:
>
>
> So I am try to get a simple CGO program going with a GO function that can
> get called back from a 'C' library
>
> the error I get is
>
> In file included from _cgo_export.c:3:
> cgo-gcc-export-header-prolog:42:14: error: conflicting types for
> '_go_Callback'
> src/smsdk/go_bindings.go:12:12: note: previous declaration is here
> _cgo_export.c:17:7: error: conflicting types for '_go_Callback'
> src/smsdk/go_bindings.go:12:12: note: previous declaration is here
>
> The code is simple looks like this
>
> package smsdk
>
> /*
> #cgo CFLAGS: -Damd64 -D SM_SDK_INTERNAL -I ${SRCDIR}/smsdk
> #cgo LDFLAGS: -L${SRCDIR} -lsm_sdk
> #include
> #include
> #include "sm_sdk.h"
>
> extern int _go_Callback(int speaking_state);
>
> static void Callback(Handle h, void * caller_context)
> {
> int val = CLibraryFunction(h);
> _go_Callback(val);
> }
> */
> import "C"
> import (
> "unsafe"
> "sync"
> )
>
> var _registeredCallback func(int)
>
> //export _go_SpeakingStateCallback
> func _go_SpeakingStateCallback(val int) int {
>
> if _registeredCallback != nil {
> _registeredCallback(val)
> return 1
> }
> return 0
> }
>
> Any suggestions?
>
> --
>
> "This communication is confidential and may contain privileged and/or
> copyright material. If you are not the intended recipient you must not use,
> disclose, copy or retain it. If you have received it in error please
> immediately notify me by return email, delete the emails and destroy any
> hard copies. Soul Machines Limited does not guarantee the integrity of this
> communication, or that it is free from errors, viruses or interference."
>
> *Please consider the environment before printing this email.*
>
--
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: Need help in in implementing a method on an interface
If GenericMethod is truly the same, as in not even using the struct fields
from P1data/P2data then there is a way. You just need to create a new
struct type in package main that implements GenericMethod and then in
packages p1 and p2 you embed the struct and thus expose the method.
package main
import (
"fmt"
)
type I interface {
F1()
GenericMethod()
}
type Generic struct{}
func (*Generic) GenericMethod() {
fmt.Printf("Hello World")
}
//package p1
type P1data struct {
Generic
}
func (x *P1data) F1() {}
func main() {
i := I(&P1data{})
i.GenericMethod()
}
On Wednesday, 25 April 2018 12:01:36 UTC+8, rickyu...@gmail.com wrote:
>
> Hello all,
>
> I am golang beginner. And I have a problem with interfaces.
> Here is the problem where I have one main package with has an Interface I.
> and multiple sub packages each implementing interface I. So I have a method
> which is exactly the same for all sub packages. Is there a way I can
> implement this method for I.
>
> package main
>
> type I interface {
> F1()
> GenericMethod()// Is there a way I can implement it on I since
> its the same in all packages?
> }
>
> package p1
>
> type P1data struct {}
>
> (x *P1data) F1()
> (x *P1data) GenericMethod()
>
>
> package p2
>
> type P2data struct {}
>
> (x *P2data) F1()
> (x *P2data) GenericMethod()
>
>
> under the main package.
> for each data in sub packages do data.F1 and data.GenericMethod().
>
>
> Now I don't want to implement GenericMethod for all packages. Since its
> the same.So can I implement GenericMethod on I (I know this is not
> possible). But how can do something like this?
>
> -Thanks
>
--
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: Need help in in implementing a method on an interface
Then just do
type Generic struct{
name string
}
func (*Generic) GenericMethod() {
fmt.Printf(name)
}
If you want to access name from p1
type Generic struct{
Name string
}
func (g *Generic) GenericMethod() {
fmt.Printf(g.Name)
}
//package p1
func (x *P1data) F1() {
x.Generic.Name = "asdf"
}
On Wednesday, 25 April 2018 12:58:36 UTC+8, rickyu...@gmail.com wrote:
>
> Hi Alex,
>
> Thanks for the response. Apologies for the confusion. The Generic method
> indeed uses struct fields from P1data/P2data struct(they are all same
> structs). Can I still achieve this? From the below. GenericMethod should
> read name field from structs.
>
> //package p1
> type P1data struct {
> name string
> }
>
> //package p2
> type P1data struct {
> name string
> }
>
> -Thanks
>
> On Wednesday, April 25, 2018 at 10:16:24 AM UTC+5:30, alex@gmail.com
> wrote:
>>
>> If GenericMethod is truly the same, as in not even using the struct
>> fields from P1data/P2data then there is a way. You just need to create a
>> new struct type in package main that implements GenericMethod and then in
>> packages p1 and p2 you embed the struct and thus expose the method.
>>
>> package main
>>
>>
>> import (
>> "fmt"
>> )
>>
>>
>> type I interface {
>> F1()
>> GenericMethod()
>> }
>>
>>
>> type Generic struct{}
>>
>>
>> func (*Generic) GenericMethod() {
>> fmt.Printf("Hello World")
>> }
>>
>> //package p1
>> type P1data struct {
>> Generic
>> }
>>
>>
>> func (x *P1data) F1() {}
>>
>>
>> func main() {
>> i := I(&P1data{})
>> i.GenericMethod()
>> }
>>
>>
>>
>>
>>
>>
>> On Wednesday, 25 April 2018 12:01:36 UTC+8, rickyu...@gmail.com wrote:
>>>
>>> Hello all,
>>>
>>> I am golang beginner. And I have a problem with interfaces.
>>> Here is the problem where I have one main package with has an Interface
>>> I. and multiple sub packages each implementing interface I. So I have a
>>> method which is exactly the same for all sub packages. Is there a way I can
>>> implement this method for I.
>>>
>>> package main
>>>
>>> type I interface {
>>> F1()
>>> GenericMethod()// Is there a way I can implement it on I
>>> since its the same in all packages?
>>> }
>>>
>>> package p1
>>>
>>> type P1data struct {}
>>>
>>> (x *P1data) F1()
>>> (x *P1data) GenericMethod()
>>>
>>>
>>> package p2
>>>
>>> type P2data struct {}
>>>
>>> (x *P2data) F1()
>>> (x *P2data) GenericMethod()
>>>
>>>
>>> under the main package.
>>> for each data in sub packages do data.F1 and data.GenericMethod().
>>>
>>>
>>> Now I don't want to implement GenericMethod for all packages. Since its
>>> the same.So can I implement GenericMethod on I (I know this is not
>>> possible). But how can do something like this?
>>>
>>> -Thanks
>>>
>>
--
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: what can I do about this interface conversion error
Struct embedding works like this:
type ActionNode struct {
basicNode
}
Turns into:
type ActionNode struct {
basicNode basicNode
}
func (a *ActionNode) OutputsTo(n2 node) {
a.basicNode.OutputsTo(n2)
}
So basicNode will behave as a field of ActionNode with wrapper functions.
If you must embed and get basicNode out of a interface then you need to add
to your interface a new method to get basicNode,
e.g. https://play.golang.org/p/QhTmqeg9vgU
On Wednesday, 2 May 2018 03:43:17 UTC+8, Mark Nahabedian wrote:
>
> I don't know why I'm getting this interface conversion error or what to do
> about it.
>
> I define an interface, node, and a struct, basicNode that implements
> behavior common to all nodes. I also define ActionNode and TestNode which
> both anonymously embed basicNode.
>
> basicNode implements OutputsTo which links the receiver with the node
> passed as argument.
>
> I get the runtime error
>
> panic: interface conversion: main.node is *main.ActionNode, not
> *main.basicNode
>
>
>
>
> Here's a playground link that exhibits my problem:
>
> https://play.golang.org/p/ZeIkJSd7qB0
>
> Thanks.
>
>
--
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: what can I do about this interface conversion error
>
> That shows that basicNode's inputs and outputs fields are not visible as
> fields of ActionNode or TestNode though.
Yup, struct embedding is just a shortcut to writing wrapper functions.
Even if basicNode's fields gets promoted to ActionNode's fields, doing
b2 := n2.(*basicNode)
Wouldn't work anyway, they are still completely different named types and
go is very strict on that.
On Wednesday, 2 May 2018 05:21:51 UTC+8, Mark Nahabedian wrote:
>
> I was expecting that since basicNode is anonymously embedded into TestNode
> and ActionNode, that the methods and fields of basicNode would all be
> present in TestNode and ActionNode. In that case I'd have expected
>
> https://play.golang.org/p/gIvykcxFTmQ
>
> to have worked. That shows that basicNode's inputs and outputs fields are
> not visible as fields of ActionNode or TestNode though.
>
>
>
>
> On Tuesday, May 1, 2018 at 3:58:35 PM UTC-4, alex@gmail.com wrote:
>>
>> Struct embedding works like this:
>>
>> type ActionNode struct {
>> basicNode
>> }
>>
>> Turns into:
>>
>> type ActionNode struct {
>> basicNode basicNode
>> }
>>
>> func (a *ActionNode) OutputsTo(n2 node) {
>> a.basicNode.OutputsTo(n2)
>> }
>>
>> So basicNode will behave as a field of ActionNode with wrapper functions.
>> If you must embed and get basicNode out of a interface then you need to
>> add to your interface a new method to get basicNode, e.g.
>> https://play.golang.org/p/QhTmqeg9vgU
>>
>> On Wednesday, 2 May 2018 03:43:17 UTC+8, Mark Nahabedian wrote:
>>>
>>> I don't know why I'm getting this interface conversion error or what to
>>> do about it.
>>>
>>> I define an interface, node, and a struct, basicNode that implements
>>> behavior common to all nodes. I also define ActionNode and TestNode which
>>> both anonymously embed basicNode.
>>>
>>> basicNode implements OutputsTo which links the receiver with the node
>>> passed as argument.
>>>
>>> I get the runtime error
>>>
>>> panic: interface conversion: main.node is *main.ActionNode, not
>>> *main.basicNode
>>>
>>>
>>>
>>>
>>> Here's a playground link that exhibits my problem:
>>>
>>> https://play.golang.org/p/ZeIkJSd7qB0
>>>
>>> Thanks.
>>>
>>>
--
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: what can I do about this interface conversion error
You can't do that with interfaces, embedding struct or not. You can only
call methods on interfaces or assert to a type.
On Wednesday, 2 May 2018 05:48:26 UTC+8, Mark Nahabedian wrote:
>
> b2 isn't in my most recent example. Thus gets the error that n2.inputs is
> not defined.
>
> func (n1 *basicNode) OutputsTo(n2 node) {
> n2.inputs = append(n2.inputs, n1)
> n1.outputs = append(n1.outputs, n2)
> }
--
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: what can I do about this interface conversion error
If basicNode isn't the only struct that could be passed, I would argue that that's cleaner than checking for every possible type. Also doing it that way means that your interface couldn't care less about the actual structure of the struct and so is much more flexible. And they won't break if and when you decide to change the struct layout cause that doesn't matter anymore. btw if the structs and interface are in different packages, you need to make those methods public or it wouldn't be able to call them. Can I suggest you join the golang discord chat server? You seem to be asking a lot of short answer questions and a chat server would give you faster response time than a forum. https://discord.gg/7WhXAaF On Wednesday, 2 May 2018 11:49:03 UTC+8, Mark Nahabedian wrote: > > Thanks for your help and patience Alex. I guess I need to do something > like > > https://play.golang.org/p/qURVD3of5oU > > but I find it kind of unclean to have to add private methods to do this. > > It wouldn't be appropriate to define a basicNode getter method on the node > interface since basicNode is just one possible implementstion. > > Anyway, I'm past that problem. > > 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] How to change the GBK with golang default charset?
Go only has support for UTF-8, so you need to convert the file.
e.g.
package main
import (
"fmt"
"golang.org/x/text/encoding/simplifiedchinese"
)
func main() {
gbk := simplifiedchinese.GBK.NewDecoder()
s, err := gbk.String("a\xfe\xfeb")
if err != nil {
panic(err)
}
fmt.Println(s)
}
On Thursday, 3 May 2018 16:12:28 UTC+8, Able Gao wrote:
>
> I want to call a DDL file in windows XP or 7 32bit system, and the DDL
> file was encoded by GBK. Is there any expert knows what is the best
> solution to call this GBK encoded DDL file by GO？ In GCC, i can use gcc
> -finput-charset=GBK -fexec-charset=GBK
>
--
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] How to fake os.Stdout in golang for testing?
Or use log instead of fmt
var stdout = log.New(os.Stdout, "", 0)
Then you can easily redirect it to any io.Writter like
buf := &strings.Builder{}
stdout = log.New(buf, "", 0)
On Sunday, 6 May 2018 13:32:47 UTC+8, Lars Seipel wrote:
>
> On Sat, May 05, 2018 at 08:55:17AM -0700, mfried...@gmail.com
> wrote:
> > * Now in golang `os.Stdout` is an `*os.File` which is mostly a wrapper
> for
> > an OS specific file.
>
> You can always use os.Pipe to get an actual file descriptor to write to.
>
--
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] How to fake os.Stdout in golang for testing?
The output of text printed with the log as created in my example and fmt
are exactly the same.
The only change you would have to make is have a global log var and then do
a simple search and replace all fmt.Printf to logVar.Printf.
So the only argument you gave for not changing would be not wanting to
change the original source.
If changing the code is an absolute impossibility then sure the os.Stdout
redirect makes sense.
On Sunday, 6 May 2018 18:44:10 UTC+8, Mirko Friedenhagen wrote:
>
>
> On Sunday, May 6, 2018 at 8:21:14 AM UTC+2, alex@gmail.com wrote:
>>
>> Or use log instead of fmt
>>
>> var stdout = log.New(os.Stdout, "", 0)
>>
>> Then you can easily redirect it to any io.Writter like
>>
>> buf := &strings.Builder{}
>> stdout = log.New(buf, "", 0)
>>
>
> Hello Alex,
>
> good point, however firstly I do not want to modify the original code. My
> first goal is to cover it completely with tests. This being a test project
> for legacy code refactoring, the program *must* always produce the output
> given here:
> https://github.com/mfriedenhagen/trivia/blob/master/reference/result.txt.
>
> Regards
> Mirko
>
--
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] cross-compile mac to linux
There's a tool for that, and yeah it uses docker. https://github.com/karalabe/xgo On Monday, 7 May 2018 22:32:00 UTC+8, mbanzon wrote: > > It was specifically stated that the code was CGO - this approach won’t > work unless there is a C compiler that is crosscompile enabled installed > already - I’m guessing the question is how to do that. > > In my experience the (by far) easiest way to do this is to set up a > (Docker) container or a VM with the needed Linux toolchain and use that. As > long as the target is Linux it is fairly easy (I am still to crack the > Windows<->macOS cross compilation for my CGO code - which is also caused by > SQLite). > > -- > Michael Banzon > https://michaelbanzon.com/ > > Den 7. maj 2018 kl. 07.22 skrev Rohit Jain >: > > *GOOS=linux GOARCH=amd64 go build* > > Try this? > > On Mon, May 7, 2018 at 8:56 AM, Steven Roth > wrote: > >> Can anyone point me to a recipe or guidance on how to set up a >> cross-compilation environment on a Mac that will allow me to build >> CGO-enabled Go code to run on Ubuntu? The program I'm building is pure Go >> except for an unavoidable dependency on libsqlite3. >> >> Thanks in advance, >> Steve >> >> -- >> 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. >> > > > > -- > Rohit Jain > > -- > 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. > -- 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: Writing a Compiler for Web Assembly
If you clicked under Issues you'll see the first result is https://github.com/golang/go/issues/18892 On Friday, 11 May 2018 19:59:39 UTC+8, Chris FractalBach wrote: > > So I've been playing around with compilers lately, and thought it might be > fun to write a compiler from Go to web assembly! > I notice it has been mentioned before, but discussion seems to be > scattered around. > > searching the github repo reveals that the keyword: "wasm" is appearing: > https://github.com/golang/go/search?&q=wasm > > Is there a main discussion for making "Go To Web Assembly" ? =) > -- 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: Why does unmarshalling this API response return an unexpected EOF?
You need to use the go protobuf json decoder https://github.com/golang/protobuf/tree/master/jsonpb On Monday, 14 May 2018 11:24:06 UTC+8, Luke IC wrote: > > Hi all, > > I'm creating a microservice in Go, using protocol buffers and gRPC. It > interacts with a third-party API (Snooth) and I'm trying to unmarshal the > JSON response into a protobuf struct I've created, using the proto > package. > > Unmarshalling returns an unexpected EOF error. > > > I've summed up the details in full on this question at Stack Overflow: > https://stackoverflow.com/questions/50314476/why-does-unmarshalling-this-api-response-return-an-unexpected-eof > > > In addition to the information posted there, I've also tried using > strconv.Unquote before unmarshalling in line with the idea that the escaped > characters in the API response are causing a double-encode. But this didn't > work either. > > Any help would be greatly appreciated as I've been stuck on this for a > while now and feel there's something simple I'm missing. > > > Thanks. > -- 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: Why does unmarshalling this API response return an unexpected EOF?
In the long term I would investigate what's wrong with the json and if
possible fix it at the source.
Also use this as a reference on what gets mapped to what
https://developers.google.com/protocol-buffers/docs/proto3#json
On Tuesday, 15 May 2018 05:03:46 UTC+8, Luke IC wrote:
>
> Thanks a lot, I went back and gave jsonpb a go and finally got it
> unmarshalling as desired.
>
> To do so though I had to unmarshal and marshal the response with the
> regular json library first, in order to get around some escaped values in
> the response (I was receiving a 'bad value in Struct' error:
>
> resJson, err := ioutil.ReadAll(res.Body)
>
> j := make(map[string]interface{})
>
> jbytes, err := json.Marshal(j)
>
> result := &pb.Response{}
> r := strings.NewReader(string(jbytes))
> if err := jsonpb.Unmarshal(r, result); err != nil {
> panic(err)
> }
>
>
> Is this fine to do, or is it super inefficient and will cause problems?
>
>
> On Tuesday, 15 May 2018 05:09:04 UTC+10, alex@gmail.com wrote:
>>
>> You need to use the go protobuf json decoder
>> https://github.com/golang/protobuf/tree/master/jsonpb
>>
>> On Monday, 14 May 2018 11:24:06 UTC+8, Luke IC wrote:
>>>
>>> Hi all,
>>>
>>> I'm creating a microservice in Go, using protocol buffers and gRPC. It
>>> interacts with a third-party API (Snooth) and I'm trying to unmarshal the
>>> JSON response into a protobuf struct I've created, using the proto
>>> package.
>>>
>>> Unmarshalling returns an unexpected EOF error.
>>>
>>>
>>> I've summed up the details in full on this question at Stack Overflow:
>>> https://stackoverflow.com/questions/50314476/why-does-unmarshalling-this-api-response-return-an-unexpected-eof
>>>
>>>
>>> In addition to the information posted there, I've also tried using
>>> strconv.Unquote before unmarshalling in line with the idea that the escaped
>>> characters in the API response are causing a double-encode. But this didn't
>>> work either.
>>>
>>> Any help would be greatly appreciated as I've been stuck on this for a
>>> while now and feel there's something simple I'm missing.
>>>
>>>
>>> Thanks.
>>>
>>
--
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: Why does unmarshalling this API response return an unexpected EOF?
I do not see escaped quotes on your stackoverflow post, can you post the
raw json exactly as received?
On Tuesday, 15 May 2018 05:16:59 UTC+8, Luke IC wrote:
>
> Thanks again for the help. Unfortunately it's a third-party API, so I
> won't be able to fix it myself. The full error message is as follows:
>
> bad value in StructValue for key "image": unrecognized type for Value
> "\"https:\\/\\/ei.isnooth.com
> \\/multimedia\\/0\\/2\\/8\\/image_787698_square.jpeg\""
>
> I assume the cause for this error is the escaped quotes?
>
> On Tuesday, 15 May 2018 07:08:05 UTC+10, alex@gmail.com wrote:
>>
>> In the long term I would investigate what's wrong with the json and if
>> possible fix it at the source.
>> Also use this as a reference on what gets mapped to what
>> https://developers.google.com/protocol-buffers/docs/proto3#json
>>
>> On Tuesday, 15 May 2018 05:03:46 UTC+8, Luke IC wrote:
>>>
>>> Thanks a lot, I went back and gave jsonpb a go and finally got it
>>> unmarshalling as desired.
>>>
>>> To do so though I had to unmarshal and marshal the response with the
>>> regular json library first, in order to get around some escaped values in
>>> the response (I was receiving a 'bad value in Struct' error:
>>>
>>> resJson, err := ioutil.ReadAll(res.Body)
>>>
>>> j := make(map[string]interface{})
>>>
>>> jbytes, err := json.Marshal(j)
>>>
>>> result := &pb.Response{}
>>> r := strings.NewReader(string(jbytes))
>>> if err := jsonpb.Unmarshal(r, result); err != nil {
>>> panic(err)
>>> }
>>>
>>>
>>> Is this fine to do, or is it super inefficient and will cause problems?
>>>
>>>
>>> On Tuesday, 15 May 2018 05:09:04 UTC+10, alex@gmail.com wrote:
You need to use the go protobuf json decoder
https://github.com/golang/protobuf/tree/master/jsonpb
On Monday, 14 May 2018 11:24:06 UTC+8, Luke IC wrote:
>
> Hi all,
>
> I'm creating a microservice in Go, using protocol buffers and gRPC. It
> interacts with a third-party API (Snooth) and I'm trying to unmarshal the
> JSON response into a protobuf struct I've created, using the proto
> package.
>
> Unmarshalling returns an unexpected EOF error.
>
>
> I've summed up the details in full on this question at Stack Overflow:
> https://stackoverflow.com/questions/50314476/why-does-unmarshalling-this-api-response-return-an-unexpected-eof
>
>
> In addition to the information posted there, I've also tried using
> strconv.Unquote before unmarshalling in line with the idea that the
> escaped
> characters in the API response are causing a double-encode. But this
> didn't
> work either.
>
> Any help would be greatly appreciated as I've been stuck on this for a
> while now and feel there's something simple I'm missing.
>
>
> Thanks.
>
--
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: What powers search on golang.org?
https://github.com/golang/blog/blob/a317451f36b22672c8a079489aa5425b9fa3a9da/content/context/google/google.go Google search On Monday, 21 May 2018 04:08:18 UTC+8, meir fischer wrote: > > golang.org let’s you search all stdlib go source code. > > For example, see https://golang.org/search?q=hello > > Where is the code that serves these search queries? If the code is not > public, does it use a publicly available or at least publicly documented > search engine? -- 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: What powers search on golang.org?
Tho there is also the offline one used by godoc https://github.com/golang/tools/blob/4e70a1b26a7875f00ca1916637a876b5ffaeec59/godoc/search.go On Monday, 21 May 2018 05:27:53 UTC+8, alex@gmail.com wrote: > > > https://github.com/golang/blog/blob/a317451f36b22672c8a079489aa5425b9fa3a9da/content/context/google/google.go > > Google search > > On Monday, 21 May 2018 04:08:18 UTC+8, meir fischer wrote: >> >> golang.org let’s you search all stdlib go source code. >> >> For example, see https://golang.org/search?q=hello >> >> Where is the code that serves these search queries? If the code is not >> public, does it use a publicly available or at least publicly documented >> search engine? > > -- 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] Why doesn't this select statement timeout?
https://golang.org/ref/spec#Select_statements
Execution of a "select" statement proceeds in several steps:
>
>1. For all the cases in the statement, the channel operands of receive
>operations and the channel and right-hand-side expressions of send
>statements are evaluated exactly once, in source order, upon entering the
>"select" statement. The result is a set of channels to receive from or
> send
>to, and the corresponding values to send. Any side effects in that
>evaluation will occur irrespective of which (if any) communication
>operation is selected to proceed. Expressions on the left-hand side of a
>RecvStmt with a short variable declaration or assignment are not yet
>evaluated.
>2. If one or more of the communications can proceed, a single one that
>can proceed is chosen via a uniform pseudo-random selection. Otherwise, if
>there is a default case, that case is chosen. If there is no default case,
>the "select" statement blocks until at least one of the communications can
>proceed.
>3. Unless the selected case is the default case, the respective
>communication operation is executed.
>4. If the selected case is a RecvStmt with a short variable
>declaration or an assignment, the left-hand side expressions are evaluated
>and the received value (or values) are assigned.
>5. The statement list of the selected case is executed.
>
>
So it evaluates all your function calls before doing the select in the
order they appear in single threadeddly.
On Wednesday, 23 May 2018 07:29:59 UTC+8, ag wrote:
>
> This is interesting and I still don't get why it's not working.
>
> I modified the code a bit and expected it to immediately break out of
> select but it still waits for http calls to finish
>
> https://play.golang.org/p/z1mmqpQtOre
>
> package main
>
> import (
> "errors"
> "fmt"
> "net/http"
> "net/http/httptest"
> "time"
> )
>
> func main() {
> ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r
> *http.Request) {
> time.Sleep(1 * time.Second)
> w.WriteHeader(http.StatusOK)
> }))
> defer ts.Close()
>
> req, _ := http.NewRequest(http.MethodGet, ts.URL, nil)
>
> f := func(r *http.Request, n int) error {
> fmt.Println("Making the http call ", n)
> _, err := http.DefaultClient.Do(r)
> return err
> }
>
> ch := make(chan error, 1)
>
> timeout := 1 * time.Millisecond
> select {
> case ch <- errors.New("immediate timeout"):
> case ch <- f(req, 1):
> case ch <- f(req, 2):
> case <-time.After(timeout):
> fmt.Println("Timeout being called")
> ch <- errors.New("timeout")
> }
>
> err1 := <-ch
> fmt.Println("Received first error", err1)
> close(ch)
>
>
> // Output:
>
>// Making the http call 1 // Making the http call 2 //
> Received first error immediate timeout
>
> }
>
>
>
>
>
> On Monday, May 21, 2018 at 10:25:08 PM UTC-7, Burak Serdar wrote:
>>
>> On Mon, May 21, 2018 at 12:13 PM, wrote:
>> > timeout := 1 * time.Millisecond
>> > select {
>> > case ch <-f(req):
>> > case <-time.After(timeout):
>> > ch <- errors.New("timeout")
>> > }
>>
>> The instant 'select' is evaluated, ch is writable. Also time.After()
>> is called, and returns a channel that will be ready to be read in a
>> millisecond, i.e. not readable immediately. So it'll write to ch, and
>> will never timeout.
>>
>> To do what you described, you need to run the request piece in a
>> goroutine, and write the result to a channel:
>>
>> go func() {
>>_,err:=http.DefaultClient.Do(...)
>>ch<-err
>> }()
>>
>> Then, wait for the error to arrive on ch, or timeout:
>>
>> select {
>> case err:=<-ch:
>> case <-time.After(timeout):
>> }
>>
>>
>> > err:= <-ch
>> > close(ch)
>> > fmt.Println(err) // outputs , not timeout
>> > // Output:
>> > // timeout
>> > }
>> >
>> >
>> > --
>> > 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.
>>
>
--
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: I am confused.
I would suggest you join a chat server so people can guide you through the whole process with a quicker response time than the hours you are waiting for each reply on a forum such as this one. https://discordapp.com/invite/PxwHvBS https://invite.slack.golangbridge.org/ #go-nuts on irc.freenode.net On Wednesday, 23 May 2018 12:41:07 UTC+8, John wrote: > > Is the visual code studio an compiler or a what, I tried it myself but I > isn't able to program. > > > -- 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] Why doesn't this select statement timeout?
No, not the entire case statements, only the statements on the right of the
"<-"
btw if you run it out of the playground (which makes concurrency more
deterministic)
You would get timeout sometimes and nil sometimes
Also maybe this example would help you understand what's going on.
https://play.golang.org/p/DokMlHtdzi7
On Thursday, 24 May 2018 16:58:20 UTC+8, gopher...@gmail.com wrote:
>
> Thanks for the reply.
>
> So you're saying that all case statements are evaluated first before a
> choice is made.
> Which means that the full request/response must complete even if the
> timeout case finishes first.
>
> If I swap the cases, now I consistently get a `timeout`.
> All cases are run to completion, so the full request/response occurs.
> Whats the reason for selecting the timeout? shouldn't it be pseudo-random?
> https://play.golang.org/p/M-7rMPJxOWq
>
> How should the done channel be setup to get this example working properly?
>
>
>
> On Tuesday, May 22, 2018 at 5:29:43 PM UTC-7, alex@gmail.com wrote:
>>
>> https://golang.org/ref/spec#Select_statements
>>
>> Execution of a "select" statement proceeds in several steps:
>>>
>>>1. For all the cases in the statement, the channel operands of
>>>receive operations and the channel and right-hand-side expressions of
>>> send
>>>statements are evaluated exactly once, in source order, upon entering
>>> the
>>>"select" statement. The result is a set of channels to receive from or
>>> send
>>>to, and the corresponding values to send. Any side effects in that
>>>evaluation will occur irrespective of which (if any) communication
>>>operation is selected to proceed. Expressions on the left-hand side of a
>>>RecvStmt with a short variable declaration or assignment are not yet
>>>evaluated.
>>>2. If one or more of the communications can proceed, a single one
>>>that can proceed is chosen via a uniform pseudo-random selection.
>>>Otherwise, if there is a default case, that case is chosen. If there is
>>> no
>>>default case, the "select" statement blocks until at least one of the
>>>communications can proceed.
>>>3. Unless the selected case is the default case, the respective
>>>communication operation is executed.
>>>4. If the selected case is a RecvStmt with a short variable
>>>declaration or an assignment, the left-hand side expressions are
>>> evaluated
>>>and the received value (or values) are assigned.
>>>5. The statement list of the selected case is executed.
>>>
>>>
>> So it evaluates all your function calls before doing the select in the
>> order they appear in single threadeddly.
>>
>> On Wednesday, 23 May 2018 07:29:59 UTC+8, ag wrote:
>>>
>>> This is interesting and I still don't get why it's not working.
>>>
>>> I modified the code a bit and expected it to immediately break out of
>>> select but it still waits for http calls to finish
>>>
>>> https://play.golang.org/p/z1mmqpQtOre
>>>
>>> package main
>>>
>>> import (
>>> "errors"
>>> "fmt"
>>> "net/http"
>>> "net/http/httptest"
>>> "time"
>>> )
>>>
>>> func main() {
>>> ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r
>>> *http.Request) {
>>> time.Sleep(1 * time.Second)
>>> w.WriteHeader(http.StatusOK)
>>> }))
>>> defer ts.Close()
>>>
>>> req, _ := http.NewRequest(http.MethodGet, ts.URL, nil)
>>>
>>> f := func(r *http.Request, n int) error {
>>> fmt.Println("Making the http call ", n)
>>> _, err := http.DefaultClient.Do(r)
>>> return err
>>> }
>>>
>>> ch := make(chan error, 1)
>>>
>>> timeout := 1 * time.Millisecond
>>> select {
>>> case ch <- errors.New("immediate timeout"):
>>> case ch <- f(req, 1):
>>> case ch <- f(req, 2):
>>> case <-time.After(timeout):
>>> fmt.Println("Timeout being called")
>>> ch <- errors.New("timeout")
>>> }
>>>
>>> err1 := <-ch
>>> fmt.Println("Received first error", err1)
>>> close(ch)
>>>
>>>
>>> // Output:
>>>
>>>// Making the http call 1 // Making the http call 2 //
>>> Received first error immediate timeout
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>> On Monday, May 21, 2018 at 10:25:08 PM UTC-7, Burak Serdar wrote:
On Mon, May 21, 2018 at 12:13 PM, wrote:
> timeout := 1 * time.Millisecond
> select {
> case ch <-f(req):
> case <-time.After(timeout):
> ch <- errors.New("timeout")
> }
The instant 'select' is evaluated, ch is writable. Also time.After()
is called, and returns a channel that will be ready to be read in a
millisecond, i.e. not readable immediately. So it'll write to ch, and
will never timeout.
To do what you described, you need to run the request piece in a
goroutine, and write the result to a channel:
go func() {
_,err:=http.DefaultClient.Do(...)
ch<-err
}()
Then, wait for the error to arrive on ch, or timeout:
select {
case err:=<-ch:
case <-time.After(timeout
[go-nuts] Re: Freeing memory of a cgo library
Memory allocated by one C/C++ runtime must and can only be freed through the same runtime. This is not a Go/cgo problem, this is normal C/C++ behavior. So by mixing gcc and msvc there are at least 2 C/C++ runtimes. Even mixing different compiler versions might cause issues. On Saturday, 26 May 2018 00:47:58 UTC+8, Liron Levy wrote: > > Hey Jake, > > First if all thanks for the willing to help. > > Cgo is the built-in tool in go of building c libraries (see: > https://golang.org/cmd/cgo/) > > What I basically do is that I have a go code, which i build into c library > (dll), i.e, i insert the go code onto the cgo mechine then get .h and .dll > on the otherside. > > The memory is allocated inside the .dll using C.malloc (which is basically > c malloc), and i try to free it inside the cpp file which is linked to this > dll. > > If i build a function inside the go code to free a recived pointer, which > will end up in the dll, then the problem is avoided. > > That being said, due to the fact that I have quite a few callbacks and a > large data transfer between the dll and my app i would like to keep it > simple and not have to use a third function to free the mallocs, as it is > also a problem if it happens the other way around, i.e., if i allocate > memory in the app and try to free it inside the library. > > Sorry if im unclear i tried to explsin it the best as i can. > > Ps yes i do use windiws, a side remark is that if i use gcc this does not > happen. > > -- 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: Freeing memory of a cgo library
Nope, not ATM. Go only works with gcc, even the dlls are made with gcc. There is a issue on that and it seems like there is some progress but it isn't clear when it will be usable. https://github.com/golang/go/issues/20982 Also note that even if Go uses msvc, you would still have issues freeing memory allocated in the dll through the exe unless maybe both of them are not static linking the runtime and are using the exact same runtime. You can see this for some info on the topic https://blogs.msdn.microsoft.com/oldnewthing/20060915-04/?p=29723 On Saturday, 26 May 2018 02:15:32 UTC+8, Liron Levy wrote: > > Well it is kinda reoated as im in this mass because of go :) > > Anyway, is there anyway to use cgo with msvc? I actually run the cgo > command from msvc cmd assuming the c part will be compiled with msvc. > > In addition as far as i know you can actually do that with visual studio > if you put the /md (multi threading) flag on. > > -- 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: how to reuse getters and setters of two different versions of struct ? [interface{}/generics]
This is what interfaces are for.
You have:
type GetKeyer interface {
GetKey1() string
GetKey2() string
}
Then to use it: https://play.golang.org/p/rvLsWCIBuxe
You still have to implement GetKey1 and GetKey2 on each struct, but you can
access them through a common interface without knowing the actual type.
On Saturday, 26 May 2018 02:23:39 UTC+8, anil kuncham wrote:
>
> Hi,
>
> I have a use case where there are two different versions of struct. The
> problem is when the model is retrieved from database, it can be of either
> version. Both structs have same getters implemented.
> This is what the code looks like.
>
> type structA {
>Key1 string
>Key2string
> }
>
> func(s *structA) GetKey1() string {
> return s.key1
> }
>
>
> type structB {
>Key3 string
>Key4string
> }
>
> func(s *structB) GetKey1() string {
> return s.key3
> }
>
> version, obj, err := getObjFromDB(args)
> if err != nil {
> return err
> }
>
> var objA *structA
> var objB *structB
>
> if version == "A" {
> objA := obj.(structA)
> } else if version == "B" {
> objB := obj.(structB)
> }
>
>
> I want this logic to be abstracted to one object so that subsequent code
> should like
>
> obj.GetKey() -> doesn't matter whether obj is of type structA or structB
>
> Any help is greatly appreciated. Thanks for your time to look into this.
>
>
>
>
>
>
--
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: I am confused.
Have you not seen my post about joining a chat server? Instead of waiting a day or so for each reply, people could reply instantly and hold your hand through setting things up. On Sunday, 27 May 2018 11:37:48 UTC+8, John wrote: > > Well I guess I would just use the Go playground so it is easier. > > > On Saturday, May 26, 2018 at 8:27:59 PM UTC-7, John wrote: >> >> I tried to find the terminal button but did not find it. And also I don't >> know but does the welcome screen say welcome using or something. Because I >> can't find the blue vertical line on the right. But to make matters >> worse Okay I confess: I am just a kid under 15, and me and my mom just >> moved to CA two years ago. And because of that she do not know much English >> so our computer is installed from a language that is nothing alike English. >> When I downloaded VS code it is in that language, and I don't know how to >> get it to English. But the good thing is I have good proper English. >> >> On Thursday, May 24, 2018 at 8:18:21 AM UTC-7, buc...@gmail.com wrote: >>> >>> When you open VS Code there is a welcome screen. On the left side of >>> the screen you open/create a program filename to work on. Note the BLUE >>> vertical line separating the narrow left window from the larger right >>> window where you do your program editing. Toward the bottom of that window >>> you'll see another BLUE horizontal line. Below that BLUE line click on the >>> "Terminal" and to the right of that you'll see the word "1: powershell" and >>> below those you'll see the intro to Windows Powershell and a command line >>> prompt. cd to the directory where the file you are working on is located. >>> >>> Thereafter, as you go along writing your program in the upper window, >>> you can drop down into the lower command line window periodically and you >>> can type 'go build yourfilename.go' and the go compiler will attempt to >>> compile your program, showing you any errors it hits along the way. If it >>> doesn't hit any errors, the command line will return. If it shows errors, >>> return to the upper window and fix them (the errors will usually show the >>> line number that had the error). >>> >>> Open a Windows command window elsewhere (on another monitor), cd to the >>> same directory you are in in the VS Code lower window and execute the >>> command, observing the output. Go back-and-forth between the VS Code IDE >>> and the command window to change your program to get the results you want. >>> >>> Go on and accomplish great things! I have no computer science >>> background, am not particularly smart, am a noob to Go and am able to write >>> a complex web server application with Go that does exactly what I want. >>> You can, too. Persistence! There are lots of free, .pdf books online that >>> teach you Go programming. >>> >>> (notice my liberal use of the word 'Go') >>> >>> >>> On Wednesday, May 23, 2018 at 11:04:38 PM UTC-6, John wrote: Yes I did, what do you mean by top part of the screen? On Wednesday, May 23, 2018 at 6:54:47 AM UTC-7, buc...@gmail.com wrote: > > Did you get Go installed? > >> >> -- 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: I am confused.
That's why I also linked discord (age 13) and irc On Sunday, 27 May 2018 17:07:10 UTC+8, David Skinner wrote: > > https://invite.slack.golangbridge.org/ > You Must be Over the Age of 16 to use chat server. > > You must be over age 13 to use GitHub > > On Sat, May 26, 2018 at 11:07 PM > wrote: > >> Have you not seen my post about joining a chat server? >> Instead of waiting a day or so for each reply, people could reply >> instantly and hold your hand through setting things up. >> >> On Sunday, 27 May 2018 11:37:48 UTC+8, John wrote: >>> >>> Well I guess I would just use the Go playground so it is easier. >>> >>> >>> On Saturday, May 26, 2018 at 8:27:59 PM UTC-7, John wrote: I tried to find the terminal button but did not find it. And also I don't know but does the welcome screen say welcome using or something. Because I can't find the blue vertical line on the right. But to make matters worse Okay I confess: I am just a kid under 15, and me and my mom just moved to CA two years ago. And because of that she do not know much English so our computer is installed from a language that is nothing alike English. When I downloaded VS code it is in that language, and I don't know how to get it to English. But the good thing is I have good proper English. On Thursday, May 24, 2018 at 8:18:21 AM UTC-7, buc...@gmail.com wrote: > > When you open VS Code there is a welcome screen. On the left side of > the screen you open/create a program filename to work on. Note the BLUE > vertical line separating the narrow left window from the larger right > window where you do your program editing. Toward the bottom of that > window > you'll see another BLUE horizontal line. Below that BLUE line click on > the > "Terminal" and to the right of that you'll see the word "1: powershell" > and > below those you'll see the intro to Windows Powershell and a command line > prompt. cd to the directory where the file you are working on is located. > > Thereafter, as you go along writing your program in the upper window, > you can drop down into the lower command line window periodically and you > can type 'go build yourfilename.go' and the go compiler will attempt to > compile your program, showing you any errors it hits along the way. If > it > doesn't hit any errors, the command line will return. If it shows > errors, > return to the upper window and fix them (the errors will usually show the > line number that had the error). > > Open a Windows command window elsewhere (on another monitor), cd to > the same directory you are in in the VS Code lower window and execute the > command, observing the output. Go back-and-forth between the VS Code IDE > and the command window to change your program to get the results you want. > > Go on and accomplish great things! I have no computer science > background, am not particularly smart, am a noob to Go and am able to > write > a complex web server application with Go that does exactly what I want. > You can, too. Persistence! There are lots of free, .pdf books online > that > teach you Go programming. > > (notice my liberal use of the word 'Go') > > > On Wednesday, May 23, 2018 at 11:04:38 PM UTC-6, John wrote: >> >> Yes I did, what do you mean by top part of the screen? >> >> >> On Wednesday, May 23, 2018 at 6:54:47 AM UTC-7, buc...@gmail.com >> wrote: >>> >>> Did you get Go installed? >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/ynKfU5JOHiY/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@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: I am confused.
Then you shouldn't even have a google account/gmail and shouldn't be posting on google groups. https://support.google.com/accounts/answer/1350409?hl=en > For all countries not listed below, 13 is the minimum age to manage your > own Google Account. The only legit way for you to have a google account would be for your parents to manage it for you, which I highly doubt is the case. https://support.google.com/families/answer/7101025 On Monday, 28 May 2018 08:31:42 UTC+8, John wrote: > > Okay I will confess my age: 9 .. > > On Saturday, May 26, 2018 at 9:07:26 PM UTC-7, alex@gmail.com wrote: >> >> Have you not seen my post about joining a chat server? >> Instead of waiting a day or so for each reply, people could reply >> instantly and hold your hand through setting things up. >> >> On Sunday, 27 May 2018 11:37:48 UTC+8, John wrote: >>> >>> Well I guess I would just use the Go playground so it is easier. >>> >>> >>> On Saturday, May 26, 2018 at 8:27:59 PM UTC-7, John wrote: I tried to find the terminal button but did not find it. And also I don't know but does the welcome screen say welcome using or something. Because I can't find the blue vertical line on the right. But to make matters worse Okay I confess: I am just a kid under 15, and me and my mom just moved to CA two years ago. And because of that she do not know much English so our computer is installed from a language that is nothing alike English. When I downloaded VS code it is in that language, and I don't know how to get it to English. But the good thing is I have good proper English. On Thursday, May 24, 2018 at 8:18:21 AM UTC-7, buc...@gmail.com wrote: > > When you open VS Code there is a welcome screen. On the left side of > the screen you open/create a program filename to work on. Note the BLUE > vertical line separating the narrow left window from the larger right > window where you do your program editing. Toward the bottom of that > window > you'll see another BLUE horizontal line. Below that BLUE line click on > the > "Terminal" and to the right of that you'll see the word "1: powershell" > and > below those you'll see the intro to Windows Powershell and a command line > prompt. cd to the directory where the file you are working on is located. > > Thereafter, as you go along writing your program in the upper window, > you can drop down into the lower command line window periodically and you > can type 'go build yourfilename.go' and the go compiler will attempt to > compile your program, showing you any errors it hits along the way. If > it > doesn't hit any errors, the command line will return. If it shows > errors, > return to the upper window and fix them (the errors will usually show the > line number that had the error). > > Open a Windows command window elsewhere (on another monitor), cd to > the same directory you are in in the VS Code lower window and execute the > command, observing the output. Go back-and-forth between the VS Code IDE > and the command window to change your program to get the results you want. > > Go on and accomplish great things! I have no computer science > background, am not particularly smart, am a noob to Go and am able to > write > a complex web server application with Go that does exactly what I want. > You can, too. Persistence! There are lots of free, .pdf books online > that > teach you Go programming. > > (notice my liberal use of the word 'Go') > > > On Wednesday, May 23, 2018 at 11:04:38 PM UTC-6, John wrote: >> >> Yes I did, what do you mean by top part of the screen? >> >> >> On Wednesday, May 23, 2018 at 6:54:47 AM UTC-7, buc...@gmail.com >> wrote: >>> >>> Did you get Go installed? >>> -- 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] is it normal for buildmode=shared and buildmode=c-shared to be ok with building package main with no exported functions?
Was looking through the issues tracker and saw someone having issues with trying to use buildmode=c-shared and I noticed he linked a package main with only a main function as the thing he is trying to build. So for lulz I tried building it with buildmode=c-shared followed by buildmode=shared and apparently it didn't complain about anything and generated a binary. -- 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.
