profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/hhugo/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

hhugo/deriving-yojson 13

Parse/convert ocaml value from/to yojson ast

hhugo/cairo-opa 3

Opa Cairo Binding

gpetiot/ocamlformat 0

Auto-formatter for OCaml code

hhugo/ace_of_ocaml 0

Bindings in js_of_ocaml for Ace editor

hhugo/alcotest 0

A lightweight and colourful test framework

hhugo/angstrom 0

Parser combinators built for speed and memory efficiency

hhugo/async_kernel 0

Jane Street Capital's asynchronous execution library (core)

hhugo/aws 0

OCaml client access to Amazon services, such as S3, EC2, FPS, etc.

hhugo/base 0

Standard library for OCaml

hhugo/bigstringaf 0

Bigstring intrinsics and fast blits based on memcpy/memmove

delete branch hhugo/ezjsonm

delete branch : jsoo-friendly-tc

delete time in 13 hours

PullRequestReviewEvent

Pull request review commentmirage/ezjsonm

Improve support for Js_of_ocaml

-.PHONY: build clean test doc install uninstall+.PHONY: build clean test test-js doc install uninstall  build: 	dune build  test: 	dune runtest +test-js:+	dune build @runtest-js

This diff is useless. There is no runtest-js alias anymore

hhugo

comment created time in 13 hours

pull request commentmirage/ezjsonm

Better errors and jsoo friendly

This should be closed

dinosaure

comment created time in 14 hours

pull request commentmirage/ezjsonm

Switch to JSOO-friendly algorithm for `json_of_src` (#41)

This should be closed

smondet

comment created time in 14 hours

Pull request review commentocaml/dune

Draft: Better jsoo support

 let rules (t : Dune_file.Tests.t) ~sctx ~dir ~scope ~expander ~dir_contents =       `Regular   in   let open Memo.Build.O in+  let modes =+    if Dune_project.dune_version (Scope.project scope) < (3, 0) then+      [ (Dune_file.Executables.Link_mode.exe, Loc.none) ]

How do I get it ?

hhugo

comment created time in a day

PullRequestReviewEvent

issue commentocaml/dune

dune-build-info only works when public_name is specified, even if only mode is JS

I'm pretty sure dune-build-info is broken with js_of_ocaml separate compilation. link_time_code_gen should be used in the jsoo codepath.

phated

comment created time in a day

PullRequestReviewEvent

Pull request review commentocaml/dune

Draft: Better jsoo support

 include Sub_system.Register_end_point (struct           | Best           | Byte ->             None-          | Javascript -> Some "node"+          | Javascript -> Some Jsoo_rules.runner         in-        SC.add_alias_action sctx ~dir ~loc:(Some info.loc) (Alias.runtest ~dir)+        let* runtest_alias =+          match mode with+          | Native+          | Best+          | Byte ->+            Memo.Build.return Alias.Name.runtest+          | Javascript -> Super_context.js_of_ocaml_runtest_alias sctx ~dir

jsoo tests are a bit special because they depend on a tool (node) that might not be available. I started to work on allowing more customization but I couldn't come-up with a good spec. Also, I don't have a use case for this. The PR focuses on jsoo instead.

hhugo

comment created time in a day

pull request commentocaml/dune

Draft: Better jsoo support

Looking good so far. Are we going to allow passing flags to the jsoo "linker"? (in separate compilation mode).

Yes. We could even allow flags for jsoo build-runtime

hhugo

comment created time in a day

pull request commentocaml/dune

Modular Jsoo settings [WIP]

I'm looking at this now. Will work on https://github.com/ocaml/dune/pull/5049

rgrinberg

comment created time in a day

pull request commentocaml/dune

Draft: Better jsoo support

@rgrinberg, do you want to help me land that PR ?

hhugo

comment created time in a day

PR opened ocaml/dune

Draft: Better jsoo support
  • [x] the tests stanza should run tests for all the modes defined. Allowing running tests in javascript automatically
  • [x] configure the default alias for runtest with js_of_ocaml. The main motivation is that we want people to be able to run tests even without node installed
  • [x] configure compilation mode in env
  • [ ] configure jsoo flags

Extends https://github.com/ocaml/dune/pull/1044

+264 -120

0 comment

14 changed files

pr created time in a day

create barnchhhugo/dune

branch : better-jsoo

created branch time in a day

push eventhhugo/ezjsonm

Hugo Heuzard

commit sha 894889c44f8d4d025b06c243c18089bd21d0158b

refactor to reduce allocations

view details

push time in 2 days

push eventhhugo/ezjsonm

Hugo Heuzard

commit sha f6bfcdd7988a446d97edbdccf3ee09d82550563f

more tests for deeply nested values

view details

push time in 3 days

push eventhhugo/ezjsonm

Hugo Heuzard

commit sha 431ed623e8c54c8365fc17b6a112dbb6aed245bd

defunctionalize the continuation

view details

hhugo

commit sha 7d7a8ba06db682ce4b3eef8a95c9f4e66d1a20f9

Update opam

view details

Hugo Heuzard

commit sha 82498a95e1fcddddb2d81a5652ba7f87e2e58eee

add runtest-js alias

view details

push time in 3 days

startedtmcgilchrist/ocaml-gitlab

started time in 4 days

pull request commentmirage/ezjsonm

Yet another jsoo friendly attempt (without cps)

Switch to GitHub action ?

hhugo

comment created time in 4 days

PR closed mirage/ezjsonm

Yet another jsoo friendly attempt
  • make existing tests run in javascript as well
  • add new tests failing in js due to stackoverflow
  • update the implementation and see the tests pass
+145 -70

6 comments

5 changed files

hhugo

pr closed time in 4 days

pull request commentmirage/ezjsonm

Yet another jsoo friendly attempt

Closing in favor of #48

hhugo

comment created time in 4 days

pull request commentmirage/ezjsonm

Yet another jsoo friendly attempt

Ah, yes, upgrading alcotest did it. Thanks. Can we change the opam file to require 1.5 with these patches?

I've fixed the opam file

hhugo

comment created time in 4 days

pull request commentmirage/ezjsonm

Yet another jsoo friendly attempt (without cps)

Can someone help with having node installed in the CI

hhugo

comment created time in 4 days

push eventhhugo/ezjsonm

hhugo

commit sha 00eab5c97313697901a4ae3fc452b11aa93be63c

Update opam

view details

push time in 4 days

issue commentocsigen/js_of_ocaml

RFC: ecmascript modules as primary build artifact

There are two ways to compile with jsoo:

Separate compilation (probably what you used), it is the default when using dune. libraries and modules are compiled individually to javascript and then linked together. In that mode there is no deadcode elimination and the runtime is included in full. This mode should be used during development because of the short feedback loop.

Whole program compilation, used in dune when --profile release. In that mode, jsoo does deadcode elimination and only include the part of the runtime it needs. Depending on size of the dependencies, compilation can easily take 10s or more.

cdaringe

comment created time in 5 days

issue commentocsigen/js_of_ocaml

RFC: ecmascript modules as primary build artifact

Thanks for taking the time to write all this.

I want to clarify one aspect for people reading this RFC

the full runtime is compiled, even if only a subset is used

What's nice about this, is that only the bare minimum import graph gets used, versus a full runtime!

js_of_ocaml is designed to only include the part of the runtime that it needs. It does not blindly including the whole runtime for not reason

$ cat test.ml 
let () = print_endline "Hello, world!"
$ ocamlc test.ml -o test.bc
$ js_of_ocaml test.bc
$ ls -lh test.js 
20K test.js

One of the reason for the size of the included runtime is that we try hard to keep the same semantic as regular OCaml. For example, print_endline is not translated to plain console.log, instead the output will be buffered, and flushed when needed, similar to regular OCaml

cdaringe

comment created time in 5 days

pull request commentmirage/ezjsonm

Yet another jsoo friendly attempt

I'm confused by this PR. What is the goal? It looks like it is testing whether the backend supports TCO, and then:

  1. on backends that support TCO, it uses the tail-recursive implementation (which itself uses CPS)
  2. on backends that do not support TCO, it uses a non-tail-recursive implementation

What is gained with (2)? If the backend does not support TCO, (1) is not compiled to tail-recursive calls either, so it should be equivalent to (2), right? (Or is the assmption that (2), being more direct code, will be faster than (1)?) I would assume that large inputs are going to blow the stack just like before.

I'm confused by you confusion.

Jsoo does not optimize TCO in general (cps) but is perfectly able to optimize mutually tail recursive functions. The PR similar to #45, remove cps for dict/object and array when general TCO is not supported. (2) is not completely tail recursive and will stack overflow on deeply nested values. See #48 for the full tail call version.

hhugo

comment created time in 6 days

push eventhhugo/ezjsonm

Hugo Heuzard

commit sha b1aabbfb629c4fe531ad0b189c4905b1c2765589

refactor

view details

push time in 6 days

push eventhhugo/ezjsonm

Hugo Heuzard

commit sha e6a37f90789c647e3304b2aa7ab594ef43ab0b93

cleanup implem

view details

push time in 6 days