treesciencebot

That is the part that baffles me. There might be an argument against when this becomes unsustainable (e.g. the number of bytes inside a file is actually smaller than the number of bytes the metadata associated with that file takes) but that can be solved quite intuitively by making user pay for it (essentially they should be counted towards the same usage limits, if they aren't already?).

> It's a proprietary versus open source argument. You can build a mk4 clone for much less than the price of a Prusa-branded one, as everything is open source. The higher price tag is like a donation to open source.

I would say the higher price tag is more like "Prusa" using its name as a quality assurance system where if you want to get something working without much hassle (since nearly every other mk4/mk3s clone that has been out there really really sucks except the ones from Prusa) you have to pay the premium.

This is not to say they are necesarrily doing a bad job on open sourcing or abusing, but just a mark that "open source hardware" doesn't necessarily benefit the customer as much as "real world features".

Indeed. I always thought they deferred the launch of any new model after X1C in order to take the true "just works" crown back (with the hopes of it would be something like Intel/AMD feuds where the monopoly had finally came to an end and customers can finally see some real competition). But apparently it is just a classic Prusa printer with better parts but still a very very high price to usability ratio (compared to Bambu Lab P1P or X1).

Intel must feel pretty bad about messing up the whole chiplet thing since that advantage allowed AMD to overthrow them in just under a couple of years. And it seems like they still seem to be adjusting into it since compared to Zen 4 SKUs, SPR seems like a horrible design that won't scale well (and doesn't according to pretty much all benchmarks).

AMD can simply make a smaller core and release a new CPU with 128 cores (Zen 4C -- higher density core clusters consisting of smaller Zen 4 cores [with less L3 than a normal one]). On the other hand, for nearly every Intel CPU it is a whole new design/engineering mess.

I hope they don't fall to behind on this, otherwise we might see yet another monopoly (e.g. AMD not releasing a consumer grade Threadripper is the first indication that they kind of feel safe on this side since even their multiple years old SKUs offer far more value brand-new SPRs).

I wonder whether the upcoming APUs will feature 3D cache. Assuming it server pretty well in a gaming scenario (and more so when the CPU and GPU is sharing the same memory bandwith) it should be a pretty clear win. And since these chips are meant to be drawing less power than the general purpose ones, I guess having another layer of 3D v-cache would not constitute as big of a problem as it does on the desktop platform.

2 x 32GB ECC UDIMM DDR5-4800 RAM is going around for ~280$ here (including a %20 VAT, so I'd assume it would be a little bit cheaper in the states). Not really unreasonable considering regular DIMMs (albeit with higher speeds like 6000) going for 400$ for the same configuration.

I was also really curious about Linux benchmarks; and seems like Phoronix, a Linux-centric tech review outlet, also released their own reviews with tons of game and productivity benchmarks running on the latest kernel. https://www.phoronix.com/review/amd-ryzen9-7950x3d-linux

Yes [1]! IIRC the iGPU is located in the I/O die [2] which is pretty much the same in all their consumer SKUs (so I don't expect any changes in either memory controller or the iGPU for their X3D models).

[1]: https://www.amd.com/en/products/apu/amd-ryzen-9-7950x3d [2]: https://chipsandcheese.com/2023/01/05/amds-zen-4-part-3-syst...

As someone who only needs raw CPU single-thread power when waiting for an executable to link (while using a stock linker for rust and taking a release build takes minutes, which is not much time but also a lot of time), I wonder whether I should go with the new M2 Max's or build a desktop computer (%99 of the time, I will be sitting my desk) with these shiny CPUs to get the most single-thread power (the parallelization does not really help in my workloads [esp compiler stuff, since everything is pretty much incremental and once I take the first build then it is only linking]).

It will probably be post 3.0, since the underlying HTTP interface we use (https://pypi.org/project/requests) does not support HTTP/2. We are currently discussing how to migrate from that to something like httpx, without causing any change of user-visible behavior.

(HTTPie maintainer here)

You might be in luck since Nested JSON support is going to be star feature of our upcoming release. Here is a sneak peek:

$ http --offline --print=B pie.dev/post \ search[type]=client \ search[stars]:=50000 \ search[platforms][]=Web \ search[platforms][]=Desktop \ search[platforms][]=Mobile \ search[platforms][]=CLI

{ "search": { "platforms": [ "Web", "Desktop", "Mobile", "CLI" ], "stars": 50000, "type": "client" } }

We are rolling a brand-new mini-language that integrates really well with the existing request building syntax, but also features stuff like JSON type-safety and amazing error messages for basic syntax errors.

Thanks! Glad you liked it.

Extra clarification: I'm well aware the concerns about tokens vs CST vs AST, that is why I decided to write down a library that does refactors on small code fragments rather than just unparse()ing everything. CST is definitely more sound in terms of preserving these details but dealing with it much more complicated than the regular AST. Refactor's README these also mentions other libraries for complex refactors: parso, LibCST, FixIT

Thanks for the suggestion though just want to clarify, I am also one of the maintainers of parso :-) (and also the ast module in the standard library)

It would probably be better if you can just write a typescript parser, and then you can transpile type script AST directly to Python AST and use ast.unparse() without any additional libraries.

Indeed! I also would suggest people to use a CST implementation (parso / LibCST) instead of refactor if they intend do large scale refactors, but from what I can see in my previous attempts (e.g teyit, a unittest assertion formatter) when you deal with small code fragments (a single expression, or a small statement) then you generally don't need to worry much about the style. The only concern is the literals (especially strings, which there are a few different variations of the same AST) where you could resurrect them back from the token stream (which the CustomUnparser representative in refactor allows).

The real start point for this project was to find / replace all type(<literal>)'s in CPython codebase with type(type(<literal>)) (e.g type('') would become type(str)) which is very light weight transformation, and I was able to write a script which did it without having any major problems about style on over 2000 files. Here it is for the reference: https://github.com/isidentical/refactor/blob/master/examples...

Also one thing to note here is that; in the last couple of years, thanks to black (and yapf), the adoptance of code formatters have really increased which is very nice for custom refactoring tools like refactor since the end-code would be refactored anyways so that means if you convert a multi line call, or a list to a single line version then the formatter you use probably reformat that segment anyways.

But thanks for authoring Bowler! It is a very cool project.

I haven't used bowler, but from what I can see it is using lib2to3 (through fissix), which can't parse newer Python code (parenthesized context managers, new pattern matching statement etc.) due to it being using a LL(1) parser. The regular ast on the other hand is always compatible with the current grammar, since that is what CPython internally consumes. It is also more handy to work with since majority of the linters already using it, so it would be very easy to port rules.

Yes! I love to do transformations with lib2to3, but unfortunately it is now deprecated. As I've stated in the README, for complex refactorings I also would personally prefer working with CST (probably through parso instead of regular lib2to3), but for refactoring small fragments I wasn't able to observe major differences in formatting in big codebases. Thanks for sharing this btw!

Author of this project here (and also a CPython core developer FWIW), for many aspects (including the AST) PyPy follows CPython closely even on implementation details so `refactor` would probably work out of the box once PyPy releases 3.9 (the latest stable version for PyPy is 3.7, and 3.8 is on the way!).

This has been brought up: https://github.com/python/cpython/pull/26264#discussion_r640...

Though personally I would dislike this, since every time somebody mentioned about type hints they commented on the property of them not causing 'ANY RUNTIME EFFECTS'. Of course the specializations come with guards, so if the annotation is wrong it is just going to work as a mispredicted option and fallback to the generic implementation though the concept of them changing the initial layer of optimizations is not something that I'd rather see in 'the Python language. PEP 563 even moves this properties forward and renders them totally uneffective in the eyes of the interpreter.