From ntoll at ntoll.org Fri Nov 3 12:40:35 2017 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 3 Nov 2017 16:40:35 +0000 Subject: [Microbit-Python] micro:bit Mu/MicroPython questions In-Reply-To: References: Message-ID: <016c8fec-483f-8278-75bc-9c9835b2dae3@ntoll.org> Hi Matt, Comments in-line below. Apologies for the tardy response time, but PyCon UK has taken up most of my time in October. On 17/10/17 13:30, Matthew Jadud wrote: > Dear all, > > @ntoll suggested I post my thoughts to this list. They're on the long side. > No problem, more meat to chew. ;-) > For background, I'm taught introductory through advanced computer > science and electronics/embedded systems courses at the college level > since roughly 1999. For years, I contributed significantly to a small, > portable runtime for the concurrent/parallel language occam, which gave > us the ability to run 100+ concurrent processes on devices as small as > the ATmega328. It never quite took over the world, but I did learn the > joys of building a portable bytecode interpreter for multiple > architectures, and associated toolchain support. > Wow. Do you have a link for these resources? > There is much I do not know, and little that I know about Micro:Python > and it's ecosystem. What I have discovered from teaching with it this > term is that there are things I need/want in order to execute good > pedagogy. I'm happy to contribute my time to working on Mu and > associated tools to make these tools better for me (and others).? > We absolutely welcome contributions no matter how big or small they are. > At a high level, in terms of design and development, the "philosophy" > (in the README) doesn't get us down to enough detail to really have a > discussion. It is not possible to evaluate whether someone "understands" > an IDE. "Easy to use" is highly subjective, and also not easily > evaluated. Without personas that clearly indicate who the user is, and > testing with users representative of that user (or, feedback from > educators working with those users), these are spaces where we might > easily devolve into disagreement that is subjective and personal (and > grounded in the experience of experts) rather than grounded in a target > user's experience. For context, I lived/worked with members of the BlueJ > team for 5 years; I have more than passing experience/exposure to the > life of a pedagogic IDE in and out of the classroom. > Right... so bear in mind that Mu is a labour of love. The website was cobbled together in about 30 minutes on a train journey because it was what was needed *right then*. I tried to summarise the outlook Mu was promoting (based on Carrie Anne's keynote). The most important aspect of Mu is that it is a stepping stone. The Raspberry Pi Foundation explained they wanted the simplest possible editor from which students could quickly graduate to other avenues of coding. Most of Mu was originally created from feedback given by teachers who had used the browser based micro:bit Python editor. They wanted a flash button, they wanted easy access to the REPL and they wanted a very limited UI that covered only the basic operations needed for a functioning editor. Hence the Mu you see today. > I'm going to offer comments about what I know/think I need/want. I'll > number these for easier reference. > > --- > > 1. The ability to turn on/off style checking/linting.? > > There's an overwhelming number of distracting errors for a novice. My > students are beginning to ignore the arrows, and they've barely begun > programming. This is a problem, because some of those errors matter. > BlueJ (used to?) show one error at a time; DrRacket has language levels. > Mu throws an industrial-grade linter at the students on day one. It > needs to either be tunable, or able to be turned off. Right now, it's > causing students to rapidly begin ignoring errors... > This was a stop-gap and I agree with you. Remember, most of Mu was written during my 30 minute commute to London which probably explains the often quick and dirty solutions you'll find therein. My modus operandi has been to make *something* (anything!) and then be guided by the users. It's a straw man in code and allows me to make decisions on how to develop the feature based upon evidence from educators. You're not alone in criticising the code checker, since similar feedback came from other teachers. > 2. Projects vs. Files > > I need the ability for students to save a project of files vs a single > file. Think Arduino. Why? > Mu works this way simply because you used to only be able to flash your code onto the device as a single script (appended to the hex file copied onto the device). Since the addition of the filesystem (great work Mark Shannon!) it has been possible to work in the way you describe. However, this is usually considered a more advanced way to work since the target users (11yo kids) are generally writing the "conventional" single scripts. > 3. I need the ability to distribute starter projects. > > I would like to ship a piece of starter code for a project, with a > library of support code in a separate file. Asking students to reset > their micro:bit, upload using the "filesystem browser," (which is > buggy), make sure they get the right files... and then begin writing > their code is too complex for students on day one. > Carlos has been looking at how to embed a selection of files into the MicroPython hex. Pending the outcome of his work, it'll certainly be simpler than the jiggery-pokery you describe. > 4. Starter projects should be accessible through a project manager.? > > This might be akin to the library installation interface of the Arduino > environment, or how PXT does it. I'm OK if students have to paste a > Github URL into a dialog. In a perfect world, they can enter one URL at > the start of the term, and the repository is a "meta library," where all > future extensions/projects go. This way, I can say "install starter > project one," or "install starter project three," and they never have to > leave the course project library. Allowing multiple libraries/project > repositories (think apt) would be fine with me. > > I'm aware libraries and starter projects are different. This is a rather significant change in behaviour and you're the first to ask for it. I guess this depends upon the work Carlos is doing to embed files on the filesystem in the hex. How this should be exposed to the user is moot and requires further research. > > 5. Starter projects and libraries should both be installable. > > When ladyada produces a new library for the New Awesome Board of > Greatness, or even for an Existing Board of Greatness, or someone writes > a library for the micro:bit that I want my students to use, they should > be able to install it, and access it. Perhaps even with > > from new_library import * > > by making sure the? > > a) include path is correctly set, and? > b) the library is automatically transferred to their micro:bit. > Are you suggesting Mu should do some code analysis and work out, from the import statements, which modules should be included in the hex? This is non-trivial and, perhaps, something the user should manage themselves ("explicit is better than implicit" - the Zen of Python). > 6. The icons need to be smaller for some screens.? > > They're huge, take up too much real estate (eg. when the REPL is open), > and I worry that they're not accessible to screen readers. Hopefully > they're standard widgets. This might just be a personal thing, but I > have some students with lower-res devices, and code + REPL eat a lot of > vertical space. > In the new version, Mu is "responsive" like websites ought to be. The icons change size as Mu grows and shrinks. The zoom buttons change the font size which is also probably useful in this instance. > 7. microfs does not work well when an error is showing. > > I've been experimenting with microfs; it seems to hang when a syntax > error is crawling its way across the micro:bit. This is painful. Perhaps > this means microfs is better replaced with pyOCD, or similar, or perhaps > the runtime for micro:python needs to be changed. > > I might be doing something wrong here. This is from my (quick) > experience of throwing together a tool or two of my own that wrap > microfs/uflash, so I could be Doing Something Wrong. So microfs uses USB/serial and the REPL to list, put, get and delete files. If there's an error scrolling, the REPL blocks until it has finished. Hence the problems you've encountered. Perhaps the simplest fix would be for the text to scroll with the equivalent of the wait=False flag. You can suggest this via an issue here: https://github.com/bbcmicrobit/micropython > > 8. I wouldn't mind a simulation API.? > > But, that's in the "I want a pony" category. I'm thinking PXT and it's > simulator... but, the API piece is so that the Circuit Express can be > added along side the micro:bit, along side The Next New Awesome Python > Board, along side... > Yup, that's definitely in the "I want a pony" category. ;-) However, various people (Grok Learning, for instance, some of whom are on this list) are working on this problem and we may be able to re-use their work. > 9. Project sharing/submission. > > Think Scratch/etc. However, this comes later. An infrastructure for > projects, however, and integration with git, get the mechanisms in place > for this kind of code-based-sharing-community-building. > I believe this beyond the scope of Mu since it would require the support of infrastructure and/or third party tools. Put simply, Mu is created by volunteers and I don't think we have the bandwidth to support this. Also, each educator is likely to have unique constraints and requirements in this respect, so, at best, we'd be bodging a solution that never quite worked right for all users. ;-) > 10. Extensions API. > > Well, if we're strapping fake horns onto the pony, we might as well > solve half (or more) of these problems by exposing the core editor and > its functionality through an extensions API, so you can say "Do what you > want: here's the API. Have a blast." This created a vibrant ecosystem > for BlueJ, enabled a good bit of research on learners using it as well. > Funny you should mention that... In the next version of Mu there are several "modes", one of which is the original micro:bit related functionality (the others are for Circuit Python and "regular" Python 3 [including a simple visual debugger]). This afternoon's work was to be documenting how to write new modes. But I answered this email instead. ;-) You certainly can't change *everything* about Mu in a mode. In fact, you're rather constrained. But that's on purpose. Mu is opinionated about what a mode should be, which makes them simple to write. This is intentional since writing a new mode could be something a competent school teacher or advanced student might do as a project. Developer documentation is (slowly) appearing here: https://mu.readthedocs.io/en/latest/ > --- > > Those are a few thoughts from a few weeks of teaching with these tools. > In part, I want some of the library functionality because I don't like > the MicroPython API. I won't expand on the pedagogic reasons extensively > (this is long already), but I really want a transition from PXT to > Python (or, just be able to control the introduction of concepts), and > to do so, I want a functional interface that hides the objects. I can do > that if I can wrap the existing API. > OK... so we'll have to agree to disagree here. Please bear in mind that a *lot* of thought and plenty of input from educators went into the design of the MicroPython API. You may also want to investigate the EduBlocks project. The maintainer (Josh) tells me a micro:bit mode is coming soon. > Shiffman's "Learning Processing" does an excellent job of providing a > pedagogically ordered introduction to Java(esque) in his text, by > introducing one new concept at a time. That's impossible with the > micro:bit as MicroPython is currently organized. > > from microbit import * > > while True: > ? sleep (1000) > ? display.scroll("Hi") > ? sleep (1000)? > ? display.show(Image.HAPPY) > > introduces concepts of: > > * library import > * looping > * booleans > * function calls > * objects > * object methods > * object static members > Right, but such examples also depend upon the nous and skill of the teacher to introduce things in such a way that makes sense. In my experience as a teacher, it's the *teacher* and their interaction with students that is perhaps the most fundamental aspect of the learning situation. While the tools (such as Mu or MicroPython) help, they are always going to be a compromise for teachers, unless you create everything bespoke for your lessons. For example, I personally wouldn't start with such an example. Put simply, there are plenty of ways to introduce each of the concepts you list in a gradual way using the existing Python API. I completely respect your desire to use a functional style - I'm a firm believer in letting many flowers bloom - but we had to do *something* and, in this instance, it's not what you may perhaps have done when it comes to API design. > The benefit of Arduino's setup()/loop() is that they're both functions, > they have clear meaning, and the student never has to modify them for > many of their introductory experiences. Granted, there's syntactic > wrapping that happens around them, but it makes sense, and provides a > clear foundation for every program a student writes. I'd like to be able > to hide some of these things, so when I introduce objects, it's > intentional, and does not involve telling students lies, or glossing > over details. The above code could become > > while True: > ? show_string ("Hi") > ? sleep (1000) > ? show_image(HAPPY) > ? sleep (1000) > > although, that's debateable: HAPPY becomes a "magic variable". That > might be OK. It might not. But, if I'm able to have them import a > library/tool/mode that automatically imports my library of? > > from makecode import * > > in the background, then I can deal with that in my own way (and other > educators can choose to deal with it in theirs). > Sure, the last thing *we* want to do is limit your options as an educator. Just remember, when we built the API we wanted it to be obvious, simple AND a reflection of "Pythonic". > --- > > This got long.? > Good... we welcome feedback. :-) Just remember we're a community of volunteers working on this stuff in our spare time. Things may not get fixed quickly and it may take time for people to respond. That's just the nature of a project run by volunteers. > @ntoll suggested I post my thoughts to this list. I would be happy to > contribute to the community. That is, if there's space to develop a > roadmap for Mu, in conjunction with others, that starts moving towards a > teaching environment that supports pedagogically motivated modes of > interactions with code and hardware. I have taught with hardware for the > past 5 years, and really enjoy it. I like teaching with Python, and > think the micro:bit/Circuit Express/etc. are great platforms for > students to learn with. > Absolutely, please feel welcome! I guess you've seen the work on the new version of Mu? If not, take a look around. Best wishes, Nicholas. > Yours, > Matt > > -- > Matt Jadud > Pronouns: he/him/his > Associate Professor of Digital and Computational Studies (Chair) > Bates College > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From mjadud at bates.edu Fri Nov 3 14:19:16 2017 From: mjadud at bates.edu (Matthew Jadud) Date: Fri, 3 Nov 2017 14:19:16 -0400 Subject: [Microbit-Python] micro:bit Mu/MicroPython questions In-Reply-To: <016c8fec-483f-8278-75bc-9c9835b2dae3@ntoll.org> References: <016c8fec-483f-8278-75bc-9c9835b2dae3@ntoll.org> Message-ID: On Fri, Nov 3, 2017 at 12:40 PM, Nicholas H.Tollervey wrote: > Hi Matt, > > Comments in-line below. Apologies for the tardy response time, but PyCon > UK has taken up most of my time in October. > > Understood. I can appreciate logistics and organization as things that take up time. I'll just reply briefly to one or two things, and then a bit more when I have a chance to research some of the pieces. Thank you for your thoughtful and detailed reply. > On 17/10/17 13:30, Matthew Jadud wrote: > > > > portable runtime for the concurrent/parallel language occam, which gave > > us the ability to run 100+ concurrent processes on devices as small as > > the ATmega328. It never quite took over the world, but I did learn the > > > Wow. Do you have a link for these resources? > http://transterpreter.org/ http://concurrency.cc/ https://github.com/concurrency I had to pull the cloud-based compiler down a while ago, and have not brought it back up. The code... well, I wouldn't say it is "bitrotted," because it is such straight-forward ANSI C. But, I wouldn't try and teach a course with it in the current state. I'm in a space where I'm wondering how best to move forward with the intellectual work from this project. I hate to see it die. But that's neither here nor there. > Right... so bear in mind that Mu is a labour of love. The website was > cobbled together in about 30 minutes on a train journey because it was > This I understand fully; see links above. I've been there, in various ways, at various points. This helps me understand a great deal more than it might seem. > The most important aspect of Mu is that it is a stepping stone. The > Raspberry Pi Foundation explained they wanted the simplest possible > editor from which students could quickly graduate to other avenues of > coding. > This, too, helps. It might be that Mu is never the editor I want it to be. Or, perhaps, it is. I actually don't want complexity; I want just enough flexibility that I'm not locked into someone else's pedagogic approach simply because of the tool. But, hammers are hammers and screwdrivers are screwdrivers. Tools matter. And, it might be that I either need to adjust my approach to fit the tool, or acknowledge that the tool might have other purposes. Point being, I understand. A few quick responses. I have to go to class shortly. > Mu works this way simply because you used to only be able to flash your > code onto the device as a single script (appended to the hex file copied > onto the device). > > Since the addition of the filesystem (great work Mark Shannon!) it has > been possible to work in the way you describe. However, this is usually > considered a more advanced way to work since the target users (11yo > kids) are generally writing the "conventional" single scripts. > Agreed, but adults, and sometimes teachers, are supporting that learning. Hence, being able to say "here's a starting point," and provide wrappers that provide stepping-stones to a learning outcome can sometimes be critical. I agree that this feature does not seem useful to the 11-year-old at first glance, but it is an example of something that might be critical to the educators/community members/etc. supporting them. > Carlos has been looking at how to embed a selection of files into the > MicroPython hex. Pending the outcome of his work, it'll certainly be > simpler than the jiggery-pokery you describe. > Groovy. Sounds like a place that, if there's a starting point/documentation/code to point me at, I might be able to contribute meaningfully. > > > 4. Starter projects should be accessible through a project manager. > > > > I'm aware libraries and starter projects are different. > > This is a rather significant change in behaviour and you're the first to > ask for it. > Agreed. If it ever were possible, it's down the road. And, easily developed (possibly) as an extension, if extensions are ever a thing. > 7. microfs does not work well when an error is showing. > > So microfs uses USB/serial and the REPL to list, put, get and delete > files. If there's an error scrolling, the REPL blocks until it has > finished. Hence the problems you've encountered. > > Perhaps the simplest fix would be for the text to scroll with the > equivalent of the wait=False flag. You can suggest this via an issue here: > > https://github.com/bbcmicrobit/micropython I can also get a build environment set up, and explore this before suggesting the issue. I have the ability to take the next step, which is to get it building, test it, and offer a pull request. > > 10. Extensions API. > > > Funny you should mention that... > > In the next version of Mu there are several "modes", one of which is the > original micro:bit related functionality (the others are for Circuit > Python and "regular" Python 3 [including a simple visual debugger]). > This afternoon's work was to be documenting how to write new modes. But > I answered this email instead. ;-) > > You certainly can't change *everything* about Mu in a mode. In fact, > you're rather constrained. But that's on purpose. Mu is opinionated > about what a mode should be, which makes them simple to write. This is > intentional since writing a new mode could be something a competent > school teacher or advanced student might do as a project. > > Yep. It might well be a good path forward for me, for some/all of what I'd like to be able to do. Or, it might be some of the comments/suggestions I've made (less in the "pony" category, and more in the "how do I provide stepping-stones" category) might be useful as design targets/considerations/debate points as to what a Mode can or can not do. > Developer documentation is (slowly) appearing here: > > https://mu.readthedocs.io/en/latest/ In BlueJ, there's a rich extensions API; more than you want, probably. https://www.bluej.org/doc/extensionsAPI/ It's a pedagogic environment used by millions. It's been extended by many educators, and some of those extensions have enabled a great many interesting things... without taxing or damaging the "core" principles of the environment itself. That is, BlueJ remains highly opinionated in its implementation, but provides you tools to extend and modify as suits. Disclosure: that extensions API enabled my dissertation work. Other extensions have been used by many tens to hundreds of thousands of students. It's an incredibly powerful and important part of the BlueJ environment. > > Those are a few thoughts from a few weeks of teaching with these tools. > > In part, I want some of the library functionality because I don't like > > the MicroPython API. > > > > OK... so we'll have to agree to disagree here. Please bear in mind that > a *lot* of thought and plenty of input from educators went into the > design of the MicroPython API. > Indeed. If you point me to where these discussions took place, I can better understand where the tools are now, and why they are the way they are, and in doing so, take up less of your time. > Right, but such examples also depend upon the nous and skill of the > teacher to introduce things in such a way that makes sense. In my > experience as a teacher, it's the *teacher* and their interaction with > Which is my point exactly. I'm looking for ways to support more pedagogic approaches. I'm glad you wouldn't start there... but, you and I are different educators. For example, I personally wouldn't start with such an example. Put > simply, there are plenty of ways to introduce each of the concepts you > list in a gradual way using the existing Python API. I completely > respect your desire to use a functional style - I'm a firm believer in > I'm wondering if there's a design space (as described above) where it becomes *possible*, using these tools, to teach differently than the tool imposes. By not having a mechanism to easily include a library, it suggests that Mu does *not* respect other ways of doing. Only if your library is directly part of the MicroPython project is it the case that it is a "first class citizen" in the Mu/MicroPython universe. Hence, my question isn't "can we rewrite MicroPython," or "can I get my library into the MicroPython build," but instead "is it possible for me to easily hide parts of MicroPython, using an import statement, and have Mu know that the library should be imported." A projects-vs.-files approach, with an invisible ".project" file that specifies what libraries should be bundled/included in the .hex file, is an example of one way to solve such a problem. But, if the principle is that "all MicroPython programs in Mu are ALWAYS single files," then there's no point in debating or discussing: Mu will never be able to support what I want to do, and I should either 1) fork, or 2) write my own. I suppose I could build a custom MicroPython, replace it for Mu, and solve some of my problem that way... which, sounds awfully painful, and lacks flexibility. Just remember we're a community of volunteers working on this stuff in > our spare time. Things may not get fixed quickly and it may take time > for people to respond. That's just the nature of a project run by > volunteers. > Yep. And, if it is valuable (and scratches an itch I have), I'll do my best to become one of those volunteers. You can gauge best. It's OK if your recommendation is that my time is best spent elsewhere. If you think that I can contribute to Modes/extensions, or to thinking about (and/or implementing) a project-based approach to managing work vs. a file-centric approach, or supporting the work on injecting additional hex into the .hex bundle... then, yes. But, if you think that, fundamentally, my goals simply don't align, then do feel free to suggest as much. I'm being honest, and am neither frustrated nor upset. If you said "Matt, I think we're heading in a different direction," then that is good! Your time is valuable, and you don't want to spend it debating philosophies and instructional approaches with me. There's work to do! Many thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Fri Nov 3 16:20:24 2017 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 3 Nov 2017 20:20:24 +0000 Subject: [Microbit-Python] micro:bit Mu/MicroPython questions In-Reply-To: References: <016c8fec-483f-8278-75bc-9c9835b2dae3@ntoll.org> Message-ID: <4a87fe22-5aee-4c3d-679f-65a7885ec64f@ntoll.org> On 03/11/17 18:19, Matthew Jadud wrote: > I'm being honest, and am neither frustrated nor upset. If you said > "Matt, I think we're heading in a different direction," then that is > good! Your time is valuable, and you don't want to spend it debating > philosophies and instructional approaches with me. There's work to do! My background is as a senior (classically trained music) teacher working with teenagers in inner city schools. I also have an MA in Philosophy of Education from London University's Institute of Education (https://www.ucl.ac.uk/ioe/about), so *I MOST CERTAINLY WANT TO SPEND TIME DEBATING* philosophy and approaches with you. ;-) A more full reply forthcoming probably after the weekend. Best wishes, N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: