is there any way to convert python straight to C yet? i just barely can't get PyInstaller working on PythonD because no os.fork() (because DOS. no, not cmd.exe, actual fucking DOS.)

one broken function between me and victory

"just use C" DJGPP is kicking my ass all the same, random unknown segfaults are a bitch and also i can't get quite what i want in the memory layout restrictions i have to work under

"just use Assembly/BASIC" their file handling makes me wanna die and BASIC is fucking massive as well

@subspace not all of the standard stuff is supported because DJGPP, I don't even have "getline", i had to use an FSF implement for that (and i was using exactly that, too, but random segfaults i dunno what to do about and, again, can't do what i actually want because code/data size limits)

@subspace It's certainly not liking any modern form of C and there's no standard libs and there's no dev docs for it anymore, so yes, but there's fuck all I can do with it.

@Parzi ANSI C isn't that bad. You can typedef C99's portable data types yourself, "restrict" is just for performance (define it to empty), C11's thread support is useless on a single task system anyway, which is also why you don't need C11's atomics. You'll have the C standard library plus the DOS specific conio.h for interesting IO functions like keyboard and screen.

I guess you need a python ParzEr first

@Parzi And if you can't reach your goals in C because of too little memory, just forget about throwing Python in the mix. Underneath, Python is implemented e.g. in C, after all.

@Fast-Nop yes but y'see Python actually works under DJGPP, it's just PyInstaller that doesn't, or this wouldn't be an issue anymore. Also "import <stdio.h>" fails in Borland, so...?
@uyouthe i have a python parser, i said PythonD was working

@Haxk20 i did this but it implodes on an fwrite and i cannot find out why

@Haxk20 DJGPP runs everything in 32-bit protected mode so no debugger and it just shits out a "hey it did a SIGSEGV here's registers" which means fucking nothing because it then immediately wipes the RAM it was just telling me it was in

@Parzi good ol process of elimination.

fucking enabling and disabling lines by using comments and then seeing what breaks.

all else fails, ask for input before every possible problematic line. (you can toss the actual input and just hit enter), and count the number of times you hit enter before something breaks. theres your problem line, or at least a hint at what the problen is.

@Wisecrack printf("<next line>");

i know exactly what does it, but not *why.* an fwrite is the issue, which by all account SHOULD work.

@Parzi things pulled out of my ass:

1. unicode whete it wants ascii or vice versa?

2. unprintable characters?

3. overflow, reading past the end of a string, data is the wrong type even though you're sure it isn'tr

4. unhandled exception (lol)

5. unhandled or incorrect return value.

I would test for all of these things and more.

@Wisecrack it prints the line as part of the debug strings i threw in then immediately dies, and I'm only taking data from in one file (known to be a DOS-made textfile every time, so ASCII) and the command line (which is pretty much always ASCII.) The line isn't run, it sees it and eats shit.

Just bundle Python with your code and start the construct with a batch file? Besides creating a self extracting executable, Pyinstaller does no different.

@sbiewald PythonD, as a downloadable binary meant to be used in DOS, needs LFN and DPMI and 4MB of RAM + 64MB of HDD swap + 32MB HDD storage to just itself, plus other shit it may load on start for no reason. Most of that would be attainable if I weren't running off a CD + boot floppy, so no swap space available either.

PyInstaller usually trims the bullshit to just what you need and compiles to bytecode, since I don't need OpenGL and graphics modes and a packet driver and USB mouse support and LFN and a GUI and such for a silent file patcher, and Python on a 386 is awful so the bytecode compile helps some there too. Still need DPMI in this case, but no LFN, which frees RAM, along with the trimming. But no. No os.fork() so no pyinstaller.

@Parzi Well you could trim it and compile the bytecode manually.

@sbiewald how do i strap it after?

@Parzi There is a module in standard Python (maybe even PythonD or it may even be compatible?) to evaluate the import tree of your Python script.
Then remove all modules from PythonD you do not need.
What I'm wondering is, why you need 64m swap, as not even standard python requires that much ram.

@sbiewald I have no idea. It's some sort of PythonD buffer for some of the modules. I did try to trim it manually, but for some reason it throws a fit and fails to start if a bunch of the weird shit like packet drivers and USB mouse support and OpenGL modules are removed. It seems they did something to it, but the last update was 2008 and there's no forum or anything to ask in, just now-defunct mailing lists.