2013-01-30 00:28 Hoolxi has joined #qi-hardware
2013-01-30 00:32 Hoolxi has quit [Remote host closed the connection]
2013-01-30 01:11 megha has quit [Ping timeout: 264 seconds]
2013-01-30 01:24 megha has joined #qi-hardware
2013-01-30 01:35 rz2k has quit [Read error: Connection reset by peer]
2013-01-30 01:44 <wpwrak> if you want to outdo C++, you'll probably have to make it at least 4-5 passes. if they're already at two, they'll certainly add another one in C++14 or whenever the next abomination is due
2013-01-30 01:46 <wpwrak> a radically different approach would be just recording the error but proceeding, then handling it when all is done
2013-01-30 01:46 <wpwrak> if that doesn't work, you don't seem to have much hope, though, if your language has destructors
2013-01-30 01:47 <wpwrak> (C's longjmp is kinda nice in terms of efficiency. but of course, it has its own set of issues.)
2013-01-30 01:47 <whitequark> wpwrak: oh, you don't know yet
2013-01-30 01:47 <whitequark> longjmp unwinds the stack too
2013-01-30 01:48 <wpwrak> in C, it just sets the stack :)
2013-01-30 01:48 <whitequark> my language doesn't have RAII, because it doesn't make sense
2013-01-30 01:48 <whitequark> it has closures. wanna free some resource, use a closure and `ensure' (ie finally)
2013-01-30 01:49 <whitequark> (well, technically I have finalizers, but they're more a special case than a common pattern)
2013-01-30 01:49 <whitequark> all this decreases the amount of cruft to do quite a bit.
2013-01-30 01:49 <whitequark> mutexes, similarly: @mutex.synchronize { do_your_work_here }
2013-01-30 01:49 <wpwrak> your problem is that you have implicit dynamic allocation. that's where all the messiness comes from.
2013-01-30 01:50 <whitequark> wpwrak: to begin with, I also have a concurrent, lock-free heap
2013-01-30 01:50 <whitequark> which means that I never do cli;alloc;sti.
2013-01-30 01:50 <wpwrak> in embedded, you rarely need such things. you may still keep them at a semantic level, but you may want to try to come up with usage rules that allow the compiler to always de-dynamize them.
2013-01-30 01:51 <whitequark> you are right here indeed; most of the dynamic allocations will be resolved to stack ones at compile-time.
2013-01-30 01:51 <whitequark> so this is exactly what I do
2013-01-30 01:51 <wpwrak> now just change "most" to "all" :)
2013-01-30 01:52 <whitequark> oh I'd be happy to. currently I see two places where it's hard.
2013-01-30 01:52 <whitequark> first, strings, and to a lesser extent arrays
2013-01-30 01:53 <whitequark> well, hm
2013-01-30 01:53 <whitequark> actually no, I can predict at compile-time what the maximal length for, e.g. a %d substitution will be
2013-01-30 01:54 <wpwrak> maybe have something along the lines of global variables that are only conditionally visible. then "enable" them dynamically.
2013-01-30 01:54 emeb has quit [Quit: Leaving.]
2013-01-30 01:54 <whitequark> this is kind of how I'll do the exceptions
2013-01-30 01:54 <wpwrak> if the call chains of paths that enable them could cross, it's an error
2013-01-30 01:54 <whitequark> because allocating exceptions on stack is not an option
2013-01-30 01:55 <whitequark> wpwrak: (call chains) this is theoretically possible, but a) requires an exponentially bounded analysis b) is way too hard to debug when it goes wrong
2013-01-30 01:55 <whitequark> I avoid such stuff :)
2013-01-30 01:55 <wpwrak> in C, you do of course have a means to do such things (through unions), but the compiler won't check it for you
2013-01-30 01:56 <whitequark> I do have union types, through for reasons unrelated
2013-01-30 01:56 <wpwrak> and the next step, making it possible to let such pseudo-dynamic allocations live on for a while would even be more difficult
2013-01-30 01:56 <whitequark> I'd say it is Turing-undecidable in the general case
2013-01-30 01:57 <wpwrak> of course
2013-01-30 01:57 <wpwrak> but the compiler could still detect clearly correct, clearly incorrect, and dubious cases
2013-01-30 01:58 <wpwrak> maybe it's best to think in terms of usage scenarios
2013-01-30 01:58 <whitequark> wpwrak: the problem is what should the programmer do when (not if) the compiler does not what she wants.
2013-01-30 01:58 <whitequark> this is something I consider first before adding any feature
2013-01-30 01:58 <whitequark> *does not do
2013-01-30 01:59 <wpwrak> for example, i ran into this with my "antorcha". it has several relatively complex subsystems that each handle message sequences
2013-01-30 02:00 <wpwrak> so the message dispatcher calls X1, X2, etc., where X1 initializes some resource, then X2 and so on use it, but if an Y1 would arrive, the resource would have to be taken away
2013-01-30 02:00 <wpwrak> i didn't really implement such a scheme, though. so most of it is individual allocation (of static items or stack), with a small number of manually managed shared things
2013-01-30 02:01 <wpwrak> maybe you could structure the language such that only things the compiler can handle can be expressed
2013-01-30 02:02 <whitequark> this is not quite a good way to make a systems programming language :)
2013-01-30 02:02 <whitequark> let me make a small overview of different allocation cases.
2013-01-30 02:02 <wpwrak> depends. as long as you don't exclude things people actually need, why not ?
2013-01-30 02:03 <whitequark> first, I of course do not have boxed objects. The memory layout of an object is just its fields and alignment, plus maybe a pointer to vtable if it can have virtual dispatch.
2013-01-30 02:03 <whitequark> scalars are scalars. Int64 is a 64-bit machine int and nothing else to stay in the way.
2013-01-30 02:04 <wpwrak> it may also help to exclude linking at the beginning. assume the compiler sees the entire source, libraries included. that way, it can keep as much information as it wants
2013-01-30 02:04 <wpwrak> in embedded, many programs are small enough that a modern PC can handle this anyway
2013-01-30 02:04 <whitequark> almost everything (to be precise, everything except scalars) is passed by reference; there are no "copy constructors" or "move semantics"
2013-01-30 02:05 <whitequark> wpwrak: (entire source) of course, ruby kind of forces this. also LTO is mandatory. don't underestimate modern PCs; webkit links for 8 hours @ modern i7 and gigabytes of RAM with LTO, but it builds.
2013-01-30 02:05 <wpwrak> ;-))
2013-01-30 02:06 <wpwrak> seems there's still some room for improvement :)
2013-01-30 02:06 <whitequark> so, each time I allocate something non-scalar, I have to consider allocating it either on stack or on heap.
2013-01-30 02:06 <whitequark> I already perform bidirectional dataflow analysis for unrelated reasons, so checking if a value escapes its scope is almost trivial
2013-01-30 02:06 <wpwrak> or static (allocation)
2013-01-30 02:07 <whitequark> (not quite trivial with virtual calls, but still manageable)
2013-01-30 02:07 <wpwrak> heap is dangerous. heap is basically static allocation where you don't know what you're actually doing.
2013-01-30 02:07 <whitequark> kind of. if you want static allocation, just allocate a value globally
2013-01-30 02:08 <whitequark> and capture the reference somewhere.
2013-01-30 02:08 <whitequark> a constant probably.
2013-01-30 02:08 <wpwrak> what i mean is that, in order to avoid bad surprises, the compiler should always be able to reduce things to static allocation
2013-01-30 02:08 <wpwrak> with the option of overlapping allocations, of course
2013-01-30 02:08 <whitequark> wait a bit :)
2013-01-30 02:08 <wpwrak> also stack allocation should be bounded for the same reason
2013-01-30 02:09 <whitequark> there are generally two kinds of allocations; first, there are objects.
2013-01-30 02:09 <whitequark> objects have a fixed size, which is known at compile time.
2013-01-30 02:09 <whitequark> second, there are buffers, which these objects allocate. buffer size can be either known or unknown at compile time.
2013-01-30 02:10 <whitequark> allocating an unbounded buffer on stack is so bad I think it should be simply forbidden
2013-01-30 02:10 <whitequark> bounded buffers can sometimes be allocated on stack or statically.
2013-01-30 02:10 <wpwrak> well, if your embedded system has a nice way of handling an out of memory condition ... ;-)
2013-01-30 02:11 <whitequark> now, there's one case which C++ doesn't play quite well
2013-01-30 02:11 <whitequark> what if I try to return an aggregate?
2013-01-30 02:11 <wpwrak> you could still have global variables that need stack allocation. then figure out the maximum stack size via call chain analysis.
2013-01-30 02:11 <wpwrak> disallow recursive functions ;-)
2013-01-30 02:12 <whitequark> non-tail-recursive functions, but yes, of course there'll be such an option
2013-01-30 02:12 <wpwrak> aggregates are scalars :)
2013-01-30 02:12 <whitequark> afaik it is a general guideline in embedded anyway :)
2013-01-30 02:12 valhalla has quit [Ping timeout: 276 seconds]
2013-01-30 02:12 <whitequark> global vars that need stack allocation -- not sure here
2013-01-30 02:12 <whitequark> why would globals need stack allocation?
2013-01-30 02:13 <wpwrak> because part of the code may use global A and another part may use global B. but if the life time of A ends before B is used and vice versa, you can share the memory
2013-01-30 02:14 <whitequark> I guess in this case you could simply allocate it as a local?
2013-01-30 02:15 <whitequark> or a part of a local
2013-01-30 02:15 <whitequark> that would be clear from the source itself and easily controllable
2013-01-30 02:16 <whitequark> eg pack your work into classes WorkA and WorkB. then from the dispatcher, WorkA.new.work or WorkB.new.work
2013-01-30 02:16 <whitequark> and the memory would be shared implicitly via the stack; also the compiler will statically check for stack overflows for you in this case.
2013-01-30 02:16 <wpwrak> the domain of A and the domain of B may have a common ancestor (in the call chain)
2013-01-30 02:16 <wpwrak> like in my networking example
2013-01-30 02:17 <wpwrak> of course, you could disallow that way of expressing my example
2013-01-30 02:17 <wpwrak> but then you have to deal with several instances of the message dispatcher
2013-01-30 02:18 <whitequark> if they simply have a common ancestor in the call chain, that's not a problem
2013-01-30 02:18 <whitequark> if they intersect, they is
2013-01-30 02:18 <whitequark> *that is
2013-01-30 02:18 <wpwrak> they intersect in the ancestor as far as locals are concerned
2013-01-30 02:19 <whitequark> ahh
2013-01-30 02:19 <wpwrak> so you'd need a away to tell the ancestor that this apparent intersection in fact isn't an intersection
2013-01-30 02:19 <whitequark> DFA has no problems figuring out this :)
2013-01-30 02:19 <wpwrak> ... and make sure that is enforced :)
2013-01-30 02:20 <whitequark> you mean this case? http://pastie.org/5952380
2013-01-30 02:20 <whitequark> so the domains would intersect in a 'temporary local'?
2013-01-30 02:20 <wpwrak> let there be several foo messages. foo1, foo2, foo3
2013-01-30 02:21 <wpwrak> all begin with foo1. then you can have foo* for as long as you wish. but if you have a bar, then you need to do a foo1 or it's an error
2013-01-30 02:21 <whitequark> so it's an FSM?
2013-01-30 02:22 <wpwrak> so foo1 creates the potentially large context (and of course, foo1 may in turn be a set of messages)
2013-01-30 02:22 <wpwrak> well, everything is an FSM ;-)
2013-01-30 02:22 <whitequark> heh
2013-01-30 02:22 <whitequark> I don't quite get the nesting in your example
2013-01-30 02:22 <whitequark> maybe a snippet would be a better explanation?
2013-01-30 02:22 <whitequark> pseudocode, whatever
2013-01-30 02:24 <wpwrak> well, i have code but that may be too convoluted to help: http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/fw/dispatch.c and http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/fw/dispatch.h for the packet handlers
2013-01-30 02:24 <wpwrak> here's no "clean" resource management there
2013-01-30 02:26 <wpwrak> that protocol has several "modes". you enter a mode, e.g., an image upload, with a start message, then a number of image-specific messages, and you eventually exit it (be it by success, failure, or a switch to another mode)
2013-01-30 02:26 <wpwrak> instead of the image mode, you make have a continuous measurement mode (there's an acceleration sensor in the system)
2013-01-30 02:26 <whitequark> yup, got it
2013-01-30 02:26 <wpwrak> and there are more modes
2013-01-30 02:27 <whitequark> neat design btw
2013-01-30 02:27 <wpwrak> some of them set up secret keys for authentication. (the "crypto" there is all fake but in theory you could make it work better)
2013-01-30 02:27 <wpwrak> thanks :)
2013-01-30 02:28 <wpwrak> those crypto keys are expensive in relation to total memory of that chip. and so are the network buffers.
2013-01-30 02:29 <whitequark> buf[1] is sequence number?
2013-01-30 02:29 <wpwrak> well, crypto contexts. the keys actually aren't so bad. but checking them is.
2013-01-30 02:29 <wpwrak> yes: http://projects.qi-hardware.com/index.php/p/antorcha/source/tree/master/doc/PROTOCOL
2013-01-30 02:31 <wpwrak> (payload sizes are per packet. an image would have multiple packets.)
2013-01-30 02:32 <wpwrak> the underlying crypto concept are shared secret keys. then you send a hash of key+salt+data
2013-01-30 02:33 <wpwrak> of course, the actual hash function is everything but secure ;-)
2013-01-30 02:34 <wpwrak> i'm not even sure i would have enough space in that chip for it. but this is an obsolete design anyway. the designated successor will abandon AVR for ARM cortex. still constrained, though. just not as badly.
2013-01-30 02:34 <whitequark> you would have a chance to use Foundry ;)
2013-01-30 02:36 <wpwrak> foundry .. make my own arm chips ?
2013-01-30 02:37 <whitequark> meh. no, that's the name of my compiler
2013-01-30 02:37 <wpwrak> ah :)
2013-01-30 02:37 <whitequark> http://foundry-lang.org/ etc.
2013-01-30 02:37 <wpwrak> naw, in C i trust :)
2013-01-30 02:37 <wpwrak> ;-))
2013-01-30 02:38 <whitequark> btw how are you going to flash the firmware if it doesn't fit in RAM?
2013-01-30 02:38 <whitequark> or rather, how are you going to verify it prior to flashing?
2013-01-30 02:38 <whitequark> key word is prior :)
2013-01-30 02:38 <wpwrak> i have a separate boot loader. and i can't verify.
2013-01-30 02:39 <wpwrak> well, maybe i could. but that would be over-engineering :)
2013-01-30 02:39 <whitequark> I think that CBC is what you effectively want
2013-01-30 02:39 <whitequark> but that'd require some crypto magic
2013-01-30 02:39 <wpwrak> i think i sized things for md5 or sha1
2013-01-30 02:40 <whitequark> you could append sha1 after each block and extend it with the next one
2013-01-30 02:40 <whitequark> sha1 is Merkle-Damgard chainable
2013-01-30 02:40 <wpwrak> not meant to be super-hard. just discourage any bastards from trying anything
2013-01-30 02:41 <wpwrak> naw, i have an "unlock" step and then a content verification.
2013-01-30 02:41 <whitequark> yeah, would work too
2013-01-30 02:41 <whitequark> unlock, that is
2013-01-30 02:41 <wpwrak> that's of course not bullet-proof, but the idea is that one would never send the unlock in an unsafe environment
2013-01-30 02:42 <wpwrak> or, rather, hostile environment
2013-01-30 02:42 <whitequark> I don't quite get why you need content verification, or how would you prevent malicious code to be flashed even partially
2013-01-30 02:42 wolfspraul has quit [Quit: leaving]
2013-01-30 02:42 wolfspraul has joined #qi-hardware
2013-01-30 02:42 <wpwrak> so you have "safe" (which doesn't exist), "unsafe" (you trust but you also check), and "hostile" (you assume that you will be attacked)
2013-01-30 02:43 <whitequark> that sounds rather silly to me, to be sincere
2013-01-30 02:43 <whitequark> you either protect yourself from attacks, or not
2013-01-30 02:43 <whitequark> there is no half-way security.
2013-01-30 02:43 <wpwrak> of course, the enemy would first have to figure out there's something worth attacking :)
2013-01-30 02:43 <wpwrak> naw, it's a matter of procedure
2013-01-30 02:44 <whitequark> given that you don't need encryption but only authentication, you can trivially chain sha1
2013-01-30 02:44 <whitequark> over a known secret and all the following firmware blocks
2013-01-30 02:44 <wpwrak> in "hostile", you don't do an unlock. in "unsafe", you do. but you may end up with a denial of service if an enemy sneaks in at the right moment.
2013-01-30 02:44 <whitequark> you don't need unlock with chained sha1
2013-01-30 02:44 <wpwrak> (chain) yes, that's the idea
2013-01-30 02:44 <whitequark> at all
2013-01-30 02:45 <wpwrak> i don't have storage for a tentative copy
2013-01-30 02:45 <whitequark> see, you don't _end_ the transmission with salt and then verify
2013-01-30 02:45 <whitequark> you first hash a known secret, then append firmware blocks to that hash
2013-01-30 02:46 <whitequark> if a particular hash compares equal, that means that every previous one was good as well.
2013-01-30 02:46 <whitequark> *shared secret.
2013-01-30 02:46 <whitequark> that's the whole point of Merkle-Damgard
2013-01-30 02:46 <wpwrak> yes, i could send a hash after each block
2013-01-30 02:47 <wpwrak> but then, the bad guys could just jam me, giving me the same sort of DoS ;-)
2013-01-30 02:47 <whitequark> sha1(a+b) is (omitting some details) sha1extend(sha1extend("", a), b)
2013-01-30 02:47 <whitequark> so it is composable
2013-01-30 02:47 <whitequark> wpwrak: (jamming) but you're not immune to it in any case
2013-01-30 02:47 <whitequark> so it doesn't exactly matter
2013-01-30 02:48 <wpwrak> exactly. so i can't ensure transactional semantics, no matter what i do
2013-01-30 02:48 <wpwrak> i.e., there's no rollback if things turn sour
2013-01-30 02:48 <wpwrak> but yes, i could avoid the unlock
2013-01-30 02:48 <wpwrak> one key less to manage :)
2013-01-30 02:48 <whitequark> and more clear crypto.
2013-01-30 02:49 <wpwrak> yeah, fewer states
2013-01-30 02:51 <wpwrak> but as i said, the "crypto" in this implementation sucks. it's pretty much a foul compromise that acknowledges that "secret" keys can be compromised. (due to implementation restrictions)
2013-01-30 02:51 <wpwrak> so it's more security theater than anything properly done
2013-01-30 02:52 <whitequark> well, you can disable flash reading, no?
2013-01-30 02:52 <whitequark> won't make a problem for someone with an UV and some black duct tape, though
2013-01-30 02:52 <wpwrak> oh, i assume i have control of the device at all times
2013-01-30 02:52 <whitequark> then how could the keys be compromised?
2013-01-30 02:53 <wpwrak> since i don't have proper crypto in place, they're pretty much sent over the air :)
2013-01-30 02:53 <whitequark> ahhh
2013-01-30 02:53 <whitequark> add something lightweight
2013-01-30 02:53 <whitequark> Rijndael?
2013-01-30 02:53 <whitequark> aka AES
2013-01-30 02:53 <whitequark> this would fit very nicely in that chained scheme
2013-01-30 02:53 <wpwrak> but this still needs 1) the enemy to even be aware of me, 2) care, 3) find a way to be RF-compatible, 4) implement the protocol
2013-01-30 02:53 <whitequark> that is basically how AES is generally authenticated
2013-01-30 02:53 <whitequark> well, yeah
2013-01-30 02:55 <wpwrak> i designed for SHA1, which is pretty much the most light-weight without being silly
2013-01-30 02:56 <wpwrak> but anyway, this design isn't going anywhere. the next one will have different parameters. even RF will be optional there.
2013-01-30 02:56 <wpwrak> i.e., a little uSD card goes a long way ;-)
2013-01-30 02:58 <whitequark> wpwrak: well, what I'd do with that code is simply factor out the nested message parsing loops to, well, nested loops
2013-01-30 02:58 <whitequark> would solve everything *and* make it more clear :)
2013-01-30 02:59 <wpwrak> you mean get rid of the protocol handlers ? yes, that would work. less modular, though.
2013-01-30 02:59 <whitequark> no, why do that?
2013-01-30 02:59 <wpwrak> to help the compiler :)
2013-01-30 02:59 <whitequark> ok, I'll just open my editor...
2013-01-30 03:01 megha has quit [Quit: WeeChat 0.4.0]
2013-01-30 03:01 <wpwrak> the infinite jukebox works really well, 05:20 and counting :) (still bug powder dust)
2013-01-30 03:04 xiangfu has joined #qi-hardware
2013-01-30 03:04 <wpwrak> the only things missing are some female vocals and something like the "I can and shall obey" of "blue monday"
2013-01-30 03:24 <whitequark> wpwrak: I guess this is pretty close: http://pastie.org/5953095
2013-01-30 03:25 <whitequark> line 52 should be: class FirmwareFlashHandler < Handler
2013-01-30 03:29 <wpwrak> yes, but you lose the central event loop this way. so that would have to be restructured as well.
2013-01-30 03:29 <wpwrak> not impossible, though
2013-01-30 03:30 <whitequark> wpwrak: you can restructure this code as well
2013-01-30 03:31 <whitequark> in numerous ways. closures and lightweight coroutines would work here, with coroutines being probably the best option
2013-01-30 03:31 <wpwrak> the limitation is that you need to be able to call the message getter instead of being called by the message getter
2013-01-30 03:32 <wpwrak> and you need this to be able to "own" the mode-specific state
2013-01-30 03:33 <wpwrak> you could have objects with mutually exclusive lifetimes instead, but then you'd need a way to communicate that to the compiler
2013-01-30 03:33 <wpwrak> (that is, unless it can figure it out by execution flow analysis)
2013-01-30 03:34 <whitequark> compilers seldom analyze memory
2013-01-30 03:34 <whitequark> nonlocal memory, that is.
2013-01-30 03:35 <wpwrak> to make everything static in a language that is inherently dynamic, it has to analyze everything :)
2013-01-30 03:35 <whitequark> hehe
2013-01-30 03:38 <whitequark> wpwrak: well, there's a way
2013-01-30 03:38 <whitequark> you just wrap this in a Fiber.
2013-01-30 03:39 <wpwrak> fiber ?
2013-01-30 03:39 <whitequark> a coroutine.
2013-01-30 03:39 <whitequark> in this particular case it won't be lightweight, but the maximal stack size is still known precisely
2013-01-30 03:39 <wpwrak> then you need to ensure coroutines don't coexist
2013-01-30 03:39 <whitequark> nay
2013-01-30 03:39 <whitequark> all of the stuff which cannot coexist is in *one* fiber
2013-01-30 03:39 <whitequark> but Message.get gets replaced by a Fiber.yield.
2013-01-30 03:40 <whitequark> then, event loop yields the message to the fiber when it's available.
2013-01-30 03:41 <whitequark> you can schedule concurrent tasks in a similar way, and still be sure that you'll fit into RAM
2013-01-30 03:41 <whitequark> well, basically this is a way of telling compilers which lifetimes can intersect and which ones cannot :)
2013-01-30 03:41 <whitequark> *compiler
2013-01-30 03:42 <wpwrak> that seems to just add an unnecessary extra layer. isn't the code in your example already single-threaded ?
2013-01-30 03:42 <whitequark> wpwrak: no, that's just rearranging exactly same code in a more structured way
2013-01-30 03:43 <wpwrak> hmm. i sense extra allocations :)
2013-01-30 03:43 <whitequark> *if* you need an external event loop, which means that an incoming message is not the only event
2013-01-30 03:43 <whitequark> then you probably need to handle another ones
2013-01-30 03:43 <whitequark> extra allocations? nay
2013-01-30 03:44 <whitequark> you simply split the stacks
2013-01-30 03:44 <whitequark> the default Fiber has everything which was below `dispatch', the communication fiber has `dispatch' and everything above
2013-01-30 03:44 <whitequark> there's nothing inside a Fiber except its stack, so... :)
2013-01-30 03:45 <whitequark> of course, if you don't need to process those other events, you can as well leave Message.get where it is
2013-01-30 03:45 <whitequark> the advantage of Fibers is that you don't need to refactor almost anything.
2013-01-30 03:45 <wpwrak> so you pass messages by reference between threads ?
2013-01-30 03:45 <whitequark> coroutines. they're not threads; they cannot execute in parallel
2013-01-30 03:45 <whitequark> so, yes
2013-01-30 03:47 <whitequark> code with coroutines is directly equivalent to corresponding evented code
2013-01-30 03:47 <whitequark> it's just another way of representing the same thing
2013-01-30 03:49 <wpwrak> i see. yes, that may work. compiler still needs to be able to figure out how coroutines are nested, though
2013-01-30 03:49 <whitequark> that is trivial, given my bidiDFA and EA
2013-01-30 03:49 <wpwrak> so they're just like functions
2013-01-30 03:50 <whitequark> functions which can return from a random point and return to that point, yeah
2013-01-30 03:50 <whitequark> if you write it evented way, you have to track all that manually
2013-01-30 03:51 <wpwrak> (functions) i mean to the compiler
2013-01-30 03:51 <whitequark> oh. no, of course. they're values.
2013-01-30 03:51 <whitequark> first and foremost.
2013-01-30 03:52 <whitequark> and I can trivially check if a value is only referenced in the main dispatch loop
2013-01-30 03:52 <whitequark> besides, it doesn't even matter if they call each other or not
2013-01-30 03:52 <whitequark> coroutine calls never grow the call stack
2013-01-30 03:53 <whitequark> it *does* matter that you do not create them without bounds. but see above.
2013-01-30 03:55 <wpwrak> hmm yes, you'd have to track their life time, not whether they call each other
2013-01-30 03:56 <whitequark> yup
2013-01-30 03:57 <whitequark> note that if your call graph is a tree, you can allocate Fibers on stack
2013-01-30 03:57 <whitequark> fiberception!
2013-01-30 03:59 <whitequark> and specialization and aggressive constant propagation and inlining greatly simplifies the call graph, which also helps quite a bit
2013-01-30 03:59 <whitequark> *simplify
2013-01-30 04:00 <wpwrak> not too different from objects. common ancestor owns them, they call each other's methods.
2013-01-30 04:00 <whitequark> yeah, kind of
2013-01-30 04:00 <wpwrak> where "owns" means "determines lifetime"
2013-01-30 04:00 <whitequark> as I've said, it is a structured way to alter control flow
2013-01-30 04:02 <whitequark> also lightweight coroutines are an excellent tool for writing highly concurrent code
2013-01-30 04:02 DocScrutinizer05 has quit [Read error: Operation timed out]
2013-01-30 04:02 <whitequark> eg Hoare/Communicating Sequental Processes; what Go is based on.
2013-01-30 04:02 <wpwrak> yes, where you "call" to return and are "returned to" to be called
2013-01-30 04:02 <whitequark> wpwrak: there's a thing called "continuation"
2013-01-30 04:02 <wpwrak> making the local state a little less clunky
2013-01-30 04:03 <whitequark> simplified, a captured continuation represents all the computation which will happen *after* your method returns
2013-01-30 04:03 DocScrutinizer05 has joined #qi-hardware
2013-01-30 04:03 <wpwrak> you can hide it all in message passing. as long as there's no buffer, you get the same semantics
2013-01-30 04:03 <whitequark> here, you basically capture exchange continuations between functions
2013-01-30 04:03 <whitequark> yeah
2013-01-30 04:03 <wpwrak> e.g., SPIN does that
2013-01-30 04:04 <wpwrak> well, Promela (SPIN is the implementation)
2013-01-30 04:05 <whitequark> yup, Prolema looks like it was modelled after CSP
2013-01-30 04:05 <wpwrak> ah, you know it. good :) few enough people do
2013-01-30 04:06 <wpwrak> lovely system. about the only way to get the bugs out of non-trivial protocols.
2013-01-30 04:06 <whitequark> wpwrak: not exactly Promela, never seen it before. but I did look at enough CSP-related code
2013-01-30 04:06 <whitequark> it's hardly the only example :)
2013-01-30 04:06 <whitequark> see, there's something I do better than C ;)
2013-01-30 04:09 <wpwrak> heh, well the purpose of promela is to add non-determinism, so ... :)
2013-01-30 04:12 <whitequark> oh 8AM
2013-01-30 04:12 <whitequark> this was sudden
2013-01-30 04:12 <wpwrak> that sneaky sun ;-)
2013-01-30 04:14 <whitequark> sun?
2013-01-30 04:14 <whitequark> what's that?
2013-01-30 04:15 <whitequark> it'll be not until 10AM or maybe even 12AM that it'd begin to dawn
2013-01-30 04:15 <wpwrak> the position of the evil day star is what commonly determines the day time, in some areas with +/- 1 h or similar
2013-01-30 04:15 <wpwrak> oh. what's why they called it the dark age :)
2013-01-30 04:16 <whitequark> besides, I've caught a cold and really need to sleep. so, bbl.
2013-01-30 04:16 <wpwrak> interesting fever dreams then !
2013-01-30 04:16 <whitequark> thanks:)
2013-01-30 04:58 pcercuei has joined #qi-hardware
2013-01-30 05:11 Jay7 has joined #qi-hardware
2013-01-30 05:22 pcercuei has quit [Quit: Bye]
2013-01-30 07:39 jluis has joined #qi-hardware
2013-01-30 07:54 jekhor has joined #qi-hardware
2013-01-30 07:56 valhalla has joined #qi-hardware
2013-01-30 08:48 <DocScrutinizer05> hey guys, anybody good with ssh(d)?
2013-01-30 08:50 <DocScrutinizer05> why can I log in with one local ssh setting while not with another to a machine where .ssh/ is 744? Why can same local ssh setting that refuses to log in to machine A with 744 nevertheless log in fine to another machine that also has .ssh/ = 744?
2013-01-30 08:51 <DocScrutinizer05> some *strict*-fu* I guess
2013-01-30 08:53 <DocScrutinizer05> and is there any friggin way to make ssh output meaningful diagnostics regarding all that? -vv doesn't help at all
2013-01-30 08:56 <DocScrutinizer05> ooh, i maybe should mention that ssh-agent is involved
2013-01-30 08:57 <DocScrutinizer05> to forward local private key to second hop: local->A->B
2013-01-30 09:10 <mth> I'd guess that the sshd on the machine you're logging in to would decide whether or not to reject that machine's ~/.ssh/ with 744
2013-01-30 09:31 jekhor has quit [Ping timeout: 256 seconds]
2013-01-30 09:40 <lindi-> wpwrak: spin is the closed source implementation, nips is the open source implementation
2013-01-30 10:20 wej has joined #qi-hardware
2013-01-30 10:22 <DocScrutinizer05> mth: depending on my *local* config the *remote* machine needs 700 .ssh/ (on remote) or not
2013-01-30 10:24 <DocScrutinizer05> and remote A rejects with 744 while remote B doesn't, with same local config
2013-01-30 10:33 <mth> that second line is what I expected, the first isn't
2013-01-30 10:34 <mth> maybe both the server and the client check and only if both approve you can login?
2013-01-30 11:28 dandon_ has joined #qi-hardware
2013-01-30 11:30 dandon has quit [Ping timeout: 257 seconds]
2013-01-30 11:30 dandon_ is now known as dandon
2013-01-30 11:44 megha has joined #qi-hardware
2013-01-30 11:53 xiangfu has quit [Ping timeout: 264 seconds]
2013-01-30 11:59 xiangfu has joined #qi-hardware
2013-01-30 12:02 qwebirc83678 has joined #qi-hardware
2013-01-30 12:03 <qwebirc83678> Hi everyone! Anybody has recovered a "bricked" ATUSB ?
2013-01-30 12:04 <qwebirc83678> I have two ATUSBs and when I plug one it appears in the lspci and the other one not, so I suppose it is bricked or directly no correctly assembled
2013-01-30 12:17 qwebirc83678 has quit [Ping timeout: 245 seconds]
2013-01-30 12:27 xiangfu has quit [Read error: Connection reset by peer]
2013-01-30 12:28 xiangfu has joined #qi-hardware
2013-01-30 12:32 xiangfu has quit [Client Quit]
2013-01-30 12:32 xiangfu has joined #qi-hardware
2013-01-30 12:55 dandon has quit [Ping timeout: 246 seconds]
2013-01-30 12:55 dandon_ has joined #qi-hardware
2013-01-30 12:55 dandon_ is now known as dandon
2013-01-30 13:06 megha has quit [Read error: Connection reset by peer]
2013-01-30 13:21 pcercuei has joined #qi-hardware
2013-01-30 13:23 <qi-bot> [commit] Werner Almesberger: prod/doc/figfilt: script to filter portions of a FIG file based on keys in comments (master) http://qi-hw.com/p/ben-wpan/5733b60
2013-01-30 13:23 <qi-bot> [commit] Werner Almesberger: prod/doc/Makefile: add missing dependencies on at{ben,usb}-{front,back}.png (master) http://qi-hw.com/p/ben-wpan/3800125
2013-01-30 13:23 <qi-bot> [commit] Werner Almesberger: prod/doc/test.hmac: fix unterminated IMG tag (master) http://qi-hw.com/p/ben-wpan/ee870b5
2013-01-30 13:24 megha has joined #qi-hardware
2013-01-30 13:59 pcercuei has quit [Ping timeout: 272 seconds]
2013-01-30 13:59 pcercuei has joined #qi-hardware
2013-01-30 14:09 xiangfu has quit [Ping timeout: 248 seconds]
2013-01-30 14:11 xiangfu has joined #qi-hardware
2013-01-30 14:50 rz2k has joined #qi-hardware
2013-01-30 14:59 xiangfu has quit [Ping timeout: 245 seconds]
2013-01-30 15:07 pcercuei has quit [Ping timeout: 272 seconds]
2013-01-30 15:13 viric_ has joined #qi-hardware
2013-01-30 15:14 viric has quit [Ping timeout: 252 seconds]
2013-01-30 15:25 urandom__ has joined #qi-hardware
2013-01-30 15:30 DocScrutinizer05 has quit [Disconnected by services]
2013-01-30 15:30 DocScrutinizer05 has joined #qi-hardware
2013-01-30 15:43 kyak has joined #qi-hardware
2013-01-30 15:55 emeb has joined #qi-hardware
2013-01-30 16:07 wej has quit [Ping timeout: 245 seconds]
2013-01-30 16:26 megha is now known as firewall
2013-01-30 16:29 jluis has quit [Ping timeout: 246 seconds]
2013-01-30 16:40 viric_ is now known as viric
2013-01-30 16:47 pcercuei has joined #qi-hardware
2013-01-30 16:47 wej has joined #qi-hardware
2013-01-30 17:06 kilae has joined #qi-hardware
2013-01-30 17:25 pcercuei has quit [Ping timeout: 248 seconds]
2013-01-30 17:27 bzb has joined #qi-hardware
2013-01-30 17:28 pcercuei has joined #qi-hardware
2013-01-30 17:46 pcercuei has quit [Remote host closed the connection]
2013-01-30 18:19 <whitequark> damn, it's night again :S
2013-01-30 18:19 <whitequark> wpwrak: you'll like this: I've just compiled a file, LLVM decided it's more clever than me and rewrote printf("foo\n"); to puts("foo");
2013-01-30 18:27 <wpwrak> nice :)
2013-01-30 18:28 <wpwrak> can it also figure out printf("%s\n", blah); ?
2013-01-30 18:31 <whitequark> wpwrak: yeah
2013-01-30 18:32 <whitequark> it has builtin knowledge of all of the C stdlib, including prototypes, printf/scanf format specifiers, and whatnot
2013-01-30 18:33 <whitequark> converts exit() in main() to return;
2013-01-30 18:34 <whitequark> verifies that you didn't suddenly decided to overwrite a .rodata string
2013-01-30 18:34 <whitequark> etc etc
2013-01-30 18:34 <whitequark> converts loops to memset/memcpy
2013-01-30 18:36 <whitequark> figures out that in a loop like for(int i = 0; i < 10; i++) printf("
2013-01-30 18:36 <whitequark> err
2013-01-30 18:36 <whitequark> figures out that in a loop like for(int i = 0; i < 10; i++) printf("%d\n", ints[i]); it would be beneficial to convert the induction variable to be incremented by word size and begin at the `ints'
2013-01-30 18:37 <whitequark> it is quite certainly more clever than me in a lot of cases.
2013-01-30 18:42 <larsc> only so long until the machines will take over ;)
2013-01-30 18:42 <larsc> I think the last optimization is pretty standard though
2013-01-30 18:42 <whitequark> larsc: I'm not sure gcc does it
2013-01-30 18:42 <whitequark> LLVM in fact does it becaise autovectorizer needs it :)
2013-01-30 18:42 <larsc> I would be scared if it didn't
2013-01-30 18:43 <whitequark> larsc: I'm scared of GCC since I looked into its sources and seen lisp, c and asm in one file
2013-01-30 18:45 <larsc> just tried it: "add    $0x4,%rbx" and "cmp    $0x28,%rbx"
2013-01-30 18:54 kilae has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]]
2013-01-30 19:26 <whitequark> hm, LLVM is able to retain correct debug info through all optimizations, and it retains it at all for most of them
2013-01-30 19:27 <whitequark> eg stacktraces include inlined functions
2013-01-30 19:27 <whitequark> and it doesn't screw your mind with <value optimized out>.
2013-01-30 19:27 <lindi-> wpwrak: gcc also converts printf to puts
2013-01-30 19:27 <lindi-> wpwrak: llvm copied that idea from there :)
2013-01-30 19:28 <whitequark> lindi-: might be the other way around
2013-01-30 19:28 <whitequark> gcc is now C++-compatible to allow for more easy incorporation of LLVM passes :)
2013-01-30 19:28 <lindi-> wpwrak: my impression is that gcc got it first, I fixed a bug in that part in llvm
2013-01-30 19:28 <lindi-> wpwrak: the optimization is incorrect if you use the return values of the printf in your program
2013-01-30 19:32 <wpwrak> heh :)
2013-01-30 20:08 jekhor has joined #qi-hardware
2013-01-30 20:11 <larsc> whitequark: yea, <value optimized out> is a major annoyance. but how does llvm make sure that this doesn't happen?
2013-01-30 20:13 <whitequark> larsc: I guess just better tracking of values and better DWARF generation
2013-01-30 20:13 <whitequark> as in, your value could be moved to register from memory, but DWARF can still handle it
2013-01-30 20:14 <whitequark> or optimized to constant, but see above
2013-01-30 20:24 <larsc> whitequark: yeay, but if you have something like foo(int x) { int t = abs(x); ... } and the compiler decides to put x and t in the same register, how does it get to know x?
2013-01-30 20:27 <whitequark> larsc: hm this is interesting
2013-01-30 20:27 <whitequark> I should check this case
2013-01-30 21:14 <larsc> anybody coming to fosdem?
2013-01-30 21:20 <viric> ah
2013-01-30 21:20 <viric> I was about to ask that!
2013-01-30 21:20 <viric> I go.
2013-01-30 21:20 <larsc> cool
2013-01-30 21:20 <larsc> going to the beer event?
2013-01-30 21:44 <viric> uhm I haven't looked at the program :D
2013-01-30 21:44 <viric> I discovered only yesterday that I could go to it
2013-01-30 21:44 <viric> Ah I see
2013-01-30 21:45 <viric> I arrive on saturday, 16:00!
2013-01-30 21:45 <larsc> so you are going to miss the best part ;)
2013-01-30 21:47 <viric> yes, I imagine so
2013-01-30 21:47 <viric> But my boss forbid me to move on friday
2013-01-30 21:47 <larsc> :/
2013-01-30 21:49 <viric> Yes, because we promised to give support to one customer on full friday
2013-01-30 21:49 <viric> but now the customer says that he won't be ready. A hell.
2013-01-30 22:02 firewall is now known as megha
2013-01-30 22:03 wej has quit [Ping timeout: 264 seconds]
2013-01-30 22:08 wej has joined #qi-hardware
2013-01-30 22:14 jekhor has quit [Read error: Operation timed out]
2013-01-30 22:15 jekhor has joined #qi-hardware
2013-01-30 22:24 Guo has joined #qi-hardware
2013-01-30 22:25 Guo has quit [Client Quit]
2013-01-30 22:43 jekhor has quit [Ping timeout: 252 seconds]
2013-01-30 22:47 jekhor has joined #qi-hardware
2013-01-30 22:53 <viric> larsc: I'd be pleased to meet you at fosdem
2013-01-30 22:55 <viric> are you giving a talk?
2013-01-30 22:57 jekhor has quit [Ping timeout: 264 seconds]
2013-01-30 22:58 <larsc> no, I decided to late that I'd come to fosdem.
2013-01-30 22:58 <larsc> if you don't have any other plans we could maybe go for a beer on saturday evening
2013-01-30 23:04 <viric> I'm not sure I have other plans :)
2013-01-30 23:04 <viric> I plan to meet people
2013-01-30 23:04 <wpwrak> larsc: i approve of your priorities :)
2013-01-30 23:05 <wpwrak> viric: the best meetings are over some beers ;-)
2013-01-30 23:06 <viric> I don't oppose the beers! :)
2013-01-30 23:06 <viric> I just don't know if I may meet with 20 more people for beers
2013-01-30 23:09 <viric> it may be that I join the people around 'nix', maybe some around 'gnu'
2013-01-30 23:09 <viric> but I don't want to miss larsc !
2013-01-30 23:09 <viric> larsc: do other people from mipslinux come?
2013-01-30 23:12 <larsc> I know that nbd will be there, haven't heard from anybody else
2013-01-30 23:37 <viric> ok
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/ubb-la.c: raise MMC bus clock to 84 MHz during overhead (master) http://qi-hw.com/p/ben-blinkenlights/bf62b20
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/ubb-la. (xfers): re-optimize the start bit (master) http://qi-hw.com/p/ben-blinkenlights/3b007eb
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/ubb-la.c (xfers): revert to "safe" end-of-command synchronization (master) http://qi-hw.com/p/ben-blinkenlights/760e8a8
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/ubb-la.c: add more section titles (master) http://qi-hw.com/p/ben-blinkenlights/b7688f3
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/gui.c: experimental GUI code (WIP) (master) http://qi-hw.com/p/ben-blinkenlights/94e099e
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/gui.c: use powers of two for zoom and integer arithmetic (WIP) (master) http://qi-hw.com/p/ben-blinkenlights/1b0a2cf
2013-01-30 23:40 <qi-bot> [commit] Werner Almesberger: ubb-la/gui.c (gui): fix the event loop to properly ignore unrecognized events (master) http://qi-hw.com/p/ben-blinkenlights/12a1808
2013-01-30 23:44 rz2k has quit [Read error: Connection reset by peer]
2013-01-30 23:58 urandom__ has quit [Quit: Konversation terminated!]