# Contributing libraries **URL:** \ **Category:** General\ **Created:** [March 12, 2019, 8:50pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381 "2019-03-12T20:50:14Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 12, 2019, 8:50pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/1 "2019-03-12T20:50:14Z")
Over the years I have written lots of prolog code, some of which might be useful generally. Is there anybody on the team who’d be interested in a guided tour with an aim to identifying what might be good to share, and maybe how it should adapt to fit in among existing packs? ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 16, 2019, 5:27pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/2 "2019-03-16T17:27:14Z")
Okay, here’s a list of potentially useful stuff. Anything stand out as particularly wanted? - gen - declarative source code expansion system - A variety of non-standard extensions to CHR, implemented using source transformation. - struct.pl - functional - math - poly - failure-driven-test - equations.pl - diff\_list.pl - id\_var - table-0424 - readtable - read\_object - repl\_chr - units.pl - costvectors.pl - encoding - client4 - log - nb\_queue - util - tons of little functions ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 16, 2019, 5:28pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/3 "2019-03-16T17:28:12Z")
These are not in ready-to-share condition, so please just pick one and I will work to ready it. ---
**Author:** ![fnogatz](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/fnogatz/32/19_2.png) [@fnogatz](https://swi-prolog.discourse.group/u/fnogatz)\ **Post date:** [March 18, 2019, 7:36am UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/4 "2019-03-18T07:36:39Z")
> [@abaljeu](#): > > A variety of non-standard extensions to CHR, implemented using source transformation. Out of curiosity: what extensions have you implemented for CHR? ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 18, 2019, 9:19am UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/5 "2019-03-18T09:19:44Z")
Thanks for sharing. There seems to be a lot of nice stuff there. I think this mostly raises the question on how the Prolog community can best share code. For the moment we have two mechanisms - Be part of the bundled libraries, either as part of the core library or one of the bundled extension modules. This code should be well maintained, documented, portable and serve some purpose that justifies the added size and complexity to the project. There is surely (mostly old) stuff that should never have gotten in there ☹ - Distribute as a pack add-on, typically based on a GitHub repository. That is lightweight and judging the quality and value is totally up to the publisher and users. My original hope was that the packs would in part act as a playing field for stuff to be added to the main system. That didn’t really happen. The packs do influence the core system though. Consider e.g., _arouter_ that influenced the http\_dispatch library, _sort\_dict_ that gave rise to support dict sorting in the ECLiPSe derived sort/4, etc. One of the reasons is that many of the packs build on each other, creating a parallel universe that often duplicates significant parts of the core functionality. I typically do not want to copy that as I want to avoid that the core contains too many libraries that do more or less the same but a little differently. ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 18, 2019, 5:22pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/6 "2019-03-18T17:22:09Z")
For CHR, I implemented an alternate notation that made it much easier for some rules to write the code. **qqq** **++con1(…)** **– con2(…)** **++con3(…)** **\<=\> effect.** Rather than worry if something is simpagate, propagate, or reduce, I just declare what matches I want to keep and what deletes I want. Actually it’s a bit more sophisticated than the above description, and has stuff helpful for managing constraint interaction and lifetime. It’s hard to explain. **Query qis Matches \<=\> Code** Generates a chr constraint and a rule that acts as a Prolog query for Matching constraints. It will pass/fail/unify and not affect the database. ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 18, 2019, 5:25pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/7 "2019-03-18T17:25:44Z")
Only one question, Jan: What do other languages do? E.g. Python. I suspect part of their thing is a team of interested people who review contributions and enable people to amend core libraries which amendments may be integrated if the review board likes the change. ---
**Author:** ![nuclear\_ares](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/nuclear_ares/32/144_2.png) [@nuclear\_ares](https://swi-prolog.discourse.group/u/nuclear_ares)\ **Post date:** [March 19, 2019, 6:04pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/8 "2019-03-19T18:04:20Z")
One possibility: A team of [volunteer] curators, community voting on which packs to review =\> code gets reviewed =\> constructive criticism + suggestions on “what to do next” get published (preferrably on / reachable from the swipl packs pages == infrustructure requirements) =\> hopefully someone steps up ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 19, 2019, 7:26pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/9 "2019-03-19T19:26:00Z")
hm, with Discourse, we could create a dedicated forum and we could discuss contributions. ---
**Author:** ![nuclear\_ares](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/nuclear_ares/32/144_2.png) [@nuclear\_ares](https://swi-prolog.discourse.group/u/nuclear_ares)\ **Post date:** [March 19, 2019, 7:53pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/10 "2019-03-19T19:53:04Z")
My thoughts exactly. Before I got lost being all non-commited (like equal opportunities, man), and then decided to scratch the next possible paragraph. What I wanted to say was: "I think the community is small & friendly enough, so that reviewing could get carried out in public, so even “non-curators” could chime in (or at least lurk and soak in the expected “wisdom.of ages” … … and the inevitable [religious] crusades, i fear 😉 " ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 20, 2019, 8:13am UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/11 "2019-03-20T08:13:34Z")
Learning from others cannot be a bad idea. Anyone with good/bad experiences in communities that are sufficiently comparable? There are IMO two aspects: - How to make the pack system better? - How to make the core system libraries grow? With also a question on whether they should grow or new functionality should be primarily in extension packs? It seems a big selling point that the core system comes with a rich set of libraries that are maintained as a whole, is somewhat consistent without too much overlap and quite rarely suffers from regressions. At the same time, there is still a lot of stuff missing there (e.g., type and mode handling), some stuff is dubious (e.g., the BerkeleyDB interface), a mess (organization of the RDF/XML libraries), etc. A possible step good be real clean guidelines on what should be where? And, while I do think that a pack system with really minimal requirements is useful, could we somehow separate them in high quality and maintained vs. one-shot partial attempts to support something? ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 20, 2019, 2:52pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/12 "2019-03-20T14:52:07Z")
Could start by improving the structure of the documentation for these. It’s a bit confusing as is. 1. Under Download you have Add-Ons, which leads to Packs, described as “known packages”. Which it instructs to install using pack\_install. Can we not just call these Packages Tried that and it worked fine. One thing is missing: A text search for packs. If I want a “machine learning” pack, I want to search, not browse alphabetically by name. This is a nicely described pack: [http://www.swi-prolog.org/pack/list?p=plcairo](http://www.swi-prolog.org/pack/list?p=plcairo) Wolud be best to put the extended description under the title rather than below the fold. 1. Under Documentation you have Packages The first is Paxos. Is that new? I don’t see it on my computer. Second is ssl. Given that these are in code known as libraries, why does the website call them packages? ![image](https://global.discourse-cdn.com/free1/uploads/swiprolog/original/1X/55a5a3dc8a4712cb7599744d284ae98bcdbb1e39.png) The way this is structured is also kind of clunky. See how they are cut off both horizontally and vertically? How do I find a library? I’m also confused by the broader structure. Why is CLP not under packages? It’s under The SWI-Prolog Library. Why is Pengines in Packages and not SWI-Prolog Library? ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 20, 2019, 3:07pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/13 "2019-03-20T15:07:09Z")
Documentation aside. In Visual Studio for example I find two extension mechanisms. One is an IDE extension system, where within the IDE itself I get to browse and search and install extensions to the program. The other is a program library system where I get to browse and search and install libraries to my current project. Both of these are user-contributed, and all the content is user-managed, much like the pack system Prolog has. Additionally, Visual Studio Code is Microsoft’s Open Source project. In that the code for the IDE and the code for the .Net libraries are open source, and grown by the community under the direction of the Microsoft .net Core team. > The Microsoft team’s game plan is primary. They decide what they want added to the core, and direct contributions from others and vet them. I think that’s how SWI should go. The libraries you most want in the core libraries, you setup a project to intergrate. Contributors can work together to improve (under experimental) the style, quality, test suite, documentation, and then when it’s ready it gets published and promoted. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [March 20, 2019, 3:11pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/14 "2019-03-20T15:11:45Z")
For releasing and reviewing the code, why not just use github’s facilities for code review, with each piece having its own separate review? This will allow people to comment on specific parts (even after the code has been committed, I think), contribute changes, report bugs, suggest sharing a part or not sharing, etc. Other choices include phabricator (I know of one project that moved from phabricator to github tools, but don’t know if that was because of features or for other reasons). ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 20, 2019, 3:17pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/15 "2019-03-20T15:17:14Z")
When it gets down to the coding details, I like github fine. For getting public engagement, I think a forum here discussing what project to pursue. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [March 20, 2019, 3:27pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/16 "2019-03-20T15:27:23Z")
> [@abaljeu](#): > > For getting public engagement, I think a forum here discussing what project to pursue. So, use the forum to announce and point to github. The forum can still be used for design discussions and github for the details. Another possibility is to use Google Docs for making comments and having discussions on a design doc. (Something similar can be done by having the design doc as a README.md and commenting on that in github … but when I worked at Google, we tended to use Docs comments rather than code review tools (and our tools were much nicer than github’s) and eventually moving the design doc to a Markdown or similar file.) ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 20, 2019, 3:48pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/17 "2019-03-20T15:48:14Z")
The silly answer is of course history ☹ - **Packages** reside in the `packages` directory of the source tree. They are git submodules wrt. the main project and may or may not be installed. They should be considered optional components of the installation. If they are installed they indeed show up in the system library. As a normal user, the only thing you should be aware of is that not all installed systems ship with all of these. - **Packs** were invented to allow for lightweight user contributions. Anne used **Add ons** on the website. **Paxos** is not that new. It was extracted from the **TIPC** package as it can also work on top of the much more widely available UDP messaging. The package should not yet be in the distribution. It is far too immature. It would be great to have a mature implementation, so if anyone is interested … Part of the **CLP** libraries have been developed as part of the core system. There is no clear boundary to what should be in the core library and what would be better a package. So, yes this is all a bit of a mess. Maybe do this: - Rename **Packages** into **Optional components** in the manual. - Rename **Add-ons** into **Packages** (or **Packs**?) Update of the overall add-on/package page as well as the contents is of course another issue. A search facility is only one step though. With 279 items listed your browser search is still acceptable for the short term. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [March 20, 2019, 4:11pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/18 "2019-03-20T16:11:51Z")
Deviating a bit from the original posting (oh, how I miss threaded discussions!) … is there a mechanism for auto-updating of packs? (It would be so nice if I could just do “sudo apt-get upgrade” and magic happens everywhere …) OTOH, is there much harm in making packs non-optional? If I don’t use something, it occupies a few kB on my disk, which hardly matters nowadays (and if you’re on something space-constrained, like a Raspberry Pi, you probably want less than the standard install anyway). ---
**Author:** ![abaljeu](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/abaljeu/32/136_2.png) [@abaljeu](https://swi-prolog.discourse.group/u/abaljeu)\ **Post date:** [March 20, 2019, 4:12pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/19 "2019-03-20T16:12:18Z")
Core libraries Optional libraries Packs (user-contributed libraries) Optional Libraries I think would make sense for things that fit one of these categories: 1. Links to some other software that not everyone has 2. Has a different license 3. Is immature and we’re working on it becoming a core library. I don’t see a reason CLP or Regex are not now core. ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [March 20, 2019, 4:21pm UTC](https://swi-prolog.discourse.group/t/contributing-libraries/381/20 "2019-03-20T16:21:28Z")
You’re adding to the confusion. User packs can be upgraded using `?- pack_upgrade(Pack).` Extensions/components are upgraded during the build using `git submodule update` before building. I assume you refer to the extensions/components for being optional? Some definitely need be as they pull in a lot of dependencies. Think of `xpce`, which you typically do not on a server as it pulls in X11. But also JPL which is hard to get properly configured, ODBC, etc. If you do a default build you get it all and if you want to select I guess you know what you are doing. [Next page](https://swi-prolog.discourse.group/t/contributing-libraries/381.md?page=2)