IRC Logs for #io Monday, 2016-04-18

*** soveran has joined #io00:04
*** soveran has quit IRC00:04
*** soveran has joined #io00:04
*** soveran has quit IRC00:09
*** cspotcode has quit IRC00:41
*** cspotcode has joined #io00:59
*** soveran has joined #io02:07
*** soveran has quit IRC02:12
*** TheMonkey has joined #io02:54
*** ElMonkey_ has quit IRC02:58
*** soveran has joined #io03:09
*** soveran has quit IRC03:13
*** soveran has joined #io05:10
*** soveran has quit IRC05:15
*** soveran has joined #io05:41
*** soveran has quit IRC05:41
*** soveran has joined #io05:41
*** soveran has quit IRC05:45
*** soveran has joined #io05:51
*** whaletechno has quit IRC05:53
*** joews has joined #io08:33
joewsHello! does Io have a hook for running code at end-of-process? Like Ruby's at_exit?08:34
soveranjoews: I don't think so08:44
*** joews_ has joined #io09:42
*** joews has quit IRC09:44
*** ijon_ has joined #io09:47
*** ijon_ has quit IRC09:48
*** ijon_ has joined #io09:49
joews_Does this channel have a logger? or some other way to catch up on messages?10:06
*** soveran has quit IRC10:16
*** soveran has joined #io10:19
*** soveran has quit IRC10:19
*** soveran has joined #io10:41
*** soveran has quit IRC10:41
*** soveran has joined #io10:41
*** ec\_ has joined #io11:04
*** bomma has joined #io11:04
joews_ soveran: thanks11:05
*** brixen has joined #io11:05
*** brixen_ has quit IRC11:06
*** ec\ has quit IRC11:06
*** bomma_ has quit IRC11:06
*** pdurbin has quit IRC11:06
*** pdurbin has joined #io11:44
*** soveran has quit IRC14:53
jerjoews_, you can write one but it doesn't have one baked in by default -- you can do it one of two ways, one is less ideal but easier, the other involves some C code =]14:56
joews_jer: I thought something like that would be the answer :)15:18
joews_I want to do it in Io if possible - what are the drawbacks there?15:20
joews_It's for a little test runner, it'd be a shame if I had to get a compiler involved :D15:23
joews_Of course I could just change the API so I have knowledge of when tests are done, but I figured this would be a fun thing to do in Io15:23
jerjoews_, sorry, i'm half afk15:40
jerso you can build an atExit in pure Io by writing a function, having it take a message or a block, and evaluating it -- be sure to throw atExit at the end of your program ;)15:41
jerof course you might be able to tie into the CLI object if you only care about the REPL 15:41
jerit's been a while since i looked at the CLI15:41
jerthe way i'd go about doing it is, have a primitive on Object called whatever you want, let's use atExit for the purposes of this discussion; which takes a block, and registers it in a cache kept internally to the interpreter15:42
jeron exit, we loop this cache, calling the blocks15:43
jerhonestly, we should have one of these anyway, to support a "defer" style message, that lets us defer some block to be run once the scope it is in goes away15:43
jer(as in, not when it's gc'd, but when it exits scope)15:43
jerif we had that, you'd get this behaviour almost for free15:44
jeryou'd have something like: main := method(...; defer block(blah blah blah); ...); main15:44
jerthat defer block would be run "at exit" basically15:44
jerjust before main() returns15:44
*** soveran has joined #io15:53
joews_Thanks. In the case I have in mind I don't know when the program will end (i'd like to load my library up front, then execute some amount of user code, then finally call the "atExit" block.15:55
joews_A top-level "defer" would work well there, I think, though it could still get fooled if the user code called 15:57
joews_...defer itself15:57
*** soveran has quit IRC16:09
*** soveran has joined #io16:11
*** bb010g has quit IRC16:19
jerjoews_, right, but what i'm saying is atExit is a degenerate case of defer16:23
jerthere's a global scope you don't see16:23
jereven doing a defer outside of a main() function, would suffice for atExit()16:23
joews_yeah, I got that thanks16:25
joews_defer would be a C implementation, right? 16:25
jersince the VM would have to have an internal list of block objects it could call16:46
jerthey'd have to be block objects, since they need to hold a reference to the context in which they were created, in order to execute later and have everything be found16:46
*** joews_ has quit IRC17:02
*** joews has joined #io17:16
*** joews has quit IRC17:20
jerpdurbin, you around?17:29
jerhaving this thought about building a new language, not one that's dependently typed -- that's a long term project that'll probably turn into a proof assistant tbh, but something that can actually be used to write real programs and would be. have an idea for a fault tolerant manycore language17:31
jerat a high level, take io, retune objects to act more like actors... in this sense, they could be entirely in control of their own evaluation strategy -- before i continue, this language would out of necessity be dynamically typed17:33
jerbut there'd be a possibility to add a "lint"-like tool to typecheck many aspects of programs, in the future; just wouldn't be baked into the core17:34
jercore would only allow communication between objects asynchronously, and message sends wouldn't return anything (because they can't) -- the actor involved could of course, reply if it wanted to17:34
*** endou has quit IRC17:35
jerbasic types, like numbers, reals, lists and tuples, no user defineable data structures -- objects wouldn't be a user definable data structure -- it'd merely be a container for behaviour17:35
*** endou has joined #io17:35
jerthere'd be no state sharing, the system would be immutable, this should simplify the sharing of programs across nodes17:36
jereven across processors17:36
jereach actor would have its own memory management, and a really small heap17:37
jeractually maybe it doesn't need shared memory at all17:37
jergonna have to think about that a bit more17:38
pdurbinjer: I'm barely around. Home but in and out bringing my kids to the Boston Marathon.17:40
jerah cool have fun17:41
jerjust wanted to bounce some ideas around and see if anything resonated17:41
jeri at least have an application in mind17:48
pdurbinjer: aren't your sort of describing Erlang?18:09
jeryes and no, it's hard to not show similarities18:12
pdurbinhow does it differ?18:13
jeri don't want the vm18:13
jeri want programs to be able to compiled and run on an independent core among a matrix of thousands, without having to spin up a vm18:14
pdurbinok, so like Go... similar to Erlang but compiles down to native code... no VM18:14
jerplus, erlang is the only language of its kind, we could use another18:14
jergo's not similar to erlang at all really18:14
jerplus it has a vm, it's just built in at compile time18:14
jeror not exactly a vm, but a runtime18:14
jerultimately i would want system libraries to take the C++ philosophy, of only paying for what you use -- i don't want to have to bake in any runtime more than say, 5 lines of assembler18:15
jer(i.e., bootstrap the stack)18:15
pdurbinwell, both Erlang and Go have lightweight processes or routines18:15
jerwell yes, but they're fundamentally different18:15
jererlang basically independently discovered the actor model, and go is based on csp18:15
jergive you some of the same benefits, but implemented very differently18:15
pdurbinmaybe I'm wrongheaded in thinking of Go as a more modern Erlang18:16
jertbh, it's not18:17
jerelixir is a modern erlang18:17
jerfixes some of erlang's issues around the way terms work in the system18:17
pdurbinyeah, I could see that18:17
jerplus provides a more modern syntax and libraries18:17
jergo is basically like C meets Occam18:17
jerand nothing really special about it beyond that18:17
jerplus, in go, sending a value is a synchronous operation18:18
pdurbinI'm looking at
jeryeah ignore the syntax18:18
pdurbinboth Erlang and Go seem like practical languages... production systems are built with them18:21
jeri know, i've built production systems with both18:21
jerbut we're still only really in the multicore realm, up to 16 processors, and usually no more than that.18:21
jergo is perfectly suited to that environment, erlang too18:21
jererlang may be suited for higher number of cores, i've not tried18:21
jeri want to build something that will be ok for multicore, but really built for manycore (hundreds and thousands of cores)18:22
pdurbinI thought I heard Joe Armstrong say that Erlang's excellent support for multicore is sort of a happy accident. They didn't have multicore machines like the ones we have now.18:24
pdurbinI also thought I heard that Erlang doesn't do as well after 64 cores but maybe I dreamed that.18:26
jeri don't know, i haven't tested18:26
pdurbinI've never even written any Erlang. :)18:28
jeri have18:28
jerit takes a bit of getting used to, if you've never touched it before18:28
jerbut it's not hard if you can get over what you already know about solving problems and how things work18:28
jeri.e., think of a web server; usually you bind and listen to some socket, you accept an incomming connection, and loop waiting for more connections right? your process manages all your connections, and sends the right data over the right connection as needed18:29
jernot in erlang lang, in erlang land you're webserver would respond to one and only one connection18:29
jeranother web server in your app would answer the next one, and so on18:29
jerthat way, when bugs happen, and your web server crashes, it at most impacts 1 client vs your traditional system which affects N where N is at least some subset of your total userbase, maybe all of them18:30
jerin erlang basically, don't ever think about sharing some data -- you just don't do that.18:30
jerat all.18:30
jeri mean there are ways you can, but you'll get up to speed quicker if you can hold that in your head18:31
jerthis'll lead you to making your application a set of tiny applications that talk between one another18:31
jeronly concerned with their responsibility18:31
jersending messages between each other18:31
jerso sidetracking18:32
pdurbinmakes sense18:32
jerif there's no runtime embedded in a process that's running on another core, and no vm running on that core, and there's also no sharing of state, then we don't need a heap at all, since a process would just be a collection of behaviours18:33
jerin this sense, a small slice of memory can be set up for shared stack between functions, and grow that as necessary up to some hard limit18:33
jerusually in 1000 core setups, you only have access to a few hundred kb of memory if any at all18:33
jerso that's probably not a big deal18:34
jerno need for a garbage collector at all18:34
jerneed to think about my app idea and see if this can resolve18:34
pdurbinwhat's a typical 1000 core setup? some kind of HPC environment?18:34
jertypically, now at least, they tend to be special purpose built cores layed out in an fpga, or asic, really simple, with little to no memory18:38
pdurbinhmm. ok18:38
*** zaquest has quit IRC18:38
jerno memory on each core saves you some on the power budget you have to bring to each core, but adds latency and shared memory problems -- usually have to chunk out a bunch of processors and have them share a common bus to shared memory18:39
jerand mane an N/M ported memory which can get hard18:39
jerN being core count, M being chunk of cores18:39
jerbut there are many applications that are truely parallelizeable, and benefit from more cores being thrown at a problem18:40
jerrealtime detection of patterns is a good example18:40
pdurbinI'm not very familiar with the kind of hardware you're talking about. I don't know that you can spin up stuff like this on AWS or whatever.18:41
*** bear has quit IRC18:41
*** zaquest has joined #io18:43
jeryou can't, at least yet18:43
jerwho knows what amazon will do in the future18:43
jeri dunno, something's been bugging me about not having built out acute (my implementation of io that was aiming to get serious about performance and what apis should look like, as well as how the vm shouldbe built)18:44
pdurbinin time, perhaps, availability of hardware like this would catch up to this new language... the new language would be ready :)18:44
jeras i say, i have an application idea that would suit me18:44
jerand i also have a reasonable sized fpga to play with18:45
*** bear has joined #io18:45
jeri dunno, i think i might spin up something18:46
jeri wanted to get acute to a point where io was fast enough to implement itself reasonably, allow a bit more dynamicism (let you specify your own custom lookup behaviours and evaluation strategies on a per object basis -- seemed the natural progression to the mutable AST)18:47
jerbut abandoned it after getting the vm and basic tree walker of the first stage up to about 65% completion w/o considering libraries18:48
jerbut as i say, that kind of language no longer interests me 18:48
pdurbinjer: so you're finding Io to be a good language to implement new languages in? Like the new one you're talking about?18:51
jeroh no18:52
jeri was back then, 4 and 5 years ago18:52
jertrying to build an alternate to the mainline io18:52
jermainline io wasn't too concerned about performance, or added flexibility unless it could be done in a way that wouldn't break things18:52
jeri was also interested in exploring something we'd talked about many times, making io methods and blocks take a single argument and return a single argument only18:53
jerso i changed the syntax a bit too18:53
pdurbinoh, I thought you meant you were building this on Io. would you implement it in C?18:53
jeryou can see what i did it's still up... the grammar is complete though not bug free18:53
jeri was building stage-0 in C, which would then generate a stage-1 in Io code, which would then compile that bit + extra bits into a final stage18:54
jererr correction18:54
jers/that bit/the version written in io/18:54
jerwhole purpose of the c version was just to build something flexible enough to be used to implement the rest of the system in itself18:55
jerthe resulting vm would contain a JIT evaluator, GC, standard libraries18:55
jeranother idea i've got involves the core of a tracing jit like used in pypy to spot patterns, and generate stubs that could be used to call into an fpga, along with generating verilog code that can be used to synthesize on an fpga to get some performance gains out of regular code you might not otherwise be able to19:00
jer^^ that'll be more useful once more computers come with fpga's19:00
jer(a few do right now, but not a lot)19:01
pdurbinI'm looking at
jeri also write verilog code =p19:03
jeri've got a little accumulator machine that'd be perfect -- it fits in a mid sized cpld -- about 800 LUTs19:03
jerif you've ever wondered what a register file looks like, here's one from another project: -- takes two parameters, the width of each register (32 bits in the example), and the number. the ADDR_WIDTH is the width of the address space (in this case, 2 << 4 == 32 == WIDTH)19:09
jeri could make it just take two parameters, and i think i did in a later version of that hdl19:11
jerbut oh well19:11
*** ijon_ has quit IRC19:13
jertakes a few wires, clk is the clock, reset is a reset wire, write is used to writeback, addr is the register selection in little endian, data_in holds the value to be written back; then we just output the value at addr to the output data_out, and if write is high, then we write the value in data_in back19:14
jerreally simple19:14
jerfor shits 'n giggles, an alu: =]19:24
*** FilipHanes has joined #io19:38
*** FilipHanes has quit IRC19:40
*** ijon_ has joined #io19:59
*** joews has joined #io20:51
joewsDo coroutines always execute async? i.e. given `@a; b` can I make an assumption about whether a will be executed before b?20:54
*** bb010g has joined #io20:54
joews* b before a20:54
jera will be issued before b is executed, but a will almost certainly not return before b21:13
jerand while that's not officially guaranteed, i can tell you it's de facto guaranteed based on the implementation21:14
joewsOK, thanks. I suspected that was the answer.21:15
joewsjer: I was thinking about the defer/at exit thing. What if you give the "root" coroutine a parent?21:32
joewsIs there some reason this is an awful idea? :D21:32
joewsThat constrained example does what I want, btw21:33
joewsThe main issue I see is guaranteeing that the coro I set as the parent is the same one I just created with Defer defer21:38
joewsBut then i've been playing with Io for all of a week so I may be totally wrong about how this works21:38
joewsoh, more than a week according to git! time flies.21:39
jerjoews, i just forgot =]21:44
*** soveran has quit IRC21:44
jeryeah it should be suitable21:44
joewsCool! If I can't rely on the last yielding coro being the one I just created it looks like I can `currentCoro setParentCoroutine(Scheduler yieldingCoros select(runTarget == Defer) last)`21:45
joewsThis language is pretty addictive :)21:46
*** joews has quit IRC21:50
*** soveran has joined #io22:01
*** soveran has quit IRC22:33
*** bb010g has quit IRC23:09
*** soveran has joined #io23:33
*** soveran has quit IRC23:33
*** soveran has joined #io23:33
*** whaletechno has joined #io23:37
*** soveran has quit IRC23:39
*** ijon_ has quit IRC23:40

Generated by 2.14.0 by Marius Gedminas - find it at!