October 2016 - Pharo-dev - lists.pharo.org

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

by 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 <bera.clement(a)gmail.com> wrote: > > > > On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi StÃ©phane > > Indeed, build is broken :) > Yesterday I took a very brief look at bloc and can confirm that development version is loadable in Pharo 6 and is completely Sparta based. (all examples work for me) > > You are right, live environment on embedded systems is great goal to achieve. Sparta must not prevent pharo from getting there. It is true that plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it is all-in-one build and size can be reduced dramatically. > > As I understand, Pharo for PC should not make any assumptions about user's hardware. If gpu accelerated backend can not be used there should be still a performant fallback backend which also needs a fallback that is guaranteed to work even on Personal Calculators. (Taschenrechner). That is why library is so big. For example for mac and windows Sparta is shipped with 3 (!) backends that together build fallback chain, for instance on windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia reduces binary size from 15mb to 10mb. Removing GL package and leaving only software backends may reduce size even more. > > It is a bit different on embedded systems, since hardware configuration is already known and there is no need to have so many fallback backends. Library itself allows developers to add new exotic backends quite easily. > > Let's take Pharo6 for mac. It is shipped with the following libs: > Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb > > Moz2D is self contained and does not require any additional libs. > Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? (estimate around 6-7mb). > > As you can see we get almost the same numbers :) > > Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE. > > Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint. > > Which leads the first question... > > >> Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? > > The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger. > > >> Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ? > > > Cheers > Alex > > On Oct 19, 2016 22:16, "stepharo" <stepharo(a)free.fr> wrote: > Hi Aliaksei > > It looks gorgeous. > I tried to launch the Bloc image from the CI and it crashes during startup on my mac. I reported that to Glenn and Alain but so far I simply cannot see Bloc code. Is it working for you? I mean is it me that is using the wrong VM. > > Then I have a question: > > - do you think that we can have a fallback in terms of back end for the case where we could like to run Pharo on coffee machines but get a live environment on such machines? This is related to the discussions we got this summer about the memory footprint that Moz2D will put on us. > > I do not mean that we must have one but I think that this is important to check because we can say that Pharo is small but if we need 20 mb libraries for rendering there are some cases where this can kill its usage. > > Stef > > Le 19/10/16 Ã 18:06, Aliaksei Syrel a Ã©crit : >> Hi >> >> I am happy to announce the release of Sparta v1.1 for Pharo 6. >> https://github.com/syrel/Sparta/tree/v1.1 >> >> It can be bootstrapped with the following script: >> >> Metacello new >> >> >> baseline: 'Sparta' >> ; >> >> repository: 'github://syrel/sparta:v1.1/src' >> ; >> >> load: #file:core >> Examples are on class side of: MozExamples, MozTextExamples >> (for linux users: if you use 32bit pharo on 64bit linux, sparta will not work, since 32bit plugin depends on 32bit GTK which conflicts with 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with 64bit vm on mac and linux - it works, but some features fail because FFI is not ready) >> Release of v1.1 is focused on hardware acceleration, windows support and text rendering. >> What is new: >> - Default backends on all platforms changed from software to hardware accelerated. >> - Now also works on Windows! Default backend is Direct2D for drawings and DirectWrite for text. On multi-gpu machines per-app-default setting is respected. In case of Nvidia it can be changed in nvidia control panel. Sparta is x2 faster on discrete gpu than on integrated one. >> - Added initial text support, for instance rendering and high precision measurement. >> - Per-platform settings system is now image based. Allows to enable/disable hardware acceleration, change default backends, change font-mappings tables. >> Some text examples: >> (rendering) >> <Mail Attachment.png> >> (measurement) >> <Mail Attachment.png> >> Cheers, >> Alex -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Oct. 21, 2016

Re: [Pharo-dev] Git versions on CI slaves

by Nicolas Passerini

So what is the path to go? Shall we update the slaves to use the newer version or should we see how to remove that option? BTW, the -C option is in which git command? 2016-10-21 11:20 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > we have a problem with current MonticelloFileTree (and Iceberg) on our CI > slaves because it requires option -C that was introduced in version 1.8.5 > or something like so but our slaves have older Git versions (1.7). > > -- Pavel >

Oct. 21, 2016

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

by 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 <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>>: > >> Denis Kudriashov wrote >>> I look at code and it seems you implemented another one new text model? >>> Why >>> you not use TxText? >> >> Argh. I know it's bad form to complain about gifts, but at the rate we >> reinvent the wheel, I often fear that I will be retired from programming >> before we have a sane text model :/ >> > It has a name and we should fight it: > > https://en.m.wikipedia.org/wiki/Not_invented_here > > Norbert >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com <http://Nabble.com>. >>

Oct. 21, 2016

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

by Tudor Girba

> On Oct 21, 2016, at 4:00 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Denis Kudriashov wrote >> I look at code and it seems you implemented another one new text model? >> Why >> you not use TxText? > > Argh. I know it's bad form to complain about gifts, A bit :). > but at the rate we > reinvent the wheel, I often fear that I will be retired from programming > before we have a sane text model :/ I would kindly ask for patience. What is perhaps less clear is that this editor is in the critical path of the GT project and we are committed to deliver an editor that actually works. We are still investigating different paths, both on the low level (like with Rope) and at the higher level (like how to organize the layout). Alex will follow up with a more technical comparison between the current approach and the one from TxText. Doru > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Oct. 21, 2016

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

by ClÃ©ment Bera

On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi StÃ©phane > > Indeed, build is broken :) > Yesterday I took a very brief look at bloc and can confirm that > development version is loadable in Pharo 6 and is completely Sparta based. > (all examples work for me) > > You are right, live environment on embedded systems is great goal to > achieve. Sparta must not prevent pharo from getting there. It is true that > plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it > is all-in-one build and size can be reduced dramatically. > > As I understand, Pharo for PC should not make any assumptions about user's > hardware. If gpu accelerated backend can not be used there should be still > a performant fallback backend which also needs a fallback that is > guaranteed to work even on Personal Calculators. (Taschenrechner). That is > why library is so big. For example for mac and windows Sparta is shipped > with 3 (!) backends that together build fallback chain, for instance on > windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia > reduces binary size from 15mb to 10mb. Removing GL package and leaving only > software backends may reduce size even more. > > It is a bit different on embedded systems, since hardware configuration is > already known and there is no need to have so many fallback backends. > Library itself allows developers to add new exotic backends quite easily. > > Let's take Pharo6 for mac. It is shipped with the following libs: > Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb > > Moz2D is self contained and does not require any additional libs. > Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? > (estimate around 6-7mb). > > As you can see we get almost the same numbers :) > Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run Pharo, they're required only if you use them. I compile VMs without such libraires and Pharo works just fine as a development environment and for simple things like web servers. The Squeak VM for example have around 2Mb footprint in total, including 1Mb for the C runtime (initialized and uninitialized data, executable code) and 1 Mb for the machine code zone and can run most Pharo features just fine, including for examples web services and the IDE. Right now the VM cannot start completely headless, the headless mode just hides the main window, so if the main window start-up depends on Sparta, it's not possible to run Pharo headless without many Mb of memory footprint. Which leads the first question... *>>* Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? By asking this question, I imply, if there is no Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it run UI applications ? The last problem is that Pharo can currently run UI application like the IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. can be run either headless on a 2Mb memory footprint VM or with a UI on a 7Mb+ memory footprint VM. It means now people doing UI would need extra memory, for example, in the case of android deployment where the android app includes the VM and the image, the app memory consumption at runtime would be at least 5Mb bigger. *>> *Is the community ok with this or will we need to maintain both the Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on smaller VMs ? > Cheers > Alex > > On Oct 19, 2016 22:16, "stepharo" <stepharo(a)free.fr> wrote: > >> Hi Aliaksei >> >> It looks gorgeous. >> I tried to launch the Bloc image from the CI and it crashes during >> startup on my mac. I reported that to Glenn and Alain but so far I simply >> cannot see Bloc code. Is it working for you? I mean is it me that is using >> the wrong VM. >> >> Then I have a question: >> >> - do you think that we can have a fallback in terms of back end for >> the case where we could like to run Pharo on coffee machines but get a live >> environment on such machines? This is related to the discussions we got >> this summer about the memory footprint that Moz2D will put on us. >> >> I do not mean that we must have one but I think that this is important to >> check because we can say that Pharo is small but if we need 20 mb libraries >> for rendering there are some cases where this can kill its usage. >> >> Stef >> Le 19/10/16 Ã 18:06, Aliaksei Syrel a Ã©crit : >> >> Hi >> >> I am happy to announce the release of Sparta v1.1 for Pharo 6. >> https://github.com/syrel/Sparta/tree/v1.1 >> >> It can be bootstrapped with the following script: >> >> Metacello new >> baseline: 'Sparta'; >> repository: 'github://syrel/sparta:v1.1/src'; >> load: #file:core >> >> Examples are on class side of: MozExamples, MozTextExamples >> (*for linux users:* if you use 32bit pharo on 64bit linux, sparta will >> not work, since 32bit plugin depends on 32bit GTK which conflicts with >> 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with >> 64bit vm on mac and linux - it works, but some features fail because FFI is >> not ready) >> Release of v1.1 is focused on hardware acceleration, windows support and >> text rendering. >> *What is new:* >> - Default backends on all platforms changed from software to hardware >> accelerated. >> - Now also works on Windows! Default backend is Direct2D for drawings >> and DirectWrite for text. On multi-gpu machines per-app-default setting >> is respected. In case of Nvidia it can be changed in nvidia control panel. >> Sparta is x2 faster on discrete gpu than on integrated one. >> - Added initial text support, for instance rendering and high precision >> measurement. >> - Per-platform settings system is now image based. Allows to >> enable/disable hardware acceleration, change default backends, change >> font-mappings tables. >> Some text examples: >> (rendering) >> [image: Inline images 2] >> (measurement) >> [image: Inline images 1] >> Cheers, >> Alex >> >>

Oct. 21, 2016

Git versions on CI slaves

by Pavel Krivanek

Hi, we have a problem with current MonticelloFileTree (and Iceberg) on our CI slaves because it requires option -C that was introduced in version 1.8.5 or something like so but our slaves have older Git versions (1.7). -- Pavel

Oct. 21, 2016

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

by 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

Oct. 21, 2016

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

by 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

Oct. 21, 2016

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

by Norbert Hartl

> Am 21.10.2016 um 04:00 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > Denis Kudriashov wrote >> I look at code and it seems you implemented another one new text model? >> Why >> you not use TxText? > > Argh. I know it's bad form to complain about gifts, but at the rate we > reinvent the wheel, I often fear that I will be retired from programming > before we have a sane text model :/ > It has a name and we should fight it: https://en.m.wikipedia.org/wiki/Not_invented_here Norbert > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-Sparta-v1-1-tp4919394p4919570.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 21, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60266 Home: https://github.com/pharo-project/pharo-core

Oct. 21, 2016