| 00:05:29 | * | zahary1 quit (Read error: Operation timed out) |
| 01:45:46 | * | q66 quit (Quit: Quit) |
| 03:34:12 | * | FreeArtMan quit (Ping timeout: 260 seconds) |
| 06:13:53 | * | ccssnet quit (Ping timeout: 245 seconds) |
| 07:22:49 | * | Trix[a]r_za is now known as Trixar_za |
| 07:24:20 | * | gour joined #nimrod |
| 09:05:03 | * | Trixar_za is now known as Trix[a]r_za |
| 09:34:20 | * | Araq_ joined #nimrod |
| 10:26:36 | * | Araq_bnc joined #nimrod |
| 10:29:04 | * | Amrykid quit (Ping timeout: 245 seconds) |
| 10:29:04 | * | dom96 quit (Ping timeout: 245 seconds) |
| 10:29:05 | * | dom96 joined #nimrod |
| 10:29:11 | * | dom96 quit (Changing host) |
| 10:29:11 | * | dom96 joined #nimrod |
| 10:29:45 | * | Araq quit (Ping timeout: 260 seconds) |
| 11:05:30 | * | ccssnet joined #nimrod |
| 12:09:53 | * | zahary joined #nimrod |
| 13:07:33 | * | q66 joined #nimrod |
| 13:40:48 | * | Amrykid joined #nimrod |
| 14:58:49 | * | Amrykid quit (Changing host) |
| 14:58:54 | * | Amrykid joined #nimrod |
| 16:07:39 | dom96 | hello |
| 16:36:54 | * | Trix[a]r_za is now known as Trixar_za |
| 17:31:10 | * | Araq_bnc is now known as Araq |
| 17:35:30 | Araq | ping zahary |
| 17:42:30 | Araq | hi dom96 |
| 17:42:35 | dom96 | hello Araq |
| 17:44:50 | dom96 | So, I am now officially off school |
| 17:46:50 | Araq | lol, what did you do wrong? |
| 17:47:00 | dom96 | what? it's christmas |
| 17:47:50 | Araq | that is your answer for everything, hu? |
| 17:56:55 | dom96 | no, 'what?' is not my answer for everything? |
| 17:57:20 | Araq | I'm referring to "it's christmas" ;-) |
| 17:57:55 | Araq | sorry, tried to be funny ... |
| 18:05:35 | dom96 | sorry, I didn't realise you were joking... |
| 18:11:15 | * | gradha joined #nimrod |
| 18:24:55 | Araq | hi gradha |
| 18:25:10 | gradha | hi Araq |
| 18:25:50 | Araq | so does babel work on macosx? |
| 18:26:15 | gradha | it will when https://github.com/Araq/Nimrod/issues/272 is dealt with |
| 18:26:35 | Araq | well can you have a look at #272 and fix it? |
| 18:26:50 | gradha | it's on my todo list |
| 18:29:50 | Araq | gradha: excellent, thank you |
| 18:34:50 | gradha | there's also an alternative: tell mac people to wait patiently |
| 18:35:00 | Araq | they are used to that anyway :P |
| 18:35:30 | dom96 | it's ok. I have an idea on how to fix it. |
| 18:35:35 | Araq | but I think on linux the problem is the same? |
| 18:35:50 | Trixar_za | If you're going with what their used to, you should probably charge for the port too |
| 18:36:00 | Araq | Trixar_za: nice idea :D |
| 18:36:10 | gradha | Trixar_za: that's old school. Instead nimrod should be free, and each babel module paid for |
| 18:36:30 | Trixar_za | Of course |
| 18:36:35 | Trixar_za | With it's own Apple Shop price |
| 18:37:10 | Araq | babel needs to be intregrated into iTunes for that to work |
| 18:37:30 | Araq | heck, Nimrod should be part of iTunes for that matter |
| 18:37:50 | Araq | but iTunes needs a much better facebook integration ... |
| 18:38:20 | gradha | they already send all your privacy data "to the cloud", that's pretty well integrated |
| 18:38:30 | Araq | so that iTunes can tell facebook that I just downloaded a new Nimrod module with the iTunes Babel plugin |
| 18:39:15 | * | apriori| joined #nimrod |
| 18:39:30 | gradha | dom96: last time I tried using the buffered socket with json parsing it failed with extraneous data, so it's seems it's not just taking long, also getting extra bytes |
| 18:40:00 | dom96 | gradha: It simply shouldn't use buffered sockets. |
| 18:40:10 | dom96 | The code was designed for unbuffered sockets. |
| 18:40:40 | dom96 | now the problem with SSL's recvLine not working with unbuffured sockets might be a bit tricky. |
| 18:41:10 | Araq | I still don't get the sockets API |
| 18:41:35 | gradha | why would be a problem that code designed for unbuffered sockets to use buffered ones? |
| 18:41:40 | Araq | I don't want to do an OS <-> userspace context switch for every single byte |
| 18:42:00 | Araq | but since we don't know how many bytes arrived what else can you do? |
| 18:42:31 | dom96 | I think httpclient does its own buffering |
| 18:42:56 | dom96 | well actually, the way http works is that it may send you the content length. |
| 18:43:11 | dom96 | You then simply recv(contentLength, ...) |
| 18:43:21 | Araq | yeah I know |
| 18:43:31 | dom96 | But with buffering enabled it might request more. |
| 18:43:36 | Araq | but that's backwards and shouldn't be HTTP's business |
| 18:43:41 | dom96 | hrm, maybe this is a bug with buffering |
| 18:43:51 | gradha | does that work too with gzip deflate? the http protocol reports the compressed size |
| 18:44:11 | Araq | apparently buffering on the socket level is very bad idea |
| 18:44:21 | Araq | but then as I said, how is it supposed to work? |
| 18:44:31 | gradha | but at least on iOS the network layer returns you the uncompressed data, so it's bigger |
| 18:45:01 | Araq | I think HTTP does report the compressed size then, yes |
| 18:45:56 | dom96 | it shouldn't matter for httpclient as it doesn't request compressed data. |
| 18:46:16 | Araq | many website only send compressed data |
| 18:46:21 | Araq | *websites |
| 18:46:31 | Araq | no matter if you requested it or not |
| 18:46:41 | gradha | heh, thought the other way round was more frequent |
| 18:46:51 | dom96 | Araq: Example? |
| 18:47:11 | Araq | dom96: uni frankfurt iirc |
| 18:47:36 | Araq | maybe they changed it |
| 18:47:51 | gradha | I scraped some days ago the web minus.com, which is a picture image, whenever they see fit they return gzip content, without you requesting it |
| 18:54:31 | dom96 | A web crawler would be a nice test for httpclient |
| 19:03:41 | dom96 | damn, I can't remember the reason why unbuffered ssl sockets cannot use recvLine. |
| 19:04:31 | Araq | you should have made a comment ;-) |
| 19:04:56 | dom96 | I remember now. |
| 19:05:16 | dom96 | Normal recv allows you to peek. |
| 19:05:31 | dom96 | OpenSSL's does not. |
| 19:07:51 | dom96 | Araq: fields in object variants are always there anyway right? |
| 19:08:11 | Araq | for now, yes |
| 19:08:21 | Araq | that won't stay though :P |
| 19:08:31 | dom96 | hrm, but then again this will make the implementation a bit confusing. |
| 19:08:51 | dom96 | I'll simply add a little 1 char buffer to the SSL implementation :D |
| 19:09:11 | Araq | sounds like a good idea |
| 19:09:31 | Araq | btw never ever look at SSL's implemenation |
| 19:09:51 | Araq | and never think about it's the base of the "secure" internet |
| 19:10:31 | Zor | openssl is the scariest C code base I have ever looked at, hands down |
| 19:10:36 | Araq | "My definition of an expert in any field is a person who knows enough about what's really going on to be scared." |
| 19:10:41 | Araq | P. J. Plauger, |
| 19:23:31 | Araq | so according to SO buffering the socket is the way to go |
| 19:23:41 | Araq | so I dunno why it should block ... |
| 19:24:11 | Araq | maybe we overlooked some non-posix flag? |
| 19:25:51 | Araq | hrm you can call it once with MSG_PEEK to retrieve the number of bytes that can be read |
| 19:27:41 | dom96 | link? |
| 19:27:51 | Araq | http://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx |
| 19:31:21 | Araq | "The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested. " says http://linux.die.net/man/2/recv |
| 19:32:17 | dom96 | well then there is no reason for it to block. |
| 19:32:32 | Araq | yeah |
| 19:32:52 | dom96 | I shall investigate once I implement recvLine for unbuffered ssl sockets. |
| 19:32:57 | Araq | so is it a macosx problem or a problem in general? |
| 19:33:02 | dom96 | as that feature is useful anyway |
| 19:35:17 | dom96 | wait. OpenSSL does have a peek function? how did I miss this. |
| 19:38:52 | gradha | how is it named? |
| 19:40:57 | dom96 | SSL_peek |
| 19:41:12 | dom96 | It seems as if it has been removed. |
| 19:41:17 | dom96 | I can't find it in the official docs. |
| 19:41:22 | Araq | it was a security risk |
| 19:41:37 | Araq | people could use it to know about how many bytes to read |
| 19:42:02 | Araq | so they could in fact, read *data* |
| 19:42:12 | Araq | big security risk |
| 19:42:22 | dom96 | Are you joking again? |
| 19:42:57 | gradha | it's not really reading, just knowing how much you will read |
| 19:43:17 | dom96 | it is reading. |
| 19:43:52 | dom96 | The only difference between SSL_read and SSL_peek is that SSL_peek does not remove the data that is returns. |
| 19:43:57 | dom96 | *it |
| 19:44:32 | Araq | dom96: yes :D |
| 19:45:32 | gradha | that's nice documentation, not a single reference to SSL_peek from SSL_read |
| 19:45:37 | Zor | openssl documentation is fucking terrible |
| 19:46:02 | Zor | from the BN_rand man page: |
| 19:46:12 | Zor | If top is 0, it is set to 1, and if top is 1, the two most significant bits of the number will be set to 1, so that the product of two such random numbers will always have 2*bits length. |
| 19:46:22 | Araq | XD |
| 19:46:32 | Zor | but what do the two most significant bits in openssl's magical bignum format mean? nobody knows! |
| 19:47:37 | Zor | (here's a fun fact, neither of them means signed) |
| 19:47:52 | gradha | sounds like in older versions top == 0 meant something different |
| 19:48:17 | gradha | can't understand anything else, I'm afraid |
| 19:48:52 | dom96 | well no one is answering me in #openssl |
| 19:48:57 | Zor | that's okay, neither can I, after googling around and asking several reverse engineer friends for days |
| 19:49:12 | Zor | all I could gather is that signedness is not part of those two bits |
| 19:49:22 | gradha | you reverse engineer your friends for days? |
| 19:49:37 | gradha | oh, wait, it's another day where I read everything wrong, sorry |
| 19:49:52 | Araq | you know, that's why I consider computing surreal: open, read/write, close; how hard can it be to design such an API? |
| 19:50:17 | Araq | turns out the international posix standard couldn't do even that |
| 19:50:52 | Zor | oh, I didn't paste the full explanation of top |
| 19:50:57 | Zor | If top is -1, the most significant bit of the random number can be zero. If top is 0, it is set to 1, and if top is 1, the two most significant bits of the number will be set to 1, so that the product of two such random numbers will always have 2*bits length. |
| 19:51:02 | Zor | there it is |
| 19:51:07 | Zor | (more magic values, wheeee) |
| 20:09:12 | gradha | so github disallows downloads now, but they still allow/host web pages through the gh-page branch where you can put any binary |
| 20:09:23 | gradha | does somebody understand? |
| 20:09:53 | Araq | you just found a hole in their system |
| 20:10:23 | gour | when i asked tcl/tk folks about migrating from SF to fossil, they replied "we do not want to have anything critical at SF"...it looks that GH is going similar router |
| 20:38:23 | * | gradha quit (Quit: gradha) |
| 20:46:13 | * | FreeArtMan joined #nimrod |
| 22:01:14 | * | gour quit (Disconnected by services) |
| 22:01:19 | * | gour_ joined #nimrod |
| 22:01:34 | * | gour_ is now known as gour |
| 22:07:59 | * | gour is now known as Anaphaxeton |
| 22:10:14 | * | Anaphaxeton is now known as gour |
| 22:29:54 | * | Trixar_za is now known as Trix[a]r_za |
| 22:45:04 | * | apriori| quit (Quit: Konversation terminated!) |
| 23:03:19 | * | Araq__ joined #nimrod |
| 23:03:39 | * | Araq_ quit (Ping timeout: 255 seconds) |
| 23:10:54 | * | zahary quit (Read error: Operation timed out) |
| 23:19:45 | * | gour quit (Quit: WeeChat 0.3.8) |
| 23:26:20 | * | Araq__ quit (Read error: Connection timed out) |
| 23:28:45 | * | Araq_ joined #nimrod |