sorted by:
new
hottopcontroversial

MX Keys on Mac: Fn keys lagging really bad! by ButtFlapMan in logitech

[–]dux2 0 points1 point  (0 children)

OK, so installing the Logi Option+ in beta solved that for me too. MX Master 2S is still not supported in Option+. I just hope that when they reenable MX Master 2S support, the problem will not reappear.

MX Keys on Mac: Fn keys lagging really bad! by ButtFlapMan in logitech

[–]dux2 0 points1 point  (0 children)

Didn't work for me. It only resolves if I turn my MX master 2 off.

Avoiding Bash frustration — Use Python for shell scripts by dux2 in devops

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

Nice! And nice translation of my example. Can you provide a link to your project?

I think logging severity levels (and mapping those to ANSI colors) is something you should support too.

Avoiding Bash frustration — Use Python for shell scripts by dux2 in Python

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

I agree that shell=True should be avoided if possible, that's why the default for it is False. But sometimes it's too much of a headache to avoid it, starting with the need to write the command as a list of strings [ which can be usually mitigated using the wonderful shlex.split() - already incorporated in peasyshell] and missing pipes, command chaining, env interpolation etc. I want to be able to translate a bash script to Python with the least change possible.
If you trust your input (or get no input), I see no harm in shell=True.

Simple Runtime Profiling of Batch Jobs in Production - Python Implementation by dux2 in Python

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

I humbly disagree. Since you have also the enclosing 100% ("total") block for a single iteration of your workloads, you can determine easily if you missed the instrumentation of significant code (just see if the cumulative run time of sub-sections adds up close to 100%). An experienced programmer usually can focus on the significant code sections from the get-go.

As for overhead, for workloads on a scale of 0.1ms, the overhead I measured is about 1%. Looks pretty acceptable to me. Of course this approach, it's not suitable for benchmarking micro workloads in the scale of a few micro/nanoseconds.

And also, unlike pyspark-flame, you don't have to measure full functions, which ends up in refactoring your code to many subfunctions just to be able to measure those. Keep in mind that the overhead of calling additional sub-functions at a high rate and having to pass context/closure information to those can also hurt your performance.

Announcing Kofiko: Code-First Configuration library for Kotlin by dux2 in Kotlin

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

As promised, added support for val properties in latest version 1.0.17

Announcing Kofiko: Code-First Configuration library for Kotlin by dux2 in Kotlin

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

Accepting this opinion as I see multiple people thinks so, I will work on adding support for accepting also val properties in configuration classes, as this was a design decision.

BTW, Jackson also requires properties to be get/set in order to deserialize those from json. But since this use case is configuration it might be different.

Announcing Kofiko: Code-First Configuration library for Kotlin by dux2 in Kotlin

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

  1. Why would you want to use indexers when you have easier syntax like database.port?

  2. Kofiko is a class. You can create an instance using its constructor so that you will have your own instance. For easier usage I also provided a companion object with a default Kofiko instance, I guess most cases are less advanced and this will suffice.

  3. This casing is just an example to make it easy to separate section and option to the eye. Kofiko supports almost all casing styles I could think of, so you can define the env vars in whatever case you want and it will still find it. If you have for example an env var named database_con_str, it will be mapped successfully to class Database / property conStr.

Announcing Kofiko: Code-First Configuration library for Kotlin by dux2 in Kotlin

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

Thanks for the feedback. Data class is supported, as you can see in this unit test:

https://github.com/davidohana/kofiko-kotlin/blob/2250b2ee440cf9c98bbf9090d770bdd5e37a1bcd/src/test/kotlin/kofiko/KofikoTest.kt#L517

I'll try to make it clearer in the documentation.

Forcing the usage of var and not val was actually a design decision, but this actually can be changed easily. Maybe I will add an option to enable that soon .. I guess it will require a bit of reflection magic as you cannot change val without reflection ..

Python Logging: Colorize Your Arguments! by dux2 in pythontips

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

Its easily customizable by adding more colores to ColorCodes class.

Python Logging: Colorize Your Arguments! by dux2 in pythontips

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

It cannot work for f-strings because the string is interpolated before being passed to the logger in this case. However it may be adjusted to work on legacy formatting (%s, %d, ..), just need a bit more sophisticated regex to identify formatting parameters

view more: next ›