| | <<<Back 1 day (to 2017/06/02) | 20170603 |
| dinamic | Hi, I'm currently working on a rustc bindings for mujs and stumble upon complications with newcfunction and the callback | 00:51.37 |
| | I cant find a way to pass along a userdata for the function which can be read in the callback impl. , any ideas ? | 00:52.44 |
| RobinWattsLenovo | You need tor8 (or possibly avih), but tor8 is travelling at the moment, so may be distracted. | 01:16.46 |
| tor8 | dinamic: there's no generic userdata attached to functions | 01:19.18 |
| | dinamic: but you can set put some properties on the function object | 01:19.55 |
| | see the implementation of bound functions in jsfunction.c for some ideas | 01:20.26 |
| mrottenkolber | Hi! Iâm trying to build mupdf-gl on slackware, I have glfw3-3.1.1, but I get lots of these: | 16:01.01 |
| | build/release/platform/gl/gl-input.o: In function `ui_input': | 16:01.02 |
| | gl-input.c:(.text.ui_input+0xe3): undefined reference to `glColor4f' | 16:01.02 |
| | any hint what I might be missing? | 16:01.21 |
| | This is the command in error: cc -Wl,--gc-sections -Wl,-s -o build/release/mupdf-gl build/release/platform/gl/gl-font.o build/release/platform/gl/gl-input.o build/release/platform/gl/gl-main.o build/release/libmupdf.a build/release/libmupdfthird.a -lm -lfreetype -lharfbuzz -ljbig2dec -ljpeg -lopenjp2 -lz | 16:02.00 |
| | I enabled the build via HAVE_GLFW=yes | 16:02.25 |
| | I think I might be missing some -l needed? | 16:02.56 |
| malc_ | mrottenkolber: your cc command line lacks -lGL hence linker error | 16:04.03 |
| mrottenkolber | ah thanks! | 16:04.23 |
| | hmm how do I get the Makefile to include it though? | 16:09.05 |
| | malc_: not sure I am doing it right, the Makefile has no mential of libGL at all... | 16:15.40 |
| | how I enable the build to link with it? | 16:15.52 |
| | oh, XLIBS? | 16:16.44 |
| malc_ | mrottenkolber: for me it always picked it up automatically, not sure how you build your stuff | 16:18.18 |
| mrottenkolber | weird though that this isnât implied whith HAVE_GLFW=yes, no? | 16:18.20 |
| | malc_: other from not using thirdparty/, standard make | 16:19.11 |
| malc_ | mrottenkolber: uhm, so you are trying to use your system supplied libraries to build stuff, right? | 16:19.47 |
| mrottenkolber | yes | 16:19.51 |
| malc_ | mrottenkolber: sorry can't help you there, never tried it | 16:20.33 |
| mrottenkolber | malc_: could you show me how your "cc -Wl,--gc-sections -Wl,-s -o build/release/mupdf-gl build..." command line looks like? | 16:21.18 |
| | I seem to be missing more than just -lGL | 16:21.31 |
| malc_ | mrottenkolber: you miss a whole lot if you are not using thirdparty.. harfbuzz for instance | 16:22.02 |
| mrottenkolber | no, not missing that. I can build without HAVE_GLFW fine, I think its just the -l<GLSTUFF> thatâs missing | 16:23.15 |
| | glut? | 16:23.29 |
| malc_ | nope | 16:23.33 |
| mrottenkolber | thatâs why Iâm aksing/looking for what the arguments should be, or how they are usually set | 16:24.08 |
| | oh Iâm a dummy I should just look at glfw dependencies | 16:25.25 |
| malc_ | mrottenkolber: fwiw cc -Wl,--gc-sections -Wl,-s -o build/native/mupdf-gl build/native/platform/gl/gl | 16:27.24 |
| | -font.o build/native/platform/gl/gl-input.o build/native/platform/gl/gl-main.o b | 16:27.24 |
| | uild/native/libmupdf.a build/native/libmupdfthird.a build/native/libglfw.a -lm | 16:27.24 |
| | -lGL -ldl -lX11 -lXcursor -lXrandr -lXinerama -lpthread | 16:27.24 |
| mrottenkolber | yep: /usr/lib64/pkgconfig/glfw3.pc: Requires.private: x11 xrandr xinerama xi xxf86vm xcursor gl | 16:28.44 |
| | Ok, so the outline is nice. Any way to change its width (it doesnât wrap lines)? | 16:48.21 |
| | i.e. scroll horizontally | 16:48.28 |
| malc_ | mrottenkolber: ask tor8 who just joined he's an author | 16:51.16 |
| tor8 | mrottenkolber: building is a lot easier if you use the included thirdparty libraries instead of trying to use the system libraries | 16:52.49 |
| | often the system libraries are incompatible versions, etc. | 16:53.00 |
| | mrottenkolber: sadly, no, the outline view is not resizable or scrollable yet. | 16:53.15 |
| | I intend to make it resizable, but haven't got around to it. | 16:53.24 |
| mrottenkolber | by the way: mupdf is great stuff, Iâve used it on Linux for years and now also on iOS | 16:54.00 |
| tor8 | Robin_Watts: fix for the pdfgraft api with mutool run on tor/master | 16:54.08 |
| | mrottenkolber: glad to hear it! :) | 16:54.24 |
| mrottenkolber | do I get this right? Artifex is a for profit developing mupdf, the state of the art PDFÂ renderer, as AGPL software, and license non-copyleft to business? | 16:55.15 |
| | thatâs a pretty laudable business. | 16:56.12 |
| | How do you deal with contributions/copyright? | 16:56.14 |
| tor8 | Correct. We require copyright assignments for non-trivial contributions. | 16:56.48 |
| mrottenkolber | to Artifex Software, Inc.? | 16:57.28 |
| tor8 | We also develop and license Ghostscript the same way. | 16:57.39 |
| jogux | yeah. lots of projects do similar things - agreement is linked at the bottom of https://www.artifex.com/developers-mupdf/ | 16:57.44 |
| mrottenkolber | good to hear, Iâm also a firm believer into AGPL-3.0 and selling separate licences, but right now everybody seems to be scared by copyleft | 16:59.13 |
| | Iâm especially interested in how to deal with this without a trusted backing company, i.e. a bunch of people contribute, license as AGPL-3.0, and are open to proprietary licenses in exchange for, lets say dev resources, build farms, etc... | 17:00.53 |
| | so........ why doesnât mupdf render postscript? :D | 17:01.37 |
| tor8 | good question ... :) | 17:04.30 |
| mrottenkolber | hmm, sadly in the -gl build left/right arrow keys to turn pages no longer work | 17:05.57 |
| | thatâs a muscle memory deal breaker for me | 17:06.13 |
| tor8 | Use the source :) easy enough to fix locally. | 17:07.33 |
| | platform/gl-main.c function do_app() | 17:08.33 |
| RobinWattsLenovo | yup. | 18:35.27 |
| | oops. | 18:35.35 |
| dinamic | tor8, hi, care to explain jsfunction.c ? | 18:47.30 |
| | tor8, I tried to understand but couldn't figure out what would help me there.. | 18:49.18 |
| | tor8, Do you mean I could modify the Function_prototype to store my specific cvalue value ? | 18:52.08 |
| avih | dinamic: so you want to store some userdata pointer along with a function you insert with newcfunction(J, foo, ...), and then from inside foo access that pointer? | 18:56.00 |
| dinamic | yes | 18:56.10 |
| avih | you have few options, depending on your use case, you could add it as a property of the function, and then from within foo js_currentfunction(J) will place it on the stack and from there you can grab that property | 18:57.40 |
| | another option is to bind foo to your userdata as this (or as a first arg, etc) | 18:58.31 |
| | i think tor made you look how bind is implemented to do something similar yourself. not to modify how bind works. | 19:00.08 |
| dinamic | how does the userdata approach work with function? | 19:00.10 |
| avih | js_newcfunction(J, foo, ...); js_newnull(J); js_newuserdata(J, your_ptr, "some-tag"); js_setproperty(J, -2, "mydata") | 19:01.40 |
| dinamic | ah, as simple as that :) | 19:01.57 |
| avih | and now your stack top has foo with a property mydata which is your userdata pointer | 19:01.57 |
| dinamic | wtf | 19:01.59 |
| | let me try that.. | 19:02.36 |
| | thanx avih | 19:03.02 |
| avih | and from within foo you do js_currentfunction(J); js_getproperty(J, -1, "mydata); myptr = js_touserdata(J, -1, "some-tag") | 19:03.12 |
| | or something along those lines | 19:03.16 |
| | yw | 19:03.31 |
| dinamic | the solution was to simple to me to see.. | 19:03.39 |
| avih | :) | 19:03.45 |
| | the burden of experience :p | 19:04.01 |
| dinamic | :) | 19:11.17 |
| avih | you got it working? | 19:11.45 |
| knielsen | Hey, mupdf-gl is nice and simple to hack on - I managed to implement dual-page view fairly easily | 19:37.00 |
| dinamic | avih, I'm onto it now... i let you know.. Its for my rustc binding of mujs, the last part in the puzzle.. | 21:39.35 |
| tor8 | dinamic: is this userdata a per-function pointer or would a single userdata object for all functions be enough? | 21:59.41 |
| | dinamic: in the latter case, js_getcontext/js_setcontext can set a void* userdata pointer associated with the js_State context | 22:00.18 |
| dinamic | actually i have two properties to pass along, one for each function pointer and one for each js_State | 22:00.19 |
| | wonderful | 22:00.27 |
| | and the stuff i need to pass with the function is a the function name.. could that be retreived ? | 22:01.07 |
| | in another fashion ? | 22:01.18 |
| | i need it due to i need to create a trampoline function for ALL functions which dispatch the call to correct rust closure | 22:01.58 |
| tor8 | oh, it's just the function name that you passed in to the js_newfunction? | 22:02.17 |
| dinamic | yeap | 22:02.24 |
| | o wait, it need to be uniw | 22:02.55 |
| | uniq | 22:02.58 |
| | eg. obj_a.func1 and obj_b.func1 is uniq | 22:03.12 |
| tor8 | oh, so you have a common C callback that needs to find the correct rust function to jump to? | 22:05.46 |
| dinamic | yeap | 22:07.23 |
| | exactly like that | 22:07.28 |
| tor8 | in that case I'd just create a js_newuserdata with the identifier/rust closure pointer and set it to a say "__RustFunction__" property | 22:07.48 |
| | which you can make readonly, non-enumerable, and non-deletable | 22:08.02 |
| dinamic | yeap | 22:08.09 |
| | i'm currentyl onto that track.. | 22:08.22 |
| tor8 | it would be possible to have an internal void* userdata pointer in function objects without bloating the struct | 22:09.01 |
| | but then it will need some hacky accessors in the API | 22:09.18 |
| | so I think creating a userdata property on the function object will be good enough | 22:09.37 |
| dinamic | latter sounds good enough, ill walk that road for now.. | 22:16.18 |
| | Forward 1 day (to 2017/06/04)>>> | |
Log of #mupdf at irc.freenode.net.