Programming thread

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Hi.

I've been working on a CMS project for 5 years now. I've been working on a PHP ASN.1 parser for a year or so now. I've implemented every instruction of the ASN.1 language with the exception of the encoding rules so far. I keep running into problems when parsing ASN.1 scripts from a module on GitHub due to various formatting differences these scripts contain. I haven't touched it in a while due to me getting bored with it and wanting to work on other projects, I want to touch it but then I don't feel like doing it and would rather have someone else fix a problem for me than to bang my head on a wall repeatedly.

I know, why code your own ASN.1 parser when there are others already available? Well the main reason is that all the other ASN.1 parsers out there for PHP don't fully support the ASN.1 language and only support one or two encoding rules, mainly DER. I also wanted to challenge myself as well. I've also been trying to implement passkey support and one of the main reasons for the parser is to take the CBOR/COSE certificate, translate it so that it can be read by the OpenSSL implementation so I can verify that the certificate is legitimate.

If anybody's down to give me some advice on how I should proceed, that'd be great. It's not required but I thought I'd put it out there.
 
cigint said:
That's right, and the indirect addressing options have very restrictive requirements, always working off the zero page, and are even confusingly described in the actual manual. I'm not saying you need to stay on 65c02 forever and create 8 bit TempleOS with a 100% Aryan almost-C compiler. After you learn on a conceptual level you can graduate to a modern machine.

A dynamically typed and garbage-collected interpreted language is great for beginners because it has training wheels and the 6502 is great for beginners because it has blinders.
Click to expand...
I like the training wheels versus blinders analogy a lot, actually, it describes the "wide but shallow" versus "thin but deep" conceptualizations of targetted learning really well.
 
So I've been implementing a split reference count DWCAS atomic shared pointer for windows with the interlocked functions.

Normally, I would have loved to have solved my issue of deferred reclamation by just synchronizing with a mutex but can't do that because of unique constraints.

Facebook's FOLLY has a decent implementation but uses the 16 unused virtual address bits of a pointer for the ref count which will break when Intel or whoever decide to start using more. Not to mention they assume those 16 bits are initialized to 0 which is true for user mode but not for kernel mode virtual addresses.

Upside is my atomic shared pointer (which in STL is not lock free btw) and custom atomic generics are portable for user mode which has allowed me to do some gtests. Don't know if there were any test wizards who could suggest how to effectively test all thread interleaving and prove my implementation can't double free or use after free. I'm relying on brute force fuzzing atm
 
Last edited by a moderator:
Realistic said:
If anybody's down to give me some advice on how I should proceed, that'd be great. It's not required but I thought I'd put it out there.
Click to expand...
With parsers especially, I would need a lot more details about how you're approaching it to give more than heavily generalized advice.

As a rule of thumb, make the fewest assumptions possible about input state/form at any phase/stage of the AST building process. The same concept applies to all programming and passing data around, and I can never emphasize it heavily enough when talking to people about software design.

Edit: This book Algebra-Driven Design (libgen.li mirror) covers the more abstract theory of this last bit I'm bringing up. I saw it recommended here a while ago and agreed strongly with the principles it presented and liked how it presented them.
Higher mathematics and such is all about generalizing and abstracting—a bit like discovering core foundational principles backwards, starting from basic facts. It's tough to explain the super abstract concepts without diving into all the layers within, and it gets tougher the more you "zoom out" conceptually. I really appreciate when people take the time to lay such concepts out in a clear fashion like this; it's no easy feat.
 
Last edited:
cigint said:
x86 is a complete quagmire for a learner because on one hand it's designed to be a backwards-compatible instruction set almost back to the stone age of PC processors, and on the other it has a huge number of very specifc fringe-use instructions that'll have a learner scratching their head trying to figure out why the computer is doing what it's doing.

Instead of learning with a pure fully abstract Teletubbies assembly language, a newbie had better learn to first program a chip like 6502 which has both a fairly simple instruction set and will confront you with the very real hardware constraints involved, particularly if you emulate it at its real speed.
Click to expand...
What would you think of RISC-V as a learning option? I've had to mess with it a bit on some personal projects and it was surprisingly pleasant, although I haven't written much of substance in it.
 
August Levasseur said:
RISC-V as a learning option
Click to expand...
Really appealing option, frankly. Little of the overwroughtness of contemporary ARM and x86, competitive dev platforms, runs Linux.

Apparently the ESP32 arch is more documented now. I was reading some of that the other day. In terms of "cheap SoC", hard to beat ESP32, but the documentation is garbage.
 
August Levasseur said:
What would you think of RISC-V as a learning option? I've had to mess with it a bit on some personal projects and it was surprisingly pleasant, although I haven't written much of substance in it.
Click to expand...
RISC-V and MIPS are both really nice. I like that unlike 6502 and x86, their call instruction equivalent puts the return address into a register rather than the stack. So in every single function you write, unless that function is at the bottom of the call chain, you need to personally store (and restore) that register value at the top and bottom of the function.

edit: that doesn't sound like a good feature the way I worded it. What I mean by it being nice is that the programmer is in control of whether the stack is even needed or used on a subroutine call.
 
cigint said:
RISC-V and MIPS are both really nice. I like that unlike 6502 and x86, their call instruction equivalent puts the return address into a register rather than the stack. So in every single function you write, unless that function is at the bottom of the call chain, you need to personally store (and restore) that register value at the top and bottom of the function.

edit: that doesn't sound like a good feature the way I worded it. What I mean by it being nice is that the programmer is in control of whether the stack is even needed or used on a subroutine call.
Click to expand...
That sounds like it’d be pretty useful for implimenting tail calls or continuations. And people say imperative languages are closer to the hardware.
 
August Levasseur said:
And people say imperative languages are closer to the hardware.
Click to expand...
in a way, tail calls are actually more "low-level" than regular procedure calls
if you want to implement a procedure call, you have to fiddle with a stack structure or something so you know where to return those values when your function is done running
tail calls, however, are usually implemented as goto instructions or similar
 
Creative Username said:
in a way, tail calls are actually more "low-level" than regular procedure calls
if you want to implement a procedure call, you have to fiddle with a stack structure or something so you know where to return those values when your function is done running
tail calls, however, are usually implemented as goto instructions or similar
Click to expand...
The best way to think about tail calls is in the context of creation of stack frames, especially in the context of recursion. Tail calls allow for either clever reuse of frames or general prevention of stack overflows.
You're jumping to a pointer (the function being returned), but there's some extra magic in there. It's closer to the concept of a natural processing pipeline.
 
OpenAI makes the most cucked and useless AI/GML/CIE/ML/GAN(N)/NN/LLM out there.
They used to be a pretty good open source project leading up to GPT-2 and then suddenly became massive homosexuals and now everything is closed source and behind an API. If you use if in a way they don't like then you lose the API.
I wish LLMs would be available to tje general public to run on local hardware provided they had it.
 
ADHD Mate said:
ChatGPT is open to correcting errors the same way jeet is. It will say you are absolutely right, and then will proceed to do the same shit again lol
Click to expand...
True but if you recognize it's wrong and it ends up being a moron, you pop up another session and can go again with different results. There are good ways to use it but the catch is always being aware it has high potential to spout some nonsense and it's on you to catch that and to keep in mind it lacks most context and is heavily influenced by the initial prompt.

All of the LLMs are better than relying on Indians and if they're not working out then you're no worse off. If an Indian isn't working out well... he's still around to mess things up.
 
Jotch said:
OpenAI makes the most cucked and useless AI/GML/CIE/ML/GAN(N)/NN/LLM out there.
They used to be a pretty good open source project leading up to GPT-2 and then suddenly became massive homosexuals and now everything is closed source and behind an API. If you use if in a way they don't like then you lose the API.
I wish LLMs would be available to tje general public to run on local hardware provided they had it.
Click to expand...
I don't like being that person.. however I run ollama on my laptop with decent results..

Qwen:30b is pretty good ngl. If you have some scratch you can get the "agent" experience locally.
 
Jotch said:
OpenAI makes the most cucked and useless AI/GML/CIE/ML/GAN(N)/NN/LLM out there.
They used to be a pretty good open source project leading up to GPT-2 and then suddenly became massive homosexuals and now everything is closed source and behind an API. If you use if in a way they don't like then you lose the API.
I wish LLMs would be available to tje general public to run on local hardware provided they had it.
Click to expand...
FailurePersonifiedV2 said:
I don't like being that person.. however I run ollama on my laptop with decent results..

Qwen:30b is pretty good ngl. If you have some scratch you can get the "agent" experience locally.
Click to expand...
IBM's Graphite models are very small and were intended to be used locally by end users. They set up some demos where you can run the models locally in your browser, without needing to download anything. You still have to have a decent computer, but I'm getting ~4 tokens/second running the 4.0 Micro model on my Thinkpad E14.
 
You must log in or register to reply here.
Back
Top Bottom