bugGNU Octave - Bugs: bug #61783, [octave forge] (image) errors...


bug #61783: [octave forge] (image) errors while installing image package on 7.0.90

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Mon 10 Jan 2022 05:20:13 AM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  avinoam
Originator Name:  Avinoam Open/Closed:  * Closed
Release:  * 7.0.90 Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Thu 13 Jan 2022 06:02:14 AM UTC, comment #7: 

Correction for fortran_vec pushed also

Thanks, @Markus & @Pantxo for the explanations.

Closing as fixed.

Avinoam Kalma <avinoam>
Project Member
Tue 11 Jan 2022 05:20:49 AM UTC, comment #6: 

Correction for namespace collision was pushed:


Avinoam Kalma <avinoam>
Project Member
Mon 10 Jan 2022 05:37:26 PM UTC, comment #5: 

Thanks, @Pantxo, I will replace fortran_vec with data.

Avinoam Kalma <avinoam>
Project Member
Mon 10 Jan 2022 05:17:42 PM UTC, comment #4: 

@Avinoam: AFAICS the warning about fortran_vec is displayed together with the solution

warning: ‘const T* Array<T, Alloc>::fortran_vec() const [with T = long int; Alloc = std::allocator<long int>]’ is deprecated: [7]: for read-only access, use 'data' method instead

So for const access to the elements of Array based classes you should use the "data" method as a replacement for "fortran_vec". The "data" method has been there since at least Octave 4.0 (see http://wiki.octave.org/Publications_about_Octave#Doxygen) and this should thus be backward compatible.

Pantxo Diribarne <pantxo>
Project Member
Mon 10 Jan 2022 08:05:19 AM UTC, comment #3: 

Thanks, @Markus for the detailed explanation.
I will use octave_image_pkg, and thus avoid future conflicts.

meanwhile, I have many deprecation warnings concerning fortran_vec.
How should I fix this warning?

Avinoam Kalma <avinoam>
Project Member
Mon 10 Jan 2022 07:44:22 AM UTC, comment #2: 

Adding to my previous comment: It might be best to avoid the `octave` namespace in packages to prevent possible collisions in the future. That namespace is used by Octave core and new objects or sub-namespaces might be added to it in the future...

Markus Mützel <mmuetzel>
Project Member
Mon 10 Jan 2022 07:36:15 AM UTC, comment #1: 

IIUC, that patch resolves a namespace collision with the graphics object `image` that has been moved to the `octave` namespace in Octave 7.
The image package seems to be using the namespace `octave::image`. That namespace collides with the object `octave::image` in Octave core.

The patch in MXE Octave resolves that namespace collision by renaming the namespace used by the image package to `octave_image`.
If you prefer, you can use any other namespace (that doesn't collide with Octave core). E.g. `octave::image_pkg` or whatever you deem best.

Renaming the namespace in the image package is independent of the version of Octave core. I.e., it can be done unconditionally for any version of Octave core (as long as it doesn't collide with a namespace used in any of those versions).

Markus Mützel <mmuetzel>
Project Member
Mon 10 Jan 2022 05:20:13 AM UTC, original submission:  

We are working on a new release of image package.
The release candidate works well on version 6.4.0,
but there are errors on version 7.0.90.
These errors are due to namespace change from
octave::image to octave_image, and are treated in patch

The question is: how can I apply this patch such that image package will continue to compile on previous releases of Octave?

Avinoam Kalma <avinoam>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by avinoam (Submitted the item)
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by avinoam

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-13 avinoam StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2022-01-11 avinoam StatusNone => In Progress
        Assigned toNone => avinoam
    2022-01-10 avinoam Carbon-Copy- => Added carandraug
        Carbon-Copy- => Added hardy
        Carbon-Copy- => Added mmuetzel

    Back to the top

    Powered by Savane 3.9