| <<<Back 1 day (to 2011/10/18) | 2011/10/19 |
arthurf | ray_laptop: I think system_profiler | grep 'Serial Number (system)' was answer #4 - if I counted right - the main problem is that the CD / DVD drive spins up on activation - and it takes a few seconds to return the unique id | 02:33.26 |
| ray_laptop: I just heard my own drive spin up when I tried it on my MacBook Pro. | 02:34.35 |
| This avoids the DVD drive spin up delay -> system_profiler SPHardwareDataType | grep 'Serial Number (system)' | 03:24.04 |
ray_laptop | arthurf: so, you confirm robin_watts' finding that OS/X doesn't have the (somewhat standard) sys/sysinfo.h ? | 03:43.00 |
arthurf | ray_laptop: yes | 03:43.21 |
ray_laptop | arthurf: I may have misread the stackoverlow page -- I was looking at: | 03:45.13 |
| void get_platform_uuid(char * buf, int bufSize) { | 03:45.15 |
| io_registry_entry_t ioRegistryRoot = IORegistryEntryFromPath(kIOMasterPortDefault, "IOService:/"); | 03:45.16 |
| CFStringRef uuidCf = (CFStringRef) IORegistryEntryCreateCFProperty(ioRegistryRoot, CFSTR(kIOPlatformUUIDKey), kCFAllocatorDefault, 0); | 03:45.18 |
| ... | 03:45.19 |
| arthurf: note that I haven't looked into whether or not that works (or even builds) | 03:47.33 |
arthurf | ray_laptop: okay - it looks like it will need to be linked with Core Foundation and the IOKit - just from reading the code blurb - I'll try it out just for fun | 03:49.55 |
| ray_laptop: I get a UUID from the example code - which probably matches your requirement. Trying to confirm that kIOPlatformUUIDKey is indeed the right key, likely is. | 04:09.07 |
| It's the right one - I see the Hardware UUID under Serial Number in About This Mac / More Info - and it's a match with the results from the code. | 04:10.36 |
| The following includes are required - along with the frameworks of the same name | 04:14.56 |
| #include <CoreFoundation/CoreFoundation.h> | 04:14.58 |
| #include <IOKit/IOKitLib.h> | 04:14.58 |
visitor1 | hi there, how do i start mupdf under ubuntu 10.04 | 04:35.27 |
| i downloaded it and extracted it but i cant start it | 04:35.44 |
ray_laptop | bed time... | 06:19.09 |
Robin_Watts | Am I missing something obvious? | 09:47.19 |
| In Thunderbird, it correctly marks a load of messages as being junk - but doesn't immediately move them to the junkfolder. | 09:47.48 |
| Is there a way to say "Move all the junk items to the junk folder" ? | 09:48.04 |
chrisl | I think you setup a filter - Tools->Message Filters - although, between spamcop and gmail, I've never had to bother...... | 09:52.18 |
Robin_Watts | I've got it to move junk messages directly. | 09:54.07 |
| but it's not ideal. | 09:54.11 |
| reboot | 11:40.19 |
kens | Hi ray_laptop | 14:43.07 |
Robin_Watts | Sheesh. | 14:43.47 |
| This file works fine on 32bit windows, 64 bit windows, 32 bit linux... but not 64bit linux. | 14:44.16 |
| Guess which one, I *can't* easily debug locally... | 14:45.49 |
kens | Hmm, 'Dear Team' from someone who seems to be a free user (government at that !) | 14:54.44 |
| I think I'll point Scott at him :-) | 14:54.55 |
Robin_Watts | kens: reply with "Dear Freeloader" :) | 14:56.52 |
kens | Oh no, I have asked him nicely to confirm that they are a customer, and passed them over to Scott. | 14:57.54 |
| They claim to represent the FSA in the UK. | 14:58.10 |
| I figure they can afford a support contract | 14:58.19 |
henrys | kens:that was an odd one "dear team" | 15:04.10 |
| kens:are we up to date on support? | 15:04.48 |
kens | henrys, I believe we are yes. | 15:05.11 |
| I've seen 'Dear Team' from India before, but not previously from someone in the UK. | 15:05.34 |
Robin_Watts | 64bit linux banded only, it seems. The hits just keep coming. | 15:37.18 |
henrys | kens I'll start responding to support when you sign off - there's a message now. | 15:52.50 |
kens | thanks henrys, missed it, I'll get itnow | 15:53.27 |
henrys | fine to leave it too either way | 15:54.08 |
kens | Not a problem, I'll do it now | 15:54.18 |
henrys | that reminded me we had a recent luratech fix by alexcher that I thought ray_laptop raised a problem about and then it was dropped. | 15:58.14 |
kens | mail sent with the link and stuff | 16:00.18 |
| Over t oyou henrys | 16:00.25 |
kens | passes virtual baton | 16:00.33 |
henrys | 10/4 | 16:00.48 |
| odd url in your mail. | 16:06.25 |
| it is repeated 2x | 16:06.39 |
kens | Odd, it isn't here. | 16:07.07 |
henrys | but it works fine clicking on it. In gmail I see: <http://www.ghostscript.com/%7Ecustomer/releases/9.04/>http://www.ghostscript.com/~customer/releases/9.04/ | 16:07.39 |
chrisl | It look like a pseudo-html tag | 16:07.49 |
kens | Oh, I think that must be your mail client, I don;t send HTML mail | 16:08.00 |
chrisl | My mail client is set to display as plain text...... | 16:08.38 |
kens | mine displays and sends plain text | 16:08.48 |
henrys | I'm using web gmail | 16:08.50 |
chrisl | Weird, none of the "view as" settings make a difference in tbird..... | 16:09.53 |
henrys | and looking at the original message without any interpretation the string above is what it is. | 16:09.57 |
Robin_Watts | Looks odd in thunderbird too. | 16:10.00 |
chrisl | I wonder if it's gmail trying to be "clever"....... | 16:11.26 |
henrys | I believe I am looking at the raw message and I see the repeated string above. | 16:11.59 |
Robin_Watts | me too. | 16:12.20 |
chrisl | Yeh, I mean gmail tweaking the message text when it spots what looks like a link | 16:12.43 |
Robin_Watts | You mean gmail rewriting the message as it sends it? rather than the gmail web client ? | 16:13.30 |
chrisl | Yes | 16:13.50 |
| It's also interesting that the one enclosed in the <> has an escaped character | 16:14.51 |
henrys | I doubt google would rewrite folks mail, but maybe. | 16:15.14 |
| kens what's your client? | 16:15.35 |
ray_laptop | chrisl: well, in a URL you need to escape special characters, but not in the "raw text" | 16:15.37 |
chrisl | ray_laptop: sure, which again hints at a pseudo-html tag rather than plain text. | 16:16.33 |
ray_laptop | are you guys talking about the message from Dean B ? | 16:16.40 |
| I have it on tbird and it looks OK | 16:16.52 |
henrys | I think kens client rewrote it because of the ~ and wrote it again as a bug. | 16:17.01 |
kens | henrys Eudora | 16:17.09 |
henrys | now I'm convinced ;-) | 16:17.20 |
chrisl | Well, it works okay, so it's not exactly a big deal | 16:17.44 |
henrys | ray_laptop:I left a question for you about the luratech bug above - was your problem with alexcher's fix resolved? | 16:18.08 |
| yeah no big deal. | 16:18.17 |
ray_laptop | henrys: Yes, iirc (can't recall the details now) | 16:18.37 |
henrys | great | 16:19.19 |
ray_laptop | Oh, I see -- the strange looking link is in Ken's email to Axel | 16:19.49 |
kens | apparenlty so | 16:20.23 |
henrys | alexcher are you around we need a public branch for your type 1 stuff - chrisl can help you with that while he is here he has good git kung fu. | 16:20.31 |
Robin_Watts | Sheesh. Now valgrind runs clean on 64bit linux, and I *still* get different results than on 32bit. | 16:22.40 |
ray_laptop | In tbird I just use 'Insert / Link ..." and it lets me have the text to show as the link different to the link itself. But Ken's message it isn't formatted properly (as <a href="___">other text</a> | 16:23.54 |
| whatever tool created that link is pretty broken | 16:25.27 |
Robin_Watts | ray_laptop: I suspect it's Eudora spotting a link and rewriting it into a form that is less likely to get mangled by email transmission. It's not attempting to write html, hence it's hard to claim that it's 'wrong'. | 16:26.57 |
ray_laptop | Robin_Watts: True, I guess. but it sure makes for a confusing email on the receiving end. | 16:34.46 |
kens | Well I don't usually have a problem, it may be because I cut and paste it fomr a Marcos email | 16:35.20 |
Robin_Watts | Or it may be that your usual links don't have ~ in them ? | 16:35.47 |
kens | That's also a possibility | 16:35.57 |
henrys | yeah i was thinking you could resend to support without the ~ ... | 16:36.30 |
kens | As a test you mean ? | 16:37.25 |
henrys | yes | 16:37.48 |
ray_laptop | chrisl: you "own" the configure.ac -- I want a flag for 'HAVE_SYS_SYSINFO" -- (for the presence of include/sys/sysinfo.h) any objections ? | 16:37.49 |
chrisl | ray_laptop: no objections, no | 16:38.27 |
| ray_laptop: are you happy doing the changes in there? | 16:38.53 |
ray_laptop | oh, looking at it, I should have the flag be HAVE_SYS_SYSINFO_H | 16:39.04 |
| chrisl: happy isn't exactly the right emotion | 16:39.20 |
chrisl | ray_laptop: :-) point taken - perhaps "confident" would be a better word | 16:39.48 |
ray_laptop | chrisl: but since I am just cloning that is there for HAVE_SYS_TIME_H | 16:39.54 |
kens | test email sent out | 16:40.29 |
ray_laptop | I'll do it and send you the diff to configure.ac and Makefile.in for your comment | 16:40.45 |
chrisl | ray_laptop: okay, cool. | 16:41.06 |
| kens: that still has the oddness - I wonder if Windows is pasting rtf instead of plain text, or something | 16:41.46 |
kens | It is possible. | 16:41.58 |
| But as long as the customer can follow the link it'll be OK | 16:42.35 |
ray_laptop | kens: can't you have Eudora send HTML ? | 16:45.40 |
chrisl | shudders...... | 16:45.58 |
ray_laptop | that's what I do and I've never had a problem with customer reading it | 16:46.11 |
kens | ray_laptop : I can, but I think HTML email is an abomination that should be banned | 16:46.30 |
ray_laptop | kens: Oh, sorry. I didn't mean to blaspheme ;-) | 16:46.54 |
| kens: it can be really difficult when your religion is looked on by the rest of the world as a cult ;-) | 16:48.13 |
kens | I've given up expecting everyone else to conform, but I don't have to ;-) | 16:48.44 |
Robin_Watts | is with ken on this. | 16:49.25 |
henrys | I'd rather have the link repeat 50 times than get html | 16:50.57 |
kens | time to go , night all | 16:56.04 |
henrys | bye kens | 16:56.17 |
ray_laptop | you guys have never complained to me about getting HTML -- isn't that what you get in emails from me ? | 16:59.20 |
Robin_Watts | ray_laptop: html mail tends to send both a text version and an html one. | 16:59.50 |
| so we read the text version. | 16:59.58 |
| and (speaking for the others) I will read html mail (grudgingly) but I won't contribute to the problem by proliferating it :) | 17:00.27 |
| s/the others/myself, not necessarily the others/ | 17:01.14 |
ray_laptop | Robin_Watts: yes, it sends both, but text tends to be displayed (by many tools) using fixed space fonts, so my lines are probably pretty ragged | 17:01.37 |
Robin_Watts | Oh no! How will we cope! :) | 17:01.55 |
| Anything other than fixed space fonts is asking for chaos, right? | 17:02.35 |
| If I format something in fixed spaced fonts and send it out to someone else with fixed space fonts, they have a hope of reading it as it was formatted. | 17:03.14 |
ray_laptop | yeah, and we should all make sure our lines are 80 characters or less so that reading on dumb terminals doesn't wrap ;-) | 17:03.31 |
Robin_Watts | If I format something in proportional fonts and send it out, NO ONE is guaranteed to be able to get the same thing :) | 17:03.55 |
| ray_laptop: My client wraps at 72 chars to allow for quoting. | 17:04.16 |
ray_laptop | of course, my ASR-33 only has 72 characters line width | 17:04.20 |
ray_laptop | thinks that none of you will even remember ASR-33 | 17:05.14 |
mvrhel2 | they look heavy | 17:07.40 |
| robin_watts: let me know when I need to get to work on the halftone bands buffer stuff. I am going to work on some of these XPS bugs right now | 18:00.31 |
| oh we need to figure out about making lcms2 live also | 18:00.55 |
Robin_Watts | mvrhel2: I've been stuck all day on this bug. | 18:01.31 |
henrys | what's up with that, tkamppeter has gone rogue or something? | 18:01.58 |
Robin_Watts | I made what I thought should be the fix to avoid having to use copy_plane, and it works on 32/64bit windows and 32bit linux, but it's failing on 64bit linux. | 18:02.28 |
mvrhel2 | ugh | 18:02.39 |
henrys | Robin_Watts:how does it fail? | 18:03.22 |
Robin_Watts | Different rendering. | 18:03.53 |
henrys | my new pcl code is crashing in the sse2 code but I'm not ready to say it isn't my fault yet. | 18:04.11 |
| so this is the fix to use copy_planes instead of copy_plane? | 18:06.05 |
| tor8:there is a suggestion to use third party mobile developers to fast track the mupdf port, mobilezapp, my guess is it would be very expensive and they wouldn't beat your current schedule by much but it would save you doing it. | 18:10.43 |
| tor8:it does seem we could benefit from third party expertise in ios. | 18:12.02 |
Robin_Watts | If we're in the market for having another developer come on board to get a port out quickly, I know someone who'd be a good choice and who might be interested. | 18:12.08 |
| (but he's not an iOS expert) | 18:12.45 |
| (Then again, I know iOS and Android experts that may be available too) | 18:13.24 |
tor8 | henrys: considering I already invested the time to learn ios development I may as well continue | 18:13.45 |
henrys | okay | 18:14.29 |
tor8 | the current code that's checked in on user/tor/mupdf.git already works better than the old demo :) | 18:14.34 |
| I picked up an iPad today, and reactivated the dev account so soon I'll be able to test this thing on something other than the simulator | 18:15.07 |
| henrys: there's a secondary benefit to me writing these apps -- I get to know first hand what parts of the API that need improvement to make them easier to use in different scenarios | 18:16.03 |
Robin_Watts | tor8: That's unquestionably good knowledge to have in house. | 18:17.49 |
tor8 | Robin_Watts: quite. the pdfdraw and pdfclean command line suite have been good for banging on the batch processing and cli feature set, but the x11 viewer is so rudimentary it's not really indicative of anything | 18:19.06 |
vtorri | tor8: and you'll use plain xcb ? or xlib ? | 18:19.36 |
Robin_Watts | tor8: It strikes me that a lot of what we want a viewer to do (certainly a desktop one) is GUI rather than guts. | 18:19.55 |
| The guts can already do everything we need for fit to window, facing pages, continuous views etc. | 18:20.19 |
tor8 | Robin_Watts: yeah. the guts are there, but how you access them varies in how bloody hands you'll get | 18:20.25 |
Robin_Watts | Making the viewer do it is just donkey work. | 18:20.36 |
tor8 | and I think a lot of common operations a viewer wants to do can be streamlined | 18:20.55 |
Robin_Watts | Yes. | 18:21.04 |
tor8 | there's a bit too much "boiler plate" code to set up the common operations, like rendering a page | 18:21.37 |
Robin_Watts | The person I have in mind for this is Paul Gardiner. He was my business partner for many years, and is a good friend. He has a gift for spotting the 'right' interface for things. | 18:21.58 |
tor8 | then again, it's designed more as a tool box than a consumer-device-like-pipeline-api | 18:21.59 |
Robin_Watts | Helping out on the viewer would be a good way to draw him in and get him to know the interfaces as they are; then I'm sure he'd have ideas about what could usefully be rejigged. | 18:25.18 |
tor8 | Robin_Watts: is he the non-ios/android developer? | 18:25.49 |
Robin_Watts | Yes. | 18:26.08 |
| He has a lot of experience of developing for embedded devices (he, like me worked for Picsel for many years), but he's not specifically wrangled iOS or android, I think. | 18:26.56 |
| Anyway, I thought I'd mention him while the subject was raised. | 18:27.25 |
tor8 | Robin_Watts: btw, none of the iOS examples or frameworks or documentation as far as I can tell ever check for malloc failures... | 18:27.46 |
| yeah, it may well be worth sticking him with the android port | 18:28.28 |
Robin_Watts | I really hope that's because they simplified for ease of exposition. | 18:28.35 |
| Oh, and he's the co-author of the try/catch stuff :) | 18:29.17 |
mvrhel2 | bbiab | 18:40.58 |
tor8 | Robin_Watts: apple is not being very informative in their documentation about what NSObject +alloc can return (no mention anywhere of null being returnable from it... which is a bit of an odd thing to not document) | 18:48.00 |
| I know from way back when I was using objective c that passing a message to null is a no-op | 18:48.21 |
Robin_Watts | tor8: Try mallocing 16 meg repeatedly :) | 18:59.18 |
| or if malloc isn't the issue, malloc 1 meg chunks until it starts to fail, then repeatedly create new objects... | 18:59.58 |
tor8 | eternal loop creating new NSStrings waiting for the bomb should do the trick | 19:00.20 |
Robin_Watts | How can banding be giving different results on the same command line on windows and linux? Both 64bit. | 19:10.53 |
henrys | I've been campaigning for a windows regression machine, be nice! | 19:15.33 |
| have you tried both debug and optimized? | 19:16.11 |
Robin_Watts | And memento. | 19:16.20 |
| and valgrind gives it a clean bill of health. | 19:16.33 |
henrys | okay so -ZL to files remove the addresses and do a diff. | 19:16.43 |
Robin_Watts | That's what I'm looking at now. | 19:16.57 |
| The offsets are different. | 19:17.02 |
| and this tile is being written as 256x1 instead of 80x80 | 19:17.17 |
| trying to see why now. | 19:17.27 |
tor8 | Robin_Watts: different floating point instruction ordering, or truncating from the 80-bit registers at different locations? | 19:17.42 |
Robin_Watts | Looks like the tile hash table is different somehow. | 19:36.07 |
| sizeof(*cdev->tile_table) is 8 on linux, and 4 on windows. | 19:40.47 |
| What is a ulong supposed to be ? | 19:42.30 |
vtorri | long is 4 bits on win 32 bits or 64 bits | 19:43.59 |
| contrary to unix | 19:44.23 |
| where long is 4 bytes on 32 bits and 8 bytes on 64 bits | 19:44.42 |
Robin_Watts | Indeed, and that's a difference. | 19:45.01 |
vtorri | so don't use long :) | 19:45.19 |
Robin_Watts | I suspect, that given we mean "ulong" to mean "at least 32bits", we should make ulong be unsigned int on linux. | 19:45.36 |
| That way we'd be consistent. | 19:45.47 |
| henrys: Am I right in thinking that we use ulong to mean "at least 32bits" ? | 19:46.21 |
Robin_Watts | would like to see us move to int32_t, uint32_t, etc and make it explicit. | 19:47.38 |
vtorri | if the spec you use is C99, yes, but beware that vc++ is not C99 | 19:48.28 |
henrys | I agree we should use inttypes.h and provide our own replacement if the explicit types aren't available. | 19:48.48 |
vtorri | they have other types __int32, __int64, etc... | 19:48.51 |
henrys | Robin_Watts:what is the typedef you are look at in gs? | 19:49.15 |
Robin_Watts | henrys: typedef struct { ulong offset; } tile_hash | 19:49.37 |
| and typedef unsigned long ulong; | 19:49.49 |
| from stdpre.h | 19:49.53 |
| vtorri: We should standardise on the names that C99 uses, and provide them via our own typedefferey if we are on older C compilers. | 19:50.53 |
henrys | my concern would be some evil code buried in storing pointer in a long, of course that would be broken on windows already. | 19:52.25 |
| I guess I don't undestand why that should matter output wise 32 vs. 64 bit offset we should get the same output anyway right. | 19:54.38 |
| ? | 19:54.39 |
| a bug for ray_laptop? | 19:54.59 |
Robin_Watts | henrys: It may be that this doesn't actually matter. | 20:08.28 |
| But it makes it harder to do side by side comparisons. | 20:08.39 |
| Certainly the raster calculations are different on windows and linux; linux aligns to 8 where windows aligns to 4. | 20:09.13 |
| But the problem here appears to be that on linux I'm getting a -13 return code from cmd_put_bits in clist_change_tile. | 20:09.52 |
| Dinner time. Will look more later (well, tomorrow, probably) | 20:10.04 |
tor8 | Robin_Watts: eww, that's baaaad. the iOS drops touch events if an event triggers heavy processing. | 20:11.11 |
sebras | tor8: iOS doesn't have to _be_ good, just good looking... | 20:13.17 |
tor8 | well, at least they made the right choice in using opengl for all graphics compositing everywhere | 20:17.25 |
mvrhel2 | ah. nice. Visual studio has a XPS editor | 20:59.30 |
| hmm. doesn't like it though when I edit the xml | 21:00.58 |
| thats real useless | 21:01.09 |
| ah. there it worked | 21:04.03 |
| this will make figuring out the xps issues a bit easier | 21:06.44 |
henrys | ray_laptop you around? | 21:57.57 |
| guess not | 21:58.16 |
| I sent him mail. | 22:01.26 |
Robin_Watts | I fear a compiler bug :( | 23:18.18 |
mvrhel2 | hmm. our parsing in the xps interpreter is not very robust to spaces in several places. I think this need to be done in a slightly different manner | 23:26.33 |
Robin_Watts | mvrhel2: fun. | 23:27.11 |
mvrhel2 | yes. not glamorous work, but it has to be done.... | 23:27.47 |
| not as exciting as a compiler bug.... | 23:28.10 |
Robin_Watts | I think that fear has passed. | 23:28.27 |
mvrhel2 | thats good | 23:28.32 |
Robin_Watts | It looks like it's writing the right bitmap into the clist, but the wrong index (and hence the wrong data) is being read out. | 23:29.04 |
| Instead of an 80x80 tile, we read the next one, and get a 256x1 tile. | 23:29.46 |
| and so, of course, the rendering is different. | 23:30.19 |
mvrhel2 | clist work, is best done after a good nights rest. I think I would call it a day/night if I were you | 23:30.48 |
Robin_Watts | Yeah, I'm just off to bed. | 23:30.58 |
mvrhel2 | ok. tty tomorrow | 23:31.10 |
Robin_Watts | If I don't solve this by the time ray wakes up tomorrow, I may try and drag him into it. | 23:31.14 |
mvrhel2 | always a good idea | 23:31.21 |
| bbiab | 23:31.43 |
Robin_Watts | I'd try and pull the 64bit linux things into line with the 64 bit windows ones, but I fear that would just mask the problem. | 23:31.46 |
| Night. | 23:31.48 |
mvrhel2 | good night | 23:32.02 |
| Forward 1 day (to 2011/10/20)>>> | |