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

[Sean P. DeNigris]

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

Argh. I know it's bad form to complain about gifts, but at the rate we
reinvent the wheel, I often fear that I will be retired from programming
before we have a sane text model :/



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

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

[Aliaksei Syrel]

Hi Denis

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

Cheers,
Alex

On 20 October 2016 at 22:17, Denis Kudriashov  wrote:

>
> 2016-10-20 1:15 GMT+02:00 Glenn Cavarlé :
>
>> Good job Alex!
>> Yes, the development version of Bloc is already based on Sparta.
>> The stable version 0.10.1 is the last version with Athens support.
>>
>
> What the repository for Bloc?
>

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

[Denis Kudriashov]

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

> Good job Alex!
> Yes, the development version of Bloc is already based on Sparta.
> The stable version 0.10.1 is the last version with Athens support.
>

What the repository for Bloc?

Re: [Pharo-dev] [Moose-dev] new themoosebook.org - work in progress

[Alexandre Bergel]

Impressive

Alexandre


> On Oct 20, 2016, at 3:46 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> I am working on a new The Moose Book. You can see the current draft here:
> http://themoosebook.org
> 
> In the current form, it covers about 40% of what I want to have at the end. 
> My target is to get a first complete version ready until Spring 2017. The 
> book targets Moose 6.1, although most parts will work with Moose 6.0.
> 
> The book is written in Pillar. A secondary goal for this book is to build a 
> book editor with tools in Pharo. The current book was generated directly from 
> Pharo without using the command line. The current code is in book GitHub 
> repository, but the end goal is to have these tools working separately from 
> the book.
> 
> Please let me know what you think.
> 
> The book repo is here:
> https://github.com/girba/themoosebook
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Every thing has its own flow."
> 
> 
> 
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

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

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: ae8113132bc2dbe240e6b4e1bff1cb64a9c88d01
  
https://github.com/pharo-project/pharo-core/commit/ae8113132bc2dbe240e6b4e1bff1cb64a9c88d01
  Author: Jenkins Build Server 
  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

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[Denis Kudriashov]

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

> As I understand, Pharo for PC should not make any assumptions about user's
> hardware. If gpu accelerated backend can not be used there should be still
> a performant fallback backend which also needs a fallback that is
> guaranteed to work even on Personal Calculators. (Taschenrechner). That is
> why library is so big. For example for mac and windows Sparta is shipped
> with 3 (!) backends that together build fallback chain, for instance on
> windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia
> reduces binary size from 15mb to 10mb. Removing GL package and leaving only
> software backends may reduce size even more.
>
> It is a bit different on embedded systems, since hardware configuration is
> already known and there is no need to have so many fallback backends.
> Library itself allows developers to add new exotic backends quite easily.
>
> Let's take Pharo6 for mac. It is shipped with the following libs:
> Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb
>
> Moz2D is self contained and does not require any additional libs.
> Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ?
> (estimate around 6-7mb).
>

Also imaging that we will remove Cairo, Athens, Fonts from image, font
plugin from VM. Also Morphic and old Canvas. I expect Morphic is much
bigger then Bloc. And at some point bitblt stuff from image and VM.
I am sure at the end new clean solutions will provide much lesser image and
VM size.

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

[Denis Kudriashov]

Hi Aliaksei

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

> Was tough decision :) We decided (in GT) that next moldable tool should be
> a "Moldable Text Editor for Pharo". Here are some requirement that must be
> full-filled by text editor:
>

Could you explain what is wrong with TxText model to achieve this? (I
comment bellow each point). And do you have any links to understand what
moldable text editor means?


>   - support of very large files (gigabytes)
>

TxText-Athens implement text morph to show big text models. Maybe the way
how it is designed is not suitable for Sparta and Bloc. Then I will
understand if you will just drop away this code and build Bloc/Sparta
optimized version but on top of same text model.
If you talk about showing *files* it is not enough of course because full
text model needs to be loaded from file which is not scale when file size
is huge.

But TxText model looks very smart to provide lazy logic where text elements
are loaded and built by demand. And it looks much easy to do than with Rope
kind model. TxText is linked list of elements. No problem to build them
lazily.


>   - multithreading (styling, syntax highlighting in background)
>

I am really interesting how it could be done and why Rope model is better
than TxText model from this perspective.

Styling is just editing text by splitting elements and marking them with
specific attributes. How to do it in background when somebody could edit
text in same time?
Rope model or TxText model is complex structure. It is quite difficult to
make it safe for concurrency.


>  => text model has to be immutable
>

So solution is to not modify existing model. For example we could extract
full string from text, build new model and install it into widget. But here
is same problem original copy could be modified by user while new model is
built. What to do then?
I actually made conclusion that background styling is bad idea. (in the way
when we show text to user and only then start styling it)

  - fast access by index (for styling; parser returns Tokens with indices)
>

Ok. Here Rope model works better then TxText. But is it really important
case?
For your styling example it is possible to solve it differently. Imaging if
parser will produce text model itself. So any parse node will not point to
token string but to text element inside text model. And then styler will
just mark them with attributes directly. No index access will be needed.
And such approach could lead to very interesting things. Imaging that
source code is text model where elements are marked by AST-nodes (as
attributes).


>   - optimised for sparta (use all amazing text features provided by Moz2D)
>

I see same kind of text attributes in Sparta text as in TxText. What else
you added to text to cover specific Sparta features and why attributes was
not enough for this?

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

[Norbert Hartl]

Nico,

> Am 13.10.2016 um 14:25 schrieb Nicolas Passerini :
> 
> - 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.
> 
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

[Pharo-dev] new themoosebook.org - work in progress

[Tudor Girba]

Hi,

I am working on a new The Moose Book. You can see the current draft here:
http://themoosebook.org

In the current form, it covers about 40% of what I want to have at the end. My 
target is to get a first complete version ready until Spring 2017. The book 
targets Moose 6.1, although most parts will work with Moose 6.0.

The book is written in Pillar. A secondary goal for this book is to build a 
book editor with tools in Pharo. The current book was generated directly from 
Pharo without using the command line. The current code is in book GitHub 
repository, but the end goal is to have these tools working separately from the 
book.

Please let me know what you think.

The book repo is here:
https://github.com/girba/themoosebook

Cheers,
Doru


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

"Every thing has its own flow."