31–40 of 49 posts
I'm one of the authors of BITS, and the presenter of the PyCon presentation this article discusses. Happy to answer any questions here.
[1] I'm using networking as an example package, not knowing what other semi-optional packages could be used as an example.
Earlier quoted context omitted.
The context is that Lua has "several other impedance mismatches" beyond Python, not that Python-the-language is like C. Note that Lua also does not have a switch statement: http://lua-users.org/wiki/SwitchStatement .
I made no mention of Lua. The context is C and assembly programmers as an audience. But let's consider Lua. Most of the Lua pogrammers I know also know C. How do they handle the so-called "impedence mismatches"? (Should this be plural? What else besides 1-based arrays?) As far as I know Lua's target audience is, at least in part, C programmers. That's why it's made to be easy to embed in a C program.
You can't simply pull a few words out of the comment and assume it means there is no mismatch what C programmers expect and what Python offers. It doesn't mean that and wasn't meant to mean that.
You wrote "Lua's target audience is, at least in part, C programmers". That is also true of CPython. Bear in mind that these facts aren't that relevant. This code is not mean for the wider class of "C programmers". The relevant bit is "the target audience writes assembly and C". This is far different than "the target audience is assembly and C programmers", which appears to be what you think it says.
Instead, the target audience is the narrower class of people writing EFI binaries and working with the EFI protocol. As JoshTriplett further clarified, the "existing development tools in that area already support Python", but apparently not in Lua.
Earlier quoted context omitted.
The context is that Lua has "several other impedance mismatches" beyond Python, not that Python-the-language is like C. Note that Lua also does not have a switch statement: http://lua-users.org/wiki/SwitchStatement .
I made no mention of Lua. The context is C and assembly programmers as an audience. But let's consider Lua. Most of the Lua pogrammers I know also know C. How do they handle the so-called "impedence mismatches"? (Should this be plural? What else besides 1-based arrays?) As far as I know Lua's target audience is, at least in part, C programmers. That's why it's made to be easy to embed in a C program.
Earlier quoted context omitted.
I made no mention of Lua. The context is C and assembly programmers as an audience. But let's consider Lua. Most of the Lua pogrammers I know also know C. How do they handle the so-called "impedence mismatches"? (Should this be plural? What else besides 1-based arrays?) As far as I know Lua's target audience is, at least in part, C programmers. That's why it's made to be easy to embed in a C program.
JoshTriplett's comment was a response to "why would they not use lua?" The points were all made relative to "C and assembly programmers" using Python vs. the same using Lua. You can't simply pull a few words out of the comment and assume it means there is no mismatch what C programmers expect and what Python offers. It doesn't mean that and wasn't meant to mean that. You wrote "Lua's target audience is, at least in p…
No problem. I get it.
How is this different from micropython?
Earlier quoted context omitted.
I am always interested to hear when a language is ported to a new plaform, in this case Python (or a subset of) on GRUB. The question would be why? Is this because you have lots of test cases already in Python and can easily deployed those test cases on using this?
Originally, it was because we had a lot of one-off test cases not written in Python. Before BITS, most BIOS test programs consisted of one-off DOS programs, or later one-off EFI programs. If you wanted a new test, or you wanted a customer to quickly gather some information for you, you sent them a new test program, or a bootable image. Now, many of those one-off tests have become Python one-liners, and you can use Py…
is BITS building for ARM ?
The biggest challenge would be adding equivalents of the assembly that implements SMP support (waking up other CPUs and putting them into a loop ready to run code on request).
I'm one of the authors of BITS, and the presenter of the PyCon presentation this article discusses. Happy to answer any questions here.
Could you envision a (G)UI toolkit written in Python that could be used to write applications that run in EFI?