Tiny suggestion, possibly without merit (no comments or email in the article):
Use ULEB64 encoding instead of RAW unsigned 64-bit fields for STRING lengths.
ULEB64 (https://en.wikipedia.org/wiki/LEB128) is a simple encoding where the 7th bit is used to show if there are more bytes following. So, lengths less than 128 can be encoded in one byte and so forth.
I doubt the protocol will routinely send lengths that are more than, say, four gigabytes. The longest ULEB64 number is eleven bytes, as far as I recall.
Other than that, I know nothing about the ancestors of the proposed protocol and thus cannot comment.
it's still a commercial service, with RustDesk or MeshCentral I own/I can own if I wish the entire infra, so I can be let down by a third party problem.
It's also assigning string literals to char array struct members in a non-initializing context, which doesn't work.
As someone trying to piece together C knowledge from various b0rk3n tutorials (as a pre-Internet teenager in the early 90s) it's pretty provocative. Luckily I healed and levelled up since.
Fact is, with a little LCD and a nice keyboard, one could put the Amiga in the 'loo and have a fair bash at the old school while pushing one out, eh .. ?
An "A500 Mini" is basically the same emulator you could get for basically free, plus a case which is reminiscent of the actual Amiga A500, bundled with some video games.
Probably if you are interested in writing software for an Amiga, rather than nostalgia of old video games you might better begin with just the emulator.
Okay, hear me out .. sure, you could do all this with another system too, if you had them available, but this is a pretty decent implementation, in hardware.
You can boot it into a 'proper' A1200 and use it just like that, as a pretty decent little Amiga system - one doesn't have to only run the built-in OS/provided games, you know.. you can boot it like an Amiga would, albeit with USB.
With the distinctly relevant advantage that a) it is a small and compact, unassuming device .. and therefore can be duct-taped to the back of the LCD monitor[1] that has, inevitably, a 'spare' video input, and b) one doesn't have to install anything on your other .. potentially work-provided .. computer .. which you occasionally switch back to, when the cubicle alarm goes off ..
I mean, I use my raspberry-Pi for productive things. Having an Amiga handy here and there, has been great. Even the conference room monitor has extra inputs and some spots for duct-taping ..
[1] or underneath the desk, in the cabinet, whatever ..
>but this is a pretty decent implementation, in hardware.
minimig mist branch is a decent implementation in hardware.
The A500 mini is an open source SOFTWARE emulator (amiberry, designed for the raspberry pi) put in a much cheaper/weaker board relative to the pi, enclosed by a nostalgia-inducing box, and sold at a very profitable price.
I don't want to be toxic but why make a function to cast a char to an int? I was astounded when I briefly skimmed through the list. I hope this is not curriculum in education.
I don't see the one you're talking to on a brief skim, but there are several functions that deal with processing a file character by character. They generally use ints because they need a way to signal end of file and you can't do that with any value of a byte.
I was invited to join the ReactOS project about 10-12 years ago. I was part of it for, say, four days, then I left. I realized I could format my system drive with no warning or error. Then did a code review and realized that this project will never fly. I appreciate the motivation and goals, but I don't think you'll ever see a usable release of ReactOS. I am not against ReactOS, but the guys have way too few resources to ever be able to compete against Microsoft.
I was interested in helping, too, and I set out to fix some obvious UI bugs, which turn out to be bugs in Wine. The Wine devs are not the same people, and they take a long time to review patches, if at all.
I thought the kernel aspects would be interesting, but they were really trying for driver-level compatibility with Windows NT, which means that they have to have essentially the same operating principles, etc. For some reason, I didn't want to make a line-for-line clone of Windows itself. After all, OSS people are always talking about how we would do it better.
If the goal is to be able to use the proprietary drivers supplied with some kind of hardware on a mostly OSS base, that's a decent goal. But if you want to be able to run it with complicated software that uses a lot of Windows APIs, etc., it's a fools errand.
However, I found it interesting how ReactOS could be used to teach Microsoft devs about Windows internals, even if it wasn't exactly the same. That sort of blew my mind. When you have a bunch of trade secrets, you don't really want the whole company to have access to the code, I guess, and so you benefit from having an open source clone to point to when you want to say how something like a Mutex is really implemented.
They don't need to be able to compete. But they need to be able to keep up with the moving target that is "Windows on which you can run applications that many people want to run". And they don't have the resources for even that.
In a way, yes. But I left because I could see no future for the project due to the fact that I could format my system partition without getting warning and other similar issues. I have to say that I wasn't a coder or anything, only invited to test. And I quickly felt that there was no way this thing could be made to fly.
I admire the people behind ReactOS for their perseverance, I really wish I had just 1/10th of what they have.
> the guys have way too few resources to ever be able to compete against Microsoft
Really? Are you absolutely sure, Sherlock? Did you know that the water is wet already or are you going to announce that in your next comment? ;)
The project has many other reasons-to-be and it would probably be very hard to find anyone seriously believing that "competing against Microsoft" is one of them.
As a matter of fact, I think it is a shame that so few support ReactOS. The idea is grand and think about how many resources people are willing to invest into using, say, Linux as an alternative to Windows (I love Linux, by the way): If those resources were spent on ReactOS, the project would be flying in 5-10 years or so. Then we could perhaps have a well-designed, compatible, free "Windows".
As a language purist, I'm slightly saddened by the removal of the colon to indicate the beginning of an indented block on the next line.
I believe Cobra did the same and it always bogs my mind why that darned colon can't be left in peace. When you are reading line N, you already know that the next line will be indented, if there is a colon, that is. It is all about making the reading experience as pleasant and meaningful as possible.
Other than that: don't mind my gripes and congrats with the project. It looks good! :-)
So fine with new and actually improved technologies instead of the many GUI rehashes that some companies make money off delivering all the time.
I don't often use SVG, and am by no means an expert on it, but I dislike the experience every time. Like having to edit an .SVG file to fix a wrong displacement that places it a bit too far down. Trial and error, trial and error, until you randomly hit the spot that makes the thing begin to behave.
I think TVG popularity boils down to browser support and nothing else. I hope somebody with the skills picks up the task of integrating it into Chromium, then the rest of the world will bend and bow quickly.
Also, one might hope that a freeware GUI editor will see the light in not too long.
Perhaps the authors should do a new single-protocol Mail/Calendar/Contacts/Notes/etc. standard as well? I recall IMAP being a horribly clumsy and complex protocol, and didn't Einstein say:
inkscape allows you to modify and save SVGs in plain SVG format. You can also right-click an SVG and modify its properties in the inspector window.
SVG is a very impressive, extremely clear format with many bells and whistles such as text-to-path and animation built-in.
The only improvement I can see it might need is a better compression functionality that can selectively prioritize symbols to load first if the SVG is sufficiently large.
I love SVG, but there are a lot of improvements that I can think of: conic gradients, better (and faster) filters, a less awkwards non-scaling stroke definition, better color spaces for gradients, lightweight symbols that are not copies in shadow DOM, meshes, etc.
Also a simplified font spec while we're at it? While there are libraries for it, it is apparently discouraging if you wanted to code your own parser for the existing font formats.
Unlike PDF, PostScript is a full Turing-complete programming language, capable of far more document complexity than PDF (though less interactivity). The PostScript Language Reference Manual is 900 pages, and the PostScript Language Reference Supplement is another 160.
PDF however includes (a subset of) Javascript, making it just as Turing complete.
The spec for PDF 1.7 (dated 2008) is 745 pages long. The more modern PDF 2.0 is not freely available. I'm not willing to spend hundreds of euros to get access to the document, but together with the long list of errata and additional documents linked from the standard body's website, I'm willing to bet it's at least equivalent in length to PostScript.
> PDF however includes (a subset of) Javascript, making it just as Turing complete.
Not really, because the JavaScript is quite limited in what it can do (e.g. forms and interactive features). It can't produce text or graphical elements. A PDF reader can show view of a PDF that looks correct even if it doesn't implement any of the JavaScript features.
The lack of multipage support is the most obvious distinction, I think, but you could probably add the necessary metadata and render fake borders and boxes to simulate pages if you really wanted to. As far as I know, SVGs cannot contain forms for one example. PDFs can also be digitally signed according to the spec, and they contain DRM provisions.
PDF has a lot of features that I would never think of myself (pronunciation guides, for example) which would require designing a custom solution for in many other formats such as SVG.
If I wanted to render something to be printed and I wanted it to be printed exactly as specified, I would consider PDF (and PostScript) files to be much more reliable than SVG files. SVGs are great for images and icons, but they're simply not designed to do the things PDF was designed to do.
Conversely, PDFs are difficult to embed and require proprietary tools to use most of their less common features, so in many areas they're much worse than SVGs.
1. Hype over Rust.
2. Pragmatism because of the many complexities with imperative programming and multi-tasking in a more and more multi-core world.
3. Hype over Rust.
:-)
I personally find Rust so ugly that I refuse to learn it. I don't understand why things like "let mut" are even allowed to exist. Why not simply "create" or "var" for "let mut" and "define" or "def" for "let"?
I am not trying to start a flame war, rather I believe I'm documenting my own ignorance of Rust, the language which I believe you are subtly referring to. I tend to learn languages from an aesthetic angle: If they look beautiful and practical to me (like Python with type annotations), I learn them. Otherwise I steer clear of them while waiting for the world to become ecstatic over them and cool down again a few decades later.
Honestly, it might just be a matter of taste. Not everything is for everyone. For example, I find Python hideous in more than one dimension, yet I like Rust (and Ruby, weirdly enough).
Even though a lot (most?) Rust code you encounter will be written in functional style, it's not a FP language, but it does borrow some great FP/ML ideas.
I think it depends on if you define a functional language as one that functional programs can be written in, or a language that can only write functional programs.
I often see JavaScript described as a functional language, so I think modern parlance leans towards the former.
Use ULEB64 encoding instead of RAW unsigned 64-bit fields for STRING lengths.
ULEB64 (https://en.wikipedia.org/wiki/LEB128) is a simple encoding where the 7th bit is used to show if there are more bytes following. So, lengths less than 128 can be encoded in one byte and so forth.
I doubt the protocol will routinely send lengths that are more than, say, four gigabytes. The longest ULEB64 number is eleven bytes, as far as I recall.
Other than that, I know nothing about the ancestors of the proposed protocol and thus cannot comment.