Timestamps are in GMT/BST.
| 00:04:44 | raptor | it compiled! and with no new warnings |
| 00:07:41 | raptor | Watusimoto: looks like we already do something in LuaScriptRunner::setModulePath() |
| 00:07:47 | raptor | is that sufficient? |
| 00:08:14 | raptor | looks good to me... |
| 00:08:35 | raptor | other than setting 'package' to nil (which will be done with the sandbox) |
| 00:08:40 | Watusimoto | probably... I thought so at one time |
| 00:09:06 | Watusimoto | that's what I was looking for earlier in the lua code |
| 00:10:02 | raptor | so with that, do we even need our 'include' function in the lua_helper_scripts.lua? |
| 00:12:01 | raptor | I'm going to change it to 'require' and see what happens |
| 00:13:05 | raptor | looks like it works! |
| 00:21:51 | raptor | oh interesting - i think kaen put all of our Geom library methods into c++ |
| 00:22:50 | raptor | oh wiat |
| 00:22:56 | raptor | no he didn't, that's something else |
| 00:33:46 | Watusimoto | he put additional methods into c++ |
| 00:34:35 | raptor | yes |
| 00:34:37 | raptor | ok |
| 00:34:44 | raptor | so... i think i can do our sandbox... |
| 00:34:51 | raptor | we don't need the loadfile function any more |
| 00:35:03 | raptor | and that leaves the strict stuff |
| 00:35:53 | Watusimoto | Hmmm... I pushed some changes, and they didin't show up here |
| 00:36:10 | raptor | checking BFLogBot... |
| 00:36:10 | BFLogBot | Be careful or be road-kill. -- Calvin |
| 00:36:12 | Watusimoto | they're in google code |
| 00:36:26 | Watusimoto | but those I pushed 40 mins ago did show up here |
| 00:36:45 | Watusimoto | there was a problem with the push, maybe that's the reason? |
| 00:37:32 | raptor | could be |
| 00:39:31 | raptor | no more UIYesNo? |
| 00:42:50 | raptor | looks like googlecode ddin't post to the web hook |
| 00:42:59 | raptor | so not a problem with logbot |
| 00:43:16 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 00:45:49 | Watusimoto | that was my guess as well. |
| 00:45:53 | Watusimoto | well... good night! |
| 00:46:18 | | Flynnn has joined |
| 00:46:23 | raptor | night! |
| 00:46:36 | raptor | maybe i'll get the sandbox working by tomorrow... |
| 00:47:42 | Watusimoto | maybe we'll get a release by christmas! |
| 00:47:59 | Watusimoto | (intended as a joke, maybe not obvious...) |
| 00:48:05 | raptor | heh... |
| 00:48:07 | raptor | ... |
| 00:48:36 | raptor | we keep promising ourselves not to ever again take as long as 016 to release |
| 00:48:50 | raptor | dinner! |
| 01:06:11 | | Watusimoto Quit (Ping timeout: 240 seconds) |
| 01:13:17 | | Nothing_Much Quit (Read error: Connection reset by peer) |
| 01:13:54 | | Nothing_Much has joined |
| 01:37:20 | | Platskies Quit (Quit: Platskies) |
| 01:39:13 | | Platskies has joined |
| 02:06:51 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 02:11:29 | | Flynnn has joined |
| 02:29:12 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 02:30:07 | | Flynnn has joined |
| 02:50:31 | | BFLogBot Commit: 335ffb326409 | Author: buckyballreaction | Message: Fix compiling |
| 02:53:28 | | Platskies Quit (Read error: Connection reset by peer) |
| 03:01:13 | | Platskies has joined |
| 03:02:36 | | Skybax has joined |
| 04:01:01 | raptor | question of the night: should I set _G to nil? |
| 04:15:54 | Skybax | What |
| 05:03:19 | | Nothing_Much Quit (Remote host closed the connection) |
| 05:13:06 | | sam686 has joined |
| 05:13:06 | | ChanServ sets mode +v |
| 05:48:31 | | Platskies Quit (Quit: Platskies) |
| 05:51:11 | | Platskies has joined |
| 06:13:11 | | Platskies__ has joined |
| 06:16:40 | | Platskies Quit (Ping timeout: 264 seconds) |
| 06:16:47 | | raptor Quit () |
| 06:16:55 | | Platskies__ is now known as Platskies |
| 06:42:31 | | Platskies__ has joined |
| 06:45:50 | | Platskies Quit (Ping timeout: 264 seconds) |
| 06:52:47 | | noneofmynickswor Quit (Quit: holy shit its 3am!) |
| 06:57:14 | | Platskies__ Quit (Read error: Connection reset by peer) |
| 06:59:26 | | Platskies has joined |
| 07:31:28 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 07:35:24 | | Flynnn has joined |
| 08:31:06 | | Darrel has joined |
| 08:54:57 | | watusimoto has joined |
| 08:54:57 | | ChanServ sets mode +o |
| 09:09:02 | | HylianSavior Quit (Read error: Connection reset by peer) |
| 09:10:52 | | Skybax Quit (Ping timeout: 244 seconds) |
| 09:54:49 | | Nothing_Much has joined |
| 10:09:58 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 11:58:29 | | Watusimoto_ has joined |
| 12:01:11 | | Invisible1 has joined |
| 12:26:45 | | Platskies Quit (Quit: Platskies) |
| 12:54:25 | | Invisible1 Quit (Ping timeout: 272 seconds) |
| 13:08:50 | | Invisible1 has joined |
| 13:12:05 | | Watusimoto_ Quit (Ping timeout: 248 seconds) |
| 13:40:04 | | Invisible1 Quit (Ping timeout: 264 seconds) |
| 13:40:28 | | Invisible1 has joined |
| 13:54:35 | | Invisible1 Quit (Ping timeout: 245 seconds) |
| 13:57:04 | | kaen has joined |
| 14:02:29 | | destroyerimo has joined |
| 14:19:33 | | kaen Quit (Ping timeout: 272 seconds) |
| 14:44:54 | | Invisible1 has joined |
| 14:46:30 | | kaen has joined |
| 15:00:35 | | destroyerimo Quit (Read error: Connection reset by peer) |
| 15:03:27 | | Watusimoto_ has joined |
| 15:04:58 | | destroyerimo has joined |
| 15:05:01 | | watusimoto1 has joined |
| 15:05:17 | | watusimoto Quit (Ping timeout: 252 seconds) |
| 15:05:35 | | watusimoto has joined |
| 15:05:45 | | ChanServ sets mode +o |
| 15:09:19 | | watusimoto1 Quit (Ping timeout: 252 seconds) |
| 15:26:18 | | watusimoto1 has joined |
| 15:26:18 | | watusimoto Quit (Read error: Connection reset by peer) |
| 15:34:53 | | destroyerimo Quit (Read error: Connection reset by peer) |
| 15:35:18 | | destroyerimo has joined |
| 15:48:05 | | watusimoto1 Quit (Quit: Leaving.) |
| 15:50:39 | | watusimoto has joined |
| 15:50:45 | | ChanServ sets mode +o |
| 15:55:26 | | kaen Quit (Remote host closed the connection) |
| 15:58:04 | | kaen has joined |
| 16:05:56 | | destroyerimo Quit (Read error: Connection reset by peer) |
| 16:06:46 | | destroyerimo has joined |
| 16:10:57 | | Invisible1 Quit (Ping timeout: 240 seconds) |
| 16:11:17 | | Watusimoto_ Quit (Ping timeout: 252 seconds) |
| 16:17:47 | | HylianSavior has joined |
| 16:27:26 | | raptor has joined |
| 16:27:27 | | ChanServ sets mode +o |
| 16:27:45 | raptor | good morning! |
| 16:29:38 | | destroyerimo Quit (Ping timeout: 240 seconds) |
| 16:31:20 | raptor | oooo all the devs are here, yay |
| 16:31:22 | raptor | ok |
| 16:31:24 | raptor | so |
| 16:32:07 | raptor | I made progress on the sandbox |
| 16:32:32 | raptor | the black list is working; however, there are 2 problems now: |
| 16:33:05 | raptor | 1. the STRICT rules do not work in the environment as they call blacklisted methods |
| 16:33:22 | raptor | 2. stacktracer fails because I blacklisted much of 'debug' |
| 16:49:54 | | kaen Quit (Ping timeout: 265 seconds) |
| 16:51:32 | | kaen has joined |
| 16:51:59 | kaen | STRICT doesn't break my heart ... but stack tracer is really important |
| 16:52:06 | raptor | hi kaen |
| 16:52:46 | raptor | the question is - do we still want to provide debugging utilities that'll allow breaking out of the sandbox? |
| 16:56:23 | | kaen Quit (Ping timeout: 252 seconds) |
| 17:02:22 | | kaen has joined |
| 17:08:16 | kaen | connection is still pretty spotty -- anyway I don't see how stack tracer lets you break the sandbox |
| 17:08:30 | raptor | it requires certain debug commands |
| 17:08:42 | raptor | which can allow environment switching |
| 17:09:28 | kaen | so I'm saying run it in a context where it has those commands, and do the sandboxing afterwards |
| 17:10:52 | raptor | the issue is that debug has commands that will allow it to break out of the environment |
| 17:11:05 | raptor | maybe i'm not understanding what you're saying |
| 17:11:50 | kaen | ok, I'm taking for granted that we trust stacktrace.lua |
| 17:12:36 | kaen | so when we require() or include() it etc., we let it run with access to the natural context |
| 17:13:14 | kaen | this might require storing local references to the debug functions it needs (local dbg_fn = debug.fn) |
| 17:13:47 | kaen | then we just put the value returned from include (_M in the script) into the new environment we're creating |
| 17:14:20 | kaen | _M is an opaque black box that will still have acess to its locals (via closure) but won't expose them in any way |
| 17:14:44 | kaen | and it will still be able to run in a sandboxed environment |
| 17:20:08 | raptor | wait wait - i think I can expose some of the safer debug commands and it'll work for stacktracer |
| 17:20:54 | raptor | ha! it worked! |
| 17:23:29 | raptor | kaen: do 'getinfo' and 'getlocal' seem harmless enough to allow?: http://www.lua.org/manual/5.1/manual.html#pdf-debug.getinfo |
| 17:23:48 | raptor | without special wrapping, etc.. |
| 17:25:19 | | kaen Quit (Ping timeout: 240 seconds) |
| 17:26:19 | | kaen has joined |
| 17:26:20 | | kaen Quit (Changing host) |
| 17:26:20 | | kaen has joined |
| 17:28:57 | raptor | ooo... this looks nice: https://github.com/kikito/sandbox.lua/blob/master/sandbox.lua |
| 17:29:54 | raptor | it even has loop protection |
| 17:34:23 | | LordDVG has joined |
| 17:36:58 | kaen | hmm getlocal is cutting it close, but it's safe as long as no function which calls user code also stores a blacklisted value as a local |
| 17:37:58 | raptor | stacktracer seems to work fully if I allow those 2 |
| 17:39:23 | raptor | FYI, here's my current sandbox, that I execute right when the environment is set up: http://pastie.org/pastes/8472425/text |
| 17:39:45 | raptor | notably, 'require' is not on that list |
| 17:40:03 | raptor | we already lock it down to jsut the 'scripts' directory |
| 17:40:43 | kaen | ah, beautiful |
| 17:41:23 | raptor | so if you think it's ok for those debug methods, then the last thing I need to do is some how remap the current environment to _G |
| 17:41:52 | raptor | I wonder if I should store this in a .lua file instead of the c++ |
| 17:43:30 | | kumul has joined |
| 17:43:34 | kaen | I don't see a reason for it to be in C |
| 17:43:53 | raptor | would it be ok to put in a sandbox.lua in the scripts dir? what are the risks? |
| 17:44:18 | | kumul Quit (Client Quit) |
| 17:44:27 | kaen | It sounds fine to me. User code can only require() it into a sandboxed environment |
| 17:44:39 | kaen | worst case scenario, you crash lua by trying it I think |
| 17:45:21 | raptor | ok, but deploying it as a text file makes it easy for the end-user to edit |
| 17:47:28 | raptor | but if a user wants to, i suppose that their prerogative to mess up their own environment |
| 17:48:10 | kaen | and on the flip side, it lets advanced users "fix up" their own environment :) |
| 17:49:21 | raptor | heh |
| 17:49:33 | raptor | seems reasonable, then |
| 17:49:35 | raptor | i'll do that.. |
| 17:57:35 | watusimoto | raptor: I have a pull request open on that package! |
| 17:57:36 | watusimoto | https://github.com/eykamp/sandbox.lua |
| 17:58:10 | raptor | hi watusimoto |
| 17:58:12 | raptor | huh?? |
| 17:58:36 | raptor | i don't see any changes you've made... |
| 17:58:46 | raptor | oh... h aha |
| 17:58:49 | raptor | a typo |
| 17:58:55 | watusimoto | I'm not sure how to display them |
| 17:58:59 | raptor | do you use that somewhere? |
| 17:59:02 | watusimoto | no |
| 18:00:24 | watusimoto | https://github.com/eykamp/sandbox.lua/compare/kikito:master...eykamp:patch-1?expand=1 |
| 18:00:38 | watusimoto | just like things to be "right" |
| 18:00:51 | raptor | heh |
| 18:01:04 | watusimoto | actually never saw it before you posted the link |
| 18:01:39 | watusimoto | but it looks good |
| 18:01:49 | watusimoto | anyway... heading out... back later |
| 18:02:04 | kaen | later! |
| 18:02:12 | raptor | haha |
| 18:02:14 | raptor | later |
| 18:12:51 | raptor | it sure is nice having no warnings when compiling... |
| 18:16:40 | | watusimoto Quit (Ping timeout: 245 seconds) |
| 18:18:27 | kaen | I still get a handful |
| 18:18:41 | kaen | at least on gcc 4.8.2 i386 |
| 18:19:14 | raptor | release or debug? |
| 18:19:31 | raptor | I've been ignoring the poly2tri/sqlite/recast ones |
| 18:20:38 | kaen | debug I believe |
| 18:21:26 | raptor | hmmm, i'm on 4.7.2 |
| 18:21:28 | raptor | for gcc |
| 18:21:50 | kaen | yep, debug |
| 18:22:03 | kaen | my ubuntu gcc gives no warnings, but the debian testing gcc does |
| 18:24:35 | kaen | wow, it even generates one inside of boost :/ |
| 18:24:54 | raptor | eek |
| 18:24:56 | kaen | and it's really, really long |
| 18:25:06 | kaen | BanList.cpp:12 |
| 18:25:09 | kaen | right at the include |
| 18:33:44 | raptor | we have the newest boost I though |
| 18:33:46 | raptor | *thought |
| 18:37:20 | | Watusimoto has joined |
| 18:43:57 | | Nothing_Much Quit (Remote host closed the connection) |
| 18:44:30 | raptor | I attempted to add read-only properties to some Lua modules |
| 18:44:36 | raptor | I figured it was a good idea |
| 18:44:58 | raptor | however, we add a table.clear() method in lua_helper_functions.lua that will trigger the protection |
| 18:45:24 | raptor | so I can either: 1. not have protection OR 2. add the table.clear() method in the cpp |
| 18:46:13 | | Nothing_Much has joined |
| 18:46:24 | raptor | hmm... or maybe this is a bug - I mean, why are the lua_helper_functions loading after the sandbox anyways |
| 18:46:43 | kaen | sounds like it |
| 18:48:44 | raptor | ah... each sub-class is reloading the script in its context (like console, plugin, etc.) |
| 18:57:49 | | Nothing_Much Quit (Remote host closed the connection) |
| 18:59:51 | | Nothing_Much has joined |
| 19:05:53 | | kumul has joined |
| 19:07:55 | Watusimoto | what does the ro propery do exactly? |
| 19:08:06 | raptor | ro ro ro your boat |
| 19:08:16 | Watusimoto | that's rho! |
| 19:08:21 | raptor | oh... read-only? |
| 19:08:31 | Watusimoto | oh.... yes |
| 19:08:39 | raptor | it just makes it so you cannot modify the table |
| 19:08:48 | raptor | like this: http://lua-users.org/wiki/ReadOnlyTables |
| 19:09:08 | Watusimoto | so the ro ro ro property prevents a script from modifying the modules? |
| 19:09:14 | raptor | yes |
| 19:09:29 | raptor | so you don't accidentally change 'string' to something else |
| 19:09:51 | Watusimoto | like string = print |
| 19:09:55 | raptor | yep |
| 19:10:10 | Watusimoto | can you modify modules by default? |
| 19:10:12 | raptor | but sadly, it also prevents adding to a table - like adding table.clear |
| 19:10:38 | Watusimoto | we can either apply the ro property after table.clear gets added, or, as you say, do it from c++ |
| 19:10:49 | raptor | i'm trying to apply it afterwards |
| 19:10:59 | raptor | i run my loadSandbox() after the prepareEnvironments |
| 19:11:08 | raptor | but it's still being triggered somehow |
| 19:11:58 | sam686 | ClientGame.cpp ClientGame::onGameUIActivated() has logprintf("Hi raptor!"); |
| 19:12:02 | Watusimoto | trying to apply the sandbox after the setup? |
| 19:12:31 | raptor | yes, I'm loading it in this: |
| 19:12:32 | raptor | bool LuaScriptRunner::runScript(bool cacheScript) |
| 19:12:34 | raptor | { |
| 19:12:35 | raptor | return prepareEnvironment() && loadSandbox() && loadScript(cacheScript) && runMain(); |
| 19:12:36 | Watusimoto | sam686: that was proof that a certain function was running on raptor's computer |
| 19:12:37 | raptor | } |
| 19:12:41 | Watusimoto | you can delete it |
| 19:12:55 | raptor | did you want to revert your attempts at fixing that bug |
| 19:12:57 | sam686 | ok |
| 19:12:57 | raptor | ? |
| 19:13:02 | Watusimoto | raptor: no |
| 19:13:14 | raptor | k |
| 19:13:22 | Watusimoto | so prepareEnv is where the table.clear gets run? |
| 19:13:27 | Watusimoto | gets set rather? |
| 19:13:36 | raptor | yes |
| 19:13:48 | raptor | so i'm looking for other weirdness... |
| 19:14:45 | raptor | ok - it only happens when i host twice in a row |
| 19:14:52 | raptor | first time it works OK |
| 19:15:05 | Watusimoto | could the sandbox be lingering somehow? |
| 19:15:36 | raptor | here is the method: http://pastie.org/pastes/8472665/text |
| 19:15:43 | raptor | it is definitely lingering |
| 19:16:38 | raptor | and here is my sandbox: http://pastie.org/pastes/8472669/text |
| 19:17:31 | Watusimoto | not using the sandbox I contributed to? :-) |
| 19:17:45 | | BFLogBot Commit: 71c1b37d839b | Author: kaen | Message: remove a few more warnings in TNL (and correct a disturbing lack of error checking) |
| 19:17:56 | Watusimoto | it seems to me that the sandbox will linger |
| 19:18:11 | Watusimoto | you nil out a function, why would it come back when you want to run a new script? |
| 19:18:36 | raptor | I thought I was setting it only in the context... |
| 19:18:43 | Watusimoto | maybe it is |
| 19:18:51 | raptor | hence the call to setEnvironment() |
| 19:18:53 | Watusimoto | but your evidence suggests otherwise |
| 19:18:58 | raptor | yep |
| 19:25:40 | Watusimoto | ok, time to make dinner.... back later |
| 19:26:33 | raptor | later |
| 19:37:30 | | BFLogBot Commit: ac98b9846de1 | Author: sam8641 | Message: Get rid of pending window events while toggling fullscreen, fixes giant window size |
| 19:39:39 | raptor | sam686: that last commit of yours may have a better fix which was just pushed to the SDL repo. See: https://code.google.com/p/bitfighter/issues/detail?id=252 |
| 19:40:00 | raptor | I was planning on working on that this week - either something is wrong with our logic or it was a bug in SDL (probably both) |
| 19:40:16 | sam686 | who cares... My fix is just adding one line of code. |
| 19:40:53 | raptor | i care because i'd rather it make sense than just patching it (and I've worked on this one a lot already) |
| 19:41:04 | raptor | but it's a nice one-liner :) |
| 19:42:34 | sam686 | SDL events can get delayed, its still better to just clear them when switching to/from fullscreen.. |
| 19:43:42 | raptor | ok |
| 19:43:46 | raptor | that seems fine |
| 19:45:10 | sam686 | Oh and.. I might have not givan me the newest SDL as well to see that.. |
| 19:45:32 | raptor | that's OK - I just got the e-mail yesterday from the mailing list |
| 19:46:07 | raptor | so I had just decided this morning to finally see if the event problems were fixed (still haven't gotten to it) |
| 19:50:39 | raptor | hmmm... I think caching is gettting in the way of sanboxxing |
| 20:05:51 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 20:25:40 | | LordDVG Quit (Remote host closed the connection) |
| 20:54:06 | | Skybax has joined |
| 21:09:54 | | Flynnn has joined |
| 21:12:45 | | Nothing_Much is now known as Nothing |
| 21:12:50 | | Nothing is now known as Nothing_Much |
| 21:17:58 | | Nothing_Much Quit (Remote host closed the connection) |
| 21:20:31 | | Watusimoto has joined |
| 21:40:37 | | Nothing_Much has joined |
| 21:46:33 | raptor | i think it's caching |
| 21:47:55 | raptor | becasue we do: prepareEnvironment -> loadSandbox -> loadScript -> runMain |
| 21:48:03 | raptor | and caching is in the loadScript |
| 21:48:18 | raptor | so everytime a script is run prepareEnvironment and loadSandbox is run, too |
| 21:48:26 | sam686 | not if you do /clearcache |
| 21:48:56 | raptor | i'm talking about why i'm having sandbox problems |
| 21:49:19 | sam686 | ok, you saying it only partially works? |
| 21:49:56 | raptor | no it works - it's just throwing errors because it's running too many times |
| 21:51:52 | | Invisible1 has joined |
| 21:58:23 | raptor | FYI, I'm runnign new code, nothing that's committed |
| 22:39:46 | raptor | Watusimoto: do we need to redo 'prepareEnvironment' if a script is cached? |
| 22:40:27 | Watusimoto | let's see.... where to we cache it? |
| 22:40:46 | raptor | flow is this: prepareEnvironment -> loadSandbox -> loadScript -> runMain |
| 22:40:50 | raptor | and we cache it in loadScript |
| 22:41:25 | Watusimoto | so we load the script, compile it, then cache the compiled product |
| 22:41:37 | raptor | yes |
| 22:41:54 | Watusimoto | that suggests that we do not cache the environment |
| 22:42:01 | Watusimoto | just a quick thought experiment: |
| 22:42:09 | | Flynnn Quit (Quit: This computer has gone to sleep) |
| 22:42:18 | Watusimoto | we prepare the environment by adding table.clear |
| 22:42:26 | Watusimoto | then load the sandbox |
| 22:42:29 | Watusimoto | then load the script |
| 22:42:39 | Watusimoto | then save the compiled script |
| 22:42:42 | Watusimoto | then time passes |
| 22:43:01 | Watusimoto | if we just load the compiled script, will table.clear() be defined? |
| 22:43:07 | Watusimoto | I don;t think so |
| 22:43:22 | Watusimoto | which suggests that we d need to prepare the ecnronment again |
| 22:43:42 | Watusimoto | so I think the answer is yes, unless I erred in one of my statements above |
| 22:52:09 | raptor | err'd |
| 22:52:17 | raptor | i think (sorry coworker stopped by) |
| 22:52:29 | raptor | >> if we just load the compiled script, will table.clear() be defined? |
| 22:53:20 | raptor | the answer is 'yes' |
| 22:53:32 | | Flynnn has joined |
| 22:53:37 | raptor | the issue is that the method runScript() is run *every* time |
| 22:53:48 | raptor | and that is the method that specifies prepareEnvironment -> loadSandbox -> loadScript -> runMain |
| 22:54:49 | raptor | so when we run a script again, it reloads the environment and tries to load table.clear() (from lua_helper_functions.lua) which will conflict with the sandbox already loaded in the environment |
| 23:04:14 | | Skybax Quit (Ping timeout: 244 seconds) |
| 23:06:55 | Watusimoto | if the answer is yes (which I don;t fully believe, but will accept for the moment; easy enough to prove later), then we probably don;t need to preprae or sandbox |
| 23:07:53 | raptor | ok wait |
| 23:08:11 | Watusimoto | so maybe runScript needs a flag or something to tell if L has already been prepared? |
| 23:08:24 | raptor | you're saying to *only* run the loadScript() piece? |
| 23:08:29 | Watusimoto | no |
| 23:08:31 | Watusimoto | yes |
| 23:08:32 | Watusimoto | wait |
| 23:08:34 | Watusimoto | yes |
| 23:08:38 | Watusimoto | that and runMain |
| 23:08:39 | raptor | that doesn't happen in our code - prepareEnvironment is called *every* time |
| 23:08:45 | Watusimoto | yes |
| 23:08:55 | Watusimoto | so obviously that will need to change :-) |
| 23:09:28 | raptor | hmmm..... so maybe a cache check first |
| 23:10:14 | | Invisible1 Quit (Ping timeout: 240 seconds) |
| 23:13:24 | raptor | maybe this would be a good time for me to learn the GTESTs |
| 23:19:07 | Watusimoto | yes! |
| 23:19:17 | Watusimoto | though this sounds like a complex test to start with |
| 23:19:56 | | Flynnn Quit (Quit: Leaving) |
| 23:20:29 | raptor | oh hey, they compile now! |
| 23:20:40 | raptor | so should I be worried that some tests are failing? like ones not having to do with Lua... |
| 23:22:40 | Watusimoto | not sure. there is a way to run only selected tests... a cmd line if that is an issue |
| 23:22:58 | Watusimoto | I gotta go... can help with tests tomorrow if you need it |
| 23:23:06 | raptor | hmmm |
| 23:23:08 | raptor | ok |
| 23:23:10 | raptor | night! |
| 23:23:19 | Watusimoto | start with a simple test and work up |
| 23:23:25 | raptor | kaen: is our test framework mature enough to handle lua stuff? |
| 23:24:15 | | BFLogBot Commit: 406968f32786 | Author: watusimoto | Message: Make spinner's size more appropriate |
| 23:24:16 | | BFLogBot Commit: ee5c41b17270 | Author: watusimoto | Message: Adjust spinner position more better |
| 23:24:18 | | BFLogBot Commit: 536fbc080ae3 | Author: watusimoto | Message: Don't allow quit during upload |
| 23:24:19 | | BFLogBot Commit: 994babfb7124 | Author: watusimoto | Message: Merge |
| 23:24:31 | raptor | mroe better! |
| 23:28:21 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 23:33:51 | Nothing_Much | I have a quick question, how do I set a prefix for make? |
| 23:34:04 | raptor | hi Nothing_Much |
| 23:34:09 | raptor | what do you consider a prefix? |
| 23:34:11 | Nothing_Much | Hello |
| 23:34:21 | Nothing_Much | Oh, uh |
| 23:34:28 | Nothing_Much | Lemme see, |
| 23:34:34 | Nothing_Much | Installation prefix |
| 23:34:40 | Nothing_Much | No wait |
| 23:34:52 | Nothing_Much | make *prefix=/usr* |
| 23:35:02 | raptor | are you working with bitfighter? |
| 23:35:16 | raptor | ohhhh |
| 23:35:24 | Nothing_Much | Oh, no, I got bitfighter to run, I'm trying to get 3D acceleration |
| 23:35:30 | Nothing_Much | on this computer |
| 23:35:38 | Nothing_Much | I thought make would have a universal way of setting a prefix |
| 23:35:39 | raptor | you can do this: make DESTDIR=/some/folder |
| 23:35:48 | Nothing_Much | Ah, thanks! |
| 23:36:24 | raptor | but that's just for isntalling after the fact - for a prefix for the code, that is usually handled internally somewhere, maybe in a Makefile or in the code itself |
| 23:36:35 | Nothing_Much | Ohh |
| 23:37:00 | Nothing_Much | Alright, well it didn't work, but I'll figure it out |
| 23:37:09 | raptor | if using autotools (e.g. with a ./configure script), then you add it with the ./configure script |
| 23:37:29 | raptor | ./configure --prefix=/usr |
| 23:37:46 | raptor | then the resultant Makefiles will have that in it |
| 23:42:26 | Nothing_Much | Thanks |
| 23:48:26 | | Skybax has joined |