| | <<<Back 1 day (to 2014/07/03) | 2014/07/04 |
| kens | chrisl ping | 07:47.34 |
| chrisl | kens: pong | 07:49.45 |
| kens | You still have a PowerPC platform there ? | 07:49.58 |
| chrisl | Yes, I do | 07:50.06 |
| | running linux | 07:50.21 |
| kens | Looking at bug #695350, could you compile and try that ? Its GhostPCL | 07:50.36 |
| | I know its not AIX< but at least its the same endian-ness | 07:50.51 |
| chrisl | Okay, it'll take a while, I'll need to build it | 07:52.05 |
| kens | Yeah I figured that, but I'm stumped otherwise, the file works just fine for me | 07:52.30 |
| | If we don't have a way to reproduce it I'll have to close it as worksforme (not going to try running an IBM loaner for a free user) | 07:53.17 |
| chrisl | I guess I'll get the 9.14 release, too..... | 07:54.15 |
| kens | It would be best, yes please | 07:54.27 |
| | Not that I think its an endian-ness problem, but its all I can think of | 07:54.43 |
| chrisl | Well, unless I'm misunderstanding what he's saying, the configure command doesn't make sense - if he's cross-compiling, that ain't gonna work! | 07:55.50 |
| kens | There's a example faulty PDF attached to the bug, so I guess he got 'something' to work. | 07:56.22 |
| | And it definitely is 9.14, because (fortunately) the Creator is set in the PDF file. | 07:56.45 |
| | According to IBM the system 520 has been obselete (withdrawn from sale) for 6 years.... | 07:57.24 |
| | Thought that might be just the i520, not sure if there are other ones | 07:57.49 |
| | oh and its using teh IBM 'i' operating system...... | 07:58.48 |
| | Oh my word, PASE seems to be some sort of migration product that takes AIX compiled code and makes it work on i | 08:01.32 |
| | The more I look at this report the more I think 'good luck chum, let us know how you get on' | 08:04.22 |
| Robin_Watts | kens: From my brief read it sounded like a pcl problem, not a pdfwrite one. | 08:05.40 |
| kens | Robin_Watts : can't tell at the moment, I don't think he's tried running to as bitmap (I have suggested it) | 08:06.02 |
| | If the bitmap is the same, then its a PCL problem, otherwise its pdfwrite | 08:06.21 |
| | But even if it is PCL, that just shifts the problem to henry, who is no better placed to investigate a problem on an IBM server, running 'i' and using a migration tool on a binary built for AIX..... | 08:07.29 |
| chrisl | I could look at getting an IBM loaner - but it will be next week...... | 08:07.43 |
| kens | chrisl, free user, IMO we don't do that | 08:07.58 |
| | If he wants to debug it, I'll certainly be available to answer questions, and more than willing to take on whatever he fionds out. But the platform is (highly) unsupported by us. | 08:09.14 |
| chrisl | It was my hope that testing on a "real" AIX 6 machine would illustrate that the problem isn't ours! | 08:10.17 |
| kens | Possibly...... But its more effort than I feel inclined to go to myself | 08:10.35 |
| | Perhaps I'm just bheing lazy | 08:10.54 |
| chrisl | What's with these people bouncing on and off IRC this morning??? | 08:11.34 |
| kens | feels we have enough to do for paying customers without chasing weird operating systems for free users | 08:11.38 |
| | chrisl I can tell Miranda to ignore those, can't you do that with your client ? | 08:12.02 |
| chrisl | Probably. But I kind of like to see when people really join and really leave - I guess I could filter on "Ping timeout" | 08:12.57 |
| kens | That would probably work | 08:13.08 |
| chrisl | Hmm, on ppc I get a broken PDF...... | 08:24.16 |
| kens | Well I guess that's progress of a sort. WHat do you get if you render it ? | 08:24.38 |
| | I guess the other question is how is it broken ? Can you send me the PDF ? | 08:24.54 |
| chrisl | No text at all, and we emit "**** Error reading a content stream. The page may be incomplete" and evince says "Syntax Warning: matrix not invertible" | 08:25.38 |
| kens | Well it all sounds bad | 08:25.49 |
| chrisl | ain't good ;-) | 08:26.02 |
| kens | So the user should be happy it just mispositions the text :-) | 08:26.16 |
| chrisl | Broken pdf on its way | 08:26.54 |
| kens | I am surprised mind you, I didn't think there was anything specific to endian-ness in there any more | 08:26.55 |
| | OK thanks | 08:26.59 |
| | Acrobat doesn't complain :-) | 08:27.43 |
| | Looks like a matrix problem, judging by the errors in GS | 08:29.38 |
| | Weird, the inital matrix at the head of the stream is 0 0 0 0 0 0 | 08:32.23 |
| | So it look slike the HWresolution is 0 | 08:32.37 |
| | There are som other oddities too. 100.8 is coming out as 00.8 | 08:33.26 |
| | THis sort of looks like some strangeness in printf | 08:33.38 |
| chrisl | It could be a problem with trio :-( | 08:33.57 |
| kens | Well I'm seeing numbers like -000.57 which shoudl be -1000.57 | 08:34.20 |
| | I can't really see how pdfwrite would be doing that. | 08:34.33 |
| chrisl | I'll look at it in a little while | 08:34.53 |
| kens | I could believe the '0' matrix, but the broken floating points are just strange. | 08:35.08 |
| | I'll take a quick poke at the PDF file the OP made, though it can't really be the same problem. | 08:35.29 |
| | chrisl I do see the same number problem in the file the OP made, but (and this is truly weird) only in 2 places. Of course those appear to be the places where the text is misplaced. | 08:39.58 |
| | Oh oops, there's another 2 | 08:40.13 |
| Robin_Watts | Fixed version of last nights commits on line. tests running now. | 08:43.15 |
| chrisl | debug pcl6 also gives errors in the pdf - so that's a start! | 08:43.56 |
| kens | chrisl I suspect its a printf or Trio problem. Weirdly it is *not* affecting all teh cases, neither in the customer file nor the one you sent me. | 08:47.06 |
| | Let me find where the initial Matrix get sset for the stream, that's probably the easies place to set a breakpoint | 08:47.29 |
| chrisl | kens: it doesn't seem to be a trio problem, I just built without trio, and get the same issue | 08:47.36 |
| kens | Very strange | 08:47.43 |
| | At the start of the page stream you see '0 0 0 0 0 0 cm BT' ? | 08:48.05 |
| chrisl | Which object is the page stream? | 08:48.37 |
| kens | object 5 for me, you'll need to decompress the file though | 08:49.04 |
| chrisl | Oh, like 5 lines into the page stream? "0 0 0 0 0 0 cm BT" | 08:49.10 |
| kens | Yes, that's it | 08:49.22 |
| | That should be 10 0 0 10 0 0 cm BT | 08:49.37 |
| chrisl | Well, let me do a full clean build, and try again | 08:50.18 |
| kens | OK | 08:50.22 |
| | But it is similar to the problem I see in the customer file | 08:50.35 |
| chrisl | My understanding is that trio is *supposed* to endian agnostic, that's one of the reasons I opted for it | 08:51.06 |
| | *supposed* to be...... | 08:51.18 |
| kens | Yep, it could be somethign else of course. | 08:51.19 |
| | give me a couple of minutes, I'm having trouble finding the stream code | 08:51.36 |
| chrisl | Oh, I'm doing a build on the PPC Mac Mini - you have plenty of time! | 08:52.01 |
| kens | :) | 08:52.11 |
| | ah looks like none_to_stream, I'll just debug it and check | 08:52.47 |
| | Yes, if you stick a breakpoint at about line 1001 in gdevpdfu.c, none_to_stream(), where it does pprintg2(s, "q %g 0 0 %g 0 0 cm\n" That should come out as 10 0 0 10 0 0 aqnd actually gets written as 0 0 0 0 0 0 | 08:55.17 |
| | That's just after the comment starting "* Scale the coordinate system. Use an extra level of q/Q..." | 08:56.07 |
| chrisl | Yeh, I see it..... | 08:56.17 |
| kens | Its not the place where the customer file breaks, but it kind of looks like the same problem | 08:56.45 |
| | OK I just modified the customer file by changing the -00.8 to -100.8 and that fixes the file, the text comes out in the right place. | 08:58.45 |
| pedro_pc | hi folks | 08:59.35 |
| kens | Morning | 08:59.40 |
| chrisl | kens: the initial matrix for the stream can't be 10 0 0 10 0 0 | 09:05.14 |
| kens | really ? why not ? | 09:05.24 |
| | The inital resolutiopn for pdfwrite is supposed to be 720 dpi | 09:05.43 |
| chrisl | It's calculated as 72.0 / pdev->HWResolution[0] | 09:05.44 |
| kens | Hmm, yes, I wonder if I'm looking at the wrong stream. | 09:06.07 |
| | It *looks* liek the right place :-( | 09:06.17 |
| chrisl | It should be approx 0.1 0 0 0.1 0 0 | 09:06.53 |
| kens | Yeah but that would be wrong..... | 09:07.07 |
| kens | hates pdfwrite more every day | 09:07.20 |
| | Looks like that's not the initial setting, that seems to come from 'prepare_text_drawing :-( | 09:08.14 |
| mattchz | morning. Iâll be mostly doing non-artifex stuff today, but Iâll be here if anyone needs anything. | 09:08.15 |
| chrisl | kens: I'm look at the call from pdf_open_contents | 09:09.09 |
| kens | Yeah but that's called from pdf_prepare_text_drawing | 09:09.36 |
| | WHich is much too late | 09:09.47 |
| chrisl | Oh yes, so it is..... | 09:09.55 |
| kens | I'll have to track a bit further back | 09:09.58 |
| chrisl | I think I'll go get a coffee! | 09:11.17 |
| kens | Good plan | 09:11.25 |
| | chrisl its stream_to_text() in the same source file | 09:14.07 |
| | Line 1032 pprintg2(pdev->strm, "%g 0 0 %g 0 0 cm BT\n" | 09:14.56 |
| kens | coffees also | 09:18.29 |
| chrisl | On the first call (at least) the values written to the stream in stream_to_text() 10 0 0 10 0 0 | 09:21.04 |
| kens | That's not what was in the file you sent me :-) | 09:21.26 |
| chrisl | No, but that's what's written to the stream write buffer | 09:21.48 |
| kens | ah, ok. what happens if you run to completion ? You might want to add -dCompressPages=false as well for easier reading | 09:22.16 |
| | Assuming that doesn't make it start working of course | 09:22.28 |
| chrisl | I do have CompressPages=false | 09:23.41 |
| kens | Oh, right, well if you run to completion, is that matrix broken ? | 09:24.16 |
| chrisl | great, running in the debugger produces a valid pdf :-( | 09:24.16 |
| kens | Ah, I had a nasty suspicion that might happen :-( | 09:24.27 |
| | The fact that only some printfs get broken suggested some kind of memory corruption | 09:24.52 |
| chrisl | -Z@ makes no difference...... | 09:25.46 |
| kens | I'm at a loss to know what to suggest.... | 09:26.04 |
| chrisl | I'll try valgrind and memento | 09:26.19 |
| kens | I guess that makes sense | 09:26.27 |
| chrisl | If those don't help, I'll go back to bed, pull the covers over my head, and hope it all goes away...... | 09:26.58 |
| kens | That's pretty much how I feel about it too :-( | 09:27.17 |
| chrisl | Okay, valgrind on a rather elderly PPC machine - this won't be quick! | 09:27.55 |
| kens | nor will memento be | 09:28.05 |
| | I'll go back to what I was doing | 09:28.15 |
| | If I can remember what that was.... | 09:28.26 |
| chrisl | <sigh> valgrind reports *no* errors/warnings...... which is rare! | 09:34.39 |
| kens | chrisl I guess that proves my efforst in that regard have had *some* effect.... | 09:54.17 |
| chrisl | kens: Yes, that's a good thing - in some ways | 09:55.03 |
| kens | <sigh> Seems my network is not happy today :-( | 09:58.31 |
| chrisl | memento reports corrupted memory, but I'm finding it confusing...... | 10:01.56 |
| kens | The memento log ? | 10:02.12 |
| | Maybe I should try a memento build here too, I'll get that started building | 10:02.26 |
| chrisl | Hmm, too big to pastebin - but I'm not sure it would help you much. | 10:03.24 |
| kens | I'll see what I can come up with here | 10:03.42 |
| chrisl | It does show similar results on x86_64 | 10:04.11 |
| kens | OK well hopefully I can see it too, and it 'might' give me something to go on | 10:04.31 |
| chrisl | It all seems to be corruption of the text enumerator allocated in gx_default_text_begin(), called from pdf_default_text_begin() | 10:06.28 |
| kens | Ah, intereswting indeed. I have a vague recollection of doing something related to that relatively recently. | 10:06.59 |
| | But I could be making that up...... | 10:07.18 |
| | Anyway build done, now I need to run it | 10:07.26 |
| chrisl | The trouble is, once again, we have a reference counted object, and don't bother with the reference counting - that really p*sses me off! | 10:08.14 |
| kens | Wow, *loads* of corruption warnings | 10:08.25 |
| | Yeah I'm not sure why we even bother with reference counts on so many things | 10:08.45 |
| chrisl | Well, clearly we don't bother! | 10:09.07 |
| kens | Well, I meant having the field in there | 10:09.19 |
| chrisl | Well, the object *is* reference counted, in some places, and not in others | 10:12.42 |
| kens | That makes even less sense :-( | 10:12.52 |
| | 1.8 Mb of log.... | 10:13.09 |
| | THis might take a while | 10:14.09 |
| chrisl | kens: so, if you look in gdevpdtt.c line ~3274 the call to complete_charproc()...... | 10:18.21 |
| kens | One moment | 10:18.30 |
| | OK I see that (its 3276 for me) | 10:19.05 |
| chrisl | complete_charproc() calls gs_text_release() on pte_default | 10:19.15 |
| kens | Hmm, I think it needs to | 10:19.35 |
| | Thre are at least 2 places we can free that | 10:20.08 |
| chrisl | Then later in gdevpdftt.c (for me) line ~3352 we do: pte_default->procs = save_procs; | 10:20.10 |
| kens | Hmm, tht looks wrong, yes | 10:20.38 |
| chrisl | We also then use pte_default in the next block starting line ~3377 - not sure about that | 10:21.49 |
| kens | This code has undergone a lot of changes | 10:21.55 |
| | I'm fairly certain it can't get to the next block from there | 10:22.32 |
| | It eikther returns an error, goes back to the top, or goes to the default implemenentation (bitmap) | 10:22.53 |
| chrisl | I think you're right, it's a fairly convoluted flow at that point | 10:22.55 |
| kens | Yeah this code is very horrible | 10:23.03 |
| | adding in support for all the PCL font types only made it more horrible | 10:23.17 |
| | It looks like 'save_procs' is useless now | 10:23.33 |
| | Ah, I think some light dawns | 10:24.26 |
| | THIs is a special case (of course!) | 10:24.35 |
| | Its the early_accumulator case | 10:24.48 |
| | If we ever 'goto top' I htink htis will fail | 10:25.16 |
| | Because we have released the text_eunmerator | 10:25.27 |
| chrisl | Removing the save_proc assignment cures those memento errors | 10:25.42 |
| kens | Well, that's a start. I guess the question is what does it do on the PPC build | 10:26.03 |
| chrisl | Well, the memento build produces a valid PDF...... | 10:26.24 |
| kens | Yeah, sadly memory corruption is like that :-( | 10:26.42 |
| chrisl | I've made a small other change, and I'll rebuild a non-memento version | 10:27.32 |
| kens | OK I'm going to work through the code a bit, because I'm concerned that if we ever execute 'got top' then this will fail horribly anyway | 10:28.06 |
| chrisl | Well, the think I've just added is to set penum->pte_default = NULL - so if we "goto top" we'll be forced to recreate the enumerator | 10:28.57 |
| | s/think/thing | 10:29.05 |
| kens | That will prevent the problem, certainly, but I'm wondering if its ever valid, in which case we would not want to do that. Bear with me, I'll need to dig through a fair bit of code | 10:29.40 |
| | Clearly the save_procs stuff is bigus though | 10:29.57 |
| | bogus* | 10:30.02 |
| | Ah, looks like something already sets penum->pte_default to 0 for this case. | 10:30.42 |
| | and the reason we go round again is because we have more glyphs to process | 10:30.57 |
| | (potentially) | 10:31.03 |
| chrisl | Well, you could use the reference count to ensure pte_default hangs around until you are done with it | 10:32.26 |
| kens | chrisl complete_charprocs sets pte_default to 0 if it releases pte_default | 10:32.28 |
| | SO it ought to be all safe, apart from the reassignment of the save_procs | 10:32.52 |
| chrisl | Oh yes, so it does | 10:33.01 |
| kens | I reckon the safest solution is to guard the assugnement with a check on penum->pte_default. | 10:34.01 |
| | Though in truth I can't see any way to get there without releasing it, so the best solution is probably to remove save_procs altogether | 10:34.44 |
| | I strongly suspect this code is a holdover from some earlier incarnation where it did something useful | 10:35.15 |
| chrisl | The only possible issue in the future might be if the pte_default has a ref count > 1, so doesn't actually get freed, the procs would be wrong | 10:35.50 |
| kens | True, but we would not reuse it ourselves anyway, and since we have the only reference to it (as far as I know) that should be OK | 10:36.21 |
| | setting penum->pte_default to NULL gets rid of our only reference in pdfwrite | 10:36.41 |
| chrisl | Yeh, okay - *clear* comment on that front would be good! | 10:37.00 |
| kens | I've tried to comment tbhis code, not always with much success I fear | 10:37.23 |
| chrisl | Well, just comment at the call to complete_charproc() saying "we assume we have the only reference to pte_default, so we don't need to return the procs to defaults" | 10:38.31 |
| kens | Oh yeah, I'll add a comment all right, just that this code is already fairly heavily commented, and it *still* doesn't make much sense :-( | 10:39.04 |
| | I'm just doing a cluster push to see if anythgin horrendous falls out | 10:39.16 |
| chrisl | I don't like the way it uses "goto top" both for "retry" and normal multi-glyph processing. | 10:40.19 |
| kens | I'm afraid I inherited that form the original architect | 10:40.39 |
| chrisl | things "architect" == "hacker"...... | 10:41.01 |
| kens | :-D | 10:41.06 |
| chrisl | or possibly "thinks" - geez! | 10:41.22 |
| kens | I don't actually know who wrote it, its been like that for a very long time | 10:41.27 |
| | Its definitely worth fixing the memento fault anyway, its good to find this, they can be hard to track down in pdfwrite | 10:42.28 |
| chrisl | That resolves the memento errors, and the PDF output is now good on PPC. As you say, it's hard to be sure, but it's likely this is the problem | 10:43.29 |
| kens | Well its defintely *a* problem :-) If the regression run is OK I'll commit thre change and tell the reporter to try it, with no warranty. THanks for the help chrs | 10:44.12 |
| | Or even Chris.... | 10:44.33 |
| chrisl | How competent do you reckon this guy is? I've been messing with the 9.14 release code, so could stick up the complete file for him to just drop in - rather than a patch | 10:45.09 |
| kens | Well, he's building GS from source..... | 10:45.26 |
| | If he's not happy with the patch from the commit, he can say so :-) | 10:45.57 |
| chrisl | He's building it from source - without a pointless and wrongly formed option to configure! | 10:45.59 |
| kens | isn't going to get involved with build stuff :-) | 10:46.25 |
| Robin_Watts | paulgardiner, pedro_pc, jogux: Tests passed. Could someone review robin/master when you get a mo? 2 commits. | 10:51.01 |
| pedro_pc | looks | 10:51.53 |
| | Robin_Watts | 10:52.43 |
| | Robin_Watts: the DPI change and windesktop-sot hashes commits? | 10:53.09 |
| | Robin_Watts: in pdf-export-mode-generic I'd factor out the dpi calculation into a sepearate function as its used 3 times (could probably cover the calculation in pdf-export-mode-image.c too with a small tweak). LGTM otherwise | 11:08.34 |
| | hashes change is a bit puzzling - did we change the build options on windesktop-sot recently? If it works for you I'm happy for it to go in anyway | 11:09.35 |
| Robin_Watts | pedro_pc: No idea about the hashes change. Possibly I just cut and pasted something badly. | 11:14.21 |
| kens | lunches | 11:14.32 |
| paulgardiner | Robin_Watts: so are you now calculating the dpi on the basis of the image's width/height in pixels and the height/width of the area within the document where it's displayed? | 11:15.28 |
| Robin_Watts | yes. | 11:16.17 |
| paulgardiner | As pedro_pc says there's a function that could be broken out, but otherwise look good. | 11:18.53 |
| | Robin_Watts: what happens without the hashes update? | 11:19.06 |
| Robin_Watts | paulgardiner: it builds, but the bsc information is wrong. | 11:24.32 |
| | yeah, I'm going to look at breaking out the common function now. | 11:24.51 |
| paulgardiner | Robin_Watts: ah I'd noticed that but thought it was something specific to my set up | 11:29.04 |
| | LGTM then | 11:29.09 |
| | pedro_pc: did you get to the bottom of the problems swapping branches? | 11:29.44 |
| pedro_pc | paulgardiner: not completely - I checked the source too and your branch is definitely the same. I had an issue trying to deploy - corrupt apks, various failures and I had a build failure about an hour ago where it looks like there have been problems with swap on my PC - no actually out of memories until python failed trying to fork the compiler. Hard to pin down, but I've rebooted and rebuilt the Good app - just rebuilding the standard SO builds | 11:35.14 |
| paulgardiner | :-( Hopefully a transient thing | 11:36.02 |
| pedro_pc | I had a couple of apparently zombied devenv and ffox processes which weren't in the process list but *were* in the paging allocation list (with very large allocations) | 11:36.03 |
| | yeah, haven't every seen that before | 11:36.16 |
| | perhaps I should just reboot 'doze more often ;) | 11:36.37 |
| paulgardiner | I'm part was through a new release to the Apple app store. I was hoping to release from the same version of the source as I used for the testflightapp test version, but I need to add a few extra icons to resources because of iOS 7 changes. | 11:51.44 |
| | My feeling is I should branch from where I generated the test version | 11:52.12 |
| | I was thinking smart-office-2.3.0-release-branch | 11:53.04 |
| | I wasn't thinking we'd use this for anything other than adding the icons, certainly not a great long branch divergent from master. | 11:53.49 |
| | Robin_Watts, pedro_pc: what do you think? | 11:54.11 |
| | I can't really see how it can cause any problems to do so. | 11:54.29 |
| Robin_Watts | paulgardiner: Sounds reasonable. | 11:54.59 |
| paulgardiner | ... other than using up that branch name. Maybe a different name would be better. | 11:55.00 |
| Robin_Watts | branch names are cheap. | 11:55.16 |
| paulgardiner | yeah true | 11:55.23 |
| | I'll plan on going with that. If anyone has further thoughts... | 11:55.40 |
| pedro_pc | is there anything on master since you did the testflight build? I don't have any particular issue with a release branch but if there's nothing since then I'd just commit the icons to master and tag it | 11:55.49 |
| Robin_Watts | I was assuming there must be something else on master. | 11:56.31 |
| | as otherwise, ... what pedro said | 11:56.41 |
| pedro_pc | probably, I just can't remember when paulgardiner did the testflight build :) | 11:56.55 |
| paulgardiner | pedro_pc: there's not much, but if I commited to master then I'd feel nervous about release without doing yet another testflight test | 11:57.53 |
| pedro_pc | paulgardiner: no problem - if there's other stuff on there then I'd go with what you suggested | 11:58.30 |
| paulgardiner | ok great | 11:58.40 |
| pedro_pc | otherwise you end up in subjective discussions about potential impact of changes | 11:58.53 |
| Zaister | Robin_Watts: are you open to some expansion code for mupdf? | 11:58.53 |
| pedro_pc | has to pop out - back in 30 mins | 11:59.29 |
| Robin_Watts | Zaister: Sure. | 12:00.17 |
| Zaister | i have implemented PageLable evaluation for mupdf | 12:00.26 |
| | PageLabel even | 12:00.34 |
| Robin_Watts | just on hold with AVIS customer service, so if I go quiet, it's cos I am screaming at them. | 12:00.53 |
| Zaister | ah I see | 12:00.59 |
| Robin_Watts | Zaister: Nice. | 12:01.01 |
| Zaister | I've been working on a mupdf backend for Okular, and that a feature that mupdf was missing | 12:01.29 |
| Robin_Watts | Zaister: The best way to do this is for you to create a bug on bugs.ghostscript.com | 12:01.35 |
| Zaister | OK | 12:01.45 |
| Robin_Watts | Say that this is a missing feature, and add a patch. | 12:01.48 |
| | We can then look at it etc and feed back etc. | 12:01.54 |
| Zaister | cool | 12:02.09 |
| Robin_Watts | There is also a link to our CLA from where you upload the patch. | 12:02.15 |
| | but this does sound like a bit of functionality we are missing, so thanks. | 12:02.41 |
| Zaister | It's probalby not perfect in the way the code is organized, but it works :) | 12:03.15 |
| henrys | US holiday today, FYI | 12:05.45 |
| kens | Yep, notcied that one. | 12:06.04 |
| chrisl | It is the one US holiday I always remember! | 12:07.24 |
| Robin_Watts | Woo Hoo! Avis have reduced the upgrade fee from 780 dollars to 180. Much more reasonable. | 12:13.11 |
| kens | Congratulations! But how much did it cost you in phone calls and frustration ? :-) | 12:15.24 |
| Robin_Watts | hours and hours :) | 12:16.55 |
| | but it was a welcome break from smart office. | 12:17.03 |
| | Fixed version of that commit online now. | 12:21.46 |
| | Just going to test it while I go for lunch. | 12:21.56 |
| Zaister | Robin_Watts: mailing the scanned, signed CLA to the email address will get this sorted out with the bug? | 13:11.58 |
| Robin_Watts | Zaister: Should do, yes, thanks. | 13:12.17 |
| Zaister | cool. | 13:12.38 |
| Robin_Watts | paulgardiner, pedro: tests passed. Do you want to rereview? | 13:13.01 |
| pedro_pc | Robin_Watts: just trying to fetch the changes, but my git fetch just failed with a network error | 13:14.13 |
| | odd given that I appear to be talking to you now... | 13:14.27 |
| | this is turning out to be One Of Those Days | 13:14.42 |
| Robin_Watts | is familiar with them. | 13:14.53 |
| pedro_pc | for the SOG oddities I dumped genroot, checked out my own branch, rebuilt and now the app fails to init because it can't open any system font files on android | 13:16.03 |
| Zaister | Robin_Watts: OK, CLA mailed, bug submitted with patch attached: http://bugs.ghostscript.com/show_bug.cgi?id=695351 | 13:16.06 |
| | btw, I have this nicely working in Okular now. The only thing I'm missing now is printing. | 13:17.23 |
| Robin_Watts | Zaister: I see some indentation problems, and some C99isms... | 13:18.06 |
| | and a potential leak of buf in pdf_load_page if pdf_lookup_page_label throws an error. | 13:18.53 |
| Zaister | oh are you using C11? | 13:19.17 |
| paulgardiner | Robin_Watts: looks fine to me | 13:19.22 |
| Robin_Watts | Zaister: C89 :) | 13:19.35 |
| Zaister | oh | 13:19.44 |
| | :) | 13:19.53 |
| paulgardiner | Can some one look at my commit on the new smart-office-2.3.0-release-branch? | 13:19.55 |
| Robin_Watts | and the pdf_label_items stuff could possibly be more in the style of the stuff around it, but it looks like a good start, thanks! | 13:20.54 |
| | paulgardiner: Ta. Will look now. | 13:21.10 |
| Zaister | Robin_Watts: I tried to match the style but probably wasn't aware of your implied conventions | 13:22.15 |
| Robin_Watts | Zaister: no worries. | 13:22.36 |
| | Tor will need to look over the patch, but it's certainly not offensive :) | 13:22.54 |
| Zaister | cool | 13:23.00 |
| Robin_Watts | paulgardiner: Looks rubberstampable to me :) | 13:25.03 |
| paulgardiner | :-) ta | 13:25.10 |
| Zaister | Robin_Watts: on thing, the PDF standard spoecifies numbers can be arabic numerals, or upper or lower case roman numerals, er even letters; currently my patch only uses arabic numerals | 13:28.07 |
| Robin_Watts | Zaister: ok, I've not read that bit of the spec, so I'll take your word for it. | 13:28.57 |
| | As long as the patch allows for it to be updated to support the others later without changing the API, I imagine that would be fine. | 13:29.20 |
| Zaister | you might have a preface in a book, numbered i, ii, iii, and then the normale pagination form 1 | 13:29.26 |
| | yes that would be easy | 13:29.34 |
| | except for the actual numeral converting :) | 13:29.59 |
| | Robin_Watts: are you sure about C89? mupdf doesn't compile with -ansi added to the CFALGS :) | 13:34.45 |
| | CFLAGS even | 13:35.09 |
| Robin_Watts | Zaister: We try for the lowest version of C we can. | 13:35.19 |
| | Specifically, we avoid using inline declaration of vars, and only declare them at the top of blocks. | 13:35.43 |
| Zaister | ah ok | 13:35.55 |
| | that makes sense | 13:35.58 |
| Robin_Watts | I wonder why it fails with -ansi though... | 13:36.13 |
| Zaister | / comments, forexample :) | 13:37.08 |
| | // | 13:37.12 |
| Robin_Watts | Broadly we try to avoid // too in the non-platform specific bits. | 13:37.34 |
| Zaister | hm, the memory issue is tricky, as these page labels have no specified length limit | 13:54.57 |
| jogux | good afternoon | 13:59.45 |
| kens | Hi jogux | 13:59.53 |
| Robin_Watts | Zaister: So fz_malloc it, have the pdf_page own the memory, and have it free it on page release? or something? | 14:00.31 |
| pedro_pc | fixes his font loading problems in the android C code by adding an ALIEN_SECURE_FS to the #ifdef ALIEN_SECURE_FS_ANDROID_C | 14:00.34 |
| paulgardiner | jogux: I'd dispute that. But Hi | 14:00.35 |
| Zaister | yeah, i'm trying to work that in, allocaing based on length | 14:00.53 |
| pedro_pc | E_TOOMANYVARIANTS | 14:00.53 |
| jogux | paulgardiner: uhoh :) | 14:01.13 |
| | paulgardiner: did you remember my notes about stuff we should change in itunesconnect? | 14:01.35 |
| paulgardiner | Eek! What? | 14:02.00 |
| Robin_Watts | dives into the Image component... if I'm not back in an hour, come find me with boltcutters. | 14:02.08 |
| pedro_pc | grins | 14:02.20 |
| jogux | paulgardiner: iirc something like we should add âsmartofficeâ to the keyword list | 14:02.24 |
| pedro_pc | and 'Picsel' if its not there ;) | 14:02.44 |
| pedro_pc | would add entwrx too | 14:02.54 |
| Zaister | Robin_Watts: usage of sigjmp_buf breaks the ansi compile, btw | 14:03.19 |
| jogux | paulgardiner: I think Iâd be tempted to mention the fact that thereâs a forum at the start of the âwhatâs newâ section too | 14:04.35 |
| | hm, thatâs odd, http://www.picsel.com/legal/pso-eula renders as plain text for me, html tags and all | 14:06.15 |
| | the text is also wrong :-( | 14:06.33 |
| kens | Yes me too | 14:06.36 |
| jogux | (mentioned SOT Ltd) | 14:06.46 |
| chrisl | Maybe because there's no .html/.htm extension? | 14:07.42 |
| paulgardiner | jogux: feel free to edit. It looks like it isn't too late | 14:08.13 |
| jogux | paulgardiner: darn. weâll need to remove something to add smartoffice :( | 14:08.54 |
| | we have document, office, edit, view, print, share, word, powerpoint, excel, pdf, text, presentation, and the limit is 100 characters | 14:09.04 |
| | removing âshareâ does it. sound ok? | 14:09.45 |
| paulgardiner | Yeah | 14:09.53 |
| jogux | seems the least valuable. in fact I canât see the value. | 14:09.55 |
| | the description mentions the picseluk facebook and twitter - are we planning to use those? | 14:10.32 |
| paulgardiner | If you were looking for something like SO, I can't imaging "Share" being the most likely choice of search terms | 14:10.58 |
| | Probably not. Good place to mention the forum | 14:11.52 |
| jogux | âwhatâs newâ could maybe do with a bit of marketeer polish :-) | 14:12.25 |
| | âWelcome to SmartOffice, now by Artifex. This is just a quick minor update to remove the nag banners, fix a few layout issues and a few other minor bugs. We have big plans for SmartOffice - stay tuned for a large update coming later in the year!â | 14:13.53 |
| Robin_Watts | quick or minor, not both. | 14:14.20 |
| jogux | yup | 14:14.35 |
| | Iâm almost certainly not the person we want writing this :-) | 14:14.43 |
| Robin_Watts | quick update, and instead of "minor bugs" say "annoying bugs" | 14:14.56 |
| paulgardiner | Your suggestions so far look pretty good to me | 14:18.59 |
| | How about "Here's the result of several months of hell. God I hope someone finds a use for it"... no lets stick with yours. | 14:22.07 |
| jogux | is Miles our marketing person? I guess we should run it past him | 14:22.41 |
| | paulgardiner: did you decide we didnât need to worry about the app id changing? | 14:23.06 |
| paulgardiner | Yeah. I don't think it's avoidable when an app is moved from one account to another. | 14:23.47 |
| jogux | that seems odd - you wouldnât want to lose login details just because of that. | 14:24.15 |
| Robin_Watts | jogux: Is this android or ios? | 14:24.32 |
| jogux | iOS | 14:24.36 |
| Robin_Watts | On android you can tweak the listings after publishing. | 14:24.47 |
| jogux | I think you canât on iOS anymore, but let me just check | 14:25.02 |
| | hm. odd. It /looks/ like it would let me | 14:25.40 |
| | you canât edit the keyword list though | 14:26.42 |
| paulgardiner | Do we still get random image differences in ATS? | 14:34.52 |
| | http://intranet.picsel.com/~ats/cgi-bin/results-tgvath.pl?resultid=1320&diff=0 | 14:34.59 |
| Robin_Watts | paulgardiner: Those are because of my commit. | 14:35.11 |
| | ATS has not updated its baselines yet. | 14:35.16 |
| | Let me run the appropriate group task to do that. | 14:35.28 |
| paulgardiner | Oh okay | 14:35.34 |
| jogux | robin_watts : Iâve rerun them now | 14:36.07 |
| Robin_Watts | jogux: too slow! | 14:36.13 |
| jogux | :) | 14:36.18 |
| | paulgardiner: http://stackoverflow.com/questions/23792236/application-identifier-entitlement-value-has-changed does seem to suggest thereâs nothing we can do about the identifier chain. At least we donât actually use the keychain :-) | 14:39.54 |
| paulgardiner | Same stack overflow post that let me to the same conclusion. :-) | 14:40.41 |
| jogux | ah :-) | 14:40.46 |
| paulgardiner | s/let/led | 14:40.47 |
| | There are some of Pete's commits on my master branch. Was just about to push them but might be good if someone else looked over them too. | 14:42.36 |
| Robin_Watts | fetches | 14:43.00 |
| | paulgardiner: Any changes since I pulled for the last review? | 14:43.40 |
| | git fetch isn't giving me anything. | 14:43.55 |
| paulgardiner | No | 14:43.57 |
| | Been there a while | 14:44.07 |
| | Oh. I'll need to rebase again | 14:44.59 |
| Robin_Watts | The gen-patch one... | 14:46.57 |
| jogux | paulgardiner: the commit messages may not be wrapped at 72 columns | 14:46.59 |
| Robin_Watts | It used to try to make gen_root and throw an error if the creation failed. | 14:47.20 |
| | now it checks to see if it exists, and if not makes gen_root. | 14:47.35 |
| | but nothing now checks whether that creation worked or not. | 14:47.44 |
| | paulgardiner: All seem sane to me. | 14:51.18 |
| jogux | doesnât see what was wrong with gen-patch before. but the new one looks odd as it has / hardcoded. | 14:51.24 |
| pedro_pc | if it works for everyone else then don't commit this - it fails for me still on golden master | 14:52.57 |
| | and the errors seemed real enough when I debugged it | 14:53.14 |
| jogux | pedro_pc : are you running it under git bash? | 14:53.18 |
| pedro_pc | no, commandline | 14:53.38 |
| paulgardiner | I'm confused about how it was: it used to check whether the mkdir failed because the dir already exists, but then bomb out even if that was the reason. | 14:53.40 |
| Robin_Watts | I always run it under git bash. | 14:53.56 |
| jogux | really, the directory shouldnât exist. It has the process id in it. | 14:54.03 |
| Robin_Watts | I use git bash as my standard windows command line. | 14:54.07 |
| jogux | and itâs cleaned up on exit | 14:54.10 |
| paulgardiner | Oh okay | 14:54.27 |
| jogux | so to see a directory getting reused, you would have to be stunningly unlucky, or the $$ for the process id isnât worked. | 14:54.42 |
| | if it does already exist, we should probably clean it out | 14:55.07 |
| pedro_pc | if we can't use gen-patch in a 'doze shell any more then I'll revert to using git bash or cygwin/mingw | 14:55.28 |
| jogux | pedro_pc : Iâll admit I donât think I tested it in that scenario. | 14:55.46 |
| pedro_pc | if we do expect it to work, I'm pretty sure its broken | 14:55.46 |
| paulgardiner | I don't think it works from git bash on windows | 14:56.01 |
| Robin_Watts | paulgardiner: Works for me | 14:56.13 |
| pedro_pc | running in a 'doze shell I get: Failed to read in stderr output from 'e:\genroot\gen-patch-112556/gen-patch-stderr-output.txt as the first thing I hit | 14:57.14 |
| paulgardiner | I have GENROOT set. Might that make a difference? | 14:57.22 |
| jogux | pedro_pc: interesting. | 14:57.37 |
| paulgardiner | GEN_ROOT in fact | 14:57.46 |
| pedro_pc | tbh I'm not fussed - just think we should either fix 'doze shell or decide that its not supported | 14:58.22 |
| paulgardiner | Well, we can leave that one for now. And I'll push the rest | 14:58.25 |
| Robin_Watts | I don't have GEN_ROOT or GENROOT set. | 14:58.26 |
| pedro_pc | either works for me | 14:58.27 |
| jogux | pedro_pc : I think it would be good to fix it :-) | 14:58.51 |
| paulgardiner | For me Failed to open tempfile : C:\Picsel\genroot/gen-patch-xxxxxxxxx | 14:59.59 |
| | Presumably because my GEN_ROOT has backslashes | 15:00.15 |
| | and doesn't start with /c/ | 15:00.31 |
| Robin_Watts | why is gen-patch using GEN_ROOT? | 15:00.50 |
| jogux | if set it uses it in preference to /tmp or %TMP% or whatever. | 15:01.28 |
| paulgardiner | Hmmm. Good question. | 15:01.32 |
| jogux | (I know that doesnât answer the âwhyâ question) | 15:01.47 |
| Robin_Watts | OK, Mine is using /tmp | 15:01.50 |
| paulgardiner | jogux: good observation. :-) | 15:02.06 |
| jogux | I suspect these differences are all setup differences. maybe. so it works for Robin because he doesnât have GEN_ROOT set, maybe. | 15:03.34 |
| paulgardiner | It would probably hurt me none to unset it | 15:04.19 |
| pedro_pc | gets the same issue but with my tmp dir instead of genroot if genroot isn't set | 15:04.21 |
| jogux | pedro_pc: do you still get a mix of \ and / ? | 15:04.35 |
| pedro_pc | yes | 15:04.46 |
| jogux | Iâm suspicious that may be part of the problem | 15:04.54 |
| | I can look at that separately - I may need to fix this for ATS on windows. | 15:05.25 |
| paulgardiner | I'll leave it out for now | 15:06.01 |
| pedro_pc | isn't sure - I'm pretty sure there was a mutually-exclusive situation on 'doze where one place complained if it didn't exist then another failed if it did, and I think I checked the physical existence of the dirs too | 15:06.14 |
| jogux | pedro_pc : there is certainly one or more funky things going on | 15:06.46 |
| | ATS images are up to date now btw. | 15:07.03 |
| pedro_pc | yep; just leave it out for now anyway - only seems to be me who had issues anyway ;) | 15:07.14 |
| paulgardiner | I have issues in git bash, although possibly fixable by unsetting GEN_ROOT | 15:07.46 |
| Robin_Watts | mattchz: Are you here? | 15:10.33 |
| mattchz | yep | 15:10.53 |
| | my mind has been elsewhere though | 15:10.58 |
| pedro_pc | mattchz is cowering in th corner 'cos you mentioned 'image component' | 15:11.02 |
| mattchz | I havenât been reading tbf :) | 15:11.12 |
| Robin_Watts | So, I've updated the Image component, specifically Image_getSource. | 15:11.16 |
| mattchz | just got notifications on my name | 15:11.19 |
| | lalala | 15:11.33 |
| Robin_Watts | If you do Image_getSource, and imdec->source->supportsReOpening, then I open the estream from that. | 15:12.12 |
| mattchz | ok | 15:12.31 |
| pedro_pc | paulgardiner: I have a few fixes on my sot-android-gdauth branch for the regular SO build. Reckon its worth me pushing them across to your pete-sog branch or just wait till we're done with that? | 15:12.55 |
| Robin_Watts | so, for a substantial class of images, Image_getSource will now work without needing to have that flag set. | 15:12.56 |
| mattchz | ok | 15:13.11 |
| Robin_Watts | So next step is the pdfexport stuff. | 15:13.21 |
| mattchz | has no idea what supportsReOpening is, or how it gets set | 15:13.23 |
| jogux | pedro_pc : I think pushing to other peopleâs trees usually fails :( | 15:13.35 |
| Robin_Watts | mattchz: RemoteURLs don't support reopening, but local ones do. | 15:13.50 |
| mattchz | ah, okay. | 15:13.54 |
| paulgardiner | pedro_pc: yeah probably worth rebasing them onto pete-sog and working from there from now on | 15:14.01 |
| Robin_Watts | so I can get the source. | 15:14.13 |
| pedro_pc | jogux: oh, is the dir readonly for other artifex folks? | 15:14.16 |
| jogux | pedro_pc : seemed so the time I tried :-) | 15:14.28 |
| Robin_Watts | and the format. | 15:14.29 |
| pedro_pc | paulgardiner: cool, I'll do that | 15:14.37 |
| Robin_Watts | If it's JPEG I want to save it out as is. | 15:14.37 |
| | I need to know width and height (easy), but also the colorspace... | 15:14.52 |
| | In case it's a greyscale or a CMYK jpeg. | 15:15.17 |
| paulgardiner | pedro_pc: although I'm just rebasing it again so best hold off until I've done | 15:15.18 |
| pedro_pc | nods | 15:15.26 |
| mattchz | k | 15:15.50 |
| Robin_Watts | mattchz: Any thoughts on how that might be achieved? | 15:16.16 |
| mattchz | Image_getType() or something gets the type iirc? | 15:17.08 |
| Robin_Watts | tee hees at: "FIXME: MJH 12/3/2006 - Some of the below blurb is inaccurate. Will fix this soon." | 15:17.14 |
| mattchz | no idea about the colourspace | 15:17.21 |
| | robin> hah | 15:17.27 |
| Robin_Watts | Image_getInfo returns the type. | 15:17.36 |
| mattchz | really needs past life regression therapy | 15:17.44 |
| Robin_Watts | sorry, Image_getSource returns the type. | 15:17.52 |
| | I suspect it's possible that the Image component doesn't know about the type. | 15:18.12 |
| mattchz | seems unlikely. | 15:18.19 |
| | is it available through a meta function? | 15:18.24 |
| Robin_Watts | The image component gets all images decoded to 565, right? | 15:18.39 |
| | so the colorspace is likely hidden in the decoder. | 15:18.57 |
| mattchz | Iâve lost track, but I think it depends on how it is initialised | 15:18.58 |
| | but in practice, 565 yeah | 15:19.03 |
| | the colorspace is a JPEG specific thing, right? | 15:19.14 |
| Robin_Watts | yeah. | 15:19.25 |
| | so I may need to go digging in the JPEG stream :( | 15:19.43 |
| mattchz | iirc, those meta functions are for the source, right? | 15:20.31 |
| Robin_Watts | meta functions are for the source estreams, yes. | 15:20.53 |
| mattchz | so, thatâs no help. | 15:20.59 |
| | OOI, why do you need to know? | 15:21.15 |
| Robin_Watts | Cos I need to write it out into the PDF file that we are saving. | 15:21.29 |
| mattchz | isnât it in the original pdf? | 15:21.42 |
| Robin_Watts | currently it saves all images as flate compressed raw ones, and I'd rather it stored the image as a JPEG if it was originally a JPEG. | 15:21.59 |
| | a) yes, but I've not got access to that, and b) what if I am saving out from (say) word ? | 15:22.23 |
| mattchz | oh, ok, I thought this was just editing existing PDFs. | 15:22.36 |
| Robin_Watts | mattchz: Nah, pdf export works for all formats. It basically makes a whole new PDF from the Layout list. | 15:22.56 |
| mattchz | I guess you want to consider adding more fields to Image_Dimensions or something? | 15:22.59 |
| Robin_Watts | mattchz: Maybe. | 15:23.10 |
| | Yes, in order to have got the width/height from the JPEG stream, we must have decoded enough to know the colorspace, I think. | 15:23.55 |
| | so that seems reasonable. | 15:23.58 |
| | That's nicer than I was thinking. Thanks. | 15:24.11 |
| mattchz | np | 15:24.20 |
| | I guess Image_dimensions should be renamed Image_Meta or something like that. | 15:24.30 |
| | oh, thereâs an Image_Info too. | 15:25.17 |
| | Not sure if that is more appropriate, or why it is separate. | 15:25.23 |
| | (both are returned from Image_getInfo) | 15:25.31 |
| Robin_Watts | has bloke coming to talk about solar hot water heating in a mo, so if I disappear, have a good weekend all. | 15:28.03 |
| mattchz | I think Dimensions is probably the correct one, since it causes a decode to get the required info, iirc. | 15:28.45 |
| paulgardiner | pedro_pc: paul/pete-sog is stable now. I finished messing with it | 15:28.56 |
| mattchz | (and for async images, one of the authoritative flags tells you if you actually have the info or not). | 15:29.09 |
| | vageuly. | 15:29.11 |
| | this is all hazy. | 15:29.13 |
| pedro_pc | paulgardiner: great - ta | 15:29.20 |
| mattchz | yeah, Image_Dimensions is what you want. | 15:30.21 |
| paulgardiner | pedro_pc: let me know when you've added your other commits. I may well need those too. | 15:30.49 |
| mattchz | Robin_Watts: iâve got this vague feeling that supportsReOpening can be false if the decoded image is smaller than the original version (for example, when the image comes from an estream) | 15:32.38 |
| pedro_pc | noticed they're actually on your pete-sog-old - although the FSSecure ifdef commit has been changed | 15:32.40 |
| Robin_Watts | mattchz: Yeah, I think so too. | 15:32.54 |
| | but that just means that we recompress small images losslessly. That doesn't bother me. | 15:33.08 |
| mattchz | thatâs almost certainly overridable. | 15:33.11 |
| | ah right, you fall back to the PNG thing. | 15:33.24 |
| Robin_Watts | I was mainly upset that we are recoding large jpegs as lossless PNGs. | 15:33.30 |
| paulgardiner | pedro_pc: everything from there is in pete-sog now. I used the one you just mentioned as a fixup for the earlier FSSecure change | 15:33.48 |
| Robin_Watts | after having taken the 565 quality loss hit. | 15:33.51 |
| mattchz | are we still doing 565 in this day and age? | 15:34.06 |
| pedro_pc | paulgardiner: ah, excellent - ta | 15:34.12 |
| | Robin_Watts, mattchz : reckon it would be nice to get the original source data to embed in the PDF? | 15:35.23 |
| paulgardiner | Oh hang on. I have just pulled something new in | 15:35.25 |
| Robin_Watts | pedro_pc: That's what I'm trying to do. | 15:36.54 |
| pedro_pc | Robin_Watts : cool - I'll go back in my box then :) | 15:37.17 |
| Robin_Watts | At the moment the PDF export just 'claims' the decoded bitmap and recodes it. | 15:37.19 |
| | I'm trying to get the original image data and use that. | 15:37.31 |
| | At the moment it will just be for JPEGs. | 15:38.22 |
| paulgardiner | pedro_pc: so looks like you rebased your android-sog-gdauth branch since I marked it in my repo as pete-sog-old. Is that right? | 15:38.24 |
| Robin_Watts | Fax/JBIG/JPX is possible too, with some more pain. | 15:38.41 |
| pedro_pc | paulgardiner: quite possible - you took that yesterday midday-ish? | 15:39.15 |
| paulgardiner | Still it shouldn't make any odds. Still everything is on pete-sog | 15:40.09 |
| | And the initial ones on that branch is pushed to golden, so that's the best place to work now. | 15:40.56 |
| pedro_pc | nods | 15:42.48 |
| paulgardiner | Actually somehow the ALIEN_SECURE_FS change you mentioned earlier is missing | 15:44.37 |
| | pedro_pc: I think I see now. You used rebase -i on your branch to update "Add secureFS ifdef..."? | 15:47.20 |
| | I'll update pets-sog to include that | 15:49.20 |
| pedro_pc | paulgardiner : yes, you are correct. I confess :) | 15:50.04 |
| paulgardiner | :-) | 15:50.10 |
| pedro_pc | we need a git confess in addition to git blame | 15:50.53 |
| paulgardiner | :-) | 15:52.47 |
| | Bah. I've pushed the commit for which that's a fixup to golden. | 15:54.00 |
| | Still I've just added it to pete-sog. Just has the commit message "Fixup" at the moment, but at least it's there. | 15:56.29 |
| pedro_pc | nods | 15:59.53 |
| jogux | hm. my gitbash is missing zip apparently | 16:42.51 |
| | I feel it should be obvious, but how do I add zip into git bash? | 16:44.42 |
| Robin_Watts | c:/Program Files (x86)/msys-git/bin or something | 16:47.25 |
| jogux | oh. perhaps the question I meant to ask was where to get a msys-git compatible zip :) | 16:47.47 |
| Robin_Watts | jogux: And dos zip will do. | 16:48.16 |
| pedro_pc | has a mingw zip on my path | 16:48.26 |
| Robin_Watts | s/And/any/ | 16:48.29 |
| | I have info-zip 3.0 from 2008. | 16:48.49 |
| jogux | for native windows I need wincvs for patch.exe apparently :-S | 16:52.37 |
| pedro_pc | yup - 1.2 | 16:55.13 |
| jogux | right, so other than needing to install zip, it âjust worksâ for me in git-bas. | 16:57.19 |
| | git-bash | 16:57.22 |
| | it also works if I have gen_root set to c:\genroot | 16:58.32 |
| | GEN_ROOT, even | 16:58.38 |
| | even with a mixture of \ and /s | 16:59.44 |
| jogux | installs wincvs | 17:01.13 |
| | ahh, yes, that breaks. | 17:03.16 |
| | $$ appears to get a PRNG | 17:03.59 |
| | s/get/be/ | 17:04.03 |
| | itâs failing in my new git code. | 17:04.33 |
| jogux | fails to understand how anything ever worked | 17:14.38 |
| | so, first / main bit of stupidness: I am using the tmp directory before itâs created. | 17:18.32 |
| | ahha. which is only an issue on windows as linux doesnât use a temporary file for stderr. | 17:22.39 |
| pedro_pc | better go pack. catch you later | 17:39.09 |
| jogux | cya peds, have a fun holiday :) | 17:39.24 |
| Robin_Watts | pedro_pc: Yeah, have a good one. | 17:39.37 |
| jogux | is in a maze of paths, some with s and some with /s :( | 17:45.46 |
| | robin_watts : pedro_pc : fixes for native windows gen-patch on my master. | 18:04.38 |
| | both were problems I introduced when changing it for our git repo :-( | 18:05.40 |
| Robin_Watts | fetching now | 18:05.50 |
| | seems plausible. | 18:07.17 |
| jogux | works for me in native windows, git bash and mac. | 18:08.36 |
| | even works in GEN_ROOT set (though I think it did before too). How does it fail for you PaulGardiner? | 18:09.45 |
| jogux | pushes those, anyway - thanks Robin | 18:09.54 |
| | does epage build okay on 64 bit windows? | 18:15.23 |
| Robin_Watts | On 64 windows, yes. | 18:15.35 |
| jogux | great, ta. | 18:15.41 |
| Robin_Watts | Using 64bit compilers, no idea. | 18:15.41 |
| | I use x86 compilers on a 64bit OS. | 18:15.53 |
| | (standard VS 2010 Professional install) | 18:16.06 |
| jogux | yeah, I need to go back to my vs 2010 install I was doing in the office that claimed to be installing only x64 compilers and see if it actually works or not. I hope it does. | 18:16.30 |
| | ie. I presume it means âcompilers to run on x64â rather than âcompilers that can only generate x64 codeâ. | 18:16.50 |
| Robin_Watts | jogux: Would seem odd otherwise. | 18:18.29 |
| | Ah, it's the British GP weekend. That's why it's just started to rain... | 18:19.13 |
| marcosw | sebras: I'd like to update and reboot casper, you are the only one logged on so I'm letting you know. | 20:02.58 |
| | Since today is a holiday in the US and our european customers/users are presumably done for the day I'm going to take this opportunity to do some maintenance on casper. I don't expect it to be down for more than 30 minutes or so. | 20:31.35 |
| | Forward 1 day (to 2014/07/05)>>> | |
IRC Logs