[Gwyddion-users] Gwyddion 2.48 was released

[David Nečas (Yeti)]

Gwyddion 2.48 is now available for download at

https://sourceforge.net/projects/gwyddion/files/gwyddion/2.48/
(all released files)

http://gwyddion.net/download/2.48/
(source code)

Released files are signed with PGP/GnuPG key

"David Nečas (Yeti) <***@gwyddion.net>", id 62A07732
fingerprint = 263F 9B1E C1E0 5261 C689 D83B 00FD D1D0 62A0 7732

-----------------------------------------------------------------------------

This is a stable version continuing the 2.x series, backward compatible with
previous 2.x versions.

More information about Gwyddion is available at

http://gwyddion.net/

Bugs should be reported to

***@gwyddion.net

the mailing list, or the project's web forum at SourceForge.

-----------------------------------------------------------------------------

Summary of changes:
Application:
- New translation: Brazilian Portugese.
- Translations updated: Czech, French, Russian.
- Toolbox: Default width was increased to 5 columns (to work around broken MS
Windows 10 window management).
- Command line: New options --disable-modules prevents loading of specified
modules.

Libraries:
- libgwyddion: K-correlated PSDF fitting function was added.
- libgwyprocess: Positions of minimum and maximum are now available as data
field row/column statistics quantities.
- libgwyprocess: GwyShapeFitPreset has a quick-fit function for rough fitting
with reduced number of data points.
- libgwyprocess: Function for reduction of the number of points in GwySurface
was added.
- libgwyprocess: Mask thinning function was added.
- libgwydgets: A large number of new stock icons were added.
- libgwydgets: gwy_data_view_coords_xy_cut_line() cuts also vertical and
horizontal lines to nothing when they do not intersect the area at all.
- libgwymodule: Specific modules can be prevented from registration by
gwy_module_register_modules().
- libgwyapp: Ascending abscissae point order is enforced in graph curves upon
file import, with a warning emitted.
- libgwyapp: Progress dialogues shown by the wait functions can be disabled.
- libgwyapp: Misbehaving data window size restoration was corrected.
- libgwyapp: File name filter in the file chooser is now correctly applied only
to the actual file name instead of the whole path.
- libgwyapp: Helper functions for bad data masking and interpolation now use
fast Laplace interpolation instead of simple average.
- libgwyapp: GwyAppFileChooser avoids attempting full preview of huge files.

Modules:
- Zeiss LSM (new): Imports Carl Zeiss CLSM data.
- Dektak VCA (new): Import Dektak OPDx (VCA DATA) files.
- MFM perpendicular (new): Calculates stray field above sample with
perpendicular domains.
- MFM parallel (new): Calculates stray field above sample with parallell
domains.
- MFM shift (new): Transfers the field from one lift height to another.
- MFM current (new): Calculate stray field above sample with current line.
- MFM estimate shift (new): Estimates lift height difference between two MFM
images of the same structure.
- PSF estimate (new): Estimates point spread function based on ideal data and
measured data using deconvolution with regularisation.
- PSF fit (new): Estimates point spread function based on ideal data and
measured data by fitting an explicit PSF functional form.
- Phases synthesis (new): Simple generator of data resembling two-state
(two-phase) systems studied for instance in MFM.
- Stitch (new): Merges multiple images based on origin offsets.
- Pygwy: Standard output from modules and the console is captured (so in the
console print works again as expected). Python modules have new optional
registration variables. Pygwy console remembers recent scripts. Several
more function were added to the Python API.
- Renishaw, volume slice: Create graphs with ascending abscissae point order
now.
- MicroProf: Files with comment at the beginning are imported correctly now.
- Summarize Profiles: Now supports minimum and maximum positions.
- ISO28600: Import of multichannel files was corrected (field separator is
specified as comma). Irregular (XYZ) data import was implemented.
- WITec Project: Now supports different x axis units for spectra and spectral
images.
- NanoObserver: Support for v1.33 files was added (including spectroscopy).
- Spectro tool: CRITICAL error when avaraged curves differed in the number of
points was fixed. Subsequent spectra are interpolated onto the range of the
first selected now when averaging.
- Seiko: At least the first image should be imported from XQ?X files now.
- JPK: Initial support for volume force data (QI) was added. Single point
spectra import was fixed to ascending abscissae.
- SPMLab: All image layers are now loaded (not just the first one).
- Slice volume: Working with Z-axis calibrations was fixed. Initial choice of
possible target graphs was fixed.
- Profile tool: Averaging of thick profiles was fixed (lines close 45 degrees
were mostly affected).
- AMB: Physical dimmensions and scales of the data should be correct now.
- Image export: False colour bar ticks were corrected for inverted mappings.
Rendering of rulers for images with offsets was fixed.
- Nanoscope: Electrochemistry files are recognised.
- Distance tool: The exported table is tab-separated now.
- Mask editor tool: Spurious extra pixels in occurring free-hand drawing were
corrected.
- OPD: Import of ASC files written as XYZ was implemented (assuming regular
grid). Workaround for import error with ‘ImageModificat~0’ was added.
- Graph function fit, FD curve fit and Shape fit: Fit results can be copied
to the cliboard.

Other:
- OSX/BSD pygwy build: Build failure due to pygwy-fix-defs.sed containing
non-standard regexps was fixed (by replacing it with a Python script).
Several other problems related to compiler and linker flags and library
naming were corrected.
- Development snapshots: Now display a prominent label ‘Development snapshot’
in the splash screen so you know you are running a snapshot.

-----------------------------------------------------------------------------

Thanks all who contributed,

Yeti

[Tino Wagner]

Dear Yeti,

thank you for this release and your great work.

While packaging this version for Homebrew, I noticed that there is an issue now with the way how the Pygwy module is linked on macOS (again) [1]. Although, Gwyddion and the Python module compile and work fine as is, the module should not be linked explicitly against libpython.

Regarding the "# XXX: Do we still need this?“ comment in modules/pygwy/Makefile.am – yes, we do. I’d suggest a patch similar to this:

---
-gwy_la_LDFLAGS = -avoid-version -module $(no_undefined) $(PYTHON_LDFLAGS)
-# XXX: Do we still need this?
+gwy_la_LDFLAGS = -avoid-version -module $(no_undefined)
if OS_DARWIN
gwy_la_LDFLAGS += -undefined dynamic_lookup
+else
+gwy_la_LDFLAGS += $(PYTHON_LDFLAGS)
endif
---

Thanks and best regards,
Tino

[1]: https://github.com/Homebrew/homebrew-core/pull/13043

[David Nečas (Yeti)]

Post by Tino Wagner
While packaging this version for Homebrew, I noticed that there is an
issue now with the way how the Pygwy module is linked on macOS (again)
[1]. Although, Gwyddion and the Python module compile and work fine as
is, the module should not be linked explicitly against libpython.

I see there are now LDFLAGS where we had an exception for Darwin.
In the long thread about manual OS X compilation

https://sourceforge.net/p/gwyddion/mailman/gwyddion-users/thread/CA%2ByMqGkb83mjLfheKTSU1WNQgGBy_CJ_PnZ7%2BZE3YBLOyoEg2g%40mail.gmail.com/#msg35763310

it took some work to get the linker flags right (for some value of
right anyway). So you say none of the things we get from

python2.7-config --ldflags

need to be ever passed to the linker when linking gwy.dylib?

Post by Tino Wagner
Regarding the "# XXX: Do we still need this?“ comment in
modules/pygwy/Makefile.am – yes, we do.

OK, thanks for the clarification.

Post by Tino Wagner
-gwy_la_LDFLAGS = -avoid-version -module $(no_undefined) $(PYTHON_LDFLAGS)
-# XXX: Do we still need this?
+gwy_la_LDFLAGS = -avoid-version -module $(no_undefined)
if OS_DARWIN
gwy_la_LDFLAGS += -undefined dynamic_lookup
+else
+gwy_la_LDFLAGS += $(PYTHON_LDFLAGS)
endif

AFAIK the only OS where we *need* to link with libpython is MS Windows
because DLLs cannot be linked with unresolved symbols. So I can
actually make it controlled by ‘if MODULE_DEPENDENCIES’. Everywhere
else python has libpython already loaded so the dlopen()ed module just
resolves symbols against that.

What I am not sure about is the other things we get in PYTHON_LDFLAGS.

Regards,

Yeti


P.S.: This would be probably more appropriate in gwyddion-devel.

[Tino Wagner]

Dear Yeti,

Post by David Nečas (Yeti)
P.S.: This would be probably more appropriate in gwyddion-devel.

You’re right. I will cross-post this reply to the -devel list, so we can continue the discussion there. I’ll keep your original response in here for reference.

Post by David Nečas (Yeti)

Post by Tino Wagner
While packaging this version for Homebrew, I noticed that there is an
issue now with the way how the Pygwy module is linked on macOS (again)
[1]. Although, Gwyddion and the Python module compile and work fine as
is, the module should not be linked explicitly against libpython.

I see there are now LDFLAGS where we had an exception for Darwin.
In the long thread about manual OS X compilation
https://sourceforge.net/p/gwyddion/mailman/gwyddion-users/thread/CA%2ByMqGkb83mjLfheKTSU1WNQgGBy_CJ_PnZ7%2BZE3YBLOyoEg2g%40mail.gmail.com/#msg35763310
it took some work to get the linker flags right (for some value of
right anyway). So you say none of the things we get from
python2.7-config --ldflags
need to be ever passed to the linker when linking gwy.dylib?

I don’t think it is necessary.

$ python-config --ldflags
-L/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -lpython2.7 -ldl -framework CoreFoundation

This is what I get from distutils when I try to link a simple extension:

$ cat setup.py
from distutils.core import setup, Extension
test_ext = Extension(
'test_ext',
sources=[],
libraries=[])
setup(
name="test",
ext_modules=[test_ext],
)
$ python setup.py build_ext --inplace
running build_ext
building 'test_ext' extension
clang -bundle -undefined dynamic_lookup -L/usr/local/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/sqlite/lib -o /private/tmp/python-ext/test_ext.so
...

So there’s no explicit linkage. We can get the linker call from the Python configuration, as the distutils module does.

Post by David Nečas (Yeti)

Post by Tino Wagner

from distutils import sysconfig
sysconfig.get_config_var('CC')

'clang'

Post by David Nečas (Yeti)

Post by Tino Wagner

sysconfig.get_config_var('LDFLAGS')

''

Post by David Nečas (Yeti)

Post by Tino Wagner

sysconfig.get_config_var('LDSHARED')

'clang -bundle -undefined dynamic_lookup'

I don’t know whether these variables already contain the necessary things on Windows, though.

Post by David Nečas (Yeti)

Post by Tino Wagner
Regarding the "# XXX: Do we still need this?“ comment in
modules/pygwy/Makefile.am – yes, we do.

OK, thanks for the clarification.

Post by Tino Wagner
-gwy_la_LDFLAGS = -avoid-version -module $(no_undefined) $(PYTHON_LDFLAGS)
-# XXX: Do we still need this?
+gwy_la_LDFLAGS = -avoid-version -module $(no_undefined)
if OS_DARWIN
gwy_la_LDFLAGS += -undefined dynamic_lookup
+else
+gwy_la_LDFLAGS += $(PYTHON_LDFLAGS)
endif

AFAIK the only OS where we *need* to link with libpython is MS Windows
because DLLs cannot be linked with unresolved symbols. So I can
actually make it controlled by ‘if MODULE_DEPENDENCIES’. Everywhere
else python has libpython already loaded so the dlopen()ed module just
resolves symbols against that.
What I am not sure about is the other things we get in PYTHON_LDFLAGS.
Regards,
Yeti

Seems like a good plan. Unfortunately it seems to me that what we get from "python-config --ldflags“ is not really what should be used to link extensions. Maybe the cleanest way is to let distutils/setuptools handle the tricky parts instead (i.e., call ... build_ext --inplace from the makefile).

Best regards,
Tino