Hi Schorsch, You can download the files from this link <https://dl.dropboxusercontent.com/u/16228160/sunlighthours_round_III.zip>.
For anyone who might be interested here is the original discussion <https://unmethours.com/question/17201/rcontrib-misses-one-of-the-modifiers-if-number-of-modifiers-between-240-420/> on unmethours. Thanks, Mostapha On Thu, May 12, 2016 at 4:09 AM, Georg Mischler <[email protected]> wrote: > 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 >> -schorsch >> >> PS: 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, >>> -Greg >>> >>> >>> FROM: 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. >>>> Mostapha >>>> >>>> On 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, >>>> -Greg >>>> >>>> FROM: 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/ >
_______________________________________________ Radiance-dev mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/radiance-dev
