> > Cuis basically delegates everything to git and use one file per package. > >
yes thats the direction I want to go with this, if possible kill any kind of meta information and turn everything to Smalltalk code. Even fileout contains meta data. > > He has a nice lib interface targetting both mercurial? and git; a kind of > ancestor to Pharo libgit effort. Mainly targeted at Smalltalk/X > are you talking about this https://github.com/janvrany/libgit2 his last commit was 4 years ago. this is going the exact opposite direction once again tries to bring git inside the pharo image. Or are you talking about something else ? "I don't understand how you can say that after so many years. The secret, the attractiveness of Pharo/Smalltalk is the _combination_ of the language, the library and the environment (IDE). You can consider these separately and many projects have taken one element out of it to another context. However it is the combination that is magic. Working (developing) command line or file based in Pharo/Smalltalk feels so uncomfortable that it simply hurts. No browsers, no senders/implementors, no workspaces, no inspector, no debugger, no spotter, no interaction, no ... Anyway, this is my opinion and you are of course entitled to yours." I try to refrain from criticising Pharo, because I don't want to decrease the motivation of people contributing to Pharo which I consider critical to the improvement of Pharo and secondly because my criticisms are largely based on personal taste which I think would make for a very poor discussion since personal taste cannot be debated. The summary of my ideology is that there are only parts of Smalltalk I really like and not the whole thing. I have several ideas about Pharo. Whether some or all of those ideas will be proven bad or too difficult to implement , time will tell. Some of those ideas are 1) a component based environment similar to Delphi (one of the things I loved about Delphi). Basically Objects on steroids. 2) An enhancement of visual coding experience in Pharo. Roassal could help here. 3) The ability to use Emacs as an alternative code editor outside the box. Shampoo has accomplished this goal, but I have not tested it yet. 4) Deep integration with both C++ and Python, this is more than a need since I depend both on Python and C++, this idea is the closest to materialisation and probably my most critical one 5) Modular image = This one I am lucky enough that is already a Pharo goal and an ongoing project 6) A more powerful documentation system , Pillar could help here and the inspector / gtspotter 7) Auto update in the background , not a high priority goal since I will be using the Steam API that handles updates but it would be nice 8) Fragmentation of the image format, this one will be a combination of fuel (or custom format) and bootstrap 9) Removal of any mid ground between Smalltalk code and Git , this is the idea I was talking early on 10) Integration with OS tools , like file browsers, web browsers , system utilities etc 11) Replacement of Morphic with QT, I already can do this at least in part with my python bridge but for now its a low priority 12) Management of user analytics, that will be specific to my games and probably will utilise Steam's and Unreal's analytics for gathering information about the user , obviously with the permission of the user, most likely this will require minimum Pharo code 13) Unification of Browser, Workspace , GTInspector, GTDebugger and GtSpotter under one tool 14) More strict evaluation of potential errors and user mistakes and many more. All those ideas are mostly long term so it may be years if not a decade before they materialise and probably will change along the process to fit practical needs. You could say that Ephestos most likely will turn into an alternative Pharo Distribution like Cuis is for Squeak but with very different goals. Again my goal is not to produce something for public consumption but merely an image that follows more closely my personal taste.
