On Fri, 2010-06-18 at 13:01 -0400, Hans-Christoph Steiner wrote: > On Jun 18, 2010, at 8:49 AM, Roman Haefeli wrote: > > > On Thu, 2010-06-17 at 16:56 -0400, Mathieu Bouchard wrote: > >> On Wed, 16 Jun 2010, Hans-Christoph Steiner wrote: > >>> On Jun 15, 2010, at 10:09 PM, Mathieu Bouchard wrote: > >>>> On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote: > >>>>> You need to do [import hexloader] first, then those objects will > >>>>> create. > >>>> Why isn't hexloader enabled by default ? > >>> It was causing a lot of problems. Check the archives for details. > >> > >> Actually, I can't get hexloader to work. It seems to have no effect. > >> > >> I can't instantiate [mtx_+] without first instantiating [mtx_add], > >> which > >> is the same class. > >> > >> There are pd-extended users who recompile zexy and iemmatrix as big > >> libraries because the system of one-class-per-file of pd-extended > >> doesn't > >> work with those names and the filesystems. It's causing a lot of > >> problems. > > > > Yeah, there have been some troubles. In the case of iemmatrix: most of > > the aliases were missing completely, so even with hexloader loaded, > > Pd-extended wouldn't find the correct files. I created a patch that > > adds > > all missing aliases for iemmatrix and IOhannes committed it two days > > ago > > [1]. I guess you would need to try a current autobuild to be able to > > create [mtx_+] directly. The rc3 version was released before the patch > > was applied. > > > > Regarding zexy, I am not aware of any troubles in Pd-extended. Please > > post bugs, if you find any. I guess we're not far away from the > > libdirs > > behaving similar to the original multi-object library format. I > > personally care most about zexy and iemmatrix, I haven't checked if > > other libraries also require aliases. > > > > [1] > > https://sourceforge.net/tracker/?func=detail&aid=3017152&group_id=55736&atid=478072 > > > > > > @ Hans > > You said you removed hexloader from automatically being loaded, > > because > > there have been some troubles in the past. The reason could be found > > in > > the list archives. I haven't thoroughly checked everything about > > hexloader, but it seemed to me that most problems have been solved. If > > not, can you elaborate a bit the issue? > > Personally, I think it would help _a lot_ to make Pd patches portable > > between flavours, if hexloader would be loaded automaticall on start- > > up > > of Pd-extended. Please let me know, if you think it is not worth > > raising > > this discussion again. > > > > Roman > > I don't remember the reasons, I'd have to dig in the archives to > remember :) hexloader has been IOhannes' project. I think in order > for it to work, it should be simplified more. I think it should use a > setup function called setup(), for example. Then it wouldn't need to > do any 0x hex rewriting for the setup function.
I don't see how _not_ loading hexloader automatically on start-up can help here. A supposedly too complex hexloader mechanism is still better that none at all, even more since it is already implemented, no? I personally would welcome if it _would_ be loaded automatically for reasons I mentioned above. I am probably the wrong person to comment on the technical aspects, but it seems to me that your proposal of having only a setup() function instead of the current classname_setup() function would render it impossible to have a c file provide more than one class. Or am I misunderstanding something here? Roman _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
