Re: how to convert VB scripts to Gnumeric python

[Morten Welinder <mortenw gnome org>]

Some progress.  I have something like this working now:

    import gi
    gi.require_version('Gnm', '1.12')
    from gi.repository import Gnm
    Gnm.init()

    wb = Gnm.Workbook.new_with_sheets(1)
    sheet = wb.sheet_by_index(0)
    sheet.cell_set_value(0,0,Gnm.Value.new_int(10))
    sheet.cell_set_value(0,1,Gnm.Value.new_float(1.0/3.0))
    sheet.cell_set_text(0,2,"=A1+A2")
    wb.recalc()

    for i in range(3):
        print sheet.cell_get_value(0,i).peek_string()

It's not a great API.  In fact, in it shows clear signs of being a bit foreign to Python.

A gotcha: all versions of introspection until about 2 months ago misunderstood "char const *" as "char *" causing problems with functions like value_peek_string.  Such functions will need to have their return value marked "transfer none".  ("const char *" worked fine, on the other hand.)

M.

On Wed, Apr 11, 2018 at 8:01 PM <dm-gnome mercuryresearch com> wrote:

Copying would be a helpful thing. I ran into similar problems. There is a workaround.

My copy/paste operation core (sorry, this is c/p from my application so no setup code shown):

                        cell = sheet.cell_fetch(col, row)
                        if cell is not None:
                            d_cell = d_sheet.cell_fetch(dest_col, dest_row)
                            # For whatever reason, copying/duping value doesn't work, so we use other methods
                            if (debug > 0): print dest_col, dest_row
                            v = cell.get_rendered_text()
                            d_cell.set_text(v)
                            # This works but generates tons of gnm_style_unref errors
                            style = cell.get_style()
                            d_sheet.style_set_pos(dest_col, dest_row, style)

d_sheet, d_cell is the destination to copy to.

You essentially have to work with parts of a cell.

I can probably help with the introspection annotations, as you've already seen from the
patches I sent privately. I think if certain core functions are done first it will enable development
that would uncover other problems.

I have a personal development note document I will share here, since apparently rough drafts are OK to some of you and hint at problems:

Gnome Introspection notes
 - not part of the application
 - used scanner driven code
 - comments are code
 - function names influence introspection interface
 - names with "new" mostly result in constructor interfaces that return full-ownership objects that are easily usable.
 - Comments may not export usable interface and this will not show up as a bug in the application. e.g. allow-none/nullable optional values. (* I previously described this about inserting "allow-none" in the defintions)

 https://wiki.gnome.org/Projects/GObjectIntrospection#Annotation_System
 https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations

Python GI API Reference
https://lazka.github.io/pgi-docs/


Python and introspection
 - Applications are C, python is not
 - Objects needs to be converted between the two, normally transparent but sometimes results in unexpected behavior.


 Memory Management
 - not all objects get exported in a directly usable way
 - in .gir file, object definitions tagged return-value transfer-ownership="full" are directly usable python objects
 - other objects may need reference or memory management and can trigger segfaults

On 04/11/2018 04:42 PM, Morten Welinder wrote:

I tried to write a script to do some basic operations, but I immediately hit problems in introspection
and/or pygobject.  Specifically, something gets terminally confused over sheet_cell_set_value
leading to a double-free.  Even if they fix that right now, it's going to be years before stable distributions

will see the fix.

In this particular case I might be able to paper over the problem by interposing a function that copies

its argument instead of taking ownership.  That'll slow down python a bit, but if you're using python

you're probably not that much in a hurry.

The key to getting parts of Gnumeric available via python is to have accurate introspection annotations

for the relevant APIs.  If anyone feels like helping with that, it would be appreciated.

Morten

_______________________________________________
gnumeric-list mailing list
gnumeric-list gnome org
https://mail.gnome.org/mailman/listinfo/gnumeric-list

_______________________________________________
gnumeric-list mailing list
gnumeric-list gnome org
https://mail.gnome.org/mailman/listinfo/gnumeric-list