|
»
»
»
Libanjuta-python not building properly
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Libanjuta-python not building properly
by surendran m
::
Rate this Message:
Hi Seb,
The Libanjuta python bindings from the source forge site is not building properly. Should I do something before something ?? It actually fails during make step ! You were suggesting some patch right ? where can I get it ? (I am going to take your bindings as base and work on it ! ) Thanks ! -- regards Surendran NIT Trichy ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
Hi,
suren a écrit : > The Libanjuta python bindings from the source forge site is not building > properly. Should I do something before something ?? Yes, you should apply a patch on pygtk. > It actually fails during make step ! You were suggesting some patch > right ? where can I get it ? (I am going to take your bindings as base > and work on it ! ) here http://bugzilla.gnome.org/show_bug.cgi?id=503668 Regards, Sébastien ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Fabio Rafael da Rosa-2
::
Rate this Message:
Seb, do you have any position from pygtk team on when this will be upstream ?
On Tue, May 13, 2008 at 9:19 AM, Sébastien Granjoux <seb.sfo@...> wrote: Hi, -- Fabio Rafael da Rosa fabiorafael.rosa@... ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
Hi,
Fabio Rafael da Rosa a écrit : > Seb, do you have any position from pygtk team on when this will be > upstream ? No, you get all my exchange with them in the bug report. I have been able to get a few patches upstream but they hadn't changed anything at the user level contrary to this one. I don't know exactly how to push this patch. Regards, Sébastien ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Fabio Rafael da Rosa-2
::
Rate this Message:
I applied the patch and recompiled pygtk, but It's still complaining about the virtual methods :
ianjuta-debugger.override: In function '_wrap_IAnjutaDebuggerStringListCallback': ianjuta-debugger.override:250: warning: passing argument 2 of 'g_list_foreach' from incompatible pointer type libanjuta-interface.c: In function '_wrap_IAnjutaDebuggerBreakpoint__do_implement_breakpoint': libanjuta-interface.c:7467: error: 'IAnjutaDebuggerBreakpointIface' has no member named 'implement_breakpoint' libanjuta-interface.c:7468: error: 'IAnjutaDebuggerBreakpointIface' has no member named 'implement_breakpoint' I guess I'm probably doing something stupied, so, can you point me to some direction? Any clue ? On Tue, May 13, 2008 at 10:17 AM, Sébastien Granjoux <seb.sfo@...> wrote: Hi, -- Fabio Rafael da Rosa fabiorafael.rosa@... ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
Hi Fabio,
Fabio Rafael da Rosa a écrit : > I applied the patch and recompiled pygtk, but It's still complaining > about the virtual methods : > '_wrap_IAnjutaDebuggerBreakpoint__do_implement_breakpoint': > libanjuta-interface.c:7467: error: 'IAnjutaDebuggerBreakpointIface' has > no member named 'implement_breakpoint' > libanjuta-interface.c:7468: error: 'IAnjutaDebuggerBreakpointIface' has > no member named 'implement_breakpoint' > I guess I'm probably doing something stupied, so, can you point me to > some direction? Any clue ? It could be quite possible that I have make an error myself in the package.... Ok, you probably don't use the patched codegen.py program. My patch adds a new attribute vmethod which allow to define a different name for the C function (defined with vmethod) and the python function (defined with define-virtual). In the libanjuta-interface.defs you should have something like: (define-virtual implement_breakpoint (of-object "IAnjutaDebuggerBreakpoint") (c-name "ianjuta_debugger_breakpoint_implement") (vmethod "implement") (return-type "gint") (parameters '("GError**" "err") ) ) So, the python function is called implement_breakpoint while the C function is called implement. codegen.py should generate the following code: static PyObject * _wrap_IAnjutaDebuggerBreakpoint__do_implement_breakpoint(PyObject *cls, PyObject *args, PyObject *kwargs) { IAnjutaDebuggerBreakpointIface *iface; static char *kwlist[] = { "self", NULL }; PyGObject *self; int ret; GError *err = NULL; if (!PyArg_ParseTupleAndKeywords(args, kwargs,"O!:IAnjutaDebuggerBreakpoint.implement_breakpoint", kwlist, &PyIAnjutaDebuggerBreakpoint_Type, &self)) return NULL; iface = g_type_interface_peek(g_type_class_peek(pyg_type_from_object(cls)), IANJUTA_TYPE_DEBUGGER_BREAKPOINT); if (iface->implement) ret = iface->implement(IANJUTA_DEBUGGER_BREAKPOINT(self->obj), &err); .... You see here we use iface->implement and not iface->implement_breakpoint. Perhaps you have not regenerated the .c file from the .defs file after applying the patch. Regards, Sébastien ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
|
|
|
|
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
Hi,
Fabio Rafael da Rosa a écrit : > Seb, should I stick to the API for 2.4 (stable), or should I carry on > fixing things with trunk ? As you want. I have made a branch 0-3 that should stay compatible with 2.4 stable version of Anjuta. You could work here without being disturbed by interface changes. The trunk should follow the new Anjuta API. I have already modified Anjuta interfaces and I'm planing to do even more changes, but I haven't updated libanjuta-python. You could work here, but you will have to fix things from time to time when an interface function change. The advantage is that you could work on Anjuta trunk at the same time. Regards, Sébastien ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Naba Kumar-2
::
Rate this Message:
Hi Seb,
On Tue, 2008-05-13 at 16:17 +0200, Sébastien Granjoux wrote: > I have been able to get a few patches upstream but they hadn't changed > anything at the user level contrary to this one. > > I don't know exactly how to push this patch. > If this patch is severely blocking libanjuta-python bindings, we can consider fixing the method names to not collide for now. But in the long run the patch should really be the one taking care of it because we can predict future collisions. Thanks. Regards, -Naba ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Naba Kumar-2
::
Rate this Message:
Hi Seb,
On Mon, 2008-05-19 at 23:27 +0300, Naba Kumar wrote:because we can > predict future collisions. > Uhm. I mean we *can't* .. :) Thanks. Regards, -Naba ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
Hi Naba,
Naba Kumar a écrit : > If this patch is severely blocking libanjuta-python bindings, we can > consider fixing the method names to not collide for now. Currently I have added some information in the README file moreover you don't need it if you use a released tarball because the .c files are already generated correctly. There are several functions that conflict (especially in the debugger) so it makes quite a lots of changes. > But in the long > run the patch should really be the one taking care of it because we can > predict future collisions. I will write a mail on pygtk mailing list perhaps we could get some progress. I think we have to change the function names only if we consider this limitation as permanent. It could be an option as, it's possible that we get the same limitation for other language bindings. GInterface are not very common so few people really get the same trouble. Regards, Sébastien ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
|
|
|
|
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
Hi,
Fabio Rafael da Rosa a écrit : > Got your point. So , in C that works because the Interface concept is > implemented mangling the name of the interface method. Yes. > My point here is that the method should have clear names, so, for your > first example, a clear_mark method would be more descriptive than only > clear. The same way, in the second example, a clear_buffer would make > more sense, because, I can just see the name of the method and get the > idea of what it' ll probably do . I'm not convinced. Python Windows and dict objects both have a clear method which are just named clear and are doing something really different. And I can easily get lots of example in probably all object oriented language. > I say that because Interfaces are not supposed to have methods with the > exact same name and different behavior. We can do that in see because of > the way it's implemented, but, It's seems a little weird for me. An object can implement any number of interfaces and normally you don't know which interface will be implemented by one object. So, in order to avoid name collision, you need to have an unique name (in the global name space) for all interface functions. One easy way to achieve this is to prefix the interface function name by the interface name as you know that interface name are already unique. It's exactly what is done in C, you have ianjuta_document_clear and ianjuta_indicable_clear. The fact, that there is somewhere a clear field is part of the implementation detail in C. What you ask here, is to use in Python the same method than in C for interface function name, add an unique prefix (or suffix if you really prefer). I'm agree that it will work but it has not be done and now I think it's too late to change this. By the way, I still understand that functions are looking better without this prefix and similar to member functions which don't need prefix in Python because they are local to one class (which is not possible in C). > All > other languages (that I know) that have interfaces (or something that > resembles that) don't let you do something like that (AFAIK) . It's not true. In C++, you can have multiple inheritance which is the closest thing, so you have a object of type C deriving from class B and A having both a clear member function and still be able to call clear from B using B::clear and clear from A using A::clear. Regards, Sébastien ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Johannes Schmid-4
::
Rate this Message:
Hi!
> One easy way to achieve this is to prefix the interface function name by > the interface name as you know that interface name are already unique. > It's exactly what is done in C, you have ianjuta_document_clear and > ianjuta_indicable_clear. The fact, that there is somewhere a clear field > is part of the implementation detail in C. > Though this could be some work I think it is the best we can do in anjuta. C++ itself might allow to have the same methods in multiple derived classes but I even doubt that the perl script that creates C++ bindings does allow it. Not speaking of any other language (python, vala, whatever). Regards, Johannes ------------------------------------------------------------------------- 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/ _______________________________________________ Anjuta-devel mailing list Anjuta-devel@... https://lists.sourceforge.net/lists/listinfo/anjuta-devel |
|
|
Re: Libanjuta-python not building properly
by Sébastien Granjoux
::
Rate this Message:
|
signature.asc (196 bytes)