- Jan 28, 2021
-
-
matu3ba authored
-
- Jan 23, 2021
-
-
merge MR 1216 from @NateDogg1232 fixes #997
-
- Jan 08, 2021
-
-
matu3ba authored
backtrace shows garbage without debug symbols
-
- Dec 30, 2020
-
-
matu3ba authored
fix(manual, testing): unit tests for correctly working sections+examples in manual chapter expansion
-
- Dec 27, 2020
- Dec 18, 2020
-
-
matu3ba authored
-
- Dec 16, 2020
- Dec 14, 2020
- Dec 06, 2020
-
-
Fixes first part of #973
-
- Sep 14, 2020
-
-
Luke Clifton authored
-
- Sep 11, 2020
-
-
Michael Aaron Murphy authored
-
Michael Aaron Murphy authored
-
- Aug 21, 2020
-
-
baka authored
-
- Aug 02, 2020
-
-
Jeremy Soller authored
-
- Jun 30, 2020
-
-
The Infinite toshokan authored
-
- Jun 25, 2020
-
-
Nathaniel Allred authored
-
Nathaniel Allred authored
-
- Jun 22, 2020
-
- Jun 13, 2020
- Jun 11, 2020
-
- May 20, 2020
-
-
Michel Le Bihan authored
-
- May 02, 2020
-
-
- May 01, 2020
-
-
matu3ba authored
-
- Apr 21, 2020
-
-
matu3ba authored
adding template description for merge requests
-
- Apr 20, 2020
-
-
matu3ba authored
templates for issues and merge_requests for specific user information and better analysis of tradeoffs of certain features
-
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).
-
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.
-
Prior to this commit, the following type was considered invalid: `[[float]]` 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.
-
- Apr 13, 2020
-
-
Graham MacDonald authored
-
- Mar 22, 2020
-
-
Tom Almeida authored
-
Tom Almeida authored
-
Tom Almeida authored
-
- Jan 28, 2020
-
-
- Jan 26, 2020
-
-
AdminXVII authored
When some binaries set the TTY to non-blocking mode, the shell would panic because of a nonblock error. Fix this by reseting the O_FLAGS while reading lines
-
- Jan 22, 2020
-
-
Xavier L'Heureux authored
-