Didn't Esteban fixed metarepo ? I think I remember him saying that he did. Don't know how heavy and complex your setup is but if I was in a situation where the building process became to complex with several builds at the same time , I think as Phil said a CI would have been more handy. Its what we use for a vast array of custom images. Obviously you could make your own command line tool with Pharo. An image dedicated to building your own images , you alias the Pharo executable passed the image name to any name that make it look as if it is a bash command or bash utility.
For example Pharo-build gitfiletree ./filetree -replace -stable -runTests On Sat, 22 Oct 2016 at 12:34, Thierry Goubier <thierry.goub...@gmail.com> wrote: > Hi Kilon, > > 2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>: > > it depends, the power that pharo offers is just massive on this department. > > For example you say you dont like the idea of a global startup script, > thats fine because you can have startup scripts per image, they go to the > same folder as your image. If you really have a super complex setup it > would make sense to make a git repo with just your make file and startup > scripts. The makefile can be parameterized with command line arguments to > perform diffirent installs then its a just a matter of copying the correct > startup script to the folder with the appropriate image which of course is > something the makefile can handle too. > > > Good point: the Makefile has to copy the startup script inside the image > directory, if we keep that convention of building the new image inside a > dedicated directory to be able to clean by rm -r that directory. > > > > Mariano has a great post on the subject of startup scripts which what I > used to make my own > > > https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-scripts-in-pharo/ > > By interactive mode again , I assume here you mean the GUI. Again it > depends what you want to do, a pharo install comes with 2 executables > pharo-ui which is the well known gui front and pharo which has no gui. In > both cases you have debug abilities though I presume it would be easier to > do this from inside a GUI. pharo and pharo-ui has an eval argument that > allow you to execute any kind of code and there is also a save argument to > save the image with your new code. > > > Yes. I've been using eval in Makefiles for a few years now. I even prefer > an eval Metacello new baseline: ... to the command line configuration > loader, because I can use the standard Smalltalk syntax with eval (and > Metacello) whereas I need to read the doc for the configuration command > line handler. > > I even have a 'deployment' version for external partners, where the > Makefile detect it is started from an archive extracted from git and not > the original git repo, and switches to filetree (and loading different > packages) to build the image. > > > > If you prefer GUI then you dont even need to pass metacello arguments, > just make a configuration installing all your dependencies and put it in > the STHUB metarepo corresponing to the version of pharo you use, it will be > available from Package browser and you will be able to install all your > dependencies with a single click every time you download a new install of > pharo. Or just install a tool that you can use from playground to install > the dependencies with a simple message. Or make a spec GUI or morphic GUI > and do all that from the comfort of your mouse. OR....... > > the options are just endless. > > > Yes. Oh well, in fact the metarepo thing doesnt work well with Pharo5 and > Pharo6, as one of the user of the GitFileTree configuration discovered a > week or two ago. If you are using Pharo5, a configuration in the Pharo6 > metarepo will override the one in the Pharo5 metarepo. > > > > Another thing to remember here is that a baseline does not have to have > one setup, you can have multiple setups installing things under diffirent > conditions. Baseline also are aware of smalltalk implementation (squeak/ > pharo) and pharo versions. That means diffirent installs under diffirent > conditions and some deep fine tuning. Baseline also allow for actions > before the install after the install, so even if you want to do some clean > up you can do this also from the comfort of baseline. > > Lastly but not least metacello is fully aware of git branches that gives > you even more possibilities since a branch even in the same repo can be a > completely new repo that gives you even more crazy options , since you can > have diffirent Baseline under diffirent branch and of course the branch can > contain its own code and assets (images, sounds , binary files, anything). > > > Yes, > > Thierry > > > > It really comes down to the way you like to work, pharo can do it, you > choose how and what. > > On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier < > thierry.goub...@gmail.com> wrote: > > Hi Kilon, > > 2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>: > > 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. > > > Yes, that looks pretty cool. > > I still stick with Makefiles and command line Pharo to build images, in > part because when I run different projects, I can store inside the git of > the project (i.e. version them) both the squeleton of the build environment > and all the build instructions, instead of having to put a project-specific > startup script inside a settings directory shared among all projects. > > But I certainly see the value of running the startup scripts in the image > in interactive mode, where it becomes a lot easier to debug them. > > While running them on the command line is convenient too (make build, > switch to email, reply, come back when the build is done). > > > > you can find my build setup here > > https://github.com/kilon/makePharo > > > I'll keep it in mind, thanks! > > Thierry > > > > > On Sat, Oct 22, 2016 at 10:06 AM p...@highoctane.be <p...@highoctane.be> > 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 <kilon.al...@gmail.com> > 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 <tblanch...@mac.com> wrote: > > > On Oct 21, 2016, at 07:30, Norbert Hartl <norb...@hartl.name> 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. > > >
