On 25/03/2017 11:46, Michael Richardson wrote: > > Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > It doesn't deal well with flexible types either, a dangerous luxury in > > Python that I've got very fond of. But it seems to me that if a GRASP > > core implementation is written in C for efficiency, it will *need* to > > offer an API in C that higher level languages can build on. > > No, because it will be monolithic: not part of a library, no sockets API, etc.
It can't be monolithic in a general-purpose device with a variety of ASAs sharing a discovery cache, flood cache, etc. Well, I'll show you my code later today if you like. (I will get to the hackathon at a time that depends on service on the Red Line train...). > > BTW, my not-production-quality Python version of the GRASP core is now > > about 1800 lines of code, but if we take out the stuff for diagnostics > > and debugging there's maybe 1000 lines. I hope we'll find out in the > > hackathon how big the BUPT code is; so far they don't support an API, > > so they are on your model. > > My understanding is that uPython is getting significant traction in some > constrained environments: someone may want to rewrite your code to this > very limited subset (less than python 2, I'm told). I think that this is > more likely to be a "library" than any C code. I know nothing about uPython. I did look at downgrading my code to Python 2 but quickly gave up because, well, Python 3 is better. So it all depends on what they've kept and what they've removed in uPython. Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
