Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 18 15:25

    pmoura on master

    Fix `os` library `directory_fil… Update SVG diagrams (compare)

  • Aug 18 10:37

    pmoura on master

    Minor improvement to the docume… Update FCube port list of known… (compare)

  • Aug 17 10:09

    pmoura on master

    Add new `[]` and `{}` edge case… Update SVG diagrams (compare)

  • Aug 15 17:43

    pmoura on master

    Additional test for the optiona… (compare)

  • Aug 15 08:30

    pmoura on master

    Update FCube port with comments… (compare)

  • Aug 15 08:09

    pmoura on master

    Workaround XSB operator issue p… (compare)

  • Aug 15 07:18

    pmoura on master

    Improve ports documentation (compare)

  • Aug 15 07:10

    pmoura on master

    Update FCube port list of known… (compare)

  • Aug 14 20:33

    pmoura on master

    Update the `NOTICE.txt` file fo… (compare)

  • Aug 14 19:41

    pmoura on master

    Add port of FCube: An Efficient… (compare)

  • Aug 09 10:00

    pmoura on master

    Additional test for the `setof/… (compare)

  • Aug 08 17:09

    pmoura on master

    Detect conflicts between `dynam… (compare)

  • Aug 08 08:38

    pmoura on master

    Improve instructions for runnin… (compare)

  • Aug 04 07:14

    pmoura on master

    Update version to 3.58.0-b01 in… Fix typo in the sample queries … (compare)

  • Jul 26 14:28

    pmoura on lgt3570stable

    (compare)

  • Jul 26 13:43

    pmoura on master

    Change version to 3.57.0 stable… (compare)

  • Jul 26 10:21

    pmoura on master

    Update bibliography and citatio… (compare)

  • Jul 26 09:32

    pmoura on master

    Simplify `gensym::reset_gensym/… Change new `genint` library to … Change version to 3.57.0 stable… (compare)

  • Jul 25 13:44

    pmoura on master

    Fix malformed TSV test file in … (compare)

  • Jul 25 10:26

    pmoura on master

    Add description of the `flags` … (compare)

Paulo Moura
@pmoura
The most important inherited predicate declaration is new/1, which you will ned to implement.
A Man With A Clever Disguise
@ACleverDisguise
    check(Term) :-
        (    valid(Term) ->
            true
        ;    var(Term) ->
            instantiation_error
        ;    type_error(rbtree, Term)
        ).
Could you explain this to me? The very first check in valid/1 is var(Term). So why a separate var(Term) clause in check/1?
Oh, I think I get it!
You're keeping the code steadfast instead of having a conditional inside valid/1.
valid/1 backs out if the value isn't grounded which makes the next clause trigger keeping all the choice point mangling in a single place.
Am I close?
Paulo Moura
@pmoura
In check/1, the var(Term) test is required to distinguish between instantiation and type errors.
A Man With A Clever Disguise
@ACleverDisguise
But why not put the var(Term) as the first test in check/1?
Like swap the var/1 and valid/1 tests.
Paulo Moura
@pmoura
Which object are you looking at?
A Man With A Clever Disguise
@ACleverDisguise
Sorry. Had to flee work (literally: the Delta outbreak here was sourced to a place 1km from work, so ... uh ... nobody's going to work for a few days at least).
This was in the rbtree.
Here's check/1:
    check(Term) :-
        (    valid(Term) ->
            true
        ;    var(Term) ->
            instantiation_error
        ;    type_error(rbtree, Term)
        ).
It calls valid/1 which is here:
    valid(X) :-
        var(X),
        !,
        fail.
    valid(t(Nil,Nil)) :-
        !.
    valid(t(_,Tree)) :-
        catch(check_rbtree_root(Tree), _, fail).
So the first clause of valid/1 calls var/1 right off the start. Then it does the weird cut and fail thing.
A Man With A Clever Disguise
@ACleverDisguise
Now by my reading that's saying, loosely, "if X is not grounded, fail hard so you don't come back".
Then the very next clause in the conditional calls var/1.
Throwing an instantiation_error.
Now what I don't understand is why you're structuring this. I thought exceptions wipe away choice points. As do conditionals, in fact? (One of the reasons why conditionals are considered code smell by people like ROK, IIRC?)
The construct var/1, !, fail looks a lot like you're trying to chew away choice points, but ... the action for the var/1 situation later is an exception so I'm a bit baffled.
Paulo Moura
@pmoura
See the documentation on the valid/1 and check/1 predicates.
That said, type-checking nowadays is preferably accomplished using the type object.
Jacob Friedman
@jacobfriedman
Could types be used over attributed variables?
Paulo Moura
@pmoura
I guess you could typ-check the attribute values. But note that attributed variables are not standard.
Paulo Moura
@pmoura
Logtalk 3.50.0 released with focus on improved documentation, developer tools, and test suites.
A Man With A Clever Disguise
@ACleverDisguise
Paulo: In the installation, could you copy settings.lgt forward when the dates in the header match that of settings-sample.lgt?
Paulo Moura
@pmoura
The logtalk_user_setupscripts already copies the $LOGTALKUSER/settings.lgt(or $LOGTALKUSER/settings.logtalk) file forward if it exists.
A Man With A Clever Disguise
@ACleverDisguise
I just installed 3.50.0 on three environments (Windows 10, Windows 10 WSL, Linux Mint) and in none of those cases did it copy settings.lgt forward.
I had to manually copy them forward from the backup.
Paulo Moura
@pmoura
I assume you used the Windows .exe installer? And either the the .deb or the .rpm installers on Linux Mint?
Paulo Moura
@pmoura
Paulo Moura
@pmoura
In the case of Linux and macOS, the backup of the $LOGTALKUSERdirectory and the copy of any settings.lgtor settings.logtalk file is done not by the installers but by running the logtalk_user_setup script. This script is automatically called when the $LOGTALKUSERdirectory is outdated due to a new Logtalk version been installed.
Paulo Moura
@pmoura
Also note that the settings file can be stored in other locations than the $LOGTALKUSERdirectory and thus not affected by the updating of that folder when installing a new Logtalk version.
A Man With A Clever Disguise
@ACleverDisguise
Used .exe for Windows and .deb for Mint, yes.
Different issue I can't fathom: I'm trying to print debug messages. It's not working. I've compiled the .lgt file with debug(on) in the options. I've manually added set_logtalk_flag(debug, on) in the load script. I am manually TYPING set_logtalk_flag(debug, on) in the toplevel. I am checking that current_logtalk_flag(debug, X) binds 'on' to X.
But all of my print_message(debug, component, Message) calls aren't doing a thing.
If I switch that to information, say, it works.
What step am I missing that makes debug messages display? Does it need to be run in the context of the debugger?
Paulo Moura
@pmoura
Printing of debug messages is indepedent of the debugger (which is an application).
You also don't need to compile code that calls logtalk::print_message(debug, component, Message)in debug mode.
Paulo Moura
@pmoura
You may also want to simplify the calls by defining a predicate shortcut. For example:
:- uses(logtalk, [print_message(debug, foo, Message) as dbg(Message)]).
Printing of debug message requires the debug flag to be on when the call is made, not when the code making the calls is compiled.
A Man With A Clever Disguise
@ACleverDisguise
I'm still completely unable to get debug messages to print. information, warning, error, etc. all do, but debug don't.
Paulo Moura
@pmoura
Maybe put the minimal code required to reproduce the issue in a public paste bin?
A Man With A Clever Disguise
@ACleverDisguise
Before that, just a quick question: in my debug.lgt file:
:- initialization((
    logtalk_load(loader),
    logtalk_load(debugger(loader)),
    set_logtalk_flag(debug, on),
    debugger::trace
)).
Paulo Moura
@pmoura
Isn't the loader file loading the code that you want to debug?