Spec
iceberg
| Spec | iceberg | |
|---|---|---|
| 1 | 5 | |
| 61 | 133 | |
| - | 0.0% | |
| 9.2 | 9.1 | |
| 4 days ago | 11 days ago | |
| Smalltalk | Smalltalk | |
| 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.
Spec
-
Pharo 10
On the screens in Getting started tutorial I found this: https://github.com/pharo-spec/Spec
iceberg
-
LSP could have been better
The problem with the filesystem is that it privileges organization scheme which isn’t the best one for every editing task. This makes, for example, implementation inheritance hard because your class has a bunch of invisible code in it. But, it you could expand all the superclass methods into a single view and then have edits automatically integrated into the appropriate places, this wouldn’t be as much of a problem.
Java’s filesystem hierarchy is a great example of a “fileout” format for the sort of environment I’m talking about. Another example here is smalltalk repositories generated by Iceberg: https://github.com/pharo-vcs/iceberg
-
Pharo 11, the pure object-oriented language and environment is released!
and looking at sample git commit (I assume this was done in Iceberg): https://github.com/pharo-vcs/iceberg/pull/1687/files
-
Stop Writing Dead Programs
By committing the code to a git repo and having a code review like every other language out there.
I'm guessing you have never tried these things but image based Smalltalk implementations have supported VCS for decades now, literally. In Pharo this is with git using Iceberg:
https://github.com/pharo-vcs/iceberg
They even wrote a tutorial to make it easier: https://github.com/pharo-vcs/iceberg/wiki/Tutorial
It's not magic, it's not even a problem, because the problem you're imagining doesn't actually exist. So long as the user of the system has at least half a brain (and maybe less) they will be capable of distributing their code with git these days.
-
Design Principles Behind Smalltalk (2001)
Iceberg for Pharo: https://github.com/pharo-vcs/iceberg
Monticello: http://www.wiresong.ca/monticello/
I haven't used the latter, but the former is easy to use and based on libgit. Create a new repository, select the packages that go into it, make the initial commit. After that it'll tell you when the changes don't match the repo. You can select down to the method level since it's aware of the language's syntax and semantics. The generated repository looks like the Iceberg repo itself, a collection of directories for the packages and then .st files for the classes and their contents.
-
Pharo 10
> a copy of your code the environment does some extra epicycles to copy it outside
Iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.
What are some alternatives?
seaside - The framework for developing sophisticated web applications in Smalltalk.
gtoolkit - Glamorous Toolkit is the Moldable Development environment. It empowers you to make systems explainable through experiences tailored for each problem.