From time to time, my mails are rejected because my ISP smtp server is blacklisted by uceprotect. Up to now, I have been able to avoid it by using a different server but it seems that all are blacklisted today and they will not be removed from the list before one week.


Could you add an exception for the following IP?
212.27.42.1
212.27.42.2
212.27.42.3
212.27.42.4
212.27.42.5
212.27.42.6


Here is the reply I received:

This is the mail system at host smtp1-g21.free.fr.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<anjuta-devel-list@gnome.org>: host mail.gnome.org[209.132.180.169] said: 554
    5.7.1 Service unavailable; Client host [212.27.42.1] blocked using
    dnsbl-1.uceprotect.net; IP 212.27.42.1 is UCEPROTECT-Level 1 listed. See
    http://www.uceprotect.net/rblcheck.php?ipr=212.27.42.1 (in reply to RCPT TO
    command)



Reporting-MTA: dns; smtp1-g21.free.fr
X-Postfix-Queue-ID: D8CEA940629
X-Postfix-Sender: rfc822; seb.sfo@free.fr
Arrival-Date: Wed, 21 Dec 2011 22:26:41 +0100 (CET)

Final-Recipient: rfc822; anjuta-devel-list@gnome.org
Original-Recipient: rfc822;anjuta-devel-list@gnome.org
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.gnome.org
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host [212.27.42.1]
    blocked using dnsbl-1.uceprotect.net; IP 212.27.42.1 is UCEPROTECT-Level 1
    listed. See http://www.uceprotect.net/rblcheck.php?ipr=212.27.42.1


Partie 1.2
Sujet:
Re: [anjuta-devel] Change project property interface
De :
Sébastien Granjoux <seb.sfo@free.fr>
Date :
Wed, 21 Dec 2011 22:26:40 +0100
Copie à :
anjuta-devel-list <anjuta-devel-list@gnome.org>

Hi Abderrahim,


Le 21/12/2011 13:58, Abderrahim Kitouni a écrit :
> Well, it does. Functions like anjuta_project_node_insert_property_info
> clearly create the nodes added to the list, and this is the only way to
> add PropertyInfo's to a node (if we remove the gobject property).

Yes, I don't use this function. I'm setting directly the properties_list member. I have added it for you. I think it would be better to set the whole properties info list in one call allowing you to reuse the same list for several nodes.


When loading nodes, I could have temporary properties which could have temporary PropertiesInfo structure. It's the case when the properties are declared before the target in Makefile.am. By example if you have
  test_CFLAGS = -O0
  bin_PROGRAMS = test

A dummy CFLAGS property is added to a dummy node until we find the target node test. These dummy properties have a temporary property info which is free with the dummy node. To make the distinction, I have added a flag ANJUTA_PROJECT_PROPERTY_STATIC which is cleared for such property.


> This could be done in a generic manner by using the user_data field, but
> I think it should be possible to keep the current C plugins unchanged.

Even if you use the user_data field, you need to have a function to free the data correctly.


> The problem is that the list is a field in AnjutaProjectNode, and as
> such needs to be freed from there. And while things like you propose are
> doable in Vala (we need however to tweak generated bindings), it is
> impossible to do for dynamic languages.

To be clear, even if I'm discussing quite a lot, I would like to make it work with dynamic languages and without too much tricky things in Vala.


> Try to think in Python: the info list is a Python list, and in order to
> get this list to the node object (even through a possible
> set_properties_info) it needs to be converted to a GList, then either
> its ownership is taken by the node object, or it is freed just
> afterwards. So the node object needs to own at least the list (even
> though it doesn't need to own its contents).

How does it work if the object doesn't own the content? the content is a Python structure by example, so it should be converted to a C structure no?

In my idea, the properties info list argument is like the gpointer data argument of g_list_append by example.

I have looked as instrospection documentation, it has improved since last time I read it. Indeed, the argument should be marked as transfer none but we expect that the caller keep a valid copy of the parameter. I think it triggers issues similar to call back which is tricky.


Anyway, I think we can make it works exactly as you want. Having both the properties and the properties information content and list belonging to the node. As I have explained above, it's already working like this when loading a node.


Then, I'm still a bit annoyed that the properties info list will be duplicated in project backend not written in C. I think one solution for this is to create a new object which is a AnjutaPropertyInfoList. For C it could be just a GList so it cost nothing, but for a Python backend it can be a opaque object that the Python backend has to create, fill with needed data and pass to the project node. So we could have functions like

AnjutaProjectPropertyInfoList *anjuta_project_property_info_list_new ();
void anjuta_project_property_info_list_free (
        AnjutaProjectPropertyInfoList *list);
void anjuta_project_property_info_list_add (
        AnjutaProjectPropertyInfoList *list,
        AnjutaProjectPropertyInfo *info);

We could have (transfer full) for the info parameter of list_add function and (transfer none) when this list is used to initialize a new node. So it's up to the backend to keep all property information lists with the node using them as long as the backend is running. What do you think?

I could be a bit more complex to use (one additional object) just to gain memory perhaps we don't care.



Regards,

Sébastien