eans I can't help with "Is there something I'm not taking into
> consideration, maybe?". Best of luck!
> cheers
>
>
> On 12/9/20, Dumitru Ungureanu wrote:
> > Yes, you can safely assume we can agree to disagree on the value of my
> > version for containment, no p
names should keep the confusion to a minimum.
On Wednesday, December 9, 2020 at 10:04:48 AM UTC+2 Gergely Födémesi wrote:
> On 12/9/20, Dumitru Ungureanu wrote:
> > I decided to place them all in one place for containment.
> Thanks! (Though I believe we can agree to disagree on the val
re your
> requirements/issues you came up with a solution for?
>
> To help with your original question, assuming your only goal is to
> manage all subtrees exposed by environment variables "go env" shows at
> least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR,
&
is short and complete, maybe you should
> check it out again.)
>
> The installed go compiler is really just a trivial tree.
>
> On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu wrote:
>
>> I don't use an installer. I set GOROOT/bin manually. And the rest
>> follows.
I don't use an installer. I set GOROOT/bin manually. And the rest follows.
Easy to remember, nothing to forget.
On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
> On 12/8/20, Dumitru Ungureanu wrote:
> > Paths in symmetry with the environmental
> >
Paths in symmetry with the environmental
variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
go/cache, GOENV is go/env.
Bonus points: modules in go/modules.
On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:
> On 12/7/20, Dumitru Ungureanu wr
Hi.
I'm currently using this directory tree for golang. Is there something I'm
not taking into consideration, maybe? Thanks.
├─ go
│ ├─ bin (GOBIN, where install command deploys binaries)
│ ├─ cache (GOCACHE, where cached builds await reuse)
│ ├─ modules
│ ├─ path (GOPATH, first workspace, w
It helps a lot! Thanks.
I now have two things to moan about.
If I was to pass c around, I would added it to the params list. If I had
more others, I'd built a struct. But now, if somehow I lose track of who's
passing what and where, hard times debugging ahead. Having them declared at
package l
First off, thank you for the time Jan.
Secondly, as far as my knowledge goes:
- your example is declaring the function in place, it doesn't pass the
variable around to another function, i.e. goConect
- my code evolved , so now, if I use a init func then it's off to init
passing the
In this particular case, w.DefineFunction Api does not acomodate such a
passing. Reason I asked in the first place. Dependency injection of what sort
can be used here...
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this g
I have this.
Enter code here...
package main
import (
"fmt"
"log"
"github.com/sciter-sdk/go-sciter"
"github.com/sciter-sdk/go-sciter/window"
)
var w *window.Window
func init() {
var err error
w, err = window.New(sciter.DefaultWindowCreateFlag, sciter.DefaultRect)
i
11 matches
Mail list logo
