These are chat archives for miketheprogrammer/go-thrust

17th
Nov 2014
Shion Ryuu
@ShionRyuu
Nov 17 2014 09:51
thrust_shell will not exist and occupy more CPU if you stop the go program
test on windows, running "go run tutorial/basic_window.go"
Shion Ryuu
@ShionRyuu
Nov 17 2014 11:29
There are some warnings:
/home/secret/workspace/GoPath/src/github.com/miketheprogrammer/go-thrust/spawn/helper_linux.go:37: missing return at end of function
/home/secret/workspace/GoPath/src/github.com/miketheprogrammer/go-thrust/spawn/helper_linux.go:53: missing return at end of function
errors
Michael Hernandez
@miketheprogrammer
Nov 17 2014 12:32
Thanks shion
All, ill be in the office soon and be able to read the past few messages, and answer questions.
Reviewing pull requests now
thanks @averrin for the pr as well
Michael Hernandez
@miketheprogrammer
Nov 17 2014 12:38
@gerred Currently there is no way, @spolu is working on an IPC interface in thrust-core not sure what that will cover. We need strong devs to help plan out and contribute to go-thrust and add stuff like basic rpc control from javascript. Maybe expose a little bit of the go stl as well
Michael Hernandez
@miketheprogrammer
Nov 17 2014 14:26
@gerred Ideally, I would like to reuse the same kind of JSONRpc communication that go-thrust uses to communicate with thrust, to do communication from the browser context with go-thrust
we could create a theoretical package web, that encorporates all the necessary subpackages for achieving RPC over sockets
Michael Hernandez
@miketheprogrammer
Nov 17 2014 14:33
On the Readme I have a future of go thrust section, where i detail my request for people to help me figure out the best way to achieve a reasonable level of abstraction of communication between the browser and go-thrust
William McGann
@tehbilly
Nov 17 2014 14:44
AND I RETURN, somewhat. I have a bit to catch up on, apparently. Let me get some coffee and do some reading.
Michael Hernandez
@miketheprogrammer
Nov 17 2014 14:51
Not much actually, shion and averrin made PR's to fix a linux issue i let slip by into master, Gerred was asking about browser rpc to run the thrust commands
I was contemplating using github.com/tv42/birpc
its currently used in the chat example
William McGann
@tehbilly
Nov 17 2014 14:58
Have you looked at the stl rpc/jsonrpc packages?
Michael Hernandez
@miketheprogrammer
Nov 17 2014 15:00
Hmm, let me check them out again, i think i looked at them a while ago, coming from the nodejs community im so used to the "lets throw a package at it" solution to problems.
I have to actually do work as well this week, so will be working a little slower on go-thrust
oooooooo just found this on awesome-go
might be able to test our builds pretty efficiently with that, by compiling one of the examples.
Michael Hernandez
@miketheprogrammer
Nov 17 2014 15:29
@ShionRyuu Omg, that is critical, @tehbilly , shion discovered that if you close the go process first, the window stays open, but, the thrust_shell process shoots up to 99% utilization of cpu
implementing window close api, and deferring the close of all windows
Michael Hernandez
@miketheprogrammer
Nov 17 2014 15:41
@tehbilly Implementing a ton of window api's right now
William McGann
@tehbilly
Nov 17 2014 17:02
Today is going to be one of those days, apparently.
Let's see. Using gobuild.io is pretty cool. I use travis if I need CI for open source stuff, usually.
And if I am just cross-compiling (not useful for us, but would be good to keep in mind for later for examples) I use gox
Does the thrust_shell not have a check to terminate when the backend goes away? After n failed responses it should terminate.
Michael Hernandez
@miketheprogrammer
Nov 17 2014 17:04
gox and gobuild.io are useful for us, in terms of testing quickly
William McGann
@tehbilly
Nov 17 2014 17:04
go test should be our first line of defense, we need to stabilize the api and then start writing tests for the functions.
Back in a bit, setting up a new environment at work.
I'll be checking in.
Michael Hernandez
@miketheprogrammer
Nov 17 2014 17:05
yea, ill talk to spolu, for now im adding some Signal Channels
Definitely, I would love to discuss with you how to test this almost purely functional enviroment, there seems to be very little that can be unit tested, probably most of spawn, can be unit tested.
William McGann
@tehbilly
Nov 17 2014 17:07
We just need to set up mocks for sending messages to and receiving responses for command
Michael Hernandez
@miketheprogrammer
Nov 17 2014 17:07
oh yea, duh, i was starting that a while back :).
William McGann
@tehbilly
Nov 17 2014 17:08
Or we could actually spin up an instance and test the methods again, just clean up the downloads/resources afterwards.
Would make the tests tied to the version we fetch, but hey.
Also, I think we should allow a person to specify which version of thrust to download. With a tag "latest" for the latest one. Thought of that this morning. :D
Michael Hernandez
@miketheprogrammer
Nov 17 2014 17:12
That would be great, as long as we maintain compatibility support with previous versions
A person can already create their own ThrustProvisioner, however i admit we should add some flags to the default one,
Michael Hernandez
@miketheprogrammer
Nov 17 2014 17:30
signal.Notify(os.Interrupt) seems to break on windows
it just doesnt do anything and prevents the app from exiting
William McGann
@tehbilly
Nov 17 2014 17:33
Yeah, os.Interrupt isn't handled in windows
However, a defer should be used to clean things up
What's the cleanup method you're doing now, when you catch the signal?
Michael Hernandez
@miketheprogrammer
Nov 17 2014 17:37
connection.CleanExit()
or connection.Clean()
they are both new methods
I am not even sure i can kill a subprocess from a parent process on windows
Maybe if I defer on the main thread, it will get executed, but deferring from Goroutines does not work
we also need to do that PR, that improves Channel usage for managing routines, and quitting them.
Creating a ticket for @spolu now to kill thrust when parent process no longer exists
if thats even possible.
William McGann
@tehbilly
Nov 17 2014 18:50
You can, as long as you keep a handle to the process.
You can send arbitrary signals, too.
After opening a connection, I'd immediately defer connection.CleanExit() or whichever makes the most sense. And for the command, i'd defer process.Kill() or defer process.Signal(yourSignalChoiceHere)
Michael Hernandez
@miketheprogrammer
Nov 17 2014 19:13
both defer, and signal.Notify are needed, defer will work when normal exit has occured, and signal handlers will work otherwise
ive got a branch thats almost done, just doing cleanup, and then a flatten rebase
William McGann
@tehbilly
Nov 17 2014 21:21
Sounds good. I've been slammed at work today and have time for zero things.
Michael Hernandez
@miketheprogrammer
Nov 17 2014 22:09
It's cool, me too
Im currently working on the Handler Interface, trying to come up with a first stab at somewhat generic handlers
Also starting it with some basic TDD, so the thrust.go file will be tested with thrust_test.go
we will start adding tests iteratively while adding new functionality