[m-users.] Mercury Development Docker, and Bisecting Debugger?

[Fabrice Nicol]

I've set up a Gentoo-based (amd64 branch) Docker image with a functional
version of Mercury (current github dev code with a few weeks' lag) and
common dev tools. I'll be uploading it to github in the first days of
January just in case it should be of any use.
Fabrice Nicol


Le mar. 21 déc. 2021 à 5:21 PM, <users-request at lists.mercurylang.org> a
écrit :

> Send users mailing list submissions to
>         users at lists.mercurylang.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.mercurylang.org/listinfo/users
> or, via email, send a message with subject or body 'help' to
>         users-request at lists.mercurylang.org
>
> You can reach the person managing the list at
>         users-owner at lists.mercurylang.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>    1. Re: Mercury Development Docker, and Bisecting Debugger?
>       (Paul Bone)
>    2. Re: Mercury Development Docker, and Bisecting Debugger?
>       (Volker Wysk)
>    3. Re: Mercury Development Docker, and Bisecting Debugger?
>       (Zoltan Somogyi)
>    4. Re: Mercury Development Docker, and Bisecting Debugger?
>       (Volker Wysk)
>    5. Useful predicates for loops of IO actions (Volker Wysk)
>    6. Re: Useful predicates for loops of IO actions (Zoltan Somogyi)
>    7. Possiblt stupid list question.... (Sean Charles (emacstheviking))
>    8. Re: Useful predicates for loops of IO actions (Volker Wysk)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 21 Dec 2021 12:13:56 +1100
> From: "Paul Bone" <paul at bone.id.au>
> To: Prolog Rules <prologrules at gmail.com>
> Cc: users at lists.mercurylang.org
> Subject: Re: [m-users.] Mercury Development Docker, and Bisecting
>         Debugger?
> Message-ID: <20211221011356.GA16396 at sulfur>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hi, I published a docker image here:
> https://hub.docker.com/r/paulbone/mercury
>
> It's built around the debian packages.  If you're using a Debian/Ubuntu
> system just use those directly http://dl.mercurylang.org/deb/
>
> Pretty sure this is a slightly older version of Mercury. Updating it is on
> my TODO list ;-)
>
> Good luck.
>
>
> --
> Paul Bone
> http://paul.bone.id.au
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 21 Dec 2021 08:56:06 +0100
> From: Volker Wysk <post at volker-wysk.de>
> To: Peter Wang <novalazy at gmail.com>, Prolog Rules
>         <prologrules at gmail.com>
> Cc: users at lists.mercurylang.org
> Subject: Re: [m-users.] Mercury Development Docker, and Bisecting
>         Debugger?
> Message-ID:
>         <e6d959f0e220664fbebbcfeaee15e83a4a010724.camel at volker-wysk.de>
> Content-Type: text/plain; charset="utf-8"
>
> Am Dienstag, dem 21.12.2021 um 11:34 +1100 schrieb Peter Wang:
> > asm_fast.gc.decldebug.stseg is the one you will need to use the
> > declarative debugger.
>
> Is the declarative debugger different from the normal debugger, "mdb"?
>
> Bye, Volker
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: This is a digitally signed message part
> URL: <
> http://lists.mercurylang.org/archives/users/attachments/20211221/866a50f2/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 21 Dec 2021 19:08:16 +1100 (AEDT)
> From: "Zoltan Somogyi" <zoltan.somogyi at runbox.com>
> To: "Volker Wysk" <post at volker-wysk.de>
> Cc: users <users at lists.mercurylang.org>
> Subject: Re: [m-users.] Mercury Development Docker, and Bisecting
>         Debugger?
> Message-ID: <E1mzaC0-00061h-1b at rmmprod06.runbox>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> On Tue, 21 Dec 2021 08:56:06 +0100, Volker Wysk <post at volker-wysk.de>
> wrote:
>
> > Am Dienstag, dem 21.12.2021 um 11:34 +1100 schrieb Peter Wang:
> > > asm_fast.gc.decldebug.stseg is the one you will need to use the
> > > declarative debugger.
> >
> > Is the declarative debugger different from the normal debugger, "mdb"?
>
> Yes and no. It is invoked from within mdb, via the "dd" command,
> but it is quite different. Within the declarative debugger, the debugger
> itself
> decides what to look at next, though you can control it. If you know
> military
> terminology, think of yje as the debugger being a tactician that executes
> your chosen strategy.
>
> Also, to make full use of the declarative debugger, you have to compile
> your program in a grade whose name contains "decldebug", not just
> "debug". This puts into the executable the extra info that the declarative
> debugger can use but non-dd mdb does not.
>
> See section 7.11 of the Mercury users' guide.
>
> Zoltan.
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 21 Dec 2021 09:11:24 +0100
> From: Volker Wysk <post at volker-wysk.de>
> To: zoltan.somogyi at runbox.com
> Cc: users <users at lists.mercurylang.org>
> Subject: Re: [m-users.] Mercury Development Docker, and Bisecting
>         Debugger?
> Message-ID:
>         <836b8a0960fab5c72a583f239245956709001a55.camel at volker-wysk.de>
> Content-Type: text/plain; charset="utf-8"
>
> Am Dienstag, dem 21.12.2021 um 19:08 +1100 schrieb Zoltan Somogyi:
> >
> > On Tue, 21 Dec 2021 08:56:06 +0100, Volker Wysk <post at volker-wysk.de>
> wrote:
> >
> > > Am Dienstag, dem 21.12.2021 um 11:34 +1100 schrieb Peter Wang:
> > > > asm_fast.gc.decldebug.stseg is the one you will need to use the
> > > > declarative debugger.
> > >
> > > Is the declarative debugger different from the normal debugger, "mdb"?
> >
> > Yes and no. It is invoked from within mdb, via the "dd" command,
> > but it is quite different. Within the declarative debugger, the debugger
> itself
> > decides what to look at next, though you can control it. If you know
> military
> > terminology, think of yje as the debugger being a tactician that executes
> > your chosen strategy.
>
> This sounds interesting.  :-)
>
> > Also, to make full use of the declarative debugger, you have to compile
> > your program in a grade whose name contains "decldebug", not just
> > "debug". This puts into the executable the extra info that the
> declarative
> > debugger can use but non-dd mdb does not.
> >
> > See section 7.11 of the Mercury users' guide.
>
> Okay, thanks. I'll read the user's guide.
>
> Cheers,
> Volker
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: This is a digitally signed message part
> URL: <
> http://lists.mercurylang.org/archives/users/attachments/20211221/35e21661/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 21 Dec 2021 16:18:48 +0100
> From: Volker Wysk <post at volker-wysk.de>
> To: Mercury Users <users at lists.mercurylang.org>
> Subject: [m-users.] Useful predicates for loops of IO actions
> Message-ID:
>         <02f305e17818d6170a68b98855a3d85b70c7d5b5.camel at volker-wysk.de>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Mercury developers!
>
> I'm using four meta-predicates which deal with loops and IO, and I find
> them
> useful. Maybe you want to include them in the Mercury libraries? They
> correspond to map, foldl and filter, but they additonally thread through an
> IO state. They are the same as Haskell's "mapM", "mapM_", "foldM" and
> "filterM" combinators.
>
> Here are the IO-versions for map. In the first one, the IO-predicate's
> result is collected and returned as a list. In the second one, the IO-
> predicate doesn't have a return value. It's just the threading of the IO
> state that's is wanted:
>
> :- pred map_io(pred(T, U, io, io)::in(pred(in, out, di, uo) is det),
>                list(T)::in,
>                list(U)::out,
>                io::di, io::uo)
>    is det.
>
> :- pred map_io(pred(T, io, io)::in(pred(in, di, uo) is det),
>                list(T)::in,
>                io::di, io::uo)
>    is det.
>
> This is the IO-version of foldl:
>
> :- pred fold_io(pred(T, A, A, io, io)::in(pred(in, in, out, di, uo) is
> det),
>                 list(T)::in,
>                 A::in,
>                 A::out,
>                 io::di, io::uo)
>    is det.
>
> And the IO version of list.filter/4:
>
> :- pred filter_io(
>     pred(T, bool, io, io)::in(pred(in, out, di, uo) is det),
>     list(T)::in,
>     list(T)::out,
>     list(T)::out,
>     io::di, io::uo)
>    is det.
>
> If you'd like to include these predicates, I'd provide proper comments and,
> of course, the implementation.
>
> Happy hacking, Volker
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: This is a digitally signed message part
> URL: <
> http://lists.mercurylang.org/archives/users/attachments/20211221/5fc5c861/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 6
> Date: Wed, 22 Dec 2021 02:51:28 +1100 (AEDT)
> From: "Zoltan Somogyi" <zoltan.somogyi at runbox.com>
> To: "Volker Wysk" <post at volker-wysk.de>
> Cc: Mercury Users <users at lists.mercurylang.org>
> Subject: Re: [m-users.] Useful predicates for loops of IO actions
> Message-ID: <E1mzhQG-00057t-T7 at rmmprod06.runbox>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> On Tue, 21 Dec 2021 16:18:48 +0100, Volker Wysk <post at volker-wysk.de>
> wrote:
> > I'm using four meta-predicates which deal with loops and IO, and I find
> them
> > useful. Maybe you want to include them in the Mercury libraries?
>
> Three out of the four are already there, in more general forms. Instead of
> the last pair of arguments required to be I/O states, they can be any type,
> and their modes do not have to be di/uo; they can be e.g. in/out.
>
> > :- pred map_io(pred(T, U, io, io)::in(pred(in, out, di, uo) is det),
> >                list(T)::in,
> >                list(U)::out,
> >                io::di, io::uo)
> >    is det.
>
> This is list.map_foldl.
>
> > :- pred map_io(pred(T, io, io)::in(pred(in, di, uo) is det),
> >                list(T)::in,
> >                io::di, io::uo)
> >    is det.
>
> This is list.foldl.
>
> > This is the IO-version of foldl:
> >
> > :- pred fold_io(pred(T, A, A, io, io)::in(pred(in, in, out, di, uo) is
> det),
> >                 list(T)::in,
> >                 A::in,
> >                 A::out,
> >                 io::di, io::uo)
> >    is det.
>
> This is list.foldl2.
>
> > And the IO version of list.filter/4:
> >
> > :- pred filter_io(
> >     pred(T, bool, io, io)::in(pred(in, out, di, uo) is det),
> >     list(T)::in,
> >     list(T)::out,
> >     list(T)::out,
> >     io::di, io::uo)
> >    is det.
>
> This is not in the Mercury standard library, and I don't think
> I have ever needed a predicate like this. (If I had, I *would* have
> added it to the library.)
>
> > If you'd like to include these predicates, I'd provide proper comments
> and,
> > of course, the implementation.
>
> Thanks, but that is not necessary; for predicate signatures like this,
> the code practically writes itself.
>
> Zoltan.
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 21 Dec 2021 16:21:06 +0000
> From: "Sean Charles (emacstheviking)" <objitsu at gmail.com>
> To: users <users at lists.mercurylang.org>
> Subject: [m-users.] Possiblt stupid list question....
> Message-ID: <F298BCE6-AEE9-4C24-85B3-A7221E532F7B at gmail.com>
> Content-Type: text/plain;       charset=utf-8
>
> If I have a list of strings I can use
>
>         string.join_list(Separator, Strings)
>
> but if I have a list of things, and I want to separate them all with a
> list of another thing within the same type…?
>
> I have a formatted output system, it encapsulates text in various type
> constructors
>
>         t(string)
>         tnl(string)
>         etc
>
> so given a list
>
>         [ t(“arg1”), t(“arg2”) ]
>
> how do I arrive at
>
>         [ t(“arg1”), t(“, “), t(“arg2”) ]
>
> I COULD introduce a new type constructor called csv() but …. just asking
> for a friend etc.
>
>
> Thanks
> Sean
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 21 Dec 2021 17:21:22 +0100
> From: Volker Wysk <post at volker-wysk.de>
> To: zoltan.somogyi at runbox.com
> Cc: Mercury Users <users at lists.mercurylang.org>
> Subject: Re: [m-users.] Useful predicates for loops of IO actions
> Message-ID:
>         <11e856719255a98c9723c3d9c5bc537ecf0bf503.camel at volker-wysk.de>
> Content-Type: text/plain; charset="utf-8"
>
> Am Mittwoch, dem 22.12.2021 um 02:51 +1100 schrieb Zoltan Somogyi:
> >
> > On Tue, 21 Dec 2021 16:18:48 +0100, Volker Wysk <post at volker-wysk.de>
> wrote:
> > > I'm using four meta-predicates which deal with loops and IO, and I
> find them
> > > useful. Maybe you want to include them in the Mercury libraries?
> >
> > Three out of the four are already there, in more general forms. Instead
> of
> > the last pair of arguments required to be I/O states, they can be any
> type,
> > and their modes do not have to be di/uo; they can be e.g. in/out.
>
> Now I'm feeling bashful... :) In the future, I'll make it a habit to read
> the documentation more thoroughly. It's, in part, because I didn't fully
> understand what was meant by "accumulator". (I have a different
> understanding of it).
>
> Bye, Volker
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: This is a digitally signed message part
> URL: <
> http://lists.mercurylang.org/archives/users/attachments/20211221/f903cf12/attachment.sig
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users
>
>
> ------------------------------
>
> End of users Digest, Vol 88, Issue 6
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20211221/da4bf595/attachment-0001.html>