Re: [Pharo-dev] [Ann] Stack Android VM

[Denis Kudriashov]

Great.
Do you have prebuilt apk file?

2016-10-23 22:03 GMT+02:00 Santiago Bragagnolo :

>Still far from production. But since i would happy to have some
> feedback, I'm happy to show you some progress on the android VM. Not yet
> release. But we have already a way of compiling and deploying an image into
> an android device.
>
>   You can check it in this repo github.
>   https://github.com/sbragagnolo/pharo-vm/
>
>   The building steps are detailed on the README-Android.md file.
> Building the Stack AndroidVM
>
>1.
>
>Download the sources from github
>
>
>git clone --depth=1 https://github.com/sbragagnolo/pharo-vmcd pharo-vm
>
>2.
>
>Set-up your environment: This script will download the SDK installer
>and NDK R10
>
>cd android/scripts
>./setupAndroidEnvironment.st
>
>This script downloads the content from
>- 'http://dl.google.com/android/repository/android-ndk-r10e-
>   linux-x86_64.zip'.
>   - 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'.
>
>After this process you should have available the environment variables
>ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by checking your .bashrc
>file at the user's home directory.
>3.
>
>Create a new image: this image will be created by pointing to this
>local git repository
>
>cd android/scripts
>./newImage.st
>
>4.
>
>Link sources to the build folder: The Android vm relies on a Java
>wrapper. This sources must be accessible from the build folder.
>
>cd android/scripts
>./linkSources.st
>
>5.
>
>Generate the sources of the stack vm: This script executes the
>generator of the image created on int the 3rd step.
>
>cd android/scripts
>./generateStackAndroidMake.st
>
>6.
>
>Generate the resource image for deployment: This script download and
>suites up an image for deployment on the folder build/assets/
>SmalltalkRessources
>
>cd android/scripts
>./newResourceImage.st
>
>This image created in this point is downloaded with it related VM for
>editing and loading the code you want to deploy, or configure the things
>you want.
>7.
>
>The VM compilation: This script generates the libraries with the VM
>code.
>
>cd build
>./build.sh
>
>8.
>
>The Java wrapper compilation and Android Application packaging
>
>cd build
>./package.sh
>
>9.
>
>Installing into your device. If you want to generate an APK file with
>your custom name, you will need to deal with the AndroidManifest.xml before
>runing the package.sh script :)
>
>cd build/bin
>adb install -r StackActivity-debug.apk
>
>
>
> - Im currently working on the JIT version of the VM, that still avoiding
> me :).
>  But you have as well the instruction on the same README-Android.me file.
>
>
>  Santiago
>
>
>
>
>
>
>
>

Re: [Pharo-dev] [ANN] Scale

[p...@highoctane.be]

Ok thanks, that will do for me.

Phil

On Sun, Oct 23, 2016 at 10:11 PM, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

> Thanks Phil! That's not easy to do now, Is mean to be a feature for the
> next version.
>
> By the moment you have to add the variable to SCScriptRunner and
> initialize the value maybe in initialize.
>
> This SCScriptRunner is the context of execution of the script.
>
>
>
> On Sun, 23 Oct 2016 at 21:48 p...@highoctane.be 
> wrote:
>
>> Ah, this is just *beautiful*
>>
>> Thank you thank you thank you for making this available.
>>
>> Question: How is one creating a new scripting object and making it
>> available? (like system etc).
>>
>> Phil
>>
>>
>>
>>
>>
>> On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo <
>> santiagobragagn...@gmail.com> wrote:
>>
>> Hi everybody.
>>
>> We are officially releasing a first version of scale.
>>
>> Scale is a command line handler that is there for making easier the life
>> of the people that uses scripting in linux. As such, we only tested it so
>> far in linux. It will be for sure easy to adapt it to mac because its a
>> *nix, but not for windoze.
>>
>> *IMPORTANT REMARK*: scale is not meant to develop applications, it is
>> meant to develop scripts in Pharo, to be launched from the command line.
>> This means that scale does not provide a top level syntax to declare
>> classes or methods: people should do that as any normal Pharo application.
>> Scale should be used to invoke such applications.
>>
>> When would you use scale?
>>   - For example, to replace some bash scripts used for common boring
>> tasks (and you are using python or ruby there :P)
>>   - Another example, would be when you want to replace bash scripts that
>> chain things like:
>> ./pharo eval --save "something"
>> ./pharo eval --save "other something"
>> ...
>>
>> Github: https://github.com/guillep/Scale
>> Oneliner to install: (note it needs sudo)
>>
>>  wget -O- 
>> https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo 
>> bash
>>
>>
>> In the repository there is some user level documentation based on
>> examples and a list of available methods on the magical variable system.
>> There are many examples as well on the repository.
>>
>> Last but not least, I'm using this project in others two projects, where
>> it proof it self quite powerful what keeps me on maintaining Scale.
>>
>> These projects are:
>>
>> *Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm
>>
>>  Here I use it for automating the creation of a
>>* new building image,
>>* the creation of new resource image (for deploying on the android
>> apk),
>>* linking the android sources into the building directory
>>* generating the code from the console
>>
>> *MakrosTool* https://github.com/sbragagnolo/MakrosTool
>>
>> MakrosTool is an extension of scale that adds a second magical variable
>> for building up component reification in a ROS based environment.
>>
>>
>> Santiago & Guille
>>
>>
>>
>>
>>
>>
>>

Re: [Pharo-dev] [Ann] Stack Android VM

[Aliaksei Syrel]

AMAZING!!!

I will definitely try to compile :)
Thanks a lot for this great work! Keep it up!

Cheers,
Alex

On 23 October 2016 at 22:03, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

>Still far from production. But since i would happy to have some
> feedback, I'm happy to show you some progress on the android VM. Not yet
> release. But we have already a way of compiling and deploying an image into
> an android device.
>
>   You can check it in this repo github.
>   https://github.com/sbragagnolo/pharo-vm/
>
>   The building steps are detailed on the README-Android.md file.
> Building the Stack AndroidVM
>
>1.
>
>Download the sources from github
>
>
>git clone --depth=1 https://github.com/sbragagnolo/pharo-vmcd pharo-vm
>
>2.
>
>Set-up your environment: This script will download the SDK installer
>and NDK R10
>
>cd android/scripts
>./setupAndroidEnvironment.st
>
>This script downloads the content from
>- 'http://dl.google.com/android/repository/android-ndk-r10e-
>   linux-x86_64.zip'.
>   - 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'.
>
>After this process you should have available the environment variables
>ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by checking your .bashrc
>file at the user's home directory.
>3.
>
>Create a new image: this image will be created by pointing to this
>local git repository
>
>cd android/scripts
>./newImage.st
>
>4.
>
>Link sources to the build folder: The Android vm relies on a Java
>wrapper. This sources must be accessible from the build folder.
>
>cd android/scripts
>./linkSources.st
>
>5.
>
>Generate the sources of the stack vm: This script executes the
>generator of the image created on int the 3rd step.
>
>cd android/scripts
>./generateStackAndroidMake.st
>
>6.
>
>Generate the resource image for deployment: This script download and
>suites up an image for deployment on the folder build/assets/
>SmalltalkRessources
>
>cd android/scripts
>./newResourceImage.st
>
>This image created in this point is downloaded with it related VM for
>editing and loading the code you want to deploy, or configure the things
>you want.
>7.
>
>The VM compilation: This script generates the libraries with the VM
>code.
>
>cd build
>./build.sh
>
>8.
>
>The Java wrapper compilation and Android Application packaging
>
>cd build
>./package.sh
>
>9.
>
>Installing into your device. If you want to generate an APK file with
>your custom name, you will need to deal with the AndroidManifest.xml before
>runing the package.sh script :)
>
>cd build/bin
>adb install -r StackActivity-debug.apk
>
>
>
> - Im currently working on the JIT version of the VM, that still avoiding
> me :).
>  But you have as well the instruction on the same README-Android.me file.
>
>
>  Santiago
>
>
>
>
>
>
>
>

Re: [Pharo-dev] [ANN] Scale

[Santiago Bragagnolo]

Thanks Phil! That's not easy to do now, Is mean to be a feature for the
next version.

By the moment you have to add the variable to SCScriptRunner and initialize
the value maybe in initialize.

This SCScriptRunner is the context of execution of the script.



On Sun, 23 Oct 2016 at 21:48 p...@highoctane.be  wrote:

> Ah, this is just *beautiful*
>
> Thank you thank you thank you for making this available.
>
> Question: How is one creating a new scripting object and making it
> available? (like system etc).
>
> Phil
>
>
>
>
>
> On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo <
> santiagobragagn...@gmail.com> wrote:
>
> Hi everybody.
>
> We are officially releasing a first version of scale.
>
> Scale is a command line handler that is there for making easier the life
> of the people that uses scripting in linux. As such, we only tested it so
> far in linux. It will be for sure easy to adapt it to mac because its a
> *nix, but not for windoze.
>
> *IMPORTANT REMARK*: scale is not meant to develop applications, it is
> meant to develop scripts in Pharo, to be launched from the command line.
> This means that scale does not provide a top level syntax to declare
> classes or methods: people should do that as any normal Pharo application.
> Scale should be used to invoke such applications.
>
> When would you use scale?
>   - For example, to replace some bash scripts used for common boring tasks
> (and you are using python or ruby there :P)
>   - Another example, would be when you want to replace bash scripts that
> chain things like:
> ./pharo eval --save "something"
> ./pharo eval --save "other something"
> ...
>
> Github: https://github.com/guillep/Scale
> Oneliner to install: (note it needs sudo)
>
>  wget -O- 
> https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo 
> bash
>
>
> In the repository there is some user level documentation based on examples
> and a list of available methods on the magical variable system.  There are
> many examples as well on the repository.
>
> Last but not least, I'm using this project in others two projects, where
> it proof it self quite powerful what keeps me on maintaining Scale.
>
> These projects are:
>
> *Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm
>
>  Here I use it for automating the creation of a
>* new building image,
>* the creation of new resource image (for deploying on the android
> apk),
>* linking the android sources into the building directory
>* generating the code from the console
>
> *MakrosTool* https://github.com/sbragagnolo/MakrosTool
>
> MakrosTool is an extension of scale that adds a second magical variable
> for building up component reification in a ROS based environment.
>
>
> Santiago & Guille
>
>
>
>
>
>
>

[Pharo-dev] [Ann] Stack Android VM

[Santiago Bragagnolo]

   Still far from production. But since i would happy to have some
feedback, I'm happy to show you some progress on the android VM. Not yet
release. But we have already a way of compiling and deploying an image into
an android device.

  You can check it in this repo github.
  https://github.com/sbragagnolo/pharo-vm/

  The building steps are detailed on the README-Android.md file.
Building the Stack AndroidVM

   1.

   Download the sources from github
   

   git clone --depth=1 https://github.com/sbragagnolo/pharo-vmcd pharo-vm

   2.

   Set-up your environment: This script will download the SDK installer and
   NDK R10

   cd android/scripts
   ./setupAndroidEnvironment.st

   This script downloads the content from
   - '
  http://dl.google.com/android/repository/android-ndk-r10e-linux-x86_64.zip
  '.
  - 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'.

   After this process you should have available the environment variables
   ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by checking your .bashrc
   file at the user's home directory.
   3.

   Create a new image: this image will be created by pointing to this local
   git repository

   cd android/scripts
   ./newImage.st

   4.

   Link sources to the build folder: The Android vm relies on a Java
   wrapper. This sources must be accessible from the build folder.

   cd android/scripts
   ./linkSources.st

   5.

   Generate the sources of the stack vm: This script executes the generator
   of the image created on int the 3rd step.

   cd android/scripts
   ./generateStackAndroidMake.st

   6.

   Generate the resource image for deployment: This script download and
   suites up an image for deployment on the folder
   build/assets/SmalltalkRessources

   cd android/scripts
   ./newResourceImage.st

   This image created in this point is downloaded with it related VM for
   editing and loading the code you want to deploy, or configure the things
   you want.
   7.

   The VM compilation: This script generates the libraries with the VM code.

   cd build
   ./build.sh

   8.

   The Java wrapper compilation and Android Application packaging

   cd build
   ./package.sh

   9.

   Installing into your device. If you want to generate an APK file with
   your custom name, you will need to deal with the AndroidManifest.xml before
   runing the package.sh script :)

   cd build/bin
   adb install -r StackActivity-debug.apk



- Im currently working on the JIT version of the VM, that still avoiding me
:).
 But you have as well the instruction on the same README-Android.me file.


 Santiago

Re: [Pharo-dev] [ANN] Scale

[p...@highoctane.be]

Ah, this is just *beautiful*

Thank you thank you thank you for making this available.

Question: How is one creating a new scripting object and making it
available? (like system etc).

Phil





On Sun, Oct 23, 2016 at 8:34 PM, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

> Hi everybody.
>
> We are officially releasing a first version of scale.
>
> Scale is a command line handler that is there for making easier the life
> of the people that uses scripting in linux. As such, we only tested it so
> far in linux. It will be for sure easy to adapt it to mac because its a
> *nix, but not for windoze.
>
> *IMPORTANT REMARK*: scale is not meant to develop applications, it is
> meant to develop scripts in Pharo, to be launched from the command line.
> This means that scale does not provide a top level syntax to declare
> classes or methods: people should do that as any normal Pharo application.
> Scale should be used to invoke such applications.
>
> When would you use scale?
>   - For example, to replace some bash scripts used for common boring tasks
> (and you are using python or ruby there :P)
>   - Another example, would be when you want to replace bash scripts that
> chain things like:
> ./pharo eval --save "something"
> ./pharo eval --save "other something"
> ...
>
> Github: https://github.com/guillep/Scale
> Oneliner to install: (note it needs sudo)
>
>  wget -O- 
> https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo 
> bash
>
>
> In the repository there is some user level documentation based on examples
> and a list of available methods on the magical variable system.  There are
> many examples as well on the repository.
>
> Last but not least, I'm using this project in others two projects, where
> it proof it self quite powerful what keeps me on maintaining Scale.
>
> These projects are:
>
> *Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm
>
>  Here I use it for automating the creation of a
>* new building image,
>* the creation of new resource image (for deploying on the android
> apk),
>* linking the android sources into the building directory
>* generating the code from the console
>
> *MakrosTool* https://github.com/sbragagnolo/MakrosTool
>
> MakrosTool is an extension of scale that adds a second magical variable
> for building up component reification in a ROS based environment.
>
>
> Santiago & Guille
>
>
>
>
>
>

[Pharo-dev] [ANN] Scale

[Santiago Bragagnolo]

Hi everybody.

We are officially releasing a first version of scale.

Scale is a command line handler that is there for making easier the life of
the people that uses scripting in linux. As such, we only tested it so far
in linux. It will be for sure easy to adapt it to mac because its a *nix,
but not for windoze.

*IMPORTANT REMARK*: scale is not meant to develop applications, it is meant
to develop scripts in Pharo, to be launched from the command line. This
means that scale does not provide a top level syntax to declare classes or
methods: people should do that as any normal Pharo application. Scale
should be used to invoke such applications.

When would you use scale?
  - For example, to replace some bash scripts used for common boring tasks
(and you are using python or ruby there :P)
  - Another example, would be when you want to replace bash scripts that
chain things like:
./pharo eval --save "something"
./pharo eval --save "other something"
...

Github: https://github.com/guillep/Scale
Oneliner to install: (note it needs sudo)

 wget -O- https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh
| sudo bash


In the repository there is some user level documentation based on examples
and a list of available methods on the magical variable system.  There are
many examples as well on the repository.

Last but not least, I'm using this project in others two projects, where it
proof it self quite powerful what keeps me on maintaining Scale.

These projects are:

*Pharo Android VM building *https://github.com/sbragagnolo/pharo-vm

 Here I use it for automating the creation of a
   * new building image,
   * the creation of new resource image (for deploying on the android
apk),
   * linking the android sources into the building directory
   * generating the code from the console

*MakrosTool* https://github.com/sbragagnolo/MakrosTool

MakrosTool is an extension of scale that adds a second magical variable for
building up component reification in a ROS based environment.


Santiago & Guille

Re: [Pharo-dev] roundTo: strange behavior

[p...@highoctane.be]

I use the Printf package for that.

v := 65.456.
'With 2 decimal digits: %5.2f, or 3 like this: %6.3f'
printf: {v. v}.

With 2 decimal digits: 65.45, or 3 like this: 65.456

It is in http://www.smalltalkhub.com/#!/~philippeback/HOExtras

Printf

I am just used to C printf and well, I like the way it works.

Phil

On Sun, Oct 23, 2016 at 6:35 PM, stepharo  wrote:

> I see.
>
> I writing a little example for my new newbies book
>
> now how can get only two digits after the .
>
>
> Stef
>
> Le 23/10/16 à 18:23, Thierry Goubier a écrit :
>
> I think that's called 'welcome to the wonderfull world of floating points
> approximations' and not a bug :(
>
> See unums/Gustafson for something more interesting on the subject.
>
> Thierry
>
> 2016-10-23 18:16 GMT+02:00 stepharo :
>
>> Hi
>>
>> I'm wondering if we do not have a bug here
>>
>> 12.221 roundTo: 0.1
>>  "12.201"
>>
>> 12.221 roundTo: 0.01
>>  "12.22"
>>
>>
>> Stef
>>
>>
>>
>
>

Re: [Pharo-dev] roundTo: strange behavior

[stepharo]

Thanks because roundUpTo: did not make it either :)


Le 23/10/16 à 18:45, Peter Uhnak a écrit :

I usually use 12.221 round: 2 "12.22".

Peter

On Sun, Oct 23, 2016 at 06:38:47PM +0200, stepharo wrote:

3.1479 roundUpTo: 0.01 is what I was looking for.


Stef



Le 23/10/16 à 18:35, stepharo a écrit :

I see.

I writing a little example for my new newbies book

now how can get only two digits after the .


Stef


Le 23/10/16 à 18:23, Thierry Goubier a écrit :

I think that's called 'welcome to the wonderfull world of
floating points approximations' and not a bug :(

See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo mailto:steph...@free.fr>>:

Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef

Re: [Pharo-dev] roundTo: strange behavior

[Peter Uhnak]

I usually use 12.221 round: 2 "12.22".

Peter

On Sun, Oct 23, 2016 at 06:38:47PM +0200, stepharo wrote:
> 3.1479 roundUpTo: 0.01 is what I was looking for.
> 
> 
> Stef
> 
> 
> 
> Le 23/10/16 à 18:35, stepharo a écrit :
> >
> >I see.
> >
> >I writing a little example for my new newbies book
> >
> >now how can get only two digits after the .
> >
> >
> >Stef
> >
> >
> >Le 23/10/16 à 18:23, Thierry Goubier a écrit :
> >>I think that's called 'welcome to the wonderfull world of
> >>floating points approximations' and not a bug :(
> >>
> >>See unums/Gustafson for something more interesting on the subject.
> >>
> >>Thierry
> >>
> >>2016-10-23 18:16 GMT+02:00 stepharo  >>>:
> >>
> >>Hi
> >>
> >>I'm wondering if we do not have a bug here
> >>
> >>12.221 roundTo: 0.1
> >> "12.201"
> >>
> >>12.221 roundTo: 0.01
> >> "12.22"
> >>
> >>
> >>Stef
> >>
> >>
> >>
> >
> 

Re: [Pharo-dev] roundTo: strange behavior

[Dimitris Chloupis]

aand I was wrong, my bad

On Sun, Oct 23, 2016 at 7:29 PM Dimitris Chloupis 
wrote:

> I think lisp solves this problem by using integers for its floats , or
> something along those line, I remember reading about it somewhere when I
> was studying common lisp 5 years ago
>
> Or maybe my memory fails me
>
> On Sun, Oct 23, 2016 at 7:24 PM Thierry Goubier 
> wrote:
>
> I think that's called 'welcome to the wonderfull world of floating points
> approximations' and not a bug :(
>
> See unums/Gustafson for something more interesting on the subject.
>
> Thierry
>
>
> 2016-10-23 18:16 GMT+02:00 stepharo :
>
> Hi
>
> I'm wondering if we do not have a bug here
>
> 12.221 roundTo: 0.1
>  "12.201"
>
> 12.221 roundTo: 0.01
>  "12.22"
>
>
> Stef
>
>
>
>

Re: [Pharo-dev] roundTo: strange behavior

[stepharo]

3.1479 roundUpTo: 0.01 is what I was looking for.


Stef



Le 23/10/16 à 18:35, stepharo a écrit :


I see.

I writing a little example for my new newbies book

now how can get only two digits after the .


Stef


Le 23/10/16 à 18:23, Thierry Goubier a écrit :
I think that's called 'welcome to the wonderfull world of floating 
points approximations' and not a bug :(


See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo >:


Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef

Re: [Pharo-dev] roundTo: strange behavior

[stepharo]

I see.

I writing a little example for my new newbies book

now how can get only two digits after the .


Stef


Le 23/10/16 à 18:23, Thierry Goubier a écrit :
I think that's called 'welcome to the wonderfull world of floating 
points approximations' and not a bug :(


See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo >:


Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef

Re: [Pharo-dev] roundTo: strange behavior

[Dimitris Chloupis]

I think lisp solves this problem by using integers for its floats , or
something along those line, I remember reading about it somewhere when I
was studying common lisp 5 years ago

Or maybe my memory fails me

On Sun, Oct 23, 2016 at 7:24 PM Thierry Goubier 
wrote:

> I think that's called 'welcome to the wonderfull world of floating points
> approximations' and not a bug :(
>
> See unums/Gustafson for something more interesting on the subject.
>
> Thierry
>
>
> 2016-10-23 18:16 GMT+02:00 stepharo :
>
> Hi
>
> I'm wondering if we do not have a bug here
>
> 12.221 roundTo: 0.1
>  "12.201"
>
> 12.221 roundTo: 0.01
>  "12.22"
>
>
> Stef
>
>
>
>

Re: [Pharo-dev] roundTo: strange behavior

[Thierry Goubier]

I think that's called 'welcome to the wonderfull world of floating points
approximations' and not a bug :(

See unums/Gustafson for something more interesting on the subject.

Thierry

2016-10-23 18:16 GMT+02:00 stepharo :

> Hi
>
> I'm wondering if we do not have a bug here
>
> 12.221 roundTo: 0.1
>  "12.201"
>
> 12.221 roundTo: 0.01
>  "12.22"
>
>
> Stef
>
>
>

[Pharo-dev] roundTo: strange behavior

[stepharo]

Hi

I'm wondering if we do not have a bug here

12.221 roundTo: 0.1
 "12.201"

12.221 roundTo: 0.01
 "12.22"


Stef

Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

[stepharo]

Is there no way Igor can finish this up?


Not that I know.
I did not get why Igor went totally off like that.


Phil


Le 23 oct. 2016 12:19, "stepharo" > a écrit :



Hi Stef,

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

Don't play with words.

We already learnt a lot from TxText, but it has limitations in
how to deal with things that are not only text.

I can imagine.

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

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

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

Cheers,
Doru


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

Hi aliaksei

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

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

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

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

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

Cheers,
Alex

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

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

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

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

"Some battles are better lost than fought."

Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

[Sean P. DeNigris]

stepharo wrote
>> We have no intention of producing an unfinished text model :).
> Me neither with igor and txText yet life decided otherwise. You see I 
> spent at 10 months of salary on txText.

I'm not sure if the following qualifies as a rant, but I apologize in
advance just in case...

Hopefully the difference in this instance is that there is an entire team
around this effort. It's just hard to be asked to trust after years of
(albeit solo, usually unpaid) projects, touted as our future salvation, and
then abandoned when "life got in the way" - e.g. (in no particular order,
and some of these might not exactly fit into the above description) TxText,
Nautilus, Spec, Amber, Simple Morphic / Morphic 3, NativeBoost, Rome (iirc
the name), etc. The thing is that in niche (i.e. non-core dev) projects this
path to failure seems to be the rule, and not an exception, especially when
releases are put off indefinitely chasing perfection.

I have a very personal experience of this since one of my first desires  (a
quick search of the mailing list shows a post as early as May 14, 2010!) was
to implement VIM key bindings. Our exasperating text/editor model quickly
ground the project to a halt. I feel like I've been waiting for a
just-around-the-corner cleanup in this area for over 6 years now. Of course,
I'm not complaining about the lack of result, just offering some context
around the suspicion and concern about yet-another-reboot with not a single
release in over 7 years.

All that having been said, you're directions of investigation are very
exciting and I look forward to the results!



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

Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

[Tudor Girba]

Hi,


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

I am really not playing with words :). We really have zero desire in working on 
the text editor. Just like we had zero desire in working on Sparta and Bloc. We 
are doing it because we need a sane infrastructure. We have halted the work on 
user interface of GT for more than 1 year just because it did not make 
engineering and economic sense to invest on the current infrastructure.

We need an infrastructure to support at least the next 5-10 years of 
development, and we are decided to deliver on it.

The investment in TxText is not at all wasted, it allowed us to bootstrap Bloc 
and to learn. We might end up with reusing parts of it, but the thing is that 
now we have new opportunities that come with Sparta.

For example, all text measurements are super accurate and are available in 
image. This means that we can address text rendering in two ways:
1. treat text as one entity and embed graphics inside as elements in the text 
model. This is where TxText is. However, TxText does not have the support for 
non-text elements (at least not now). Furthermore, this approach makes floating 
images inside the text (images that allow text to wrap around) to not be really 
working. 
2. split the text in different sections and lay it out together with other 
graphical elements using the layout engine from Bloc.

Option 2 was not really an option until now because we did not have the 
performance and accuracy. Now it is an option and we want to investigate this 
as well before committing to a model.

Cheers,
Doru



>> Cheers,
>> Doru
>> 
>> 
>>> On Oct 22, 2016, at 8:31 PM, stepharo  wrote:
>>> 
>>> Hi aliaksei
>>> 
>>> I thought that you were just changing the internal representation of txText 
>>> to use Ropes
>>> and building on top of / improving txText
>>> I did not think that you were throwing away all the work igor did. Because 
>>> he spent a lot of time
>>> 
>>> designing the text model and making it is scalable - and now I read that 
>>> apparently it was not scalable enough.
>>> I'm wondering what will happen if suddenly you disappear: we will get two 
>>> unfinished textmodel
>>> and use an old one? When do you think that you will have a working usable 
>>> by other for real text model?
>>> Stef
>>> 
>>> Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :
 As Doru already mentioned text editor is an important part of the tools. 
 There are some requirements a text editor should fulfil.
 
• Support of large files ( >> 100mb)
• Support of large pieces of text located in memory
• Allow developers to embed visual elements (pictures, interactive 
 elements, custom elements)
• Support of more sophisticated layouts rather than line-based. For 
 example columns.
• Line breaking
• Text wrapping
• Hyphens
• Should be fast
 Tests show that TxText model is very nice for basic cases, works well for 
 "normal" use.
 However, when it comes to extreme cases linked list of spans just fails, 
 while rope shows great performance - and it also scales.
 
 Cheers,
 Alex
 
 On 19 October 2016 at 23:51, Denis Kudriashov  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?
 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Some battles are better lost than fought."
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

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

"Next time you see your life passing by, say 'hi' and get to know her."

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

[philippe.b...@highoctane.be]

What has VTermOutputDriver to do with FilePolicy?

Le 23 oct. 2016 12:22, "stepharo"  a écrit :

> In the bug tracker
>
> https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver
>
> https://pharo.fogbugz.com/f/cases/18649/
>
> we got a lot of problems because the monkey and our build process were
> using the api we wanted to change.
>
> So now we are making the changes one by one.
>
> I hope to work on it during the next sprint.
>
>
> Stef
>
>
>
> Le 23/10/16 à 11:31, p...@highoctane.be a écrit :
>
> Where?
>
> On Sun, Oct 23, 2016 at 10:42 AM, stepharo  wrote:
>
>> Note that all the work on making sure that the image is not writing files
>> when it is on read only mode is part of making coral installable on unix.
>> Now if people wants coral they can join the effort.
>>
>> stef
>>
>>
>
>

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] new text model / TxText [was Re: [ANN] Sparta v1.1]

[philippe.b...@highoctane.be]

Is there no way Igor can finish this up?

Phil

Le 23 oct. 2016 12:19, "stepharo"  a écrit :

>
> Hi Stef,
>>
>> We are not throwing away anything. The goal is not to produce a new
>> model, the goal is to find one that matches the requirements.
>>
> Don't play with words.
>
> We already learnt a lot from TxText, but it has limitations in how to deal
>> with things that are not only text.
>>
> I can imagine.
>
>> We have no intention of producing an unfinished text model :).
>>
> Me neither with igor and txText yet life decided otherwise. You see I
> spent at 10 months of salary on txText.
>
>>   This is a critical component for us. Please let us work for a couple of
>> months and we get back with news.
>>
>> Cheers,
>> Doru
>>
>>
>> On Oct 22, 2016, at 8:31 PM, stepharo  wrote:
>>>
>>> Hi aliaksei
>>>
>>> I thought that you were just changing the internal representation of
>>> txText to use Ropes
>>> and building on top of / improving txText
>>> I did not think that you were throwing away all the work igor did.
>>> Because he spent a lot of time
>>>
>>> designing the text model and making it is scalable - and now I read that
>>> apparently it was not scalable enough.
>>> I'm wondering what will happen if suddenly you disappear: we will get
>>> two unfinished textmodel
>>> and use an old one? When do you think that you will have a working
>>> usable by other for real text model?
>>> Stef
>>>
>>> Le 22/10/16 à 12:29, Aliaksei Syrel a écrit :
>>>
 As Doru already mentioned text editor is an important part of the
 tools. There are some requirements a text editor should fulfil.

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

 Cheers,
 Alex

 On 19 October 2016 at 23:51, Denis Kudriashov 
 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?

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

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

[stepharo]

In the bug tracker

https://pharo.fogbugz.com/f/cases/18650/VTermOutputDriver

https://pharo.fogbugz.com/f/cases/18649/

we got a lot of problems because the monkey and our build process were 
using the api we wanted to change.


So now we are making the changes one by one.

I hope to work on it during the next sprint.


Stef



Le 23/10/16 à 11:31, p...@highoctane.be a écrit :

Where?

On Sun, Oct 23, 2016 at 10:42 AM, stepharo > wrote:


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

stef

Re: [Pharo-dev] new text model / TxText [was Re: [ANN] Sparta v1.1]

[stepharo]

Hi Stef,

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

Don't play with words.


We already learnt a lot from TxText, but it has limitations in how to deal with 
things that are not only text.

I can imagine.

We have no intention of producing an unfinished text model :).
Me neither with igor and txText yet life decided otherwise. You see I 
spent at 10 months of salary on txText.

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

Cheers,
Doru



On Oct 22, 2016, at 8:31 PM, stepharo  wrote:

Hi aliaksei

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

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

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

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

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

Cheers,
Alex

On 19 October 2016 at 23:51, Denis Kudriashov  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?


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

"Some battles are better lost than fought."

Re: [Pharo-dev] MetaLink to conditionally skip a method execution based on an arg

[Peter Uhnak]

I was looking at this and ran into some very odd behavior:

imagine we have some method:

```
Object subclass: #MyClass.
MyClass compile: 'method: arg
Transcript crShow: ''executed '', arg asString'.
```

and a simple metalink

```
link := MetaLink new
metaObject: Halt;
selector: #now;
control: #instead.

(MyClass >> #method:) ast link: link.
```

Now I can do the following to execute the code:

```
c := MyClass new.
(MyClass>>#method:) valueWithReceiver: c arguments: #(1).
(MyClass>>#method:) reflectiveMethod valueWithReceiver: c arguments: #(1).
(MyClass>>#method:) compiledMethod valueWithReceiver: c arguments: #(1).
MyClass rFwithArgs: #(1) executeMethod: (MyClass>>#method:) compiledMethod.
```

All of the statements above will call the method WITHOUT triggering the 
metalink, which is odd.

Now what's even stranger, if I instead do this

```
c := MyClass new.
c method: 1.
(MyClass>>#method:) valueWithReceiver: c arguments: #(1).
(MyClass>>#method:) reflectiveMethod valueWithReceiver: c arguments: #(1).
(MyClass>>#method:) compiledMethod valueWithReceiver: c arguments: #(1).
MyClass rFwithArgs: #(1) executeMethod: (MyClass>>#method:) compiledMethod.
```

Then ALL the statements (starting with `c method: 1`) will be suddenly halting 
(triggering the metalinks).


So my questions are:

1) why in the first case the following two methods didn't trigger the metalink?

(MyClass>>#method:) valueWithReceiver: c arguments: #(1).
(MyClass>>#method:) reflectiveMethod valueWithReceiver: c arguments: #(1).

2) why in the second case these two methods did trigger the metalink?

(MyClass>>#method:) compiledMethod valueWithReceiver: c arguments: #(1).
MyClass rFwithArgs: #(1) executeMethod: (MyClass>>#method:) compiledMethod.

#rFwithArgs:executeMethod: even has comment "This method is used by 
reflectivity internally. All meta-links are ignored".

3) why the class of (MyClass>>#method:) changed after calling `method:`?

```
(MyClass >> #method:) ast link: link.

c := MyClass new.
(MyClass>>#method:) class. "ReflectiveMethod"
(MyClass>>#method:) valueWithReceiver: c arguments: #(1).
(MyClass>>#method:) class. "ReflectiveMethod"
c method: 1.
(MyClass>>#method:) class. "CompiledMethod"
```

4) (unrelated to the above) I tried calling `link disable` from within the 
#metaObject, but it was ignored, but maybe I don't understand its purpose.


Thanks,
Peter

On Sun, Oct 23, 2016 at 09:21:59AM +0200, Yuriy Tymchuk wrote:
> I’ve also described the question with examples on SO: 
> https://stackoverflow.com/questions/40200546/conditionally-skip-a-method-with-matalinks
> 
> > On 22 Oct 2016, at 23:13, Yuriy Tymchuk  wrote:
> > 
> > Hi.
> > 
> > Imagine I have method a: and I want to skip the execution (return self or 
> > nil or whatever) when a: is evaluated with parameter 0. I have tried to add 
> > a meta link which will run instead of the method with a condition, but the 
> > condition did not work… I have tried to implement the metallic method to do 
> > nothing if the arg is 0 otherwise to perform the method, but I end up with 
> > an infinite loop…
> > 
> > Did anybody do something like that already? Any suggestions?
> > 
> > Uko
> 

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

[p...@highoctane.be]

Where?

On Sun, Oct 23, 2016 at 10:42 AM, stepharo  wrote:

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

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 and the image, the app memory consumption at runtime 
>>> would be

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 Bloc 
code. Is it working for you? I mean is it me that is using th

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

[stepharo]

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

stef

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

[Esteban Lorenzano]

> On 22 Oct 2016, at 20:16, stepharo  wrote:
> 
> 
> 
> Le 22/10/16 à 17:21, p...@highoctane.be  a écrit :
>> The st command line handler is pretty much giving the same.
>> 
>> I used scale, it works nicely indeed.
>> 
>> But I want Coral reborn.
> 
> me too. 
> Damien is working on a new command line parser. 

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

Esteban 

> 
>> 
>> Phil
>> 
>> On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis > > wrote:
>> This link may interest you command line people , it basically what I 
>> proposed as an idea early on
>> 
>> https://github.com/guillep/Scale 
>> 
>> On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis > > wrote:
>> I was replying to Thierry saying that we had issues with Pharo mixing 
>> metarepo6 with metarepo5
>> On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano > > wrote:
>> 
>>> On 22 Oct 2016, at 12:00, Dimitris Chloupis >> > wrote:
>>> 
>>> Didn't Esteban fixed metarepo ? I think I remember him saying that he did.
>> 
>> fixed in what sense?
>> 
>> Esteban
>> 
>> 
> 

Re: [Pharo-dev] MetaLink to conditionally skip a method execution based on an arg

[Yuriy Tymchuk]

I’ve also described the question with examples on SO: 
https://stackoverflow.com/questions/40200546/conditionally-skip-a-method-with-matalinks

> On 22 Oct 2016, at 23:13, Yuriy Tymchuk  wrote:
> 
> Hi.
> 
> Imagine I have method a: and I want to skip the execution (return self or nil 
> or whatever) when a: is evaluated with parameter 0. I have tried to add a 
> meta link which will run instead of the method with a condition, but the 
> condition did not work… I have tried to implement the metallic method to do 
> nothing if the arg is 0 otherwise to perform the method, but I end up with an 
> infinite loop…
> 
> Did anybody do something like that already? Any suggestions?
> 
> Uko