GEM-dev September 2005

gem-dev@lists.iem.at

10 participants
18 discussions

Re: [GEM-dev] TextBase class
by Georg Holzmann 21 Sep '05

21 Sep '05

Hallo! > this an implementation detail of [linebreak] ;-) (and linebreak > shouldn't be part of Gem) yes, but then you would have to say in each patch "use that external" etc. - now everything would be in one object (okay, it's a little bit more high level - but easy to use - and you can still use it as it was, with linebreak <= 0 ...) anyway, I don't have the time now to rewrite everything again - so I will leave it as it is for now ... > i'm off for spain now ;-) good luck and have fun ... LG Georg > > _______________________________________________ > GEM-dev mailing list > GEM-dev(a)iem.at > http://lists.puredata.info/listinfo/gem-dev > > -- =%)!:?"Â§<Â§0&-"|>* http://grh.mur.at -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse fÃ¼r Mail, Message, More +++

5 12

glibc pthread_join freezing on sarge using pd/pdp/gem
by B. Bogart 21 Sep '05

21 Sep '05

Hi all again, Time is running out for this machine... After spending some time on debian-glibc it seems they are not convinced that it is pthread crashing on my machine, but something happening in the other threads. So lets get to the tracing... after I manually kill PD this is what I'm seeing in gdb: Program received signal SIGTERM, Terminated. [Switching to Thread 1076308992 (LWP 9384)] 0xffffe410 in __kernel_vsyscall () (gdb) (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4012f288 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x403f7dad in videoV4L::stopTransfer () from /usr/lib/pd/extra/Gem.pd_linux #3 0x403f7f66 in videoV4L::setNorm () from /usr/lib/pd/extra/Gem.pd_linux #4 0x403f3755 in pix_videoNEW::normMess () from /usr/lib/pd/extra/Gem.pd_linux #5 0x403f3f1a in pix_videoNEW::modeMessCallback () from /usr/lib/pd/extra/Gem.pd_linux #6 0x0809ba47 in pd_typedmess () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x00000000 in ?? () #10 0x00000000 in ?? () #11 0x00000000 in ?? () #12 0x00000000 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0xbfffdc30 in ?? () #20 0x00000000 in ?? () #21 0xbfffdc00 in ?? () #22 0xbfffdc20 in ?? () #23 0xbfffe1b8 in ?? () #24 0x0025771c in ?? () #25 0x00000000 in ?? () #26 0x08257628 in ?? () #27 0x00000000 in ?? () #28 0x080eccff in _IO_stdin_used () #29 0x082147b8 in ?? () #30 0x0809cf77 in outlet_anything () #31 0x08250728 in ?? () #32 0x080eccc3 in _IO_stdin_used () #33 0xbfffdc78 in ?? () #34 0x4050244c in ?? () from /usr/lib/pd/extra/Gem.pd_linux #35 0x08250728 in ?? () #36 0xbfffdc60 in ?? () #37 0xbfffdc78 in ?? () #38 0x08257690 in ?? () #39 0x080f73d0 in stderr () #40 0x00000002 in ?? () #41 0x082318e0 in ?? () #42 0x0809cf77 in outlet_anything () #43 0x00000000 in ?? () #44 0x00000000 in ?? () #45 0x08256e48 in ?? () #46 0x00000002 in ?? () #47 0x080f73d0 in stderr () #48 0x0820b558 in ?? () #49 0x082508fc in ?? () #50 0x0809b696 in pd_typedmess () #51 0x404a60cc in GemMan::m_border () from /usr/lib/pd/extra/Gem.pd_linux #52 0x00000000 in ?? () #53 0xbfffdcc8 in ?? () #54 0x40331af1 in GemMan::startRendering () from /usr/lib/pd/extra/Gem.pd_linux Previous frame inner to this frame (corrupt stack?) (gdb) info threads 2 Thread 1146301360 (LWP 9389) 0xffffe410 in __kernel_vsyscall () * 1 Thread 1076308992 (LWP 9384) 0xffffe410 in __kernel_vsyscall () (gdb) thread 2 [Switching to thread 2 (Thread 1146301360 (LWP 9389))]#0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40203fe9 in ioctl () from /lib/tls/i686/cmov/libc.so.6 #2 0x403f7481 in videoV4L::capturing () from /usr/lib/pd/extra/Gem.pd_linux #3 0x4012ee40 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x4020c60e in clone () from /lib/tls/i686/cmov/libc.so.6 This means very little to me, and it sure meant little to the glibc folks. For completness here is the same deal for PDP, which is also crashing with pdp_v4l: Program received signal SIGTERM, Terminated. [Switching to Thread 1076308992 (LWP 9395)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4012f288 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x40294440 in pdp_sdl_setup () from /usr/lib/pd/extra/pdp.pd_linux (gdb) info threads 3 Thread 1109560240 (LWP 9399) 0xffffe410 in __kernel_vsyscall () 2 Thread 1099164592 (LWP 9398) 0xffffe410 in __kernel_vsyscall () * 1 Thread 1076308992 (LWP 9395) 0xffffe410 in __kernel_vsyscall () (gdb) thread 2 [Switching to thread 2 (Thread 1099164592 (LWP 9398))]#0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40130d46 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x402b16fc in pdp_procqueue_flush () from /usr/lib/pd/extra/pdp.pd_linux #3 0x402b7350 in ?? () from /usr/lib/pd/extra/pdp.pd_linux #4 0x00000001 in ?? () #5 0x00000001 in ?? () #6 0x402b7320 in ?? () from /usr/lib/pd/extra/pdp.pd_linux #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x402b1898 in pdp_procqueue_add () from /usr/lib/pd/extra/pdp.pd_linux #10 0x402b7320 in ?? () from /usr/lib/pd/extra/pdp.pd_linux #11 0x40137ff4 in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #12 0x00000000 in ?? () #13 0x007d0f00 in ?? () #14 0x4183e4c8 in ?? () #15 0x4000aaa0 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #16 0x00000002 in ?? () #17 0x4183e490 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x4183ebb0 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x40137ff4 in ?? () from /lib/tls/i686/cmov/libpthread.so.0 #26 0x00000000 in ?? () #27 0x007d0f00 in ?? () #28 0x4183e4c8 in ?? () #29 0x4183e470 in ?? () #30 0x4012ee14 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #31 0x4020c60e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) thread 3 [Switching to thread 3 (Thread 1109560240 (LWP 9399))]#0 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x40203fe9 in ioctl () from /lib/tls/i686/cmov/libc.so.6 #2 0x40294626 in pdp_sdl_setup () from /usr/lib/pd/extra/pdp.pd_linux #3 0x0000000a in ?? () #4 0x40047612 in snd_config_searcha () from /usr/lib/libasound.so.2 #5 0x4020c60e in clone () from /lib/tls/i686/cmov/libc.so.6 Not I am running libc 2.3.5 BUT the above trace contains: #1 0x40130d46 in pthread_cond_wait@@GLIBC_2.3.2 () So looking through here I noticed that /lib/tls/i686/cmov/libpthread.so.0 is what is being used, which says: Native POSIX Threads Library by Ulrich Drepper et al Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Forced unwind support included. And /lib/tls/i686/cmov/libc.so.6 says: GNU C Library stable release version 2.3.5, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.0.2 20050725 (prerelease) (Debian 4.0.1-3). Compiled on a Linux 2.6.13 system on 2005-08-27. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. What I'm confused about it how this libc differs from /lib/libc.so.6: Compiled by GNU CC version 4.0.2 20050725 (prerelease) (Debian 4.0.1-3). Compiled on a Linux 2.6.13 system on 2005-08-27. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. So why is /lib/tls/i686/cmov/libc.so.6 used and not /lib/libc.so.6 ? Anyhow I'm way over my head debugging this so please lend me a hand, what the heck is going on?!?!?! pdp_v4l does not happen to be very similar to pix_video does it? Perhaps based on pix_video? Thanks to all on glibc for at least getting me this far, I hope the gem and PDP developers have a closer look at this. b.

2 2

multitextureTest
by james tittle 07 Sep '05

07 Sep '05

hey ya'll, ...a coupla things here: 1. Iohannes had committed a "fix" to [pix_texture]'s setUpTextureState() that caused me weirdness with non-power of two textures (they came out looking like [pix_refraction], but it didn't affect power of two textures...simple enuff to fix by switch back to GL_CLAMP_TO_EDGE, but it makes me wonder why (...and are...) we correctly setting up textures to begin with? I've since added an assignment to the constructor that automatically sets m_textureType to GL_TEXTURE_RECTANGLE_EXT if defined... 2. attached is a patch that shows how to do multitexture (ie. load two movies and then have them blended by the gpu)...atm, it's just cobbled together with the glWrappers, but it works! I see this being rolled into a [pix_multitexture], which could be responsible for up to 8 textures (depending on gl implementation), and do all sorts of blending/replacing/whatever... ...before I go much further with this, I wanted to know if anyone can figure out why it doesn't work correctly if we try to texture each individual film to it's own [rectangle]: there winds up being a flashing texture on the individual rectangles, but the final multitexture looks fine...it's also interesting that it doesn't seem to work with GL_TEXTURE_RECTANGLE_EXT, but I don't know if this is according to spec or not? ...anyway, lemme know what ya'll think... jamie

1 0

Re: [GEM-dev] TextBase class
by IOhannes m zmoelnig 05 Sep '05

05 Sep '05

Georg Holzmann wrote: > Hallo! > > >>i meant what i always meant: that the text-objects shouldn't do the >>line-breaking (where to break!) themselves; this should be done by the >>[linebreak] object. > > yes, and what is the output of the [linebreak] object? A long symbol, or a > atom list ... this an implementation detail of [linebreak] ;-) (and linebreak shouldn't be part of Gem) i think one single symbol is ok (because of the additional spaces that would be introduced by having a list of symbols) >>the changes that went in, is that the text-objects now can handle >>multi-lined text. > > and how? it just converts the incoming list into a string and then breaks this string at each occuring '\n'; it is pretty much your code, but it doesn't know anything about "maxchar". mfg.a.dr IOhannes i'm off for spain now ;-)

1 0

Re: [GEM-dev] TextBase class
by Georg Holzmann 05 Sep '05

05 Sep '05

Hallo! > ok, i have added your changes to the CVS, but i have kicked out the > line-breaking thing (it just breaks whereever it encounters a "\n" > (ascii 10(dec))) h? I don't understand you - what do you mean with "the line-breaking thing" - these were the only changes i made ... Or do you mean something else ... ? LG Georg > > mfg.a.sdr > IOhannes > > _______________________________________________ > GEM-dev mailing list > GEM-dev(a)iem.at > http://lists.puredata.info/listinfo/gem-dev > > -- =%)!:?"Â§<Â§0&-"|>* http://grh.mur.at -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse fÃ¼r Mail, Message, More +++

2 1

TextBase class
by Georg Holzmann 05 Sep '05

05 Sep '05

Hallo gem-devs! I currently need to display formated text in GEM: I use text2d and need to display a longer text over more lines - so I have to check where I have to make a newline ... I know I can implement that with the pd message system, but it's a little bit hacky and not so dynamic. So I thought about implementing it directly in the TextBase class: e.g.: ////////// // The string to display char **m_theString; ////////// // max. characters pro lines // (if 0 then there will be only 1 line // with as much characters as needed!) int m_maxchar; ////////// // lines of the string int m_lines; with changing m_theString to a double pointer and m_maxchar is the maximum of characters in one line - so I can automatically calculate the nr of lines (m_lines) and display the text dynamically in more lines - and of course if a word doesn't fit into the line anymore it will be put in the next line... So my question, would that be usefull ? (because it's a little bit of work - I would have to modify all the different text objects ...) If not I will simply use a hack, which also would do the job, but maybe this solution could be usefull ... let me know what you think ... Thanks, LG Georg

4 19

finding headers
by Tim Blechmann 04 Sep '05

04 Sep '05

hi all, i've got some problems compiling gem on gentoo ... mostly problems finding headers: libmpeg3.h is located in /usr/include/libmpeg3 avifile.h in /usr/include/avifile-0.7 avformat.h in /usr/include/ffmpeg ... but it fails to compile: filmFFMPEG.cpp: In member function `virtual bool filmFFMPEG::open(char*, int)': /usr/include/ffmpeg/avformat.h:577: error: too few arguments to function `int av_seek_frame(AVFormatContext*, int, int64_t, int)' filmFFMPEG.cpp:145: error: at this point in file filmFFMPEG.cpp: In member function `virtual pixBlock* filmFFMPEG::getFrame()': /usr/include/ffmpeg/avformat.h:577: error: too few arguments to function `int av_seek_frame(AVFormatContext*, int, int64_t, int)' filmFFMPEG.cpp:214: error: at this point in file make: *** [filmFFMPEG.o] Error 1 seems, that i'll stick to my old binary for now ... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk latest mp3: kMW.mp3 http://mattin.org/mp3.html latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/ After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

2 1

more textCoord fun
by B. Bogart 02 Sep '05

02 Sep '05

Hey all, I realized some weirdness with textcoords in my patch the spreads one texture over many geos. My chain looks something like this: [gemhead] [pix_image] [loadbang] [pix_texture]-[mode 0, repeat 1 < [s group] Then there are 40x30 geos each with: [r group] [pix_coordinate] [separator] [square] I've moved separator AFTER pix_coordinate as per cgc's instructions. As far as I know this is odd in Gem, since the pix_coordinate for each square is before the seperator they may interfere? Anyhow When I just this patch the text-cords are all screwed up, (shifted slightly, actually looks like they are doing square texturing when they should be doing rectangular). Even once I send the proper coordinates using my python script. In order to get everything to display right what I need to do is load the patch and then manually reinstanciate the pix_texture (clearing the texture) and then reloading it with pix_image. Actually now that I think of it that is effectively removing the "mode 0, repeat 1" thing. Hmmm, actually I don't need to set "mode 0, repeat 1" now that I put separator after pix_coordinate... Anyhow I answered by own question, maybe someone can enlighten me as to why this is happening. Thanks all. b>

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev September 2005