Example how to use the options library

[hnbeck]

Hi,

is there some simple example code how to use the Logtalk Options library, including a "config" file and how to read and write options? I don't understand how to use it from the documentation in the handbook ;)

Remark: in SWI Prolog one way is to read a file via "load_files(File, [sandboxed(true), if(not_loaded)" containing some "config(Key, Value)." predicates and look for them via option(config(....))

Cheers

Hans

[pmoura]

Indeed the options library usage guidelines are a bit frugal. Meanwhile, there are three developer tools that use it (diagrams, lgtdoc, and packs) that provide usage examples (with lgtdoc likely being the simple one for you to browse).

Start by loading the library from your application loader file:

:- initialization((
    % library dependencies
    logtalk_load(options(loader)),
    logtalk_load(types(loader)),
    ...
    % application source files
    ...
)).

Then import the options category into the application objects that make available predicates that take a list of options and define its default options (with optional type-checking). For example:

:- object(foo,
    imports(options)).

    :- uses(list, [
        memberchk/2
    ]).

    :- uses(type, [
        valid/2
    ]).

    :- public(p/1).
    p(UserOptions) :-
        ^^check_options(UserOptions),
        ^^merge_options(UserOptions, Options),
        ...
        memberchk(baz(Boolean), Options),
        q(Boolean),
        ...

    default_option(bar(42)).
    default_option(baz(true)).

    valid_option(baz(Boolean)) :-
        valid(boolean, Boolean).

:- end_object.

See the library API documentation for details. Let us know if you need additional functionality from the library.

[hnbeck]

Thanks for the example :)
With respect of additional functionality: it seems that the options library is intended to handle comandline options, like "-key1 value1 -key2 value2..."
What I would need is a library to handle options given in a file as "key=value;" or "key= value1, value2, value3...;" or something like that. The syntax would be not important as long as the user can simply read, understand and modify it. A simple XML (but simple!) may be also useful. Than predicats like check_value(File, Key, Value) would look into the file and be true if Value is associated with Key and false if not.

At my current project, I'm working on an (basic) OWL reader. But OWL seems to me too heavy for simple options. In a bigger application like the "Traffic in Metaverse thing" I'm working on it may be appropriate. In this case, it would be nice to use the protocol of options to overwrite the behaviour to look into OWL for options. So: check_value(Object, Key, Vlaue) would be true if the data property Key of object Object is associated with Value, false otherwise and error if Object not exist.

Cheers

Hans

[pmoura]

With respect of additional functionality: it seems that the options library is intended to handle comandline options, like "-key1 value1 -key2 value2..."

Hum? Logtalk's options library handles (object or category) predicate options, nothing to do with command-line options. SWI-Prolog option library (that you allude to in your original question) also deals with predicates options.

What I would need is a library to handle options given in a file as "key=value;" or "key= value1, value2, value3...;" or something like that. The syntax would be not important as long as the user can simply read, understand and modify it. A simple XML (but simple!) may be also useful. Than predicats like check_value(File, Key, Value) would look into the file and be true if Value is associated with Key and false if not.

There's no library in Logtalk that implements file options. I'm also not aware of such a library in any of the supported Prolog backends. Are those plain Prolog files (i.e. no modules or objects)? Also, would modifying the file option values require some form of persistency?

[hnbeck]

Hi,

ok I see, there is a big mis-understanding on my side. I'm assuming I don't had interpreted the lgtdoc code corretly. Sorry for that. I never used predicate options, so this term is not common to me.

Maybe I'm opening a problem space where no problem is. To give the context: the SWI code I'm currently port to Logtalk uses a file with "config(Key, Value) " entries. It is loaded via load_files(File, [sandboxed(true), if(not_loaded)]". Options then queried with option(key, Value).

The Logtalk compiler had a problem with "sandboxed", a lot of errors comming in the sense "sandboxed ... cannot be reached".... And this was the very beginning of my question here :)

Again, sorry for confusion.

Cheers

Hans

[pmoura]

ok I see, there is a big mis-understanding on my side. I'm assuming I don't had interpreted the lgtdoc code corretly. Sorry for that. I never used predicate options, so this term is not common to me.

Passing a list of options to a predicate allows the user to customize it, overriding default options. For example, the lgtdoc::rlibrary(tools,[xml_spec(xsd)]) goal generates XML documenting files while overriding the default xml_spec(dtd) option.

Maybe I'm opening a problem space where no problem is. To give the context: the SWI code I'm currently port to Logtalk uses a file with "config(Key, Value) " entries. It is loaded via load_files(File, [sandboxed(true), if(not_loaded)]". Options then queried with option(key, Value).

There's no mention of a config/2 predicate in the documentation of the SWI-Prolog library(option). Maybe something else is being (also) used?

The Logtalk compiler had a problem with "sandboxed", a lot of errors comming in the sense "sandboxed ... cannot be reached".... And this was the very beginning of my question here :)

Can you provide a minimal example that reproduces those errors?

[hnbeck]

yep
That is a minimal config
xmpp_config.txt

and the basic example - a stripped down from the real code - is

:- object(xmppConfig).
	:- public([xmpp_client/1]).
	:- use_module(library(option), [option/2, option/3]).
	:- dynamic config/2.	

	:- meta_predicate(config(*, *)).

	xmpp_client(Client) :-
		xmpp_client([encrypted_config(false), config('xmpp_config.txt')], Client).
	 
	xmpp_client(Options, Client) :-
		option(config(File), Options),	!,
		load_config(File, Options).
	 
	load_config(File, _Options) :-
		load_files(File, [ sandboxed(true), if(not_loaded)] ).
	
:- end_object.

The error is (multiple times)

ERROR:    No permission to call sandboxed `'$current_source_module'(_29844)'
ERROR:    Reachable from:
ERROR:            user:prolog_load_context(A,B)
ERROR:            user:term_expansion(A,B)

Cheers

Hans

[pmoura]

Those errors came from SWI-Prolog itself. Not clear what's causing them.

But the code above will never work as I assumed you intended. Mainly, the call to the load_files/2 predicate will not load the contents of a file into the object (as that predicate is not, like every other Prolog built-in predicate, Logtalk-aware). Is there a reason why the contents of the xmpp_config.txt file are not simply found in the xmppConfig object itself as default option values? Something like:

:- object(xmppConfig,
	imports(options)).

	:- public([
		xmpp_client/1, xmpp_client/2
	]).

	xmpp_client(Client) :-
		xmpp_client(Client, []).
	 
	xmpp_client(Client, UserOptions) :-
		^^merge_options(UserOptions, Options),
		...
	 
	default_option(encrypted_config(false)).
	default_option(jid('myAcc@localhost')).
	default_option(host('localhost')).
	default_option(tls(none)).

:- end_object.

Would the solution sketched above work in your case?

[hnbeck]

Hi Paulo,

yes, it would. If I add something to fill the defaults out from a file then I can imagine to build a nice application option component. But the main value out of your example is that I've finally got (after a long time :D) the idea and usage of predicate options. Thank you very much for your time and help!

Cheers

Hans

[pmoura]

If I add something to fill the defaults out from a file then I can imagine to build a nice application option component.

If you absolutely need the defaults to be in a separate file, you can always use an include/1 directive inside the object. Something like:

:- object(xmppConfig,
	imports(options)).

	:- public([
		xmpp_client/1, xmpp_client/2
	]).

	xmpp_client(Client) :-
		xmpp_client(Client, []).
	 
	xmpp_client(Client, UserOptions) :-
		^^merge_options(UserOptions, Options),
		...
	 
	:- include('xmpp_config.txt').

:- end_object.```