youknowone

The article is a bit misleading.

The new law requires the installation of solar panels in all *public* parking lots operated by the government. I checked this through local news sources.

In South Korea, there are already incentives to install solar panels on buildings, including parking lots. If you operate a solar power system with a capacity of over 20 kW, you can sell the generated electricity at prices higher than the market rate thanks to government support programs.

Despite these benefits, many parking lots in South Korea still do not install solar panels. This is mainly because, given the country’s high population density, most parking lots are located on land that is considered potential development sites. Once solar panels are installed, it becomes more difficult to change the land use later for development purposes, and the owners would also have to bear additional costs for removing the panels.

Congratulations on having been born into an environment where you’ve had the privilege of becoming so fluent in English that you feel comfortable complaining about other people’s stylistic choices in writing. Note: This comment was translated using an LLM.

Our team tends to drilling on code more than writing. I know it is not a strategic good way though. Any idea what do you expect to see on the blog?

Thank you for working with RustPython. I believe kybra made RustPython wasi support a lot more stable.

If Python community and CPython developers were more open to PyPy, many things could be changed. A group of people talks about how good having a third-party interpreter in Python community while the whole Python eco-system is heavily relying on the old (maybe good-enough) Python C API.

Whenever I meet a C API issue on RustPython project (yes, I contribute to RustPython), I think about PyPy, and check what's going on C API, and realize 15 years was not enough to change things. Now the momentum of PyPy is not that strong as before. I believe Python community lost a huge chance.

Hope HPy or something can save PyPy. Maybe RustPython also will get a chance around there.

I translated a survey about LK-99 papers to English

https://hackmd.io/DMjYGOJFRheZw5XZU8kqKg

The article is mostly about people and their motivation. And why it is going with noise and trouble.

Please feel free to ask about the article if your machine translator doesn't work for specific sentences.

Thank you. That sounds like an important feature.

RustPython itself has more bugs. e.g. `dict()` doesn't work well on some multithread scenario yet.

RustPython didn't adapt the optimization designs yet. One of the current major goal is this optimization: https://github.com/RustPython/RustPython/issues/3244

RustPython even cannot run `1+1` without calling `int.__add__` yet. And it is working on https://github.com/RustPython/RustPython/pull/4615

So it still has long way to go not C vs Rust but from the design level.

RustPython doesn't have working JIT in the common meaning of JIT yet.

RustPython doesn't use GIL at all. RustPython use individual lock for each data type. So RustPython has more multithreading bugs.

Windows utility. Working for AMD chips with multiple L3 cache clusters.

By the developer, it boosts stellaris 50%.

preview: https://twitter.com/js1024fun/status/1547183423239897089

This is insane.

Thanks. I didn't think adding them to the why page. For now, the actual projects work like:

  if DEBUG:
      ring_cache = functools.partial(ring.dict, {}, default_action='execute')
  else:
      ring_cache = functools.partial(ring.redis, client)

  @ring_cache(...)
  def ...

Which is not very good solution at all. I will fix the design and properly document it. Thanks for suggesting why page and mock section.

agree

Thanks, I will fix it

I agree they are missing features but still they are easy goal with small refactoring so it will be solved soon. Issue #129 is about application default. After that, dryrun is just replacing default action from 'get_or_update' to 'execute'

Will it be correct expression if I fix it to outside? https://github.com/youknowone/ring/pull/133/files

no dogpile lock but get_or_create exists with different name: get_or_update

I want to say "not yet". It is shame that I didn't know docpile lock.

Thanks for the great advice. I never thought about this problem.

Actually it is common requests from the users but it wasn't solved yet. I will check the project, thanks!

Because I didn't write one before, I made a new one with the projects I remember: https://github.com/youknowone/ring/tree/feature-table#featur...

This is a good point. asyncio backends now partially take an initializer function because calling await at importing time is a kind of non-sense.

I think it needs to take also a client-configuration or a client initializer. Any advice from your use case?

It doesn't have any cascading feature for now. @ring.redis_hash can be helpful for certain cases, but it is not a generic solution.

In future, there is a plan for indirect invalidation. It will use another key to decide expiration. Though this is not designed for cascading, but it will probably work for a part of them

I reviewed a few cache libraries, but this is the new one I didn't checked.

Roughly, Ring consists of 6 key features - sub-functions, universal decorator, data coder, asyncio support, consistent and readable key generation and abstract-transparent back-end access. I will check dogpile soon, thanks.

Aheui even has a JIT compiler implementation. I wrote it :D https://github.com/aheui/rpaheui

If you want details: http://ruststat.youknowone.org/

I thought Apple recommends 3-digits prefix and 'UI7' can be one. Is it weird?