February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Basics...Pluggable..Morphs on change

by Krishsmalltalk

I must say it was an off color moment to state it this way. Rather I should say, morphs must be intelligent to update: themselves, but models can choose to have the #changed: call when they get to have a need to connect more than one view. So i should rewrite the examples as >> changeModelSelection: anInteger >> >> setIndexSelector ifNotNil: >> [model perform: setIndexSelector with: anInteger]. >> "update this morph implicitly without needing model #changed: call" >> self update: getIndexSelector Similar for the acceptInTextModel, in an MVP world, view or widget has to be intelligent for it's own updates, not wait only on the model or controller to send updates...even for such obvious update On Feb 6, 2012, at 8:46 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It has been done like that because sometimes ( and in fact quite often for complex UIs ), the model want to perform some actions before the UI is updated. > But I am agree that for some instructions, like selection changes, it could (should ?) be send directly by the morph. > > > Ben > > > On Feb 6, 2012, at 5:49 AM, S Krish wrote: > >> >> I am checking out on the basics of the PluggableTextMorph and PluggableListMorph .. and its cousins. >> >> PluggableListMorph >> >> changeModelSelection: anInteger >> >> setIndexSelector ifNotNil: >> [model perform: setIndexSelector with: anInteger]. >> >> here it is the responsibility of the model to send #changed: getIndexSelector. why..? >> >> why not a simpler generic: >> >> changeModelSelection: anInteger >> >> setIndexSelector ifNotNil: >> [model perform: setIndexSelector with: anInteger]. >> "sends the call to all dependents of the model implicitly" >> model perform: #changed: with: getIndexSelector >> >> thereof the models anywhere need not bother sending #changed: calls... ! >> >> similarly: >> >> acceptTextInModel >> >> ..... >> [^setTextSelector isNil or: >> [setTextSelector numArgs = 2 >> ifTrue: [model perform: setTextSelector with: acceptedText with: self] >> ifFalse: [model perform: setTextSelector with: acceptedText]] >> ] ensure: [unstyledAcceptText := nil]. >> model perform: #changed with: getTextSelector >> >> We can avoid these in the methods if implemented across all Pluggable??Morphs >> >> Workspace class>> >> openContents: aString >> >> ^ self new >> open; >> contents: aString; "funny is this itself calls #changed:" >> "changed: #contents;" >> yourself >> >> Makes common sense to me.. rather than expecting the model to explicity call #changed:..this "view" / widget knows its model and it implicitly invoking #changed: is cleaner abstraction, unless a use case exists which may break infrastructure/ whole base doing this.. >> >> This way all models associated with various Pluggable??Morphs will work perfectly fine on just a setter call without extra line being added everywhere in the application code, apps need to bother about changes to other symbol viz: updating a list selection index causes another widget to refresh its content.. >> >> >> >> >

Feb. 6, 2012

Re: [Pharo-project] Basics...Pluggable..Morphs on change

by Benjamin

It has been done like that because sometimes ( and in fact quite often for complex UIs ), the model want to perform some actions before the UI is updated. But I am agree that for some instructions, like selection changes, it could (should ?) be send directly by the morph. Ben On Feb 6, 2012, at 5:49 AM, S Krish wrote: > > I am checking out on the basics of the PluggableTextMorph and PluggableListMorph .. and its cousins. > > PluggableListMorph >> > changeModelSelection: anInteger > > setIndexSelector ifNotNil: > [model perform: setIndexSelector with: anInteger]. > > here it is the responsibility of the model to send #changed: getIndexSelector. why..? > > why not a simpler generic: > > changeModelSelection: anInteger > > setIndexSelector ifNotNil: > [model perform: setIndexSelector with: anInteger]. > "sends the call to all dependents of the model implicitly" > model perform: #changed: with: getIndexSelector > > thereof the models anywhere need not bother sending #changed: calls... ! > > similarly: > > acceptTextInModel > > ..... > [^setTextSelector isNil or: > [setTextSelector numArgs = 2 > ifTrue: [model perform: setTextSelector with: acceptedText with: self] > ifFalse: [model perform: setTextSelector with: acceptedText]] > ] ensure: [unstyledAcceptText := nil]. > model perform: #changed with: getTextSelector > > We can avoid these in the methods if implemented across all Pluggable??Morphs > > Workspace class>> > openContents: aString > > ^ self new > open; > contents: aString; "funny is this itself calls #changed:" > "changed: #contents;" > yourself > > Makes common sense to me.. rather than expecting the model to explicity call #changed:..this "view" / widget knows its model and it implicitly invoking #changed: is cleaner abstraction, unless a use case exists which may break infrastructure/ whole base doing this.. > > This way all models associated with various Pluggable??Morphs will work perfectly fine on just a setter call without extra line being added everywhere in the application code, apps need to bother about changes to other symbol viz: updating a list selection index causes another widget to refresh its content.. > > > >

Feb. 6, 2012

Re: [Pharo-project] Debugger filtering

by StÃ©phane Ducasse

yes > I know what proper implementation of it should be: > > contextsToShow := > stack reject: [:context | > context method pragmas anySatisfy: [:pragma | pragma keyword == > #skipWhileDebugging ] > ] > > like that, you can tag the methods by yourself, instead of making > Debugger too clever to decide: > > Foo>>bar > <skipWhileDebugging> > > ..some boring code.. > > > and probably the test can be more complicated, since we don't want all > #at: method for colleciton, for instance, > we should be able to tag only #at: method in Collection itself , > so debugger should take the method and check if it overrides a method, > which is tagged as unimportant. > > > :) > > >> best >> cami > > > > -- > Best regards, > Igor Stasenko. >

Feb. 6, 2012

Re: [Pharo-project] Debugger filtering

by Ben Coman

Camillo Bruni wrote: > In the latest Pharo Release we pushed a new Setting for the Debugger: > > see Settings / Debugging / Filter out common message sends, > when enabled the Debugger behaves a bit nicer in most cases by filtering some non-interesting contexts: > > - "self halt" will now open the Debugger in the sender context, not somewhere on Halt / Object > - sends to Kernel Classes are not shown (like Dictionary >> #at:ifAbsent: #do: #collect: ...) > - a failing TestCase will open the Debugger in the test method itself > > So all in all it will save you some clicks and concentrate on the important stack elements > For those interested in the details or wanting to extend it see > > Debugger >> #shouldDisplayContext: > > best > cami > > That is really great. I have found it hard to adapt to jumping back a forth through the 'aBlock value: (self at: index)' in #do: Does that also include all the system fluff occurring prior to executing... self halt. #(1 2 3 4 5) do: [ :x | Transcript crShow: x ] ...in a Workspace ? cheers, ben

Feb. 6, 2012

Re: [Pharo-project] Debugger filtering

by Igor Stasenko

On 6 February 2012 14:48, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > In the latest Pharo Release we pushed a new Setting for the Debugger: > > see Settings / Debugging / Filter out common message sends, > when enabled the Debugger behaves a bit nicer in most cases by filtering some non-interesting contexts: > > - "self halt" will now open the Debugger in the sender context, not somewhere on Halt / Object > - sends to Kernel Classes are not shown (like Dictionary >> #at:ifAbsent: #do: #collect: ...) > - a failing TestCase will open the Debugger in the test method itself > > So all in all it will save you some clicks and concentrate on the important stack elements > For those interested in the details or wanting to extend it see > > Â Â Â Â Debugger >> #shouldDisplayContext: > I know what proper implementation of it should be: contextsToShow := stack reject: [:context | context method pragmas anySatisfy: [:pragma | pragma keyword == #skipWhileDebugging ] ] like that, you can tag the methods by yourself, instead of making Debugger too clever to decide: Foo>>bar <skipWhileDebugging> ..some boring code.. and probably the test can be more complicated, since we don't want all #at: method for colleciton, for instance, we should be able to tag only #at: method in Collection itself , so debugger should take the method and check if it overrides a method, which is tagged as unimportant. :) > best > cami -- Best regards, Igor Stasenko.

Feb. 6, 2012

[Pharo-project] [update 1.4] #14316

by Marcus Denker

14316 ----- Issue 5251: Remove MCWorkingCopy from startup list http://code.google.com/p/pharo/issues/detail?id=5251 Issue 5167: Fix weak finalization thrashing - improve interrupt behavior http://code.google.com/p/pharo/issues/detail?id=5167 Issue 5224: move deprecated methods from category convenience-inspecting in ToolRegistry to deprecated14 http://code.google.com/p/pharo/issues/detail?id=5224 -- Marcus Denker -- http://marcusdenker.de

Feb. 6, 2012

Re: [Pharo-project] [update 1.4] #14314

by Camillo Bruni

On 2012-02-06, at 10:43, Lukas Renggli wrote: >> - there should be :D (I imagine it exactly like in eclipse, cmd-key pressed => underline all links and display a hand cursor onOver) >> - telling morphic to do highlighting is a different story |-( >> - right now you only get onDrag events in â although named onMove â I guess I will have to hack a bit :) >> - right-click menus should start working again (they're currently slightly broken) >> - we should have refactoring menus in there (rename instVar/args, push instvar...) > > Most of these things have been done in Helvetia. > > The next most useful thing after code navigation was on-the-fly Code > Critics with the yellow wiggly underlines and Ctrl+1 instant-fix. indeed that sounds cool :)

Feb. 6, 2012

[Pharo-project] Debugger filtering

by Camillo Bruni

In the latest Pharo Release we pushed a new Setting for the Debugger: see Settings / Debugging / Filter out common message sends, when enabled the Debugger behaves a bit nicer in most cases by filtering some non-interesting contexts: - "self halt" will now open the Debugger in the sender context, not somewhere on Halt / Object - sends to Kernel Classes are not shown (like Dictionary >> #at:ifAbsent: #do: #collect: ...) - a failing TestCase will open the Debugger in the test method itself So all in all it will save you some clicks and concentrate on the important stack elements For those interested in the details or wanting to extend it see Debugger >> #shouldDisplayContext: best cami

Feb. 6, 2012

Re: [Pharo-project] Creating a file with FS

by Sven Van Caekenberghe

On 06 Feb 2012, at 09:25, Camillo Bruni wrote: > (wk / 'foo') writeStreamDo: [ :s | > s << 'bar' ]. Yes, this is nice code!

Feb. 6, 2012

Re: [Pharo-project] pharo vision

by StÃ©phane Ducasse

On Feb 6, 2012, at 12:56 PM, Nick Ager wrote: > Hi Stef, > > Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo. > > I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work. yes but this is a web centric view :). We will have to get decent uibuilder and reuse of logic > At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo? I do not know. What is clear is that we are working micro kernels and bootstrap for pharo and we will restart our effort on it. > As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone. Indeed now our goal is to absorb as much as possible grease so that there is no need to load grease for pharo this will proved that our libraries will get better. > > [1] http://thiscontext.wordpress.com/ > [2] http://netjam.org/spoon/naiad/ > [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.ht… > > > > > > > > On 5 February 2012 17:43, Philippe Marschall <kustos(a)gmx.net> wrote: > On 30.01.2012 09:24, StÃ©phane Ducasse wrote: > > OK, so here's my take. I try to not turn this into a wish list. > > Rich libraries > While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. > > FFI > First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer "turtles all the way down" but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have "threaded-FFI". > Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: > - use FFI for call-outs > - use Alien for call-backs > - use NativeBoost for faster callouts? "portable plugins"? > It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me. > > 64 bit > I think it's important to make a distinction between 64bit images and 64 bit VMs. > > 64 bit VMs > Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: > - it clearly marks the application as legacy > - you can only talk to 32bit libraries (see FFI) > - we don't know how long this will still be supported (Apple anybody?) > I don't know how much work is required to make Cog run on 64bit. > > 64bit images > While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images. > > SOAP > SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things. > > Sockets > I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can â and should â be improved, but it's not holding us back. IMO it's missing four things: > - better documentation with examples, this is important and relatively easy to do > - SSL, this is "just" an issue for clients since servers are fronted anyway. I know Sven's working on this. > - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. > - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. > I know I have a narrow Seaside-centric focus here. > What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo. > > Load balancer > I don't think this needs to be part of Pharo. Apache already does this. > > UI frameworks: > Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. > Options that I would consider: > - status quo, maintenance only, no further development > - drop UI entirely, go for something like embedded WebKit > - make it somebody else's problem, once you have better FFI generate bindings for GTK/QT/â¦ > This is not giving up. This is not fighting battles you cannot win. > > Plug Computer > Really? You have all the other places that need more resources and you want to do even more. > > Now the things that aren't on your list: > > VM: > Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring. > > #identityHash > It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time. > > Infrastructure > If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well. > > Migration Support > Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: > - tell the user where he uses deprecated code > - assist the user in migrating to new APIs > this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers. > > Releases > I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: > - One main release every year > - Two bugfix releases every year > - after the two bugfix releases a new main release is done and the old main release becomes unsupported > The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable. > > [1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%… > [2] http://wiki.eclipse.org/Simultaneous_Release > [3] http://wiki.eclipse.org/SimRel/Overview > > Cheers > Philippe > > >

Feb. 6, 2012