| | <<<Back 1 day (to 2016/09/14) | 20160915 |
| sebras | fred (for the logs): in Page_enableSeparation() fz_control_separation_on_page() may fz_throw() and if it does there is no fz_catch() in Page_enableSeparation() to catch it which means we longjump to... somewhere..? :) | 04:01.35 |
| | fred (for the logs): the same with Page_getSeparation() and fz_get_separation_on_page() | 04:02.29 |
| | fred (for the logs): I'll fix those. | 04:03.26 |
| | fred: I'm also wondering about the LOGI calls. are they just there for your current debugging session or are they necessary long term? because no other JNI-function have them right now. | 04:04.36 |
| | fred: in Page_getSeparation() the global ref to the Separation was never deleted like with the other classes in lose_fids() which gets called as part of JNI_OnUnload(). | 04:16.55 |
| | also NewStringUTF() may fail with NULL (and a stored exception) and we'd better not call any other JNI-interface, but rather just returning | 04:17.42 |
| | fred: Separation.rgba should really be called Separation.bgra right? because you convert it in Page_getSeparation() | 04:18.29 |
| | fred: when are those temporary files created by make_tmp_gproof_path() removed? | 04:35.47 |
| | fred: it seems to me that only the app knows when those should can be removed safely. so I'm thinking that maybe the app could create the file and just give us an java.io.OutputStream (possibly java.io.FileOutputStream if we care about that it goes into a file) that we write to? | 04:36.56 |
| | do we ever save the proofing document? if not, how about using a java.io.ByteArrayOutputStream and avoid creating a file all together? | 04:42.49 |
| | fredross-perry: I've seen a few problems with the commits you pushed yesterday. | 05:42.21 |
| fredross-perry | for example? | 05:42.35 |
| sebras | fredross-perry: fz_*() often throw exceptions, but those are different from java exceptions. | 05:42.59 |
| | so you must do fz_try(){}fz_catch(){} and convert the exception to a java exception. | 05:43.23 |
| | fz_control_separation_on_page() may throw, but Page_enableSeparation() has no fz_try{}. | 05:43.51 |
| | same with fz_get_separation_on_page(). | 05:44.05 |
| | also NewStringUTF() may return NULL and throw a Java exception, in which case we want to return as soon as possible | 05:44.34 |
| | the self pointer need not be checked since the JVM will not call a JNI binding on a null pointer. | 05:44.56 |
| | the pattern is to throw IllegalArgumentException upon null arguments | 05:45.20 |
| | so, jni_throw_arg() rather than jni_throw() | 05:45.41 |
| fredross-perry | If you can point me to functions that follow the correct patterns, I'll make adjustments, thanks. | 05:46.11 |
| sebras | the global ref to the Separation class is acquired in Page_getSeparation() but never freed (should be in lose_fids()) | 05:46.23 |
| | fredross-perry: I have a few patched almost being ready here. :) | 05:46.57 |
| fredross-perry | SO you're handling this then? | 05:47.19 |
| sebras | fredross-perry: do you want to review them? | 05:47.19 |
| fredross-perry | Sure when you're done. | 05:47.33 |
| sebras | fredross-perry: I can, but I think it is good if you review them in preparation for next time. :) | 05:47.56 |
| fredross-perry | I will review them. But it's late here, so tomorrow. | 05:48.22 |
| | thanks | 05:48.24 |
| sebras | fredross-perry: one design decision that I'm stumped by though: can we have makeProof take a ByteArrayOutputStream? | 05:48.32 |
| | fredross-perry: since the proof document is temporary anyway there, is there any need to actually save it on disk? | 05:48.55 |
| | that way we can avoid creating those pesky paths. | 05:49.04 |
| | but I'm not sure if doing this makes sense. maybe we'll run out of memory. are they big? just for one page or many? | 05:49.40 |
| fredross-perry | Are you talking about the files like gprf_0_xxxxxxxx? | 05:51.16 |
| | This is all lifted form the previous incarnation of proofing. | 05:51.46 |
| sebras | yes. I know, I found the old code. | 05:52.21 |
| | I'm just wondering if we want to change it while we are rewriting it anyway..? | 05:52.35 |
| | how are proofing files used? | 05:52.58 |
| | looks like you hit the proof button in the old viewer and then view the proofing of that file (just one page?) and then the file is thrown away. | 05:53.33 |
| fredross-perry | I'd rther do it in two steps, (1) fix the JNI issues, and then (2) address your concern here. We've got a demo of this coming up for the show. | 05:53.35 |
| sebras | do we intend to save the proofing files later on? | 05:53.44 |
| | fredross-perry: I'll definitely fix (1). :) | 05:54.31 |
| | fredross-perry: (2) is more of a question. also I have no idea about the show or when it is. | 05:54.49 |
| fredross-perry | the path is created and handed (I believe) to gs to actually make the file. Then some other files are created by the gprf device that contain each page. At the end they are all thrown away. | 05:54.51 |
| | The show is right before the upcoming meeting in Orlando. We can tackle (2) after that. | 05:55.20 |
| sebras | fredross-perry: right, since I'm not attending the Orlando meeting maybe I have missed that info. | 05:55.42 |
| fredross-perry | sure. | 05:55.48 |
| sebras | fredross-perry: ok, I'll let you know when I'm done. | 05:55.58 |
| fredross-perry | thanks. | 05:56.05 |
| sebras | fredross-perry: the devil is in the details in the JNI error handling. ;) | 05:56.10 |
| fredross-perry | I imagine. | 05:56.19 |
| sebras | fredross-perry: I created a small patch series over at sebras/master | 06:10.34 |
| fredross-perry | thanks, i'll look tomorrow | 06:10.51 |
| sebras | np. | 06:21.06 |
| | https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369#.bnnug8i6g seems similar to multiple master fonts. | 06:40.45 |
| | tor8 (for the logs): there's a patch for BufferInputStream on sebras/master | 07:51.34 |
| | tor8: I've been thinking about the InputStream interface suggesting to use NullPointerException for the byte array being null. the same is surprisingly not true for OutputStream! both NPE and IAE are RuntimeExceptions so I'm thinking that the difference is very minor. | 07:53.43 |
| | tor8: I believe that this makes the Streams and Buffer things well behaved. | 07:57.16 |
| | chrisl: awake? | 08:18.45 |
| | chrisl: in 2013 you merged an updated version of luratech for j2k. | 08:19.14 |
| | chrisl: do you still have their original delivery available? | 08:19.26 |
| | chrisl: since I'm looking into mergeing their latest drop I want to see what you did. | 08:19.58 |
| | chrisl: if I have access to that old file it is easier to determine what changes luratech did and just merge those without losing any changes we've done ourselves. | 08:21.39 |
| chrisl | sebras: No, sorry, I don't have the original. Is the record of what's done not in the repo? | 08:23.17 |
| | Is it still in subversion, or did we move it to git? | 08:24.04 |
| sebras | chrisl: yes, but just unpacking their drop is not enough, then we'll lose any changes we did. | 08:24.07 |
| | chrisl: moved to git! :) | 08:24.13 |
| | I think tor did that last time. | 08:24.22 |
| chrisl | Actually, there was an update that I added in 2014 as well..... v1.12 (Aug 2014) | 08:27.10 |
| sebras | chrisl: are we talking about commit 6e589f2 in the git repo? | 08:27.51 |
| | that one's dated 2013. but it does reference jp2k 2.12. | 08:28.05 |
| chrisl | Urm, I don't have it in git locally, I still have the subversion one, give me a minute..... | 08:28.24 |
| kens | I don't see an August 2014 luratech commit in Git | 08:28.56 |
| chrisl | Date: Fri Aug 22 07:47:53 2014 +0000 - commit e56fd4d7a29958b7cb41db4f36d565d457f369f2 | 08:30.26 |
| | So there's the "inline" fix, and the gcc 5.x fix | 08:31.00 |
| kens | Gitweb isn't showing any commit on that date for me :-( | 08:31.42 |
| sebras | chrisl: ah, right, but that wasn't a complete code drop. | 08:31.48 |
| | kens: I think this is in svn..? | 08:31.58 |
| kens | Oh OK | 08:32.02 |
| chrisl | No, this is in git | 08:32.05 |
| kens | THen, I still don't see it in gitweb :-(( | 08:32.28 |
| | Not that it matters | 08:32.33 |
| chrisl | The newest comit is 8b812c1f16b21 made by Marcos May 25 2016 | 08:32.42 |
| sebras | chrisl: right I see it, but that's jb2, not jp2k. | 08:32.47 |
| kens | Its till Luratech though ? | 08:33.04 |
| sebras | chrisl: I'm refering to jp2k. :) | 08:33.04 |
| | kens: yes, but I have only got a jp2k drop to merge, nothing for jb2. | 08:33.26 |
| kens | Huh, I thought it was all the same library. Oh well | 08:33.45 |
| sebras | kens: there are two subdirectories and they appear to be versioned independently I think. | 08:34.03 |
| chrisl | I'm not sure how gitweb works with a completely private repo...... | 08:34.16 |
| kens | I guess badly is the answer, or possibly I can't drive it properly, which is possibly more likely the case. | 08:34.57 |
| | Anywya, just ignore me | 08:35.16 |
| chrisl | sebras: but I | 08:35.33 |
| | oops, sorry | 08:35.38 |
| sebras | chrisl: either way you don't have that jp2k drop either. | 08:35.40 |
| | I was hoping that you'd have an old e-mail or something. | 08:35.54 |
| chrisl | sebras: what version of jp2k is currently in there? | 08:35.54 |
| sebras | chrisl: 2.1.00.12 (apr 2012) | 08:36.27 |
| | chrisl: and jb2 is 1.12 (aug 2014) but that's not important | 08:37.07 |
| chrisl | They'v always come to me via HenryStiles | 08:37.37 |
| sebras | chrisl: same for me, but since you committed it last time I was hoping you'd still have the drop. :) | 08:39.02 |
| chrisl | sebras: the way I work with the libraries like luratech is that I commit the original drop, then reapply any of our changes afterwards (sometimes on a branch), so the source control keeps a record of what we've done | 08:41.47 |
| | So it looks like you need to reapply commit 94511dd7eb22d4 | 08:42.28 |
| | And possibly also 8b812c1 | 08:43.12 |
| | Actually, no, not 8b812c1 as that appears to only relate to JB2 | 08:45.07 |
| sebras | chrisl: ah, ok. I see. | 08:45.22 |
| | chrisl: I was under the impression that the code drop merged whatever was in the repo previously too. | 08:45.42 |
| chrisl | sebras: sometimes it does. The two change sets mentioned in 94511dd are specific to our use of the luratech JP2k decoder | 08:46.41 |
| sebras | chrisl: so basically I can import the drop in a commit and then cherry-pick 94511dd "Bug 694358: re-apply two fixes." in order to not end up in the same situation as you did. | 08:53.42 |
| | chrisl: do I need to squash the drop and the cherry-picked commit into one? | 08:53.56 |
| chrisl | sebras: I wouldn't bother for the closed source libs, no | 08:54.44 |
| sebras | chrisl: ok. | 08:54.53 |
| chrisl | sebras: for the open source libs on Ghostscript, I tend to do the reapplying of our patches on a branch, and squash it onto master (so the branch keeps the record of the changes, but master always works) | 08:55.43 |
| | Forward 1 day (to 2016/09/16)>>> | |
IRC Logs