<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Yes. Mostly I wrote this as a learning example. You suggested I write more examples and that was the result, it will end up in the FFI section soon.<div class=""><br class=""></div><div class="">I have used inotify, watchman, some awful 'grunt' solution et al. from years ago, but all of them just seemed overkill and had issues one way or another and I thought that just writing something that was minimal viable product, with Mercury as more education, would be fun. Plus this works on any platform I care to run Mercury on and forms a part of my custom toolkit I use.</div><div class=""><br class=""></div><div class=""> * rr - the file watcher dostuff thing</div><div class=""> * mlpt - my literate programming tool</div><div class=""> * pberr - put back errors (but a nod to Paul Bone too) as I found it it had been done decades ago! LOLZ etc</div><div class=""><br class=""></div><div class="">When coding in mercury now I use nano, with my 'pberr' that includes the .err file into the source file, I have a custom nano mode for Mercury, based on the Prolog one, it's not ideal but it works pretty good. All in all I am a happy bunny with Mercury these days. So glad I stuck with it and I have barely scratched the surface with it.</div><div class=""><br class=""></div><div class="">I don't know if this screenshot will make it through the plumbing but it's a screen shot of a Mercury literate programming session from yesterday. I used it for a few hours yesterday and it works for me just fine running code rendering and pandoc->pdf->xpdf in another window. Emacs in the right pane has auto-revert on so it refreshes when the code is re-rendered so I can see what's coming out.</div><div class=""><br class=""></div><div class="">Just lately mercury makes me feel like I am 12 years old again, learning BASIC in school; the frontiers are open, everything and anything is possible!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="E6B4C366-FE77-4712-9FBB-8657473893EB" src="cid:22DC9390-FA62-485D-B893-A49966862327" class=""></div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 15 Aug 2022, at 11:25, Richard O'Keefe <<a href="mailto:raoknz@gmail.com" class="">raoknz@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:monospace,monospace">I liked the idea so much that I wrote my own 'rr'</div><div class="gmail_default" style="font-family:monospace,monospace">in another language.  There are problems, which I</div><div class="gmail_default" style="font-family:monospace,monospace">noticed in my own program first.  One I don't see</div><div class="gmail_default" style="font-family:monospace,monospace">a way around is the distinction between 'this</div><div class="gmail_default" style="font-family:monospace,monospace">file has changed in some way' and 'the series of</div><div class="gmail_default" style="font-family:monospace,monospace">changes to this file has now reached a new stable</div><div class="gmail_default" style="font-family:monospace,monospace">state where it is safe to look at.'</div><div class="gmail_default" style="font-family:monospace,monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace,monospace">Of course the inotifywait(1) command, which relies</div><div class="gmail_default" style="font-family:monospace,monospace">on the Linux inotify(7) interface, has precisely</div><div class="gmail_default" style="font-family:monospace,monospace">the same issue.  It can tell when a file that was</div><div class="gmail_default" style="font-family:monospace,monospace">opened for writing has just been closed, so is</div><div class="gmail_default" style="font-family:monospace,monospace">presumably in a stable state, but it can't tell</div><div class="gmail_default" style="font-family:monospace,monospace">whether a file is in a stable state if it HASN'T</div><div class="gmail_default" style="font-family:monospace,monospace">been closed, and just because file X is now ready</div><div class="gmail_default" style="font-family:monospace,monospace">to look at doesn't mean that a connected series</div><div class="gmail_default" style="font-family:monospace,monospace">of updates to X Y and Z have now reached a stable</div><div class="gmail_default" style="font-family:monospace,monospace">point.</div><div class="gmail_default" style="font-family:monospace,monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace,monospace">make(1) leaves the problem in the user's hands.</div><div class="gmail_default" style="font-family:monospace,monospace"><br class=""></div><div class="gmail_default" style="font-family:monospace,monospace">What we really need is a notion of "transaction"</div><div class="gmail_default" style="font-family:monospace,monospace">built into the file system.  (Oh, and a 50 cent</div><div class="gmail_default" style="font-family:monospace,monospace">supercomputer would be nice too. (:-))<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 15 Aug 2022 at 18:21, Volker Wysk <<a href="mailto:post@volker-wysk.de" class="">post@volker-wysk.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for sharing!<br class="">
<br class="">
Volker<br class="">
<br class="">
Am Sonntag, dem 14.08.2022 um 20:05 +0100 schrieb Sean Charles<br class="">
(emacstheviking):<br class="">
> Hi,<br class="">
> <br class="">
> In case anybody might be looking for some simple code that shows how<br class="">
> to call "C" code and also have a utility that watches files for their<br class="">
> modification timestamp(s) to change, then run a command and rinse-<br class="">
> repeat forever.<br class="">
> <br class="">
> It builds on a sample program I released last week, if you find it<br class="">
> useful my name was Sean, if not, my name was Donald.<br class="">
> <br class="">
> <a href="https://github.com/emacstheviking/mercury-rinse-repeat" rel="noreferrer" target="_blank" class="">https://github.com/emacstheviking/mercury-rinse-repeat</a><br class="">
> <br class="">
> I wrote it to drive my Literate Programming tangle/weave tool which I<br class="">
> am almost ready to publish as well, it just needs some very minor<br class="">
> tweaks before it passes muster. It's fashioned after `noweb`, in fact<br class="">
> the syntax for blocks is the same, I took inspiration from it as I<br class="">
> have used it in the past to produce working sellable Drupal modules<br class="">
> back in the bad old days.<br class="">
> <br class="">
> The program is VERY simple and VERY naive but that's all I needed and<br class="">
> it works for me.<br class="">
> <br class="">
> Thanks for all the comments along the way,<br class="">
> <br class="">
> Sean.<br class="">
> <br class="">
> _______________________________________________<br class="">
> users mailing list<br class="">
> <a href="mailto:users@lists.mercurylang.org" target="_blank" class="">users@lists.mercurylang.org</a><br class="">
> <a href="https://lists.mercurylang.org/listinfo/users" rel="noreferrer" target="_blank" class="">https://lists.mercurylang.org/listinfo/users</a><br class="">
<br class="">
_______________________________________________<br class="">
users mailing list<br class="">
<a href="mailto:users@lists.mercurylang.org" target="_blank" class="">users@lists.mercurylang.org</a><br class="">
<a href="https://lists.mercurylang.org/listinfo/users" rel="noreferrer" target="_blank" class="">https://lists.mercurylang.org/listinfo/users</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>