[17:52:03] <dbrewer> Hi Derick. I'm given to understand that you are the man to ask Xdebug questions. I have a test case which is failing silently part way through the test (it behaves as if I had called exit() in the middle of the test). I activated Xdebug to get a deeper look into the situation... and lo and behold the test now merrily runs all the way through. My question: do you have any ideas about what circumstances might cause simply activating Xdebug to fix
[17:53:04] <philip__> the beauty of php is its rtfs and oral traditions... who needs README files? :)
[17:54:31] <Rasmus> dbrewer: is it crashing?
[17:54:41] <Rasmus> running it under gdb might give you a clue
[17:56:13] <dbrewer> That... is a really good idea.
[17:56:22] ← robinf left IRC. (Quit: Calm a llama deep down in the ocean blue.)
[17:57:04] <Rasmus> Adding xdebug to the mix could change the memory footprint enough to avoid the crash
[17:57:27] <madbomber> Rasmus always seems to be full of good ideas. That's why he gets the big bucks :D
[17:57:31] <dbrewer> Hehe
[17:57:39] <Rasmus> yeah right
[17:57:50] <Rasmus> Chances are pretty good it isn't a crash
[17:57:59] <dbrewer> I should say that this is related to the Doctrine ORM, which used to have all kinds of crashing issues under PHP < 5.2.3
[17:58:25] <dbrewer> But it's been much better since then.
[17:59:24] ← lstrojny left IRC. (Read error: Operation timed out)
[18:01:02] <Rasmus> Yikes, just had a look at it. Thousands of lines of PHP code
[18:01:36] <dbrewer> Yes, I think it might be considered an 'edge case' for PHP. :-)
[18:01:38] <lsmith> Rasmus: indeed .. needs to be split up .. but its aint so bad .. it can cache the generated SQL and of course the result sets as well
[18:02:09] → auroraeos joined the channel.
[18:02:15] <Rasmus> Looks nasty to me
[18:02:16] <lsmith> but it can be a real timesaver when your clients decides mid way into the project he does not want stuff to ever be deleted .. instead everything should just have an "is_deleted" flag instead
[18:02:29] <lsmith> but its definately not for yahoo.com
[18:02:39] <Rasmus> The base class has a gazillion constants
[18:02:58] <Rasmus> and conditional includes everywhere
[18:03:01] <lsmith> yeah .. thats one of the things that needs to be refactored .. the code is currently a bit too monolithic
[18:03:16] <Rasmus> if (isset($loadedModels[$className]) && file_exists($loadedModels[$className])) {^M
[18:03:16] <Rasmus> require_once $loadedModels[$className];^M
[18:03:24] <madbomber> i wish i knew what i do now, when i started my site
[18:03:27] <Rasmus> that kind of stuff is absolute death for any sort of caching
[18:03:30] <madbomber> the could would be so much better. lol
[18:03:37] <madbomber> err the code would
[18:04:26] <Rasmus> I still don't really buy this yahoo.com vs. everyone else argument
[18:04:34] <Rasmus> We actually run pretty small servers
[18:04:45] <Rasmus> Generally no more than 32 MaxClients on each
[18:05:03] <Rasmus> Latency is everything whether you have a 1-server site or a 3000-server site
[18:05:26] <lsmith> Rasmus: well i do not know if yahoo is willing to throw more developers at tasks, in order to keep the code leaner
[18:05:39] <lsmith> however one thing might be true .. intranet apps tend to have very complex business logic
[18:05:56] <lsmith> and for these i think an ORM lends itself much better
[18:06:01] <lsmith> than handcrafted SQL
[18:06:14] <lsmith> (with the fallback to SQL where ever there is a big bottleneck)
[18:06:41] • lsmith wonders if you guys are using Propel in the yahoo symfony projects
[18:06:59] <Rasmus> Symfony isn't used for anything interesting
[18:07:13] ← helly25 left IRC. (Read error: Operation timed out)
[18:07:13] • helly__ is now known as helly25.
[18:07:20] <Rasmus> A couple of 3rd tier properties are playing with it
[18:07:26] <lsmith> right
[18:09:22] <lsmith> i am not sure how much effort it is to always structure your includes in such a way to get rid of any conditonal includes .. never really tried to get there
[18:09:35] <lsmith> i presume one would have to really prune out all unused files from libs
[18:09:35] <Rasmus> There still has to be a way to write this stuff without those sorts of doubly-conditional includes
[18:09:49] <Rasmus> triple-conditional actually
[18:09:50] <lsmith> and then just include everthing?
[18:10:06] <Rasmus> With an opcode cache, they will all be in memory anyway
[18:10:12] <lsmith> right
[18:10:13] <Rasmus> you don't save anything by not including a file
[18:10:24] <ScottMac> a stat call?
[18:10:26] <lsmith> doctrine has a method to compile everything into one file
[18:10:34] <lsmith> IIRC
[18:10:34] <Rasmus> apc.stat=0
[18:10:37] <Rasmus> and then even that is gone
[18:10:47] <ScottMac> even with relative directories?
[18:11:00] <Rasmus> no, you'd need to use full paths for apc.stat=0
[18:11:07] <madbomber> hey Rasmus, i've been meaning to ask you.... do you guys run stat=0, and then use the built in apc routines to refresh code when it changes? or just restart the whole server?
[18:11:15] <Rasmus> but that stat will be quick on a modern kernel
[18:11:20] <lsmith> Rasmus: yeah .. so about absolute files ..
[18:11:30] <Rasmus> and you gain cached classes if you make everything top level
[18:11:46] <lsmith> thats kinda annoying to maintain inside libs .. unless they use autoload .. which is again not nice to byte code caches
[18:11:46] <madbomber> i'm super scared about spitting out php code if apc/php breaks by refreshing individual files inside apc... and i've just been restarting the whole server
[18:11:47] <Rasmus> that doctrine base class, for example, with its 5000 constants wouldn't need to be created on each request
[18:12:19] <Rasmus> right, I don't generally suggest using apc.stat=0
[18:12:35] <Rasmus> take the slight stat hit for convenience, but reduce your dep tree to a single level
[18:12:40] ← jmessa left IRC. (Quit: ChatZilla 0.9.81 [Firefox 2.0.0.12/2008020121])
[18:12:41] <lsmith> Rasmus: is it ok if i log this discussion?
[18:12:43] <Rasmus> and make all includes top-level unconditonal
[18:13:00] <Rasmus> I suppose
[18:13:24] <Rasmus> madbomber: search and frontpage run apc.stat=0 because they need massive speed
[18:13:40] <Rasmus> and they will restart the server on a code push
[18:13:53] <lsmith> madbomber: big sites also prime their caches
[18:13:58] <Rasmus> for frontpage there are some files that change between code pushes and these are simply not cached
[18:15:12] <madbomber> ya..... i ghetto-prime ours. i wouldnt call my site big, but it's very busy. across the 40 web servers they do around 225 php pages per second at peak
[18:15:19] <lsmith> Rasmus: which version of Doctrine were you looking at btw?
[18:15:31] <Rasmus> the nightly tarball
[18:15:50] <Rasmus> oh wait, actually it is 0.10.2
[18:16:09] <madbomber> my rollout is basically: iptables port 80 so the load balancer stops sending traffic, shutdown apache, rsync the entire code base, bring up apache, sleep 2 seconds, wget the top 100 request scripts to their in the apc cache, disable the iptables on port 80
[18:16:15] <lsmith> ok .. thats current (though they are already working on 2.0 in trunk)
[18:16:20] <madbomber> super ghetto... but it seems to work. the problem now is that takes a long time
[18:16:24] <madbomber> cause it's all serial
[18:16:33] <Rasmus> they could at least get rid of the require_once inside that class_exists check
[18:16:39] <Rasmus> seems like a double-check there
[18:17:06] <madbomber> also, if i just modify a single php file, or include... doing that across the entire tier at peak generally 'sucks'
[18:17:21] <lsmith> yeah .. well that autoload is not mandated .. but i guess enough users will end up using it .. people that care about speed will usually use that compile tool
[18:17:46] <madbomber> i was tempted to modify my rollout script to take file names as arguements, then just run a local php script on each web server that did the internal apc() recache calls on them
[18:18:06] <madbomber> but as i said before, that makes me a wee bit nervous
[18:18:17] <ScottMac> madbomber, we use apc_compile_file