[L2Ork-dev] Purr Data 2.15.1 => 2.15.2- Zexy library

Albert Graef aggraef at gmail.com
Wed Oct 14 09:53:59 EDT 2020


Hi Joseph,

thanks for testing, your feedback is very much appreciated, as usual. :)

On Wed, Oct 14, 2020 at 1:20 PM Linux ROUEN Normandie <linux.rouen at free.fr>
wrote:

> * A side comment regarding, e.g., [image toto.png].
> Since at least 2.14.0, when you click on an embedded image into my
> patches/subpatches there is anymore a surrounding box telling you this
> object is selected.
>

Yep, I can confirm that issue, but AFAICT it goes back to 2.13.0 at least.
Sorry, I'm afraid that I don't have the faintest idea whether that's
actually a regression or the intended behavior. ;-) Jonathan, do you know
more about this change?

* I will also test Purr Data 2.15.2 under Windows when it will be available.
>

Yeah, sorry for the delay. I accidentally built my testing branch first,
and didn't notice until it was well underway. Right now my Windows 10 VM is
still chugging along building the 64 bit package for the 2.15.2 branch.
Alas, building Purr on Windows is painfully slow, especially in VirtualBox,
but it'll hopefully be ready in the next 1-2 hours. I'll let you know.

Thanks,
Albert


> Best, Joseph
> - - - - - - - - - -
>
> Le 14/10/2020 à 10:23, Albert Graef a écrit :
>
> Ok, I got that new segfault in zexy sorted out as well.
>
> Joseph, 2.15.2 is currently building on the OBS, so expect an update in
> 1-2 hours. Thanks again for reporting, and it would be nice if you could
> give zexy another whirl and check whether the issues you reported have
> indeed been fixed in 2.15.2. They should be. ;-) I did my best to also
> backport the fixes that we previously had in the 2.2.6 zexy tree.
>
> 2.15.2 packages for Mac and Windows should be available at
> https://github.com/agraef/purr-data/releases in the course of the next 2
> hours as well.
>
> Thanks,
> Albert
>
>
> On Tue, Oct 13, 2020 at 6:37 PM Albert Graef <aggraef at gmail.com> wrote:
>
>> Just a quick heads up, as Gitlab seems to be down again: There are still
>> some residual issues with the reworked zexy 2.3.1 implementation in Purr,
>> I'm currently working on those:
>>
>> - zexy/sort not loadable due to a typo in the source. I wonder how that
>> slipped through IEM quality control? ;-) Anyway, that's a really trivial
>> issue, I already fixed that, but still need to upload a new package.
>>
>> - On *Windows only*, `make check` (and the CI) gives a segfault somewhere
>> in zexy (I'm not sure at present which object causes this, or whether it's
>> related to the zexy/sort issue). Linux and Mac are unaffected, `make check`
>> works fine there.
>>
>> If Gitlab remains down for an extended period, I'll just release the
>> fixed up zexy as 2.15.2 on the GitHub mirror as soon as I've sorted out the
>> Windows `make check` issue.
>>
>> Albert
>>
>>
>> On Tue, Oct 13, 2020 at 11:08 AM Albert Graef <aggraef at gmail.com> wrote:
>>
>>> Yep, that did it. Jonathan, can you please have a look (i.e., review,
>>> test, and merge)
>>> https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/592?
>>>
>>> That MR also backports the various bugfixes and the hexmunger-related
>>> changes from the old version. I *think* that I did this right, but it can't
>>> hurt to have a second pair of eyeballs have a look.
>>>
>>> Joseph, thanks again for reporting the issue, here's proof that
>>> everything is back to normal again:
>>> [image: image.png]I'll toss up a build of 2.15.2 to the preview channel
>>> shortly, so that you can test for yourself. Note that this will also
>>> include Ico's latest (and somewhat experimental) changes, which are slated
>>> to go into 2.15.2 as well, but I already tested these myself for a bit and
>>> they seem to work ok so far.
>>>
>>> Thanks,
>>> Albert
>>>
>>> On Tue, Oct 13, 2020 at 2:31 AM Albert Graef <aggraef at gmail.com> wrote:
>>>
>>>> On Mon, Oct 12, 2020 at 10:53 PM Jonathan Wilkes <
>>>> jon.w.wilkes at gmail.com> wrote:
>>>>
>>>>> # make-lib-executable:
>>>>>
>>>>
>>>> Oops, I overlooked that one.Thanks, I will give it a go immediately.
>>>>
>>>> # When this variable is defined 'yes' in your makefile or as command
>>>>> argument,
>>>>> # Makefile.pdlibbuilder will try to build all classes into a single
>>>>> library
>>>>> # executable (but it will force exit if lib.setup.sources is
>>>>> undefined).
>>>>> # If your makefile defines 'make-lib-executable=yes' as the library
>>>>> default,
>>>>> # this can still be overriden with 'make-lib-executable=no' as command
>>>>> argument
>>>>> # to build individual class executables (the Makefile.pdlibbuilder
>>>>> default.)
>>>>>
>>>>> On Mon, Oct 12, 2020 at 4:25 PM Albert Graef <aggraef at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > On Mon, Oct 12, 2020 at 10:14 PM Jonathan Wilkes <
>>>>> jon.w.wilkes at gmail.com> wrote:
>>>>> >>
>>>>> >> Our previous version of Zexy had the option to produce both types of
>>>>> >> output, but it didn't use Makefile.pdlibbuilder. You might skim that
>>>>> >> file to see if there's an option to build one-file-per-class.
>>>>> >
>>>>> >
>>>>> > I already did that, but couldn't find any such option.
>>>>> >
>>>>> > Albert
>>>>> >
>>>>> >>
>>>>> >> -Jonathan
>>>>> >>
>>>>> >> On Mon, Oct 12, 2020 at 4:03 PM Albert Graef <aggraef at gmail.com>
>>>>> wrote:
>>>>> >> >
>>>>> >> > On Mon, Oct 12, 2020 at 8:41 PM Jonathan Wilkes <
>>>>> jon.w.wilkes at gmail.com> wrote:
>>>>> >> > > Whoa, that is a huge regression and needs to be fixed.
>>>>> >> >
>>>>> >> > The only (quick) fix I see is to unmerge
>>>>> >> > https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/583.
>>>>> >> >
>>>>> >> > That might work for most people, but zexy will then be completely
>>>>> >> > broken in the mingw64 build again. Which means that I won't be
>>>>> able to
>>>>> >> > use zexy, because I need to be able to run pd-faustgen2 (which
>>>>> >> > requires 64 bit) on Windows in at least one of my upcoming
>>>>> courses.
>>>>> >> >
>>>>> >> > > namespace prefixes like zexy/date should be supported in all
>>>>> the default libs, no exceptions.
>>>>> >> >
>>>>> >> > Is there a way you can do that if a collection of externals is
>>>>> >> > compiled as a library? Do we have a working example of this in the
>>>>> >> > libraries that we ship? Then we could possibly apply the same
>>>>> method
>>>>> >> > to zexy.
>>>>> >> >
>>>>> >> > > Is there a compile-time option for Zexy to produce
>>>>> one-class-per-file output, or was that removed in a newer version?
>>>>> >> >
>>>>> >> > Not as far as I can tell -- as you know if you read the
>>>>> description of
>>>>> >> > my MR, it uses Makefile.pdlibbuilder now. It's hopefully possible
>>>>> to
>>>>> >> > massage zexy/Makefile so that it produces separate externals. I
>>>>> can
>>>>> >> > look into that as soon as I find the time if you want.
>>>>> >> >
>>>>> >> > > Also-- Albert, did you go through the `git log externals/zexy`
>>>>> to see if we had any fixes for things that aren't upstream? The only thing
>>>>> I vaguely recall had to do with hexloader, but that my have been a
>>>>> different external lib...
>>>>> >> >
>>>>> >> > No, I didn't. Most of those seem to be about hexmunger, which the
>>>>> >> > library version doesn't need if I understand correctly. The others
>>>>> >> > are:
>>>>> >> >
>>>>> >> > https://git.purrdata.net/jwilkes/purr-data/-/commit/5e9124e9: Not
>>>>> >> > sure, code review is in order.
>>>>> >> >
>>>>> >> > https://git.purrdata.net/jwilkes/purr-data/-/commit/3cf58d708:
>>>>> Not
>>>>> >> > sure, code review is in order.
>>>>> >> >
>>>>> >> > https://git.purrdata.net/jwilkes/purr-data/-/commit/7b3a9f539:
>>>>> >> > Probably still needed, but it won't apply without ado to the new
>>>>> >> > version because of code changes.
>>>>> >> >
>>>>> >> > https://git.purrdata.net/jwilkes/purr-data/-/commit/e294b129:
>>>>> Probably
>>>>> >> > still needed as well, we may just apply it anyway because it
>>>>> won't do
>>>>> >> > any harm AFAICT.
>>>>> >> >
>>>>> >> > Albert
>>>>> >> >
>>>>> >> > >
>>>>> >> > > -Jonathan
>>>>> >> > >
>>>>> >> > >>
>>>>> >> > >>
>>>>> >> > >> HTH,
>>>>> >> > >> Albert
>>>>> >> > >>
>>>>> >> > >>
>>>>> >> > >> On Mon, Oct 12, 2020 at 7:03 PM Linux ROUEN Normandie <
>>>>> linux.rouen at free.fr> wrote:
>>>>> >> > >>>
>>>>> >> > >>> Hello Albert,
>>>>> >> > >>>
>>>>> >> > >>> I have just updated Purr Data 2.15.0 towards 2.15.1 with
>>>>> success (OBS branch). :-)
>>>>> >> > >>>
>>>>> >> > >>> In my projects the console now prints out for example:
>>>>> >> > >>> error: couldn't create "zexy/date -----------"
>>>>> >> > >>> ... click the link above to track it down, or click the 'Find
>>>>> Last Error' item in the Edit menu.
>>>>> >> > >>> error: couldn't create "zexy/makesymbol %s-%s-%s"
>>>>> >> > >>> error: couldn't create "zexy/makesymbol %s"
>>>>> >> > >>> error: couldn't create "zexy/makesymbol 0%s"
>>>>> >> > >>> error: couldn't create "zexy/makesymbol %s"
>>>>> >> > >>> error: couldn't create "zexy/makesymbol 0%s"
>>>>> >> > >>> error: couldn't create "zexy/time -----------"
>>>>> >> > >>> error: couldn't create "zexy/makesymbol %s:%s:%s"
>>>>> >> > >>>
>>>>> >> > >>> So now the new Zexy library 2.3.0 as of 2020/02/20 is not
>>>>> totally functional: /opt/purr-data/lib/pd-l2ork/extra/zexy with only 145
>>>>> elements!
>>>>> >> > >>> In Purr Data 2.15.0, the Zexy library was v.2.2.6 as of
>>>>> 2016/01/22 with 241 elements.
>>>>> >> > >>>
>>>>> >> > >>> After checking the content of this folder (which is not
>>>>> empty), it seems to be missing at least:
>>>>> >> > >>> - "date.pd_linux" [ISOdata] when "date-help.pd" is present,
>>>>> >> > >>> - "time.pd_linux" [ISOtime] when "time-help.pd" is present,
>>>>> and
>>>>> >> > >>> - "makesymbol.pd_linux" when "makesymbol-help.pd" is present.
>>>>> >> > >>>
>>>>> >> > >>>
>>>>> >> > >>>
>>>>> >> > >>> * Any idea if this is due to this new Zexy library 2.3.0
>>>>> and/or something else ?
>>>>> >> > >>>
>>>>> >> > >>> Thanks.
>>>>> >> > >>> Best, Joseph
>>>>> >> > >>> _______________________________________________
>>>>> >> > >>> L2Ork-dev mailing list
>>>>> >> > >>> L2Ork-dev at disis.music.vt.edu
>>>>> >> > >>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >> > >>
>>>>> >> > >>
>>>>> >> > >>
>>>>> >> > >> --
>>>>> >> > >> Dr. Albert Gr"af
>>>>> >> > >> Computer Music Research Group, JGU Mainz, Germany
>>>>> >> > >> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>> >> > >> _______________________________________________
>>>>> >> > >> L2Ork-dev mailing list
>>>>> >> > >> L2Ork-dev at disis.music.vt.edu
>>>>> >> > >> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >> > >
>>>>> >> > > _______________________________________________
>>>>> >> > > L2Ork-dev mailing list
>>>>> >> > > L2Ork-dev at disis.music.vt.edu
>>>>> >> > > https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > Dr. Albert Gr"af
>>>>> >> > Computer Music Research Group, JGU Mainz, Germany
>>>>> >> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>> >> > _______________________________________________
>>>>> >> > L2Ork-dev mailing list
>>>>> >> > L2Ork-dev at disis.music.vt.edu
>>>>> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >> _______________________________________________
>>>>> >> L2Ork-dev mailing list
>>>>> >> L2Ork-dev at disis.music.vt.edu
>>>>> >> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Dr. Albert Gr"af
>>>>> > Computer Music Research Group, JGU Mainz, Germany
>>>>> > Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>> > _______________________________________________
>>>>> > L2Ork-dev mailing list
>>>>> > L2Ork-dev at disis.music.vt.edu
>>>>> > https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>> _______________________________________________
>>>>> L2Ork-dev mailing list
>>>>> L2Ork-dev at disis.music.vt.edu
>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Dr. Albert Gr"af
>>>> Computer Music Research Group, JGU Mainz, Germany
>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>
>>>
>>>
>>> --
>>> Dr. Albert Gr"af
>>> Computer Music Research Group, JGU Mainz, Germany
>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>
>>
>>
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com, web: https://agraef.github.io/
>
> _______________________________________________
> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201014/01f3a65d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 40456 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201014/01f3a65d/attachment-0001.png>


More information about the L2Ork-dev mailing list