- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] New release of iceberg

by Nicolas Passerini

Thank you Alex, a fix for that is in the way, but it needs some work yet, I will integrate it as soon as possible. A little clarification yet: we do not have a "three way diff"... or at least I am not aware of and a query in this list a few weeks ago raised no results. So using a 2-way diff there is no way to *really *show new code vs. old code. It will just show the differences between the two versions... in the case that one version is an ancestor of the other one, then the differences could be understood as "new code" vs. "old code" but that will not be allways the case. I will like to have a 3-way diff, but I am not sure that I will have time for that soon enough because we have defined other priorities. In the meantime we are working on making a bit more flexible the current 2-way diff, so that we can decide which side to paint red and which one to paint green. (Yes I could have just swap the versions, but I preferred to have allways "my" code in the left... I think that once we fix the color issue it will be more intuitive.) So the corrected version will work so: - left is allways "my code", right is "their" code. - red is old, green is new. (Another improvement would be to put labels on top of it, but it also needs improving the diff widget. Now we have only one title for the morph, the information is there but is not so clear as I would liket to.) Also we have problems with the highlihgting, because sometimes it is shifted one or two characters. I would like to fix it but... again, it takes time. So, to sum up, the diff needs a lot of work yet. 2016-10-17 11:48 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Diff has inverted colors (Red <-> Green) Almost every time have to stop > and think why new code I just wrote will be removed ;) > > GitHub: (new content is green) > [image: Inline images 1] > > Iceberg: (new content is red, note also that last E character in LINE is > not highlighted, but it should): > [image: Inline images 2] > > Cheers, > Alex > > On 16 October 2016 at 20:28, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> Hi >> >> I use Iceberg to load project in non-interactive mode and this is what I >> get with latest stable: >> >> RETRY->BaselineOfIceberg An attempt to use interactive tools detected, >> while in non-interactive mode >> >> Is there any reason that prevents Iceberg to be used in non-interactive >> mode, from command line for example? >> >> Cheers, >> Alex >> >> On 15 October 2016 at 13:59, stepharo <stepharo(a)free.fr> wrote: >> >>> + 1 >>> >>> This is on my todo :) >>> >>> >>> Le 13/10/16 Ã 20:37, Tudor Girba a Ã©crit : >>> >>> Hi Nicolas, >>>> >>>> Great work! >>>> >>>> I will test it again. I kindly ask everyone else to follow the call and >>>> test this release. Ideally, create a repository on GitHub and play with it. >>>> >>>> It is important to get this piece as stable as possible to make Git >>>> part of the default Pharo experience. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Oct 13, 2016, at 2:25 PM, Nicolas Passerini <npasserini(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hi, we are releasing a new version of Iceberg, with several new >>>>> features and bugfixes. I would't yet say that is 100% production ready, but >>>>> it is close, so I want to invite you to test it and provide feedback. >>>>> >>>>> You can install it by doing: >>>>> >>>>> Metacello new >>>>> baseline: 'Iceberg'; >>>>> repository: 'github://npasserini/iceberg'; >>>>> load. >>>>> >>>>> More installation instructions and documentation can be found at >>>>> https://github.com/npasserini/iceberg. >>>>> >>>>> Some of the new features in this version are: >>>>> - Allow to commit several packages together in the same commit. >>>>> - Show diffs for incoming and outgoing commits (i.e. before push/pull >>>>> you can browse the difference between the remote and the local versions). >>>>> - New History view allows to see any commit in any branch and compare >>>>> it to the current loaded version. >>>>> - Better support for interacting code loaded outside Iceberg >>>>> (smaltalkhub, filetree, gitfiletree, etc). >>>>> - From the diff view, revert changes or browse them (i.e. open a >>>>> Nautilus on the changed class/method). >>>>> - Automatically update presentations on code / repository changes. >>>>> - Integration with Metacello, i.e. after installing Iceberg you do >>>>> something like >>>>> >>>>> Metacello new >>>>> >>>>> baseline: 'TaskIt' >>>>> ; >>>>> repository: 'github://sbragagnolo/taskit' >>>>> ; >>>>> load. >>>>> >>>>> >>>>> (By default) it will be loaded using iceberg (there is a setting to >>>>> avoid it if you prefer traditional behavior. >>>>> >>>>> - Improved handling of git errors. >>>>> - Improved performance for several operations. >>>>> - Improved documentation. >>>>> - ... and several bug fixes and other minor improvements (please look >>>>> at https://github.com/npasserini/iceberg/milestone/7?closed=1 for >>>>> more details). >>>>> >>>>> >>>>> Please do not hesitate to contact me if you have any doubts. >>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>>> >>>> >>>> >>> >>> >> >

Oct. 20, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by Norbert Hartl

I would be interested how (or if) people use iceberg. I think it is an important tool for us so a lot of people should try. What makes me wonder is the fact that I usually need around 2-3 clicks until I get a debugger from iceberg. How are other people using it? - I cloned a repository myself and packages existed before hooking up iceberg. On "synchronize repositoryâ¦" I get a DNA IceForeignVersion>>#snapshot - I clone a remote repository and get - after that I can close and open iceberg and get the red square. No cure so far - I created the directory and tried again. Then I get So what is _the_ use case for iceberg that works? thanks, Norbert > Am 13.10.2016 um 14:25 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > Hi, we are releasing a new version of Iceberg, with several new features and bugfixes. I would't yet say that is 100% production ready, but it is close, so I want to invite you to test it and provide feedback. > > You can install it by doing: > > Metacello new > baseline: 'Iceberg'; > repository: 'github://npasserini/iceberg'; > load. > > More installation instructions and documentation can be found at https://github.com/npasserini/iceberg <https://github.com/npasserini/iceberg>. > > Some of the new features in this version are: > - Allow to commit several packages together in the same commit. > - Show diffs for incoming and outgoing commits (i.e. before push/pull you can browse the difference between the remote and the local versions). > - New History view allows to see any commit in any branch and compare it to the current loaded version. > - Better support for interacting code loaded outside Iceberg (smaltalkhub, filetree, gitfiletree, etc). > - From the diff view, revert changes or browse them (i.e. open a Nautilus on the changed class/method). > - Automatically update presentations on code / repository changes. > - Integration with Metacello, i.e. after installing Iceberg you do something like > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit'; > load. > > (By default) it will be loaded using iceberg (there is a setting to avoid it if you prefer traditional behavior. > > - Improved handling of git errors. > - Improved performance for several operations. > - Improved documentation. > - ... and several bug fixes and other minor improvements (please look at https://github.com/npasserini/iceberg/milestone/7?closed=1 <https://github.com/npasserini/iceberg/milestone/7?closed=1> for more details). > > > Please do not hesitate to contact me if you have any doubts.

Oct. 20, 2016

[pharo-project/pharo-core]

by GitHub

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

Oct. 20, 2016

[pharo-project/pharo-core] ae8113: 60265

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ae8113132bc2dbe240e6b4e1bff1cb64a9c88d01 https://github.com/pharo-project/pharo-core/commit/ae8113132bc2dbe240e6b4e1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-10-20 (Thu, 20 Oct 2016) Changed paths: R Morphic-Widgets-Pluggable.package/PluggableTextEditorMorph.class/README.md R Morphic-Widgets-Pluggable.package/PluggableTextEditorMorph.class/class/as yet unclassified/stylingClass.st R Morphic-Widgets-Pluggable.package/PluggableTextEditorMorph.class/definition.st R Morphic-Widgets-Pluggable.package/PluggableTextEditorMorph.class/instance/as yet unclassified/textMorphClass.st R Polymorph-Widgets.package/TEasilyThemed.class/instance/controls/newAutoAcceptTextEditorFor_getText_setText_getEnabled_.st R Polymorph-Widgets.package/TEasilyThemed.class/instance/controls/newBasicTextEditorFor_getText_setText_.st R Polymorph-Widgets.package/TEasilyThemed.class/instance/controls/newBasicTextEditorFor_getText_setText_getEnabled_.st R Polymorph-Widgets.package/TEasilyThemed.class/instance/controls/newBasicTextEditorFor_getText_setText_getEnabled_menu_.st R Polymorph-Widgets.package/UITheme.class/instance/morph creation/newAutoAcceptTextEditorIn_for_getText_setText_getEnabled_.st R Polymorph-Widgets.package/UITheme.class/instance/morph creation/newBasicTextEditorIn_for_getText_setText_getEnabled_menu_.st R Rubric.package/RubFindReplaceService.class/instance/as yet unclassified/initialize.st A Rubric.package/RubFindReplaceService.class/instance/initialization/initialize.st A Rubric.package/RubFindReplaceService.class/instance/private/findAndSelect.st A Rubric.package/RubFindReplaceService.class/instance/private/findAndSelectRegex.st A Rubric.package/RubFindReplaceService.class/instance/private/setStartIndex.st M Rubric.package/RubFindReplaceService.class/instance/services/find.st M Rubric.package/RubFloatingEditorBuilder.class/instance/private/buildEditor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60264.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60265.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60264.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60265.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60265 19220 MNU in Find and Replace on accepting empty input https://pharo.fogbugz.com/f/cases/19220 17194 users of PluggableTextEditorMorph should use Rubric https://pharo.fogbugz.com/f/cases/17194 18904 Opened Find And Replace dialog from fasttables search is uncloseable https://pharo.fogbugz.com/f/cases/18904 http://files.pharo.org/image/60/60265.zip

Oct. 20, 2016

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

by Denis Kudriashov

2016-10-20 9:07 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > As I understand, Pharo for PC should not make any assumptions about user's > hardware. If gpu accelerated backend can not be used there should be still > a performant fallback backend which also needs a fallback that is > guaranteed to work even on Personal Calculators. (Taschenrechner). That is > why library is so big. For example for mac and windows Sparta is shipped > with 3 (!) backends that together build fallback chain, for instance on > windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia > reduces binary size from 15mb to 10mb. Removing GL package and leaving only > software backends may reduce size even more. > > It is a bit different on embedded systems, since hardware configuration is > already known and there is no need to have so many fallback backends. > Library itself allows developers to add new exotic backends quite easily. > > Let's take Pharo6 for mac. It is shipped with the following libs: > Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb > > Moz2D is self contained and does not require any additional libs. > Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? > (estimate around 6-7mb). > Also imaging that we will remove Cairo, Athens, Fonts from image, font plugin from VM. Also Morphic and old Canvas. I expect Morphic is much bigger then Bloc. And at some point bitblt stuff from image and VM. I am sure at the end new clean solutions will provide much lesser image and VM size.

Oct. 20, 2016

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

by Denis Kudriashov

I also wondering about Sparta approach for text layout/rendering. You implemented old text morph idea: layout text while render it. Why you choose it? With such approach all computed information about text layout is lost when text is rendered. You can't reuse it for text navigation/editing. And anytime redraw is needed all these objects will be recreated again. Many garbage for any redraw. And many garbage for text navigation, for any cursor movement. Am I wrong about it? 2016-10-20 9:16 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi Denis > > I look at code and it seems you implemented another one new text model? >> Why you not use TxText? > > > Was tough decision :) We decided (in GT) that next moldable tool should be > a "Moldable Text Editor for Pharo". Here are some requirement that must be > full-filled by text editor: > - support of very large files (gigabytes) > - multithreading (styling, syntax highlighting in background) > => text model has to be immutable > - fast access by index (for styling; parser returns Tokens with indices) > - optimised for sparta (use all amazing text features provided by Moz2D) > > Cheers, > Alex > > On 20 October 2016 at 09:07, Aliaksei Syrel <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 :) >> >> 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. 20, 2016

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

by Denis Kudriashov

Hi Aliaksei 2016-10-20 9:16 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Was tough decision :) We decided (in GT) that next moldable tool should be > a "Moldable Text Editor for Pharo". Here are some requirement that must be > full-filled by text editor: > Could you explain what is wrong with TxText model to achieve this? (I comment bellow each point). And do you have any links to understand what moldable text editor means? > - support of very large files (gigabytes) > TxText-Athens implement text morph to show big text models. Maybe the way how it is designed is not suitable for Sparta and Bloc. Then I will understand if you will just drop away this code and build Bloc/Sparta optimized version but on top of same text model. If you talk about showing *files* it is not enough of course because full text model needs to be loaded from file which is not scale when file size is huge. But TxText model looks very smart to provide lazy logic where text elements are loaded and built by demand. And it looks much easy to do than with Rope kind model. TxText is linked list of elements. No problem to build them lazily. > - multithreading (styling, syntax highlighting in background) > I am really interesting how it could be done and why Rope model is better than TxText model from this perspective. Styling is just editing text by splitting elements and marking them with specific attributes. How to do it in background when somebody could edit text in same time? Rope model or TxText model is complex structure. It is quite difficult to make it safe for concurrency. > => text model has to be immutable > So solution is to not modify existing model. For example we could extract full string from text, build new model and install it into widget. But here is same problem original copy could be modified by user while new model is built. What to do then? I actually made conclusion that background styling is bad idea. (in the way when we show text to user and only then start styling it) - fast access by index (for styling; parser returns Tokens with indices) > Ok. Here Rope model works better then TxText. But is it really important case? For your styling example it is possible to solve it differently. Imaging if parser will produce text model itself. So any parse node will not point to token string but to text element inside text model. And then styler will just mark them with attributes directly. No index access will be needed. And such approach could lead to very interesting things. Imaging that source code is text model where elements are marked by AST-nodes (as attributes). > - optimised for sparta (use all amazing text features provided by Moz2D) > I see same kind of text attributes in Sparta text as in TxText. What else you added to text to cover specific Sparta features and why attributes was not enough for this?

Oct. 20, 2016

Re: [Pharo-dev] [ANN] New release of iceberg

by Norbert Hartl

Nico, > Am 13.10.2016 um 14:25 schrieb Nicolas Passerini <npasserini(a)gmail.com>: > > - Integration with Metacello, i.e. after installing Iceberg you do something like > > Metacello new > baseline: 'TaskIt'; > repository: 'github://sbragagnolo/taskit' <github://sbragagnolo/taskit'>; > load. > > (By default) it will be loaded using iceberg (there is a setting to avoid it if you prefer traditional behavior. > should that work for other repo types as well. I'm trying to load the code from a local directory that has been checked out before. Is it possible it uses iceberg repos when loaded, too? thanks, Norbert

Oct. 20, 2016

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

by Aliaksei Syrel

Hi Denis I look at code and it seems you implemented another one new text model? Why > you not use TxText? Was tough decision :) We decided (in GT) that next moldable tool should be a "Moldable Text Editor for Pharo". Here are some requirement that must be full-filled by text editor: - support of very large files (gigabytes) - multithreading (styling, syntax highlighting in background) => text model has to be immutable - fast access by index (for styling; parser returns Tokens with indices) - optimised for sparta (use all amazing text features provided by Moz2D) Cheers, Alex On 20 October 2016 at 09:07, Aliaksei Syrel <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 :) > > 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. 20, 2016

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

by Aliaksei Syrel

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