October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Norbert Hartl

Isn't that something complementary to pharo. Why have the tools a different name??? I think pharo should be usable as scripting engine. And that means files should begin with #! /usr/bin/env pharo Norbert > Am 22.10.2016 um 13:41 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > >> On 22 Oct 2016, at 12:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> This link may interest you command line people , it basically what I proposed as an idea early on >> >> https://github.com/guillep/Scale > > yes, Santi is working a lot on it so I think they are going to release it very soon :) > > Esteban > >> >>> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>> I was replying to Thierry saying that we had issues with Pharo mixing metarepo6 with metarepo5 >>>> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>> >>>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did. >>> >>> fixed in what sense? >>> >>> Esteban >>> >

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

Norbert, On 10/22/16 3:56 AM, Norbert Hartl wrote: > Dale, > >> Am 21.10.2016 um 22:15 schrieb Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>: >> >> >> >> On 10/21/2016 07:30 AM, Norbert Hartl wrote: >>> Dale, >>> >>>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs >>>> <dale.henrichs(a)gemtalksystems.com >>>> <mailto:dale.henrichs@gemtalksystems.com>>: >>>> >>>> Norbert, >>>> >>>> I didn't realize that you were claiming that the new text model for >>>> Sparta was (potentially) inferior. >>>> >>>> The other day you were expressing sadness about having to use the >>>> newer version of Metacello (which is *only* 3 years old), so I >>>> assumed that you were just being generally cranky about change:). >>>> >>> it might be true it is a current topic for me. In my struggle to >>> establish a solid devlopment process I have sometimes the feeling it >>> is impossible. Especially when the new metacello thingie improves >>> something I don't know but at the same time I loose Versionner and >>> the commandline handlers which I know :) >>> 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 :) >>> >>> <dark mode off/> >>> >> Okay, so you _are_ being generally cranky:) > > Seems to be the case ;) Please, don't take it personal. I like others > here are trying to propose pharo to other people and doing software > projects with it. I can see the need for change and I'm able to > adjust. If I complain publicly (and I keep myself from doing that for > some time) it is just a sign that I'm not able to deal with all of > this. It might be just me having that problem. If not it means that it > might be a general problem and that's something to think about. I do not take it personally ... and I agree with you completely, there is great value in "well-tempered crankiness" >> >> FWIW, I took great pains to ensure the the old way of using Metacello >> continued to work the old (buggy) way while introducing the new >> (non-buggy) way and that you should be happy to only start feeling >> the pain of this new feature 3 years after it was introduced:) >> > I don't care which way it is. I took the freedom to take metacello as > granted and didn't see the need to adjust my way of doing until now. > It is quite handy to have a few parts in your workflow that are not > moving. And I didn't know until now that there is an old and a new > way. If Cyril is right and the commandline handler is using the "new > way" then my complaint is as wrong as annoying. But that would be the > perfect case that it changed without infecting me. > Well, it is just the case that using the pharo commandline handler > does not work while eval plus the new way works. So if I didn't do > something wrong we should remove the handler for configurations. And > as I said I was so happy having Versionner and now it is more or less > useless. Well, I think others might do it the same way by managing > their dependencies with Versionner and then copy the baseline method > into the baseline class. Awkward, annoying and the best I can imagine. Yes, Metacello tools have been a great sticking point ... I decided early on that I could not afford to get involved in creating and maintaining GUI tools (for three platforms) not only because I don't have the time, but because creating GUI tools is one of those thankless jobs:) Not to mention that it is incredibly difficult to put together a comprehensive and complete GUI tool. I think that the original reason that Versionner did not handle BaselineOf is that support for BaselineOf was missing from the MetacelloToolBox ... I have since added BaselineOf support to MetacelloToolBox, but of course the developer of Versionner is most likely busy with something else ... With the MetacelloToolBox support for BaselineOf an enterprising individual should be able to add BaselineOf support to Versionner:) > >> I should also note that I have no plans to remove the old way of >> doing things, even though I don't recommend that anyone use the old >> way anymore ... At GemStone we have users running on 20 year old >> versions of our product, so I have an appreciation for "legacy users." >> > I'm sorry if you meant my complaint includes you. No, there are a few > people that I would need to exclude from my complaint explicitly. But > that is not possible without punching everyone else in the face :) I > like the way you handle things. And I know you enjoy getting annoying > questions from people like me. As I said, I appreciate "well-tempered crankiness" as it keeps me honest:) But crankiness begets crankiness and I apologize for going over the top in my response as well:) > >> If you are using filetree based projects then the only way to access >> them is the new way... >> > Yes, but you know â¦ things are moving and the "new way" is so "first > half of 2016" because now we have iceberg which makes the situation > potentially better but actually more complicated (you see ;) ). > Loading projects do not anymore depend on a tool like metacello that > loads but also on the kind of repository is created for all the > projects inside of metacello. I'm nagging Nico to establish a workflow > where I can checkout a git repo, load my project using metacello and > then can use iceberg to management my development. Yeah, I really think that when working with git repos that the tools need to de-emphasize packages and instead focus on the fact that there is a one-to-one correspondence between a github project and a Metacello project. In the following screen shot from tODE, each line represents a Metacello project and I can save, diff and load without ever looking at a package: tODE project list screen shot As I mentioned in another email this morning I will be talking about this approach in more detail in my talk with the working title "Dangerous Liaisons: Smalltalk, Files, and Git" ... > > But that is a problem we need to tackle anyway. In my metacello > baseline I have > > spec repository: 'filetree://repository/'. > > to load my code from a sub-directory of that git working copy. That's > ok but if I like to develop on that project I would need gitfiletree > or iceberg to do that in image. So while for loading the project the > filetree scheme based url is ok for doing actually work it is not. And > I'm not sure where is the right place to put it. I could also imaging > that I can instruct metacello to create the right kind of repository. > I think that you need to look into Metacello locks[1]. You use a lock, to associate a Metacello project with a repository that may be different that that specified in a baselineof. This feature was specifically invented to make it possible to create a BaselineOf that references the official download location like: `gitfiletree://github.com/dalehenrich/metacello-work:master/repository` but then in my working image, lock the project to point at the filetree directory on my local disk ... If you've seen my comments about TDProjectSpecEntryDefinition and MetacelloProjectLoadSpecs there is a `locked` field[2] that is meant to allow you to specify that the repository location in the TDProjectSpecEntryDefinition should be locked. At this point it is also important to note that you can lock unloaded projects ... [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Metacello.ston#L10 > >> Regarding the "command-line", did you know that once you've loaded a >> project using the new way, that you can re-load a project using the >> following shorter smalltalk script: >> >> Metacello image baseline: 'AAA'; load >> > That's good and will try that. > >> I made a sweep through the docs a couple of years ago, but since no >> one seemed to be interested in using the new API I found other things >> to do ... and now that there's more interest in the "new way" I >> simply don't have the time (right now) to make another pass through >> the docs ... so you can be cranky about that too :) >> > Come on! Now you sound a bit cranky :P > haha ... "well-tempered crankiness" my friend, "well-tempered crankiness" Dale

Oct. 22, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Dimitris Chloupis

Configurations in MetaRepo are supposed to be maintained and uploaded by developers anyway. Its a public repo with no requirement for access to write and read. http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60 Unless your solution offers an advantage I cant see. On Sat, Oct 22, 2016 at 4:51 PM Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 10/22/16 3:09 AM, Esteban Lorenzano wrote: > > > On 22 Oct 2016, at 10:56, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > We need some easy to use gem-style installer on the command line. > > > we have it: > > ./pharo Pharo.image get Seaside3 > > will load seaside into your Pharo.image > > this is catalog based, of course (there is no magic there, if you want an > easy way to install things, you need a centralised repository). > > Esteban > > ps: there are a lot of perks like that people ignoresâ¦ what we actually > need is a better documentation system :) > > Esteban, > > I really think that the catalog could benefit by a first class objects > like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be > objects directly created and maintained by the project developers > themselves. The objects would be used for custom build scripts, > smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello > class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.) > > As a coincidence, I have been planning on talking on this subject at the > upcoming Smalltalks conference ... The working title for the talk is > "Dangerous Liaisons: Smalltalk, Files and Git" ... > > Dale >

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dimitris Chloupis

I really like STON , even more than I like JSON. Very readable and easy to edit format. Very good idea, I would probably something similar but less more elegant. You probably know this, but if you host the ston configurations files as you do in that link , Github gives you the ability to directly read files from inside a git repo without having to download it via its blob directory. So one could keep those ston config files in a repo in git and have access to it from any computer , any OS, of course under the condition he/she is connected to internet. This trick is what I used for checking whether there is a new version of my project ChronosManager in my git repo. I added the latest version in the RELEASENOTES text file that is located on the top level repo which it compares with its internal versions (just a class variable) and if it finds it bigger it alerts the user for an update. https://raw.githubusercontent.com/kilon/ChronosManager/master/RELEASENOTES.… Top version is marked X because is not yet a stable release. This way the project wont download it. On Sat, Oct 22, 2016 at 4:35 PM Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > 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/pr… > > > > On Sat, Oct 22, 2016 at 10:06 AM phil(a)highoctane.be <phil(a)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.alios(a)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 <tblanchard(a)mac.com> wrote: > > > On Oct 21, 2016, at 07:30, Norbert Hartl <norbert(a)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. > > > >

Oct. 22, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Dale Henrichs

On 10/22/16 3:09 AM, Esteban Lorenzano wrote: > >> On 22 Oct 2016, at 10:56, Dimitris Chloupis <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> >> We need some easy to use gem-style installer on the command line. > > we have it: > > ./pharo Pharo.image get Seaside3 > > will load seaside into your Pharo.image > > this is catalog based, of course (there is no magic there, if you want > an easy way to install things, you need a centralised repository). > > Esteban > > ps: there are a lot of perks like that people ignoresâ¦ what we > actually need is a better documentation system :) Esteban, I really think that the catalog could benefit by a first class objects like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be objects directly created and maintained by the project developers themselves. The objects would be used for custom build scripts, smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.) As a coincidence, I have been planning on talking on this subject at the upcoming Smalltalks conference ... The working title for the talk is "Dangerous Liaisons: Smalltalk, Files and Git" ... Dale

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

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/pr… > > > On Sat, Oct 22, 2016 at 10:06 AM phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@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.alios(a)gmail.com <mailto:kilon.alios@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 > <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: > > >> On Oct 21, 2016, at 07:30, Norbert Hartl >> <norbert(a)hartl.name <mailto:norbert@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. > >

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

On 10/22/16 12:08 AM, phil(a)highoctane.be wrote: > Dale, > > I looked at the docs but it was kind of a hunt as they were a bit kind > of everywhere.\ > > * Book chapters (Pharo). This including preversions with more info > than the published one > * Google code wiki pages > * Github > * Other but can't even remember > > Is there an official place for all things Metacello? Well the github repo should be the "official place" but besides being a poor writer I really have never figured out how to organize documentation --- which should be obvious by now ... I suppose I should take 6 months or a year off to learn how to write/organize good documentation but there's just "one more bug that I need to fix, before I do that"... With that said, I have never turned down a pull request to the github repo. Dale

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

On 10/22/16 12:04 AM, phil(a)highoctane.be wrote: > We need some easy to use gem-style installer on the command line. Phil, Since I am not really familiar with ruby, I'm not sure what you mean by "gem-style installer on the command line"? Depending upon what you mean, I think I agree:) For GsDevKit_home[1], I have arranged for bash scripts that can be used for building both stones and clients for GemStone. Here are the example scripts for Tugrik[2]: |# Create Tugrik stone createStone -u http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston -i Tugrik -l Tugrik Tugrik 3.3.0 # Create Tugrik Pharo5.0 client createClient -t pharo tugrik -l -v Pharo5.0 -z $GS_HOME/shared/repos/Tugrik/.smalltalk.ston| The Tugrik.ston file is a tODE object looks like the following[1] when materialized (basically a Metacello load script with additional info): ^ TDProjectSpecEntryDefinition new baseline: 'Tugrik' repository: 'github://dalehenrich/Tugrik:master/repository' loads: #('default'); installScript: ' project install --local --url=http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston project clone --https --local Tugrik'; postLoadScript: 'mount @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik'; status: #(#'inactive'); locked: false; yourself Their are fields for comments and a project url as well ... obviously other fields are possible ... the cool thing about this is that is a specification for a load rather than a Smalltalk load expression ... which means the repository can easily be re-targetted or the loads list changed, etc. Since Pharo doesn't have tODE:), I leverage the SmalltalkCI[4] configuration file for Tugrik[5], which looks like this: SmalltalkCISpec { #loading : [ SCIMetacelloLoadSpec { #baseline : 'Tugrik', #load : [ 'CI' ], #onWarningLog : true, #directory : 'repository', #platforms : [ #gemstone, #pharo ] } ], #configuring : [ SCIGemStoneServerConfigSpec { #defaultSessionName : 'Tugrik', #platforms : [ #gemstoneClient ] } ] } Very similar information, but has the advantage of being usable in GemStone, Squeak and Pharo ... I have an option for creating stones using a SmalltalkCI configuration file as well ... I've been thinking that I could add a MetacelloProjectLoadSpecification class to Metacello that is meant to be passed around as an object in STON format that combines the good bits of the TDProjectSpecEntryDefinition with the good bits of the SCIMetacelloLoadSpec and be available in GemStone, Pharo and Squeak ... then you'd just send #load to the object to trigger the install ... Is there anything in the "gem-style installer on the command line"that I'm missing? Am I completely off-base? Dale [1] https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-g… [2] https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client [3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci--- [5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Denis Kudriashov

2016-10-22 11:55 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > MozServices crash is intentional! > When you load Sparta using metacello it runs installer scripts and > automatically starts services. But they are already running if you have > Sparta installed. > > I need to find a pretty solution for it. Actually it is complicated. > Services can not just stop while image is running, because rendering would > instantly crash. Imagine if Bloc is running on Sparta, playground is > rendered on Sparta. And now you stop services to update. What should > happen? :) > > Just take fresh image. I will add an assertion to forbid Sparta > installation if it is already installed. > Yes, this is what I thought about.

Oct. 22, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Esteban Lorenzano

> On 22 Oct 2016, at 12:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > This link may interest you command line people , it basically what I proposed as an idea early on > > https://github.com/guillep/Scale <https://github.com/guillep/Scale> yes, Santi is working a lot on it so I think they are going to release it very soon :) Esteban > > On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > I was replying to Thierry saying that we had issues with Pharo mixing metarepo6 with metarepo5 > On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> Didn't Esteban fixed metarepo ? I think I remember him saying that he did. > > fixed in what sense? > > Esteban >

Oct. 22, 2016