Ah, so now I figured that this wasn't actually on radiance-dev to begin with...
Mostapha, have you considered joining the list for a while?
And please see my query just below.
Cheers
-schorsch
···
Am 2016-05-12 09:10, schrieb Georg Mischler:
There's no way for this to be the same problem we recently identified.
For one, I don't think Robs gcc is using the MS Universal CRT from
Windows 10 which caused that one. And secondly, the character that gets
eaten here is nowhere near a line ending.Mostapha, can you send me your current test dataset? I only have the
version with 420 names, which does not seem to cause trouble anymore.
Then I'll check if the SCons build has the same issue, and if so,
walk through it to see what really happens.Cheers
-schorschPS: I'm following radiance-dev, no need for a seperate cc.
Am 2016-05-12 00:39, schrieb Gregory J. Ward:
OK, this seems to happen when a Windows read operation ends halfway
through a "\r\n" sequence, leaving a '\r' at the end of one buffer and
reading a '\n' character at the beginning of the next read() call. It
isn't a bug in my code as far as I'm concerned, as Unix handles this
case just fine. Rather, I think there's a bug in the way Windows
replaces "\r\n" with "\n" so that it ends up replacing "\ns" in this
case with the empty string, effectively lobbing the first character
off the returned buffer.We can test this by running a couple of read() calls on an input
buffer such that the length of the read splits an EOL sequence. This
may be the source of the occasional dropped characters Schorsch was
seeing in his earlier tests. Microsoft said they will fix this at
some point....Meanwhile, we could try setting the _O_BINARY flag in the open()
command in wordfile(), assuming we won't run into the ^Z EOF marker
that Schorsch claims is just a childhood trauma of mine and nothing to
fear these days...If Rob is willing to re-compile the librt.a in src/common using the
attached version of wordfile.c and link it with the debug version of
rcontrib, we can see if it makes any difference to test my hypothesis.Cheers,
-GregFROM: Mostapha Sadeghipour <[email protected]>
SUBJECT: Re: NREL Radiance re-distribution
DATE: May 11, 2016 3:17:59 PM PDT
Thanks Greg! Let me know if there is anything that I can do on my
side to help.
MostaphaOn Wed, May 11, 2016 at 6:09 PM, Gregory J. Ward >>> <[email protected]> wrote:
Hi Mostapha,
Your screen capture came through -- now we're getting somewhere!
The error again happens near the boundary between read() calls, so
it's a matter of figuring out what could be going wrong on Windows
even after the earlier bug fix.Schorsch has noticed issues with dropped bytes on stdin, but I don't
think we've seen this sort of problem with file input. It could
still have something to do with the conversion of "\r\n" EOL
sequences to "\n" in O_TEXT input files, but I need to think how
this might happen.More later,
-GregFROM: Mostapha Sadeghipour <[email protected]>
DATE: May 11, 2016 2:44:18 PM PDT
Thanks Rob! Dropbox link worked. Maybe I was doing something wrong.
I think we're close. New rcontrib prints out some notes which show
that solar1216 is picked up as 8-letter modifier `olar1216` missing
the starting s. The rest are 9 letter modifiers. That should be why
it never shows up?I almost never copy images in an email but I hope this one shows up
right. Let me know if it wasn't and I can save and attach it.Mostapha
--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/