From mboxrd@z Thu Jan 1 00:00:00 1970 References: <87v9xbih63.fsf@kyleam.com> <87d0jj9m4s.fsf@elephly.net> <87sgsej565.fsf@kyleam.com> From: Ricardo Wurmus Subject: Re: Some doc/examples files incompatible with latest update In-reply-to: <87sgsej565.fsf@kyleam.com> Date: Fri, 14 Jun 2019 15:52:41 +0200 Message-ID: <87k1doqno6.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Kyle Meyer Cc: gwl-devel@gnu.org List-ID: Hi Kyle, > Ricardo Wurmus writes: > >>> | ERROR: In procedure scm-error: >>> | No applicable method for #< workflow-processes* (1)> in call >>> | (workflow-processes* #) >> >> =E2=80=9Cload-workflow=E2=80=9D now prints an understandable error messa= ge when the file >> it loads does not evaluate to a workflow. > > Thanks. > > Should simple-wisp.w also be updated to evaluate to a workflow > (something along the lines of the patch I included with my first email)? I=E2=80=99ve got some WIP for that, but I=E2=80=99m still working on fixing= / improving the behaviour of =E2=80=9Ccontainerize=E2=80=9D. > Right, that was one thing. Another thing I hit into is the assumption > that the workflow is executed from a particular location, which is > presumably an interaction between loading extended-example-workflow.scm > and its `(include "example-workflow.scm")'. I had already fixed this locally but didn=E2=80=99t push my changes. The n= ew approach is to use =E2=80=9Cload-workflow=E2=80=9D. It looks for workflows= relative to the location where it is invoked (unless it=E2=80=99s a sub-directory of th= e GWL and pre-inst-env is used, so copy the examples). In the next couple of days I=E2=80=99ll update this. --=20 Ricardo