| | <<<Back 1 day (to 2017/05/02) | 20170503 |
| Robin_Watts | sebras: zlib update screwed Windows builds :( | 11:44.34 |
| | We really need to get you sorted so you can build on windows. | 11:44.50 |
| sebras | Robin_Watts: the right idea, the wrong approach imho. I'd rather we put in the effort to have a windows node in the cluster | 11:45.36 |
| | and an ios node, for that matter. | 11:45.41 |
| Robin_Watts | sebras: Working on getting windows nodes into the cluster is on my list. I've kinda got it working. | 11:46.12 |
| sebras | Robin_Watts: nice. I'm looking forward to that working as it would help everyone with things like these. | 11:47.05 |
| Robin_Watts | but it doesn't stop it being desirable for us all to be able to build on windows locally. | 11:47.23 |
| sebras | Robin_Watts: is the failing build because they added code? | 11:47.29 |
| | I didn't notice them adding new .c-files. | 11:47.35 |
| tor8 | sebras: we don't use wildcards to build the zlib on unix either | 11:48.06 |
| sebras | tor8: true. maybe a header file then? | 11:48.29 |
| Robin_Watts | sebras: Nope, it's trying to #include <unistd.h> | 11:48.43 |
| | because _LARGEFILE64_SOURCE is defined. | 11:48.53 |
| sebras | Robin_Watts: ah, so we include our system.h (which defines _LARGEFILE64_SOURCE) and the later on some file includes zlib.h which then attempts to include unistd.h which is missing on windows? | 11:50.14 |
| tor8 | what is Z_SOLO for? that seems to inhibit including unistd.h | 11:50.41 |
| Robin_Watts | Also, where is function.c ? | 11:51.19 |
| tor8 | Robin_Watts: function.c is gone, my bad. | 11:51.33 |
| Robin_Watts | tor8: OK. | 11:51.44 |
| tor8 | my winxp virtual machine had an accident, and I haven't taken the time to set up a new one | 11:53.08 |
| avih | tor8: thx. what about the other question of binding "global" names? (also, i still didn't test the exact effect of different 'this' values with js_loadstring, other than undefined seemingly implies global) | 11:56.01 |
| tor8 | avih: have you looked at how mujs/main.c implements the require() function? | 11:57.40 |
| sebras | tor8: you really do have the space to make a backup of your winxp machine once you are able to build mupdf the first time. and then snapshot it and restore from the snapshot... | 11:57.49 |
| tor8 | sebras: but windows update made a mess of things | 11:58.18 |
| avih | tor8: sure. it's simple. it lacks the file name, and it's the same hack which i use. i'm asking if there's a way without a hack where i wrap the loaded file with a string | 11:58.32 |
| sebras | tor8: that's why microsoft added it. | 11:58.47 |
| tor8 | and installing a new machine, now that they've removed the ISOs from the official website I have to dig out my old pre-SP1 DVD image | 11:58.55 |
| | and then spend two days patching | 11:59.01 |
| avih | the joy (and pains) of new machines :) | 11:59.25 |
| tor8 | var x = "prefix" + read("file.js") + "postfix"? | 11:59.39 |
| avih | tor8: not sure what you're asking. i know a solution with wrapping the file with a string. | 12:00.12 |
| tor8 | avih: then I don't know what you're asking. | 12:00.37 |
| avih | for instance, if mujs ever gets line offset info at the stack trace, then this will fail on the first line | 12:00.53 |
| sebras | Robin_Watts: do we still retain that winrt support somewhere? or that was removed? | 12:01.17 |
| Robin_Watts | sorry, swamped in cluster woes at the moment. | 12:01.37 |
| sebras | np. | 12:01.45 |
| tor8 | avih: not if you don't put a newline after the prefix | 12:01.49 |
| avih | tor8: wrong. the offset _within_ the line would be wrong (+strlen(prefix)) | 12:02.25 |
| tor8 | we only track the line number | 12:03.28 |
| avih | this is negligible though and mujs currently doesn't have in-line offsets. so it does work well enough. i'm asking if there's a way to do that without wrapping the file with a string | 12:03.33 |
| | like playing with the 'this' argument when calling js_load{string|file} or maybe passing an additional object who's names would behave like formal arrguments of the file | 12:05.34 |
| tor8 | "(function(module, exports){" + file_data + "\n;})(val1, val2);" is the same as new Function(module, exports, file_data)(val1, val2) | 12:05.49 |
| avih | no, Function argument doesn't take a file name for stack traces | 12:06.44 |
| | it will report the current file, while i want to report traces with the file name which i load | 12:07.11 |
| tor8 | it will report "[string]" as the file name, not the current file | 12:07.52 |
| avih | tor8: that's what i use currently (mp is a global object and mp.utils.load_string maps directly to invoking js_loadstring) https://pastebin.mozilla.org/9020601 | 12:08.25 |
| tor8 | js_loadstring is the closest you will get without digging through internals | 12:09.37 |
| avih | i do have a fully working solution. i'm just asking if there's a way to do that without wrapping the loaded file with a string, while still getting stack traces with the loaded file's name | 12:09.57 |
| tor8 | no, not without making a copy of jsB_Function that takes a file name instead of source string | 12:10.30 |
| avih | k, thx. | 12:11.08 |
| Robin_Watts | tor8, sebras: So, do we think that using Z_SOLO would solve the problem? | 12:30.45 |
| | Nope, that doesn't work, cos we use compress and compressBound | 12:32.08 |
| tor8 | Robin_Watts: it seems to just be removing the prefixes | 12:33.08 |
| | and if we avoid building the gz* functions we can run with Z_SOLO on unix | 12:33.43 |
| | Robin_Watts: though it'd probably be easier to just #undef _LARGEFILE64 on windows, or is that macro used there too? | 12:34.21 |
| Robin_Watts | OK, not defining _LARGEFILE64 on windows seems to get us further. | 12:37.13 |
| | I now hit problems with S_ISDIR and sys/time.h | 12:37.26 |
| | ffs. | 12:37.29 |
| sebras | Robin_Watts: is S_ISDIR() my fault too? | 12:38.36 |
| | Robin_Watts: someone reported that source/fitz/directory.c caused a problem when it was using S_IFDIR on mageia linux 5.0 | 12:39.07 |
| Robin_Watts | sebras: I have not assigned blame yet. I know it wasn't me :( | 12:39.08 |
| tor8 | S_ISDIR is probably a side effect of fixing the S_IFDIR bug. | 12:39.09 |
| | I take all blame. | 12:39.16 |
| sebras | Robin_Watts: and I know tor8 had this change on his branch, but I'm not sure if he's merged it yet? | 12:39.29 |
| | tor8: unless the compilation error is inside zlib... | 12:39.57 |
| | tor8: you wouldn't have to if there was a windows node in the cluster... see where I'm going with this? ;) | 12:40.27 |
| tor8 | sebras: I wouldn't have to if windows wasn't ass-backwards about C compatibility with the rest of the world either. | 12:41.00 |
| Robin_Watts | And if wishes were fishes... | 12:42.06 |
| sebras | tor8: yeah, but that's something we know about but can't do anything about ourselves. the cluster is something we can choose to do something about. | 12:42.15 |
| tor8 | we *could* decide to abandon winxp and upgrade to a newer MSVC | 12:42.31 |
| | one that has stdint.h for instance | 12:42.37 |
| sebras | tor8: have their C compatibility (and I guess posix compatibility) changed a lot in later versions? | 12:43.10 |
| tor8 | it has improved | 12:43.22 |
| Robin_Watts | sebras: Only in *much* newer versions. | 12:43.26 |
| | 2012 upwards I think. | 12:43.36 |
| tor8 | but only in very recent versions, that don't support winxp | 12:43.37 |
| Robin_Watts | and then we'd have customers complaining a lot. | 12:43.53 |
| sebras | Robin_Watts: aha. | 12:44.07 |
| tor8 | the sys/time.h thing is probably down to something I really didn't understand with windows | 12:44.20 |
| | there is no gettimeofday function, but *somewhere* (not in our code) there is a struct definition for the timeval arguments to it | 12:44.39 |
| | I could've misunderstood the #ifdef stuff in our headers and thus introduced that error when moving sys/time.h to the source files that use it rather than include it in fitz.h | 12:45.32 |
| Robin_Watts | We implement our own gettimeofday for windows. | 12:46.32 |
| tor8 | yes, but somewhere in the windows headers there is a struct definition | 12:47.32 |
| | probably <time.h> | 12:47.42 |
| | couldn't we replace that whole thing with int64_t fz_current_time() that returns the number of milliseconds since the epoch? | 12:49.12 |
| Robin_Watts | tor8: Yes, that'd be nicer. | 12:49.50 |
| tor8 | Robin_Watts: muraster.c has some nicer ifdef's for the gettimeofday stuff that mudraw.c doesn't if that helps the immediate problem | 12:50.09 |
| Robin_Watts | tor8: Yeah, I've just dragged that over. | 12:51.07 |
| | just fz_is_directory to fix now. | 12:51.19 |
| sebras | Robin_Watts: I'm surprised that these discrepancies doesn't irk tor8 enough to spend a weekend building a fully compliant C compiler along with a standard library that can target any platform. this seems to be the normal course of action. ;) | 12:58.19 |
| Robin_Watts | ok, various commits on robin/master to staunch the bleeding. | 13:03.38 |
| tor8 | Robin_Watts: all LGTM | 13:10.24 |
| Robin_Watts | ta. | 13:44.50 |
| jogux | hi all. I still have a few commits for iOS things in http://git.ghostscript.com/?p=user/joseph/mupdf-ios-viewer.git;a=summary for review if anyone could oblige please :) | 18:33.53 |
| | Forward 1 day (to 2017/05/04)>>> | |
Log of #mupdf at irc.freenode.net.