- Pharo-dev - lists.pharo.org

Re: [Pharo-project] New Text Completion suggestions

by Igor Stasenko

(a bit orthogonal) i don't understand why we cannot have own, consistent set which is good for us? vim, emacs.. why this is so important ? Those editors were not written for editing smalltalk code in mind.. they are best suited for big, hundreds lines of code, files.. while something like that in our case is an exception rather than norm. So, why some people striving for having same keys as there? Just because they get used to them? Seriously vim? A modal editor which is invented for editing files on obscure terminals, where you don't even have a cursor keys on keyboard? I pass.. Just give me a decent editor with good cursor navigation, selection and undo/redo/find/replace, that's all i need. -- Best regards, Igor Stasenko.

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Camillo Bruni

On 2012-08-23, at 19:50, Stephan Eggermont <stephan(a)stack.nl> wrote: > Camillo wrote: >> So you're saying modifiable keyboard shortcuts are a bad design? > > Yes. > > That is to say, using them outside of developing a good set of > key bindings (possibly for each language/keyboard). We need them > to get to this consistent set. Options could be on the level of > vi/wordstar/emacs style. I see 3 versions here, I add vim, BOOM flamewar :D. so no options, is no option, forget it... whenever there will be an emacs keybinding set, I will bribe people until I have a corresponding vim set :D

Aug. 23, 2012

[Pharo-project] Friday in Ghent

by DeNigris Sean

I'm arriving on Friday morning (about 9am)... anyone else around? Sean

Aug. 23, 2012

Re: [Pharo-project] [In Progress] WebSocket support being added to Zinc HTTP Components

by Esteban A. Maringolo

Excellent news Sven! -- View this message in context: http://forum.world.st/In-Progress-WebSocket-support-being-added-to-Zinc-HTT… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 23, 2012

Re: [Pharo-project] [In Progress] WebSocket support being added to Zinc HTTP Components

by Igor Stasenko

On 23 August 2012 21:27, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Yes, the rumors are true: WebSocket support is coming to Zinc HTTP Components and thus to Pharo Smalltalk ! > > Several people asked for it, but Andy Burnett of Knowinnovation USA provided a financial incentive (thanks a lot Andy for sponsoring open-source Smalltalk software like that), so I am now putting in the effort to make this happen. > Great! :) -- Best regards, Igor Stasenko.

Aug. 23, 2012

[Pharo-project] [In Progress] WebSocket support being added to Zinc HTTP Components

by Sven Van Caekenberghe

Yes, the rumors are true: WebSocket support is coming to Zinc HTTP Components and thus to Pharo Smalltalk ! Several people asked for it, but Andy Burnett of Knowinnovation USA provided a financial incentive (thanks a lot Andy for sponsoring open-source Smalltalk software like that), so I am now putting in the effort to make this happen. The goal is to add WebSocket (RFC 6455) client and server support over plain and TLS/SSL streams (ws:// and wss://) to Zinc HTTP Components maintaining compatibility with Pharo 1.3, 1.4 and 2.0, as well as community suported portability to Gemstone/Smalltalk and Squeak. The test for success will be: Use Pharo Smalltalk as both client and server for the Echo example at http://www.websocket.org/echo.html as well as implement the same example directly (through a locally served page). The final code will be open source and MIT licensed. It will include unit tests, documentation as well as basic support on the mailing list. The purpose of this email is twofold: to announce the fact that this is happening and to look for early alpha testers that can help shape the API. Although as yet unfinished, largely undocumented and untested, still containing debugging and tracing code and subject to change, there is already working code that meets the functional goals available in the main development Zn repository. Gofer it url: 'http://mc.stfx.eu/ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-FileSystem'; package: 'Zinc-Tests'; package: 'Zinc-WebSocket-Core'; package: 'Zinc-WebScoket-Tests'; load The first working example is accessing an existing WebSocket test application at http://www.websocket.org/echo.html ZnWebSocketTests>>#testEchoWebSocketsDotOrg | webSocket message | webSocket := ZnWebSocket to: 'ws://echo.websocket.org'. message := 'Greetings from Pharo Smalltalk @ ', TimeStamp now printString. webSocket sendMessage: message. self assert: webSocket readMessage equals: message. webSocket close. The second working example is Zinc implementing the same echo service itself as well as accessing it ZnWebSocketTests>>#testEchoLocally | webSocket message | ZnServer startDefaultOn: 1701. ZnServer default logToTranscript. ZnServer default delegate map: 'ws-test' to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestHtml) ]; map: 'ws-test-local' to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestLocalHtml) ]; map: 'ws-echo' to: (ZnWebSocketDelegate new prefixFromString: 'ws-echo'; handler: ZnWebSocketEchoHandler new; yourself). webSocket := ZnWebSocket to: 'ws://localhost:1701/ws-echo'. message := 'Greetings from Pharo Smalltalk @ ', TimeStamp now printString. webSocket sendMessage: message. self assert: webSocket readMessage equals: message. webSocket close. ZnServer stopDefault. Where ZnWebSocketEchoHandler>>#value: webSocket "I implement an echo service conversation as a server: reading messages and echoing them back until ConnectionClosed" [ webSocket runWith: [ :message | self crLog: 'Received message: ', message printString, ' echoing...'. webSocket sendMessage: message ] ] on: ConnectionClosed do: [ self crLog: 'Ignoring connection close, done' ] If you select and execute the following part from the above ZnServer startDefaultOn: 1701. ZnServer default logToTranscript. ZnServer default delegate map: 'ws-test' to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestHtml) ]; map: 'ws-test-local' to: [ :request | ZnResponse ok: (ZnEntity html: ZnWebSocketDelegate wsTestLocalHtml) ]; map: 'ws-echo' to: (ZnWebSocketDelegate new prefixFromString: 'ws-echo'; handler: ZnWebSocketEchoHandler new; yourself). You can use your browser to access the echo service through the standard JavaScript API http://localhost:1701/ws-test http://localhost:1701/ws-test-local The first URL goes out to websocket.org, the second uses the local Zinc implementation. Again, this is early code, anything might change. So, if you have some prior knowledge in this area and are interested, have a look and let me know what you think. Thx, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Stephan Eggermont

Camillo wrote: >So you're saying modifiable keyboard shortcuts are a bad design? Yes. That is to say, using them outside of developing a good set of key bindings (possibly for each language/keyboard). We need them to get to this consistent set. Options could be on the level of vi/wordstar/emacs style. Stephan

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Stephan Eggermont

Doru wrote >I think an option would only add to the confusion. Please replace the >option with one decision. If some do not like it, they can shout and >the designer can take the input into account. But, it's the designer >that decides. +1 Stephan

Aug. 23, 2012

Re: [Pharo-project] why do we have methods with trailer EmbeddedSourceZip ?

by Igor Stasenko

no idea :/ you can just resave them to go back to normal On 23 August 2012 16:15, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > In Pharo 2.0 > > (CompiledMethod allInstances select: [:each | each trailer kind = > #EmbeddedSourceZip ]) size -> 15 > > (CompiledMethod allInstances select: [:each | each trailer kind = > #EmbeddedSourceZip ]) > > -> > > {(Dictionary>>#keysAndValuesDo: "a CompiledMethod(578289664)"). > (Morph>>#extent: "a CompiledMethod(691011584)"). (Morph>>#initialExtent "a > CompiledMethod(450101248)"). (Object>>#at:put: "a > CompiledMethod(784859136)"). (Object>>#printOn: "a > CompiledMethod(589299712)"). (Object>>#windowIsClosing "a > CompiledMethod(476839936)"). (Object>>#is: "a CompiledMethod(798752768)"). > (Object>>#at: "a CompiledMethod(660078592)"). (Object class>>#initialize "a > CompiledMethod(184549376)"). (Stream>>#nextPutAll: "a > CompiledMethod(881328128)"). (Stream>>#next: "a CompiledMethod(841744384)"). > (Stream>>#upToEnd "a CompiledMethod(483393536)"). (SystemWindow>>#delete "a > CompiledMethod(222035968)"). (SystemWindow>>#initialExtent "a > CompiledMethod(28835840)"). (SystemWindow>>#update: "a > CompiledMethod(521928704)")} > > Any idea why we have that instead of a regular one with a source pointer? > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Aug. 23, 2012

Re: [Pharo-project] New Text Completion suggestions

by Camillo Bruni

So you're saying modifiable keyboard shortcuts are a bad design? On 2012-08-23, at 16:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I definitely do not adhere to this point of view, but I think I > understand it well. > > Let's think of code design now. When you see non-object-oriented > design, you go and refine. When you see conceptual duplication, you go > for it and unify. Until you get a better abstraction that matches the > paradigm and gestalt of the entire system. You apply rigor. That is > why Pharo is getting better every day. > > When you see non-conforming UI, you invoke preference choice and add > an option. This approach is likely to get the UI experience exactly > towards where Pharo comes from code-wise. > > The IDE (and UI in general) requires rigor and design as well. I will > keep saying it :). > > Cheers, > Doru > > p.s. Regarding ENTER on completion, I have documented the reasons why > it is a bad idea before: > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/016413.h… > (Please note that the mail provides a list of hands-on arguments, and > it does not invoke preference or taste) > > > > On Thu, Aug 23, 2012 at 3:40 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> no options, this what options are for. you can decide on a default. >> and then change the options. we live in a multidimensional world. >> >> it's the same thing with using ENTER instead of TAB to accept >> completions. I and Igor for instance strongly prefer ENTER, whereas >> other people like you don't like that... now we can start a swiss >> democracy over that and decide in 100 years whether we should support >> ENTER or not. OR we simply add an option, both sides happy! >> >> On 2012-08-23, at 14:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> I think an option would only add to the confusion. Please replace the >>> option with one decision. If some do not like it, they can shout and >>> the designer can take the input into account. But, it's the designer >>> that decides. >>> >>> Cheers, >>> Doru >>> >>> >>> On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>> On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>>> Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? >>>>> Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... >>>>> Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. >>>>> moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? >>>>> Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. >>>>> >>>>> Suggestions: >>>>> - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. >>>>> - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ >>>>> - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. >>>> >>>> maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, >>>> so everybody is happy >>>> >>>>> PS: AlphaBlendingCanvas suggested for 'aB'... really? >>>> for me, clearly yes, substring matching is exactly then important when >>>> you don't fully remember the selector name. But again, adding an option here >>>> will make both sides happy... >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 23, 2012