HackerTrans
トップ新着トレンドコメント過去質問紹介求人

codelobe

no profile record

コメント

codelobe
·2 年前·議論
Holo Display: generate the refractive voxel via ultrasonic convergent propagation fringe pattern, and light the voxel with IR that becomes higher frequency visible light color at point of interfearance/intersection.

PrHoteph: hyperplanes are your friends, may they guide your long distance acoustic whisper / ultrasonic voxel intersections.
codelobe
·2 年前·議論
Distinguished seekers also searched: "NOFORN" "EYES ONLY"
codelobe
·2 年前·議論
Ooin called; Wants the Yggdrasil equation back... TREE_LIFE=FILE_TREE

The meaning of life is what life is and does. Life experiences reality and message-passes thee grokked data to the future.
codelobe
·2 年前·議論
Thanks for your suggestion!

I tried cats.youtube.com also, but it's just like my IRL cat.
codelobe
·2 年前·議論
>a certain number of plants will form a rough line as seen from the earth

Ah, a fellow galactic hitchhicker. I too am a fan of dead-reaconeering in favor of astrolabian navigation.
codelobe
·2 年前·議論
[x] Strongly Agree.

Also, the focus on how these devices are increasingly consumer only instead of me being able to use my device to create

Disclaimer: one of my goals is to build apps for my machine on the machine itself. I had this working on the now defunct Firefox phone OS (Its apps were deployed as Zipped HTML/JS and related resources -- I cobbled together a dev environ out of a few browser based tools).

TL;DR: I'm a tool-using creator-type species, The modern "CONSUME ONLY" device craze makes my eye twitch; Ads that reinforce destruction of tools make me want to join fight club.
codelobe
·2 年前·議論
Indie Gamedevs can do their own Voice Acting? See also indie film, same use case. Actor dies / hit by buss before a work is finished - Create a few more lines posthumously (it'll be in the fine print of the contract that you allow voice & image fakes in the event not able to do them). Satire, Pranks, and alleged pranks (stuff that makes folk laugh).
codelobe
·2 年前·議論
Maybe the Sumerian or (blue-skinned) Vedic Gods saw some giant sentient machine life, and went out of their way to honor these "Angels" with many eyes and huge wings by creating what we call insects (in addition to Humans [Hanuman's ilk]).

When you transcend the physical form into a body of energy (hint: OR=constructive, XOR=deconstructive, NOT=XOR(k,1), NOT( OR(j,k) )=NOR(j,k), NOR=Functionally Complete, ergo EMF or even sound can be Turing Complete), then as an energy body you may want to interact with physical forms again w/o ionizing them; So you'll create (sentient) machinations that can do tasks. Because your design parameters include survivability across large thermal and pressure gradients you'll [re]discover giant robotic beetle design.

If you'll excuse me, I've got to tend a Kephri (beetle of remanifestation) who is eagerly attempting to choose an Odin to ride this 6-legged "Steed" next Ragnorok.
codelobe
·2 年前·議論
The upstream who manages their name::location mapping?
codelobe
·2 年前·議論
Usually I would agree. I typically make a "Crash-Course in $PLATFORM" document while keeping notes. These I very commonly reference in order to externalize my memory since it seems to be approaching capacity. I don't care about Ruby on Rails, but once I did, and I can reference my notes if I ever need to touch that platform again.
codelobe
·2 年前·議論
I never refactor for the purpose of refactoring.

If I can do things better, and I usually can, it's because I have a more performant higher level algorithm or set of low level optimization strategies to apply.

I agree, Those API organizers are just creating future crap for others. However, objective benchmarks showing my changes yield 10 to 100 thousand times quicker execution than the old method mean the legacy code was crap...

Legacy being crap is not always the fault of devs. Back on Z80 and similar, before execution caches were expansive and expensive to invalidate, the short circuiting && and || bool operators made sense. Now that invalidating the CPU instruction cache with a jump is far more expensive than just running the ops these short circuits are trying to avoid, it is better to just use bitwise | or & instead of boolean || or && unless there are needed side-effects (really should make the conditional evaluations into proper branches [if statements] anyway, if only for clarity). Benchmark it and see. C is stuck doing LOTS of old and busted style logic, and coders imagine their compiler is doing a lot of magic voodoo under the hood that simply isn't happening. There's loads of compiler optimization hype.

Sometimes the hardware or platform just shifts underneath Good Code and turns it into Crap Code.
codelobe
·2 年前·議論
Join the trust graph...
codelobe
·2 年前·議論
Remember when .PNG included a gamma correction to try and make a more accurate image -- Appearing as the creator viewed the image...

And then WE ALL REJECTED THIS INSANITY because it made .PNG images a pain in the butt to work with since the gamma corrected image wouldn't match the RGB values of the surrounding document (see: CSS color codes). Then Ye ol' .GIF enjoyed being the pixel perfectionist's choice of image format for the web for quite a while longer. I once was forced to write a script that chopped up a 24bit images into a bunch of 16px by 16px .GIFs (one palette entry per pixel, 256 total).

Digital doesn't usually need to be restored as long as it is replicated often enough (before bit-rot sets in). However, I've got a large number of tools for restoring spinning disks (migration to new hardware isn't easy for the average end-user).

Let's say a modern game came out that had a capability to demand of a GPU more polygons/paritcles than capable today... but in the future those capabilities might exist. Digital media could be improved by adding more/better compute resources (if originally designed to scale, that is). Then there will be curmudgeons (like me) that think things were better before the edge users' hardware became a giant supercompute cluster / distributed storage...
codelobe
·2 年前·議論
My "solution", to the example config error: delete everything after the first close curly brace.

Works on my machine... Ship it!
codelobe
·2 年前·議論
> The second front end, the one I’ve actually published on GitHub [ed: link now defunct, since the JavaScript front end was scrapped], uses JavaScript for the drawing, and Neon Bindings as a Rust-to-JavaScript bridge. It’s packaged as an ElectronJS app because ElectronJS apps can be built and deployed to all the major platforms, which was an essential goal.

Ugh, all that just to provide a HTML5 canvas pixel buffer to a native (Rust) app. The pain of doing simple input/audio/graphics on GUI OSes today... We've made a wrong turn. It's back to TUI for me. Would you accept sixel graphics for the DMD 5620 Terminal's display?

> The main pain point so far has been working with the JavaScript ecosystem, which has hitherto been an enigma to me. I’ve found ElectronJS to be somewhat painful to work with because, although it is indeed cross platform, there are many caveats. The primary issue is in recompiling native NodeJS modules across platforms, which took some trial and error to get working correctly. In fact, I still haven’t produced a Linux app bundle yet, because the build keeps failing in ways I don’t quite understand.

> In general, it feels like JavaScript and NodeJS modules are a lot more brittle and error-prone than the code I’m used to working with.

Seriously, its $CURRENT_YEAR and getting a simple cross platform windowed graphical application up and running is still a pain? Hey that emulator community, say, MAME or BSNES might be of help -- oops, Rust... yeah, maybe not? Why isn't a simple GFX/audio/input API a must-have in any [new] language today?
codelobe
·2 年前·議論
Indeed. When I ask (now retiring) office workers they typically agree that WordPerfect 5.1 is the best document editor our Earth has to offer.
codelobe
·2 年前·議論
Well, Red-Black algos are supposed to be better at cache-locality, but I have an AVL-tree impl (ugg jokes, again: AVUL (ALV) is the "evil" tree of "forbidden" {carnal?} wisdom from The Garden of Eden, associated with Yggdrasil/Odin [a "pagan" God of Balance & Pleasure]) that has improved cache locality since its data nodes can be made to contain AvlTreeNode structure(s), and avoid copying any data, as users are made to provide node alloc/free function pointers to this C lib's Tree "constructor". This means, for real example, I have a command line option interpreter with const structures for each option, each node added to two AVL trees (to find by unicode codepoint and find by length prefixed unicode string name). C++ STL Map implementations can not conditionally generate code for const types and thus do needless coppies, whereas my C collections API causes 0 calls to malloc (vs STL's 2 mallocs per node insert). NodeAlloc is just pointer math to get at the apt AvlNode, NodeFree is NoOp.

Benchmarking the STL vs my AVL approach results in millions of times quicker cmd line opt interpretaion (for my gnu getopt replacement lib) due to reduction of pointer chasing...

And if I want to do something similar in C++ (overloading operator new), I have to instantiate multiple copies of the Tree code, one per each "class". What if I want to use my Sortable class with various allocators: OBJ cache, dynamic GC'd, static (no alloc, its in the .data section already)...? Well then I get N copies of EXACT SAME template code for no real reason, only differing in delete and new [con|de]structors. The cache-misses galore this causes isn't even fair to bench against the C w/ fn() ptr approach.
codelobe
·2 年前·議論
[insert confused trollface]

> ffmpeg There is certainly a few hundered exploitable vectors in that program alone... to say nothing of the rest.

When in doubt, spin up a VM to run the random untrusted thing -- And then go read its mailing list/issue tracker for known VM escaping exploits. I have a machine setup to test malware, so I just hit my "airgap" switch to isolate the system from my network once the questionable code is in place and ready to run (potentially amok). Study-up about ARP-poison attacks, and remember ARP does not transit to upstream routers/switches (Y "combinate" your network for fun and profit).

Before you assume non malicious simple text output, consider "ANSI" escape code complexity as an intrusion vector for whatever terminal you run. I've got "0-days" for this going back to MSDOS: ANSI Bomb => arbitrary CMD entry. You don't have to take my word for it, your terminal of choice is most certainly vulnerable to some ANSI/escape code related exploit, look it up.
codelobe
·2 年前·議論
My first thing is usually:

    #0: Replace the custom/proprietary Hashmap implementation with the STL version.
Once upon a time, C++ academics brow beat the lot of us into accepting Red-Black-Tree as the only Map implementation, arguing (in good faith yet from ignorance) that the "Big O" (an orgasm joke, besides others) worst case scenario (Oops, pregnancy) categorized Hash Map as O(n) on insert, etc. due to naieve implementations frequently placing hash colliding keys in a bucket via linked list or elsewise iterating to other "adjacent" buckets. Point being: The One True Objective Standard of "benchmark or die" was not considered, i.e., the average case is obviously the best deciding factor -- or, as Spock simply logic'd it, "The needs of the many outweigh the needs of the few".

Thus, it came to pass that STL was missing its Hashmap implementation; And since it is typically trivial (or a non issue) to avoid "worst case scenario" (of Waat? A Preggers Table Bucket?), e.g., use of iterative re-mapping of the hashmap. So it was that many "legacy" codebases built their own Hashmap implementations to get at that (academically forbidden) effective/average case insert/access/etc. sweet spot of constant time "O(1)" [emphasis on the scare quotes: benchmark it and see -- there is no real measure of the algo otherwise, riiight?]. Therefore, the affore-prophesied fracturing of the collections APIs via the STL's failure to fill the niche that a Hashmap would inevitably have to occupy came to pass -- Who could have forseen this?!

What is done is done. The upshot is: One can typically familiarize oneself with a legacy codebase whilst paying lip service to "future maintainability" by (albeit usually needless) replacing of custom Hashmap implementations with the one that the C++ standards body eventually accepted into the codebase despite the initial "academic" protesting too much via "Big O" notation (which is demonstrably a sex-humor-based system meant to be of little use in practical/average case world that we live in). Yes, once again the apprentice has been made the butt of the joke.
codelobe
·2 年前·議論
To lessen the cost of the first step that begins The Thousand Mile Journey: I plan to do everything at least twice. Leave room for failure in the prediction to (at least partially) avoid the planning fallacy.

https://en.wikipedia.org/wiki/Planning_fallacy (if you haven't encountered this one weird quirk yet, it's a must read/skim). I believe most mammals tend toward optimism... They naturally have less fear of doomed endeavors.

I had an essay on Emergent Design Principles around here somewhere... For instance, I do a quick and dirty stab in the dark to map the problem space. Then totally rewrite and refactor now that I can make a more educated guess. Right then I generate the API and all (public function stubs), organizing and documenting everything. Management will demand I "ship it" without full docs and full of kluges otherwise...

I'll save the rest of that for a more on-topic thread. The gist is that procrastination can be countered by allotting time to play around in the problem space (incorporate procrastination into workflow -- can't beat it, join it). At worse I try a deliberate attempt at failure (well I knew it wouldn't have worked, but it would have been cool if it had), and at least I got myself into "code mode" doing something at all. No fear of failure, since I planned to fail that time anyway. Then I'll at least know a bit better the "lay of the land" (problem space features to fit against). It's oft the first step for me that's the hardest.

My favorite trick is to have at least one side project that I work on as procrastination of doing main projects. Without fail I'll be worrying about the main project enough that I'll realize some side-project procrastination-code I've just written shows an elegant way forward in the main project and I can no longer resist the urge to see it in action. At the least I'll be making some manner of progress, and getting closer to that "Zen" state wherein I do my main project work.