iocamljs
iocamljs copied to clipboard
andrewray
how to create a stand-alone js notebook
Hi,
sorry for the naive question. I am trying to put online a small tutorial using static webpages, using a custom iocamljs kernel. I've read the documentation to successfully build my custom kernel.js but I don't know what to do next. What static files should I copy on my website?
(I've followed http://andrewray.github.io/iocamljs/adding_demos.html successfully)
Are you using a gh-pages site? The iocamljs site is processed with jekyll (by gh-pages) which does some (simple) templating stuff. If not then there are a couple of things to set up first. Basically, what you need is
static/... (copied from iocamljs#gh-pages)
test1.html
test2.html
notebooks/test1.ipynb
notebooks/test2.ipynb
In gh-pages the html files are created by jekyll by copying _layouts/iocamljs.html are replacing the {{ .. }} variables. This sets up the sites root path (for the various internal links), kernel name, and notebook name.
Are you are not using gh-pages then this will need to be done by hand. Let me know your target setup and I can try to help some more.
Would a crunch'ed binary with these static files be useful? Could then try in iocamljs-it-up foo.ml and have it magically be served up (or output a static html site). Similar to iocaml-server I guess; could fold it in there.
Cloning and using the gh-pages works well indeed (I missed that step while following the docs). Having a crunched version, which dumps the static contents locally -- which can be HTML/CSS customised easily -- would be awesome!
Iocamlserver has everything needed crunched up inside itself.
I'll add a -generate-static-site option to cover the most useful case of a single kernel and multiple notebooks. On 9 Oct 2014 12:19, "Thomas Gazagnaire" [email protected] wrote:
Cloning and using the gh-pages works well indeed (I missed that step while following the docs). Having a crunched version, which dump the static contents locally which can be customised easily, would be awesome!
— Reply to this email directly or view it on GitHub https://github.com/andrewray/iocamljs/issues/4#issuecomment-58495005.
I've just added a new static-site branch to andrewray/iocamlserver.
It's briefly described at http://andrewray.github.io/iocamljs/creating_static_sites.html
If you get a chance to test it that would be grand.
I'm testing this today. First refreshing iocaml's dependencies to latest cohttp by getting ocaml/opam-repository#3306 merged.
I've got iocaml to build against the latest library set, but it's not working properly. The websocket comms seems to be garbled. I cant see anything obvious, so I will need to build a simpler test case.
This is working out great for me. See https://avsm.github.io/ocaml-dockerfile/ for an example site I've deployed using the static site generator.
I've got some lashed up scripts that could be cleaned up in https://github.com/avsm/ocaml-dockerfile/commit/7b8dd1b4bdbe8bfc04436f48e7e04aea9e5cd556. I think that an opam-github plugin that combines the Travis, OCamldoc and IOCamlJS shell scripts would be pretty nice. I can do that once you release an iocaml so we don't need a pin anymore.
Also, it would be nice if the static site could be built purely locally without copying the js kernels into ~/.opam, but it's not a huge deal.
On Fri, Jan 2, 2015 at 4:09 PM, Anil Madhavapeddy [email protected] wrote:
This is working out great for me. See https://avsm.github.io/ocaml-dockerfile/ for an example site I've deployed using the static site generator.
I've got some lashed up scripts that could be cleaned up in avsm/ocaml-dockerfile@7b8dd1b https://github.com/avsm/ocaml-dockerfile/commit/7b8dd1b4bdbe8bfc04436f48e7e04aea9e5cd556. I think that an opam-github plugin that combines the Travis, OCamldoc and IOCamlJS shell scripts would be pretty nice. I can do that once you release an iocaml so we don't need a pin anymore.
I've hopefully found the problem with websockets - iocaml seems to be back again after the fix. We can either wait for a new websocket release or I could prepare an opam patch against 0.9 to get it working again.
Also, it would be nice if the static site could be built purely locally without copying the js kernels into ~/.opam, but it's not a huge deal.
What I could so is make the -js option a little smarter. If the argument has a .js extension, then I'll assume it's a full file path and use it directly, otherwise go looking up in the opam path with name munging.
That's odd - it seems to be working fine for me with websocket.0.9. The -js path munging sounds like a good plan too. I can pull together the opam-github plugin if you cut an iocamlserver release.
The js kernel code path doesn't use websockets so that should still work.
Will do a new release once websockets 0.9.1 is alive. On 3 Jan 2015 16:22, "Anil Madhavapeddy" [email protected] wrote:
That's odd - it seems to be working fine for me with websocket.0.9. The -js path munging sounds like a good plan too. I can pull together the opam-github plugin if you cut an iocamlserver release.
— Reply to this email directly or view it on GitHub https://github.com/andrewray/iocamljs/issues/4#issuecomment-68600282.
That makes sense; I was only using JS. Native code is so 2014.
On 3 Jan 2015, at 16:35, Andrew Ray [email protected] wrote:
The js kernel code path doesn't use websockets so that should still work.
Will do a new release once websockets 0.9.1 is alive. On 3 Jan 2015 16:22, "Anil Madhavapeddy" [email protected] wrote:
That's odd - it seems to be working fine for me with websocket.0.9. The -js path munging sounds like a good plan too. I can pull together the opam-github plugin if you cut an iocamlserver release.
— Reply to this email directly or view it on GitHub https://github.com/andrewray/iocamljs/issues/4#issuecomment-68600282.
— Reply to this email directly or view it on GitHub https://github.com/andrewray/iocamljs/issues/4#issuecomment-68600717.
byte-code is old skool coz rekursion is, like, you know, for beardies. native-code though - that would be kool.
andrewray/iocamlserver@55c9e864b000043d9c1e1883ec96fde9337f9931 should do the -js path munging. I'll need to do another round of testing before release but initial impressions seem favourable.