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

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

by 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" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> 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 <stepharo(a)free.fr > <mailto:stepharo@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 > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> > wrote: > > 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel > <alex.syrel(a)gmail.com <mailto:alex.syrel@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 <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Some battles are better lost than fought." > > > > > > > >

Oct. 23, 2016

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

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

Oct. 23, 2016

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

by Tudor Girba

Hi, > On Oct 23, 2016, at 12:18 PM, stepharo <stepharo(a)free.fr> 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 <stepharo(a)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 <dionisiydk(a)gmail.com> wrote: >>>> >>>> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)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." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."

Oct. 23, 2016

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

by philippe.back＠highoctane.be

What has VTermOutputDriver to do with FilePolicy? Le 23 oct. 2016 12:22, "stepharo" <stepharo(a)free.fr> 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, phil(a)highoctane.be a Ã©crit : > > Where? > > On Sun, Oct 23, 2016 at 10:42 AM, stepharo <stepharo(a)free.fr> 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 >> >> > >

Oct. 23, 2016

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

by Denis Kudriashov

Hi Aliaksei. 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > 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?

Oct. 23, 2016

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

by philippe.back＠highoctane.be

Is there no way Igor can finish this up? Phil Le 23 oct. 2016 12:19, "stepharo" <stepharo(a)free.fr> 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 <stepharo(a)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 <dionisiydk(a)gmail.com> >>>> wrote: >>>> >>>> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)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." >> >> >> >> >> >> >> > >

Oct. 23, 2016

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

by 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, phil(a)highoctane.be a Ã©crit : > Where? > > On Sun, Oct 23, 2016 at 10:42 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> 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 > >

Oct. 23, 2016

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

by 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 <stepharo(a)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 <dionisiydk(a)gmail.com> wrote: >>> >>> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)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." > > > > > >

Oct. 23, 2016

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

by 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-wi… > > > On 22 Oct 2016, at 23:13, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 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 >

Oct. 23, 2016

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

by phil＠highoctane.be

Where? On Sun, Oct 23, 2016 at 10:42 AM, stepharo <stepharo(a)free.fr> 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 > >

Oct. 23, 2016