| | <<<Back 1 day (to 2016/01/10) | 20160111 |
| Robin_Watts | Morning kens. Good break? | 10:32.25 |
| kens | Hi Robin, yes very nice thanks | 10:33.39 |
| | Now wading through email..... | 10:33.50 |
| Robin_Watts | kens: I did a load of warning squashing commits last week. All over the code. | 10:47.47 |
| kens | I know :-( | 10:47.53 |
| Robin_Watts | One or two bits in pdfwrite etc, so feel free to yell at me if I cocked them up. | 10:48.05 |
| kens | I have an awful lot of reading to do | 10:48.10 |
| | At least its pdfwrite, not the PDF interpreter | 10:48.35 |
| Robin_Watts | tor8: Hey. | 11:14.11 |
| | I updated robin/jni2 with the latest version. See what you think. | 11:14.35 |
| tor8 | Hi. Let me take a look. | 11:14.42 |
| | Robin_Watts: yes, that looks nicer. | 11:18.56 |
| | why the ctx null test? | 11:19.10 |
| | why clone path and text? we have reference counting for them. | 11:20.02 |
| Robin_Watts | which ctx null test? | 11:20.32 |
| tor8 | if (ctx == NULL) | 11:20.42 |
| | return NULL; | 11:20.42 |
| | in every jni method | 11:20.42 |
| Robin_Watts | ah, right. | 11:20.58 |
| | If you look at the 'get_context' function... | 11:21.08 |
| | It is conceivable that fz_clone_context may fail (due to lack of memory) | 11:22.08 |
| tor8 | yes...? | 11:22.08 |
| Robin_Watts | hence get_context can return null. | 11:22.17 |
| | The typical pattern of use is that we do: | 11:22.27 |
| | fz_context *ctx = get_context(env); | 11:22.35 |
| tor8 | right. and should we not throw a java exception in that case? | 11:22.41 |
| | that still won't break out of the control flow though | 11:23.00 |
| Robin_Watts | fz_blah *blah=fz_blah_from_Blah(env, jblah); | 11:23.04 |
| | etc. | 11:23.06 |
| | oops. | 11:23.12 |
| | fz_blah *blah=fz_blah_from_Blah(env, ctx, jblah); | 11:23.16 |
| | so all the fz_blah_from_Blah stuff needs to cope with a null ctx. | 11:23.35 |
| tor8 | yeah, I see now | 11:23.55 |
| Robin_Watts | Yes, we should throw a java exception. BUT the way java exception throwing from JNI works, it just sets a flag and so we still have to exit cleanly. | 11:24.07 |
| | But I'll fix it to throw an exception. | 11:24.18 |
| tor8 | ugh, do you really have to spell this and class with z? I'd rather use synonyms or something... | 11:24.21 |
| Robin_Watts | tor8: That's "convention" I think. | 11:24.35 |
| tor8 | I'd use "self" rather than "thiz"; I think that's just as much based on tradition :) | 11:25.08 |
| | the class objects (all the FindClass calls) should probably be cached somewhere too | 11:25.22 |
| Robin_Watts | I have no strong feelings, so sure. | 11:25.26 |
| tor8 | and global refs made | 11:25.27 |
| Robin_Watts | caching class objects means ensuring we handle refs properly. | 11:25.43 |
| tor8 | iirc FindClass returns a local ref | 11:25.59 |
| Robin_Watts | it does. hence doing 'FindClass' each time is easy. | 11:26.14 |
| | caching them means we have to explicitly take global refs and clean them all up when we exit. | 11:26.45 |
| | Let's leave that for if we have performance problems. | 11:27.11 |
| tor8 | which we can turn into a global ref with (*env)->NewGlobalRef(env, obj); | 11:27.15 |
| | and then delete at UnLoad time | 11:27.19 |
| | but sure, that's something we can trivially do later | 11:27.39 |
| Robin_Watts | Any suggestions for 'clazz' replacement ? | 11:28.49 |
| tor8 | clazz -> class_Path (or Path_class or Path_cls to match the _mid and _fid suffixes) | 11:29.46 |
| Robin_Watts | ok. | 11:30.21 |
| | will do those cleanups now. | 11:30.27 |
| tor8 | the currentPoint and bound methods could use Rect_from_fz_rect and point helpers | 11:31.43 |
| | I wonder if we could do a varargs like constructor thing | 11:32.28 |
| | but probably best to just make them typesafe | 11:33.16 |
| | I would make fz_rect_from_Rect return fz_rect rather than fill out a pointer, then it can live up with the pointer extractions at the variable declaration blocks | 11:34.59 |
| | fz_rect rect = fz_rect_from_Rect() | 11:35.24 |
| | I'm not convinced about having a destroy method at all, but if we do why not just implement it in java? (either call finalize() from destroy, or vice versa) | 11:36.50 |
| Robin_Watts | yeah. makes the code nicer. | 11:36.58 |
| | Ah, I just moved away from that :) | 11:37.15 |
| | Having a destroy as well as a finalize is considered good practice, cos it can take a long time for finalize to get called. | 11:37.45 |
| | So for things that have significant underlying data (such as most of our fz_structures), it's good form to have a 'destroy'. | 11:38.15 |
| | And if we have destroy for some, it's easiest for consistency to have it for all. | 11:38.29 |
| tor8 | I can live with that, though I think it's still dangerous and un-java-like. | 11:38.50 |
| | still, destroy implemented natively, why not just public void destoroy() { finalize(); nativeColorSpace = 0; } in java? | 11:39.15 |
| Robin_Watts | I would be quite happy to have destroy be implemented in java by calling finalize and nulling the private data. | 11:39.16 |
| | I just moved to doing it all in C, because I thought we were trying to make the java stuff as empty as possible. | 11:39.41 |
| | destroy is an "extra" thing that people can call if they are concerned about performance. | 11:40.12 |
| tor8 | well, yes. but I think some of the java stuff can still be reasonable to implemented in java. | 11:40.23 |
| | we could add some nice constructors with overloading etc | 11:40.36 |
| Robin_Watts | Everything will work OK if they don't call it, just at the potential cost of performance etc. | 11:40.39 |
| | Android bitmaps work in exactly this way, as do other things (though don't ask for me an example off the top of my head) | 11:41.02 |
| tor8 | Okay. I believe you. | 11:41.26 |
| Robin_Watts | tor8: Yes, I have some stuff in path.java that allows stuff to be called with Points or explicit floats. | 11:41.48 |
| tor8 | yes. exactly that kind of stuff I was thinking of :) | 11:42.10 |
| Robin_Watts | Ok, so move back to having finalize() as native, and destroy as a java wrapper. | 11:42.24 |
| | self, and class. | 11:42.31 |
| | and Rect_from_fz_rect etc. | 11:42.43 |
| tor8 | PathProcessor -> PathIterator or PathWalker? | 11:43.48 |
| Robin_Watts | Iterator suggests that the caller is responsible for prodding it to iterate, to me. | 11:45.10 |
| | I prefer Processor to both those names, personally. | 11:45.37 |
| tor8 | yeah, I was just thinking that as soon as I typed it. walker seems more accurate and more to the point than the rather generic process, to me. | 11:45.38 |
| | but I can live with processor if you insist | 11:45.50 |
| Robin_Watts | Walker suggests that the thing that is being called does the walking. | 11:46.02 |
| | whereas it's the opposite way round. | 11:46.19 |
| | Something walks the path, and you process the path segments. | 11:46.29 |
| | PathSegmentProcessor would be better, but that's too long. | 11:46.38 |
| tor8 | our path structs are really set up for 'pull' processing are they? | 11:46.45 |
| | are *not* set up | 11:46.51 |
| Robin_Watts | tor8: It would be tricky to 'pull' a segment at a time out. | 11:47.26 |
| tor8 | so an iterator first/nextPathSegment() wouldn't be easy to implement | 11:47.26 |
| Robin_Watts | Indeed. | 11:47.30 |
| | I have a feeling the internal name is fz_path_processor for the equivalent in the C. | 11:47.54 |
| tor8 | fair enough. java has anonymous inner classes, and lambda style things so this will be good enough | 11:48.01 |
| | ah yes, it is. | 11:48.15 |
| | fz_path_processor | 11:48.19 |
| | let's keep the name then | 11:48.32 |
| | Robin_Watts: one final thing, before I let you go... how do you feel about putting this jni code in a different directory | 11:50.08 |
| | like platform/java or source/java | 11:50.16 |
| | and add some make targets to build it for desktop java | 11:50.33 |
| | I see Image.java has hard coded a reference to android.graphics.Bitmap | 11:50.50 |
| Robin_Watts | Yeah, though nothing is actually coded from that yet. | 11:54.42 |
| tor8 | the *DrawDevice's take 4 arguments per rect rather than a Rect() | 11:54.49 |
| Robin_Watts | we could have AndroidImage derived from Image, probably. | 11:54.53 |
| tor8 | we don't have a Pixmap yet either | 11:55.06 |
| | AndroidPixmap extends Pixmap, and new Image(Pixmap pix) would match what our C stuff does better I think | 11:55.27 |
| Robin_Watts | yeah. | 11:55.33 |
| tor8 | for desktop java, I think just the int array is the only way to get/write raw RGB data using AWT/Swing | 11:56.03 |
| | I'd be perfectly okay with just copying the pixmap samples to an array of ints/bytes as accessor for the desktop version | 11:56.40 |
| | and not have any actual AWT dependencies in our code | 11:56.48 |
| | and #ifdef the android stuff, and keep the android specifics to limited classes | 11:57.01 |
| | do you test this stuff using android? | 11:57.26 |
| Robin_Watts | Yeah. The AwtDrawDevice/AndroidDrawDevice thing is my first attempt/nod at that. | 11:57.27 |
| | I do. | 11:57.33 |
| | I *did* have this all working with the android app. | 11:57.44 |
| | but it's crashing at the moment. I'll make all these changes, and try and get that sorted. | 11:58.00 |
| tor8 | I suspect it'd be faster to do with desktop java, but that's just me having issues with the android dev kit and usb cables | 11:58.04 |
| Robin_Watts | tor8: I'm well set up for android dev now cos of SOT. | 11:58.20 |
| tor8 | I was thinking if we can get this building on desktop java as well, I could make a simple AWT-based viewer demo just to test that things are working | 11:58.43 |
| | (unless you feel like doing that too) | 11:58.48 |
| Robin_Watts | tor8: That sounds like a good idea. | 11:59.02 |
| tor8 | right. my android dev isn't working. bloody stupid 64-bit sdk still requires 32-bit linux. | 11:59.20 |
| Robin_Watts | but let me get it working on android first, otherwise we'll be tripping over the same bugs. | 11:59.24 |
| tor8 | yes, of course | 11:59.31 |
| Robin_Watts | cool. | 11:59.37 |
| | tor8: Oh, you asked about why clone path. | 12:39.11 |
| | Suppose I interpret a PDF page to get a displaylist. | 12:39.22 |
| | And I run that displaylist to a java device. | 12:39.34 |
| | The java device gets passed Paths made from fz_paths. | 12:40.14 |
| | If the java author tries to modify the path, it will alter the path that it was called with. | 12:40.46 |
| | There is no 'const' in java. | 12:40.51 |
| | Hence I clone paths before passing them to the java. | 12:41.08 |
| | The alternative is to have a 'const' flag pickled into the Path object and have things like "moveTo" refuse to do anything if const is set. | 12:41.58 |
| tor8 | Robin_Watts: there is no const like that in C either... | 12:42.12 |
| Robin_Watts | tor8: Is too. | 12:42.27 |
| | In C you have pass by value and pass by reference. | 12:42.39 |
| tor8 | in fact, I've been thinking of adding a 'freeze()' method to fz_path and text and throw exceptions if you try to call moveto etc | 12:42.42 |
| Robin_Watts | In java you only get by reference effectively. | 12:42.54 |
| tor8 | we don't pass fz_path as const in c | 12:43.13 |
| Robin_Watts | Well, that's a bug, arguably. | 12:43.29 |
| tor8 | even so, the 'const' in c is very limited in what it protects | 12:44.05 |
| | it doesn't go further than one level of pointerness | 12:44.12 |
| Robin_Watts | Could we make fill_path etc take a const fz_path ? | 12:44.23 |
| tor8 | isn't 'final' in java pretty much the same as c's const? | 12:44.24 |
| | we could try | 12:44.32 |
| | but I think adding a fz_freeze_path/text call would be a decent compromise for safety | 12:44.48 |
| Robin_Watts | tor8: Not AIUI. | 12:44.49 |
| | final Blah fred means, that the value of fred will never change during the scope of the final. | 12:45.10 |
| | so int foo(final Blah fred) { .... } means that the value of fred won't change during the execution of foo. | 12:45.37 |
| | It doesn't mean that you can't do fred.bibble(); | 12:45.47 |
| tor8 | yeah, final in java is like "char * const p;" rather than "const char * p" | 12:45.47 |
| | it protects the reference, not the pointed to data | 12:45.57 |
| Robin_Watts | Right. | 12:46.01 |
| | C is closer to what we want. | 12:46.14 |
| | So that's why I'm cloning the path. | 12:46.29 |
| tor8 | I think passing as const is not going to work with the reference counting though | 12:46.35 |
| Robin_Watts | We can revisit that in future if we think there is a better way. | 12:46.43 |
| | tor8: Ah, yes. Unless we allow the reference counter to break const. | 12:46.58 |
| tor8 | I think we should add fz_freeze_path rather than clone | 12:46.58 |
| | not only the reference counter, but the eventual dealloc as well | 12:47.38 |
| Robin_Watts | tor8: It can be done in the java rather than needing the C to change. So we should only add fz_freeze_path if we think there are benefits for it in and of itself. | 12:47.42 |
| | tor8: The dealloc only happens via the ref coutner. | 12:48.02 |
| | It would mean adding the union { const blah c; blah u } u dance to the ref counter. | 12:49.13 |
| | which never actually costs us anything in terms of performance. | 12:49.28 |
| tor8 | I don't think that union would work | 12:49.59 |
| | const fz_path *path still means the union itself is const from the outside | 12:50.10 |
| | we'd have to un-const the fz_path for refcounting | 12:50.38 |
| Robin_Watts | union { const fz_path *c; fz_path *u;) u; u.c = const_path; then operate on u.u ? | 12:53.08 |
| | That could be added to fz_drop_storable, etc. | 12:53.38 |
| | That way fz_keep_storable and fz_drop_storable could always take const fz_storable *'s. | 12:54.02 |
| | So 'const' would mean (to us at least) that the internals of the structure aren't messed with (other than for reference counting), which is arguably a more useful definition than C's. | 12:54.59 |
| tor8 | the contents of the array pointed to by path->coords is still not protected | 12:55.42 |
| | const in c falls down for complex data structures, I'd rather avoid it | 12:56.04 |
| Robin_Watts | tor8: At best const in C is a 'statement of intent' rather than a guarantee. | 12:56.59 |
| | We can make it so that fz_moveto(path, x, y); still takes the non-const version. It makes it clearer to a caller that he's doing something wrong if he has to ignore a warning about passing a const thing there. | 12:58.05 |
| | I think for what we want, it might work quite well. | 12:58.24 |
| | If I get bored with the JNI stuff (or need a break) I might have a fiddle, and we can see how it looks. | 12:58.41 |
| tor8 | sure. | 12:59.06 |
| | I'd just add the const-uncasting in the fz_storable call without invoking unions | 12:59.26 |
| | but that's a minor quibble of implementation details | 12:59.34 |
| | if we can get const into the functions without too much pain I think that would be worth having, if it works well | 12:59.49 |
| Robin_Watts | tor8: The problem with const-uncasting in fz_storable without unions is that *every* bloody C compiler whinges (rightly) | 13:00.23 |
| tor8 | not with the explicit cast, unless my memory is totally failing this monday | 13:00.58 |
| Robin_Watts | tor8: even with the explicit cast (with the same proviso ;) ) | 13:03.51 |
| tor8 | Robin_Watts: neither gcc nor clang warn about explicit casting away a const, with -Wall -Wextra | 13:09.28 |
| Robin_Watts | tor8: MSVC ? | 13:09.40 |
| tor8 | #include <stdio.h> | 13:09.46 |
| | int main() { | 13:09.47 |
| | const char *a = "hello"; | 13:09.47 |
| | char *b = (char*)a; | 13:09.47 |
| | return printf("%s", b); | 13:09.47 |
| | } | 13:09.47 |
| Robin_Watts | My memory is that I've always had to do the union dance to shut *something* up. I forget which something. | 13:10.22 |
| tor8 | Robin_Watts: all the (colorspace, color, alpha) triplets in the device interface | 13:15.23 |
| | wrap them up in a Color class? | 13:15.29 |
| Robin_Watts | That might be nicer, yes. | 13:15.53 |
| tor8 | new Color(ColorSpace colorspace, float[] color, float alpha) | 13:15.57 |
| | maybe even unpack the color into plain fields | 13:16.25 |
| | to avoid that extra array | 13:16.35 |
| Robin_Watts | plain fields? | 13:16.45 |
| | c0,c1,c2,c3,c4.. c31? | 13:17.00 |
| tor8 | class Color { ColorSpace colorspace; float c0, c1, c2, c3; float alpha; } | 13:17.02 |
| Robin_Watts | ick. | 13:17.03 |
| tor8 | yeah | 13:17.03 |
| Robin_Watts | grabs some lunch. got to take dog to vets after that. bbl. | 13:19.24 |
| | back for a bit. | 14:06.52 |
| kens | Robin, commit 240b8f the change in gdevpsds.c | 14:09.00 |
| | You've only altered (I think) one case where n is 'unused' | 14:09.16 |
| | Was that deliberate ? Am I missing something ? | 14:09.25 |
| | Diff is: | 14:09.39 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=blobdiff;f=devices/vector/gdevpsds.c;h=5f57f34660f5ee683eb48d01a8968848a5892f5b;hp=5292cdf81aa54ef610161f22fa05684e1c4e6c84;hb=240b8f048945a129aacb1e84c7e7b66cf0d5bff1;hpb=8db551f3a3e949035889fcb63188764ca61ab8c1 | 14:09.39 |
| | That seems to be the s_16_8_process case, but the s_12_8_process case immediately above seems the same | 14:10.18 |
| Robin_Watts | kens: That was the only one that the compiler warnings were complaining about. | 14:10.23 |
| | unless I misread. | 14:10.27 |
| kens | I can't comment on the compiler warnings, but the code (and tehj misuse comment) is the same | 14:10.48 |
| | If 'n' was unused in the second case, it should also have been unused in the first | 14:11.13 |
| | Ah no actually I see it now | 14:11.25 |
| | n is acxtually used in the body there | 14:11.34 |
| Robin_Watts | ah, cool. | 14:11.59 |
| kens | says horrible macro crap, remove it all, grumble, grumble.... | 14:12.57 |
| Robin_Watts | kens: yeah. | 14:14.19 |
| | We should do Macro-removal-february. | 14:17.07 |
| | Every developer needs to remove at least 1 macro from gs a day. | 14:17.19 |
| chrisl | Speaking of horrible crap, any complaints about this: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=d43e2ebb ? | 14:17.42 |
| Robin_Watts | Having reviewed the commit message - no :) | 14:18.09 |
| kens | I can't see any reason to object | 14:18.17 |
| | I'm not going to read them all :-) | 14:18.24 |
| chrisl | I'd be shocked if anyone did! | 14:18.46 |
| kens | So was (void)n; better than n=n; ? | 14:23.11 |
| chrisl | gcc warns with n=n | 14:24.49 |
| kens | THe reason I ask is that Robin did some commits with n=n and then later did some commits with (void)n; but didn'[t change the earlier ones | 14:25.14 |
| | (In at least one place) | 14:25.26 |
| Robin_Watts | kens: I did change the earlier ones (or I meant to) | 14:25.32 |
| kens | The one I'm referring to is the one in that commit earlier :-) | 14:25.47 |
| kens | goes to check it again | 14:26.03 |
| Robin_Watts | kens: After a few days my eyes glazed over, so it's possible I missed something. | 14:26.31 |
| chrisl | I feel "n=n" risks being mistaken for a typo/error, of the type Robin spotted in the truetype code | 14:26.38 |
| kens | Its also possible I haven't reached that commit yet..... | 14:26.50 |
| Robin_Watts | n=n; is also subject to some compiler or other whinging (which is the big reason I changed it) | 14:27.12 |
| kens | Yes, I read the commit comment, but unless I haven't reached another commit, then aty least one case was left untouched | 14:27.40 |
| | I'll keep looking | 14:27.46 |
| | I also have not yet pulled from the repository as its going to be a royal pain to update at least one of my branches with all these changes | 14:28.19 |
| Robin_Watts | takes dog to vets. bbs. | 14:28.32 |
| kens | OK you fixed it in a later commit (I just reached it) | 14:30.30 |
| Robin_Watts | :) | 15:36.50 |
| kens | But I'm concerned by the commit that rremoves the GC descriptor for the txtwrite structure | 15:37.16 |
| | I seem to recall that's required | 15:37.26 |
| | Can you remember what caused you to remove it ? | 15:37.40 |
| Robin_Watts | If it's required, it should probably have been used somewhere :) | 15:37.47 |
| kens | Hmm..... | 15:37.58 |
| Robin_Watts | It was unused. | 15:38.02 |
| kens | Its a macro | 15:38.13 |
| | which defiens two routines, amongst other things | 15:38.37 |
| Robin_Watts | kens: I am aware of that. | 15:42.02 |
| | neither of which was used. | 15:42.09 |
| kens | I know that | 15:42.14 |
| | But I believe the finalize is required | 15:42.22 |
| | THat's why it uses add_final_0 | 15:42.30 |
| Robin_Watts | It defines 2 routines, and a struct st_thingy with pointers to those routines. | 15:42.35 |
| kens | Instead of a more normal macro | 15:42.44 |
| chrisl | How do you know they weren't used? | 15:42.44 |
| kens | THey really weren't | 15:42.54 |
| | There are no pointers to track | 15:43.01 |
| Robin_Watts | Cos the compiler warning told me :) | 15:43.04 |
| | (specifically it told me that st_thingy was unused, and when I removed it, nothing failed to compile). | 15:43.30 |
| chrisl | Ah, so that construct is only used because it needs the finalize | 15:43.42 |
| kens | grr network hiccup | 15:44.01 |
| | As I was saying..... | 15:44.11 |
| | according to my (very imperfect) memory, the macro adds a finalize ot the structure, and as I recall, that is required in this case | 15:44.44 |
| | Which is why it uses the highly unusual macro that it does (or rather, did) | 15:45.04 |
| chrisl | Yeh, I think we discussed this: we don't have a way to *just* add a finalize | 15:45.38 |
| kens | now that the logs have cauhgt up..... | 15:46.03 |
| | yes, the macro adds a finalise which we *do* need | 15:46.14 |
| | It also adds two routines we *don't* need | 15:46.23 |
| | If you remove the finalize bad things will happen (I thnk) | 15:46.39 |
| | The fact that it compiles doesn't prove its right in this case | 15:47.00 |
| | Nor does a cluster test, because we don';t test the txtwrite device on cluster runs | 15:47.15 |
| | I really think you should put that back | 15:47.24 |
| Robin_Watts | I'm struggling to understand this. | 15:47.24 |
| chrisl | Possibly the two not needed routines could be just NULLs? | 15:47.36 |
| kens | Well the macro specifically adds them | 15:47.48 |
| | I admit its been some considerable time since I did this, and my memory is more than usually hazy on the subject | 15:48.21 |
| Robin_Watts | Either there is a reference to the finalise routine, or there isn't. | 15:48.47 |
| kens | The finalize is in the 'procs' structure | 15:48.58 |
| | Which can be referenced, or set to 0 | 15:49.05 |
| | If its 0 we don't call the finalize routine | 15:49.17 |
| Robin_Watts | If there isn't a reference, then it wasn't doing anything, and removing it can't hurt. If there is a reference, then it would fail to compile. | 15:49.19 |
| | I never changed the procs structure though. | 15:49.26 |
| kens | The macro does, I believe | 15:49.36 |
| | As Chris says above we don't have a macro to simply add a finalize | 15:49.51 |
| Robin_Watts | kens: OK, can you point me at the commit please, so I can double check ? | 15:49.53 |
| kens | 1 moment | 15:50.00 |
| chrisl | There is *no way* the finalize method was defined but not used, since it was the generic gx_device_finalize() method | 15:51.15 |
| kens | Its fd9a66f | 15:51.40 |
| HenryStiles | Miles should send out the next meeting announcement today, with the holiday it seems like the time between meetings is much shorter this time. | 15:51.47 |
| kens | http://git.ghostscript.com/?p=ghostpdl.git;a=blobdiff;f=devices/vector/gdevtxtw.c;h=1f8a8ae293a56795e8d121d7b215c1eac1206652;hp=4388257136b54856c1b81fcb0da5d799e923ed95;hb=fd9a66f997bb57e9628a703774eddcf933475a34;hpb=e7e548af55b7034409e96483fee1d92313573973 | 15:51.50 |
| | I will admit that its possible this didn't do anything, but I'm doubtful, the usage of the strange macro tweaks my memory and makes me thnk we need this. | 15:52.51 |
| | I'd also have preferred to leave a bunch of the pdfwrite stuff alone. I don't *think* any of these changes will cause a problem, but since I don't have any way to deliberately exercise those code paths I'm not totally comfortable with those. But I won't shout about them. | 15:54.08 |
| Robin_Watts | I really can't see how removing that line can possibly break anything. | 15:56.51 |
| kens | Nevertheless, I'd prefer it be reinstated | 15:57.08 |
| chrisl | Robin_Watts: at the very least, it could cause a memory leak, because the device isn't being finalized | 15:58.13 |
| Robin_Watts | chrisl: No. It could not. | 15:58.25 |
| | The macro defines 2 routines, and a structure. | 15:58.42 |
| | The structure is never referred to by anything in the code. | 15:58.54 |
| | Therefore the structure can make no difference to anything at all. | 15:59.02 |
| | The 2 routines are solely referred by the structure. | 15:59.18 |
| | Therefore, given that the structure is never used, the routines are never used. | 15:59.35 |
| | Therefore removing the macro can't hurt. | 15:59.50 |
| chrisl | That's..... confusing | 16:00.15 |
| kens | OK let me put it a different way. I'm going to put it back as it was. At a later date (when I'm not so busy) I will look again at the GC in the txtwrite device. | 16:00.19 |
| Robin_Watts | Now, if you can see a flaw in my logic, then please feel free to point it out and make me look a fool. It won't be a new experience for me. | 16:00.34 |
| kens | But at the moment ths chgange concerns me, a lot | 16:00.36 |
| | I'm not happy about a potentially har to track down failure being added, just to squash a compiler warning | 16:01.13 |
| Robin_Watts | quietly explodes. | 16:01.24 |
| kens | Robin, if ths is a problem, the likely first time we will discover it is immediately after the next release | 16:02.06 |
| | Why run the risk when its only a compiler warning ? | 16:02.16 |
| Robin_Watts | Now, if you want to tell me that the structure that the macro defines *should* be being used somewhere, well, I could believe that. | 16:02.22 |
| kens | As I said, I will review the code when I have some leisure | 16:02.37 |
| | At the moment I don't. | 16:02.42 |
| Robin_Watts | well, have at it. | 16:03.00 |
| kens | We have a release coming up shortly and I don't want to risk adding a failure to that release | 16:03.03 |
| Robin_Watts | For that finaliser to be used, then I would expect, somewhere in the code to see a gs_alloc_struct(mem, gx_device_txtwrite, &st_device_txtwrite, cname); or something like that. | 16:10.28 |
| | I can't find a gx_device_txtwrite at all though, so... | 16:10.42 |
| | Aha. | 16:11.03 |
| | gs_txtwrite_device | 16:11.05 |
| | ooh, again, not referred to anywhere. wtf? | 16:11.29 |
| kens | Just leave it with me, its going to take me some time to reconstruct the logic in ths and in the meantime I still have to update my other branch | 16:11.40 |
| chrisl | gs_txtwrite_device is the prototype of the device that, IIRC, genconf will generate a reference to | 16:12.39 |
| kens | Seriously, leave it with me, I'll get back to it, its not worth us all wasting time over | 16:13.09 |
| Robin_Watts | OK. I'll leave it. But just as a last observation... my gs no longer has txtwrite built into it. | 16:14.13 |
| | ignore me. | 16:14.28 |
| | I can't read. | 16:14.32 |
| | So the RSA expo looks to be open from 10-3 on March 3rd. | 16:41.37 |
| | In order for us to visit that, we'd then have to fly in on Wed 2nd. | 16:41.52 |
| kens | Indeed | 16:41.58 |
| Robin_Watts | It's open 10-6 on the tuesday and wednesday. | 16:42.56 |
| kens | I'm not convinced I'm terribly interested..... | 16:43.10 |
| mvrhel_laptop | did miles send out something about the meeting? | 16:43.43 |
| kens | Just now yes | 16:43.48 |
| Robin_Watts | I'm wondering if they'd like help on the stand. Given that it's an SOT based thing, and Pete/Joseph aren't going this time (AIUI). | 16:43.53 |
| kens | Lets me out then :-) | 16:44.04 |
| mvrhel_laptop | oh there it is | 16:44.04 |
| Robin_Watts | I believe Fred might have already been volunteered for this. | 16:44.17 |
| mvrhel_laptop | ugh I managed to catch a cold yesterday | 16:44.21 |
| kens | I caught mine at the end of my holiday | 16:44.33 |
| Robin_Watts | mvrhel_laptop: That was silly. | 16:44.38 |
| kens | So I'm sure everyone on the flight home has mine now | 16:44.46 |
| mvrhel_laptop | how was the skiing kens? | 16:45.42 |
| kens | Better than I hoped for :-) | 16:45.58 |
| | It snowed Satruday night, and from Tuesday it was cold enough to make snow as well | 16:46.14 |
| | Even so, only 1/3 of runs were open, whch was a shame | 16:46.30 |
| mvrhel_laptop | wow. that sounds like last year here. | 16:46.56 |
| kens | We'd hoped to takeStella round the mountain but when Melanie and I went to the next resort over the snow was so awful we came straight back on the lift | 16:47.00 |
| | The El Nino hit the Alps really badly | 16:47.25 |
| | Italy has (or had) no snow below 3,000 metres | 16:47.40 |
| | But I understand Henry has plenty, its a pity he can't export it | 16:48.23 |
| mvrhel_laptop | yes. western US has gotten quite a bit this year | 16:48.41 |
| HenryStiles | yup plenty of snow here... | 16:49.57 |
| kens | Looking at flights, going out Thursday I'm thinking of the 12:20 departure froim Heathrow, on Thursday 3rd, returning on Sunday 6th leaving at 17:00 US time, arriving on Monday in the UK at 11:00 | 16:50.33 |
| | Total price £580.25 | 16:51.20 |
| | Oh that's a Virgin flight | 16:51.41 |
| Robin_Watts | Just checking with Miles if he wants help for the other days. | 16:53.57 |
| | I might go on the wednesday to have a mooch around the show even if he doesn't need me. | 16:54.15 |
| kens | Yeah, I was going to wait until tomorrow to actually book | 16:54.17 |
| | I don't thnk the RSA show interests me enough | 16:54.35 |
| | I also dfon't know how much I'd get out of it trying to understand it while jet-lagged | 16:55.07 |
| mvrhel_laptop | Wow. Under $200 for me to fly to and back to SFO | 16:55.31 |
| kens | cheap oil ? :-) | 16:55.46 |
| mvrhel_laptop | actually under $150 | 16:56.07 |
| | crazy | 16:56.19 |
| | I guess the cheap oil is starting to affect airline prices | 16:56.44 |
| | It took long enough | 16:56.57 |
| Robin_Watts | I wonder if the US is like the UK. | 16:59.12 |
| kens | I'm pretty sure it isn't :-) | 16:59.25 |
| Robin_Watts | In the UK, oil suppliers are required to hold something like 60 days supply of stocks for oil. | 16:59.35 |
| kens | Hmm I thought the Feds had a reserve themselves | 16:59.58 |
| Robin_Watts | this means that price rises get passed on very quickly, but price rises take much longer to filter down. | 17:00.00 |
| kens | Well I think that's enough mayhem for first day back | 17:01.50 |
| | Goodnight all | 17:01.57 |
| Robin_Watts | ok, booth is covered. I'll be flying on the wednesday then and will just catch the last day of the show. | 17:09.19 |
| chrisl | Where is the show? | 17:10.05 |
| mvrhel_laptop | I am flying in Thursday morning and hope to wander the show a bit | 17:10.12 |
| Robin_Watts | chrisl: moscone. | 17:11.39 |
| | so right in the middle of downtown SF. | 17:11.47 |
| | And Sheryl Crow is playing a gig there on thursday night. | 17:12.46 |
| | dunno if our tickets would cover us for that :) | 17:12.57 |
| Robin_Watts | goes to fetch helen. bbs. | 17:13.08 |
| | Oh, god, I hate JNI. | 18:51.25 |
| | In the JNI_OnLoad stuff, I want to cache all the fieldids, classes etc. | 18:52.19 |
| | so I can use them in the actual JNI implementations. | 18:52.30 |
| | So as soon as I call 'GetMethodID' on the colorspace class, it loads the colorspace class in the background, which means initing the statics., which means calling the JNI, which means my code gets called which expects the JNI to have been set up .... boom. | 18:53.38 |
| | tor8: You said earlier about the idea of putting this code in platform/java or something. Nice idea, but java is a pain in the ass with such things. | 19:39.29 |
| | I suspect we might need to have a platform/java and then unifdef from that to give platform/java/desktop and platform/android. | 19:40.17 |
| | tor8: OK, updated robin/jni2. | 19:57.43 |
| | The app runs with that. | 19:57.48 |
| | I think I've done all the changes we talked about. Let me know if there is anything I missed. | 19:58.06 |
| | Forward 1 day (to 2016/01/12)>>> | |
IRC Logs