- Pharo-users - lists.pharo.org

Re: [Pharo-users] Few days old 6.1 image now leaves window trails?

by Manuel Leuenberger

Sept. 7, 2017

Re: [Pharo-users] Few days old 6.1 image now leaves window trails?

by Tim Mackinnon

Itâs happened a few more times and Iâve noticed that the culprit in the process explorer is (40) Morphic UI Process: <something that isnât nil> <ââ this one (40) Morphic UI Process: nil If I terminate the not nil one (and sometimes there are 2) then things seem to clear up. Not sure which of my debug windows causes this, but it seems like it happens. tim > On 7 Sep 2017, at 19:53, Tim Mackinnon <tim(a)testit.works> wrote: > > Answering my own question - I tried the Process browser and tried suspending a few processes and then found a debug window that when closed fixed the problem. > > > Tim > >> On 7 Sep 2017, at 19:46, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi there - Iâve been running in a 6.1 64bit image for a few days - doing a few experiments at lunch times, debugging things etc. I have had a few infinite loops that Iâve had to Cmd-. Out of and clean up lots of windows (whoever came up with the close all windows to right is a star!). >> >> Anyway, I just noticed that now when I drag windows around in the world - they leave lots of window trails around. Redrawing the screen cleans it up - but Iâm wondering what causes this? >> >> I tried running the the TimeProfiler and 91% of the time when dragging a window around is in BlockClosure>>newProcess but this doesnât seem out of what with another image that doesnât exhibit this behaviour? >> >> Is there something that I should do to clean up? I wondered if I might find some stuck process in the background that was gobbling cpu - but I donât really see that (but is there an easy way to check?). >> >> Tim > >

Sept. 7, 2017

Re: [Pharo-users] Teapot and Websockets

by Attila Magyar

Teapot already supports conditional routes, maybe using them instead of adding the WS: message would be better. I'm thinking domething like: Teapot on GET: '/chat' -> whatever; when: [:req | req isWebSocket]; start. or just Teapot on GET: '/chat' -> whatever; when: #isWebSocket start. I'll play with this idea sometime. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 7, 2017

Re: [Pharo-users] Teapot and Websockets

by Attila Magyar

Teapot already supports conditional routes, maybe using them instead of adding the WS: message would be better. I'm thinking domething like: Teapot on GET: '/chat' -> whatever; when: [:req | req isWebSocket]; start. or just Teapot on GET: '/chat' -> whatever; when: #isWebSocket start. I'll play with this idea sometime. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 7, 2017

Re: [Pharo-users] Few days old 6.1 image now leaves window trails?

by Tim Mackinnon

Answering my own question - I tried the Process browser and tried suspending a few processes and then found a debug window that when closed fixed the problem. Tim > On 7 Sep 2017, at 19:46, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi there - Iâve been running in a 6.1 64bit image for a few days - doing a few experiments at lunch times, debugging things etc. I have had a few infinite loops that Iâve had to Cmd-. Out of and clean up lots of windows (whoever came up with the close all windows to right is a star!). > > Anyway, I just noticed that now when I drag windows around in the world - they leave lots of window trails around. Redrawing the screen cleans it up - but Iâm wondering what causes this? > > I tried running the the TimeProfiler and 91% of the time when dragging a window around is in BlockClosure>>newProcess but this doesnât seem out of what with another image that doesnât exhibit this behaviour? > > Is there something that I should do to clean up? I wondered if I might find some stuck process in the background that was gobbling cpu - but I donât really see that (but is there an easy way to check?). > > Tim

Sept. 7, 2017

Few days old 6.1 image now leaves window trails?

by Tim Mackinnon

Hi there - Iâve been running in a 6.1 64bit image for a few days - doing a few experiments at lunch times, debugging things etc. I have had a few infinite loops that Iâve had to Cmd-. Out of and clean up lots of windows (whoever came up with the close all windows to right is a star!). Anyway, I just noticed that now when I drag windows around in the world - they leave lots of window trails around. Redrawing the screen cleans it up - but Iâm wondering what causes this? I tried running the the TimeProfiler and 91% of the time when dragging a window around is in BlockClosure>>newProcess but this doesnât seem out of what with another image that doesnât exhibit this behaviour? Is there something that I should do to clean up? I wondered if I might find some stuck process in the background that was gobbling cpu - but I donât really see that (but is there an easy way to check?). Tim

Sept. 7, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Manuel Leuenberger

Well, it has something similar now: > On 7 Sep 2017, at 15:54, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Thank you! > > This is really useful in the context of Seaside render blocks. > > How hard would it be to also add vertical "lines" at the sides like in the following screenshot: > <image.png> > > > Best regards! > > > El sept. 6, 2017 8:53 AM, "Manuel Leuenberger" <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>> escribiÃ³: > Hi everyone, > > I built a little syntax highlighting extension for the Nautilus source code pane, which puts a background color behind blocks, so that nested blocks are easily recognizable. > > <highlight.png> > > Install with: > > Metacello new > baseline: 'BlockStyler'; > repository: 'github://maenu/BlockStyler/repository <>'; > load > > GitHub: https://github.com/maenu/BlockStyler <https://github.com/maenu/BlockStyler> > > Doesnât work with âFormat as you readâ, just as the IconStyler. If anybody has an idea how to integrate it properly into Nautilus as a plugin, let me know. Currently itâs an ugly meta-link hack to get access to the sourceTextModel. > > Cheers, > Manuel

Sept. 7, 2017

Re: [Pharo-users] Teapot and Websockets

by Georges

Hello Attila, What I want is to have a Teapot Server running that somehow also can handle websockets :) In the Pharo Enterprise Book there is a chapter about WebSockets. In there are examples how to setup a ZnServer with a ZnWebSocketDelegate, for instance: ZnServer stopDefault. ZnServer startDefaultOn: 1701. ZnServer default logToTranscript. ZnServer default delegate map: 'ws-echo-client' to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketEchoHandler clientHtml) ]; map: 'ws-echo' to: (ZnWebSocketDelegate map: 'ws-echo' to: ZnWebSocketEchoHandler new). I think it would be nice if this translates to: Teapot on GET: '/ws-echo-client' -> ZnWebSocketEchoHandler clientHtml; WS: '/ws-echo' -> [: webSocket | ZnWebSocketEchoHandler new value: webSocket]; start. But I do not know if this is correct syntax. (Is WS a correct Method? , does it fit next to GET / PUT / POST etc ?) Or is it better to do something like: teapot := Teapot on. teapot GET: '/ws-echo-client' -> ZnWebSocketEchoHandler clientHtml. teapot server delegate map: 'ws-echo' to: (ZnWebSocketDelegate map: 'ws-echo' to: ZnWebSocketEchoHandler new). teapot start. I hope this makes it a bit more clear :) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 7, 2017

Re: [Pharo-users] BlockStyler: Make Blocks more recognizable in source code

by Esteban A. Maringolo

Thank you! This is really useful in the context of Seaside render blocks. How hard would it be to also add vertical "lines" at the sides like in the following screenshot: [image: ImÃ¡genes integradas 1] Best regards! El sept. 6, 2017 8:53 AM, "Manuel Leuenberger" <leuenberger(a)inf.unibe.ch> escribiÃ³: > Hi everyone, > > I built a little syntax highlighting extension for the Nautilus source > code pane, which puts a background color behind blocks, so that nested > blocks are easily recognizable. > > > Install with: > > Metacello new > baseline: 'BlockStyler'; > repository: 'github://maenu/BlockStyler/repository'; > load > > GitHub: https://github.com/maenu/BlockStyler > > Doesnât work with âFormat as you readâ, just as the IconStyler. If anybody > has an idea how to integrate it properly into Nautilus as a plugin, let me > know. Currently itâs an ugly meta-link hack to get access to the > sourceTextModel. > > Cheers, > Manuel >

Sept. 7, 2017

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

by Tim Mackinnon

Thanks Thierry - Iâve been noodling in the background and next I hit the question of âcommentsâ - which I found RB does handleâ¦ and then as per your point - how to skip past an error and try further down (which it seems that the scanner might have the info to let me skip simple things). You seem to get sucked in more and more when trying to to this properly - which does make it sound like a very good internship or GSoc project. I think I may have enough to get something polished enough to release to the wider world. I certainly love having better keyboard support when Iâm coding - as we type a lot (even though we have simple syntax) - and having efficient tools takes away the friction. Next on my hit list, it add the same support to the refactoring tools - which while sophisticated are so clunky in use when compared to IntelliJ. Tim > On 7 Sep 2017, at 08:02, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Tim, > > 2017-09-01 13:39 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Thanks Thierry - this is proving an interesting problem domain ... > > I too am using #bestNodeFor: although I don't find it always gives the best node (it does if you are clearly in the target range, but if you are on the outer boundary like the next position after a selector or next to a "." or ";" it favours the parent and not the closest node. So in usage I find I need to tweak it a bit. > > Yes, when you are on a boundary, then finding the right node may be difficult. When developping the ancestor to smart suggestion, I considered #bestNodeFor: as good enough, but I considered looking into "up" and "down" ast navigation at a time, and I wasn't alone (I think it was active in the Pharo editor at a point). > > > I'll look at smacc though - also there is that experimental setting to allow parse errors, I don't know if it helps in any way. > > There is a general question there, which is how you try to parse as much as possible while jumping over the error, making the error area as small as possible (that would be really great for syntax highlighting, by the way). > > The problem is that in hand-written parsers, you need to hard-code the error management in the parser. With a table-driven parser (as is SmaCC), then you can explore in a systematic way what are the possible states that would allow the parsing to continue correctly after making the error area as small as possible. > > This would make for a very nice internship subject... > > > All this said, I think I have a workable suggestion that is not much code that might be open to scrutiny from those wiser than me. > > Looking at the keyboard handling in the system - it's quite sprawling and tricky to follow. I think there is lots of room for refactoring. > > It is very easy in Pharo to implement a nice and clean keyboard handling; all the necessary components have been in place for years, and we already have implementations (using the KM API). > > Now, most Pharo developpers just jump into hardcoding keyboard handling instead. > > Thierry > > > I'm also not sure if I like the pragma usage either - I find it quite difficult to follow what's calling what. > > Tim > > Sent from my iPhone > > On 1 Sep 2017, at 09:18, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > >> Hi Tim, >> >> The RB ast has a specific method for finding the right node: in AltBrowser, I use ast bestNodeFor: aTarget selectionInterval. >> >> For the second case (parse what is selected), you may want to look into SmaCC: it has specific entry points (used for refactoring) to try all possible starts in a parser for a given piece of text and returning all the possible correct asts. As a hand-writen parser, the RBParser can't do that unless you add the necessary entry points by hand and hack around the error handling, because most of the parse attempts end on an error (as they should). >> >> Regards, >> >> Thierry >> >> 2017-09-01 8:50 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Marcus - I'd be interested in how you thought to solve this. >> >> My solution seems to work - but it's not the most elegant. Retrying lots of different ways like I show, smacks a bit of desperation (this said, it is quite compact). >> >> Apart from that - I was actually interested in thoughts on the parse method - the onError naming is a bit misleading compared to other methods in the image. I wonder if it should be called something like "onErrorMerge:" to signal that it's going to reuse the results? >> >> Stef - with regards to broken source, my proposed solution reuses what is already there - thus if you highlight specific code, it reverts to the original strategy and tries to compile just that code. This bugs me however - so if you highlight nothing, it tries to compile the source multiple ways, I drop down to chopping the source up to where your cursor is - which seems like a decent cheap strategy. >> >> I don't know if our parser is able to recover from simple errors and just have error nodes in the ast, and whether the #bestNodeFor method then ignored error nodes... this is what I think Dolphin used to do. >> >> Tim >> >> Sent from my iPhone >> >> > On 31 Aug 2017, at 19:11, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> > >> > >> >> On 31 Aug 2017, at 19:07, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >> >> >> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >>> Iâm looking for some feedback on the usage of RBParser>>#parseMethod:onError:. >> >>> >> >>> I am looking at ways of improving the way we edit code - and making things work (as least for me - but maybe for everyone) a bit more like IntelliJ where they have some great code operations and very good keyboard support. We are certainly close, but at times feel a bit clumsy - which is a shame as we have far better infrastructure to support equivalent features. So I thought I would have a go. >> >> >> >> Excellent!!! >> >> >> >> >> >>> Anyway - step one (which I think Iâve come close on), was to teach senders/implementors to look at the AST so you donât have to highlight exactly what you want to search on - instead it can infer from your cursorâ¦ however my next step was to improve how we can select code to ease refactoring, bracketing etcâ¦ >> >> >> >> Yes but we have to handle broken code then. >> >> Did you check how smart suggestions did it for code that compiled? >> >> >> > >> > I looked some weeks ago and made some notes what to doâ¦ but I fear this has to wait for next week, >> > there is no way that I can do anything till ESUGâ¦ >> > >> > Marcus >> >> >> >

Sept. 7, 2017