| | <<<Back 1 day (to 2012/09/23) | 2012/09/24 |
| tidux | hi, is there anything in GhostScript other than the DVI and PS viewers that would get lost on an OS without an X server? | 04:23.00 |
| chrisl | tidux: Ghostscript doesn't have a DVI viewer (or any DVI stuff in it, AFAIK). Without X you lose the X11 devices, that should be all (if the OS in question is Windows, there's a "display device") | 07:22.56 |
| kens | Hmm, shiny new VM is doing 'something'. Very slowly...... | 07:24.36 |
| | Good grief, it actually seems to work :-O | 07:29.56 |
| chrisl | What seems to work? | 07:30.39 |
| kens | THe thing Robin sent me | 07:31.15 |
| chrisl | hmm, none the wiser...... | 07:31.57 |
| kens | sent you a private message | 07:33.47 |
| Robin_Watts | kens: yes, first boot is very slow. gets faster though. | 08:34.05 |
| kens | Robin_Watts : yes, seems OK | 08:34.16 |
| | I don't have enough memory to drive it properly | 08:34.26 |
| | But its a lot better than trying to work over teh net with someone else's Mac | 08:34.43 |
| | So, where do I get Git for it ? | 08:35.00 |
| Robin_Watts | Ouch. a friend of mine just spent 4 hours queuing for immigration at JFK | 08:39.00 |
| kens | THa'ts worse than I've ever seen | 08:39.15 |
| Robin_Watts | Amazon have a 120Gig SSD in lightning deals today, coming online at 1pm, for less than 65 quid. | 08:44.58 |
| | chrisl: I'm gonna have a crack at making it so that un 'm' printing modes go back to real stdout/stderr in threadsafe builds. | 10:26.59 |
| | chrisl: Actually... if the allocator fails to init, nothing is printed anyway. | 10:32.47 |
| kens | Oh god, so many hoops to jump through, all I want is to download XCode... | 10:39.45 |
| chrisl | Robin_Watts: I think it would be nice if we could do that - perhaps the allocator initialisation failing *should* print something? | 10:43.27 |
| Robin_Watts | chrisl: OK, but that could be a special case :) | 10:43.49 |
| chrisl | What I was thinking was if we have a fallback direct to stderr, with a warning about bypassing the redirect, it would help highlight anywhere with problems, without preventing them working. | 10:45.04 |
| Robin_Watts | chrisl: At the moment, the libctx keeps a static of the 'last inited base allocator' gs_memory_t *, and all non-m prints are passed to m-prints using that. | 10:49.09 |
| chrisl | Which seems entirely pointless, to me...... | 10:50.18 |
| Robin_Watts | chrisl: It means that everything ends up going down the same route. | 10:50.56 |
| | (Previously, before we had the context, we only ever had that var, and everything went through it) | 10:51.38 |
| | I'm extremely loathe to move away from the model where everything ends up in the same place. | 10:52.08 |
| chrisl | Robin_Watts: true, but things change | 10:52.10 |
| Robin_Watts | I could make it so that in GS_THREADSAFE builds all the non m printfs go to 'raw' stderr and stdout, but that assumes that the systems underlying stderr/stdout are threadsafe. | 10:53.28 |
| chrisl | Well, the other option is to give no feedback in the event of an error where these calls are used, and I'm not keen on that. | 10:55.32 |
| Robin_Watts | Frankly, if we're building GS_THREADSAFE, then the odds are that we're building for a server, so a mixed up stdout/stderr will be useless. | 10:55.56 |
| chrisl | Surely we should be defaulting to GS_THREADSAFE? | 10:56.31 |
| Robin_Watts | We aren't currently, and that's not an option unless you a) want to fix a load of devices, or b) want to remove a load of devices from the default build. | 10:57.30 |
| chrisl | Well, I want to do "b" - if we're claiming to be threadsafe, we should be | 10:58.28 |
| Robin_Watts | We are claiming the core of gs is threadsafe. | 10:59.17 |
| | or "GS can be built in a threadsafe form, subject to appropriate choice of devices" | 10:59.53 |
| chrisl | I can see complaints coming from those who use our DLL on Windows and the distro maintainers :-( | 11:01.53 |
| Robin_Watts | It's not like "making the print functions work" will make devices thread safe. | 11:05.17 |
| | Changing over to using the right print functions is a trivial thing to do if you decide to make a device threadsafe | 11:06.33 |
| | In a way, I was tempted to leave the code failing to compile if those print functions were used as an impetus. | 11:07.21 |
| | but to do so would have meant either losing some of the debug code we have in the core, or of having to add #ifndef GS_THREADSAFE stuff in lots of places. | 11:07.57 |
| | Ok. windows utf8 stuff. At least I have a clear plan for making progress for that. I think. | 11:10.13 |
| chrisl | Robin_Watts: I wasn't suggesting *you* should make all the various devices thread safe, I was thinking we bounty it. | 11:29.05 |
| Robin_Watts | chrisl: Yeah, I think that would be a sensible thing. | 11:29.23 |
| chrisl | Then, once the bounty is complete, we default to GS_THREADSAFE | 11:29.53 |
| sebras | wolfpython: hi! | 11:30.21 |
| | wolfpython: you mentioned that you are working on some adaptations of mupdf a few days ago..? | 11:30.39 |
| Robin_Watts | My point is, that we are essentially arguing over how a vanishingly small set of print functions behave in increasingly obscure circumstances. | 11:30.40 |
| | wolfpython, sebras: Ah, yes, I read that in the logs I think. | 11:30.57 |
| chrisl | Robin_Watts: yeh, I wasn't really arguing on that point - I felt it would be nice to have a last ditch fallback option, but I have no feel for how much hassle that would be | 11:31.43 |
| sebras | wolfpython: there is a bugzilla over at http://bugs.ghostscript.com if it is a patch for a bug you found that you want to contribute. | 11:31.49 |
| Robin_Watts | Certainly, we'd love to see any such code. The best way is to open an enhancement bug at bugs.ghostscript.com, describe what the problem is that you're solving, and then attach your patch as a suggested fix. | 11:32.08 |
| sebras | wolfpython: but if you'd like to write a short description here it would be nice. | 11:32.37 |
| Robin_Watts | Yes, if you want to discuss exactly what you feel is missing, and how you've solved it here, that may short circuit a lot of stuff on the bug. | 11:33.16 |
| | Oh Gawd. | 11:38.38 |
| | gs supports @file as command line option to mean 'get options from file' I think. | 11:39.00 |
| chrisl | Yes, I seem to remember it does | 11:39.26 |
| Robin_Watts | So if we're providing utf8 and non-utf8 entry points, does that mean we have to support utf8 and non-utf8 files full of args? | 11:39.36 |
| chrisl | If the file is already in UTF-8 shouldn't it just work? | 11:42.13 |
| Robin_Watts | chrisl: If the file is full of utf8 args, yes. | 11:42.34 |
| | but if someone calls the non utf8 entry point, they can reasonably expect to pass a file full of non-utf8 args. | 11:43.02 |
| chrisl | I don't think we need to convert the file *to* UTF-8 | 11:43.55 |
| Robin_Watts | The core of gs assumes that it gets utf8 passed to it. | 11:44.34 |
| chrisl | Always? | 11:44.57 |
| Robin_Watts | Yes, that's the new world order, right? | 11:45.08 |
| | the gs core always gets utf8 in, and always gives utf8 out. | 11:45.24 |
| | The display functions (for gswin32 (rather than gswin32c) need to convert from utf8 to unicode when printing. | 11:46.13 |
| | The file functions take utf8 filenames to wchar filenames and open them. | 11:46.34 |
| chrisl | The problem we'll have is that we can't know if the file is already UTF-8 or not | 11:46.55 |
| Robin_Watts | The wrapper takes wchar args and converts them to utf8 args. | 11:47.12 |
| | Well, the plan was to add a new set of entry points. | 11:47.28 |
| chrisl | But the options file is ASCII, not wchar | 11:47.39 |
| Robin_Watts | The existing entry points would revert to ALWAYS be called with 'system local' stuff. | 11:48.02 |
| | The _utf8 entry points would be called with utf8 args. | 11:48.31 |
| | Hence it's reasonable to assume that if you're passing an @file to the utf8 entrypoint, the file should contain utf8 data - do you not think? | 11:49.02 |
| chrisl | Right, that makes sense, yes | 11:49.12 |
| kens | Can't we just say that the @file*must* be UTF-8 ? | 11:49.26 |
| Robin_Watts | kens: We *could*, but that would break backwards compatibility, which is precisely what we are revisiting this to try to avoid. | 11:49.56 |
| kens | Does it break backwards compatibility ? | 11:50.14 |
| Robin_Watts | All that sounds nice and simple, but it's a bit of a git to implement. | 11:50.14 |
| kens | I thought right nw it all had to be ASCII, which is UTF-8 | 11:50.31 |
| Robin_Watts | Suppose Mr X has been calling gs for years by calling it with an @file that isn't utf8. | 11:50.42 |
| | When we produce a new release with unicode enabled by default, we can't suddenly change the interpretation of that file without upsetting him. | 11:51.24 |
| kens | I thought that ASCII was the same as UTF-8 | 11:51.55 |
| | For ASCII c text | 11:52.03 |
| Robin_Watts | For 7 bit text, yes. | 11:52.11 |
| kens | Yes that's what I mean | 11:52.17 |
| Robin_Watts | But suppose someone has a 'beta' symbol in a filename. | 11:52.28 |
| kens | Well, I'd be inclined to tell tehm tough | 11:52.42 |
| Robin_Watts | In their local encoding, that may be character 140. | 11:52.44 |
| | Historically they could always have just passed that in to gs with no problems. Had they changed locales or languages, they would have had a problem, but... | 11:53.31 |
| kens | I think its fairly unllikely Robin_Watts, I'd be inclined to just say that @files must now be UTF-8 | 11:54.00 |
| | But hey, I'm not doing the work... ;-) | 11:54.13 |
| Robin_Watts | While it sounds nice and simple to say "@file encoding should match the functions that are called" it's 'interesting' to code. | 11:55.03 |
| | because the @ files are handled below the level I was hoping to do the conversion at. | 11:55.38 |
| | Could we have @file's as local and @@ as utf8 ? | 11:59.40 |
| | Hmm. 55 quid for a 120GB SSD from amazon. | 12:00.35 |
| | lunchtime. | 12:02.22 |
| chrisl | Off to see a man about a badly running car..... back much later...... | 12:22.09 |
| wolfpython | sebras, Robin_Watts: hi! | 13:59.02 |
| Robin_Watts | hi | 13:59.16 |
| sebras | wolfpython: hiya! | 14:00.27 |
| wolfpython | just came back home :) | 14:01.17 |
| | sebras, Robin_Watts : yes. It is my first time adapting open source code | 14:06.43 |
| Robin_Watts | Excellent. What feature did you feel was missing? | 14:07.20 |
| wolfpython | return to the last page | 14:07.51 |
| | when I follow the links | 14:08.12 |
| | and with the 123g command | 14:08.29 |
| Robin_Watts | By hitting a key? | 14:08.48 |
| sebras | wolfpython: doesn't the 't' key do that for you? | 14:09.07 |
| | I seem to recall that it does. I hope I'm right. :) | 14:09.40 |
| Robin_Watts | sebras: Indeed, it seems to work for me. | 14:10.00 |
| | wolfpython: There are many layers of code, so it would be easy to miss. | 14:11.23 |
| | Or maybe you're doing something subtlely different? | 14:11.43 |
| wolfpython | sebras, Robin_Watts:Oh, sorry to not try it . I thought it only works with the *mark* | 14:12.27 |
| | Robin_Watts, sebras: Does 't' works when using 123g ? | 14:13.02 |
| | it doesn't work here | 14:13.11 |
| Robin_Watts | No. | 14:13.36 |
| | but it is possible that it would be an enhancement if it did. | 14:14.05 |
| | tor8 coded this originally, so he may have thoughts. | 14:14.18 |
| wolfpython | and it seems 't' only can pop back to latest page? not second latest page and so forth, right? | 14:17.21 |
| tor8 | Robin_Watts: no opinions | 14:17.58 |
| | wolfpython: no, the 't' key works as a stack | 14:18.17 |
| Robin_Watts | wolfpython: If you wanted to extend the code so that 123g put an entry on the stack so we could pop back to it, that would be a worthwhile enhancement I think. | 14:19.11 |
| | although it should be noted that the viewer is currently being rewritten. | 14:19.31 |
| wolfpython | tor8: I try it , it works as a stack :). sorry | 14:21.31 |
| | so, come on tor8 , I need this enhancement :) | 14:22.13 |
| Robin_Watts | wolfpython: There is little chance that we will make the change ourselves, I would guess. | 14:23.23 |
| | We are concentrating on the new version. | 14:23.29 |
| | But it should be straightforward enough for you to make the change. | 14:23.48 |
| wolfpython | aha, I'm reading the source code about 't' :). | 14:31.55 |
| sebras | wolfpython: the fact that you didn't know that it works for links means that I should probably update the manpages a bit. | 14:32.16 |
| wolfpython | sebras: hehe, yes, I thinks so :) | 14:33.01 |
| sebras | wolfpython: I'll see if I can do that tonight. | 14:34.57 |
| wolfpython | thank you :) | 14:35.25 |
| | mupdf is amazing, I've been using it since I turn to lxde and e17. But never use it on an andorid device. | 14:36.33 |
| | thank you all :) | 14:36.40 |
| | a friend of mine told me that mupdf cannot return to its origin resolution after zooming in and out several times | 14:41.16 |
| | it seems that * and / lose it's precision in the code | 14:42.33 |
| Robin_Watts | Yes, the matrix is iteratively changed, not recalculated each time. | 14:43.07 |
| tor8 | wolfpython: change the "app->pageno = xxx" line in case 'g' to a call to pdfapp_gotopage() instead | 14:44.12 |
| wolfpython | tor8, Robin_Watts sebras: I think we'd better keep 't''s functions, as it's used in mark and links. It ('t' I mean)does pretty good job and there is no need to extend it. | 14:58.32 |
| Robin_Watts | wolfpython: If you do what tor8 said above, then 't' will work exactly as it does now, but it will ALSO work with 123g. | 14:59.08 |
| kens | wishes he hadn't started trying to install Git | 15:10.19 |
| Robin_Watts | kens: It isn't that bad, is it? | 15:13.34 |
| kens | Its still downloading, building, installing, cleaning..... | 15:13.51 |
| | Been at it for 3 hours | 15:13.59 |
| | Currently doing pcre | 15:14.16 |
| | THe list of dependencies seems to be gigantic | 15:14.39 |
| Robin_Watts | Yeah. It's a huge house of cards, like all of unix. | 15:15.02 |
| kens | I'd say its downloading a pretty large part of Uniux | 15:15.16 |
| Robin_Watts | But once you've installed git, everything else is easy :) | 15:15.17 |
| | port install global-thermonuclear-war | 15:15.37 |
| | Disc space required = 1K. | 15:15.47 |
| kens | Today's network usage is 3.8GB | 15:16.17 |
| Robin_Watts | :) | 15:16.38 |
| kens | 1.5 GB of tht was XCode, the rest is 'command line tools' for XCode and waht feels like every package ever released for Unix | 15:16.58 |
| mvrhel | good morning | 15:20.14 |
| Robin_Watts | Morning all | 15:21.54 |
| kens | expat, curl, gperf, libiconv, ncurses, gettext, bash, bash-completion, gdbm, perl5.12, curl-ca-bundle, libidn, zlib, openssl, pkgconfig, curl (again!), p5.12-error, p5.12-encode-locale, p5.12-http-date, p5.12-file-listing, p5.12-html-tagset, p5.12-html-parser, p5.12-lwp-mediatypes,.... That's about half the packages installed so far | 15:22.02 |
| Robin_Watts | p5 = perl5. | 15:22.25 |
| kens | Up to python27 now. | 15:22.25 |
| Robin_Watts | I would assume. | 15:22.33 |
| kens | I assumed that too | 15:22.39 |
| | THere were a lot of those | 15:22.44 |
| wolfpython | hmm, are you all write code with OS X? | 15:23.08 |
| Robin_Watts | no. | 15:23.21 |
| kens | I'm trying to debug a problem that the customer claims only exists on a Mac | 15:23.30 |
| | So I need a Mac development environament | 15:23.39 |
| | And to get the soruces, I want Git to aceess the repository | 15:23.55 |
| | Which is taking an endless age to build and install | 15:24.12 |
| wolfpython | aha | 15:24.36 |
| | how about mount tmpfs and build packages in memory ? that's what i do in my Funtoo box | 15:26.50 |
| kens | I'd liek to think its nearly finished..... | 15:27.14 |
| Robin_Watts | wolfpython: The slow bit is fetching the packages from the net, not the disc access per se. | 15:28.02 |
| wolfpython | Oh, get it. | 15:29.13 |
| kens | Oh, I finally reached git-core, I hope that means all the dependencies are sorted out.... | 15:32.23 |
| | Wow, finally finished. | 15:39.40 |
| henrys | why is kens getting xcode what is he going to run it on? is there a windows simulator? | 15:43.20 |
| Robin_Watts | mvrhel: I pushed LittleCMS 2.4 (+fixes) into the gs source on friday. | 15:47.07 |
| | Not heard back from Marti re the fixes though. | 15:47.28 |
| | (I only just realised that Marti is based in europe (spain I assume). I'd assumed he was US based) | 15:47.55 |
| mvrhel | Robin_Watts: yes. I think someone handed me a bug that the device link stuff broke with the move to 2.4 | 15:50.31 |
| Robin_Watts | already? crumbs. | 15:50.44 |
| | sorry. | 15:50.46 |
| mvrhel | 693349 | 15:50.52 |
| | I need to take a look at this | 15:51.07 |
| | I also need to set up some tests for all these various color management situations | 15:51.25 |
| | as part of the weekly testing | 15:51.39 |
| Robin_Watts | oh, hmm. | 15:51.41 |
| | I had to make changes to make that bit of the code work | 15:51.50 |
| | and I discussed it with marti, and he redid the changes in a slightly different way. | 15:52.12 |
| | It may be that there are cases that don't work. | 15:52.18 |
| | If you want to throw that one back at me, feel free. | 15:52.26 |
| mvrhel | ok will do | 15:52.31 |
| | I am working on adding blackpoint compensation control | 15:52.45 |
| | for a customer | 15:52.47 |
| | Robin_Watts: ok. I gave it to you and bumped up the priority and added customer number to it | 15:55.27 |
| Robin_Watts | ok. I'll look at that as soon as I figure out what I've broken with my utf8 changes. | 15:56.34 |
| mvrhel | looks like he is using the device link profile for ink limiting. Good use of that | 15:56.44 |
| henrys | Sabrina says I've reached new heights in dorkness - I got one of these http://connect-a-desk.com/ | 16:06.46 |
| kens | I think my daughter would disown me if I used one | 16:07.30 |
| mvrhel | ha! | 16:07.54 |
| | henrys: then you can work while going for a run | 16:08.23 |
| henrys | or biking | 16:08.57 |
| Robin_Watts | Think of the productivity during toilet breaks. | 16:09.02 |
| mvrhel | true | 16:09.02 |
| | ha | 16:09.05 |
| Robin_Watts | henrys: Tell her she can borrow it for painting. | 16:09.34 |
| henrys | it actually works okay for me, if I'm doing easy stuff, I'll have to wait for the multi monitor setup before I can work on hard problems ;-) | 16:11.46 |
| mvrhel | silly question. when does the doc at http://ghostscript.com/doc/current/Use.htm update to what is in the trunk. Does that happen at each release? | 16:14.41 |
| kens | I blelieve it is updated from teh release docs yes | 16:15.27 |
| mvrhel | ok | 16:15.33 |
| kens | Off for dinner, goodnight all | 16:34.23 |
| chrisl | mvrhel: kens is correct, the "current" Use.htm file is updated with the release - we need some git hacking to have it stay up to date with master, and it's never seemed important enough to spend the time on it | 17:09.24 |
| Robin_Watts | I'd argue that it should match master | 17:09.45 |
| | gah. | 17:09.51 |
| | I'd argue that it should match the release. | 17:09.55 |
| chrisl | Hmm, maybe we all agreed on that, and that's why it didn't get worked on..... | 17:10.48 |
| mvrhel | I am fine either way | 17:12.48 |
| | release probably make the most sense though | 17:13.02 |
| | bbiab | 17:13.17 |
| chrisl | As matching the release means no more work, I'm good with that :-) | 17:13.39 |
| Robin_Watts | henrys: ping | 18:54.14 |
| | Well, for the logs and discussion anyway... I'm looking into the unicode/windows thing again. | 18:54.51 |
| | The current solution in the code for unicode is to let the windows app get called through wmain, which gives it a 'unicode' argv. | 18:55.55 |
| | (Or at least, what microsoft calls unicode, meaning it's UTF16ish) | 18:56.23 |
| | I then convert that argv down to a UTF8 version, and call the normal entry points. | 18:56.48 |
| | When we come to open files etc, I convert back from UTF8 to unicode and open that. This solution seems to work well, with the stated objection that we are changing the meaning of the entrypoint, which has always historically expected 'local' encodings in. | 18:58.10 |
| | So I was going to add a new _utf8 entrypoint. This would have done exactly what I just described. The normal entrypoint would continue to take locally encoded stuff. | 18:59.57 |
| | (So it would convert from local encoding to unicode, then from unicode to utf8). | 19:00.50 |
| | But then I spotted the fact that gs supports @ files. | 19:01.56 |
| | Is it reasonable to assume that the @file is formatted in the same way as the args ? | 19:03.02 |
| kens | As long as its clearly documented, I don't see a problem with that | 19:06.02 |
| Robin_Watts | The problem I'm having here is that I can't make the non-unicode case work right. | 19:06.56 |
| | I have a file called 'tigerBETA.eps' where BETA is a thorn/beta symbol. | 19:07.23 |
| | If I get called through the non-unicode entrypoint, something is getting the beta wrong - possibly because there are 2 symbols in the codepage that look similar and a mapping is getting screwed. | 19:08.23 |
| | Ah, but the existing gs can't call it either, so I'm no worse off. | 19:10.07 |
| ghostscript776 | Hey MuPDFDevelopers ! Anyone here ? | 19:52.51 |
| | well thanks for the awesome fits based library ! I have been lurking in to the source code to use it for the pdf rendering purpose in my android app | 19:53.47 |
| | I looked in to the sample app and saw the native methods exposed inside mupdf.h which comprises of getInternalPage and Draw | 19:54.22 |
| kens | ghostcript776 the developers are European based, and mostly offline at this time of night | 19:54.52 |
| | but the channel is logged and they will read it | 19:55.00 |
| ghostscript776 | thanks Kens...let me post this...i shall wait for their reply in that case ! | 19:55.32 |
| kens | Here's the URL for the logs: | 19:56.41 |
| | http://ghostscript.com/irclogs/current.html | 19:56.41 |
| ghostscript776 | Devs: So the thing is I need few utilities for Android App such as : 1) an utility to get the page number of the currently displayed page of the pdf 2) An API to fetch the text data on a particular page 3) A API to get the word given 4 rectangular X-Y coordinates.... So Is there a way I could achieve all these 3 requirements with the current muPDF 11 code or I need to play around with eh source to get these things do | 19:59.51 |
| henrys | sorry Robin_Watts I was away from IRC - reading now. | 20:36.40 |
| ghostscript776 | any Dev ninja ..who could help me here... | 20:38.41 |
| henrys | kens, Robin_Watts: don't know how far you should go with the file stuff what about postscript languages file operations, search directories, library files etc.? I thought we were just going to modify the API for input files. | 20:47.54 |
| | bbiab | 21:00.16 |
| Robin_Watts | ghostscript776: All that is achievable with the existing code. Talk to us tomorrow. | 23:11.41 |
| | henrys: The theory was that in the old scheme, whatever filenames got passed in on the command line would be passed straight back out to the fopen call. | 23:14.01 |
| | So windows codepage encoded stuff would go in, windows codepage encoded stuff would get passed to fopen. | 23:14.27 |
| | On linux utf8 goes in on the command line, and utf8 is fed to the fopen. | 23:14.46 |
| | If we want to be in the situation of using utf8 consistently inside gs, then we need to convert names on the way in, and we need to convert the utf8 names on the way out. | 23:15.31 |
| | The code to do utf8 -> unicode and then fopen the unicode name is already in place. | 23:15.48 |
| henrys | right and I thought we weren't concerned with filenames that come from places other than the command line - environment available and postscript programs for example, is that right? | 23:29.30 |
| | s/available/variable | 23:30.19 |
| Robin_Watts | If postscript programs generate filenames internally, then on linux they'll be interpreted as utf8. | 23:31.03 |
| | On windows they would historically have been interpreted according to the whim of the currently set codepage. | 23:31.25 |
| | In the new world, they will be interpreted as utf8 everywhere. | 23:31.43 |
| henrys | oh I didn't realize that code was in place. | 23:32.16 |
| Robin_Watts | henrys: The code is in place but not enabled. | 23:32.35 |
| | (unless you build with USEUNICODE) | 23:32.46 |
| henrys | I should look at the code so I know what the hell I'm talking about first that might save us some time. | 23:33.00 |
| Robin_Watts | The commit I am preparing here swaps it to be on by default. | 23:33.04 |
| | I'll put the commit on my repo for comments before tomorrows meeting. | 23:33.18 |
| henrys | okay sounds good. | 23:33.42 |
| Robin_Watts | (by the meeting I will have put it up, not "I expect comments by the meeting"). | 23:33.43 |
| henrys | right | 23:35.06 |
| Robin_Watts | I did have: gsapi_init_with_args and gsapi_init_with_args_utf8, but I think I prefer the idea of doing a: gsapi_set_arg_encoding() and then just having a single entry point. | 23:42.51 |
| | Forward 1 day (to 2012/09/25)>>> | |
IRC Logs