Oh wow, an answer from ******, I am honored! (and a bit sad to see you vote no, TBH!)
Well to be honest, not only would the motivation boost have been nice, but I honestly wouldn't want to invest so much time and effort if people just won't use it. I expect there is a real reason why the original plugin didn't interest so many people, and if that reason still exists I might want to know about it before committing to this tutorial - or more accurately tutorial series, because as you noticed there might be a bunch of topics involved.
The code is under GPL, so yeah, I would have released it one day or another - but once again the tutorial is a good way to force my own hand instead of procrastinating my way out of this.
Okay, double assignments in Pawn are possible, noted. Frankly, with the language not being OO and usually needing several statements to get anything done, I rarely would have needed it so far. The sarcasm wasn't necessary however: not only did I already read through the implementer's guide as I experienced some weird issues back in the day, I'm mostly making a point about Python being good, not Pawn being bad.
Well, I didn't like ORMs myself, so I'm no exception to the rule. But then I discovered SQLAlchemy and my life changed forever. Rather than typing a TL; DR block of text explaining how it's good, I can only recommend you check it out yourself - I use it for work quite often, in all sorts of (sometimes extreme) situations, and it never failed me. In particular, I never had to type a single line of SQL that I couldn't make SQLAlchemy type for me instead.
The simple reason for that is that it started as a generic SQL abstraction library, and became an ORM later. Its ecosystem is wide, supports migrations through Alembic for production DBs so that you don't even type a single line of SQL when your database format evolves - in short, it's really great for actual work, when most SA-MP tools feel a bit clunky and incomplete.
To interface with the natives, I simply get them at startup in the AMX part of the plugin using the SDK's amx_FindNative function and keep a reference to each, and then I call them from the CPython part of the plugin? I don't see how that would be expensive. And even then, as mentioned, it's not a few nanoseconds that weight a lot in face of 2 hours of scratching head because of a stack/heap collision, or other fun stuff in pawn.
Quote:
Originally Posted by ******
That's just bad coding - bad coders will write bad code in any language.
|
Well that's the thing, there's the languages that encourage good coding, and the languages that don't. Python is a doer.
Python was simpler than pawn for me from the get-go. I had been coding pawn long before I picked up Python, and even longer before I made Python a job. I initially was a C/C++ openGL/ogre3D programmer, so people would think that I would be more naturally inclined to use a language that has a similar syntax... But no. Saving human time is just too important.
Quote:
You said you were debugging multi-threaded code, hows that GIL working out for you?
|
Hahaha, still not GIL-sectomized yet
but be reassured, the interaction with the Python VM is threaded. I'm just making sure daemonized threads don't crash the VM or do other nasty stuff, and more generally doing a fuzz testing of the codebase to prevent surprises. Wouldn't want my DB socket thread to be killed before it's done emitting data, would I?
And also... sure, no concurrency for Python, but pawn doesn't even have threads or multiprocessing built-in, so...