{"push_id":822300103,"size":17,"distinct_size":17,"ref":"refs/heads/master","head":"21d2851de61a3248a93076409a31029aad357da0","before":"029fdc5423a1f5d5d181fbd1c3708d2b7fef277b","commits":[{"sha":"cf404dd5cb715121f1a0dec755218b3a6ee986dd","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Add ANY-SERIES/SCALAR/NUMBER to r2r3-future.reb\n\nThe r2r3-future.reb file is something of relatively limited interest (for\nadapting Rebol2 and R3-Alpha in a way that it might run Ren/C or future\nscripts).  That will be impossible in general, but for a limited sense it can\nwork for a subset of files.  One relevant subset: the make prep scripts.\n\nBecause FAIL is a widely relevant change, it has a small shim in the\nr2r3-future.r file.  The FAIL shim depended on scalar? which was converted\nto any-scalar?, which had no shim.  This adds those shims, and makes a\nnote that this stub file needs a \"Czar\" to get it into better shape for those\nwho would be interested beyond the `make prep` script's needs.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/cf404dd5cb715121f1a0dec755218b3a6ee986dd"},{"sha":"61abd10cc866d292173f2fbf3481b53e77af460d","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"ANY-TYPE! => ANY-VALUE!\n\nThere is an ambiguity inherent when types themselves are values\nin the language, and you say \"ANY-TYPE\".  The problem is that may\nsuggest something more narrow than what has been meant, which\nhistorically is that ANY-TYPE meant \"any legal Rebol value\" (and that\nincluded UNSET!, when UNSET! was a legal Rebol value, which it is\nnow planned to not be).\n\nRenaming it to ANY-VALUE! clears up the problem, so you don't think\nit suggests it could be \"any type\", e.g. STRING! or INTEGER! etc.\n\nANY-TYPE! added to legacy for backward compatibilty.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/61abd10cc866d292173f2fbf3481b53e77af460d"},{"sha":"c68ec99592c48a5796fa9e79ce4df0c059aa6b51","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Cleanups and enhancements of Ren/C zlib usage\n\nIn the early commits of Ren/C it absorbed a PR that had been pending\non rebol/rebol's GitHub which brought Rebol up to date with a copy of\nzlib that was extracted using a script.  (The old copyright date was 1998,\nand there had been a number of fixes between then and 2013.)\n\nThis updated library had not been tested with the unzip.reb script, which\nwas failing to work.  Reasoning was that zlib had been \"hacked\" to\naccept an invalid format.  Updating had removed that hack:\n\n    http://stackoverflow.com/q/32907420/211160\n\nIn order to support correct function of the library, this adds an /ONLY\nrefinement to COMPRESS and DECOMPRESS.  It also in general solves\na number of problems, e.g. making GZIP reading and writing functional\nso that you can process .GZ files.  Other adjustments included based on\nfollowing modern Zlib documentation.\n\nThis change requires an updated version of unzip.reb to work, as the old\nversion was doing something rather incorrect.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/c68ec99592c48a5796fa9e79ce4df0c059aa6b51"},{"sha":"be40eb210d7dd2e6295f183a88f9eb54411a02df","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Fix signed comparison warning in Encode_UTF8\n\nWhen pulling @meshpoint's change I'd overlooked this signed warning.\nAlso changed a nearby C-style cast to a cast macro.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/be40eb210d7dd2e6295f183a88f9eb54411a02df"},{"sha":"c48b9d55e925e5689ef4cb07801a8f579f95a398","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"ERROR => same struct as OBJECT/PORT/MODULE\n\nAt one point in time, ERROR! objects did double duty as the value\ntype for THROWN() values generated for function returns and\nsimilar.  The error then contained a number identifying the throw\nand a possible argument.\n\nWith the desire to allow a \"full value's worth\" of value to /NAME a\nthrow, the THROWN() convention was changed to a header bit that\ncould be set on any value type.  This meant all errors were changed\nto have \"object frames\" and be ordinary objects which could be\nhanded to the user (with two exceptions: halt and a parse hack).\n\nThis commit started as comment maintenance but then shifted to\nmerging ERROR! in to be in the same form as PORT!, MODULE!,\nand OBJECT! which share a common REBVAL structure.  (This\nis similar to how series values like BLOCK! and STRING! and\nPAREN! and BINARY! share the same structure.)","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/c48b9d55e925e5689ef4cb07801a8f579f95a398"},{"sha":"8ab045e0262ddd7912f3abad74949b015438896b","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Fix missing exit_status assignments in host_main.c\n\nThe exit_status was intentionally not defaulted to a value in order\nto catch branches that did not purposefully assign it in Valgrind.\nThis closes the assignment loop for a missing case.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/8ab045e0262ddd7912f3abad74949b015438896b"},{"sha":"7b9768f84636b0ae41e65f8395015c279295950c","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Adjustments for unknown-size decompression experiment\n\nThe primary use-case for the change to the zlib interface was\nunzip.reb, which knew the size of the raw decompression...but\nsome not-very-tested code was added to kick off an attempt at\nbeing able to inflate a block of deflate data without storing or\nstating a size.  It had an error in that it expanded the target\nseries, but if it had to reallocate the series then the underlying\npointer would not adjust, so zlib had to be told where the new\npointer could be.\n\nFixes a crash on an error-reporting condition, as well as a\npotential memory leak from zlib internal structures on error.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/7b9768f84636b0ae41e65f8395015c279295950c"},{"sha":"fea592111bdd56ba8ef8c0fca99c2647b5e833ab","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Differentiate 4-byte/8-byte binary-to-int process\n\nThis was motivated by discovery that Rebol3's CRC32 hash values\nare returned as signed quantities.  When reading a 32-bit CRC out\nof the zip container as bytes, using TO-INTEGER on it would extend\nit to a 64-bit quantity which was never signed...leading to a difference\nof comparison.\n\nUsing logic based on a previous futureproofing proposal from...\nsomeone, this does not interpret to-integer #{FFFFFFFF} in Ren/C as\n#{00000000FFFFFFFF} but rather #{FFFFFFFFFFFFFFF}.  It will\neffectively extend the bytes to the left to make a 64-bit number based\non the high bit of the most significant big-endian byte of the input.\nIf a 4-byte number coming from Rebol2's TO-BINARY of an integer is\nread then it will be compatible, and if an 8-byte number coming from\nRebol3's TO-BINARY of an integer is read then that will be compatible\nalso.  As an added benefit, one can force the interpretation of a number\nas positive by prepending a #{00} to the binary prior to conversion, or\nforce a negative interpretation by prepending a #{FF}.\n\nThis does not change the TO-BINARY behavior, leaving it as always\nproducing a 64-bit binary from integers.  However, it does change the\ntruncation rule for long numbers to an error.  Hence a long byte stream\ncannot have its head converted implicitly.\n\nWith this and the zip changes, unzip.reb works with correct external\nCRC calculations via an unmodified zlib.\n\nA legacy switch for conditional code related to this and other bit-size\nfutureproofing #ifdefs was added and enabled in <r3-legacy>","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/fea592111bdd56ba8ef8c0fca99c2647b5e833ab"},{"sha":"514028067495459a7553f92c26b75ac80e990dae","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"WORD! => SET-WORD! instances in %errors.r\n\nThe bootstrap load of data doesn't do checking on the object it loads\n(no binding of words) so it did not notice that two WORD! instances\nhad crept into where set-words should be for error keys.\n\nThis fixes that and does a cleanup and more checking in make-boot.r\nto prevent such things from happening again.  It puts the make-boot\ninto the same terminology as the error code itself to make it easier\nto understand and modify.  It also uses FAIL which has been added\nto r2r3-future.r.\n\nBecause it was tempting to use EVERY instead of FOR-EACH, this\n*removes* every from the past-to-future Rebol adaptation, because\nthere is no way to write a working loop wrapper in R3-Alpha.  Hence\nin make-boot modifications it should not be used, even if it looks\nnicer...and making it a synonym is now a lie as EVERY has a different\n(and more useful) return result.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/514028067495459a7553f92c26b75ac80e990dae"},{"sha":"706431e3590fbd1714e37c10cb38f76ba466bd91","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Ensure error argument NULL termination size\n\nA check on error creation ensured that all errors originating from\nC code were created with the right number of arguments for their\ntemplate message.  This adjusts cases where NULL was passed\nin and shouldn't have been, too many nulls were given, or moves\nafter-the-fact argument supply to be before-the-fact to avoid\ntriggering the alarm.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/706431e3590fbd1714e37c10cb38f76ba466bd91"},{"sha":"33f0003fcddc6fc72205a5b27b5bfb2bd9b9fe5e","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"!Make_Error_Object(...) => Make_Error_Object_Throws(...)\n\nAt one point Make_Error_Object was retrofitted to \"bubble up\" the\ncases where a throw happened in the evaluation, and this was\npassed as a \"success\" or \"failure\" flag.  Overall in the system as more\nsuch leaks were plugged the pattern emerged that usually the caller\nneeded to test the throw condition and do handling...and it was not\nthat clear what a boolean result meant at the callsite.  By inverting the\nlogic and adding \"throws\" into the name it could be read more easily\nas testing whether the operation in the if statement is (in the present\ntense) throwing during the conditional test.\n\nThis propagates that rule to Make_Error_Object, and lessens the need\nfor the \"THROWN()\" assertions at the callsites to document the meaning\nof the branch.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/33f0003fcddc6fc72205a5b27b5bfb2bd9b9fe5e"},{"sha":"dc25cd6c0f2df485105271953c61262f21577e79","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Roll back speculative change of frame offset in cell\n\nWhen all OBJECT! type structures were unified under Reb_Object\nin c48b9d5, it led to the removal of an assertion that Reb_Error and\nReb_Object had their frames at the same offset in a value cell.\n(as the same structure, it was now impossible for them to be different).\n\nThis suggested checking to see if the common position of the frame\nat the same pointer location was essential or not.  If it was not, then\nit would be possible to make changes to the behavior of ANY-OBJECT!\nor ANY-SERIES! with one not affecting the other by having the same\nrequirements of behavior w.r.t. VAL_SERIES and VAL_OBJ_FRAME.\n\nAt least one issue was found with an assumption in core code itself\n(patched here--caused defects in deep copying apparently not checked\nby any tests).  Yet the reason for undoing the change anyway is due\nto the value cell layouts being mirrored and dependent in the RXIARG\nstructure.  A simple patch of the address in the macros did not fix it,\nsuggesting that series RXIARGs and object RXIARGs are being called\nrandomly interchangeable.\n\nRather than investigate the specific cause of that bug, the speculative\nchange is rolled back here and an assertion and notes added, and\nfurther consideration will be given when RXIARG is being eliminated\n(which is a part of the Ren/C plan to use pure Rebol headers for\nextension DLLs vs. a mirrored type hierarchy).","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/dc25cd6c0f2df485105271953c61262f21577e79"},{"sha":"0e7821dabe0ae36a0a20c89893c449d03ffb8d5b","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Bound Debug build DO step counter to MAX_U32\n\nThere's a counter used for debugging getting to a certain \"tick count\" of DO\nsteps in the source.  It will probe that step and let you set a breakpoint.  This\nis very useful, however it didn't have a bound on it... so it would overflow.\n\nThough \"only a debug feature\", running a debug build is supposed to be a\nbetter-checked version of the release build.  So it shouldn't give any output\nthat wasn't requested.  This expands the range of where you set the tick\ncount by using an unsigned number and limits the tick counting range to\nMAX_U32.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/0e7821dabe0ae36a0a20c89893c449d03ffb8d5b"},{"sha":"e9c4fcf8c8a3b4b5c16f42caf17f6a9cc5f2e81e","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"TO-INTEGER/UNSIGNED and conversion fixes\n\nThis factors out the functionality of INTEGER!'s TO conversion into\na service function, and then adds a parameter to that function for\nenforcing interpretation to be unsigned.  Then it creates a NATIVE!\nversion of TO-INTEGER! which provides an /UNSIGNED refinement\nto use the new ability.\n\nIt also fixes a bug in the TO INTEGER! implementation for numbers\n(introduced in fea5921).  The problem would occur when leading 0xFF\nbytes were followed by a byte without the high bit set.  This would\nlead to positive interpretations of those numbers.\n\nSeveral other adjustments were made to correct edge cases or add\ninformative errors for surprising results.  As a by-product of writing the\nroutine for general purposes, it can generate a REBI64 directly into a\nvalue cell or into a REBI64 without a value cell.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/e9c4fcf8c8a3b4b5c16f42caf17f6a9cc5f2e81e"},{"sha":"8a3e8813dc646973c36a8bf9ac0338e3b789bc2b","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Print BINARY! as raw bytes to console, skip NONE!\n\nAn issue discovered regarding Rebol's limitations of interacting in a\nweb CGI environment is that it has no way to do full 8-bit transport to\nthe console.  Unlike WRITE, PRINT of a binary would not send the\nraw bytes to the device but rather do an effective PROBE of the data.\n\nThe general idea that a PRINT of a value is a general-purpose way\nof inspecting any arbitrary Rebol type is already undermined by its\nlongstanding behavior with BLOCK!.  Hence, in order to make it\npossible to access things like terminal escape codes and other needs\nit makes more sense to treat printing of a binary in a way that gives\nfull raw access to the device.\n\n(This does not change the behavior of BINARY! inside of a block that\nis passed to PRINT, which is currently the domain of FORM.)\n\nThis adds another behavior which has been sought after and requested,\nwhich is that NONE! and UNSET! omit any print whatsoever.  This\nmakes it possible for a function call to \"opt out\" of a print.\n\nSwitch in `<r3-legacy>` for old behavior: PRINT-FORMS_EVERYTHING","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/8a3e8813dc646973c36a8bf9ac0338e3b789bc2b"},{"sha":"22d95cca4526113dd6cc5f17b5ffddcbacb24af9","author":{"email":"760e7dab2836853c63805033e514668301fa9c47@hostilefork.com","name":"Hostile Fork"},"message":"Patch size conversions from binary streams to unsigned\n\nSome size conversions of binary were affected by the sign\ninterpretation change...because it was being used in TLS and\nHTTP to decode streams.  Hence the binaries were not full 64-bit\nintegers, and could be interpreted as signed when they were meant\nto be unsigned.\n\nThis was obviously going to be a problem for clients not using\n`<r3-legacy>`, which was known.  But for reasons of oversight and\nfalse security from not getting alerts raised by conversions in the\ntests, Mezzanine instances were not thought to be examined\nmanually.","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/22d95cca4526113dd6cc5f17b5ffddcbacb24af9"},{"sha":"21d2851de61a3248a93076409a31029aad357da0","author":{"email":"244f89aaae629c48d90244a7ac94a161187c6537@the-handleys.net","name":"Brett Handley"},"message":"Merge branch 'master' of https://github.com/metaeducation/ren-c","distinct":true,"url":"https://api.github.com/repos/codebybrett/ren-c/commits/21d2851de61a3248a93076409a31029aad357da0"}]}