Re: [PD] hex loader
Hans-Christoph Steiner wrote: > By the way, I just read thru the whole hexloader README. Looks like > nice work, I think you covered every possibility that I could think > of :) > ah, finally someone who acknowledges my hard labour :-) fgmadsf rIOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
By the way, I just read thru the whole hexloader README. Looks like nice work, I think you covered every possibility that I could think of :) .hc On Nov 28, 2007, at 10:05 PM, Mathieu Bouchard wrote: > On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote: > >> i don't like matju's suggestion to provide an API, > > Ideally, hexloader should be merged into the core and the API would > be a single function shared by the loader and the parts of the > internals that do the same thing as the hexloader does (the symbol > mangler). > > I'm not really advocating that an external exposes an API otherwise > than as pd objects and methods... but then, this is also what Gem > need to do if some externals are not linked directly into Gem... so > it must not be that ugly. GridFlow will also have to do it > eventually. I just think that doing it for one function is a waste. > > Anyway, because virtually the same code is already in the core, it > makes sense to have that shared function in the core, so the issue > of linking to an external should be moot. > >> as this would require to have hexloader be loaded before all other >> externals that rely on that API. > > Not if the linker knows about it. (The problem is how to tell the > linker about it) > >> what might be a better solution is to tell Pd to try to load a >> different class instead (kind of recursively calling the loading >> stuff). > > I don't understand. > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada "It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote: right, i found out that hexloader does a bad job when trying to load patches. this part of the hexloader is obviously still experimental. what it does is to register a dummy class for an abstraction which it thinks it should handle. Why do you need dummy classes? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Wed, 28 Nov 2007, Hans-Christoph Steiner wrote: This is the patch in question, it exposes the loader_t and sys_register_loader() in s_stuff.h. That seems like something worthwhile to support, no? If you look at the bulk of s_stuff.h, you'll see that those are functions that you never use when making externals. They are part of a file that is never included by externals (ok, there are some special cases). The only public API is still m_pd.h, even though g_canvas.h has crept to a de-facto semi-public, but still, m_pd.h is the only header added by make install. So, I don't know what's your goal with putting it in s_stuff.h... do you want to hide it? ;) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote: i don't like matju's suggestion to provide an API, Ideally, hexloader should be merged into the core and the API would be a single function shared by the loader and the parts of the internals that do the same thing as the hexloader does (the symbol mangler). I'm not really advocating that an external exposes an API otherwise than as pd objects and methods... but then, this is also what Gem need to do if some externals are not linked directly into Gem... so it must not be that ugly. GridFlow will also have to do it eventually. I just think that doing it for one function is a waste. Anyway, because virtually the same code is already in the core, it makes sense to have that shared function in the core, so the issue of linking to an external should be moot. as this would require to have hexloader be loaded before all other externals that rely on that API. Not if the linker knows about it. (The problem is how to tell the linker about it) what might be a better solution is to tell Pd to try to load a different class instead (kind of recursively calling the loading stuff). I don't understand. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
patrick wrote: > hi, > etc... > but if i create a new patch and type [relay] it will works... > any ideas? right, i found out that hexloader does a bad job when trying to load patches. this part of the hexloader is obviously still experimental. what it does is to register a dummy class for an abstraction which it thinks it should handle. (unfortunately currently it also thinks it should handle "normal" abstractions, that do not need hexmangling) when the objectclass gets instantiated it is really the hexloader-external that gets called (hence the "disguising as..." message), and tries to load the abstraction. for whatever reasons this does not work with abstractions containing abstractions. i will have a look at this. fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
Hans-Christoph Steiner wrote: >> >> yes indeed it would be nice. >> how do you think it should work (if done in core-pd)? >> why do you think it is impossible to do this with an external loader? >> > > As a loader that worked for other loaders would be even better. i agree that this would be nice. how do you think it should work (if done in core-pd)? why (and) do you think it is impossible to do this with an external loader? probably i am just too tired to think of a good idea. i don't like matju's suggestion to provide an API, as this would require to have hexloader be loaded before all other externals that rely on that API. what might be a better solution is to tell Pd to try to load a different class instead (kind of recursively calling the loading stuff). mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Nov 27, 2007, at 4:11 PM, IOhannes m zmoelnig wrote: > hi > > patrick wrote: >> IOhannes, >> >>> _part_ of it is included in pd-vanilla (a bug has been fixed >>> recently >>> with pd-0.41-test6 (or 7)) >> >> maybe that's why it's not working even if i removed -Werror: > [...] >> >> the include ../../../pd/src/s_stuff.h is from pd.0.41.08. >> patrick >> > > > are you sure? > i cannot find a loader_t in s_stuff.h of pd-0.41-0test8. > have you patched the pd-sources? This is the patch in question, it exposes the loader_t and sys_register_loader() in s_stuff.h. That seems like something worthwhile to support, no? [EMAIL PROTECTED] > cd ~/code/pure-data/packages/patches/ [EMAIL PROTECTED] > grep loader_t * expose_sys_register_loader-0.41.0-test03.patch:-typedef int (*loader_t)(t_canvas *canvas, char *classname); expose_sys_register_loader-0.41.0-test03.patch: loader_t loader; expose_sys_register_loader-0.41.0-test03.patch:+typedef int (*loader_t)(t_canvas *canvas, char *classname); expose_sys_register_loader-0.41.0-test03.patch:+EXTERN void sys_register_loader(loader_t loader); It seems either I forgot to submit that patch to the tracker, or it got deleted somehow. Strange, I don't know why I wouldn't have submitted it, I wonder if SourceForge is having some issues, or I am losing my mind. I (re?)added it. .hc All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
Hans-Christoph Steiner wrote: > You might consider, Pd-extended is pd-vanilla plus the patches that > have been submitted to the patch tracker. Miller ends up taking most > of these patches. I believe he would be more likely to accept > patches that have been used successfully in Pd-extended. yes this is fine: as soon as the loader_t line shows up in Pd-vanilla's s_stuff.h i will remove it permanently from the hexloader.c my main intention is still compatibility with pd-vanilla. you (not necessarily hcs; anybody who wants to do it) could also just add the hexloader to Pd-extended's build-system and while doing so apply a wee patch in Pd-extended's makefile that removes the line. something like : "sed -i -e 's|^typedef int (\*loader_t)(t_canvas \*canvas, char \*classname);$|' hexloader.c" (that's al in one line) mfa.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Nov 28, 2007, at 4:08 AM, IOhannes m zmoelnig wrote: > patrick wrote: >> hi IOhannes, >> >> 1) >> http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout- >> developer-layout.sh?rev=HEAD >> >> 2) >> rm -rf pd >> unpack pd.0.41.08 to pd >> cd pure-data/packages/ >> >> vi Makefile (removed Gem because it doesn't compile on gutsy >> (avifile)) >> make patch > > so you are patching the pd-sources. > > i only have time to make hexloader compatible with one flavour of > pd and > i chose pd-vanilla. > > to make it work on pd-extended, please create a diff that removes the > offending line and submit it to the pd-extended's patches to be > automatically applied when you do "make patch". You might consider, Pd-extended is pd-vanilla plus the patches that have been submitted to the patch tracker. Miller ends up taking most of these patches. I believe he would be more likely to accept patches that have been used successfully in Pd-extended. .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Nov 28, 2007, at 3:49 AM, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: > >> I am curious why you chose to make it a loader rather than to make >> it part of the core? > > ??? > just to refresh everyones memories: > i have originally written the hexloader as a patch against pd-vanilla. > zthe functionality was: setupfun-mangling and filename-mangling. > this was in times before the sys_loader mechanism existed. > miller then applied my patch (i think for pd-0.39, but i am not > sure about pd-versions). > miller also applied tg's sys_loader patch. > in the next release of Pd, the hexloader was reduced to setupfun- > mangling only. > > i then thought (and still think) that miller has some reason to > reduce the hexloader-functionality in pd-core. > however, at the same time he provides an alternative to create your > own loader, so why not use that one instead? > > e.g. i could have bothered to get [>~] into core pd for 7 long years. > instead i chose the suggested way by writing an external that > provides [>~]. this has worked fine, why should i change it? why > should i have spent energy to get something i already have? Ah, ok, I didn't realize that Miller has scaled back the loader stuff. > (why do i have to spend energy in explaining this?) Maybe because you want people to use your code? :D >> For example, it would be nice to be able to write <~ in tcl with >> tclpd, if need be. > > > yes indeed it would be nice. > how do you think it should work (if done in core-pd)? > why do you think it is impossible to do this with an external loader? > As a loader that worked for other loaders would be even better. .hc All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Nov 28, 2007, at 4:04 AM, IOhannes m zmoelnig wrote: > patrick wrote: >> hi, >> >> i was able to compile hexloader by removing the "loader_t" >> declarations >> in hexloader.c: >> hex loader $Revision: 1.4 $ >> written by IOhannes m zmölnig, IEM <[EMAIL PROTECTED]> >> compiled on Nov 27 2007 at 23:36:07 >> compiled against Pd version 0.41.0.extended-20071126 >> >> [<~] works! > > good > >> >> but i have many errors while opening a patch: >> hexloader: disguising as 'convert.list2symbol' > > oops, that's the hexloader interfering with valid filenames. > it should do no harm though (but i thought that pd will try to > create an > object from a .pd-file before trying to run the loaders; i'll have > to check) > > >> dollarg >> ... couldn't create > > i have not tested how the hexloader works with other loaders (and i > guess nobody has tested it the other way round). > > one thing i can say for sure is: currently, other loaders will not > profit from the hexloader stuff: if [import]-like functionality is > implemented as loader (instead of "just" an [import] external), than > this will not work: "import" zexy + [>~]; [zexy/>~] should work > nevertheless. > i haven't tested anything i have just said, probably it is all wrong. [import] has nothing to do with the loader stuff, it is just a different interface to the [declare] code. .hc > > apart from that, i don't see how [dollarg] should be affected by this. > > >> mergefilename space >> ... couldn't create >> relay symbol >> ... couldn't create >> hexloader: disguising as 'scale.symbol' >> demultiplex 0 1 >> ... couldn't create >> convert.symbol2chars >> ... couldn't create >> hexloader: disguising as 'convert.list2symbol' >> dollarg >> ... couldn't create >> mergefilename space >> ... couldn't create >> relay symbol >> ... couldn't create >> hexloader: disguising as 'convert.list2symbol' >> dollarg >> ... couldn't create >> mergefilename space >> ... couldn't create >> relay symbol >> ... couldn't create >> hexloader: disguising as 'scale.symbol' >> >> etc... > > now that is all weird! > could you send me a simple patch to test (preferrably with only > zexy+iemlib+vanilla objects as i don't have any other libs installed) > > > > mfga.dsr > IOhannes > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Tue, 27 Nov 2007, Hans-Christoph Steiner wrote: Ah, ok, I was under the impression that you wanted to remove the hex loader stuff from pd-vanilla and replace it with a loader. I think that wouldn't be so good because then other loaders couldn't use the hex names. Yes, that was my comment on the sourceforge page. the problem is that unless the hexloader exposes an API that other language interface externals rely on, those externals have to duplicate most of the code of hexloader. Compared to the existing load of copy-paste and of almost-copy-paste in pd source and externals sources in general, it's not a big deal, but still I'm happier when there is no excuse for more copy-paste. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
patrick wrote: > hi IOhannes, > > 1) > http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout-developer-layout.sh?rev=HEAD > > 2) > rm -rf pd > unpack pd.0.41.08 to pd > cd pure-data/packages/ > > vi Makefile (removed Gem because it doesn't compile on gutsy (avifile)) > make patch so you are patching the pd-sources. i only have time to make hexloader compatible with one flavour of pd and i chose pd-vanilla. to make it work on pd-extended, please create a diff that removes the offending line and submit it to the pd-extended's patches to be automatically applied when you do "make patch". fgmadr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
patrick wrote: > hi, > > i was able to compile hexloader by removing the "loader_t" declarations > in hexloader.c: > hex loader $Revision: 1.4 $ > written by IOhannes m zmölnig, IEM <[EMAIL PROTECTED]> > compiled on Nov 27 2007 at 23:36:07 > compiled against Pd version 0.41.0.extended-20071126 > > [<~] works! good > > but i have many errors while opening a patch: > hexloader: disguising as 'convert.list2symbol' oops, that's the hexloader interfering with valid filenames. it should do no harm though (but i thought that pd will try to create an object from a .pd-file before trying to run the loaders; i'll have to check) > dollarg > ... couldn't create i have not tested how the hexloader works with other loaders (and i guess nobody has tested it the other way round). one thing i can say for sure is: currently, other loaders will not profit from the hexloader stuff: if [import]-like functionality is implemented as loader (instead of "just" an [import] external), than this will not work: "import" zexy + [>~]; [zexy/>~] should work nevertheless. i haven't tested anything i have just said, probably it is all wrong. apart from that, i don't see how [dollarg] should be affected by this. > mergefilename space > ... couldn't create > relay symbol > ... couldn't create > hexloader: disguising as 'scale.symbol' > demultiplex 0 1 > ... couldn't create > convert.symbol2chars > ... couldn't create > hexloader: disguising as 'convert.list2symbol' > dollarg > ... couldn't create > mergefilename space > ... couldn't create > relay symbol > ... couldn't create > hexloader: disguising as 'convert.list2symbol' > dollarg > ... couldn't create > mergefilename space > ... couldn't create > relay symbol > ... couldn't create > hexloader: disguising as 'scale.symbol' > > etc... now that is all weird! could you send me a simple patch to test (preferrably with only zexy+iemlib+vanilla objects as i don't have any other libs installed) mfga.dsr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
Hans-Christoph Steiner wrote: > I am curious why you chose to make it a loader rather than to make it > part of the core? ??? just to refresh everyones memories: i have originally written the hexloader as a patch against pd-vanilla. zthe functionality was: setupfun-mangling and filename-mangling. this was in times before the sys_loader mechanism existed. miller then applied my patch (i think for pd-0.39, but i am not sure about pd-versions). miller also applied tg's sys_loader patch. in the next release of Pd, the hexloader was reduced to setupfun-mangling only. i then thought (and still think) that miller has some reason to reduce the hexloader-functionality in pd-core. however, at the same time he provides an alternative to create your own loader, so why not use that one instead? e.g. i could have bothered to get [>~] into core pd for 7 long years. instead i chose the suggested way by writing an external that provides [>~]. this has worked fine, why should i change it? why should i have spent energy to get something i already have? (why do i have to spend energy in explaining this?) > For example, it would be nice to be able to write <~ > in tcl with tclpd, if need be. yes indeed it would be nice. how do you think it should work (if done in core-pd)? why do you think it is impossible to do this with an external loader? mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Nov 27, 2007, at 1:03 PM, IOhannes m zmoelnig wrote: > >>> also it would be nice to include this external in pd-extended. >>> >>> _part_ of it is included in pd-vanilla (a bug has been fixed >>> recently >>> with pd-0.41-test6 (or 7)) >>> >>> however, i have no problem if you add it to pd-extended (but i >>> have no >>> time to do it myself) >> Ah, ok, I was under the impression that you wanted to remove the >> hex loader stuff from pd-vanilla and replace it with a loader. I >> think that wouldn't be so good because then other loaders couldn't >> use the hex names. > > > other loaders can't use the hex-names anyhow. > > what is currently in pd-vanilla is the hexloader _without_ the > filename-mangling (only the setup-name is mangled) > >> What's the hex loader do? > > as opposed to the hexloader in pd-vanilla, the hexloader-loader > also mangles filenames. > I am curious why you chose to make it a loader rather than to make it part of the core? For example, it would be nice to be able to write <~ in tcl with tclpd, if need be. .hc http://at.or.at/hans/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
hi, i was able to compile hexloader by removing the "loader_t" declarations in hexloader.c: hex loader $Revision: 1.4 $ written by IOhannes m zmölnig, IEM <[EMAIL PROTECTED]> compiled on Nov 27 2007 at 23:36:07 compiled against Pd version 0.41.0.extended-20071126 [<~] works! but i have many errors while opening a patch: hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol' demultiplex 0 1 ... couldn't create convert.symbol2chars ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol' etc... but if i create a new patch and type [relay] it will works... any ideas? patrick ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
hi IOhannes, 1) http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout-developer-layout.sh?rev=HEAD 2) rm -rf pd unpack pd.0.41.08 to pd cd pure-data/packages/ vi Makefile (removed Gem because it doesn't compile on gutsy (avifile)) make patch cd linux_make make install 3) install pd in /usr/local (cp -R ...) 4) chmod +s /usr/local/bin/pd 5) edit /usr/local/lib/pd/default.pdsettings 6) compile the missing externals (flext, py, xsample...) patrick ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
hi patrick wrote: > IOhannes, > >> _part_ of it is included in pd-vanilla (a bug has been fixed recently >> with pd-0.41-test6 (or 7)) > > maybe that's why it's not working even if i removed -Werror: [...] > > the include ../../../pd/src/s_stuff.h is from pd.0.41.08. > patrick > are you sure? i cannot find a loader_t in s_stuff.h of pd-0.41-0test8. have you patched the pd-sources? mfga.dfr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
IOhannes, > _part_ of it is included in pd-vanilla (a bug has been fixed recently > with pd-0.41-test6 (or 7)) maybe that's why it's not working even if i removed -Werror: cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here the include ../../../pd/src/s_stuff.h is from pd.0.41.08. patrick ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
patrick wrote: > IOhannes, > >> _part_ of it is included in pd-vanilla (a bug has been fixed recently >> with pd-0.41-test6 (or 7)) > > maybe that's why it's not working even if i removed -Werror: > cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops > -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes > -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o > hexloader.pd_linux hexloader.c > hexloader.c:64: error: redefinition of typedef ‘loader_t’ > ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ > was here > > the include ../../../pd/src/s_stuff.h is from pd.0.41.08. > patrick > i see. i only ever use the pd from CVS, where these changes are obviously not there yet. sidenote to miller: will you check the latest and greatest Pd into the CVS? should i do it for you? in the meantime: check whether the "loader_t" declarations in s_stuff.h:55 and hexloader.c:64 are the same and if so remove (or comment out) the line in hexloader. and it should work. fgamsrd IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
>> >>> >>> also it would be nice to include this external in pd-extended. >> >> _part_ of it is included in pd-vanilla (a bug has been fixed recently >> with pd-0.41-test6 (or 7)) >> >> however, i have no problem if you add it to pd-extended (but i have no >> time to do it myself) > > Ah, ok, I was under the impression that you wanted to remove the hex > loader stuff from pd-vanilla and replace it with a loader. I think that > wouldn't be so good because then other loaders couldn't use the hex names. other loaders can't use the hex-names anyhow. what is currently in pd-vanilla is the hexloader _without_ the filename-mangling (only the setup-name is mangled) > > What's the hex loader do? > as opposed to the hexloader in pd-vanilla, the hexloader-loader also mangles filenames. fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
On Nov 27, 2007, at 3:30 AM, IOhannes m zmoelnig wrote: > hi > > patrick wrote: >> hi IOhannes, >> >> [<~] couldn't create. hans told me that i need your hex loader. so i >> tried to compile it: >> >> externals/loaders/hexloader# make >> make pd_linux >> make[1]: Entering directory >> `/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' >> cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops >> -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes - >> Werror >> -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o >> hexloader.pd_linux hexloader.c >> hexloader.c:64: error: redefinition of typedef ‘loader_t’ >> ../../../pd/src/s_stuff.h:55: error: previous declaration of >> ‘loader_t’ >> was here >> make[1]: *** [hexloader.pd_linux] Error 1 >> make[1]: Leaving directory >> `/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' >> make: *** [auto] Error 2 > > remove the "-Werror" flag from the makefile. > >> >> also it would be nice to include this external in pd-extended. > > _part_ of it is included in pd-vanilla (a bug has been fixed recently > with pd-0.41-test6 (or 7)) > > however, i have no problem if you add it to pd-extended (but i have no > time to do it myself) Ah, ok, I was under the impression that you wanted to remove the hex loader stuff from pd-vanilla and replace it with a loader. I think that wouldn't be so good because then other loaders couldn't use the hex names. What's the hex loader do? .hc > > >> and finally, what is the statut of the migration of cvs to svn? > > nil > > > fgmasd.r > IOhannes > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] hex loader
hi patrick wrote: > hi IOhannes, > > [<~] couldn't create. hans told me that i need your hex loader. so i > tried to compile it: > > externals/loaders/hexloader# make > make pd_linux > make[1]: Entering directory > `/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' > cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops > -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Werror > -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o > hexloader.pd_linux hexloader.c > hexloader.c:64: error: redefinition of typedef ‘loader_t’ > ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ > was here > make[1]: *** [hexloader.pd_linux] Error 1 > make[1]: Leaving directory > `/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' > make: *** [auto] Error 2 remove the "-Werror" flag from the makefile. > > also it would be nice to include this external in pd-extended. _part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7)) however, i have no problem if you add it to pd-extended (but i have no time to do it myself) > and finally, what is the statut of the migration of cvs to svn? nil fgmasd.r IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] hex loader
hi IOhannes, [<~] couldn't create. hans told me that i need your hex loader. so i tried to compile it: externals/loaders/hexloader# make make pd_linux make[1]: Entering directory `/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here make[1]: *** [hexloader.pd_linux] Error 1 make[1]: Leaving directory `/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' make: *** [auto] Error 2 also it would be nice to include this external in pd-extended. and finally, what is the statut of the migration of cvs to svn? patrick ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
