**** BEGIN LOGGING AT Fri Jun 02 03:00:03 2017 Jun 02 09:56:32 jkridner: ping! Jun 02 09:59:14 jkridner: I'm still having issues with the serializer module, it's serializing variables in alphabetical order, not in the order of packet frame written. See here https://gist.github.com/ravikp7/1ded85a989cdf540a0cd6737ab88278b Jun 02 10:01:07 jkridner: "binary-parser" module works good for parsing. It's written purely in js Jun 02 10:01:55 jkridner: So, I'm thinking of writing the serializer module in js which should be compatible with "binary-parser" module Jun 02 10:04:39 jkridner: That way, I'd have to write packet headers once for both modules, unlike current approach which requires writing different packet headers for different modules for binary parsing and serialization Jun 02 10:05:21 jkridner: That should also make the code clean a lot Jun 02 10:06:51 jkridner: I'm currently understanding the working of the "binary-parser" module and will be writing the serializer module first this week Jun 02 10:07:56 jkridner: Here's the source of "binary-parser" module Jun 02 10:08:00 https://github.com/Keichi/binary-parser Jun 02 13:25:16 ravikp7[m]: from a style standpoint, I'd resist suggestions to extract a module member directly from the require line. Jun 02 13:29:16 jkridner: Working on porting BeagleLogic core to linux kernel 4.4 . If things go right, BeagleLogic should be up and running on 4.4 by next week. Jun 02 13:30:23 ravikp7[m]: you can get the ordering to work by making an array of objects, rather than simply a set of objects. Jun 02 13:30:57 ravikp7[m]: objects don't typically maintain member order Jun 02 13:31:21 Abhishek_: sweet! Jun 02 13:32:36 Suman Anna has been very helpful with my queries. Jun 02 13:33:08 jkridner: sorry, I could not understand the first point Jun 02 13:33:32 style standpoint thing Jun 02 13:33:46 ravikp7[m]: I'm working on a patch to show. Jun 02 13:34:07 jkridner: k, thanks! Jun 02 13:34:28 ravikp7[m]: right now, I'm struggling with the array size being encoded. Jun 02 13:35:38 ravikp7[m]: due to the available data types for schemapack, it might not be possible to remove the array size without defining things a bit more combersome. Jun 02 13:35:43 cumbersome even. Jun 02 13:36:32 jkridner: yeah, indeed Jun 02 13:43:27 ravikp7[m]: k, fixed that. Jun 02 13:43:43 ravikp7[m]: last issue... being able to specify network-byte order. Jun 02 13:43:59 ravikp7[m]: found it. Jun 02 13:44:38 oh, endian spec is only for strings. :( Jun 02 13:48:03 ravikp7[m]: hmmmm.... the Buffer seems to indicate it IS being encoded big endian (network byte order) already, but the manual parsing returns the wrong value. Jun 02 13:49:45 jkridner: manual parsing ? using "binary-parser" ? Jun 02 13:50:51 yeah, it is encoded as be Jun 02 13:51:30 ravikp7[m]: https://gist.github.com/jadonk/e3796e7373a1ce1ac5d441a642b4ea33 Jun 02 13:52:04 ravikp7[m]: so, the above fixes the encoding. Jun 02 13:52:11 ravikp7[m]: I'm not sure why the parsing isn't right. Jun 02 13:53:45 jkridner: checking it out Jun 02 13:55:11 ravikp7[m]: added package.json Jun 02 13:55:39 yes Jun 02 13:57:09 jkridner: there is an extra byte before the protocol id in buffer Jun 02 13:57:21 oh. Jun 02 13:58:19 I see the 03. :( Jun 02 13:58:27 don't know why it is there. Jun 02 13:58:40 hm, :( Jun 02 13:59:00 length of the outer object array? Jun 02 14:00:00 that seems to be a fit for 3, but it's position there doubts me Jun 02 14:00:12 ravikp7[m]: yeah, no idea why it is THERE. Jun 02 14:03:41 jkridner: now, I hack around with it a bit and try to figure out Jun 02 14:06:49 ravikp7[m]: hack work-around: https://gist.github.com/jadonk/e3796e7373a1ce1ac5d441a642b4ea33 Jun 02 14:07:54 ravikp7[m]: the critical part of the schemapack schema specification is that the end of an array can be repeated an indeterminate number of times per the protocol. Jun 02 14:08:31 ravikp7[m]: you can move the extra byte to the end by adding pad: https://gist.github.com/jadonk/e3796e7373a1ce1ac5d441a642b4ea33/revisions Jun 02 14:09:16 jkridner: oh, got it. Thank you Jun 02 21:02:21 hmmmm quiet Jun 02 21:11:59 So far everything is ok Jun 02 21:13:07 whole icestorm toolchain works on BB very well Jun 02 21:24:25 so we are well on our way to project skynet? :D Jun 02 21:26:45 I think we still can finish it before catastrophe Jun 02 21:56:41 :) Jun 02 21:58:47 Nerdboy, mdp, guess I should grab some time for another look at the ecap driver.... Hohum too much to do though IIO is fairly quiet this week so might have time for some tinkering :) Jun 02 21:59:22 Interesting to see how ecap proves useful.. Jun 02 22:00:03 Thanks for doing the forward port! Jun 02 22:05:17 should be in the kernel build queu and deb repos Jun 02 22:05:31 *queue even Jun 02 22:06:21 nerdboy: how is data going to get to the eCAP module? Jun 02 22:16:05 pmezydlo: did the board show up today? Jun 02 22:16:42 next GSoC project is self assembly of the FPGA boards ;) Jun 02 22:17:57 :) Jun 02 22:18:54 pmezydlo was having issues buying the components in Poland Jun 02 22:19:12 resistance to skynet? Jun 02 22:21:51 the LUT count in the ice40 is not high enough for sentience Jun 02 22:28:48 * nerdboy thought you were supposed to answer that shortly Jun 02 22:29:27 or at least how deep/flexible the board interfaces are... Jun 02 22:31:32 eh? Jun 02 22:31:37 it is an analog signal Jun 02 22:31:47 you need to either limit it or run it through a comparator Jun 02 22:32:01 otherwise, digitize it with the PRUDAQ and process the analog signal but you can't use ecap for that Jun 02 22:38:31 hence the reason I am confused as to the all the talk about ecap Jun 02 22:43:22 m_w: shipment status has changed, the board should arrive on monday, **** ENDING LOGGING AT Sat Jun 03 03:00:01 2017