| | <<<Back 1 day (to 2018/05/16) | 20180517 |
| kens | That's a good piece of detective worjk there chrisl | 13:34.45 |
| chrisl | kens: If that turns out to be the problem..... | 13:35.48 |
| kens | It seems likely :-) | 13:35.56 |
| chrisl | Of course, as I said, if the app or the middle-ware library (whichever) wasn't swallowing the backchannel, it would have been immediately clear what the problem was | 13:36.43 |
| kens | Yes of course, its amazing how often we *don't* get the back channel output when bugs are reported | 13:37.04 |
| | Realistically the bug should have been raised with qpdf who could have raised it with libspectre etc. | 13:37.35 |
| chrisl | I'd guess the qpdfview people would say "use the shared lib" | 13:38.13 |
| kens | And I wouldn't blame them for that either | 13:38.23 |
| chrisl | So, I went to install "Windows Subsystem for Linux" - and, yeh, doesn't work...... | 13:39.46 |
| kens | Oh really ? | 13:39.54 |
| | Just missing X server ? | 13:39.59 |
| chrisl | When I run "bash" it says there's no distribution installed, and a link to the Windows store. | 13:40.40 |
| kens | Umm, well I don't actually have Windows 10, so... No idea. | 13:41.02 |
| chrisl | Go to that link, select Ubuntu, click "Get" - the page refreshes, and nothing installs | 13:41.07 |
| kens | Ah, how wonderfully Microsoft :-) | 13:41.19 |
| chrisl | I may just stick with cygwin after all.... | 13:41.56 |
| kens | I'm sticking with a VM :-) | 13:42.08 |
| tor8 | I found the windows subsystem to be dreadfully slow at filesystem i/o operations | 13:42.37 |
| chrisl | tor8: I've found that with cygwin and msys, too | 13:43.04 |
| tor8 | ...before I zapped it and installed debian proper. | 13:43.08 |
| | yeah. I think the windows filesystem is just slow to begin with. | 13:43.21 |
| | I found it much faster to work and build inside a VM like virtualbox | 13:43.46 |
| chrisl | Building GhostPDL in a VM... that takes dedication | 13:45.24 |
| kens | I've not found it impossibly slow | 13:46.32 |
| chrisl | I certainly found it took ages in a Windows VM, and even worse when it was on a shared drive | 13:47.48 |
| kens | Its not quick I grant you | 13:48.02 |
| | But its not outrageously slow either, it does take a few minutes | 13:48.15 |
| | But the, so does a full VS build | 13:48.33 |
| ray_laptop | The problem is that we use nmake for the VS build, so it doesn't run multiple threads (as we do on a linux make with -j) | 17:11.04 |
| chrisl | ray_laptop: that's part of it, but I do find the disk accesses on VMs rather slow, and that slows building a lot | 17:15.48 |
| | I was definitely disk bound rather than cpu bound | 17:16.08 |
| ray_laptop | chrisl: are you using VMWare or something else. VMWare works pretty well for me (but I've got SSD, so that helps) | 17:18.04 |
| chrisl | virtualbox | 17:18.14 |
| ray_laptop | you may want to try VMWare | 17:18.51 |
| | if the performance is an issue | 17:19.09 |
| chrisl | I would, but converting VMs is a pain! And I have a laptop for Windows, so I only really use the VMs for testing, at the moment | 17:19.42 |
| | Next time I change my desktop, I'll probably switch to VMware | 17:20.17 |
| ray_laptop | chrisl: BTW, I was curious and tried msvclib.mak -- I have a patch ready if you'd care to comment (it was seriously bit-rotted) pushed to my repos. Note that I don't think I've used it for a decade, so I didn't recall that it doesn't actually build a .lib (I didn't change/fix that) | 17:22.37 |
| | I mainly pulled stuff from msvc.mak | 17:23.26 |
| chrisl | ray_laptop: IIRC, it was used to build the graphics library object files for the old pcl/xps builds | 17:24.15 |
| ray_laptop | What it does is build the gslib.exe (the lib test file), so it is intended for anybody that wants to use the graphics lib calls | 17:25.40 |
| chrisl | ray_laptop: I'll assume you've confirmed those msvclib.mak changes work, so I'm fine with them - there's nothing in there that leaps out as problematic | 17:26.14 |
| ray_laptop | chrisl: I guess I should make sure that it builds with other VS versions (only tested with VS 2015) | 17:27.06 |
| chrisl | ray_laptop: ultimately, we should probably decide if we want to keep the capabilities in msvclib.mak, and if so, integrate it into msvc.mak - save this kind of bitrot happening again | 17:28.32 |
| ray_laptop | maybe so. Also get it to build a .lib | 17:33.15 |
| | OK, tested that it works with VS2005 and VS2008. Good enough | 17:43.15 |
| | Forward 1 day (to 2018/05/18)>>> | |
Log of #ghostscript at irc.freenode.net.