| Age | Commit message (Collapse) | Author |
|
this was the subject of a bunch of thought. in most languages, we'd argue against having a text-based "include" feature, because there should also be a module system, and textual include subverts the module system because you can't assume everyone will use it.
however, Evocation already very strongly encourages thinking of a program as a sequence of operations (this is after all the definition of a catenative language), and in particular the transformation system already relies very heavily on programs-as-text. so, it seems appropriate for Forth in general and for Evocation in particular.
plus it was easy to implement, because all the infrastructure for it already existed to support the transformation system
Force-Push: yes
Change-Id: I76f778e44b8189ac7052890c881654d971e43c8d
|
|
thanks to nortii for reporting this. a real fix will come soon, but meanwhile this workaround should help.
Force-Push: yes
Change-Id: I38a4c3f148f69ff7c67e8dc00fac5e1351cc3eab
|
|
now all the command-line invocations are pleasingly short :)
Change-Id: Ibe2b9f3b85ab3a51a9d95e3511b273664e6a8807
Force-Push: yes
|
|
as a result of this, the massive invocations to compile things are now shorter
not all the way shorter, but significantly shorter :)
because of where these changes are, this doesn't change the binary at all, so no new evoke.hex is needed (yay!)
Force-Push: yes
Change-Id: I35dfd065b2a4fc4bf1b80f402a07088efca43676
|
|
there was never a good reason for them not to be
plus, the formerly bespoke ones use the generic helpers now; sys-open and sys-close are implemented; and a bug in push-input-buffer and pop-output-buffer is fixed
unfortunately these were breaking changes, so there's another evoke.hex in this one
Change-Id: Ifad58fc2fd757adcf89a69c59575565a10406ec2
Force-Push: yes
|
|
and also sys-write didn't used to return a result
this required a little massaging to make it build, the host evoke needed to not actually pass the file descriptor in evoke.e. for posterity: this was fixed by changing it everywhere else as a one-off, then changing it there and using the intermediate version to build the one being checked in now.
this kind of weirdness is a thing we get the freedom to do because of the bootstrapped distribution model, though we still strongly prefer not to do it unless necessary. this breaking change would have had to happen at some point, so it's considered acceptable.
the size of the diff to evoke.hex is larger than ideal. this raises the need to have a policy for when to regenerate it. since this is a breaking change, it's mandatory. it also seems important to commit a regenerated copy when a release is tagged. it will probably turn out to be a good idea to not regenerate it excessively, otherwise. it's possible that in the long run it might make sense to add name-mapping functionality to hex, just to make the diffs smaller.
Force-Push: yes
Change-Id: I2648b2577c5c21b126e46405e9888b5cb59aa0b7
|
|
Force-Push: yes
Change-Id: I1a0ea06380095da3e7702cab278c08bd21b292ca
|
|
previously, alignment had been a special-cased type of metadata entry, with a special trap on packalign. now it uses the same programmable setup everything else does. much simpler, and prettier output.
this CL also contains some modest reformatting of section headers in the hex dump
Force-Push: yes
Change-Id: I21554e92f6af6ddefa937dad8073b89657f85d64
|
|
Force-Push: yes
Change-Id: Ie66d85fd171dfb45d1f3b6869bf94056ec8303af
|
|
since the recommended invocation to build Evocation (hehe) does the heavy lifting in interpreted mode, this required a new helper, allocate-string, which takes a string in the scratch space and properly allocates it so it won't be overwritten by future allocations
Force-Push: yes
Change-Id: Ia73612a65fd7c11af5fe110c573c23c16b777112
|
|
this will not be useful until read-to-buffer also does, but it's a step towards that
Force-Push: yes
Change-Id: Icf03088c9e52e427a5c130949e9ba85655d59044
|
|
Force-Push: yes
Change-Id: I5c0e7abaebb9388f7900dbae8bde1b1cd528ac32
|
|
Force-Push: yes
Change-Id: I6cf15b4e37b66a04afd5af9dfd9cc3d5eb52b894
|
|
not fully tried though
Force-Push: yes
Change-Id: I19b39f2b982fde66863c710b6d458c3bd12bdf4a
|
|
see dynamic.e, input.e, interpret.e, and flow-control.e
there were a couple things in the log-load transform that need to work in compile mode, too
Force-Push: yes
Change-Id: I7caac3b9205f36f7e082a3fd280561d67e27942c
|
|
it's in dynamic.e for now
Force-Push: yes
Change-Id: I4d0c5917eccd58cb881850faee0728d786010c27
|
|
it's merged into core now. that just made the most sense... a couple of its combinators are too useful to not use once you know about them
Force-Push: yes
Change-Id: I3857f353a8603960bebbf34f24572e3d5815f0de
|
|
wow!!!!!! wow
making this work required implementing comma and keyword in the log-load transform
Force-Push: yes
Change-Id: If888d89c23389720840b49b72478e4826a15a269
|
|
also s" and ." work in the label transform, and are used to produce an important error message during the log-load routine, since we can't know whether log-loaded words exist until runtime
sweet, right?
Change-Id: I6a67139538c2cbcef40a1093202b2b4e0ad6febb
Force-Push: yes
|
|
yay
next up is to figure out why calling newly-defined docol-based words with it does not work
Force-Push: yes
Change-Id: I9c5f50d20f43ad8a15b6db58e046f1e0bb158266
|
|
having some trouble with colon
Force-Push: yes
Change-Id: I5fc0f4519bdd8de1033e24730f63296d8076782e
|
|
also said feature seems to work, which is flatly astonishing
just a little more now...
Force-Push: yes
Change-Id: I1bda7e99e524ac73a761859e86e01251e7d17525
|
|
so okay, now all the machine code stuff is implemented and it builds without crashing
the generated executable still crashes though, but this was enough work that it's getting a celebratory check-in
Force-Push: yes
Change-Id: I201e6912253647da58ef3537c735b478b0dca9fb
|
|
it doesn't work yet, but it's gonna
the reason it doesn't work is that the new helper log-load-variable relies on the assembly-definition words being statically available, and they aren't yet
that's fine though, this is still a huge change, worth checking in. why? well, it represents like 16 hours of debugging which culminated in some very minor changes to the semantics of the label transform, in order to make missing words easier to notice and debug. see comments for details.
woooooo :D
Force-Push: yes
Change-Id: Id8334819d165ba9e3156ef2bf32008af748eac29
|
|
Force-Push: yes
Change-Id: I04dd65a9eec71f9b50c8875bdcbe5d4be59888d5
|
|
it doesn't actually output anything, but it all runs without crashing
Force-Push: yes
Change-Id: I48f2e647044df0ae3db961c747cee31a8826ecf3
|
|
fixed now
also a bunch of small things towards adding a log-load transform
Force-Push: yes
Change-Id: I6eeb94d896a7e79092886d7b60e9404c31b2ba6f
|
|
Force-Push: yes
Change-Id: I45662e60c0035758a2cd57d971031eb0562eccb7
|
|
the code doesn't quite run yet, that'll be a future CL
Force-Push: yes
Change-Id: I71e6a45127c1fc37906d902e36142c17afef2a21
|
|
also some minor cleanup that ie. fixes alignment padding
Force-Push: yes
Change-Id: Ia8fcb9a44e05e37751cc1b8334aa72add7e62353
|
|
wow! yes. good. now it needs to actually generate label calls :)
Force-Push: yes
Change-Id: Ide4336e00aa6860fe55c956063303edc873c6d9b
|
|
then it crashes on warm-start because warm-start doesn't exist yet
Force-Push: yes
Change-Id: I9eba481b31d48f9d32c3790f296204c5c8d90938
|
|
also, add support for ;asm and stuff
Force-Push: yes
Change-Id: I904bc0c31e7e4c8b0abc7790f3af5d20c275f2a5
|
|
it depended on the execution-model stuff, for the "next" macro. in general, any word implemented in assembly will depend on that. so, the execution stuff is moved into its own file, leaving evoke.e with only the job of bringing everything together. that's a little disappointing because talking about the execution model seems like a good introduction to the whole topic, but perhaps the problem can be solved down the line with literate programming...
Force-Push: yes
Change-Id: Ic2fe22dcc39980ef75763ae293e41024abc8ba38
|
|
oops - the last CL was supposed to fix this, but it was inadvertently left out
Force-Push: yes
Change-Id: I4edf5abed315bea51abcd98ad67cd28782a62efe
|
|
Force-Push: yes
Change-Id: Icf69cdfe7cf31fda07031bbc848c3ce2acb8cca1
|