profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/copy/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.

copy/life 254

The definite Conway's Game of Life implementation in your browser. Features an infinite field & Hashlife

copy/gdbprofiler 85

Rich man's profiler, a profiler for native OCaml and other executables

copy/iwbtc 81

I Wanna Be Thy Copy

copy/images 71

Some OSs to test v86

copy/dotfiles 39

https://copy.sh/dotfiles/

copy/deoplete-ocaml 27

Asynchronous completion for OCaml in vim or neovim

copy/jslzjb-k 23

Fast compression for JavaScript (browser and node)

copy/fs2json 10

Create a json file from a folder

copy/falling-fellow 5

A game for Lounge's game jam

copy/google-result-plot 4

Plot search engine result hits. Via http://xkcd.com/715/

push eventcopy/nvim-lspconfig

Fabian

commit sha 90f6697d7beff36d1445c8cbcb675e06055c5eb3

Add fstar support

view details

push time in 6 hours

PR opened neovim/nvim-lspconfig

Add FStar support
+21 -0

0 comment

1 changed file

pr created time in a day

push eventcopy/nvim-lspconfig

Fabian

commit sha 9e23a5b6699c510d20b7457a50bdf53fe77fc2ca

Add fstar support

view details

push time in a day

fork copy/nvim-lspconfig

Quickstart configurations for the Nvim LSP client

fork in a day

delete branch copy/v86

delete branch : wasm

delete time in 2 days

push eventcopy/v86

Fabian

commit sha 85df1ec7982f53a98bba134f6026cf810dc2d4be

Expect tests: tlb offset is not stable

view details

push time in 2 days

PR merged copy/v86

Fix tests
+13 -13

0 comment

9 changed files

copy

pr closed time in 2 days

PR opened copy/v86

Fix tests
+13 -13

0 comment

9 changed files

pr created time in 2 days

issue closedcopy/v86

How to connect VM to the internet?

I'm trying to test out a Linux distro before I install it using this website, and I want to try using the internet on it. How am I supposed to do that?

closed time in 2 days

TheGlassPenguin

push eventcopy/v86

Progyan Bhattacharya

commit sha 9679e2c00aa53189f9498cf1e6da06d785e7b443

(feat) Docker: Add Support for Running inside Docker Container (#501) * (feat) Docker: Add Support for Running inside Docker Container Uses Alpine image as base to have minimal size. 2-step build process to get rid of source and library files after compilation and during runtime. Uses Python3 HTTP Server to serve static assets. Signed-off-by: Progyan Bhattacharya <bprogyan@gmail.com>

view details

Ryo Ota

commit sha 3648b4ba8895b7c8b01f13aa8e340775e3e17c88

fix docker-run command in README.md

view details

Ryo Ota

commit sha df94bd595a02f12a0384149ceaf650f510a12561

fix typo

view details

Ryo Ota

commit sha 51105a6700f47e8cf840676dd36469125fbbb82c

Fix debian build

view details

Fabian

commit sha a1c5db38a45cc5450d6cffd40755704cdc719221

Expect tests: tlb offset is not stable

view details

push time in 2 days

push eventcopy/v86

Ryo Ota

commit sha 51105a6700f47e8cf840676dd36469125fbbb82c

Fix debian build

view details

push time in 2 days

PR merged copy/v86

Fix debian build

Hi,

I fixed tools/docker/debian to build debian image. FROM i386/debian causes errors, "... bullseye-security InRelease' is not signed.", so I specified :buster. I added ../ to build-container.sh and build-state.js.

One thing I'm not sure is the following statement in tools/docker/debian/Readme.md.

Go to debug.html?profile=debian to start the generated container.

I don't know how to start the built debian. I confirmed I could run the built debian, modifying examples/arch.html instead.

image

But anyway, this PR fixed building of debian.

+8 -8

1 comment

3 changed files

nwtgck

pr closed time in 2 days

pull request commentcopy/v86

Fix debian build

Thanks!

One thing I'm not sure is the following statement in tools/docker/debian/Readme.md.

At one point in the past it was planned to release a debian profile, but it was scrapped and instead the Arch profiled was updated to Archlinux 32.

nwtgck

comment created time in 2 days

push eventcopy/v86

Ryo Ota

commit sha df94bd595a02f12a0384149ceaf650f510a12561

fix typo

view details

push time in 2 days

PR merged copy/v86

fix simple typo

Hi,

The PR fixes a simple typo.

+1 -1

0 comment

1 changed file

nwtgck

pr closed time in 2 days

issue closedcopy/v86

Arch Linux dhcpcd Networking not working

I've attempted to use dhcpcd to no avail, any other things I could try, sorry if this is a repeat, i'm probably just stupid. download

closed time in 2 days

JVGA8837

issue commentcopy/v86

Arch Linux dhcpcd Networking not working

In the Arch profile you need to run modprobe ne2k-pci first. Or just run ./networking.sh which does everything for you.

JVGA8837

comment created time in 2 days

pull request commentocaml/ocaml-lsp

Doc update performance

Can confirm this is significantly faster and fixes #504, thanks.

rgrinberg

comment created time in 6 days

issue closedocaml/ocaml

Pattern-matching on mutable field surprisingly allocates a closure

I suspect the OCaml developers might already be aware of this issue, however, as a user of the language, I found this behaviour quite surprising. The allocation showed up while optimising some code and was found using memtrace. Below is a reduced test case.

type t = {
    mutable buffer: Bytes.t;
    mutable line_to_byte: int array;
    mutable number_of_lines: int;
}

let get_line_start { line_to_byte; _ } i = Array.get line_to_byte i

Which compiles to (using 4.12.0 with flambda -O3):

0000000000015f40 <camlTest__get_line_start_177>:
   15f40:	48 83 ec 08          	sub    rsp,0x8
   15f44:	48 8b 58 08          	mov    rbx,QWORD PTR [rax+0x8]
   15f48:	49 83 ef 20          	sub    r15,0x20
   15f4c:	4d 3b 7e 08          	cmp    r15,QWORD PTR [r14+0x8]
   15f50:	72 2d                	jb     15f7f <camlTest__get_line_start_177+0x3f>
   15f52:	49 8d 47 08          	lea    rax,[r15+0x8]
   15f56:	48 c7 40 f8 f7 0c 00 	mov    QWORD PTR [rax-0x8],0xcf7
   15f5d:	00 
   15f5e:	48 8d 3d 2b 00 00 00 	lea    rdi,[rip+0x2b]        # 15f90 <camlTest__fun_242>
   15f65:	48 89 38             	mov    QWORD PTR [rax],rdi
   15f68:	48 bf 05 00 00 00 00 	movabs rdi,0x100000000000005
   15f6f:	00 00 01 
   15f72:	48 89 78 08          	mov    QWORD PTR [rax+0x8],rdi
   15f76:	48 89 58 10          	mov    QWORD PTR [rax+0x10],rbx
   15f7a:	48 83 c4 08          	add    rsp,0x8
   15f7e:	c3                   	ret    
   15f7f:	e8 8c c8 01 00       	call   32810 <caml_call_gc>
   15f84:	eb cc                	jmp    15f52 <camlTest__get_line_start_177+0x12>
   15f86:	66 2e 0f 1f 84 00 00 	cs nop WORD PTR [rax+rax*1+0x0]
   15f8d:	00 00 00 

0000000000015f90 <camlTest__fun_242>:
   15f90:	48 83 ec 08          	sub    rsp,0x8
   15f94:	48 8b 5b 10          	mov    rbx,QWORD PTR [rbx+0x10]
   15f98:	48 8b 7b f8          	mov    rdi,QWORD PTR [rbx-0x8]
   15f9c:	48 c1 ef 09          	shr    rdi,0x9
   15fa0:	48 39 c7             	cmp    rdi,rax
   15fa3:	76 0a                	jbe    15faf <camlTest__fun_242+0x1f>
   15fa5:	48 8b 44 83 fc       	mov    rax,QWORD PTR [rbx+rax*4-0x4]
   15faa:	48 83 c4 08          	add    rsp,0x8
   15fae:	c3                   	ret    
   15faf:	e8 94 cb 01 00       	call   32b48 <caml_ml_array_bound_error>
   15fb4:	66 66 2e 0f 1f 84 00 	data16 cs nop WORD PTR [rax+rax*1+0x0]
   15fbb:	00 00 00 00 
   15fbf:	90                   	nop

Changing the function to let get_line_start t i = Array.get t.line_to_byte i or making the field immutable fixes the issue.

closed time in 8 days

copy

issue commentocaml/ocaml

Pattern-matching on mutable field surprisingly allocates a closure

Makes sense, thanks.

copy

comment created time in 8 days

issue commentocaml/ocaml-lsp

Diagnostics are played back slowly if didChange events are coming in faster than diagnostics are produced

Sure:

00:00:03.796058 schedule ...
00:00:00.312077 Document.with_pipeline_exn begin
00:00:00.557834 Document.with_pipeline_exn end
00:00:00.000066 ok
00:00:00.831686 schedule ...
00:00:00.064203 schedule ...
00:00:00.000035 cancelled
00:00:00.154039 schedule ...
00:00:00.000033 cancelled
00:00:00.000335 schedule ...
00:00:00.000018 cancelled
00:00:00.271854 schedule ...
00:00:00.000031 cancelled
00:00:00.018779 schedule ...
00:00:00.000020 cancelled
00:00:00.067849 schedule ...
00:00:00.000034 cancelled
00:00:00.179250 schedule ...
00:00:00.000048 cancelled
00:00:00.115154 schedule ...
00:00:00.000033 cancelled
00:00:00.260367 schedule ...
00:00:00.000037 cancelled
00:00:00.131017 schedule ...
00:00:00.000035 cancelled
00:00:00.028162 schedule ...
00:00:00.000034 cancelled
00:00:00.327396 Document.with_pipeline_exn begin
00:00:00.378769 Document.with_pipeline_exn end
00:00:00.000039 ok
00:00:00.000340 schedule ...
00:00:00.019257 schedule ...
00:00:00.000037 cancelled
00:00:00.294601 Document.with_pipeline_exn begin
00:00:00.000050 schedule ...
00:00:00.413766 Document.with_pipeline_exn end
00:00:00.000045 ok
00:00:00.000256 Document.with_pipeline_exn begin
00:00:00.000022 schedule ...
00:00:00.347274 Document.with_pipeline_exn end
00:00:00.000038 ok
00:00:00.000267 Document.with_pipeline_exn begin
00:00:00.000072 schedule ...
00:00:00.443465 Document.with_pipeline_exn end
00:00:00.000036 ok
00:00:00.000335 Document.with_pipeline_exn begin
00:00:00.000019 schedule ...
00:00:00.511823 Document.with_pipeline_exn end
00:00:00.000038 ok
00:00:00.000276 Document.with_pipeline_exn begin
00:00:00.000097 schedule ...
00:00:00.566351 Document.with_pipeline_exn end
00:00:00.000034 ok
00:00:00.000307 Document.with_pipeline_exn begin
00:00:00.000020 schedule ...
00:00:00.586907 Document.with_pipeline_exn end
00:00:00.000050 ok
00:00:00.000344 Document.with_pipeline_exn begin
00:00:00.000147 schedule ...
00:00:00.677253 Document.with_pipeline_exn end
00:00:00.000040 ok
00:00:00.000347 Document.with_pipeline_exn begin
00:00:00.000021 schedule ...
00:00:00.684469 Document.with_pipeline_exn end
00:00:00.000043 ok
00:00:00.000288 Document.with_pipeline_exn begin
00:00:00.000020 schedule ...
00:00:00.711074 Document.with_pipeline_exn end
00:00:00.000034 ok
00:00:00.000275 Document.with_pipeline_exn begin
00:00:00.000151 schedule ...
00:00:00.757719 Document.with_pipeline_exn end
00:00:00.000040 ok
00:00:00.000290 Document.with_pipeline_exn begin
00:00:00.000099 schedule ...
00:00:00.822952 Document.with_pipeline_exn end
00:00:00.000052 ok
00:00:00.001334 Document.with_pipeline_exn begin
00:00:00.000065 schedule ...
00:00:00.407869 Document.with_pipeline_exn end
00:00:00.000037 ok
copy

comment created time in 8 days

issue commentocaml/ocaml-lsp

Diagnostics are played back slowly if didChange events are coming in faster than diagnostics are produced

Yes, the difference between ok's is bigger than the debounce time (this is with diagnostics_delay = 0.25, the previous log was with diagnostics_delay = 0.0):

00:00:03.997043 ok
00:00:00.001197 cancelled
00:00:00.051944 cancelled
00:00:00.000321 cancelled
00:00:00.069403 cancelled
00:00:00.047868 cancelled
00:00:00.144102 cancelled
00:00:00.000297 cancelled
00:00:00.248861 cancelled
00:00:00.041456 cancelled
00:00:00.071246 cancelled
00:00:00.184572 cancelled
00:00:00.113229 cancelled
00:00:00.186805 cancelled
00:00:00.204764 cancelled
00:00:00.000404 cancelled
00:00:00.114031 cancelled
00:00:00.135216 cancelled
00:00:00.917139 ok
00:00:00.670341 ok
00:00:00.698839 ok
00:00:00.787267 ok
00:00:00.745207 ok
00:00:00.831514 ok
00:00:00.795399 ok
00:00:00.408448 ok
00:00:00.360801 ok
00:00:00.363178 ok
…

Note that all entries that follow are ok's until the queueing effect has stopped.

copy

comment created time in 8 days

issue commentocaml/ocaml-lsp

Diagnostics are played back slowly if didChange events are coming in faster than diagnostics are produced

It does hit the cancelled branch, but less than I would expect. Repeating what I typed in the video above:

ok
cancelled
ok
cancelled
ok
cancelled
ok
ok
ok
ok
ok
ok
ok
ok
ok
…
copy

comment created time in 8 days

issue commentneovim/neovim

lsp: outdated diagnostics show up, slowly, after they have been fixed

A little confused by this, as the same argument would apply if we debounced text changes until leaving insert mode.

When debouncing with a timer of a second, the didChange event is sent to the lsp server one second after the last key is pressed (worst case). My proposal would send the didChange event immediately when insert mode is exited.

That said, I now think this is a lsp server issue (which are slow and/or queue up didChange events), and debounce_text_changes is good enough for dealing with such language servers.

mrnugget

comment created time in 9 days

issue commentocaml/ocaml-lsp

Diagnostics are played back slowly if didChange events are coming in faster than diagnostics are produced

Try increasing the setting to see if it does anything https://github.com/ocaml/ocaml-lsp/blob/master/ocaml-lsp-server/src/configuration.ml#L5

Yes, setting it to a higher value fixes the issue, and setting it to 0 makes the issue worse. That said, I prefer the setting of 0 since it reduces the latency before getting diagnostics (if it weren't for the queueing up of diagnostics). Or, in other words, it would be nice if ocaml-lsp could send diagnostics as fast as possible (one at a time), but collapse multiple change events instead of queueing them up.

copy

comment created time in 9 days

issue openedocaml/ocaml

Pattern-matching on mutable field surprisingly allocates a closure

I suspect the OCaml developers might already be aware of this issue, however, as a user of the language, I found this behaviour quite surprising. The allocation showed up while optimising some code and was found using memtrace. Below is a reduced test case.

type t = {
    mutable buffer: Bytes.t;
    mutable line_to_byte: int array;
    mutable number_of_lines: int;
}

let get_line_start { line_to_byte; _ } i = Array.get line_to_byte i

Which compiles to (using 4.12.0 with flambda -O3):

0000000000015f40 <camlTest__get_line_start_177>:
   15f40:	48 83 ec 08          	sub    rsp,0x8
   15f44:	48 8b 58 08          	mov    rbx,QWORD PTR [rax+0x8]
   15f48:	49 83 ef 20          	sub    r15,0x20
   15f4c:	4d 3b 7e 08          	cmp    r15,QWORD PTR [r14+0x8]
   15f50:	72 2d                	jb     15f7f <camlTest__get_line_start_177+0x3f>
   15f52:	49 8d 47 08          	lea    rax,[r15+0x8]
   15f56:	48 c7 40 f8 f7 0c 00 	mov    QWORD PTR [rax-0x8],0xcf7
   15f5d:	00 
   15f5e:	48 8d 3d 2b 00 00 00 	lea    rdi,[rip+0x2b]        # 15f90 <camlTest__fun_242>
   15f65:	48 89 38             	mov    QWORD PTR [rax],rdi
   15f68:	48 bf 05 00 00 00 00 	movabs rdi,0x100000000000005
   15f6f:	00 00 01 
   15f72:	48 89 78 08          	mov    QWORD PTR [rax+0x8],rdi
   15f76:	48 89 58 10          	mov    QWORD PTR [rax+0x10],rbx
   15f7a:	48 83 c4 08          	add    rsp,0x8
   15f7e:	c3                   	ret    
   15f7f:	e8 8c c8 01 00       	call   32810 <caml_call_gc>
   15f84:	eb cc                	jmp    15f52 <camlTest__get_line_start_177+0x12>
   15f86:	66 2e 0f 1f 84 00 00 	cs nop WORD PTR [rax+rax*1+0x0]
   15f8d:	00 00 00 

0000000000015f90 <camlTest__fun_242>:
   15f90:	48 83 ec 08          	sub    rsp,0x8
   15f94:	48 8b 5b 10          	mov    rbx,QWORD PTR [rbx+0x10]
   15f98:	48 8b 7b f8          	mov    rdi,QWORD PTR [rbx-0x8]
   15f9c:	48 c1 ef 09          	shr    rdi,0x9
   15fa0:	48 39 c7             	cmp    rdi,rax
   15fa3:	76 0a                	jbe    15faf <camlTest__fun_242+0x1f>
   15fa5:	48 8b 44 83 fc       	mov    rax,QWORD PTR [rbx+rax*4-0x4]
   15faa:	48 83 c4 08          	add    rsp,0x8
   15fae:	c3                   	ret    
   15faf:	e8 94 cb 01 00       	call   32b48 <caml_ml_array_bound_error>
   15fb4:	66 66 2e 0f 1f 84 00 	data16 cs nop WORD PTR [rax+rax*1+0x0]
   15fbb:	00 00 00 00 
   15fbf:	90                   	nop

Changing the function to let get_line_start t i = Array.get t.line_to_byte i or making the field immutable fixes the issue.

created time in 9 days

issue commentocaml/ocaml-lsp

Diagnostics are played back slowly if didChange events are coming in faster than diagnostics are produced

  1. I've reproduced this in 1.7.0 and 1.8.0
  2. neovim with nvim-lspconfig
  3. Linux

The plugin does have an option to debounce text changes sent to the lsp server, however that increases the delay I get a diagnostics (for example, after setting the debounce to one second I need to wait up to one second to get the latest diagnostic) and I believe this could be fixed on the ocaml-lsp side.

ocaml-lsp implements debouncing which should prevent the thing we see on the video; maybe you have file auto-save ON?

What do you mean by file auto-save? I believe lsp clients send didChange events on every keystroke by design (to support completion; and because the lsp client doesn't know if the server is working on diagnostics).

It seems that the lsp server calculates exactly one diagnostic per incoming didChange event, so perhaps the debouncing is not working correctly?

copy

comment created time in 9 days

issue closedcopy/life

life 1.06

is life 1.06 working?

closed time in 12 days

Bdoom

issue closedmodlfo/pla

Port to ppxlib

See https://discuss.ocaml.org/t/ocaml-migrate-parsetree-2-0-0/5991

closed time in 18 days

copy

issue commentmodlfo/pla

Port to ppxlib

Seems to have been fixed. Cheers!

copy

comment created time in 18 days