Hi Stéphane Indeed, build is broken :) Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me) You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically. As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more. It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily. Let's take Pharo6 for mac. It is shipped with the following libs: Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb Moz2D is self contained and does not require any additional libs. Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb). As you can see we get almost the same numbers :) Cheers Alex On Oct 19, 2016 22:16, "stepharo" <stepharo@free.fr> wrote:

Hi Aliaksei

It looks gorgeous. I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM.

Then I have a question:

- do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us.

I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage.

Stef Le 19/10/16 à 18:06, Aliaksei Syrel a écrit :

Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6. https://github.com/syrel/Sparta/tree/v1.1

It can be bootstrapped with the following script:

Metacello new baseline: 'Sparta'; repository: 'github://syrel/sparta:v1.1/src'; load: #file:core

Examples are on class side of: MozExamples, MozTextExamples (*for linux users:* if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) Release of v1.1 is focused on hardware acceleration, windows support and text rendering. *What is new:* - Default backends on all platforms changed from software to hardware accelerated. - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. - Added initial text support, for instance rendering and high precision measurement. - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. Some text examples: (rendering) [image: Inline images 2] (measurement) [image: Inline images 1] Cheers, Alex

Hi Aliaksei 2016-10-20 9:16 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:

Was tough decision :) We decided (in GT) that next moldable tool should be a "Moldable Text Editor for Pharo". Here are some requirement that must be full-filled by text editor:

Could you explain what is wrong with TxText model to achieve this? (I comment bellow each point). And do you have any links to understand what moldable text editor means?

- support of very large files (gigabytes)

TxText-Athens implement text morph to show big text models. Maybe the way how it is designed is not suitable for Sparta and Bloc. Then I will understand if you will just drop away this code and build Bloc/Sparta optimized version but on top of same text model. If you talk about showing *files* it is not enough of course because full text model needs to be loaded from file which is not scale when file size is huge. But TxText model looks very smart to provide lazy logic where text elements are loaded and built by demand. And it looks much easy to do than with Rope kind model. TxText is linked list of elements. No problem to build them lazily.

- multithreading (styling, syntax highlighting in background)

I am really interesting how it could be done and why Rope model is better than TxText model from this perspective. Styling is just editing text by splitting elements and marking them with specific attributes. How to do it in background when somebody could edit text in same time? Rope model or TxText model is complex structure. It is quite difficult to make it safe for concurrency.

=> text model has to be immutable

So solution is to not modify existing model. For example we could extract full string from text, build new model and install it into widget. But here is same problem original copy could be modified by user while new model is built. What to do then? I actually made conclusion that background styling is bad idea. (in the way when we show text to user and only then start styling it) - fast access by index (for styling; parser returns Tokens with indices)

Ok. Here Rope model works better then TxText. But is it really important case? For your styling example it is possible to solve it differently. Imaging if parser will produce text model itself. So any parse node will not point to token string but to text element inside text model. And then styler will just mark them with attributes directly. No index access will be needed. And such approach could lead to very interesting things. Imaging that source code is text model where elements are marked by AST-nodes (as attributes).

- optimised for sparta (use all amazing text features provided by Moz2D)

I see same kind of text attributes in Sparta text as in TxText. What else you added to text to cover specific Sparta features and why attributes was not enough for this?

2016-10-20 9:07 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:

As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more.

It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily.

Let's take Pharo6 for mac. It is shipped with the following libs: Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb

Moz2D is self contained and does not require any additional libs. Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb).

Also imaging that we will remove Cairo, Athens, Fonts from image, font plugin from VM. Also Morphic and old Canvas. I expect Morphic is much bigger then Bloc. And at some point bitblt stuff from image and VM. I am sure at the end new clean solutions will provide much lesser image and VM size.

Hi Clement, Thanks for raising this question. In short, Sparta is inspired from Athens and it has a similar structure. So, there is an in-image interface of the canvas, and there is a concrete implementation through the plugin (based on Moz2D). To target a completely in-image rendering, it is certainly possible to implement a BitBlt backend of the Sparta canvas. To implement this part, we would need help. The goal is indeed to have only one canvas in the default Pharo distribution: Sparta. However, this will not happen suddenly. Ideally, when Pharo 6 will be released, there will be a beta version of Sparta + Bloc + some tools that will be loadable externally. Then my guess is that it will still take another year until we get the full development environment working on top of Sparta. So, it is to be expected that this transition will take at least 1.5 years during which time Athens will still provide the option of running on top of BitBlt. Does this answer the concern? But, now my question: Would it not be possible to get the VM to not open a window when in headless mode? Cheers, Doru

On Oct 21, 2016, at 2:23 PM, Clément Bera <bera.clement@gmail.com> wrote:

On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote: Hi Stéphane

Indeed, build is broken :) Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me)

You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically.

As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more.

It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily.

Let's take Pharo6 for mac. It is shipped with the following libs: Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb

Moz2D is self contained and does not require any additional libs. Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb).

As you can see we get almost the same numbers :)

Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE.

Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint.

Which leads the first question...

...

...

Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ?

The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger.

...

...

Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ?

Cheers Alex

On Oct 19, 2016 22:16, "stepharo" <stepharo@free.fr> wrote: Hi Aliaksei

It looks gorgeous. I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM.

Then I have a question:

- do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us.

I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage.

Stef

Le 19/10/16 à 18:06, Aliaksei Syrel a écrit :

...

Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6. https://github.com/syrel/Sparta/tree/v1.1

It can be bootstrapped with the following script:

Metacello new

baseline: 'Sparta' ;

repository: 'github://syrel/sparta:v1.1/src' ;

load: #file:core Examples are on class side of: MozExamples, MozTextExamples (for linux users: if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) Release of v1.1 is focused on hardware acceleration, windows support and text rendering. What is new: - Default backends on all platforms changed from software to hardware accelerated. - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. - Added initial text support, for instance rendering and high precision measurement. - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. Some text examples: (rendering) <Mail Attachment.png> (measurement) <Mail Attachment.png> Cheers, Alex

-- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Doru does it mean that right now with Sparta we do not have any fallback? Stef Le 21/10/16 à 15:41, Tudor Girba a écrit :

Hi Clement,

Thanks for raising this question.

In short, Sparta is inspired from Athens and it has a similar structure. So, there is an in-image interface of the canvas, and there is a concrete implementation through the plugin (based on Moz2D). To target a completely in-image rendering, it is certainly possible to implement a BitBlt backend of the Sparta canvas. To implement this part, we would need help.

The goal is indeed to have only one canvas in the default Pharo distribution: Sparta. However, this will not happen suddenly. Ideally, when Pharo 6 will be released, there will be a beta version of Sparta + Bloc + some tools that will be loadable externally. Then my guess is that it will still take another year until we get the full development environment working on top of Sparta. So, it is to be expected that this transition will take at least 1.5 years during which time Athens will still provide the option of running on top of BitBlt.

Does this answer the concern?

But, now my question: Would it not be possible to get the VM to not open a window when in headless mode?

Cheers, Doru

...

On Oct 21, 2016, at 2:23 PM, Clément Bera <bera.clement@gmail.com> wrote:

On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.syrel@gmail.com> wrote: Hi Stéphane

Indeed, build is broken :) Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me)

You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically.

As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more.

It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily.

Let's take Pharo6 for mac. It is shipped with the following libs: Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb

Moz2D is self contained and does not require any additional libs. Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb).

As you can see we get almost the same numbers :)

Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE.

Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint.

Which leads the first question...

...

...

Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger.

...

...

Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ?

Cheers Alex

On Oct 19, 2016 22:16, "stepharo" <stepharo@free.fr> wrote: Hi Aliaksei

It looks gorgeous. I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM.

Then I have a question:

- do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us.

I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage.

Stef

Le 19/10/16 à 18:06, Aliaksei Syrel a écrit :

...

Hi

I am happy to announce the release of Sparta v1.1 for Pharo 6. https://github.com/syrel/Sparta/tree/v1.1

It can be bootstrapped with the following script:

Metacello new

baseline: 'Sparta' ;

repository: 'github://syrel/sparta:v1.1/src' ;

load: #file:core Examples are on class side of: MozExamples, MozTextExamples (for linux users: if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) Release of v1.1 is focused on hardware acceleration, windows support and text rendering. What is new: - Default backends on all platforms changed from software to hardware accelerated. - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. - Added initial text support, for instance rendering and high precision measurement. - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. Some text examples: (rendering) <Mail Attachment.png> (measurement) <Mail Attachment.png> Cheers, Alex -- www.tudorgirba.com www.feenk.com

"There are no old things, there are only old ways of looking at them."

2016-10-20 1:15 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>:

Good job Alex! Yes, the development version of Bloc is already based on Sparta. The stable version 0.10.1 is the last version with Athens support.

What the repository for Bloc?

Denis Kudriashov wrote

I look at code and it seems you implemented another one new text model? Why you not use TxText?

Argh. I know it's bad form to complain about gifts, but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/ ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Norbert, It is also called evolution ... with each step forward new possibilities are revealed and often the old (current) way of doing things needs to change to better leverage these new possibilities ... and evolution is required[4]. Change is also painful and keeping up with an ever-changing system takes a lot of individual effort. If you don't want to deal with change, then pick a Pharo version and stick with it ... Pharo3.0 is still functional and I for one make sure that all new versions of Metacello work on older versions of Squeak, Pharo and GemStone[1] --- but you don't have to use the newer version of Metacello if you don't want to:). I use Pharo3.0 on a daily basis for tODE -- I decided that I wanted to spend my time evolving and changing tODE itself rather than spend a portion of every year porting to a newer version of Pharo. Fortunately I don't NEED the fancy new widgets in Pharo3.0 to make progress with tODE. Metacello is not the only project to ensure that it continues to function on older versions of Pharo. Seaside[2], Voyage[3] and I'm sure others make an effort to continue to function on older versions of Pharo --- the technology exists for maintaining compatibility with older versions of Pharo for those projects that aren't making the effort now. If you choose to leverage the benefits of the newer versions of Pharo, then you must accept the cost, but you can pace yourself if the rate of change becomes too much. Dale [1] https://travis-ci.org/dalehenrich/metacello-work/builds/168940183 [2] https://travis-ci.org/SeasideSt/Seaside/builds/160382244 [3] https://travis-ci.org/pharo-nosql/voyage/builds/167012791 [4] https://en.wikipedia.org/wiki/Software_evolution On 10/21/16 12:10 AM, Norbert Hartl wrote:

Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:

...

Denis Kudriashov wrote

...

I look at code and it seems you implemented another one new text model? Why you not use TxText?

Argh. I know it's bad form to complain about gifts, but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/

It has a name and we should fight it:

https://en.m.wikipedia.org/wiki/Not_invented_here

Norbert

...

----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://Nabble.com>.

Hi Norbert, It is not ignored at all. Cheers, Doru

On Oct 21, 2016, at 3:50 PM, Norbert Hartl <norbert@hartl.name> wrote:

Dale,

I was not arguing against evolution. I was refering to the fact that work of others is mostly ignored just to come up with a potential weaker solution.

Norbert

...

Am 21.10.2016 um 15:34 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:

Norbert,

It is also called evolution ... with each step forward new possibilities are revealed and often the old (current) way of doing things needs to change to better leverage these new possibilities ... and evolution is required[4]. Change is also painful and keeping up with an ever-changing system takes a lot of individual effort.

If you don't want to deal with change, then pick a Pharo version and stick with it ... Pharo3.0 is still functional and I for one make sure that all new versions of Metacello work on older versions of Squeak, Pharo and GemStone[1] --- but you don't have to use the newer version of Metacello if you don't want to:).

I use Pharo3.0 on a daily basis for tODE -- I decided that I wanted to spend my time evolving and changing tODE itself rather than spend a portion of every year porting to a newer version of Pharo. Fortunately I don't NEED the fancy new widgets in Pharo3.0 to make progress with tODE. Metacello is not the only project to ensure that it continues to function on older versions of Pharo. Seaside[2], Voyage[3] and I'm sure others make an effort to continue to function on older versions of Pharo --- the technology exists for maintaining compatibility with older versions of Pharo for those projects that aren't making the effort now. If you choose to leverage the benefits of the newer versions of Pharo, then you must accept the cost, but you can pace yourself if the rate of change becomes too much.

Dale [1] https://travis-ci.org/dalehenrich/metacello-work/builds/168940183

[2] https://travis-ci.org/SeasideSt/Seaside/builds/160382244

[3] https://travis-ci.org/pharo-nosql/voyage/builds/167012791 [4] https://en.wikipedia.org/wiki/Software_evolution

On 10/21/16 12:10 AM, Norbert Hartl wrote:

...

Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <sean@clipperadams.com>:

...

Denis Kudriashov wrote

...

I look at code and it seems you implemented another one new text model? Why you not use TxText?

Argh. I know it's bad form to complain about gifts, but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/

It has a name and we should fight it:

https://en.m.wikipedia.org/wiki/Not_invented_here

Norbert

...

----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

I think that the concept of a LTS will become useful at one point. Like, every 3 versions or so. On Fri, Oct 21, 2016 at 4:12 PM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:

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

Dale

On 10/21/16 6:50 AM, Norbert Hartl wrote:

Dale,

I was not arguing against evolution. I was refering to the fact that work of others is mostly ignored just to come up with a potential weaker solution.

Norbert

Am 21.10.2016 um 15:34 schrieb Dale Henrichs < dale.henrichs@gemtalksystems.com>:

Norbert,

It is also called evolution ... with each step forward new possibilities are revealed and often the old (current) way of doing things needs to change to better leverage these new possibilities ... and evolution is required[4].

Change is also painful and keeping up with an ever-changing system takes a lot of individual effort.

If you don't want to deal with change, then pick a Pharo version and stick with it ... Pharo3.0 is still functional and I for one make sure that all new versions of Metacello work on older versions of Squeak, Pharo and GemStone[1] --- but you don't have to use the newer version of Metacello if you don't want to:).

I use Pharo3.0 on a daily basis for tODE -- I decided that I wanted to spend my time evolving and changing tODE itself rather than spend a portion of every year porting to a newer version of Pharo. Fortunately I don't NEED the fancy new widgets in Pharo3.0 to make progress with tODE.

Metacello is not the only project to ensure that it continues to function on older versions of Pharo. Seaside[2], Voyage[3] and I'm sure others make an effort to continue to function on older versions of Pharo --- the technology exists for maintaining compatibility with older versions of Pharo for those projects that aren't making the effort now. If you choose to leverage the benefits of the newer versions of Pharo, then you must accept the cost, but you can pace yourself if the rate of change becomes too much.

Dale

[1] https://travis-ci.org/dalehenrich/metacello-work/builds/168940183

[2] https://travis-ci.org/SeasideSt/Seaside/builds/160382244

[3] https://travis-ci.org/pharo-nosql/voyage/builds/167012791

[4] https://en.wikipedia.org/wiki/Software_evolution

On 10/21/16 12:10 AM, Norbert Hartl wrote:

Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <sean@clipperadams.com>:

Denis Kudriashov wrote

I look at code and it seems you implemented another one new text model?

Why

you not use TxText?

Argh. I know it's bad form to complain about gifts, but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/

It has a name and we should fight it:

https://en.m.wikipedia.org/wiki/Not_invented_here

Norbert

----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN- Sparta-v1-1-tp4919394p4919570.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.

On 21 Oct 2016, at 16:30, Norbert Hartl <norbert@hartl.name> wrote:

Dale,

...

Am 21.10.2016 um 16:12 schrieb Dale Henrichs <dale.henrichs@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/> now you are going to complain also for the dark theme? come on! ;)

Norbert

...

Dale

On 10/21/16 6:50 AM, Norbert Hartl wrote:

...

Dale,

I was not arguing against evolution. I was refering to the fact that work of others is mostly ignored just to come up with a potential weaker solution.

Norbert

...

Am 21.10.2016 um 15:34 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>>:

Norbert,

It is also called evolution ... with each step forward new possibilities are revealed and often the old (current) way of doing things needs to change to better leverage these new possibilities ... and evolution is required[4]. Change is also painful and keeping up with an ever-changing system takes a lot of individual effort.

If you don't want to deal with change, then pick a Pharo version and stick with it ... Pharo3.0 is still functional and I for one make sure that all new versions of Metacello work on older versions of Squeak, Pharo and GemStone[1] --- but you don't have to use the newer version of Metacello if you don't want to:).

I use Pharo3.0 on a daily basis for tODE -- I decided that I wanted to spend my time evolving and changing tODE itself rather than spend a portion of every year porting to a newer version of Pharo. Fortunately I don't NEED the fancy new widgets in Pharo3.0 to make progress with tODE. Metacello is not the only project to ensure that it continues to function on older versions of Pharo. Seaside[2], Voyage[3] and I'm sure others make an effort to continue to function on older versions of Pharo --- the technology exists for maintaining compatibility with older versions of Pharo for those projects that aren't making the effort now. If you choose to leverage the benefits of the newer versions of Pharo, then you must accept the cost, but you can pace yourself if the rate of change becomes too much.

Dale [1] https://travis-ci.org/dalehenrich/metacello-work/builds/168940183 <https://travis-ci.org/dalehenrich/metacello-work/builds/168940183> [2] https://travis-ci.org/SeasideSt/Seaside/builds/160382244 <https://travis-ci.org/SeasideSt/Seaside/builds/160382244> [3] https://travis-ci.org/pharo-nosql/voyage/builds/167012791 <https://travis-ci.org/pharo-nosql/voyage/builds/167012791> [4] https://en.wikipedia.org/wiki/Software_evolution <https://en.wikipedia.org/wiki/Software_evolution>

On 10/21/16 12:10 AM, Norbert Hartl wrote:

...

Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:

...

Denis Kudriashov wrote

...

I look at code and it seems you implemented another one new text model? Why you not use TxText?

Argh. I know it's bad form to complain about gifts, but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/

It has a name and we should fight it:

https://en.m.wikipedia.org/wiki/Not_invented_here <https://en.m.wikipedia.org/wiki/Not_invented_here>

Norbert

...

----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html <http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.

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@mac.com> wrote:

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

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 On Sat, Oct 22, 2016 at 10:06 AM phil@highoctane.be <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@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@mac.com> wrote:

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

it depends, the power that pharo offers is just massive on this department. For example you say you dont like the idea of a global startup script, thats fine because you can have startup scripts per image, they go to the same folder as your image. If you really have a super complex setup it would make sense to make a git repo with just your make file and startup scripts. The makefile can be parameterized with command line arguments to perform diffirent installs then its a just a matter of copying the correct startup script to the folder with the appropriate image which of course is something the makefile can handle too. Mariano has a great post on the subject of startup scripts which what I used to make my own https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s... By interactive mode again , I assume here you mean the GUI. Again it depends what you want to do, a pharo install comes with 2 executables pharo-ui which is the well known gui front and pharo which has no gui. In both cases you have debug abilities though I presume it would be easier to do this from inside a GUI. pharo and pharo-ui has an eval argument that allow you to execute any kind of code and there is also a save argument to save the image with your new code. If you prefer GUI then you dont even need to pass metacello arguments, just make a configuration installing all your dependencies and put it in the STHUB metarepo corresponing to the version of pharo you use, it will be available from Package browser and you will be able to install all your dependencies with a single click every time you download a new install of pharo. Or just install a tool that you can use from playground to install the dependencies with a simple message. Or make a spec GUI or morphic GUI and do all that from the comfort of your mouse. OR....... the options are just endless. Another thing to remember here is that a baseline does not have to have one setup, you can have multiple setups installing things under diffirent conditions. Baseline also are aware of smalltalk implementation (squeak/ pharo) and pharo versions. That means diffirent installs under diffirent conditions and some deep fine tuning. Baseline also allow for actions before the install after the install, so even if you want to do some clean up you can do this also from the comfort of baseline. Lastly but not least metacello is fully aware of git branches that gives you even more possibilities since a branch even in the same repo can be a completely new repo that gives you even more crazy options , since you can have diffirent Baseline under diffirent branch and of course the branch can contain its own code and assets (images, sounds , binary files, anything). It really comes down to the way you like to work, pharo can do it, you choose how and what. On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <kilon.alios@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 phil@highoctane.be <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@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@mac.com> wrote:

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

Didn't Esteban fixed metarepo ? I think I remember him saying that he did. Don't know how heavy and complex your setup is but if I was in a situation where the building process became to complex with several builds at the same time , I think as Phil said a CI would have been more handy. Its what we use for a vast array of custom images. Obviously you could make your own command line tool with Pharo. An image dedicated to building your own images , you alias the Pharo executable passed the image name to any name that make it look as if it is a bash command or bash utility. For example Pharo-build gitfiletree ./filetree -replace -stable -runTests On Sat, 22 Oct 2016 at 12:34, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Kilon,

2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <kilon.alios@gmail.com>:

it depends, the power that pharo offers is just massive on this department.

For example you say you dont like the idea of a global startup script, thats fine because you can have startup scripts per image, they go to the same folder as your image. If you really have a super complex setup it would make sense to make a git repo with just your make file and startup scripts. The makefile can be parameterized with command line arguments to perform diffirent installs then its a just a matter of copying the correct startup script to the folder with the appropriate image which of course is something the makefile can handle too.

Good point: the Makefile has to copy the startup script inside the image directory, if we keep that convention of building the new image inside a dedicated directory to be able to clean by rm -r that directory.

Mariano has a great post on the subject of startup scripts which what I used to make my own

https://marianopeck.wordpress.com/2012/05/12/startuploader-running-startup-s...

By interactive mode again , I assume here you mean the GUI. Again it depends what you want to do, a pharo install comes with 2 executables pharo-ui which is the well known gui front and pharo which has no gui. In both cases you have debug abilities though I presume it would be easier to do this from inside a GUI. pharo and pharo-ui has an eval argument that allow you to execute any kind of code and there is also a save argument to save the image with your new code.

Yes. I've been using eval in Makefiles for a few years now. I even prefer an eval Metacello new baseline: ... to the command line configuration loader, because I can use the standard Smalltalk syntax with eval (and Metacello) whereas I need to read the doc for the configuration command line handler.

I even have a 'deployment' version for external partners, where the Makefile detect it is started from an archive extracted from git and not the original git repo, and switches to filetree (and loading different packages) to build the image.

If you prefer GUI then you dont even need to pass metacello arguments, just make a configuration installing all your dependencies and put it in the STHUB metarepo corresponing to the version of pharo you use, it will be available from Package browser and you will be able to install all your dependencies with a single click every time you download a new install of pharo. Or just install a tool that you can use from playground to install the dependencies with a simple message. Or make a spec GUI or morphic GUI and do all that from the comfort of your mouse. OR.......

the options are just endless.

Yes. Oh well, in fact the metarepo thing doesnt work well with Pharo5 and Pharo6, as one of the user of the GitFileTree configuration discovered a week or two ago. If you are using Pharo5, a configuration in the Pharo6 metarepo will override the one in the Pharo5 metarepo.

Another thing to remember here is that a baseline does not have to have one setup, you can have multiple setups installing things under diffirent conditions. Baseline also are aware of smalltalk implementation (squeak/ pharo) and pharo versions. That means diffirent installs under diffirent conditions and some deep fine tuning. Baseline also allow for actions before the install after the install, so even if you want to do some clean up you can do this also from the comfort of baseline.

Lastly but not least metacello is fully aware of git branches that gives you even more possibilities since a branch even in the same repo can be a completely new repo that gives you even more crazy options , since you can have diffirent Baseline under diffirent branch and of course the branch can contain its own code and assets (images, sounds , binary files, anything).

Yes,

Thierry

It really comes down to the way you like to work, pharo can do it, you choose how and what.

On Sat, Oct 22, 2016 at 11:37 AM Thierry Goubier < thierry.goubier@gmail.com> wrote:

Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <kilon.alios@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 phil@highoctane.be <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@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@mac.com> wrote:

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

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@gmail.com> wrote:

On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

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

fixed in what sense?

Esteban

On 22 Oct 2016, at 12:41, Dimitris Chloupis <kilon.alios@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@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@gmail.com <mailto:estebanlm@gmail.com>> wrote:

...

On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios@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

On 22 Oct 2016, at 16:24, Norbert Hartl <norbert@hartl.name> wrote:

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

yes, I also suggested them to follow this direction… Esteban

Am 22.10.2016 um 13:41 schrieb Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

...

...

On 22 Oct 2016, at 12:41, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@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@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@gmail.com <mailto:estebanlm@gmail.com>> wrote:

...

On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios@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

Le 22/10/16 à 17:21, phil@highoctane.be a écrit :

The st command line handler is pretty much giving the same.

I used scale, it works nicely indeed.

But I want Coral reborn.

me too. Damien is working on a new command line parser.

Phil

On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@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>

On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <kilon.alios@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@gmail.com <mailto:estebanlm@gmail.com>> wrote:

...

On 22 Oct 2016, at 12:00, Dimitris Chloupis <kilon.alios@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

Note that all the work on making sure that the image is not writing files when it is on read only mode is part of making coral installable on unix. Now if people wants coral they can join the effort. stef

In the bug tracker https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver https://pharo.fogbugz.com/f/cases/18649/ we got a lot of problems because the monkey and our build process were using the api we wanted to change. So now we are making the changes one by one. I hope to work on it during the next sprint. Stef Le 23/10/16 à 11:31, phil@highoctane.be a écrit :

Where?

On Sun, Oct 23, 2016 at 10:42 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

Note that all the work on making sure that the image is not writing files when it is on read only mode is part of making coral installable on unix. Now if people wants coral they can join the effort.

stef

On 22 Oct 2016, at 10:56, Dimitris Chloupis <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 :)

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@gemtalksystems.com> wrote:

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

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

Ah ok I see you mean you want a cleaner to do this, I agree, it can be improved. On Sat, Oct 22, 2016 at 5:51 PM Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:

On 10/22/16 7:03 AM, Dimitris Chloupis wrote:

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 < dale.henrichs@gemtalksystems.com> wrote:

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

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

I'm wrong ... I hadn't followed the whole chain. Although as I've mentioned in another post, the Catalog is wired to ConfigurationOf and is Pharo-specific ... A common "project load spec" could be plugged into the CatalogBrowser framework and provide ConfigurationOf and BaselineOf support ... Dale On 10/22/16 8:31 AM, phil@highoctane.be wrote:

CatalogProvider projectNamed: 'QuickAccess'

is doing that already.

Or I am mistaken? Phil

On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:

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

...

...

On 22 Oct 2016, at 10:56, Dimitris Chloupis <kilon.alios@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

Esteban, This is why I'm bringing up the idea of MetacelloProjectLoadSpec now ... my current thoughts are that MetacelloProjectLoadSpec would look like a cross between the CatalogProject, TDProjectEntry, and SCIMetacelloLoadSpec. Here are some initial examples for a ConfigurationOf and and a BaselineOf project: MetacelloProjectLoadSpec { #name : 'A4BP', #metacello : { #configuration : 'A4BP', #repository : 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main', #version : #stable, #loads : [ 'Core' ], #locked : false }, #projectUrl : 'http://a4bp.com/', #description : 'A4BP (Assessment for Business Process).\rSee more here: http://a4bp.com/', #keywords : [ 'development', 'bpmn' ], #platforms : [ #pharo ] } MetacelloProjectLoadSpec { #name : 'Tugrik', #metacello : { #baseline : 'Tugrik', #repository : 'gitfiletree://github.com/dalehenrich/Tugrik:master/repository', #onWarningLog : true, #loads : [ 'default' ], #locked : true }, #projectUrl : 'https://github.com/dalehenrich/Tugrik#tugrik', #description : 'Voyage client for GemStone', #keywords : [ 'persistence', 'voyage' ], #properties : { #tode_InstallSscript : 'project clone --https --local Tugrik', #tode_PostInstallScript : 'mount @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik' }, #platforms : [ #pharo, #gemstone ] } If we assume that the .ston files will be hosted directly in the github project then something like the following would be possible: 'https://raw.githubusercontent.com/GsDevKit/GsDevKit_home/gh-pages/Tugrik.sto...' asMetacelloProjectLoadSpec load or: 'https://raw.githubusercontent.com/GsDevKit/GsDevKit_home/gh-pages/Tugrik.sto...' metacelloLoad for sharing customized local project load specs : (FileLocator projectDirectory / 'A4BP.ston') asMetacelloProjectLoadSpec load or: (FileLocator projectDirectory / 'Tugrik.ston') metacelloLoad The above assumes that you may only want to load a project ... but if you've customized your load spec (i.e., have a local git clone that you always want used) you may just want to lock the project in your image without loading. Then you'd do something like the following: (FileLocator projectDirectory / 'A4BP.ston') asMetacelloProjectLoadSpec lock Of course a tool similar to the CatalogBrowser for local projects could be written to manage the contents of the `FileLocator projectDirectory` ... this is what the tODE project list does: project list Presumably the catalog browser could be easily converted to use MetacelloProjectLoadSpecs ... the issue of how to register a project load spec for a baseline still remains, but Pharo could accept pull requests for a github project where the user simply submits a .ston file for their project - a cross between https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages and https://github.com/dalehenrich/nosql-database.org... ... just some thoughts .... Dale On 10/22/16 9:41 AM, Esteban Lorenzano wrote:

Catalog is a “temporary solution” for a problem that is already 2 years around… is not what I would like, and certainly is far from perfect. One of this days I will come with a solution that can allow baselines, for example…

Esteban

...

On 22 Oct 2016, at 18:37, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:

I'm wrong ... I hadn't followed the whole chain. Although as I've mentioned in another post, the Catalog is wired to ConfigurationOf and is Pharo-specific ... A common "project load spec" could be plugged into the CatalogBrowser framework and provide ConfigurationOf and BaselineOf support ...

Dale

On 10/22/16 8:31 AM, phil@highoctane.be wrote:

...

CatalogProvider projectNamed: 'QuickAccess'

is doing that already.

Or I am mistaken? Phil

On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:

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

...

...

On 22 Oct 2016, at 10:56, Dimitris Chloupis <kilon.alios@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

Yeah it takes long because of pharo compilation, this is not different than python and ruby. Though python has pyc files which are compiled py files , unfortunately we dont have something similar out of the box. This is where the monolithic nature of the image file bite us back. I dont know if gems distributes the binary version of the source file, if they do , then yes gem has there the advantage of speed, if they dont, its the same situation. Fuel does fit the job well in that department. Fuel files should be able to speed up your build process so massively that only your internet speed will be the bottleneck. Of course you will have to do the the export of pharo live code and date as fuel files but that is something your CI process can handle in the background. This means by the time you issue a rebuild or its issued auto magically because of webhook to a git commit, fuel files will be readily available and you will be able to reduce build time down to a minimal. Fuel files give also the advantage of live data which will come handy for reproducing errors and fine tuning unit tests. On Sat, Oct 22, 2016 at 12:15 PM phil@highoctane.be <phil@highoctane.be> wrote:

I am having my (local) Jenkins CI do that for me.

There are several projects:

1/ P1: download fresh pharo 2/ P2: build "base worker" (an image with all prerequisites to dev) (takes a while: Seaside, Magritte, ....) 3/ P3: take recent commits from Git project and build an image based on the base worker one.

2 is taking a long time and if I did 2 and 3 it would be reallly long to ensure the final image is done.

Now, 3 takes only a few seconds, which allows to iterate fast (and as I keep a few artifacts back, save my ass at times)

Phil

On Sat, Oct 22, 2016 at 9:52 AM, Dimitris Chloupis <kilon.alios@gmail.com> 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

On Sat, Oct 22, 2016 at 10:06 AM phil@highoctane.be <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@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@mac.com> wrote:

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

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.m... 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@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/pro...

On Sat, Oct 22, 2016 at 10:06 AM phil@highoctane.be <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@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@mac.com> wrote:

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

On 10/22/16 12:04 AM, phil@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-ge... [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

I wholeheartedly agree that Smalltalk is not desirable as a specification language ... I included the Smalltalk expression as an example of the type of information I am using in tODE (when I make another pass through tODE I will switch from smalltalk to STON) ... So moving forward I think a STON-based project load spec is preferable. See my reply to Esteban for an example of the types of information that I imagine would be included in a project load spec. Looking closely at the below, I think including the license is a good idea... Now it seems to me that both`compose install` and `bower install` don't do much more that automatic `git clone` ... is that right? I have toyed with the idea that a BaselineOf could be represented as a STON file (or XML file), but right now I tend to think that there isn't much difference in the readability/simplicity between Smalltalk and STON ... STON might be a bit more sparse, but without a tool for writing STON files (syntax validation and automatic saving ... to disk????) so I will stick with Smalltalk for the foreseeable future:) Dale On 10/22/16 8:29 AM, phil@highoctane.be wrote:

Looks like we are on the same wavelength but...

Look how this is done in PHP with Composer:

- simple Json file - declares repositories - requires and requiresdev - uses semver versions

so, 'composer install' will fetch and install deps.

composer update will update deps.

composer.json { "name": "zendframework/skeleton-application", "description": "Skeleton Application for ZF2", "license": "BSD-3-Clause", "keywords": [ "framework", "zf2" ], "homepage": "http://framework.zend.com/", "repositories": [{ "type": "vcs", "url": "https://github.com/RobLoach/firephp-core" }], "require": { "php": ">=5.5", "zendframework/zendframework": "~2.5", "zendframework/zftool": "dev-master", "firephp/firephp-core": "dev-master", "videlalvaro/php-amqplib": "^2.5" }, "require-dev": { "snapshotpl/zf-snap-event-debugger": "1.*", "zendframework/zend-developer-tools": "dev-master", "phpunit/phpunit": "4.8.*" } }

In the JS Ecosystem, eg. bower.json

{ "name": "adsdaq", "homepage": "https://github.com/anais-it/adsdaq", "authors": [ "Philippe Back <phil@highoctane.be <mailto:phil@highoctane.be>>" ], "description": "adsdaq-frontend", "main": "", "moduleType": [], "license": "Adlogix", "private": true, "ignore": [ "**/.*", "node_modules", "bower_components", "vendor/bower_components", "test", "tests" ], "dependencies": { "angular": "~1.4.7", "restangular": "~1.5.1", "lodash": "~3.10.1", "angular-route": "~1.4.7", "angular-spinner": "~0.8.0", "angular-bootstrap": "~0.14.3", "typeahead.js": "~0.11.1" } }

So, basic module names in deps and semver.

The st code you show is more cryptic.

Is there a sweet spot ?

Ston is a great format and is Json compatible if we are careful (meaning I can actually use vim and json syntax checkers plugins)

St code is indeed more powerful but it leaves a lot of people in the dust with configurations.

What do you think?

Phil

On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:

On 10/22/16 12:04 AM, phil@highoctane.be <mailto:phil@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 <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 <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-ge... <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 <https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client> [3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston <https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston> [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci <https://github.com/hpi-swa/smalltalkCI#smalltalkci>--- [5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston <https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston>

Pointer? Sent from the road

On Oct 22, 2016, at 11:39, stepharo <stepharo@free.fr> wrote:

This is what christophe is doing in cargo.

Stef

...

Le 22/10/16 à 17:29, phil@highoctane.be a écrit : Looks like we are on the same wavelength but...

Look how this is done in PHP with Composer:

- simple Json file - declares repositories - requires and requiresdev - uses semver versions

so, 'composer install' will fetch and install deps.

composer update will update deps.

composer.json { "name": "zendframework/skeleton-application", "description": "Skeleton Application for ZF2", "license": "BSD-3-Clause", "keywords": [ "framework", "zf2" ], "homepage": "http://framework.zend.com/", "repositories": [{ "type": "vcs", "url": "https://github.com/RobLoach/firephp-core" }], "require": { "php": ">=5.5", "zendframework/zendframework": "~2.5", "zendframework/zftool": "dev-master", "firephp/firephp-core": "dev-master", "videlalvaro/php-amqplib": "^2.5" }, "require-dev": { "snapshotpl/zf-snap-event-debugger": "1.*", "zendframework/zend-developer-tools": "dev-master", "phpunit/phpunit": "4.8.*" } }

In the JS Ecosystem, eg. bower.json

{ "name": "adsdaq", "homepage": "https://github.com/anais-it/adsdaq", "authors": [ "Philippe Back <phil@highoctane.be>" ], "description": "adsdaq-frontend", "main": "", "moduleType": [], "license": "Adlogix", "private": true, "ignore": [ "**/.*", "node_modules", "bower_components", "vendor/bower_components", "test", "tests" ], "dependencies": { "angular": "~1.4.7", "restangular": "~1.5.1", "lodash": "~3.10.1", "angular-route": "~1.4.7", "angular-spinner": "~0.8.0", "angular-bootstrap": "~0.14.3", "typeahead.js": "~0.11.1" } }

So, basic module names in deps and semver.

The st code you show is more cryptic.

Is there a sweet spot ?

Ston is a great format and is Json compatible if we are careful (meaning I can actually use vim and json syntax checkers plugins)

St code is indeed more powerful but it leaves a lot of people in the dust with configurations.

What do you think?

Phil

...

On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:

On 10/22/16 12:04 AM, phil@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-ge... [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/21/2016 07:30 AM, Norbert Hartl wrote:

Dale,

...

Am 21.10.2016 um 16:12 schrieb Dale Henrichs <dale.henrichs@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:) 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 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." If you are using filetree based projects then the only way to access them is the new way... 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 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 :) Dale

On 10/22/16 12:08 AM, phil@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

Much appreciated! On 10/22/16 8:30 AM, phil@highoctane.be wrote:

Ok, message received. PRs launching.

On Sat, Oct 22, 2016 at 3:23 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:

On 10/22/16 12:08 AM, phil@highoctane.be <mailto:phil@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

Norbert, On 10/22/16 3:56 AM, Norbert Hartl wrote:

Dale,

...

Am 21.10.2016 um 22:15 schrieb Dale Henrichs <dale.henrichs@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@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/LockCommandRe... [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 Oct 21, 2016, at 4:00 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Denis Kudriashov wrote

...

I look at code and it seems you implemented another one new text model? Why you not use TxText?

Argh. I know it's bad form to complain about gifts,

A bit :).

but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/

I would kindly ask for patience. What is perhaps less clear is that this editor is in the critical path of the GT project and we are committed to deliver an editor that actually works. We are still investigating different paths, both on the low level (like with Rope) and at the higher level (like how to organize the layout). Alex will follow up with a more technical comparison between the current approach and the one from TxText. Doru

----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Hi,

On Oct 21, 2016, at 3:55 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-10-21 15:21 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

...

but at the rate we reinvent the wheel, I often fear that I will be retired from programming before we have a sane text model :/

I would kindly ask for patience. What is perhaps less clear is that this editor is in the critical path of the GT project and we are committed to deliver an editor that actually works. We are still investigating different paths, both on the low level (like with Rope) and at the higher level (like how to organize the layout).

I am not against to any new implementation of existing stuff. It is always interesting how things could be done different and especially if it provides better solution. But I really fear that new text experiments will dramatically delay releaze of Bloc and Sparta and following migration to new UI. And this is real importance for Pharo future, and not possible moldable editor. Text editors are very complex domain. It takes more than year to get working TxText and Twisty. Why not finish Bloc and Sparta with minimal effort on adopting TxText or Twisty to run on them?

I think there is a confusion here. Sparta was just released on all three OSs (a major effort of Alex), Bloc is working and it even has TxText working there on top of Sparta (another major effort of Glenn). As to the importance of a moldable text editor that also scales properly, I disagree with you. We need an infrastructure on top of which we can build the next 5 years of tools. Especially in the context of GT, the goal is not to reproduce the existing tools, but to create completely new ones that are not possible right now, and a scalable & moldable text editor and model is a key component for what we want to do next. That is why we will invest the effort in this part. We might fail in the process, but then again we might succeed. We can only invent a new future if we first dream of it, and then try :). Doru -- www.tudorgirba.com www.feenk.com “Software has no shape. Actually, it has no one shape. It has many."

2016-10-21 16:20 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2016-10-21 16:15 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

...

...

I would kindly ask for patience. What is perhaps less clear is that this editor is in the critical path of the GT project and we are committed to deliver an editor that actually works. We are still investigating different paths, both on the low level (like with Rope) and at the higher level (like how to organize the layout).

I am not against to any new implementation of existing stuff. It is always interesting how things could be done different and especially if it provides better solution. But I really fear that new text experiments will dramatically delay releaze of Bloc and Sparta and following migration to new UI. And this is real importance for Pharo future, and not possible moldable editor. Text editors are very complex domain. It takes more than year to get working TxText and Twisty. Why not finish Bloc and Sparta with minimal effort on adopting TxText or Twisty to run on them?

I think there is a confusion here. Sparta was just released on all three OSs (a major effort of Alex), Bloc is working and it even has TxText working there on top of Sparta (another major effort of Glenn).

If it is done then no complains from me. It is super cool.

Unfortunately I not found TxText integration in dev Bloc. BlText uses new model.

On 21 Oct 2016, at 16:43, Sean P. DeNigris <sean@clipperadams.com> wrote:

Tudor Girba-2 wrote

...

I would kindly ask for patience. What is perhaps less clear is that this editor is in the critical path of the GT project and we are committed to deliver an editor that actually works. We are still investigating different paths, both on the low level (like with Rope) and at the higher level (like how to organize the layout).

I really appreciate your long-term vision. My point/concern is that IMHO the most important thing is to "rachet up" - to alternate frequently between: a) releasing working versions of current best ideas (the many benefits of which include locking in progress, getting feedback from a wide audience, and getting buy-in/allowing users to adapt), and b) using that as a launching point for new experiments

We are still using the same original awful text model that has stymied so many users/projects! Let's focus on and release something useable - anything - to take the pressure off while we invent the future.

To illustrate the general principal, think about all the pain we have experienced because the last (promised) crucial step of cleaning and refactoring Squeak was not accomplished before beginning the next experiment! My question is: where is the sweet spot between the zero vision (but universal accessibility for actual work) of Java/C++, and infinite vision (at the extreme cost of immediately-usable artifacts) of Squeak/VPRI[1]?

amen. think is: is like the third time we start once again to build the next huge steps. and frankly, while waiting for that we have a text model that sucks and a cool text model unfinished and usable and a text editor that cannot handle complicated stuff because it is not ready, etc. etc. it feels bad. it tastes bad. and is not good at all. Esteban

1. This is not a criticism; they are just in a different business (cathedral building)

----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919647.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil. 1. Support of large files ( >> 100mb) 2. Support of large pieces of text located in memory 3. Allow developers to embed visual elements (pictures, interactive elements, custom elements) 4. Support of more sophisticated layouts rather than line-based. For example columns. 5. Line breaking 6. Text wrapping 7. Hyphens 8. Should be fast Tests show that TxText model is very nice for basic cases, works well for "normal" use. However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales. Cheers, Alex On 19 October 2016 at 23:51, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>:

...

- Added initial text support, for instance rendering and high precision measurement.

I look at code and it seems you implemented another one new text model? Why you not use TxText?

Hi Stef, We are not throwing away anything. The goal is not to produce a new model, the goal is to find one that matches the requirements. We already learnt a lot from TxText, but it has limitations in how to deal with things that are not only text. We have no intention of producing an unfinished text model :). This is a critical component for us. Please let us work for a couple of months and we get back with news. Cheers, Doru

On Oct 22, 2016, at 8:31 PM, stepharo <stepharo@free.fr> wrote:

Hi aliaksei

I thought that you were just changing the internal representation of txText to use Ropes and building on top of / improving txText I did not think that you were throwing away all the work igor did. Because he spent a lot of time

designing the text model and making it is scalable - and now I read that apparently it was not scalable enough. I'm wondering what will happen if suddenly you disappear: we will get two unfinished textmodel and use an old one? When do you think that you will have a working usable by other for real text model? Stef

Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :

...

As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil.

• Support of large files ( >> 100mb) • Support of large pieces of text located in memory • Allow developers to embed visual elements (pictures, interactive elements, custom elements) • Support of more sophisticated layouts rather than line-based. For example columns. • Line breaking • Text wrapping • Hyphens • Should be fast Tests show that TxText model is very nice for basic cases, works well for "normal" use. However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales.

Cheers, Alex

On 19 October 2016 at 23:51, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>: - Added initial text support, for instance rendering and high precision measurement.

I look at code and it seems you implemented another one new text model? Why you not use TxText?

-- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

Is there no way Igor can finish this up? Phil Le 23 oct. 2016 12:19, "stepharo" <stepharo@free.fr> a écrit :

Hi Stef,

...

We are not throwing away anything. The goal is not to produce a new model, the goal is to find one that matches the requirements.

Don't play with words.

We already learnt a lot from TxText, but it has limitations in how to deal

...

with things that are not only text.

I can imagine.

...

We have no intention of producing an unfinished text model :).

Me neither with igor and txText yet life decided otherwise. You see I spent at 10 months of salary on txText.

...

This is a critical component for us. Please let us work for a couple of months and we get back with news.

Cheers, Doru

On Oct 22, 2016, at 8:31 PM, stepharo <stepharo@free.fr> wrote:

...

Hi aliaksei

I thought that you were just changing the internal representation of txText to use Ropes and building on top of / improving txText I did not think that you were throwing away all the work igor did. Because he spent a lot of time

designing the text model and making it is scalable - and now I read that apparently it was not scalable enough. I'm wondering what will happen if suddenly you disappear: we will get two unfinished textmodel and use an old one? When do you think that you will have a working usable by other for real text model? Stef

Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :

...

As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil.

• Support of large files ( >> 100mb) • Support of large pieces of text located in memory • Allow developers to embed visual elements (pictures, interactive elements, custom elements) • Support of more sophisticated layouts rather than line-based. For example columns. • Line breaking • Text wrapping • Hyphens • Should be fast Tests show that TxText model is very nice for basic cases, works well for "normal" use. However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales.

Cheers, Alex

On 19 October 2016 at 23:51, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>: - Added initial text support, for instance rendering and high precision measurement.

I look at code and it seems you implemented another one new text model? Why you not use TxText?

--

www.tudorgirba.com www.feenk.com

"Some battles are better lost than fought."

Hi,

On Oct 23, 2016, at 12:18 PM, stepharo <stepharo@free.fr> wrote:

...

Hi Stef,

We are not throwing away anything. The goal is not to produce a new model, the goal is to find one that matches the requirements. Don't play with words. We already learnt a lot from TxText, but it has limitations in how to deal with things that are not only text. I can imagine. We have no intention of producing an unfinished text model :). Me neither with igor and txText yet life decided otherwise. You see I spent at 10 months of salary on txText. This is a critical component for us. Please let us work for a couple of months and we get back with news.

I am really not playing with words :). We really have zero desire in working on the text editor. Just like we had zero desire in working on Sparta and Bloc. We are doing it because we need a sane infrastructure. We have halted the work on user interface of GT for more than 1 year just because it did not make engineering and economic sense to invest on the current infrastructure. We need an infrastructure to support at least the next 5-10 years of development, and we are decided to deliver on it. The investment in TxText is not at all wasted, it allowed us to bootstrap Bloc and to learn. We might end up with reusing parts of it, but the thing is that now we have new opportunities that come with Sparta. For example, all text measurements are super accurate and are available in image. This means that we can address text rendering in two ways: 1. treat text as one entity and embed graphics inside as elements in the text model. This is where TxText is. However, TxText does not have the support for non-text elements (at least not now). Furthermore, this approach makes floating images inside the text (images that allow text to wrap around) to not be really working. 2. split the text in different sections and lay it out together with other graphical elements using the layout engine from Bloc. Option 2 was not really an option until now because we did not have the performance and accuracy. Now it is an option and we want to investigate this as well before committing to a model. Cheers, Doru

...

Cheers, Doru

...

On Oct 22, 2016, at 8:31 PM, stepharo <stepharo@free.fr> wrote:

Hi aliaksei

I thought that you were just changing the internal representation of txText to use Ropes and building on top of / improving txText I did not think that you were throwing away all the work igor did. Because he spent a lot of time

designing the text model and making it is scalable - and now I read that apparently it was not scalable enough. I'm wondering what will happen if suddenly you disappear: we will get two unfinished textmodel and use an old one? When do you think that you will have a working usable by other for real text model? Stef

Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :

...

As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil.

• Support of large files ( >> 100mb) • Support of large pieces of text located in memory • Allow developers to embed visual elements (pictures, interactive elements, custom elements) • Support of more sophisticated layouts rather than line-based. For example columns. • Line breaking • Text wrapping • Hyphens • Should be fast Tests show that TxText model is very nice for basic cases, works well for "normal" use. However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales.

Cheers, Alex

On 19 October 2016 at 23:51, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com>: - Added initial text support, for instance rendering and high precision measurement.

I look at code and it seems you implemented another one new text model? Why you not use TxText?

-- www.tudorgirba.com www.feenk.com

"Some battles are better lost than fought."

-- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."

Denis, Sierra seems to have some issues. A couple weeks ago one of our users ran into a problem with Pharo3.0 and Sierra --- Esteban jumped on that pretty quickly, but then we discovered some additional issues with GemStone and Sierra -- in our case it was a known bug in Sierra and we are waiting for a fix --- the upshot is that GemStone does not properly run on Sierra until that particular bug is fixed or we release a new version of GemStone with patches ... Upshot is that Sierra is apparently not quite ready for prime time ... Dale On 10/21/2016 03:44 PM, Denis Kudriashov wrote:

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel@gmail.com <mailto:alex.syrel@gmail.com>>:

It can be bootstrapped with the following script:

Metacello new baseline: 'Sparta'; repository: 'github://syrel/sparta:v1.1/src'; load: #file:core

Strange crash detected. I just execute twice this script and pharo crashed. I use Mac sierra. And here is top of crash.dmp: C stack backtrace & registers: eax 0x0f986260 ebx 0x00000000 ecx 0x00000000 edx 0x00000000 edi 0x103bfc4e esi 0x103bfc4e ebp 0xbff58bf8 esp 0xbff58bd0 eip 0x103bfcd4 0 libMoz2D.dylib 0x103bfcd4 _ZN22nsComponentManagerImpl4InitEv + 148 1 Pharo 0x00067b16 reportStackState + 166 Smalltalk stack dump: 0xbff69b60 I MozServices class>primStartServices 0xca6c830: a(n) MozServices class 0xbff69b80 I MozServices class>start 0xca6c830: a(n) MozServices class

Right, but since there are known bugs in Sierra perhaps MozServices is hitting one of them. In our case we hit a bug in poll() which is a bit surprising and apparently the bug is hitting Apple's own curl implementation -- see discussion here[1]... Dale [1] https://github.com/curl/curl/issues/1057 On 10/21/2016 04:56 PM, Denis Kudriashov wrote:

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>>:

Denis,

Sierra seems to have some issues. A couple weeks ago one of our users ran into a problem with Pharo3.0 and Sierra

Pharo works fine. When I first time load Sparta everything works well. I am not saw any problem. But it crashed when MozServices are starting second time where dll call is failed (last log entry)

I use plugin for months and never had a single random crash :) It is very stable On Oct 22, 2016 11:55 AM, "Aliaksei Syrel" <alex.syrel@gmail.com> wrote:

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.

Cheers Alex

On Oct 22, 2016 2:09 AM, "Dale Henrichs" <dale.henrichs@gemtalksystems.com> wrote:

...

Right, but since there are known bugs in Sierra perhaps MozServices is hitting one of them.

In our case we hit a bug in poll() which is a bit surprising and apparently the bug is hitting Apple's own curl implementation -- see discussion here[1]...

Dale [1] https://github.com/curl/curl/issues/1057

On 10/21/2016 04:56 PM, Denis Kudriashov wrote:

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs <dale.henrichs@gemtalksystems.com

...

:

...

Denis,

Sierra seems to have some issues. A couple weeks ago one of our users ran into a problem with Pharo3.0 and Sierra

Pharo works fine. When I first time load Sparta everything works well. I am not saw any problem. But it crashed when MozServices are starting second time where dll call is failed (last log entry)