| | <<<Back 1 day (to 2018/05/17) | 20180518 |
| granttrec1 | is there now way to install via distribution repos, just install via source? | 02:18.32 |
| granttrec | nvm its in the repos my mistake | 02:56.40 |
| moolc | tor8: same question | 08:21.05 |
| tor8 | moolc: fix on tor/master | 08:27.30 |
| moolc | tor8: bra! | 08:27.40 |
| tor8 | it still doesn't render as you would want, because we don't support CSS styling in SVG | 08:27.48 |
| | you want to save as "plain" svg from inkscape | 08:28.00 |
| moolc | i was mainly concerned with SEGV | 08:28.09 |
| | getting "proper" SVG rendering is not gonna happen i realize that | 08:28.29 |
| tor8 | that said ... we do have a css parser available, so if we were to spend some effort it could be possible | 08:28.45 |
| | SVG just hasn't been a high priority | 08:28.52 |
| moolc | you would have to define "proper" first | 08:29.08 |
| tor8 | not with all the cruft that's been added with CSS and javascripting etc | 08:29.12 |
| moolc | tor8: can i remove the files from the server? | 08:29.33 |
| tor8 | moolc: yes, I've got them saved. | 08:29.47 |
| moolc | cool | 08:30.06 |
| inflex | I don't suppose anyone has created a zoom-at-mousepoint snippet at all? I can't seem to get my head around the different coordinate systems at the moment (between X11 + GLUT + pdf page). | 08:38.13 |
| moolc | i have.. not in mupdf-gl context though | 08:43.03 |
| inflex | ja, I've done it in SDL/ImGui context... but for some reason cannot make it work in mupdf-gl... yet | 08:45.34 |
| moolc | the thing i did is using mupdf the library | 08:46.20 |
| | just doesn't touch the tools | 08:46.25 |
| inflex | A side question too, I cannot pin down the routine that shades the search results in pink/orange within mupdf-gl. I was hoping to add to it so it'll put a box (or change colour) depending on which index in the bbox list I'm selecting from the search list. | 08:47.04 |
| | btw, apologies if these questions are not relevant to the context of this channel. | 08:47.33 |
| moolc | inflex: zooming - https://www.youtube.com/watch?v=P6cUPjGvSGg&l&t=13 | 08:47.55 |
| inflex | ( I am reading the mupdf_explored.pdf atm) | 08:48.15 |
| moolc | inflex: Robin_Watts authored | 08:48.42 |
| | it | 08:48.43 |
| tor8 | inflex: in platform/gl/gl-main.c where the currentzoom variable is changed, you'd want to also adjust the scroll_x and scroll_y variables to keep a specific point centered | 08:48.56 |
| | inflex: search results are displayed in the do_search_hits() function | 08:49.27 |
| inflex | thanks for the pointer tor8 - I must just have one of those "one off" signing of type bugs. | 08:49.29 |
| | *blink* HOW did I not see that function before tor8 :( Thank you! | 08:50.27 |
| | Fantastic, at least the search-highlight thing is now working. | 08:57.02 |
| tor8 | inflex: look at tor/master for another commit that might help you with your zoom issues | 09:07.26 |
| inflex | Thanks. | 09:09.21 |
| | I think some of the problem I'm encountering is that when the canvas expands to the limits of the GL window, the scrolls_x/y fz clamping takes effect overrides the offsets; I tried removing the clamping but then the whole page disappeared. Clealy I have a lot more to learn about this muPDF | 09:56.30 |
| tor8 | inflex: if the page is smaller than the canvas it will be forced centered | 09:57.48 |
| inflex | Might disable that (force centering) for now. | 09:59.48 |
| tor8 | inflex: in do_canvas() the if (page_tex.w <= canvas_w) statement is where you want to poke around then | 10:18.02 |
| avih | tor8: did something change in mujs.pc file recently? mpv checks for mujs >= 1.0 using pkgconf, and it now failed to detect it. the version at the .pc file is now cbdf814 which apparently doesn't count as >= 1.0 | 11:15.26 |
| | i'm pretty sure it didn't have this issue not long ago - while building git master | 11:16.12 |
| | i don't _think_ i always just happened to be on a release tag on the master branch tip. | 11:16.49 |
| tor8 | avih: the mujs.pc version number is taken from the git. unless you're on a release tag then it will be formatted in a different way. | 11:17.16 |
| | tor/master should have the version number as: 1.0.3-8-g0fce5eb | 11:17.41 |
| avih | but i was always on HEAD, and never had this issue in the past... | 11:17.43 |
| tor8 | 1.0.3, plus eight more commits, git checksum 0fce5eb | 11:17.57 |
| avih | right, but mine is not 1.0.3-foo-bar. it's just Version: cbdf814 | 11:18.19 |
| tor8 | avih: what says git describe --tags --always | 11:18.42 |
| avih | just the hash. hmm, i do have shallow clone though | 11:19.16 |
| tor8 | and also "git tag -l"? | 11:19.30 |
| avih | but still, i haven't changed it | 11:19.32 |
| tor8 | that would probably explain it -- then you don't have the tags that 'git describe' needs to format the version number | 11:19.51 |
| avih | this does show 1.0.0 and .1 and .2 and .3 | 11:19.59 |
| tor8 | well, a shallow clone is missing the history, so maybe it can't trace the ancestry of your commit to the tag? | 11:20.40 |
| avih | but git tag -l does show the tags. again, i haven't changed the setup. previously it was detected as >= 1.0 | 11:20.41 |
| tor8 | avih: can you checkout a tag? | 11:20.48 |
| avih | probably not, but let me try | 11:21.02 |
| | yeah, i can | 11:21.17 |
| tor8 | and git describe on that tag? | 11:21.25 |
| avih | but the history from head doesn't reach the tab. it only goes 2 commits back - and none of tem is the tag | 11:22.04 |
| | tag* | 11:22.10 |
| | $ git describe --tags | 11:22.50 |
| | 1.0.3 | 11:22.51 |
| | but just git describe gives: | 11:23.05 |
| | $ git describe | 11:23.06 |
| | fatal: No annotated tags can describe '25821e6d74fab5fcc200fe5e818362e03e114428'. | 11:23.06 |
| tor8 | avih: on your master checkout. git log --oneline HEAD | 11:23.14 |
| | does it say "grafted" there? | 11:23.17 |
| avih | iirc yes | 11:23.24 |
| tor8 | cause that would explain why it can't trace back to a tag to describe | 11:23.26 |
| avih | yes | 11:23.32 |
| tor8 | so, don't use shallow clones (or if you must, make sure to have it deep enough to reach the tag) | 11:23.51 |
| avih | as i said, the history from HEAD only goes back 2 commits (my shallow depth) and doesn't reach a tag | 11:23.53 |
| tor8 | the mujs.pc depends on git finding the tag to give you a proper version number | 11:24.18 |
| avih | i realize that. so previously i was just lucky? | 11:24.55 |
| | so there are no version files as part of the archive itself? | 11:25.37 |
| | as part of the *files* | 11:25.45 |
| tor8 | correct. if you are building from not-a-git directory (such as a tarball archive) it will pick up the version name from the directory name. | 11:26.53 |
| | mujs.pc is created as part of the build step | 11:27.30 |
| avih | i know when it's created. so for a tarball it looks at the tar/dir name? that's a bit meh, isn't it? | 11:28.11 |
| tor8 | shrugs. | 11:28.20 |
| avih | tor8: you think it'd be a bad idea to keep a VERSION which will be used at the PC and updated manually whenever you tag a release? | 11:30.46 |
| tor8 | avih: I dislike having redundant information that needs to be kept manually in check. What we have now is good enough, IMO. | 11:56.18 |
| | Robin_Watts: a handful of commits on tor/master for review, if you got a moment. | 11:57.10 |
| avih | i don't disagree about redundancy, though the tarball dirname thingy is quite meh imo. | 11:57.23 |
| | and apparently shallow clones are affected, and don't have the dir name.. | 11:57.45 |
| tor8 | shallow clones are a terrible hack; and when the full history of mujs.git still results in a <1Mb repository I really don't see why you'd use a shallow repository with all the caveats and breakage such repos involve. | 11:59.41 |
| Robin_Watts | tor8: "Fix segfault in SVG parser when encountering text data." | 12:00.15 |
| | Could maybe do with a tag more explanation in the commit message? | 12:00.29 |
| | Isn't text data rather common? | 12:00.39 |
| | Other than that, all lgtm. | 12:01.58 |
| tor8 | Robin_Watts: can do. updated commit there now. | 12:02.12 |
| | fz_xml_tag returns NULL for non-tag elements (i.e. the text nodes) | 12:02.24 |
| avih | tor8: i don't know about being a hack, but it does have its use case, though clearly not for mujs being a very small repo. i just had this build system where all projects are shallow, and it worked till now. i already modified mujs to not do shallow, but it could bite others too. anyway, fyi. | 12:03.14 |
| tor8 | fz_xml_is_tag is a better function, which I believe I added after writing the original code and never retrofitted onto it. | 12:03.17 |
| | avih: are you telling me that there's a build system that uses pkgconfig for non-system dependencies? ick! :) | 12:04.07 |
| avih | yes, because mpv sometimes need new packages which are not provided by the distro (mujs typically being one of them, but recent ffmpeg version frequently is too), it creates a custom prefix and installs these uncommon/latest deps in there and adjusts PKG_CONFIG_PATH such that mpv finds the correct libs | 12:05.39 |
| | then links mpv statically with those libs such that you don't need to maintain conflicting system libs | 12:06.21 |
| | (this is mostly true for ffmpeg) | 12:06.37 |
| | and that's the updated config file to not use shallow with mujs https://github.com/avih/mpv-build/commit/8ee0ae56 | 12:07.41 |
| tor8 | avih: I would suggest such a build system to always grab a specific version, not just the master | 12:08.47 |
| | because who knows what breakage could slip in on a random commit that hasn't been tagged as a stable release | 12:09.23 |
| avih | tor8: it can, but by default all packages are configured to gram HEAD | 12:09.25 |
| | grab* | 12:09.31 |
| tor8 | nitpicking here, but HEAD is the name for the currently checked out commit ... you mean master don't you? | 12:09.55 |
| avih | i could have configured it also to use the latest release tag, it a specific tag etc. | 12:10.04 |
| | no, i mean upstream's head | 12:10.16 |
| | which is typically master, but not always | 12:10.27 |
| tor8 | that sounds even scarier... | 12:11.03 |
| avih | for instance in luajit upstream's HEAD is the latest release branch iirc, while master is the dev branch. again _IIRC_ | 12:11.08 |
| tor8 | but I guess that could be one way to do it | 12:11.21 |
| avih | whatever upstream defines as its HEAD, that's how the projects are configured to update by default. | 12:11.44 |
| inflex | tor8, I got the zoom in working fine now, perhaps slightly cumbersome, and some double->int rounding issues, but overall working great | 12:11.58 |
| avih | and shallow. which has a big impact with huge projects like ffmpeg etc | 12:12.09 |
| | especially if you use it in a docker thingy and do everything from scratch. | 12:12.39 |
| tor8 | avih: that's interesting, I may just have learned something new about git today! | 12:12.57 |
| avih | (otehrwise shallow or not typically affects only the close, but has way less impact on updates) | 12:13.09 |
| | clone* | 12:13.23 |
| tor8 | avih: if you fetch from mujs.git (the main repo, on ghostscript.com) that should now have a release branch and HEAD should be set to that | 12:14.09 |
| avih | oh? :) | 12:14.27 |
| | that's uncommon though. in the vast majority of projects HEAD is the main dev branch, or "trunk", while releases are tagged/branched | 12:15.19 |
| tor8 | avih: I only have one branch ... the development branch. | 12:15.58 |
| | but I'm happy enough to have a release branch that just points to the latest tagged release | 12:16.22 |
| inflex | Seems learning "Best practices" in git is quite a learning journey in itself. | 12:16.49 |
| | I'm a complete disaster with git :( | 12:16.56 |
| moolc | inflex: if you will find a person who isn't please share his identity | 12:17.19 |
| avih | tor8: wait, so the main repo's HEAD is now 1.0.3 ? which branch is that? and where are the commits beyond 1.0.3 ? | 12:17.31 |
| inflex | moolc, it's hard enough just getting up to speed with other people's codebases (as opposed to "I'm gonna change everything!"), let alone acquiring git skills along the way. Maybe in 15 years more I'll be reasonable at it. | 12:19.12 |
| avih | hmm.. so this is now 1.0.3 http://git.ghostscript.com/?p=mujs.git;a=summary not great IMO | 12:19.23 |
| tor8 | avih: the main repo has two branches: master and release, several tags: 1.0.x, and HEAD points to release | 12:19.25 |
| inflex | ( and now I've completely ruined the purity of what was mupdf-gl ) | 12:19.47 |
| tor8 | avih: ugh. yeah. not ideal. | 12:19.49 |
| moolc | inflex: the lesson here is - don't mess with other peoples codebases | 12:20.00 |
| | write everything yourself | 12:20.07 |
| avih | tor8: the convention that HEAD is master is a pretty strong one IMO | 12:20.21 |
| inflex | moolc, I like your style. | 12:20.22 |
| tor8 | inflex: I *significantly* rewrote big chunks of mupdf-gl on my 'ui' branch | 12:20.23 |
| | avih: yeah. | 12:20.34 |
| moolc | inflex: thank you, it took me years | 12:20.52 |
| avih | but it's fine to have a release branch too | 12:20.53 |
| inflex | tor8, oh okay, I don't feel so bad then. I basically selected different primary tasks based on the anticipated workflow | 12:20.57 |
| tor8 | avih: would a 'release' branch that just sits on the latest commit work for you (then you can ask the build system to just get the latest 'release' branch) | 12:21.22 |
| moolc | inflex: have you tried llpp, i mean.. you like my style and all that | 12:21.36 |
| tor8 | inflex: the 'ui' branch adds an annotation editing UI (and the IMGUI stuff that's needed for it) | 12:21.55 |
| avih | (in my update config, pointing it to upstream's master branch would have been "^master" ) | 12:22.09 |
| inflex | tor8, orconut's ImGui? | 12:22.46 |
| tor8 | inflex: no. homebrewed (the way it's supposed to be done...) | 12:23.06 |
| | I'm not touching C++ | 12:23.15 |
| | Robin_Watts: thanks. | 12:24.04 |
| avih | tor8: any configuration would work, and my update config is very flexible. see here how it can be configured to be basically anything https://github.com/avih/mpv-build/blob/mpv-build-rewrite/config/default.conf#L74 | 12:24.06 |
| | but it's not about me. it's about following common conventions. | 12:24.18 |
| moolc | yeah | 12:24.26 |
| | mupdf is known for that | 12:24.31 |
| | following conventions | 12:24.34 |
| inflex | tor8, right, wasn't sure; since I see IMGUI both as that project, and the type of GUI. | 12:24.53 |
| | I must say, that is what I found very pleasing with mupdf... the C. I'm working a medium project here that's done in C++ and I just find it a never ending tangle. | 12:26.53 |
| tor8 | inflex: we try keeping it simple. we don't always succeed, though.... | 12:28.21 |
| moolc | inflex: apparently the authors of the tangles haven't cloned and studied https://github.com/isocpp/CppCoreGuidelines/ C++ | 12:28.34 |
| | is wonderful | 12:28.39 |
| | fluffy and modern | 12:28.44 |
| avih | inflex: agreed, and tor8 generally has a sense for clean C code :) | 12:29.34 |
| inflex | It certainly made my life considerably easier, so again, thank you ( I still will always code in C given a choice, assuming it's reasonably appropriate ). | 12:31.22 |
| moolc | inflex: bear in mind that mupdf has a hard dependency on C++ library.. and is written in a language most compilers for which are written in C++ (gcc/clang/msc) | 12:32.47 |
| | so uhm | 12:32.49 |
| | transitively mupdf is a C++ project | 12:33.02 |
| tor8 | moolc: thankfully harfbuzz doesn't depend on the C++ standard library. If it did, we'd likely ditch it. | 12:34.16 |
| moolc | tor8: give it time | 12:35.23 |
| | and you rejected my pitch for a C library back in the day | 12:35.35 |
| tor8 | opentype layout is a thorny problem. harfbuzz is at least mature and well bashed on. can't quite remember which library you advocated for, how is it doing these days?L | 12:36.37 |
| moolc | tor8: m17n is doing well i suppose... emacs is still using it | 12:37.06 |
| avih | tor8: under normal workflow, the remote HEAD affects mostly the initial clone - as it checks out the branch pointed to by the remote HEAD. so before you restored the repo to point to master, if you cloned it, you'd have ended up with the release branch checked out | 12:40.37 |
| tor8 | moolc: LGPL is problematic for our commercial customers. | 12:41.07 |
| | avih: yes. that's why I changed it back. | 12:41.54 |
| avih | aye | 12:42.16 |
| moolc | tor8: oh.. yeah fair point.. harfbuzz is mit never knew that | 12:43.10 |
| tor8 | moolc: I suspect that's the main reason I didn't investigate m17n more thoroughly (but it's been a while, my memory of distant events is not so good) | 12:43.50 |
| avih | (that's because "distant" changes its semantics as you amass years!) | 12:44.45 |
| moolc | tor8: another thing might have been m17n reliance on external files for it's shaping magic.. hb sorta expects decent in-font machinery (not always the case mind you) | 12:45.00 |
| inflex | Is there a "Bring to the top" FreeGLUT call in Windows? I've tried pop/push without luck. | 12:54.59 |
| tor8 | inflex: glutPush/PopWindow are no-ops in windows on freeglut | 12:57.54 |
| inflex | That explains that then. I thought I was just coding it wrong. | 12:58.09 |
| tor8 | I don't think there is an equivalent Win32 call to XRaise/LowerWindow | 12:58.17 |
| inflex | in SDL I have SDL_RaiseWindow(), in GDI I have BringWindowToTop( hwnd ); (if I save the hwnd from the FreeGLUT window var ) | 12:59.27 |
| | Will have to leave that feature for another year. | 13:00.10 |
| tor8 | freeglut is pretty easy to modify | 13:00.49 |
| | adding the missing functions shouldn't be too hard | 13:00.55 |
| inflex | I'll get other things sorted out first. Too many fingers in pies now. | 13:02.30 |
| | regarding mupdf-gl, why does the "manual" decoding of the button states to determine wheel actions work in *nix/X, but not in windows (in windows I have to set glutMouseWheelFunction() to on_wheel(), but in X have to keep it as on_mouse() . | 16:05.08 |
| | Forward 1 day (to 2018/05/19)>>> | |
Log of #mupdf at irc.freenode.net.