1. 11 Sep, 2020 1 commit
  2. 21 Aug, 2020 1 commit
  3. 02 Aug, 2020 1 commit
  4. 30 Jun, 2020 1 commit
  5. 25 Jun, 2020 2 commits
  6. 22 Jun, 2020 1 commit
  7. 13 Jun, 2020 3 commits
  8. 11 Jun, 2020 1 commit
  9. 20 May, 2020 1 commit
  10. 02 May, 2020 1 commit
  11. 01 May, 2020 1 commit
  12. 21 Apr, 2020 1 commit
  13. 20 Apr, 2020 4 commits
    • matu3ba's avatar
      templates for issues and merge_requests for specific user information and... · f27a1380
      matu3ba authored
      templates for issues and merge_requests for specific user information and better analysis of tradeoffs of certain features
    • Tom Almeida's avatar
      feat: Make all variables show when running `let`. · 35382090
      Tom Almeida authored and AdminXVII's avatar AdminXVII committed
      Before this patch, `let` only shows string and array variables, whilst
      all mapping types are not shown. In addition, string and array variables
      are separated from each other by comments.
      This patch implements a new function on `shell::Variables` that returns
      all the variables in scope and then modifies `Shell::list_vars` to print
      all the variables. The syntax returned is equivalent to the method of
      declaring the variables themselves, however this still results in
      mapping types being indistinguishable from each other by looking at the
      output of `let` (both `HashMap` and `BTreeMap` look the same).
    • Tom Almeida's avatar
      feat: Print an error when attempting to assign to a string index · 42e40e90
      Tom Almeida authored and AdminXVII's avatar AdminXVII committed
      Why is this needed?
      Well, at the moment nothing happens when the user tries something along
      the lines of `let some_string[3] = 'v'`, even though we don't allow it.
      The variable itself doesn't change, and we don't print any errors.
      This patch just makes the function that would assign return an error
      instead of silently failing.
      Why not implement modifying strings by index?
      Sure, we could do that, but it's not quite as obvious as it seems. We
      support utf8 strings, so modifying the `i`th byte obviously doesn't
      work, and could potentially make the string invalid. Another option
      would be to set the `i`th character to whatever is passed in. This is
      fine in theory, but it would be an `O(N)` operation in the average
      case, and we'd have to shuffle all the following chars either further up
      or further down the string.
      While this may be a desirable ability to eventually have, it will
      require significantly more work and thought around strings in ion than
      simply returning an error.
    • Tom Almeida's avatar
      feat: Make arrays able to nest · 47bb7068
      Tom Almeida authored and AdminXVII's avatar AdminXVII committed
      Prior to this commit, the following type was considered invalid:
      Of course, sometimes it is helpful to have arrays within arrays, and as
      such, this patch allows for nested arrays. To do this, the array types
      in `Primitive` have all been converted to a `Primitive::Array` type,
      that holds a `Box<>` to another `Primitive`. There is - of course - a
      slight performance penalty to be expected with moving to using another
      `Box` for arrays, however after having run the benchmarks, the
      difference appears to be negligible.
  14. 13 Apr, 2020 1 commit
  15. 22 Mar, 2020 3 commits
  16. 28 Jan, 2020 1 commit
  17. 26 Jan, 2020 1 commit
  18. 22 Jan, 2020 1 commit
  19. 19 Jan, 2020 2 commits
  20. 12 Jan, 2020 12 commits