[ANN] Sparta v1.1

This link may interest you command line people , it basically what I proposed as an idea early on

https://github.com/guillep/Scale

Dale,

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-gemstones-64-bit-
[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

On 10/22/16 12:08 AM, [hidden email] wrote: 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

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 [hidden email] <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

On Oct 21, 2016, at 07:30, Norbert Hartl <[hidden email]> 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.

On 22 Oct 2016, at 10:56, Dimitris Chloupis <[hidden email]> 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

Norbert,

Dale,

Am 21.10.2016 um 22:15 schrieb Dale Henrichs <[hidden email]>:

On 10/21/2016 07:30 AM, Norbert Hartl wrote:

Dale,

Am 21.10.2016 um 16:12 schrieb Dale Henrichs <[hidden email]>:

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:



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: '<a moz-do-not-send="true" href="filetree://repository/" class="">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/LockCommandReference.md#lock-command-reference
[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

On 22 Oct 2016, at 12:41, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

On 22 Oct 2016, at 12:00, Dimitris Chloupis <[hidden email]> wrote:

Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

fixed in what sense?

Esteban

On 10/22/16 7:01 AM, Dimitris Chloupis wrote:
> 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.
This is why I'm threatening to create MetacelloProjectLoadSpec ... not
to be elegant but to save you the work of creating such a beast on your
own ... I really think there can be great advantages to have a sharable
and customizable load spec object ...
>
> 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.
I have collected a number of the TDProjectEntry objects up on the
GsDevKit_home project on the gh-pages branch and I a variant of the load
command that works with an url:

   project load --url=http://gsdevkit.github.io/GsDevKit_home/Metacello.ston

That directly downloads form web ... I put things on disk, so that the
developer can download the official object to a known location on disk
and then edit/customize the object for her own use.

Then build scripts will use the object from the directory by default and
each image shares the same custom load specification object.

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
>
> 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.md
Ah yes, it would be much more convenient to get the load specification
object directly from the project itself ...

Dale

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.

ConfigurationOfs are "obsolete" ... github projects use BaselineOf and the BaselineOf is not portable. The BaselineOf is meant to be loaded from the repository that it manages ...

The catalog browser uses the ConfigurationOf to get meta-data about the project and then uses the ConfigurationOf to load the project and at the moment for a github project to be listed in the catalog one must create a ConfigurationOf whose sole purpose is to provide meta data to the catalog.

A MetacelloProjectLoadSpec would provide the portability that a BaselineOf lacks, while providing the necessary meta data and maintaining the loadability of a ConfigurationOf.

 Finally, a MetacellProjectLoadSpec is useful for more than just the Pharo catalog. The same object could be used to load projects in Squeak and GemStone and as I have mentioned in the previous email could be a component of local build scripts as well ..

So yes I think that there are additional advantages:)

Dale

On Sat, Oct 22, 2016 at 4:51 PM Dale Henrichs <[hidden email]> wrote:

On 10/22/16 3:09 AM, Esteban Lorenzano wrote:

On 22 Oct 2016, at 10:56, Dimitris Chloupis <[hidden email]> 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