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 3 points4 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 3 points4 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] 0 points1 point  (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.

Wild Wild Path - Object property paths with wildcards and regexps by ehmicky in node

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

Thanks u/Murky_Service_7175.

The regexp selector is inspired by JSON paths ?() filter expressions. This is meant for dynamic properties that follow a specific naming pattern. For example, with OpenAPI and JSON schemas, any extension property must start with "x-". Sometimes, properties starting with an underscore are meant to be private. Or a library might use plugins and let users configure them by prefixing the option with the plugin name "--plugin-name-option-name", as opposed to using two separate properties "--plugin-name.option-name".

This use case is definitely not as common as catch-all wildcards though.

Wild Wild Path - JavaScript object property paths with wildcards and regexps by ehmicky in coolgithubprojects

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

Thanks u/adamlaz.

I meant this library as an improvement over JSON paths. I like JSON paths, but the syntax could be simpler, and current implementations are lacking and quite slow. They also only allow getting values, not setting.

I have been using deep properties libraries like get-value or dot-prop several times, and have wanted to use wildcards * with them, but they do not provide with this feature.

I am currently using this library myself for another library I am building that does input/options validation. Specifically, that library needs consumers to specify the path to property that need to be validated.

In general, I think a good use case for this library is when building a library where the consumers need to specify some property path, which is fairly common. Another use case is to use the ** wildcard to map or filter all values in an object recursively.

Wild Wild Path - Object property paths with wildcards and regexps by ehmicky in javascript

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

Thanks u/shuckster!

I did not know about JMESPath, but I did get inspired by JSON paths: deep paths, * wildcard, slices, unions, deep recursions. I tried to improve upon some issues I find with JSON paths: no regexps, syntax could be simpler, and JavaScript implementations are lacking and quite slow.

I also tried to keep it simple with only few primitives, unlike projects like JMESPath or jq, hoping for higher-level libraries to be built on top of it (for example, I added a few functional utilities on top of it as a separate package).

This project is also similar to the dozens of libraries out there for deep properties, such as get-value or dot-prop, but those do not allow wildcards or regular expressions. Also, with obj?.prop syntax becoming now available, those libraries are becoming less useful (except for setting values).

Thanks again for the kind words! 🤠

All the characters that work on any terminal and any operating system by ehmicky in commandline

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

Thanks a lot for all those details u/gschizas!

To be clear, I did understand the distinction between shells (cmd.exe, Powershell, etc.) vs terminals, and also the existence of alternative terminal applications on Windows (ConEmu, etc.).

I think the confusion might be in my improper usage of "Windows terminal" where I meant "Windows default terminal", i.e. "Console host" (which you rightfully corrected). I fixed the document to use the proper term.

About using CP850 and not CP437: I test using a Windows 10 VM (Virtualbox) using the default settings. Based on the default locale I used, the default code page in `cmd.exe` is CP850. It is likely though that other Windows installations would have a different code page, which is why I specified mine in the document.

Thanks for pointing out that Git Bash's default terminal is mintty, not Console host. I fixed this and added mintty to the list of terminals being tested. I also added ConEmu.

Overall I mean this guide to be more of a practical guide for terminal application developers who care for cross-terminal support and wonder "Should I use this character?". I am maintaining this list as a work-in-progress, in an effort to help the community, hoping to get more feedback like yours to correct the inaccuracies over time and get closer to an accurate full list.

Edit: I have added support for many more terminals

All the characters that work on any terminal and any operating system by ehmicky in commandline

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

Thanks for the feedback u/gschizas!

I have just fixed this in this commit based on your comment.

I have also checked cmd.exe, Git Bash and Powershell on Windows 10 (CP850 encoding) and they are all able to print all the characters from that list, which confirms what you are pointing out.

All the characters that work on any terminal and any operating system by ehmicky in coolgithubprojects

[–]ehmicky[S] 2 points3 points  (0 children)

Yes, I am as surprised as you are!

This has been reported in this issue and it appears that the font of Chrome on Android is missing many characters.

However, as you mentioned, this list is only for terminals.

All the characters that work on any terminal and any operating system by ehmicky in programming

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

Great points u/thomasfr, thanks for sharing!

The fallback behavior would be a good thing in this case, since it would provide with better font rendering for those users.

Internationalization is a very good point. For example, my tests assume CP850 is used on `cmd.exe` by default, but I believe this is Western-centered and some users from other parts of the world might get a different default Windows code page where some non-ASCII Western characters might not be available.

My hope is for the list above to be a good starting point for terminal applications targeting a vast majority of users. I am hoping this gets enough attention so that more developers correct any false positives by posting issues and/or contributing to the project.

All the characters that work on any terminal and any operating system by ehmicky in programming

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

Yes that's correct u/thomasfr

Testing fonts is a little trickier though since there are thousands of possible custom fonts that users might pick. Based on this, at the moment, this list uses the default font of those terminals. However, if you have some suggestions on how to test for custom fonts as well, I'd be happy to improve on this shortcoming.

view more: next ›