Discussion:
[ANN] Sparta v1.1
(too old to reply)
Aliaksei Syrel
2016-10-19 16:06:49 UTC
Permalink
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
Alexandre Bergel
2016-10-19 19:08:28 UTC
Permalink
This is impressive! We are moving right!

Alexandre


> On Oct 19, 2016, at 1:06 PM, Aliaksei Syrel <***@gmail.com> wrote:
>
> Hi
>
> I am happy to announce the release of Sparta v1.1 for Pharo 6.
> https://github.com/syrel/Sparta/tree/v1.1 <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)
> <sparta-text-haiku.png>
>
> (measurement)
> <sparta-text-measurement.png>
>
>
> Cheers,
> Alex
Tudor Girba
2016-10-19 19:16:05 UTC
Permalink
Great work!

Doru



> On Oct 19, 2016, at 5:06 PM, Aliaksei Syrel <***@gmail.com> wrote:
>
> 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)
> <sparta-text-haiku.png>
>
> (measurement)
> <sparta-text-measurement.png>
>
>
> Cheers,
> Alex

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

"We are all great at making mistakes."
Norbert Hartl
2016-10-19 20:02:12 UTC
Permalink
Great! Seems to be the case that we need to take the 64bit border!!

Norbert

> Am 19.10.2016 um 18:06 schrieb Aliaksei Syrel <***@gmail.com>:
>
> 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)
> <sparta-text-haiku.png>
>
> (measurement)
> <sparta-text-measurement.png>
>
>
> Cheers,
> Alex
stepharo
2016-10-19 20:15:20 UTC
Permalink
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)
> Inline images 2
> (measurement)
> Inline images 1
> Cheers,
> Alex
Aliaksei Syrel
2016-10-20 07:07:30 UTC
Permalink
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" <***@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
>
>
Aliaksei Syrel
2016-10-20 07:16:41 UTC
Permalink
Hi Denis

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


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:
- support of very large files (gigabytes)
- multithreading (styling, syntax highlighting in background)
=> text model has to be immutable
- fast access by index (for styling; parser returns Tokens with indices)
- optimised for sparta (use all amazing text features provided by Moz2D)

Cheers,
Alex

On 20 October 2016 at 09:07, Aliaksei 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 :)
>
> Cheers
> Alex
>
> On Oct 19, 2016 22:16, "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
>>
>>
Denis Kudriashov
2016-10-20 09:50:54 UTC
Permalink
Hi Aliaksei

2016-10-20 9:16 GMT+02:00 Aliaksei 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?
Denis Kudriashov
2016-10-20 10:02:59 UTC
Permalink
I also wondering about Sparta approach for text layout/rendering. You
implemented old text morph idea: layout text while render it. Why you
choose it?

With such approach all computed information about text layout is lost when
text is rendered. You can't reuse it for text navigation/editing. And
anytime redraw is needed all these objects will be recreated again. Many
garbage for any redraw. And many garbage for text navigation, for any
cursor movement.
Am I wrong about it?


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

> Hi Denis
>
> I look at code and it seems you implemented another one new text model?
>> Why you not use TxText?
>
>
> 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:
> - support of very large files (gigabytes)
> - multithreading (styling, syntax highlighting in background)
> => text model has to be immutable
> - fast access by index (for styling; parser returns Tokens with indices)
> - optimised for sparta (use all amazing text features provided by Moz2D)
>
> Cheers,
> Alex
>
> On 20 October 2016 at 09:07, Aliaksei 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 :)
>>
>> Cheers
>> Alex
>>
>> On Oct 19, 2016 22:16, "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
>>>
>>>
>
Denis Kudriashov
2016-10-20 10:07:42 UTC
Permalink
2016-10-20 9:07 GMT+02:00 Aliaksei 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.
Clément Bera
2016-10-21 12:23:24 UTC
Permalink
On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei 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" <***@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
>>
>>
Tudor Girba
2016-10-21 13:41:29 UTC
Permalink
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 <***@gmail.com> wrote:
>
>
>
> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei 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" <***@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."
Clément Bera
2016-10-21 14:29:22 UTC
Permalink
On Fri, Oct 21, 2016 at 3:41 PM, Tudor Girba <***@tudorgirba.com> wrote:

> 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?
>

It does. I understand a BitBlt back-end is possible to have UI applications
running on a low memory footprint runtime. Now the question the community
should answer is if we want to implement and maintain that back-end or not.


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

I would love to see that. It's theoretically possible, it's just a matter
of doing it and integrating it while it's time-consuming. I believe there
was some work in that direction as part of the SDL / OSWindow work.

If the community wants to move to Sparta and does not care if the memory
footprint is increased by 5 Mb for non headless application, it may make
sense to invest in that direction instead of the implementation and
maintenance of a BitBlt based back-end.


>
> Cheers,
> Doru
>
> > On Oct 21, 2016, at 2:23 PM, Clément Bera <***@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei 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" <***@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."
>
>
>
>
>
>
stepharo
2016-10-23 08:43:11 UTC
Permalink
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 <***@gmail.com> wrote:
>>
>>
>>
>> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei 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" <***@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."
>
>
>
>
>
>
Tudor Girba
2016-10-23 08:51:19 UTC
Permalink
Yes. At this point, there is no fallback implemented.

Doru


> On Oct 23, 2016, at 10:43 AM, stepharo <***@free.fr> wrote:
>
> 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 <***@gmail.com> wrote:
>>>
>>>
>>>
>>> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei 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" <***@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."
>>
>>
>>
>>
>>
>>
>
>

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

"Beauty is where we see it."
Denis Kudriashov
2016-10-19 20:52:13 UTC
Permalink
Super!!!

Is latest Bloc uses Sparta?

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

> 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
>
Glenn Cavarlé
2016-10-19 23:15:42 UTC
Permalink
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.

Cheers,
Glenn.



-----
Glenn Cavarlé
--
View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919438.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Denis Kudriashov
2016-10-20 20:17:11 UTC
Permalink
2016-10-20 1:15 GMT+02:00 Glenn Cavarlé <***@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?
Aliaksei Syrel
2016-10-20 22:18:50 UTC
Permalink
Hi Denis

Thanks for your questions! They are important.
Unfortunately, I didn't have time today to perform a detailed comparison
and stress test of txtext model.
I will answer tomorrow :)

Cheers,
Alex

On 20 October 2016 at 22:17, Denis Kudriashov <***@gmail.com> wrote:

>
> 2016-10-20 1:15 GMT+02:00 Glenn Cavarlé <***@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
2016-10-19 21:29:10 UTC
Permalink
2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <***@gmail.com>:

> Examples are on class side of: MozExamples, MozTextExamples
>

I found 18+ example :)))
Denis Kudriashov
2016-10-19 21:51:34 UTC
Permalink
2016-10-19 18:06 GMT+02:00 Aliaksei 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?
Sean P. DeNigris
2016-10-21 02:00:35 UTC
Permalink
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 Hartl
2016-10-21 07:10:26 UTC
Permalink
> Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <***@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.
>
Dale Henrichs
2016-10-21 13:34:01 UTC
Permalink
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 <***@clipperadams.com
> <mailto:***@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>.
>>
Norbert Hartl
2016-10-21 13:50:29 UTC
Permalink
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 <***@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 <***@clipperadams.com <mailto:***@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/>.
>>>
>
Tudor Girba
2016-10-21 14:02:55 UTC
Permalink
Hi Norbert,

It is not ignored at all.

Cheers,
Doru


> On Oct 21, 2016, at 3:50 PM, Norbert Hartl <***@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 <***@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 <***@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."
Dale Henrichs
2016-10-21 14:12:49 UTC
Permalink
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
>> <***@gemtalksystems.com
>> <mailto:***@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
>>> <***@clipperadams.com <mailto:***@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/>.
>>>>
>>
>
p***@highoctane.be
2016-10-21 14:17:02 UTC
Permalink
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 <
***@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 <
> ***@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 <***@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/>.
>
>
>
>
>
Norbert Hartl
2016-10-21 14:30:37 UTC
Permalink
Dale,

> Am 21.10.2016 um 16:12 schrieb 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/>

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 <***@gemtalksystems.com <mailto:***@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 <***@clipperadams.com <mailto:***@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/>.
>>>>>
>>>
>>
>
Esteban Lorenzano
2016-10-21 14:51:31 UTC
Permalink
> On 21 Oct 2016, at 16:30, Norbert Hartl <***@hartl.name> wrote:
>
> Dale,
>
>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs <***@gemtalksystems.com <mailto:***@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 <***@gemtalksystems.com <mailto:***@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 <***@clipperadams.com <mailto:***@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/>.
>>>>>>
>>>>
>>>
>>
>
Todd Blanchard
2016-10-21 16:04:47 UTC
Permalink
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
Dimitris Chloupis
2016-10-21 18:12:33 UTC
Permalink
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 <***@mac.com> wrote:

>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
p***@highoctane.be
2016-10-22 07:04:50 UTC
Permalink
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 <***@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 <***@mac.com> wrote:
>
>>
>> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>>
>
Dimitris Chloupis
2016-10-22 07:52:31 UTC
Permalink
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 ***@highoctane.be <***@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 <***@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 <***@mac.com> wrote:
>
>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
>
>
Thierry Goubier
2016-10-22 08:36:39 UTC
Permalink
Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com>
>> wrote:
>>
>>
>> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>>
>>
>>
Dimitris Chloupis
2016-10-22 08:56:29 UTC
Permalink
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-scripts-in-pharo/

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

> Hi Kilon,
>
> 2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com> wrote:
>
>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
>
>
Thierry Goubier
2016-10-22 09:33:05 UTC
Permalink
Hi Kilon,

2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <***@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-scripts-in-pharo/
>
> 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 <
> ***@gmail.com> wrote:
>
>> Hi Kilon,
>>
>> 2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com>
>> wrote:
>>
>>
>> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>>
>>
>>
Dimitris Chloupis
2016-10-22 10:00:59 UTC
Permalink
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 <***@gmail.com>
wrote:

> Hi Kilon,
>
> 2016-10-22 10:56 GMT+02:00 Dimitris Chloupis <***@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-scripts-in-pharo/
>
> 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 <
> ***@gmail.com> wrote:
>
> Hi Kilon,
>
> 2016-10-22 9:52 GMT+02:00 Dimitris Chloupis <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com> wrote:
>
>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
>
>
Esteban Lorenzano
2016-10-22 10:10:54 UTC
Permalink
> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com> wrote:
>
> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.

fixed in what sense?

Esteban
Dimitris Chloupis
2016-10-22 10:20:48 UTC
Permalink
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 <***@gmail.com> wrote:

>
> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com> wrote:
>
> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>
>
> fixed in what sense?
>
> Esteban
>
>
Dimitris Chloupis
2016-10-22 10:41:53 UTC
Permalink
This link may interest you command line people , it basically what I
proposed as an idea early on

https://github.com/guillep/Scale

On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <***@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 <***@gmail.com>
> wrote:
>
>
> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com> wrote:
>
> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>
>
> fixed in what sense?
>
> Esteban
>
>
Esteban Lorenzano
2016-10-22 11:41:29 UTC
Permalink
> On 22 Oct 2016, at 12:41, Dimitris Chloupis <***@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 <***@gmail.com <mailto:***@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 <***@gmail.com <mailto:***@gmail.com>> wrote:
>
>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>
> fixed in what sense?
>
> Esteban
>
Norbert Hartl
2016-10-22 14:24:59 UTC
Permalink
Isn't that something complementary to pharo. Why have the tools a different name??? I think pharo should be usable as scripting engine.

And that means files should begin with

#! /usr/bin/env pharo

Norbert

> Am 22.10.2016 um 13:41 schrieb Esteban Lorenzano <***@gmail.com>:
>
>
>> On 22 Oct 2016, at 12:41, Dimitris Chloupis <***@gmail.com> wrote:
>>
>> This link may interest you command line people , it basically what I proposed as an idea early on
>>
>> https://github.com/guillep/Scale
>
> yes, Santi is working a lot on it so I think they are going to release it very soon :)
>
> Esteban
>
>>
>>> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <***@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 <***@gmail.com> wrote:
>>>>
>>>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com> wrote:
>>>>
>>>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>>
>>> fixed in what sense?
>>>
>>> Esteban
>>>
>
Esteban Lorenzano
2016-10-22 16:15:42 UTC
Permalink
> On 22 Oct 2016, at 16:24, Norbert Hartl <***@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 <***@gmail.com <mailto:***@gmail.com>>:
>
>>
>>> On 22 Oct 2016, at 12:41, Dimitris Chloupis <***@gmail.com <mailto:***@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 <***@gmail.com <mailto:***@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 <***@gmail.com <mailto:***@gmail.com>> wrote:
>>>
>>>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com <mailto:***@gmail.com>> wrote:
>>>>
>>>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>>
>>> fixed in what sense?
>>>
>>> Esteban
>>>
>>
p***@highoctane.be
2016-10-22 15:21:09 UTC
Permalink
The st command line handler is pretty much giving the same.

I used scale, it works nicely indeed.

But I want Coral reborn.

Phil

On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis <***@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
>
> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis <***@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 <***@gmail.com>
>> wrote:
>>
>>
>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com>
>> wrote:
>>
>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>
>>
>> fixed in what sense?
>>
>> Esteban
>>
>>
stepharo
2016-10-22 18:16:48 UTC
Permalink
Le 22/10/16 à 17:21, ***@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
> <***@gmail.com <mailto:***@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
> <***@gmail.com <mailto:***@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
> <***@gmail.com <mailto:***@gmail.com>> wrote:
>
>
>> On 22 Oct 2016, at 12:00, Dimitris Chloupis
>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>> Didn't Esteban fixed metarepo ? I think I remember him
>> saying that he did.
>
> fixed in what sense?
>
> Esteban
>
>
Esteban Lorenzano
2016-10-23 08:12:50 UTC
Permalink
> On 22 Oct 2016, at 20:16, stepharo <***@free.fr> wrote:
>
>
>
> Le 22/10/16 à 17:21, ***@highoctane.be <mailto:***@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.

we can have one while we want for the other.
as it is now, we do not have none :)

Esteban

>
>>
>> Phil
>>
>> On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis <***@gmail.com <mailto:***@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 <***@gmail.com <mailto:***@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 <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>>> On 22 Oct 2016, at 12:00, Dimitris Chloupis <***@gmail.com <mailto:***@gmail.com>> wrote:
>>>
>>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>>
>> fixed in what sense?
>>
>> Esteban
>>
>>
>
stepharo
2016-10-23 08:42:09 UTC
Permalink
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
p***@highoctane.be
2016-10-23 09:31:39 UTC
Permalink
Where?

On Sun, Oct 23, 2016 at 10:42 AM, 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
>
>
stepharo
2016-10-23 10:21:35 UTC
Permalink
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, ***@highoctane.be a écrit :
> Where?
>
> On Sun, Oct 23, 2016 at 10:42 AM, stepharo <***@free.fr
> <mailto:***@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
>
>
Esteban Lorenzano
2016-10-22 10:09:13 UTC
Permalink
> On 22 Oct 2016, at 10:56, Dimitris Chloupis <***@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 :)
Dale Henrichs
2016-10-22 13:50:06 UTC
Permalink
On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>> On 22 Oct 2016, at 10:56, Dimitris Chloupis <***@gmail.com
>> <mailto:***@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
Dimitris Chloupis
2016-10-22 14:03:33 UTC
Permalink
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 <
***@gemtalksystems.com> wrote:

>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>
> On 22 Oct 2016, at 10:56, Dimitris Chloupis <***@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
>
Dale Henrichs
2016-10-22 14:50:22 UTC
Permalink
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
> <http://smalltalkhub.com/#%21/%7EPharo/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
> <***@gemtalksystems.com
> <mailto:***@gemtalksystems.com>> wrote:
>
>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>>
>>> On 22 Oct 2016, at 10:56, Dimitris Chloupis
>>> <***@gmail.com <mailto:***@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
>
Dimitris Chloupis
2016-10-22 15:36:11 UTC
Permalink
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 <
***@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 <
> ***@gemtalksystems.com> wrote:
>
>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>
> On 22 Oct 2016, at 10:56, Dimitris Chloupis <***@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
>
>
>
p***@highoctane.be
2016-10-22 15:31:45 UTC
Permalink
CatalogProvider projectNamed: 'QuickAccess'

is doing that already.

Or I am mistaken?
Phil

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

>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>
>
> On 22 Oct 2016, at 10:56, Dimitris Chloupis <***@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
>
Dale Henrichs
2016-10-22 16:37:24 UTC
Permalink
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, ***@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
> <***@gemtalksystems.com
> <mailto:***@gemtalksystems.com>> wrote:
>
>
>
> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>>
>>> On 22 Oct 2016, at 10:56, Dimitris Chloupis
>>> <***@gmail.com <mailto:***@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 Lorenzano
2016-10-22 16:41:39 UTC
Permalink
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 <***@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, ***@highoctane.be <mailto:***@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 <***@gemtalksystems.com <mailto:***@gemtalksystems.com>> wrote:
>>
>>
>> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>>>
>>>> On 22 Oct 2016, at 10:56, Dimitris Chloupis <***@gmail.com <mailto:***@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
>>
>
Dale Henrichs
2016-10-22 17:48:48 UTC
Permalink
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.ston'
asMetacelloProjectLoadSpec load

or:

'https://raw.githubusercontent.com/GsDevKit/GsDevKit_home/gh-pages/Tugrik.ston'
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
>> <***@gemtalksystems.com
>> <mailto:***@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, ***@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
>>> <***@gemtalksystems.com
>>> <mailto:***@gemtalksystems.com>> wrote:
>>>
>>>
>>>
>>> On 10/22/16 3:09 AM, Esteban Lorenzano wrote:
>>>>
>>>>> On 22 Oct 2016, at 10:56, Dimitris Chloupis
>>>>> <***@gmail.com <mailto:***@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
>>>
>>>
>>
>
p***@highoctane.be
2016-10-22 09:14:17 UTC
Permalink
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 <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com>
>> wrote:
>>
>>
>> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>>
>>
>>
Dimitris Chloupis
2016-10-22 09:28:56 UTC
Permalink
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 ***@highoctane.be <***@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 <***@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 ***@highoctane.be <***@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 <***@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 <***@mac.com> wrote:
>
>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
>
>
>
Dale Henrichs
2016-10-22 13:34:14 UTC
Permalink
On 10/22/16 12:52 AM, Dimitris Chloupis wrote:
> Actually we dont, I am using the terminal to get and build my own
> images. Curl + use of startup scripts are more than enough. Simply ,
> easy and straightforward. Pharo offers a super easy way to export any
> method as a command line argument. So there is literally no excuse.
>
> Pharo already offers a metacello argument so you are set to go on
> installing anything you want through the terminal in your image and
> also offers evaluation of smalltalk code as argument. But I prefer
> startup scripts, I have made a startup script that can detect the name
> of images and install different packages to them, you can do insane
> things with startup scripts actually.
>
> you can find my build setup here
>
> https://github.com/kilon/makePharo
For GsDevKit_home, I have a projects directory[1] where I store
TDProjectSpecEntryDefinitions ... which are the moral equivalent of each
of your `Metacello new` lines in the script ... By putting a Metacello
load "spec" in an object, it is easier to customize the build of an
image, than it is to edit and manage a smalltalk script. For example in
tODE here are the commands that would be used to construct your image
(the name of the project refers to the names the .ston objects in the
projects directory:

project load IconFactory
project load ChronosManager
project load Nireas
project load Ephestos

With scripts based on something like this, it is easy to change all of
the load scripts sharing the load specs (TDProjectSpecEntryDefinitions)
by editing the .ston file on disk ... all builds going forward would
pick up the new specification ...

Dale

[1]
https://github.com/GsDevKit/GsDevKit_home/tree/master/sys/default/server/projects
>
>
> On Sat, Oct 22, 2016 at 10:06 AM ***@highoctane.be
> <mailto:***@highoctane.be> <***@highoctane.be
> <mailto:***@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
> <***@gmail.com <mailto:***@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
> <***@mac.com <mailto:***@mac.com>> wrote:
>
>
>> On Oct 21, 2016, at 07:30, Norbert Hartl
>> <***@hartl.name <mailto:***@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.
>
>
Dimitris Chloupis
2016-10-22 14:01:19 UTC
Permalink
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.md

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 <
***@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/projects
>
>
>
> On Sat, Oct 22, 2016 at 10:06 AM ***@highoctane.be <***@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 <***@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 <***@mac.com> wrote:
>
>
> On Oct 21, 2016, at 07:30, Norbert Hartl <***@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.
>
>
>
>
Dale Henrichs
2016-10-22 14:36:10 UTC
Permalink
On 10/22/16 7:01 AM, Dimitris Chloupis wrote:
> I really like STON , even more than I like JSON. Very readable and
> easy to edit format. Very good idea, I would probably something
> similar but less more elegant.
This is why I'm threatening to create MetacelloProjectLoadSpec ... not
to be elegant but to save you the work of creating such a beast on your
own ... I really think there can be great advantages to have a sharable
and customizable load spec object ...
>
> You probably know this, but if you host the ston configurations files
> as you do in that link , Github gives you the ability to directly read
> files from inside a git repo without having to download it via its
> blob directory. So one could keep those ston config files in a repo in
> git and have access to it from any computer , any OS, of course under
> the condition he/she is connected to internet.
I have collected a number of the TDProjectEntry objects up on the
GsDevKit_home project on the gh-pages branch and I a variant of the load
command that works with an url:

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

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

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

[1] https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages
>
> This trick is what I used for checking whether there is a new version
> of my project ChronosManager in my git repo. I added the latest
> version in the RELEASENOTES text file that is located on the top level
> repo which it compares with its internal versions (just a class
> variable) and if it finds it bigger it alerts the user for an update.
>
> https://raw.githubusercontent.com/kilon/ChronosManager/master/RELEASENOTES.md
Ah yes, it would be much more convenient to get the load specification
object directly from the project itself ...

Dale
Dale Henrichs
2016-10-22 13:17:13 UTC
Permalink
On 10/22/16 12:04 AM, ***@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-gemstones-64-bit-
[2] https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client
[3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston
[4] https://github.com/hpi-swa/smalltalkCI#smalltalkci---
[5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston
p***@highoctane.be
2016-10-22 15:29:16 UTC
Permalink
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 <***@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 <
***@gemtalksystems.com> wrote:

>
>
> On 10/22/16 12:04 AM, ***@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-gemstones-64-bit-
> [2] https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client
> [3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston
> [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci---
> [5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston
>
Dale Henrichs
2016-10-22 18:27:37 UTC
Permalink
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, ***@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 <***@highoctane.be <mailto:***@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
> <***@gemtalksystems.com
> <mailto:***@gemtalksystems.com>> wrote:
>
>
>
> On 10/22/16 12:04 AM, ***@highoctane.be
> <mailto:***@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-gemstones-64-bit
> <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>
>
stepharo
2016-10-22 18:39:30 UTC
Permalink
This is what christophe is doing in cargo.


Stef



Le 22/10/16 à 17:29, ***@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 <***@highoctane.be <mailto:***@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
> <***@gemtalksystems.com
> <mailto:***@gemtalksystems.com>> wrote:
>
>
>
> On 10/22/16 12:04 AM, ***@highoctane.be
> <mailto:***@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-gemstones-64-bit
> <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>
>
Todd Blanchard
2016-10-22 19:19:00 UTC
Permalink
Pointer?

Sent from the road

> On Oct 22, 2016, at 11:39, stepharo <***@free.fr> wrote:
>
> This is what christophe is doing in cargo.
>
> Stef
>
>
>
>> Le 22/10/16 à 17:29, ***@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 <***@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 <***@gemtalksystems.com> wrote:
>>>
>>>
>>> On 10/22/16 12:04 AM, ***@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-gemstones-64-bit- [2] https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client [3] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci--- [5] https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston
stepharo
2016-10-22 18:14:31 UTC
Permalink
Superb Phil.


PS: For the record:

we are working on

- bootstrap core and we are making progress

- Git support

- package manager and distribution building

Now we cannot go faster.

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

Now it was NEEDED and we get Spur and SIsta.

Stef


Le 22/10/16 à 09:04, ***@highoctane.be a écrit :
> We need some easy to use gem-style installer on the command line.
>
> Pharo is perfectly usable for any kind of project provided energy is
> poured in.
>
> Things are in flux, yes, and it is frustrating not to have it all
> perfect. So what? If we weren't interested in wild things why would we
> be here after all?
>
> Think long term: 10 years from now, improvements will have been
> massively compounding (not to mention 20).
>
> I hope to have a huge win with Pharo business wise and be able to fund
> a serious team. That's my dream. I am actively working on it.
>
> Pharo can stay relevant for that long I believe. I love the way it
> helps me think. I love the fact that I can look everywhere I want. I
> love the fact that this community has balls. I love to show the magic
> we can do with it. If it all goes nowhere, I do not even mind as I
> have a damn awesome time around here.
>
> Now, I also want a working text model. This feels like a kind of
> psychological roadblock. Like a self sabotage. Let's put that dead rat
> on the table and make something about it.
>
> I like Doru's Pillar editor. I guess the underlying engine will evolve
> to make it faster. Great. Grafoscopio will also be a driving force
> there I believe. Pharo can be superspeedy, no core problem.
>
> Sorry for the rant.
>
> Now back to promoting Pharo in front of Android/Angular/Java people
> this afternoon at http://devfest.be (note that this is the 3rd time I
> show Pharo/Amber there - they could kick me out but do not).
>
> /Phil
>
>
> On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis
> <***@gmail.com <mailto:***@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 <***@mac.com
> <mailto:***@mac.com>> wrote:
>
>
>> On Oct 21, 2016, at 07:30, Norbert Hartl <***@hartl.name
>> <mailto:***@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.
>
>
Dale Henrichs
2016-10-21 20:15:00 UTC
Permalink
On 10/21/2016 07:30 AM, Norbert Hartl wrote:
> Dale,
>
>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs
>> <***@gemtalksystems.com
>> <mailto:***@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
p***@highoctane.be
2016-10-22 07:08:54 UTC
Permalink
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?

Metacello is great, especially with GTInspector so that we can see the
directives etc.

Compared to Maven pom.xml / parent and nexus/artefactory repos, it is
easier to deal with I'd say.

Phil



On Fri, Oct 21, 2016 at 10:15 PM, Dale Henrichs <
***@gemtalksystems.com> wrote:

>
>
> On 10/21/2016 07:30 AM, Norbert Hartl wrote:
>
> Dale,
>
> Am 21.10.2016 um 16:12 schrieb 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
>
>
>
>
>
>
>
Dale Henrichs
2016-10-22 13:23:56 UTC
Permalink
On 10/22/16 12:08 AM, ***@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
p***@highoctane.be
2016-10-22 15:30:12 UTC
Permalink
Ok, message received. PRs launching.

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

>
>
> On 10/22/16 12:08 AM, ***@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
>
>
Dale Henrichs
2016-10-22 16:38:07 UTC
Permalink
Much appreciated!


On 10/22/16 8:30 AM, ***@highoctane.be wrote:
> Ok, message received. PRs launching.
>
> On Sat, Oct 22, 2016 at 3:23 PM, Dale Henrichs
> <***@gemtalksystems.com
> <mailto:***@gemtalksystems.com>> wrote:
>
>
>
> On 10/22/16 12:08 AM, ***@highoctane.be
> <mailto:***@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 Hartl
2016-10-22 10:56:52 UTC
Permalink
Dale,

> Am 21.10.2016 um 22:15 schrieb 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 <***@gemtalksystems.com <mailto:***@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.
>
> 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.

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

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

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.


> 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

Norbert
Dale Henrichs
2016-10-22 14:24:42 UTC
Permalink
Norbert,


On 10/22/16 3:56 AM, Norbert Hartl wrote:
> Dale,
>
>> Am 21.10.2016 um 22:15 schrieb Dale Henrichs
>> <***@gemtalksystems.com
>> <mailto:***@gemtalksystems.com>>:
>>
>>
>>
>> On 10/21/2016 07:30 AM, Norbert Hartl wrote:
>>> Dale,
>>>
>>>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs
>>>> <***@gemtalksystems.com
>>>> <mailto:***@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/LockCommandReference.md#lock-command-reference
[2]
https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Metacello.ston#L10
>
>> Regarding the "command-line", did you know that once you've loaded a
>> project using the new way, that you can re-load a project using the
>> following shorter smalltalk script:
>>
>> Metacello image baseline: 'AAA'; load
>>
> That's good and will try that.
>
>> I made a sweep through the docs a couple of years ago, but since no
>> one seemed to be interested in using the new API I found other things
>> to do ... and now that there's more interest in the "new way" I
>> simply don't have the time (right now) to make another pass through
>> the docs ... so you can be cranky about that too :)
>>
> Come on! Now you sound a bit cranky :P
>

haha ... "well-tempered crankiness" my friend, "well-tempered crankiness"

Dale
Stephan Eggermont
2016-10-21 08:30:19 UTC
Permalink
On 21/10/16 04:00, Sean P. DeNigris 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, 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 :/

There seem to be different ideas about what a sane text model is. I'm
only interested in a high-quality text editing model, extendable to
support hyphenation, kerning, line-breaking, multiple-column page
layout, tables, foot- and endnotes, styling on more than a character
span basis. In particular I will not use a model that is only suitable
for line-based editing. That is a dead-end. It is fine to have only
trivial implementations of those at first, but the abstractions need to
be there.

Stephan
Tudor Girba
2016-10-21 13:21:10 UTC
Permalink
> On Oct 21, 2016, at 4:00 AM, Sean P. DeNigris <***@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."
Denis Kudriashov
2016-10-21 13:55:49 UTC
Permalink
2016-10-21 15:21 GMT+02:00 Tudor Girba <***@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?
Tudor Girba
2016-10-21 14:15:07 UTC
Permalink
Hi,

> On Oct 21, 2016, at 3:55 PM, Denis Kudriashov <***@gmail.com> wrote:
>
>
> 2016-10-21 15:21 GMT+02:00 Tudor Girba <***@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."
Denis Kudriashov
2016-10-21 14:20:22 UTC
Permalink
2016-10-21 16:15 GMT+02:00 Tudor Girba <***@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.
Denis Kudriashov
2016-10-21 23:57:35 UTC
Permalink
2016-10-21 16:20 GMT+02:00 Denis Kudriashov <***@gmail.com>:

> 2016-10-21 16:15 GMT+02:00 Tudor Girba <***@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.
Sean P. DeNigris
2016-10-21 14:43:50 UTC
Permalink
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]?

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.
Esteban Lorenzano
2016-10-21 15:19:01 UTC
Permalink
> On 21 Oct 2016, at 16:43, Sean P. DeNigris <***@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.
>
Sven Van Caekenberghe
2016-10-21 15:30:18 UTC
Permalink
> On 21 Oct 2016, at 17:19, Esteban Lorenzano <***@gmail.com> wrote:
>
>>
>> On 21 Oct 2016, at 16:43, Sean P. DeNigris <***@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.

Yes, that does not feel good.

But the fact that something is not completely finished is in the first place the responsibility of who started it in the first place - they did not drive there work all the way through (including integration, documentation, actively supporting it for a couple of years).

> 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.
Aliaksei Syrel
2016-10-22 10:29:00 UTC
Permalink
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 <***@gmail.com> wrote:

>
> 2016-10-19 18:06 GMT+02:00 Aliaksei 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?
>
stepharo
2016-10-22 18:31:32 UTC
Permalink
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.
>
> 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 <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
>
> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <***@gmail.com
> <mailto:***@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?
>
>
Tudor Girba
2016-10-23 05:05:00 UTC
Permalink
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 <***@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 <***@gmail.com> wrote:
>>
>> 2016-10-19 18:06 GMT+02:00 Aliaksei 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."
stepharo
2016-10-23 10:18:27 UTC
Permalink
> 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 <***@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 <***@gmail.com> wrote:
>>>
>>> 2016-10-19 18:06 GMT+02:00 Aliaksei 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."
>
>
>
>
>
>
philippe.back@highoctane.be
2016-10-23 10:32:26 UTC
Permalink
Is there no way Igor can finish this up?

Phil

Le 23 oct. 2016 12:19, "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 <***@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 <***@gmail.com>
>>>> wrote:
>>>>
>>>> 2016-10-19 18:06 GMT+02:00 Aliaksei 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."
>>
>>
>>
>>
>>
>>
>>
>
>
Stephan Eggermont
2016-10-21 08:26:10 UTC
Permalink
On 19/10/16 18:06, Aliaksei Syrel wrote:
> Examples are on class side of: MozExamples, MozTextExamples

Error: could not coerce arguments

primSetAttributeEnum: anEnumValue index: anIndex

^ self ffiCall: #(void moz2d_filter_node_set_attribute_int(self,
FFIExternalEnumeration anIndex, FFIExternalEnumeration anEnumValue))

60265, Vm 497, Mac, 10.10.5

Stephan
Denis Kudriashov
2016-10-21 22:44:34 UTC
Permalink
2016-10-19 18:06 GMT+02:00 Aliaksei 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
Dale Henrichs
2016-10-21 23:20:28 UTC
Permalink
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 <***@gmail.com
> <mailto:***@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
Denis Kudriashov
2016-10-21 23:56:11 UTC
Permalink
Hi Dale

2016-10-22 1:20 GMT+02:00 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)
Dale Henrichs
2016-10-22 00:08:39 UTC
Permalink
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
> <***@gemtalksystems.com
> <mailto:***@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)
>
>
Aliaksei Syrel
2016-10-22 09:55:09 UTC
Permalink
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" <***@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 <***@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)
>
>
>
>
Aliaksei Syrel
2016-10-22 09:56:45 UTC
Permalink
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" <***@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" <***@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 <***@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)
>>
>>
>>
>>
Denis Kudriashov
2016-10-22 11:44:28 UTC
Permalink
2016-10-22 11:55 GMT+02:00 Aliaksei Syrel <***@gmail.com>:

> MozServices crash is intentional!
> When you load Sparta using metacello it runs installer scripts and
> automatically starts services. But they are already running if you have
> Sparta installed.
>
> I need to find a pretty solution for it. Actually it is complicated.
> Services can not just stop while image is running, because rendering would
> instantly crash. Imagine if Bloc is running on Sparta, playground is
> rendered on Sparta. And now you stop services to update. What should
> happen? :)
>
> Just take fresh image. I will add an assertion to forbid Sparta
> installation if it is already installed.
>
Yes, this is what I thought about.
Denis Kudriashov
2016-10-23 10:37:29 UTC
Permalink
Hi Aliaksei.

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

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

What you think how difficult to move Morphic to Sparta canvas? In the way
Athens support was added to Morphic (by Nicolai Hess I guess?).
Maybe it could be useful to provide some comparison table between Athens
and Sparta API. What you think?
Loading...