If anyone wants to stumble along with me, or mentor, feel free to check out the CE_Chargen code.
Back to learning Go
- Thread starter Leitz
- Start date
ShawnDriscoll
SOC-14 1K
Wow! Can you really import functions from a URL? "github.com/makhidkarun/CE_Chargen/travfunc"
Or was it meant to import from "travfunc"?
Or was it meant to import from "travfunc"?
In Javascript, yes.
In Java, if the permissions are set correctly, yes.
In Python, again, if the permissions are set correctly, yes.
All of them accept code in text-files. It's a known security hole in all of them.
Go's setup is an acquired taste. It uses directory stuff to track packages. Of course, it *may* be able to pull in and import, I'm still learning.
ShawnDriscoll
SOC-14 1K
I would kind of expect Go to have such features, because of the client/server nature of that Language.
Ok. It's packaging system is designed with github in mind. Kind of cool.
Sort of. Packages are like python modules or C libraries; they provide namespace and modularity. Go is designed as a systems language like C/C++.
In normal usage, as I understand it, I clone a repo in my workspace, the $GOPATH. So travfunc is in
in $GOPATH/src there are a few repository options, github.com, golang.org for some of the base stuff and language add-ons, gopkg.in, and gopl.io. It depends on where the package is housed. That said, most seem to be on github and I'm trying to stick with those.
My CE_Chargen code uses the go-sqlite3 package, so I git clone in $GOPATH/src/github.com/mattn and get the go-sqlite3 repo. I can then, in $GOPATH, install:
Which gives me a static library:
Go has pretty firm perceptions on how things should be done. Enforcing them, like directory structure, helps keep the code structured and clean. Like white space in python or "do...end" in Ruby, it's an acquired taste. The vargr_names code I wrote for Go 1.3 works under 1.8. No expected time-line for Go 2.0.
Since Rob Pike and Brian Kernighan are involved in Go, I expect good things.
In normal usage, as I understand it, I clone a repo in my workspace, the $GOPATH. So travfunc is in
Code:
$GOPATH/src/github.com/makhidkarun/CE_Chargen/travfunc/travfunc.goin $GOPATH/src there are a few repository options, github.com, golang.org for some of the base stuff and language add-ons, gopkg.in, and gopl.io. It depends on where the package is housed. That said, most seem to be on github and I'm trying to stick with those.
My CE_Chargen code uses the go-sqlite3 package, so I git clone in $GOPATH/src/github.com/mattn and get the go-sqlite3 repo. I can then, in $GOPATH, install:
Code:
go install github.com/mattn/go-sqlite3Which gives me a static library:
Code:
pkg/linux_amd64/github.com/mattn/go-sqlite3.aGo has pretty firm perceptions on how things should be done. Enforcing them, like directory structure, helps keep the code structured and clean. Like white space in python or "do...end" in Ruby, it's an acquired taste. The vargr_names code I wrote for Go 1.3 works under 1.8. No expected time-line for Go 2.0.
Since Rob Pike and Brian Kernighan are involved in Go, I expect good things.
Keeping things in the makhidkarun group, I've started breaking packages and files up. ce_tools will have the basics like dice rollers. There, person.go will be the stuff used to make basic characters. Will be adding more details like appearance, etc, down the road. plan on moving the names.db out of SQLite and into an array to remove the need for SQLite.
Critique and collaborators welcome!
Critique and collaborators welcome!
