Superb Phil.

PS: For the record:

    we are working on

        - bootstrap core and we are making progress

        - Git support

        - package manager and distribution building

Now we cannot go faster.

This is not every year that we change the complete representation of objects.

Now it was NEEDED and we get Spur and SIsta.

Stef


Le 22/10/16 à 09:04, p...@highoctane.be a écrit :
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.



Reply via email to