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. >> >> >>
