profile
viewpoint

tianyicui/yixin 2

存乎一心

mbouaziz/backtothefutur 1

Around the 4004 Intel microprocessor

mbarbin/dune 0

A composable build system for OCaml.

mbarbin/macao 0

A general purpose game playing A.I. framework based on the Monte Carlo tree search algorithm.

mbarbin/opalang 0

The Opa Language for Web Application Development

mbarbin/spin 0

OCaml project generator.

pull request commenttmattio/spin

Preserve trailing newline characters at the end of template files when present

I think input_all works on all kinds of channels? in_channel_length only works on files, so you can use it for any channel.

Ah, yes - that's probably it.

The PR looks good to me, merging now, thanks a lot for your contribution

Great :slightly_smiling_face:. Thanks for spin!

mbarbin

comment created time in 14 days

pull request commenttmattio/spin

Preserve trailing newline characters at the end of template files when present

Hi @tmattio,

Thank you for looking into it :slightly_smiling_face:

My bad - I wasn't sure whether spin.exe already linked base.cmxa and incorrectly thought it did.

<details> <summary>base dependency</summary> <p>

The base package is indeed a build dependency of spin (required by parsexp) but doesn't make it to the linked targets.

spin$ dune clean && dune build --verbose 2>&1 | grep base.cmxa > /dev/null
EXIT 1 (no match)

</p> </details>

I reverted the new dep addition, and committed further based on your suggestions. While doing that, I had 2 minor questions, on which I'd like your input please (998f08d)

text mode vs binary mode

I wondered whether to open the files in binary mode rather than text mode. stdlib.mli has some comments about conversions happening in text mode than may influence the behavior of in_channel_length, whereas binary mode makes no conversion. Thus I currently favored the latest.

reading all at once vs reading in chunks

I've noticed Stdio.In_channel.input_all performs reading in chunks. I'm not sure why that is, rather than using really_input_string to read the whole file at once. If it's just to avoid the prior call to in_channel_length, then I don't have a concern with our 'read all at once' implementation. If there's another reason input_all is implemented the way it is, I may want to think about it.

Please let me know what you think. Thanks!

mbarbin

comment created time in 15 days

push eventmbarbin/spin

Mathieu Barbin

commit sha d96fc28a91ce139e85603058e4167d3e7ca6a99f

Remove stdio dependency Taking suggested implementations for read/write from: https://github.com/tmattio/spin/pull/123#issuecomment-977007511 https://github.com/tmattio/spin/pull/123#issuecomment-977022370

view details

Mathieu Barbin

commit sha 998f08de391183dd61258bc208813e353307da5c

Minor tweak to Spin_std.Sys read/write

view details

push time in 15 days

push eventmbarbin/spin

Mathieu Barbin

commit sha e6702dc7968f8f41070139d5af2440c607d35edd

Added opam dependency (stdio)

view details

push time in 16 days

push eventmbarbin/spin

Mathieu Barbin

commit sha d579b2385a99e7d7020251cd976bad34e65b0696

Added opam dependency (stdio)

view details

push time in 16 days

PR opened tmattio/spin

Preserve trailing newline characters at the end of template files when present

The current behavior of spin new is to generate template files without newline characters at the end.

dune build @fmt and git status show a warning for files without trailing newline: \ No newline at end of file

This PR proposes to keep the trailing newline characters at the end of template files, when originally present.

I considered the alternative of systematically adding a trailing newline on every generated file, but decided against it because I thought that:

  • a template authors may have reasons not to want this
  • they're probably better off fixing their original template files as well if they care about trailing newlines.

This PR introduces a new dependency in the stdio opam package. stdio only depends on base. I made a guess that adding this new dependency would be fine, since it does not seem to significantly grow the current set of transitive dependencies, simplifies spin_std.sys and comes with a performance improvement to read_all (although probably not noticeable on small files).

+24 -20

0 comment

4 changed files

pr created time in 16 days

create barnchmbarbin/spin

branch : patch-1

created branch time in 16 days

fork mbarbin/spin

OCaml project generator.

fork in 16 days

fork mbarbin/ocaml-stdint

Various signed and unsigned integers for OCaml

fork in 20 days

startedupenn-cis1xx/camelot

started time in a month

startedocurrent/opam-dune-lint

started time in a month

pull request commentsnowfrogdev/macao

[fix] `now()` causing runtime exception on Chrome

In the debug console on chrome, the following shows how to reproduce the core of the issue:

> var i = performance.now
undefined
> i()
Uncaught TypeError: Illegal invocation at <anonymous>:1:1 (anonymous) @ VM1365:1
> var j = () => performance.now()
undefined
> j()
2076082.200000003
mbarbin

comment created time in a month

PR opened snowfrogdev/macao

[fix] `now()` causing runtime exception on Chrome

When trying to execute macao on Chrome, I was getting a Type error: Illegal invocation traced to the execution of now().

I looked briefly on the web for info and found this which gave me the idea for the fix: https://coderedirect.com/questions/116205/uncaught-typeerror-illegal-invocation-in-javascript

Using an eta-expension and thus making the call in the context of performance seems to fix the issue for me.

I am not claiming this is a complete fix, adding there for your consideration. Please adapt as desired. Thanks!

+1 -1

0 comment

1 changed file

pr created time in a month

push eventmbarbin/macao

Mathieu Barbin

commit sha 804bb8b948e16ac0a801beebeffc583d9a8776f8

[fix] `now()` causing runtime exception on Chrome When trying to execute macao on Chrome, I was getting an Type error: Illegal invocation traced to the execution of [now()]. I looked briefly on the web for info and found this which gave me the idea for the fix: https://coderedirect.com/questions/116205/uncaught-typeerror-illegal-invocation-in-javascript Using an eta-expension and making the call in the context of performance seems to fix the issue for me. I am not claiming this is a complete fix, adding there for your consideration. Please adapt as desired. Thanks!

view details

push time in a month

fork mbarbin/macao

A general purpose game playing A.I. framework based on the Monte Carlo tree search algorithm.

fork in a month

more