Add geas compat entry

[crownedgrouse]

A nice new feature ;>) https://github.com/crownedgrouse/geas

[fenollp]

I want to be able to extract the release window of a project, but it has to take into account this project's deps release windows.

What code do I need to write to come about this?

[crownedgrouse]

ok, you mean you want compat for project and deps, like plugins does, but with a tuple term as output. I forgot this point for your need. Let me add this. Come back ASAP.

[fenollp]

Yeah the idea is to know where the project can be built/ran. If it has deps, their compat have to be taken into account. Thanks :)

[crownedgrouse]

Please fetch last commits and try : geas:compat(".",global). README updated.

[crownedgrouse]

For erlydtl : /home/eric/git/debris/deps/erlydtl/src/erlydtl_compiler_utils.erl R15B03-1 erlang:integer_to_binary/1

[fenollp]

Works nicely, though on something depending on erlydtl I get:

0 erldocs master λ GEAS_USE_SRC=1 er -noshell -eval 'erlang:display(geas:compat(".", global)).' -s init stop
{"R15","R15B03-1","18.2","18.2"}

Even though: https://github.com/erlydtl/erlydtl#do-not-use-erlang-r16b03

[crownedgrouse]

Yes, for now geas do not tell if it works on release window, only if it runs. This simply allow to eunit and common tests to be sure to run, and maybe fail. I will however see if it is the case with this constraint on Erlydtl.

[crownedgrouse]

looks like R16B03 syntax tools is broken and fixed in R16B03-1 . I suppose it is not limited to erlydtl. R16B03 should simply not be used.

[fenollp]

Well, could geas detect that a project is using syntaxtools, then remove R16B03 from the returned window?

[crownedgrouse]

Compat give a continuous release window. Excluding a particular release is not possible for now. I think it is up to users to exclude this particular release from CI list or kerl. I will add this warning in limitation chapter for the moment and maybe think to this.

[fenollp]

Why not return a set of OTP releases?

[crownedgrouse]

This could be an idea, but I think to another opposite way. User could give list of its available release and another function returning the possible ones.

[crownedgrouse]

Your idea could be however done on compat/2 by giving a special atom or a function helper translating compat tuple to a list. But I do not have the release list in database ... I m doing the rebar3 plugin for 2.0.4 anouncement. Please wait for next release.

[crownedgrouse]

please fetch last commit . You can use w2l/1 function to translate compat tuple window to list of releases. Using environment variable GEAS_MY_RELS limit list to local possible releases. Tell me if it is ok for you. README updated for GEAS_MY_RELS documentation.

[fenollp]

0 erldocs master λ GEAS_USE_SRC=1 er -noshell -eval 'erlang:display(geas:w2l(geas:compat(".", global))).' -s init stop
["R15B03-1","R16B","R16B01","R16B02","R16B03","R16B03-1","17.0","17.1","17.3","17.4","17.5","18.0","18.1","18.2"]

I'm happy with a list of releases :) But the fact that "R16B03" is in there is wrong. Do you think you could fix this?

[crownedgrouse]

this is the next step , I need to give opportunity to exclude releases. . I need a general way to exclude some release depending module/function used. Not so simple but I'm working on this

[crownedgrouse]

I will postpone any announcement until it is ok. Do you have other wishlist ?

[fenollp]

Yes: why does geas uses os:env variables when it could take a proplist?

[crownedgrouse]

because it is mainly to be used in plugin for rebar or erlang.mk , and geas is not an OTP app where a config file can be used. But I note the demand. It may imply to create functions xxxx/y+1 in order to add options as last argument.

[crownedgrouse]

do you use rebar3 ? I will have a plugin for it shortly, need to add documentation. I'm interested in having a beta tester...

[fenollp]

I don't use any rebars. Was just curious for ENV vars, no need to write functions for that. Drop a line on #erlang or #erlounge on freenode or the frencherlang slack ;)

[crownedgrouse]

Please fetch last commit. Now by default some releases are discarded when some module or function used. (to keep anyway discarded release, use GEAS_DISC_RELS=0 ). Only a first entry set in src/geas_disc.hrl for syntax_tools/R16B03. To be augmented :>) but a big work probably.

[fenollp]

Probably a lot of work, that's where erldocs_erldocs will help :)

Checking your changes changed nothing: on erldocs R16B03 is still here, defining GEAS_DISC_RELS has no effect

[crownedgrouse]

by default it should work without GEAS_DISC_RELS set. how did you update ? i cannot see any clone yesterday. R16B03 is removed only if syntax_tools is used in analyzed project . I tested it successfully, please tell me on what project you did the test

[fenollp]

Pulled master then just ran make. Tried it on github.com/erldocs/erldocs (erlydtl is a dep).

How do you know when someone clones your repo? Where can I see this kind of info?

[crownedgrouse]

in your OWN repo : graphics / traffic show you how many clone are done per day and how many different visitors, with some useful stats on pages seen. I will test on your repo and see what is going wrong. Come back ASAP

[crownedgrouse]

when saying OWN repo, you must be logged as the owner of this repo. If logged off, graphics show only the public graphics.

[crownedgrouse]

hum github.com/erldocs/erldocs use erl.mk . but where are fetch dependencies ? geas use erlang.mk and rebar2/3 usages, i.e. deps/ or _build/ .

[crownedgrouse]

Works on my side:

1> geas:compat("/home/eric/git/erldocs/").
   R15                   18.2       Geas database       
---Min--------Arch-------Max----------------------------------------------------
   R15B03-1                         erlydtl              
                                    erldocs              
--------------------------------------------------------------------------------
   R15B03-1              18.2       Global project       
Disc. : R16B03

geas:w2l(geas:compat(".", global)). ["R15","R15B","R15B01","R15B02","R15B03","R15B03-1","R16B", "R16B01","R16B02","R16B03-1","17.0","17.1","17.3","17.4", "17.5","18.0","18.1","18.2"]

[crownedgrouse]

oops sorry, forget. I added 'lists' in geas_disc.hrl locally to test.

[crownedgrouse]

/home/eric/git/erldocs/deps/erlydtl/rebar.config.script load syntax_tools at runtime... hum . more complicated than expected....

[crownedgrouse]

stupid me. syntax_tools is not a module but several modules : erl_syntax, erl_tidy etc... let me fix.

[crownedgrouse]

bug was in syntax_tools-1.6.12/src/erl_syntax.erl but called in other syntax modules. please fetch again. sorry for the noise.

[fenollp]

Whoohoo! works great!

Regarding the syntax_tools thing, maybe the 'incompatible with this release' should trigger when any of syntax_tools' modules are used, or when the syntax_tools app is used?

For more general support of target-app dependencies:

• maybe geas can look for git URLs inside Makefile or rebar*.conf*? erldocs_other finds that most projects are roll-your-own-Makefile based. (and could provide geas with the discovered deps!)
• maybe it's just better to force projects' compatibility with rebar* or erlang.mk but then geas is a compatibility-checking tool…

[crownedgrouse]

not necessary because geas work with module/function/arity used in code. The fact of using erl_syntax in code (or other syntax_tools related modules) raise the discard of R16B03. So no need to check the applications loaded. geas is not built to replace rebar of erlang.mk or whatever, and won't fetch dependencies in place of them. if there is new build tool that use something else than deps/ or _build , I will add it.

[crownedgrouse]

BTW you could use src/geas_db.hrl in erldocs to add the starting release of each function/arity in official Erlang documentation. this is a really missing information. for example many people use ensure_all_started but are not aware it is not available in older releases . Unfortunately database start beginning R15 for now. but if you have running older releases , we could update it from older releases.

[fenollp]

I don't know projects running on releases older than R15B03 but I think for geas to support earlier releases doesn't cost much.

If geas prefixes M/F/A with the application name (thus N/M/F/A), then it could warn about module clashes and that is part of "checking compatibility with releases"

Adding "available for release #…" support to erldocs is a feature that was requested before and I agree it should be included. I'll write a ticket.

[crownedgrouse]

R15 is a trivial choice: I cannot reach to compile older release on my linux. I need a running release to get all exported functions in all modules and application. But I may try windows binaries maybe. geas is written only to detect what official Erlang release can compile and run a project . it is not planned to detect module clash, as far geas do not care of module that do not exists in its database. So module and functions created by the application is out of geas scope. however I could maybe create a function that return all distinct module/function/arity used in a project, so that a higher tool could use it for such need.

[fenollp]

What I am saying is to get the intersection of the set of modules of an OTP release and modules introduced by the project. If it is non-empty then show an error.

BTW is there a verbose mode? Something that explains why a release was excluded

[crownedgrouse]

Ok, got it. I plan to add a way to display/get why a rel is discarded. In plugin and by a call. For other subject, intersection , could be possible but I need to think about it.

[crownedgrouse]

Please fetch last commits. Logs and other some informations are now available after compat run. See API Changelog for 2.0.6

[crownedgrouse]

you can get log entries with erlang:get(geas_logs) or call geas:log() to print them. Variable GEAS_LOG tune only printing.

[crownedgrouse]

Hi Pierre, any update ? your site still not working...

[fenollp]

Sorry I had/have no time getting into this right now. Also to make other.erldocs.com work again I need to get it to a smaller size (I intend to move it to a Jekyll format)

[crownedgrouse]

size does matter ;>)

[crownedgrouse]

Note that geas now create a process dictionary entry with list of Exported functions, this can help you to check N/M/F/A clashes by merging geas calls on all apps/libs in a project .

[crownedgrouse]

Ping ?

[fenollp]

Hey @crownedgrouse while a more up to date version of the project is up at dev.erldocs.com, it has not been generated since mid June. The issue has to do with xmerl: I need to find a way for xmerl to not depend on ETS as it exhausts any number of ETS tables I give it pretty quickly…