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

Re: [Pharo-dev] TxText model

by Nicolai Hess

2016-04-06 18:00 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 6 April 2016 at 18:34, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> >> Am 06.04.2016 5:21 nachm. schrieb "Igor Stasenko" <siguctua(a)gmail.com>: >> > >> > btw, >> > >> > if you wanna feel a difference, why we wanted vector based rendering, >> by yourself, open: >> > >> > Morph comment asText asMorph openInSceneView >> > >> > and then >> > >> > | sceneView view | >> > sceneView := AthensSceneView new. >> > view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. >> > >> > sceneView scene: view. >> > sceneView openInWindow >> > >> > >> > and try zooming it in and out with mouse wheel. >> > >> > >> >> I know it's limitation. My point was, that it is not impossible, or >> depends an the model Text vs. TxModel, alone. >> > Of course it doesn't depends on either of those. But it wasn't an answer > concerning model, but you question why i had to abandon idea to keep using > DisplayScanner & friends. > Sure, but as you talked about limitiations solved by TxText, I thought about limitation for building editor/tools around Text or TxText. I see that you had rendering vector based graphics with TxText and Athens. What I want to see, is a Text-Tool framework for building custom editors or easily add features (code tools or tools for other kinds of text). Rubric comes close, it has some good features for text decorations. Twisty looks promisinig too, I like that it is build on similar classes like TxText but looks more finished. (As it is based on TxText (or a fork) maybe it isn't that difficult to add rendering on athens ?) > > > -- > Best regards, > Igor Stasenko. >

April 6, 2016

Re: [Pharo-dev] TxText model

by Sean P. DeNigris

> What are the main problems with Text, Paragraph, ... and other old > TextComponents? > And how are these solved with TxText? > Stephan Eggermont wrote >> |t1 t2 ball page| >> page := Morph new. >> ... Yes, this example brackets the situation quite nicely. The current text system "makes hard things easy, and the easy things impossible". Text winding around little Morphic tubes, while the coolest thing ever, is rarely useful, but try changing the caret and you will end up in hell: [rant]I find the whole text system very confusing. What the heck does a paragraph know about insertion points?? A view has one paragraph object, even if there are several paragraphs (as understood by the rest of humanity as a block of text with breaks between the adjoining ones. Editors and Paragraphs are thrown out and replaced on a whim. I'm finding it very hard to understand and modify[/rant] [1] [rant] Of course, the instant I touched Paragraph/XxxEditor, and friends I got lost down the rabbit hole of incomprehensibility... like Paragraph, which draws the cursor and keeps track of the selection, obviously... not! wtf ?! Quick definition... paragraph |ËparÉËgraf| noun a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering. Where, tell me, does it say anything about cursors and selections?? [/rant] [2] 1. http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tt46402… 2. http://forum.world.st/Re-Vim-Keys-tt4657381.html#a4657594 ----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888748.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 6, 2016

Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place

by Ben Coman

On Wed, Apr 6, 2016 at 4:36 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > That explains, why, there initially certain features of Cairo, that not > exposed by Athens. > It is not because we can't or just don't care.. we do.. But only after we > can see that it consistent with rest of API and can be easily implemented on > most of other potential backends. > Yes, i am talking about that damn 'minimal common denominator' problem. :) > > Oh, and also i forgot to mention, that there could be also 2 more potential > backends: > - OpenVG > and > - Quartz, that is a vector graphics library for Mac OS and Vulkan? and thanks for writing up that explanation on Athens. cheers -ben

April 6, 2016

Re: [Pharo-dev] TxText model

by phil＠highoctane.be

Ok. Call me stupid but in Pharo I don't see how to do that easily. Phil On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 06-04-16 11:13, phil(a)highoctane.be wrote: > >> Another pain is the styling of text where the only styler we have is the >> SHSt80Styler (class name out of my mind, need to check) and that's a huge >> pain to support other stylings. >> > > Styling with different stylers worked in TextMorph. In Squeak it is easy > to add styling for a different language in the class browser. Levente did > that for PostgreSQLv3. > > Stephan > > >

April 6, 2016

Re: [Pharo-dev] TxText model

by Igor Stasenko

On 6 April 2016 at 18:34, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Am 06.04.2016 5:21 nachm. schrieb "Igor Stasenko" <siguctua(a)gmail.com>: > > > > btw, > > > > if you wanna feel a difference, why we wanted vector based rendering, by > yourself, open: > > > > Morph comment asText asMorph openInSceneView > > > > and then > > > > | sceneView view | > > sceneView := AthensSceneView new. > > view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. > > > > sceneView scene: view. > > sceneView openInWindow > > > > > > and try zooming it in and out with mouse wheel. > > > > > > I know it's limitation. My point was, that it is not impossible, or > depends an the model Text vs. TxModel, alone. > Of course it doesn't depends on either of those. But it wasn't an answer concerning model, but you question why i had to abandon idea to keep using DisplayScanner & friends. -- Best regards, Igor Stasenko.

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Henrik Sperre Johansen

Not really about modifying during iteration, if an object you try to remove: is in the wrong slot, you'll most likely get a CannotBeFound error. Which you can work around by iterating indexes and nilling directly, doing so in reverse merely minimizes the amount of work needed to potentially fill the slot when it is still empty after re-adding. (Maintain index of next nil slot as well, test backwards from that, and you should get away with the minimal amount of work required... Just need to ensure it's still nil, and not the slot removed object was put in) Needless to say, it'd probably end up pretty hairy, and still have worse worse-case perf* than rehash, though average-case would probably be much better. Cheers, Henry * worst-case performance in linearly hashed tables is *much* worse for remove than add, due to the potential fixups needed when the set is dense... Consider at:ifAbsent: perf experienced for missing entries in default sized Unicode tables with hash at start of longest non-nil sequence of slots, and multiply by 100 > On 6. apr. 2016, at 21.07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Yeah, I just realised that iterating and changing a dictionary or set at the same time won't work ;-) > >> On 06 Apr 2016, at 16:01, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> If you are iterating over a Set with incorrectly placed objects, remove: calls aren't going to do you much good ;) >> Not to mention, even nilling the slot directly, then add:'ing, still means you have to scan subsequent entries up to the next empty slot for potentially better placement, if the object ended up being added elsewhere. >> (IOW, if you're gonna do it, better iterate in reverse) >> >> Cheers, >> Henry >> >>> On 06 Apr 2016, at 3:46 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 06 Apr 2016, at 15:34, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-04-06 15:25 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> Hi Nicolai, >>>> >>>>> On 06 Apr 2016, at 14:56, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> 2016-04-06 14:27 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> Fix for review: >>>>> >>>>> === >>>>> Name: STON-Core-SvenVanCaekenberghe.71 >>>>> Author: SvenVanCaekenberghe >>>>> Time: 6 April 2016, 2:22:24.782251 pm >>>>> UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24 >>>>> Ancestors: STON-Core-SvenVanCaekenberghe.70 >>>>> >>>>> Fix a bug where STONReferences occurring as keys in Dictionaries or elements in Sets caused those to be unhealthy after materialization. Thx to Peter UhnÃ¡k for reporting this issue. >>>>> >>>>> Add 3 new unit tests to STONReaderTests >>>>> >>>>> #testDictionaryWithReferenceKeys >>>>> #testSetWithReferenceElements >>>>> #testDeepStructure >>>>> >>>>> Fix Details >>>>> >>>>> change the implementation of STONReader>>#processSubObjectsOf: from iterative to recursive (see version 39 of 29 November 2012, this might be a functional regression, see #testDeepStructure; cleanup of stack instance variable for later) so that #stonProcessSubObjects: can be overwritten with code being executed before or after full reference resolution >>>>> >>>>> imho, recursion stack depth will be equal during both writing and reading, and should be acceptable. >>>>> >>>>> overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the end, but only when needed (minimal optimalization, see Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) >>>>> === >>>>> Name: STON-Tests-SvenVanCaekenberghe.63 >>>>> Author: SvenVanCaekenberghe >>>>> Time: 6 April 2016, 2:22:45.01986 pm >>>>> UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a >>>>> Ancestors: STON-Tests-SvenVanCaekenberghe.62 >>>>> >>>>> (idem) >>>>> === >>>> >>>> Thanks for looking at the code. >>>> >>>>> Hi Sven, >>>>> instead of rehashing the dictionary for every ston reference, >>>> >>>> (It rehashes only once after resolving all references) >>>> >>>> Ah, of course. I thought this would be called for every ston reference used as key. >>>> >>>> >>>> >>>>> wouldn't it work to remove and readd the value after processing the subobject: >>>>> >>>>> Dictionary>>#stonProcessSubObjects: block >>>>> self keys do:[:key | >>>>> |value| >>>>> value := block value:(self removeKey: key ifAbsent:[ nil]). >>>>> self at: (block value: key) put: value]. >>>> >>>> Interesting idea. I have to think about that approach. >>>> >>>> Now, Object>>#stonProcessSubObjects: is very general and looks at named and indexed instance variables. But this probably could be replaced by something more high level and specific I guess. >>>> >>>> Adding and removing each key/value has a cost too. I try to make the simplest case very efficient and only pay a price when really needed. Anyway, time for some calculations. >>>> >>>> ok, yes running over all keys isn't better than rehashing :-) >>> >>> Still, your idea might be better than you would expect: >>> >>> Now, there is 1 (partial) iteration to do the check before, 2 iterations over the keys and values arrays, then an optional full rehash (which also reallocates and thus generates garbage). >>> >>> Your idea does only 1 iteration over keys, with remove and add (which also happens more efficiently on the arrays above), no check before, no rehash, probably no garbage generation at all in any case. >>> >>> Like I said, I have to study it (especially the cost of remove/add, maybe that can be optimised a bit as well). >>> >>>> Thanks again for the suggestion ! >>>> >>>> Sven >>>> >>>>>> On 06 Apr 2016, at 14:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Diction… >>>>>> >>>>>> fix coming >>>>>> >>>>>>>> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>>>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: >>>>>>>>> >>>>>>>>> Like I said, it is a hashing issue, sometimes it will be correct by accident. >>>>>>>>> >>>>>>>>> I hope you did not have to much trouble with this bug, I guess it must have been hard to chase. >>>>>>>>> >>>>>>>>> Is it urgent ? >>>>>>>>> >>>>>>>>> I probably can give you a quick fix, but I would like to think a bit more about this, since rehashing each materialised dictionary seems expensive. >>>>>>>> >>>>>>>> Hi Sven, >>>>>>>> >>>>>>>> I got the same kind of problem in a personal application. >>>>>>>> >>>>>>>> I use Sets that I serialize and I had a lot of trouble because sometimes >>>>>>>> some action had strange behaviours. >>>>>>>> >>>>>>>> For example in a set with element `aSet remove: aSet anyOne` raised 'XXX >>>>>>>> not found in aSet'. >>>>>>>> >>>>>>>> I am glad to hear that it is a Ston issue and not me that used sets in a >>>>>>>> bad way :) >>>>>>>> >>>>>>>> For me too it is not urgent since I have a not of university work for >>>>>>>> the moment. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> How are hashed collections created/filled during ston-parsing ? >>>>>>>> If the position in a hashed collection is created by a ston-reference, that is later replaced by the "real" object, >>>>>>>> the index in the dictionary (or other hashed collections) may be wrong. >>>>>>> >>>>>>> Yes, that is indeed it, Nicolai. >>>>>>> >>>>>>> But I would like to try to minimise the rehashing as it seems expensive. But first I need a more reliable failure. >>>>>>> >>>>>>>> -- >>>>>>>> Cyril Ferlicot >>>>>>>> >>>>>>>> http://www.synectique.eu >>>>>>>> >>>>>>>> 165 Avenue Bretagne >>>>>>>> Lille 59000 France > >

April 6, 2016

Re: [Pharo-dev] TxText model

by Stephan Eggermont

On 06-04-16 11:13, phil(a)highoctane.be wrote: > Another pain is the styling of text where the only styler we have is > the SHSt80Styler (class name out of my mind, need to check) and that's > a huge pain to support other stylings. Styling with different stylers worked in TextMorph. In Squeak it is easy to add styling for a different language in the class browser. Levente did that for PostgreSQLv3. Stephan

April 6, 2016

Re: [Pharo-dev] TxText model

by Torsten Bergmann

April 6, 2016

Re: [Pharo-dev] TxText model

by Nicolai Hess

Am 06.04.2016 5:21 nachm. schrieb "Igor Stasenko" <siguctua(a)gmail.com>: > > btw, > > if you wanna feel a difference, why we wanted vector based rendering, by yourself, open: > > Morph comment asText asMorph openInSceneView > > and then > > | sceneView view | > sceneView := AthensSceneView new. > view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. > > sceneView scene: view. > sceneView openInWindow > > > and try zooming it in and out with mouse wheel. > > I know it's limitation. My point was, that it is not impossible, or depends an the model Text vs. TxModel, alone. > > On 6 April 2016 at 17:58, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>> >>>> >>>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> Thanks Igor. >>>>> Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing). >>>>> >>>>>> >>>>>> 1. No support for vector graphics >>>>> >>>>> >>>>> I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment >>>>> rendering a TextMorph in Athens works: >>>>> Morph comment asText asMorph openInSceneView >>>> >>>> >>>> Sorry, missed to reply to that important point. >>>> It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form >>>> on Athens surface. >>> >>> >>> Nah, actually it works a bit different. Many (Form)Canvas methods are reimplemented on Athens API. But yes, I used some hacks as well. >>> >> >> >> Didn't knew. >> Aha.. i see AthensCanvasWrapper. >> Ohh.. that's so much pain :) >> >> >>>> >>>> So, that is why it 'works' :) >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > > -- > Best regards, > Igor Stasenko.

April 6, 2016

Re: [Pharo-dev] TxText model

by Igor Stasenko

btw, if you wanna feel a difference, why we wanted vector based rendering, by yourself, open: Morph comment asText asMorph openInSceneView and then | sceneView view | sceneView := AthensSceneView new. view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. sceneView scene: view. sceneView openInWindow and try zooming it in and out with mouse wheel. On 6 April 2016 at 17:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> >> >> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >> >>> >>> >>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>>> >>>> >>>> Thanks Igor. >>>> Maybe some more Info? (I don't have much experience with this and don't >>>> fully understand what is missing). >>>> >>>> >>>>> 1. No support for vector graphics >>>>> >>>> >>>> I know some parts of Athens (with Cairo font renderer and how it is >>>> used in TxText) but at the moment >>>> rendering a TextMorph in Athens works: >>>> Morph comment asText asMorph openInSceneView >>>> >>> >>> Sorry, missed to reply to that important point. >>> It works because one good soul spent effort and helped me to finish >>> implementation of a wrapper for Morph, to be able to render any morph into >>> Form, and then render Form >>> on Athens surface. >>> >> >> Nah, actually it works a bit different. Many (Form)Canvas methods are >> reimplemented on Athens API. But yes, I used some hacks as well. >> >> > > Didn't knew. > Aha.. i see AthensCanvasWrapper. > Ohh.. that's so much pain :) > > > >> So, that is why it 'works' :) >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

April 6, 2016