| | <<<Back 1 day (to 2014/10/23) | 20141024 |
| avih | i'm evaluating mujs for a project, and noticed that on compile errors i get the file/line of the error at the message, but on other errors (such that reference errors) i don't. is there a way around this? any plans to improve this? | 02:51.30 |
| | (regardless, i find mujs really nice overall) | 02:52.35 |
| | also, noticed that there are about 7 functions which could be declared static (used only at the file, no decelerations outside the file), but which are not static. this can generates some warnings depending on warning levels | 02:54.07 |
| | the functions are numtostr, js_isiterator, js_rot4, jsR_dumpstack, jsR_dumpenvironment, js_trap | 02:55.44 |
| | making them static removes the warnings | 02:57.00 |
| OmSai | Hi all, can anyone tell me if ghostscript installs `ps2write' or `epswrite' in recent versions? I'm trying to fix https://savannah.gnu.org/bugs/?41141 but ghostscript 9.10 and 9.14 don't create / install either of those files on my distribution (Gentoo). | 04:51.57 |
| chrisl | OmSai: ps2write and epswrite are/were Ghostscript devices. epswrite has been deprecated for some time, and was removed in a recent version (can't remember exactly which one), ps2write is included in the default build (as is eps2write which is the replacement for epswrite). | 06:35.45 |
| | OmSai: and looking at the bug report: we no longer have any PS Level 1 output. | 06:37.36 |
| OmSai | chrisl: Thanks for your help in confirming those files are built and the PS 1 removal. So then the sane fix for that octave bug is migrating to ps2write. Now I just need to fix my distro build to generate ps2write, then work on the patch for the octave bug. | 07:40.52 |
| chrisl | OmSai: unless the maintainer takes special action to drop it, ps2write should be built into Ghostscript | 07:42.49 |
| OmSai | chrisl: Ah, I reread your statement and you say they are ghostscript devices. Does that mean they are not necessarily executable files? Is there a /usr/bin/ps2write? | 07:43.20 |
| chrisl | No, they are not executable files | 07:43.43 |
| OmSai | chrisl: Ok, thanks for clearning my misunderstanding. That's everything I needed to know for now | 07:44.28 |
| chrisl | OmSai: if you do "gs -h" that'll give you (amongst other things) a list of the device build into gs | 07:45.03 |
| OmSai | chrisl: I see ps2write listed in `Available devices' | 07:45.46 |
| | so it would seem I only need focus on octave | 07:46.10 |
| chrisl | It depends on how octave calls gs - there are "helper" scripts like "ps2ps2", but we tend to discourage their use | 07:47.03 |
| kens2 | I htink the scripts got rewritten to use ps2write, but I may have missed some | 07:55.24 |
| malc_ | chrisl: why? (discourage the scripts that is) | 08:20.52 |
| chrisl | malc_: because they hide the details of what gs is doing, and often cause confusion about people's expectations | 08:22.32 |
| malc_ | i see, thanks | 08:23.25 |
| kens2 | There's also confusion over whether its one of our scripts, or some other applicaiton or script from another application | 08:23.51 |
| | ps2ps or pstops for example | 08:24.05 |
| malc_ | uhm.. yeah xpdf had something like this | 08:34.17 |
| chrisl | I'm generally more concerned with people using it from a utility or script, rather that those doing a one-off conversion. If you're calling from a utility/app or script, I *strongly* encourage folk to use gs directly | 08:36.40 |
| _wiz_ | hi. | 08:37.29 |
| chrisl | Why, in the name of hell, do the gp_* file functions not take a memory parameter?? | 08:44.29 |
| kens2 | No idea, many things don't seem to | 08:44.48 |
| chrisl | So, there's no (easy) way to add -Z.. debug code to the platform specific file handling :-( | 08:45.49 |
| kens2 | THat's less than ideal. Add it to the list of things that should get changed..... | 08:47.18 |
| chrisl | Do we have such a list? | 08:47.52 |
| kens2 | I'm making one for the devices stuff, as comments in the C file :-) | 08:48.19 |
| | Hmm, looks like I'm going to have to make my own 'do nothing' compositor device | 08:49.25 |
| | Hmm, or maybe not, the nulldevice seems to simply assign itself to the compositor device, intriguing | 08:50.20 |
| chrisl | Or could you just "force" the normal compositors into "passthough" mode? | 08:50.48 |
| kens2 | Doe sit have a passthrough mode ? | 08:52.03 |
| | I htink defining my own device as the compositor probably works, I@ll find out in a minute | 08:52.35 |
| chrisl | Yeh, that's how we get away with the pdf14 compositor being installed for the entire file, but only actually used when the page has transparency | 08:52.47 |
| kens2 | Ah, I didn't know that one. | 08:53.01 |
| | I'm going to try the same as the nulldevice, after all, at this point my device effectively is the nulldevice | 08:53.43 |
| | Well, no seg fault, so that's a good thing. Now to try a more complex test | 08:54.35 |
| | Oh, that caused a crash with pdf14 relocating pointers. :-( | 08:55.14 |
| | Strange, considering it had already run 7 pages, some of which use transparency | 08:56.12 |
| | Oh, its trying to reloc the device, why on earth is it doing that ? | 08:59.43 |
| | Well if I stop pdf14 trying to relocate the device(s) then everything works just fine. If only I understood why it was trying to do that ;_( | 09:03.22 |
| tor8 | avih: regarding runtime errors; there are ways to get the line information but they require storing debug information to associate every instruction with a source line | 09:04.48 |
| kens2 | chrisl, so why do I get create_compositor called for every page, if pdf14 is installed at startup, and deactivated for pages without transparency ? | 09:09.07 |
| chrisl | I *think* that behaviour changed when the PDF interpreter was changed to surround each page with save/restore. | 09:09.55 |
| kens2 | OK I guess that makes sense. | 09:10.14 |
| chrisl | So, I think the "passthrough" mode now only applies in banded mode, to differentiate between bands with transparency, and bands without | 09:10.36 |
| kens2 | I wish I understood what the reason for relocating the device is, the device in this case *can't* be relocated, because its a copy and the copy was made in non-gc memory. | 09:10.46 |
| | I'm going to work around it for now and hope it doesn't cause a problem. | 09:11.05 |
| chrisl | But it's referenced from the graphics state | 09:12.07 |
| | Or is referenced by another device, which is referenced by the graphics state..... | 09:12.33 |
| kens2 | Its refrernced by another device, which is referenced from the graphics state (potentially multiple links in that chain) | 09:16.09 |
| | So why do we need to relocate any opf the devices ? | 09:16.30 |
| chrisl | Because devices are allocated in gc memory | 09:16.43 |
| kens2 | Hmm, well the top level debice is | 09:16.57 |
| | All the children are allocated in non-gc memory | 09:17.08 |
| chrisl | I thought all devices were allocated in gc memory | 09:17.31 |
| kens2 | I guess what I mean is why does the compositor device need to reloc the device in the gsstate ? | 09:17.32 |
| | Not the ones I'm creating manually | 09:17.43 |
| | The original device is created in gc memory | 09:17.57 |
| chrisl | So how does the garbage collector know that in certain cases the "target" pointer is to gc memory, and in other cases it isn't? | 09:18.43 |
| kens2 | I'm unclear why it cares | 09:19.01 |
| chrisl | Because the passthrough device prototype tells the garbage collector to care | 09:19.32 |
| kens2 | More reason to get rid of it IMO, except that other devices do the same, so I have to cater for this | 09:19.54 |
| | Its easy enough to tell anyway (which is what I'm working on now), if there's subclass_data, then the device is not GC'ed | 09:20.29 |
| | So presumably I cna just tell the device_reloc code to not reloc any such device | 09:20.50 |
| | Err, I should say if thre's subclass datga and the parent is not NULL | 09:21.14 |
| chrisl | Oh, ick, more special cases?? Surely it would be easier/better if you just use gc memory like you're supposed to | 09:21.34 |
| kens2 | I really don't want to use GC memory for the child devices because then I get into having to have GC descriptors for them | 09:22.29 |
| chrisl | Aren't there already prototype gc descriptors for default and passthrough devices? | 09:23.52 |
| kens2 | These devices are copies of the original device, which I'm sotring when I overwrite the original device with my new device. | 09:24.17 |
| | The subclassing stuff first makes a new copy of the existing device | 09:24.46 |
| | The copy is not (currently) in GC memory | 09:24.59 |
| chrisl | That's not going to work...... | 09:25.46 |
| kens2 | Why ? | 09:25.51 |
| chrisl | What if the original device references objects in gc memory? | 09:26.07 |
| kens2 | I'm not sure why that's a problem ? The device maintains its own pointers still, and has reference counts and enumerators and so on | 09:26.56 |
| | Hmm, but I suppose the GC can't find the devcie | 09:27.13 |
| | Rats. | 09:27.17 |
| | I *hate* dealing with GC memory | 09:27.32 |
| chrisl | yes, so objects that get relocated won't have their pointers updated in the device, and if the device holds the only reference, the object will be freed (due to not being marked) | 09:28.06 |
| | But you shouldn't need new descriptors for these cases, all the devices already need descriptors. | 09:28.38 |
| kens2 | That's going to be a major problem then, because if I have a device copy an existing copied device, I'm not sure how I can have the GC enumeration and relocation work. | 09:28.54 |
| | chrisl I need the device to maintain a pointer to the next device, (and the previous one) and both those poitners need GC enumeratora and reloactors | 09:29.29 |
| kens2 | goes off to look in gxdevice.c again | 09:29.58 |
| chrisl | Okay, but your new "filter" device must be in gc memory, so must have a gc descriptor | 09:30.26 |
| | kens2: ^^] | 09:30.30 |
| kens2 | Well, the copy is currently in non-GC memory, so I need to change that. And somehow the copy needs to enumerate and relocate the parent (and if present, child) pointers to/from other devices, so it needs a GC descriptor for those. I'm not clear on how I can add those to an existing device. WHich is why I'm off looking at how devices are declared again. I'd hoped to avoid all this mess. | 09:32.07 |
| chrisl | I assumed you've added the parent/child pointers to the gx_device_common list? | 09:33.19 |
| kens2 | No. | 09:33.36 |
| | I'd added a void * to a common data structure, the idea beign that the pointers are stored there, along with a size of the data structure, and devices could store device-specific stuff there | 09:34.17 |
| | THey can't use the existing device memory, because it may not be big enough | 09:34.33 |
| | Obviously I can alter that and have three new pointers, parent, child and data | 09:35.45 |
| chrisl | kens2: if the new opaque ptr is for device's private data, then how does your "filter" device change it? | 09:38.09 |
| kens2 | If the child already has one, it doesn't, it just updates the parent and child pointers as required. Then allocates a new one for itself and stores it in the pre-existing device structure. When we finalize the device we free the data poitned to by it, copy the child device up and finalize that. | 09:39.34 |
| chrisl | So, it's not really for data private to the device | 09:40.22 |
| kens2 | It is, honestly | 09:40.41 |
| chrisl | So, your device can't really modify it | 09:40.54 |
| kens2 | See PM | 09:41.05 |
| | Lunch time, back in a bit | 11:30.22 |
| avih | tor8: yeah, obviously it will require some runtime memory, but debugging script without them could be a nightmare... maybe some runtime option to compile with or without debug info? | 14:14.57 |
| tor8 | avih: yes. I have considered such an option. | 14:19.34 |
| | at one point I had a LINE op-code that just set the currently executing line number. slow and inefficient, but it got the job done. | 14:20.08 |
| avih | tor8: an interesting starting point could be to support __line__ ;) | 14:21.28 |
| | (though i don't think it's common is js). | 14:21.53 |
| tor8 | avih: which js has that? | 14:22.26 |
| avih | tor8: none that i know of, but then again, all of them show errors with line numbers ;) | 14:22.54 |
| | tor8: how would you evaluate the runtime memory increase and complexity of coding such "debug info" support? | 14:23.49 |
| | the former probably not more than.. 10-20% ram i guess? the latter - no clue | 14:24.20 |
| tor8 | avih: it should be a fairly small impact. at most it would double the code size of functions, which is already pretty minimal compared to the amount of memory used by actual runtime objects. | 14:24.44 |
| avih | right | 14:25.04 |
| | would it have a non-negligible effect on runtime speed? | 14:25.21 |
| | i'm guessing not since this info only needs to be accessed on errors/warnings | 14:25.51 |
| tor8 | it would just bump the memory use, no effect on runtime speed | 14:26.47 |
| | since as you say, it'd only be accessed when creating errors | 14:27.05 |
| | hm, on second thought, it might be more trouble since I'll need to start being able to track the 'pc' outside of the interpreter | 14:28.47 |
| | since the errors are usually created inside C functions (builtin or otherwise) there's no access to the call stack | 14:30.56 |
| avih | hmm... i'm not familiar with the internals of mujs to understand this ... | 14:35.11 |
| tor8 | avih: it means I have to track call info somewhere explicitly, which will have an impact or runtime speed | 14:35.42 |
| | anytime there's a call-out to a C or JS function, I have to save the source line and location for debugging | 14:36.11 |
| | so you can get a stack trace | 14:36.33 |
| avih | hmm... | 14:36.35 |
| tor8 | and this is also for internal functions that implement the opcodes | 14:36.55 |
| avih | yeah.. but stack trace will take more resources i think than just logging the line of the error | 14:37.10 |
| | (though stack traces would definitely be cool to have :) ) | 14:37.59 |
| tor8 | something like a ReferenceError can occur in the OP_GETPROP opcode | 14:38.02 |
| Robin_Watts | tor8: You could consider having something whereby you either build a debug capable version or not. | 14:38.28 |
| avih | can you access the call stack internally? | 14:38.36 |
| tor8 | which has a chain of C function calls to resolve stuff based on the data types | 14:38.41 |
| Robin_Watts | so for stuff where debugging is never an issue (like mupdf), you'd use the non-debug capable version. | 14:38.54 |
| tor8 | and in those C functions, I will need to look at the last 'program counter' | 14:39.04 |
| | there's no need for a full stack, but I do need to stash the program counter and last function somewhere so I can look up the last location in JS | 14:39.32 |
| avih | Robin_Watts: actually, i was thinking of this feature for at least some release configurations, e.g. when an applications embeds js and the user creates the files, being able to debug errors in user files is extremely useful | 14:39.37 |
| tor8 | Robin_Watts: yeah, I'd imagine a debugging flag toggle when creating the js_newstate | 14:40.00 |
| avih | e.g. right now i'm trying to add js scripting support to mpv (video player derived from mplayer), and not seeing error lines can make it real hard to work with | 14:40.27 |
| Robin_Watts | tor8: I was thinking a compile time thing for mujs itself. | 14:40.36 |
| tor8 | Robin_Watts: I expect the easiest way to do this is by telling the compiler to emit a special opcode to record the current file and line number | 14:41.20 |
| avih | yeah, compile time is definitely better than nothing | 14:41.20 |
| tor8 | that'll slow down execution some, but it's the trivial way to do it without needing to add debug information data structures and call stack tracing | 14:42.09 |
| avih | tor8: did you also see my comment on static files? https://github.com/ccxvii/mujs/issues/11 | 14:42.29 |
| tor8 | avih: yes | 14:43.04 |
| malc_ | avih: lua is not good enough? | 14:44.58 |
| avih | btw, i do find the language implementation very solid. i tried few other embedded js engines, and none so far was as smooth to work with as mujs is. cheers. | 14:45.31 |
| | malc_: it is, for devs who speak lua. there are many who speak js but not lua | 14:45.59 |
| tor8 | malc_: in a perfect world, everybody would use lua instead of js | 14:46.57 |
| | but since we're stuck with js, I tried to do the best of the situation with mujs | 14:47.13 |
| malc_ | tor8: how come? | 14:47.21 |
| tor8 | the PDF spec requires it, and a lot of people prefer JS for insane reasons | 14:47.57 |
| | malc_: mujs has an API and design heavily inspired by the lua API | 14:48.33 |
| Robin_Watts | The fact it's in every browser is a killer one. | 14:48.33 |
| malc_ | tor8: no, i meant why do you think js is worse than lua? | 14:48.48 |
| tor8 | malc_: JS has way too many ugly warts | 14:49.02 |
| | Eich should have spent more than a week on it before shoving the first version out the door | 14:49.24 |
| avih | heh | 14:49.42 |
| tor8 | and the lua metatables is so much more useful than JS prototypes | 14:50.00 |
| malc_ | tor8: well, afaik his initial version was more scheme like (syntax wise), should it have stayed that way -- would have stopped some of the insanity | 14:50.50 |
| tor8 | if you can ignore the warts, and live with the limitations of prototypes vs metatables, they're not all that much different | 14:50.56 |
| | but the one feature that is the major killer of JS as a good language is that all dictionary keys are strings and only strings | 14:51.29 |
| avih | btw, what's the relation between mujs and ghostscript? | 14:51.31 |
| | same developers? same company? | 14:51.49 |
| tor8 | avih: mujs is the JS interpreter I wrote for use with MuPDF, which is a product by the same company as Ghostscript | 14:52.00 |
| malc_ | tor8: i was considering adding some scripting stuff would you say lua or js (in form of mujs) would be a better choice? | 14:52.03 |
| tor8 | malc_: if you have the option -- go with lua | 14:52.14 |
| avih | tor8: gotcha. thx | 14:52.20 |
| malc_ | tor8: hum hum.. tack | 14:52.38 |
| tor8 | lua is faster, has luajit if you really need performance, and it's a better spec'd language with way fewer surprises and limitations | 14:52.59 |
| malc_ | tor8: sure lua(jit) is faster than mujs (probably), yet money and man power poured into v8 and suchlike make me doubt the validty of your assertion (in general) | 14:54.28 |
| tor8 | if you don't like lua (because of silly reasons like arrays starting at 1) and don't mind not having actual arrays (js arrays are just magic foo based on strings that look like integers) | 14:54.33 |
| malc_ | hey.. my inner fotranner rejoyces at 1 based arrays | 14:55.03 |
| tor8 | JS jit compilers still have to deal with JS crap like what I just mentioned -- in the best case they can get comparable performance to luajit, but in the general case, I believe luajit will beat them any day | 14:55.41 |
| | not to mention -- luajit is what, 250K, and v8 is 25M | 14:56.14 |
| | and pulls in crazy C++ and multi-threading dependencies | 14:56.29 |
| Robin_Watts | 1 based arrays? jeez. | 14:56.45 |
| malc_ | tor8: http://multimedia.cx/eggs/playing-with-emscripten-and-asm-js/ | 14:56.53 |
| avih | how many/which projects other than myPDF use mujs? | 14:57.05 |
| Robin_Watts | If someone asks you how many people are in the room, and you don't start counting from 0, you are not a programmer :) | 14:57.09 |
| malc_ | tor8: heh, i've browsed through v8 once, ran away in horror | 14:57.19 |
| avih | it seems to me it has less buzz than it should have | 14:57.28 |
| Robin_Watts | avih: muhs has only been out for a month or two. | 14:57.45 |
| avih | s/myPDF/muPDF/ | 14:57.48 |
| tor8 | Robin_Watts: it's the only questionable design feature of lua :) that, and a sadly necessary bit of evil with variables being global by default (due to the way scoping and modules work) | 14:57.52 |
| avih | Robin_Watts: oh.. though i've seem commit messages going back at least 9 months.. | 14:58.30 |
| tor8 | avih: make more buzz :) it's a very new project, it's only been released for a couple of months. development started last christmas. | 14:58.33 |
| avih | good to know :) | 14:59.07 |
| | tor8: in that case, i've heard mpv people asking if it has pkg-config ;) | 14:59.37 |
| tor8 | avih: I was fed up with the giant monster JS implementations (I don't care about or want JIT compilation, and we try very hard to avoid C++ dependencies) | 14:59.40 |
| | and all the small implementations were as you say, incomplete | 14:59.50 |
| | malc_: asm.js is a different beast :) | 15:00.36 |
| avih | yeah, i think the closest to working nicely was duktape. tbh i don't recall why i didn't pick it up.. maybe the code base seemed way bigger than mujs? | 15:00.36 |
| tor8 | avih: I only discovered duktape after I'd gotten mujs to the stage where it actually worked | 15:01.06 |
| avih | :) | 15:01.13 |
| tor8 | it seems to have very similar goals | 15:01.14 |
| avih | yes | 15:01.18 |
| | though different api. mujs api is very nice on one hand to add js support where lua support exists, but then again it's just different enough such that refactoring existing code to support both languages is not somehing i wanna venture into | 15:02.13 |
| | and duplicating big chunks of code only to modify few lines on each function is ugly | 15:02.57 |
| tor8 | avih: yeah, the runtime models of lua and js are different enough that you don't really want to support both using mechanical transformations | 15:03.06 |
| | the way 'this' works in JS, and prototypes vs metatables | 15:03.22 |
| avih | yeah | 15:03.39 |
| tor8 | it would probably be easier going the other way, retasking mujs interfaced code to work with lua as well | 15:04.26 |
| avih | overall though, these are "rich people's problems" to be able to duplicate almost verbatim instead of having to implement embedding from scratch :) | 15:04.30 |
| tor8 | prototypes map easily to metatable.__index | 15:04.37 |
| | and dictionaries in js are a subset of what tables in lua can do | 15:05.05 |
| | having only string keys | 15:05.13 |
| | avih: if you don't mind my asking, where are you using mujs? | 15:05.53 |
| avih | you mean for supporting both apis automatically? | 15:05.54 |
| tor8 | avih: yeah. | 15:05.58 |
| avih | trying to add js support at mpv movie player) | 15:06.16 |
| | which already has lua support | 15:06.27 |
| tor8 | or creating a common wrapper or translation layer between mujs/lua | 15:06.39 |
| avih | yeah. one thing at a time, first et me get it working, then, maybe, maybe, i'll try to unify them :) | 15:07.08 |
| | (fwiw, i work for mozilla, but i still value small code bases and easy integration and wouldn't think of trying to embed spidermonkey into mpv ;) ) | 15:08.44 |
| | nor v8 :) | 15:09.42 |
| tor8 | :) | 15:09.57 |
| avih | v7 actually sounded interesting (same dev who wrote the mongoose web server), and he has nice complementary c++ packages which could integrate into the implementation as modules (socket, crypto, etc), supposedly exposing it all as a single small "Smart js" embedded js, but it's.. not smooth. the js itself doesn't seem stable enough, and smart js is in a weird state where it's not clear what's released and what isn't.. | 15:13.48 |
| | tor8: btw, i extended require a bit to also support node.js style modules, and emit the line number on syntax errors ;) https://pastebin.mozilla.org/6885030 feel free to take it | 15:17.52 |
| | well.. it emitted the line numbers already, but not the file name | 15:19.42 |
| tor8 | avih: check the 'debug' branch on git://git.ghostscript.com/user/tor/mujs.git | 16:16.49 |
| avih | tor8: will do :) | 16:17.31 |
| | tor8: so the only change is js_setdebug, right? no defines which i missed to check debug support, yes? | 16:31.55 |
| | (that was quick! :D) | 16:34.21 |
| | works very nicely on the simple cases i tested before this patch :) thanks | 16:38.07 |
| tor8 | avih: great! | 16:56.11 |
| avih | tor8: btw, just noticed that there's a pretty print dump, how do i invoke it? it's not on mujs.h, and also 'dump' is not defined when called from within js code | 16:56.54 |
| | (trying to read jsdump.c now) | 16:57.30 |
| | same for jsR_dumpstack, is there an e.stack property of exceptions? | 17:03.02 |
| zauberparacelsus | How do you access the help window in MuPDF? A friend of mine was able to access it on Windows through the icon at the top-left of the window bar, but doing it that way doesn't work on Linux. | 17:58.24 |
| henrys | random rant: gdev_vector_stream() ... why do we still have code like this? What do streams have to do with beginpage? | 18:28.52 |
| avih | re TODO: lifetime of js_tostring <-- till gc? | 19:09.21 |
| marcosw | I'm going to reboot casper in a few minutes so that the pending updates can occur. It should be back up momentarily. | 21:44.47 |
| | Forward 1 day (to 2014/10/25)>>> | |
IRC Logs