Hello list
i have a problem with the latest cyclone dll's from http://suita.chopin.edu.pl/~czaja/miXed/externs/cyclone.html. It seems like the prepend object is broken: not taking set messages as it used to do.
So, i've tried to compile it with mingw, but keep getting stuck here:
../../shared/shared.h:152: parse error before "int32"
../../shared/shared.h:152: warning: no semicolon at end of struct or union
../../shared/shared.h:153: warning: type defaults to int' in declaration oft_ shared_wrappy'
../../shared/shared.h:153: warning: data definition has no type or
storage class
../../shared/shared.h:158: parse error before "int32"
../../shared/shared.h:158: warning: no semicolon at end of struct or union
../../shared/shared.h:159: warning: type defaults to int' in declaration oft_ shared_floatint'
../../shared/shared.h:159: warning: data definition has no type or
storage class
i'd be glad if someone could give me a clue about what's happening, or for that matter leave me unenlightened and pass me some working dlls. thanks.
Johannes
hi Johannes,
Johannes Burström wrote: ...
http://suita.chopin.edu.pl/~czaja/miXed/externs/cyclone.html. It seems like the prepend object is broken: not taking set messages as it used to do.
in order to restore 'set' message to prepend and Append, run cyclone in max-compatibility mode: load it as "-lib maxmode", instead of "-lib cyclone", or replace "cyclone" with "maxmode" in "File/Startup...". The mode may be set by messages too.
When compatibility mode is not "max", prepend would handle 'set' message like any other. Instead, a prepend without creation arguments would get the second inlet -- accepting any message, which it stores as a new prefix.
So, i've tried to compile it with mingw, but keep getting stuck here:
../../shared/shared.h:152: parse error before "int32"
good to know... still using vc, but it is probably time to test for mingw as well...
Krzysztof
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
in order to restore 'set' message to prepend and Append, run cyclone in max-compatibility mode: load it as "-lib maxmode", instead of "-lib cyclone", or replace "cyclone" with "maxmode" in "File/Startup...". The mode may be set by messages too.
When compatibility mode is not "max", prepend would handle 'set' message like any other. Instead, a prepend without creation arguments would get the second inlet -- accepting any message, which it stores as a new prefix.
I cannot build the latest archive, because common/lex.c seems to be missing, but:
Do I understand this correctly, that prepend only accepts "set" messages to change the argument, when I load Cyclone as a library and do so as "maxmode"?
I somehow get the feeling that about a year of patches work is slowly falling apart at the moment ... :(
May I suggest that "set" retains the old default behaviour, until we have a "msg" object? Or maybe make [prepend with] argument accept "set" messages as in the past, and [prepend] without arg get the second inlet, but without the need to load libraries, so that it works as single external prepend, too.
Ciao
Frank Barknecht _ ______footils.org__
hi Frank,
Frank Barknecht wrote: ...
I cannot build the latest archive, because common/lex.c seems to be missing, but:
weird... was your last cvs update on Dec 8, between 15:40 and 15:45? a narrow window...
have a "msg" object? Or maybe make [prepend with] argument accept "set" messages as in the past, and [prepend] without arg get the second inlet, but without the need to load libraries, so that it works as single external prepend, too.
done. Should I put a warning: "'set' message is deprecated, and will be removed after %d days"? Perhaps, do so only on Mondays... How many prepends are out there to repatch?
Krzysztof
So, i've tried to compile it with mingw, but keep getting stuck here:
../../shared/shared.h:152: parse error before "int32"
you are getting the linux build. you might want to post on the mingw sourceforge tracker to have 'uname -a' report something besides MINGW32_NT-5.1, in the meantime you can remove the "ifeq ($(OS_NAME),MinGW)" thing from Makefile.common or change it to match uname -a...
good to know... still using vc, but it is probably time to test for mingw as well...
miXed/ all builds great, well, had to change this:
< LFLAGS = -shared $(PD_DIR)/../bin/pd.dll
LFLAGS = -shared $(PD_DIR)/../bin/pd.dll -Wl,--enable-runtime-pseudo-reloc
otherwise linking fails with gcc 3.4.2...
carmen (who's thinking about reimplementing the rest of iemgui objects in ToXY...)
hi carmen,
carmen wrote: ...
you are getting the linux build. you might want to post on the mingw sourceforge tracker to have 'uname -a' report something besides MINGW32_NT-5.1, in the meantime you can remove the "ifeq ($(OS_NAME),MinGW)" thing from Makefile.common or change it to match uname -a...
currently, OS_NAME is read from uname -s. How about testing for ifneq (,$(findstring MinGW,$(OS_NAME)))? Or should this be ifneq (,$(findstring MINGW,$(OS_NAME))), or both?
...
miXed/ all builds great, well, had to change this:
< LFLAGS = -shared $(PD_DIR)/../bin/pd.dll
LFLAGS = -shared $(PD_DIR)/../bin/pd.dll -Wl,--enable-runtime-pseudo-reloc
done, thanks
Krzysztof
-
carmen -
Frank Barknecht -
Johannes Burström -
Krzysztof Czaja