- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Opal Decompiler status

by Marcus Denker

On Apr 27, 2013, at 5:59 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote:. > >> Could we have a primer on what remains to do on the Opal front? >> > > > -> debug BC-IR->AST->text mapping more (lots of it working already) > -> debug temp variable lookup in optimized blocks in the debugger (almost there, too) > -> Go through all the test for the old Compiler and port them to the new. > -> Better compiler API and refactor the whole system to use it > (but keep a backward compatible API at least to some extend) All the TODOs are in the bug tracker, Project "Compiler (Opal)". There are right now 29 Issues. Marcus

April 27, 2013

Re: [Pharo-project] Opal Decompiler status

by Marcus Denker

On Apr 27, 2013, at 5:26 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I see that the OCFakeDecompiler which uses the old and horrible (*) Decompiler is still in use. > Though, IRBytecodeDecompiler seems already quite advanced. The idea actually is to not have a decompiler BC->AST. We have one BC->IR for manipulating things on the byte code level (e.g. he new class builder will use it). BC->IR->BC is working and tested after every commit. But on the AST level, idea is to have a higher level representation of code always available. (compressed ASTs in the long term, compressed source as the intermediate solution). Yes, I know that people will be highly skeptical about this. Up to the point that I even don't expect to convince anyone other than by actually showing a working versionâ¦ This goes hand-in-hand with the "one file" image: just one .pharo image, no .sources, no .changes. (Which real conservative people will not like, either). We need to see how fast this progresses, if we see that it will not be ready for 3.0, we should add a IR->AST decompiler, but I hope the alternative will show that it is not necessary. > Could we have a primer on what remains to do on the Opal front? > -> debug BC-IR->AST->text mapping more (lots of it working already) -> debug temp variable lookup in optimized blocks in the debugger (almost there, too) -> Go through all the test for the old Compiler and port them to the new. -> Better compiler API and refactor the whole system to use it (but keep a backward compatible API at least to some extend) Marcus

April 27, 2013

[Pharo-project] Opal Decompiler status

by Nicolas Cellier

I see that the OCFakeDecompiler which uses the old and horrible (*) Decompiler is still in use. Though, IRBytecodeDecompiler seems already quite advanced. Could we have a primer on what remains to do on the Opal front? (*) just look number of inst vars, count how many times their state change, and measure average method length for an approximate definition of horrible

April 27, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by Sean P. DeNigris

Sean P. DeNigris wrote > You're my new best friend :) The cursor is an actual Morph (TxCursorMorph) instead of magic conjured up my Paragraph!!! All my other friends are fired, they've never given me a present this nice :) Also, please add me to the repo. I have a small fix (TxCursorMorph should show cursorColor instead of defaultColor) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683990.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by Denis Kudriashov

I should say it is not difficult to do with current design. I were think about it and current layout building logic requires little changes, maybe just one spesific method. But there is cases where any text change required rebuilding full layout. Fo example, single line text with wrapping mode. 2013/4/27, Igor Stasenko <siguctua(a)gmail.com>: > Very impressive progress, Denis! :) > > I going to finish low-level stuff in Athens (path approximation / > point location) > and then go straight to text rendering with existing Text. > Next stage will be to take TxText model and provide rendering for it > with Athens, > as well as review the code. > > About text editing and re-layout. > It should be possible that any local update (which affecting only > single character span or multiple adjusted character spans will > require only local recalculations of text layout). Otherwise there is > no reason why in our model we don't keep whole text in single big > buffer (like Text does). > Splitting text on multiple spans was the reason to make local layout > updates possible. > But i know it is not that easy to do :) > > > -- > Best regards, > Igor Stasenko. > >

April 27, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by Sean P. DeNigris

OMG, TxTextMorph can grow horizontally. You're my new best friend :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683988.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by Sean P. DeNigris

Denis Kudriashov wrote > You can load configuration from > http://www.smalltalkhub.com/#!/~sig/TxText. For the recreationally-inclined, like myself ;) Gofer it url: 'http://www.smalltalkhub.com/#!/~sig/TxText'; package: 'ConfigurationOfTxText'; load. ((Smalltalk at: #ConfigurationOfTxText) project version: '0.6') load: #('ALL'). ----- Cheers, Sean -- View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683987.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by Igor Stasenko

Very impressive progress, Denis! :) I going to finish low-level stuff in Athens (path approximation / point location) and then go straight to text rendering with existing Text. Next stage will be to take TxText model and provide rendering for it with Athens, as well as review the code. About text editing and re-layout. It should be possible that any local update (which affecting only single character span or multiple adjusted character spans will require only local recalculations of text layout). Otherwise there is no reason why in our model we don't keep whole text in single big buffer (like Text does). Splitting text on multiple spans was the reason to make local layout updates possible. But i know it is not that easy to do :) -- Best regards, Igor Stasenko.

April 27, 2013

Re: [Pharo-project] [update 3.0] #30066

by Sean P. DeNigris

stephane ducasse wrote > marcus do you know why the diff does not work with SmalltalkHub? It works sometimes. It seems that it works when the ancestors are present and produces a confusing error message when they are not... ----- Cheers, Sean -- View this message in context: http://forum.world.st/update-3-0-30066-tp4683816p4683983.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by Denis Kudriashov

2013/4/27 Denis Kudriashov <dionisiydk(a)gmail.com> > 2013/4/27 Denis Kudriashov <dionisiydk(a)gmail.com> > >> 2013/4/27 Denis Kudriashov <dionisiydk(a)gmail.com> >> >>> 2013/4/27 stephane ducasse <stephane.ducasse(a)free.fr> >>> >>>> Nice! >>>> Denis did you see the benchs that doru tried to see if we can use >>>> Rubric? >>>> Because it is interesting to see if we can load and manipulate really >>>> large file. >>>> >>>> Now it would be good that alain releases Rubric with a stable version >>>> and check how to take advantage of the new TextMorph. >>>> >>>> I saw his post. >>> And just now I check this test with TxTextMorph with unwrapped strategy. >>> Similar results like at Rubric test. nearly 30 secs. >>> I generate 50 mb string with almost million lines: >>> TxModel building get 10 seconds. Layout building get 20 seconds. >>> >>> If you want repeat this test you should not use #newTextContents: >>> method. You should build text model manually and put it at morph by >>> #textModel:. >>> #newTextContents: method should be optimized. When I try test with >>> #newTextContents: it was hang on very long time and I stop it. >>> >>> >> And now text editing has no optimization. After each edit full text >> layout rebuilt. So pressing some character in our test take another 20 >> seconds. >> It should be just fixed >> > > And #drawOn: method should be optimized too. I think it is not difficult > task. > Now each line try to draw on canvas. But morph should draw only visible > lines > Drawing fixed. I upload new TxText-Layout version > > >> >>> >>>> Stef >>>> >>>> On Apr 26, 2013, at 11:19 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>> >>>> Hi guys. >>>> >>>> I'm happy to announce that new text editor based on new text model >>>> done. You can load configuration from >>>> http://www.smalltalkhub.com/#!/~sig/TxText. Last version: 0.6. >>>> See class side example methods. >>>> >>>> What available now in TxTextMorph: >>>> - cursor navigation with move left, right, down, up and mouse click >>>> - text selection with move left, right, down, up and mouse movement >>>> - editing by keyboard input >>>> - text wrap >>>> - #addCursor/#removeCursor >>>> - #enableSelection. >>>> - #beEditable >>>> - all keyboard interractions based on shortcuts >>>> >>>> Little details about navigation and editing: >>>> There is TxEditor object which know about cursor position and text >>>> selection. Text morph ask him to perform all navigation and editing >>>> behaviour. >>>> It has cursorMode which knows how to change editor selection when >>>> cursor moved. Editor delegates all move actions to cursorPosition by >>>> #doesNotUnderstand method. It is simplified adding new navigation methods. >>>> For example see TxTextMorph>>enableSelection >>>> >>>> aTxTextMorph>>moveEditorOn: Character arrowLeft by: #moveLeft. >>>> >>>> This expression adds two shortcuts: to move editor left and to select >>>> text left (when selectionModeModifier active). >>>> >>>> What next: >>>> - Remains standart navigation and editing features like copy/paste, >>>> move to line end, to text end and etc. >>>> - halo menu items to edit text and layout properties >>>> - Edit decorators to get mask behaviour like "(999)***-**-**", pretty >>>> numbers like "1'000'000", secrete field like "***" >>>> - Value specs to filter inserted text (only numbers, only english and >>>> etc) >>>> >>>> There are some problems with focus behaviour now. And drawing text >>>> morph with transparent back color works bad. It will be cool if somebody >>>> with good knowledge at this topics can fix it. >>>> >>>> Best regards, >>>> Denis >>>> >>>> >>>> >>> >> >

April 27, 2013