zzo38computer

Clippy is not good, but maybe it is good in comparison to many modern computers, in some ways.

The standards are not all good for the same purposes, and many of them have problems anyways. Furthermore, you will not always know all of the details at first, and different computers will have differences than each other, for good reasons. Furthermore, people do not necessarily agree (this does not always break compatibility, but sometimes it does, although sometimes indirect compatibility is possible). This is some possible reasons why they cannot all be made compatible.

I had not been at hotels with bathroom without a door, but I would want them to have a door like the people who wrote the article allegedly do. What I could do without is a TV set and many other things, but I would want to have a door, and a desk, and fresh air.

> You can determine user's language from IP address location.

There are reasons why it might not work (VPN is only one of them; there are others such as places with multiple languages, people traveling to foreign countries, and others), although it is also a bad idea for other reasons as well.

If the user specifies the language then you should use that one. I think it would probably be better to use the following order of figuring out which language you should want:

1. If the URL specifies the language to use, then use the language specified by the URL.

2. If the language is not specified by the URL, use the language specified by any cookies that are set for the purpose of selecting the language.

3. If the language is not specified by URL or cookies, but the user is logged in and the user account has a language setting, use the language specified by the user account. (If TLS client authentication is being used, then you might consider adding an extension into the client's X.509 certificate to select the language.)

4. If the language is not specified by URL or cookies or the user's account, or the user is not logged in, use the Accept-Language header.

5. If the language is not specified by URL or cookies or the user's account, or the user is not logged in, or the Accept-Language header is not present or cannot be parsed or does not specify any language that the request file is available in, then use the default, such as the language that it was originally written in.

At first, I disagree that the label should be removed (but see my comments below for more nuances about this; it is not as simple as it might seem). However, if they have no way to know if it is made with AI, that is different, although they should ask whoever made the game and put it there, it if they do not know. It is not only about plagiarism, though; at least, to me it isn't mostly about plagiarism.

Epic Games Store does not have to add a label that it is made with AI if Tim Sweeney thinks it is better to not have such a label, but I think it might be better for Steam to keep the label if that is what the Steam believes they should have.

> It makes no sense for game stores, where AI will be involved in nearly all future production.

I would not be so sure. However, there are multiple kind of AI as well as multiple cases where it may be used. Depending on the specific case, it might not be a problem, but that does not necessarily mean that the label should be removed, either, although it might mean that there is the nuances to be mentioned. For example, is it LLMs? Is it precalculated, or dynamic at run time? Can it be disabled? What parts use this AI? etc. It is complicated, and I do not know what to do about it.

> What do you mean under "syntax typing" and complications in the syntax?

This question has been answered by someone else, but I have my own comments about this as well so I will write it also.

EDN does complicate the syntax (so does XML, TER, various extensions of JSON, etc), but DER (and SDSER, if you want streaming) avoids this problem because the framing is the same for all data types, even though it has many different types and the encoding of the values of each type.

> That [the whole world seems to run on JSON] is true, and I don't like that :)

I agree with you (well, not everything but too many things); I don't like that either.

> From my perspective JSON syntax is too "light" and that translates to many complications typically in the form of convention

I agree with you about that too. In this case it is a number (there are problems with the numeric types in JSON), but there is also such things as: octet strings, date/time, non-Unicode text, etc.

> I agree JSON’s number types are weak; it’s been a source of real problems for me. Given that observation, you can go in two directions: have richer types, like EDN, or give up on types in JSON entirely, which is the alternative I’d propose.

Not only the number type (which is floating point so there is not a proper 64-bit or larger integer type, even though a integer type has been added into JavaScript after JSON was invented); the string type is also weak (since it cannot be arbitrary bytes), and so is the key/value list type (keys are only allowed to be strings and cannot be other types).

There are other directions as well; I think DER does in between because of the same framing for all types even though there are many types (you do not have to use all of the types; it seems that some people don't like it apparently due to the expectation that you have to use all of the types, but that is wrong). (DER also has the advantage of the canonical form if you need it (DER is already canonical form); although there is a canonical form for JSON, it is a bit messy, and apparently the canonical form for numbers in JSON is complicated.)

If you want to give up on types entirely, then why should you use JSON?

Maybe it might be better to be implemented as a function attribute instead

I happen to like the Windows 1.0 appearance and I think it is not so ugly.

I agree that it should not use JSON. I think it would be better to use DER (or SDSER if streaming is needed) rather than XML or JSON, but that is just my opinion. However, if the existing protocol already uses XML, then that is what it will be, but the new one perhaps would not use XML.

I mean the possibility that the rest of the program guarantees that the address is valid if the condition is true but otherwise it might be valid or invalid. This is probably not important for most applications, but I don't know if there are some unusual ones where it would matter.

I think you might have misunderstood what I meant, because I was unclear. I meant that it would have to decode the entire EDN string literal containing the base64 data before decoding the base64, not that it would have to decode the entire file before doing so. (I might still be wrong.)

Specifically, I refer to what is quoted below:

> Upon encountering a tag, the reader will first read the next element (which may itself be or comprise other tagged elements), then pass the result to the corresponding handler for further interpretation, and the result of the handler will be the data value yielded by the tag + tagged element, i.e. reading a tag and tagged element yields one value.

> If a reader encounters a tag for which no handler is registered, the implementation can either report an error, call a designated 'unknown element' handler, or create a well-known generic representation that contains both the tag and the tagged element, as it sees fit. Note that the non-error strategies allow for readers which are capable of reading any and all edn, in spite of being unaware of the details of any extensions present.

Due to these things, EDN does not have a proper "octet string" type, even if the extension is added.

> This implementation does not do streaming for now, but it understands a concept of "reading one complete" element from buffer. The only missing part is buffer managment.

OK, then it could be improved.

> Could you explain how it is restricted if you are allowed to run whatever you want during reading of edn document? You can even do IO, no restrictions at all!

Perhaps the above explains how it is restricted. It does not prevent you from looking up data in a database, etc; it is the data model of EDN itself which is restricted; it is not restricting what you do with it.

> Please show how it does better. I'm very curious

Since all types using the same framing, you can do "lazy decoding" if appropriate (you can also use custom decoders in any part of the file, and this can depend on the schema), and ASN.1 does have a built-in octet string type (as well as bit string, unrestricted character string, etc), and you can add implicit or explicit tagging (I prefer to use implicit if the underlying type is sequence or octet string, and explicit otherwise), as well as types such as External (and the nonstandard ASN1_IDENTIFIED_DATA type), you can easily define any type and can easily skip past any field of any type.

> #init/postgres {:db-spec {:host "..." :port 54321 ,,,} :specs {:user ,,,}} [#user/id 1 #user/id 2 #user/id 3]

Even with TER (the below does not use any extensions to TER itself, but extensions to TER are also possible; even if not, whoever reads the resulting DER can handle the application-specific types as needed), you can:

  [ [P:(database.example) 54321] [0A:1 0A:2 0A:3] ]

In this case, the "0A:" prefix means application type 0, which has a meaning specific to the application; presumably for this application, application type 0 would correspond to user IDs. This example uses implicit types for the user IDs; if you want explicit types instead, then you can write:

  [ [P:(database.example) 54321] [0A[1] 0A[2] 0A[3]] ]

Or, if you want to extend TER instead, then you might define your own keyword, e.g. "userid{1}" instead of "0A:1" or "0A[1]".

(TER is not one of the official ASN.1 formats; it is one that I invented for the purpose of having a text format for ASN.1 which can then be converted to DER; most programs would be expected to use DER rather than TER.)

I think __builtin_ct_select and __builtin_ct_expr would be good ideas. (They could also be implemented in GCC in future, as well as LLVM.)

In some cases it might be necessary to consider the possibility of invalid memory accesses (and avoid the side-channels when doing so). (The example given in the article works around this issue, but I don't know if there are any situations where this will not help.)

> EDN also has no builtin 'raw bytes' type.

That was my complaint too.

> I am working on a format consisting of serialized B-tree. It is essentially a dictionary, but serialized

I had wanted something a bit similar; a serialized B-tree (or a similar structure) but with only a 'raw bytes' type, for keys and values (I will use DER for the values; I have my own library to work with DER already), and the ability to easily find all records whose key matches a specified prefix.

I think it depends what you will intend to do with the data (which is true for all of the formats that you mentioned); not everyone will do the same thing with it even if it is the same file. It might be helpful to know from other programs that do not know this schema to be able to parse the data (not always the case when using IMPLICIT types in ASN.1, which is one reason to use EXPLICIT instead, although it has avantages and disadvantages compared with IMPLICIT; however, in DER all types will use the same framing allowing the framing to be parsed even if the specific type cannot be understood by the reader), and can also be used in case the schema is later extended to use types other than the ones that were originally expected. (I prefer to use ASN.1 DER in my stuff, although JSON and other formats are also used by other formats that were made by someone else)

OK, this is possible, but it seems the type that ought to be a built-in type.

Also, if there is not a binary file format for the data then you will need to always convert to/from base64 when working with this file whether or not you should need to.

Furthermore, this does not work very well when you want to deal with character sets rather than binary data, since (as far as I can tell from the specification) the input will still need to be UTF-8 and follow the EDN syntax of an existing type.

From what I can understand from the specification, the EDN decoder will still need to run and cannot be streamed if the official specification is used (which can make it inefficient), although it would probably be possible to make an implementation that can do this with streaming instead (but I don't know if the existing one does).

So, the extensibility is still restricted. (In my opinion, ASN.1 (and ASN.1X) does it better.)

I think it would be better to not use Unicode (so that you can use any character set), and to use "0o" instead of "0" prefix for octal numbers. Also, EDN seems to lack a proper format for binary data.

I think ASN.1 (and ASN.1X which is I added a few additional types such as key/value list and TRON string) is better. (I also made up a text-based ASN.1 format called TER which is intended to be converted to the binary DER format. It is also intended that extensions and subsets of TER can be made for specific applications if needed.) (I also wrote a DER decoder/encoder library in C, and programs that use that library, to convert TER to DER and to convert JSON to DER.)

ASN.1 (and ASN.1X) has many similar types than EDN, and a comparison can be made:

- Null (called "nil" in EDN) and booleans are available in ASN.1.

- Strings in ASN.1 are fortunately not limited to Unicode; you can also use ISO 2022, as well as octet strings and bit strings. However, there is no "single character" type.

- ASN.1 does have a Enumerated type, although the enumeration is made as numbers rather than as names. The EDN "keywords" type seems to be intended for enumerations.

- The integer and floating point types in ASN.1 are already arbitrary precision. If a reader requires a limited precision (e.g. 64-bits), it is easy to detect if it is out of range and result in an error condition.

- ASN.1 does not have a separate "list" and "vector" type, but does have a "set" type and a "sequence" type. A key/value list ("map") type is a nonstandard type in ASN.1X, but standard ASN.1 does not have a key/value list type.

- ASN.1 does have tagging, although its working is difference from EDN. ASN.1 does already have a date/time type though, so this extension is not needed. Extensions are possible by application types and private types, as well as by other methods such as External, Embedded PDV, and the nonstandard

- The rational number type (in edn.c but the main EDN specification does not seems to mention it), is not a standard type in ASN.1 but ASN.1X does have such a type.

(Some people complain that ASN.1 is complicated; this is not wrong, but you will only need to implement the parts that you will use (which is simpler when using DER rather than BER; I think BER is not very good and DER is much better), which ends up making it simpler while also capable of doing the things that would be desirable.)

(But, EDN does solve some of the problems with JSON, such as comments and a proper integer type.)

This is a problem, that the software will try to guess what you mean by such things like this (it is not specific to this feature, but other features of computer programs in general; this is one specific case of that). Just because you do not want it to translate such a language (or any other langage) automatically does not necessarily mean that you can read it or that you want to request documents written in that language. Fingerprinting is not the only issue with this.

Of course that is wrong and it is not immoral; but, if you want to do it in the moral way, you have to consider the lives of any living things (plants and animals), including but not limited to humans. Furthermore, there is the consideration of what exactly has to be sacrificed and what kind of coercion is being used (which might be immoral for a different reason); morals is not as simple like they would say.

But, yes people do find all sorts of justifications, whether or not they are any good (although sometimes it is not immediately clear if it is any good, unfortunately).

The actual death penalty is not a good idea for several reasons, including possibility of error (even if that possibility is small).

(In the case of a corporation, also many people might be involved, some of whom might not know what it is, therefore increasing the possibility of error.)

However, terminating the corporation might help (combined with fines if they had earned any profit from it so far), if there is not an effective and practical lesser punishment which would prevent this harm.

However, your other ideas seem to be valid points; one thing that you mention is, government monopoly can (and does) lead to corruption (although not only this specific kind).

It does not display the text; it just displays a mess. In my experience it sometimes does this when the file is compressed but the server does not tell you that it is compressed (I have also had the other way around happen; the server telling you that it is compressed even though it is not compressed).

Maybe it is possible to make it (and other functions) to stay disabled by the enterprise policies file.

Gemini and Gopher are better than the existing WWW, (although there are others as well, such as Spartan (uses the same file format as Gemini, but it is a different protocol without TLS), Scorpion (my own format, intended to be between Gemini and "WWW as it should be if it was designed better"), and others).

However, you might also want to access HTTP and HTML, and to do so without needing to load fonts, pictures, etc; you might use a web browser that omits many of these features. However, it also can result in some problems; there are a few ways to work around some of these, such as adding your own scripts to handle some services, adding proxy services for handling some services (although some of these can use other protocols such as Gemini), and/or using the HTML/CSS commands in other ways (e.g. using ARIA to decide the formatting rather than using CSS). However, there are other issues, e.g. if the web page you download includes more junk than the actual main text.

I have seen some of the interpreter source codes, but I don't know if they have been "officially" published. These also include some other things such as test files, and a picture file that I have never seen a decoder for (other than the decoder (and encoder) that I wrote myself).

Many modern implementations do not support permanent shifts in Z versions 3 and above (although all of my own implementations do, and I think all of the official implementations also do, even though Infocom never used that feature (this isn't too surprising since the algorithm they described for deciding when to use permanent shifts is worse than not using them at all; I worked with someone else to make a better algorithm for making this decision)).

Some of the official implementations check the Z version number and some don't; even some that do, do not check if it is a small-endian story file (and the ones that do will only display an error message if it is, and refuse to run it). My own implementations do check for small-endian story files (as well as the Z version number), although some will display an error message and refuse to run it in that case, some actually are able to run both big-endian and small-endian story files (as far as I know, there are no small-endian story files; Infocom never used this feature and no modern compilers support this).

Something else I might mention is that some people say that Infocom used many tricks in the programming, although I have looked at disassembled code in the debugger and found that they could be optimized a lot more (e.g. by using SET->BCOM optimization, and many other things), and the source code for the interpreters also shows some things that could be optimized much better. (Another thing revealed from the source code of the interpreters is a undocumented command-line switch for the DOS version that allows you to specify the name of the story file.)

Your comment is marked as [dead] (and so is the other one that mentions GPT-5.1 and the other stuff) but I can read it but cannot write a response directly. I am unable to access that URL. I know what you meant that it is Sokoban inspired (and I did not intend to disagree with that or to dispute that); what I meant by my comment is being a similar class of games even if it is not Sokoban; I don't know what such a class of games would be called ("Sokoban" might be misleading even if it is not entirely wrong).

I think it would be better to abolish patents entirely, but maybe that could potentially be another alternative way.

Sokoban is you must move the boxes to the targets, although it can be called a class of puzzle games that are similar even if they do not involve moving boxes to targets; such as, it is a turn-based game with tile grid that has a puzzle to move around the pieces, etc.

(Also, it does not load, which is why I asked for a proper documentation.)

Do you have a document explaining all of the rules? (I think it is unfortunate that too many games do not make the rules clear by writing long documents about their working. How should you know how to do it if you do not know its working?)

(I had made a puzzle game engine that does not require a web browser nor an internet connection, and has no spyware or analytics or telemetry or anything else like that. Some puzzles can be made by it including stuff similar to sokoban.)

You are not the only one to suggest that.

I think there is benefit in having multiple approaches available, and that is one of them, but the other one is the other benefit.

You can prevent many kind of ads and tracking from working and disable JavaScripts (and other features if wanted, e.g. CSS) entirely, although there is no guarantee that it will work.

You can use the Scorpion protocol that I made up if you want optional TLS and including the file size (and if you don't like the Han unification). You can use Spartan protocol if you want the Gemini file format (with one difference) but a different protocol that does not use TLS (although it is not the same as just Gemini without TLS, but works significantly differently), although if you have any dynamic files then you might need to handle them differently for Spartan than Gemini.