Re: how to convert VB scripts to Gnumeric python

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 <[email protected]> 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 [email protected]://mail.gnome.org/mailman/listinfo/gnumeric-list
>
>
> _______________________________________________
> gnumeric-list mailing list
> [email protected]
> https://mail.gnome.org/mailman/listinfo/gnumeric-list
>

_______________________________________________
gnumeric-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnumeric-list