| | <<<Back 1 day (to 2015/04/09) | 20150410 |
| rayjj | has it really been this quiet all night, or do I need to wake up ghostbot ? | 15:11.32 |
| chrisl | it's been quiet | 15:11.50 |
| Robin_Watts | rayjj: Ghostbot has not been logging my sobbing. | 15:41.23 |
| rayjj | chrisl: I'm surprised that you had problems with 871 it worked "out of the box" for me (well, with my usual diddling to setsim.bat to force it to VS9 by removing the REM). As far as the solution file, it creates it from sim/syssim/emusw_gs.tpl | 15:48.26 |
| chrisl | rayjj: there's no solution file - that *cannot* work..... | 15:49.03 |
| rayjj | chrisl: that and the build failed the first time because it hadn't built gs__ufst.lib before it tried to link with it. Just doing a second build fixed that | 15:49.14 |
| | chrisl: their setsim.bat uses perl to make the solution file from emusw_gs.tpl I think. At least mine worked | 15:49.58 |
| chrisl | rayjj: It just didn't work - I started it with setsim 6thgen fs and with setsim 6thgen <the other option> and neither worked.... | 15:50.21 |
| rayjj | did you run setsim.bat 6thgen | 15:50.32 |
| chrisl | rayjj: okay, but after running setsim, there should be a solution after running setsim..... | 15:51.04 |
| rayjj | chrisl: just setsim 6thgen | 15:51.07 |
| chrisl | I think I tried that.... | 15:51.31 |
| rayjj | maybe the 'fs' confused it | 15:51.37 |
| chrisl | setsim 6thgen didn't work either - VS couldn't open a solution file..... | 15:52.48 |
| rayjj | mine is in SIM/SYSSIM/emusw_6thgen_fs.sln | 15:52.57 |
| | but I started setsim without the 'fs' after the 6thgen | 15:54.01 |
| | chrisl: note that I've modified the setsim.bat to remove the "REM " from the line that has set OVERRIDE_VS_VERSION=%VS90COMNTOOLS% | 15:55.50 |
| chrisl | rayjj: I also modified it to use VS2010, and I get a solution file of zero bytes - which, not surprisingly, doesn't work | 15:57.21 |
| rayjj | chrisl: and I always start the simulators from a "shorcut" that has the full/path/to/setsim.bat 6thgen with the full/path/to/the/BAT folder as the "Start in" | 15:58.12 |
| | chrisl: do you have 2008 ? | 15:58.28 |
| chrisl | I think so - that previously did not work. Neither did 2005..... | 15:59.08 |
| rayjj | it may be that 871 didn't work for vs 2010. ISTR they used to have problems, and 871 is really old | 15:59.13 |
| | I can send you my 2008 solution if you want it | 16:00.04 |
| Robin_Watts | 2010 uses vxcproj rather than vcproj, so I'd imagine that 2010 would cause problems. | 16:00.08 |
| rayjj | Robin_Watts: I think they've since fixed it for 906, but most of cust 532 are not past 2008 | 16:00.43 |
| | TBH I don't have 2010 installed, so I've never tried it. I only have VS 2013 installed to mess with gsview | 16:01.27 |
| chrisl | rayjj: VS versions 2005, 2008 and 2010 all give the same error - invalid solution file (all are zero bytes) | 16:01.33 |
| rayjj | chrisl: can you remove the .sln files from SIM/SYSSIM and try it again with 2008 (with the OVERRIDE_VS_VERSION=%VS90COMNTOOLS% ) | 16:02.51 |
| chrisl | rayjj: I did remove the sln between each attempt | 16:03.23 |
| | 4 | 16:03.40 |
| rayjj | chrisl: can you try manually: perl sim/syssim/emusw_gs.tpl > SIM/SYSSIM/emusw_6thgen_fs.sln | 16:05.18 |
| chrisl | rayjj: to be honest, no. I've had enough of it | 16:05.45 |
| rayjj | chrisl: note they use a perl that's in sim/bin/perl.exe | 16:05.55 |
| | chrisl: OK. | 16:06.08 |
| | it may be that you have a strange installation of Windows that they don't expect (different locations for stuff or drive letters) | 16:07.17 |
| henrys | chrisl: has anyone over there satisfactorily explained why the don't have a friggin' profiler? | 17:21.11 |
| chrisl | henrys: Or even a target debugger. I find it baffling that they can manage without either of those | 17:21.48 |
| | rayjj: (for the logs) the problem with the 8.71 simulator was that the perl.exe in the package wouldn't run (calling it gave "Access denied"). Replacing it with the one from the 9.06 simulator means I can get VS to open the solution now. | 17:22.55 |
| mvrhel_laptop | testing fix for 695916. Issue was caused by the poor method of simulating overprinting of spot colors | 18:49.42 |
| | henrys are you around? | 18:51.27 |
| henrys | mvrhel_laptop: I am | 18:51.39 |
| mvrhel_laptop | I just wanted to let you know that I had been working on 695916. I think I have it figured out and am testing a fix. Then I will get back to gsview. Robin had given me a list of things on gsview that should probably be fixed before the beta. I had hoped to have them done this week but was derailed by the customer issue | 18:53.09 |
| | Hopefully I can get most of them wrapped up this weekend | 18:53.19 |
| henrys | mvrhel_laptop: feel free to assign problems to fredross-perry if he can look at them. | 18:55.20 |
| mvrhel_laptop | ok | 18:57.19 |
| fredross-perry | and please send me anything that needs fixing in the mac/linux versions too. Or, any features hat have crept into the Windows version of late. | 19:00.21 |
| mvrhel_laptop | fredross-perry: yes I will do that today | 19:01.17 |
| fredross-perry | groovy. | 19:01.27 |
| | yes, I went there. | 19:01.34 |
| mvrhel_laptop | fredross-perry: just sent you an email | 19:50.51 |
| | grrr. why am I getting all these cluster timeouts | 19:51.24 |
| | I don't understand how these changes could result in all these time outs. | 20:56.57 |
| | aha! | 20:58.48 |
| | I accidentally committed my transparency debug | 20:59.15 |
| | define | 20:59.18 |
| | marcosw are you there? | 20:59.26 |
| | I may have filled up some significant space on the cluster machines with that test. Unless of course the directory is scrubbed of extra stuff with each build | 21:02.20 |
| rayjj | mvrhel_laptop: at least the "dump" files were png's and not raw | 21:10.48 |
| | mvrhel_laptop: there are tons of "dump###.png" files in ~marcos/cluster | 21:11.28 |
| | mvrhel_laptop: on peeved there were about 1G of them | 21:13.32 |
| mvrhel_laptop | they are raw. | 21:14.36 |
| | those png files are not from me rayjj | 21:14.47 |
| rayjj | interesting | 21:14.58 |
| mvrhel_laptop | not sure where the pngs would have come from | 21:15.15 |
| rayjj | apparently they were created on March 27 | 21:17.05 |
| | mvrhel_laptop: can you have a look at my fix for the transparency+transfer_function bug 695904 ? http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=c12d2ed36726b9717e23c93d30c07f684050ef77 | 21:20.25 |
| mvrhel_laptop | rayjj: That all looks reasonable to me | 21:23.30 |
| | rayjj: can I give you a call | 21:30.34 |
| rayjj | mvrhel_laptop: sure. | 21:32.04 |
| | I may live to regret it, but I agreed to take on mvrhel's overprint issue. :-/ | 21:57.10 |
| | mvrhel_laptop: BTW, can you assign whatever bug that is to me ? | 21:57.23 |
| mvrhel_laptop | will do ;) However, I think we can close this once I rip out the simulated stuff as it is a customer bug. We then should open a new bug about doing it correctly | 21:59.06 |
| rayjj | mvrhel_laptop: but doesn't the customer want it to work ?? | 21:59.34 |
| | SimulateOverprint, that is | 21:59.44 |
| mvrhel_laptop | rayjj: I am not sure that they even realize that is happening | 21:59.54 |
| | it is on by default | 22:00.01 |
| rayjj | or was he just griping because SimulateOverprint defaulted to true and it was messing up | 22:00.13 |
| mvrhel_laptop | yes | 22:00.17 |
| | well maybe we are talking about different bugs | 22:00.38 |
| rayjj | I see. Well, as I said, cust 532 _is_ interested in having it work | 22:00.39 |
| mvrhel_laptop | rayjj: I think we should make it work correctly | 22:01.00 |
| | This bug is really a regression | 22:01.15 |
| | 695916 | 22:01.21 |
| | as the simulation is giving bad output | 22:01.29 |
| rayjj | mvrhel_laptop: agreed. And I don't see any way to do it without the extra buffers as we discussed | 22:01.34 |
| mvrhel_laptop | due to the repeated draws of the same spot color | 22:01.46 |
| | hence I think we close this once I rip out the current simulation | 22:02.18 |
| | and I will open a new bug | 22:02.21 |
| | and reference this one | 22:02.36 |
| rayjj | oh, crud. One thing I just realized is that the 'pdf14_needed' condition where we decide whether or not we need the compositor for a band will also need to track areas that need overprint handling so we can make sure and use the pdf14 compositor | 22:03.00 |
| | I'm sure I will trip across other issues as I dig into this more than during a 15 minute phone call ;-) | 22:05.34 |
| | mvrhel_laptop: OK, I've opened bug 695919 to track the 7.6.4 implementation as an enhancement | 22:25.20 |
| | Forward 1 day (to 2015/04/11)>>> | |
IRC Logs