Re: [PD] error: maximum object loading depth 1000 reached (was: pduino patches on pdx)

2012-04-16 Thread Roman Haefeli
On Sun, 2012-04-15 at 19:45 -0400, Hans-Christoph Steiner wrote:
 On Apr 13, 2012, at 3:44 AM, Roman Haefeli wrote:
 
  On Thu, 2012-04-12 at 17:52 +0200, Roman Haefeli wrote:
  On Wed, 2012-04-11 at 22:49 -0400, Hans-Christoph Steiner wrote:
  It would affect vanilla if you have the libdir loader running in it.  Its 
  related to that.
  
  I think I experienced once also problem with maximum object loading
  depth 1000 reached and this was on Pd-vanilla without libdir. So
  probably there is still a problem outside of libdir?
  
  I'll post again, when I figured out how to exactly reproduce the
  situation.
  
  This also triggers the same error, although this is with a binary
  external and with no libdir involved:
  
  [declare -stdpath extra/iemnet]
  
  [tcpclient] - works fine
  [iemnet/tcplient] - triggers error from subject
  
  
  Why is that?
  
  Roman
 
 The depth 1000 error is completely separate from libdir.

Yes, that is why I said in the above example there is _no_ libdir loader
involved.

   It is caused by when you try to load an object, and Pd can load the
 files, but can't find a setup() function mapped to the classname. 

Aha, thanks for the explanation. 

But why is it, that [iemnet/tcpclient] works fine without having the
above [declare] statement in the patch, but fails with maximum depth
reached when there is a such statement? 
Sounds like a bug in [declare], but is it really?

Roman



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] how to debug tcpsocketserver?

2012-04-16 Thread Roman Haefeli
On Sat, 2012-04-14 at 15:28 +0200, rolf wrote:
 hello roman,
 
  May I ask what is your reasoningu behind your use of [tcpsocketserver]
  over [tcpserver]?
  
 it's my first try at using network objects inside Pd.
 the communication is between Pd patches, doable with FUDI.
 (it took me some time to find out that FUDI is not some mysterious
 protocol but about Pd messages).
 
 because i have a number of clients [tcpsocketserver] seemed the right
 choice, for the reasons you mention yourself.

Ah, ok. Just to be sure ;-)

 
  It's not possible to handle packet oriented protocols correctly with
  plain [tcpserver], since you might receive packets from different
  clients interleaved. That is why [tcpsocketserver] was written.
  
 
 actually, i'm slowly developing the Pd-clients and how to 'conduct' 10
 or more live, so for the moment sticking to a one-sided server-broadcast
 communication, which can do with [tcpserver].

Actually, if you want a FUDI server, there is already [netserver] from
maxlib. It should work for most cases. AFAIK, maxlib is not actively
maintained anymore and I had a problem with [netserver], because it is
relatively easy to make it block Pd, as it is not threaded at all. That 
is why wrote [tcpsocket.FUDI], which can be used with [tcpserver].

Regarding your initially posted problem with not receiving all messages
from your clients, I might only be able to help you with more
information (How are you creating the FUDI messages? Are they properly
delimited? etc.). The packet delimiter of [tcpsocket.FUDI] is pretty
simple: It waits for a semicolon (';', ascii 59) and flushes its buffer,
when it receives one. So you need to make sure, that your packets really
are delimited by semi-colons (and not commas or new-line-only).

 my problem with tcpsocketserver which started this thread is therefore
 momentarily in the waiting room.
 
 trying out the iemnet server like suggested by martin: iemnet is not in
 Pdext.

It is included since Pd-0.43-extended.

Roman



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] two new strings in Pd-extended to translate

2012-04-16 Thread Hans-Christoph Steiner

I think Transifex only checks the git once a day, it looks like it updated it 
today at 8:42am Eastern, so about two hours ago.

As for the empty string, that seems to be related to the header.  The gettext 
tools seem to create it.  Obviously no need to translate ;)

.hc

On Apr 16, 2012, at 3:45 AM, Lorenzo Sutton wrote:

 
 Hi Hans,
 
 I did it (with a few other untranslated strings) for Italian however I didn't 
 find Reset to Defaults... The Transifex interface presents an empty string 
 between Autotips and Pd-extended, maybe it was meant to be there?
 Lorenzo.
 
 On 16/04/12 05:13, Hans-Christoph Steiner wrote:
 As of tomorrow's build, there are two new strings to translate in the 
 Preferences:
 
 - Real-time scheduling (originally was Defeat real-time scheduling)
 
 - Reset to Defaults
 
 Update them in Transifex if you want them translated in your localization:
 https://www.transifex.net/projects/p/puredata/resource/templatepot/
 
 .hc
 
 
 
 
 The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
 
 
 
 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -  
 http://lists.puredata.info/listinfo/pd-list
 





I have the audacity to believe that peoples everywhere can have three meals a 
day for their bodies, education and culture for their minds, and dignity, 
equality and freedom for their spirits.  - Martin Luther King, Jr.



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pd-extended 0.43 builds for Mac OS X/PowerPC are back

2012-04-16 Thread Epic Jefferson
Great.

On Sun, Apr 15, 2012 at 10:00 PM, Hans-Christoph Steiner h...@at.or.atwrote:


 We now have Mac OS X/PowerPC builds again for Pd-extended 0.43:

 http://puredata.info/downloads/pd-extended/releases/0.43.1

 Thanks to Greg Pond/Sewanee for setting up and hosting the PowerPC build
 machine.

 .hc


 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -
 http://lists.puredata.info/listinfo/pd-list




-- 
www.epicjefferson.com
www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit Org
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] trying to track down a bug: Pd-extended 0.43-1 beta on Oneric 32 bit

2012-04-16 Thread John Harrison
Sorry for the delay on this. I downloaded today's binary build of
Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in gdb.
I still get a segfault when opening/deleting/opening test99.pd as an
abstraction. For your convenience, test99.pd is again attached. Here's the
backtrace:

Program received signal SIGSEGV, Segmentation fault.
outlet_anything (x=0x0, s=0x81c7fc0, argc=2, argv=0x82395d8) at m_obj.c:469
469 m_obj.c: No such file or directory.
 in m_obj.c
(gdb) bt
#0  outlet_anything (x=0x0, s=0x81c7fc0, argc=2, argv=0x82395d8) at
m_obj.c:469
#1  0x00c4c8dc in gem::RTE::Outlet::send(std::string, std::vectorgem::any,
std::allocatorgem::any ) () from
/usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#2  0x00db4443 in pix_image::loaded(unsigned int, imageStruct*,
gem::Properties const) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#3  0x00db57b3 in pix_image::loadCallback(void*, unsigned int,
imageStruct*, gem::Properties const) () from
/usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#4  0x00c37f30 in gem::image::PixImageThreadLoader::done(unsigned int,
void*)
() from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#5  0x00c49996 in gem::thread::SynchedWorkerThread::dequeue() ()
   from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#6  0x00c37bc0 in gem::image::load::poll() ()
   from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#7  0x00db3b6e in pix_image::pix_image(_symbol*) ()
   from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#8  0x00db3ca8 in create_pix_image(_symbol*) ()
   from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux
#9  0x0808027a in pd_typedmess (x=0x80ff880, s=0x81cac20,
argc=optimized out, argv=0xbfffe18c) at m_class.c:795
#10 0x0808631e in binbuf_eval (x=0x824a158, target=0x80ff880, argc=1,
argv=0x83bd270) at m_binbuf.c:767


On Thu, Apr 5, 2012 at 12:39 PM, IOhannes m zmoelnig zmoel...@iem.atwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 2012-04-05 17:35, John Harrison wrote:
  Today's build still fails with same test:
 
  [New Thread 0x1defb70 (LWP 19910)]
  [New Thread 0x2c86b70 (LWP 19911)]
 
  Program received signal SIGSEGV, Segmentation fault.
  outlet_anything (x=0x0, s=0x81c7df0, argc=2, argv=0x82181b8) at
 m_obj.c:469
  469m_obj.c: No such file or directory.
  in m_obj.c
  (gdb) watchdog: signaling pd...
 

 please post a complete backtrace (and turn off realtime mode with -nrt
 when running Pd in gdb)

 fgmasdr
 IOhannes
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk992LwACgkQkX2Xpv6ydvRcxQCgwF+Sdl5QFz4gKUYxlkvsvI6D
 fh8AoJbD8XPHJ8au3fnLW+pPjv4VQzwQ
 =GEzY
 -END PGP SIGNATURE-




test99.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list