mu - Soul of a tiny new machine. More thorough tests → More comprehensible and rewrite-friendly software → More resilient society.

	Commit message (Collapse)	Author	Age	Files	Lines
*	2295 - drop first-class recipes and continuations	Kartik K. Agaram	2015-10-28	1	-52/+0
\| \| \| \|	Making life too complex at this time.
*	2294	Kartik K. Agaram	2015-10-28	1	-1/+3
\| \| \| \|	Bah, sick of CALL and continuations.
*	2283 - represent each /property as a tree	Kartik K. Agaram	2015-10-26	1	-1/+1
\|
*	2277 - reagents now have a tree of types	Kartik K. Agaram	2015-10-25	1	-3/+3
\|
*	2271 - bugfix: traces cross-contaminating errors	Kartik K. Agaram	2015-10-19	1	-0/+5
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	There were several places where we push a call on to a routine without incrementing call-stack depth, which was used to compute the depth at which to trace an instruction. So sometimes you ended up one depth lower than you started a call with. Do this enough times and instructions that should be traced at level 100 end up at level 0 and pop up as errors. Solution: since call-stack depth is only used for tracing, include it in the trace stream and make sure we reset it along with the trace stream. Then catch all places where we forget to increment call-stack depth and make sure we catch such places in the future. When I first ran into this with Caleb I thought there must be some way that we're writing some output into the warnings result. I didn't recognize that the spurious output as part of the trace, just at the wrong level.
*	2262 - strengthen some type checks	Kartik K. Agaram	2015-10-07	1	-1/+10
\|
*	2258 - separate warnings from errors	Kartik K. Agaram	2015-10-06	1	-2/+2
\| \| \| \| \| \| \|	At the lowest level I'm reluctantly starting to see the need for errors that stop the program in its tracks. Only way to avoid memory corruption and security issues. But beyond that core I still want to be as lenient as possible at higher levels of abstraction.
*	2232	Kartik K. Agaram	2015-10-01	1	-9/+10
\|
*	2226 - standardize warning format	Kartik K. Agaram	2015-10-01	1	-2/+2
\| \| \| \| \| \| \| \|	Always show recipe name where error occurred. But don't show internal 'interactive' name for sandboxes, that's just confusing. What started out as warnings are now ossifying into errors that halt all execution. Is this how things went with C and Unix as well?
*	2137	Kartik K. Agaram	2015-09-03	1	-1/+0
\|
*	1868 - start using naked literals everywhere	Kartik K. Agaram	2015-07-28	1	-2/+2
\| \| \| \|	First step to reducing typing burden. Next step: inferring types.
*	1848 - core instructions now check for ingredients	Kartik K. Agaram	2015-07-25	1	-2/+10
\| \| \| \|	Also standardized warnings.
*	1829	Kartik K. Agaram	2015-07-23	1	-1/+1
\|
*	1711 - start adding methods to editor-data objects	Kartik K. Agaram	2015-07-05	1	-4/+6
\| \| \| \|	The menu bar needs separate recipes to render and respond to events.
*	1702 - experiment: start using 'ordinal' in names	Kartik K. Agaram	2015-07-04	1	-5/+5
\| \| \| \| \| \| \|	It comes up pretty early in the codebase, but hopefully won't come up in the mu level until we get to higher-order recipes. Potentially intimidating name, but such prime real estate with no confusing overloadings in other projects!
*	1701	Kartik K. Agaram	2015-07-04	1	-4/+4
\|
*	1699 - first-class recipe types	Kartik K. Agaram	2015-07-03	1	-0/+51
	It should now be easy to do dynamic dispatch, create higher-order functions, etc.