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

[Denis Kudriashov]

Hi Aliaksei.

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :

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

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

[Tudor Girba]

Yes. At this point, there is no fallback implemented.

Doru


> On Oct 23, 2016, at 10:43 AM, stepharo  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  wrote:
>>> 
>>> 
>>> 
>>> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel  
>>> 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 

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

[stepharo]

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  wrote:



On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel  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"  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 

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

[Todd Blanchard]

Pointer? 

Sent from the road

> On Oct 22, 2016, at 11:39, stepharo  wrote:
> 
> This is what christophe is doing in cargo. 
> 
> Stef
> 
> 
> 
>> Le 22/10/16 à 17:29, p...@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 "
>>   ],
>>   "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 
>>>  wrote:
>>> 
>>> 
>>> On 10/22/16 12:04 AM, p...@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 

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

[stepharo]

This is what christophe is doing in cargo.


Stef



Le 22/10/16 à 17:29, p...@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 >"
  ],
  "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 
> wrote:




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

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

[stepharo]

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 > wrote:



2016-10-19 18:06 GMT+02:00 Aliaksei Syrel >:

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

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

[Dale Henrichs]

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, p...@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 >"
  ],
  "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 
> wrote:




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

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

[stepharo]

Superb Phil.


PS: For the record:

we are working on

- bootstrap core and we are making progress

- Git support

- package manager and distribution building

Now we cannot go faster.

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


Now it was NEEDED and we get Spur and SIsta.

Stef


Le 22/10/16 à 09:04, p...@highoctane.be a écrit :

We need some easy to use gem-style installer on the command line.

Pharo is perfectly usable for any kind of project provided energy is 
poured in.


Things are in flux, yes, and it is frustrating not to have it all 
perfect. So what? If we weren't interested in wild things why would we 
be here after all?


Think long term: 10 years from now, improvements will have been 
massively compounding (not to mention 20).


I hope to have a huge win with Pharo business wise and be able to fund 
a serious team. That's my dream. I am actively working on it.


Pharo can stay relevant for that long I believe. I love the way it 
helps me think. I love the fact that I can look everywhere I want. I 
love the fact that this community has balls. I love to show the magic 
we can do with it. If it all goes nowhere, I do not even mind as I 
have a damn awesome time around here.


Now, I also want a working text model. This feels like a kind of 
psychological roadblock. Like a self sabotage. Let's put that dead rat 
on the table and make something about it.


I like Doru's Pillar editor. I guess the underlying engine will evolve 
to make it faster. Great. Grafoscopio will also be a driving force 
there I believe. Pharo can be superspeedy, no core problem.


Sorry for the rant.

Now back to promoting Pharo in front of Android/Angular/Java people 
this afternoon at http://devfest.be (note that this is the 3rd time I 
show Pharo/Amber there - they could kick me out but do not).


/Phil


On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis 
> 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.

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

[Dale Henrichs]

Much appreciated!


On 10/22/16 8:30 AM, p...@highoctane.be wrote:

Ok, message received. PRs launching.

On Sat, Oct 22, 2016 at 3:23 PM, Dale Henrichs 
> wrote:




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

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

[p...@highoctane.be]

Ok, message received. PRs launching.

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

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

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

[p...@highoctane.be]

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 "
  ],
  "description": "adsdaq-frontend",
  "main": "",
  "moduleType": [],
  "license": "Adlogix",
  "private": true,
  "ignore": [
"**/.*",
"node_modules",
"bower_components",
"vendor/bower_components",
"test",
"tests"
  ],
  "dependencies": {
"angular": "~1.4.7",
"restangular": "~1.5.1",
"lodash": "~3.10.1",
"angular-route": "~1.4.7",
"angular-spinner": "~0.8.0",
"angular-bootstrap": "~0.14.3",
"typeahead.js": "~0.11.1"
  }
}


So, basic module names in deps and semver.

The st code you show is more cryptic.

Is there a sweet spot ?

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

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

What do you think?

Phil




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

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

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

[Dale Henrichs]

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

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

[Dimitris Chloupis]

I really like STON , even more than I like JSON. Very readable and easy to
edit format. Very good idea, I would probably something similar but less
more elegant.

You probably know this, but if you host the ston configurations files as
you do in that link , Github gives you the ability to directly read files
from inside a git repo without having to download it via its blob
directory. So one could keep those ston config files in a repo in git and
have access to it from any computer , any OS, of course under the condition
he/she is connected to internet.

This trick is what I used for checking whether there is a new version of my
project ChronosManager in my git repo. I added the latest version in the
RELEASENOTES text file that is located on the top level repo which it
compares with its internal versions (just a class variable) and if it finds
it bigger it alerts the user for an update.

https://raw.githubusercontent.com/kilon/ChronosManager/master/RELEASENOTES.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 <
dale.henri...@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 p...@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 
> 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 

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

[Dale Henrichs]

On 10/22/16 12:52 AM, Dimitris Chloupis wrote:
Actually we dont, I am using the terminal to get and build my own 
images. Curl + use of startup scripts are more than enough. Simply , 
easy and straightforward. Pharo offers a super easy way to export any 
method as a command line argument. So there is literally no excuse.


Pharo already offers a metacello argument so you are set to go on 
installing anything you want through the terminal in your image and 
also offers evaluation of smalltalk code as argument. But I prefer 
startup scripts, I have made a startup script that can detect the name 
of images and install different packages to them, you can do insane 
things with startup scripts actually.


you can find my build setup here

https://github.com/kilon/makePharo
For GsDevKit_home, I have a projects directory[1] where I store 
TDProjectSpecEntryDefinitions ... which are the moral equivalent of each 
of your `Metacello new` lines in the script ... By putting a Metacello 
load "spec" in an object, it is easier to customize the build of an 
image, than it is to edit and manage a smalltalk script. For example in 
tODE here are the commands that would be used to construct your image 
(the name of the project refers to the names the .ston objects in the 
projects directory:


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

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


Dale

[1] 
https://github.com/GsDevKit/GsDevKit_home/tree/master/sys/default/server/projects



On Sat, Oct 22, 2016 at 10:06 AM p...@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
> 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 

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

[Dale Henrichs]

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

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

[Dale Henrichs]

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

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

[Denis Kudriashov]

2016-10-22 11:55 GMT+02:00 Aliaksei Syrel :

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

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

[Norbert Hartl]

Dale,

> Am 21.10.2016 um 22:15 schrieb Dale Henrichs 
> :
> 
> 
> 
> On 10/21/2016 07:30 AM, Norbert Hartl wrote:
>> Dale,
>> 
>>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs 
>>> >> >:
>>> 
>>> 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 :)
>> 
>> 
>> 
> 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.
  

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

[Aliaksei Syrel]

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  wrote:

>
> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :
>
>>  - 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?
>

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

[Aliaksei Syrel]

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

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

[Aliaksei Syrel]

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

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

[Dimitris Chloupis]

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

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

[p...@highoctane.be]

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

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

[Thierry Goubier]

Hi Kilon,

2016-10-22 9:52 GMT+02:00 Dimitris Chloupis :

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

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

[Dimitris Chloupis]

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

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

[p...@highoctane.be]

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

>
>
> On 10/21/2016 07:30 AM, Norbert Hartl wrote:
>
> Dale,
>
> Am 21.10.2016 um 16:12 schrieb Dale Henrichs <
> dale.henri...@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 :)
>
> 
>
> 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
>
>
>
>
>
>
>

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

[p...@highoctane.be]

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

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

[Dale Henrichs]

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


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)

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

[Denis Kudriashov]

2016-10-21 16:20 GMT+02:00 Denis Kudriashov :

> 2016-10-21 16:15 GMT+02:00 Tudor Girba :
>
>> > 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.

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

[Denis Kudriashov]

Hi Dale

2016-10-22 1:20 GMT+02:00 Dale Henrichs :

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

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

[Dale Henrichs]

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



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 0x ecx 0x edx 0x
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

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

[Denis Kudriashov]

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :

>
> 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 0x ecx 0x edx 0x
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

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

[Dale Henrichs]

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

Dale,

Am 21.10.2016 um 16:12 schrieb Dale Henrichs 
>:


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





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

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

[Dimitris Chloupis]

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  wrote:

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

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

[Todd Blanchard]

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

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

[Sven Van Caekenberghe]

> On 21 Oct 2016, at 17:19, Esteban Lorenzano  wrote:
> 
>> 
>> On 21 Oct 2016, at 16:43, Sean P. DeNigris  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.

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

[Esteban Lorenzano]

> On 21 Oct 2016, at 16:43, Sean P. DeNigris  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.
> 

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

[Sean P. DeNigris]

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.

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

[Esteban Lorenzano]

> On 21 Oct 2016, at 16:30, Norbert Hartl  wrote:
> 
> Dale,
> 
>> Am 21.10.2016 um 16:12 schrieb Dale Henrichs 
>> >:
>> 
>> 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 :)
> 
> 
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 
 >:
 
 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  >:
> 
>> 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 

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

[Clément Bera]

On Fri, Oct 21, 2016 at 3:41 PM, Tudor Girba  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 
> wrote:
> >
> >
> >
> > On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel 
> 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 

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

[Norbert Hartl]

Dale,

> Am 21.10.2016 um 16:12 schrieb Dale Henrichs 
> :
> 
> 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 :)



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

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

[p...@highoctane.be]

I think that the concept of a LTS will become useful at one point.
Like, every 3 versions or so.



On Fri, Oct 21, 2016 at 4:12 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Norbert,
>
> I didn't realize that you were claiming that the new text model for Sparta
> was (potentially) inferior.
>
> The other day you were expressing sadness about having to use the newer
> version of Metacello (which is *only* 3 years old), so I assumed that you
> were just being generally cranky about change:).
>
> Dale
>
> On 10/21/16 6:50 AM, Norbert Hartl wrote:
>
> Dale,
>
> I was not arguing against evolution. I was refering to the fact that work
> of others is mostly ignored just to come up with a potential weaker
> solution.
>
> Norbert
>
> Am 21.10.2016 um 15:34 schrieb Dale Henrichs <
> dale.henri...@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 :
>
> 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 .
>
>
>
>
>

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

[Denis Kudriashov]

2016-10-21 16:15 GMT+02:00 Tudor Girba :

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

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

[Tudor Girba]

Hi,

> On Oct 21, 2016, at 3:55 PM, Denis Kudriashov  wrote:
> 
> 
> 2016-10-21 15:21 GMT+02:00 Tudor Girba :
> > 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."

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

[Dale Henrichs]

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


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



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 .

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

[Tudor Girba]

Hi Norbert,

It is not ignored at all.

Cheers,
Doru


> On Oct 21, 2016, at 3:50 PM, 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 
>> :
>> 
>> 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 :
>>> 
 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."

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

[Denis Kudriashov]

2016-10-21 15:21 GMT+02:00 Tudor Girba :

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

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

[Norbert Hartl]

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

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

[Tudor Girba]

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  wrote:
> 
> 
> 
> On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel  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"  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 

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

[Dale Henrichs]

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



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 .

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

[Tudor Girba]

> On Oct 21, 2016, at 4:00 AM, 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,

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

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

[Stephan Eggermont]

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

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

[Stephan Eggermont]

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

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

[Norbert Hartl]

> Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris :
> 
> 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.
> 

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

[Sean P. DeNigris]

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.

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

[Aliaksei Syrel]

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  wrote:

>
> 2016-10-20 1:15 GMT+02:00 Glenn Cavarlé :
>
>> 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?
>

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

[Denis Kudriashov]

2016-10-20 1:15 GMT+02:00 Glenn Cavarlé :

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

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

[Denis Kudriashov]

2016-10-20 9:07 GMT+02:00 Aliaksei Syrel :

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

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

[Denis Kudriashov]

Hi Aliaksei

2016-10-20 9:16 GMT+02:00 Aliaksei Syrel :

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

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

[Glenn Cavarlé]

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.

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

[Denis Kudriashov]

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :

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

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

[Denis Kudriashov]

2016-10-19 18:06 GMT+02:00 Aliaksei Syrel :

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

I found 18+ example :)))

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

[Norbert Hartl]

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 :
> 
> 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)
> 
> 
> (measurement)
> 
> 
> 
> Cheers,
> Alex

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

[Tudor Girba]

Great work!

Doru



> On Oct 19, 2016, at 5:06 PM, Aliaksei Syrel  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)
> 
> 
> (measurement)
> 
> 
> 
> Cheers,
> Alex

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

"We are all great at making mistakes."

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

[Alexandre Bergel]

This is impressive! We are moving right!

Alexandre


> On Oct 19, 2016, at 1:06 PM, Aliaksei Syrel  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)
> 
> 
> (measurement)
> 
> 
> 
> Cheers,
> Alex