> special CoordSet that wraps a regular Set, encoding objects into integers... we don’t need to implement decoding the integers and reifying the Coord objects
Wouldn't it be much simpler to just keep a set of hashes? That's basically what this is.
Not sure what you mean by this. Hashes have collisions, so how would that work?
The attraction of the CoordSet is that it behaves as if it is storing actual objects, but is actually saving memory. So the abstraction hides the optimization, which makes it easier to reason about the rest of the program.
Collisions are extremely unlikely. You will know if a collision occurred if the answer is rejected. If that happens you can tweak the hash algorithm and try again. This would allow saving coordinates outside of the [-1000, 30000] range.
I think it would be easier to reason about because,
1. KISS: You don't need to verify the encoding code is correct.
2. YAGNI: The program doesn't require reading the coordinates back out, so the program should not store the coordinates in a format that can do that.
I would very much recommend the Visual Studio Code extension when you are starting out with the language. Will give you a lot of help and hints around the syntax. But you can use any editor.
Run a program on the desktop with `jag run -d host myprogram.toit`
Install the `host` package for non-embedded things like files, pipes and subprocesses:
Thank you very much for the instruction. It went smoothly. I just had to additionally run
jag setup
which I was clearly told by jag run ...
Very nice experience so far.
One issue I have is that when I use UTF-8 characters in strings they don't show up correctly when the program outputs them to console which also uses UTF-8.
Not sure if I should configure jag somehow to make it work?
With exactly the same setup (editor/console) I have no encoding issues with javascript or python.
What's weirder, console in MINGW64 git bash window (directly, but not through Visual Studio Code) works just fine, even if I launch cmd or powershell in this gitbash window it still works fine.
Switching windows to UTF-8 systemwide through intl.cpl seems to help.
Still weird that other environments don't require this.
I noticed that people encontering the language for the first time are surpised that they don't see examples of doing ESP32 specific things up front.
I know all of that is covered in the docs but maybe you could additionally a create single page meant to illustrate ESP32 specific functionalities provided by the standard library (similar to that: http://docs.micropython.org/en/latest/esp32/quickref.html ) and make it easily accessible from the front page?
Plus maybe how to read anything from terminal that print outputs to.
managed not to give up on any days, heheh!
it’s day 24 where after my initial attempt i thought it would be absolutely impossible. but then next day an alternative approach popped in mind, phew!
Yes, Toit is pretty much a Smalltalk dialect.
Similarities
Blocks (closures passed to functions as a foundation of control flow)
Blocks have non-local return (you can return from the syntactically enclosing fn in a block).
Block arguments introduced with | | delimiters
Single inheritance object orientation
Dynamic typing but type safe
Named arguments
Uses virtual machine to run, including garbage collector.
Differences
Toit's syntax is more like a cleaned up Python than Smalltalk.
Toit also has positional arguments.
Toit's blocks are more lightweight than Smalltalk closures (no allocation)
Development is with source files and compiler, not image-based.
Toit has optional types, and if you use them they are checked. (Types are non-nullable by default.)
Toit has interfaces
Toit can build standalone executables, VM included
Toit has top level functions not attached as methods to some class.
Array (List) indexing is 0-based, not 1-based.
Quick intro here: https://docs.toit.io/language