about summary refs log tree commit diff stats
path: root/mu.vim
Commit message (Collapse)AuthorAgeFilesLines
* 7842 - new directory organizationKartik K. Agaram2021-03-031-76/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Baremetal is now the default build target and therefore has its sources at the top-level. Baremetal programs build using the phase-2 Mu toolchain that requires a Linux kernel. This phase-2 codebase which used to be at the top-level is now under the linux/ directory. Finally, the phase-2 toolchain, while self-hosting, has a way to bootstrap from a C implementation, which is now stored in linux/bootstrap. The bootstrap C implementation uses some literate programming tools that are now in linux/bootstrap/tools. So the whole thing has gotten inverted. Each directory should build one artifact and include the main sources (along with standard library). Tools used for building it are relegated to sub-directories, even though those tools are often useful in their own right, and have had lots of interesting programs written using them. A couple of things have gotten dropped in this process: - I had old ways to run on just a Linux kernel, or with a Soso kernel. No more. - I had some old tooling for running a single test at the cursor. I haven't used that lately. Maybe I'll bring it back one day. The reorg isn't done yet. Still to do: - redo documentation everywhere. All the README files, all other markdown, particularly vocabulary.md. - clean up how-to-run comments at the start of programs everywhere - rethink what to do with the html/ directory. Do we even want to keep supporting it? In spite of these shortcomings, all the scripts at the top-level, linux/ and linux/bootstrap are working. The names of the scripts also feel reasonable. This is a good milestone to take stock at.
* 7785 - baremetal/shell: trace primitives doneKartik K. Agaram2021-02-221-0/+2
| | | | Rendering traces will be an ongoing journey.
* 7337 - tile: jumping to a functionKartik Agaram2020-12-051-2/+2
| | | | We can't yet edit the function once we jump to it.
* 7149Kartik Agaram2020-10-311-1/+1
|
* 6973Kartik Agaram2020-10-081-1/+1
|
* 6951 - 4 colors for Mu as wellKartik Agaram2020-10-041-1/+4
|
* 6938 - start colorizing floating-point registersKartik Agaram2020-10-031-1/+1
|
* 6697Kartik Agaram2020-08-011-1/+1
|
* 6634 - highlight bad variables in vimKartik Agaram2020-07-111-0/+2
|
* 6630 - define type signatures for SubX functionsKartik Agaram2020-07-101-1/+1
| | | | This was easier than I'd feared.
* 6412Kartik Agaram2020-05-271-1/+1
|
* 6409 - primitives for text-mode UIsKartik Agaram2020-05-271-1/+1
|
* 6399 - make mu.vim work better out of the boxKartik Agaram2020-05-241-2/+6
| | | | | | Adding some more colors will improve the experience, but the choices depend on colorscheme, and first impressions should at least not seem to have degraded things.
* 6398Kartik Agaram2020-05-241-2/+2
|
* 6162Kartik Agaram2020-03-231-5/+10
|
* 6137Kartik Agaram2020-03-121-1/+2
|
* 6078 - highlight hex literals in VimKartik Agaram2020-03-021-1/+1
|
* 6075Kartik Agaram2020-03-021-1/+2
|
* 6068Kartik Agaram2020-02-281-1/+1
|
* 6067Kartik Agaram2020-02-281-0/+58
| | | | Missed the file.
* 5485 - promote SubX to top-levelKartik Agaram2019-07-271-98/+0
|
* 4910Kartik Agaram2019-01-061-4/+4
|
* 4294Kartik Agaram2018-06-301-9/+9
|
* 4293Kartik Agaram2018-06-301-1/+1
|
* 4262 - literal 'null'Kartik Agaram2018-06-171-0/+1
|
* 4261 - start using literals for 'true' and 'false'Kartik Agaram2018-06-171-0/+1
| | | | | | | | | They uncovered one bug: in edit/003-shortcuts.mu <scroll-down> was returning 0 for an address in one place where I thought it was returning 0 for a boolean. Now we've eliminated this bad interaction between tangling and punning literals.
* 4214Kartik K. Agaram2018-02-211-1/+1
|
* 4165Kartik K. Agaram2017-12-271-9/+19
|
* 4164Kartik K. Agaram2017-12-271-3/+19
|
* 4163Kartik K. Agaram2017-12-241-1/+1
|
* 4134 - 'input' = 'ingredient'Kartik K. Agaram2017-12-031-2/+2
|
* 3976Kartik K. Agaram2017-08-201-1/+1
|
* 3969Kartik K. Agaram2017-07-131-1/+1
|
* 3702Kartik K. Agaram2016-12-061-1/+1
| | | | Commands like '$exit' shouldn't look like labels.
* 3569Kartik K. Agaram2016-10-231-2/+4
| | | | Update syntax highlighting to not color numeric locations like literals.
* 3568Kartik K. Agaram2016-10-231-1/+3
| | | | Fix syntax highlighting for labels after commit 3552.
* 3561Kartik K. Agaram2016-10-221-4/+4
|
* 3431Kartik K. Agaram2016-09-301-16/+13
| | | | | Improvements to syntax highlighting, particularly for Mu code in C++ files.
* 3426Kartik K. Agaram2016-09-271-1/+2
|
* 2838Kartik K. Agaram2016-04-161-1/+1
|
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-2/+2
| | | | | | | | | | | | I'm dropping all mention of 'recipe' terminology from the Readme. That way I hope to avoid further bike-shedding discussions while I very slowly decide on the right terminology with my students. I could be smarter in my error messages and use 'recipe' when code uses it and 'function' otherwise. But what about other words like ingredient? It would all add complexity that I'm not yet sure is worthwhile. But I do want separate experiences for veteran programmers reading about Mu on github and for people learning programming using Mu.
* 2562Kartik K. Agaram2016-01-171-1/+0
| | | | | | | | | | | | We want to use the type 'recipe' for recipe *variables*, because it seems nicer to say `recipe number -> number` rather than recipe-ordinal, etc. To support this we'll allow recipe names to be mentioned without any type. This might make a couple of places in this commit more brittle. I'm dropping error messages, causing them to not happen in some situations. Maybe I should just bite the bullet and require an explicit :recipe-literal. We'll see.
* 2367Kartik K. Agaram2015-11-051-1/+1
|
* 2306 - recipe headersKartik K. Agaram2015-10-281-0/+1
| | | | | | | | | | Once a student has gotten used to recipes and ingredients using the staged 'next-ingredient' approach there's no reason to avoid conventional function headers. As an added bonus we can now: a) check that all 'reply' instructions in a recipe are consistent b) deduce what to reply without needing to say so everytime c) start thinking about type parameters for recipes (generic functions!)
* 2295 - drop first-class recipes and continuationsKartik K. Agaram2015-10-281-1/+0
| | | | Making life too complex at this time.
* 2294Kartik K. Agaram2015-10-281-0/+1
| | | | Bah, sick of CALL and continuations.
* 2266 - drop experiment with genericsKartik K. Agaram2015-10-071-1/+1
|
* 2252Kartik K. Agaram2015-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I can't easily use generic containers without needing some syntax for generic recipes: push:number a:number, l:list:number which would be implemented as: T <- next-type a:T <- next-ingredient etc. Another concern: how to represent map<string, list<number>>? map::address:array:character::list:number where the '::' is just silently turned into ':'. Agh, all this is so baroque. All this while I've been trying to avoid getting into language design. All I want is some lightweight way to avoid security holes and memory corruption. But now it seems like I need facets to control compile-time activities and so on.
* 2174Kartik K. Agaram2015-09-061-1/+2
|
* 2153Kartik K. Agaram2015-09-051-1/+1
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-09-24 18:39:08 +0000