{"push_id":1411887097,"size":2,"distinct_size":2,"ref":"refs/heads/master","head":"9150008bfc046a71b696c430c240cfd5972aec05","before":"9f5302b9e00bbc450358835b553ace9039726c54","commits":[{"sha":"bca655a4fb992c3a8f83a65223a77aec41b84861","author":{"name":"Brian Dickens","email":"1d28577c3a34c1ac08d512237ad32156e7267b61@hostilefork.com"},"message":"Working implementation of stack-frame GC'd pairings\n\nWhen it was made possible for \"singular\" Rebol Arrays to hold a value\ninside the REBSER node itself (and still act as terminated), this\nmade it more feasible to use these singular arrays as a way of\ngenerically getting GC behavior for small REBVAL-sized items.  This\nwas used in places like function bodies, or to make a form of HANDLE!\nthat could participate in GC.\n\nAnother place where lifetime management for individual REBVAL-sized\nthings would be helpful is the external C API (or \"RL_API\").  Before it\nspoke in terms of proxy REBVALs called \"RXIARG\"s which had no design\nfor their lifetime.  If the REBVALs used in the API lived inside of\nsomething like a singular REBSER, they could participate in GC, and\nhave their lifetime attached to something like the lifetime of the\nfunction frame that requested them.\n\nAlthough a singular array could be used for this purpose, the singular\narray has a property that's not really needed...which is to have\ntermination via an END marker.  The REBVAL is isolated and does not\nhave to appear as a BLOCK! of values.  This raised the possibility of\ncoming up with another layout for the bits inside the REBSER...which\ncould actually lay two entire REBVALs inside of a REBSER node.\n\nThis new structure (known as a \"pairing\") meant the API exposed values\ncould also have a \"meta value\".  This value could be anything from an\nINTEGER! reference count, to a HANDLE!, to a FRAME! of the function\nwhich--when it is done running--should indicate the garbage collection\nof the value and its pointer.  But also, it gave a reusable \"exactly\ntwo values long\" form of series that could be used with very little\noverhead--and which would be unlikely to fragment memory, because the\nsize was the commonly-used size of a REBSER.\n\nThis commit goes ahead and makes the FRAME!-based GC of these values\nwork (it was just pseudocode before).","distinct":true,"url":"https://api.github.com/repos/metaeducation/ren-c/commits/bca655a4fb992c3a8f83a65223a77aec41b84861"},{"sha":"9150008bfc046a71b696c430c240cfd5972aec05","author":{"name":"Brian Dickens","email":"1d28577c3a34c1ac08d512237ad32156e7267b61@hostilefork.com"},"message":"Get rid of RL_API doc generator, more tab excising\n\nThe comments in %a-lib.c were structurally analyzed to produce a text\nfile for documentation of the RL_API that nobody has probably ever\nactually read (at least not in many years).  It used an ad-hoc parsing\ntechnique when there is now a much better C-language parser from\n@CodeByBrett.\n\n(Also, as basically none of the RL_API routines are being kept as they\nwere, the arbitrary restrictions on the comment blocks for the format\nwas really just in the way.)\n\nIf documentation is desired, it should be done as an extension of the\ncurrent source analysis parser.  This will be more appropriate when\nthe RL_API has been stabilized.\n\nThis also adds to %common.r an override of `tab` which causes an error,\nto try and prevent putting tab characters in the files that the tools\ngenerate.  (They can still use tab escapes in strings or other means,\nbut this cuts down on the cases...hopefully eliminated eventually.)\n\nAlso macro++ changed to PROCEDURE for correct bootstrap.","distinct":true,"url":"https://api.github.com/repos/metaeducation/ren-c/commits/9150008bfc046a71b696c430c240cfd5972aec05"}]}
{"actor":{"display_login":"hostilefork"}}