Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to opam install cogutil #263

Open
gl-yziquel opened this issue Sep 6, 2023 · 4 comments
Open

Failed to opam install cogutil #263

gl-yziquel opened this issue Sep 6, 2023 · 4 comments

Comments

@gl-yziquel
Copy link
Contributor

gl-yziquel commented Sep 6, 2023

As I'm busy checking the status of ocaml integration with atomspace, I attempted to opam install . the cogutil.opam file. I get:

mini-me@virtucon ~/h/c/cogutil (master)> opam install .
[cogutil.opam-1.0] synchronised (git+file:///home/mini-me/home/cellar/cogutil#master)
[WARNING] Failed checks in opam file from upstream of cogutil:
    error 39: Command 'make' called directly, use the built-in variable instead
[ERROR] Package conflict!
  * Missing dependency:
    - g++
    unknown package

No solution found, exiting

This missing g++ package seems rather unexpected: g++ is of course installed on my system.

Anyway. Anything that may make me progress in cleaning up some bitrot would be welcome.

@linas
Copy link
Member

linas commented Sep 14, 2023

I notice that you've opened a number of open and ocaml-related issues in a number of opencog git repos. I'll try to address all of them with this comment/this issue. In short:

  • I cannot personally provide ocaml support, but I will accept patches if you submit them.
  • The ocaml type model is a terrible fit for Atomese, which makes caml support not very interesting.

Let me expand on that second bullet. ML and related systems (CaML, OCaML) use a static type system: types must be declared at compile time. This allows type checking, type casting, and a large variety of optimizations to be done at compile time. The AtomSpace is a dynamic type system: new types can be defined at runtime. It is more-or-less impossible to force-fit run-time types into OCaML.

I spent about a month trying to do this. After a while, it just became clear that it was a futile exercise. There doesn't seem to be any way of "tricking" OCaML into supporting run-time types. Even if such a trick could be found, it is unlikely to be stable & supported: it runs counter to the entire OCaML philosophy. Based on my experience with other engineering/design groups, it would be a matter of time before some lead OCaMLarchitect/engineer pronounced the while idea to be nonsense, and be forcefully against it.

And .. that's it. If you want to fool with it, fine. If you want to submit patches, I'll merge them. As a playground in which to try things, it can be fun. As a realistic path forward, its a dead-end.

@gl-yziquel
Copy link
Contributor Author

Hi.

I'm fairly familiar with OCaml. The impedence mismatch you noticed with OCaml is genuine. There could be some workarounds, but if you really want dynamic strong typing, you'd have to engineer quite a mess.

I'm not specifically interested in binding ocaml with atomese or metta. (Though that indeed could be fun...) My concern is much more simple:

I want the opencog ecosystem to be able to build fine with ocaml installed on Ubuntu 22 via apt. As of today, to get opencog to build, I need to uninstall ocaml, build opencog and atomese stuff, and then reinstall ocaml again. I hate it.

@linas
Copy link
Member

linas commented Sep 14, 2023

I upgraded to Debian bookworm (Debian 12.1, aka the latest Debian stable) just a few days ago, and am experiencing a variety of build problems. I'm knocking them down, now.

@linas
Copy link
Member

linas commented Sep 15, 2023

As of today, to get opencog to build, I need to uninstall ocaml, build opencog and atomese stuff, and then reinstall ocaml again. I hate it.

I disabled the OCaml build in the AtomSpace. I believe that this is enough to cure all your other OCaml problems. In particular, just don't opam anything, and it should be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants