I find it interesting that MicroPython's `re` module[0] is implemented with a backtracking regular expression engine from re1.5[1], instead of one of the linear-time engines from the same library. (Russ Cox covers the various engines in the excellent blog series[2] which re1 is a companion to.) I figure the choice was made due to binary size or memory constraints, though they're all quite small.
so alternatives to provide additional features have been discussed... Either extending the existing module or swapping to a more feature-rich library. Possibly even doing so for larger micros that can afford the additional flash/memory, though that makes support more challenging.
I was talking about the performance, not the feature set. Russ Cox's re1 and the re1.5 fork have several engines for different implementation strategies. re1 was written for primarily pedagogical reasons, so its minimality comes from that.
The engine chosen by MicroPython is vulnerable to catastrophic backtracking and switching to the Pike VM implementation would fix that. Instead of backtracking in the text when the pattern doesn't match, the Pike VM iterates each char in the text only once, visiting the states valid for that position in lock step. Consequently, it allocates a list of “thread”s, proportional in length to the number of states in the pattern (though usually patterns have relatively few states). Many security issues have resulted from regexp denials of service, so this slight memory tradeoff might be worthwhile.
Since recursiveloop.c has been changed by MicroPython, those changes would need to be ported to pike.c. The fixes are small and none of the extra features exploit the backtracking, so this should be easy.
Yes, with the PiDP-10 we did a huge injection mold and it nearly killed us. Well, no, but we still have not recovered the investment. And it became an expensive thing, which limits the amount of people who want to play with one.
So with the PiDP-1, we figured out how to make the entire case from FR4 panels. As there are no Iconic Curves in a PDP-1 case. Turns out this is the sturdiest PiDP yet!
We hope to get some interest from the democoder community. Writing games and demos for the PDP-1's Type 30 display is so much more fun than pushing pixels on a C64 :-)
Someone had a PiDP-10 set up at the last Hacker's Conference. Damn it's a gorgeous machine. Your heroic efforts to recreate it in such spectacular fidelity are greatly appreciated by many!
Can't wait to see the PiDP-1! By the way, something I'm really looking forward to is the KA-10 FPGA implementation for the PiDP-10, rather than the less realistic SIMH simulator running on top of Linux/Raspberry Pi. It would be a true miniaturized PDP-10 CPU, not just a simulation. Do you know if this is still being worked on?
I have a bunch of KA10 verilog that worked on a DE10-nano in the past, but it's been quite a while and i think i have a bunch of uncommitted stuff lying around as well. The verilog is based on the original schematics and I successfully ran LISP and Spacewar on it. Unfortunately simulating peripherals is always a pain, so the project currently lies dormant. But i'd like to pick it up again at some point. I just really need to rethink my approach how to do this, qsys was maybe not the greatest way to wire up the system.
It’s exciting to hear that you’ve successfully run LISP and Spacewar on it, especially since the Verilog is based on the original schematics. That makes the PiDP-10 an actual KA-10 CPU, which is a big deal for authenticity.
I completely understand the difficulty with simulating peripherals. Perhaps the FPGA could focus on implementing the CPU, leaving the peripherals to a SIMH backend using a hybrid approach. A slightly longer PCB with space for both a DE10-nano and an RPi 0 might work out well.
Have you considered opening a discussion on VCFED or Google Groups to gather more ideas and see what others think? I’m sure many people would be excited to follow and contribute to that progress.
I hadn't connected it to the pidp-10 panel yet actually, my stuff is older than that. but eventually i would like to. the approach i went with was to put some of the peripherals on the linux side of things but have the controller logic on the FPGA. it's all a bit fiddly with FPGAs...
Thanks for sharing the link. Had no clue. Funny how things came about to be; who would've known that salmon wasn't part of the foundational sushi dishes until this occurred.
txtar is used in the testsuite package to make writing CLI (blackbox) tests really easy. It adds a header section for the steps to run and comparisons to make. Often you compare actual output with golden data.
The tools have been extracted and made installable from here: https://github.com/rogpeppe/go-internal/tree/master/cmd
This is really handy for any project to have people submit reproducers as a single file anyone can run. These tools make it so you can transform between txtar and files on disk, and then run the txtar (testscript) as a test or directory of tests.
I have built them into my hof tool, "hof run [--mode test] file.txtar" so you run them as either test files or multifile scripts. The second option is handy if you want to eject a file onto the filesystem without having to do echo or EOF business in bash scripts
I'm continuing my tradition of doing AoC in Whitespace[0]. The first year I did it, it was motivation to build out a standard library so things wouldn't be so tedious. Now, I find myself wishing I had finished better tooling. I debug with wsjq[1], a CLI debugger like gdb written in jq, but it's slow.
> Excel 2.0 was released a month before Windows 2.0, and the installed base of Windows was so low at that point in 1987 that Microsoft had to bundle a runtime version of Windows 1.0 with Excel 2.0.
Or easier, do an interactive rebase and mark the last commit which is in the partial-rebase branch for editing. Then, do `git reset --hard partial-rebase` and continue the rebase.
