mxflib-developers — All MXFLib developers

[Mxflib-developers] MFXLib build on OSX

[Patrick C. <pat...@ma...>]

I am trying to build MFXLib on OSX 10.9 64 bit. It appears that fstat64 is deprecated on OSX, although it is available. Otherwise, there are a few actual errors that I don’t quite understand, and I hoped that you could provide some clarity.

Thanks,

Patrick

Patricks-MacBook-Pro-2:mxflib-master-2 patrickcusack$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in mxflib
if g++ -DHAVE_CONFIG_H  -I..   -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DDEFAULT_DICT_PATH=\"/usr/local/share/mxflib\" -Wall -g -O2 -MT crypto.o -MD -MP -MF ".deps/crypto.Tpo" -c -o crypto.o crypto.cpp; \
	then mv -f ".deps/crypto.Tpo" ".deps/crypto.Po"; else rm -f ".deps/crypto.Tpo"; exit 1; fi
In file included from crypto.cpp:31:
In file included from ../mxflib/mxflib.h:42:
../mxflib/system.h:546:69: warning: 'fstat64' is deprecated: first deprecated in OS X 10.6 [-Wdeprecated-declarations]
        inline Int64 FileSize(FileHandle file) { struct stat64 buf; return fstat64(fileno(file), &buf) != 0 ? -1 : buf.st_size; } 
                                                                           ^
/usr/include/sys/stat.h:378:5: note: 'fstat64' has been explicitly marked deprecated here
int     fstat64(int, struct stat64 *) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_5,__MAC_10_6,__IPHONE_NA,__IPHONE_NA);
        ^
In file included from crypto.cpp:31:
In file included from ../mxflib/mxflib.h:88:
../mxflib/smartptr.h:667:48: error: member reference base type 'SmartPtr<T> *' is not a structure or union
                bool operator<(SmartPtr &Other) { return this.operator<(*Other->GetPtr()); }
                                                         ~~~~^~~~~~~~~~
In file included from crypto.cpp:31:
In file included from ../mxflib/mxflib.h:117:
../mxflib/mxffile.h:108:25: error: extra qualification on member 'ReadMasterPartition'
                PartitionPtr MXFFile::ReadMasterPartition(Length MaxScan, bool CheckForCompleteFooter = false);
                             ~~~~~~~~~^
In file included from crypto.cpp:31:
In file included from ../mxflib/mxflib.h:121:
../mxflib/essence.h:1578:16: warning: 'mxflib::EssenceSubSource::Use' hides overloaded virtual function [-Woverloaded-virtual]
                virtual void Use(WrappingOptionPtr WrapOpt)
                             ^
../mxflib/essence.h:247:16: note: hidden overloaded virtual function 'mxflib::EssenceSource::Use' declared here: type mismatch at 1st parameter ('WrappingOptionPtr &'
      (aka 'SmartPtr<mxflib::WrappingOption> &') vs 'WrappingOptionPtr' (aka 'SmartPtr<mxflib::WrappingOption>'))
                virtual bool Use(WrappingOptionPtr &UseWrapping)
                             ^
2 warnings and 2 errors generated.
make[2]: *** [crypto.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

[Mxflib-developers] help needed

[paul m. <pau...@ya...>]

helloi am new to mxf , i don't know the format and the api of mxflib too well but i would like to write a simple app that reads an mxf file in memory , dump the content and it writes in a new mxf file the whole content of the input file 
please help me with this task beacuse i don't get along with the writing api of mxflib.please send me hints or even a code snapshotthank you 
paul

[Mxflib-developers] Building on Mac OS X 10.8.5

[Vincent O. <vi...@up...>]

Hi!

I'm trying to build MXFLib on Mac OS X 10.8.5 and I'm getting this error. Can anyone help, please? Regards.


Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

make  all-recursive
Making all in mxflib
if g++ -DHAVE_CONFIG_H  -I..   -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DDEFAULT_DICT_PATH=\"/usr/local/share/mxflib\" -Wall -g -O2 -MT crypto.o -MD -MP -MF ".deps/crypto.Tpo" \
	  -c -o crypto.o `test -f 'crypto.cpp' || echo './'`crypto.cpp; \
	then mv -f ".deps/crypto.Tpo" ".deps/crypto.Po"; \
	else rm -f ".deps/crypto.Tpo"; exit 1; \
	fi
In file included from crypto.cpp:31:
In file included from ../mxflib/mxflib.h:85:
../mxflib/smartptr.h:506:48: error: member reference base type 'SmartPtr<T> *' is not a structure or union
                bool operator<(SmartPtr &Other) { return this.operator<(*Other->GetPtr()); }
                                                         ~~~~^~~~~~~~~~
In file included from crypto.cpp:31:
In file included from ../mxflib/mxflib.h:105:
../mxflib/metadata.h:367:8: warning: 'mxflib::DMSegment::MakeLink' hides overloaded virtual functions [-Woverloaded-virtual]
                bool MakeLink(MDObjectPtr DMFramework);
                     ^
../mxflib/metadata.h:165:16: note: hidden overloaded virtual function 'mxflib::Component::MakeLink' declared here
                virtual bool MakeLink(TrackPtr SourceTrack, Int64 StartPosition = 0) { return false; }
                             ^
../mxflib/metadata.h:169:16: note: hidden overloaded virtual function 'mxflib::Component::MakeLink' declared here
                virtual bool MakeLink(UMIDPtr LinkUMID, UInt32 LinkTrackID, Int64 StartPosition = 0) { return false; }
                             ^
1 warning and 1 error generated.
make[2]: *** [crypto.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Re: [Mxflib-developers] Reading MXF Files from Panasonic P2?

[Matt B. <ma...@be...>]

Hi,

It seems from the link that ffmpeg is using MXFTk.

This is the mailing list for MXFLib developers.

However...

It seems that the problem should be quite easy to solve if you can get
MXFTk to give you access to the single clip-wrapped essence KLV. DV is
CBR (constant-bit-rate) so each frame of DV is exactly the same size.
You could then easily read 1 frame at a time without needing to do any
parsing of the stream.

Matt


On 13/03/2008, Richard Spindler <ric...@gm...> wrote:
> Hi,
>
>  I have a little problem here, and I though that the right people to
>  help my out with this might be on this list.
>
>  I am programming a little video editing software at:
>  http://www.openmovieeditor.org/
>  And I had a couple of friends ask me about how they can read footage
>  from their HVX200 Camera on Linux. But unfortunatly I couldn't help
>  them.
>
>  The ffmpeg project has limited support for Codecs embedded in MXF, but
>  it does not work for that particular kind of file:
>  http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/40655
>
>  I've tried to understand how to work with mxf, but it appears to me
>  that it also handles a lot of stuff that I am not particularly
>  interested in, I just want to import videos from p2 cards (DVCPRO50
>  only for now), for playback and editing.
>
>  I would like to submit a patch to ffmpeg to fix that feature, but the
>  MXF stuff is just overwhelming and I don't know where to start, as I'd
>  rather not dig through piles of documentation that might be only
>  mildly related to what I want to do.
>
>
>  So, can anyone point me into the right direction and just give me some
>  clues about what I would need to know to do this, and where I would
>  find this information?
>
>  I would also like to get into contact with anyone how would like to
>  have P2 MXF in ffmpeg, or who would like to help out with making this
>  happen. :-)
>
>
>  Thank you so much,
>  Cheers,
>  and have fun
>  -Richard
>
>  PS.: Sorry, if this might be a little Off-Topic, no offense intended. :-)
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Mxflib-developers mailing list
>  Mxf...@li...
>  https://lists.sourceforge.net/lists/listinfo/mxflib-developers
>
>
>

[Mxflib-developers] Reading MXF Files from Panasonic P2?

[Richard S. <ric...@gm...>]

Hi,

I have a little problem here, and I though that the right people to
help my out with this might be on this list.

I am programming a little video editing software at:
http://www.openmovieeditor.org/
And I had a couple of friends ask me about how they can read footage
from their HVX200 Camera on Linux. But unfortunatly I couldn't help
them.

The ffmpeg project has limited support for Codecs embedded in MXF, but
it does not work for that particular kind of file:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/40655

I've tried to understand how to work with mxf, but it appears to me
that it also handles a lot of stuff that I am not particularly
interested in, I just want to import videos from p2 cards (DVCPRO50
only for now), for playback and editing.

I would like to submit a patch to ffmpeg to fix that feature, but the
MXF stuff is just overwhelming and I don't know where to start, as I'd
rather not dig through piles of documentation that might be only
mildly related to what I want to do.


So, can anyone point me into the right direction and just give me some
clues about what I would need to know to do this, and where I would
find this information?

I would also like to get into contact with anyone how would like to
have P2 MXF in ffmpeg, or who would like to help out with making this
happen. :-)


Thank you so much,
Cheers,
and have fun
-Richard

PS.: Sorry, if this might be a little Off-Topic, no offense intended. :-)

[Mxflib-developers] HOWTO find a frame which is out of order?

[<zhu...@16...>]

Hi,
   I am a freshman in using mxflib.I would be interested to support mxf in my player.
   who can tell me how to find out a frame which is out of order.
   Thanks
 
Zhu Jiaqi

[Mxflib-developers] Intel Mac compilation

[Matt B. <ma...@be...>]

Has anyone yet tried MXFLib under Mac OS X on an Intel Mac?

I would be interested to know if the current version works properly on this
platform.

Thanks,

Matt Beard

[Mxflib-developers] mxflib 0.5.2.1.2(development)

[Oliver M. <ol...@me...>]

HEAD is now 0.5.2.x.2(Development)

from NEWS:

Changes for 0.5.2.1.2(Development)
==================================

Optional compile-time dictionary (run-time dictionary still preferred)
Autogen from xmldict.xml and types.xml with new dictconvert project
See mxfdump.cpp for how to use (#define COMPILED_DICT)

Optional use of Expat to get wide character support (#define HAVE_EXPAT)
Needs ../expat/lib/* static libraries from expat 1.95.8

UInt (still legacy support for Uint)


regards
Oliver and Matt

[Mxflib-developers] FLTK GUI toolkit

[Robin R. <ro...@Mo...>]

Hi. Just joined the list. See in the forums there was a question about GUI 
toolkits back in April. Do you still want info on that?

I lead the CinePaint project, the most popular open source tool in the 
motion picture industry. CinePaint was originally based upon GIMP and 
therefore uses GTK. CinePaint is being rewritten to use FLTK instead. Did a 
lot of research on toolkits before taking this drastic step. FLTK, the Fast 
Light Toolkit, lives up to it's name. Much smaller than other toolkits like 
GTK. It is also the only toolkit that was developed by the film industry, 
created by Digital Domain as the toolkit for the successful compositor NUKE. 
FLTK supports Linux, Windows, and Mac. License is LGPL.

More info:

www.fltk.org.
http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK

Hope this helps,

Robin
-------------------------------------------------------------------
Rob...@Mo...   Beverly Hills, California
www.CinePaint.org - Open source digital motion picture software


--- original message ---

Matt Beard
Joined: 15 Apr 2004
Location: Scotland
Posted: Fri Apr 16, 2004 6:55 am    Post subject: Cross-platform GUIs

At present the example applications supplied with MXFLib are all 
command-line utilities. At some stage it would be useful to provide some GUI 
applications, however as cross-platform support and truly open licensing are 
key to MXFLib the choice of tool-kit is important.

Please post your views on candidate cross-platform C++ GUI toolkits. 

Re: [Mxflib-developers] Re: getchar() before exit...

[Oliver M. <ol...@me...>]

OK=0D
=0D
Can we move swiftly to implement -q -v and -z=0D
And make the behaviour of -v (plain) to set DebugFlag =3D ~(Uint64)0=0D
=0D
Agree that degub is stdout, warnings and errors are stderr=0D
=0D
thanks=0D
Oliver=0D
=0D
On Wed Nov 10  2:40 , 'Matt Beard' <ma...@be...> sent:=0D
=0D
>=0D
>----- Original Message -----=0D
>From: Oliver Morgan ol...@me...>=0D
>To: mxf...@li...=0D
>Subject: [Mxflib-developers] Re: getchar() before exit...=0D
>Date: Tue, 09 Nov 2004 14:17:58 -0600=0D
>=0D
>> =0D
>> Fine on making default not getchar(), providing an option can reenable i=
t.=0D
>> =0D
>> I was aiming for the following other behaviours consistet across all app=
s:=0D
>> =0D
>> -q	quiet:=0D
>> 	never writes to stdout=0D
>> 	writes errors to stderr=0D
>> 	sets exit code on errors and warnings=0D
>=0D
>Sounds a good idea.=0D
>=0D
>> =0D
>> (none)default:=0D
>> 	writes sparsely to stdout=0D
>> 	writes errors warnings and config to stderr=0D
>> 	sets exit code on errors and warnings=0D
>=0D
>Also sounds a good idea.=0D
>=0D
>> =0D
>> -v	verbose:=0D
>> 	writes verbosely to stdout=0D
>> 	writes errors warnings and config to stderr=0D
>> 	sets exit code on errors and warnings=0D
>=0D
>Yes, but I would like to go further (but it would take a bit of work to ac=
hieve).  I would like to =0D
have a 64-bit variable that holds a set of debug flags. For example bit 0 s=
et will produce XML-parser =0D
debug, bit 1 will produce dictionary loader debug, bit 2 will produce smart=
 pointer debug etc... One =0D
section of bits will be reserved for the application and the rest for the l=
ibrary. debug messages =0D
would change to:=0D
>=0D
>  debug( DEBUG_SMARTPTR, "Incrementing reference to %d\n", Count );=0D
>=0D
>The verbose flag would be -v (set default set of flags decided by the app)=
 or -v=3D0x00f0c3070 (set a =0D
complex set of debug flags) or maybe even -v=3DSMARTPTR|DICT|XML (to debug =
smart pointers, dictionary =0D
loading and XML parsing)=0D
>=0D
>> =0D
>> Questions: is the proposed -z orthogonal to this? Or could it be seen as=
 a "very verbose" (-vv) =0D
level? My vote would be for -vv=0D
>=0D
>I see -z being orthogonal. There may be times that a pause is required, bu=
t debug isn't. -vv may =0D
simply be -v=3D0xffffffffffffffff.=0D
>=0D
>Also it seems that some embedded systems may not cope with getchar() at al=
l (yuck!) so maybe we gain =0D
a new function in system.h of the form PauseForInput() which will print a p=
rompt and wait - or on =0D
embedded systems wait for some other form of input.=0D
>=0D
>> =0D
>> Another: how does this relate to #ifdef MXFLIB_DEBUG and the mxflib::deb=
ug() function? The present =0D
code seems to imply that debug =0D
>> messages are only output by mxflib::debug() if both -v and MXFLIB_DEBUG.=
 Is that what we want?=0D
>> =0D
>=0D
>The idea is that debug messages will only be produced when -v is set, but =
all debug messages can be =0D
removed by not defining MXFLIB_DEBUG. The result is that both MXFLIB_DEBUG =
and -v are required to get =0D
debug. Why? Because the runtime test is done after putting together much of=
 the debug info so even =0D
with -v not supplied most of the CPU cycles are still used. When MXFLIB_DEB=
UG is not defined the debug =0D
code does not get compiled in.  For example:=0D
>=0D
>  debug("Length of %s is %s\n", Object->Name().c_str(), Int64toString(Obje=
ct->Size()).c_str());=0D
>=0D
>...will still build a string version of the 64-bit size and extract buffer=
 pointers to this and the =0D
string containing the object name and passing them to the debug function wh=
ich simply discards them.=0D
>=0D
>> Should mxflib::debug use vfprintf(stderr, Fmt, args)?=0D
>> Should mxflib::warning use vfprintf(stderr, Fmt, args)?=0D
>> Should mxflib::error use vfprintf(stderr, Fmt, args)?=0D
>> =0D
>=0D
>mxflib::debug use vfprintf(STDOUT, Fmt, args)=0D
>mxflib::warning use vfprintf(stderr, Fmt, args)=0D
>mxflib::error use vfprintf(stderr, Fmt, args)=0D
>=0D
>Two important reasons why debug messages should go to stdout... firstly th=
ey are not errors, they are =0D
debug, but secondly stdout can easily be redirected, stderr can't.  Debug p=
roduces loads of output and =0D
will often need to be captured to a file for processing.=0D
>=0D
>> thanks=0D
>> Oliver=0D
>> =0D
>> =0D
>> -------------------------------------------------------=0D
>> This SF.Net email is sponsored by:=0D
>> Sybase ASE Linux Express Edition - download now for FREE=0D
>> LinuxWorld Reader's Choice Award Winner for best database on Linux.=0D
>> http://ads.osdn.com/\?ad_idU88&alloc_id=12065&op=3Dclick=0D
>> _______________________________________________=0D
>> Mxflib-developers mailing list=0D
>> Mxf...@li...=0D
>> https://lists.sourceforge.net/lists/listinfo/mxflib-developers=0D
>> =0D
>=0D
>=0D
>=0D
>-------------------------------------------------------=0D
>This SF.Net email is sponsored by:=0D
>Sybase ASE Linux Express Edition - download now for FREE=0D
>LinuxWorld Reader's Choice Award Winner for best database on Linux.=0D
>http://ads.osdn.com/\?ad_idU88&alloc_id=12065&op=3Dclick=0D
>_______________________________________________=0D
>Mxflib-developers mailing list=0D
>Mxf...@li...=0D
>https://lists.sourceforge.net/lists/listinfo/mxflib-developers=0D
=0D
=0D

Re: [Mxflib-developers] Re: getchar() before exit...

[Matt B. <ma...@be...>]

----- Original Message -----
From: Oliver Morgan <ol...@me...>
To: mxf...@li...
Subject: [Mxflib-developers] Re: getchar() before exit...
Date: Tue, 09 Nov 2004 14:17:58 -0600

>=20
> Fine on making default not getchar(), providing an option can reenable it.
>=20
> I was aiming for the following other behaviours consistet across all apps:
>=20
> -q	quiet:
> 	never writes to stdout
> 	writes errors to stderr
> 	sets exit code on errors and warnings

Sounds a good idea.

>=20
> (none)default:
> 	writes sparsely to stdout
> 	writes errors warnings and config to stderr
> 	sets exit code on errors and warnings

Also sounds a good idea.

>=20
> -v	verbose:
> 	writes verbosely to stdout
> 	writes errors warnings and config to stderr
> 	sets exit code on errors and warnings

Yes, but I would like to go further (but it would take a bit of work to ach=
ieve).  I would like to have a 64-bit variable that holds a set of debug fl=
ags. For example bit 0 set will produce XML-parser debug, bit 1 will produc=
e dictionary loader debug, bit 2 will produce smart pointer debug etc... On=
e section of bits will be reserved for the application and the rest for the=
 library. debug messages would change to:

  debug( DEBUG_SMARTPTR, "Incrementing reference to %d\n", Count );

The verbose flag would be -v (set default set of flags decided by the app) =
or -v=3D0x00f0c3070 (set a complex set of debug flags) or maybe even -v=3DS=
MARTPTR|DICT|XML (to debug smart pointers, dictionary loading and XML parsi=
ng)

>=20
> Questions: is the proposed -z orthogonal to this? Or could it be seen as =
a "very verbose" (-vv) level? My vote would be for -vv

I see -z being orthogonal. There may be times that a pause is required, but=
 debug isn't. -vv may simply be -v=3D0xffffffffffffffff.

Also it seems that some embedded systems may not cope with getchar() at all=
 (yuck!) so maybe we gain a new function in system.h of the form PauseForIn=
put() which will print a prompt and wait - or on embedded systems wait for =
some other form of input.

>=20
> Another: how does this relate to #ifdef MXFLIB_DEBUG and the mxflib::debu=
g() function? The present code seems to imply that debug=20
> messages are only output by mxflib::debug() if both -v and MXFLIB_DEBUG. =
Is that what we want?
>=20

The idea is that debug messages will only be produced when -v is set, but a=
ll debug messages can be removed by not defining MXFLIB_DEBUG. The result i=
s that both MXFLIB_DEBUG and -v are required to get debug. Why? Because the=
 runtime test is done after putting together much of the debug info so even=
 with -v not supplied most of the CPU cycles are still used. When MXFLIB_DE=
BUG is not defined the debug code does not get compiled in.  For example:

  debug("Length of %s is %s\n", Object->Name().c_str(), Int64toString(Objec=
t->Size()).c_str());

...will still build a string version of the 64-bit size and extract buffer =
pointers to this and the string containing the object name and passing them=
 to the debug function which simply discards them.

> Should mxflib::debug use vfprintf(stderr, Fmt, args)?
> Should mxflib::warning use vfprintf(stderr, Fmt, args)?
> Should mxflib::error use vfprintf(stderr, Fmt, args)?
>=20

mxflib::debug use vfprintf(STDOUT, Fmt, args)
mxflib::warning use vfprintf(stderr, Fmt, args)
mxflib::error use vfprintf(stderr, Fmt, args)

Two important reasons why debug messages should go to stdout... firstly the=
y are not errors, they are debug, but secondly stdout can easily be redirec=
ted, stderr can't.  Debug produces loads of output and will often need to b=
e captured to a file for processing.

> thanks
> Oliver
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> _______________________________________________
> Mxflib-developers mailing list
> Mxf...@li...
> https://lists.sourceforge.net/lists/listinfo/mxflib-developers
>=20

[Mxflib-developers] Re: getchar() before exit...

[Oliver M. <ol...@me...>]

Fine on making default not getchar(), providing an option can reenable it.=
=0D
=0D
I was aiming for the following other behaviours consistet across all apps:=
=0D
=0D
-q	quiet:=0D
	never writes to stdout=0D
	writes errors to stderr=0D
	sets exit code on errors and warnings=0D
=0D
(none)default:=0D
	writes sparsely to stdout=0D
	writes errors warnings and config to stderr=0D
	sets exit code on errors and warnings=0D
=0D
-v	verbose:=0D
	writes verbosely to stdout=0D
	writes errors warnings and config to stderr=0D
	sets exit code on errors and warnings=0D
=0D
Questions: is the proposed -z orthogonal to this? Or could it be seen as a =
"very verbose" (-vv) level? My vote would be for -vv=0D
=0D
Another: how does this relate to #ifdef MXFLIB_DEBUG and the mxflib::debug(=
) function? The present code seems to imply that debug =0D
messages are only output by mxflib::debug() if both -v and MXFLIB_DEBUG. Is=
 that what we want?=0D
=0D
Should mxflib::debug use vfprintf(stderr, Fmt, args)?=0D
Should mxflib::warning use vfprintf(stderr, Fmt, args)?=0D
Should mxflib::error use vfprintf(stderr, Fmt, args)?=0D
=0D
thanks=0D
Oliver=0D

[Mxflib-developers] getchar() before exit...

[Matt B. <ma...@be...>]

It seems to be useful in some cases to have command-line applications pause=
 before exiting, but not always.

Therefore I propose that each of the mxflib applications gain a -z option t=
o cause "Press enter to continue" and to wait on getchar().

Any objections or comments?

Matt

[Mxflib-developers] MXFLib check-in locks

[Matt B. <ma...@be...>]

I have added a thread to the developers forum to allow developers to "lock" 
the CVS.

This is a procedural lock rather than being forced.  It is up to developers 
to check this thread to see if someone has added a lock before starting a 
large check-in. Small check-ins are unlikely to cause problems and CVS will 
look after that, but please use this procedure if you intend to make any 
major check-ins.  Also please don't forget to follow the "Rules for 
Changes" and "Coding Style" project documents at all times.

Thanks,

Matt

[Mxflib-developers] Proposed change to FileGetc

[Matt B. <ma...@be...>]

Developers,

I am planning a not-exactly-backwards-compatible change to the FileGetc() 
function.

Currently it is as follows:

   Uint8 FileGetc(FileHandle file) { Uint8 c; FileRead(file, &c, 1); return 
c; }

Returning the unsigned byte read, or random gack on EOF or another error.

I propose changing it to:

   int FileGetc(FileHandle file) { Uint8 c; return (FileRead(file, &c, 1) 
== 1) ? (int)c : EOF; }

Which will return the unsigned byte read as the bottom 8-bits of a signed 
(platform optimized) integer, or EOF if there is an error (including 
end-of-file).

I will also add this to the developers forum on SourceForge, please reply 
there rather than this list.

Matt

[Mxflib-developers] Smart Pointers

[Matt B. <ma...@be...>]

Guys,

A couple of issues regarding smart pointers...

Firstly I have been considering ways to reduce the overhead when using 
smart pointers and it seems that a lot of cycles can be saved by using 
references to pointers in function calls. This will save incrementing and 
decrementing the count with each call - there is no risk of the object 
needing to be deleted as the calling function will always hold a pointer to 
it.  This should be especially useful for in-lines as they will optimize 
out nicely.  The only things that are not safe (as far as I can tell) are 
storing references to smart pointers and passing references between threads 
- so don't do either.  I will gradually move functions to use references to 
pointers rather than pointers - this will not affect any calling code.

Secondly I have established how to safely use "polymorphic" smart 
pointers.  This can be done providing the base class derives from 
RefCount<> and none of the derived classes do.  Then a smart pointer to a 
base class can safely point to a derived class and the correct virtual 
functions will be called as expected.  However... if you do this please 
remember to include a virtual destructor or things can fall apart (as in 
normal c++).

On a related issue I have also added "SmartPtr_Cast" which allows you to 
cast a smart pointer to a pointer of a different type. Unfortunately it has 
to be a bit awkward as MSVC 6 doesn't cope well with template functions. 
Also both classes must be derived (directly or indirectly) from RefCount<> 
to ensure that the reference counting works.

Matt


P.S. All this is going on in the Develop-EssenceRead branch which will 
become 0.5-Beta at some stage.

[Mxflib-developers] Coding style

[Matt B. <ma...@be...>]

Guys,

I have added a document on coding style to the docs page on SourceForge.

Hopefully this will help keep the code as clean as possible.

Matt

[Mxflib-developers] Mailing list spam

[Matt B. <ma...@be...>]

Developers,

Please don't reply to any spam sent to this mailing list (it only 
encourages them!).

I am willing to enable the list blocking if everyone is happy for the list 
to be so restricted. Note that this will expect your e-mail address to be 
the one used for your list subscription (i.e. probably your SourceForge 
address) but I can add your main address as an allowed posted.

Matt

[Mxflib-developers] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [Mxflib-developers] Next release this weekend

[Stuart C. <st...@rd...>]

Unfortunately, Cygwin allows a choice of Unix or DOS style line endings
when you install it.  Choosing DOS CRLF line endings can cause
interoperability problems with source packages using autoconf/automake
since although GCC can cope with either line-endings, some of the shell
commands used in autoconf may be sensitive to line-endings.

Also, I committed a change to bootstrap.sh to make it work reliably with
the limited /bin/sh shell installed by default by Cygwin (fixes the
"line 14" error).

Stuart

On Wed, 2004-05-12 at 19:25, Matt Beard wrote:
> Not at the moment I can't!!   I cant access CVS from my Linux box and 
> autoconf/automake barfs on the windows line-ends!!
> 
> Cygwin barfs at line 14 of bootstrap.sh
> 
> Matt
> 
> 
> At 18:43 12/05/2004, Stuart Cunningham wrote:
> >I bumped the version number in configure.ac to 0.4.0.  Also I added a
> >zip target for "make dist".  All you need to do to produce both the .zip
> >and .tar.gz packages is:
> >   ./bootstrap.sh
> >   ./configure
> >   make dist
> >
> >You should get:
> >   355362  mxflib-alpha-0.4.0.zip
> >   279709  mxflib-alpha-0.4.0.tar.gz
> >
> >You can do this from Cygwin or a Unix/Linux/MacOSX box provided you have
> >autoconf and automake installed.
> >
> >Stuart
> >
> >On Wed, 2004-05-12 at 18:06, Matt Beard wrote:
> > > I intend to release mxflib-alpha-0.4.0 this weekend.  If you think there
> > > are any problems in doing so please squeek now or forever hold your peas.
> > >
> > > Obviously please don't check-in anything during the weekend as it might 
> > get
> > > half released!!
> > >
> > > Matt
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Sleepycat Software
> > > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> > > deliver higher performing products faster, at low TCO.
> > > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > > _______________________________________________
> > > Mxflib-developers mailing list
> > > Mxf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mxflib-developers
> 

Re: [Mxflib-developers] Next release this weekend

[Matt B. <ma...@be...>]

Not at the moment I can't!!   I cant access CVS from my Linux box and 
autoconf/automake barfs on the windows line-ends!!

Cygwin barfs at line 14 of bootstrap.sh

Matt


At 18:43 12/05/2004, Stuart Cunningham wrote:
>I bumped the version number in configure.ac to 0.4.0.  Also I added a
>zip target for "make dist".  All you need to do to produce both the .zip
>and .tar.gz packages is:
>   ./bootstrap.sh
>   ./configure
>   make dist
>
>You should get:
>   355362  mxflib-alpha-0.4.0.zip
>   279709  mxflib-alpha-0.4.0.tar.gz
>
>You can do this from Cygwin or a Unix/Linux/MacOSX box provided you have
>autoconf and automake installed.
>
>Stuart
>
>On Wed, 2004-05-12 at 18:06, Matt Beard wrote:
> > I intend to release mxflib-alpha-0.4.0 this weekend.  If you think there
> > are any problems in doing so please squeek now or forever hold your peas.
> >
> > Obviously please don't check-in anything during the weekend as it might 
> get
> > half released!!
> >
> > Matt
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> > deliver higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > _______________________________________________
> > Mxflib-developers mailing list
> > Mxf...@li...
> > https://lists.sourceforge.net/lists/listinfo/mxflib-developers

Re: [Mxflib-developers] Next release this weekend

[Stuart C. <st...@rd...>]

I bumped the version number in configure.ac to 0.4.0.  Also I added a
zip target for "make dist".  All you need to do to produce both the .zip
and .tar.gz packages is:
  ./bootstrap.sh
  ./configure
  make dist

You should get:
  355362  mxflib-alpha-0.4.0.zip
  279709  mxflib-alpha-0.4.0.tar.gz

You can do this from Cygwin or a Unix/Linux/MacOSX box provided you have
autoconf and automake installed.

Stuart

On Wed, 2004-05-12 at 18:06, Matt Beard wrote:
> I intend to release mxflib-alpha-0.4.0 this weekend.  If you think there 
> are any problems in doing so please squeek now or forever hold your peas.
> 
> Obviously please don't check-in anything during the weekend as it might get 
> half released!!
> 
> Matt
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Mxflib-developers mailing list
> Mxf...@li...
> https://lists.sourceforge.net/lists/listinfo/mxflib-developers

[Mxflib-developers] Next release this weekend

[Matt B. <ma...@be...>]

I intend to release mxflib-alpha-0.4.0 this weekend.  If you think there 
are any problems in doing so please squeek now or forever hold your peas.

Obviously please don't check-in anything during the weekend as it might get 
half released!!

Matt

RE: [Mxflib-developers] Coding style

[Oliver M. <ol...@me...>]

Actually, Sourceforge Bugs and RFE trackers are perfect for the job

Oliver

> -----Original Message-----
> From: mxf...@li... 
> [mailto:mxf...@li...] On 
> Behalf Of Matt Beard
> Sent: Tuesday, April 27, 2004 8:19 AM
> To: Stuart Cunningham; Oliver Morgan
> Cc: mxf...@li...
> Subject: RE: [Mxflib-developers] Coding style
> 
> 
> My usage of DRAGONS dates from 'The Arc' and has been 
> reasonably common in 
> some circles.  I can accept that the world has moved on a 
> little and it may 
> be worth updating to a more common version.
> 
> I suggest:
>    1) We leave all uncataloged DRAGONS as they are...
>    2) We sort out a cataloging system.  I think the 
> SourceForge bug tracker 
> could be used, but is perhaps a little cumbersome.  Any 
> better suggestions?
>    3) As each DRAGON is catalogued we turn it into a "TODO" 
> or "FIXME".
>    4) We consider a release policy at some stage...
> 
> Matt
> 
> 
> At 13:05 27/04/2004, Stuart Cunningham wrote:
> >Yes.  I think the most important cataloguing would be into 
> those areas
> >where there are potential bugs (or known bad behaviour) and 
> those areas
> >where there is missing functionality or optimisation needed.  Perhaps
> >during such a process we should mark such areas with "FIXME" 
> and "TODO"
> >respectively.
> >
> >Large projects like Gnome don't release a minor version until all
> >FIXMEs are fixed, and won't release a major version until all TODOs
> >are addressed.
> >
> >Stuart
> >
> >On Tue, 2004-04-27 at 12:54, Oliver Morgan wrote:
> > > More to the point: we need a concerted program to catalog 
> them, eliminate
> > > the worst, and eventually resolve all of them - whatever 
> they are called.
> > >
> > > Cataloguing them is easier if they are all marked the 
> same way. Consistency
> > > is good. "dragons" is as good as anything for now.
> > >
> > > Oliver
> > >
> > >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Mxflib-developers mailing list
> Mxf...@li...
> https://lists.sourceforge.net/lists/listinfo/mxflib-developers
> 

RE: [Mxflib-developers] Coding style

[Matt B. <ma...@be...>]

My usage of DRAGONS dates from 'The Arc' and has been reasonably common in 
some circles.  I can accept that the world has moved on a little and it may 
be worth updating to a more common version.

I suggest:
   1) We leave all uncataloged DRAGONS as they are...
   2) We sort out a cataloging system.  I think the SourceForge bug tracker 
could be used, but is perhaps a little cumbersome.  Any better suggestions?
   3) As each DRAGON is catalogued we turn it into a "TODO" or "FIXME".
   4) We consider a release policy at some stage...

Matt


At 13:05 27/04/2004, Stuart Cunningham wrote:
>Yes.  I think the most important cataloguing would be into those areas
>where there are potential bugs (or known bad behaviour) and those areas
>where there is missing functionality or optimisation needed.  Perhaps
>during such a process we should mark such areas with "FIXME" and "TODO"
>respectively.
>
>Large projects like Gnome don't release a minor version until all
>FIXMEs are fixed, and won't release a major version until all TODOs
>are addressed.
>
>Stuart
>
>On Tue, 2004-04-27 at 12:54, Oliver Morgan wrote:
> > More to the point: we need a concerted program to catalog them, eliminate
> > the worst, and eventually resolve all of them - whatever they are called.
> >
> > Cataloguing them is easier if they are all marked the same way. Consistency
> > is good. "dragons" is as good as anything for now.
> >
> > Oliver
> >
> >