| | <<<Back 1 day (to 2012/09/27) | 2012/09/28 |
| chrisl | Well, cia.vc is dead, so I've disabled the ciabot notification commit hook | 08:20.52 |
| | <sigh> the Windows build just freezes up when writing >4Gb tiff output :-( | 09:19.07 |
| tor8 | that's funny. I'm actually seeing virgn atlantic flights being served up with connecting flights! | 09:19.27 |
| kens | chrisl that's odd, is it us or libtiff ? | 09:22.51 |
| kens | wonders if something is going negative... | 09:23.43 |
| chrisl | Actually, I think the problem is related to the windows command line app I'm using - I'm going to try it in just cmd.exe. I think the error message dialogue is disappearing | 09:24.22 |
| kens | ah! | 09:24.33 |
| chrisl | In which case, it would probably be good to rejig the libtiff error reporting *even* more so it doesn't throw up an error dialogue at all! | 09:25.17 |
| | Yep, that's what it was :-( The libtiff integration really isn't complete...... | 09:28.00 |
| kens | Not ideal | 09:28.12 |
| | I think I've confused the cluster slightly, started a run, immediately aborted it and started another, now only some of the nodes are running tests. Not that its important | 09:29.24 |
| chrisl | It may be the dashboard that's lagging behind | 09:30.19 |
| kens | good point | 09:30.53 |
| chrisl | Okay, 4.6 Gb tiff file successfully created. Now for something bigger....... | 09:31.39 |
| kens | Good start though | 09:31.55 |
| chrisl | Bigger test is already at 7.3 Gb...... | 09:32.22 |
| Robin_Watts | kens: The cluster code checks for "pushed" jobs once a minute | 09:33.12 |
| | (and an abort is a pushed job) | 09:33.17 |
| chrisl | Okay, so 9.8 Gb output was successful - of course, I have *nothing* that can read it! | 09:33.25 |
| Robin_Watts | hence if you abort then rerun, you should leave 1 minute between aborting and rerunning. | 09:33.32 |
| kens | robin I probably did, because I changed the code and recompiled | 09:33.57 |
| Robin_Watts | And of course, the abort only goes out to the clients once then check in to get more jobs. | 09:33.57 |
| kens | In any event it looks like 4 nodes go toncfused, but its not important | 09:34.28 |
| chrisl | Hmm, I'm having trouble pulling from my repository on casper - the rebase goes awry trying to apply jbigdec patches to ghostpdl :-( | 10:34.13 |
| Robin_Watts | chrisl: My solution in such circumstances is to: git branch ass | 10:37.45 |
| | Then git reset --hard BLAH where BLAH is the place where your history forks from the main repo. | 10:38.11 |
| | Then you can git pull in with no problems (hopefully) | 10:38.22 |
| | Then you git cherry-pick individual commits over one at a time. | 10:38.41 |
| | And if all else fails you can: git reset --hard ass to get back where you started from. | 10:39.00 |
| chrisl | Hmmm, can I resolve it by getting a new copy of the central repos? So the two histories match exactly? | 10:40.33 |
| Robin_Watts | chrisl: If you do what I just described, after you have: git reset --hard BLAH then the SHAs will be the same. That's all you need. | 10:41.24 |
| | If the SHAs match, the history (at least for the commit you are on) matches exactly. | 10:41.48 |
| chrisl | I've done git reset --hard to the latest common commit, and it still goes wrong | 10:42.02 |
| | I haven'#t tried it on a branch, though | 10:42.21 |
| Robin_Watts | No, the point of the 'git branch ass' is that it makes a new branch called ass, that is set to whatever master was. | 10:42.44 |
| | You remain on master, but you have a placeholder so you can get back to where you were if you have problems. | 10:43.03 |
| | chrisl: What commit are you on, and what command are you trying? | 10:43.21 |
| | Let me try it here too. | 10:43.25 |
| chrisl | I'm trying to pull in the latest commit in my own repository, on top of a fully up to date local repos | 10:44.08 |
| Robin_Watts | Are you following my instructions above? | 10:44.47 |
| | If so, it must be a cherry-pick that's going wrong ? | 10:45.02 |
| chrisl | No, I'd already checked out a fresh copy of my own repos - it was the rebase that was failing | 10:45.51 |
| | I mean, before you'd replied, I decided to just clone anew from my repos on casper, rather than pull onto an existing repos | 10:46.41 |
| Robin_Watts | OK. so you've cloned *your* repo on casper. | 10:46.59 |
| | and now you're trying to pull --rebase from the golden repo ? | 10:47.16 |
| chrisl | No, originally, I had a fully up to clone of the golden repo, and then I did: git pull --rebase <my repo> master | 10:48.05 |
| | And the rebase from my repo failed | 10:48.21 |
| Robin_Watts | Well, there is nothing to rebas.e | 10:48.57 |
| chrisl | There is, my repo on casper is a commit ahead of the golden repo | 10:49.26 |
| Robin_Watts | If the head of the golden repo is A, the head of your repo is B, where B has 1 more commit after A. | 10:49.36 |
| chrisl | Yes, so it should be a trivial fast-forward merge, but it failed | 10:50.12 |
| Robin_Watts | So the golden repo can pull in B from your repo, but it's not a rebase. | 10:50.25 |
| | So it's not a rebase that's failing, it's a pull. | 10:50.44 |
| chrisl | It *is* a rebase, and it *is* the rebase that's failing | 10:51.15 |
| | All I'm doing is bringing my local clone up to date with a remote repository - it shouldn't matter whether it's the golden repo or my own | 10:52.27 |
| Robin_Watts | A rebase is where you take a 'forked' piece of development and move the base of that fork along a branch. | 10:53.44 |
| | If you're in the golden repo, you have no forked development to move. | 10:54.14 |
| chrisl | I have a fork which is in my own repos | 10:54.59 |
| Robin_Watts | git implements such things by rewinding (removing commits that existing within the repo you are working) to the point of the fork, then reapplying those commits one by one. | 10:55.37 |
| | If you are in a fresh clone of the golden repo and you pull in changes from another repo, then there are no commits to rebase within the existing repo. | 10:56.15 |
| | Hence your pull --rebase is actually a pull. | 10:56.34 |
| chrisl | Yes, so I don't know why it's faffing around with jbigdec commits | 10:57.03 |
| Robin_Watts | Me either. | 10:57.17 |
| | Does "git pull" give the same problems ? | 10:57.44 |
| chrisl | Hmmm, no, git pull succeeds. | 10:58.39 |
| Robin_Watts | Are we using git submodules? | 10:58.47 |
| chrisl | No | 10:58.53 |
| Robin_Watts | ok. | 10:58.56 |
| chrisl | I'm confused, in a case like this, I thought merge and rebase would do exactly the same "fast forward" action doing the update | 10:59.34 |
| Robin_Watts | I would have thought so too. | 10:59.52 |
| chrisl | I have just checked (again) and HEAD~1 SHA on my repo == HEAD SHA in the golden repo | 11:00.48 |
| Robin_Watts | Does git diff HEAD~1 show anything strange ? | 11:01.14 |
| paulgardiner | You can always try fetch rather than pull. Then look at the tree with gitk and decide how to merge or whatever is needed. I always fetch rather than pull | 11:01.44 |
| chrisl | I'm seeing anything weird in the diff. | 11:02.40 |
| | there should be a "not" in there.... | 11:03.08 |
| Robin_Watts | chrisl: Can you git reset --hard HEAD~1 to go back to the state you were in before the merge, then git pull --rebase and paste what git says into a pastebin please? | 11:03.56 |
| | What version of git ? | 11:04.50 |
| chrisl | 1.7.9 | 11:05.31 |
| Robin_Watts | Newer than my 1.7.7.msysgit.1 then. | 11:06.21 |
| | git pull --rebase chris master works for me - but I do have a commit in there that needed rebasing. | 11:06.39 |
| chrisl | Er, it's just worked witout an error - so now I'm *really* confused :-( | 11:07.13 |
| Robin_Watts | Turn it off and on again. | 11:08.31 |
| chrisl | I guess so - weird...... | 11:08.51 |
| | On that note, I think I'll feed the cat - I *know* I can do that! | 11:11.04 |
| ubitux | hi | 13:55.52 |
| ghostbot | moin moin | 13:55.52 |
| ubitux | i'm trying to build mupdf, but i have some issues with openjpeg; what's the version requierements? | 13:56.56 |
| | to be more specific: http://pastie.org/4855806 | 13:57.20 |
| Robin_Watts | ubitux: You need version 1.5 at least. | 13:59.35 |
| | and really you should use the version we supply, as it's a patched version with bugs fixed. | 13:59.52 |
| | Are you building from git or from a .zip ? | 14:00.03 |
| ubitux | from the git | 14:00.42 |
| Robin_Watts | Then, all the prerequesites are supplied as git submodules. | 14:01.05 |
| ubitux | oh? great | 14:01.11 |
| Robin_Watts | Do: git submodule update --init | 14:01.15 |
| | and that will bring everything you need into the thirdparty directory. | 14:01.32 |
| ubitux | maybe it should be mentioned below the git download url on the mainpage | 14:01.46 |
| | instead of giving the dep | 14:01.51 |
| Robin_Watts | Possibly. It's very new :) | 14:01.58 |
| ubitux | is it the correct place to ask for development hints? | 14:02.56 |
| Robin_Watts | it is. | 14:03.06 |
| ubitux | right ok, assuming i would like to create some kind of filter before rendering, where should i look for? | 14:03.35 |
| Robin_Watts | What do you mean? | 14:03.50 |
| ubitux | (oh great the Makefile automatically handles the libraries) | 14:04.12 |
| | i mean i want to apply an image filtering on each page | 14:04.40 |
| Robin_Watts | indeed. | 14:04.42 |
| | What sort of image filtering? | 14:04.59 |
| ubitux | in my case i'd like to invert the colors | 14:05.40 |
| | but does it matter? | 14:05.49 |
| | (similar to ctrl+i in evince) | 14:06.04 |
| Robin_Watts | Well, I'm trying to understand where best to do such things. | 14:06.09 |
| | or 'i' in mupdf :) | 14:06.14 |
| ubitux | ! | 14:06.22 |
| | it wasn't in the help! :D | 14:06.28 |
| | thanks :)) | 14:06.41 |
| Robin_Watts | np. | 14:07.12 |
| ubitux | ah it isn't in the debian version, of course. | 14:07.14 |
| Robin_Watts | That happens *after* rendering. | 14:07.19 |
| | We render, then invert the bitmap. | 14:07.29 |
| ubitux | ok | 14:07.39 |
| | fun | 14:07.42 |
| | btw, any reason the scroll position is memorized? | 14:07.58 |
| | for instance, if i scroll down a page, and go to the next page | 14:08.10 |
| | it will focus on the bottom of the next page | 14:08.25 |
| Robin_Watts | Sorry, that's one for tor8. | 14:08.35 |
| ubitux | it's not that much a problem but i was curious | 14:09.03 |
| | '?' doesn't print anymore the help.. too bad | 14:09.37 |
| | ok so last question | 14:09.42 |
| | is there a way to print the ToC? | 14:09.47 |
| tor8 | ubitux: I think the different key bindings for paging have different scrolling behaviour | 14:10.19 |
| | one remembers the offset, the other doesn't | 14:10.28 |
| Robin_Watts | In the android and iOS viewers, there is an outline view that might be what you want. | 14:10.32 |
| | The current windows/linux viewers do not have that facility. | 14:10.47 |
| ubitux | :( | 14:11.34 |
| | okay | 14:11.44 |
| | ah, and we can't copy/paste anything, right? | 14:11.58 |
| | (well, just copy) | 14:12.07 |
| | tor8: arrows and j/k scrolling seems to be kept between page switches | 14:12.55 |
| Robin_Watts | ubitux: You can copy/paste from mupdf, yes. | 14:14.42 |
| ubitux | can't figure out how | 14:19.05 |
| Robin_Watts | right hand drag box or something | 14:19.34 |
| ubitux | oh. | 14:20.13 |
| | hey it's awesome. | 14:20.48 |
| Robin_Watts | tor8,sebras: OK, I rejigged the shade handling to subdivide at render time. | 14:21.42 |
| | 33 Meg instead of 750 :) | 14:23.29 |
| tor8 | Robin_Watts: neat! | 14:34.50 |
| Robin_Watts | Who originally coded this stuff? sebras? | 15:01.52 |
| | Oh, I see what I've broken. | 15:04.38 |
| sebras | Robin_Watts: no, jeong-hee. but I amended it significantly to make it understandable and handle high number shadings correctly. | 15:08.40 |
| tor8 | Robin_Watts: originally, jeong-hee. then sebras cleaned it up a bit. | 15:08.42 |
| sebras | Robin_Watts: why? | 15:08.44 |
| | tor8: your definition of "a bit" is interesting. ;) | 15:09.00 |
| tor8 | I like understatements :) | 15:09.17 |
| Robin_Watts | sebras: I thought I spotted something that was broken, but actually, I'd broken it while refactoring. | 15:09.19 |
| sebras | Robin_Watts: ah. ok. | 15:09.59 |
| | Robin_Watts: there's a 2.7.1colorspace-devicen.pdf or something similar that is a really good testcase. | 15:10.29 |
| | I think that is part of the ghent och kensington testsuites. | 15:11.03 |
| Robin_Watts | I just clusterpushed it and got 87 diffs, which is a really good number when you consider that the transformation now happens in a different place. | 15:11.52 |
| sebras | right, the thing is that the file I'm referring to has all types of shadings. | 15:12.44 |
| | which explains why it's a good test case. | 15:12.52 |
| Robin_Watts | sebras: Right. I'll definitely look for that then, thanks. | 15:13.06 |
| sebras | I think it might be part of tor8's sane suite, but I'm not sure. | 15:13.08 |
| Robin_Watts | Hmm. I've just spotted 'Free PDF Support' on Google Play. | 15:35.13 |
| | It's mupdf packaged into a separate app. | 15:35.23 |
| | The idea being that apps can call it programatically to render pdfs. | 15:35.38 |
| | I suspect that it would be against the GPL for any app to call it. | 15:35.54 |
| | Or rather, non non GPL app should be able to use it. | 15:36.08 |
| | s/non non/no non/ | 15:36.51 |
| sebras | s,s/non non/no non/,s/non non /no non-/, | 15:39.34 |
| | is 'Free PDF Support GPLv3'? | 15:39.57 |
| Robin_Watts | https://github.com/adk/FreePdfParser | 15:41.21 |
| | I see no license there at all. | 15:41.28 |
| | Which means it can't be as the GNU GPL requires a license to be included, right? | 15:41.42 |
| | Ah. On the google play description it says it's GNU GPL licensed. | 15:42.33 |
| sebras | Robin_Watts: http://newfrontiernomads.com looks like there might be a company behind it..? | 15:42.39 |
| Robin_Watts | Yeah. | 15:42.43 |
| | So, any app that uses FreePdfParser must itself be GNU GPL licensed. | 15:43.10 |
| | That's going to be a git to police. | 15:43.25 |
| | I suspect we should ask him to add to his description to say something like: "Under the terms of this license, any app that makes use of this must itself be GNU GPL v3 licensed". | 15:44.40 |
| sebras | Robin_Watts: btw, in that git... where is the source for libmupdf.so? | 15:44.52 |
| Robin_Watts | sebras: I bet it isn't there. | 15:45.21 |
| sebras | I can't find it. | 15:45.35 |
| | I cloned it just now, and no -- it's not there. | 15:46.23 |
| Robin_Watts | I might drop the author a line. | 15:46.41 |
| sebras | to the best of my knowledge that would pose a problem. | 15:46.44 |
| | Robin_Watts: oh.. it might be the guy that developed the Canalbalt game present in one of the humble bundles... | 15:47.52 |
| | or the author just forked the canalbart game.. I'm not sure I understand githubs webinterface. :-/ | 15:50.15 |
| Robin_Watts | yeah, he forked it. | 15:51.13 |
| | Looks like ericjohnson is the original author. | 15:51.39 |
| sebras | ah, yes. you're right. | 15:51.51 |
| | at least the FreePdfParser repo has not been forked at github. | 15:55.33 |
| Robin_Watts | tor8, sebras, henrys, anyone else: http://pastebin.com/an45ixhG | 16:01.05 |
| | That's the email I have in mind. | 16:01.11 |
| kens | First parafraph I'd say 'developers of' rather than developers on | 16:02.32 |
| | para 4 mislead should be misled | 16:03.07 |
| sebras | Robin_Watts: lgtm, but apparently I missed the typos. | 16:04.14 |
| kens | apart from that, it looks fine to me, maybe send it to Miles ? | 16:07.44 |
| Robin_Watts | kens: I was thinking that I'd send my 'friendly' email first, and then we'd have the option of Miles sending a nuclear one later :) | 16:08.51 |
| kens | Fair enough, up to you | 16:12.06 |
| henrys | Sounds fine maybe Scott can use some of your words in future interactions, I don't think he ever brings out the GPL 3 of course we don't use the GPL 3 but GPL (Miles' interpretatition version 1). I do think we should generally stay out of this though and let Scott and Miles deal with it. | 16:15.59 |
| Robin_Watts | henrys: Really? | 16:16.26 |
| | I thought we were very specifically GPL v3. | 16:16.33 |
| sebras | Robin_Watts: that's what the mupdf source says. | 16:16.51 |
| henrys | it was sort of a joke but Miles does have his "interpretation" of the GPL ... | 16:17.44 |
| Robin_Watts | henrys: yeah, I'm aware of that. But the 'base' version of the GPL that Miles can interpret all he likes is v3. | 16:18.13 |
| | I was thinking that a nice quiet word from me, might achieve stuff that a huge scary letter from Scott/Miles wouldn't. | 16:18.46 |
| | And it leaves open the option of Miles/Scott going in later. | 16:20.08 |
| henrys | Robin_Watts:the initial letters never struck me that way, if they do sound threatening we should make suggestions about fixing them, but your letter if fine by me. Scott or Miles may feel you are getting into their world so to speak though. I don't know. | 16:20.35 |
| Robin_Watts | I'll send a mail to Miles/Scott with my suggested email and see what they say. | 16:21.04 |
| | sebras, tor8: shading changes pushed to my repo. | 17:13.12 |
| | marcosw: My last cluster run (a mupdf one) produced 86 diffs. I've just bmpcmped and had no differences found. Trying it again now, but do you know of anything that might have changed in this area? | 17:19.17 |
| marcosw | Robin_Watts: not off hand, I can look at the logs and try to figure out why. | 17:19.43 |
| Robin_Watts | It looks to correctly be sending 86 jobs out. | 17:20.05 |
| | This time it worked. How odd. | 17:28.28 |
| | Sorry. | 17:28.30 |
| sebras | Robin_Watts: regarding the constants -- I guess we could just subdivide until we realize that the patch/triangle/whatever is sufficiently small. | 17:29.55 |
| marcosw | I was about to suggest it was an issue with the third party libraries, that the ones in your directory are being used for the clusterpush but the ones in the repository are being used for the bmpcmp jobs. Though that doesn't seem likely, particularly in lieu of the information that it worked the second time you trie dit. | 17:29.55 |
| sebras | Robin_Watts: the trouble is detecting at what point this happens. | 17:30.07 |
| Robin_Watts | sebras: Yeah. | 17:30.45 |
| sebras | Robin_Watts: when we were loading the code we couldn't know how big a patch would be when rendered, but since you moved this to the rendering part of mupdf then I guess we could make use of the ctm to detect this somewhow? | 17:30.52 |
| Robin_Watts | It's more feasible too do that now, as ... exactly. | 17:31.00 |
| sebras | so when it is less than a pixel in the output image then there is not point in subdividing any further... | 17:31.21 |
| Robin_Watts | The code is no worse now than before, but it's a possible future enhancement. | 17:31.26 |
| sebras | yeah. | 17:31.38 |
| | I just noticed that you added a few fixme's. | 17:31.49 |
| Robin_Watts | sebras: We can also say "when the color doesn't differ by much, don't subdivide further". | 17:31.52 |
| | yeah, otherwise I'll forget. I may have mentioned my poor memory before. | 17:32.18 |
| sebras | Robin_Watts: actually that might be a better threshold. | 17:33.01 |
| | btw, doesn't this also mean that we can decide to only render the parts of the shading that are within a certain bbox? | 17:34.56 |
| Robin_Watts | sebras: Yes, theoretically. | 17:35.13 |
| sebras | as another further enhancement of course. | 17:35.13 |
| Robin_Watts | Miles says to send my email. | 17:39.11 |
| henrys | I'm sorry he want me to send your email? | 17:48.04 |
| sebras | Robin_Watts: there are some default assumptions when erroneous values are encountered in pdf_load_mesh_params() that we ought to warn about I think. | 17:49.50 |
| Robin_Watts | henrys: Sorry, no. He wanted me to send the email, so I have. | 17:50.28 |
| | I mention it here, because he didn't copy his reply to tech. | 17:50.39 |
| henrys | yes he seems to struggle with reply-all or just doesn't like to use it I don't know which. | 17:52.14 |
| Robin_Watts | I mess that up enough myself that I daren't take a position on it :) | 17:52.42 |
| sebras | Robin_Watts: ideally we would want a pdf_read_complete_stream() in pdf/pdf_stream.c that calls pdf_guess_filter_length() so you don't have to pass 1024 to fz_read_all(). something similar to pdf_load_image_stream(). | 17:54.48 |
| Robin_Watts | sebras: Yes. | 17:55.06 |
| | Ideally I want a 'pdf_read_compressed_stream_as_buffer_that_I_can_reopen' :) | 17:55.32 |
| sebras | mmm. | 17:55.53 |
| Robin_Watts | something that returns an fz_buffer_compressed or something. I need to work on my naming :) | 17:56.01 |
| | I already have something a bit akin to that with the pdf_image stuff, I wonder if it can be refactored. | 17:56.36 |
| | but the bmpcmp shows that I have some shadings not showing up. Got to fix them first. | 17:56.56 |
| sebras | yes indeed, do not dare to make all my hours last year in vain! :) | 17:57.47 |
| Robin_Watts | The code seemed very readable before I started playing with it. | 17:58.17 |
| | I hope I haven't lost that :) | 17:58.24 |
| sebras | cool, I'm happy you feel that way. I tried to make it readable. the reason that shading were lagging behing somewhat before was due to the code not being readable at all which is why I put some effort into it. | 17:59.13 |
| | though now that you have separate the parsing from the rendering I spot omissions that could be handled better. there's a high probability I'll dive in with some patches this weekend. | 17:59.53 |
| Robin_Watts | sebras: Well, bear in mind that I might not get it fixed this evening :) | 18:04.46 |
| sebras | Robin_Watts: no problem. then I might try to fix this on a branch of my own. | 18:05.14 |
| sebras | wanders away towards the cinema. | 18:05.33 |
| Robin_Watts | have fun. | 18:06.39 |
| | sebras, tor8: OK. I've just pushed a version of the shading commit to my repo that tests out OK (68 diffs, all look OK on my bmpcmp). | 19:50.59 |
| | Let me know when/if you're happy with it, and I'll push it to golden. | 19:51.14 |
| mvrhel | brb | 20:18.14 |
| | henrys: you there? | 21:11.06 |
| henrys | I am | 21:13.42 |
| mvrhel | So I am obviously going to be working for the next couple of weeks on getting all the bells and whistles in for the customer. It would be ideal if I can just get them to take the current head and start working from that | 21:15.51 |
| | These should not take too long to get in place. I am revamping things a bit to make it easier to add in new stuff that they may want | 21:16.26 |
| henrys | so you can point them to the "snapshot" on the git page right? | 21:17.42 |
| mvrhel | Hopefully things have not diverged too far from them. I never got the feeling that they had done much effort to get things working. Only the past month did I get an email that their device was working with 9.06 | 21:17.45 |
| | henrys: yes | 21:17.49 |
| | plus since 9.06 we have fixed a few more issues with spot color handling with transparency and shading that they would want | 21:18.34 |
| | as much as we complain about gemma, they do do a lot of stress testing of the sep devices | 21:19.14 |
| | which is going to help everyone | 21:19.23 |
| henrys | yea I really agree with Marcos' summary of the customer. I just wish they paid us more. | 21:20.25 |
| | I imagine your customer will get more responsive seeing the exchange with miles. | 21:21.10 |
| mvrhel | I hope so. I feel a bit bad after reading his response. I am going to push to try to get this stuff wrapped up by the end of next week. | 21:21.33 |
| henrys | mvrhel:did you get a chance to look at the gray mapping I pointed you at, looks like somebody else has commented on the bug? | 21:22.48 |
| mvrhel | henrys: I did not review that yet. I will make sure to do so today/tonight | 21:23.17 |
| | birthday party here this afternoon / evening with 9 boys all play x-box | 21:23.39 |
| | in about 1 hour..... | 21:23.51 |
| | I have dual x-box consoles set up and ready to go. minecraft fest | 21:24.23 |
| henrys | oh sounds like fun. | 21:24.36 |
| | my son was xbox crazy and now he's all about PC gaming I think the consoles are not keeping up with desktop horsepower. | 21:34.00 |
| mvrhel | I believe that. The 360 is quite a few years old | 21:34.20 |
| | Not sure when the 720 is coming out. Maybe next year | 21:34.42 |
| | We have a friend here who works on the firmware on the devices and he wont tell.... | 21:34.59 |
| | I am sure there will be 3D support | 21:35.35 |
| henrys | well have fun! and happy friday, bbiab | 21:36.58 |
| mvrhel | thanks ttyl | 21:37.05 |
| | Forward 1 day (to 2012/09/29)>>> | |
IRC Logs