sbinet

6 ms·

1.
by sbinet 2y ago
back in the days, one always had to have 2 terminals open to work with ROOT: one to work and the other to 'kill -9 root.exe' thanks to CINT happily completely destroying your TTY.
2.
by sbinet 2y ago
that's odd. TEfficiency is a relatively simple thing to read/write : - https://github.com/go-hep/hep/blob/main/groot/rhist/efficien...
3.
by sbinet 2y ago
IMHO, ROOT[3-5] is too many things with a lot of poorly designed API and most importantly a lack of separation between ROOT-the-library and ROOT-the-program (lots of globals and assumptions that ROOT-the-program is how people should use it)
4.
by sbinet 8y ago
there are actually a couple of real interpreters for Go: - neugram.io - https://github.com/cosmos72/gomacro here is a mybinder that used to use the former, and now uses the latter: - https://mybinder.org&#x2
5.
by sbinet 8y ago
> These are things that are great for product development and devops and not in fact all that valuable in scientific computing I disagree. Again, this may very well be science-domain dependent, but in High Energy Physics (where, finally,
6.
by sbinet 8y ago
wrt n-dim arrays: yes, it's a pain point. we (Gonum devs) tried to push for an "n-dim slice" type a couple of years ago. it didn't pan out. generics may help in that department. in the meantime, there's Apache Arrow
7.
by sbinet 8y ago
this is being worked on: - https://github.com/golang/tools/blob/master/cmd/golsp/main.g...
8.
by sbinet 8y ago
I guess it's scientific domain dependent. I've very rarely needed something else than float/double in my C++ days or REAL*8 in my F77 ones. sure, when you need it, you need it. but float64 caters for a good 99% of my usual wo
9.
by sbinet 8y ago
others have already mentioned Gonum: - https://gonum.org Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there. Go-HEP is my attempt to bring a few Hi
10.
Go-HEP: writing concurrent software with ease and Go(arxiv.org)
2 points by sbinet 8y ago|0 comments
11.
by sbinet 8y ago
Next step is to directly generate IR with (link: https://github.com/llir/llvm ) github.com/llir/llvm. And then rewrite all of llvm in Go :)
12.
by sbinet 8y ago
- the VM is written in Go and can execute wasm binaries - the next version of the Go toolchain (Go-1.11) will have a wasm target
13.
by sbinet 8y ago
there's actually (the beginning of) an interpreter in Go, for Go, that consummes wasm :) https://github.com/go-interpreter/wagon
14.
by sbinet 9y ago
as I am working on https://github.com/go-interpreter/wagon , I'd be very interested in these issues you're talking about.
15.
by sbinet 9y ago
> But Go doesn't have a JIT, and its performance is good enough that I don't expect one to emerge any time soon. that's true. that is... until a (real) Go interpreter shows up. something that's bound to happen when Go
16.
by sbinet 9y ago
I have been using Gonum for some time now (also contributed, mostly in the plotting area). Last summer, I tried an experiment: have a student migrate a little python-based analysis to a Go-based one. The analysis was fitting some cosmologic
17.
by sbinet 9y ago
also, there's been work to make for-loops preemptible: - https://github.com/golang/go/issues/10958 - https://go-review.googlesource.com/c/go/+/33910 - https://g
18.
by sbinet 10y ago
and for those doing the same but in Go: https://github.com/astrogo/fitsio (a pure Go version)
19.
by sbinet 10y ago
out of interest, what do you find lacking in https://github.com/gonum offering as a scientific stack?
20.
by sbinet 10y ago
I was challenging your "Go is not set up to have a REPL" assertion. we are in violent agreement about the (non) "REPL-ness" of _gore_ and the fact that "just keep compiling a module incrementally" is a dead end
21.
by sbinet 10y ago
I beg to differ. See: https://github.com/sbinet/igo It is a true REPL (not like "gore", mentioned somewhere in that thread). It doesn't implement the whole Go specs, but there's AFAICT nothing in th
22.
by sbinet 10y ago
you can even use it on the web: https://github.com/gopherds/mybinder-go
23.
by sbinet 10y ago
https://github.com/go-python/gopy it automatically creates a CPython-2 extension module out of a Go-1.5 package. I plan to update it for Go>=1.6 and also directly generate a "cffi" python module so CPython
24.
Gonum: 3 years (and a bit) old
6 points by sbinet 10y ago|0 comments
25.
by sbinet 11y ago
generating structs at runtime might land for go-1.7: https://go-review.googlesource.com/#/c/9251/4
26.
by sbinet 11y ago
state. as I said elsewhere in this HN thread, many of the first REPLs that appeared when Go was first released used this rather effective scheme of recompiling on the fly a single main.go file after each new input the user entered and re-ru
27.
by sbinet 11y ago
that's my personal bias. GoRe's REPL recompiles and re-runs the resulting binary after each line entered, accumulating side effects: $ gore gore version 0.2.5 :help for help gore> var i = 41 gore> f := func() { i+
28.
by sbinet 11y ago
ah, didn't know about CAAS. of course LLVM/CLang was also on our radar. we are still pondering on whether we should target LLVM bitcode so we could easily build upon LLVM toolchain (and cross-pollinate with other LLVM-based interp
29.
by sbinet 11y ago
interesting, it's true having a toolbox for creating go interpreters would be much more powerful. I am not sure I completely get what a compiler-as-a-service really is. could you expand please? (wrt JITing, yes, we considered it and it
30.
by sbinet 11y ago
actually, somebody already wrote a kernel for (at the time) IPython, using "my" github.com/sbinet/go-eval go interpreter: https://github.com/takluyver/igo my plan for this new go interpreter propos

More ›