From valj01 at gel.usherb.ca Tue Jul 3 23:32:30 2001 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:39:19 2006 Subject: [Pipet Users] Overflow 0.5.0 released Message-ID: <3B428E4E.54E77DE@gel.usherb.ca> Hi Pipers! I've just released Overflow (PL) 0.5.0. Get it at: http://sourceforge.net/project/showfiles.php?group_id=590 Improvements are: - Binary I/O (serialization/unserialization) of objects - Major improvements to object ASCII I/O, mostly with the Vector type - Default FFT implementation when FFTW is not available - Possibility of passing any object type as a parameter from the GUI - gcc 2.96-RH support - Performance improvements - Fixes for Piper (http://bioinformatics.org/piper/) compatibility - Several new nodes The most important for Piper is the (binary) IO part. It allow to serialize (in endian-independent format) Overflow objects so they can be sent through a network. This will allow to exchange objects between machines. This release should also address the compilation issues of last month. Have fun! Jean-Marc From jarl at xs4all.nl Thu Jul 5 09:29:39 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Overflow 0.5.0 released References: <3B428E4E.54E77DE@gel.usherb.ca> Message-ID: <3B446BC3.3090507@xs4all.nl> HI JM, Great work, nice to see you're still continueing to work on Overflow. I got a problem though. Compilation of Overflow-0.5.0 goes without any problem, but during compilation of Piper I got: ----- In file included from /usr/local/include/ObjectRef.h:8, from plugin_sensor_PL_main.c:16: /usr/local/include/net_types.h:241: type/value mismatch at argument 1 in template parameter list for `template TypeTraits' /usr/local/include/net_types.h:241: expected a type, got `String' /usr/local/include/net_types.h:241: explicit specialization of non-template `{anonymous struct}' /usr/local/include/net_types.h:241: anonymous class type not used to declare any objects ----- my C++ knowlegde is too limited to fix this, and I guess this should be fixed in the Overflow codebase. Any thoughts? > - Binary I/O (serialization/unserialization) of objects > The most important for Piper is the (binary) IO part. It allow to serialize (in > endian-independent format) Overflow objects so they can be sent through a > network. This will allow to exchange objects between machines. Very nice.. I didn't thought about this issue yet ;) Jarl From valj01 at gel.usherb.ca Thu Jul 5 09:38:45 2001 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Overflow 0.5.0 released References: <3B428E4E.54E77DE@gel.usherb.ca> <3B446BC3.3090507@xs4all.nl> Message-ID: <3B446DE5.645A8871@gel.usherb.ca> > Great work, nice to see you're still continueing to work on Overflow. I > got a problem though. Compilation of Overflow-0.5.0 goes without any > problem, but during compilation of Piper I got: > > ----- > In file included from /usr/local/include/ObjectRef.h:8, > from plugin_sensor_PL_main.c:16: > /usr/local/include/net_types.h:241: type/value mismatch at argument 1 in > template parameter list for `template TypeTraits' > /usr/local/include/net_types.h:241: expected a type, got `String' > /usr/local/include/net_types.h:241: explicit specialization of > non-template `{anonymous struct}' > /usr/local/include/net_types.h:241: anonymous class type not used to > declare any objects > ----- > > my C++ knowlegde is too limited to fix this, and I guess this should be > fixed in the Overflow codebase. Any thoughts? That's odd... I never got that error. Right now, the quick fix for you would be to remove the offending line: _DEF_OBJECT_TYPE(String) (I think it won't cause much side effet for you) while I try to find the problem. What compiler are you using? I see the file to be plugin_sensor_PL_main.c, is that C or C++? Also, could you send me the pre-processed file so I can see what happened with the includes? Jean-Marc P.S. As a general rule when compiling Overflow: if it doesn't compile, remove it and all the rest is likely to work. For instance, most of the times, you can remove a .cc (when it's a node implementation) from the Makefile and everything will keep working (just don't use that Node). From jarl at xs4all.nl Thu Jul 5 10:33:42 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Overflow 0.5.0 released References: <3B428E4E.54E77DE@gel.usherb.ca> <3B446BC3.3090507@xs4all.nl> <3B446DE5.645A8871@gel.usherb.ca> Message-ID: <3B447AC6.8080707@xs4all.nl> > That's odd... I never got that error. Right now, the quick fix for you would be > to remove the offending line: > _DEF_OBJECT_TYPE(String) righty, after done this Piper compiles again nicely. > (I think it won't cause much side effet for you) while I try to find the > problem. What compiler are you using? I see the file to be > plugin_sensor_PL_main.c, is that C or C++? Also, could you send me the > pre-processed file so I can see what happened with the includes? Got gcc 2.95.3 \ glib2.2.1 \ slackware7.1 \ kernel 2.4.5 Jarl -------------- next part -------------- plugin_sensor_PL_main.o: plugin_sensor_PL_main.c \ ../include/messaging_config.h ../include/messaging.h \ /usr/include/stdlib.h /usr/include/features.h \ /usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/stddef.h \ /usr/include/sys/types.h /usr/include/bits/types.h \ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \ /usr/include/time.h /usr/include/endian.h /usr/include/bits/endian.h \ /usr/include/sys/select.h /usr/include/bits/select.h \ /usr/include/bits/sigset.h /usr/include/sys/sysmacros.h \ /usr/include/alloca.h /usr/include/glib-1.2/glib.h \ /usr/lib/glib/include/glibconfig.h /usr/include/limits.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/limits.h \ /usr/include/bits/posix1_lim.h /usr/include/bits/local_lim.h \ /usr/include/linux/limits.h /usr/include/bits/posix2_lim.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/float.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/stdarg.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iostream \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iostream.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/streambuf.h \ /usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \ /usr/include/bits/wchar.h /usr/include/gconv.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/map \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_tree.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_config.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_relops.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_pair.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/type_traits.h \ /usr/include/string.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/new.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/new \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/exception \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_iterator.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_alloc.h \ /usr/include/assert.h /usr/include/pthread.h /usr/include/sched.h \ /usr/include/bits/time.h /usr/include/signal.h \ /usr/include/bits/initspin.h /usr/include/bits/sigthread.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_construct.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_function.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_map.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_multimap.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/list \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_uninitialized.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_list.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/vector \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_vector.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_bvector.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/string \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/bastring.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cstddef \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/straits.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cctype \ /usr/include/ctype.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cstring \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/alloc.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iterator \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/bastring.cc \ /usr/include/dlfcn.h /usr/include/bits/dlfcn.h /usr/include/stdio.h \ /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \ /usr/include/unistd.h /usr/include/bits/posix_opt.h \ /usr/include/bits/confname.h /usr/include/getopt.h \ /usr/include/glib-1.2/gmodule.h /usr/include/sys/stat.h \ /usr/include/bits/stat.h /usr/include/fcntl.h \ /usr/include/bits/fcntl.h /usr/include/gnome-xml/tree.h \ /usr/include/bits/signum.h /usr/include/bits/siginfo.h \ /usr/include/bits/wordsize.h /usr/include/bits/sigaction.h \ /usr/include/bits/sigcontext.h /usr/include/asm/sigcontext.h \ /usr/include/bits/sigstack.h /usr/local/include/ParameterSet.h \ /usr/local/include/Object.h /usr/local/include/rc_ptrs.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/typeinfo \ /usr/local/include/BaseException.h /usr/local/include/ObjectRef.h \ /usr/local/include/net_types.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/fstream \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/fstream.h \ /usr/local/include/ObjectPool.h /usr/local/include/ObjectParser.h \ /usr/local/include/typetraits.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/complex \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/complext.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cmath \ /usr/include/math.h /usr/include/bits/huge_val.h \ /usr/include/bits/mathdef.h /usr/include/bits/mathcalls.h \ /usr/include/bits/mathinline.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/fcomplex.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/dcomplex.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/ldcomplex.h \ /usr/local/include/UIDocument.h /usr/local/include/UINetwork.h \ /usr/local/include/UINetTerminal.h \ /usr/local/include/UINodeParameters.h /usr/local/include/path.h \ plugin_sensor_PL_main.h BL2PL.hh /usr/local/include/omniORB3/CORBA.h \ /usr/local/include/omniORB3/omniInternal.h /usr/include/strings.h \ /usr/local/include/omnithread.h /usr/local/include/omnithread/posix.h \ /usr/local/include/omniORB3/CORBA_sysdep.h \ /usr/local/include/omniORB3/CORBA_basetypes.h \ /usr/local/include/omniORB3/seqtemplates.h \ /usr/local/include/omniORB3/GIOP.h /usr/local/include/omniORB3/IOP.h \ /usr/local/include/omniORB3/IIOP.h \ /usr/local/include/omniORB3/omniObjKey.h \ /usr/local/include/omniORB3/tracedthread.h \ /usr/local/include/omniORB3/rope.h \ /usr/local/include/omniORB3/bufferedStream.h \ /usr/local/include/omniORB3/giopDriver.h \ /usr/local/include/omniORB3/omniObjRef.h \ /usr/local/include/omniORB3/proxyFactory.h \ /usr/local/include/omniORB3/omniServant.h \ /usr/local/include/omniORB3/templatedecls.h \ /usr/local/include/omniORB3/stringtypes.h \ /usr/local/include/omniORB3/userexception.h \ /usr/local/include/omniORB3/corbaidl_defs.hh \ /usr/local/include/omniORB3/CORBA_vartypes.h \ /usr/local/include/omniORB3/omniORB.h \ /usr/local/include/omniORB3/templatedefns.h \ /usr/local/include/omniORB3/corba_operators.h \ /usr/local/include/omniORB3/poa.h \ /usr/local/include/omniORB3/poa_defs.h \ /usr/local/include/omniORB3/poa_operators.h \ /usr/local/include/omniORB3/poa_poa.h \ /usr/local/include/omniORB3/corbaidl_operators.hh \ /usr/local/include/omniORB3/corbaidl_poa.hh \ /usr/local/include/omniORB3/boa.h \ /usr/local/include/omniORB3/Naming.hh -------------- next part -------------- plugin_sensor_PL_main.o: plugin_sensor_PL_main.c \ ../include/messaging_config.h ../include/messaging.h \ /usr/include/stdlib.h /usr/include/features.h \ /usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/stddef.h \ /usr/include/sys/types.h /usr/include/bits/types.h \ /usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \ /usr/include/time.h /usr/include/endian.h /usr/include/bits/endian.h \ /usr/include/sys/select.h /usr/include/bits/select.h \ /usr/include/bits/sigset.h /usr/include/sys/sysmacros.h \ /usr/include/alloca.h /usr/include/glib-1.2/glib.h \ /usr/lib/glib/include/glibconfig.h /usr/include/limits.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/limits.h \ /usr/include/bits/posix1_lim.h /usr/include/bits/local_lim.h \ /usr/include/linux/limits.h /usr/include/bits/posix2_lim.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/float.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/stdarg.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iostream \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iostream.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/streambuf.h \ /usr/include/libio.h /usr/include/_G_config.h /usr/include/wchar.h \ /usr/include/bits/wchar.h /usr/include/gconv.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/map \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_tree.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_config.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_relops.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_pair.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/type_traits.h \ /usr/include/string.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/new.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/new \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/exception \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_iterator.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_alloc.h \ /usr/include/assert.h /usr/include/pthread.h /usr/include/sched.h \ /usr/include/bits/time.h /usr/include/signal.h \ /usr/include/bits/initspin.h /usr/include/bits/sigthread.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_construct.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_function.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_map.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_multimap.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/list \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_uninitialized.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_list.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/vector \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_vector.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_bvector.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/string \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/bastring.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cstddef \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/straits.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cctype \ /usr/include/ctype.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cstring \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/alloc.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iterator \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/bastring.cc \ /usr/include/dlfcn.h /usr/include/bits/dlfcn.h /usr/include/stdio.h \ /usr/include/bits/stdio_lim.h /usr/include/bits/stdio.h \ /usr/include/unistd.h /usr/include/bits/posix_opt.h \ /usr/include/bits/confname.h /usr/include/getopt.h \ /usr/include/glib-1.2/gmodule.h /usr/include/sys/stat.h \ /usr/include/bits/stat.h /usr/include/fcntl.h \ /usr/include/bits/fcntl.h /usr/include/gnome-xml/tree.h \ /usr/include/bits/signum.h /usr/include/bits/siginfo.h \ /usr/include/bits/wordsize.h /usr/include/bits/sigaction.h \ /usr/include/bits/sigcontext.h /usr/include/asm/sigcontext.h \ /usr/include/bits/sigstack.h /usr/local/include/ParameterSet.h \ /usr/local/include/Object.h /usr/local/include/rc_ptrs.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/typeinfo \ /usr/local/include/BaseException.h /usr/local/include/ObjectRef.h \ /usr/local/include/net_types.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/fstream \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/fstream.h \ /usr/local/include/ObjectPool.h /usr/local/include/ObjectParser.h \ /usr/local/include/typetraits.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/complex \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/complext.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cmath \ /usr/include/math.h /usr/include/bits/huge_val.h \ /usr/include/bits/mathdef.h /usr/include/bits/mathcalls.h \ /usr/include/bits/mathinline.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/fcomplex.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/dcomplex.h \ /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/ldcomplex.h \ /usr/local/include/UIDocument.h /usr/local/include/UINetwork.h \ /usr/local/include/UINetTerminal.h \ /usr/local/include/UINodeParameters.h /usr/local/include/path.h \ plugin_sensor_PL_main.h BL2PL.hh /usr/local/include/omniORB3/CORBA.h \ /usr/local/include/omniORB3/omniInternal.h /usr/include/strings.h \ /usr/local/include/omnithread.h /usr/local/include/omnithread/posix.h \ /usr/local/include/omniORB3/CORBA_sysdep.h \ /usr/local/include/omniORB3/CORBA_basetypes.h \ /usr/local/include/omniORB3/seqtemplates.h \ /usr/local/include/omniORB3/GIOP.h /usr/local/include/omniORB3/IOP.h \ /usr/local/include/omniORB3/IIOP.h \ /usr/local/include/omniORB3/omniObjKey.h \ /usr/local/include/omniORB3/tracedthread.h \ /usr/local/include/omniORB3/rope.h \ /usr/local/include/omniORB3/bufferedStream.h \ /usr/local/include/omniORB3/giopDriver.h \ /usr/local/include/omniORB3/omniObjRef.h \ /usr/local/include/omniORB3/proxyFactory.h \ /usr/local/include/omniORB3/omniServant.h \ /usr/local/include/omniORB3/templatedecls.h \ /usr/local/include/omniORB3/stringtypes.h \ /usr/local/include/omniORB3/userexception.h \ /usr/local/include/omniORB3/corbaidl_defs.hh \ /usr/local/include/omniORB3/CORBA_vartypes.h \ /usr/local/include/omniORB3/omniORB.h \ /usr/local/include/omniORB3/templatedefns.h \ /usr/local/include/omniORB3/corba_operators.h \ /usr/local/include/omniORB3/poa.h \ /usr/local/include/omniORB3/poa_defs.h \ /usr/local/include/omniORB3/poa_operators.h \ /usr/local/include/omniORB3/poa_poa.h \ /usr/local/include/omniORB3/corbaidl_operators.hh \ /usr/local/include/omniORB3/corbaidl_poa.hh \ /usr/local/include/omniORB3/boa.h \ /usr/local/include/omniORB3/Naming.hh plugin_sensor_PL_main.c : ../include/messaging_config.h : ../include/messaging.h : /usr/include/stdlib.h : /usr/include/features.h : /usr/include/sys/cdefs.h : /usr/include/gnu/stubs.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/stddef.h : /usr/include/sys/types.h : /usr/include/bits/types.h : /usr/include/bits/pthreadtypes.h : /usr/include/bits/sched.h : /usr/include/time.h : /usr/include/endian.h : /usr/include/bits/endian.h : /usr/include/sys/select.h : /usr/include/bits/select.h : /usr/include/bits/sigset.h : /usr/include/sys/sysmacros.h : /usr/include/alloca.h : /usr/include/glib-1.2/glib.h : /usr/lib/glib/include/glibconfig.h : /usr/include/limits.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/limits.h : /usr/include/bits/posix1_lim.h : /usr/include/bits/local_lim.h : /usr/include/linux/limits.h : /usr/include/bits/posix2_lim.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/float.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/stdarg.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iostream : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iostream.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/streambuf.h : /usr/include/libio.h : /usr/include/_G_config.h : /usr/include/wchar.h : /usr/include/bits/wchar.h : /usr/include/gconv.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/map : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_tree.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_algobase.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_config.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_relops.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_pair.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/type_traits.h : /usr/include/string.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/new.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/new : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/exception : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_iterator.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_alloc.h : /usr/include/assert.h : /usr/include/pthread.h : /usr/include/sched.h : /usr/include/bits/time.h : /usr/include/signal.h : /usr/include/bits/initspin.h : /usr/include/bits/sigthread.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_construct.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_function.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_map.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_multimap.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/list : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_uninitialized.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_list.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/vector : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_vector.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/stl_bvector.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/string : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/bastring.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cstddef : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/straits.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cctype : /usr/include/ctype.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cstring : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/alloc.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/iterator : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/bastring.cc : /usr/include/dlfcn.h : /usr/include/bits/dlfcn.h : /usr/include/stdio.h : /usr/include/bits/stdio_lim.h : /usr/include/bits/stdio.h : /usr/include/unistd.h : /usr/include/bits/posix_opt.h : /usr/include/bits/confname.h : /usr/include/getopt.h : /usr/include/glib-1.2/gmodule.h : /usr/include/sys/stat.h : /usr/include/bits/stat.h : /usr/include/fcntl.h : /usr/include/bits/fcntl.h : /usr/include/gnome-xml/tree.h : /usr/include/bits/signum.h : /usr/include/bits/siginfo.h : /usr/include/bits/wordsize.h : /usr/include/bits/sigaction.h : /usr/include/bits/sigcontext.h : /usr/include/asm/sigcontext.h : /usr/include/bits/sigstack.h : /usr/local/include/ParameterSet.h : /usr/local/include/Object.h : /usr/local/include/rc_ptrs.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include/typeinfo : /usr/local/include/BaseException.h : /usr/local/include/ObjectRef.h : /usr/local/include/net_types.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/fstream : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/fstream.h : /usr/local/include/ObjectPool.h : /usr/local/include/ObjectParser.h : /usr/local/include/typetraits.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/complex : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/complext.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/cmath : /usr/include/math.h : /usr/include/bits/huge_val.h : /usr/include/bits/mathdef.h : /usr/include/bits/mathcalls.h : /usr/include/bits/mathinline.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/fcomplex.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/dcomplex.h : /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3/std/ldcomplex.h : /usr/local/include/UIDocument.h : /usr/local/include/UINetwork.h : /usr/local/include/UINetTerminal.h : /usr/local/include/UINodeParameters.h : /usr/local/include/path.h : plugin_sensor_PL_main.h : BL2PL.hh : /usr/local/include/omniORB3/CORBA.h : /usr/local/include/omniORB3/omniInternal.h : /usr/include/strings.h : /usr/local/include/omnithread.h : /usr/local/include/omnithread/posix.h : /usr/local/include/omniORB3/CORBA_sysdep.h : /usr/local/include/omniORB3/CORBA_basetypes.h : /usr/local/include/omniORB3/seqtemplates.h : /usr/local/include/omniORB3/GIOP.h : /usr/local/include/omniORB3/IOP.h : /usr/local/include/omniORB3/IIOP.h : /usr/local/include/omniORB3/omniObjKey.h : /usr/local/include/omniORB3/tracedthread.h : /usr/local/include/omniORB3/rope.h : /usr/local/include/omniORB3/bufferedStream.h : /usr/local/include/omniORB3/giopDriver.h : /usr/local/include/omniORB3/omniObjRef.h : /usr/local/include/omniORB3/proxyFactory.h : /usr/local/include/omniORB3/omniServant.h : /usr/local/include/omniORB3/templatedecls.h : /usr/local/include/omniORB3/stringtypes.h : /usr/local/include/omniORB3/userexception.h : /usr/local/include/omniORB3/corbaidl_defs.hh : /usr/local/include/omniORB3/CORBA_vartypes.h : /usr/local/include/omniORB3/omniORB.h : /usr/local/include/omniORB3/templatedefns.h : /usr/local/include/omniORB3/corba_operators.h : /usr/local/include/omniORB3/poa.h : /usr/local/include/omniORB3/poa_defs.h : /usr/local/include/omniORB3/poa_operators.h : /usr/local/include/omniORB3/poa_poa.h : /usr/local/include/omniORB3/corbaidl_operators.hh : /usr/local/include/omniORB3/corbaidl_poa.hh : /usr/local/include/omniORB3/boa.h : /usr/local/include/omniORB3/Naming.hh : From jmvalin at locusdialogue.com Thu Jul 5 11:08:57 2001 From: jmvalin at locusdialogue.com (Jean-Marc Valin) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Overflow 0.5.0 released References: <3B428E4E.54E77DE@gel.usherb.ca> <3B446BC3.3090507@xs4all.nl> <3B446DE5.645A8871@gel.usherb.ca> <3B447AC6.8080707@xs4all.nl> Message-ID: <3B448309.6524E0E9@locusdialogue.com> > Got gcc 2.95.3 \ glib2.2.1 \ slackware7.1 \ kernel 2.4.5 That's really strange... could you send the preprocessed output, I found nothing wrong in the include list. Jean-Marc From jeff at bioinformatics.org Thu Jul 5 18:10:49 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Open-source fans try to outflank .Net - Tech News - CNET.com Message-ID: <3B44E5E9.49DDF1A9@bioinformatics.org> http://news.cnet.com/news/0-1003-200-6455783.html Not about Piper. Jeff From jeff at bioinformatics.org Thu Jul 5 18:23:30 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - CNET.com References: <3B44E5E9.49DDF1A9@bioinformatics.org> Message-ID: <3B44E8E2.D0B51BC2@bioinformatics.org> Here's a very telling quote: Last week, de Icaza said he's researched .Net extensively, likes it and believes having a version of .Net for Linux would be "good for Linux and Microsoft." I heard Miguel talk in Boston last year, and he unabashedly says that he likes and copies Microsoft programs for Gnome. Personally, I think that both GNOME and KDE are much too much like Windows AND EACH OTHER. Here's a good question: Is it possible to create an "open-source Linux-based clone" of a Windows-centric system/standard dictated by "embrace, extend, extinguish" Microsoft? Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From jarl at xs4all.nl Wed Jul 4 20:06:06 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - CNET.com References: <3B44E5E9.49DDF1A9@bioinformatics.org> <3B44E8E2.D0B51BC2@bioinformatics.org> Message-ID: <3B43AF6E.5080909@xs4all.nl> > Here's a good question: Is it possible to create an "open-source Linux-based > clone" of a Windows-centric system/standard dictated by "embrace, extend, > extinguish" Microsoft? Are you asking us or is this a part of the quote? Anyways, I think .net will be crushed unther it's own weight: it's mad to think Mircrosoft or any other firm could build it. A 'general VM that abstracts any hardware ' is something out a satiric movie about an insane scientist. Will die same death as Java: burried in it's little nich where it has some sort of usefullness. And forgotten once it's no longer a buzz word. Hmm.. maybe I'm having a scinical mood orso ;-) Jarl From jeff at bioinformatics.org Thu Jul 5 20:52:35 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - CNET.com References: <3B44E5E9.49DDF1A9@bioinformatics.org> <3B44E8E2.D0B51BC2@bioinformatics.org> <3B43AF6E.5080909@xs4all.nl> Message-ID: <3B450BD3.32366A92@bioinformatics.org> Jarl van Katwijk wrote: > > Are you asking us or is this a part of the quote? Asking > Anyways, I think .net > will be crushed unther it's own weight: it's mad to think Mircrosoft or > any other firm could build it. A 'general VM that abstracts any hardware > ' is something out a satiric movie about an insane scientist. Will die > same death as Java: burried in it's little nich where it has some sort > of usefullness. And forgotten once it's no longer a buzz word. That is, *IF* it is only supported by Microsoft. Having Gnome support .NET (and/or the Free/Open source community in general, as the article suggests) throws some substantial weight behind ".NET as an open standard". It would be the irony of the decade if the Free/Open source community actually ends up boosting a Microsoft system into dominance. I'm extremely biased, but I would rather see a UNIX-like system that leverages existing tools and uses community-developed standards. Hmmm, now what could that be? ;-) Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From SCoffman at COVANSYS.com Sat Jul 7 18:11:12 2001 From: SCoffman at COVANSYS.com (COFFMAN Steven) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - CNET.com Message-ID: There's several free, open-source projects that track Microsoft "standards" I can think of: Samba tracks SMB (file, print, auth) GB tracks Visual Basic for Gnumeric (excel clone) FreeTDS tracks SQL Server/Sybase protocol Jabber (among others) tracks MSN Messenger Since .NET is ostensibly open, even if Microsoft controls it, and free software is capable of both reverse-engineering and tracking closed Microsoft standards, I think it's quite possible, especially if big money funds it. Whether it is a good strategy to do so is another question, but I don't fault de Icaza for liking the idea of sharing reusable components. Both MS and Gnome/KDE camps are concerned with incremental change rather than revolutionary, and reusable component sharing is a practical idea. As for revolutionary change in software, that will come from elsewhere. Exokernels, data visualization (like Piper, ZigZag, or Arrows) and such. Any cool software revolutions brewing you find interesting? -Steve -----Original Message----- From: J.W. Bizzaro To: pipet-users@bioinformatics.org Sent: 7/5/01 6:23 PM Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - CNET.com Here's a very telling quote: Last week, de Icaza said he's researched .Net extensively, likes it and believes having a version of .Net for Linux would be "good for Linux and Microsoft." I heard Miguel talk in Boston last year, and he unabashedly says that he likes and copies Microsoft programs for Gnome. Personally, I think that both GNOME and KDE are much too much like Windows AND EACH OTHER. Here's a good question: Is it possible to create an "open-source Linux-based clone" of a Windows-centric system/standard dictated by "embrace, extend, extinguish" Microsoft? Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- _______________________________________________ pipet-users maillist - pipet-users@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-users From jeff at bioinformatics.org Sun Jul 8 23:10:11 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] PiperNet and PNSO Message-ID: <3B492093.47E93E30@bioinformatics.org> Greetings Pipers! We have a new website set up for PiperNet and PNSO. What are they? From the website: ``PiperNet is any network of programs that work with the PiperNet standards. Piper is a reference implementation of this standard. It is an application or system for the peer-to-peer (P2P) distribution of programs and data-flow. ``The PiperNet Standards Organization (PNSO) is a committee involved in the standardization of PiperNet protocols and interfaces.'' http://bioinformatics.org/pipernet/ PNSO membership is open but limited. We're not sure about how many seats we'll have. Obviously, the founding members of Piper are included. We'd also like to extend membership to LogiLab (Narval -- what happened to the website?) and dLoo (BlueBox). Others can include projects that may work with/on the PiperNet. We also have pipernet.org and pipernet.net, which will be working soon. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From Alexandre.Fayolle at logilab.fr Mon Jul 9 03:15:19 2001 From: Alexandre.Fayolle at logilab.fr (Alexandre Fayolle) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] PiperNet and PNSO In-Reply-To: <3B492093.47E93E30@bioinformatics.org> Message-ID: On Sun, 8 Jul 2001, J.W. Bizzaro wrote: > we'll have. Obviously, the founding members of Piper are included. We'd also > like to extend membership to LogiLab (Narval -- what happened to the website?) We'd be glad to be members. Concerning the web site, as far as I know, it's up and running (http://www.logilab.org/narval/) Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). From andy.elvey at paradise.net.nz Mon Jul 9 03:47:09 2001 From: andy.elvey at paradise.net.nz (Andy Elvey) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Re: pipet-users digest, Vol 1 #282 - 2 msgs References: <200107081600.MAA32580@www.bioinformatics.org> Message-ID: <000c01c1084b$5c6e81c0$999360cb@andyelve> ----- Original Message ----- > > Message: 1 > From: COFFMAN Steven > Any cool software revolutions brewing you find interesting? > -Steve Yes ! Although its still in its early stages, check out Oscar/Primo ( http://groups.yahoo.com/group/OSCAR-PROJECT ) OSCAR = Open Source Code Aka Rebol. As the name suggests, this is an open-source imitation/"work-alike" of Rebol (http://www.rebol.com ) . Rebol is an **amazing** package that has to be seen to be believed. The most compact and powerful programming-language syntax I've seen , and that includes Python - Rebol even out-does that :-) Supports any data-type you can think of, and pretty much **all internet protocols** as well - all in less than 1/2 MB download. ( Sorry if this seems a bit "ad-like" ..... :-) Sadly - Rebol itself is not open-source. Free , yes (Rebol/Core anyway) , but not open-source. Hence, the above project, which has a keen and able core group of developers (I'm a keen follower, not one of the developers). If you have some free time and are keen to help, I'm sure they'd love to hear from anyone here ..... If Oscar/Primo can become something close to Rebol, that'll be great - I'm awaiting with keen interest ! > -----Original Message----- > From: J.W. Bizzaro > To: pipet-users@bioinformatics.org > Sent: 7/5/01 6:23 PM > Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - > CNET.com > > Here's a very telling quote: > > Last week, de Icaza said he's researched .Net extensively, > likes it and believes having a version of .Net for Linux > would be "good for Linux and Microsoft." > > I heard Miguel talk in Boston last year, and he unabashedly says that he > likes and copies Microsoft programs for Gnome. Personally, I think that both > GNOME and KDE are much too much like Windows AND EACH OTHER. > Here's a good question: Is it possible to create an "open-source > Linux-based clone" of a Windows-centric system/standard dictated by "embrace, > extend extinguish" Microsoft? > Cheers. > Jeff Yes again ! See the above ...... :-) From Nicolas.Chauvat at logilab.fr Mon Jul 9 07:05:27 2001 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] Re: Open-source fans try to outflank .Net - Tech News - CNET.com In-Reply-To: Message-ID: > Any cool software revolutions brewing you find interesting? Me, me !!! http://www.logilab.org/narval is AI for the rest of us :-)) -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From Nicolas.Chauvat at logilab.fr Mon Jul 9 07:15:10 2001 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] PiperNet and PNSO In-Reply-To: <3B492093.47E93E30@bioinformatics.org> Message-ID: Hi List, > PNSO membership is open but limited. We're not sure about how many > seats we'll have. Obviously, the founding members of Piper are > included. We'd also like to extend membership to LogiLab We gladly accept the invitation ! :-) > (Narval -- what happened to the website?) Still at www.logilab.org/narval -- do you have any problem to get to it ? -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From jeff at bioinformatics.org Mon Jul 9 18:19:59 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] TSpaces - Computer Science Research at Almaden Message-ID: <3B4A2E0F.8469B165@bioinformatics.org> I don't think this was mentioned here before: http://www.almaden.ibm.com/cs/TSpaces/ Jeff From nile at dloo.com Wed Jul 11 10:55:52 2001 From: nile at dloo.com (nile@dloo.com) Date: Fri Feb 10 19:39:20 2006 Subject: [Pipet Users] BlueBox released under GPL In-Reply-To: Message-ID: Hi guys, We just released BlueBox under the GPL. Thanks for your patience. Implementing this stuff was hard. It uses the word model to implement the architecture for a P2P programming language. Here's the press release: A Peer to Peer Programming Language Most programming languages are statically defined when they are compiled. C++, C, Java, and other languages cannot become richer over time after their compilers or interpreters are compiled. This model of building programming languages is pre-Internet, mirroring how books, magazines, and journals were published before the appearance of Web pages, dynamic content, and hyperlinking. Instead of this model, however, imagine a programming language that was defined on the Internet and more importantly, became richer over time as more programmers added to it. This is the idea behind BlueBox, a browser that runs a scalable peer-to-peer programming language that we are releasing today. dLoo was formed over a year ago to create a browser, BlueBox, that could download language structures from the Internet and dynamically assemble them into languages. We needed the language structures to be modular so that the languages could scale in richness across non-communicating parties. We needed developers to be able to extend languages simply by linking to existing structures. The goal was to create a language that lived on the Internet and that grew in richness as developers created new pieces. Although the concept of a scalable peer-to-peer programming language is conceptually simple, implementing it took over than a year. We tried over a hundred variations before finding a programming unit that would fit our criteria for a language structure and be simple to use. The structure that we choose and that is used in BlueBox today is called a "word." Words are scalable, linkable, and allow for language inheritance and polymorphism. They model Web pages in their ability to scale and link to one another to solve new problems. With words, one programmer can post HTML words, another Calculus words, and a third could create an HTML/Calculus language by changing one of the links in an HTML word to point to Calculus. A fourth programmer could then come along and add a graphing language by adding a link from a graph word to a Calculus word. This simple ability to link one language to another allows programmers to create very dense syntaxes to cleanly solve complicated problems. Individuals can build off of the words that have already been posted on the Internet to create richer and richer languages without every talking to one another. The language is defined on the Internet and can be extended by anyone with a minimal amount of work. In addition to linking, words allow programmers to inherit languages and override their syntax and semantics on a word-by-word basis. Language inheritance adds phenomenal power to the programmers toolkit. One of the modules included in BlueBox is an abstract programming language written in words that programmers can inherit from to create specific programming languages like Perl and Python. Because this language already supports inheritance, standard conditional structures, and other basic features of programming language, programmers do not have to implement them when creating a new language. They simply inherit from the abstract language and override its syntax where appropriate. Language polymorphism means that if programmers specify that a document is written in an abstract language, they can use all of the languages that inherit from it. For example, the abstract programming language can compile programs written using syntax from any of the languages that inherit from it. As syntaxes like Perl, Python, C++, and Java are created by inheriting from the abstract language, it is possible to write programs that mix all of these languages together (see bluebox/src/tests/code). More importantly, language polymorphism means that new developers can add new words to a language simply by inheriting from existing ones. If HTML was written in words, for example, anyone could add new widgets and domains to the language. All of the features mentioned in this paper are working today. After a year of development, the product has been released to the open source community under the GPL. A community site set up around BlueBox with access to the source can be found at http://www.dloo.org. The main features in this release are: Implementation of a natural language database so that words can be dynamically downloaded, compiled, and assembled into a language. Full support for language inheritance and polymorphism BlueBox itself written in words Full support for words that are written in other words Ability to download and compile words from the Internet The architecture of a software translator for transforming one technology or language to another. Only has Python as a dependency. The previous releases, which were solely for educational purposes, had several difficult dependencies. A tutorial on how to create and post words can be found here and a more detailed description of BlueBoxs architecture is available here. The Web broke the conventions that information should be formally organized and indexed. One of the main criticisms of the early Web was that it was unorganized: anyone could post and link to other articles. BlueBox brings the same roller-coaster ride to language design. In place of formal language committees and hundred-page specifications, we have an language that can be added to and linked to by anyone. In the next few weeks, we are going to be implementing the code for database sharing in BlueBox and launching the network for sharing words. We do not know what this Internet of words is going to become but we think it is going to grow fast and with a wild creativity beyond anything that we can imagine today. Were looking for early adopters to post some of the first words on the Internet. We also want to invite anyone whos interested to jump in and get their hands dirty on a peer to peer natural programming language. From jeff at bioinformatics.org Fri Jul 13 02:32:41 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] .GNU Message-ID: <3B4E9609.DD057A1B@bioinformatics.org> Yet another .NET alternative: http://news.linuxprogramming.com/news_story.php3?ltsn=2001-07-12-001-06-LT Jeff From jeff at bioinformatics.org Fri Jul 13 02:38:29 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Nareau Message-ID: <3B4E9765.746CB2E7@bioinformatics.org> Yet ANOTHER .NET alternative: http://nareau.weblogs.com/ Jeff From Robin.Ge at aventis.com Mon Jul 16 14:58:18 2001 From: Robin.Ge at aventis.com (Robin.Ge@aventis.com) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] download Message-ID: I don't have CVS on my unix machine. Can you give the ftp site for me to download them? Thanks! Robin Ge Aventis Pharmaceuticals Inc. Bridgewater, NJ From jeff at bioinformatics.org Mon Jul 16 19:24:36 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: download References: Message-ID: <3B5377B4.62DC063E@bioinformatics.org> Robin.Ge@aventis.com wrote: > > I don't have CVS on my unix machine. Can you give the ftp site for me > to download them? Hi Robin. Zipped archives of the CVS module are placed in FTP nightly: ftp://bioinformatics.org/pub/piper/CVS/ Along with Overflow: ftp://bioinformatics.org/pub/Overflow/CVS/ Please note that Piper may or may not compile, depending on the setup of your own system. In any case, please let us know what happens. Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From valj01 at gel.usherb.ca Mon Jul 16 22:22:17 2001 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: download References: <3B5377B4.62DC063E@bioinformatics.org> Message-ID: <3B53A159.FDA12E2B@gel.usherb.ca> > > I don't have CVS on my unix machine. Can you give the ftp site for me > > to download them? I think it would be a good idea to do the same as with Overflow (and many others), that is to have a crontab that takes a snapshot of the code in CVS every day so that anyone can get the latest code. Jean-Marc From jarl at xs4all.nl Tue Jul 17 04:22:28 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: download References: <3B5377B4.62DC063E@bioinformatics.org> Message-ID: <3B53F5C4.1030204@xs4all.nl> I installed Piper on Slackware 8.0 recently, and the biggest problem I had was were the python automake bindings (pyautomake), they requiere autoconf 2.13. New distro's have 2.14 bundled. Good news is that the pyautomake package is dropped and merged into the CVS automake code, so soon this issue is fixed once and for all. Jarl > Please note that Piper may or may not compile, depending on the setup of your > own system. In any case, please let us know what happens. From jarl at xs4all.nl Tue Jul 17 06:16:35 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] DL crash References: <3B5377B4.62DC063E@bioinformatics.org> <3B53F5C4.1030204@xs4all.nl> Message-ID: <3B541083.7070608@xs4all.nl> Hi, I got the new BL code communicating with the DL, which is working fine, but after the two layers have connected, the DL dies: 1 Starting definition layer... 2 Starting pied... 3 ior file: /home/jarl/piper_info/ior/dl2bl.ior 4 Wrote IOR file /home/jarl/piper_info/ior/uil2dl.ior 5 Getting document... 6 error: net LP already existed 7 error: net HP already existed 8 error: net LPC_DECOMP already existed 9 Connecting with the bl... 10 setting up a connection with a unique dl_id... 11 Tue Jul 17 11:59:18 2001 | 224 | Info | Accepted DL, created area 2 12 got dl_id... 13 Loading crash info... 14 no crash info 15 Adding a Network... 16 Document:ShowNetwork 17 Could not contact the dl, it appears not to be started. 18 The dl must be running before the Gnome user interface. I added the numbers in front manually, line 11 mains the BL got a corba call from the DL and all is well, line 12 is the DL saying it got response back from the BL. I tried tracing this by putting some print's in the dl sources, but found nothing because python is a bit confusing to me, could someone say something about this, Jeff? Brad? Any thoughts? Jarl From jarl at xs4all.nl Tue Jul 17 06:27:18 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] DL crash References: <3B5377B4.62DC063E@bioinformatics.org> <3B53F5C4.1030204@xs4all.nl> <3B541083.7070608@xs4all.nl> Message-ID: <3B541306.4030300@xs4all.nl> Hi again, Had another look, and I already found some, it's the BL that's not responding correctly during the DL call 'uri_ids = self.query_ref.programIds()' Working to fix it now... sorry to bring this one up too soon ;) Jarl From jeff at bioinformatics.org Tue Jul 17 09:40:06 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: download References: <3B5377B4.62DC063E@bioinformatics.org> <3B53A159.FDA12E2B@gel.usherb.ca> Message-ID: <3B544036.B4D69A64@bioinformatics.org> Jean-Marc Valin wrote: > > I think it would be a good idea to do the same as with Overflow (and many > others), that is to have a crontab that takes a snapshot of the code in CVS > every day so that anyone can get the latest code. We do! :-) ftp://bioinformatics.org/pub/Overflow/CVS/ Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From jmvalin at locusdialogue.com Tue Jul 17 10:08:08 2001 From: jmvalin at locusdialogue.com (Jean-Marc Valin) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: download References: <3B5377B4.62DC063E@bioinformatics.org> <3B53A159.FDA12E2B@gel.usherb.ca> <3B544036.B4D69A64@bioinformatics.org> Message-ID: <3B5446C8.68A4A286@locusdialogue.com> > > I think it would be a good idea to do the same as with Overflow (and many > > others), that is to have a crontab that takes a snapshot of the code in CVS > > every day so that anyone can get the latest code. > > We do! :-) What I meant is doing this for the Piper CVS... Jean-Marc From jeff at bioinformatics.org Fri Jul 20 07:09:56 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] [Fwd: LWN referenced Piper today] Message-ID: <3B581184.329AA6A2@bioinformatics.org> -------------- next part -------------- An embedded message was scrubbed... From: Michael McLay Subject: LWN referenced Piper today Date: Thu, 19 Jul 2001 12:42:54 -0400 Size: 6360 Url: http://bioinformatics.org/pipermail/pipet-users/attachments/20010720/23c2863c/attachment.mht From jeff at bioinformatics.org Sat Jul 21 09:58:18 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: LWN referenced Piper today References: <01071912425402.02438@fermi.eeel.nist.gov> Message-ID: <3B598A7A.A8F699A1@bioinformatics.org> Hi Michael! Thanks for writing. We apologize for the late reply; several of us are in Denmark for a meeting right now. I'm not the networking guy in the project, Jarl is, so I'll leave some of your points for him to answer. > A quote from one posting[1] suggests you have been considering using XML to > define the GUI interface layout. I also gather from the discussion on the > design of the project that the glue to hold the architecture together is > CORBA and a primary design goal is to manage workflows. Both true. > Managing workflows is a very general problem which also applies to almost any > business activity. This generality is a good thing and makes the technology a > potential foundation for many projects. I'm interested in applying workflow > sotware to business management activities. This generality also means that > many other people are attacking the same problem domain and as a result we > have many projects solving the same problem, with slightly different > approaches and architectures. This presents a problem when trying to select > the appropriate solution and it also makes it very difficult for potential > peers to collaborate if they each choose different base technologies. Yes. Piper is perhaps unique in the field for being rather general-pupose -- not requiring new or specific programs -- among other things. Bur standards are indeed difficult to create and impossible to control or inforce. > There is a second problem. Piper is already the result of several projects > merging, so, as I am sure you are aware, a common problem facing projects > like Piper is that the chances of long term survival are determined by both > the goodness of the design and the momentum behind the project. Projects > with large followings have a higher probability of success, given equally > good architectures. I'm not sure this is a problem. As someone commented to us, the fact that we are merging several smaller projects ensures modularity. Any part of Piper will be swappable for anything else. We actually consider Piper to be a reference for the PiperNet standard, allowing other variations on the Piper theme to be made. > Assuming my summary of Piper is correct I would like to suggest that the > Piper project team might benefit from some of the technology that is > currently under development on the Zope CMF project. I didn't see your email > address on the zope-cmf@zope.org mailing list, so I assume you are not > following that project closely. The CMF architecture is summarized on a Wiki > page[2]. It discuses the plans to convert CMF to use the new Zope component > model. With the recent addition of Workflows to the Zope CMF the amount of > overlap between the Zope project and Piper has become quite significant. We are well aware of Zope, and a few years back we considered using Zope to make Piper (when it was Loci). I think we felt that Zope did more than what we needed and that it would be a large dependency that not everyone would have by default. > The strength of Piper, and a weakness of Zope, is the interactive GUI. The > Zope project has concentrated on the server side. The only GUI for Zope uses > web pages. This works, but it is not appropriate in some situations. > Applications need a custom GUI for daily interactive use or when > visualization requires an interface design that isn't readily represented as > a web page. Consequently, visualizing and designing Zope workflows is very > awkward using the web based interface. I designed the Piper desktop, and I agree with your assessment of Web interfaces. I usually argue that the Web was designed to be a document publication system, not an application GUI builder. I find "scroll up and down" and "flip back and forward" to be inhibitive to any real "work". > What I envision is a grafting of the > Piper interface onto the Zope CMF workflow architecture. > > As you probably know the Zope technology includes many conduits for passing > information into the Zope object store. In addition to HTTP the Zope server > can be manipulated through WebDav, and XML-RPC. The XML-RPC technology is a > lightweight replacement for CORBA. Shifting the Piper architecture from > CORBA based to a XML-RPC looks interesting, but I don't think it would not be > the appropriate approach. There are two problems. The XML-RPC interface has > bandwidth limitations caused by the use of HTTP as the transport protocol. > Each transaction requires reestablishing connections. This isn't appropriate > for a peer to peer networking arrangement. We tried an XML-RPC-like object model at the very beginning. We found it to be VERY SLOW, so we switched to CORBA. So, why does Zope use XML-RPC instead of something like SOAP? > A more appropriate solution for building peer to peer interfaces between Zope > servers would be to add yet another conduit type to Zope. This isn't hard > because Zope was designed to support multiple connection types. Adding the > IETF BEEP framework[3] to Zope is how I envision the architecture evolving. > The BEEP framework was specifically created to build peer to peer protocols. > The Zope workflow interface would be exposed on top of the BEEP framework. > And the Piper user interface would control the Zope workflow interfaces by > connecting to the Zope servers over the BEEP based conduits. It may be possible to do this, since there are some things left unresolved in the Piper Broker. However, I'll leave it up to Jarl to decide if this would mean too much of a change. As I mentioned before, swapping out the Piper Broker for Zope is a possibility. > Tthe use of XML to define the GUI is also a good idea and can be done in the > libglade user interface. The Glade interface builder saves the GUI design as > .glade files. These files are then read into an application by using the > libglade module[4] in Python. The application then associates callbacks > names defined by Glade with the appropriate functions or methods in Python. > This works very nicely for building user interfaces, but the Glade > application sits separate from the application that is built with Glade. Yes, we did get the idea from Glade. We also want to define parameters using something like the HTML "form" tags. We could use Glade to build some interfaces, but it may not be required. We could also use Bonobo. > I > would like to see the Glade application rewritten as a Python module. This > would allow applications to embed a GUI builder into the application. This > way the GUI builder could be aware of the application functions and present > them as options to be automatically associated with the callbacks. That sounds like a good idea :-) Actually, when I asked, they said they had no intention to support Python in Glade :-( > I know this would be another big change for the Piper project participants > and some code would have to be rewritten, but I suspect that the added > momentum behind Zope and the CMF will get the Piper project back to parity > with the current state of the project in a couple months. At that point the > growth of both Piper and Zope-CMF will be greater than if the projects > continue as serparate activities. That's the argument I always make for collaborations, how Piper was formed actually ;-) I think there are some interesting possibilities. I will talk about this with the others here in Copenhagen tonight. Cheers. Jeff From jarl at xs4all.nl Tue Jul 24 16:21:05 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Re: LWN referenced Piper today References: <01071912425402.02438@fermi.eeel.nist.gov> <3B598A7A.A8F699A1@bioinformatics.org> Message-ID: <3B5DD8B1.60808@xs4all.nl> Pipers & Michael, As I was in Denmark too, I didsided to wait till I was home again and could have a look at Zope before I was to reply. No that I dicovered I need to upgrade my python (and a lot of other python packages) I'll only comment on the parts that are not directly related to Zope. Once I finished upgrading Python I'll get back to the other issues. >>A quote from one posting[1] suggests you have been considering using XML to >>define the GUI interface layout. I also gather from the discussion on the >>design of the project that the glue to hold the architecture together is >>CORBA and a primary design goal is to manage workflows. > Both true. True, but one might look at 'workflow' in more than one way. Piper is to handle application workflow. Other systems might specialise to content (Like 'your' CMF, or the firms Yournews.com and Zed.com), or to transportation, like Cisco boxes. But again: I didn't looked at a operational Zope system yet, so excuse me for any wrong assumpsions. >>Managing workflows is a very general problem which also applies to almost any >>business activity. This generality is a good thing and makes the technology a >>potential foundation for many projects. > Yes. Piper is perhaps unique in the field for being rather > general-pupose -- not requiring new or specific programs -- among other > things. Bur standards are indeed difficult to create and impossible to > control or inforce. I like emphasise the fact that Piper is ment to be general, it's not designed to be a system to setup a calculation farm, neither will it be specialised for handling content or to use it as a middleware. Jarl From jeff at bioinformatics.org Wed Jul 25 04:54:35 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] [Fwd: LWN referenced Piper today] Message-ID: <3B5E894B.A23C83FA@bioinformatics.org> -------------- next part -------------- An embedded message was scrubbed... From: Michael McLay Subject: Re: LWN referenced Piper today Date: Mon, 23 Jul 2001 14:10:40 -0400 Size: 7393 Url: http://bioinformatics.org/pipermail/pipet-users/attachments/20010725/71469477/attachment.mht From Nicolas.Chauvat at logilab.fr Wed Jul 25 08:31:33 2001 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Zope + Piper Message-ID: Hi folks, Concerning the recent Zope'n Piper thread, MHO is that it's not quite the same goal. But I'm a strong believer in component-based architectures, especially for free software projects where open-source and GPL code make reuse both possible and interesting. Hence if someone says that there are interesting similarities, it's definitely worth a look. I'm about to start some Zope development for a customer. I'll try to take a moment to look at the CMF at the same time and let you know about my findings. Cheers, -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From jeff at bioinformatics.org Fri Jul 27 23:30:40 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] [Fwd: Answers to both emails are included] Message-ID: <3B6231E0.270C77A7@bioinformatics.org> -------------- next part -------------- An embedded message was scrubbed... From: Michael McLay Subject: Answers to both emails are included Date: Wed, 25 Jul 2001 14:00:45 -0400 Size: 7291 Url: http://bioinformatics.org/pipermail/pipet-users/attachments/20010727/d2e8cc04/attachment.mht From jeff at bioinformatics.org Sat Jul 28 19:22:32 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Microsoft's bait and switch Message-ID: <3B634938.9C734D3B@bioinformatics.org> http://iwsun4.infoworld.com/articles/op/xml/01/07/30/010730oppetreley.xml Jeff From aeoo at myrealbox.com Sun Jul 29 01:30:58 2001 From: aeoo at myrealbox.com (Gold is Heavy) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] need help compiling piper Message-ID: <01072901305801.12721@void2> Hi people, I just went through the compile dance for piper and at the very last moment I hit an unexpected snag. I am using latest CVS sources. My autogen command looks like this: sh autogen.sh --prefix=/opt --with-piperhome=/home/piper \ --with-overflow=/opt/overflow --with-omniorb=/opt/omniORB \ --with-omnilibs=/opt/omniORB/lib/i586_linux_2.0_glibc2.1 It seems to complete without errors. Then, when I run make, I get the following: [...make visiting various boring directories here...] make[5]: Entering directory `/home/aeoo/piper/piper/src/dl/vflow/interfaces' c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/gnome-xml -I/opt/include/python2.1 -I/opt/lib/python2.1/config -fPIC -g -O2 -Wall -Wstrict-prototypes -I/opt/overflow/include -g -O2 -c mod_vflow_wrap.c mod_vflow_wrap.c:469: path.h: No such file or directory mod_vflow_wrap.c:471: UIDocument.h: No such file or directory mod_vflow_wrap.c:472: UINetwork.h: No such file or directory mod_vflow_wrap.c:477: UINetwork.h: No such file or directory mod_vflow_wrap.c:478: UIDocument.h: No such file or directory mod_vflow_wrap.c:479: UINode.h: No such file or directory mod_vflow_wrap.c:480: UITerminal.h: No such file or directory mod_vflow_wrap.c:481: UILink.h: No such file or directory mod_vflow_wrap.c:482: UINetTerminal.h: No such file or directory mod_vflow_wrap.c:485: UINetTerminal.h: No such file or directory mod_vflow_wrap.c:486: UITerminal.h: No such file or directory mod_vflow_wrap.c:487: UINode.h: No such file or directory mod_vflow_wrap.c:488: UINetwork.h: No such file or directory mod_vflow_wrap.c:490: UINode.h: No such file or directory mod_vflow_wrap.c:491: UINetwork.h: No such file or directory mod_vflow_wrap.c:492: UITerminal.h: No such file or directory mod_vflow_wrap.c:493: UIDocument.h: No such file or directory mod_vflow_wrap.c:494: UILink.h: No such file or directory mod_vflow_wrap.c:497: UINodeParameters.h: No such file or directory mod_vflow_wrap.c:498: UINode.h: No such file or directory mod_vflow_wrap.c:499: UINetwork.h: No such file or directory mod_vflow_wrap.c:500: UIDocument.h: No such file or directory make[5]: *** [mod_vflow_wrap.o] Error 1 [...make leaving all the directories...] Any ideas? I am running on a Libranet 1.9.0 system, which is basically a Debian Potato system that I have dist-upgraded recently. I have also installed a bunch of stuff in /opt, like Python 2.1.1, omniORB, and anything else that is not supplied by potato to my liking (or that doesn't fulfill the build requirement). I really like the concept of piper. I've looked through the slides and some other docs on the site. My only ob-gripe is that piper has too many dependencies, and I am not sure if I like its heavy use of CORBA. Of course these are very preliminary opinions that are liable to change as I learn more, and I would really have to do a lot of learning to understand it thoroughly. But for now I would just like to compile it :). Thank you, --Leo From jarl at xs4all.nl Sun Jul 29 07:06:02 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> Message-ID: <3B63EE1A.3090800@xs4all.nl> > mod_vflow_wrap.c:494: UILink.h: No such file or directory > mod_vflow_wrap.c:497: UINodeParameters.h: No such file or directory > mod_vflow_wrap.c:498: UINode.h: No such file or directory > mod_vflow_wrap.c:499: UINetwork.h: No such file or directory > mod_vflow_wrap.c:500: UIDocument.h: No such file or directory Did you install Overflow, at least version 0.5.0? From valj01 at gel.usherb.ca Sun Jul 29 11:16:46 2001 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <3B63EE1A.3090800@xs4all.nl> Message-ID: <3B6428DE.43602D4B@gel.usherb.ca> > Did you install Overflow, at least version 0.5.0? Also if you download Overflow 0.5.1 RPMS, the default path is /usr instead of /opt/overflow so you'll need to change some options. Jean-Marc From aeoo at myrealbox.com Sun Jul 29 14:06:20 2001 From: aeoo at myrealbox.com (Gold is Heavy) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] need help compiling piper In-Reply-To: <3B63EE1A.3090800@xs4all.nl> References: <01072901305801.12721@void2> <3B63EE1A.3090800@xs4all.nl> Message-ID: <01072914062000.26234@void2> On Sunday 29 July 2001 07:06, you wrote: > > mod_vflow_wrap.c:494: UILink.h: No such file or directory > > mod_vflow_wrap.c:497: UINodeParameters.h: No such file or directory > > mod_vflow_wrap.c:498: UINode.h: No such file or directory > > mod_vflow_wrap.c:499: UINetwork.h: No such file or directory > > mod_vflow_wrap.c:500: UIDocument.h: No such file or directory > > Did you install Overflow, at least version 0.5.0? Yes, I installed everything from CVS, so I assume that it's the very latest. It is indeed in /opt/overflow, I just checked. In fact, I can run some overflow programs from /opt/overflow/bin, like vflow. gflow crashes as soon as I start it. And I see all the includes now, in /opt/overflow/include/overflow. Maybe I can make it compile now :). Ok, looking carefully at config.status and noticing s%@overflowdir@%/opt/overflow%g So, it looks like the dir is set correctly, but make still gives the same error. Trying: void2:/opt/overflow# mv include/ include-overflow void2:/opt/overflow# ln -s include-overflow/overflow include Aha! I don't get the same error anymore. Looks like /opt/overflow/include/overflow was wrongly created. The last "overflow" dir is superfluous. Ok, got an error saying that omniidl cannot be found. Oops, forgot to set my omniORB environment. Aha, looks like I also forgot to copy omni/include dir to /opt/omniORB. Alright, now it's compiling much further. Now I have to install panel-applet-dev package. Ok, it goes further. Bang, now I get this error: c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/include -I../include -I/opt/omniORB/include -g -ggdb -D__x86__ -D__linux__ -Wall -I../src -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/opt/overflow/include -I/usr/include/gnome-xml -g -O2 -c plugin_sensor_PL_main.c In file included from /opt/overflow/include/rc_ptrs.h:31, from /opt/overflow/include/Object.h:7, from /opt/overflow/include/ParameterSet.h:8, from plugin_sensor_PL_main.c:15: /opt/overflow/include/BaseException.h: In method `ExceptionStack::~ExceptionStack()': /opt/overflow/include/BaseException.h:109: warning: comparison between signed and unsigned /opt/overflow/include/BaseException.h: In method `void ExceptionStack::print(ostream & = cerr)': /opt/overflow/include/BaseException.h:112: warning: comparison between signed and unsigned /opt/overflow/include/BaseException.h: In method `void ExceptionStack::freeze()': /opt/overflow/include/BaseException.h:118: warning: comparison between signed and unsigned In file included from /opt/overflow/include/ParameterSet.h:8, from plugin_sensor_PL_main.c:15: /opt/overflow/include/Object.h: At top level: /opt/overflow/include/Object.h:156: warning: `class _ObjectFactory' has virtual functions but non-virtual destructor In file included from /opt/overflow/include/ObjectRef.h:8, from plugin_sensor_PL_main.c:16: /opt/overflow/include/net_types.h:247: type/value mismatch at argument 1 in template parameter list for `template TypeTraits' /opt/overflow/include/net_types.h:247: expected a type, got `String' /opt/overflow/include/net_types.h:247: explicit specialization of non-template `{anonymous struct}' /opt/overflow/include/net_types.h:247: anonymous class type not used to declare any objects make[4]: *** [plugin_sensor_PL_main.o] Error 1 Doing cvs update on Overflow and piper; there is nothing new. --Leo From jarl at xs4all.nl Sun Jul 29 16:09:44 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:21 2006 Subject: [Pipet Users] Comments to Zope References: <3B5EBB1E.BCD4132B@bioinformatics.org> <0107251400450I.02438@fermi.eeel.nist.gov> Message-ID: <3B646D88.70800@xs4all.nl> Hi, I still have a hard time understanding the scope of Zope. I've been playing a bit with the web interface, and looked at some code. So far I understand Zope has a singel network consisting of Zope Objects. Or is there more going on, are there any other 'node type' in Zope, or hiarchic structures of some kind? Also I cant find how the functionality of the 'nodes' in Zope is arranged. Is it all done by the ExtensionClass? And what limit's are there in the functionality that can be plugged into the Zope objects? About the security model so far I got the impression Zope is handling access control by a very long and specific rules list, like in Zope-2.4.0-src/lib/python/AccessControl. The access system compared to that of Piper is way more detailed and differnent because it's 'node' oriented, and that of Piper being 'area' oriented. Has Zope an equivalent like groups? Also Piper does not manage the acccess between nodes in a singel execution zone. Can access control be disabled on induvidual node level? > Perhaps you could give some concrete examples of how you envision Piper being > used. Also, how does Piper interact with information access control > mechanisms of other systems? Piper enhances communication channels like unix pipe to the extend so that networks of functional units can be build. Piper is focussed on of-the-shelf technology, being already availeble tools. CLI tools are the main target, but this can eventualliy grow to scripting or other application types. Point is that Piper offers channels. The new thing about Piper is that it isn't limited to 2-way pipes: multi connectivity, filtering, execution zones for security, marchalling, management user interface API, etc. All that is needed to make network based execution is supplied. Piper aims to be 'general' in not dictating any format to the functional units (applications ea), it just transports the datastream. Functional units can receive or send data, that's basically all that Piper is about. Out a uses's perspective Piper is a management interface that lets you arrange the set of available units in a network with unlimited connectivity. The strenght of Piper is that it offer network execution, where (unix) shells offer sequential execution, GUI's 2D execution and schedulars (CA7) event based execution. > XML-RPC ftp, SOAP, and WebDAV. I expect that the BEEP based Python module > will also be added to the Zope server eventually. That addition will make it > much easier to build a peer to peer interface to Zope. BEEP looks like being a good candidate for a protocol for communication between instances of Piper. Shame there is no C implementation yet. (?) More next time ;) Jarl From valj01 at gel.usherb.ca Sun Jul 29 23:08:42 2001 From: valj01 at gel.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <3B63EE1A.3090800@xs4all.nl> <01072914062000.26234@void2> Message-ID: <3B64CFBA.B0210B98@gel.usherb.ca> > It is indeed in /opt/overflow, I just checked. In fact, I can run some > overflow programs from /opt/overflow/bin, like vflow. gflow crashes as soon > as I start it. And I see all the includes now, in > /opt/overflow/include/overflow. Maybe I can make it compile now :). Since version 0.5.0, the Overflow include dir changed from $prefix/include to $prefix/include/overflow. The reason for that is that it is now possible to set $prefix to /usr without getting tons of includes into /usr/include (which then causes problems when you want to install a newer version). This normally shouldn't have broken the build if it was setup correctly. There is a shell script called overflow-config (it works the same way as gnome-config) that should return the right flags to put with Overflow. For example: 'overflow-config libflow --cflags' outputs: -I/home/jm/maitrise/install/include/overflow That way, whenever the directories change things keep working. > panel-applet-dev package. Ok, it goes further. Bang, now I get this error: > > c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/include -I../include > -I/opt/omniORB/include -g -ggdb -D__x86__ -D__linux__ -Wall -I../src > -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include > -I/usr/X11R6/include -I/usr/include/glib-1.2 -I/usr/lib/glib/include > -I/opt/overflow/include -I/usr/include/gnome-xml -g -O2 -c > plugin_sensor_PL_main.c > In file included from /opt/overflow/include/rc_ptrs.h:31, > from /opt/overflow/include/Object.h:7, > from /opt/overflow/include/ParameterSet.h:8, > from plugin_sensor_PL_main.c:15: > /opt/overflow/include/BaseException.h: In method > `ExceptionStack::~ExceptionStack()': > /opt/overflow/include/BaseException.h:109: warning: comparison between signed > and unsigned > /opt/overflow/include/BaseException.h: In method `void > ExceptionStack::print(ostream & = cerr)': > /opt/overflow/include/BaseException.h:112: warning: comparison between signed > and unsigned > /opt/overflow/include/BaseException.h: In method `void > ExceptionStack::freeze()': > /opt/overflow/include/BaseException.h:118: warning: comparison between signed > and unsigned > In file included from /opt/overflow/include/ParameterSet.h:8, > from plugin_sensor_PL_main.c:15: > /opt/overflow/include/Object.h: At top level: > /opt/overflow/include/Object.h:156: warning: `class _ObjectFactory' has > virtual > functions but non-virtual destructor > In file included from /opt/overflow/include/ObjectRef.h:8, > from plugin_sensor_PL_main.c:16: > /opt/overflow/include/net_types.h:247: type/value mismatch at argument 1 in > template parameter list for `template TypeTraits' > /opt/overflow/include/net_types.h:247: expected a type, got `String' > /opt/overflow/include/net_types.h:247: explicit specialization of > non-template `{anonymous struct}' > /opt/overflow/include/net_types.h:247: anonymous class type not used to > declare > any objects > make[4]: *** [plugin_sensor_PL_main.o] Error 1 This problem is quite odd and I haven't figured out why it works on some machines and not on others. What compiler are you using? For now, you can safely comment line 247 in /opt/overflow/include/net_types.h and things are still going to work. Jean-Marc From chapmanb at arches.uga.edu Mon Jul 30 05:15:54 2001 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper In-Reply-To: <3B64CFBA.B0210B98@gel.usherb.ca> References: <01072901305801.12721@void2> <3B63EE1A.3090800@xs4all.nl> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> Message-ID: <15205.9674.71276.259825@taxus.athen1.ga.home.com> Jean-Marc: > Since version 0.5.0, the Overflow include dir changed from > $prefix/include to $prefix/include/overflow. [...] > This normally shouldn't have broken the build if it was > setup correctly. There is a shell script called overflow-config > (it works the same way as gnome-config) that > should return the right flags to put with Overflow. The Piper build doesn't use this script since overflow-config wasn't around when I originally wrote the autoconf stuff; so this would explain why the build breaks currently. I can probably blindly add the overflow-config stuff into the piper build if ya'll want me to, but it might be better for someone to do it who is building the code all of the time so that nothing gets messed up. Brad From jarl at xs4all.nl Mon Jul 30 06:31:49 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <3B63EE1A.3090800@xs4all.nl> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> <15205.9674.71276.259825@taxus.athen1.ga.home.com> Message-ID: <3B653795.3050201@xs4all.nl> > The Piper build doesn't use this script since overflow-config > wasn't around when I originally wrote the autoconf stuff; so this > would explain why the build breaks currently. > > I can probably blindly add the overflow-config stuff into the piper > build if ya'll want me to, but it might be better for someone to do it > who is building the code all of the time so that nothing gets messed > up. I'll do this, because it probably fixes some errors I got because I'm compiling against the old Overflow includes for some time now, and that could explain some problems I have. Jarl From aeoo at myrealbox.com Mon Jul 30 07:03:34 2001 From: aeoo at myrealbox.com (Gold is Heavy) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper In-Reply-To: <3B64CFBA.B0210B98@gel.usherb.ca> References: <01072901305801.12721@void2> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> Message-ID: <01073006355300.01030@void2> On Sunday 29 July 2001 23:08, you wrote: > > /opt/overflow/include/net_types.h:247: type/value mismatch at argument 1 > > in template parameter list for `template TypeTraits' > > /opt/overflow/include/net_types.h:247: expected a type, got `String' > > /opt/overflow/include/net_types.h:247: explicit specialization of > > non-template `{anonymous struct}' > > /opt/overflow/include/net_types.h:247: anonymous class type not used to > > declare > > any objects > > make[4]: *** [plugin_sensor_PL_main.o] Error 1 > > This problem is quite odd and I haven't figured out why it works on some > machines and not on others. What compiler are you using? For now, you can > safely comment line 247 in /opt/overflow/include/net_types.h and things are > still going to work. aeoo@void2:~$ gcc --version 2.95.2 Standard compiler for Debian potato (stable) system. Should I get a new gcc? I commented line 247 in net_types.h and as you said, it did finish compiling. I was then able to finish installing it. But now when I run 'piper' I get this: aeoo@void2:~$ piper Starting processing layer... Starting brokering layer... PL: error in loading shared libraries: libflow-0.5.so: cannot open shared object file: No such file or directory BL: error in loading shared libraries: libflow-0.5.so: cannot open shared object file: No such file or directory Starting definition layer... Starting pied... Default location of the DL2BL IOR file: /home/aeoo/piper_info/ior/dl2bl.ior Wrote IOR file /home/aeoo/piper_info/ior/uil2dl.ior Getting document... omniORB: Caught an unexpected Python exception during up-call. Traceback (most recent call last): File "/home/piper/dl/modules/dl2uilserver.py", line 81, in addDocument temp_locus = TempCompositeLocus(self.commit_queue) File "/home/piper/dl/modules/compositelocus.py", line 440, in __init__ toolboxes = os.listdir(BASE_TB_DIR) OSError: [Errno 2] No such file or directory: '/opt/overflow/toolbox' Traceback (most recent call last): File "startpied.py", line 180, in ? pied_gnome = PiedGnome() File "startpied.py", line 161, in __init__ new_document = dl_connection.addDocument(client_obj, view_obj) File "/home/piper/uil/pied/modules/UIL2DL_idl.py", line 1052, in addDocument return _omnipy.invoke(self, "addDocument", _0_piper.UIL2DL.DlServer._d_addDocument, args) omniORB.CORBA.UNKNOWN: Minor: 0, Completed: COMPLETED_MAYBE. aeoo@void2:~$ shutting down DL... cat: /home/aeoo/piper_info/pids/BL.pid: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec] terminating DL... shutting down DL... Exception in thread uil_orb: Traceback (most recent call last): File "/opt/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/home/piper/dl/modules/dlmain.py", line 248, in run self.dl_server.clean_up(0) File "/home/piper/dl/modules/dl2uilserver.py", line 198, in clean_up os.unlink(pidfilename) OSError: [Errno 2] No such file or directory: '/home/aeoo/piper_info/pids/DL.pid' But, aeoo@void2:~$ ls -l /opt/overflow/lib/libflow-0.5.so -rwxr-xr-x 1 root root 28205779 Jul 29 00:26 /opt/overflow/lib/libflow-0.5.so and aeoo@void2:~$ find /opt/overflow/ -type d| grep toolbox /opt/overflow/share/overflow/toolbox So, I am not sure what is wrong? Any ideas? --Leo From jarl at xs4all.nl Mon Jul 30 07:21:24 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> <01073006355300.01030@void2> Message-ID: <3B654334.1010709@xs4all.nl> Hi, CVS now contains the new compilation files that make use of Overflow's overflow-config script. About the running problems: > 2.95.2 > Standard compiler for Debian potato (stable) system. Should I get a new gcc? I use gcc 2.95.3 with is the latest, and it has the same problem with Oveflow. > PL: error in loading shared libraries: libflow-0.5.so: cannot open shared Overflow isn't installed correctly, you should get libflow listed in a ldconfig -p dump. When it isn't there , the system (linux) can not find the library, and so cant any application. That's why 2 of the 4 layers of Piper wont run for you, and you'll have the other 2 not working too ;) Jarl From jeff at bioinformatics.org Mon Jul 30 10:36:23 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> <01073006355300.01030@void2> <3B654334.1010709@xs4all.nl> Message-ID: <3B6570E7.D22997DC@bioinformatics.org> > > PL: error in loading shared libraries: libflow-0.5.so: cannot open shared > > Overflow isn't installed correctly, you should get libflow listed in a > ldconfig -p dump. When it isn't there , the system (linux) can not find > the library, and so cant any application. I've been getting the same error recently, and I think I have Overflow installed correctly. This is what I do to temporarily resolve the problem: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/overflow/lib Cheers. Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From jean-marc.valin at infospace.com Mon Jul 30 13:00:47 2001 From: jean-marc.valin at infospace.com (Jean-Marc Valin) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> <01073006355300.01030@void2> <3B654334.1010709@xs4all.nl> <3B6570E7.D22997DC@bioinformatics.org> Message-ID: <3B6592BF.E1F1522B@infospace.com> > I've been getting the same error recently, and I think I have Overflow > installed correctly. This is what I do to temporarily resolve the problem: > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/overflow/lib I think the -rpath option should be used when linking Piper to libflow.so, so it can be found automatically (of course, you can use LD_LIBRARY_PATH as Jarl suggested). There is now another option: installing Overflow with --prefix=/usr. I originally strongly recommeded not to usr /usr or /usr/local, but since 0.5.1 it is OK (and recommended). This is why I absolutly needed to move the includes so they don't end up all in /usr/include (and cause problems with the next compilation). By configuring with --prefix=/usr, you get all the executables in /usr/bin and libflow in /usr/lib, the includes in /usr/include/overflow and the rest in /usr/share/overflow. Jean-Marc From jarl at xs4all.nl Mon Jul 30 16:44:52 2001 From: jarl at xs4all.nl (Jarl van Katwijk) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> <01073006355300.01030@void2> <3B654334.1010709@xs4all.nl> <3B6570E7.D22997DC@bioinformatics.org> Message-ID: <3B65C744.3040303@xs4all.nl> This is what is mean by 'not being installed correctly' :) The installed stuff has to be available to the system at all in order to be installed. You can also edit /etc/ld.so.conf > I've been getting the same error recently, and I think I have Overflow > installed correctly. This is what I do to temporarily resolve the problem: > > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/overflow/lib From jeff at bioinformatics.org Mon Jul 30 16:50:06 2001 From: jeff at bioinformatics.org (J.W. Bizzaro) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper References: <01072901305801.12721@void2> <01072914062000.26234@void2> <3B64CFBA.B0210B98@gel.usherb.ca> <01073006355300.01030@void2> <3B654334.1010709@xs4all.nl> <3B6570E7.D22997DC@bioinformatics.org> <3B65C744.3040303@xs4all.nl> Message-ID: <3B65C87E.BC8EE491@bioinformatics.org> Jarl van Katwijk wrote: > > This is what is mean by 'not being installed correctly' :) The > installed stuff has to be available to the system at all in order to be > installed. You can also edit /etc/ld.so.conf What is Overflow or the compiler supposed to do so that the user doesn't have to make these changes? Jeff -- J.W. Bizzaro jeff@bioinformatics.org Director, Bioinformatics.org http://bioinformatics.org/~jeff "As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin -- From aeoo at myrealbox.com Tue Jul 31 11:05:20 2001 From: aeoo at myrealbox.com (Gold is Heavy) Date: Fri Feb 10 19:39:22 2006 Subject: [Pipet Users] need help compiling piper In-Reply-To: <3B654334.1010709@xs4all.nl> References: <01072901305801.12721@void2> <01073006355300.01030@void2> <3B654334.1010709@xs4all.nl> Message-ID: <01073111052000.12548@void2> On Monday 30 July 2001 07:21, you wrote: > Overflow isn't installed correctly, you should get libflow listed in a > ldconfig -p dump. When it isn't there , the system (linux) can not find > the library, and so cant any application. Did that. Then I also had to symlink /opt/overflow/share/overflow/toolbox to /opt/overflow/toolbox. And then I got this error: aeoo@void2:~$ piper Starting processing layer... Starting brokering layer... Starting definition layer... Starting pied... Message: Piper BL 0.4.0pre10 wrote IOR file /home/aeoo/piper_info/ior/bl2pl.ior Loading plugin /opt/lib/libplugin_sensor_DL.so... OK. Loading plugin /opt/lib/libplugin_sensor_PL.so... OK. Loading plugin /opt/lib/libplugin_sensor_localhost.so... OK. Loading plugin /opt/lib/libplugin_sensor_syslogd.so... bind, suspending inet OK. Loading plugin /opt/lib/libplugin_visual_DL.so... OK. Loading plugin /opt/lib/libplugin_visual_PL.so... OK. Loading plugin /opt/lib/libplugin_visual_devel.so... OK. Loading plugin /opt/lib/libplugin_visual_festival.so... OK. Loading plugin /opt/lib/libplugin_visual_localhost.so... OK. Loading plugin /opt/lib/libplugin_visual_statusbar.so... OK. Loading configuration REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. activating DL plugin sensor activating PL plugin sensor ** WARNING **: Error 2 during file open activating Localhost plugin sensor activating Syslogd plugin sensor activating DL plugin visual activating PL plugin visual activating visual SCRATCH MO activating visual Festival MO activating visual LOCALHOST MO REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. REDEFINE conflict, an existing relation is redefined. Default location of the DL2BL IOR file: /home/aeoo/piper_info/ior/dl2bl.ior Wrote IOR file /home/aeoo/piper_info/ior/uil2dl.ior Getting document... Toolbox load error: /opt/overflow/share/overflow/lib/audio_blocks.tlb: undefined symbol: __ti6Object Could not contact the dl, it appears not to be started. The dl must be running before the Gnome user interface. aeoo@void2:~$ MDO 37962 is allowed to access MO pipeLine_MO Filled MDO dataDescription with MO->dataDescription Localhost plugin sensor passes data to pipeline Warning: MDO 17767 with datadescription localhost plugin sensor is not allowed to MO Syslogd plugin collector with datadescription Syslogd plugin sensor MDO 17767 with datadescription localhost plugin sensor is allowed to MO Localhost plugin collector with datadescription localhost plugin sensor MDO 17767 is allowed to access MO Localhost plugin collector pipeLine_MO passes data to Localhost plugin collector with 0 childs non-threaded Warning: MDO 17767 with datadescription localhost plugin sensor is not allowed to MO PL plugin collector with datadescription PL plugin sensor Warning: MDO 17767 with datadescription localhost plugin sensor is not allowed to MO DL plugin collector with datadescription DL plugin sensor And nothing came up. That daemons kept spinning and spitting out messages, and I had to run killall to get rid of them. --Leo