Difference between revisions of "User talk:Darkcanuck"
Darkcanuck (talk | contribs) (→CassiusClay 2rho.02mg crashing: replies) |
|||
(9 intermediate revisions by 5 users not shown) | |||
Line 113: | Line 113: | ||
ALSO and even more puzzling, jab.DiamondStealers has managed to get 34 pairings in a 34 participant rumble, shouldnt this be at 33 max? im guessing a result of it paired against itself has slipped in somehow.... | ALSO and even more puzzling, jab.DiamondStealers has managed to get 34 pairings in a 34 participant rumble, shouldnt this be at 33 max? im guessing a result of it paired against itself has slipped in somehow.... | ||
--[[User:Quietus|Quietus]] 01:50, 11 September 2010 (UTC) | --[[User:Quietus|Quietus]] 01:50, 11 September 2010 (UTC) | ||
+ | |||
+ | I've never run the team rumble (it never worked for me) but it looks like tema ImWithStupid ''is'' downloadable. What error message do you get when roborumble tries to download or run it? DiamondStealers is stuck with an old pairing number from when it last ran almost a year ago -- the pairing number won't update until it gets another battle. Maybe it is generating an error too? --[[User:Darkcanuck|Darkcanuck]] 02:27, 11 September 2010 (UTC) | ||
+ | |||
+ | == Diamond 1.6.1 exceptions? == | ||
+ | |||
+ | Hey, do you see any exceptions / being stopped from Diamond 1.6.1 on your client? I see a couple painful results: [http://darkcanuck.net/rumble/BattleDetails?game=roborumble&name=voidious.Diamond%201.6.1&vs=kc.serpent.Hydra%200.21] [http://darkcanuck.net/rumble/BattleDetails?game=roborumble&name=voidious.Diamond%201.6.1&vs=sul.Pinkbot%201.1]. --[[User:Voidious|Voidious]] 02:57, 22 August 2011 (UTC) | ||
+ | |||
+ | : Ouch! No, I don't see anything on the console for those two cases -- does Diamond save exception data anywhere? --[[User:Darkcanuck|Darkcanuck]] 03:44, 22 August 2011 (UTC) | ||
+ | |||
+ | : No, he doesn't, but thanks for checking. Hopefully it's just an anomaly - I don't think recalculating all bullet shadows on one tick is much CPU compared to all the precise prediction / precise intersection I do each tick. Unless there's some obscure bug... --[[User:Voidious|Voidious]] 03:52, 22 August 2011 (UTC) | ||
+ | |||
+ | == CassiusClay 2rho.02mg crashing == | ||
+ | Similar question to the one above. It seems my latest CC experiment runs into crashing problems. An example: | ||
+ | |||
+ | http://darkcanuck.net/rumble/BattleDetails?game=roborumble&name=pez.rumble.CassiusClay%202rho.02mg&vs=quietus.NarrowRadar%200.1 | ||
+ | |||
+ | I can't recreate it. It seems it's always on from your rr@h client (only you and I running battles at the moment, I think). I see you ask Voidious, above, if he saves exception data somewhere. Is there a way I can do that generally to facilitate debugging of these situations? | ||
+ | |||
+ | -- [[User:PEZ|PEZ]] 11:29, 8 November 2011 (UTC) | ||
+ | |||
+ | It seems to be about reading or writing those gun stats this time too: | ||
+ | |||
+ | http://darkcanuck.net/rumble/BattleDetails?game=roborumble&name=pez.rumble.CassiusClay%202rho.02me&vs=ahf.r2d2.R2d2%200.86 | ||
+ | |||
+ | But why would this be specially tricky on your machine? | ||
+ | |||
+ | -- [[User:PEZ|PEZ]] 15:55, 8 November 2011 (UTC) | ||
+ | |||
+ | : Not sure what's different about my machine.... it is picky about the memory and CPU requirements, since it's just a mac mini that has the other core occupied with some work stuff. About the exceptions, some folks have added debug code to log exceptions to a file -- if CC does that I'd be happy to pass on your log files. I haven't written any code like that myself, but I think Skilgannon and Skotty have. --[[User:Darkcanuck|Darkcanuck]] 03:21, 12 November 2011 (UTC) | ||
+ | |||
+ | :: I'm curious Darkcanuck, what Java version is on that mac mini? If ancient Java 1.5, then... hm --[[User:Rednaxela|Rednaxela]] 04:50, 12 November 2011 (UTC) | ||
+ | |||
+ | ::: Java 1.6.0_26-b03-384-10M3425) -- it's a fairly new mini, just picked it up in the spring. Still running Snow Leopard, but otherwise up to date. --[[User:Darkcanuck|Darkcanuck]] 16:49, 12 November 2011 (UTC) | ||
+ | |||
+ | :: A similar thing happens with YersiniaPestis sometimes. I've had some really high scores against YersiniaPestis before because the battles ran on Darkcanuck's server. YersiniaPestis and Darkcanuck's server don't seem to get along. At the moment, I can't remember if it was YersiniaPestis 3.0 or the other version that was out there for awhile. -- [[User:Skotty|Skotty]] 06:38, 12 November 2011 (UTC) | ||
+ | |||
+ | ::: It's always seemed like YP 3.0 has some intermittent bug because it's results are more variable than they should be. It's not always my client, see [http://darkcanuck.net/rumble/BattleDetails?game=roborumble&name=zyx.mega.YersiniaPestis%203.0&vs=xander.cat.XanderCat%2010.25] or any other high-pbi for examples. --[[User:Darkcanuck|Darkcanuck]] 16:49, 12 November 2011 (UTC) |
Latest revision as of 17:49, 12 November 2011
Archived chat from old wiki: Jan 2008 |
Contents
E-mail notifications
Hey, just wanted to let you know that the e-mail notifications are working. I'd never played with the wiki e-mail stuff at all, so I checked existence of sendmail, tried to confirm my e-mail to see what error I got, and it worked. I can only deduce that the recent OS upgrade server maintenance did something different that didn't break it (like install sendmail)? Anyway, let me know if you have any problems with it. --Voidious 23:23, 22 July 2009 (UTC)
- Nice, I think it's working. Got the confirmation email at long last... =) --Darkcanuck 05:59, 23 July 2009 (UTC)
Snow Leopard?
Hey - have you upgraded to Snow Leopard? If so, have you run a RoboRumble client? After quite a few minor annoyances already tonight with Snow Leopard, I was really bummed to run into this when I ran RoboRumble (not every match):
Exception in thread "AWT-Shutdown" java.lang.IllegalThreadStateException at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:832) at java.lang.Thread.init(Thread.java:344) at java.lang.Thread.<init>(Thread.java:410) at sun.awt.AppContext$CreateThreadAction.run(AppContext.java:522) at java.security.AccessController.doPrivileged(Native Method) at sun.awt.AppContext.stopEventDispatchThreads(AppContext.java:542) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:290) at java.lang.Thread.run(Thread.java:637)
It was kinda nice for those 10 days of Leopard on the MacBook Pro being able to run an Apple JVM with the RoboRumble, but I guess it's back to SoyLatte for me...
--Voidious 03:17, 2 September 2009 (UTC)
- That error is not OS related, it's a Roborumble bug. I see it in my work computer too (Win XP), after a while the client freezes. It has been preventing me from contributing more to the melee rumble. --ABC 09:41, 2 September 2009 (UTC)
- Same here, I've seen this regularly since I started with 1.6.1.4. Doesn't seem to have influence on the results though. Seems to happen more often if the system is rather busy, like refreshing RR rankings. My client doesn't freeze, so contributing is no problem. --GrubbmGait 11:01, 2 September 2009 (UTC)
- That sucks... I did upgrade on Sunday, although I haven't tried roborumble yet, my CPU has been occupied with targeting and movement experiments. Maybe the new rumble beta will be better? --Darkcanuck 03:32, 2 September 2009 (UTC)
- You know what, this is embarrassing, but I think I was actually running SoyLatte those 10 days of Leopard + MBP, anyway. I remember checking the Java version at some point, but it must have been before I fixed my shell to be tcsh, which loaded my .cshrc and pointed back at SoyLatte. I was definitely seeing the X11 app load (which I knew seemed odd). The net being that I am still getting the above error in SL + MBP + RoboRumble, but it may not be new to Snow Leopard... --Voidious 04:05, 2 September 2009 (UTC)
Aha! Well, I just did a local test and it seems to be fine here. In Leopard I had to download the 64-bit build of Java 1.6 separately (from Apple) but I'm not sure if it was made the default in Snow Leopard. This is my "java -version" output:
java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)
--Darkcanuck 04:20, 2 September 2009 (UTC)
What other "minor annoyances" have you found? I miss iStat Menus -- now I have to listen to fan intensity to tell if RoboResearch is still running in another space... --Darkcanuck 04:25, 2 September 2009 (UTC)
Exposé and Spaces seem a bit choppy, which really bothers me - that's the biggest one. A quick search showed a lot of others with this gripe. I also dislike this "Recipient Bar" in iChat message windows that I cannot disable (only for contacts for whom I have both AIM and Jabber accounts in my buddy lists, but that includes several of my main contacts). Minor stuff, really, but given a lack of any huge features that are drawing me in, it's been a pretty underwhelming upgrade so far... Maybe I'll wait for .1 from now on. --Voidious 04:38, 2 September 2009 (UTC)
- Hmm, I never use iChat or Expose, but I'm very much a Spaces junkie and haven't really noticed much. I was sold on the 7GB of freed drive space and Mail seems more stable so far. Mouse transition into VMWare is the only thing bothering me, but that could be an application issue. Overall I like the philosophy of a release that's focused on performance rather than features and the price was nice to boot. --Darkcanuck 04:52, 2 September 2009 (UTC)
- Today I was hearing from an avid mac user who is a coworker of mine, talking about the changes in Snow Leapord. While it's true it doesn't have many user-visible features, it has some very major under-the-hood updates. What I find particularly neat, is that benchmark scores were up by well over 10% when he updated to Snow Leopard, and as a developer, some of the new under-the-hood features like 'Grand Central Dispatch' seem really amazingly awesome... Anyways, I'm also pretty sure that the fact that Snow Leopard was primarily an under-the-hood update was why it was a significantly less expensive update than normal anyway. --Rednaxela 06:05, 2 September 2009 (UTC)
- I don't at all mean to sound like a hater. I think the under-the-hood improvements will pay huge dividends over time, especially when apps leveraging the new stuff start coming out. I love that OS X gets leaner and meaner over time instead of bloating and slowing down. But as for first impressions, having one of my very favorite OS X features (Exposé) perform considerably worse on brand spankin' new hardware was pretty frustrating, and there wasn't much else in terms of visible features to offset it mentally... --Voidious 14:44, 2 September 2009 (UTC)
I encountered a strange thing last night while doing some Diamond debugging. I was using the Apple JVM to run Robocode, because with Snow Leopard + SoyLatte, Robocode crashes when I open Preferences. With the Apple JVM (but not with SoyLatte), I found my 1v1 radar was slipping - for one turn, it would just not move. It turns out that execute() was simply never being called for that one tick (and no skipped turn was reported). It was a rare thing, not nearly often enough to affect results (imo), but easily reproducible in just a few rounds. It took me a while to realize it was not my radar code at fault. I'd be curious to hear if you can duplicate this... I can send you a bot that prints when it happens if you want. I still need to test it on Leopard/Apple Java 5, too. --Voidious 17:45, 8 September 2009 (UTC)
- Sure, either email it or put it up on digitari and I'll give it a try. I haven't noticed anything, but then all of my bots like skipping turns and I've never trusted how Robocode notifies bots of skipped turns anyway. My bots track two things: the number of skipped turn events received, plus the difference between the current tick (from getTime) and the last tick after every call to execute(). The second number is always smaller. --Darkcanuck 18:50, 8 September 2009 (UTC)
B26354
Hey man, been waiting for you to make a page for B26354, but since I'm not seeing one... =) What's up with this? If it's indeed an all-new melee bot from you, great work! (I only temper my congrats in case it is HawkOnFire movement or something, as your description was "a test"...) --Voidious 03:58, 9 September 2009 (UTC)
- Working on the second iteration, was going to make a page after getting to 2000 battles -- I forgot how long that takes in the meleerumble! It's not a HawkOnFire clone, although the minimum risk component is definitely inspired by it (rozu is a genius). The movement is a wave surfing + min. risk hybrid which still needs more work. Targeting is a modified version of Gaff's NN setup, but with a melee gun similar to Shadow's strategy (which didn't actually work in the 1.00 release). Seems to do well in the mid-to-late game, but has trouble surviving to that point. I'll put up a page soon and lay most of your questions to rest... --Darkcanuck 04:10, 9 September 2009 (UTC)
I Just added some debug in my User_talk:DavidR#Melee_client_problem.3F page about the problems with my meleerumble client. --DavidR 09:07, 3 December 2009 (UTC)
Weirdness in the rumble
Just as a heads up in case this gets your attention... LBB 1.58 is having weirdness in the rumble, with clients stuck running it. See LittleBlackBook#Bot_Blog. --Rednaxela 19:47, 14 January 2010 (UTC)
- Thanks for mentioning it, should be clearing up now... --Darkcanuck 21:20, 14 January 2010 (UTC)
- I also posted on source forge about this last night. It's my fault completely on this one - a codesize goof up on my local system caused the cascade. I'm quickly throwing together a LBB 1.60 to retire 1.59 which should stop the loop. Or you can fix it locally :) --Miked0801 21:26, 14 January 2010 (UTC)
- The way the clients work bots end up getting cached for up to 2 hours so there's not much I can easily do to break the loop. Let 1.59 get to full pairings, THEN replace it with a new bot. --Darkcanuck 21:30, 14 January 2010 (UTC)
- Can you force a run of the following bots? That will fix it immediately...
ahf.Acero 1.0 apv.NanoLauLectrik 1.0 arthord.NanoSatanMelee Beta braaropolis.Abot 1.0 bzdp.Pansy 2.1 chickenfuego.UrChicken2 1.0 codemojo.nano.Woot 1.0 demetrix.nano.Neutrino 0.27 donjezza.Jezza 1.0 jep.nano.Hawkwing 0.4.1 kc.nano.Splinter 1.2 kinsen.nano.Quarrelet 1.0 mz.AdeptBSB 1.03 mz.NanoGod 2.02 nz.jdc.nano.NeophytePRAL 1.2 nz.jdc.nano.NeophytePattern 1.0 oog.nano.Fuatisha 1.0 oog.nano.MagicD2 2.4 oog.nano.SavantVS 1.1 ratosh.Nobo 0.21 ratosh.Wesco 1.4 repositorio.NanoStep 1.0 robar.nano.Pugio 1.49 sam.Samspin 1.0 spinnercat.CopyKat 1.2.3 spinnercat.Kitten 1.6 stelo.FretNano 1.1 tobe.calypso.Calypso 4.1 wiki.nano.RaikoNano 1.1 zyx.nano.EscherichiaColi 1.0
More Weirdness in the rumble
in the teamrumble pedersen.ImWithStupid hasn't paired and I'm currently unable to download it to fix its pairings,
ALSO and even more puzzling, jab.DiamondStealers has managed to get 34 pairings in a 34 participant rumble, shouldnt this be at 33 max? im guessing a result of it paired against itself has slipped in somehow.... --Quietus 01:50, 11 September 2010 (UTC)
I've never run the team rumble (it never worked for me) but it looks like tema ImWithStupid is downloadable. What error message do you get when roborumble tries to download or run it? DiamondStealers is stuck with an old pairing number from when it last ran almost a year ago -- the pairing number won't update until it gets another battle. Maybe it is generating an error too? --Darkcanuck 02:27, 11 September 2010 (UTC)
Diamond 1.6.1 exceptions?
Hey, do you see any exceptions / being stopped from Diamond 1.6.1 on your client? I see a couple painful results: [1] [2]. --Voidious 02:57, 22 August 2011 (UTC)
- Ouch! No, I don't see anything on the console for those two cases -- does Diamond save exception data anywhere? --Darkcanuck 03:44, 22 August 2011 (UTC)
- No, he doesn't, but thanks for checking. Hopefully it's just an anomaly - I don't think recalculating all bullet shadows on one tick is much CPU compared to all the precise prediction / precise intersection I do each tick. Unless there's some obscure bug... --Voidious 03:52, 22 August 2011 (UTC)
CassiusClay 2rho.02mg crashing
Similar question to the one above. It seems my latest CC experiment runs into crashing problems. An example:
I can't recreate it. It seems it's always on from your rr@h client (only you and I running battles at the moment, I think). I see you ask Voidious, above, if he saves exception data somewhere. Is there a way I can do that generally to facilitate debugging of these situations?
-- PEZ 11:29, 8 November 2011 (UTC)
It seems to be about reading or writing those gun stats this time too:
But why would this be specially tricky on your machine?
-- PEZ 15:55, 8 November 2011 (UTC)
- Not sure what's different about my machine.... it is picky about the memory and CPU requirements, since it's just a mac mini that has the other core occupied with some work stuff. About the exceptions, some folks have added debug code to log exceptions to a file -- if CC does that I'd be happy to pass on your log files. I haven't written any code like that myself, but I think Skilgannon and Skotty have. --Darkcanuck 03:21, 12 November 2011 (UTC)
- I'm curious Darkcanuck, what Java version is on that mac mini? If ancient Java 1.5, then... hm --Rednaxela 04:50, 12 November 2011 (UTC)
- Java 1.6.0_26-b03-384-10M3425) -- it's a fairly new mini, just picked it up in the spring. Still running Snow Leopard, but otherwise up to date. --Darkcanuck 16:49, 12 November 2011 (UTC)
- A similar thing happens with YersiniaPestis sometimes. I've had some really high scores against YersiniaPestis before because the battles ran on Darkcanuck's server. YersiniaPestis and Darkcanuck's server don't seem to get along. At the moment, I can't remember if it was YersiniaPestis 3.0 or the other version that was out there for awhile. -- Skotty 06:38, 12 November 2011 (UTC)
- It's always seemed like YP 3.0 has some intermittent bug because it's results are more variable than they should be. It's not always my client, see [3] or any other high-pbi for examples. --Darkcanuck 16:49, 12 November 2011 (UTC)