Wed 30 Nov 2011 12:07:09 AM UTC, comment #19:
With the latest dev. source (after cb15c5185b6a ),
octave:1> test get_first_help_sentence
PASSES 7 out of 7 tests
The problem is now fixed so that this post can be closed.
|
Tue 29 Nov 2011 09:48:09 AM UTC, comment #18:
I checked in the following change:
http://hg.savannah.gnu.org/hgweb/octave/rev/cb15c5185b6a
It seems to fix the problem for me with Octave cross-compiled for Windows using MinGW and tested with a copy of Windows 7 running in a virtual machine. Let me know if the problem is not fixed for you.
|
Mon 28 Nov 2011 11:32:52 PM UTC, comment #17:
I have attached the patch (file #24480)
scripts\help\get_first_help_sentence.m ................. PASS 6/7 FAIL 1
The situation is the same as that when the previous patch (file #24431) is applied.
|
Mon 28 Nov 2011 08:31:37 AM UTC, comment #16:
OK, I'm attaching another patch, this time using mkostemp so that the mkstemp function can open files in binary mode. Does this work?
(file #24480)
|
Mon 28 Nov 2011 06:02:01 AM UTC, comment #15:
Perhaps fdopen is not able to rebind a file from text mode to binary mode? Some googling of the question didn't help much. All of the documentation I can find says only that the mode in fdopen must be consistent with the mode used to open the original file. So, if the original file was opened with append you can't rebind to just 'w'.
So, unfortunately the situation is back to using a hack in the .m file or integrating mkostemp from gnulib.
|
Thu 24 Nov 2011 04:39:16 AM UTC, comment #14:
I have attached the patch (file #24431)
The result is
scripts\help\get_first_help_sentence.m ................. PASS 6/7 FAIL 1
|
Wed 23 Nov 2011 06:56:42 AM UTC, comment #13:
Looking at this now, I don't think we need to use mkostemp. How about the attached change? Does it solve the problem? It simply adds "b" to the mode argument of the call to fdopen in the mkstemp function in file-io.cc.
(file #24431)
|
Wed 23 Nov 2011 04:41:51 AM UTC, comment #12:
Upgrading to blocker for 3.6.0 release. Either the submitted patch should be applied or mkostemp should be used. In either case this bug should be resolved and closed.
|
Tue 04 Oct 2011 04:06:25 AM UTC, comment #11:
I think I'd rather extend mkstemp to accept options, probably by using mkostemp internally. Let me see if I can do that quickly. If not, then I'll apply the other patch.
|
Tue 04 Oct 2011 03:58:28 AM UTC, comment #10:
It is natural the patch by Rik (file #24074) works for me.
|
Sun 02 Oct 2011 06:07:27 AM UTC, comment #9:
John,
I amended your patch so that it only applies to Windows systems and the other operating systems get to use a real mkstemp. If you think it is fine then please commit it.
(file #24074)
|
Wed 29 Jun 2011 09:31:20 PM UTC, comment #8:
I applied your patch.
Problem seems to be fixed.
Thanks!
Please pushed patch to both the stable and development brances.
|
Wed 29 Jun 2011 03:13:08 PM UTC, comment #7:
Does the change attached in diffs-2.txt fix the problem for you?
I don't think this is the best fix, but if it works, I think I understand the problem, which is that mkstemp uses text mode to open files by default. I guess we need to use mkostemp instead and specify the mode as binary. But Octave doesn't currently have a binding for mkostemp.
(file #23587)
|
Wed 29 Jun 2011 09:05:12 AM UTC, comment #6:
>If you apply the attached patch, what is the output from running
>on your system?
|
Wed 29 Jun 2011 04:51:27 AM UTC, comment #5:
That looks normal, with no CR characters. So how do they get added?
If you apply the attached patch, what is the output from running
on your system?
(file #23586)
|
Wed 29 Jun 2011 04:42:40 AM UTC, comment #4:
>What is the output of
>[ht, fmt] = get_help_text ('get_first_help_sentence');
>toascii (ht(1:250))
>on your system?
The result is
|
Wed 29 Jun 2011 04:26:10 AM UTC, comment #3:
OK, so the first six characters are a combination of CR and SPC, so I guess we are not handling CR somewhere that we should. I tried adding CR to the ends of the lines of a function file on my system but I don't see this result.
What is the output of
on your system?
|
Wed 29 Jun 2011 04:12:56 AM UTC, comment #2:
Thanks for your reply.
>It looks like you have some extra space at the beginning of the line.
>What is the output of
>toascii (get_first_help_sentence ('get_first_help_sentence'))
>on your system?
The below is the result
|
Wed 29 Jun 2011 03:52:12 AM UTC, comment #1:
It looks like you have some extra space at the beginning of the line.
What is the output of
on your system?
|
Wed 29 Jun 2011 03:12:49 AM UTC, original submission:
Test of get_first_help_sentence fails on MinGW.
get_first_help_sentence('get_first_help_sentence') seems not to return simple strings. Am I right?
|