Back
[12:45:38] <seb_kuzminsky> in master (and ja3), Axis' DRO and backplot-overlay are missing the Velocity display
[12:45:48] <seb_kuzminsky> View->Show Velocity has no effect
[12:46:33] <seb_kuzminsky> hm, many pf the View->Show Mumble things have no effect
[12:48:06] <seb_kuzminsky> View->Show DTG does not affect the DTG display, but View->Show Offsets turns DTG on/off along with the TLO, G92, etc
[13:37:24] <seb_kuzminsky> https://sourceforge.net/p/emc/bugs/335/
[14:45:47] <psha> mhaberler: heh, have you tested protobuf speed?
[14:46:05] <mhaberler> which one, c or py
[14:46:13] <psha> C
[14:46:15] <psha> C or C++
[14:46:29] <psha> seems that not much difference..
[14:47:14] <mhaberler> you have an issue?
[14:47:23] <psha> i have numbers that i don't trust
[14:47:26] <mhaberler> or curious?
[14:47:30] <mhaberler> show me
[14:47:58] <psha> sub ns encoding times...
[14:48:15] <mhaberler> I dont think pb will be an issue at all in this context, except for the non-native Py bindings
[14:48:20] <mhaberler> that is a bit fast
[14:48:20] <psha> 1.5ns for encoding of message with 20 submessages
[14:48:31] <mhaberler> wtf
[14:48:37] <psha> yep :]
[14:48:40] <psha> something wierd
[14:48:52] <psha> probably i've mistake somewhere and it caches everything
[14:49:02] <mhaberler> post your 'measuring code' please ;)
[14:49:21] <mhaberler> that could well be the case; do a message.Clear() to wipe tje curren Message
[14:49:59] <mhaberler> they do recommend to reuse the Message object and .Clear() it to reduce mem fragmentation
[14:50:19] <psha> for (int i = 0; i < count; i++) {
[14:50:19] <psha> buf.reserve(updates__get_packed_size(&update));
[14:50:19] <psha> update.updates[i % update.n_updates]->price = i;
[14:50:19] <psha> updates__pack(&update, buf.data());
[14:50:19] <psha> }
[14:50:57] <psha> buf.reserve is noop in 99% of cases
[14:51:16] <mhaberler> yes, that is cached on the instance object
[14:51:42] <mhaberler> look at the members (the nonexposed ones) you have a cached size, and a dirty flag
[14:51:46] <psha> so it encodes only one...
[14:51:50] <mhaberler> yes
[14:51:51] <psha> thx
[14:52:09] <mhaberler> what is the range of i
[14:52:28] <mhaberler> depending on i and encoding of i (fixed or varint) size could change
[14:52:38] <mhaberler> fixed would be faster and const size
[14:52:56] <psha> for (int j = 0; j < update.n_updates; j++)
[14:52:56] <psha> update.updates[j]->price += i;
[14:52:56] <psha> buf.reserve(updates__get_packed_size(&update));
[14:52:56] <psha> updates__pack(&update, buf.data());
[14:53:00] <psha> no luck :]
[14:53:02] <psha> 1.3ns
[14:53:27] <mhaberler> now what about the deserialized results, do these actually make sense?
[14:53:28] <psha> i < 1000000
[14:53:36] <psha> have not yet tried
[14:53:43] <mhaberler> varint or fixed32 for i
[14:53:47] <mhaberler> ah price
[14:53:54] <psha> varint
[14:54:12] <mhaberler> hm, that should change size then at least twice
[14:54:21] <psha> sint64_t
[14:54:23] <psha> to be exact
[14:54:29] <psha> yes, size increases
[14:54:31] <mhaberler> no the proto encoding
[14:54:46] <mhaberler> whats the field line in the .proto
[14:54:55] <mhaberler> thats a c tyüe
[14:54:56] <psha> sint64_t in proto file - varint with sign bit in lower one
[14:55:47] <mhaberler> sorry, sint64_t isnt a protobuf type, thats c type , I mean those;
https://developers.google.com/protocol-buffers/docs/proto#scalar
[14:56:21] <mhaberler> sfixed64 or sin64 - if it changes size I guess sint64
[14:56:22] <psha> sint64_t is not C type :)
[14:56:33] <psha> sint64 is protobuf, int64_t is C )
[14:56:41] <psha> sorry for confusion
[14:56:57] <mhaberler> ok.. but not pb either, its a type in the psha parallel universe ;)
[14:57:04] <mhaberler> sure
[14:57:49] <mhaberler> add a deserialsation step to the loop and assert results add up, but it is _very_ well optimzed
[14:58:15] <mhaberler> that looks a bit like protoc-c?
[14:58:42] <psha> yep
[14:58:45] <psha> that's exactly it
[14:59:04] <psha> i'm testing both
[14:59:06] <psha> C and C++
[14:59:26] <mhaberler> do you get similar timings with c++?
[15:00:06] <psha> yep
[15:00:10] <psha> similar tests
[15:00:18] <psha> looks like i've error in timing test
[15:00:26] <mhaberler> try some python to slow you down ;)
[15:01:07] <psha> :]
[15:01:40] <mhaberler> the optimizer might play games on you, she is in psha detection mode tonight
[15:02:12] <psha> looks like
[15:02:16] <mhaberler> dead code removal
[15:02:18] <psha> 3 digits lost somewhere...
[15:02:24] <psha> optimized timers...
[15:02:29] <mhaberler> ha
[15:02:45] <mhaberler> well now it's starting to make sense
[15:03:08] <mhaberler> 1,5uS, you mean per iteration?
[15:03:33] <psha> yep
[15:03:51] <mhaberler> sounds reasonable
[15:05:08] <psha> buggy gcc-4.7 in testing
[15:07:02] <psha> Serialize: 1.318us/m
[15:07:02] <psha> Deserialize: 2.355us/m
[15:07:06] <psha> looks better
[15:08:37] <mhaberler> yes, makes sense
[15:09:34] <mhaberler> btw.. since you're mr bleeding edge..
https://github.com/kentonv/capnproto
[15:09:49] <mhaberler> is this phun or for work?
[15:10:25] <psha> investigating if we could use protobuf in our work
[15:10:36] <mhaberler> then forget that link for now
[15:11:08] <psha> hm, reads like a bs
[15:11:47] <mhaberler> that was the key guy in google behind lots of protobuf, knows what he's doing ; but that is very early
[15:11:52] <psha> however author is kenton varda
[15:11:54] <mhaberler> tweak your .proto
[15:11:55] <psha> yep
[15:12:04] <mhaberler> use fixed size scalars
[15:12:11] <psha> nonono :)
[15:12:18] <mhaberler> c'mon
[15:12:19] <psha> i wanna times
[15:12:23] <psha> not for fixed
[15:12:25] <psha> but for varints
[15:12:27] <psha> and tags
[15:12:47] <mhaberler> tag..
[15:13:19] <psha> btw thanks for capnpn
[15:13:32] <mhaberler> sure
[15:13:39] <mhaberler> found anything faster?
[15:13:57] <psha> we are using something like it
[15:13:58] <psha> here
[15:14:16] <psha> but i hate it :(
[15:14:22] <mhaberler> I see
[15:14:28] <psha> however i've written it myself :]
[15:14:44] <mhaberler> well then I dont have to read it to agree ;)
[15:15:21] <psha> it's working ok but all such schemes (like in capnp - no encoding/decoding) have serious issues with forward/backward compatiblility
[15:17:17] <mhaberler> btw used your json deserializer + websockets sever, works just fine, not surprises (just example log subscriber)
[15:17:26] <psha> glad to hear
[15:17:32] <mhaberler> that was a pretty sharp idea
[15:20:24] <mhaberler> are you using any RPC?
[15:21:58] <psha> not yet
[15:22:14] <psha> and probably not at all :]
[15:22:25] <psha> zmq for quickstart purposes
[15:22:35] <psha> should be replaced later
[15:22:52] <mhaberler> by the service/rpc scheme in pb?
[15:23:10] <mhaberler> or different stack?
[15:26:28] <psha> we are not using pb now
[15:26:41] <psha> something like capnp
[15:26:43] <mhaberler> aja
[15:26:49] <psha> but inhouse
[15:27:01] <mhaberler> you guys got too much time ;)
[15:27:42] <psha> hm, that's was done in two months :) full transport, encoding
[15:27:57] <psha> and lot of small goodies on top
[15:27:59] <mhaberler> idl or manual?
[15:28:37] <psha> encoding = ~capnp - machine readable description of structs, generator code, reflections. etc
[15:28:46] <psha> python/c/c++
[15:29:03] <mhaberler> and you consider switching to pb?
[15:31:28] <psha> at least for some parts
[15:32:41] <mhaberler> well makes sense, outsource support and some new features over time; over here there is a glaring example of an 'in-house middleware stack' collecting cobwebs
[15:36:13] <psha> yep
[15:44:26] <psha> capnp uses smart idea - instead of encoding/decoding message just intersperse it with tag data
[15:44:37] <psha> and thus you'll get 'serialization' for free.
[15:44:38] <psha> ..
[15:45:00] <psha> only thing is packed Bool bits and pointers that should be changed from offset to absolute
[15:45:44] <mhaberler> not sure what free serialisation means in a bigendian vs littleendian comms
[15:45:57] <mhaberler> he must have a common wire format for that to work
[15:47:21] <mhaberler> actually there was a german fellow over on zmq-dev who wrote his own serializers/deserialisers to work within pb framework; let me see if I can find that
[15:48:21] <psha> littleendian
[15:48:56] <psha> seems that big endian is not that popular nowdays
[15:50:41] <mhaberler> but he does wire2host if bigendian, I assume?
[15:52:46] <mhaberler> you have mail; see 'transenc'
[15:53:02] <mhaberler> not sure if it's any good
[15:53:26] <mhaberler> I guess it's extending your JSON stunt to wireformat
[15:54:10] <psha> thx
[16:05:38] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll 4a90d28 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10abs_encoder.c 10hm2_dpll.c 10hostmot2.h
[16:05:38] <KGB-linuxcnc> Correct prescale calcs.Prescale set automoatically (commented out for testing)
[16:05:38] <KGB-linuxcnc> Error now a float.
[16:05:38] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[16:34:42] <psha> mhaberler: heh, kenton has his own library of goodies in capnpn (c++/src/kj)
[16:35:04] <psha> and it's fun to see maybe<T> there - type that i have in my own C++ goodies lib :)
[16:35:55] <mhaberler> and what's worth looking at there?
[16:37:03] <psha> don't know yet
[16:37:10] <psha> just reading through code
[16:37:19] <mhaberler> aha, mining today, hm
[16:37:22] <psha> looks like he's got freedom to write what he want and...
[16:38:18] <psha> compiler requirements are high :) gcc >= 4.7 and clang >= 3.2
[16:39:39] <mhaberler> Am I supposed to understand this, or can you summarize for me ;-?
[16:40:18] <psha> too much C++ features per line of code
[16:40:28] <psha> C++11
[16:40:54] <psha> so older compilers found on older systems (debian/squeeze / centos / rhel / ...) are out of boat
[16:44:57] <psha> bb, night here
[16:50:05] <mhaberler> cu!
[17:25:33] <KGB-linuxcnc> 03TODO: deletor 05zmq-submit-task.commands b62cdfe 06linuxcnc 04. * branch deleted
[17:25:45] <mhaberler> oops. sorry
[17:26:15] <KGB-linuxcnc> 03TODO: deletor 05zmq-submit-task.commands b62cdfe 06linuxcnc 04. * branch deleted
[17:26:35] <linuxcnc-build> build #1397 of lucid-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1397 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:35] <linuxcnc-build> build #480 of precise-amd64-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/480 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:37] <linuxcnc-build> build #506 of precise-x86-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/506 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:38] <linuxcnc-build> build #1195 of precise-amd64-sim-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1195 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:38] <linuxcnc-build> build #480 of precise-amd64-xenomai-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/480 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:38] <linuxcnc-build> build #601 of precise-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/601 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:40] <linuxcnc-build> build #496 of precise-x86-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/496 blamelist: Michael Haberler <git@mah.priv.at>
[17:26:40] <linuxcnc-build> build #1396 of lucid-rtai-i386-clang is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1396 blamelist: Michael Haberler <git@mah.priv.at>
[17:28:46] <linuxcnc-build> build #1398 of precise-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1398 blamelist: Michael Haberler <git@mah.priv.at>
[17:32:58] <linuxcnc-build> build #1400 of precise-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1400 blamelist: Michael Haberler <git@mah.priv.at>
[17:40:03] <linuxcnc-build> build #1401 of hardy-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1401 blamelist: Michael Haberler <git@mah.priv.at>
[17:42:52] <linuxcnc-build> build #1399 of hardy-i386-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1399 blamelist: Michael Haberler <git@mah.priv.at>
[17:43:34] <linuxcnc-build> build #1396 of hardy-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1396 blamelist: Michael Haberler <git@mah.priv.at>
[17:49:24] <linuxcnc-build> build #1400 of lucid-i386-realtime-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1400 blamelist: Michael Haberler <git@mah.priv.at>
[17:49:36] <linuxcnc-build> build #1399 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1399 blamelist: Michael Haberler <git@mah.priv.at>
[17:49:36] <linuxcnc-build> build #1394 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1394 blamelist: Michael Haberler <git@mah.priv.at>
[18:12:37] <alex_joni> hi guys
[18:14:43] <micges> hi