Sup Eddie, the actual motivating example is we finally nixed Pandas from Data Ingestion, now reading excel files takes 2 seconds instead of 2 minutes. However unfortunately your
> Sup Eddie, the actual motivating example is we finally nixed Pandas from Data Ingestion, now reading excel files takes 2 seconds instead of 2 minutes. However unfortunately your
I shall pass this information along to my sleep paralysis demons. They'll be glad to hear it.
My limited and fuzzy recollection is that while the freq response of most cheap to mid speakers is balls, the freq response of most cheap mics is quite good - sure not studio quality, but much better than the equivalent speaker.
I think I did have some time early -90's someone did alternative C0.lib which actually when you linked it with your programs it made much easier porting some *nix software to MS-DOS. No need to make modifications command line handler, as that modified startup-library as I think it's or was called, did what was needed.
It was then COMMAND.COM ie. Dos command line did not do that. And there were alternatives like something called 4DOS which I did never use, but those could have done it. Or did they?
I have't used Windows for quite long time. And I do not know if CMD.EXE or PowerShell whatever its name are any better. Maybe someone knowing would like to comment this.
This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
Powershell is a completely different model where native commands run in-process, you can import commands and invoke APIs from arbitrary .NET assemblies, and then the PS runtime handles all argument parsing (and many other things). But it also lets you invoke and interop with arbitrary command-line executables and then those do their own parsing like they always have.
>This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
So is that CreateProcess much different from nix execve() which passes just a pointer to string of executable first followed by pointers to arguments *argv[], and process environment same way *envp[]?
Thus it is the shell which responsibility is to expand all wildcards before passing to that executable arguments nix systems, which do not expand any wildcards itself before passing to executed program.
I'm no Windows programmer so, genuinely what's the difference from point of executed program and just that Windows any shells do not expand wildcards etc. ?
My previous post when I did mention that alternative c0.obj (not lib, sorry) that I for example had about 36 years ago from somewhere was a nifty modified trick which took that plain dumb MS-DOS COMMAND.COM passed string and instead just making it a char *argv[] array first expanded wildcards before your main() got control. It did work very well and saved quite bit of effort when I ported some tools to MS-DOS and I think there was another version of it for OS/2 (1.something) that I used also.
I did not have to add ported software from unix any command line expanding code myself because that alternative startup c0.obj did it for me. Shame I do not remember where I got it and who did it, but it was really good. Now thinking of it perhaps it was from Compu$erve some forum or WSMR-SIMTEL20 archive.
I remember that also Fabrice Bellards lzexe and something spawnsq() (not sure about exact name any more) library also was in use. The latter swapped (saved out file) out running most of MS-DOS program before executing like execve() and freed a lot more memory to run that other program then loading it back when called program was done. I think it used something like 8k memory while resident when other called was running. Which was often enough and no need do any horrible .BAT rewrite tricks to able to accomplish same functionality.
PowerShell has a built-in command parser that all cmdlets share (provided commands; `function` based command scripts; so forth) and it's in a C# library that other .NET-based CLIs can import if they like (though today it's still not that common in writing .NET CLIs to use PowerShell's command parser and not a simpler one or the new-ish System.CommandLine which also doesn't quite resemble PowerShell's built-in one).
no, Windows still leaves that to the program. Usually handled by the msvc runtime for argv/argc, but the base windows API is GetCommandLine, giving you a single string.
Jains in India are heavy consumers of dairy products. They consume honey too. Most of them would avoid vegetables that grow underground and avoid the use of leather. They’re generally a bit closer to orthodox Hindus in practice.
Questions for those who like the grid layout of virtual desktops - how does it (or should it?) interact with multi monitor setups? Feels like this would break or at least compromise the spatial metaphor.
- Each monitor has own grid?
- The VD 'spans' the pair of monitors?
- VDs only on one monitor?
- The monitors form a fixed 'window' into the grid?
I have a separate grid on each screen. Each with different grid sizes. I have a 3x3 grid on my main display a 2x2 grid on my display to the left and leave my laptop display with no grid constantly locked to my works video conference application.
It works well for me, but as you can see from the comments everyone is different :)
I disagree with the theory that scrolling frame rate doesn't need to be smooth for scrolling to feel smooth.
On mobile it kinda does. Scrolling diffs on mobile just kinda feels crap.
I have been spoiled by years of engineer hours spent getting scrolling to be 60- or even 120Hz smooth to match my finger, and diffs just.. isn't.
I know this is frustrating to hear, and that this is technically compounded by mobile probably having the lowest device performance to be playing with too, but.. There you go.
> disagree with the theory that scrolling frame rate doesn't need to be smooth for scrolling to feel smooth
It's possible you might be misunderstanding what I was trying to say here because 120hz scrolling on a 120hz device was the goal and why one of those virtualization techniques was not acceptable to me which lead me to coming up with a novel workaround to this problem (Inverse Sticky Technique).
CodeView uses a system that allows scrolling to update at your native framerate (120hz) WITHOUT needing Javascript needing to keep up at 120hz. If you're seeing stuttering while scrolling on https://diffshub.com would love to know more context (device/diff link/etc) because that is very much NOT our experience.
Even the linked ghostty PR on your home shows this - this is Firefox Android on a Nokia XR21 / TA-1486.
It's not unuseable, but it definitely feels like 'js hacking my scrolling' and not a native surface flinging around.
The experience is actually worse with smaller movements, i guess because my brain is more conscious when breaking the 'finger physically moving the text' illusion.
I don't mean to be dismissive - you're working on a really hard problem, and you're clearly approaching it with a mindset of perfection. I'm posting because I know you're probably able to solve this too :)
Edit: as a point of (unfair) comparison, the codemirror Huge File demo works fine: https://codemirror.net/examples/million/
It does suffer from the occasional partial paint when quickly coasting, but I'm not bothered by this at all, it's far less intrusive than dropping frames / stuttering / etc.
Just to be clear tho, we don't actually scroll jack, native scrolling works as it should and content should move with normal gpu composited scroll. That said, it's possible that loading that much data into memory may be causing causing knock on effects somehow that are just slowing everything down.
Matters a great deal on desktop too, and laptops for that matter. Even more on platforms like macOS that smooths scrolling by default too, but very noticeable on Windows and various Linux distributions too when native scrolling is janky/choppy, and it frustrates even casual users.
> I chalked it up to a power trip and the indignant behavior that comes along with it, as it is especially embedded in the culture of the country that I'm based out of.
That's a very globally-conscious way to refer to the USA!
I have a consumer motion-triggered camera that is armed 24/7 and records for 30 seconds after each trigger. It has WiFi and serves playback itself, as well as of course video encoding. It's probably running Linux though i haven't verified.
It runs off a 25cm square solar panel screwed to a wall that only receives direct illumination for 5 hours a day, and is not in any way optimised beyond 'that looks roughly like it's pointing at the sun'.
I have often wondered if Chinese is a much 'better' language for LLMs - every character is a token, boom you're done. No weird subword nonsense, no strange semantics being applied to arbitrary chunks of words.. I feel like there must be benefits to being able to have the language tokenized in what must be very close to 1:1.
Yes, it is. In fact, I made a small application to reduce the token consumption for translating from one language to another, and I even invented a language called Tokinensis, which is a mix of different languages, and I ran my own tests with savings of 30%. Chinese is amazing because they encapsulate a ton of information in a single symbol, so you can save a ton of tokens.
Are you able to use the language practically? How would that work? You prompt it in english but tell it to work in tokinensis? And then translate back at the end?
Yep, actually, is a mixture that works. I actually run for my day to day, and I can save tokens, maybe not that I will expected, but it works, you can try if you wish https://translation.tokenstree.com.
I'm not sure what the state of the art is today, but 15 years ago I worked on a cross-lingual search engine - a challenge with Chinese was that ngram-like models for detecting common language errors (such as typos) were simply ineffective due to this.
We found a lot of gain by having ranking features based on Pinyin to detect typos/misspellings due to homophones (and similar sounding words). I was investigating stroke decomposition to try to be able to detect near homographs, but wasn't able to find any good libraries at the time.
I could imagine the homophone issue is especially relevant for spoken input to LLMs. LLMs are good enough that they're usually right, so it's probably less of an issue, but in English I can have crazy typos and everything just works, I am curious how well that would work for Chinese, since I suspect it's a harder problem by far due to the lack of subword tokens?
> TODO: rewrite this entire service
remains.
reply