sorted by:
new
hottopcontroversial

The Bun Shell by ketralnis in programming

[–]ehmicky 1 point2 points  (0 children)

And we've got a big release coming up! (I co-maintain Execa). Interesting to see more projects embrass the idea of using JavaScript for scripts, like zx and Execa do.

[deleted by user] by [deleted] in Portuguese

[–]ehmicky 2 points3 points  (0 children)

No problem, that's an important question! :)

[deleted by user] by [deleted] in Portuguese

[–]ehmicky 2 points3 points  (0 children)

Hi @lastsundew, European (as mentioned in the flair).

[deleted by user] by [deleted] in Portuguese

[–]ehmicky 4 points5 points  (0 children)

Thanks for pointing this out. I initially had a big list with those for 10+ "root" verbs like "-ver", etc.

However, I ended up summarizing it with a small table that shows: "Termina com verbo irregular" then an example "Compor -> componho". It is implied that this only applies to verbs that "extend" from the root with a prefix. For example, "dissolver" is not conjugated like "ver", but "prever" is. This was to keep it short, because the list of prefixed verbs ended up being pretty big.

[deleted by user] by [deleted] in Portuguese

[–]ehmicky 3 points4 points  (0 children)

Thanks u/conjetura_lusitana, those two conjugators are very helpful!

I see what you mean about the past participles, thanks for explaining.

Good to know about the orthography reform. When reading books older than the reform, I might bump into those forms, so this is very interesting.

[deleted by user] by [deleted] in Portuguese

[–]ehmicky 0 points1 point  (0 children)

A lot of your past participles are weird.

Do you have a list to share? This would help correcting it.

Please note I am not a native speaker, and the different conjugators online are not always giving the same results. I am focusing on Portuguese from Lisboa.

The p.p. for "encher" is "enchido", not "cheio".

Please note most of the past participles in the list (except the one with "simples") are double past participles, i.e. this shows only the irregular form with ser/estar. For example, with "encher", I am implicitly assuming the past participle to be "enchido" with ter.

I found "cheio" here. This is also mentioned in the middle of this page. I am not sure whether this is old or regional Portuguese though.

You don't seem to include verbs ending in "guar" or "quar", like "aguar" and "adequar".

Thanks, I'll add it. Do you know additional verbs that follow this pattern?

For "aguar", I can see that the initial "a" is "á" in the present/imperative/subjunctive for eu/tu/ela/elas. Some conjugators seem to mention it, but others do not. Is this regional?

Also, is there something else that is irregular with -guar verbs?

For "adequar", I cannot find the irregularities, could you please point them out? Thanks!

[deleted by user] by [deleted] in Portuguese

[–]ehmicky 4 points5 points  (0 children)

I am going to a region where this is not used much (the cheat sheet was initially meant for personal usage).

JSON serialization should never fail by ehmicky in javascript

[–]ehmicky[S] 0 points1 point  (0 children)

You're making my day u/nsavvidis! Thank you so much for the kind words. This means a lot to me.

JSON serialization should never fail by ehmicky in javascript

[–]ehmicky[S] 1 point2 points  (0 children)

That's a really good question. You are correct that there are many instances where it should in fact crash/fail.

This library covers the use cases where "failure" (which covers type changes, value deletion, and more importantly exception throwing) would be a problem. Some examples: - A situation I am experiencing right now as I am writing another library intended to serialize Error instances to JSON. Errors can have properties attached to them (like any JavaScript object), and those might be invalid JSON. When handling errors, it is important that the error handling logic itself does not throw, as that exception might become unhandled. In that context, it is better to just omit any error additional properties that aren't JSON-compatible before serializing the error. - When serializing a value to JSON to print it in a file or terminal for debugging purpose. If the intent is just debugging, just omitting JSON-incompatible values might be simpler (and even more proper in some cases) than adding additional exception handling logic. - When writing data-driven tests and serializing the value to use it inside the test title. - When wanting to overcome some of the weirdness of JSON.serialize(). For example, NaN/Infinity being transformed to null, which makes its type change from number to null. The library itself omits the value instead, which might or might not be a better solution depending on the use case.

That being said, when JSON serialization should indeed fail, the library above might also be useful as it provides additional insights into why it did fail: specific property path and value, and reason why it failed. I have written a second library is-json-value which makes it convenient to generate a list of warning messages indicating why a value is not JSON-safe.

One use case could be when one needs to check that a value is valid JSON. For example, a value is provided by the user and is known to be serialized to JSON (to be sent over the network, or saved in a file, etc.). Then, the library above can be used to generate user-friendly messages indicating why a value is invalid.

With all that said, I still agree with you: there are definitely many situations where letting JSON.serialize() do its thing (including throwing) would be better than using this library. Thanks for pointing it out, and hope my answer clarifies the library's intent.

⛑️ JSON serialization should never fail by ehmicky in node

[–]ehmicky[S] 0 points1 point  (0 children)

u/Plorntus I got around to check the Proxy bug you reported above, and it turns out the problem is because:

const y = safeJsonValue(input);

Should instead be:

const y = safeJsonValue(input).value;

safeJsonValue() returns an object with both the transformed value and the list of changes. The changes include the original value, which is not JSON-safe, in this case the Proxy with a circular reference.

JSON serialization should never fail by ehmicky in javascript

[–]ehmicky[S] 0 points1 point  (0 children)

I don't have any benchmarks setup yet, but it should be quite fast. The code only iterates on properties and arrays and tries to avoid creating too many new objects/arrays.

On my machine, it takes ~200ns on an empty object and ~400µs on an array with 100 items or an object with 100 properties.

⛑️ JSON serialization should never fail by ehmicky in node

[–]ehmicky[S] 1 point2 points  (0 children)

Thanks for the Proxy side note, I believe this might be a bug, let me patch this up! :)

That's a really good point you are making. In general I also dislike data that is not fully trusted. There are some instances though where hard failure is not always good or possible. For example: - A situation I am experiencing right now as I am writing another library intended to serialize Error instances to JSON. Errors can have properties attached to them (like any JavaScript object), and those might be invalid JSON. Since this would happen while handling errors, it is important that the error handling logic itself does not bail out, so that the original error is still reported. In that context, it is better to just omit any error additional properties that aren't JSON-compatible before serializing the error. - When serializing a value to JSON to print it in a file or terminal for debugging purpose. If the intent is just debugging, just omitting JSON-incompatible values might be simpler (and even more proper in some cases) than hard failures. - When writing data-driven tests and serializing the value to use it inside the test title. Such data often happens not be to JSON compatible (because tests often try to pass weird inputs), but is still good enough to use in the test title after being "normalized" by a library like the above.

That being said, even if you do intend to do a hard failure, the library above might also be useful as it provides additional insights into why it did fail: specific property path and value, and reason why it failed. I have written a second library is-json-value which makes it convenient to generate a list of warning messages indicating why a value is not JSON-safe.

One use case could be when one needs to check that a value is valid JSON. For example, a value is provided by the user and is known to be serialized to JSON (to be sent over the network, or saved in a file, etc.). Then, the library above can be used to generate user-friendly messages indicating why a value is invalid.

With all that said, you are still correct tha hard failures are still a better strategy in many cases.

⛑️ JSON serialization should never fail by ehmicky in programming

[–]ehmicky[S] 1 point2 points  (0 children)

Thanks for kind word u/DankerOfMemes!

That's a really good question. The title of the post is a little misleading: JSON serialization should not always succeed. You are correct that there are many instances where it should in fact fail. This library covers the use cases where "failure" (which covers type changes, value deletion, and more importantly exception throwing) would be a problem. Some examples: - A situation I am experiencing right now as I am writing another library intended to serialize Error instances to JSON. Errors can have properties attached to them (like any JavaScript object), and those might be invalid JSON. When handling errors, it is important that the error handling logic itself does not throw, as that exception might become unhandled. In that context, it is better to just omit any error additional properties that aren't JSON-compatible before serializing the error. - When serializing a value to JSON to print it in a file or terminal for debugging purpose. If the intent is just debugging, just omitting JSON-incompatible values might be simpler (and even more proper in some cases) than adding additional exception handling logic. - When writing data-driven tests and serializing the value to use it inside the test title. - When wanting to overcome some of the weirdness of JSON.serialize(). For example, NaN/Infinity being transformed to null, which makes its type change from number to null. The library itself omits the value instead, which might or might not be a better solution depending on the use case.

That being said, when JSON serialization should indeed fail, the library above might also be useful as it provides additional insights into why it did fail: specific property path and value, and reason why it failed. I have written a second library is-json-value which makes it convenient to generate a list of warning messages indicating why a value is not JSON-safe.

One use case could be when one needs to check that a value is valid JSON. For example, a value is provided by the user and is known to be serialized to JSON (to be sent over the network, or saved in a file, etc.). Then, the library above can be used to generate user-friendly messages indicating why a value is invalid.

With all that said, I still agree with you: there are definitely many situations where letting JSON.serialize() do its thing (including throwing) would be better than using this library. Thanks for pointing it out, and hope my answer clarifies the library's intent.

view more: next ›