[Luis EG Ontanon <luis@xxxxxxxxxxx>]

I wanted to add python support at first I just did not find the right
docs to do it. Perl is simply off... I do not think is a good
language for embeddng at all...

But perl is at lesat for me the most versatile language I've found.
It's true that it's too versatile that you often end up writing code
that just one day later you cannot read :) .

After having to deal with it for a while I just hapen not to like
python at all :). I do not like the extremely slow compilation, I do
not like the way scopes and variables are handled. But I  do like
ipython, I use it as my desk calculator on an everyday basis.

Keep on the good work.

On Mon, Jun 1, 2009 at 3:31 PM, Sébastien Tandel <sebastien@xxxxxxxxx> wrote:
> Hi Luis,
>
> I'm happy to see you're enthusiast! :)
>
>
> On Sun, May 31, 2009 at 22:01, Luis EG Ontanon <luis@xxxxxxxxxxx> wrote:
>>
>> I made the Lua bindings an application of the C API, not a simple
>> export. (e.g. proto_item and proto_tree are combined instead of dealt
>> individually, objects are managed in their scope so that deleted
>> objects are not accessed by Lua).
>
> As a rule of thumb, I'm trying to follow the C API but the main idea is of
> course to simplify whenever possible and write less code.
> That's why I'm not against following some parts of the LUA API. My main goal
> is to ease development for others people.
>
>> The reasons why I avoided just mapping the C API were many but all
>> focused on a single point: to make sure that a bug in lua code was
>> hanlded by lua's handler, not by a crash.
>
> For sure, that's something I have to work on :)
> Maybe I did not insist sufficiently on it but it's the *first step* to have
> a python binding with wireshark. There are a lot of things to do , features
> to add,  bugs to fix, etc...
>>
>> Another drive was simplyfing some wireshark concepts to make coding in
>> lua leaner, if it will take me the same number of lines to write code
>> in lua than it takes me to write it in C why not just write it in C.
>
> That's something I want to avoid too. And it's already rather concise, maybe
> not as concise as LUA is right now? maybe.
>
>> I had no python experience at the time and I had heard many good
>> things of it... Having dealt way too much (for my taste) with python
>> latelly now IMHO the only think which python does better than perl is
>> well indented code (the thing cannot even help you find a typo in the
>> name of a variable, closures are cumbersome, global variable usage is
>> painful at very least... as for java I do not understand why so many
>> people like it).
>
> OK, perl lover ... I was working with perl some years ago and I'm really
> happy to be able to avoid its use today!
> BUT my point is that if there were a binding in perl, it would be a good
> thing for wireshark because there are a lot of people using it. I just won't
> do it myself. In the same way, I do think that python is a good thing for
> wireshark too. At the end of the day, just a few people knows LUA. Even
> being in Brazil, country of origin of LUA, working for one of the largest
> brazilian IT company, people knows LUA because it's brazilian but nobody can
> (or want to) develop with it.
> After all, having a binding is not only for me or for other core people.
> Having a binding is to ease wirehark extension development for the rest of
> the community (mainly sysadmin and net guys). If we use an unknown language,
> like let's say D, it is of little interest because just an elite knows it.
> (and probably this elite won't even take a look at wireshark). I know that
> at the company I'm working in, sysadmin and net guys are using a way lot
> more python than perl, do not even think they could one day extend wireshark
> in C and as I already said LUA is just known by its name because of its
> origin. Therefore, what would you choose?
>
> Regards,
> Sebastien Tandel
>
>>
>> On Sun, May 31, 2009 at 10:41 PM, Sébastien Tandel <sebastien@xxxxxxxxx>
>> wrote:
>> > Hi Stig,
>> >
>> > First, I have to admit that I'm not really aware of the details of the
>> > defined LUA API. But as a rule of thumb, I tried to be close as possible
>> > to
>> > what exists in the C API (not LUA).
>> > Here is an informal description of what rules I tried to follow to
>> > create
>> > this API :
>> > 1) create objects as close as possible to the ones known in libwireshark
>> > There are three "obvious" objects until now : Dissector, Tree, TVB.
>> > 2) method name of each object as close as possible as the ones defined
>> > in
>> > libwireshark. I however modify the name because as C is not object, most
>> > of
>> > the time, a function includes in its name the conceptual "object" name
>> > related to it. This way, it avoids redundance in python API. For example
>> > :
>> > "proto_tree_add_item" is one method of the "tree" object in the C API.
>> > in
>> > the python API, the Tree class defines a "add_item" method. With the
>> > same
>> > idea for "tvb_get_ntohl", the method is defined in the TVB class with
>> > the
>> > name "get_ntohl".
>> > 3) formal parameters of functions :
>> >   a) first parameter is in general the "C object" and it does not make
>> > any
>> > sense to include it for the method defined in a python object. (in fact,
>> > in
>> > python it appears in the definition and "disappears" when called)
>> >   b) it might happen that some other parameters are always defined in
>> > the
>> > formal parameters of the C API but are not manipulated by the user and
>> > might
>> > be included automatically by the python API. For these ones, they also
>> > disappear from the formal parameters list of the python API.
>> >   c) if the parameter takes most of the time one value but sometimes can
>> > take another value, it is defined as an optional parameter.
>> >   d) if the parameter is totally or partially managed by the python API,
>> > it
>> > is defined as an optional parameter.
>> >   a good example is Tree.add_item(self, field, offset=0, length=-1,
>> > little_endian=False, adv=True)
>> >   the C API counterpart is : proto_tree_add_item(proto_tree, hfindex,
>> > tvb,
>> > start, length, little_endian)
>> >     - As of rule a), proto_tree is in fact the Tree object => disappear
>> > from
>> > the formal parameter list
>> >     - As of rule b), tvb is not directly manipulated by the user and
>> > therefore disappear from the formal parameter list
>> >     - As of rule c), little_endian has two possible value False or True.
>> > It
>> > becomes an optional parameter with the default value set to False.
>> >     - As of rule d), "offset" is totally managed by the API with the
>> > help of
>> > the last *added* parameter which indicates whether offset should be
>> > incremented or not. This last parameter is itself an optional parameter
>> > with
>> > a value of True ("offset" is incremented by "length"). Though, offset is
>> > totally managed by the python API, it is possible to increment manually
>> > the
>> > offset.
>> >
>> > There is already two notable exceptions to what I described here above.
>> > There exists two others objects (register_info and Subtrees). It is
>> > likely
>> > that in the future this list of objects will increase because they've
>> > initially have been created because of a "ctypes" (python module)
>> > limitation.
>> > At the end, they almost serve only as a special dictionary of elements.
>> > For these objects, I used a so interesting feature of python, definition
>> > of
>> > dynamic attributes.You have a first step in which you add items in this
>> > "dictionary" (hf_register_info fields and trees). When you have to refer
>> > to
>> > one of these while dissecting, you can refer to them as if they were
>> > attributes of the related object.
>> > For example, let's say "hf" is a register_info object, you can add
>> > something
>> > to it by doing :
>> >   hf.add("Imaginary Protocol Length", "imaginary.length", FT_UINT8)   =>
>> > Not
>> > that you have a lot of optional parameters in here!
>> > and you can refer to this field while dissecting with
>> >   hf.imaginary_length
>> > the name of the attribute is the second parameter passed with every '.'
>> > changed to '_'
>> >
>> >
>> > That's all for now .. I'll add this mail to the wiki documentation.
>> > Of course, I'll enjoy any comments (from you or anyone else) to improve
>> > the
>> > python API whatever it be following the LUA API or not. :)
>> >
>> >
>> > Regards,
>> > Sebastien Tandel
>> >
>> > 2009/5/31 Stig Bjørlykke <stig.bjorlykke@xxxxxxxxx>
>> >>
>> >> Hi,
>> >>
>> >> Do you use the same naming scheme in the Python bindings as we use in
>> >> Lua?
>> >> I think we should have the same names for equal functionality in both
>> >> Python and Lua.
>> >>
>> >>
>> >> --
>> >> Stig Bjørlykke
>> >>
>> >>
>> >>
>> >>
>> >> ___________________________________________________________________________
>> >> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> >> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >>
>> >> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> >>
>> >
>> >
>> >
>> > ___________________________________________________________________________
>> > Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> > Archives:    http://www.wireshark.org/lists/wireshark-dev
>> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> >
>> > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> >
>>
>>
>>
>> --
>> This information is top security. When you have read it, destroy yourself.
>> -- Marshall McLuhan
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>



-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan