| | <<<Back 1 day (to 2014/11/10) | 20141111 |
| henrys | yikes arctic cold front ... | 15:04.33 |
| pedro_mac | time to get the snow tires on ;) | 15:05.59 |
| henrys | interesting summary of some font law cases: http://books.google.com/books?id=c6IS3RnN6qAC&pg=PA42#v=onepage&q&f=false | 15:18.25 |
| kens | I'm reasonably sure that Europe allows copyright in font designs, that does seem to be a summary of US case law | 15:20.00 |
| henrys | I didn't know there was a monotype vs urw case. | 15:20.15 |
| kens | Its a new one on me, but there have been quite a few cases wordlwide. I thought it had all settled down, b ut maybe not | 15:20.49 |
| henrys | kens: the term of protection is 25 years - so for the important fonts the european law does not apply, there are other restrictions as well which make europe law less relevant - like demanding the same ordering. | 15:23.26 |
| kens | Hmm, sounds like you've been readin gup on it, I'm not up to date with the law in this area, haven't been following it since I left Monotype | 15:24.12 |
| henrys | kens: yes this is all fresh reading for me. URW has suggested that it would be legal for us to call their fonts by their canonical names but I don't agree from what I've read. | 15:27.05 |
| | 3 minutes to the meeting... | 15:27.39 |
| kens | The names at least are trademarks, and companies have been fiercely protective of those. Not least because those are definitely protected pretty much everywhere | 15:27.43 |
| henrys | kens: I was amazed monotype own "times new roman" how can somebody own that? | 15:28.33 |
| kens | Because they created the font specifically for the Times newapaper | 15:28.55 |
| henrys | owns the trademark that is. | 15:29.02 |
| kens | Why not ? Its a fairly unique conbination for the name | 15:29.24 |
| marcosw | Apple owns "apple", that's even less unique :-) | 15:29.38 |
| henrys | so michael won't be here. | 15:31.53 |
| Robin_Watts | henrys: He's asleep now, flying back later today. | 15:32.33 |
| henrys | marcosw: about xpswrite - what michael and I would like is to be able to do a clusterpush (local) and have xpswrite tested against only the pdf fts. | 15:32.50 |
| | Robin_Watts: right. | 15:33.06 |
| rayjj | morning, all | 15:34.46 |
| henrys | kens, marcosw : I am surprised it did not end up like courier, without a legal name owner. | 15:34.50 |
| kens | Morning | 15:34.51 |
| rayjj | sorry I'm late | 15:34.54 |
| kens | Henrys I htink Monotype were careful to get the rights back then | 15:35.12 |
| | And to protect them afterwards | 15:35.21 |
| rayjj | Apple doesn't entirely own "apple" | 15:35.33 |
| | just as a trademark in certain business areas | 15:36.01 |
| marcosw | henrys: wikipedia says about courier: "Although the design of the original Courier typeface was commissioned by IBM, the company deliberately chose not to secure legal exclusivity to the typeface and it soon became a standard font used throughout the typewriter industry." | 15:36.16 |
| rayjj | One could probably create a font and call it Apple | 15:36.20 |
| marcosw | rayjj: yes, but I'm pretty sure if you built a car and called it times new roman you'd be okay too. | 15:36.38 |
| | rayjj: like Apple Garamond? | 15:36.59 |
| rayjj | Courier would be a better name for a car ;-) | 15:37.01 |
| henrys | marcosw: right and I'm surprised times new roman came to be a standard font without that. | 15:37.31 |
| kens | It was a popular font, back then you had to buy your fonts from somone, so..... | 15:38.16 |
| | (Its hard to pirate lead type) | 15:38.41 |
| marcosw | henrys: I think I can add xpswrite to clusterpush without too much difficultly. | 15:38.44 |
| henrys | marcosw, kens : shall I add XFA to the agenda for discussion? | 15:38.46 |
| kens | henrys, can do, certainly. Its lack is not a bug in the PDF interpreter, its a commercial decision whether we add support for it (needs an XML parser and layout engine probably) | 15:39.26 |
| henrys | kens, marcosw : I notice it is unimplemented in pdfium so I guess FoxIt didn't give google everything ;-) | 15:39.32 |
| kens | We,, its not really a part of PDF. | 15:39.52 |
| | Its an extension in much the same way as 3D stuff, or movies | 15:40.06 |
| rayjj | and with a layout engine comes the 'is it done correctly' issue (i.e., will we have to match Adobe layout ?) | 15:40.26 |
| henrys | kens: right I thought we would kick around the importance of the customer and the competitors having it at the meeting. | 15:40.33 |
| kens | I imagine we will have to, yes | 15:40.46 |
| | Sure | 15:40.53 |
| kens | thinks I'd better read up on it some more before then | 15:41.09 |
| rayjj | kens: that would sway me to "run away screaming" | 15:41.14 |
| kens | In any event, we do not have resource to do it at present | 15:41.31 |
| rayjj | (having a goal of matching Adobe's layout) | 15:41.33 |
| kens | I'm not sure how hard that is likely to be, I don;t know enough about the XFA standard yet | 15:41.53 |
| rayjj | we don't even match their graphics exactly enough for some PDF's | 15:41.57 |
| Robin_Watts | I might be tempted to think about supporting XFA by doing a PDF(XFA)->PDF conversion tool. | 15:41.58 |
| henrys | kens, tor8 : I wonder if it something to be done in mupdf instead... | 15:42.03 |
| Robin_Watts | Possibly based on MuPDF. | 15:42.09 |
| kens | Well all the XFA stuff seems to be Adobe specs | 15:42.43 |
| Robin_Watts | henrys: yes, that was what I was thinking. We could leverage the layout engine that tor is currently doing, maybe. | 15:42.44 |
| kens | http://partners.adobe.com/public/developer/xml/index_arch.html | 15:42.52 |
| henrys | tor8: we need to find some work for fred, whadya got? | 15:42.58 |
| tor8 | henrys: I'd have to stop and think for a while | 15:44.10 |
| jogux | henrys: he doesn't do mobile, right? | 15:44.32 |
| henrys | jogux: I believe he does, I asked about sot and Robin_Watts and paulgardiner didn't think there was anything and suggested mupdf. I'd much rather have him work on sot if you have something. | 15:45.40 |
| Robin_Watts | henrys: You said he was a "UI guy" | 15:46.30 |
| henrys | Robin_Watts: yes he is. | 15:46.48 |
| Robin_Watts | As such, I don't think there is much SOT "UI" stuff that can be done at the moment (unless he's secretly a graphic designer too?) | 15:47.00 |
| | Or rather, there probably *is* UI stuff that can done at the moment, but it would involve him learning a whole new UI system (UE2). | 15:47.36 |
| | and that work would cease to be useful when/if we get native UI off the ground. | 15:47.54 |
| jogux | we have some android/iOS specific stuff, but thinking further it probably strictly doesn't fit into the 'UI' bucket. | 15:48.17 |
| henrys | jogux: I think it would be fine to give him stuff like that. I didn't mean to say that's all I can do, that is just where he's worked most. | 15:49.58 |
| | hi chrisl | 15:50.40 |
| chrisl | hi henrys | 15:51.13 |
| jogux | henrys: maybe come back to this in the next meeting? | 15:51.35 |
| henrys | tor8: I do also see mupdf bugs are piling up, Robin_Watts or paulgardiner can be assigned to mupdf for a while if they are at a point where a break would be okay. | 15:51.59 |
| | jogux: fair enough | 15:52.24 |
| Robin_Watts | henrys: Paul and I discussed that briefly the other day. We are aware of it. | 15:52.59 |
| henrys | Robin_Watts and paulgardiner: so I don't really need to get into it, you two will figure when it is prudent to do some mupdf stuff and we'll leave it with that? | 15:54.13 |
| chrisl | rayjj: are you okay dealing with the current stuff from Len? Is it okay if I put it aside - at least for now? | 15:54.23 |
| Robin_Watts | henrys: Yeah. We'll break off at an appropriate moment. | 15:54.36 |
| rayjj | chrisl: I don't think there is much point for both of us messing with the confusion of data | 15:54.48 |
| Robin_Watts | If we forget (or you feel that it's more urgent), do prod us again, obviously. | 15:54.59 |
| chrisl | rayjj: no, I was getting very confused.... but don't hesitate to ping me if you want me to look again | 15:55.30 |
| henrys | my last item was for chrisl and I didn't have anything else for the meeting. Does anyone have news or issues to discuss? | 15:55.40 |
| rayjj | chrisl: the frustrations are (1) the data from different sources is inconsistent and (2) we are looking for < 5% improvement that seems to be spread across all of the pages | 15:56.27 |
| henrys | chrisl: if directory reorganization is not going well we can abandon. I have another idea about language switching that I think will suffice and will be much easier. I know that isn't the only long term goal of the project but ... | 15:56.59 |
| | s/directory// | 15:57.14 |
| chrisl | henrys: I just need the time to dedicate to it.... | 15:57.27 |
| rayjj | henrys: I have a cache scheme that recovers the performance hit due to the clist tempfile changes. I'm retrofitting the scheme to be shared with the memfile (design accomodates both) | 15:57.34 |
| chrisl | rayjj: yeh, and although I got the VS profiler to "work", the results were complete nonsense (from the instrumented version) and completely useless (from the sampled one) | 15:58.24 |
| rayjj | I want to make sure that it's in place way sooner than the next release | 15:58.27 |
| henrys | rayjj: okay great, there is a p1 crash for the tempfile stuff, is that the same thing? | 15:58.46 |
| rayjj | chrisl: all I can get the VS profiler to do is reboot my machine :-( | 15:59.03 |
| chrisl | henrys: I was just getting back into the build reorg when the latest thing from Len came in.... | 15:59.04 |
| | rayjj: I had to use the command line tools to get the profiler to work | 15:59.22 |
| rayjj | henrys: I'll look at the crash as well | 15:59.38 |
| henrys | chrisl: right, my idea was to leave gs as is and make pcl and xps clients of the library than have a simple little app to switch between the regular gs iapi and the pcl frontend... the latter I'd simplify. | 16:00.57 |
| chrisl | henrys: that's essentially the approach I'd envisaged even with the build changes. | 16:02.11 |
| henrys | chrisl: but if you think the reorg is coming along then we'll stick with that. I really don't want to be caught without a robust language switching solution when a large printer customer rolls in. | 16:02.45 |
| chrisl | henrys: I'm hoping to keep my head out of the bugs arena for a couple of weeks, hopefully make some good progress - as long as Len doesn't pipe up again! | 16:03.51 |
| rayjj | I'm a bit surprised that I haven't yet gotten a "we got your email" from Saito-san (company S) re: the dither pattern issue. Should I ping them this week again ? | 16:05.11 |
| chrisl | rayjj: maybe check with Miles about it? | 16:06.16 |
| rayjj | figured I'd ask here first | 16:06.49 |
| chrisl | I only say that given Miles's taking a special interest in it | 16:07.25 |
| kens | Hmmm, tghisOh good grief. I've just spent 30 minutes chasing a seg fault, to discover its because I mes-spelled OutputFile | 16:07.35 |
| chrisl | We should fix that..... | 16:07.56 |
| henrys | sorry rayjj I'd jumped into the skype meeting | 16:12.41 |
| | rayjj: I'd follow up | 16:12.56 |
| kens | chrisl yes, I htink we should. It happens with: | 16:13.20 |
| | -sOutputFile=\temp\out.pam -dMaxBitmap=400000000 -sDEVICE=pam -r72 -Z: -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K1000000 -dClusterJob -dJOBSERVER /tests/268-03.ps | 16:13.20 |
| | Only I had -sOutputFile mis-spelled, so the filename was NULL and WIndows threw a massive fit about it | 16:13.46 |
| chrisl | Yeh, I think the issue is only with Windows | 16:14.04 |
| kens | I'll try and remember to look into it when I finish working out the bug I actually intended to investigate | 16:14.24 |
| chrisl | kens: do we also crash if we can't open a temp file? | 16:15.46 |
| kens | It is actually trying to open a temp file at the time | 16:16.00 |
| | _open_osfhandle crashes when fd == 0 | 16:16.20 |
| | Sorry, not quite | 16:16.31 |
| | I mean _open_osfhandle returns an fd of 0, and fdopen then crashes | 16:16.50 |
| chrisl | Hmm, odd - I didn't think OutputFile would influence the temp file | 16:17.03 |
| kens | My network is very unhappy today :-( | 16:17.57 |
| | chrisl I think its only opening it as a temp file *because* OutputFIle is not present, therefore the device 'fname' is empty | 16:29.18 |
| | I'm less clear on why that should fail though | 16:29.32 |
| chrisl | Well, even so, we shouldn't crash..... | 16:30.31 |
| kens | Yes, I agree completely | 16:30.47 |
| | I think I've just figured out my other problem (allocating device memory from the wrong pool, should be from stable_memory) | 16:31.12 |
| henrys | kens: hey I meant to ask about the dreaded First/Last Page... but I guess if they were good news you would have brought it up ;-) | 17:01.59 |
| kens | I'll tell everyone when I'm done :-( | 17:02.47 |
| | I think I have the seg faults down to just from the PCL interpreter now | 17:03.01 |
| | Well, seg faults and double frees | 17:03.19 |
| rayjj | henrys: paulgardiner: The problem with the BGPrint=true crash is pretty easy. In gdev_prn_tear_down I was cleaning up the fname values (and setting them to NULL) *before* closing the file, but a "wrapped" file needs the fname to find the real file to close | 17:03.31 |
| kens | And a bunch of diffs in the pdfwrite/ps2write output | 17:03.45 |
| | OK so I'll look into the PCL crashes tomorrow, there are only a few, hopefully all the same cause | 17:04.23 |
| paulgardiner | rayjj: ah yes. That makes sense | 17:04.34 |
| kens | Goodnight all | 17:04.35 |
| paulgardiner | Not related to that, there is one more little tweak I must make to the "wrapped" file methods. | 17:05.57 |
| rayjj | paulgardiner: yes ? | 17:06.10 |
| | paulgardiner: you saw my comment that I have cache working to restore performance, I assume | 17:06.45 |
| paulgardiner | rayjj: oh no I missed that. Brilliant | 17:07.07 |
| rayjj | paulgardiner: I didn't really need *brilliant* to get most of the way there -- a single cache block gets most of the way. | 17:07.47 |
| | paulgardiner: but I wanted something that would work with compressed memfiles as well (so I can share the cache logic) and that is more demanding | 17:08.19 |
| paulgardiner | Yeah I think that's what I'd imagined doing come to think of it | 17:08.20 |
| rayjj | paulgardiner: I need to do some experiments on the corpus, but what I have is several blocks and discard the LRU, but I want to see if I need to delay adding to the cache until the block has been read a second time | 17:10.26 |
| | paulgardiner: or if that helps measurably. | 17:10.41 |
| | paulgardiner: the thinking is that large "objects" in the clist (image data) only get used once, but can "blow out" the cache contents | 17:11.26 |
| | but there are some objects used in "all bands" that we will need for each band | 17:12.16 |
| paulgardiner | I've remembered: clist_fclose isn't quite correct | 17:12.25 |
| | Closing cf only if it isn't == ocf is correct, but it should close ocf if "delete" is set independently of whether ocf == cf | 17:16.59 |
| | Well logically only if ocf is not NULL, but closing NULL is harmless | 17:17.50 |
| nsz | tor8: i have some fp patches: http://port70.net/~nsz/mujs/ | 17:18.24 |
| | the first one is the big dtoa replacement | 17:18.54 |
| | the rand one is what avih reported earlier but you were not here | 17:19.25 |
| paulgardiner | Fixing that would be an improvement but might need other fixes if anyway we are attempting to delete the same file more than once. | 17:19.46 |
| rayjj | paulgardiner: it looks like the current code *is* broken. It calls 'gxclfile::close_file with the 'cf' and dereferences ifile->f even if 'cf' isn't a wrapped file (the fake_path_to_file returned NULL) | 17:24.00 |
| | stephan appears to be having net problems | 17:24.33 |
| | paulgardiner: that's what it does _correctly_ in clist_unlink | 17:25.34 |
| paulgardiner | rayJJ: I think ifile->f is okay because we are always wrapping, but not always using the new behaviour, so sometimes just using the f in the old way | 17:27.21 |
| rayjj | paulgardiner: you are saying that fake_path_file will never return NULL, but it _can_ and clist_unlink handles that (properly, IMHO) | 17:30.14 |
| | stephan: please disconnect manually since you are having net problems | 17:32.43 |
| paulgardiner | fake_path_file will return NULL if we are on a platform that is using the old method | 17:32.45 |
| | But still we wrap the FILE pointers, just using them in the old way | 17:33.10 |
| rayjj | paulgardiner: OK, but I like the "if (ocf)" used in clist_unlink better | 17:36.48 |
| | paulgardiner: or is there a case where ocf != cf but ocf is still the wrapped file ? | 17:37.41 |
| paulgardiner | Yeah, also in close_file, using if(ocf) to determine old and new methods would be better. Then in the new case close cf if it is != ocf and close ocf if "delete" is set | 17:40.46 |
| rayjj | paulgardiner: and in clist_fopen, when opening with *fname != 0 we depend on ocf NULL or not to use the old behavior | 17:40.49 |
| | paulgardiner: under what case will ocf be non-NULL but ocf != cf ??? | 17:42.08 |
| | in the clist_close | 17:42.16 |
| paulgardiner | in clist_fopen we have to ask the platform which method to use with gp_can_share_fdesc() | 17:42.42 |
| rayjj | s/clist_close/clist_fclose/ | 17:42.42 |
| paulgardiner | rayjj: in clist_fclose ocf may be non NULL and != cf if a reader thread is calling it. | 17:43.56 |
| rayjj | but in the old case, the fname won't be the special encoded one, so fake_path_to_file will return NULL, right ? | 17:43.58 |
| paulgardiner | Sorry I have food ready. bbiab | 17:44.48 |
| rayjj | paulgardiner: it doesn't seem to be valid (reader thread or not) for the ocf non-NULL but not matching the cf passed in | 17:45.37 |
| | paulgardiner: that would imply that the cf and the fname are "out of sync", AIUI | 17:46.51 |
| paulgardiner | rayjj: cf is either ocf or the fdup of ocf | 17:53.25 |
| | so cf and ocf are always the same underneath the hood but they may be different FILE pointers | 17:54.01 |
| | By that means we avoid doing explicit reference counting | 17:54.18 |
| | So cf == ocf means cf is the originally opened version, presumably for writing. cf != ocf means cf is a duplicate FILE pointer used for reading | 17:55.22 |
| rayjj | paulgardiner: but won't the IFILE->f be == cf ? | 17:56.13 |
| paulgardiner | Both cf and ocf are IFILEs so have an f inside them | 17:56.38 |
| | The IFILE wrapper is just somewhere to store the read or write position | 17:57.14 |
| rayjj | paulgardiner: yes, but the one we opened for reading using fdup will be one we want to close when ocf != cf, right? (it should match the 'cf') ??? | 17:57.57 |
| paulgardiner | So when I say duplicate the FILE, I really mean allocate a new IFILE and store in it a duplicate of the FILE pointed to by ->f | 17:58.02 |
| | Yeah when cf != ocf, we should close cf because it is the reader's reference to the file. When cf == ocf, we don't want to close ocf (unless delete is set) because that would have the side effect of deleting the file (in the windows case - or losing our reference to it in the unix case) | 18:00.06 |
| | When the new behaviour is in operation, ocf is really treated like the file name, and closing ocf deletes the file | 18:01.36 |
| | cf is the actual file handle | 18:01.52 |
| | treated as | 18:02.03 |
| | It just so happens they have the same type and cf == ocf is a test for whether cf is the original writer's handle ( != means the reader's handle) | 18:03.03 |
| | There's a lot of trickery going on, but I think it works, other than gxcfile:close_file not being quite right | 18:05.29 |
| rayjj | paulgardiner: I guess I'm not liking 'close_file' -- we have to call it to 'unwrap' (free the IFILE) but it also does the fclose, that we don't always want | 18:06.35 |
| paulgardiner | Hang on, do we really mean clist_fclose? | 18:08.27 |
| | We do always want to both free the wrapper and close the contained file | 18:09.14 |
| | Well always both or neither | 18:09.33 |
| | That's because duplicates are used for the readers | 18:09.46 |
| | So when a reader asks to close an IFILE we do want to both free the wrapper and close the FILE (its the reader's own duplicate of the FILE | 18:10.28 |
| rayjj | paulgardiner: if we call clist_fclose, shouldn't we free the wrapper ? (even if we leave that underlying FILE * unclosed so it doesn't go away) | 18:10.38 |
| paulgardiner | No. In the case we don't free it, cf == ocf and ocf will be freed when the file is deleted | 18:12.19 |
| rayjj | paulgardiner: in the previous version where it called fclose directly from clist_fclose, use of the 'cf' would have been invalid | 18:12.30 |
| | (the OS would have freed it's FILE* struct), so how come we want the wrapper left around ? | 18:13.15 |
| paulgardiner | Sorry not following which case we are on now | 18:13.39 |
| rayjj | paulgardiner: every clist_fopen call returns a new wrapper, right. | 18:13.52 |
| paulgardiner | Yes and inside a new FILE, although that FILE may be a dup | 18:14.17 |
| | Sorry bad sentence | 18:14.50 |
| | Yes clist_fopen does return a new wrapper. Each time it does, it also creats a new FILE to wrap. | 18:15.25 |
| rayjj | paulgardiner: so A = clist_fopen(name1, "w") B = clist_fopen(name1, "r") clist_fclose(B, name1, false) -- at this point the wrapper for B should have been freed, even though the file name1 is still allocated | 18:15.52 |
| paulgardiner | The new FILE may be a dup of the original FILE | 18:16.04 |
| | Yes that's right. | 18:17.09 |
| rayjj | so, that's what I am saying -- clist_fclose *always* frees the wrapper | 18:17.48 |
| paulgardiner | clist_fclose will free the B wrapper and close the FILE handle inside it, but that FILE is only a fdup of the original so closing it wont allow the file to delete | 18:17.52 |
| | for a reader call yes | 18:19.06 |
| | If the original writer calls clist_close without delete then neither the wrapper is freed or the FILE inside it closed | 18:19.57 |
| | The whole wrapping thing is just for the sake of storing the read/write position. | 18:21.09 |
| | It's not to do with controlling the life of a FILE pointer differently to the wrapper | 18:21.36 |
| | So IFILE and FILE are always destroyed together | 18:21.53 |
| | That means we need reference counting somewhere else, but we get that just from the fact that we dup the FILEs | 18:22.22 |
| rayjj | paulgardiner: I understand that we can't close the file inside the writer's wrapper (A in my example) and if I understand you, we can't free the writer's wrapper either since that's the only place the FILE * that was wrapped is contained. Is that correct ? | 18:22.27 |
| paulgardiner | Yep that's right | 18:22.45 |
| rayjj | so how does the wrapper for A get freed ? | 18:23.41 |
| paulgardiner | Yes exactly right. The writer's FILE is contained only in the writer's wrapper. The readers have dups in their own wrappers | 18:24.05 |
| rayjj | once the writer calls clist_fclose it can't use that clist_file_ptr any more -- only the fname | 18:25.05 |
| paulgardiner | Yeah and that's part of why the fname is an encoding of clist_file_ptr and why we don't actually (in that case) call close unless delete is set | 18:27.12 |
| rayjj | oh, when it calls clist_unlink with the fname (containing the encoded_ptr, that will be 'A') so then we will actually do the deed (close the FILE*, which deletes it and freeing A) ? | 18:27.38 |
| paulgardiner | Yes exactly or we might do it in clist_close if delete is set | 18:28.13 |
| | The thing I get wrong at the moment is when a reader calls clist_close with delete set. Then ocf != cf, but still we should close ocf (what you called A above) | 18:30.01 |
| | That's the one case I'm aware of that is wrong, although of course there may be others. | 18:31.02 |
| rayjj | paulgardiner: OK, so close_file(ocf) when 'delete is set whether or not ocf == cf, right ? | 18:35.57 |
| paulgardiner | Yeah. That's the thing that wants fixing, but it might cause problems doing so, if ever somthing outside this code tries deleting the same file twice | 18:41.59 |
| | It would be good if we maybe zeroed out the file name when we delete to protect it | 18:42.21 |
| | In the old way of working attempting to delete more than once was unproblematic, but now it would cause a double free | 18:43.07 |
| rayjj | paulgardiner: that's OK if we assume that fname is writable | 18:44.03 |
| | paulgardiner: or worse, since we could dereference garbage when calling fclose | 18:44.51 |
| paulgardiner | Yeah, it may be passed as a const in one of close or unlink at the moment | 18:44.54 |
| | Yes dreference garbage too | 18:45.15 |
| rayjj | paulgardiner: I'm not really worried about being passed as 'const' C run-time doesn't do anything with that -- just the compiler. But clist_fopen("test", ...) could lead to a problem since "test" may not be writable | 18:46.38 |
| | but for clist purposes, that's not really done, so we can safely ignore it. I guess just zapping the fname on delete (just fname[0] is enough) will work | 18:47.50 |
| | I have to run. bbiaw. Thanks for the discussion, paulgardiner. Now go back to your fun with SOT ;-) | 18:49.00 |
| paulgardiner | No no please not SOT!! :-) | 18:50.04 |
| | Forward 1 day (to 2014/11/12)>>> | |
IRC Logs