I guess you meant "run all imports at startup is desirable to check if they work", but I have a hard time agreeing with that (personally I think having a good test suite is needed, whereas running more code at startup is not wanted).

As it is, top-level imports IMHO are only meant to be used for modules required to be used in the startup, everything else should be a local import -- getting everyone convinced of that is the main issue though as it really goes against the regular coding of most Python modules (but the time saved to start up apps I work on does definitely make it worth it).

Import-time side effects are definitely nasty though and I wonder what the implications on all downstream code would be. Perhaps a lazy import keyword is a better way forward.

I think the new memo compiler address' this in the most complicated way possible.

  function MyProvider({ children }) {
    const [value, setValue] = useState()
    return <Context.Provider value={value}>
      {children} 
    </Context.Provider>
  }

Wow that's really bad and make it basically useless.

I still think Zustand is the simplest state management, while staying efficient. It's similar to the old Svelte stores. But I have used many state management tools and the re-renders were not the problem when it came to speed.

It's a bit unfortunate that people out of the psychology area don't even really know that there are multiple different Psychotherapies approaches and that they vary wildly in how problems are tackled/studied (source: my wife works in the area).

You'll not be able to prove validity of the concepts behind this school of therapy themselves in any other sense, even if you would be able to identify some coherent set of concepts from all the various techniques and approaches that CBT subsumed over the years.

And certainly just because "if you follow these practices, you will maybe get better" metric does not say anything about validity of the concepts of a particular school of therapy in any case, no matter what school you're talking about.

I mean yeah, many people usually care about whether some therapy works and how well, and not whether the concepts that you're told in therapy to justify what the therapy is doing make coherent sense or can be scientifically validated, so this is usually not a problem for people in need of care. But idea that CBT's concepts are more objective than other mumbo jumbo therapies out there is just plain wrong.

Idk if my therapist used something from outside of CBT, but he definitely marketed himself as a CBT-ist. I was never given this "these practices" thing. I've solved my:

- Environment control anxiety (long story)

- Strong anxiety of being late. Eradicated via specific methods that I fully understand and were specific to me: recollecting the actual source event through pre-sleep questioning, realization of specific anxiety behavior loops (just by talking about my routines) - long preparation and inability to do anything deep 4-5 hours before an appoinment, then few times intentional being late, then later unintentional, now I mostly don't care when it's not a big deal and not my need. Can just do my things up until a notification, or miss it completely.

- Depression with one heavy clinical episode without using pills. Basically I have found a key misconception in my life, work related, and adjusted thoughts radically to a real reality rather than old made-up (which was so comfortable to people I worked with).

Is that mumbo jumbo? Cause if it is, I couldn't care less how anyone calls it. That said, I can see how different people could fail to perform the methods and ideas involved. It really requires a skill of debugging and questioning yourself. Lots of people are too stubborn to even think about being less stubborn for just a minute, ime.

Therapy school can have simplistic invalid theories of functioning of human beings, and still be useful to some people. Just like religion can be psychlogically useful to people but it's all nonsense. Whether some therapy works says nothing about rationales and theories behind it, in other words.

Whether you got better or not is irrelevant to the question of whether CBT views on how human beings function are valid.

1) It still involved structured work without which it couldn’t sort out on itself. Okay, this is still religious. I believed (wanted) that it should work, and it did. But we’re talking about modifying thinking itself here, beliefs themselves. That’s a strange area because how can you even avoid that? It’s sort of an incompleteness theorem thing. Like, a therapist changed me, but he can’t change those who don’t believe in change, while “belief” is a part of the… yadda yadda. Iow, how does one falsify a therapy, I guess?

2) Since we’re talking statistics and not structure (are we?), can it be that naturally only a part of population can be “cured”? Like, you can’t cure really bad medical cases either, and some of these are common. What if there’s a consistent set of prerequisites and “therapothropism” is not random? I guess this question is naive and there’s more to it, but can’t think of anything here.

3) In my experience, religion is much more shallow wrt to “you”, and is fixed. In a sense that cbt solutions are more “meta” and then get tailored to the personal events. While religion is usually an omnidude watching you and many others and rules and requirements are all the same. CBT actively refrains from judging and giving specific advices. Even from both-religious position, is it fair to put both on the same line?

https://github.com/apache/maven-build-cache-extension

Because in my experience, this makes Maven very, very fast.

Maven has never been relevant to the Scala ecosystem given most of the community has pretty much moved straight from ant to sbt. Only a few Spark related projects stubbornly use Maven, which is a major pain given the lack of cross-building abilities. Slow dependency resolution and inefficient use of Zinc merely add insult to injury.

> INSTALLATION AND USE RIGHTS. a) General. You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”) to develop and test your applications. b) Third Party Components. The software may include third party components with separate legal notices or governed by other agreements, as may be described in the ThirdPartyNotices file(s) accompanying the software.

One thing I don't understand is how forks (I'm actually talking about Cursor which is one I'm actually evaluatinng) are getting away with scrapping all extensions from the VSCode marketplace... I even e-mailed them but had no official position on that. Maybe they have some separate contract with Microsoft -- they do have OpenAI backing, so, maybe they have some bridge there, does anyone know? Or maybe Microsoft is just waiting to see how they themselves can profit for it and so is taking no legal action at this point?

-- disclaimer: I'm on the author of PyDev and I do have my own Python extension that I publish to VSCode and OpenVSX (https://marketplace.visualstudio.com/items?itemName=fabioz.v...)... it's completely Open Source in Eclipse, but for VSCode it's currently commercial. I discovered that's a nice way to have less people requesting support, even though 99% of it is still Open Source ;)

The general idea is that pydevd will be able to use that API instead of relying on sys.settrace (which was perceived as slow in general -- pydevd got by because it had a bunch of tricks to just trace the needed contexts but implementing a fast debugger in Python with it is pretty hard).

My initial results are still mixed -- i.e.: on some cases it's definitely faster -- such as when tracking exceptions, but at this point in all other scenarios it's still slower (it's pending a few profiling sessions and I already have some ideas on where to improve), but I'm still not sure it'll ever be as fast as the version that can hook into the python frame eval and change the bytecode for the function to add programatic breakpoints... time will tell (but that approach is also very hard to keep up to date on new python releases, so, I'll probably end up deprecating it as I don't have enough time/resources to keep it up to date).

Anyways, I have most tests already passing, but I have to do a few profiling sessions before the initial release. I guess there's no much point in saying: here's a new version of the debugger using sys.monitoring -- does the same but is slower ;P