I really like STON , even more than I like JSON. Very readable and easy to edit format. Very good idea, I would probably something similar but less more elegant.
You probably know this, but if you host the ston configurations files as you do in that link , Github gives you the ability to directly read files from inside a git repo without having to download it via its blob directory. So one could keep those ston config files in a repo in git and have access to it from any computer , any OS, of course under the condition he/she is connected to internet. This trick is what I used for checking whether there is a new version of my project ChronosManager in my git repo. I added the latest version in the RELEASENOTES text file that is located on the top level repo which it compares with its internal versions (just a class variable) and if it finds it bigger it alerts the user for an update. https://raw.githubusercontent.com/kilon/ChronosManager/master/RELEASENOTES.md Top version is marked X because is not yet a stable release. This way the project wont download it. On Sat, Oct 22, 2016 at 4:35 PM Dale Henrichs < [email protected]> wrote: > > > On 10/22/16 12:52 AM, Dimitris Chloupis wrote: > > Actually we dont, I am using the terminal to get and build my own images. > Curl + use of startup scripts are more than enough. Simply , easy and > straightforward. Pharo offers a super easy way to export any method as a > command line argument. So there is literally no excuse. > > Pharo already offers a metacello argument so you are set to go on > installing anything you want through the terminal in your image and also > offers evaluation of smalltalk code as argument. But I prefer startup > scripts, I have made a startup script that can detect the name of images > and install different packages to them, you can do insane things with > startup scripts actually. > > you can find my build setup here > > https://github.com/kilon/makePharo > > For GsDevKit_home, I have a projects directory[1] where I store > TDProjectSpecEntryDefinitions ... which are the moral equivalent of each of > your `Metacello new` lines in the script ... By putting a Metacello load > "spec" in an object, it is easier to customize the build of an image, than > it is to edit and manage a smalltalk script. For example in tODE here are > the commands that would be used to construct your image (the name of the > project refers to the names the .ston objects in the projects directory: > > project load IconFactory > project load ChronosManager > project load Nireas > project load Ephestos > > With scripts based on something like this, it is easy to change all of the > load scripts sharing the load specs (TDProjectSpecEntryDefinitions) by > editing the .ston file on disk ... all builds going forward would pick up > the new specification ... > > Dale > > [1] > https://github.com/GsDevKit/GsDevKit_home/tree/master/sys/default/server/projects > > > > On Sat, Oct 22, 2016 at 10:06 AM [email protected] <[email protected]> > wrote: > > We need some easy to use gem-style installer on the command line. > > Pharo is perfectly usable for any kind of project provided energy is > poured in. > > Things are in flux, yes, and it is frustrating not to have it all perfect. > So what? If we weren't interested in wild things why would we be here after > all? > > Think long term: 10 years from now, improvements will have been massively > compounding (not to mention 20). > > I hope to have a huge win with Pharo business wise and be able to fund a > serious team. That's my dream. I am actively working on it. > > Pharo can stay relevant for that long I believe. I love the way it helps > me think. I love the fact that I can look everywhere I want. I love the > fact that this community has balls. I love to show the magic we can do with > it. If it all goes nowhere, I do not even mind as I have a damn awesome > time around here. > > Now, I also want a working text model. This feels like a kind of > psychological roadblock. Like a self sabotage. Let's put that dead rat on > the table and make something about it. > > I like Doru's Pillar editor. I guess the underlying engine will evolve to > make it faster. Great. Grafoscopio will also be a driving force there I > believe. Pharo can be superspeedy, no core problem. > > Sorry for the rant. > > Now back to promoting Pharo in front of Android/Angular/Java people this > afternoon at http://devfest.be (note that this is the 3rd time I show > Pharo/Amber there - they could kick me out but do not). > > /Phil > > > On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis <[email protected]> > wrote: > > Actually you are wrong, its not hard to use C libraries from Pharo. UFFI > is not a restart, its a continuation of Nativeboost , they are very > similar. > > Pharo FFI, whether its the old FFI, Alien, Nativeboost or UFFI, is more or > less the same. In the end an FFI is defined by C syntax , Pharo UFFI > borrows the easy of use of Nativeboost that allows you to take c functions > definition and use them as they are with a simple copy paste. > > Pharo is also is based on very good integration with C , like Squeak can > output its code as C code via the Slang interface though it comes with some > limitations. > > The availability of C libraries to Pharo is a reflection of the community > size. Comparing with Ruby is very unfair , as Ruby is vastly more popular > (think in thousand times) , hence why you see so many C libraries wrapped > for Ruby. Of course python kicks Ruby ass kung fu style with its vastly > superior array of C wrapped libraries. > > The moment you decide to use an unpopular language as Pharo then if you > are not prepared to get your hands dirty and you expect things on your > plate like Ruby or Python , then its time to go back to Ruby or Python. > > Pharo is not in flux , its evolving, every new tool or library you see is > an evolution of something else. > > We dont need Gems for Pharo, Dale has done a great job with Metacello, its > easy to make a pharo project in git/github and have it install all pharo > code and built C libraries wrapped for Pharo. Just because people are not > in the habit of doing this does not mean its not super easy to be done. For > example AFAIK my project ChronosManager was one of the first project to > install from Catalog Browser not only its Pharo code but also , pngs and > audio files. I made even an autoupdate feature that pings my github repo to > see if there are any new commits and then if so it alerts the user and give > him the ability to download the update with a single click. All that is > metacello. > > Metacello is probably one of the best if not the best package distribution > systems out there. Definetly vastly better than Python's PyPi and Node'js > NPM . I cannot praise it enough and I have no problem criticising Pharo > when I must. Dale has done an amazing job, period. > > On the GUI front on the other hand, its messy, no doubt about it. Morphic > is huge, ugly and almost not maintained. Bloc is probably going to be the > next step. > > I think the issue here is that we dont have Arduino or Raspberry Pi guys. > Same story for my field, 3d graphics. There is a OpenGL wrapper and the > Wodden graphics engine and nothing else. I and the author of Woden are the > only people here interested into 3d graphics, he makes Woden, I have made a > bridge with Blender Python , for using Pharo to make Blender addons and I > am now in the process of making a bridge with Unreal Engine. > > I dont see why you would have an issue using Pharo from Raspberry Pi, we > already support SDL and you can even run Pharo with no GUI from the > terminal and export any Pharo method as a command line argument. My Python > socket bridge also showed me that is dead easy to connect Pharo with other > programming languages, in my case python , with just a few hundred lines of > code. Typical IPC. > > So there are no excuses for not using Pharo, from there on, it depends on > your specific needs and wants and taste. > > On Fri, Oct 21, 2016 at 7:05 PM Todd Blanchard <[email protected]> wrote: > > > On Oct 21, 2016, at 07:30, Norbert Hartl <[email protected]> wrote: > > The current (!) complaint is rather based on the fact that everything > regarding the graphics backend, widget and tools appears sometimes as an > indefinite loop of reinventing stuff and improving and never get the job > done. Did I mention 64bit, UFFI,… I'm glad all these topics are worked one > and I see a bright future if half of them are done. But then sometimes it > looks rather dark and the light at the end of the tunnel just went off :) > > > I feel you. > > I very much want to use Pharo to build devices from things like Raspberry > Pi's, iPhones, and Androids. I need access to native libraries. You can't > rewrite everything ever in Smalltalk and I don't really see a good reason > to. > > I've taken about ten years off from doing Smalltalk and I'm trying to get > back into it. My interest is piqued because I want to build nice custom > systems using the nifty new cheap goodies like Arduinos and RPis and it > seems tossing together a full screen Pharo image would be a great way to > build these appliances. In that time the story for how to call out to > native code has changed...twice. Everything is broken or in flux again. > > To me, it doesn't feel like there's any more platform to build apps on > than there was ten years ago and everything is still "just around the > corner". Pharo seem to be an experiment in building next generation > programming tools using deprecated last generation programming tools. I > don't see a lot of useful programs being built atop it - largely because > the base is constantly shifting about. > > It is disheartening that the Ruby guys can crank out gems with native > libraries that compile and work on every platform and pharo is still > constantly half broken with loadable native code "doable" but only with > great effort. > > I looked and Moz2D doesn't seem to have a light weight build for Raspberry > Pi. Is hitching Pharo to a heavy weight graphics library as a core > requirement a good idea? > > I'm starting to think maybe we need something like Gems for Pharo - > dynamically loadable libraries and resources - compiled at install if > necessary. > > > >
