[L2Ork-dev] Potential Gem bug?
ico at vt.edu
Tue Apr 23 07:48:34 EDT 2019
Thank you, IOhannes. As a point of clarification, this affects pd-l2ork
(1.x) but not Purr-Data (2.x). Also, Gem is compiled from source and no
other pd version is installed, so I am unsure why there should be any
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
ico at vt.edu
On Tue, Apr 23, 2019, 05:35 IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> On 14.04.19 17:48, Ivica Ico Bukvic wrote:
> > IOhannes et al.,
> i'm just back from easter hols. sorry for the delay.
> > I just checked out the latest Gem (0.94 branch) by doing:
> > git clone https://git.code.sf.net/p/pd-gem/gem pd-gem-gem
> > When starting pd-l2ork, it segfaults with the following backtrace. Any
> > what may be wrong? Is this a stable branch?
> yes, it's a stable release.
> however, Gem does some magic to add it's own path to the search-paths of
> Pd (if it is not already added), and while doing so it might hit a
> binary incompatibility between purr-data and Pd.
> Gem will use the safer "add-to-path" message to "pd", if it detects a
> compatible version of Pd (comparing the output of sys_getversion()
> against (0,47)). this seems to fail with purr-data, so it falls back to
> calling "namelist_append" to append the path to the "sys_searchpath"
> probably jonathan can shed some light why this crashes.
> > [submodule "Gem"]
> > path = Gem
> > url = git://git.code.sf.net/p/pd-gem/gem
> i'd suggest using https://git.iem.at/pd/Gem as upstream (or
> i still mirror to sourceforge for legacy reasons, but who knows...
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the L2Ork-dev