I created Ofelia, being getting Vixie crond inside of a container is a nightmare (at least when I started the project, 1 year ago), with Ofelia is simply tasks.
As explained in the README, is a character from Mortadelo and Filemon[1], she is a office manager and I though that was a good simile to a job scheduler, obviously the intent is not make fun of the fat that she is fat.
I understand this and said that I'm not saying there was any bad intend. I'm just saying that some people will feel offended by this, so if this gets attention there will be people pointing this out.
This makes me wonder why I'm getting downvoted though.
Is it because people don't believe it's right that I point out that people might get offended by this?
Or is it more because people don't like that other people get offended by this?
It's likely the combination of the two. And a third option: folks who didn't read what you wrote closely enough and assume that you espouse those views. But to be fair to the first group (who "don't believe it's right that I point out that people might get offended by this"), having a reflex towards censoring topics/names/conversations that might make others uncomfortable is itself problematic IMO. The domain of all-things-that-might-make-others-uncomfortable is vast, and we should have discussions about subjects as they come.
For the record: I think you were genuinely trying to be helpful and don't deserve downvotes.
Yep is a very similar approach, I'm not familiar with gitgo, but we started to work on go-git before gitgo was published, so this is the reason why we have our own project instead of collaborating on a existing one.
Unfortunately NaN behavior seems to be hard-wired in encoding/json code. The proper way to fix it is perhaps taking encoding/json sources and converting marshalling/unmarshalling code to use go-duktape Push/To/etc. functions instead of JSON writing/parsing. That's indeed a sizable amount of work, though.
As of integrating (some of) changes from my fork to the go-duktape mainline, thanks a lot! Didn't get around to do it myself.
the main goal of CandyJS is allow to other developers build extendable programs without the requirement of compile.
A good example could be a chan bot in Go with plugins written on JS. (like https://github.com/djosephsen/lazlo) but with CandyJS the effort to make this will be minimal, since you can use the same structures on JS and Go.
About the performance, CandyJS javascript is much slower than pure Go, since the reflection is very expensive.
No the contexts in pools do not share any state. Once you call an Eval from Go-land you'll be tied to context until that Eval returns, but Go-land will yield during that time so other goroutines(/contexts) are free to execute. It's just a convenience for setting up and working with multiple contexts to take advantage of multiple cores. Probably better to think of it like a process-pool.
The use case I had was along the lines of:
* Bind/Expose a bunch of Go functions to N JS worker contexts.
* Execute a large queue of JS-functions using the workers.
Spidermonkey did actually have a way to do a kind of shallow copy of a context and save/restore stack, which shared state, however this actually ended up making things much slower for my use as it required locking the threads and constantly copying stacks.
the method and field names are converted to lowerCamelCase to be compliant with the JS coding style. Let's see if this transformation becomes a headache.
BTW this behaviour is undocumented, I will fix that.
