[L2Ork-dev] Purr Data 2.15.1 - Zexy library

Mon Oct 12 19:17:27 EDT 2020

Hello Albert and Jonathan,
Your technical discussion is above my understanding! :-(

Just to strengthen Jonathan earlier comment:
"namespace prefixes like zexy/date should be supported in all the 
default libs, no exceptions.".

Albert,
My issue is that I'm not using directly neither [zexy/date] nor 
[zexy/time] nor [zexy/makesymbol] but ready-to-use abstractions 
(available in Purr Data / externals) which are called by [ISOdate] and 
[ISOtime]. So that means these standard abstractions should be modified 
by myself, saved under different names and then integrated into my 
projects instead the current ones.

Best, Joseph
- - - - - - - - - - - - - - - - - - - -

Le 12/10/2020 à 22:52, Jonathan Wilkes a écrit :
> # make-lib-executable:
> # 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