headers
Victor STINNER | 3 Nov 2006 02:38

hachoir-parser version 0.6.1


Hi,

I fixed a dummy bug in EXIF metadata parser: SubFile import was missing. I
just release hachoir-parser 0.6.1 to fix it:
  http://cheeseshop.python.org/pypi/hachoir-parser

It's really easy to fix small bug using new file organisation:
  cd hachoir-parser
  svn co tags/hachoir-parser-0.6.0 tags/hachoir-parser-0.6.1
  svn ci
  cd tags/hachoir-parser-0.6.1
  (...edit...)
  svn ci
  ./setup.py register sdist bdist_egg register

I wasn't possible with Hachoir 0.5 organisation.

It's also possible to create small bugfix release using an old tag (0.6 =>
0.6.1). It's pratical since I added experimental parser (SWF parser) in
trunk.

*** Yes, Cyril, you was right. That's why I finally accepted your
suggestion ;-) **

Haypo

--

-- 
Victor STINNER
http://hachoir.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor STINNER | 5 Nov 2006 04:42

Tool to extract JPEG picture from SWF movies

Hi,

A just wrote a tool to extract JPEG pictures from SWF movies. It's
attached to this email (jpg_extractor.py). The code is really simple since
half of the complexity is in Hachoir and the other in SWF and JPEG parsers
:-)

Hachoir doesn't support compressed SWF files. You can use attached tool
(deflate_swf.py) to deflate them.

I tried on three different SWF files and it works really well :-)

You need Hachoir 1179 to use jpg_extractor.py.

Be careful to don't violate copyright using such tools...

Haypo
Attachment (jpg_extractor.py): application/x-python, 1114 bytes
Attachment (deflate_swf.py): application/x-python, 348 bytes
Permalink | Reply | 1 comment |
headers
Mike Melanson | 5 Nov 2006 04:49

Re: Tool to extract JPEG picture from SWF movies

Victor STINNER wrote:
> Hi,
> 
> A just wrote a tool to extract JPEG pictures from SWF movies. It's
> attached to this email (jpg_extractor.py). The code is really simple since
> half of the complexity is in Hachoir and the other in SWF and JPEG parsers
> :-)
> 
> Hachoir doesn't support compressed SWF files. You can use attached tool
> (deflate_swf.py) to deflate them.
> 
> I tried on three different SWF files and it works really well :-)
> 
> You need Hachoir 1179 to use jpg_extractor.py.
> 
> Be careful to don't violate copyright using such tools...

Nice work. I can't assist in this particular component (SWF) in any way, 
but still a good initiative.

--

-- 
	-Mike Melanson
Permalink | Reply | 0 comments |
headers
Victor STINNER | 6 Nov 2006 13:37

hachoir (core) 0.6.1

To apply "Release as soon as possible", here is a bugfix release of
hachoir core.

FakeArray was crapy :-) It's wasn't possible to read array[10] without
reading array[0] to array[9]. len(array) and bool(array) were also
missing.

What's new in Hachoir 0.6.1?
============================

Bugfixes:

 * Fix GenericString length attribute: wasn't initialized for UTF-* strings
 * Fix and improve FakeArray (created with fieldset.array("name"))

Improvements:

 * Add text_handler optional argument to Bits and RawBits
 * On name duplicate error (a field was same name already exists), add
"[]" to its name instead and display an error raising an exception

Minor changes:

 * Add class documentation to all types (PaddingBits, Float32, ...)
 * Fix reversed() code and __all__ constant in hachoir.compatiblity
 * Add available_types variable to hachoir.field (used by hachoir-wx)

Haypo
--

-- 
Victor STINNER
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yann Hodique | 7 Nov 2006 12:46
Face
Picon
Gravatar

0-length fields

Hello

I plan to write some tools for displaying/browsing/editing .class files
using hachoir. I've started to write the parser (that I would happily contribute
to hachoir-parser) and encountered a small issue.

In the .class format, there are often arrays expressed in the following form~:

    u2 exception_table_length;
    exception_info exception_table[exception_table_length];

Obviously, the attributes_count can be 0
The problem is, when it is 0, then the following code does not work

    yield UInt16(attr, "exception_table_length", "Exception table length")

    size = attr["exception_table_length"].value
    yield ExceptionTable(attr, "exception_table", size, "Exception table")

Instead I have to guard the second yield by

    if size != 0:
        yield ExceptionTable(attr, "exception_table", size, "Exception table")

It is a small annoyance, because this way the node "exception_table" simply doesn't
exist instead of having 0-length.
Am I missing something ?

Regards,
Yann.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Victor STINNER | 7 Nov 2006 13:38

Re: 0-length fields

Hi,

> I plan to write some tools for displaying/browsing/editing .class files
> using hachoir

Hey, exactly like Thomas :-) I attached his patch to this email. I can't
commit it now.

> I've started to write the parser (that I would happily
> contribute to hachoir-parser) and encountered a small issue.

Sure, don't hesitate to send me patches.

> In the .class format, there are often arrays expressed in the following
> form~:
>
>     u2 exception_table_length;
>     exception_info exception_table[exception_table_length];
>
> Obviously, the attributes_count can be 0

It's forbidden to create non-existent field, I mean field with nul size.
There is an exception: Link have nul size, but it's not a classic field
but a link to another field.

> Instead I have to guard the second yield by
>
>     if size != 0:
>         yield ExceptionTable(attr, "exception_table", size, "Exception
> table")
(Continue reading)

Permalink | Reply | 8 comments |
headers
Yann Hodique | 7 Nov 2006 15:03
Face
Picon
Gravatar

Re: 0-length fields

On  7 Nov 2006, Victor STINNER wrote:

> Hi,
>
>> I plan to write some tools for displaying/browsing/editing .class files
>> using hachoir
>
> Hey, exactly like Thomas :-) I attached his patch to this email. I can't
> commit it now.

Heh, what a small world: Thomas and I were in neighbor offices at the Irisa
some years ago :)
Ok, this is off-topic ^^

I'll have a look at it later, but of course it looks very similar to what
I wrote. If Thomas agrees we could avoid duplicating efforts working together
on it.

Yann.

--

-- 
Knowledge is pitiless.

  -- Orange Catholic Bible
Permalink | Reply | 0 comments |
headers
Cyril Zorin | 7 Nov 2006 17:02
Picon
Gravatar

Re: Re: 0-length fields

> Yesterday I was thinking on way to remove the "if": it would be
> interresting to allow "yield None" which would be like Python "pass" (no
> operation: do nothing). Example:
>   padding = self.seekByte(42)
>   if padding:
>       yield padding
> will become
>   yield self.seekByte(42)
> since seekByte() returns None if you're already at byte 42.

Do *not* do this. If you want to make the API more permissive, add a
new function that will do the check prior to calling the API function.

So this...

if blah:
  yield SomeType(...)

...turns to this:
yield_if(blah, SomeType(...))

You can work out the syntax/naming as you see fit to make sure that
SomeType only gets constructed if "blah" is valid.

My point is that we should not litter the API with paranoid checks for
"None" just because someone is feeling "inconvenienced" to write an
if-statement. If Yann wants calls to be more permissive, he can wrap
them himself. There is no reason to modify hachior core because of
this silly issue.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Yann Hodique | 7 Nov 2006 20:18
Face
Picon
Gravatar

Re: 0-length fields

On  7 Nov 2006, Cyril Zorin wrote:

> My point is that we should not litter the API with paranoid checks for
> "None" just because someone is feeling "inconvenienced" to write an
> if-statement. If Yann wants calls to be more permissive, he can wrap
> them himself. There is no reason to modify hachior core because of
> this silly issue.

I think I did not make my point clear : my problem with the required guard is
not (how) to write it. My problem is that having a 0-length field or no field
at all are completely different things (and both useful). I don't need some
syntactic sugar to wrap some construction I could write myself, I need support
for what seems a missing feature (0-length fields).

> On the semantic side of things, what's the point of having a field of
> size 0? Fields of size 0 don't exist, so they should not be presented
> by the parser.

I agree they don't have a physical existence because you don't need space to
store void. But from a logical point of view, they do exist (why wouldn't
they ?). If I consider a random method from a random class, does it make sense
to ask for the set of exceptions it may throw ? I think it does, but from your
point of view, I would be required to ask first if it throws at least one.
I mean, in every single language I can think about, arrays are not required to
have a strictly positive size :). Sure it would be possible to deal with them
that way, but what good would it be ?

It seems to me a better practice to *always* deal with an array (maybe without
elements in it) than dealing with either an array for 1+ elements or
nothing. The main reason is that it enables you to follow the spec directly, no
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cyril Zorin | 7 Nov 2006 20:35
Picon
Gravatar

Re: Re: 0-length fields

> I think I did not make my point clear : my problem with the required guard is
> not (how) to write it. My problem is that having a 0-length field or no field
> at all are completely different things (and both useful). I don't need some
> syntactic sugar to wrap some construction I could write myself, I need support
> for what seems a missing feature (0-length fields).

No. You need some syntactic sugar to wrap a construct, because
0-length fields do not make sense inside Hachoir. They make sense to
*you* in *your* particular case, but if we started editing features to
Hachoir just because spec XYZ requires it we'd be in a bit of a bind.

> I agree they don't have a physical existence because you don't need space to
> store void. But from a logical point of view, they do exist (why wouldn't

They do not exist in the data-observation world. They exist in the
schema world, so what you're looking for is a way to display the
schema of a .class file. Fields that exist in the format specification
(i.e. schema) but are not used in a particular file should not be
displayed. If there is no data, there is no need to say "hey this
field is empty" -- we already know it's empty, otherwise it would have
been displayed.

> they ?). If I consider a random method from a random class, does it make sense
> to ask for the set of exceptions it may throw ? I think it does, but from your
> point of view, I would be required to ask first if it throws at least one.

It makes sense to ask what exceptions it throws, and then you'd get an
empty list. Since the list is empty there is nothing to show, which is
why you have to check for that case.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane