Karl MacMillan wrote:
I cannot open externals from ggext (or I presume any other set of externals compiled into a single object file) without putting a dummy ggext object on the page. I know that this was discussed before, but there was no resolution that I remember.
there is one solution :: using the "-lib" flag
There are two solutions that I see: compile externals into individual files for each object or have a folder like Opcode Max that holds externals that are loaded at startup. It seems that the first solution is easier and it is more intuitive to the user (you can see what objects are available by looking in the folder rather than having to remember what ggext contains). I don't think the dummy object is acceptable - the point of me doing this is to make things integrate seamlessly.
to me it looks more elegant, just to create one library file than to split up thousands of tiny ones, just imagine GEM. Of course this might be discussed, still. (some times ago it was hard to create proper ~-objects that would load correctly. It was then, i decided to make a big external to work around this problem, but:: i think miller fixed this in pd0.26 or so, so it should be no problem any more) Then some objects are really linked, such as streamin~/streamout~ (note: i know that they don't work at all in the zexy external), or like guenters slider, toddles etc.; these should really be loaded at the same time...
as i indicated previously, i would highly recommend to create something like the "package require" in jmax. this would fix the problem with the dummy objects; maybe there could be a kind of "library objects" (in opposition to the command-line based jmax); but i am too lazy to do it myself
The zexy externals will not compile for me - make says "makefile:4: *** commands commence before first target. Stop." I started to hack on the makefile, but thought I would see if I am missing something obvious first. Any ideas?
i cannot reconstruct this problem, for me it works fine on Win95, WinNT and linux:debian; i haven't tried irix but maybe there are some <space>s at the and of the line ?
sfplay on linux seems to require absolute paths though the help file seems to imply that it will look in the current directory first (haven't checked NT yet). Is this is a portability issue or am I just making a wrong assumption?
again i cannot reconstruct this; here on debian it works fine with relative directories (personally i haven't tested it on NT, but i hear that it did a half-year installation very well on this os)
mfg.fdsa.dfs hannes
by the way:: i checked the linux-version of zexy and cleaned it a little bit up; there WERE some quite dirty messages when compiling (though no errors); i hope i could fix the time object too, although i still get the wrong local time on my machine (on NT/95 it works); if you have this problem too (or not), i would be pleased to be informed