bugGNU Octave - Bugs: bug #46235, [octave forge] (windows) package...

 
 

bug #46235: [octave forge] (windows) package doesn't work anymore with newest Octave 4.1.0+

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Sat 17 Oct 2015 12:05:47 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  lostbard
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 03 Sep 2017 01:15:18 PM UTC, comment #12: 

Closing this old report.
On 4.3.0+ the OF windows package works fine

Philip Nienhuis <philipnienhuis>
Group Member
Mon 14 Aug 2017 08:52:51 PM UTC, comment #11: 
John Donoghue <lostbard>
Group Member
Sat 07 Nov 2015 05:59:41 PM UTC, comment #10: 

That's what I figured.
Actually OF packages with binary modules should depend on mkoctfile (= Octave) but only in case of --enable-binary-packages.
I'll have a first go at this later on, if no one beats me to it.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 07 Nov 2015 01:53:47 PM UTC, comment #9: 

Yeah I do believe there is no rule in there to force a rebuild if the octave target changes.

The easiest way perhaps woruld be to make octave a dependcay for all octave packages.

John Donoghue <lostbard>
Group Member
Fri 06 Nov 2015 08:51:04 PM UTC, comment #8: 

So yes, recompiling the windows package does the trick.

Does mxe-octave need a mechanism to recompile all packages if the Octave target proper has changed? 
I suppose that as all OF packages with binary modules depend on Octave, such a rule would be helpful.
OTOH I know I'm bending the system as I continuously feed "make all dist" targets to mxe-octave into an existing tree.

I now wonder if it'll work w/o --enable-binary-packages flag. I have no mxe build tree with that configure setting.

Shall I close this bug report with "Invalid", or shall I change the title to s/th like "OF packages in mxe-octave should depend on Octave" ?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 06 Nov 2015 07:42:08 PM UTC, comment #7: 

Hmmm... digging around I just noted that the mxe-cross built usr/..../src/windows-1.2.1.tar.gz package in the mxe-octave build tree dated back from August, 15  (I tend to re-use existing mxe-octave trees for some months, hg pull-updating them every once and a while).

I just touch-ed all src/of-*,mk files and now have a new build running.
If this works out OK I suppose some make interdependencies are wrongly configured. Or, I'm simply too naive with undue expectations :-) (very well possible)

I'll let you know how it goes.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 06 Nov 2015 05:16:44 PM UTC, comment #6: 

This was using a new build using configure settings:  $ ./configure --enable-octave=default --enable-binary-packages --enable-windows-64=yes --enable-devel-tools

So sounds like it should be the same as yours. Just 64bit OS, 32b index

John Donoghue <lostbard>
Group Member
Fri 06 Nov 2015 05:00:48 PM UTC, comment #5: 

I use that --enable-binary-packages flag as well.

Intriguing that is doesn't work with 64b Windows/32b indexing but does with 64b indexing.
BTW were you able to confirm my observation? i.e., does not work with W64/32b indexing ?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 06 Nov 2015 03:02:02 PM UTC, comment #4: 

Note, I used the binary package created with --enable-binary-packages when compiling mxe-octave

John Donoghue <lostbard>
Group Member
Fri 06 Nov 2015 11:35:53 AM UTC, comment #3: 


>> uname
ans =

  scalar structure containing the fields:

    sysname = MINGW32_NT-6.1
    nodename = JYRW4S1
    release = Windows 7
    version = Service Pack 1
    machine = x86_64

>>  app = actxserver ("Excel.Application")
app =

<COM object _Application (0x0x63e738)>
>> app.Visible = 1

app =

<COM object _Application (0x0xdd1b5c8)>

>> app.Visible = 0
app =

<COM object _Application (0x0xdd1b5c8)>

>> get(app.Workbooks, 'Count')

ans = 0

>> app.Quit()
ans = [](0x0)
>> delete(app)


John Donoghue <lostbard>
Group Member
Thu 05 Nov 2015 10:46:42 PM UTC, comment #2: 

With 20678:4b00afb5e9c3 it still doesn't work for X86_64 builds (just --enable-windows-64).
Have you tried if COM really works:
i.e.,

app = actxserver ("Excel.Application")
app.Quit()
delete (app)

?
(no guarantees that COM will work with MS-Office anyway for 64-bit indexing Octave)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 05 Nov 2015 06:07:36 PM UTC, comment #1: 

Using current tip (changeset 20677:0d5d8db55790), in Windows, build in 64 bit mode works for me.


>>  app = actxserver ("Excel.Application")
app =

<COM object _Application (0x0xe218818)>

>>


John Donoghue <lostbard>
Group Member
Sat 17 Oct 2015 12:05:47 PM UTC, original submission:  

The OF windows package has stopped working with recent Octave development versions.

## Trying to invoke LibreOffice:
>> objServiceManager = actxserver ("com.sun.star.ServiceManager")
error: actxserver: unknown ActiveX server ` L↕j'
>>

## ...or with MS-Excel:
>> app = actxserver ("Excel.Application")
error: actxserver: unknown ActiveX server `░%‼j'
>>


where the following is expected:

## LibreOffice
>> objServiceManager = actxserver ("com.sun.star.ServiceManager")

objServiceManager =

<COM object Unknown (0x0xd6e3848)>

>>

## or for Excel:
>> app = actxserver ("Excel.Application")
app =

<COM object _Application (0x0xd8d38b8)>

>>


Experimenting with older Octave binary Windows installers I have lying around shows that OF windows packages from the mxe-octave installers:

  • work fine with Octave rev. f61c67865d9f (~7 Oct.)
  • don't work anymore with Octave rev. 56333f6df823 (~10 Oct.)


(Those revisions and dates are of course just indicative - somewhere in between them the windows package stopped working.  I merely include the revision name when renaming the mxe-octave binary installers.)

The OF windows-1.2.1 package from the newest Octave binary I have (rev. ab705b42cfd8, ~15 Oct) installs and runs fine in an Octave installation from 7 Oct. 
So something inside Octave itself has changed.  Could this be the error_state changes?

Item Group => "Incorrect result" as I think core Octave changes affecting OF packages aren't to be perceived as "regressions".

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

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 jwe (Updated the item)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-09-03 philipnienhuis StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-08-14 lostbard StatusIn Progress Ready For Test
    2017-08-14 lostbard StatusNone In Progress
        Assigned toNone lostbard
    2017-08-13 jwe Summary[OF] windows package doesn't work anymore with newest Octave 4.1.0+ [octave forge] (windows) package doesn't work anymore with newest Octave 4.1.0+

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code