The Computer And General Tech Thread - Software, Hardware, Questions, etc.

[Travis B.]

I have implemented task notifications in zeptoforth's RTOS, inspired by those in FreeRTOS. For doing the same function as rendezvous channels, aside from being limited to communication between two tasks and only transferring one word between tasks at a time, they are considerably faster, taking roughly 1/4 the time per message sent.

[MacAnDàil]

I don't know much about computing, but would like to start using Signal. As I have a Nokia, this appears to be a littlle more complicated. I tried following the instructions here, but I'm not sure how to:
https://ctrl.alt.coop/en/post/signal-wi ... martphone/

I'm stuck at the 'where do I find signal-cli?' bit

[Travis B.]

I don't know much about computing, but would like to start using Signal. As I have a Nokia, this appears to be a littlle more complicated. I tried following the instructions here, but I'm not sure how to:
https://ctrl.alt.coop/en/post/signal-wi ... martphone/

I'm stuck at the 'where do I find signal-cli?' bit

It seems it is under releases on the project's GitHub.

[Raphael]

And if I didn't misunderstand something, that's for using Signal on a computer, not a phone.

[Travis B.]

And if I didn't misunderstand something, that's for using Signal on a computer, not a phone.

Well signal-cli appears to be specifically for use on a computer, hence its name (phones typically don't have readily accessible CLI's).

[MacAnDàil]

To clarify, I am trying to use Signal on my PC. The fact that my phone is Nokia appears to make this more complicated than if I had a computerphone. As far as I can tell, I have already downloaded and unzipped the signal-cli. The problem part is that I am not sure how to get it to run.

[Raphael]

So there was a landline internet/phone outage here from Monday morning or noon until early evening on Tuesday. It affected apparently most of the municipality, as well as some neighbourhoods of the next city. I could handle it well enough, mind you, but losing a basic utility for that long in such a large area was interesting.

[Ares Land]

I have not so fond memories of an excavator hitting a main fiber optics connection a few years back. (And my workday degenerating into endless crisis meetings...)

[Travis B.]

Because I was bored I decided to rewrite the heap allocator for zeptoforth. In theory it should be faster algorithmically, since it uses a free list rather than a bitmap search for allocation, and only uses bitmap searches for freeing memory (and then they should be less intensive than the bitmap searches for allocating memory on he old allocator). The thing, though, is that the new allocator is considerably more complex than the old allocator and thus may have higher constant factors even if it is algorithmically faster. Also, the heaps involved will be rather small in practice, so whatever improved algorithmic scaling it gets may not have that much benefit in practice.

[Travis B.]

For implementing an automatic testing system for testing heap allocators I needed, I needed the capability to generate pseudorandom numbers (I already have true random number generator support for each of the platforms supported by zeptoforth, but I specifically need to be able to arbitrarily repeat sequences of numbers from given seeds) so I did a partial implementation (i.e. no floating point support or support for initialization with arrays of seeds) of the TinyMT PRNG (itself a miniature implementation of the Mersenne Twister PRNG used in places such as Python, which I chose because it has far smaller RAM requirements than MT proper and because I did not care that it had a period of only 2¹²⁷-1). I have verified that for a given seed it generates the same exact sequence of numbers as the TinyMT reference implementation for each of the seeds I tested, so I know it's good.

[Travis B.]

I have, well, an opinion question. Currently in zeptoforth when a task executes PAUSE to give up control of its core, it is put to the rear-most position, for its priority, in the core's schedule. This works all good and fine. However, when carrying out activities where a task gives up control of its core because of blocking, it might be a better idea to not move the task from the head of the schedule to somewhere in its rear, to provide better latency for tasks which block momentarily. Do you guys think this is a good idea or an awful one? The reason why it might be a bad idea is that it reduces the opportunity for other tasks to gain control of a given core by ensuring that a task is favored to run until it exhausts its timeslice. So I might have to do some tests to check which has better performance in practice or not.

[bradrn]

I have, well, an opinion question. Currently in zeptoforth when a task executes PAUSE to give up control of its core, it is put to the rear-most position, for its priority, in the core's schedule. This works all good and fine. However, when carrying out activities where a task gives up control of its core because of blocking, it might be a better idea to not move the task from the head of the schedule to somewhere in its rear, to provide better latency for tasks which block momentarily. Do you guys think this is a good idea or an awful one? The reason why it might be a bad idea is that it reduces the opportunity for other tasks to gain control of a given core by ensuring that a task is favored to run until it exhausts its timeslice. So I might have to do some tests to check which has better performance in practice or not.

Honestly, I have no idea whatsoever. I’d say you should just test both options and see which works best. (Or even just let each task assign itself the scheduling algorithm which is best for that task, if feasible.)

[Travis B.]

I have, well, an opinion question. Currently in zeptoforth when a task executes PAUSE to give up control of its core, it is put to the rear-most position, for its priority, in the core's schedule. This works all good and fine. However, when carrying out activities where a task gives up control of its core because of blocking, it might be a better idea to not move the task from the head of the schedule to somewhere in its rear, to provide better latency for tasks which block momentarily. Do you guys think this is a good idea or an awful one? The reason why it might be a bad idea is that it reduces the opportunity for other tasks to gain control of a given core by ensuring that a task is favored to run until it exhausts its timeslice. So I might have to do some tests to check which has better performance in practice or not.

Honestly, I have no idea whatsoever. I’d say you should just test both options and see which works best. (Or even just let each task assign itself the scheduling algorithm which is best for that task, if feasible.)

I decided to make it put tasks back at the head of the schedule when executing blocking operations on the current task or when one explicitly executes PAUSE-WO-RESCHEDULE. This does result in a bit of a performance hit on the RP2040 for some reason, but I suspect this has to do with the sensitivity of cache line locality in the RP2040's XIP cache, because I have seen similar effects from seemingly innocuous changes. Also, on the STM32F746 it results in no performance hit at all, which implies this is the case.

[Raphael]

I have a question about GIMP (thought if there's some way to do what I want to do in MSPaint or something, that's ok too):

Is there some way to draw a line where, instead of using the mouse to draw the line by dragging it around, you simply tell the software to draw, say, a straight line from, say, 45,87 to 163,14 , and then the software does as instructed? If, say, you want to draw a line between two specific points but don't trust your hand to hit those points just right with the mouse?

[CreativityTheEmotion]

I have a question about GIMP (thought if there's some way to do what I want to do in MSPaint or something, that's ok too):

Is there some way to draw a line where, instead of using the mouse to draw the line by dragging it around, you simply tell the software to draw, say, a straight line from, say, 45,87 to 163,14 , and then the software does as instructed? If, say, you want to draw a line between two specific points but don't trust your hand to hit those points just right with the mouse?

I'd probably write a quick SVG file, then import it into GIMP. Here's an example of that:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" width="210" height="297" viewBox="0 0 210 297">
    <path style="fill:none;stroke:#000;stroke-width:1" d="M 45,87 L 163,14" />
</svg>

[Raphael]

I'd probably write a quick SVG file, then import it into GIMP. Here's an example of that:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" width="210" height="297" viewBox="0 0 210 297">
    <path style="fill:none;stroke:#000;stroke-width:1" d="M 45,87 L 163,14" />
</svg>

Neat! Thank you!

[Raphael]

Something I've been thinking about a bit lately: how useful, really, is the concept of Turing completeness? My impression is that if I understand that concept correctly, it seems to imply that in theory, you should be able to play last year's best-selling high-end games on an ENIAC. But how would that ever work? And if, as seems likely, it can't work, what use is the concept then?

[CreativityTheEmotion]

Something I've been thinking about a bit lately: how useful, really, is the concept of Turing completeness? My impression is that if I understand that concept correctly, it seems to imply that in theory, you should be able to play last year's best-selling high-end games on an ENIAC. But how would that ever work? And if, as seems likely, it can't work, what use is the concept then?

A true Turing machine is supposed to have an infinite amount of memory, and computers, especially the earlier ones, don't have that. Instead, it's purely a theoretical tool to compare programming languages and such.

[Richard W]

Decidability theory seems to distinguish between machines with sequential memory access and those with random access memory, so the whole concept fractures.

I've been pondering a similar issue for fully designed Unicode-compliant regular expression engines. (The catch is that the set of strings recognised should be closed under canonical equivalence.) Strictly speaking, Kleene star isn't always a regular expression, though that can be made a non-issue by using a recursive NDFA (non-deterministic finite automaton) construction, which of course then isn't finite. (The simple example is deciding whether a string consists of an arbitrary number of repeats of U+0F73 TIBETAN VOWEL SIGN II. It's a fairly rare problem.) Once one throws Kleene stars and choices into the pattern, it's no longer even decidable in general whether the pattern is a regular expression.

[Travis B.]

Decidability theory seems to distinguish between machines with sequential memory access and those with random access memory, so the whole concept fractures.

Are you sure? Turing-equivalence has nothing to do with whether memory is sequentially or randomly accessible (after all, memory on a Turing machine proper is not randomly accessible, yet no other computation machine is more powerful than it).