#qi-hardware IRC log for Wednesday, 2013-03-27

hellekinWhat's up for http://www.hfday.org/map/ It's in 3 weeks...17:13
lekernelthe usual raspberry pi and makerbot nonsense?17:34
lekernelthere's even an event titled "OzBerryPi.org", lol17:35
hellekinlekernel: there was a heated discussion on FLISOL mailing-list these days (Latin-American Festival of Installation of Free Software) because people ususally install Ubuntu, and the FSF considers Ubuntu to have derived away from the ideals of free software17:39
hellekinand it's using spyware. The first reaction of the coordinators of the list was to deny, and reject that issue, and tell the people from the FSF to stop trying to divide the community17:40
hellekinafter someheated dicussion, they came to acknowledge the issue and proposed to inform all users about this issue, because it's a fundamental issue for software freedom.17:41
hellekinI think the same goes for an event called "hardware freedom day"17:41
hellekinif real hardware freedom don't get involved, it will become like "natural cow milk" in Argentina: inexistent, because by law, they need to add all sorts of nutriments to struggle against mal-nourishment (?)17:44
wpwrak"american scientists report:traces of evilness found in ubuntu" :)17:44
hellekinhardware freedom promoters I mean17:44
hellekinthe milk issue in Argentina avoids fixing the poverty issue by installing an industrial-chemical monopoly over its distribution. Great.17:45
hellekinIf you don't want people to hear "free hardware" and think "arduino", you should ponder that lekernel 17:46
lindi-I don't think there is a clear concensus on what free hardware means17:46
hellekinin propaganda terms, it's called "spinning the truth"17:47
hellekinlindi-: the CERN's OHL mailing-list is a great place to discuss it.17:47
hellekinlindi-: what's your take?17:47
lindi-hellekin: I'm afraid I don't have the knowledge to say much about it17:47
lekernelarduino isn't that bad, even if it's kinda boring at times. at least, the people behind the project act with some good faith for oshw (and have made some progress in that direction, eg using a free software usb stack instead of a ftdi-chip)17:48
lindi-hellekin: I'd much rather communicate as many facts about some piece of hardware as possible and leave it to the user to decide if those are ok at this stage17:48
lekerneland it has brought a lot of non-engineers into electronics17:48
hellekinlindi-: so you already have an opinion :)17:49
lekernelrpi? there isn't the faintest link to oshw. absolutely everything is proprietary, even some software. it resonates in the oshw community only because hackers are cheap bastards.17:49
wpwrakdeath to ftdi ! now there's a cause i can fully sympathize with17:49
hellekinlekernel: I'm glad you got more flexible about arduino. I remember it wasn't always the case :)17:50
hellekinwpwrak: "D17:50
lindi-when I started you couldn't search the arduino schematics without non-free eagle program17:51
wpwraklekernel: you're still on altium, aren't you ? :)17:51
lekernelwell it's not like there's much to see there anyway, any serious EE can design an arduino in a couple hours17:52
lekernelwpwrak, yes, I even have a dedicated windows xp machine for that purpose. my priority is shipping stuff out, not wasting my time with relatively dysfunctional software.17:53
wpwrakfor beginners, even trivial details can be an issue. so it's nice if they can find something familiar17:53
whitequarkwpwrak: it is one of things you really need just to take with a face value.17:54
wpwrak(arduino design) besides, sometimes it really helps with low-level programming if you know what exactly they did in the circuit17:54
whitequarkto quote their homepage: Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.17:54
whitequarkit is an *ideal* solution for all those groups of people17:54
whitequarksure, it has nothing to do with embedded development. no one claimed it has!17:55
hellekinsorry I didn't want to spark an arduino discussion :]17:55
wpwraklekernel: naw, kicad ain't dysfunctional. the workflow is pretty smooth these days, at least for simpler boards. haven't done multilayer so far.17:56
wpwrakwhitequark: yeah, i think it's a friendly first step for people who otherwise wouldn't think they can do something with such electronics17:57
lekernelthat's not what I heard at CERN, where they have tried to make such multilayer boards...17:57
whitequarkinterestingly, it's exactly the same about Go. some people (a lot, actually) talk about it as a C killer. meh. Pike and Thompson design it, to quote their own words, "we did it because we wanted to solve the type of tasks we commonly have at Google easier"17:57
whitequarkthat explains *everything* about Go. it is also perfectly engineered for that goal.17:58
whitequarkfrom quirks of compiler and stdlib to almost nonexistent error handling in the language.17:58
whitequarkwpwrak: what's up with ftdi?17:58
lekernelwpwrak, and I already told you I have not used kicad for the video mixer board, because I want to re-use the (validated) footprints when integrating the parts on a M1r4 derivative17:59
lekerneltime spent re-doing the footprints in altium + risk of a respin of a 6-layer PCB due to a messed-up footprint = kicad was not the right option18:01
wpwraklekernel: ah, i see. yes, for kicad you'd have to move the whole design.18:01
wpwraklekernel: we should have most of the footprints. many of them unverified, though. but no risk no fun ;-)18:02
wpwrakwhitequark: ftdi has extremely incomplete documentation18:02
FallenouI heard about a Milkymist SoC related work on USB device FPGA core, is it dead?18:45
Fallenouis it using navre with a custom "device" firmware?18:47
lekernelyes, and iirc some minor mods to the usb core too18:50
lekernelthe 'phy' part18:50
lekernelwe're also running navre at 72MHz to make it able to answer the host in a timely fashion, too18:51
Fallenouyes I saw that for the host part 18:51
FallenouI mean, the frequency was changed to 75 MHz for the host design as well, wasn't it ?18:52
Fallenouwho's working/was working on the device part?18:52
lekernelMichael Walle18:55
lekernelyes, it didn't cause issues for the host part (actually it seemed to help with a couple of , so we just use 7218:56
lekernelyes, it didn't cause issues for the host part (actually it seemed to help with a couple of issues), so we just use 72MHz everywhere18:56
Fallenouok :)18:59
whitequark72mhz, huh19:06
whitequark12mhz * 6?19:06
kyaki just came up with "extern const volatile unsigned short int test;", which compiles fine :) no point, i just find it funny :)19:23
whitequark>const volatile19:32
whitequarkwell, extern const volatile might make any sense... I dunno19:35
larsca readonly object which might change it's value without you modifing it19:36
kyaki think "const" implies that the value is not being changed by anyone19:40
kyakotherwise it should be "ro" or somthing19:40
larscno, it implies that you are not going to change the value19:41
whitequarksee also const casting19:41
whitequarkie printf won't modify your format string so it's const in printf19:41
whitequarkbut it's not necessarily const when you pass it to printf19:42
larscconst int *i; int j; i = &j; j = 10; printf("%d\n", i); -> "10"19:42
whitequark(please, for the love of everything good on this planet, do not, ever, write code which uses dynamic format strings.)19:42
lekernelwhitequark, yes, 12*6Mhz19:43
kyaklarsc: this is not defined in the standard, as far as i concern19:44
larscspeaking of format strings, I think next time I'll just sell my zero days on the blackmarket. nobody at security@kernel.org cared19:44
larsckyak: what is not defined?19:44
kyakso whenever you modify the const, the result is undefined19:44
lekernelso no asynchronous clock domain transfers19:45
whitequarkkyak: volatiles is, generally, not well defined in the standard19:45
whitequarkit's basically a message to compiler to "not touch the variable". it does not translate to any particular memory ordering, which is actually a problem.19:46
kyak"The result is implementation-defined if an attempt is made to change a const.", from K&R19:46
whitequarkand every compiler has a different meaning of "not touch"19:46
whitequarkkyak: "implementation-defined".19:46
whitequarkthe actual reason for that wording is that on some systems constant values will go to .rodata and generally to read-only memory19:47
whitequarkso oif you'll try to change it, the system will freak out.19:47
whitequarkor, more precisely, *may* freak out.19:47
kyakwhitequark: there is a good example: http://stackoverflow.com/questions/583076/c-c-changing-the-value-of-a-const. You use gcc and g++ to compile the same code, and get different results19:47
kyak(the first answer)19:48
kyakso you may as well read "undefined".19:48
larsckyak: sane code won't do that19:48
larsccasting the const away19:48
kyakthat's for sure. Because it is not defined by standard19:49
whitequarkbut you still can cast it *to* const, and change the underlying value19:49
whitequarkI guess the compiler won't be able to change two non-consecutive loads into one if it can't prove that this variable doesn't alias anything19:50
whitequarkor maybe not, I didn't check the standard19:50
larsce.g. if a function agrgument is const this tells the caller that the value it passes in won't be changed from within the function19:53
larscbut not the other way around19:53
larscthe function still has to assume that the value way change19:53
larscit's the same as if you add a comment to the function "This function won't change the value of argument X"19:55
kyakwell, this makes the whole point of "const" kida. useless?19:55
kyakit should be enforced, otherwise it's not better than a comment as you said19:55
larscas I said any sane code won't cast the const away19:56
larscbecause as you said the result is undefined19:56
larsce.g. if you have a const declaration the value will be put in a .ro section19:57
larscand on architectures which support it the .ro section is not writable19:57
kyakok, this makes sense19:58
kyakin order for "const" to really work properly, the machine must support the read-only memory19:58
larsce.g. http://pastebin.com/cyGvrzAw causes a segfault on my amd64 machine19:59
kyakstill this won't quite work for function arguments20:00
larscbecause "a" is in the .ro section20:00
kyakeven for architectures that have .ro20:00
kyaki understand it's double negative? :)20:01
larscif you have const pointer parameter this is kind of a contract between the caller and the callee that the callee wont write to the location of the pointer20:01
larscits part of the language so tools like the compiler can complain if this contract is broken20:01
kyaklarsc: does the second example work on amd64?20:02
larscwhich second example?20:02
kyakthe constTest.c20:02
larscyes, because a is on the stack20:02
kyakyep, it segfaults when it's not on the stack20:04
larscif you do a objdump you'll see that it is in the .ro.data section20:05
kyakyea, it is.20:05
kyakanyway, what was funny for me is the number of qualifiers i could use.. The "const volatile" just popped in the way20:06
kyakgotta go now20:06
larscthere is even more20:06
larscrestrict const volatile unsigned long long * const test;20:07
whitequarkunsigned long long int?..20:07
larscmaybe even that20:08
whitequarkwhoever thought that integers must be called by names, as opposed to bit widths, must be shot20:08
whitequarki8, i16, i32, and maybe `word`20:08
whitequarkoh and unsigned variants. that's all you need.20:08
whitequarkalso, love.20:08
kyakprobably he who thought that integer size is machine-specific is already dead20:10
larscthe length of long and short and int and char are up to the architecture20:10
larscI think the only restriction is char <= short <= int <= long20:10
kyakit's just short <= int <= long :)20:11
kyak"The intent is that short and long should provide different lengths of integers where practical; int will20:12
kyaknormally be the natural size for a particular machine. short is often 16 bits long, and int either 16 or20:12
kyak32 bits. Each compiler is free to choose appropriate sizes for its own hardware, subject only to the the20:12
kyakrestriction that shorts and ints are at least 16 bits, longs are at least 32 bits, and short is no longer20:12
kyakthan int, which is no longer than long."20:12
whitequarkand now we have to deal with code which cannot deal with 32-bit chars20:13
whitequarkand the whole ILP64 insanity20:13
larscwhitequark: you think 32-bit chars are bad, try 11-bit wide chars ;)20:13
whitequarkthank you, Dennis :/20:14
whitequarklarsc: hm20:14
whitequarkwhere was that20:14
larscnowhere I guess, but I think it would be legal for a C compiler to implement it that way20:14
larscby the standard20:14
whitequarkyeah, I don't think the standard requiers byte size to be 8 bit20:15
whitequarkor size of any type to be a multiple of 8 bit20:15
whitequarkI even think that most of LLVM does not depend on byte size being 8 bit...20:15
whitequark(tbaa parts do, and some intrinsics also)20:15
whitequarkthis discussion appears on the ML and irc channel with surprising regularity.20:16
whitequarkalso, trigraphs20:18
larscare there people who want support for 11 bit bytes in llvm?20:18
lindi-larsc: what does that mean?20:20
lindi-larsc: do you mean clang here?20:20
lindi-larsc: since llvm already does have "i11" type20:21
whitequarklindi-: no, that's not what I'm talking about20:21
larscI was referring to "21:16 < whitequark> this discussion appears on the ML and irc channel with surprising regularity."20:21
whitequarksee, llvm in some places assumes that the unit of addressing is 8-bit-wide20:21
lindi-but by "the standard" you mean C standard?20:21
whitequarknot in much places, but it does, particularly in stuff which works with pointers and aggregates20:22
whitequarklindi-: yeah20:22
lindi-so clang20:22
whitequarkhahahaha, http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest is the third "Related" link on wikipedia page on C20:22
whitequarkthis is totally awesome20:22
larsclindi-: think the point is that it would be a valid restriction for clang, but it also is in llvm20:23
whitequark"Winning entries are awarded with a category, such as "Worst Abuse of the C preprocessor" or "Most Erratic Behavior", and then announced on the official IOCCC website. "20:23
whitequarkI think I can award these to real-world software20:23
lekernelyou can have a look at the boost headers if you need inspiration for the former20:24
lekerneleg their "preprocessor for loop" is one of my favorites20:25
whitequark... I don't want to know.20:28
wpwrakhmm, the weekly xchat crash ...22:56
--- Thu Mar 28 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!