dbyte

Why?

The grandfather of protobuf. Lost in the tales of time.

I understand the overall feeling but I’m not sure I understand the specific reason why you say this is making code bases more terse. Are you comparing this with the alternative of using GCC specific extensions or no definition of likely/unlikely code paths at all?

Congrats

Raymond, thank you for your great work. All your contributions and talks have been inspiration for many.

I am sure Python community has much to gain having this arguments then just blindly follow any trend.

Massimo this is great. LoRa client support and maybe also an Arduino LoRa Gateway it will be amazing for rolling out nodes in agriculture. These areas are often not served by existing networks so a DIY-solution will always have its spot.

Amazing work. If you take a look at latex please consider also XeTeX for its beautiful font support. It can give a lot of satisfaction when packaging good content. Microtype is also nice if one sticks to pdflatex.

Great work. Thanks. Do you have a roadmap for the future?

Really an amazing job. Keep feeding your curiosity, it is really worth it and try to travel a bit while explaining your project. Array processing is something that deserves a better look. Many SDR solutions still lack a bit under this point of view. Yet that will be quite useful to have. :)

Even this paragraph is just a general description of what could potentially be a FEM analysis and some optimisation algorithm associated with that. Interesting result on the other hand.

Yes I agree with you but you are point out the existance of low weight packages while I would say that cost is a more important constraint for drones. I guess users can argue with the idea of equipping their low-cost drone with an expensive certified ADS-B receiver. It won't be as cost effective as one may think.

Also one has to consider that the mode S transponder is using a 24bit identifier. While this has a lot of sense for modern civil aviation (there are not as many planes) the same cannot be guaranteed as soon as you have many more temporary users of your airspace (e.g. swarms of Amazon delivery drones). IMHO regulators should aim first to create an effective solution that works well for drones (e.g. allowing ATC to broadcast digital commands to guide drones if necessary, btw there is a similar effort already for commercial planes) and then find a smart way to integrate commercial and drone aviation systems.

Btw really nice product!

What we really miss is an ADS-B low-cost variant for drones. Safety requirements are different if ones takes into account the unmanned characteristic of drones. Furthermore it will be a great exercise in solving the known problems with the existing version. The main idea of broadcasting navigation data is worth the shot to optimise even more the use of airspace. Without lives at risk technical iteration can be, at least in theory, faster. We need more IETF-style drafts and RFCs rather than classic standards (i.e that require often more than 10 years to reach the market) to see a clever use of such a technology in our daily-routine.

This is pure marketing-driven engineering. Not a bad thing per-se but they should start considering also a more pragmatic approach. They should pick a form-factor that can be future-proofed and avoid changing their mind every iteration. Current NUC form factor is too small for high TDP cpu, because of cooling, and instead of adjusting the current form-factor (e.g. expanding its width) they created another (maybe pointless) design. Advice to management start considering also the medium-term landscape. I will be more than happy to replace my NUCs is you give me consistency. If in doubt ask Apple.

Yes, this is a must. I wonder if industrial greenhouses could benefit from some sort of induced day-night cycles and thermal gradients to cuddle the little plants. Maybe it will allow them to grow better and to develop a better taste. Once you have LEDs possibilities are many.

Thanks for working on this. Really a great effort. Hope your guys can get good inspiration from projects like h5df, bcolz, pytables having the option of incrementally adding features and maintaining an open spec.

Definitely Markdown, then one can always convert back and forth other formats (e.g. using Pandoc).

The product is sweet. Enjoyed the UI/UX. However I think the landing page needs a little bit more love (pricing, team, contacts, use case, features lists) what about importing from existing Wikis or plain documentation text files (e.g. markdown, asciidoc)?

Reason is quite simple. EPS is based on PostScript. PDF specification contains a subset of PostScript. Embedding EPS into PDF is trivial and yields high quality results. For a printing publication workflow having EPS files at hand saves a lot of time and problems.

SVG is nice too, just needs few more intermediate steps.

For their website:

  mpmath internally uses Python's builtin long integers by default, but automatically switches to GMP/MPIR for much faster high-precision arithmetic if gmpy is installed or if mpmath is imported from within Sage.

With gmpy you rely on C libraries. Faster but those are still arbitrary precision computionations.

auto with lambdas can be quite dangerous if you are adding different types inside their bodies. Type promotion rules should be well understood. During code reviews we spotted several overflow bugs when using ints because the dev were thinking auto as a sort of very powerful resource.

Explicit casting if often required to make sure subtle bugs won't show up in production.

Working on SVG? What about EPS instead? For scientific publishing EPS is much better unless your visualisation is pretty much an high entropy one.

this is great work kidzik. looking forward to see more about it. hi-res are quite good, that even if in the uncanny they can be quite a success for deepart lovers.

How does this compare with what Google[x] has been developing in the RF gesture recognition? In the videos they are using a Leap Motion while G is "suggesting" using your fingers as support.

Well, it won't take much to have tools like Numba (http://numba.pydata.org/) taking advantage of such "type info" during optimization phase. On the other hand IDEs are already taking advance of those (see PyCharm).

And by the way the future looks bright as interesting PEPs are coming: PEP509, PEP510 (https://www.python.org/dev/peps/pep-0510/) and PEP511 for instance.

It is a famous idiom, hence the pun: https://en.wiktionary.org/wiki/all_roads_lead_to_Rome

Wow, I was looking forward to see what other acronym people can think of in the Software-Defined-Something family (SDx).

I'm wondering if other BMS (Battery Management Systems) used in other domains are not already doing what they propose in the paper.