about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2748Kartik K. Agaram2016-03-092-20/+20
|
* 2747Kartik K. Agaram2016-03-091-0/+4
| | | | Thanks Ben Trask for engaging with my arguments.
* 2746Kartik K. Agaram2016-03-094-8/+6
|
* 2745Kartik K. Agaram2016-03-0979-78/+79
|
* 2744Kartik K. Agaram2016-03-0995-242/+245
| | | | Tweak colors and font-sizes in generated html.
* 2743Kartik K. Agaram2016-03-0995-6019/+5666
| | | | | Looks like "TOhtml | <other command>" doesn't work on Mac OS X for some reason..
* 2742Kartik K. Agaram2016-03-083-41/+2
|
* 2741Kartik K. Agaram2016-03-081-0/+0
|
* 2740Kartik K. Agaram2016-03-083-0/+9
|
* 2739Kartik K. Agaram2016-03-083-1/+1
|
* 2738Kartik K. Agaram2016-03-081-16/+16
|
* 2737Kartik K. Agaram2016-03-081-1/+1
|
* 2736Kartik K. Agaram2016-03-081-0/+8
|
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-0898-1342/+1344
| | | | | | | | | | | | 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.
* 2734Kartik K. Agaram2016-03-081-7/+7
|
* 2733Kartik K. Agaram2016-03-071-0/+2
|
* 2732Kartik K. Agaram2016-03-071-1/+10
|
* 2731Kartik K. Agaram2016-03-071-1/+1
|
* 2730Kartik K. Agaram2016-03-071-43/+159
|
* 2729Kartik K. Agaram2016-03-061-7/+12
|
* 2728 - don't ignore /space: while checking typesKartik K. Agaram2016-03-045-39/+53
|
* 2727 - don't ignore /space: in immutability checksKartik K. Agaram2016-03-041-12/+50
| | | | | | | | | | | | | | | Right now there's now way to tag variables from surrounding spaces (lexical scopes) as immutable. Should I assume they're immutable unless the surrounding space is passed out in addition to passed in? What if it comes from a global? Or should we explicitly specify modified variables in the header, even if they'll never be saved anywhere? We don't use these features much yet, wait until we need it. Mutability checks are an optional layer and can't cause memory corruption. Lack of type-checking in the global space, however, *can* cause memory corruption. That's the biggest open issue right now.
* 2726Kartik K. Agaram2016-03-041-3/+4
|
* 2725 - dev machine is now MacKartik K. Agaram2016-03-021-0/+1
|
* 2724 - document failures of /space:globalKartik K. Agaram2016-03-012-7/+15
|
* 2723Kartik K. Agaram2016-02-291-5/+2
|
* 2722 - fix a crash; thanks Ella Couch!Kartik K. Agaram2016-02-281-2/+24
|
* 2721Kartik K. Agaram2016-02-282-11/+11
|
* 2720 - hash table teetering but aliveKartik K. Agaram2016-02-283-11/+86
| | | | More bugs fixed in generics to make this work.
* 2719 - improvements to genericsKartik K. Agaram2016-02-281-17/+65
|
* 2718 - stop crashing on unknown spaceKartik K. Agaram2016-02-263-4/+29
| | | | | I'm going to stop wasting precious first-line characters on 'bugfix:'. It's going to be all bugfixes for a while I think.
* 2717 - bugfix for dilated reagentsKartik K. Agaram2016-02-262-0/+15
| | | | Make sure static arrays can take compound types.
* 2716 - more holes in immutability checksKartik K. Agaram2016-02-264-13/+104
| | | | | We're still not done. Layer 60 doesn't yet handle variables in surrounding spaces. There's probably other issues..
* 2715 - bugfix: directly modifying ingredientsKartik K. Agaram2016-02-261-0/+24
|
* 2714 - apply 2604 to sandbox/Kartik K. Agaram2016-02-261-1/+1
|
* 2713 - require booleans for boolean operationsKartik K. Agaram2016-02-264-5/+70
| | | | | Thanks Ella Couch for finding this bug. It's helped me find errors in mu's code itself.
* 2712Kartik K. Agaram2016-02-2646-330/+330
|
* 2711 - permit boolean<-number conversionsKartik K. Agaram2016-02-253-9/+18
| | | | | | | | | | | I might change my mind on this, but it's worth a try after watching Ella run up against it today. I got her to build the recipe 'odd?', but then it failed to run because she couldn't convert a numeric remainder to a number without a conditional (which I haven't taught her yet). For now I don't change the value in the boolean, so booleans can store arbitrary bit patterns like in C. We just say that 0 is false and anything else is true. I *think* that doesn't break the type system..
* 2710Kartik K. Agaram2016-02-2528-113/+15
|
* 2709Kartik K. Agaram2016-02-2515-38/+1
| | | | | Only Hide_errors when strictly necessary. In other places let test failures directly show the unexpected error.
* 2708 - update map of transform orderingKartik K. Agaram2016-02-251-6/+10
|
* 2707Kartik K. Agaram2016-02-2519-63/+3
|
* 2706 - update htmlKartik K. Agaram2016-02-2560-1173/+3050
|
* 2705 - eradicate 'warning' from appsKartik K. Agaram2016-02-252-101/+101
|
* 2704 - eradicate all mention of warnings from coreKartik K. Agaram2016-02-259-35/+24
|
* 2703Kartik K. Agaram2016-02-257-21/+19
|
* 2702Kartik K. Agaram2016-02-254-36/+35
|
* 2701 - turn some warnings into errorsKartik K. Agaram2016-02-257-37/+37
| | | | | | | I really have only one warning left: when somebody redefines a function. I think I'm going to just turn that into an error as well and drop the notion of warnings altogether. Anytime we find something wrong we stop running the program. This is a place where hygiene is justified.
* 2700 - fail tests on unexpected errors or warningsKartik K. Agaram2016-02-253-4/+21
|
* 2699Kartik K. Agaram2016-02-241-6/+6
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-11 16:50:18 +0000