gtoolkit
tree-sitter
gtoolkit | tree-sitter | |
---|---|---|
22 | 62 | |
1,042 | 16,555 | |
1.2% | 2.1% | |
9.6 | 9.8 | |
7 days ago | 1 day ago | |
Smalltalk | Rust | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gtoolkit
-
Explorative Programming
Your ideas sounded very much like a mixup of Common Lisp with SLIME, Smalltalk interactivity and Unison-like storage of code in a database instead of files.
I've tried all of them, I think the closest thing I've seen to what you describe, which I also find very attractive, is the GT Smalltalk environment: https://gtoolkit.com/
Have you tried that? They call this idea "moldable development" as you can "mold" your environment to your needs.
Even though I loved it, I ended up not using it much, mostly because it's a bit too heavy to keep handy for exploration all the time when needed (it takes like 1GB of RAM even when idle!)... as I already can do most of that with emacs, which is much lighter, I just stick with it.
-
Smalltalk simplicity and consistency vs. other languages (2022) [video]
> This power that Smalltalk systems have where the code runs in a GUI that is also the editor/debugger/etc has deeply fascinated me recently.
Have you tried emacs?
> And I'd like to actually understand a tool that I'd have to dive into that deeply, and I think I'll never have the time to truly understand all of the VM, the classes, etc.
I've recently tried to do that myself with Smalltalk via the Glamorous Toolkit[1] (a beautiful, modern Smalltalk environment based on Pharo). Because the programming environment itself comes with a Book teaching it, you can basically just read it as a normal digital book, but with the superpower that everything is editable and interactive: you can change the book itself, every code example is runnable and you can inspect the result objects right there, change it, modify the view for it... they say it's "moldable development" because you almost literally mold the environment as you write your code and learn about the platform.
> And I'd like to be able to create applications that run without shipping the entire Smalltalk VM.
That's why even though I really enjoyed SmallTalk, I can't really see it as anything more than a curiosity. I tried using it at least for my own occasional data exploration because it has good visualisation capabilities and super easy to use HTTP client/JSON parser etc., but the system is so heavy (1GB+ of RAM) that I couldn't justify keeping it open all the time like I do with emacs, on the offchance that I might need to use it for some small task.
Anyway, perhaps that's something you might be interested in.
[1] https://gtoolkit.com/
-
An OOP modern language that is enjoyable in terms of syntax?
I have been building a drawing and animation system in Pharo (smalltalk) for a few months, using a really neat new UI called glamorous toolkit.
- Ask HN: What perfect software did you discover of recent?
-
Pharo 11, the pure object-oriented language and environment is released!
Last time I tried to "hydrate" thousands of SQL rows into objects and both Pharo and the Glamorous Toolkit froze up. Maybe that is to be expected, but I've done that a million times on the JVM without any problems.
-
Ask HN: Has anyone fully attempted Bret Victor's vision?
In my opinion the idea is more than direct data manipulation. It is about how we get feedback. In drawing, the medium to draw is the same medium to read. In programming, there is often a mismatch - coding on a text file, running on somewhere else, e.g. terminal, browser, remote server. If you count surrounding activities for programming, like versioning, debugging, metering and profiling, even more system is involved. We are not even touching the myriad of SaaS offering each tackling carve out a little pie out of the programming life cycle.
Back to your question, from my naive understanding, smalltalk seems to be an all in one environment. The Glamorous Toolkit [1] seems to be that environment on steroid. I have no useful experience to share though.
https://gtoolkit.com/
-
Emacs Is Not Enough
Wrote a review on it on the website, copypasting:
Glamorous Toolkit[1] promotes the idea of moldable development[2].
There's a talk on it: Tudor Gîrba - Moldable development.[3]
The basic idea is to have multiple views and editors for any piece of data in your system (including code). Kind of interesting, but the toolkit looks and acts more like a fancy computational notebook type of environment, but without explicitly being a computational notebook.
The site on moldable development states its difference with literate programming:
They are similar in that they both promote the use of narratives for depicting systems. However, Literate Programming offers exactly a single narrative, and that narrative is tied to the definition of the code. Through Moldable Development we recognize that we always need multiple narratives, and that those narratives must be able to address any part of the system (not only static code).
And that's a sensible viewpoint. But I still see it as an advanced version of a literate programming, all done within an interactive environment.
The focus of Glamorous Toolkit seems to be on explaining a code base or a certain part of the system via presenting it via a custom tool.
But I am not too convinced with the top-level development model / workflow it assumes for you. I guess it's too narrowly-focused / opinionated.
It's also a custom fork of Pharo, so the question of long-term stability is even more unclear than that of Pharo itself.
I can't say I can compare it to Project Mage in any meaningful way, except it's also a live environment.
[1] https://gtoolkit.com/
-
But... what is it?
Wow, that's very interesting, never heard of it before. In the first link and they've mentioned smalltalk and I remember checking out https://gtoolkit.com which I think has some of the ideas from emacs but is implemented in smalltalk. I always wondered if gtoolkit could fundamentally offer something emacs couldn't (at the principal level) but now that you've lebaled them together, I think I know the answer is no
-
The First Rule of Microsoft Excel: Don’t Tell Anyone You’re Good at It
prolly a bit outside the mainstream but -> https://gtoolkit.com/
- Glamorous Toolkit: Moldable development environment
tree-sitter
-
Lezer: A Parsing System for CodeMirror, Inspired by Tree-Sitter
I learned from a google search that these days upstream tree-sitter provides WebAssembly bindings.
Source: https://github.com/tree-sitter/tree-sitter/tree/master/lib/b...
NPM: https://www.npmjs.com/package/web-tree-sitter
Download from the latest Github release: js file (https://github.com/tree-sitter/tree-sitter/releases/download...) and wasm file (https://github.com/tree-sitter/tree-sitter/releases/download...)
-
Difftastic, a structural diff tool that understands syntax
Tree-sitter optimizes for performance (to use in editors), not for correctness. In fact even TS' core developers advocate for not bothering too much with correctness of grammars[1]. I imagine this constraint would be a deal-breaker for GitHub or anyone else in their position.
[1] https://github.com/tree-sitter/tree-sitter/issues/130#issuec...
-
Effective Neovim Setup. A Beginner’s Guide
This is a plugin that provides a simple way to use the tree-sitter in Neovim and also provides functionalities like highlighting, etc.
- An incremental parsing system for programming tools
-
Topiary: A code formatting engine leveraging Tree-sitter
From the tree-sitter side, I am tracking https://github.com/tree-sitter/tree-sitter/issues/1942
-
Shiki Syntax Highlighter
Is tree-sitter really slower than TextMate grammars? Some benchmarks indicate that this isn't really the case [1]. On the other hand, breaking parse trees is a real issue, because the error-recovery in tree-sitter is pretty rudimentary [2][3], but as you said, it's not an issue for Shiki.
Several TextMate grammars suffer from inaccuracy bugs, and issues of maintainability. Perhaps the biggest hindrance in the adoption of tree-sitter, is that the most popular editor, VSCode, still doesn't support it.
[1]: https://github.com/microsoft/vscode/pull/161479
[2]: https://github.com/tree-sitter/tree-sitter/issues/1870
[3]: https://github.com/tree-sitter/tree-sitter/issues/224
-
It seems that some BIG improvements of Treesitter on BIG FILEs have been merged into Nightly! (minutes ago!)
u/lewis6991 I think the biggest performance gain was made by tree-sitter itself: https://github.com/tree-sitter/tree-sitter/pull/2085
-
Looking for Tree-sitter query documentations and guides
I asked on the repo's discussions but responses are limited and not explanatory (I'm not shaming anyone here, discussions aren't a place for detailed how-tos and documentations anyway).
-
Will Treesitter ever be stable on big files?
The following discussion here. TS query cannot be incremental, that is why I regard it as design fault.
-
Detailed syntax highlighting
Hi, so I've recently decided to give Neovim yet another try, this time using some predefined plugins with kickstart.nvim, for syntax it uses tree-sitter.
What are some alternatives?
moose - Multiphysics Object Oriented Simulation Environment
nvim-treesitter - Nvim Treesitter configurations and abstraction layer
quokka - Repository for Quokka.js questions and issues
Visual Studio Code - Visual Studio Code
vim-buffet - IDE-like Vim tabline
indent-blankline.nvim - Indent guides for Neovim
Moose - MOOSE - Platform for software and data analysis.
doom-emacs - An Emacs framework for the stubborn martian hacker [Moved to: https://github.com/doomemacs/doomemacs]
iceberg - Iceberg is the main toolset for handling VCS in Pharo.
language-server-protocol - Defines a common protocol for language servers.
seaside - The framework for developing sophisticated web applications in Smalltalk.
coc-explorer - 📁 Explorer for coc.nvim