Mhm, have a ticket submission where you submit ONLY the code, it runs it in a simulation in some far away computer, or the cloud? Then via a link you can search bots and find the positions of them and the bots above/below them? It'd thus include every bot efficiently as well?

Logged

Autism can allow so much joy, and at the same time sadness to be seen. Our world is weird, and full of contradiction everywhere, yet somehow at moments seems to come together, and make near perfect sense.

Mhm, have a ticket submission where you submit ONLY the code, it runs it in a simulation in some far away computer, or the cloud? Then via a link you can search bots and find the positions of them and the bots above/below them? It'd thus include every bot efficiently as well?

My thinking was that a web crawler/spider could go through all the bots in the bestiary. So you'd only need to submit a bot to the bestiary and it'd get run somewhere. That's mildly hard thing #1, as I don't have any experience with crawlers/spiders, and extracting out the code for bots is not as easy as it could be because there's no common template followed.

Running the leagues could happen in theory on the web server, but we'd need to be very careful to throttle the CPU so it doesn't make the site less responsive. It's thankfully not IO bound so the only resource we'd really have to throttle is CPU, and that could work with a process priority flag I think. But DB2 isn't set up to be run from the command line and certainly not from a linux box natively. That's mildly hard thing #2.

Then you'd want to post the results to a webpage and keep it updated. The page isn't hard but extracting out the info from DB2 might be, depending on how much of the league text files still get used. So mildly hard thing #3.

Mhm, have a ticket submission where you submit ONLY the code, it runs it in a simulation in some far away computer, or the cloud? Then via a link you can search bots and find the positions of them and the bots above/below them? It'd thus include every bot efficiently as well?

My thinking was that a web crawler/spider could go through all the bots in the bestiary. So you'd only need to submit a bot to the bestiary and it'd get run somewhere. That's mildly hard thing #1, as I don't have any experience with crawlers/spiders, and extracting out the code for bots is not as easy as it could be because there's no common template followed.

Running the leagues could happen in theory on the web server, but we'd need to be very careful to throttle the CPU so it doesn't make the site less responsive. It's thankfully not IO bound so the only resource we'd really have to throttle is CPU, and that could work with a process priority flag I think. But DB2 isn't set up to be run from the command line and certainly not from a linux box natively. That's mildly hard thing #2.

Then you'd want to post the results to a webpage and keep it updated. The page isn't hard but extracting out the info from DB2 might be, depending on how much of the league text files still get used. So mildly hard thing #3.

My point of ticket submissions is just to solve the no common template, beastiary can stay to share bots to other users...Possibly an access through the league results to, as [SOME] people like to explain their bots more for other people...Just reserve some CPU usage for the website, or as leagues run in background just give it priority so check how much the website will demand to function smoothly(ish) then leave the rest over to the leagues?Extracting info from leagues...Have a webpage with a table, column 1 is bot name, column 2 is creator, column 3 date submitted, column 4 a link to the code of it, column 5 the score it got (maybe Nrg of all the bots of that species added together then divided by population? then it doesn't favour cancerous bots like the current leagues do)

Logged

Autism can allow so much joy, and at the same time sadness to be seen. Our world is weird, and full of contradiction everywhere, yet somehow at moments seems to come together, and make near perfect sense.

But again, my complete and absolute hatred of the current DB2 codebase makes this sort of moot anyway.

Why do you hate the current code so much? I hope it is not all my fault. Although I can see why you might think my attempt at a port will fail because you hate the current code anyway. Still, I would like to get some pointers from you on this when you have a chance.

P.S.I feel like with all that went down here over the years we lost respect for one another and what put us together in the first place. We love to program systems that emulate biology. Unfortunately this is not as fun as it first seems as proven by PY and Eric leaving and no way to contact them. I did try to contact Eric on a couple occasions to help me out with IM with no luck.

But again, my complete and absolute hatred of the current DB2 codebase makes this sort of moot anyway.

Why do you hate the current code so much? I hope it is not all my fault. Although I can see why you might think my attempt at a port will fail because you hate the current code anyway. Still, I would like to get some pointers from you on this when you have a chance.

I suspect it has to do with VB6 and the capabilities of it. It's not as flexible and powerful as modern languages. Sadly it isn't easy to recreate everything in a new language, a lot has already been build in DB2.

It's a combination of the language and the code base itself. Basically, error handling in VB6 is terrible, and there's all sorts of weird performance overhead on things. It's also impossible to merge changes to forms created by the form creator, which is an important thing for a collaborative open source project. Everything it was meant to be, VB.NET does better.

The code base itself is sloppy spaghetti tied together with duct tape and hope. None of it is tested, so if you make one change, even seemingly innocuous, it might (and probably will) break everything. We could fix that by adding tests, but there's no good testing framework for VB6, and even if there were, just changing the code enough to make it testable would probably break things. There are global variables all over the place that manage the simulation state, and of course all sorts of random things will poke and prod at this state from everywhere and anywhere in the code.

The few times I've tried to do anything in the codebase have always been 10000% harder than they should be. It's a classic example of a codebase that grew larger than it was architected to grow.

Agree about the spaghetti. It got reasonably bad in a couple of places. Getting rid of the goto will help. Some though I looked at but did not really figure out. One particular that drives me crazy is how the flow command logic is executed. It is a mess and it does not even let you do a start and an else block in one gene. I will have to revisit this at some point when I actually figure out how to fix it.

One other thing that people complain about alot that I need professional opinion on is the global variables. I admit I am guilty of using them often. But my question is in ideal conditions what do I replace them with? I made them public so they save state outside the scope of a subroutine. I could have gone with static but than I would not be able to capture there state for the save simulation code.

Edit: A little follow up question: I think the code (although messy in a few places) is tied together reasonably well. I assume you mean there are better ways to tie code together in a more object driven language. Still more detail on this will be good. Edit: Actually answered this question myself by looking on the DB3 Core module that was just released. However, DB2 was never built object oriented, and refactoring it in a major way like this will probably break most of it. :/

I get tests. What I am really asking is mechanics of stuff like this.The only experience with fully object oriented programming I had was an old XNA book which I never finished reading because I found "Black Art of 3D game programming" to be a far more interesting read. And than XNA got replaced with Unity.