| Age | Commit message (Collapse) | Author |
|---|
|
the migration process was a pain - order of operations for the rebuild was rough to figure out - but the actual implementation is way easier than all that stack juggling
Force-Push: yes
Change-Id: I8bbe4dfb39e5f0ed69f9759e87ac6ab79ec7558b
|
|
it's more declarative now. however, at the moment it only produces the one type of executable, so it's only for building "evoke", not "hex". hopefully that can be fixed soon.
Change-Id: Id970b9952fcd73ba6da4fa503ae2f784afe1b8a7
Force-Push: yes
|
|
there's also additional wording attempting to explain that, yes, the way to learn the language really is to read the language's source. it really is documentation.
from discussions elsewhere, some people found this obvious and some people didn't notice it and thought there was no documentation, so we've done our best to explain the choice.
Force-Push: yes
Change-Id: Ie9e4b81cd48e7ae014032d1983120edf3d823234
|
|
this will allow us to have compiled-in code that wouldn't run under the transforms, though we don't add anything of substance just yet
this strategy was used early in bring-up, in the historical flatassembler version of Evocation, so the design space of it is already well-explored in Irenes' head. how pleasant. :)
Force-Push: yes
Change-Id: I722cddb77657df9ca518c0d9841aa587bf63feb3
|
|
and rename one, linux-dynamic.e to language/dynamic/linux.e.
also make sure all references in comments and documentation refer to the new locations and names.
this directory structure reflects code organization which had existed in Irenes' head, but was likely not obvious to other readers. now hopefully it is more discoverable.
Force-Push: yes
Change-Id: Icfef3eae812a50fe20202191999e68e1f7db445a
|
|
this means all the build invocations are now as simple as they can be without new abstractions of some sort, such as letting evoke take command-line parameters. yay!
Force-Push: yes
Change-Id: Id877159f995662b8d226a9ad937ed73228a9af05
|
|
from Fred Crowson - many thanks!
Force-Push: yes
Change-Id: I369bd987b492ae01d8bed5b3ee9ee88073007c9c
|
|
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
|
|
this is the first-ever release! wow :33333
have fun y'all!!!!
Force-Push: yes
Change-Id: Ifc95e4e63e4ee477b4c23d83a82f7a1e050f7925
|
|
Change-Id: Ibfd4fa69a3d2abdaba162538f6386f7173af4311
Force-Push: yes
|
|
under the hex transform, that is
this also implements ndrop in quine, because it wasn't building evoke, and it checks in the updated hex.hex which reflects the more concise notation for integer constants. this brings all the builds into a clean state, for the moment.
Force-Push: yes
Change-Id: I243cf08c70b4a3af00ea5e0836c5596a32f1288b
|
|
this will be used to cause it to apply a tilde alternate, but the lexing code for that needs to be refactored first
also, this has an implementation of nexit, a new flow-control word for a scary style of metaprogramming
Force-Push: yes
Change-Id: Ic7fe2d50a8ee21cf9fa5fef1fef4408c2935bb4c
|
|
and also a prettier flame drawing
Force-Push: yes
Change-Id: I5896bfdee53c934b4c38861c8a9e9f5a966f7264
|
|
Force-Push: yes
Change-Id: Ia929bd55a0cec2781a4166dad4c7797fd2cb1b9d
|
|
the contents of evoke.hex aren't usable quite yet, for reasons now described in the README, but the build itself runs to completion. this is honestly a huge milestone.
Force-Push: yes!!!!!
Change-Id: Ia95d6aba7485062c0e64cdde0575058a2df2a1ef
|
|
it's now able to run all the way to the end of the label transform, inside the hex transform. the output leaves much to be desired, but it runs.
Force-Push: yes
Change-Id: I7cac39df599e8081fac6b050dfeb34e598bb54eb
|
|
yes, wow, right? big milestone! doesn't work for evoke itself quite yet, but getting really close
Force-Push: yes
Change-Id: I1e836b85cf185db4aa835d2aa494a67585e60744
|
|
Force-Push: yes
Change-Id: I7bda5d1ad0c6b1b44ea283b429b14fd397ef978a
|
|
the structure will eventually be populated from a few places, but for now, the proof-of-concept installs a complex hook that runs only on the call to "allocate" done at the top of "label-loop".
the comment output code works: the metadata entries are output in the appropriate places in the dump! yay
Force-Push: yes
Change-Id: I15f20241e84b535c8407f9a190b22c9cb85227e6
|
|
Force-Push: yes
Change-Id: I1cde3ac2bfc10ccaa8be260a1a6a88684563ccf6
|
|
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
|
|
Force-Push: yes
Change-Id: I16f8271c2629270f65e58e3a642511745ce136c1
|
|
and a useful example one ;)
this also involved fixing the failure cases in input.e to handle EINTR correctly. it required a lot of tracing, but now the expected state of the stack is much better commented for next time.
many thanks to @cks@mastodon.social who found code in the Go compiler which had the details of what's required in regard to the restorer, which made the whole thing work, and to @snowfox@tech.lgbt who did some experimental testing around the exact requirements. both those contributions are reflected in the documentation added with this CL. additional thanks to everyone who chimed in on the fedi thread, your comments kept us going!
Force-Push: yes
Change-Id: I97fd89426bf807df5565e011d3665f7e904fa138
|
|
at least it's a start :)
Force-Push: yes
Change-Id: I221a916c8d6ae5ac45c1d884232b31da89584ddc
|