Zompist Bboard Again

alice wrote: ↑Mon Jun 21, 2021 1:25 pm

bradrn wrote: ↑Mon Jun 21, 2021 6:38 amIn that case, what are your particular preoccupations? (IIRC you made… GSCA, I think?)

I'm more preoccupied with maintaining lexicons for several related languages at once, which means not focusing so much on the SCA as keepiing it unobtrusive as part of something bigger.

Interesting take. I don’t see how the premises justify the conclusion, but everyone has different preferences. (Though I admit to thinking along the same lines occasionally: e.g. this SCA will at some point get support for MDF files, so you can just apply it to a Toolbox dictionary.)

Travis B. wrote: ↑Mon Jun 21, 2021 1:33 pm I see from the screenshot that it looks like a Windows application - is there any possibility of a Linux/BSD port?

It’s written in Haskell and C++/Qt, so it shouldn’t be too difficult to compile it on Linux. (I plan to do just that before the first release.)

I rewrote DO/?DO/LOOP/+LOOP/I/J/LEAVE/UNLOOP in zeptoforth in assembly, to make them faster and more compact and they work... unless one executes LOOP inside a +LOOP loop, where under certain conditions it randomly crashes or goes bezerk. What I have figured out is that replacing LOOP with 1 +LOOP fixes the problem, but is a bit slower. What I have also figured out is the problem goes away when I am not using any interrupts or multitasking, so I suspect that an interrupt is causing a crash or return stack corruption somehow when it occurs right within the LOOP word. Thing is, I have no clue as to why this only affects LOOP and nothing else at all. Another thing is that I figured out that a number of minor changes to LOOP prevent the issue part of the time, but how or why I haven't a clue.

The source code for my SCA is publishable! Find it here: https://github.com/bradrn/brassica. Alas, it as yet has little documentation and no executables, so I will desist from making a formal release announcement until I complete those. (I suppose you can try building it yourself, if you want: you’ll need Stack, Qt, and lots of luck.)

Okay, things get weirder with LOOP etc.... I added code to specifically turn off interrupts inside the code I think is having the issue... and the problem still occurs...

Over in the "Government Videos in Indigenous Languages" thread in the Languages forum, Vijay wrote:

Vijay wrote: ↑Fri Jul 02, 2021 10:24 pm The Taiwanese government also has a bunch of student textbooks in Formosan languages with translations into Chinese, also available as Flash files, but they require the latest Flash plugin.

Today I learned that there are still latest Flash plugins being released.

Remember when the Segway was going to CHANGE THE WORLD!!!?

This piece, over in Slate, is IMO sometimes a bit too smitten with the techbro whose company developed the thing, but still quite good:

https://slate.com/human-interest/2021/0 ... -2001.html

I discovered the EspoTek Labrador a week or so ago, and decided to buy one — the prospect of a $30 oscilloscope+signal generator was too tempting to resist. It arrived a couple of days ago, and since then, I’ve been thoroughly enjoying messing around with electronics now that I can actually see what I’m doing. An image (spoilered due to dimensions, sorry):


(Mind you, I didn’t get it to work immediately. No, first I emailed the maintainer to report a ‘faulty’ USB port — which it wasn’t; the reason the oscilloscope wasn’t showing a signal was because I hadn’t connected it to the signal generator. Go figure. I then followed this up by breaking off two of the pins by repeatedly bending them back and forth while forcing it into my breadboard. Luckily, it seems robust enough to survive all this.)

Raphael wrote: ↑Tue Aug 03, 2021 7:28 am Remember when the Segway was going to CHANGE THE WORLD!!!?

This piece, over in Slate, is IMO sometimes a bit too smitten with the techbro whose company developed the thing, but still quite good:

https://slate.com/human-interest/2021/0 ... -2001.html

I still remember when the owner of Segway, Inc (not Dean Kamen, btw). drove his Segway off a cliff.

Well, I've gone and implemented semaphores for zeptoforth (they're not in a release yet, you'll have to pull the devel branch to get them). They were actually trivial because I'd already implemented an internal construct used by other synchronization constructs called "task queues", which are essentially semaphores meant to be used from within critical sections. All I had to do is add functionality to task queues to allow setting a maximum counter for a given task queue and to allow setting an initial counter on creation.

I have implemented what I call streams for zeptoforth, which are like channels but instead of concerning discrete fixed-sized messages are instead designed and optimized for arbitrary-sized sequences of bytes (even though they have a fixed-sized capacity). Unlike channels, due to their very nature they are meant to be used by one sending task and one receiving task.

zeptoforth 0.20.0 is out! Now with semaphores, streams (byte-oriented IPC queues), non-blocking operations on channels (message-oriented IPC queues) and channels, temporary buffers (when you need temporary storage), immediate-state string literals (using temporary buffers), named tasks, and scheduled task information dumping!

zeptoforth patch releases 0.20.1 and 0.20.2 just came out in close succession. 0.20.1 is only a patch release because it only affects one bit of functionality in zeptoforth, rendezvous channels, but it properly should be a full release because it involves API changes; it converts the existing rendezvous channels to proper rendezvous channels that do no buffering, and as such it eliminates the size settings for rendezvous channels (and thus results in API changes). 0.20.2 is a change to fix a stupid bug that resulted in a broken EVALUATE (it did not work properly if the data stack differed in depth before and after), and it also replaced WARM with REBOOT during the build process to fix build problems on the STM32F746.

I have implemented a far more memory-efficient memory allocator for zeptoforth than my old memory allocator, as the old allocator was particularly memory-inefficient and RAM is at a premium in most embedded systems. It is not currently in any release, but is in the repository for zeptoforth on GitHub.

I have used the new heap allocator for a new history feature to the zeptoforth line editor, something that I had always wanted to implement but which had previously seemed too inefficient to seem practical given the memory constraints of the target hardware.

As the Raspberry Pi Pico requires soldering to be useful, I have purchased a soldering kit, some lead-free solder, and a soldering mat and will be taking a go at it once they all arrive. I'm slightly apprehensive about it because it's been ages since I've soldered, and my soldering then was rather shoddy, but at the same time I've now read up on how to solder properly, which I really did not know back then.

Travis B. wrote: ↑Tue Sep 07, 2021 2:23 pm As the Raspberry Pi Pico requires soldering to be useful, I have purchased a soldering kit, some lead-free solder, and a soldering mat and will be taking a go at it once they all arrive. I'm slightly apprehensive about it because it's been ages since I've soldered, and my soldering then was rather shoddy, but at the same time I've now read up on how to solder properly, which I really did not know back then.

For some reason I thought this sounded a bit like malloc, which is funny given your earlier comment about the memory allocator. But, yes, soldering can be tricky, and I'd recommend practising for a bit on something which doesn't matter first.

alice wrote: ↑Wed Sep 08, 2021 10:07 am

Travis B. wrote: ↑Tue Sep 07, 2021 2:23 pm As the Raspberry Pi Pico requires soldering to be useful, I have purchased a soldering kit, some lead-free solder, and a soldering mat and will be taking a go at it once they all arrive. I'm slightly apprehensive about it because it's been ages since I've soldered, and my soldering then was rather shoddy, but at the same time I've now read up on how to solder properly, which I really did not know back then.

For some reason I thought this sounded a bit like malloc, which is funny given your earlier comment about the memory allocator. But, yes, soldering can be tricky, and I'd recommend practising for a bit on something which doesn't matter first.

I bought three RPi Pico's (the most they'd allow me to purchase in one order), so in case I wreck one or two I'll still have another.

Work on zeptoforth for the RP2040 has been coming along nicely (even though the code is untested at the moment), and I have got things set up so that now all I have to do is issue make and out pops binaries for all the supported platforms, including a UF2 file for the RP2040 (in the process compiling the boot block for the RP2040 and giving it a CRC32 checksum).

Now that I've got zeptoforth working on the RP2040 without any further problems, I've started working on a PIO (programmed input/output) driver for it, with less luck. I still have not been able to turn on the LED with PIO, even though doing so the ordinary GPIO way was trivial.

I just got a software update for an e-reader (not a Kindle - one of the competitors) that I bought almost four years ago. To be honest, I'm a bit (positively) surprised that the consortium selling them is still providing updates for this one after almost four years - given tech industry standard practices, I would have thought they'd just tell me to buy the successor model. And now I'm a bit depressed about the fact that I'm positively surprised about that.