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 p...@highoctane.be
<mailto:p...@highoctane.be> <p...@highoctane.be
<mailto: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 <mailto: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 <mailto:tblanch...@mac.com>> wrote:
On Oct 21, 2016, at 07:30, Norbert Hartl
<norb...@hartl.name <mailto: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.
