| | <<<Back 1 day (to 2015/11/15) | 20151116 |
| kens | chrisl I'm pretty sure I can see how that guy is ending up with a divide by zero, the problem is I don't think I want to address it where the crash occurs, I believe it should be handled earlier. I can't see how he gets to that location with the problem, and I can't reproduce it on regular Ghostscript (as indeed, he can't either) | 08:13.48 |
| chrisl | kens: I actually can't reproduce it in evince - the crash I see is somewhere in cairo - but that could be a due to any number of reasons | 08:20.52 |
| kens | I couldn't reproduce it at all. I can see a potential divide by zero in the code, but I don;t think we should ever get there with that being set to 0..... | 08:21.26 |
| | And teh guy was p*ssing me off | 08:21.50 |
| chrisl | Well, I rather felt that way - which is one reason I tried to send him off to the evince/okular devs | 08:24.39 |
| kens2 | Him and the one reporting a zoom error on GSView but no example file..... | 08:24.58 |
| chrisl | Before I gave up disgust last night, I did have a look at the evince code, and how it calls libspectre, and the libspectre code, and how it calls ghostscript..... but I still couldn't piece together a likely set of parameters that might be getting given to gs | 08:37.09 |
| kens2 | :-( | 08:37.25 |
| | d:\ghostpdl\The guy talking about gsview is correct as well, though I'm not sure I care. | 08:37.42 |
| chrisl | I dunno, it's not like we have a replacement yet.... | 08:38.16 |
| kens2 | Well I get a -13 (limitcheck) instantly on pressing the 'zoom' button. I have no idea why and no real clue how to build and debug GSView | 08:38.49 |
| | It looks like I gave up in disgust with GSPrint and built my own solution file when I had to debug it...... | 08:39.16 |
| chrisl | I was assuming you could log or view the parameters gsview uses to call gs, and reproduce it directly in gs - I thought gsview had such a function | 08:40.11 |
| kens2 | Its possible, I can't find such a thing though | 08:40.26 |
| | Not that I'm hugely familiar with GSView | 08:40.35 |
| chrisl | I did notice that libspectre uses the gs_run_string.... API, and either evince or libspectre has at least some rudimentary dsc parsing built in, so there are a lot of variables in what might trigger the sigfpe | 08:41.16 |
| kens2 | Hmm, well GSView uses DSC parsing too, I wonder if there's a common theme.... | 08:41.49 |
| chrisl | I'd be tempted to suggests GSView's dsc parsing might be more complete/robust than libspectre's | 08:42.53 |
| kens2 | No doubt! | 08:43.04 |
| | chrisl you want the bad news ? | 10:31.26 |
| chrisl | I s'pose | 10:31.47 |
| kens2 | Its the build consolidatoin commit that causes the GSView problem | 10:31.57 |
| | THe commit immediately before is OK, that (large) commit is not | 10:32.16 |
| chrisl | Hmph.... I guess I can take a look at it | 10:32.45 |
| kens2 | I can't really fathom what it could be, its taken me this long to get here because of course the directory structure kept changing..... | 10:33.12 |
| | For me commit f374cec (More fiddlig with Symbolic TrueType fonts) is OK, commit 6948650e (commit of build_consolidatoin branch) doesn't work, I ignored Marcos' commit in between as it only affected clusterpush.pl | 10:35.14 |
| | Presumably we still have the branch I guess I could check that out and bisect it | 10:35.54 |
| | But I think you can do it much faster than me | 10:36.09 |
| | The problem is, I can't reproduce a fault with GS, just with GSView, which means building it for Windows | 10:36.29 |
| | So maybe I should carry on with it | 10:36.42 |
| chrisl | I'll look at it - it looks like I have in the past, built gsview 5.x so I can look at that | 10:37.07 |
| kens2 | I thnk I can build gsview, it does have a makefile, I'm not certain how to debug it though.... | 10:37.36 |
| | Well GSView 5 won't build for me, there are missing files. | 10:48.32 |
| chrisl | Trying it now..... | 10:50.15 |
| kens2 | OK sems I have 2 copeis of gsview and in one of them I've got it building | 10:52.14 |
| | Now all I need to do is figure out how to make a debug build | 10:52.29 |
| chrisl | It looks like it's intended that adding DEBUG=1 to the nmake command like should do that - but I'm not totally sure it'll work fully | 10:55.21 |
| kens2 | I don't thnk it does | 10:55.30 |
| | I tried that and hte executable is suspiciously small | 10:55.39 |
| chrisl | Yeh, I don't think it adds all the required compiler flags | 10:56.21 |
| kens2 | chrisl, frankly I'm getting nowhere fast with ths :( If there's anythign I cando let me know, otherwise I'm going to head back to PJL hackery | 11:16.20 |
| chrisl | kens2: that's fine, leave it with me.... | 11:16.38 |
| kens2 | OK shout at me if I can do anything | 11:16.50 |
| chrisl | kens: there is a commit in my repo that I *think* should fix the gsview problem | 12:37.00 |
| | Lunch..... | 12:51.14 |
| kens | goes to look in git | 13:04.47 |
| | Well it fixes the problem for me. I'[m hazier on what this is actually doing..... | 13:13.22 |
| chrisl | Well, the problem is that the app creates one library context, which it keeps, then the shuts down and restarts multiple interpreter instances on top of that library context. | 13:14.28 |
| kens | Yeah I think I saw someone with the same problem somewhere else | 13:14.53 |
| | I'd have thougth that should work myself | 13:15.08 |
| | But I see no means to count down the io_device count | 13:15.24 |
| chrisl | There isn't one, because the iodevice table is cleaned up by the garbage collector (or other, outside means) | 13:15.59 |
| | All we have is a gs_iodev_finalize() which sets the pointer to NULL | 13:16.34 |
| kens | Ah right. I must admit it seems odd to have the table in the library instance, but this is all a bit confused, and not really code I've had to look at | 13:16.34 |
| | When we finalise the iodevice shouldn't we se tht ecount to 0 ? Or is that the ifnalise for the allocated memory ? | 13:17.17 |
| chrisl | We could set it to zero then as well | 13:17.50 |
| kens | I thnk that would be useful, perhaps even clearer :-) | 13:18.16 |
| chrisl | Hmm, I thought setting it to zero when we create a new, empty table was clearer...... | 13:18.46 |
| kens | I don't really understand the flow of control here, but it looks reasonable anyway | 13:18.52 |
| | And it seems to fix the problem, for me anyway | 13:19.26 |
| chrisl | Well, the problem is that when we try to initialise a new io device table when reusing a context, we increment the count, but not starting from zero, so we get a gs_error_limitcheck from gs_iodev_register_dev() | 13:20.57 |
| kens | Yeah I can see whjy not having the count at zero is a problem | 13:21.15 |
| | Like I said, it seems to fix the problem, I don't understand the area well enough to have a useful opinion. Ordinarily I would set the zero when I freed the memory, but then finalize routines are more than slightly surprising to people so having it where it is is fine by me. | 13:22.21 |
| chrisl | I'm going to do both - I think that's going to be safest | 13:23.07 |
| kens | Well that should prevent any surprises I guess :-) | 13:23.27 |
| chrisl | I do have some concerns about this stuff in a non-gc context, but that's not related to the changes I made for the build consolidation | 13:24.31 |
| kens | Hmm does ths work at all in a non-gc context ? What frees the memory ? | 13:24.55 |
| chrisl | Dunno, never looked at it | 13:25.21 |
| kens | Well, I guess that is something of a concern, one for Henry I suppose | 13:25.38 |
| chrisl | Currently, there is no way to get into this problem with PCL or XPS, so the issue will never have arisen. | 13:27.24 |
| kens | ah well in that case no wonder we've not seen a problem | 13:27.42 |
| | I wish I could remember where else I've seen ths mentioned, I think I'll go check SO | 13:28.03 |
| chrisl | There was someone on bugzilla a few weeks ago | 13:28.24 |
| kens | gx_io_device_table_countAh maybe that was it | 13:28.31 |
| chrisl | Bug 696307 | 13:28.57 |
| kens | Aha 100% correct | 13:29.16 |
| chrisl | Right, quick clusterpush and then I'll push the commit | 13:29.56 |
| kens | So its their own application and there wasn't enough information there to figure out what the problem was, and they are freeloader parasites, so I'm not inclined to upadate the bug really | 13:30.14 |
| chrisl | I rather feel the same way. TBH, I'm not that happy about applications working this way, but it's easier to fix Ghostscript than try to fix gsview!! | 13:31.07 |
| kens | I don't think we *can* fix GSView, not verison 5 anyway, and version 6 is going to be 'something else'..... | 13:31.44 |
| | And I see that the reporter opened a couple of bugs for Michael there too, that'll give him something to do :-) | 13:32.07 |
| | Not the greatest of starts to the week.... | 13:34.04 |
| henrys | chrisl: the icc manager stuff seems to work except for a peculiar character change I wasn't expecting. Can you look at my bmpcmp and tell me if that is an indeterm you've been seeing recently? | 13:53.36 |
| kens | You cna ignore 34-all.ps | 13:54.13 |
| | That page is just weird it changes all the time for no apparent reason | 13:54.35 |
| | Tiyr bmpcmp looks fine to me, nothign unusual thre, almost all the changes are the halftoning problems we have already mentioned. The 34_all.ps is a known strange one, and the XPS one comes and goes for me | 13:55.40 |
| henrys | kens: yeah I expect the halftoning stuff the glyph one is weird. Thanks | 13:58.56 |
| kens | NP | 13:59.06 |
| | The XPS one is another I don't really understand, but its definitely non-deterministic. | 14:00.17 |
| henrys | kens: are there bugs for those? | 14:01.09 |
| kens | I don't thnk so no | 14:01.19 |
| | THe halftoning ones maybe there's somethign for ray, the 34_all.ps I've never looked at | 14:01.34 |
| | The XPS one only ever showed up for me on a personal run, never a commit push | 14:01.52 |
| henrys | let's see what mr. valgrind says | 14:02.36 |
| | oh it has a bogus png ... tor8 will love a bug like this ;-) | 14:06.07 |
| kens | That'sa the XPS one ? | 14:06.18 |
| | Its from Sumatra and I tend to treat those files with extreme caution, they usually have a number of faults simultaneously | 14:06.43 |
| henrys | kens: well the error is exactly what I expect, valgrind shows a variable uses_stroke is undetermined which explains the observation. | 14:12.58 |
| chrisl | The segfault is worrying..... | 14:16.03 |
| | Mostly with the sumatra files, I tend to work on the basis that they are so broken, if we don't crash, that's good enough | 14:17.38 |
| kens | henrys well that sounds easy enough to fix to me | 14:18.08 |
| henrys | chrisl: you downloaded from my repo? | 14:18.43 |
| chrisl | henrys: no, just looking at the clusterpush | 14:19.03 |
| henrys | chrisl: arg I missed that I fixed several locally | 14:19.44 |
| kens | I got a random seg fault earlier that could not possibly have occurred due to my fix, and it went away when I committed the fix | 14:21.04 |
| | It was also at 72 dpi with pbmraw | 14:21.17 |
| chrisl | Odd..... | 14:21.43 |
| kens | Very, but I cannot reproduce it :-( | 14:22.01 |
| henrys | yeah why just 72? | 14:22.28 |
| kens | Well it coudl be a resolution-dependent thing | 14:22.44 |
| | The on I fixed was resolution dependent | 14:22.54 |
| | But you had to run at really low res ot see it (10 dpi) | 14:23.07 |
| | But then I'd expect to see it on other devices too | 14:23.38 |
| henrys | LGTM locally. | 14:29.30 |
| | seg fault machines should be reported. That could be on the mac only or something. | 14:32.29 |
| chrisl | It is reported | 14:33.21 |
| kens | Its kilometers that seg faulted (if I got that the right way around) | 14:33.53 |
| chrisl | I can never remember.... | 14:34.10 |
| henrys | oh never read down that far ;-( | 14:37.31 |
| chrisl | Not interested in errors?? | 14:38.02 |
| henrys | never really looked pcl crashes are usually just crashes I can reproduce anywhere I guess. | 14:41.10 |
| | stop reading when I see seg fault and go fix it. | 14:41.27 |
| chrisl | Robin_Watts: getting back to the memory manager stuff..... we have five allocators currently: gsalloc.c, gsmalloc.c, gsmchunk.c, gsmemlok.c and gsmemret.c - the last two can be ignored as they do not actually manage any memory for themselves. | 14:46.00 |
| Robin_Watts | right. | 14:46.20 |
| chrisl | gsmalloc.c and gsmchunk.c are fairly easy to revise for variable alignment | 14:46.51 |
| Robin_Watts | chrisl: Urm... really. | 14:47.20 |
| chrisl | Well, they have their own structures for headers etc, so we can hack them around all we want | 14:47.56 |
| Robin_Watts | Right, so you're talking adding an overhead on every block to cope with the very few that need alignment ? | 14:48.28 |
| chrisl | An extra byte | 14:48.42 |
| Robin_Watts | s/alignment/special alignment/ | 14:48.47 |
| | chrisl: Yeah, which means 8 bytes on 64bit platforms, I suspect. | 14:49.01 |
| chrisl | *But* gsalloc.c, which could be made to work, also interacts with the garbage collector - and that's a hole I'd rather not disappear down at the moment | 14:49.46 |
| Robin_Watts | I think this can be summed in 2 options. | 14:50.43 |
| | Either we need to add a special case alloc/free pair that does the padding itself (i.e. the solution I discussed last week with mvrhel) | 14:51.21 |
| | OR we need to somehow push something inside the generic allocation API offered by the gs_memory_t stuff. | 14:51.53 |
| chrisl | I have a half way house proposition, which is to augment gsmchunk.c with a gs_memory_chunk_wrap_align() which gives a chunk allocator instance which honours the alignment requested | 14:52.02 |
| Robin_Watts | chrisl: For *1* block? | 14:52.17 |
| | It's not 'all pngs blocks must be allocated this way'. | 14:52.30 |
| | It's 'the png decoder uses a single block which needs such allocation'. | 14:52.51 |
| chrisl | But we can't differentiate which 1 allocation needs to be so aligned | 14:53.01 |
| Robin_Watts | actually, ignore that distinction. | 14:53.03 |
| | yeah. | 14:53.06 |
| chrisl | The problem with both your proposals is it opens the risk of interaction with the garbage collector | 14:53.39 |
| Robin_Watts | The simple one certainly doesn't. | 14:53.55 |
| chrisl | Yes, because someone seeing gx_alloc_aligned may simply use it, assuming it works with all allocators | 14:54.26 |
| Robin_Watts | the special case gs_alloc_aligned/gs_free_aligned doesn't, cos it only calls for non gc allocations. | 14:54.49 |
| chrisl | Then that's implicit, hidden knowledge in the API, which I really don'y like | 14:55.48 |
| Robin_Watts | chrisl: It's no more 'implicit, hidden knowledge' than the fact that calling gs_alloc_bytes_immovable will return non-gc memory. | 14:56.33 |
| chrisl | It doesn't, gs_alloc_bytes_immovable() does return garbage collected memory | 14:57.00 |
| Robin_Watts | "gs_alloc_aligned_non_gc" if it makes you feel happier. | 14:57.00 |
| henrys | so we consider cleaning up the small allocations impossible? all of the small allocations are from the ps language. ie if mooscript were working I don't think there would be a small allocation problem worth worrying about. | 14:57.53 |
| | at least for pdf | 14:58.16 |
| Robin_Watts | henrys: non-sequitur? | 14:58.31 |
| chrisl | Do we consider changing the fundamental behaviour of the PS interpreter impractical now and for the foreseeable future? Erm, yes | 14:59.14 |
| Robin_Watts | I don't see how what we are discussing (the need for an aligned block to solve png's problems with the evil setjmp) corresponds to some possible future attempt to tidy up the number of small allocations gs makes. | 14:59.47 |
| henrys | Robin_Watts: because all allocations could be done on the larger boundary | 15:00.13 |
| Robin_Watts | henrys: That would make small allocations *worse*! | 15:00.35 |
| henrys | chrisl: I don't know if it is fundamental... but I'll leave it ... | 15:00.37 |
| Robin_Watts | Oh, right. | 15:00.55 |
| chrisl | henrys: a lot of those small allocations are in how we manage names, and that's pretty fundamental in Postscript | 15:01.04 |
| Robin_Watts | If we had fewer small allocations, then the per block overhead would drop, and that would mean a larger alignment wouldn't hurt us to much. Gotcha. | 15:01.33 |
| | s/to/too/ | 15:01.41 |
| henrys | chrisl: names and lots of tiny stuff for arrays | 15:01.43 |
| | chrisl: scanner packed stuff | 15:02.09 |
| | off for coffee | 15:02.21 |
| chrisl | Robin_Watts: I guess your proposal is simplest/quickest, I just dislike having to remember that this block of memory allocated via this special function, must be freed by other special function - there isn't a special free() that goes with memalign() | 15:04.00 |
| | Sort of tempted to just gs_png_alloc() and gs_png_free() to gsmisc.c and have both gdevpng.c and xpspng.c use them........ | 15:06.45 |
| Robin_Watts | Where gs_png_alloc and gs_png_free just have the crunchy alignment stuff in them? | 15:08.11 |
| chrisl | Yeh | 15:08.22 |
| | So, it's clear they are for a special purpose | 15:08.44 |
| Robin_Watts | I'd rather have the names reflect their utility rather than where they were used. | 15:08.45 |
| | What happens when we realise we need to the same thing in (say) the JPEG decoder ? | 15:09.23 |
| chrisl | So, what happens when we realise we need the same thing that's compatible with the garbage collector? | 15:11.06 |
| Robin_Watts | chrisl: Well, then either we're a) buggered, or b) we have to change the calling code to do the alignment itself. | 15:11.45 |
| | the jpeg code already does 'b'. | 15:11.50 |
| | It's our desire not to alter the png lib that drives us to a solution where we align all blocks for png. | 15:12.19 |
| | I'm not entirely convinced that setjmp/longjmp and gc aren't mutually incompatible. | 15:13.53 |
| | There is nothing in the C spec that says you can copy the contents of a jmpbuf elsewhere and still expect it to work. | 15:14.16 |
| chrisl | setjmp/longjmp are not the only reasons to require/desire aligned memory | 15:14.53 |
| Robin_Watts | To paraphrase Paul, if you remove the entrails from the chicken, you can't expect them to work when you put them back. | 15:14.54 |
| | chrisl: We also use aligned memory in the SSE thresholding stuff. | 15:15.24 |
| chrisl | Indeed, yes | 15:15.36 |
| Robin_Watts | but again, that code does the alignment itself. It would be nicer if it called these new routines. | 15:15.45 |
| | (possibly) | 15:15.54 |
| chrisl | So, then we'd have to remember which bitmap allocations were aligned and which weren't and use the correct free() call depending? | 15:16.31 |
| Robin_Watts | chrisl: Yes. | 15:16.40 |
| chrisl | That's exactly what I'm trying to avoid | 15:16.56 |
| Robin_Watts | But we're all adults, but honestly, that should not be a big problem, surely? | 15:17.15 |
| chrisl | It's just the kind of stuff that comes back to bite us | 15:17.51 |
| Robin_Watts | If you malloc, you free. If you new, you delete. If you alloca, you (don't do anything). If you gx_alloc_aligned, you gx_alloc_free | 15:17.55 |
| kens | Or we could do like we did in Jaws and not use 3rd party libraries >:-) | 15:18.42 |
| kens | ducks | 15:18.51 |
| chrisl | As I said, if you memalign() you don't freealign()...... | 15:18.57 |
| Robin_Watts | chrisl: Yeah, we'll, that's not a portable C function, so... | 15:19.33 |
| chrisl | It's posix.... | 15:20.41 |
| Robin_Watts | so? :) | 15:21.17 |
| chrisl | And it seems that the C11 standard adds aligned_alloc()..... which is a new one on me | 15:22.03 |
| Robin_Watts | If anyone tries to gx_free when they should have gx_free_aligned they'll fail in fairly spectacular fashion I'd have thought. | 15:24.47 |
| | It's not going to be a 'silent' bug. | 15:25.03 |
| chrisl | I've had to fix issues like that where in normal operation it was fine, but during error cleanup it was wrong - those don't necessarily appear immediately | 15:26.54 |
| | We could also just let libpng use the Windows malloc/free........ | 15:33.29 |
| Robin_Watts | That goes against everything we try to achieve. | 15:34.05 |
| chrisl | I wasn't entirely serious, although it's what gdevpng.c does | 15:34.44 |
| henrys | at least can we make the chunk allocator large aligned? XPS/PCL/PXL would never have to worry about this if it were. | 15:35.59 |
| | and it fixes michael's bug now | 15:36.29 |
| chrisl | henrys: one worry about that is that making the chunk allocator honour the existing alignment setting is what Norbert claimed caused their PCL slow down.... | 15:37.34 |
| henrys | chrisl: we had a bug for that somewhere didn't we? | 15:38.43 |
| Robin_Watts | henrys: honestly, we've spent way longer talking about this than it would actually take to fix the bug. It's a trivial fix. | 15:38.51 |
| chrisl | henrys: it's closed - I think Ray ultimately concluded it wasn't reproducible | 15:39.32 |
| | My preferences are to do something specific to solve the png problem, or do something properly general, supported by all the allocators | 15:40.56 |
| Robin_Watts | Let's do the first now to solve the bug. It's 10 minutes work. | 15:41.33 |
| | Then if you want to think about the latter one, so be it, though I personally have my doubts about whether it's worth it. But I would be happy to be proved wrong. | 15:42.41 |
| henrys | Robin_Watts: sorry yes I wasn't really focused on the specific problem. I'm more interested in having an architectural improvement. | 15:42.55 |
| chrisl | Had Michael already got it working? | 15:43.20 |
| Robin_Watts | kens: I don't necessarily think it needs a complete redesign. | 15:52.59 |
| kens | It needs cut down byb at least 75% | 15:53.11 |
| Robin_Watts | I think we can get there in an evolutionary way rather than revolutionary way. | 15:53.26 |
| kens | The ridiculous enumerator crap needs to be thrown away | 15:53.33 |
| | Etc, etc | 15:53.44 |
| Robin_Watts | But yes, we should be prepared to throw stuff out, rather than considering it set in stone. | 15:54.12 |
| chrisl | The reason for doing it in one hit is so customers only face one lot of re-engineering | 15:54.35 |
| Robin_Watts | chrisl: Which is why I said it should be a parallel branch. | 15:55.07 |
| kens | We can do it incrementally internally, but customers need to see one change, because we can't expect them to rewrite their devices continuously while we make changes | 15:55.12 |
| Robin_Watts | kens: yeah. | 15:55.26 |
| kens | And some sensible, useful, documentation on what each device API method does, what its arguments are and how it shold be used would be useful | 15:55.59 |
| tor8 | Add a new device interface, incrementally change our stuff over to use it, then once enough is working, drop the old device interface and scare the customers in one go? | 15:56.03 |
| chrisl | It's all academic anyway..... even when we just about had the man power available, we didn't get to do it, so...... | 15:56.12 |
| kens | tor8 Possibly | 15:56.15 |
| tor8 | kens: chrisl: I think a redesign of at least the device interface in ghostscript is becoming more and more urgent. | 15:56.48 |
| kens | (as tor also pointed out) | 15:56.49 |
| Robin_Watts | Of course, customers are really awkward about moving. I had a customer on skype the other day talking about mupdf, trying to decide if it was worth updating to 1.8 from 1.6 | 15:56.50 |
| kens | I don't find the include file stuff to be a problem | 15:59.59 |
| | The device API is a never ending nest of snakes | 16:00.08 |
| | For include files I include the one I want, if that gives errors I just keep including more until they go away | 16:00.37 |
| | And it cna easily be sovled by declaring 'everything.h' and putting all the definitions in it | 16:00.55 |
| | :-D | 16:01.02 |
| tor8 | kens: gxps did the "everything.h" approach | 16:01.21 |
| kens | I've been sorely tempted by a pdfwrite.h file...... | 16:01.47 |
| chrisl | Having tried a couple of times to tidy up some of the include tangle that bothered me, I'm not sure that counts as "simple"..... | 16:01.52 |
| tor8 | and it works for windows.h and all of apples stuff, so I don't see why we can't do it for ghostscript | 16:01.56 |
| kens | Even though it might be helpful, it doesn't address the real problems in GS though | 16:02.45 |
| henrys | I'm not big on the everything approach the #include's serve as documentation for the dependencies. | 16:03.16 |
| kens | Well that worked well, given the effort Chris has gone to recently to sort out the dependencies | 16:03.39 |
| tor8 | henrys: that only works if you stay on top of keeping dependencies minimal and to the point... | 16:04.24 |
| Robin_Watts | henrys: The includes DON'T serve as a documentation for the dependencies. They *SHOULD*, but they don't. | 16:04.26 |
| henrys | Robin_Watts: I was just saying why I don't like the everything approach | 16:04.54 |
| tor8 | henrys: and to do that properly requires that you *never* include another header file from inside a header file | 16:05.14 |
| tor8 | and put the onus on maintaining the full header file list in each source file | 16:05.31 |
| Robin_Watts | tor8: Eh, what? | 16:05.38 |
| | I disagree. You absolutely *should* include headers from headers. | 16:05.52 |
| | a header should include everything it relies on. | 16:06.02 |
| tor8 | A depends on B, B depends on C | 16:06.03 |
| Robin_Watts | And if you get cycles, well, that's an indication that you've screwed up your design. | 16:06.20 |
| tor8 | you use A and C in the source, but only need to include A... bad. | 16:06.22 |
| kens | thnks the include files is a side issue | 16:07.04 |
| tor8 | if you're using includes to document dependencies in the source, you should include A and B and C in the source. | 16:07.09 |
| henrys | kens: broken windows matter | 16:07.21 |
| kens | What broken windows ? | 16:07.37 |
| henrys | sorry americanism: https://en.wikipedia.org/wiki/Broken_windows_theory | 16:08.21 |
| kens | I guess that only matters if the buildings aren't burning down round you | 16:08.48 |
| | Like I said, more of a 'polished code' than a 'oh god it can't be made to work' | 16:09.05 |
| | I might also point out that the very Wikipedia article contains an opposing view :-) | 16:11.08 |
| henrys | chrisl: by the way are you certain maximally aligning allocators matters. By my read of gxalloc.h:40 it shouldn't be much of an issue. Am I missing something? | 16:14.45 |
| | s/matters/matters?/ | 16:15.23 |
| chrisl | henrys: I didn't say it did matter | 16:15.54 |
| henrys | chrisl: you said the allocators could not be aligned maximally because we make many small allocations. Didn't you? | 16:17.07 |
| chrisl | henrys: I said we make many small allocations - it was also me that suggested just change the value in windows-x64-msvc.h | 16:17.58 |
| | I have a feeling that a lot of the small allocations we do are string objects, which are handled specially - possibly for that reason | 16:19.53 |
| | Yeh, it *looks* like we don't align string allocations | 16:21.42 |
| kens | One could always just try it and see what happens | 16:22.29 |
| | prcoess explorer, amongst other things, will tell you what the maximum owrking set was | 16:22.54 |
| henrys | sure and the cluster shows us the change in memory | 16:22.55 |
| kens | The cluster doesn't (mostly at least) run Windows | 16:23.07 |
| chrisl | I could hack genarch..... | 16:23.26 |
| henrys | I thought chrisl fixed that ;-) | 16:23.34 |
| kens | TO make a 16 byte alignment on Linux, that would work | 16:23.52 |
| mvrhel_laptop | I that topic, just so I know to not do any further work on it, we are going to have chrisl do a fix for 696316 | 16:26.54 |
| | s/I/On | 16:26.59 |
| chrisl | mvrhel_laptop: sure, if you could assign the bug to me | 16:27.52 |
| | "Connection timed out, quitting: alarm" - hmm, should I be worried? | 16:28.47 |
| kens | bugzilla ? | 16:29.59 |
| chrisl | Cluster | 16:30.07 |
| mvrhel_laptop | chrisl: ok done. | 16:30.09 |
| chrisl | mvrhel_laptop: thanks | 16:30.16 |
| kens | it will probably restart eventually | 16:30.25 |
| | peeved and peeves are offline though | 16:31.10 |
| | I guess Ray's connectoin went and hiccuped or died | 16:31.30 |
| henrys | as far as man power goes I'm hoping fred can take a bit out of sot and free up Robin_Watts, I'm not sure that's realistic but that's the plan | 16:31.55 |
| | Robin_Watts: it looks like the png folks aren't going to change, sigh ;-) | 16:33.27 |
| Robin_Watts | henrys: I already tried to get the png folks to change a while ago - see the bug link I posted the other day :( | 16:34.07 |
| henrys | Robin_Watts: oh I didn't look at the date of the bug. I thought you just posted that. | 16:35.09 |
| | it says 2013? | 16:35.51 |
| chrisl | I think their logic is pretty crass.... | 16:36.02 |
| Robin_Watts | henrys: yeah. | 16:36.55 |
| chrisl | henrys: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=faea7d6e98d6e7ee0b82d891544a13d703a291f5 | 16:37.26 |
| | I think it's pretty sh*t that they provide an API to use a custom memory manager, and then say, we're not going to help because you're using a custom memory manager....... | 16:38.17 |
| henrys | mvrhel_laptop: the icc manager stuff seems to be working now. What else can we take out of the graphics state ;-) ? | 16:40.38 |
| | mvrhel_laptop: I do have some cleanup - it has to be freed explicitly | 16:42.09 |
| mvrhel_laptop | henrys: great. | 16:42.39 |
| | Should you move the profile cache next? We only have one instance of that | 16:43.37 |
| henrys | the test is: does it need gsave and grestore? | 16:44.20 |
| | mvrhel_laptop: ^^^ | 16:44.58 |
| | mvrhel_laptop: and if you could explain the confusing comment in rc_gsicc_manager_free(), I assume it is stale... there is no reference count decrementing? | 16:46.38 |
| | mvrhel_laptop: nevermind I see that's the rc free | 16:49.09 |
| mvrhel_laptop | henrys: its the same as the icc manager was | 16:50.15 |
| | and likewise it is not used during clist playback | 16:50.48 |
| henrys | mvrhel_laptop: this will be explicitly allocated and deallocated on the heap no gc... will be availiable is that okay? | 16:51.36 |
| mvrhel_laptop | henrys hold on | 16:52.16 |
| | henrys: there are structure defined for gc in gsicc_profilecache.c | 16:53.26 |
| | so its in stable memory now | 16:53.49 |
| | according to the allocator | 16:54.04 |
| henrys | that just means it's not subject to save and restore, it's gc'd | 16:54.12 |
| mvrhel_laptop | right | 16:54.16 |
| chrisl | But if it reference counted, and the reference counting is correct....... | 16:54.34 |
| mvrhel_laptop | there is no need to be gc'd then | 16:54.49 |
| | we can rip out the pointer defs for gc and move it | 16:55.13 |
| henrys | chrisl: the ref counting appears to be out of control like it is in many other places, so I don't think we are doing harm there | 16:55.32 |
| mvrhel_laptop | there should be a lot less to do with this compared to the manager you just moved | 16:56.54 |
| | the manager was also in stable memory | 16:57.25 |
| | but it was used all over the place | 16:58.02 |
| | the profile cache is only used in a few places | 16:58.17 |
| | hmm it looks like it is disabled.... | 17:00.06 |
| | except for the calRGB and calGray case | 17:00.26 |
| | hmm I think this was suppose to be a project for Alex at one time | 17:00.51 |
| | he was supposed to create a unique key for me to use in detecting the occurrence of a PS CIE color space dictionary that we have already used | 17:01.37 |
| | so that we would avoid recomputing an ICC profile for it | 17:01.45 |
| | henrys^^ | 17:01.59 |
| kens | well that shold be easy enough to do | 17:02.06 |
| | we do t for patterns already | 17:02.17 |
| mvrhel_laptop | easy for you amigo. deeficult for me | 17:02.21 |
| henrys | mvrhel_laptop: I'm still on freeing the manager, but I'll read that later | 17:02.52 |
| mvrhel_laptop | henrys: oh I thought you said that was done | 17:03.10 |
| kens | mvrhel_laptop : If you make a bug and assign it to me I cna look into it | 17:03.20 |
| henrys | above I said: mvrhel_laptop: I do have some cleanup - it has to be freed explicitly | 17:03.40 |
| mvrhel_laptop | kens: great. thanks. I will do that now. It is a performance hit for CIE color spaces for which are repeatedly encountered in a file and for which we are creating an ICC table everytime | 17:04.09 |
| kens | Should be easy enough to do, from the PS end anyway :-) | 17:04.28 |
| mvrhel_laptop | awesome | 17:04.34 |
| chrisl | Running the cluster and forcing 16 byte alignment produces a surprising number of differences...... and I don't see any mention of memory useage | 17:05.32 |
| henrys | ugh | 17:07.47 |
| | chrisl: we can ask marcosw1 how to get the memory number but the differences, that sucks | 17:08.20 |
| chrisl | The PS ones *may* be legit..... | 17:08.48 |
| rayjj | chrisl: there are a few CET files that query memory usage, but other than those, memory alignment shouldn't cause the image to differ | 17:13.16 |
| chrisl | rayjj: yes, that's what I was alluding to | 17:14.00 |
| marcosw1 | henrys and chrisl: the nightly/weekly regression tests show memory usage differences. The cluster regressions could as well (it's actually collected, just not reported). | 17:14.31 |
| | It looks like it used to be reported as well, the calls to memAnalyze.pl are commented out. | 17:15.46 |
| mvrhel_laptop | kens: ok added 696355 | 17:18.52 |
| chrisl | The differences are mostly very minor - I'd want to investigate before committing to it, but probably not a huge deal. TBH, I'd rather just go with the PNG specific alloc/free solution | 17:18.57 |
| kens | mvrhel_laptop : OK I'll look at it asap | 17:19.06 |
| mvrhel_laptop | :) | 17:19.08 |
| | thanks kens | 17:19.48 |
| | no hurry. Its been waiting almost 6 years.... | 17:20.08 |
| tor8 | Robin_Watts: s/it's/its/ in the commit message | 17:20.26 |
| Robin_Watts | tor8: eh? what? | 18:09.28 |
| rayjj | Robin_Watts: my nick "rayjj" is registered, so you should be able to add it to #artifex | 18:39.39 |
| Robin_Watts | rayjj: Done, I think. | 18:40.07 |
| rayjj | Robin_Watts: thanks. I am on (along with you) | 18:40.50 |
| | Robin_Watts: OK, thanks. I think those are linked somehow, in that when I set my nick to ray_laptop, it prompts me to identify | 18:42.31 |
| henrys | Robin_Watts: how long did you wait for email verification? I haven't gotten anything yet | 18:47.51 |
| Robin_Watts | henrys: email verification of what? | 18:48.02 |
| henrys | Robin_Watts: registerning my nick name? | 18:48.58 |
| Robin_Watts | I did that years ago. Don't remember email being required. | 18:49.14 |
| | Have you just tried: /msh nickserv register <password> ? | 18:50.33 |
| | Have you just tried: /msg nickserv register <password> ? | 18:50.38 |
| | Oh, maybe it's really asking for an email address now. | 18:51.07 |
| rayjj | Robin_Watts: according to /msg nickserv help register: | 18:51.12 |
| | 10:50]NickServYou have to confirm the email address. To do this, | 18:51.14 |
| | [10:50]NickServfollow the instructions in the message sent to the email | 18:51.16 |
| henrys | Robin_Watts: yes where ? is my email | 18:51.16 |
| rayjj | [10:50]NickServaddress. | 18:51.17 |
| Robin_Watts | yeah, clearly I've forgotten doing that, sorry., | 18:51.58 |
| henrys | well I'll give it a little time. | 18:52.06 |
| rayjj | henrys: your whois has what looks like a bogus email address: <~user@73.34.199.132> | 18:52.56 |
| henrys | rayjj: probably because I'm not registered yet | 18:53.50 |
| rayjj | henrys: but I don't know where nickserv is going to get an email address | 18:53.50 |
| | henrys: ha ha (catch 22) | 18:54.04 |
| henrys | rayjj: I gave it to them when I did the register command | 18:54.29 |
| rayjj | henrys: oh. | 18:54.47 |
| henrys | the faq says: Register your IRC nick: /msg NickServ REGISTER password youremail@example.com then wait for a message that will have instructions ... | 18:55.47 |
| | | 18:55.47 |
| rayjj | Robin_Watts: the /msg nickserv group lets you add your current nick to a group that is registered under a different nick | 18:56.24 |
| Robin_Watts | henrys: You're absolutely right. Just my crap memory again. | 18:56.54 |
| rayjj | henrys: It's been so long since I registered, I didn't remember | 18:56.57 |
| henrys | I would not expect anyone to remember that | 18:58.06 |
| Robin_Watts | henrys: Mail took about 2 mins for me. | 19:09.27 |
| | But I wasn't using an artifex address, or gmail. | 19:11.20 |
| kens | Robin_Watts : I';ve sent an email but... My nick *is* registered | 19:29.25 |
| rayjj | is someone going to set up infobot to log #artifex (privately). We could have the log page still available, but with the same login as used for the regression page | 20:02.22 |
| Robin_Watts | rayjj: excellent plan. I'll try to sort that. | 20:17.55 |
| | kens: You're invited already. Everyone is. | 20:18.07 |
| henrys | Robin_Watts: maybe I should register with a different nick | 20:31.02 |
| kens | Robin_Watts : I got the impression from the mail I wasn't. I'll see if I can join | 20:31.56 |
| | Well that seems to work | 20:33.17 |
| | Now to figure out how to do it automagically in Miranda | 20:33.41 |
| HenryStiles | Robin_Watts: I'm HenryStiles | 20:34.04 |
| | registering henrys did not work and I didn't get any feedback it was registered... nothin' | 20:35.24 |
| marcosw | I've possibly identified the commit responsible for the 34_all.PS indeterminisms: http://bugs.ghostscript.com/show_bug.cgi?id=696357 | 20:36.10 |
| pedro_mac | Robin_Watts: Iâm pedro_mac - pedro was taken ;) | 20:37.24 |
| HenryStiles | marcosw: great, the xps bug I reported looks like an easy fix. I don't know how often others see that one | 20:46.47 |
| Robin_Watts | Try now. | 20:59.07 |
| fredross-perry | I get âyou need to be identified with services.â | 21:04.47 |
| Robin_Watts | fredross-perry: Have you registered? | 21:09.01 |
| | oops. I invited the wrong name. | 21:09.11 |
| | fredross-perry: Try again now? | 21:09.49 |
| fredross-perry | nope. how do i register? | 21:11.43 |
| Robin_Watts | test | 21:15.22 |
| | Well, that's embarrassing. #artifex won't let me back in. | 21:17.41 |
| | Can someone in#artifex do: /mode #artifex +I $a:Robin_Watts and then /msg ChanServ flags #artifex Robin_Watts +voAti please? | 21:19.02 |
| | In theory I have logging working, but I can't get back in to check. | 21:26.43 |
| pedro_mac | Robin_Watts: I tried, but got âYou are not authorized to execute this command.â from ChanServ | 21:31.30 |
| Robin_Watts | ooh, this could be embarassing. | 21:31.53 |
| | I thought I made everyone operators. | 21:32.01 |
| | Did the /mode work? | 21:32.35 |
| pedro_mac | yup, seemed ok | 21:32.41 |
| sebras | Robin_Watts: what happens to rooms if everyone leaves? | 21:32.49 |
| pedro_mac | it was silent so I assumed it worked ;) | 21:32.53 |
| Robin_Watts | sebras: https://botbot.me/how-to-setup-irc-channel/ | 21:33.22 |
| sebras | Robin_Watts: maybe you should test that in a new room before testing in the one you want to fix though. | 21:33.25 |
| Robin_Watts | ChanServ is supposed to keep it alive. | 21:33.41 |
| sebras | Robin_Watts: ah. | 21:33.55 |
| pedro_mac | is supposedly in it just now | 21:33.59 |
| Robin_Watts | and if no one can invite me back in, that's a bit of a problem :( | 21:34.03 |
| sebras | Robin_Watts: so... who is the admin of ChanServ? | 21:37.56 |
| mvrhel_laptop | I have no idea what I am supposed to do to get in | 21:51.12 |
| Robin_Watts | mvrhel_laptop: Are you registered with nickserv? | 21:52.58 |
| | mvrhel_laptop: You need to do: /msg nickserv register <password> <email-address> | 21:54.35 |
| | That'll send you an email with a line that you need to paste back in here. Once you've done that, you'll have sole ownership of the name mvrhel_laptop. | 21:55.16 |
| | Then each time you log in you do: /msg nickserv identify <password> and that'll make sure that it's really you. You can set chatzilla to do that for you. | 21:55.57 |
| | Once you're identified you can just /join #artifex. | 21:56.34 |
| | You may want to do the same thing as "mvrhel". I invited both names. | 21:56.57 |
| | sebras: I've messaged the freenode staff. Hopefully they'll help once they stop laughing. | 22:03.48 |
| | OK, so logging is setup. The logging bot can log in, no problem. It's just me that can't. | 22:10.45 |
| | There is a link to the logs from the regression dashboard. | 22:11.00 |
| rayjj | mvrhel_laptop: Note that you can register "mvrhel" (I recommend it) and then "group" other nicks with it, such as mvrhel_laptop | 22:11.51 |
| Robin_Watts | rayjj: Can you invite me back in please? | 22:12.03 |
| rayjj | Robin_Watts: back in to #artifex ? | 22:12.18 |
| Robin_Watts | Yes please. | 22:12.22 |
| | See the 2 commands I gave to pedro_mac above. | 22:12.36 |
| rayjj | Robin_Watts: I get "you need to be an operator to do that" | 22:13.18 |
| Robin_Watts | crap. | 22:13.24 |
| | I thought I'd made you all operators. | 22:13.30 |
| rayjj | did you make me an op ? | 22:13.37 |
| HenryStiles | locked your keys in the car | 22:13.53 |
| rayjj | Robin_Watts: I'm trying to look up the chanserv magic for setting "op" | 22:15.17 |
| | hmm... apparently according to chanserv, I am not authorized to (de)op on #artifex | 22:17.52 |
| Robin_Watts | I'll have to keep bugging the freenode staff. | 22:20.01 |
| rayjj | RobinWattsLenovo: OK. You are back to op on #artifex | 22:25.41 |
| | the magic was to set myself as op, then I could set you | 22:25.58 |
| | first: op #artifex rayjj | 22:27.29 |
| | then: op #artifex RobinWattsLenovo | 22:27.31 |
| | correctiion--- These are the messages to chanserv. The magic sauce was: | 22:29.05 |
| | first: /msg chanserv op #artifex rayjj | 22:29.47 |
| | then: /msg chanserv op #artifex RobinWattsLenovo | 22:30.02 |
| Robin_Watts | yeah, I'm in now and have sorted it. | 22:30.20 |
| mvrhel_laptop | rayjj: how do you "group" nicknames? | 22:31.58 |
| rayjj | mvrhel_laptop: sorry -- chatting on two channels at once gets confusing when it's to the same person | 22:37.45 |
| mvrhel_laptop | np | 22:37.57 |
| rayjj | mvrhel_laptop: so as I read it, you set your nick to your "alias" and then: | 22:38.25 |
| | /msg NickServ IDENTIFY OldNick SecretPassword and: | 22:38.26 |
| | /msg NickServ GROUP | 22:38.28 |
| | where OldNick is your "master" nick that is already registered | 22:38.48 |
| | /msg backscratcher lower to the right | 22:39.52 |
| rayjj | thinks talking with bots is cumbersom | 22:40.42 |
| | /msg backscratcher ahh... that's it | 22:41.18 |
| fredross-perry | ;-) | 22:41.51 |
| rayjj | fredross-perry: at least somebody got it | 22:42.18 |
| fredross-perry | happy to help | 22:42.44 |
| rayjj | HenryStiles: BTW, I made your current nick (HenryStiles) an op on #ghostscript just now as well) | 22:47.27 |
| | since you are now a registered nick, I can do that | 22:48.20 |
| mvrhel | and there | 23:11.07 |
| | HenryStiles: | 23:11.16 |
| | Forward 1 day (to 2015/11/17)>>> | |
IRC Logs