| | <<<Back 1 day (to 2014/11/05) | 20141106 |
| tor8 | avih: d'oh! | 00:17.16 |
| | avih: github is updated manually | 00:19.34 |
| avih | tor, apparently, when compiling with cygwin, both WIN32 and __unix__ are defined, but then it doesn't find _ftime at jsdate.c . so i modified both ifdefs to check __unix first, and added elif at one of them (one of them tries both unox and win32 without elif). also, js_newerror is declared twice at mujs.h | 05:44.27 |
| | and there are few warnings which could be valid: https://pastebin.mozilla.org/7140220 | 05:50.57 |
| tor8 | http://www.theverge.com/2014/11/6/7163789/microsoft-office-free-for-ipad-iphone-android | 15:22.02 |
| kens | Hmm, that would seem to be bad news for us..... Presumably there will also be a free Android version in time | 15:24.06 |
| nsz | it's good news in the sense that it shows microsoft feels that their end is near.. | 15:27.23 |
| henrys | tor8: crazy stuff going on with them, the infinite storage too whatever that really means. | 15:49.20 |
| tor8 | henrys: I imagine what would happen if you piped /dev/random to a file on their infinite storage, and let it run forever | 15:51.54 |
| henrys | tor8: I think you have to mirror right? put up as much disk space as you use? but not sure. I am a subscriber we can try it ;-) | 15:52.29 |
| tor8 | :D | 15:52.52 |
| henrys | tor8: my idea was to start an ad based backup company. | 15:53.10 |
| tor8 | cat /dev/random > /cloud/secret-encrypted-file.dat | 15:53.19 |
| | henrys: we should have our next meeting in Berlin, Miles could get his tropical fix here: http://www.tropical-islands.de/en/ | 15:54.29 |
| henrys | tor8: right snorkeling looks good ;-) | 15:55.27 |
| Robin_Watts | tor8: ooh, I'm going to Berlin over new year. | 16:02.05 |
| kens | Berlin was good, we enjoyed it. | 16:02.26 |
| Robin_Watts | and Helen needs to learn to snorkel before next years holiday. | 16:02.27 |
| kens | Where to next year ? | 16:02.54 |
| Robin_Watts | Tahiti, Moorea, etc. | 16:03.06 |
| kens | OK snorkeling sounds good in that case | 16:03.42 |
| | If you're planning on doing touristy stuff, I reccomend the Berlin Card | 16:05.02 |
| | Robin_Watts : I suspect Helen would enjoy a visit to Fassbender and Rausch as well | 16:08.18 |
| Robin_Watts | Ah. Very probably! | 16:08.54 |
| kens | I was quite amusing to look at inside | 16:09.07 |
| | Melanie was more interested in the Ritter shop | 16:09.36 |
| avih | tor8: , apparently, when compiling with cygwin, both WIN32 and __unix__ are defined, but then it doesn't find _ftime at jsdate.c . so i modified both ifdefs to check __unix first, and added elif at one of them (one of them tries both unox and win32 without elif). also, js_newerror is declared twice at mujs.h . and there are few warnings which could be valid: https://pastebin.mozilla.org/7140220 | 16:10.22 |
| Robin_Watts | Ritter = Marzipan, right? | 16:10.38 |
| kens | Not really, no its a brand of chocolate | 16:10.52 |
| | Ritter Sport | 16:11.01 |
| Robin_Watts | Ok, but they do do chocolate covered marzipan. | 16:11.10 |
| chrisl | I always preferred Milka..... | 16:11.15 |
| kens | The Ritter place has every kind of chocolate they make, and the opportunity to make your own combination | 16:11.46 |
| | More of a kids thing really | 16:12.05 |
| roboso | hello | 16:19.43 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 16:19.43 |
| henrys | wonders if ghostbot can respond to the name that triggered him to say something.... | 16:21.24 |
| avih | tor8: also, i noticed that pop is considerably slower than push (~10x?). is this due to the data structure used? | 16:27.45 |
| tor8 | avih: you mean array push/pop? | 16:29.07 |
| avih | yes | 16:29.14 |
| | are there other push/pop in js? | 16:29.19 |
| tor8 | plenty of push/pop in the bytecode | 16:29.47 |
| avih | e.g. this prints the array with 1000 numbers practically instantly, but then takes several seconds to display the empty final array: | 16:30.09 |
| | x=[]; for (i=1; i<1000; i++) x.push(i); print(x); for (i=0; i<1000; i++) x.pop(); | 16:30.09 |
| Robin_Watts | henrys: a private message you mean? | 16:31.30 |
| tor8 | I would expect pop to be about 2x slower (it needs to both look up and then delete a property) whereas push only needs to insert one | 16:31.33 |
| avih | tor8: try the line i just posted. it's hard to assess because push happens so quickly. it feels to me like pop is exponential of length | 16:32.23 |
| Robin_Watts | henrys: Or to say "roboso: Welcome to #ghostscript..." ? | 16:32.39 |
| henrys | Robin_Watts: yes that. | 16:32.52 |
| Robin_Watts | That should be doable. | 16:33.01 |
| avih | or, it feels like push is O(1) but pop is O(n) | 16:33.53 |
| tor8 | avih: objects use a self-balancing binary search tree to store properties, so I'd expect both insert and delete operations to have the same O(log n) complexity | 16:34.20 |
| avih | tor8: did you try the line i posted? you see how the pushes finish instantly but the pop loop takes quite a few seconds? | 16:34.57 |
| | (i understand both should be O(log(n)), it just doesn't feel like it) | 16:35.31 |
| tor8 | avih: yes, it's significantly much slower | 16:35.44 |
| avih | and if you add prints per iteration, you'll see that it feels proportional to the current length of the array | 16:36.19 |
| tor8 | could be bugs in the binary search tree deletion... that stuff has not been tested exhaustively | 16:36.34 |
| avih | yeah | 16:36.48 |
| | same goes for splice etc. whenever an object has to be deleted | 16:37.09 |
| | (ii only tested arrays though) | 16:37.45 |
| tor8 | avih: arrays use the same representation as objects | 16:43.52 |
| | just magic handling of the 'length' property | 16:44.01 |
| | I'll have to look into this slowdown | 16:44.08 |
| avih | tor8: yes, i followed the implementation of the array index wrapping around objects when i was looking for the splice bug. also found the s/del/add/ bug but forgot to mention it since i managed to reproduce the crash regardless. | 16:46.13 |
| nsz | another bug in ecma-262: Number.prototype.toString ( [ radix ] ) radix other than 10 is implementation defined but "Letters a-z are used for digits with values 10 through 35" and "the algorithm should be a generalisation of that specified in 9.8.1" | 16:48.05 |
| | 9.8.1 is the tostring spec that uses 'e' for exponent.. which cannot workif radix >14 | 16:48.42 |
| | (i use c99 hexfloat formatting for now which is good for debugging purposes) | 16:51.06 |
| avih | nsz: hmm.. that's weird... so how does it handle hex fractions? | 17:16.59 |
| | or rather, how should it handle hex fractions> | 17:17.11 |
| | ? | 17:17.13 |
| nsz | ppl dont implement it, that's how | 17:17.58 |
| | it's a useless piece of spec | 17:18.17 |
| | (but i like to debug fp issues with hexfloats so i have it there for now) | 17:19.02 |
| avih | nsz: there could be hacked parsing where if all non numerals are caps and there's a single 'e' which isn't, interpret it as exponent rather than digit :) | 17:35.11 |
| | http://en.wikipedia.org/wiki/Hexadecimal#Hexadecimal_exponential_notation | 17:38.17 |
| | that's fcckued up | 17:39.31 |
| henrys | tor8: now you got me looking at the verge, now folks know how to user their surface: http://www.theverge.com/2014/11/5/7160115/microsoft-surface-loses-on-election-night-as-cnn-commentators-use-it | 18:04.24 |
| | Forward 1 day (to 2014/11/07)>>> | |
IRC Logs