wpwrak | let's see what happens if i set kseg0 to write-through ... | 08:13 |
---|---|---|
wpwrak | kernel gets a little slower. good so far. now let's try IO ... | 08:15 |
wpwrak | hmm, 10% out of 50% possible speedup. kinda disappointing :-( | 08:17 |
wpwrak | crazy measures should have a more satisfying return | 08:18 |
hellekin | Vote for wpwrak :) | 09:58 |
whitequark | grrrr | 09:59 |
whitequark | canada post can't seem to distinguish russia and uk | 09:59 |
larsc | I can understand when they mix up austria and australia, but how do you get the uk and russia confused? | 10:38 |
whitequark | http://www.canadapost.ca/cpotools/apps/track/personal/findByTrackNumber?execution=e1s1 304599176765 | 10:39 |
whitequark | I have *no idea* | 10:39 |
viric | whitequark: uk for ukraine, or for united kingdom? | 10:58 |
whitequark | viric: united kingdom | 10:59 |
viric | UK = United Kingdom = Royaume-Uni = RU = Russia | 10:59 |
viric | could be that? | 11:00 |
larsc | ... | 11:00 |
viric | It's very usual to shorten Royaume-Uni to RU, (same in Catalan; Regne Unit = RU) | 11:01 |
viric | and then you have UK for Ukraine too | 11:02 |
viric | not that difficult to mix up :) | 11:02 |
whitequark | ... indeed. | 11:03 |
larsc | did you write RU in your address field? | 11:03 |
whitequark | larsc: it was "Russia". | 11:04 |
viric | Russia is harder to mix up | 11:04 |
whitequark | not impossible evidently :/ | 11:04 |
Action: whitequark has run sloccount on gcc sources | 11:05 | |
larsc | but at least they can't say its your fault | 11:05 |
whitequark | 2848901 gcc ansic=1727123,ada=738502,cpp=247495,f90=85207,exp=16009, objc=14691,fortran=9895,ml=3007,sh=2446,awk=1880,pascal=1005,perl=913,asm=416,lex=200,haskell=112 | 11:05 |
whitequark | larsc: indeed. | 11:06 |
whitequark | omg, the C lexer is... really really simple | 11:08 |
viric | that put C in a quite safe position, among programming languages | 11:09 |
whitequark | also, I wonder if anyone could explain the rationale of this: | 11:09 |
whitequark | /* Print GENERIC declaration (functions, variables, types) trees coming from the C and C++ front-ends as well as macros in Ada syntax. | 11:09 |
whitequark | in the gcc-4.8.0/gcc/c-family/c-ada-spec.c. | 11:10 |
whitequark | ... utf-32 string literals? | 11:11 |
whitequark | ok let's not stare into the abyss any longer. | 11:11 |
larsc | better quite before it stares back into you? | 11:15 |
whitequark | larsc: yes. | 11:16 |
Action: whitequark shudders at the very thought of 7.3MLOC of GCC staring at him. | 11:16 | |
larsc | :) | 11:17 |
whitequark | there is something Lovecraftian about that. an ancient beast waking up from its eternal dream, only to cast a single stare and drive an innocent programmer on the verge of insanity | 11:17 |
wpwrak | see, better hurry and lose your innocence. then you're safe :) | 12:11 |
whitequark | I wonder what would constitute losing innocence in the context of GCC... | 12:16 |
whitequark | (also https://pp.vk.me/c410422/v410422132/82c0/Yt400Y9QKN4.jpg) | 12:16 |
wpwrak | marvelous ! | 12:18 |
whitequark | omg. | 14:16 |
whitequark | a polite postal worker (!) who, having seen an attached paper which stated a weight difference (0.9kg vs 0.6kg) asked me to check the contents and said she'll help with paperwork if something's actually was missing | 14:18 |
whitequark | (!!) | 14:18 |
pcercuei | there are some nice people out there :) | 14:19 |
wpwrak | s/polite/fake/ ? :) | 14:19 |
whitequark | wpwrak: haha | 14:19 |
whitequark | also they did not lost the parcel despite me writing the wrong zipcode | 14:20 |
larsc | whitequark: you'll be on one of these hidden camera shows | 14:20 |
whitequark | and, in a previous encounter with EMS (a subsidiary of the russian post), when I've had two parcels to receive and forgot to write the flat # on one of them, a courier who delivered the second one has remembered it and offered to redeliver | 14:21 |
whitequark | I wonder if they're they still a government-sponsored organization? | 14:22 |
wpwrak | larsc: he should go easy on these mind-altering drugs, particularly the strong ones | 14:22 |
whitequark | huh, 2/3 of connections are suddenly ECONNREFUSED. not sure if just crappy connection or malfunctioning censorship engine | 15:22 |
whitequark | regardless, openvpn solves this :) | 15:22 |
viric | meh | 16:32 |
viric | UBI error: ubi_read_volume_table: the layout volume was not found | 16:32 |
viric | oh the new qemu added a NAND to the default mips board | 16:39 |
viric | Creating 3 MTD partitions on "physmap-flash.0": | 16:40 |
viric | 0x000000000000-0x000000100000 : "YAMON" | 16:40 |
viric | 0x000000100000-0x0000003e0000 : "User FS" | 16:40 |
viric | 0x0000003e0000-0x000000400000 : "Board Config" | 16:40 |
kyak | wpwrak: spi-gpio-atben and spi_atben_gpio - i'm already lost :) | 17:24 |
kyak | btw is there a naming convention for kernel modules at all? | 17:25 |
larsc | for some | 17:31 |
larsc | e.g. some subsystems use a common prefix | 17:32 |
larsc | like i2c-foobar | 17:32 |
wpwrak | kyak: yeah, it's a little messy :) also, spi_atben is somewhat correct because it implements a SPI driver, but then spi_atben_gpio only puts things together | 17:37 |
wpwrak | kyak: but i think spi_atben can die now. it was the very first one i wrote. | 17:38 |
wpwrak | and spi_atben_gpio needs a less confusing name | 17:38 |
wpwrak | spi-* are all real SPI drivers | 17:38 |
kyak | is there a chance atben and atusb drivers will be accepted by upstream? | 17:41 |
kyak | is it even something you want to do, or we don't really care? | 17:42 |
wpwrak | oh, i want them upstream. i don't expect undue difficulties. just need a bit more testing. | 17:45 |
wpwrak | and atben has a bunch of at86rf230.c fixes it semi-depends on as well (as in "i already know it'll crash and burn before long if they're not there"). they sould probably go in first. | 17:46 |
kyak | cool :) | 17:47 |
wpwrak | of course, atben has the added issue that some things are missing in mainline for proper ben support. i do my development on a board without lcd, so i just applied the two patches i need to get at least that far. but that kernel probably has no lcd. and it also doesn't have USB. | 17:52 |
wpwrak | (i flash directly via usb-boot, which is very easy if you have idbg) | 17:53 |
wpwrak | (and can of course be the mother of all nightmares if you don't :) | 17:53 |
kyak | do you mean that your driver might affect USB? | 17:56 |
wpwrak | no, but the net-next kernel doesn't have the patch for the jz4740's USB device. so anything you build from that source will be a somewhat limited ben. | 17:59 |
wpwrak | not sure where that driver is in the pipeline, if it's on the way into mainline at all | 17:59 |
kyak | ok, now i understood :) | 18:00 |
kyak | though i thought that most of the patches went upstream | 18:01 |
kyak | except for partitions maybe | 18:01 |
wpwrak | maybe it's somewhere in a tree that hasn't been merged yet. we have quite a number of patches in the qi-gw owrt repository that aren't in mainline. e.g., several NAND performance improvements. | 18:26 |
pcercuei | hmm | 18:54 |
pcercuei | how can I stop a blocking read() call from a different thread? | 18:55 |
larsc | kill the thread | 19:55 |
larsc | or send any other signal | 19:55 |
pcercuei | well, I tried that :) | 19:55 |
pcercuei | pthread_kill(thd, SIGTERM) | 19:55 |
pcercuei | doesn't stop the read() call :( | 19:55 |
larsc | it should, at least if the signal is not blocked | 19:55 |
pcercuei | well, SIGTERM should never be blocked, no? | 19:55 |
larsc | SIGKILL is unblockable | 19:55 |
larsc | SIGTERM is just like any other signal | 19:55 |
pcercuei | hmmm | 19:55 |
pcercuei | ok | 19:55 |
larsc | it's also possible that your backend does a non-interruptible sleep | 19:56 |
pcercuei | so I believe I just have to use sigaction()? | 19:56 |
larsc | probably | 19:56 |
larsc | or you just use poll and friends | 19:57 |
pcercuei | polling would be a bit... dirty | 19:58 |
larsc | no, poll() | 19:59 |
larsc | a.k.a select() | 19:59 |
pcercuei | larsc: sigaction() does affect the whole process, not only a thread | 20:06 |
viric | pcercuei: I think you can close the fd | 20:07 |
pcercuei | viric: oh, good idea | 20:08 |
pcercuei | that would probably work | 20:08 |
pcercuei | viric: doesn't work :( | 20:27 |
pcercuei | calling close() on the file descriptor doesn't stop the read() | 20:28 |
larsc | what are you reading on? | 20:29 |
pcercuei | a file descriptor obtained with inotify_init() | 20:30 |
viric | hm ok | 20:30 |
viric | then I'm with lars | 20:30 |
viric | select or signal | 20:30 |
larsc | according to the code inotify_read is interruptible | 20:32 |
pcercuei | that's why I don't understand why I can't interrupt it ;) | 20:39 |
viric | interruptible means that on a signal it will unblock, no? | 20:40 |
viric | maybe you have set SA_RESTART for SIGTERM ? | 20:40 |
pcercuei | well, my code doesn't set it | 20:41 |
viric | ok | 20:41 |
viric | I never understood how threads and signals cope together though | 20:43 |
larsc | wpwrak: be careful if you ever want to buy a poodle | 21:14 |
larsc | http://news.yahoo.com/blogs/sideshow/ferret-poodle-argentina-125901615.html | 21:14 |
wpwrak | bwahaa. of course, he deserves it for buying at La Salada, the XXL market for fences (german "Hehler") and scammers. | 21:23 |
--- Thu Apr 11 2013 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!