Re: [Gnash-dev] New Gnash release anytime soon?
On Sat, Sep 16, 2006 at 09:28:00PM +0200, strk wrote: I think we can ship a 0.7.2 before antigrain and the new backend infrastructure. I'd just have: - all warnings removed - 'make check' rule actually do something and fail - working sound streams I guess the last item could be the most time consuming, but having elvis.swf play fine would make things visibily (well, auditably) better. I agree. The newer backend is probably not ready to ship to anyone, but the current version of the plugin is much better than the alpha release, so a new release is probably a good idea. Much of the development of the last months is stablizing, so doing a release now is less of a problem than it would have been a month or so ago. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Release shortlist
strk wrote: On Mon, Oct 02, 2006 at 10:38:21AM -0600, Rob Savoye wrote: I don't think GUI testing will fit in next release, just having the tests under actionscript.all/ and libbase/ all run by make check would be good enough for now. There is no way even simple GUI testing should be in the next release. Other than fixing sound, we should probably hesitate to launch off on any new projects to squeeze into this next release. Once the release goes out, then we can risk destabilizing everything again with alot of development. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Backend redesign done / AGG near completion
Udo Giacomozzi wrote: RS I'll also have to send you the RS copyright assignment form to the FSF, as Gnash is GPL'd. Uhm, what's that? It's the standard assignment to the FSF of your changes. This is required for contributions to a GPL'd program. This only applies to your Gnash changes, and nothing else. I'll go dig up the form and send it to you. Thank you for supporting Free software! We just got Gnash to work on a little ETRAX 100 LX (100 Mhz CPU w/o FPU) with a 320x240 LCD. It's damn slow (as expected) but looks very nice. :-) Really, at 100Mhz. It's still encouraging that it works at all! :-) There is an --enable-renderer=agg switch now. BTW, the old mesh set cache seems to have never been limited and this probably eat up memory. I added a limit in the new design (as originally intended by the author). Ah, good idea. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Backend redesign done / AGG near completion
strk wrote: Just for clarity. It is *not* required by GPL'd programs, just by some GNU packages (not even all). True, but Gnash is a GNU project, and not just GPL'd. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Re: Boost-linkage
Markus Gothe wrote: I think we are using the wrong approach here Rob. Do we really want to *LINK* against boost when building from source. All the the code is in the headers afaik. I think we should look at other projects using boost on this issue, which needs further investigation. I'm new to using Boost too. I believe to use Boost headers and mutexes you have to link against the Boost thread library. I could be wrong, but if it's not needed, why build it ? I'd just as soon not have too much complex configuration code if it's not needed. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: Boost-linkage
Markus Gothe wrote: Looking at pkgsrc, they have splitted the boost-pkg so you can choose just to install the headers (which is actually what I did on IRIX alas compilation fails due to TU-smart pointers)... If you don't link in the boost_thread library, you get undefines from using the headers, so for threading I think we're stuck with this. I just build Boost from source, and it installs in /usr/local/include/boost-1_33_1/. Yeuch... I'm not so sure the Boost developers and me are on the same planet when it comes to portability... While a lot of Boost looks really good, I'm starting to think any of the Boost code that needs a library is going to add a huge mess of configuration options. My current thought for the morning (here I just got up and just made some coffee) is to not use Booth mutexes and threads. For at least these two, we're potentially better off sticking to just using POSIX threads and mutexes. I already have a portable Thread class in libbase, and I'm debating adding a Mutex one, and blowing off Boost for this as overly complex. strk suggested earlier today that we statically link the libgnash* libraries into the binaries which I agree on (and working on modifying the makefiles so they conform to this as we still want the plugin to be a DSO-binary). You can do this by configuring with --disable-shared. Right now the plugin has zero dependencies on any other Gnash libraries, and the plugin *must* be dynamically linked anyway so the browser can load it. Why not just use the shared libraries ? For Gnash, it probably doesn't matter either way, but I'd be curious why. Other than compiling time, I don't really see an advantage to making the Gnash executables statically linked. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Cross-compiling / configure dependency checks
strk wrote: On Fri, Oct 06, 2006 at 09:38:50AM +0200, Hannes Mayr wrote: Another point might be to only check for libraries/headers which are really used and to make the checks dependend from the choosen renderer and gui (why check for X11,SDL,GTK2,KDE/QT if the user has choosen AGG as renderer and framebuffer as GUI?). Yes, I think we should fix this as well, I don't like things like SDL to be linked when not really needed, for example. So far the policy has been to just check every possibly used lib The configuration process for Gnash hasn't been optimized at all as you noticed. Typically with cross configuration you wind up using the --with-*-incl or --with-*-libs at configuration time. Does this not work ? I do agree each package needs a switch as to whether it's needed or not to produce executables for that configuration. (like not needing GTK when doing an SDL build) If we just turn off configure tests, then you're stuck adding the flags by hand to the generated Makefile. The current config macros have a few interdependencies, but I like the idea of not running tests that are unneeded. I'll look into it. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: Boost-linkage
Markus Gothe wrote: Ahh, yes --disable-shared is good. Then we can see unused linkage etc by the binary. Only makes sense for that kind of tasks (and speeding up You can also run ldd on the executable (in */.libs) to see what it actually uses. The main advantage to using static libraries is we'd save the libtool overhead of building both object files for each source file, as the shared ones get built with -fPIC. If we decided to *always* statically link the internal Gnash libraries (which we couldn't do if the plugin still depended on them) is to drop using libtool for all the libraries and executables, and just use $(AR) -rv directly. If the plugin still used libtool, it'd be dynamically linked. I'm still curious why we'd want to do this. If it's a debugging problem, I use libtool --mode=execute gdb gnash, which sets up your debugging environment correctly to find all the right libs. compilation time), so you're probably right then. Might speed up starting time(?), unless we run 'prelink'. However I'll fix the plugin to always be built as a DSO. It could improve startup time, but as also have to load other libraries dynamically (like GTK, or KDE) you'd loose out again. For some systems we'd want to have a fully linked executable, but this would likely only be possible with a SDL or FLTK using AGG configuration. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: Boost-linkage
strk wrote: I just see this as a management thing, if we don't intend to maintain a public API or a versioning scheme for binary compatibility let's just NOT install the 'helper' libraries... Not that anybody seems to notice the libraries, but I can agree to this idea. I don't think we want to offer a public API, but on Debian, it is considered a development package, and there is a special option to install all the Gnash headers. Scary but true... Someday though it is possible folks might want to use Gnash as a Flash rendering library, at least for GPL'd programs. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Backend redesign done / AGG near completion
Udo Giacomozzi wrote: Well, anyway, since you checked in the configure patch but both the renderer and GUI are not yet in CVS: are you having problems with the patch? I wound up going to bed instead of checking in the new files... I've been sick all week. I'll finish up adding the new files this morning (Colorado time). Course they won't compile till all your other changes are checked in, but it's a start. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Backend redesign done / AGG near completion
Udo Giacomozzi wrote: Did that a few moments ago. Awesome, thanks. I'll do an update. I just checked if the OpenGL/SDL backend still works (using the compatibility layer). Strangely it displays the movie upside-down!? Can somebody confirm this? I get the same result when using SDL, it appears oriented correctly when using GTK. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Backend redesign done / AGG near completion
Udo Giacomozzi wrote: I'm having problems compiling the AGG backend: ./configure --enable-renderer=agg --enable-gui=fb --with-agg-incl=/home/indunet/agg-2.4/include/ --with-agg-lib=/home/indunet/agg-2.4/src/ I'm seeing other Gnash developers checking in additional changes to this new code, so you might want to wait a bit to see if it stabilizes shortly. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Backend redesign done / AGG near completion
Udo Giacomozzi wrote: We're making progresses ;) it must have been that 3rd cup of coffee... :-) Now, the include path is supplied instead of the lib path: -L/home/indunet/agg-2.4/include that should be -L/home/indunet/agg-2.4/src (my libagg.a is there) Ah, a typo. I just checked in a fix. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash 0.7.2 release date?
Markus Gothe wrote: Are we going to ship 0.7.2 during next week? That might be pushing it a bit... considering we just added two big dependencies. What I'd like to do is start working towards the release bu not adding any more big changes but bug fixes, and to spend some time tracking down bugs. In a week or two when we're sure it's stable then we can do the actual release. But the next week will tell. So this is a good time to focus on bug fixing, and testing on multiple platforms. There can actually be alot of extraneous work involved in putting a release together, like updating the packaging, the web site, the manual, etc... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] pre-release testing
strk wrote: Some things I think we should fix before release: - ./configure improvements: + exit with error when required deps are not found (last time I checked didn't work for ffmpeg sound and agg renderer) This should work for ffmpeg, but the error message was wrong. (though it was Gstreamer). If AGG is configured, you should get an error from configure. I'll add the one line to ffmpeg to do the same. + exit with an error when an unimplemented gui/renderer is requested, document the working ones at least in gui/README You mean if they specify Cairo, or something other than cairo, opengl, or agg ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] ./configure error
strk wrote:
On Mon, Oct 09, 2006 at 09:03:35AM -0600, Rob Savoye wrote:
I knew the patch was bogus. The problem with these macros is that
the ${ac_cv_path_WHAT_lib} and ${ac_cv_path_WHAT_incl} change meaning
in different places in the code.
The value may change, but the meaning behind it shouldn't. The
${ac_cv_path_WHAT_lib} and ${ac_cv_path_WHAT_incl} should hold the
header flags or the library flags, which for a header is the include
path (usually there is only one) and the library should have the library
names, and a -Lpath if they are installed in a non standard place.
Sometime they include the -I or -L or -l switches, sometimes not.
Some code assumes they are simply paths (when matching against /usr/lib)
and some code assumes they include the switches.
That's just the internal inconsistencies in the scripts themselves.
The only thing matched against /usr/lib should be a local variable, not
the global one.
- rob -
___
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: agg.m4
strk wrote: On Mon, Oct 09, 2006 at 03:05:36PM -0600, Rob Savoye wrote: mmm.. no luck here, doesnt' recognize the forward declaration: You must be on an old compiler. What does gcc -v say ? It works just fine with gcc 4.x on FC5. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: agg.m4
strk wrote: Maybe it takes an explicit AC_TRY_RUN ? It shouldn't be necessary, and the test works like it's supposed to on my Fedora Core 5 and Ubuntu systems. I'm curious as hell why it's broken for you. You should get the proper value for the AGG headers, as if this test fails, it should go through checking all the hardcoded directories in the list. Does that step also fail for you ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] release status
strk wrote: DONE, might need more testing It needs more testing. There was the comment (bug report) from a few days ago than mention issues with the volume of music and sound effects. - involve more tests in `make check'. we'd need a better dejagnu test to run all tests. currently there's a mix of doxygen and automake default testing. this makes Doxygen testing ? I can look into the test cases aborting. I guess a single site.exp file that runs *all* tests and prints a *single* report would be more acceptable. Typically the site.exp file is just a post configuration data file. The test driver is swf_exists.exp, and it was originally only created for the does this class and method test cases, much of which don't do more than this. For a better test driver I'd probably want to wrap an other test cases that use a different style of testing. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] fixes for make distcheck
Patrice Dumas wrote: It contains a controversial change: since the tests in actionscript.all are known to be broken, I removed the directory from SUBDIRS and added it in DIST_SUBDIRS. To make the checks (or make clean) one have to go to the directory and issue the make commands there. All the tests in actionscript.all appear to be working. I just checked in support for make check to run DejaGnu style for all the test suite sub directories. Now typing make check from the testsuite directory does the right thing, and runs all the tests cases. I tweaked the rule so if DejaGNU (the runtest program) isn't installed, it just runs the tests as if they were in a TEST_PROGRAMS variable. Another thing which may be problematic is the redistribution of the Bitstream Vera Fonts in gnash since the fonts licence seems to me to be Where are Bitstream fonts in Gnash ? You mean by the usage of fonts in the various test cases ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Re: make check
strk wrote: mmm, I've seen that tests are build on 'make all', we want them to only be built by 'make check' instead, right ? Was there any problem with that ? I see you fixed this, but yes, the test cases shouldn't be built unless you're executing the check target. The other issue was to have 'make check' continue even when tests in a subdir fails. I worked around this by having 'actionscript.all' be executed last as it is known to contain failures, but... is there a cleaner way ? The traditional way folks do regression testing is to not have the test run stop when there is a FAILure, it just gets logged. When trying to reproduce a specific bug, often the test case(s) in just that directory are run. So my question is... what are your trying to accomplish exactly ? I think what you're saying is you want to see a FAILure right away, and not run all the other test cases by default ? Or just that after running all the test cases, you want to know what the FAILures were ? I can probably make things work however you want to, testing wise, once I know what that is. :-) If it'll help, I'll bring back to life a script I wrote for GCC/GDB testing that analyzes the result files. We had to do this once we got a few hundred thousand test cases because the results were so large you couldn't find problems anymore. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash on OpenEmbedded failed
Bignaux Ronan wrote: I try to package gnash with agg backend and fb gui for openembedded metadistribution building system. My board is arm9 based , and i Cool. I run OpenZaurus on my old Sharp Z5500L. :-) I'd love to see Gnash running on that platform. and i post a bug for the gnash recipe and my bug here : http://bugs.openembedded.org/show_bug.cgi?id=1480 You either need to install zlib, or we need to fix the configure script as it can't find lz. PS to Rob : i've never agreed any licence from Macromedia ;-) Good for you! :-) - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] configure sound by default ?
Right now the default build of Gnash is a GTK-OpenGL frontend with no sound. I'm considering enabling sound by default (which would use SDL-ffmpeg), plus Gnash would have sound enabled by default (-r 3 would be to turn sound off instead of on). Otherwise I have a feeling that after the next release we'll be buried in sound doesn't work emails and bug reports. What do other folks think about this idea ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: make check
strk wrote: Another option would be completely avoiding to descend in the actionscript.all dir for now, since we are not even sure those tests are correct :) The technique we used for the GCC/GDB was the concept of an expected failure, XFAIL, which didn't return an error. Currently dejagnu.h doesn't support xfail for unit testing, I'll add it. We did that so for a release if was only the unexpected failures we cared about. If a bug is fixed, the XFAIL becomes an XPASS, which means you have to remove the xfail test. I'll look at implementing this later today. I actually think it's entirely likely the test case is broken, and not Gnash. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] configure sound by default ?
Bastiaan Jacques wrote: I think we should ideally have a Gnash menu option that allows us to switch audio on and off, which should default to off. (Perhaps Gnash could even remember this user setting in a configuration file.) Anybody feel like a little GUI hacking ? :-) Gnash has support for a config file, and adding a preferences dialog box for all the settings would be very nice for end users. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: make check
strk wrote: This is an excerpt from 'runtest -a -v swf_exists.exp' Is the close result expected ? No, this looks like a merge problem. swf_exists.exp doesn't even barely use expect anymore, I'm using the enhanced local_exec built into DejaGnu as it was giving me more repeatable results. There were timing issues with ptys I noticed on various platforms so I never got the same results twice... bad for a test case. Flash version 5 pid is 25696 -25696 close result is 25696 exp8 0 0 CHILDKILLED SIGHUP hangup output is 18:17:05: Verbose output turned on Very odd. I get something like this: [ stuff deleted ...] Running ../../../../gnash/testsuite/actionscript.all/swf_exists.exp ... Executing test case NetStream.as Executing test case ContextMenu.as Executing test case Selection.as Executing test case NetConnection.as Executing test case test.as [... more stuff deleted...] - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] multiple GUIs
strk wrote: I'd name them gtk-gnash, sdl-gnash, fb-gnash etc. etc. Actually at one point I thought about having Gnash (GTK) slash (SDL), klash (KDE), and and flak (FLTK), but I think that's too confusing for end users. Most people are going to be just installing gnash, and expect it to work as a plugin for Firefox or Konqueror. With this latest change I think we should probably rename klash to also being just gnash if we keep this behavior. There is something to be said for building both the KDE and the GTK plugins though, as anyone building Gnash for a BSD or GNU/Linux distribution will likely have to supply both since users may choose KDE or GNOME at install time. It would be difficult, I think, to force a distribution to build two versions of Gnash, which is what they'll have to do now. Either that or the Konqueror support has to also work with a GTK enabled build of gnash. The rationale is that sometime you really want two or more versions. For example, a framebuffer AND a gtk based gnashes. Also, we know that gtk better integrates into the firefox browser, I have debated adding the code to load the renderer or the GUI support (and other things) as a shared library plugin type of architecture, but not for this release. I may do this in the future though, and also use it for loading ActionScript classes dynamically. This would let people write gnash extensions that would add functionality to the base player, as well as reduce the footprint on an embedded device by only loading what the Flash movie needs. But anyway, this isn't on the immediate TODO list. My question is: should we adjust the build system to allow for multiple GUIs to be built? In effect, this means we would have seperate binaries like Gnash (GTK), Klash (KDE), Slash (SDL), Flash (FLTK), et cetera. I'd actually like to see us use the klash that gets built in gui, instead of plugin/klash. plugin/klash should ideally be only the KDE parts wrappers for the standalone executable. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] configure sound by default ?
Bastiaan Jacques wrote: I'm happy with building sound by default. This is now the default. When I browse the web, though, I think random sounds from Flash advertisements are very annoying, so I would probably have the -r switch default back to 1 locally. I added config file settings, so you can control the sound for the standalone player and the plugin separately. Any command line options to turn sound off override the config file. I'll add something to the manual about these new settings. I think we should ideally have a Gnash menu option that allows us to switch audio on and off, which should default to off. (Perhaps Gnash could even remember this user setting in a configuration file.) I just checked this in, but the sound doesn't actually turn off. It looks like get_sound_handler()-stop_all_sounds() doesn't do what I'd expect. btw, we need a start_all_sounds() too. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] kde.cpp and klash.moc
strk wrote: but klash.moc is not in the reposity. A missing cvs add ? It gets generated by the QT moc tool. There must be a broken Makefile dependency, try make klash.moc. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] kde.cpp and klash.moc
strk wrote: mm... I see the klash.moc.in but it's under plugin, while the file I'm referring to is in gui/... Do we have duplicated code ? Nope, just not 100% moved from one directory to where it should be. If you don't have moc installed, it should link to the default one, which didn't get moved yet. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: make check
strk wrote: XFAIL: XFAILED: expected: 7,7,7,7,7,8,8,8,9,200,200,200,200,551,551 obtained: (line truncated) Sounds as a missing stop at newline expression in the regexps ? Those should be normalized... Hum... It works for me on Fedora Core 5 and Ubuntu, but this is the regexp line where it extracts the message from the test run log file. Try doing a puts $outp, and see if it has a newline after the line number that appears in brackets before the next timestamp. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Online flashplayer testing
Tomas Groth wrote: Tonight we had a discussion on IRC about online testing of flashplayers (like gnash) using our testcases, and we more or less came up with a structure on how this should work. The idea is simple: We create a testpage which automaticly loads the testcases, and report any errors to a database. We have a server for a developer's site, I can give you access, and we can set this up there. I have the rest of the site mostly all setup otherwise. That would be the likely place for this. It's got MySQL, PHP, Apache, all the usual Redhat Enterprise 4 has. We're using Drupal and MediaWiki. I'm curious how you're going to connect the test page with Gnash though... or are you just going to have Gnash connect directly to the database ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] ffmpeg vs libmad
I think for the release we might want to use libmad, instead of ffmpeg. While testing on various platforms, I found out on Ubuntu this brought in a bunch of dependencies, vorbisenc, libgsm, and theora. I added code to ffmpeg.m4 to handle this, but thought maybe we should just make libmad the default for this release just to simplify the installation. I'm flexible, so I thought I'd see what others think. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Porting to Win32...
Markus Gothe wrote: Seem like todays patches broke a lot of stuff and compilers complaining... Yep. CVS doesn't even build for me at all anymore, with multiple errors. I am very glad to see this gets checked in, but it also blew whatever chance we had to do a new release in the near term time frame. Please give the rest of us a heads up before checking in such major changes. Several of us have been holding some code back till after the release, which now is probably a moot point. If I had known this was coming, I'd have made a quick release branch to get 0.7.2 out the door first. I'm still glad to have video support finally, so thanks for implementing this feature. But please next time let us know what's up before such a major checkin. Now we also need to make this work with AGG. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] release branch
I just made a release branch tagged with release_0_7_2. You can change a checked out source tree to this branch with cvs update -r release_0_7_2 or check it out using cvs checkout -r release_0_7_2 gnash This is basically a snapshot from Thursday. I probably would have done this Thursday anyway it I hadn't gotten stuck traveling in the blizzard. The snapshot has already had a few changes, it correctly builds deb and rpm packages again, passes make distcheck, and seems to be in good shape. One thing that has to be fixed is building klash. It turns out klash is still not getting built. So I tweaked things do the version of klash that's in GUI gets built. There is a problem with it, it doesn't appear to initialize the OpenGL drawing area at all. Klash now builds if you have KDE installed and if --enable-plugin is specified. There's probably a few other things in this branch we'll need to fix, so let's go find em and fix em, and get this release out. I'll merge the branch back into CVS HEAD when we're done. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] what is 'klash' ?
strk wrote: without that, it never gets the Display right. For the release I'm tempted to going back to building plugin/klash/klash instead, and we can fix KDE support in CVS later. I just made this change in the release branch. For now the old behavior of 0.7.1 is restored, and klash gets built the way it used to from it's own klash.cpp version of gnash.cpp. This lets the release have a working Konqueror plugin again. We still need to fix the KDE problem in cvs HEAD, but this will buy some time... Since KDE is so totally broken in gui, I think I'm going to disable it as a config option for the release so we don't get bugs reports on it. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] release shortlist
I just fixed klash in the release branch. In the original shortlist there was an item about fixing font anti-aliasing, is anybody working on that ? Should we punt this till the next release ? (probably) Default configuration is SDL sound with libMAD, OpenGL with GTK. --enable-plugin builds both the GTK and the KDE based plugins. I'm starting to think we should enable building the plugins by default, and require a --disable-plugin, since I think most people grabbing this release will be primarily be using it as a browser plugin. Anyway, other than that little tweak, and the font issue, is there anything major left that needs to be done ? If not, we should declare a code freeze in the release branch and focus on whatever bug fixes are required to push the release out soon. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] release shortlist
Patrice Dumas wrote: On Tue, Oct 31, 2006 at 09:42:45AM -0700, Rob Savoye wrote: Please leave little time to check the packaging, to ensure that the packaging examples are correct and hopefully tested by packagers before the release (I will look at and test the spec once I can build gnash...). In the release branch I fixed several things in the packaging files, and successfully built both deb and rpm packages that look correct. (this needs to be tested for the release of course) The dist-bzip2 tarball also looks correct. Also --enable-testing code is broken as I reported some time ago. It is just for the sake of reporting, I have no opinion whether it is a problem for the release or not. Thanks for reminding me! I just fixed this by moving the additional ActionScript code out of the base class, and moving it to NetConnection where it belongs. I'll migrate this to HEAD next. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] what is 'klash' ?
Markus Gothe wrote: Well, OpenGL is for 2D as well as 3D and is hw-driven in both cases if your hw/driver supports it. I can tell that playing elvis.swf on my SGI Octane2 (OGL implemented in the HW, no headers etc...) with AGG takes Most people don't have an SGI Octane2 sitting in their house... :-) We need to compare on a standard PC with Nvidia or ATI binary blob drivers unfortunately. out; AGG has some aspects that isn't implemented (yet!) in the OGL-backend. But since it seems to me that most of you guys prefer the AGG I think we should make it default (how democratic of me ;-)). Actually the version of AGG in all the distributions is a potential show stopper, as we don't want to require anyone to build AGG from source to build Gnash. So we're still brainstorming. One big advantage OpenGL has is simply that was how the last release went out, so that's what people expect. Software OGL is usually implemented by MESA and is a *real* CPU-hog... Don't go there! Tell me about it... That's how I run all the time cause I dislike binary blobs in free software. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: gui wants redraw
Udo Giacomozzi wrote: s May I suggest all bugfixing happen in the 0.7.2 branch s for consistency ? (we'll forw-port later) OS newbe question: Is this the normal way to go? I thought a release branch gets mostly patches that have been proven? Usually that's the process, but it's also very common to squeeze in bug fixes from HEAD into the branch. We actually have a huge bug list, and can't fix *everything* before the alpha release anyway. What we do want is that the release branch doesn't core dump, and that it mostly works. Minor bugs will be fixed in CVS. As strk already mentioned, our first response to anyone about the release will be did you also try CVS HEAD ? But yes, at this point we probably need to try to not do development in the release branch, just critical fixes. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Gnash running on PDA!
I just tweaked all the configuration code in Gnash (I'll check it in shortly) that makes it trivially easy to cross configure Gnash now. Basically if you use this set of cross tools SDK http://www.welcomehome.org/gnash/oe-cross-sdk-20061103.tar.bz2, everything is pre built to cross compile for a Debian (2.6.16 kernel) and Arm based embedded Linux system. This tool chain is based on the SDK for the OpenEmbedded.org project. I used GPE, as it's an X11-GTK environment instead of Opie, which is a Qt based one. This SDK should work for any of the Nokia 770, HP iPaq, Sharp Zaurus based PDAs. This photo http://www.welcomehome.org/gnash/frog1.jpg shows the Frog Blender Flash movie running on a Sharp C3200 PDA. it's pretty slow, and seems to have event handling issues. Elvis wouldn't even load, it ran out of memory after about 5 minutes. Several other movies played fine, just slowly (it's a 436Mhz ARM) ... This was a Gtk2-AGG build, as the Zaurus has no OpenGL support. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] cross compiling Gnash
I just checked in my cross configuration changes. The default set of args I'm using is: ../../gnash/configure --host=arm-linux --build=i686-pc-linux-gnu --target=arm-linux --prefix=/usr/local/arm/oe build_alias=i686-pc-linux-gnu host_alias=arm-linux target_alias=arm-linux --disable-plugin --disable-sound --enable-render=agg I have the SDK installed in /usr/local/arm, with /usr/local/arm/oe/bin in my path. What I did was make the assumption that when one is cross building something, the prefix for that application is often the same one all the other architecture dependent files are under. So when cross configuring, $prefix and $exec_prefix get used as a root directory for searches. btw, the SDK is using GCC 3.4.4. I got 4.2.x to build out of CVS, but as the ABI changed for C++ after 3.4.4, I'm not using it yet till I'm ready to rebuild the entire Zaurus. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
Markus Gothe wrote: Seem that 0.7.2 is to be considered stable now... I think we should release it on monday. Any other opinions/suggestions? Considered stable or truly stable ? :-) I'd also like to see the release go out within the next few days. Ideally we can now code freeze the branch *except* for bug fixes. If testing over the weekend is good, then yes, we'll put the release out. I have all the announcements and upload data files for the FSF all done, so it shouldn't be as slow a process as it was when I did the 0.7.1 release. Monday is a good goal as any, but we'll see... This should be a pretty good release, and after yesterday's checkins, Gnash can be cross compiled, which I think is good. So anyway, I'd like to hear the branch is working on a variety of BSD and Linux distributions, and not generally core dumping. We'll have to support this release for at least 6 months, so we don't want any stupidities to go out if possible. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
strk wrote: What do you mean by support this release ? Luckily we're not in the enterprise support biz, or we'd have to support every old release for many years. What I meant was whatever we put out as an official release, alpha or not, is the version most distributions ship. So we'll be getting bug reports on 0.7.2, regardless of ether something is fixed in CVS or not. Should we use the branch for bugfix releases then (0.7.x) and keep head for 0.8 ? For alpha releases, now. We'll leave the branch after the release (I'll tag it again when we make the actual release). Hopefully we won't be forced to do a 0.7.2.1 bug fix release anytime soon. I'd prefer to keep developing in CVS, and then just make a new release a 0.7.3 branch when we get video stabilized to the point it works for YouTube, Google, or Lulu.tv. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
John Gilmore wrote: By the time Gnash plays videos from the top sites, as well as lots of SWF's from other places, it'll be time to stop calling it version 0.something.something and call it 0.9 or 1.0. There's little sense in three- and four-digit release numbers here. I guess my own definition for a 1.0 beta release would be full Flash v9 compliance. By that definition we have a huge amount of work ahead of us. It may be that getting streaming video working well makes a good case for an 8.0 release. That would then make a 9.0 release something like having all the ActionScript classes implemented, and v8 compliant. If anybody feels like working on some simple Gnash contributions that would be greatly appreciated, there are more than a few ActionScript classes that need code added to the stubs so they actually work. Most of us are working in the core player code currently, since that needed alot of focus. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
strk wrote: I've tried to higher severity of bugs that should be show stoppers for 0.7.2 and I ask you to do the same. Brows the current bugs database and set to Blocker any item that you think should block 0.7.2. At this point I'd say a blocker is anything that causes a core dump. Currently we have two: #18207 (the sound thing) and #18100 (stack corruption). #18207 I think we should fix, as it turns out hitting Escape for any movie causes Gnash to core dump. The problem is in gtk.cpp where it handles control keys. I just checked in a workaround so at least it doesn't core dump. Esc was being handled like a control key, and it turns out that calling gtk_main_quit() from a key handler instead of a menu item is a bad thing. For now control keys are handled better, but quit from the keyboard doesn't work. I assume most people would use the menu item to quit, which works just fine. The keys were mostly only used for SDL, since it has no menu. #18100 is much harder to track down, since most of us aren't working on OpenBSD machines. We may have to make a release note about stack protection, and then try to fix it in CVS. So, let's define what a show-stopper is. Bear in mind that we're threaded now, so memory corruptions are likely waiting around any corner... At this point a code freeze would mean no additional changes that aren't required. I'm guilty of sliding things in too, like the cross configuration changes. At this point we should concentrate on core dump bugs, or we'll never get this out. One thing to be careful of is making sure new/delete or malloc/free are thread save by always wrapping memory allocation in a thread with a mutex. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
strk wrote: Mmm.. I could reproduce #18207 with NO intervention of the Guis (NullGui - -r1) Please try now after my patch of last night. It's in both HEAD and the branch. #18120 appears to be trying to access a non existence root movie pointer after loading a movie clip. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
strk wrote: Segfaults in both cases, NOT always. I can't reproduce this anymore... PS: we should be discussing this in the bug tracker Probably... but we need to decide whether this is a show stopper bug, can we make a workaround... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
strk wrote: I think we might try waiting for the loader thread to complete before starting to play the movie. This could be a runtime option allowing specification of a preload amount. Wait for the thread to complete, or just load more data before starting ? To make STL calls thread safe we have to wrap new/delete. That way all the internal memory allocations are protected. Maybe that's the problem if it's a threading issue. I've also had tons of weird issues with varying DRI implementations causing random core dumps, which is probably a good reason to not use OpenGL... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Releasing 0.7.2 RSN (i.e. on monday)...
strk wrote: Well, at this point I'm even more convinced about the stack corruption I guess 'wiping' out deleted memory might help us, but it's probably something that's better implemented as a delete wrapper itself ? You mean setting the memory before freeing it to zeros ? I'd actually try dmalloc or efence in this case. Then is makes all allocations get their own page, useful for tracking down some memory corruption problems. The other hack we could do (probably only in HEAD), would I could port over a memory allocator I wrote for a different GNU project that allocates a big chunk of memory upfront, and then new/delete work out of that pool. The pool can also be resized. This is the simplest way to make sure all memory manipulation is thread safe. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] error while make
shamju joseph wrote: Hi NoSeekFileTest.cpp:49:21: dejagnu.h: No such file or directory NoSeekFileTest.cpp:56: error: `TestState' does not name a type NoSeekFileTest.cpp: In function `bool compare_reads(tu_file*, int, char*, char*)': Install the dejagnu package. Also please post bug reports to gnash-dev, rather than both lists. This Gnash list is more for announcements and general discussion, whereas the gnash-dev list is for development discussion. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: Unexpected exception during rendering calls
strk wrote: Well, if we're taking too much memory we can't really tell when we'll going to run out of it. I guess a proper approach would be producing a diagram of where most memory goes, While mudflap won't print out a chart, it will tell you about every access to see if there is a problem. Often I've seen bugs that trash the stack create various weird errors, hiding the original problem. I also have some code that instruments the malloc buffers in the kernel, which can also be useful at times like this. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: [Gnash] second alpha release of Gnash!
strk wrote: Guys, release_0_7_2 is still a branching tag, shouldn't we retag with a non-branching one now ? Probably... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] video in gnash
Tomas Groth wrote: * Let gnash/libcurl fetch the video, not ffmpeg, since ffmpeg doesn't support RTMP (though neither does vanilla libcurl). Actually this is the right way to do it, because I have a patch to libCurl (http://www.welcomehome.org/gnash/curl-080206.tar.bz2) that's about 90% done to add RTMP support. There is a bug in the AMF header encoding I haven't had time to track down. So we need to use libCurl to handle talking to a Flash server. We may still want to use the background thread and a cache though. * Implement MovieClip.attachAudio() for audio handling of video (audio should not be automaticly enabled it seems). Probably correct again. * Seperate the video/audio decoding from the NetStream AS-object and put it into a video/media handler. This should hopefully make it easier/cleaner to support other video decoders (gstreamer). We should make a base class for this just like the networking code is for NetConnection. Supporting multiple decoders is also a good idea. For one thing for better Nokia 770 support, they donated patches to Gstreamer for their hardware based video decoder. Since ffmpeg has FLV and VP6 support, we'll need to potentially use the ffmpeg Gstreamer plugin on some platforms to get better performance. * Implement video viewing for AGG, and later cairo. Yes, since we'll be wanting to stream video on embedded devices, which is when we'll likely be using AGG. The Cairo backend isn't fully functional, I don't think anybody's been working on it since the AGG backend works. As a side bonus I also hope make support for video embedded directly in SWF-animations. You'd think that would be easier, since there is no networking required. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Gnash patches for RISC OS
Gnash got ported to RISC OS: http://www.drobe.co.uk/riscos/artifact1734.html. It looks like mostly additional support for the RO GUI, whatever that is. Anyone interested in applying these patches to HEAD ? I'll email them and see about the proper copyright assignments for the FSF. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] default load policy in gnashrc
strk wrote: This reminds me of a current problem in gnash... We feed the standalon player with the movie from stdin, so whitelist/blacklist has NO effect on top-level movie. I didn't verify this but I suppose no load of toplevel movie will currently be blocked. Should test I think this is OK for the movie the user directly loads into Gnash. The whitelist/blacklist is to cover the situation when that movie that's playing tries to load a file from another computer over the network. Many Flash movies load content from all over the place, so this is to be able to have some control of that. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Cross Compiling
Victor Adan wrote: Is essential to have a Boost library dependency with this configuring? My problem is to cross compile this Boost library... You need Boost, as we use Boost lightweight mutextes. I have cross compiled boost for several architectures with no problems. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Gnash extensions question
I've just gotten an extension mechanism for Gnash working, where any ActionScript class can be a plugin that gets dynamically loaded. This can also be used to create your own custom ActionScript classes. My current test class is a DejaGnu one, so it'll be possible to have testing support built in. I plan to follow the DejaGnu one with a MySQL one, also to support better automated testing. Right now I install a Gnash extension in $prefix/lib/gnash/plugins, and they get loaded from there. Initially the directory is scanned, and all extensions get loaded. Later on we'll probably only load the extension if the class is invoked. I build extensions in gnash/extensions/[extension name], and they get installed in the right place. Anyway, here's the question... should I go through the effort to make Gnash load extensions from the build directory for testing ? Finding $prefix/lib/gnash/plugins is easy, but figuring out the explicit path to the build tree's version would be pretty convoluted. I figured I'd see if folks really want this ability before I go off an implement it that way... I optionally use GNASH_PLUGINS to set the path, so for debugging, this could manually be set, but would only get one plugin directory at a time. If I leave it the way I have it implemented now, you have to install and extension before Gnash (whether it's installed or uninstalled) can find it and use it. Currently the extension mechanism is limited to creating AS classes, but later on I plan to extend it so it can be used to add core functionality. As an extension is fully linked into gnash dynamically, you can actually do anything you want within the extension code, like accessing internal data structures from the player. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
Rob Savoye wrote: I optionally use GNASH_PLUGINS to set the path, so for debugging, this could manually be set, but would only get one plugin directory at a time. Since lists.gnu.org has been down a few days, I figured this out already. It turns out you can specify a colon separated list of directories to libltdl, so as the code now stands in cvs HEAD, you can set GNASH_PLUGINS to find extension in the build tree, as well as the installed location. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Bizarre screen painting outside the bounding box
John Gilmore wrote: That animates fine, but if I scroll the browser window while it is updating (moving a woman's image across the image), it suddenly starts painting part of the image at the bottom of my physical screen! The rest keeps updating in its proper place. I get a different problem with this movie. When I scroll, the plugin frame becomes a screen shot of my desktop, which usually signifys memory corruption someplace. Just to be really interesting, when the movie is done, if I click refresh on my browser, it works just fine! For me it never pains outside the window frame (gtk-opengl), but stays within the window frame for the plugin. You're on Debian stable right ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
Patrice Dumas wrote: On Sat, Nov 25, 2006 at 08:28:23AM -0700, Rob Savoye wrote: Also it may be more convenient to define that directory in configure.ac if it's going to be used in many Makefile.am (and maybe later a --with could be added). You're right again. :-) I mostly checked this code in so we could make sure it builds everywhere. You can also set GNASH_PLUGINS to point to a list of directories. This path will only be used by the extensions themselves, but one day there may be a bunch of them, so I'll see about moving the definition to a higher level place. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] how to deal with bugs reported against packages?
Patrice Dumas wrote: I asked the reporter for -va -vp and a backtrace, but now I think it would make sense to have it handled by the gnash devellopers (even though I may have a look too). What should be done for communication between package maintainers and upstream gnash for bug reports? Bugs in the package I'd prefer to be handled by the package maintainers, but this one is an X11 bug we should probably track down and fix. Usually when there is a problem with visuals, it's often very specific to that workstation, and hard to duplicate. In this case I'd also suggest they run glxinfo and xdpyinfo, since that'll have more specific info on this problem. Ideally this bug should get reported using the Savannah bug tracking for Gnash, which is the best way to get things handled. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
John Gilmore wrote: To avoid a lot of startup overhead on every gnash startup, I suggest only looking for these extensions if or when someone invokes a class that isn't already defined. I.e. turn an error into a look for extensions. That's the plan. Currently I scan the directory for just the names of the modules, and store that away. Then later if that gets called from within a movie, it'll get loaded at that time. Another thing I'm considering is making *all* the ActionScript classes plugins, which would reduce the size of the player, and reduce the amount of objects the VM would have to go through when playing a movie. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
Martin Guy wrote: 2006/11/27, Rob Savoye [EMAIL PROTECTED]: Lovely idea. I am only worried about slower startup or lumpy playback. It's a situation analogous to static linking vs shared library loading, and a quick test between bash and bash-static shows bash, which only has 4 Since the plugin mechanism uses the same API as all the existing classes, it's trivial to set things up so a Class could be compiled into the executable, or loaded dynamically. We'd probably add an option like --with-extensions=String,Math,Boolean to specify what should get linked in at compile time vs what gets loaded dynamically. Loading a plugin is pretty fast though, as all I do is find the *_class_init function and call it. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [patch] for build
strk wrote: But some people allready started modifying libltdl, so it is not obvious what to do now. To be honest, we *shouldn't* be modifying libltdl at all. I was just looking a the diffs, and they're pretty minor. One is a win32 hack that really shouldn't be there, and the other is a minor addition for riscos. I believe both these patches could be handled better at a higher level, and we'd be better off using libtoolize -ltdl to avoid problems. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Test Case Results. Flash v6. firefox. windows. adobe player.
mark cox wrote: i can't seem to find the build instructions for win anywhere. i hope i don't need to install cygwin? Actually there is a project file for VC++, just use that. Cygwin or MingW would be preferred, but VC++ is what works for now. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] URL to try
James Lockie wrote: Someone please look at this. It displays correctly but clicking on the CompTIA Certifications doesn't do anything. It you have the whitelist enabled in your ~/.gnashrc file, the URLs won't load unless you give explicit permission. Each of the links goes to a different host. You can see what Gnash is doing by running setting debuglog ~/gnash-dbg.log, and then tail -f ~/gnash-dbg.log when you click on each link lets you see if Gnash thinks you have a security violation. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [patch] for build
strk wrote: Will you take care of modifying autogen.sh, reintroducing libtool.m4 and eventually regenerate both libtool.m4 and ltmain.sh to be the latest versions ? I don't think we need libtool.m4 anymore if we're using AC_PROG_LIBTOOL. libtoolize copies over ltmain.sh, so that shouldn't be a problem. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [patch] for build
Patrice Dumas wrote: On Wed, Nov 29, 2006 at 09:27:21AM -0700, Rob Savoye wrote: Exactly. Maybe we could also get rid of config.guess, install-sh, config.sub and similar files (don't know if ther are other like those)? libtoolize copies config.guess and config.sub too, so we could probably use it for everything. I'll look into it. I don't know why but a mail I send yesterday hasn't made through to the list, where I propose a patch for kde.m4 to remove a lot of macros from that file, including AC_PROG_LIBTOOL. Once this is applied the system libtool.m4 will be used. kde.m4 was one of the few macros we didn't create, and it's not only overkill I think, but cause other issues with Gnash. So a shorter version would be good. :-) I didn't see the patch, the mail server at gnu.org has been somewhat flaky this week. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] URL to try
James Lockie wrote: export debuglog=~/gnash-dbg.log didn't create a file but this was printed to the console and might be helpful. :-) Sorry, I guess I wasn't clear. debuglog isn't a shell environment variable, it's a setting in your $HOME/.gnasrc file. More info is in the Gnash manual. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Gnash extensions question
Udo Giacomozzi wrote: Agree, although this in my opinion still means that Adobe dictates the specification. We'll be following Adobe's spec, but we'll be developing our own documentation about the spec, including the differences between subtle implementation issues. There are actually quite a few places where Abode doesn't follow their own specification... So, this means that Gnash will _always_ be one step behind. Gnash runs on many more platforms than the Adobe player, so who's behind who ? :-) If the Gnash user community starts creating interesting and useful extensions to Flash via the extension mechanism, I believe Adobe will follow us... and if not, I don't really care. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] [patch] for build
Patrice Dumas wrote: ltmain.sh should be removed from cvs too, I guess. Oops, I missed that one. It's gone now, thanks. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: Fwd: [Gnash-dev] URL to try
Martin Guy wrote: Sorry, are we blacklisting/whiltelisting sites in the default setup? If so, I think that is undemocratic and an inappropriate abuse of power. No, as there is no installed .gnashrc file, so nothing it blocked by default. Even if we installed .gnasrc file (which we probably should), the whitelist and blacklist would be blank. But yes, as we do want to give the end users an ability to block what they deem bad content. The current Flash player has pretty poor security, we should do better. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Re: gnash working on playstation3 - ps3
:: Onlinelib.de :: wrote: after 7 days and 1 ton of coffee i got a flash player working on my ps3-baby :) for the renderer i choosed cairo compiled from source. I think you'll have better luck with the AGG backend, than the Cairo one. AGG is what I've used on all the embedded ports of Gnash. - rob - (catching up on old email after a long road-trip...) ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Docbook derived documentation on the website
strk wrote: Mmm... I think we should have two versions on the manual published, one for the latest release and one for current CVS. Actually, when new releases come out it might be worth keeping the manual for older releases online, as an archive... I've always just updated the manual on the website by hand. For the last year, I've updated the manual to match CVS improvements. I think now that the 0.7.2 release is out, and is in pretty good shape, (plus it's in many distros) the manual on the gnu.org site should probably match the release. We can put the CVS version on the developers site, which should be publically available as soon as I can get somebody to make a pass through it, as I suck at writing these things... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Trying to run the tests
strk wrote: Well, a quick suggestion for you is to get Ming :) Another possibility is to grab a release snapshot, but I'm afraid we're not currently providing them. I suggest we do though... a nightly snapshot in release mode would likely be helpful. I think for now, it's better off if people wanting to test Gnash use CVS, as it changes daily. :-) I don't really want to get into the mess of supporting CVS snapshot builds at this time as we're all busy enough as it is... I also don't think we want to distribute test cases in a release, it's probably better that people use the online versions on the developers site, as one of these days we'll hook it up to automatically log all the results into a database. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] version in menu?
James Lockie wrote: It would be nice if the version (CVS) was in the popup menu of the plugin. An about dialog? Hum... I'm not sure if that's the right place for this info. This would more likely go in the About box, which unfortunately isn't part of any of the GUIs. As a more long-term goal (since we currently lack anyone with real GUI programming background) I'd love to see the Gnash GUI extended to have a real menu bar, where menu items for Help and About would go. Even better would be a dialog box for setting user preferences, etc... This would be an excellent way for somebody to make a contribution to Gnash, that doesn't want to get involved in any of the core programming. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Docbook derived documentation on the website
ann wrote: I was wondering...is there some reason that we don't build the documentation by default? It seems to me that this would be more universally useful than, say, Klash support, which is default. The main reason is that the dependencies for producing the various output formats are nasty, and aren't even supported on all platforms. Even worse, building docbook requires more than a trivial amount of packages, which aren't even the same on all distributions. So building doc by default would likely generate a huge pile of bug reports that we'd not be able to do much about. KDE support is available most everywhere, and there's a lot of KDE users out there, so it needs to be built by default. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] crash firefox
James Lockie wrote: Ok, it is firefox crashing then. :-( I actually gets many Firefox crashes these days, even without any plugins installed at all. It seems to me that as the Mozilla Corporation gets more commercially oriented, they let the quality of the free version lag... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Docbook derived documentation on the website
strk wrote: BTW, I'd like to drop the Java dependency for that... anyone ? Only if you can find another way to generate PDF from Docbook. The Java dependency bugs me too, but many people prefer PDF output. I've tried several other tools for producing PDFs, but the current way is the only one that works so far. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: Fw: [Gnash-dev] Re: gnash working on playstation3 - ps3
:: Onlinelib.de :: wrote: i have no sound at the moment. how can i enable the soundhandler ? Try --enable-sound=sdl. You can also use libMad instead of ffmpeg. Pay attention to the configure output to see if you have everything installed you'll need. how about video playback ? can i playback other fileformats then flv ? Probably, but as the video support is brand new and still under development, your mileage may vary... i have ffmpeg installed incl. libavcodec and libavformat. whats about http and rtmp streaming ?! RTMP and HTTP are used to transport the file being loaded over a network connection. I'd stick to HTTP till I finish the RTMP support for libCurl. i will study in the next couple of week the code of gnash. i would like to implement the ps3 spu processors for faster playing swf. i dont know yet if its possible to add a dspUtil class for supporting altivec with the spu´s. Nokia added support for some DSPs to Gstreamer, you might want to look at that. There is also Gstreamer support for sound in Gnash, although the ffmpeg support works better. i never done a binary installer on linux before. also here i need some help. Depending on your packaging for the PS3, make deb (for Debian) and make rpm (for Redhat) both work. Most of the time you just list the dependencies, and the binary Gnash package just contains the Gnash libraries. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Patch (5640) for task 6124
annonygmouse wrote: Everytime I try to add a comment to this patch it tells me No item found with that id. so I post it here :) Savannah just underwent some downtime this weekend, and now it's working again. That may have been your problem. I just checked in a variation of your patch #5640 that uses the sub menus for the right-click menu as well as the menu bar. That way everything is accessible from the popup when running in a browser. I move the controls to a Movie Control sub menu to reduce clutter. They don't appear to work for most movies anyway... :-( I've finished a first version of the preferences window. It's populated using the rcfile class from rc.cpp. This way it's .gnashrc independent. Cool, that's the way to do it. rcfile probably also needs support to write updated setting, as well as just reading them. What did you exactly expect from this preferences window? I mean: If a user changes a preference, the window should create a new .gnashrc? We'd probably want to just edit the settings for the lines that were changed. My assumption was any changes would get written to the .gnashrc file when the dialog box is closed. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Fwd: New Year's Eve OLPC Party-Time with Max Headroom
Gnash now runs on the OLPC! This is how I spent New years... porting Gnash with John Gilmore! :-) Maybe I should have been partying instead, but... http://www.olpcnews.com/prototypes/xo/new_years_eve_olpc_p.html - rob - (btw I do now have a cross compiling tool chain for the OLPC working) ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] cross compilation problem.
remi wrote: Hi, i try to cross compile gnash for an ARM pxa 270 target and i have this error when i execute make after ./configure --target=arm-linux --prefix=/usr/local/arm-linux --host=arm-linux --build=i686-pc-linux-gnu --disable-plugin --disable-sound Try something more like this: ./configure --host=arm-linux --build=i686-pc-linux-gnu --target=arm-linux --prefix=/usr/local/arm/oe build_alias=i686-pc-linux-gnu host_alias=arm-linux target_alias=arm-linux --disable-plugin --enable-renderer=agg build and host are the host system tou are building on. They are only different when building a Canadian cross, which trasnslates to building a cross compiler on a Unix machine thay is going to run on win32, but still produce executables for yet another target system. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Large movies (was Re: [Gnash-commit] gnash ChangeLog libbase/gstgnashsrc.c libbase/g...)
Martin Guy wrote: Can you put the actionscript source for each test alongside its .swf? For stuff under testcases, the sources are all in gnash/testsuite/actionscript.all - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] configure.ac
Martin Guy wrote: I'm gonna regularise the indentation in configure.ac because it is You'll notice I made most of the m4 macros follow a 2 space indenting, I'd prefer to use the same for configure.ac. I've been adding this to all the m4 files: # Local Variables: # c-basic-offset: 2 # tab-width: 2 # indent-tabs-mode: nil # End: To make it easier to do proper indenting, at least for us emacs users. Before I do, I wanna make sure no one is doing major work on configure.ac because the changes are likely screw up any context for automatic merges for stuff that is checked out. As one of the few people that regularly hacks on configure.ac, this is a good time as any, so go for it! - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] question about sumit patches
zou lunkai wrote: While submitting bugs, the 'Category' contains much more clearer categories. http://savannah.gnu.org/bugs/?func=additemgroup=gnash So, could the maintainer of this site do sth. to improve the pages? I just added all the categories from the Bugs page to the Patches page. This mostly hasn't been done since most people seem to just email patches to gnash-dev, instead of submitting them on Savannah. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] configure.ac
Bastiaan Jacques wrote: That said, I think we desperately need indentation fixes throughout the codebase -- not just configure.ac. If you look at files like gui/sdl.cpp and gui/gui.cpp, you see that pretty much every contributor uses his own My latest macro checkin should have fixed the indenting for most of the .m4 files. For me files I'd prefer to see no code checked in that doesn't follow standard indenting. For m4 files, this is critical, as without consistency, m4 code is even *harder* to debug. My m4 coding style, which we should adopt, is 2 space indenting after any if/while/for/ etc... and after any AC_* macro that end which a '['. I like a space after any comma. You can look at the new ffmpeg.m4 for my latest formatting style. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Building fltk; using *-config programs in configure
Martin Guy wrote: Briefly, vanilla fltk compilation fails for me bcos the configure stuff doesn't use *-config programs. Then the path lookup is wrong. If you run CONFIG_SHELL=sh -x ; sh -x configure you can look in the output to see why it fails, or send it to me and I'll look into it. [sidenote: I plan to rename fltk to fltk2 in the few places where it isn't already called that, to allow for a fltk interface for the ubiquitous and stable fltk1. Does that sound reasonable?] Sigh, I wish Debian could be more up to date. Fltk1 and Fltk2 are pretty different from each other, so you'd have to change the GUI code. the compilation of gnash then barfs on the final link with ... distcc -g -O2 ... -o .libs/gnash gnash.o ... ./.libs/libgnashgui.so: undefined reference to `FcObjectSetBuild' ./.libs/libgnashgui.so: undefined reference to `XftDrawSetClip' ./.libs/libgnashgui.so: undefined reference to `XftDrawString32' ./.libs/libgnashgui.so: undefined reference to `XRenderFreePicture' ... ./.libs/libgnashgui.so: undefined reference to `XftDrawSrcPicture' ./.libs/libgnashgui.so: undefined reference to `XineramaQueryExtension' ./.libs/libgnashgui.so: undefined reference to `XftDrawCreate' Hum, we do look for Xft. I guess one of these days I should setup a machine with Etch and see what's so different. Can you email me the output of ldd gnash ? Bastian says: I agree. I think we should consider adding package-config support to gnashpkgtool.m4. Probably. It would have to be done using the new $pathlist, so it still works when cross configuring. 1) check pkg-config for information on a package 2) fallback to package-config script 3) fallback to testing for library existence in standard paths And then try AC_CHECK_LIB and AC_CHECK_HEADER last. I'm studying autotool now (something I have been avoiding for years...) - does someone (Tomas?) want to look at this or should I do it as a learning exercise? It's probably more efficient for me or Markus to fix these issues, but learn autotools if you want. :-) - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Gnash works as OLPC plugin!
I'm probably easily excited, but here's a screenshot of Gnash running as a plugin to the Web Browser activity on the OLPC. :-) http://gnash.lulu.com/images/IMGP1232.JPG - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Using gnash to execute ActionScript in a swf file
ying lcs wrote: At the current stage of gnash, is it possible to use it to execute ActionScript in a SWF file? Yes, many AS2 classes are supported. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Using gnash to execute ActionScript in a swf file
ying lcs wrote: And i have a SWF file which uses NetStream , but how come I don't see any 'not implemented' message when i run that SWF file via gnuash? Because NetStream is now implemented. :-) Course it's still being debugged... - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
[Gnash-dev] Flash debugger support
I just checked in minimal support for a Flash movie debugger into Gnash. To activate this, start gnash with -g. This drops you into a console when Gnash first starts so you can set watchpoints. Then type c to continue, and when it stops at a watch point, you can use various commands to dump the registers, the stack, etc... Type ? at any time for simple list of commands. There is also now a dynamic disassembler. Type t, to toggle tracing on and off. When Tracing is enabled, the current opcode is disassembled and printed. This is roughly equivalent to -va, but is controlled from within the debugger, and has more verbose output than using -va. As Flash has no line numbers more symbol table, currently there isn't breakpoint support quite yet. For that I plan to allow one to say b foobar and then when the foobar Flash functions is called, it'll break. In this version only variable watchpoints work. When setting a watchpoint, you can specify a r to break on reads of the variable, or a w to break on a write to the variable. i w dumps the currently set of watchpoints. So w foobar r breaks when the movie reads the foobar variable, and w foobar d removes the watchpoint. Future enhancements will allow expanding the as_values on the stack to get to the internal data, and adding a call stack. This should not only help us debug Gnash itself, but should be useful to Flash developers. One of these days I plan to add remote debugger support, but for now I pan to focus on making this more functional. I'll be adding to this over the next few days, but anyone else that has an idea for a debugger feature should feel free to add it. Basically the guts of any new feature go in the Debugger class, with a command hook in Debugger::usage() and Debugger::console(). If you don't want debugger support, configure with --disable-debugger. Ann, can you add all this to the manual ? - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Laszlo-dev] [Gnash-dev] YouTube video via OpenLaszlo
P T Withington wrote: I remember we recently fixed a bug that was emitting with blocks with extents that were 'out of bounds'. Somehow these did not bother the Flash player, but the caused flasm to croak. Can somebody send us an swf of one of the OpenLaszlo demos ? I can only seem to find the sources, and unfortunately the Launch Flash Application just opens a new window and doesn't appear to even launch Gnash. So I'd need to run this through the standalone player to see what's up. If it choked Flasm, it's entirely likely it chokes Gnash. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Laszlo-dev] [Gnash-dev] YouTube video via OpenLaszlo
Henry Minsky wrote: On every single one of them I get this error still: 17:30:50: ERROR: swf_event::read(), event_length = 111, but read 110 So then nothing else gets parsed right, so we'll have to look into it. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] GUI-specific configuration
Udo Giacomozzi wrote: Uhm, don't want to touch rc.* just for one single GUI... :( Exactly. I just thought about a special [FB] section in .gnashrc that get's parsed / interpreted only when the FB GUI is used. So you're telling me the current design does not support this? Well, no. I never thought of adding that kind of support. I guess I could, but to me these are more hardware oriented settings. .gnashrc is oriented towards end user settings. fb.cpp could read it's own config file, of course, but I doubt that would be an elegant solution... What do you think? No, actually I think that's the best idea. If the FB GUI is the only thing that cares about these few settings, I'd load them via a simple XML based config file. The XML code in Gnash works pretty well, this is the type of thing it's to be used for. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] GUI-specific configuration
Udo Giacomozzi wrote: Exactly. And that's why I'm surprised that you're suggesting XML for a configuration file. It any compatibility with the proprietary player is desired, then XML is your best choice. Otherwise, I'd go with reading a simpler file. XML is pretty simple though, but then again, I wrote the XML support for Gnash. :-) Don't understand why you're talking about ActionScript - the GUI is not related to the VM. I was just explaining how the XML support in Gnash worked... *not* specifically designed for Gnash. However, for the player to work correctly, some additional configuration is needed to support the hardware. This is something the user has to do - just like he has to configure it's X server. The settings in .gnashrc may change over time, it sounds like the settings you are talking about are more of a platform configuration thing. (ala XF86Config) I'm not totally opposed to adding a section in the .gnashrc file, but it seems that for something that is so FB specific, it should be it's own file and format. I basically agree with you, but the FB GUI is not an extension - it's a choice. Right, but the File I/O stuff is an extension. Sometimes Gnash gets heat for the entire concept of extending the Flash spec. I see this more as making Gnash a better Flash better, with better support for the kinds of things embedded developers need. Fully agree! I'm happy you made this extension, as otherwise I would have to do it :) I'm missing functions like rename(), though. I'll see about adding some directory and file manipulation next time I work on that extension. You may not need it, but I also added a MySQL extension so you can talk directly to a database. Both of these had been suggested to me many times. Using files is the most simple and effective way to talk to the rest of an embedded system. As for compatibility, is there a way to detect if the file I/O extension is available? If file = new FileIO(); fails, it's not installed. That's at least how the testcases do it. Currently the list of extensions isn't exported into the Gnash VM in a way it'd be accessible to a movie. - rob- ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Trying file i/o extension...
Udo Giacomozzi wrote: I copied fileio.la to /root/extensions and started Gnash using: The easy thing is to configure Gnash with --enable-extension, and make install then. Without this option, Gnash doesn't look for any extensions, and it's disabled by default. No messages regarding file i/o extension and file.fopen() returns false (took the code from test.as). With -v, there should be error messages if it didn't load. Since I saw you're writing to dbglogfile I created the file /root/.gnashrc with writelog=/tmp/gnash.log but the format is probably wrong. How should .gnashrc look like? Is this documented somewhere? There should be an example in the manual. Try this: # The full path to the debug log set debuglog ~/gnash-dbg.log - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] GUI-specific configuration
Udo Giacomozzi wrote: - This config file is *only* related to the FB gui and is only necessary for someone that uses Gnash to play .swf files. There's Then I'd probably create a simple text file, stick it someplace, and just parse that using the File I/O extension myself. This info is more of a system, wide type of data than Gnash specific. It'd also be nice if there was a way to have the same options set at compile or configure time, so the extra file would be unnecessary. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
Re: [Gnash-dev] Dejagnu parser hell
strk wrote: During an IRC talk we found out that 'make check' is returning different results even when called consecutively on a single host/buildtree. This is likely due to expect buffering. Expect uses Tcl, but make check is actually an expect program. Any issues with inconsistent results is usually the pattern that's being looked for doesn't have full closure, which can cause problems with buffering. Since we're using expect to grab the output of a Flash movie running under Gnash, there are probably some weird buffering problems. Question is: is there a TCL hacker around willing to make it a robust parser, or do we want to implement the parser using a bourne shell, or perl ? To do so would mean dropping the use of DejaGnu, so as the sole Tcl hacker, I guess I'll have to see about fixing it. - rob - ___ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
