| 14:44 | <werle> | hey can anyone answer a question for me for the utf8 encoding spec? |
| 14:46 | <annevk-cloud> | werle: if you ask the question, maybe ;) |
| 14:46 | <werle> | It may just be too early for my brain |
| 14:47 | <werle> | but I'm having trouble with this step : 7. Let bytes be a list of bytes whose first byte is code point / 64count + offset. |
| 14:47 | <werle> | my implementation is in C |
| 14:48 | <werle> | and my problem is understanding the formula from the verbiage |
| 14:49 | <werle> | bytes[c++] = (code_point / pow(64.0, (float) count)) + offset; |
| 14:49 | <werle> | is that correct? |
| 14:49 | <werle> | annevk-cloud: thanks again |
| 14:49 | <annevk-cloud> | looks okay, not sure it's the most efficient to do it that way |
| 14:50 | <annevk-cloud> | In C you can do some bit shifting iirc, I recommend studying some implementations |
| 14:51 | <annevk-cloud> | The spec just describes a black box you need to be equivalent too, not identical |
| 14:55 | <werle> | ah great thanks ! |
| 15:34 | <zewt> | you definitely shouldn't have floating-point in utf-8-handling code :) |
| 15:34 | <zewt> | meanwhile, boggling at python multiprocessing breaking atexit |
| 16:11 | <werle> | zewt: yes very true :) |
| 16:44 | <zewt> | boggling at python twice in one day (where the hell is sigsetmask or sigprocmask) |
| 16:47 | <zewt> | "new in version 3.3" oh come on |
| 17:05 | <odinho> | Then use 3.3, it's very nice :) |
| 18:23 | <jgraham> | odinho: Not helpful :p |
| 18:29 | gsnedders | still votes for dropping Py2 support in html5lib, even though it's practically impossible to do :P |
| 18:29 | <jgraham> | gsnedders: No you don't |
| 18:32 | <gsnedders> | But it'd make all the changes I want to make to the input stream so much easier! |
| 18:37 | <odinho> | Now with Django finally supporting Python 3, I'll start porting quite a lot of code :) |
| 18:38 | <gsnedders> | Most of the stuff I support already runs on both, so it's now just a question of when I drop Py2. |
| 18:39 | <odinho> | Yeah. True dat. I fixed the few issues with the repatch scripts I have, in order to be able to run the tests on python 3.3. It has a nicer unittest module, with mocking. |
| 20:08 | <jgraham> | odinho: Django eh? I'm sorry :p |
| 20:09 | <jgraham> | </troll> |
| 20:09 | <gsnedders> | Django is good, if you want all the magic it does. |
| 20:10 | <jgraham> | Even the ORM? |
| 20:10 | <gsnedders> | The ORM is okay, provided you don't want more than it does. |
| 20:11 | <gsnedders> | Also, sudo get me a drink. |
| 20:11 | <zewt> | been a couple years since i used it, but the main design failure i found in it was that it tried to give an API that pretends you're not on top of SQL at all |
| 20:12 | <zewt> | so the instant you had to do something they didn't think of, you had to drop all the way to building queries yourself |
| 20:13 | <jgraham> | Right, my limited experience of these things is that the level of control offered by SQLAlchemy is the minimum you need for applications that use SQL in a serious way |
| 20:13 | <jgraham> | So the idea of using something that's known to be much more limited isn't that appealing |
| 20:14 | <zewt> | also having an API that allows running on SQL and non-SQL data stores without the application knowing about it is ... useless |
| 20:44 | <odinho> | The ORM is awesome. |
| 20:44 | <odinho> | So much better than SQLAlchemy(puke) |
| 20:47 | <odinho> | Lots of bugs. Took me ages to debug and find many of them. |
| 20:47 | <odinho> | I'm porting all systems in Desktop previously built on flask and sqlalchemy to Django. |
| 20:48 | <odinho> | I don't care about fighting with sqlalchemy anymore :) |
| 21:35 | <jgraham> | odinho: I don't htink we can be friends |
| 21:35 | <jgraham> | Sorry |
| 21:35 | <jgraham> | ;) |