-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fileioc: improve garbage collect handling #270
Conversation
Kinda related to #222 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The GraphX-oriented default post-GC handler is problematic. The default handler should simply do nothing. The documentation should then note that, if GraphX is being used,
gfx_Begin
should be registered. - There should be a pre-GC handler, as well. Analagous behavior and documentation (except mention
gfx_End
instead ofgfx_Begin
, of course).
Changed return type required for pre-gc handler. If it returns a non-zero value, the archival which causes the garbage collect will be cancelled. |
By the way, although I'm bombarding you with change requests, I'd like to state that I appreciate your work on this. After my last few comments are resolved, it looks like everything should be in good shape from my perspective. |
All comments should be resolved. I think there's another comment, but I don't see it lol. |
Looks nice enough. Can you just fix the spacing please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spacing should use tabs between opcode/operand
Done. :P |
30474c9
to
c5e4557
Compare
4065b2a
to
98d091f
Compare
; sp + 6 : pointer to routine to be run after. Set to 0 to use default handler. | ||
; return: | ||
; None | ||
pop de |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can someone else just double check that this pop order is correct? it seems that it sets up the pointers backwards but maybe I'm just tired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that apparently changed during my last pull lol. Fixed it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, no. Just realised that was an intentional optimization
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm aware. I don't think it was ever correct; which is why I am asking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dude. I am asking you to look at if you are popping the arguments in the correct order. I know how to write code.
7788074
to
1933652
Compare
well the CI is still in progress, but the toolchain builds... |
When a gc will be triggered as a result of calling _Arc_Unarc, set OS graphics mode, restore afterwards.
Added ti_SetPostGCHandler((void)(*routine)(void)) so user programs can easily setup graphics again.
Had to replace some of the files in src/include/ to get fileioc to build. Ignore those if you can lol
GC handler functionality has been tested using the attached program.
archive_overloader.zip