bugGNU Octave - Bugs: bug #33862, Test of sysdep.cc fail on dev....

 
 

bug #33862: Test of sysdep.cc fail on dev. source (MinGW)

Submitted by:  Tatsuro MATSUOKA <tmacchant>
Submitted on:  Tue 26 Jul 2011 04:08:53 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 30 Nov 2011 04:48:51 AM UTC, comment #9:

With the changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/efa658122cc9

src\sysdep.cc .......................................... PASS 13/13

FAIL is disappeared! Thanks.

Tatsuro MATSUOKA <tmacchant>
Wed 30 Nov 2011 04:39:24 AM UTC, comment #8:

Try a new tip after this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/efa658122cc9). Hopefully that changeset will fix the problem for you.

Rik <rik5>
Project Administrator
Wed 30 Nov 2011 04:16:29 AM UTC, comment #7:

The same fail still exits on recent development source.
However, this error is not critical.

Tatsuro MATSUOKA <tmacchant>
Tue 11 Oct 2011 02:26:16 AM UTC, comment #6:

I have built the recent dev. source.
(changeset 13311:d590d9df5596
date Mon Oct 10 15:08:48 2011 -0400)

Tatsuro MATSUOKA <tmacchant>
Thu 06 Oct 2011 11:23:09 PM UTC, comment #5:

One possibility is to change the left-hand side of the test rather than the right-hand side.

Rik <rik5>
Project Administrator
Thu 06 Oct 2011 11:10:38 PM UTC, comment #4:

I think the issue may lie in liboctave/file-ops.cc in function tilde_expand_word. The excerpt below is at line 220.

So it looks like "~/foobar" is immediately parsed as "~" and filename.substr (1) is "/foobar". Thus, no file separator is ever inserted.

Rik <rik5>
Project Administrator
Thu 06 Oct 2011 10:46:14 PM UTC, comment #3:

I think it is still a jumble. fullfile() and filesep both use '\' while tilde_expand is using '/'. Note that this is only for the last element of the path. One would think that tilde_expand would use '\' for all of the file separation locations but that would be wrong.

Tatsuro, could you run the following 3 lines of code to show clearly what each function returns

Rik <rik5>
Project Administrator
Thu 06 Oct 2011 09:42:12 PM UTC, comment #2:

I don't understand the fix.

So fullfile is using \ on Windows systems? That I would expect. But why is tilde_expand not producing a file with \ on Windows systems? And why is filesep returning /? I thought all of this worked in the past, with evertything producing \ on Windows systems. What changed?

John W. Eaton <jwe>
Project Administrator
Thu 06 Oct 2011 09:32:26 PM UTC, comment #1:

Fixed in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/4cca76e15876).

Rik <rik5>
Project Administrator
Tue 26 Jul 2011 04:08:53 AM UTC, original submission:

I found a new fail on the test of sysdep.cc

This fail is not so serious but I report it.

Tatsuro MATSUOKA <tmacchant>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by tmacchant (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 06 Oct 2011 09:32:26 PM UTCrik5StatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1