libvisual-devel — libvisual mailinglist for developers

Re: [Libvisual-devel] Re: frame limiting.

[Dennis S. <sy...@yo...>]

On Fri, 2004-06-25 at 20:31 -0300, Duilio Javier Protti wrote:
> > Do you think it might be useful to have helper functions
> > for frame rate limiting within the library ?
> 
> I think not, unless we give some method on the library
> to run the loop that calculates/show/handle_events and
> everything that was previously set. But this is not a
> good idea. The library must not rely on timings constrains.
> 
> The library must be kept minimal. For this, visual_bin_run()
> is a good mechanism, because it permits to model the control
> flow as a set of steps, and the timing of that steps is 
> controlled by the environmnent on which is used.
> 
> 
> Duilio.


I've got to agree with you :)

[Libvisual-devel] Re: releasing and stuff

[Duilio J. P. <dp...@fc...>]

> Do you think it's possible to release at sunday, as in,
> a good release ? :)

Ok.

> I think that in the case we want to work towards a release
> this sunday evening we might want to have a list of bullet points
> that needs to be looked at.
> 
> On the top of my head:
> 
> * Good bug reporting description.
> * Make very clear that this is WIP software.
> * --enable for all plugins, however I think we might discard the
>   videotest plugin (it was used for very early debugging).

Ok, just drop it.

> * Frame rate limiter helper functions within libvisual.
> * XMMS plugin changed so it uses libvisual frame limiting.

I say my opinion on previous mail.

> * Create NEWS files.

Very important.

According to GNU standards, NEWS file must talk about user visible
changes made in the software. In the case of libvisual itself, users
are developers, but NEWS must talk about changes on the interface or
buiding process, or a major performance improvement, not changes in
the code (which are in ChangeLog).


Duilio.

[Libvisual-devel] Re: frame limiting.

[Duilio J. P. <dp...@fc...>]

> Do you think it might be useful to have helper functions
> for frame rate limiting within the library ?

I think not, unless we give some method on the library
to run the loop that calculates/show/handle_events and
everything that was previously set. But this is not a
good idea. The library must not rely on timings constrains.

The library must be kept minimal. For this, visual_bin_run()
is a good mechanism, because it permits to model the control
flow as a set of steps, and the timing of that steps is 
controlled by the environmnent on which is used.


Duilio.

Re: [Libvisual-devel] releasing and stuff.

[Gustavo S. B. <gu...@gs...>]

Em Friday 25 June 2004 11:26, Dennis Smit escreveu:
> Gustavo please hold your mplayer stuff till 0.1.5 is released btw ;)

I'll :) I don't have time right now :(

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

[Libvisual-devel] releasing and stuff.

[Dennis S. <sy...@yo...>]

Duilio,

Do you think it's possible to release at sunday, as in,
a good release ? :)

I think that in the case we want to work towards a release
this sunday evening we might want to have a list of bullet points
that needs to be looked at.

On the top of my head:

* Good bug reporting description.
* Make very clear that this is WIP software.
* --enable for all plugins, however I think we might discard the
  videotest plugin (it was used for very early debugging).
* Frame rate limiter helper functions within libvisual.
* XMMS plugin changed so it uses libvisual frame limiting.
* Create NEWS files.


I think we both agree that the goal of this release is to fix the
previous mess and have a good buildtree. After this has settled
we can focus on features again :)

After the release we also might start thinking about creating a list
of changes, features we want in the following (0.1.6) release.

Gustavo please hold your mplayer stuff till 0.1.5 is released btw ;)

Thanks,
Dennis

[Libvisual-devel] Authors, frame limiting.

[Dennis S. <sy...@yo...>]

Duilio, btw please feel free to add yourself as author to the AUTHORS
files in the modules where you have been comitting, Also do you think
it might be useful to have helper functions for frame rate limiting
within the library ?

Cheers,
Dennis

Re: [Libvisual-devel] visual_init()

[Dennis S. <sy...@yo...>]

I have actually been using it in the examples (that is morphsdl,
simplesdl, If you see documentation errors anywhere, please feel free to
fix them I haven't yet proof readed it and it's mostly done in nightly
hours :)


On Fri, 2004-06-25 at 00:08 -0300, Duilio Javier Protti wrote:
> I have found a major issue about libvisual interface.
> The signature of visual_init() is:
> 
>   int visual_init (int *argc, char **argv[])
> 
> and the comment says:
> 
>   @param argv Pointer to a list of strings that make up the
>   argument vector or NULL.
> 
> which is not true. That would be true if argv was it
> a pointer to an array of pointers to char.
> But argv is an array of pointers to pointers to char.
> 
> I have found that error trying to set visual_init() from
> XMMS plugin to show the correct program name when showing
> debug messages (which I have added to keep track of the
> bug that make XMMS crash on plugin disabling).
> 
> Has anybody used this interface? I couldn't make it
> work. However, changing the interface signature to:
> 
>   int visual_init (int *argc, char ***argv)
> 
> and changing the client accordingly, everything works
> fine. Dennis, do you think we must change the interface?

Yes we must change it to ***argv, it's a mistake on my side :)
Would you like to check this in ?

Re: [Libvisual-devel] nebulus plugin

[Dennis S. <sy...@yo...>]

On Fri, 2004-06-25 at 00:08 -0300, Duilio Javier Protti wrote:
> Check all the packages (not our working copies, but the distro
> packages from scratch). Remember you must --enable all plugins
> before to make dist.
> 
> However, give one more day to check XMMS plugin. Another issue
> you must focus on this release, are the feedback mechanisms.
> You must say exactly how you want the report bugs must be, 
> and create categories accordingly on the sf.net site.
What would be the best place to notice about this, the README ?


> This release must be as stable as possible. Of course it will
> have the well known bugs, but despite of them, it must compile
> everywhere and it must work, and the people must know there
> is work in progress here.
Agree on that.


> After that, I think we must focus on the most important TODO:
> the versioning system.
> If we don't resolve this, on every new release of the library
> will be needed a plugins/nebulus/xmms-plugin release also,
> which is too hard to maintain.
Yep that is a important item, I haven't really thought about how
we could implement this, but whatever we do we have do this
right on the first time.

Thanks,
Dennis

Re: [Libvisual-devel] XMMS plugin

[Dennis S. <sy...@yo...>]

On Thu, 2004-06-24 at 22:01 -0300, Duilio Javier Protti wrote:
> I have submited some work:
> 
> - lv_xmms_render_pcm() now uses a fast memcpy()
> instead of a for loop.
If you'd like, you might like to redo the whole plugin
with some more config stuff and such, the plugin as it is
is one big hack used as testing and everytime hackily adapted
to changes.

> - added fullscreen support.
Wasn't that already there ?

Cheers,
Dennis

[Libvisual-devel] nebulus plugin

[Duilio J. P. <dp...@fc...>]

> Duilio would you care to check it out and see if it's release ready as
> it is right now ? we might want to add some EXTRA_DIST stuff here and
> there. 

It is right. Not only the repository, but the distro package too.
I have submitted some little work, take a look.

> Duilio what needs to be done before we can do a new
> release ?

Check all the packages (not our working copies, but the distro
packages from scratch). Remember you must --enable all plugins
before to make dist.

However, give one more day to check XMMS plugin. Another issue
you must focus on this release, are the feedback mechanisms.
You must say exactly how you want the report bugs must be, 
and create categories accordingly on the sf.net site.

This release must be as stable as possible. Of course it will
have the well known bugs, but despite of them, it must compile
everywhere and it must work, and the people must know there
is work in progress here.

After that, I think we must focus on the most important TODO:
the versioning system.
If we don't resolve this, on every new release of the library
will be needed a plugins/nebulus/xmms-plugin release also,
which is too hard to maintain.


Duilio.

[Libvisual-devel] visual_init()

[Duilio J. P. <dp...@fc...>]

I have found a major issue about libvisual interface.
The signature of visual_init() is:

  int visual_init (int *argc, char **argv[])

and the comment says:

  @param argv Pointer to a list of strings that make up the
  argument vector or NULL.

which is not true. That would be true if argv was it
a pointer to an array of pointers to char.
But argv is an array of pointers to pointers to char.

I have found that error trying to set visual_init() from
XMMS plugin to show the correct program name when showing
debug messages (which I have added to keep track of the
bug that make XMMS crash on plugin disabling).

Has anybody used this interface? I couldn't make it
work. However, changing the interface signature to:

  int visual_init (int *argc, char ***argv)

and changing the client accordingly, everything works
fine. Dennis, do you think we must change the interface?

A question would be: why not use the signature

   int visual_init (int *argc, char *(*argv)[])

which express exactly "a pointer to an array of pointers
to char"? Because it doesn't compile. Compiler needs the
array size for this to work.


Duilio.

[Libvisual-devel] XMMS plugin

[Duilio J. P. <dp...@fc...>]

I have submited some work:

- lv_xmms_render_pcm() now uses a fast memcpy()
instead of a for loop.
- added fullscreen support.


Duilio.

[Libvisual-devel] libvisual nebulus

[Dennis S. <sy...@yo...>]

Heya everyone!

I've imported libvisual-nebulus into sf.net libvisual CVS under the
module (suprise!) libvisual-nebulus.

Duilio would you care to check it out and see if it's release ready as
it is right now ? we might want to add some EXTRA_DIST stuff here and
there. 


I'd like to do a release this weekend, I would be really happy if
people could check and see if the new libvisual build tree is
doing well. Duilio what needs to be done before we can do a new
release ?


Thanks,
Dennis

Re: [Libvisual-devel] XMMS plugin

[Dennis S. <sy...@yo...>]

On Wed, 2004-06-23 at 15:13 -0300, Duilio Javier Protti wrote:
> I have fixed some problems on XMMS plugin, that 
> makes XMMS crash when you disable from the configuration
> window.
> It still not working, but I think remainings problems
> are not on the XMMS plugin, but on the Libvisual library
> side.
> 
> I think I will wait until VisBin code rewrite, and then
> see what happens here (the problem is exactly when we
> call SDL_Quit()).

I've seen this as well however been unable to isolate it. Valgrind
doesn't show up any memory errors either. Thanks a lot btw!

I've decided that I'll be doing a release this weekend, work is
exhausting me so when I'm back home I really don't feel like
releasing hehehe :)

Dennis

[Libvisual-devel] XMMS plugin

[Duilio J. P. <dp...@fc...>]

I have fixed some problems on XMMS plugin, that 
makes XMMS crash when you disable from the configuration
window.
It still not working, but I think remainings problems
are not on the XMMS plugin, but on the Libvisual library
side.

I think I will wait until VisBin code rewrite, and then
see what happens here (the problem is exactly when we
call SDL_Quit()).


Duilio.

[Libvisual-devel] CVS

[Dennis S. <sy...@yo...>]

Heya fellahs.

Duilio and I have been putting parts of libvisual into the sf.net CVS.

In cvs are now: libvisual, libvisual-xmms, libvisual-plugins.

We (especially Duilio with his auto* kung-fu powers) are fixing up the
build trees to support automake-1.8 and friends, when that is done we
will be doing a new release and hopefully cleanup the previous mess I've
left behind :)

I must admit that my spare time will be drasticly shorter for the
upcoming weeks because I'm being employed for production work in a
fabric. On the bright side, this will give me more than anough money for
a great vacation in Greece ;)

Cheers,
Dennis

Re: [Libvisual-devel] Re: infinity plugin

[Dennis S. <sy...@yo...>]

On Sun, 2004-06-20 at 12:44 -0300, Duilio Javier Protti wrote:
> Dennis wrote:
> > Your new 0.5.7 release of infinity is working great!, The colors are
> > right however resize seems to be broken.
> 
> I have fixed that right now. Thanks.
> 
> > I'm curious how you've fixed the issue with xmms FP, infinity xmms
> > clash.
> 
> Really that was not fixed, I just have disabled the MMX support
> by default. There is no way to synchronize with XMMS when using
> MMX registers, i.e. lock them or avoid context switch.
> The only way will be to run the library on a different process, 
> this way the O.S. will save registers on context switch. However,
> for this to work, XMMS must launch the plugin on a different 
> process, I cannot do that within Infinity.
> 
> Take this into account if you are planing to use MMX extensions
> on Libvisual.

Yeah it seems, the reason goom runs flawlessly is ofcourse because it
uses sse when available, and seen sse has it's own registers it isn't
clashing with that of the FPU. It might be fixed when you're not running
in a thread because you won't have two execution paths. But we really
don't want that because of the obvious reason.

Cheers,
Dennis

[Libvisual-devel] Re: infinity plugin

[Duilio J. P. <dp...@fc...>]

Dennis wrote:
> Your new 0.5.7 release of infinity is working great!, The colors are
> right however resize seems to be broken.

I have fixed that right now. Thanks.

> I'm curious how you've fixed the issue with xmms FP, infinity xmms
> clash.

Really that was not fixed, I just have disabled the MMX support
by default. There is no way to synchronize with XMMS when using
MMX registers, i.e. lock them or avoid context switch.
The only way will be to run the library on a different process, 
this way the O.S. will save registers on context switch. However,
for this to work, XMMS must launch the plugin on a different 
process, I cannot do that within Infinity.

Take this into account if you are planing to use MMX extensions
on Libvisual.


Duilio.

Re: [Libvisual-devel] Re: libvisual

[Dennis S. <sy...@yo...>]

On Sun, 2004-06-20 at 11:03 -0300, Duilio Javier Protti wrote:
> > Isn't it safer to not use symlinks for the final package ?
> The 'dist' target will not copy the symlinks, but the
> files which are pointed by the symlinks
> 
> > To include the headers next time in dist I should add them to the
> > sources right ?
> Yes. That will cause also that when you modify some header,
> 'make' will detect that and will rebuild targets that depend
> on that header.

Oooh was this supported by automake 1.4 as well ? sounds good and
I will be fixing that, however I've mailed you a few issues, could
you take a look at it ?

[Libvisual-devel] Re: libvisual

[Duilio J. P. <dp...@fc...>]

> Isn't it safer to not use symlinks for the final package ?
The 'dist' target will not copy the symlinks, but the
files which are pointed by the symlinks

> To include the headers next time in dist I should add them to the
> sources right ?
Yes. That will cause also that when you modify some header,
'make' will detect that and will rebuild targets that depend
on that header.


Duilio.

Re: [Libvisual-devel] Re: libvisual

[Dennis S. <sy...@yo...>]

On Sat, 2004-06-19 at 23:20 -0300, Duilio Javier Protti wrote:
> > Ok great, This works like a charm, is it better to use symlinks
> > for programs like depcomp, install-sh etc etc ?
> 
> symlinks are better to save some disk space, and to point to the
> last version.

Isn't it safer to not use symlinks for the final package ?

> > It would be superB if you could also port both libvisual-plugins
> > to automake-1.8, 
> 
> I have been working on that. However, due to the broken distro
> (all the headers are missing), I cannot full-test the building
> process. I will send you the updated package and you must
> copy the headers and test it.

To include the headers next time in dist I should add them to the
sources right ?

> > I will also move the current ChangeLog to NEWS and then we can use
> > the ChangeLog as a real per commit base ChangeLog.
> 
> mhmm... I think the current ChangeLog is right for CVS,
> and NEWS file must kept info on a per-release basis.
Yep.

I'll try to get libvisual into sf.net cvs today and when everything is
fixed dist wise, we'll be doing a new release to fix my previous major
screw up... Do you agree with this ?

Cheers,
Dennis

[Libvisual-devel] Re: libvisual

[Duilio J. P. <dp...@fc...>]

> Ok great, This works like a charm, is it better to use symlinks
> for programs like depcomp, install-sh etc etc ?

symlinks are better to save some disk space, and to point to the
last version.

> It would be superB if you could also port both libvisual-plugins
> to automake-1.8, 

I have been working on that. However, due to the broken distro
(all the headers are missing), I cannot full-test the building
process. I will send you the updated package and you must
copy the headers and test it.

> I will also move the current ChangeLog to NEWS and then we can use
> the ChangeLog as a real per commit base ChangeLog.

mhmm... I think the current ChangeLog is right for CVS,
and NEWS file must kept info on a per-release basis.


Duilio.

Re: [Libvisual-devel] Re: libvisual

[Dennis S. <sy...@yo...>]

On Sat, 2004-06-19 at 20:50 -0300, Duilio Javier Protti wrote:

Ok great, This works like a charm, is it better to use symlinks
for programs like depcomp, install-sh etc etc ?

It would be superB if you could also port both libvisual-plugins
to automake-1.8, when that is there i'll fix that what i've screwed
up (doh doh doh) and then check the right files into CVS
(and ofcourse exclude that what is auto generated)

I will also move the current ChangeLog to NEWS and then we can use
the ChangeLog as a real per commit base ChangeLog.

When that is done, I'll do a new release and we can start hacking
on new exciting stuff!

Thanks a lot,
Dennis


> Don't worry about the warnings in regard of AC_CANONICAL_TARGET
> and AC_ARG_PROGRAM, this is because AM_PATH_SDL macro is very
> old. We cannot (must not) change it, only Lantinga.
> 
> The error is because, like you see, aclocal.m4 is unchanged.
> These M4 macros must be recreated by automake 1.8. Just remove
> aclocal.m4, and run again autogen.sh. If the script don't 
> rebuild the file, run aclocal first.
> 
> The aclocal.m4 file must not be submitted to the CVS repository.
> 
> 
> Duilio.

[Libvisual-devel] Re: libvisual

[Duilio J. P. <dp...@fc...>]

El s=C3=A1b, 19 de 06 de 2004 a las 17:14, Dennis Smit escribi=C3=B3:
> Heya!
>=20
> I'm still having problems with auto*, I installed automake-1.8 and when
> running ./autogen.sh it gives:
>=20
> :/usr/src/libvis-duilo/libvisual-xmms-0.1.5# ./autogen.sh
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal  --output=3Daclocal.m4t
> autoreconf: `aclocal.m4' is unchanged
> autoreconf: configure.ac: tracing
> configure.ac:52: warning: AC_ARG_PROGRAM was called before
> AC_CANONICAL_TARGET
> autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from...
> configure.ac:52: AC_CANONICAL_TARGET is required by...
> aclocal.m4:7426: AM_PATH_SDL is expanded from...
> configure.ac:52: the top level
> autoreconf: running: libtoolize --force
> autoreconf: running: /opt/gtk2/bin/autoconf --force
> configure.ac:52: warning: AC_ARG_PROGRAM was called before
> AC_CANONICAL_TARGET
> autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from...
> configure.ac:52: AC_CANONICAL_TARGET is required by...
> aclocal.m4:7426: AM_PATH_SDL is expanded from...
> configure.ac:52: the top level
> autoreconf: running: /opt/gtk2/bin/autoheader --force
> configure.ac:52: warning: AC_ARG_PROGRAM was called before
> AC_CANONICAL_TARGET
> autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from...
> configure.ac:52: AC_CANONICAL_TARGET is required by...
> aclocal.m4:7426: AM_PATH_SDL is expanded from...
> configure.ac:52: the top level
> autoreconf: running: automake --add-missing --force-missing
> configure.ac:52: warning: AC_ARG_PROGRAM was called before
> AC_CANONICAL_TARGET
> autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from...
> configure.ac:52: AC_CANONICAL_TARGET is required by...
> aclocal.m4:7426: AM_PATH_SDL is expanded from...
> configure.ac:52: the top level
> configure.ac:5: version mismatch.  This is Automake 1.8.5,
> configure.ac:5: but the definition used by this AM_INIT_AUTOMAKE
> configure.ac:5: comes from Automake 1.4-p6.  You should recreate
> configure.ac:5: aclocal.m4 with aclocal and run automake again.
> /usr/share/automake-1.8/am/depend2.am: am__fastdepCC does not appear in
> AM_CONDITIONAL
> /usr/share/automake-1.8/am/depend2.am: AMDEP does not appear in
> AM_CONDITIONAL
> autoreconf: automake failed with exit status: 63
>=20
>=20
> I really appreciate your help btw!! thanks a lot
>=20
> Cheers,
> Dennis
>=20

Don't worry about the warnings in regard of AC_CANONICAL_TARGET
and AC_ARG_PROGRAM, this is because AM_PATH_SDL macro is very
old. We cannot (must not) change it, only Lantinga.

The error is because, like you see, aclocal.m4 is unchanged.
These M4 macros must be recreated by automake 1.8. Just remove
aclocal.m4, and run again autogen.sh. If the script don't=20
rebuild the file, run aclocal first.

The aclocal.m4 file must not be submitted to the CVS repository.


Duilio.

Re: [Libvisual-devel] libvisual 0.1.4 release problems.

[Dennis S. <sy...@yo...>]

On Sat, 2004-06-19 at 13:06 -0700, David Braaten wrote:
> In the libvisual package:
> the 'examples' and 'tests' subfolders are missing.
> 
> In the libvisual_plugins package:
> missing plugins/actor/JESS/*.h
> missing plugins/actor/infinite/*.h
> missing plugins/actor/oinskie/*.h
> missing plugins/actor/lv_analyzer/ directory
> missing plugins/actor/video_test/ directory
> 
> In the libvisual_xmms package:
> missing src/lv_xmms.h
> 
> You will need to make a new release so we can build
> libvisual and add spells to SMGL
> (http://www.sourcemage.org)
> 
> and maybe testing your release before posting it is
> an idea... ;)

I majorly screwed up for sure :) Duilo is rebuilding
the libvisual packages for automake-1.8 which, with some
luck will be done this weekend. Then I'll do another release.

Sorry for the inconvience