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 <***@gmail.com>
wrote:
> Hi Kilon,
>
> 2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <***@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 <
> ***@gmail.com> wrote:
>
> Hi Kilon,
>
> 2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com> wrote:
>
>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
>
>