- hard problems
- keep it simple
and many more
go generateor something to that effect.
env:In my fish config file (like .profile or .bashrc) I have the following:
set -g GOPATH $HOME/gorepo $HOMEThe -g indicates that I'm setting the GOPATH environment variable in the "global" space. Meaning this session or terminal window. Notice that I'm setting the values $HOME/gorepo and $HOME to the GOPATH variable.
GOPATH=/Users/rbucker/gorepoand I know this is the wrong value.
"Package names are central to good naming in Go programs. Take the time to choose good package names and organize your code well. This helps clients understand and use your packages and helps maintainers to grow them gracefully."I started playing with gotcl and one of the first things I did was fork it and merge the project with gotclsh. I even added a few examples in order to make sure it worked; and it did.
-- Sameer Ajmani (Package Names)
$ tclrepl fcopy "file1.txt" "file2.txt"and then in lisp
$ lisprepl (fcopy "file1.txt" "file2.txt")Inside the REPL I'm pretty certain all I need to do is join the args back together. The quoted params are already handled by the basic command line stuff. It's also interesting to note that a space is the separator character in both languages.
executeMe := strings.Join(flag.Args()," ")and then send the execMe to the interpreter. I have not decided on the exact command line but it should be pretty simple. There are only a few things that the REPL actually needs.
As I was investigating an implementation of flow based programming in Go, I realized that I needed an installation framework and that there were some similarities toI plan to talk about: Macroinator's design, tcl as an embedded DSL, a little flow based programming. and whatever I can do in the short time I have left.
frameworks like Chef, Puppet, Ansible and SaltStack. Meet the “installinator”; a “configuration as code” implementation of a DSL framed in Go using JSON for it’s configuration and thinking deeply about "Compose with functions, not methods.
brew update** note that tcl-tk is located in the homebrew/dupes folder. This is to indicate that the project tcl-tk duplicates some of the features in OSX.
brew install homebrew/dupes/tcl-tk
env GOPATH=/Users/rbucker/gocode go get github.com/nsf/gothicAt this point unless you've previously installed X11 header files and libraries you're going to get a compile error about a missing header file. So at this point I abandoned all hope of the tcl-tk working.
brew uninstall tcl-tk
brew install caskroom/cask/brew-cask** cask is a set of edge case brew tools. I'm not sure if there is any additional risk loading from here but I'm trying anyway. My bunny sense is telling me I should have created an OS X VM and practiced there.
brew cask install tcl** This is a different version of tcl. This one happens to be from ActiveState. I like those guys. I'm not exactly sure how much is their code but if tcl is going to work these guys are awesome. If you're going to write proper tcl you might want to try their tools. I think they can produce proper cross platform executables but it has been a while since I read anything about them.
brew cask uninstall tcl8) uninstall cask
brew uninstall caskroom/cask/brew-cask** even though something was installed as an admin user; when I uninstalled I was not prompted for the same admin credentials to remove them. Hmmm...
Namespacing is very sloppy. Importing a module dumps the entirety of its contents into your namespace. Method calls are just syntactic sugar: a.b() is exactly the same as b(a), so methods are also in the globalish namespace. Seems to rely extremely heavily on overloading.I applaud his commitment, the post was very long and addressed a number of topics. One thing that caught my eye was your criticism of nim namespacing or lack thereof. I'm not sure I have a strong enough opinion either way but one thing I have been noodling on is the notion of a monolithic codebase with a global namespace. Silly me, this is exactly how C does it so it's only natural that Nim does too. Java and C# privacy modifiers are nonsensical since "we" typically have access to the source. The Go implementation uses case for privacy but implements package namespaces which are easy to overlap meaning having to use aliases.
One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...