 |
| Stephen Brooks 2012-10-23 16:02:02 | Muon1 occasionally produces results with "nan" as their score. It's on the list as a bug to be fixed in the next release, but for now I'm changing the stats generator to reject "nan" results (they manifested in a problem with the successive-best files, which K`tetch noticed). Typically each of these will be a short simulation so only worth 100-200 Mpts, so reductions in scores shouldn't be huge. |
| Zerberus 2012-10-24 00:29:28 | No problem, if they do not bear any scientific value. |
| Zerberus 2012-10-24 01:09:08 | P. S. And, pretty please, fix the -txttobin and -bintotxt options in next version. They still cause a crash when used, currently. |
| Stephen Brooks 2012-10-24 18:14:13 | Can't remember offhand if I've already fixed this. Can you try the EXE in this development version with your input that's crashing it? |
| Zerberus 2012-10-24 21:20:06 | Trying a bin (samples) from the muon1 front page. Released muon1: Faulting application name: muon1.exe, version: 0.0.0.0, time stamp: 0x4d8c8f81 Faulting module name: muon1.exe, version: 0.0.0.0, time stamp: 0x4d8c8f81 Exception code: 0xc0000005 Fault offset: 0x0000a5ef Faulting process id: 0x1b8c Faulting application start time: 0x01cdb2249a84be52 Faulting application path: D:\Program Files\muon_\muon1.exe Faulting module path: D:\Program Files\muon_\muon1.exe Report Id: d926b552-1e17-11e2-a423-0015172156a0 |
| Zerberus 2012-10-24 21:20:30 | Muon dev version: Faulting application name: muon1dev.exe, version: 0.0.0.0, time stamp: 0x50784562 Faulting module name: muon1dev.exe, version: 0.0.0.0, time stamp: 0x50784562 Exception code: 0xc0000005 Fault offset: 0x0000aeb9 Faulting process id: 0xab8 Faulting application start time: 0x01cdb224a343d172 Faulting application path: D:\Program Files\muon_\muon1dev.exe Faulting module path: D:\Program Files\muon_\muon1dev.exe Report Id: e0f5c322-1e17-11e2-a423-0015172156a0 |
| Zerberus 2012-10-24 21:24:17 | Tried a convert a .txt samplefile into .bin with the same results. The conversion itself can't be the problem as it works in the program. |
| Stephen Brooks 2012-10-25 01:57:51 | OK, will add this to the bug list tomorrow, may have a go at fixing it. |
| Stephen Brooks 2012-10-25 12:00:29 | Was quite a simple error: the -bintotxt switches try to write output to the graphics screen instead of the console as a default, but the conversion process takes place before the screen has been initialised. So instead I set the output mode to commandline for these switches. Here is the fixed version. I also realise last time I didn't have debug/stack trace switched on so you just got meaningless crashes... Can you check the above works with -bintotxt and if you have time, that the other miscellaneous commandline switches don't crash as well? |
| Zerberus 2012-10-25 23:06:21 | Made a few tests with the -txttobin and -bintotxt switches. Conversion of a 100-samples file forth and back now works without a problem. The same with a ~28MiB results.dat file (don't know if they are supposed to be convertible). With a 93MiB results.dat -txttobin succeeded, but -bintotxt failed. --------------------------- lcc runtime: GP fault. Stack trace --------------------------- 0 Results_read_Binary [22] c:\sjb39\muon1\muon1.c 324 1 Results_load_Binary [4] c:\sjb39\muon1\muon1.c 362 2 detectswitches [32] c:\sjb39\muon1\muon1.c 251 3 SBCLIB_main2 [6] c:\sjb39\muon1\muon1.c 63 4 WinMain [0] c:\sjb39\muon1\muon1.c 57 Fault occurred outside a function scope Current instruction: 0x6c24c3e0 Maybe the file size? The .bin size was down to 26MiB. |
| Stephen Brooks 2012-10-26 12:24:34 | That's odd (and probably means there's an occasionally-triggered bug in there that I should fix). Is there any way you can get the original 93MB results.dat file to me? E.g. putting on a web server or uploading to Google Docs or something? |
| Zerberus 2012-10-26 22:12:54 | http://ul.to/6jt2a1xs (14.7 MiB ZIP compressed) I uploaded it to a file service (I don't have permanent storage on the web). It's a long living database, so there may be errors in it, though it passed the sanity checks of your programs. But it's too large to check by eye. |
| K`Tetch 2012-10-28 03:31:47 | Thats what something like Dropbox is perfect for, Zerberus - http://db.tt/M4ioXeD to get a little extra space over normal [Edited by K`Tetch at 2012-10-28 03:33:29] |
| Zerberus 2012-10-28 08:43:50 | Yes, but DropBox requires registration. Don't want to register anywhere and everywhere. But thanks for the offer. |
| Stephen Brooks 2012-10-29 15:00:08 | I've got the file and the processes both ways worked fine:C:\sjb39\muon1>muon1 -txttobin results_Zerberus.datDid you remember to choose the right file extensions and switch combinations? (I went .dat -> .bin -> .txt) The file sizes went (97,841,338 bytes) -> (27,118,203 bytes) -> (97,747,343 bytes) with the last one being smaller because binary format does not store the comments. |
| Zerberus 2012-10-30 06:28:43 | Just tested again. C:\>D: D:\Program Files\muon\muon.a>muon1dev.exe -txttobin results.dat Loading 'results.dat'... OK (35020 results) Binary saved 35020 results D:\Program Files\muon\muon.a>muon1dev.exe -bintotxt results.bin Binary loading results... header OK After that, the error popped up: --------------------------- lcc runtime: GP fault. Stack trace --------------------------- 0 Results_read_Binary [22] c:\sjb39\muon1\muon1.c 324 1 Results_load_Binary [4] c:\sjb39\muon1\muon1.c 362 2 detectswitches [32] c:\sjb39\muon1\muon1.c 251 3 SBCLIB_main2 [6] c:\sjb39\muon1\muon1.c 63 4 WinMain [0] c:\sjb39\muon1\muon1.c 57 Fault occurred outside a function scope Current instruction: 0x6c24c3e0 --------------------------- OK Cancel --------------------------- |
| Zerberus 2012-10-30 06:34:31 | This is really strange. If I do not specify the target filename on the commandline it fails, every time. If I do, it fails the first time, then starts to work. ??? With a renamed .bin file it doesn't work either way... |
| Stephen Brooks 2012-10-30 14:26:05 | I've just managed to reproduce your error with the odd feature thatmuon1.exe -bintotxt results_Zerberus.bincrashes, but muon1 -bintotxt results_Zerberus.binworks! I will investigate... |
| Stephen Brooks 2012-10-30 14:49:10 | Right, found the bug! It only manifests itself in files where the number of different lattices exceeds 9 (and yours had 46). Try this EXE and see if it now works for you. As before, testing the other commandline switches might also be useful to find bugs in the less-frequently-tested modes. Something interesting I found while doing this is that the combination of .bin format and 7-Zip compression is very powerful. File sizes in bytes:
|
| Zerberus 2012-10-31 13:36:23 | Will test ASAP. Maybe we could utilize the .bin format as the default one as it significantly reduces database sizes. Of course it depends on how fast random access to the .bin is, e. g. can you add entries to it without having to recalculate whole thing? |
| Stephen Brooks 2012-10-31 14:02:51 | Basically, no, and that's one reason why the .bin is not the preferred format except for long-term archiving and sending results (where bandwidth is important). The other is that I want it to be human readable and editable to an extent (like HTML/XML/CSV... formats). Even the stats server uses text format results because it wants to frequently add results to files. |
| Zerberus 2012-11-01 13:13:40 | Both switches seem to work fine now. And the other ones I tested don't produce crashes. If all really work 100% as intended needs testing by a larger audience. Note that currently it is incredibly slow, probably due to debugging code overhead. There's only one thing I couldn't get to work properly: Recording. How does that really work? Pressing r or R seems to do nothing in graphics mode. As for the .bin format, it already is used in the relevant places (when size is the issue). Too bad it cannot be used for the big results.dat databases, yet, as the size cut is amazing. [Edited by Zerberus at 2012-11-01 13:14:42] |
| Stephen Brooks 2012-11-01 16:23:18 | Thanks for testing the switches. Hopefully the slowness is the debugging (we'll know for sure when I release alpha versions of v4.46). Recording is either going to be updated or removed in the next version - it was originally intended to work with 256-colour palettes! I could remove it on the basis that FRAPS and similar programs do the same job better and don't output to my own weird format. |
| Zerberus 2012-11-02 08:59:07 | So the recording feature is dead and I'm not stupid. That's what I wanted to know.  I had an awkward moment when I first started and the particles were largely oversized (and the font too small to read). Seems there have been changes with the ''O'' (particle size) feature and the previous display.dat is incompatible, causing miniature font sizes. |
| Stephen Brooks 2012-11-21 17:57:16 | I've found out why your display.dat wasn't read properly: some time since v4.45 was released in March 2011, I added another field to the display structure and the routine to load and save it. This means if you run that routine on an old v4.45 display.dat file, everything after this field will be out of alignment! So I've rewritten that all to use the ASCII format of config.txt (there will be a display.txt file from now on), which is tolerant of new fields being added or removed. I've also preserved the read version of the binary format from v4.45 so it can automatically convert the old .dat files to .txt format. |
| Zerberus 2012-11-22 10:10:37 | I hope that it properly handles resolution changes from now on. Previously, changing resolution (especially raising it) broke the display because it still applied the old one. |
| Stephen Brooks 2012-11-22 14:50:41 | What exactly are you doing (and in what order) to get this resolution change bug? I don't know how you would change the resolution of your monitor WHILE the graphical client is running, for instance. |
| Zerberus 2012-11-22 20:19:21 | Nope, that bug doesn't exist anymore, sorry. Looks like I lost track. Possibly got smashed with the change to 16bit. I think we are good now. \o.O/ Edit: Yes, it was an old bug, I messed up my reports. FYI, it was discussed here [Edited by Zerberus at 2012-11-22 20:25:58] |
| Stephen Brooks 2012-11-26 14:40:03 | You had to wait 3 years but I did roll it up into v4.45 like I said I would  |
| Zerberus 2012-11-27 21:01:18 | Nothing more to report at the time being. Well, except, maybe, something funny in the config.txt... Use passive (PASV) mode for FTP transfers: Y/N My observations showed that enabling this option causes moun1 to send a QUOTE PASV to the server, just before sending the PUT/GET transfer command inside ftp.exe. It actually gave me a good laugh and made my day. Sending the QUOTE PASV command before sending PUT/GET inside ftp.exe is absolutely bogus and achieves exactly nothing, for multiple reasons: - Sending PASV to the FTP server is not enough, the client needs to handle the server replies. Microsoft ftp.exe doesn't do that. - If you switch Debug to ON in ftp.exe you'll see that after the ftp.exe client ignores the server's reply to PASV it sends a PORT command and thus re-initializes Active mode. - ftp.exe will never connect to the proposed IP and port from the PASV reply since it doesn't know how to. |
| Stephen Brooks 2012-11-27 22:25:06 | That's a very old feature (as is FTP sending overall). I never really looked into it but someone told me to write "QUOTE PASV" in the script to enable passive mode. The weird thing is, some people claimed it actually helped! Here's some reading if you're curious: http://www.google.co.uk/search?q=site: stephenbrooks.org+QUOTE+PASV |
| Zerberus 2012-11-28 01:34:17 | That someone is wrong. There is no way to teach Passive mode to the Windows ftp.exe, it has never supported it. If you send PASV to an FTP server, that server responds with an IP and a port to connect to. The Windows ftp.exe can not make any sense out of that information because: 1. It didn't request it. FTP is a strict command-response cycle. 2. Anything you send via QUOTE/LITERAL and the responses to this is ignored by ftp.exe, anyway. 3. It contains no code to decode the PASV response. 4. It sends a PORT command next which resets the server to Active mode. Short explanation Windows article The article states that all FTP clients shipping with Windows versions do not support Passive mode. However, I could imagine one scenario where this actually may make a difference. Most firewalls and routers permanently observe, check, and sometimes modify the FTP traffic that passes through them. It is possible some of them switch into an FTP friendlier mode when they encounter a PASV command, even if it is a fake one. [Edited by Zerberus at 2012-11-28 01:34:26] [Edited by Zerberus at 2012-11-28 01:36:44] |
