Updated library to use Link Grammar v5 #10
Conversation
|
After a quick look -- I think its a mistake to copy the sources, and redistribute the data files. The language files are big, and new ones are coming .. Mandarin and Cantonese and French and revised English are being worked on, these will be distributed in SQL form; SQLite3 if you need them embedded. My knee-jerk reaction is that its a better idea to take the JS bindings, only, and stick them into main link-grammar sources. That way, everyone who gets LG also gets the JS bindings. In particular, this makes them easier to find, and avoids the version skew. |
|
In fact, I'm confused... the ONLY file that has JS in it seems to be |
|
Yes, that is the case. I would not expect anyone one wants to use the NPM link-grammar library to download the main LG sources, build them and move them to the correct place for Javascript to find them. That is very cumbersome. The only way I found to make it easy on JS developers was to build LG myself and throw in the compiled libs to interface with. The languages, same argument. I wouldn't expect devs to go find, download and copy over these files... Can you think of a better way to deal with this problem? |
|
Ah. Well, I don't know how javascript developers work, but in other parts of the world, the source distribution, and the binary distribution are normally kept separate. So, perl has CPAN, python has eggs, linux has distros (apt, rpm, yast, etc.) So the typical developer searches for some string name e.g. So, who builds these packages? well, the package maintainers do. They grab the source from somewhere (e.g. from github) build it, package it, create a package file that specifies any pre-reqs or co-reqs, and publish this ball of stuff on whatever server(s) maintain the distribution. I suggest the same here. The javaascript sources should reside with all of teh other link-grammar sources, and the package maintainer would then build and publish the package, working from the source. That way, the users do not need to go to github to get anything: it all comes from the distro. This also solves problems with needing to have different distros for different versions of windows, mac, linux: you don't have to worry about whether some guy wants a binary for winNT or OS9 or OSX or whatever: the package maintainer creates these. Meanwhile the user has a nice way of searching for and finding packages. It solves a lot of problems. |
|
Here: Yes, javascript does have a comprehensive archive registry (distro) tool, its called "npm". Read about it here: https://en.wikipedia.org/wiki/Npm_(software) So again, the right way to do things, it would seem to me, would be to put the javascript into the LG repo, then create an npm-style package, and publish that via npm. This solves a huge number of problems in one go. |
|
Please see this: opencog/link-grammar#1053 |
No description provided.