News for hackers. Stuff that matters.

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.
Re:RustPython on Wednesday February 07, 2024 @01:05PM (#39291918)
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?
Re:RustPython on Wednesday February 07, 2024 @12:57PM (#39291789)
Thank you for working with RustPython. I believe kybra made RustPython wasi support a lot more stable.
Re:RustPython on Wednesday February 07, 2024 @12:52PM (#39291697)
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%.

Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @03:23PM (#20033415)
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.
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @03:05PM (#20033249)
agree
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @02:58PM (#20033194)
Thanks, I will fix it
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @02:56PM (#20033179)
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'
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @01:38PM (#20032419)
Will it be correct expression if I fix it to outside? https://github.com/youknowone/ring/pull/133/files
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @01:35PM (#20032391)
no dogpile lock but get_or_create exists with different name: get_or_update
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @01:33PM (#20032368)
I want to say "not yet". It is shame that I didn't know docpile lock.
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @10:26AM (#20030364)
Thanks for the great advice. I never thought about this problem.
Re:Ring: Advanced cache interface for Python on Tuesday May 28, 2019 @10:21AM (#20030282)
Actually it is common requests from the users but it wasn't solved yet. I will check the project, thanks!

Older »