Gwyddion

On Tue, Jun 28, 2005 at 01:04:46PM +0200, Sven Neumann wrote:
> reading the ChangeLog, I saw that you moved inline docs from the C file
> to the documentation templates, claiming that gtk-doc would be confused
> about inline docs. I really wonder why you had to do that (and I think
> that docs should be inline if possible).

Me too.

> The gtk-doc markup that you
> were using in gwycontainer.c looked almost right. You only got the
> signal name wrong. The canonical form of signal and property names is
> using a dash, not an underscore.

Thanks for the explanation, I can never remember which one
is canonical.  However, why underscore wins almost 8:1 in
signal names in Gtk+ itself (where I usually look for
canonical forms and inspiration)?

> Could that have confused gtk-doc?

It really seems so.  I was getting unitialized value warning
in gtkdoc-mktmpl function OutputParam().  Particularly
$param_to_output and $param_name were undefs.  gtkdoc-mktmpl
then always added one empty param @: to the template so it
soon looked like

  @gwycontainer: the object which received the signal.
  @: 
  @: 
  @: 
  @: 
  etc.

It did not seem related to signal name.  But I can move it
back now.

> What version of gtk-doc are you using anyway?

1.2, but that probably doesn't matter.

Regards,

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi,

On Tue, 2005-06-28 at 20:55 +0200, David Necas (Yeti) wrote:

> Thanks for the explanation, I can never remember which one
> is canonical.  However, why underscore wins almost 8:1 in
> signal names in Gtk+ itself (where I usually look for
> canonical forms and inspiration)?

Perhaps you should use the CVS HEAD branch for reference then. At least
property names have all been changed to the canonical form there. Most
signal names are yet to be done though.


Sven

Hi,

attached is a patch against CVS that changes the signal names used in
libgwy* to use the canonical form. Not sure if I really catched all
occurences and similar changes should be done in other parts of the
code. But it's a start.


Sven

On Wed, Jun 29, 2005 at 04:07:36PM +0200, Sven Neumann wrote:
> attached is a patch against CVS that changes the signal names used in
> libgwy* to use the canonical form. Not sure if I really catched all
> occurences and similar changes should be done in other parts of the
> code. But it's a start.

Hm, I commited something like that before an hour (to HEAD).
Unfortunately, it still didn't appear in public CVS.  If you
located the places to change automatically, could you re-run
the process once you have this commit available?

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Mon, Jun 27, 2005 at 04:04:03PM -0700, Christopher Anderson wrote:
> Correct me if I am wrong, but it seems to me that Gwyddion currently
> does not support loading of Graph data from files. I see there is an
> export to Ascii, but no loading ability. We would like to add the
> ability for Gwyddion to load spectroscopy graph data (whether in ascii
> form, our PicoScan/PicoView format, or any other formats that are out
> there). Now, my question is whether we should use a file module or a
> graph module to accomplish this.

Graphs are always associated with 2D data.  File loading
function can return a Container with 2D data and some
associated graphs -- and that's the only thing that makes
sense conceptually in current Gwyddion.

If you return a Container with no data, just graphs, it ...
well, it seems to crash, which it should not do, but anyway
it counts as file load failure.

> My first flinch is to write a file
> module, because then the filetype can be automatically detected. Also,
> saving/loading of graph data could be implemented together. However, I
> see that you have used a Graph module to implement the ascii exporter,
> so I am not sure. Let me know what you think.

If you need it now, you have to cheat -- load a graph as
a side effect of something, e.g. of normal file load, and
then let it fail.  You can't load graph in a graph module,
as they implicitely need a graph to be sensitive (so you'd
need a graph to load a graph), and this can't be changed w/o
breaking compatibility.

It is also impossible to create a standalone graph (not
associated with any 2D data), but this probably can be
enabled easily.

In short, I'd leave it for 2.x.  I think Petr will address
these issues once things settle a bit after current graph
revolution.

Regards,

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Ok, sounds good. As long as something can be done about it for version
2.x, we'll be happy. Do you have a tentative release date, btw? Not
trying to rush you, just curious.

Thanks,
Chris Anderson

On 6/28/05, David Necas (Yeti) <yeti@...> wrote:
> On Mon, Jun 27, 2005 at 04:04:03PM -0700, Christopher Anderson wrote:
> > Correct me if I am wrong, but it seems to me that Gwyddion currently
> > does not support loading of Graph data from files. I see there is an
> > export to Ascii, but no loading ability. We would like to add the
> > ability for Gwyddion to load spectroscopy graph data (whether in ascii
> > form, our PicoScan/PicoView format, or any other formats that are out
> > there). Now, my question is whether we should use a file module or a
> > graph module to accomplish this.
>=20
> Graphs are always associated with 2D data.  File loading
> function can return a Container with 2D data and some
> associated graphs -- and that's the only thing that makes
> sense conceptually in current Gwyddion.
>=20
> If you return a Container with no data, just graphs, it ...
> well, it seems to crash, which it should not do, but anyway
> it counts as file load failure.
>=20
> > My first flinch is to write a file
> > module, because then the filetype can be automatically detected. Also,
> > saving/loading of graph data could be implemented together. However, I
> > see that you have used a Graph module to implement the ascii exporter,
> > so I am not sure. Let me know what you think.
>=20
> If you need it now, you have to cheat -- load a graph as
> a side effect of something, e.g. of normal file load, and
> then let it fail.  You can't load graph in a graph module,
> as they implicitely need a graph to be sensitive (so you'd
> need a graph to load a graph), and this can't be changed w/o
> breaking compatibility.
>=20
> It is also impossible to create a standalone graph (not
> associated with any 2D data), but this probably can be
> enabled easily.
>=20
> In short, I'd leave it for 2.x.  I think Petr will address
> these issues once things settle a bit after current graph
> revolution.
>=20
> Regards,
>=20
> Yeti
>=20
>=20
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
>

On Tue, Jun 28, 2005 at 10:31:10AM -0700, Christopher Anderson wrote:
> Ok, sounds good. As long as something can be done about it for version
> 2.x, we'll be happy. Do you have a tentative release date, btw?

No, we don't, except `this year (hopefully)'.

I estimate after release of 1.99.3 (RSN) we will be we in
1/3 on the way to 2.0.  Its release will be feature-based,
not time-based.  This may be the last chance to seriously
break and fix interfaces for quite a long time, so we have
to think we have foundations we can base future development
on. See also http://gwyddion.net/future.php#v199x (and #v20)
for some fragmentary and outdated remarks.

I just wished the time more people started writing modules
and otherwise cotributing didn't coincide with the period
of worst chaos since 0.0.x times, but it was probably
predestined...

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi,


>
> I have a suggestion for a feature that might also be of use for others.
> Sometimes it is necessary to perform data correction (line-by-line
> correction or background subtraction) just to be able to see the useful
> information in the image. This is, for example, the case of STM images
> with atomic resolution on metals, where the corrugation is rather low
> and one can't see anything from the raw image.
> On the other hand, one would like to be able to read off line profiles,
> perform curve fitting, calculate statistics, etc. on *unfiltered*,
> original data.

Thanks for your remark, we have to think now on these things even more
generally as we need to approach more to multichannel data processing in
future (to analyze data from different more complicated SPMs like
MFM, SThm or NSOM). This means things like selecting one profile in
profile tool and obtaining several graphs from different channels (from
the same points) and several more things. So your proposal can
halp us to clear these ideas...


> Would it break too many things if support were added for having a choice
> of performing data correction on the original data or for viewing
> purposes only? I believe that physical and presentation data are already
> separate, so I guess this is mostly a matter of the user interface.

I think that the quickest way would be anyway to create somehow
processed data as presentation - as the presentation exactly supports
this and was designed for this. However it is true that there should
be some way how to distinguish the presentation and data image in the data
window when they are so similar.

Yours


Petr Klapetek

On Mon, Jun 20, 2005 at 06:36:28PM +0200, Rok Zitko wrote:
> 
> Would it break too many things if support were added for having a choice
> of performing data correction on the original data or for viewing
> purposes only? I believe that physical and presentation data are already
> separate, so I guess this is mostly a matter of the user interface.
> 
> Maybe presentation controls (buttons) could be moved to the data window
> to separate presentation and true data processing.
> 
> What do you think?

Since data correction algorithms can be arbitrarily slow,
I'm not much inclined to do live corrections, that is
presentation which is recomputed each time data changes.
Beside that a new type of module function would have to be
added for that -- if everything wasn't to be hardcoded to
data view layers.

However, a possibility exists that is very simple and can be
implemented right now: Write a module that puts one data to
presentation of other data (provided that they have the same
dimension).  Its GUI can consist of two data option menus --
source and target -- and that's all.  In GWYDDION-1, the
presentation data field must be created as a copy.  However
in HEAD, you can try to simply put the very same data field
object to the presentation, so any change in the source data
will also show on the presentation -- this can be a funny
method to make a few data view/layers/... bugs to show up.

Regards,

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Tue, Jun 21, 2005 at 09:01:42AM +0200, David Necas (Yeti) wrote:
> 
> However, a possibility exists that is very simple and can be
> implemented right now: Write a module that puts one data to
> presentation of other data

FYI: I've just added this functionality to presentationops
module in GWYDDION-1 branch.  I'll merge it to HEAD too,
although introduction of multidata is going to radically
change things like this.

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

I tried turning off the gwy_debug_objects:

gwy_debug_objects_enable(FALSE);

When I do this, the problem goes away, and everything works fine.
Could this be a bug in gwy_debug_objects code?

Chris

On 6/22/05, Christopher Anderson <sidewinder.asu@...> wrote:
> Let's say I have something like this code:
>=20
> some_function
> {
>   GwyDataField *dfield;
>   dfield =3D GWY_DATA_FIELD(gwy_data_field_new(256, 256, 100, 100, TRUE))=
;
>=20
>   /* Do stuff with dfield */
>=20
>   g_object_unref(dfield);
> }
>=20
> It seems perfectly sane and innocent, but every time I do something
> like this, it causes gwyddion to crash right after my module exits. I
> tried waiting until the very end of the program to unref dfield (after
> making it global), and this seemed to work. Is there some reason why I
> can't create and destroy a datafield within a self-contained function?
> Any idea what's going on here?
>=20
> Thanks,
> Chris Anderson
>

On Wed, Jun 22, 2005 at 05:25:01PM -0700, Christopher Anderson wrote:
> On 6/22/05, Christopher Anderson <sidewinder.asu@...> wrote:
> > Let's say I have something like this code:
> > 
> > some_function
> > {
> >   GwyDataField *dfield;
> >   dfield = GWY_DATA_FIELD(gwy_data_field_new(256, 256, 100, 100, TRUE));
> > 
> >   /* Do stuff with dfield */
> > 
> >   g_object_unref(dfield);
> > }
> > 
> > It seems perfectly sane and innocent, but every time I do something
> > like this, it causes gwyddion to crash right after my module exits. I
> > tried waiting until the very end of the program to unref dfield (after
> > making it global), and this seemed to work. Is there some reason why I
> > can't create and destroy a datafield within a self-contained function?
> > Any idea what's going on here?
>
> I tried turning off the gwy_debug_objects:
> 
> gwy_debug_objects_enable(FALSE);
> 
> When I do this, the problem goes away, and everything works fine.
> Could this be a bug in gwy_debug_objects code?

Well, I can't entirely rule out this possibility, but we are
talking about less than 30 lines of pretty trivial code.
I'm also unable to reproduce any of described problems,
valgrind doesn't show anything either.

Can you get a stack trace?  If it crashes in
debug_objects_set_time() -- which consists of one line of
code -- what's the value of data? Does it match what is
passed to g_object_weak_ref()?

It's also possible you overwrite stack or heap somewhere
else and only see the consequences here.

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Ok, so I came in to work today and suddenly this crash no longer
happens! I still don't know what is going on, but I suspect it is some
problem with my system. Anyway, I have come across an unrelated issue:

I have these lines in my code:

    gwy_data_field_2dfft(data_input, i_in, r_out, i_out, gwy_data_line_fft_=
hum,
                         window, 1, interp, 0, 0);
    gwy_data_field_2dffthumanize(r_out);
    gwy_data_field_2dffthumanize(i_out);

When I comment them out, my program completes without a single "alive"
object. Perfect. However, when I compile with these lines in, I get
this in my debug info:

GwySIUnit 01601CE8 0.000 ALIVE(1)!
GwySIUnit 01601D68 0.000 ALIVE(1)!
GwySIUnit 01601DE8 0.000 ALIVE(1)!
GwySIUnit 01602270 0.000 ALIVE(1)!
GwySIUnit 01602390 0.063 ALIVE(1)!
GwySIUnit 01602360 0.063 ALIVE(1)!
GwySIUnit 01602480 0.063 ALIVE(1)!
GwySIUnit 01602400 0.063 ALIVE(1)!

A bunch of GwySIUnits are staying alive somehow. I looked at the code
for gwy_data_field_2dfft() and noticed that it uses
_gwy_data_field_free(), which uses g_free(a->data); to free up the
data. Could this be allowing the GwySIUnits to remain alive somehow?

Thanks,
Chris Anderson


On 6/23/05, David Necas (Yeti) <yeti@...> wrote:
> On Wed, Jun 22, 2005 at 05:25:01PM -0700, Christopher Anderson wrote:
> > On 6/22/05, Christopher Anderson <sidewinder.asu@...> wrote:
> > > Let's say I have something like this code:
> > >
> > > some_function
> > > {
> > >   GwyDataField *dfield;
> > >   dfield =3D GWY_DATA_FIELD(gwy_data_field_new(256, 256, 100, 100, TR=
UE));
> > >
> > >   /* Do stuff with dfield */
> > >
> > >   g_object_unref(dfield);
> > > }
> > >
> > > It seems perfectly sane and innocent, but every time I do something
> > > like this, it causes gwyddion to crash right after my module exits. I
> > > tried waiting until the very end of the program to unref dfield (afte=
r
> > > making it global), and this seemed to work. Is there some reason why =
I
> > > can't create and destroy a datafield within a self-contained function=
?
> > > Any idea what's going on here?
> >
> > I tried turning off the gwy_debug_objects:
> >
> > gwy_debug_objects_enable(FALSE);
> >
> > When I do this, the problem goes away, and everything works fine.
> > Could this be a bug in gwy_debug_objects code?
>=20
> Well, I can't entirely rule out this possibility, but we are
> talking about less than 30 lines of pretty trivial code.
> I'm also unable to reproduce any of described problems,
> valgrind doesn't show anything either.
>=20
> Can you get a stack trace?  If it crashes in
> debug_objects_set_time() -- which consists of one line of
> code -- what's the value of data? Does it match what is
> passed to g_object_weak_ref()?
>=20
> It's also possible you overwrite stack or heap somewhere
> else and only see the consequences here.
>=20
> Yeti
>=20
>=20
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
>

On Mon, Jun 20, 2005 at 04:25:57PM +0200, David Necas (Yeti) wrote:
> see attached screenshot

...attached to this mail.

Yeti

Hi,

On Mon, 2005-06-20 at 16:25 +0200, David Necas (Yeti) wrote:

> You have two possibilities:
> 
> * Create a DataView that displays just selected data like
>   other modules do (see attached screenshot of how they
>   look), you can look at them and reuse their code then --
>   stpfile and rhk-spm32 are among the simplier ones.
> 
> * Continue the direction you started and render the pixbuf
>   yourself.  That's not hard, just use gwy_pixbuf_draw_data_field()
>   to render the pixbuf.  Or better gwy_data_field_get_autorange()
>   and then gwy_pixbuf_draw_data_field_with_range() to cut
>   off outliers to emulate what other modules do.

Havig the previews in the combo box is probably not going to look nice
anyway. At least not if one wants the previews to be as large as they
are in the other import modules. I have thus chosen the second approach
and created an UI that probably looks more familiar to you. Attached is
a patch against CVS HEAD. Please have a look at the patch. There's a
comment about a call that should IMO not be necessary. However I get
warnings if I omit the call to gwy_pixmap_layer_set_data_key () before
setting the layer on the view. The code then tries to disconnect a
non-existant signal handler which looks like a bug to me.


Sven

On Mon, Jun 20, 2005 at 06:16:25PM +0200, Sven Neumann wrote:
> Attached is
> a patch against CVS HEAD. Please have a look at the patch. There's a
> comment about a call that should IMO not be necessary. However I get
> warnings if I omit the call to gwy_pixmap_layer_set_data_key () before
> setting the layer on the view. The code then tries to disconnect a
> non-existant signal handler which looks like a bug to me.

You are right, it was a bug.  I fixed it and applied your
patch without the comment and the workaround call.
Thanks.

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi,

On Mon, 2005-06-20 at 20:04 +0200, David Necas (Yeti) wrote:

> You are right, it was a bug.  I fixed it and applied your
> patch without the comment and the workaround call.

Thanks. I tried to backport the preview to the stable branch. Was pretty
much straight-forward until I run into the problem that
gwy_pixmap_layer_set_data_key() doesn't seem to be available in the
stable branch. I am using this function in the HEAD branch to change the
data field shown in the preview. Can you think of a workaround?

I've attached what I got so far.


Sven

On Tue, Jun 21, 2005 at 12:20:16PM +0200, Sven Neumann wrote:
> 
> Thanks. I tried to backport the preview to the stable branch. Was pretty
> much straight-forward until I run into the problem that
> gwy_pixmap_layer_set_data_key() doesn't seem to be available in the
> stable branch. I am using this function in the HEAD branch to change the
> data field shown in the preview. Can you think of a workaround?

Widgets have lots of hardcoded assumptions in GWYDDION-1,
the data field has to be "/0/data".  Instead of switching
data key you have to switch data fields in container.

Yeti


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hi,

On Tue, 2005-06-21 at 12:32 +0200, David Necas (Yeti) wrote:

> Widgets have lots of hardcoded assumptions in GWYDDION-1,
> the data field has to be "/0/data".  Instead of switching
> data key you have to switch data fields in container.

OK, I have cleaned up my initial design a little, making it possible to
get away with almost the same code for the preview in the stable branch.
You will find the patches attached to
http://trific.ath.cx/bugzilla/show_bug.cgi?id=57


Sven

Hi,

On Tue, 2005-06-21 at 12:32 +0200, David Necas (Yeti) wrote:

> Widgets have lots of hardcoded assumptions in GWYDDION-1,
> the data field has to be "/0/data".  Instead of switching
> data key you have to switch data fields in container.

Ugh, now my design is starting to collapse... But since it seems to
work nicely in the HEAD branch, I guess I can find a hackish way to
also make it work in the stable branch.


Sven