| | <<<Back 1 day (to 2012/05/15) | 2012/05/16 |
| sebras | yey! someone noticed that mupdf 1.0 was released: http://en.wikipedia.org/w/index.php?title=MuPDF&diff=492347879 | 00:16.26 |
| oy | hello | 05:07.01 |
| | mvrhel: can I still ask you? | 05:07.33 |
| ray_laptop | sebras: You just noticed that mupdf 1.0 was released ?? (of course it is already out of date) | 05:45.27 |
| | but, at least it is a good first release. | 05:47.04 |
| mvrhel | oy: I am here | 06:12.06 |
| | for a few minutes | 06:13.16 |
| oy | mvrhel: how is DeviceXXX/ invoked with gs? | 06:13.19 |
| | I mean keeping it non converted for calibration | 06:13.57 |
| mvrhel | ah | 06:14.01 |
| | so there are a few ways | 06:14.13 |
| | If the source data is DeviceCMYK and the target device is a CMYK device, then there is by default no conversion | 06:14.56 |
| oy | no outputIntent needed for that, interessting | 06:15.36 |
| | the same for DeviceN/ ? | 06:16.30 |
| mvrhel | DeviceN source colors? | 06:16.51 |
| oy | yes | 06:16.56 |
| mvrhel | It depends upon the output device again | 06:17.06 |
| | If the output device for ghostscript supports the DeviceN source colors no conversion occurs | 06:17.43 |
| oy | in the case of Gutenprint, it would support DeviceN/ | 06:18.07 |
| mvrhel | For example, in ghostscript there is a tiffsep device and a psdcmyk device, both of which will handle a large number of different spot colorants | 06:18.26 |
| oy | that would be in the linux printing chain cupsraster directly? | 06:18.50 |
| mvrhel | oh. I don't know how cupsraster hooks in to gutenprint. | 06:19.26 |
| | and the cups device has some strange color models | 06:19.42 |
| | tkamppeter may need to comment on this. | 06:19.54 |
| | personally, I think the color models for cups could stand to be reworked a bit | 06:20.13 |
| oy | hmm, how about DeviceRGB/ calibration/profiling? | 06:20.34 |
| mvrhel | so in that case, if my source file that I want to print/display is DeviceRGB and my target device is an RGB output device, there is no conversion by default with ghostscript | 06:21.20 |
| | if you specify a profile for the output device, then there would be a conversion. of course that is what you want to create in this process | 06:21.52 |
| | same as the CMYK case | 06:21.56 |
| | but if you have a PDF file, that has DeviceRGB and output to a RGB device, then the default case will do no conversion | 06:22.27 |
| | or a PS file for that case | 06:22.47 |
| oy | ah, what if we have a OutputIntent attached and want real DeviceRGB/ for rgb device? What should we do then? | 06:23.28 |
| mvrhel | you mean if you have a PDF file that includes an output intent in it? | 06:23.49 |
| oy | yes | 06:23.56 |
| mvrhel | by default, ghostscript will ignore the output intent | 06:24.10 |
| | you have to add the special option for it to use it | 06:24.20 |
| oy | in the linux print pipeline it will be activated | 06:24.43 |
| mvrhel | oh. So, if you are going to an RGB device, what will be the output intent? | 06:25.15 |
| oy | the embedded profile of course from the PDF OutputIntent | 06:26.12 |
| mvrhel | oh. I see | 06:26.46 |
| oy | it can be any rgb ICC profile | 06:26.48 |
| mvrhel | this would be a problem. you would not want to have the output intent to be in the calibration target file. | 06:27.30 |
| | if you are going to use the option with gs to use the output intent | 06:27.47 |
| oy | for the background, this way we can express that the sender knows about DeviceXXX/ and wants in this case non converted channels | 06:27.56 |
| mvrhel | hmm I have not updated the documentation I see | 06:28.45 |
| | oy: so either you need to not have the output intent in the file, or not use the option to make use of the output intent with gs | 06:29.57 |
| | if you want a non converted flow | 06:30.08 |
| oy | the most complicated but valid case is a mixed ICC + DeviceXXX/ + OutputIntent containing PDF | 06:30.20 |
| mvrhel | oy: ok but we are not now talking about calibration target printing? | 06:30.57 |
| oy | that means we can not rely on PDF/X-3 ? | 06:31.05 |
| | well, the idea was to use PDF/X-3 as a standard way to push calibration through the pipeline | 06:31.38 |
| mvrhel | ah ok | 06:32.04 |
| | let me back up a minute | 06:32.10 |
| oy | at one point you said the DeviceRGB/ will be assumed to be sRGB and needs conversion inside GS | 06:32.35 |
| mvrhel | *if* you specify to use the output intent | 06:32.52 |
| oy | sorry for the complicatedness :-/ | 06:32.54 |
| | ok | 06:33.03 |
| mvrhel | and the output intent is RGB lets say | 06:33.15 |
| oy | fine | 06:33.23 |
| mvrhel | and you have DeviceRGB colors in the file | 06:33.26 |
| | and you are going to an RGB device | 06:33.52 |
| | and you have not specified a destination ICC profile | 06:34.03 |
| | then there will be no conversions on the DeviceRGB colors in the file | 06:34.17 |
| | replace all the above with CMYK and the same is ture | 06:34.28 |
| | true | 06:34.31 |
| | essentially, what happens is that ghostscript will assign DeviceRGB source colors to the output intent profile and it will assume it is rendering to a device with the same profile | 06:36.12 |
| oy | you talk about the -sOutputICCProfile being absent? | 06:36.31 |
| mvrhel | yes | 06:36.36 |
| oy | huh, fine then :-) | 06:36.53 |
| mvrhel | if you specify a profile with -sOutputICCProfile then it will always render to the that profile. If you are making use of the output intent it will treat the output intent as a proofing profile. | 06:37.37 |
| | for that case | 06:37.50 |
| | ghostscript avoids doing any conversions if the source and destination ICC profiles are the same | 06:38.25 |
| oy | this is what we will do anyway, select the output intent profile and omit any -sOutputICCProfile | 06:38.27 |
| mvrhel | unless someone is fooling around with rendering intents. which is another story | 06:38.42 |
| | oy: ok that should work for you | 06:38.54 |
| | oy: there is a problem with this work flow though | 06:39.12 |
| | how do you deal with non PDF/X-3 files? | 06:39.55 |
| oy | still for completeness, specifying the OutputIntent a sRGB colour will be converted to the selected OutputIntent even if no -sOutputICCProfile is specified | 06:40.18 |
| mvrhel | oy: if the source file has a source RGB color that is specified by an sRGB profile in the PDF file, then it would be converted to the Output Intent profile | 06:41.24 |
| oy | thanks | 06:41.37 |
| mvrhel | if it is DeviceRGB, it will not be converted | 06:41.40 |
| oy | great | 06:41.53 |
| | so no problems with that | 06:42.14 |
| mvrhel | ok. the same behavior occurs for the CMYK case | 06:42.44 |
| | with a CMYK output intent | 06:42.51 |
| | out to a CMYK device | 06:42.59 |
| | with DeviceCMYK | 06:43.09 |
| | oh kens is on. time for me to go to bed | 06:43.52 |
| | oy: does that answer all your questions | 06:43.59 |
| kens | :-) goodnight Michael | 06:44.21 |
| oy | PDF documents will be checked for the OutputIntent and if absent we planed to tag DeviceRGB/ colours with sRGB | 06:44.21 |
| | mvrhel: yes, thanks :-) | 06:44.41 |
| mvrhel | ok. ping me later if you have more | 06:45.11 |
| | goodnight all | 06:45.15 |
| CircuitBug | i have a problem compressing a pdf with some transparent layers. could someone please help me? | 07:19.33 |
| kens | Depends what your problem is | 07:19.48 |
| CircuitBug | and how do i find out the problem | 07:20.25 |
| kens | Surely you know what your problem is ? | 07:20.36 |
| | If not, how do you know you have a problem ? | 07:21.00 |
| CircuitBug | when i give "gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -dNOPAUSE --sOutputFile=output.pdf Vignette.pdf" command it crashes | 07:21.36 |
| kens | What version of GS ? | 07:21.49 |
| CircuitBug | but if i pass it with dNOTRANSPARENCY it works fine | 07:22.00 |
| | 9.04 | 07:22.10 |
| kens | Well my first thought is 'don't use -dPDFSETTINGS', if you want to alter compression, flip the switches manually. | 07:22.37 |
| | THe second thing is try uing the current version, 9.05 | 07:22.54 |
| | I've a feeling I fixed a problem that sounds similar | 07:23.05 |
| CircuitBug | thanks. ill try it out. | 07:23.25 |
| kens | Otherwise, open a bug report at http://bugs.ghostscript.com and attach a specimen file there. I'll need to see the file to see what the problem is | 07:23.38 |
| CircuitBug | also how do i flip the switches manually? | 07:24.17 |
| kens | There are *lots* of individual controls for selectin downsampling and compression based on image colour. They are the same as the Distiller aprams used by Adobe and documented in ps2pdf.htm | 07:25.14 |
| | Eg ColoimageDonwsampleThreshold, ColoImageDownsampleType, ColorImageFilter etc. | 07:26.20 |
| | I suspect that the ColorConversionStrategy=/sRGB is the problem | 07:26.57 |
| | And I doubt you really want to do that anyway | 07:27.21 |
| CircuitBug | so could you give me a command to shrink my pdf for web viewing? | 07:30.54 |
| | I have a 150mb pdf which i need to make atleast 80mb | 07:31.23 |
| kens | Well not really. The decision about compression filters, accceptable downsampling tyep and thredshold etc are really up to you | 07:31.25 |
| | You could try using -dPDFSETTINGS=/ebook and then override teh ColorConversionStrategy to /LeaveCOlorUnchanged. | 07:32.11 |
| | *if* as I suspect, that is the cause of your problem. | 07:32.25 |
| CircuitBug | ill try that. thnks | 07:33.04 |
| kens | OK | 07:33.09 |
| CircuitBug | i keep receiving a segmentation fault.. | 07:44.07 |
| kens | Well maybe its a different problem | 07:44.17 |
| CircuitBug | it is im guessing...it stops a t a different position.. | 07:46.07 |
| kens | Well either you can select individual configuration items, and not use whichever one is causing a problem, or open a bug report. I can't help without seeing the file. | 07:46.59 |
| CircuitBug | i can send you the link if you like... | 07:47.36 |
| kens | I'd rather you open a bug report | 07:47.48 |
| CircuitBug | ok. thanks for all the help. | 07:48.33 |
| kens | no problem | 07:48.39 |
| CircuitBug | also is there a way of converting just a small section of the file | 07:49.17 |
| kens | Depends what you mean by a small section, an area of the page or a range of pages | 07:49.37 |
| CircuitBug | range of pages | 07:50.03 |
| kens | -dFirstPage= -dLastPage= these are all documented.... | 07:50.17 |
| CircuitBug | ok thanks | 07:50.26 |
| thgis | Hello. I am trying out mupdf on linux. I read on your web page that annitation features are available but I cant seem to figure out how to use it. | 12:12.13 |
| Robin_Watts | thgis: What exactly do you mean? | 12:15.21 |
| | We render some annotations within a PDF file. | 12:15.31 |
| | The existing viewer doesn't support adding annotations (though the underlying library exposes enough that it could be added with some non-trivial work) | 12:16.31 |
| thgis | ok. Thanks | 12:17.13 |
| kens | Robin_Watts : thanks for those Memento changes | 12:41.53 |
| | ANyone know how I cna find out the Git hash for the 9.0 release ? | 12:58.58 |
| Robin_Watts | kens: np. | 13:15.59 |
| | ghostpdl-9.00 ? | 13:17.31 |
| kens | Yes, though I have that now | 13:17.40 |
| Robin_Watts | just use "ghostpdl-9.00" as the hash | 13:18.02 |
| kens | Trying to figure out how much of the hash is needed bygit bisect :-) | 13:18.04 |
| | That works ? OK I'll try that | 13:18.13 |
| | Wow, it does, that's easier | 13:18.36 |
| | thanks Robin | 13:18.50 |
| Robin_Watts | np. | 13:20.17 |
| | Git lets you use tags/heads/branches etc everywhere you can use a hash - it just resolves them down transparently. | 13:20.46 |
| kens | Handy, saves me tying in a long hash :-) | 13:21.01 |
| Robin_Watts | if you do need to use a hash, 7 chars is usually enough. | 13:21.26 |
| kens | I think I was one short ;-) | 13:21.39 |
| Robin_Watts | (although I think we've got 1 collision on the gs repo where you need 8) | 13:21.41 |
| | hey kammerer | 13:59.37 |
| kammerer | HRobin_Watts: Hi | 13:59.47 |
| Robin_Watts | I have a memory of having an outstanding issue from you, but I can't remember what it was. | 13:59.51 |
| | Can you? | 14:00.13 |
| kammerer | mmm...i pointed to memory leak in mucbz, but it was mistake in my code | 14:01.06 |
| | it seems there was no issue | 14:01.16 |
| Robin_Watts | ok, so just my crap memory then :) Thanks. | 14:01.55 |
| kammerer | Could anybody help me: Is there possible to adjust constrast parameter of pdf page with mupdf? | 14:03.22 |
| Robin_Watts | on phone. | 14:06.17 |
| kammerer | In other way: is it any parameter in mupdf that allow make dark colors darker and white whiter in resulting rendering bitmap for pdf page | 14:10.54 |
| kens | Sounds like a colour management problem. At the moment I believe the asnwer is 'no' | 14:11.49 |
| kammerer | kens: Thanks | 14:15.45 |
| kens | NP, don't rely on my answers too much for MuPDF though | 14:16.03 |
| Robin_Watts | back | 14:35.11 |
| | kammerer: There is currently no way to do that. | 14:35.26 |
| | But it would be trivial to post process the produced bitmaps. | 14:35.44 |
| kens | You really need to add colour management in MuPDF :-) | 14:36.16 |
| Robin_Watts | In the mupdf viewer, I have an 'invert' option to invert the colors (so black on white becomes white on black). | 14:36.26 |
| | It'd be easy to add a similar post process step to apply some sort of dogleg curve. | 14:36.45 |
| | kens: It's on the roadmap :) | 14:36.56 |
| kens | I knwo :-) | 14:37.04 |
| kammerer | thanks | 14:38.13 |
| tkamppeter | chrisl, I have released cups-filters 1.0.18 now where the pdftops filter allows deciding whether to use GS or Poppler at runtime and which also allows to set a resolution limit. | 14:38.46 |
| | kens ^^ | 14:39.00 |
| kens | sounds good tkamppeter | 14:39.11 |
| tkamppeter | chrisl, kens, I have packaged this for Ubuntu Quantal and also as update for Precise andf given testing instructions on all relevant bugs. | 14:39.53 |
| kens | Exellent tkamppeter thanks | 14:40.14 |
| tkamppeter | chrisl, kens, In Precise I let it default to Poppler and 360 dpi max resolution. On Quantal default is Ghostscript and 1440 dpi max resolution. | 14:41.06 |
| | In both one can easily change these defaults per-queue or per-job via command line. | 14:41.42 |
| | chrisl, kens ^^ | 14:41.55 |
| kens | Nice and flexible, I'm sure most people will be happy with 360 dpi :-) | 14:42.16 |
| chrisl | tkamppeter: good. I seem to remember kens had a suggestion about where the problem with the HP printers lie - if this latest reporter is willing to help out, it shouldn't take long to confirm (or otherwise) | 14:42.30 |
| kens | chrisl I'm afraid I'd forgotten whatever my suggestion was :-( | 14:42.49 |
| chrisl | kens: it's that crap about filters erroneously closing their data source when they shouldn't | 14:43.13 |
| kens | Nope, completely blank, still as long as you rmember :-) | 14:43.34 |
| tkamppeter | I have tested on my HP Color LaserJet CM3530 MFP and changing max resolution leads to the expected processing time changes. Switching between GS and Poppler shows that with the same resolution Poppler jobs are 2 or 3 times faster. | 14:44.42 |
| chrisl | kens: see line 4583 in lib/opdfread.ps | 14:45.38 |
| kens | Hmm, well that's slightly surprsing, but that may be due to some artefact of the way that the jobs are packaged. I noticed that our output was regularly smaller than the Poppler output, so possibly we are using more aggresive compression or something | 14:45.44 |
| tkamppeter | If I can reproduce the problem of that user on one of my HP's (please tell me the link to the bug) I could overtake the user's role in testing. | 14:45.49 |
| chrisl | tkamppeter: is that time spent on the printer, or time spent on the host producing the PS? | 14:46.43 |
| tkamppeter | chrisl, on the host already, but probably also on the printer. | 14:47.16 |
| chrisl | tkamppeter: well, it's pretty vital to know where the time is spent, if we ever want to look at it...... | 14:48.07 |
| | tkamppeter: the HP bug I was talking about was: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/998087 | 14:48.25 |
| tkamppeter | chrisl, thanks. | 15:01.13 |
| Robin_Watts | mvrhel: ping | 15:12.19 |
| kens | He was up pretty late | 15:12.32 |
| Robin_Watts | I thought that we should only ever get cmyk + spots from the gs psdcmyk device. | 15:13.01 |
| kens | Yes. | 15:13.13 |
| Robin_Watts | I'm getting RGB and greyscale ons. | 15:13.21 |
| | ones. | 15:13.24 |
| kens | Hmm, sounds wrong, but what do I know.... | 15:13.46 |
| mvrhel | Robin_Watts pong | 16:07.28 |
| | just got back from taking kids to school | 16:07.36 |
| Robin_Watts | np. | 16:07.40 |
| | I ran a bmpcmp earlier, and some files ended up with an error from bmpcmp saying "bmpcmp only supports CMYK psd files" | 16:08.21 |
| | and indeed, it looks like the psdcmyk device is producing some rgb and greyscale output pages. | 16:08.46 |
| mvrhel | oh when are you getting RGB and grayscale with that device | 16:08.50 |
| Robin_Watts | gs/debugbin/gswin32c.exe -sDEVICE=psdcmyk -r72 -o out.psd ../ghostpcl/tests_private/ps/ps3cet/29-07F.PS | 16:09.14 |
| mvrhel | oh some freaky ps cet test | 16:09.27 |
| | hmm assign a bug to me about this | 16:10.00 |
| | if you would | 16:10.06 |
| Robin_Watts | OK. I was assuming that it was actually a bmpcmp bug and that we should cope. | 16:10.33 |
| mvrhel | well *I think* | 16:10.59 |
| | the psdcmyk device was set up to be able to do rgb and cmyk | 16:11.13 |
| | both | 16:11.15 |
| | which seems odd to me | 16:11.19 |
| | and this is likely done by some setting of the process color model | 16:11.43 |
| Robin_Watts | But in digging to understand this, I've convinced myself that the bmpcmp code to read the CMYK values for the spot colors is broken and was never being triggered. | 16:11.45 |
| mvrhel | you cant have RGB + spots though | 16:12.07 |
| Robin_Watts | psd_write_16(xc, (bits16) xc->base_bytes_pp); /* Mode - RGB=3, CMYK=4 */ | 16:12.17 |
| chrisl | 29-07F.PS does a bunch of ProcessColorModel tests | 16:12.21 |
| mvrhel | yes | 16:12.25 |
| | so I need to take a look at this | 16:12.32 |
| Robin_Watts | That's outputting 1,3 (and more usually) 4. | 16:12.34 |
| mvrhel | especially with all the changes I did | 16:12.44 |
| Robin_Watts | I'm not seeing RGB + spots. | 16:12.45 |
| mvrhel | ok good | 16:12.52 |
| | well I need to go and test any RGB output cases to understand 1) what we want to do 2) if we are doing the correct thing | 16:13.16 |
| Robin_Watts | but I don't believe the code that's supposed to form a composite image by mapping the spot colors down onto it can ever have worked. | 16:13.25 |
| | Can you give me an example of a file that has CMYK + spot colors please ? | 16:13.57 |
| mvrhel | there is no composite mapping with CMYK + spots for psdcmyk | 16:14.17 |
| Robin_Watts | (I'm sure you've given me one before, but my memory is crap, as I may have mentioned) | 16:14.20 |
| | In bmpcmp there is supposed to be. | 16:14.29 |
| mvrhel | oh yes | 16:14.36 |
| | I see | 16:14.38 |
| | ok | 16:14.39 |
| | hold on | 16:14.43 |
| | let me get a simple one | 16:15.33 |
| | how about a file from tests/Ghent_V3.0 | 16:17.23 |
| Robin_Watts | any particular one ? | 16:17.40 |
| mvrhel | 080 | 16:17.45 |
| Robin_Watts | ok, thanks. | 16:17.52 |
| mvrhel | has CMYK + 2 spots | 16:17.53 |
| ray_laptop | mvrhel: the 29-07F sets the /ProcessColorModel | 16:17.57 |
| mvrhel | ray_laptop yes | 16:18.04 |
| | Robin_Watts: or 102 may be simplier | 16:18.47 |
| ray_laptop | and the psdcmyk device accepts some of the settings | 16:19.09 |
| mvrhel | ray_laptop: yes | 16:19.21 |
| | need to do a bit of checking to make sure everything is OK with this | 16:19.37 |
| ray_laptop | mvrhel: sorry -- the logs were behind when I started looking at the CET file. | 16:21.12 |
| mvrhel | no worries | 16:21.26 |
| Robin_Watts | mvrhel: So I'll open a bug and attach a list of the files I know of that work in this way? | 16:24.12 |
| mvrhel | Robin_Watts: that would be fine | 16:24.26 |
| | thanks | 16:24.28 |
| kens | Time for me to go. | 16:33.15 |
| | JUst before I do, Robin's changes to Memento allowed me to do much better leak testing of pdfwrite in 'server' mode, and it doesn't seem to leak at all. So I think that it is now ready to be talked about in the next release | 16:34.06 |
| | goodnight all | 16:34.13 |
| Robin_Watts | kens: (For the logs) Excellent! | 16:39.34 |
| ray_laptop | wonders if kens tested ps2write | 16:46.35 |
| | it should be the same, but ... | 16:46.49 |
| | Seems like it is time to have Avadhut try the pdfwrite device in server mode. | 16:48.47 |
| | mvrhel: BTW, did you try ps2write to make sure that it is faster than pswrite for his file ? | 16:49.12 |
| mvrhel | ray_laptop: working on that right this second | 16:50.53 |
| | in between getting my wife out the door as she is heading to her 20 year college reunion | 16:51.16 |
| Robin_Watts | mvrhel: 20 years since graduation or matriculation? | 16:53.52 |
| | Now you've made me feel old... | 16:54.59 |
| mvrhel | graduation.... | 16:55.14 |
| Robin_Watts | Ah, not so bad then :) | 16:55.54 |
| | Oh, wait. College = University in the states? | 16:56.27 |
| mvrhel | yes | 16:57.33 |
| Robin_Watts | OK, that's what I was thinking. | 16:57.52 |
| | We have '6th form colleges' here, which are like the last 2 years of high school. | 16:58.23 |
| mvrhel | ok | 16:59.07 |
| | Robin_Watts: quick git question for you | 18:02.58 |
| | trying to read this but a bit confused | 18:03.03 |
| henrys | thanks Robin_Watts I'll have a go with your new fill code a bit later. | 18:03.38 |
| Robin_Watts | mvrhel: go for it. | 18:03.49 |
| | henrys: I *think* it works. Certainly my postscript tests do what I expect now. | 18:04.06 |
| mvrhel | how do I reset my checkout to a particular hash id | 18:04.10 |
| | a hard reset to it | 18:04.22 |
| Robin_Watts | git checkout hash | 18:04.23 |
| mvrhel | that is | 18:04.24 |
| | ok there is no reset | 18:04.34 |
| Robin_Watts | A reset is something different. | 18:04.42 |
| mvrhel | thats my confusion | 18:04.46 |
| | gotcha | 18:04.50 |
| | hmm | 18:05.46 |
| | complaints about untracked working tree files | 18:05.56 |
| | the jbig files... | 18:06.03 |
| Robin_Watts | git reset --hard hash checks out hash, and then makes the current branch (e.g. master) point to it. | 18:06.05 |
| | rm -rf gs/jbig2dec | 18:06.21 |
| mvrhel | that is what I want I think | 18:06.24 |
| Robin_Watts | then git checkout | 18:06.25 |
| | so git reset --hard is very good for removing stray commits. | 18:06.44 |
| mvrhel | I basically want to go back to a older checkout for minute to do a timing test | 18:06.46 |
| Robin_Watts | Right, so you DO NOT want a reset. | 18:06.59 |
| henrys | I just had a stash conflict with jbig2 too. | 18:07.03 |
| Robin_Watts | Suppose your commit history is A<-B<-C<-D | 18:07.46 |
| | where master == D. | 18:07.52 |
| | if you want to go back to A to do a timing test, do: git checkout A | 18:08.11 |
| | if you did "git reset --hard A" then you'd effectively be throwing away B C and D. | 18:08.35 |
| | and master would end up being A. | 18:08.55 |
| mvrhel | ok I am where I want to be | 18:08.59 |
| Robin_Watts | You would have no trivial way to get back to D. | 18:09.01 |
| | cool. | 18:09.11 |
| mvrhel | Robin_Watts: so if I had done a reset then why could I not have gotten back to D from the master/origin? | 18:10.20 |
| Robin_Watts | Every stored state in git is a set of files, plus a pointer to 1 or more previous states, plus a commit message. | 18:12.09 |
| | A, B, C, D being such stored states. | 18:12.30 |
| mvrhel | I am worried that I may have done such a reset once in the past | 18:12.37 |
| | and then I don't recall how I got back | 18:12.53 |
| | but I wonder if I am missing any commits then | 18:13.00 |
| | or would things have exploded on me? | 18:13.07 |
| Robin_Watts | Listen to my explanation, and then ask questions if I'm not clear at the end. | 18:13.33 |
| mvrhel | my ears are open | 18:13.47 |
| Robin_Watts | So, I draw commit history as being: A<-B<-C<-D where <- indicates that the state pointed to is one of the parents. | 18:14.36 |
| | A merge will have 2 parent pointers. | 18:14.51 |
| | A 'branch' in git is just a record that maps a branch name to a given state. | 18:15.49 |
| | A tag is exactly the same. | 18:16.05 |
| | A branch doesn't contain the history of the commits done on that branch. It relies on us being able to find the history by walking backwards down the parent pointers. | 18:17.37 |
| | So, if our current branch is FRED and we commit to it, git makes a new copy of all the files, and our commit message, and makes the parent pointer point to where FRED currently points. Then it makes FRED point to that new state. | 18:19.04 |
| | If you do: git reset --hard hash then FRED will be set to point to hash. | 18:20.09 |
| | Suppose FRED pointed to D, and we git reset --hard A. | 18:21.41 |
| | That means we now have nothing in gits state that points to D anymore. | 18:21.55 |
| | git is free to garbage collect that away. | 18:22.05 |
| | Now, you can do: git reset --hard D and it'll reset FRED to point at D again (assuming it hasn't garbage collected it already) | 18:22.51 |
| | And if you forget D (or lose the piece of paper on which you scribbled it) you are in trouble. | 18:23.50 |
| | To avoid losing data, git tries not to garbage collect away any states for 30 days or so (I think that's a default setting). | 18:24.12 |
| | And you can dig around in the history of gits state changes using git reflog to try to discover D again, but it's best to be safe. | 18:24.52 |
| | If you do: git checkout A then it leaves FRED where it was, and just changes your working set of files back to A. | 18:25.33 |
| | This is referred to as detatched head state. (a 'head' is what git calls a branch - it means you're not on a branch). | 18:26.11 |
| | You can't commit whilst in a detached head state - you need to either make a new branch, or check back onto a branch first. | 18:26.48 |
| | Have I completely lost you, or does that make any sort of sense? | 18:27.00 |
| mvrhel | It seems a bit odd to me | 18:27.35 |
| | since if I were to be sitting at A and the head/origin is at D, I get all the commits to get there | 18:28.14 |
| | not sure how that would be different if I did a hard reset to A and then did the same to get to D | 18:28.42 |
| Robin_Watts | If you've checked out to A, then yes, FRED still points at D. | 18:28.50 |
| | that means that B C and D are still 'safe' and non-garbage collectable. | 18:29.21 |
| | If you reset to A, then FRED points at A. that means that B C and D are 'at risk'. | 18:29.50 |
| mvrhel | so now that I am sitting at A due to a checkout to A, how do I get back to D | 18:29.51 |
| Robin_Watts | git checkout master | 18:30.00 |
| mvrhel | ok | 18:30.05 |
| | how can B C and D be at risk if they are all in origin/master | 18:30.20 |
| Robin_Watts | If they are in origin/master they are safe. | 18:30.38 |
| | The worry is that they might be local commits that you haven't pushed anywhere else yet. | 18:30.57 |
| mvrhel | oh. I would never do a reset if I had commits that I had not pushed | 18:31.01 |
| | that I can see would be a problem | 18:31.11 |
| | and those could be lost | 18:31.14 |
| Robin_Watts | In SVN terms a git checkout is like an "svn update" | 18:31.23 |
| mvrhel | no | 18:31.35 |
| | I dont think of it that way | 18:31.39 |
| | I would say a git up is | 18:31.56 |
| Robin_Watts | Hmm. Have I got that wrong... | 18:32.01 |
| mvrhel | a pull and a rebase | 18:32.16 |
| Robin_Watts | In SVN if you want to temporarily change back to revision 123, what would you do ? | 18:32.21 |
| mvrhel | it has been too long since I fooled with that now | 18:32.57 |
| | my neurons have rewired to git thinking | 18:33.04 |
| Robin_Watts | I think it's something like "svn update 123" ? | 18:33.26 |
| mvrhel | yes there is an update to revision | 18:33.56 |
| Robin_Watts | doing a reset in those terms is like doing "svn revert" on every commit since the one you wanted. | 18:34.05 |
| mvrhel | yes | 18:34.19 |
| Robin_Watts | One other thing, and this may be the crucial factor in why to avoid "git reset --hard" | 18:34.51 |
| | When you git reset --hard hash, it will nuke all changes in your working set, without warning. | 18:35.29 |
| mvrhel | ok. My understanding of how this works I believe is correct. In my paranoia I never do any funny reset or checkouts when I have commits that I have not pushed or at least saved as a patch | 18:36.50 |
| Robin_Watts | git checkout hash warns if you would lose data, I think. | 18:36.59 |
| | That's probably not a bad approach. | 18:37.06 |
| | I *think* git checkout is safer than git reset as (unless you give it a specific file) it won't overwrite changes without prompting. | 18:37.55 |
| mvrhel | right | 18:38.11 |
| | thanks Robin_Watts | 18:41.53 |
| Robin_Watts | no worries. Not sure I helped really :( | 18:42.12 |
| mvrhel | Robin_Watts: you reinforced my paranoia | 18:44.12 |
| sebras | tor8: are you aware of the pro-version of this software? http://code.google.com/p/apv/ 8.5SEK on android market. | 19:02.52 |
| Robin_Watts | sebras: No. | 19:25.16 |
| | Both versions are open source and both are available at code.google.com/p/apv, but Pro version is not free on Android Market and it has more features. | 19:25.54 |
| | So, it could still be fine under the GPL. | 19:26.24 |
| sebras | Robin_Watts: yes it may, I just wanted to let you know about it. | 19:27.07 |
| Robin_Watts | ah, it's maciej. | 19:28.16 |
| sebras | since I don't know who are customers of artifex I can't really do more than notify you that there is someone using it. :) | 19:28.18 |
| Robin_Watts | he's on here sometimes. | 19:28.24 |
| sebras | oh..? under what nick? | 19:28.33 |
| Robin_Watts | maciej :) | 19:28.40 |
| sebras | ah. :) | 19:28.50 |
| Robin_Watts | he's not an artifex customer. he's just a GPL user. | 19:29.03 |
| | the pro version says: "APV PDF Viewer Pro is GPLv3 Free Software." | 19:29.29 |
| | so while it's odd to see people charging money for GPL stuff, it's not outlawed in any way. | 19:29.54 |
| sebras | no I know. I'm browsing the code to try to see if all of it is there or if something is missing for the pro-version. | 19:30.32 |
| | as far as I can see from a quick look it all seems to be there. :) | 19:32.33 |
| | http://goo.gl/GTVoR this one however, I can not locate the sources for. | 19:33.44 |
| Robin_Watts | AHAHAHAH! | 19:44.16 |
| | I know what causes the v8 linking problems. | 19:44.28 |
| sebras | Robin_Watts: spill! (not that I understand but it may make you feel better) :) | 19:45.03 |
| Robin_Watts | fitz.h fiddles with the definition of inline :) | 19:45.24 |
| | so including any header after fitz.h that uses inline causes problems. | 19:46.05 |
| sebras | yes, it may. | 19:46.25 |
| | maybe we should undefine inline at the end of fitz? | 19:49.20 |
| | or rather, define it back to what it used to be. | 19:49.34 |
| Robin_Watts | We can't define it back to what it used to be. | 19:53.24 |
| | I suspect the simple thing is just to include mupdf headers after all the C++ ones. That shouldn't be a problem. | 19:54.08 |
| | OR we should use fz_inline everywhere. | 19:54.16 |
| sebras | wouldn't this affect _all_ clients of mupdf that do #include <fitz.h> to get at our public interface? | 19:56.20 |
| | if so then it seems unreasonable to muck up the set of #defines that the rest of their code may depend upon. | 19:56.45 |
| Robin_Watts | yes. | 19:58.12 |
| tor8 | Robin_Watts: eh? we do all sorts of #ifdef tests for inline. oh well... | 20:23.22 |
| | oh... but the tests don't test for compiling *as* c++ which has inline in msvc | 20:23.49 |
| Robin_Watts | tor8: Yes. I suspect the correct thing to do is for us to move to use FZ_INLINE instead of inline, and to #define to that instead. | 20:32.28 |
| marcosw | sebras: If it's okay with you I'm going to reboot casper in a few minutes (you and I are the only ones logged on). | 20:46.32 |
| sebras | marcosw: sure, np. I'll log out and be back after some time... | 20:47.03 |
| | brb! | 20:47.13 |
| marcosw | casper is updated and back up. | 20:58.20 |
| sebras | marcosw: thanks for the heads up. :) | 21:02.54 |
| tor8 | Robin_Watts: no. never. the inline keyword is as good as standard, and I *HATE* macros for crap like that. next you'll be proposing FZ_INT32 etc as well... | 23:45.28 |
| | anyway, good night. :) | 23:45.43 |
| | Forward 1 day (to 2012/05/17)>>> | |
IRC Logs