Type error when building: Uchar.t / int clash
aBathologist opened this issue · comments
I'm attempting to track down the source of the problem, but thought it might be useful to make note of hurdle here.
I wonder if this is perhaps a package conflict, or conflict in version. I see there is a definition of module Uchar
in notty.ml
, and I wonder if this is perhaps coming in to conflict with with the module Uchar
in the 4.04 std library. Or perhaps it is built with an older version of some package?
System
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.11.6
BuildVersion: 15G1217
Output
# x @ y in ~/Programming/ocaml/consolate/notty on git:master o [3:57:57] C:1
$ ./pkg/pkg.ml build --with-lwt true --examples true --debug true -v -v
pkg.ml: [INFO] topkg v0.8.1, running main
pkg.ml: [EXEC] ['type' 'git' 1>'/dev/null' 2>'/dev/null']
pkg.ml: [INFO] Build configuration:
pkg-name: notty
build-dir: _build
vcs: true
pinned: false
tests:
debug: true
debugger-support: false
profile: false
with-unix: true
with-lwt: true
benchmarks: false
examples: true
pkg.ml: [EXEC] ['ocamlfind' 'ocamlc' '-config' 1>'/var/folders/6y/fszsf5zj6vngmm7l_wrst7t00000gn/T/pkg.mlad2b95topkg']
pkg.ml: [EXEC] ['ocamlbuild' '-use-ocamlfind' '-classic-display' '-tag' 'debug' '-build-dir' '_build' '-plugin-tag' 'package(ocb-stubblr)' 'opam' 'pkg/META' 'CHANGES.md' 'LICENSE.md' 'README.md' 'src/notty.a' 'src/notty.cmxs' 'src/notty.cmxa' 'src/notty.cma' 'src/notty.cmx' 'src/notty.cmi' 'src/notty.mli' 'unix/notty_unix.a' 'unix/notty_unix.cmxs' 'unix/notty_unix.cmxa' 'unix/notty_unix.cma' 'unix/notty_unix.cmx' 'unix/notty_unix.cmi' 'unix/notty_unix.mli' 'lwt/notty_lwt.a' 'lwt/notty_lwt.cmxs' 'lwt/notty_lwt.cmxa' 'lwt/notty_lwt.cma' 'lwt/notty_lwt.cmx' 'lwt/notty_lwt.cmi' 'lwt/notty_lwt.mli' 'unix/dllnotty_unix_stubs.so' 'unix/libnotty_unix_stubs.a' 'examples/testpatterns.native' 'examples/letters.native' 'examples/keys.native' 'examples/colors.native' 'examples/sierpinski.native' 'examples/cuts.native' 'examples/thisbig.native' 'examples/runes.native' 'examples/crops.native' 'examples/mouse.native' 'examples/cursor.native' 'examples/sierpinski_lwt.native' 'examples/life.native' 'examples/linear.native']
ocamlfind ocamlopt -c -g -bin-annot -safe-string -package result -package uucp -package uuseg -package uutf -w A-4-33-40-41-42-43-34-44-48 -color always -I src -I unix -I lwt -o src/notty.cmx src/notty.ml
+ ocamlfind ocamlopt -c -g -bin-annot -safe-string -package result -package uucp -package uuseg -package uutf -w A-4-33-40-41-42-43-34-44-48 -color always -I src -I unix -I lwt -o src/notty.cmx src/notty.ml
File "src/notty.ml", line 154, characters 36-37:
Error: This expression has type Uchar.t
but an expression was expected of type int
Command exited with code 2.
pkg.ml: [ERROR] cmd ['ocamlbuild' '-use-ocamlfind' '-classic-display' '-tag' 'debug'
'-build-dir' '_build' '-plugin-tag' 'package(ocb-stubblr)' 'opam'
'pkg/META' 'CHANGES.md' 'LICENSE.md' 'README.md' 'src/notty.a'
'src/notty.cmxs' 'src/notty.cmxa' 'src/notty.cma' 'src/notty.cmx'
'src/notty.cmi' 'src/notty.mli' 'unix/notty_unix.a'
'unix/notty_unix.cmxs' 'unix/notty_unix.cmxa' 'unix/notty_unix.cma'
'unix/notty_unix.cmx' 'unix/notty_unix.cmi' 'unix/notty_unix.mli'
'lwt/notty_lwt.a' 'lwt/notty_lwt.cmxs' 'lwt/notty_lwt.cmxa'
'lwt/notty_lwt.cma' 'lwt/notty_lwt.cmx' 'lwt/notty_lwt.cmi'
'lwt/notty_lwt.mli' 'unix/dllnotty_unix_stubs.so'
'unix/libnotty_unix_stubs.a' 'examples/testpatterns.native'
'examples/letters.native' 'examples/keys.native'
'examples/colors.native' 'examples/sierpinski.native'
'examples/cuts.native' 'examples/thisbig.native' 'examples/runes.native'
'examples/crops.native' 'examples/mouse.native' 'examples/cursor.native'
'examples/sierpinski_lwt.native' 'examples/life.native'
'examples/linear.native']: exited with 10
I think this is #11.
I've really been enjoying working with is library (tho I've been it by pinning @dbuenzli's branch). Thanks for the great work!
It looks to me like some recent work may have gone towards addressing this issue in d0118de.
I wanted to offer my help, in case there is anything I can do to move this wonderful library over the Uchar
hump (so it can avoid future problems like #11 (comment)). I'd be very happy to lend a hand if it would be useful (including for dong more boring stuff, like packaging or updating documentation). Let me know if I can be of any use.
Either way, thanks again :)