| <<<Back 1 day (to 2015/03/16) | 20150317 |
sebras | tor8: for the logs: welcome to HN https://news.ycombinator.com/item?id=9213248 | 01:08.55 |
ghostgum | tor8: can you answer a question about git? | 10:36.26 |
kens | What's the question ? Other people (probably not me) might be able to help | 10:37.10 |
ghostgum | I had epstool in the old CVS repository, but it got lost when casper was migrated. I want to put in the current git repository. | 10:38.47 |
kens | I suspect you don't have write privileges in our Git | 10:39.10 |
ghostgum | So the question is what command to use to push the local git that I've just created to user/ghostgum/epstool.git | 10:39.27 |
kens | Ah, your own repo, OK that shoudl be possible | 10:39.53 |
| But my knowledge is weak, I'll let TOr or Robin field iot | 10:40.10 |
Robin_Watts | Morning | 10:40.58 |
tor8 | ghostbot: there is currently no repo in user/ghostgum/epstool.git on casper | 10:41.24 |
ghostbot | tor8: I think you lost me on that one | 10:41.24 |
kens | I thnk tor8 menat ghostgum | 10:41.39 |
tor8 | ghostgum: bah. silly autocompletion :) | 10:41.45 |
kens | eerie conversation though | 10:41.46 |
ghostgum | I want to create that repo. | 10:42.27 |
tor8 | ghostgum: run, in /home/ghostgum/repos: git init --bare epstool.git | 10:42.28 |
kens | I presume ghostgum wants to create an epstool repo | 10:42.30 |
Robin_Watts | ghostgum: Log into casper. cd repos && git init --bare epstool.git | 10:42.33 |
tor8 | then on your local machine: git remote add origin ghostscript.com:/home/ghostgum/repos/epstool.git | 10:43.02 |
| then you should be able to run: git push -u origin master | 10:43.16 |
| -u to 'update' the default | 10:43.22 |
ghostgum | If I've done it backwards, and created the repo locally, can I push it up with | 10:43.33 |
| git remote add origin ghostgum@git.ghostscript.com:/home/git/user/ghostgum/epstool.git | 10:43.47 |
tor8 | ghostbot: that's the way I always work, it's not backwards :) | 10:43.49 |
| /home/git/user/ghostgum is a symlink to /home/ghostgum/repos | 10:44.11 |
ghostgum | git push origin master | 10:44.15 |
tor8 | ghostbot: yes, but you need to initialize an empty repo to push to first | 10:44.43 |
ghostgum | I'll try that now. | 10:45.57 |
| Looks that worked 99% | 10:48.20 |
| Now to fix the description and owner as shown at http://http://git.ghostscript.com/ | 10:48.54 |
tor8 | ghostbot: just edit the file in /home/ghostgum/repos/epstool.git/description | 10:49.24 |
| and add the [gitweb] | 10:50.19 |
| owner = Ghostgum Software Pty Ltd chunk to config | 10:50.19 |
| you can copy that from the gsview.git config | 10:50.34 |
| or run 'git config -l gitweb "Ghostgum ..."' in the bare git directory | 10:51.26 |
| s/gitweb/gitweb.owner/ | 10:51.37 |
ghostgum | Done. Thanks for the help. I haven't used git for a while... | 10:52.09 |
| Should I apply my dscparse.c patch to ghostscript git, or is there a process to be followed first? | 10:53.04 |
kens | Well, Ray was commenting on it, maybe he should review it ? | 10:55.11 |
Robin_Watts | tor8: I've just been asked by a mate... are there plans to bring MuJS up to ES6 ? | 10:59.52 |
ghostgum | Ok, I'll wait. I actually looks like ghostscript has an older version than I thought. | 11:00.40 |
kens | ghostgum : did you forward the patch to Ray to look at ? | 11:01.10 |
tor8 | Robin_Watts: no. ES6 is a horrible monster of complexity and extra features. | 11:01.10 |
| there are transpilers though, 6to5 etc | 11:01.31 |
ghostgum | kens: yes, with cc to support. | 11:02.27 |
kens | ghostgum : I must have missed it..... | 11:05.39 |
| Oh yeah I see it now | 11:05.56 |
ghostgum | It looks like Alex probably fixed the bug in 2013, based on the git comments | 11:05.58 |
kens | Pity he didn't mention it to you.... | 11:06.15 |
ghostgum | Having looked at the commit diff, Alex did fix the crash. My fix also put some range checks in the underlying functions for added security. They would be worth adding. I'll try to send a revised patch to Ray in the next few days. | 11:14.31 |
chrisl | Alex wasn't renowned for communications...... | 11:17.05 |
kens | So... given the time change, meeting in 50 minutes ? | 13:37.27 |
chrisl | Isn't henrys travelling? Or has that not started yet? | 13:38.32 |
kens | Oh yes, he's in Korea, no meeting then I guess :-) | 13:38.46 |
| Explains why he popped up early on IRC today | 13:39.00 |
Robin_Watts | I was assuming no meeting. | 14:20.26 |
| Does anyone have anything for the meeting if there was one? | 14:20.35 |
kens | Not really, I plain forgot Henry was travelling | 14:20.49 |
chrisl | kens: re. your e-mail: couldn't you do the kind of path management using userpaths (that no one ever seems to use)? | 14:22.36 |
kens | Hmm,didn't think of it. | 14:22.55 |
chrisl | Well, as I say, no one ever uses it - I've *never* seen it used in a real job...... | 14:23.26 |
kens | No, me neither | 14:23.33 |
| It look slike it would allow you to save a path at least | 14:23.50 |
chrisl | Well, sort of - it allows you to cache an efficient representation of the path | 14:24.22 |
kens | I guess its a matter of convenience, and the fact that the person posting there seems to like the idea of separate stacks for pretty much everything | 14:24.34 |
fredross-perry | morning | 14:25.23 |
Robin_Watts | morning fredross-perry. | 14:25.32 |
kens | Morning | 14:25.35 |
Robin_Watts | We were just saying that there probably won't be a meeting today as Henry is in Korea. | 14:25.45 |
chrisl | Yeh, I just wonder how useful it would be if you can pretty much already do it, and yet no one bothers | 14:25.47 |
fredross-perry | ok, thanks. | 14:26.02 |
Robin_Watts | fredross-perry: Did you run clusterpush.pl -filter=ppmraw.200.1 ? | 14:26.14 |
kens | No dispute thre chrisl, to be honest almost everything that came up there seemed to me to be 'you can already do that' or 'is there really a use for that ?' | 14:26.30 |
fredross-perry | not yet. I can try that now | 14:26.34 |
Robin_Watts | fredross-perry: Cool. Just going to grab some lunch, and we can look at the bmpcmp -t32 from that afterwards. | 14:26.58 |
rayjj | hurray. No meeting. | 14:31.13 |
kens | Seems not | 14:31.20 |
fredross-perry | folks: do we want/need a 32-bit Linux version of gsview? | 14:33.05 |
chrisl | Yes, definitely | 14:33.29 |
kens | Not sure really. I only have a 32-bit VM which is why I noticed, I don't know what the need for 32-bit is | 14:33.38 |
chrisl | 32 bit is still quite widely used | 14:33.56 |
mvrhel_laptop | ok. no meeting (which I would have been late for). | 14:36.15 |
fredross-perry | so then, which distro? chrislâs is edora, IIRC. | 14:36.24 |
kens | You win then :-) | 14:36.24 |
fredross-perry | *Fedora* | 14:36.32 |
mvrhel_laptop | kens: I am making my way through your list of comments on gsview (windows). Thanks | 14:36.42 |
chrisl | I use Ubuntu, kens uses Fedora | 14:36.44 |
kens | mvrhel_laptop : I noticed the commits or comments on IRC | 14:37.00 |
fredross-perry | would the same binary run on both? | 14:37.02 |
tor8 | Robin_Watts: fredross-perry: like expected, thousands of regression differences when updating freetype | 14:37.04 |
kens | I wouldn't take my comments as gospel, other people may disagree regarding things like where the search entry box is and so on | 14:37.25 |
mvrhel_laptop | I understand, but I do like it on the top too | 14:37.42 |
fredross-perry | tor: yes. Question becomes, whether to update FT and when. | 14:37.57 |
mvrhel_laptop | I just needed someone else to nudge me to do it | 14:38.02 |
chrisl | fredross-perry: Hmmm, I wouldn't rely on it - it's very distribution dependent | 14:38.12 |
kens | Well, I didn't realise it was a the bottom for quite a while, and was on the verge of reporting it as 'search doens't do anything' :-) | 14:38.13 |
tor8 | fredross-perry: now's as good a time as any | 14:38.16 |
mvrhel_laptop | right. that is where your focus is | 14:38.36 |
kens | Indeed, when you push a button at the top, you don;t htink to look at the bottom :-) | 14:39.16 |
| I notice that ghostgum shipped epstool with the original gsview in order to add previews to EPS files, I wonder if we shoul (not in this version) do something similar. SHould we start creating a list or 'pro' or 'version 2' features ? | 14:40.27 |
fredross-perry | I think weâll want to get specific about Linux versions weâre doing, andthose weâre not. | 14:40.45 |
tor8 | linux binary releases are tricky... | 14:41.10 |
kens | THey are yes | 14:41.16 |
fredross-perry | granted. | 14:41.25 |
rayjj | chrisl: sorry I forgot to review your mutex patch yesterday. (1) I think a description of the "theory" of how a GS_RECURSIVE_MUTEXATTR works would be nice (in the code, or at least in the log message). Code preferable, IMHO. (2) In gp_monitor_leave you do: scode = pthread_mutex_lock(mon); Is that right ? | 14:41.27 |
tor8 | libc version differences are bad enough, not to mention if you depend on lots of shared library dependencies | 14:41.32 |
kens | fred was trying to minimise the shared librareis | 14:41.54 |
rayjj | doesn't think so | 14:41.56 |
kens | WHich is a good thing I think | 14:42.04 |
chrisl | rayjj: oh, crap, that is wrong - how did I miss that :-( | 14:42.13 |
fredross-perry | yes, trying to minimize. | 14:42.15 |
tor8 | it's a shame that gnu libc doesn't support static linking :( | 14:42.16 |
malc_ | tor8: huh? | 14:42.34 |
chrisl | tor8: it does - if you hit it hard enough! | 14:42.36 |
tor8 | chrisl: hard enough to break it? | 14:42.47 |
| malc_: you can't (or couldn't, it's been a year since I last tried) build a purely statically linked binary if you use gnu libc | 14:43.07 |
chrisl | tor8: I've managed it, but it wasn't nice. And when Qt is involved, I doubt one of the mini-libc's would work | 14:43.28 |
rayjj | chrisl: so, if I understand it when GS_RECURSIVE_MUTEXATTR is defined, the system supports recursive mutex, otherwise we emulate with 'lcount', right ? | 14:43.46 |
chrisl | rayjj: yeh | 14:43.55 |
tor8 | chrisl: yeah. sometimes I want to propose building against musl (or another mature mini-libc) for our linux releases | 14:44.10 |
| but then my laziness kicks in... | 14:44.16 |
malc_ | tor8: some parts surely do not work, but on the whole... doubtful (checking with one of our toolchain persons rightnow) | 14:44.26 |
rayjj | chrisl: I would prefer a macro like 'RECURSIVE_MACRO_OK' the 'GS_RECURSIVE_MUTEXATTR' didn't really have meaning, and at first I thought that was the for the code for when we had to emulate RECURSIVE MUTEX | 14:45.50 |
chrisl | rayjj: there is an explanation of what it means and how it gets set. I wanted something also meaningful in the context of the makefiles | 14:46.44 |
| rayjj: the problem is that something like "USE_RECURSIVE_MUTEX" suggests a boolean setting | 14:47.55 |
tor8 | malc_: okay, looks like things have improved a bit | 14:48.17 |
rayjj | chrisl: where is the explanation? | 14:48.28 |
rayjj | didn't see it in the patch | 14:48.52 |
chrisl | I added it after - it's in place of the original comment | 14:48.55 |
| /* | 14:49.04 |
| * We need PTHREAD_MUTEX_RECURSIVE behavior, but this isn't | 14:49.04 |
| * supported on all pthread platforms, so if it's available | 14:49.04 |
| * we'll use it, otherwise we'll emulate it. | 14:49.05 |
| * GS_RECURSIVE_MUTEXATTR is set by the configure script | 14:49.05 |
| * on Unix-like machines to the attribute setting for | 14:49.05 |
| * PTHREAD_MUTEX_RECURSIVE - on linux this is usually | 14:49.06 |
| * PTHREAD_MUTEX_RECURSIVE_NP | 14:49.06 |
| */ | 14:49.06 |
rayjj | chrisl: I must be looking at a stale link | 14:50.13 |
kens | It was in the commits I saw go past | 14:50.25 |
chrisl | As I said, I added it after | 14:50.32 |
rayjj | chrisl: sorry. I was using the link from yesterday's log. | 14:51.48 |
chrisl | rayjj: sorry, I've been chasing a memory issue most of yesterday and this morning which turns out to be not related to any of the changes I had queued - so I'm a bit frazzled :-( | 14:52.14 |
fredross-perry | there is a way to distribute specific libraries with an app, by specifying LD_LIBRARY_PATH. Iâm doing this with the Qt libraries currently. | 14:52.31 |
chrisl | fredross-perry: the problem is not all distributions include the 32 bit library versions on their 64 bit dists | 14:53.15 |
| rayjj: the code is the same as on the link from the yesterday, only the comment changed | 14:53.56 |
rayjj | chrisl: so in gp_monitor_leave I think: if ((--((gp_pthread_recursive_t *)mona)->lcount) <= 0) (just in case a caller messes up) then add: ((gp_pthread_recursive_t *)mona)->lcount = 0; along with setting self_id =0 | 14:54.12 |
| self_id = 0 | 14:54.23 |
fredross-perry | I was thinking weâd have separate 32- and 64-bit versions, with separate libraries. And an installer that will sort it out. | 14:54.29 |
chrisl | rayjj: strictly speaking, we should *never* have lcount < 0 | 14:54.51 |
fredross-perry | Or, separate installers | 14:54.59 |
chrisl | Personally, I prefer separate installers, but not dogmatic about it | 14:55.20 |
rayjj | chrisl: yes, agreed. generally I think that system recursive mutexes work that way | 14:55.36 |
| rather than staying 'locked' | 14:56.00 |
chrisl | Why on earth don't the gp_monitor* functions take a gs_memory_t pointer???? :-( | 14:57.32 |
rayjj | fredross-perry: one installer is OK with me as long as we have the option of using 32-bit mode on 64-bit platforms | 14:58.07 |
fredross-perry | why do we want to do that, if we have both? just curious. | 14:58.48 |
rayjj | fredross-perry: some folks like to run 32-bit on all platforms (so they act consistently). It's easier for IT departments | 15:01.18 |
fredross-perry | Hmm. OK. | 15:02.02 |
| Robin_Watts: that bmpcmp is done. Sems legit. | 15:02.39 |
| I am stepping away for a bit. | 15:02.58 |
chrisl | With Ghostscript for Windows, the 32 bit binary downloads still outstrip the 64 bit ones | 15:03.20 |
| rayjj: actually, we can't use "if ((--((gp_pthread_recursive_t *)mona)->lcount) <= 0)" - that would reintroduce the problem I was trying to fix | 15:05.16 |
rayjj | chrisl: can you explain using thread A / thread B example (I don't immediately understand that) | 15:06.40 |
chrisl | You don't need multiple threads for it: we *cannot* safely unlock an unlocked mutex - if lcount < 0 then the mutex should already be unlocked, so if we try to unlock it, we'll crash | 15:07.43 |
rayjj | chrisl: I didn't know the 32-bit was still faster than 64-bit. Do you have percentages ? | 15:08.11 |
chrisl | rayjj: I mean outstrip in terms of download numbers..... | 15:08.38 |
rayjj | chrisl: OK (on both issues). | 15:09.13 |
| so if lcount goes < 0 we should warn or assert ? or just set it to 0 along with setting self_id = 0 ??? | 15:10.35 |
chrisl | rayjj: we can't warn, there's no memory context to use to print something | 15:11.35 |
rayjj | chrisl: we have nomem print functions, that *probably* work. | 15:12.44 |
chrisl | rayjj: we're not supposed to be using those now | 15:13.00 |
rayjj | chrisl: but I don't feel strongly about it | 15:13.09 |
| I have to run my son to school now. | 15:13.18 |
| bbiab... | 15:13.23 |
| (sorry) | 15:13.27 |
chrisl | Can't even gs_abort() as it needs a gs_memory_t parameter as well :-( | 15:14.38 |
Robin_Watts | tor8: Take a look at freds bmpcmp. He's updating freetype to the latest. | 15:26.05 |
| Interesting ones are 95, 111 and 112 | 15:34.24 |
| chrisl: What version of freetype are we using in gs? | 15:35.04 |
chrisl | Erm...... | 15:35.16 |
Robin_Watts | Are you planning to upgrade to 2-5-5 for the next release? | 15:35.17 |
chrisl | No, planning to update to 2.5.5 *after* the next release | 15:35.30 |
Robin_Watts | fred has just looked at that for mupdf, and we get 3 files with meaningful changes. | 15:35.35 |
kens | Bug687311.pdf renders blank (with an error) in Acrobat | 15:35.39 |
| GS draws the glyp[h | 15:36.06 |
chrisl | Looks like we have 2.4.9 in gs | 15:36.09 |
kens | Acrobat refuses to deal with the font in that file | 15:36.47 |
Robin_Watts | kens: yeah, I think if we updated freetype in gs, we'd get the same as mupdf (and acrobat) | 15:36.47 |
kens | Probably, it looks like the font is knackered in some way | 15:37.05 |
chrisl | Don't forget that in gs we recreate the font before passing it onto freetype | 15:37.29 |
kens | GS matches Acrobat for bug698372.pdf whihc is it writes 'Rwanda (genocide)' etc | 15:38.12 |
| Bug689516 is massive, its impossible to tell where those little flecks are really | 15:39.11 |
| Looks like Acrobat doesn't draw them | 15:40.26 |
| GS complains that the loca length is greater than the numGlyphs in one font | 15:40.56 |
| It doesn't seem to draw the little flecks | 15:41.13 |
| The little marks seem to be in Arial,Italic, which is the font GS complained about | 15:42.23 |
tor8 | lomot, I ju-n las ntan | 15:44.14 |
| argh, off-by-one | 15:44.17 |
| Robin_Watts: I just ran a bmpcmp with the newest freetype as well | 15:45.40 |
| Robin_Watts: how do you spot the meaningful changes? | 15:45.49 |
Robin_Watts | tor8: fred ran a test with -filter=ppmraw.200.1 and then bmpcmp -t32 and then I looked by hand :) | 15:49.03 |
tor8 | Robin_Watts: I found 3 files on the first 2 pages | 15:50.37 |
Robin_Watts | tor8: different to the ones I spotted? | 15:52.09 |
tor8 | Robin_Watts: ah, no. the same ones. | 15:53.15 |
| odd, Bug693279 is a file that gs handles but mupdf and evince fails on | 15:53.32 |
Robin_Watts | gs is using old freetype. | 15:53.43 |
tor8 | 253 | 15:53.50 |
kens2 | THat's a broken font, Acrobat opens it balnk and complains about the font | 15:53.51 |
| Its possible GS would handle it even with a new FT | 15:54.09 |
| Because, as Chris says, we rebuild the font first | 15:54.18 |
| But if its bad enough that Acrobat won't open it, I'd say you can happily have it blank | 15:54.57 |
tor8 | Robin_Watts: fredross-perry: I'm happy enough with the regressions/progressions to give a thumbs up to updating freetype | 15:59.08 |
Robin_Watts | tor8: cool. I feel the same. | 15:59.38 |
fredross-perry | all righty then. Thanks. So, gs uses FT as well? Should we look at that too? | 15:59.59 |
| how do I push mupdf to golden? | 16:01.00 |
chrisl | I'll not be updating ft for gs until after the pending release | 16:01.03 |
Robin_Watts | fredross-perry: First do: git pull --rebase golden master | 16:04.04 |
| That'll check that you've got all the changes in master. | 16:04.15 |
| Then do: git push golden master | 16:04.22 |
fredross-perry | ok stand by. | 16:04.30 |
| and golden is git://git.ghostscript.com/mupdf.git, yes? | 16:06.18 |
Robin_Watts | robin@ghostscript.com:/home/git/mupdf.git | 16:07.51 |
tor8 | fredross-perry: git:// is read-only | 16:07.52 |
| you need to change the url (git remote set-url golden .....) to what robin just pasted | 16:08.06 |
| but with your username instead :) | 16:08.31 |
fredross-perry | OK, I think I did that. Take a look. | 16:18.07 |
Robin_Watts | looks good. | 16:20.46 |
fredross-perry | whee! | 16:20.56 |
Robin_Watts | I should have encouraged you to mention the bug that it solved in the commit message. | 16:21.26 |
| Too late now :( | 16:21.31 |
fredross-perry | doe git allow you to edit commit messages? | 16:22.11 |
| git commit --amend -m "New commit message" | 16:22.41 |
Robin_Watts | fredross-perry: It does, but not once pushed to golden. | 16:22.59 |
fredross-perry | feh. | 16:23.15 |
Robin_Watts | (rather, our policy is that we don't change stuff once it's gone to golden. Except on sundays, when the moon is full, with a following wind, or when we really want to) | 16:23.38 |
fredross-perry | So noted. | 16:24.27 |
| out for a bit, back in 20⦠| 16:26.09 |
Robin_Watts | tor8: I made myself a 6gig pdf file yesterday. | 16:32.14 |
| I have a 32bit build of mupdf accessing it correctly now :) | 16:32.29 |
fredross-perry | back. | 16:42.30 |
mvrhel_laptop | Robin_Watts: are you around? | 18:18.39 |
Robin_Watts | I am. | 18:18.46 |
mvrhel_laptop | would it be easy for you to supply me with the latest smart office apk? | 18:19.04 |
Robin_Watts | Sure. | 18:19.19 |
mvrhel_laptop | I am heading to San Francisco tomorrow to this thing for miles | 18:19.26 |
| and I need to update the apk on the nexus 10 | 18:19.35 |
| Thanks! | 18:19.44 |
Robin_Watts | mvrhel_laptop: OK, so the easiest way is probably for you to grab an autobuild... | 18:19.50 |
| Let's move to skype? | 18:20.09 |
mvrhel_laptop | Robin_Watts: ok. sound good | 18:20.14 |
| hold on | 18:20.16 |
| ok. pushed a pile of fixes up to gsview. no doubt there are more to do, but done for the day as I want to get ready for tomorrow | 19:32.19 |
Robin_Watts | mvrhel_laptop: is that still on the mupdf repo? | 19:34.05 |
| or is it separate now? | 19:34.16 |
| ok, it's separate, and you're pushing to golden directly. | 19:36.01 |
| So no reviews for gsview then? | 19:36.11 |
| Forward 1 day (to 2015/03/18)>>> | |