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

Re: [Pharo-dev] ||

by Eliot Miranda

Hi Hernan, On Feb 7, 2015, at 12:55 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Eliot, > > 2015-02-07 14:48 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi Hernan, >> >> On Sat, Feb 7, 2015 at 7:41 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> >>> 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >>>> Personally I don't like Pragmas, they have not convinced me so far that they fit the style of Smalltalk syntax. I have to confess though I never liked descriptive elements and languages . >>> >>> Me neither. Actually the pragma idea is not wrong per se, it is the tag syntax to write them which bothers me. Because the world can be described with tags if you start that path. >> >> How exactly is the syntax wrong? > > I am not saying syntax is wrong, I just don't like it because: > > 1) Adds another level of representation inside an already reflective system. What do you mean exactly? I don't have clear recollection of whether they were in Squeak in 08 or if I ported then, but at that time CompiledMethod had a properties object, and pragmas were merged into this. What I did do was save a lot of space getting rid if the properties object unless a method needed it. And IIRC I changed the implementing class from MethodProperties to AdditionalMethodState. So there was no additional level of representation. a) the syntax was already there fir primitives and b) the state was already there in methods. > 2) It could be done with plain common message sends. No it can't. Common sends are executable and we don't want pragmas executed when the method is run, we want the pragma executed when the method is added, or analysed. That was what was ugly about the use of plain sends in e.f. VMMaker, that there had to be lots of empty implementations of the messages used for metadata. So using normal sends - prevents the metadata from being directly executed because executing them when the method is run is wrong - confuses meta level and normal level, putting them at the same level, and hence... - confusing for the programmer because its not obvious what's metadata and what's a normal send - makes analysis harder for the same reason > 3) Should be (to me) "hidden" from method pane, and displayed by a specific tool inside the system browser. I disagree. I want to see the pragma. It has essential information that shouldn't be hidden. I want to edit it easily. And how can you in the one hand say it can be implemented as a normal message send a d at the same time want it hidden? Be consistent :-) > >> The <literalMessagePattern> syntax predates pragmas. It was used first for numeric primitives in Smalltalk-76 or Smalltalk-80. Squeak extended it with primitive:module:. I and others extended it to include arbitrary literal message patterns. The syntax of a literal message pattern is the syntax of a send with no receiver and only literal arguments. >> The use of this syntax means >> a) no new syntax >> b) each pragma is potentially executable >> c) methods using specific pragmas can be found using "find senders" >> d) the execution side of a pragma can be found using "find implementors" >> >> So what's wrong with that? How is it wrong to use a common Smalltalk object, a Message, that is well-supported in the system, for method metadata? > > I get that pragmas are messages, but they assume an implicit receiver, which actually depends on context. If I understood right with pragmas always receiver = destination? Not for pragmas that are just labels. And what's destination? In the menu building example above the destination"is the menu but the receiver is the menu builder. So I think that what the receiver is depends on usage. > If you change things in the communication model (receiver, sender, message, etc.), by removing or adding elements, you have a loss in the message because it gets harder to reconstruct the message send. I don't understand this. Can you expand? > > Consider > > <eventRegistration> > | eventRegistration | > { eventRegistration }. > self eventRegistration. > > which of them "it sounds like" you cannot infer their purpose? I don't get the example, because of the confusion of meta layers. <eventRegistration> says "this is metadata" | eventRegistration | says "this is a bug in the method because the variable isn't used, and eg Opal will remove it so it won't be there". { eventRegistration }. I guess you mean { #eventRegistration }. If so this is the same. An optimizing compiler will delete it. self eventRegistration. says "send myself eventRegustration". Which /isn't/ what's wanted. So for me only the pragma implies "this method is to be registered with the event system". The middle two say "I am a bug, or syntax error". The last one says "I am a normal send". > > To me the first because you need the context MyClass>>methodName > and you need to browse the pragma to get its purpose. > > >> >>> There are other ways to add metadata to methods. Without tagging. >> >> Haven't we discussed that? Putting metadata off to the side introduces a bookkeeping problem. It is a bad idea. > > Yes, but I still have a lot of doubts about feedback with pragmas (I hope you view them as constructive criticism). I'm finding this whole conversation exhausting. > Is like pragmas assume there is always a perfect message transaction. > How can I halt the execution of a specific pragma? By putting a break point in its implementations. > Can I write <myPragma halt>? No. But you can out a conditional breakpoint in CompiledMethod>>pragmaAt: or in the pragma's implementation. > How do I know if it will get executed? By reading the broader system or adding break pints as just described. > Is <shortcut> a functional pragma? > How do I distinguis any pragma from being functional or "documentation"? Using "implementors" and "senders" you can find out where it may be used. One if the problems of late-bound systems is figuring out what binds to what. Pragmas are more difficult to figure out unless pragmas have clearly commented implementations. > >> >>> And they don't need to be in the method pane itself. >> >> For some kinds of metadata, for metadata with semantics, not just a documentary function, it is important for the metadata to be obvious. > > I think this depends on context. Because your work could be towards low-level machinery details or software reenginering, doesn't mean that we all need to view compiler directives, functional and structural annotations, etc. That's a mischaracterisation. Most of their uses are for pluggable GUIs. And if this is so onerous why weren't you protesting <primitive: 123>? > And if I can write some prediction... When someone invents automatic annotation (like happens now with genomes) and decides it will be cool to have them in the image (because you will gain performance, more reflective capabilitites, etc) methods could explode with pragmas to the point gets to be annoying to browse any method. Then the tool will have to be built by need. > >> No one has argued for hiding the primitive specification off-to-the-side. "Need" is a poor criticism here because using turing equivalence lots of things don't "need" to be the way they are. Instead why not ask what are the pros and cons? > > Ok, many of us knows the pros. I have been using pragmas for a while. > But if we stop discussing then it will never adapt to new ideas. > So you may want to share your view of cons too :) The cons are that for years, and at length, one has to defend a good idea ;-). Pragmas were a new idea and here in thus conversation we see how resistant we are to new ideas. I've seen nothing against the need for per-method metadata and a lot on how it can be done with other mechanisms. But the existing mechanisms don't do one of two things - separate normal from meta levels - obviously associate metadata with methods. So what I'm missing in this conversation is addressing the issues: - how in a componentised loadable system do we decouple component loads where components collide in areas like global menu definitions, inspectors, etc? - how do we associate metadata with methods so that - the metadata is of a form that fits well with the host system? - the metadata is clearly associated with the method it is data of? - the bookkeeping is managed? You could add good questions here. But these are the questions I was thinking of when we added pragmas to VW. >>> It is like having to specify protocol because there is no list pane to create them. >> >> I disagree. When the pragma is specifying type information, specifying that the method is an action on a specific menu, is a pane in an inspector, and many other uses, it is essential that that information be represented, and putting it in a one-off bookkeeping system is a bad idea. We're not talking about simple documentary metadata like author, category etc. > > Well, I think documentary metadata is tremendously complex. > >> We're using pragmas for semantics, semantics of the method that are outside of its execution semantics, semantics about how the method fits in the broader system. And putting that in non-obvious places is a bad idea. > > I agree. But obvious could be a place where can be located by a method though not necessarily visible. > > Cheers, > > HernÃ¡n > > >>> >>> >>> HernÃ¡n >>> >>>> >>>> About python decorators I disagree that are similar to pragmas. Pragmas are focused on being descriptive , python decorators are descriptive as by product. The main focus of python decorators is to shorten code by introducing syntactic sugar. >> >> Kilon, pragmas are not limited to being descriptive. >> >>>> >>>> I agree though this is a very interesting discussion and I dont understand most of the things stated here so I leave an open door and mind for pragmas. Maybe one day I will "get it". >> >> That would be nice :) >>> >>> >>> >>> >>>> >>>> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>> >>>>> 2015-02-06 22:00 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>>> Really interesting discussion. I like pragmas but this is interesting to see them challenged. >>>>> >>>>> Thanks. It's a pleasure to discuss that way :) >>>>> >>>>>>> Yes, but there end up being lots of naming conventions and they are non-obvious. Whereas pragmas, because they are in-your-face in the methods in question, don't need conventions. They just need documenting ;-). >>>>>> Thierry I'm skeptical that multiple protocol will save the problem because you will rely on coding conventions. >>>>> >>>>> Pragma as well: just explain the conventions behind the gtInspector pragmas, for example. >>>>> >>>>> But give me multiple protocols and I'll show you the same conventions rewritten in less lines (and a slightly more efficient code). >>>>> >>>>>> And pragma is a clever tagging. >>>>> >>>>> Then maybe we should remove protocols and replace them with pragmas :) >>>>> >>>>> Thierry >>>>> >>>>>> >>>>>> Stef >> >> >> >> -- >> best, >> Eliot >

Feb. 8, 2015

Re: [Pharo-dev] Howto create a new configuration?

by Juraj Kubelka

Hi, > 8. 2. 2015 v 8:26, Nicolai Hess <nicolaihess(a)web.de>: > > 2015-02-07 13:17 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > > > 2015-02-06 22:02 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com <mailto:juraj.kubelka@gmail.com>>: > I have changed two methods of the configuration: > > -=-=- > stable: spec > <symbolicVersion: #stable> > > spec for: #'pharo2.x' version: '2.1'. > "after some modification in NB made it incompatible with 3.0" > spec for: #'pharo3.x' version: '2.3'. > spec for: #'pharo4.x' version: '2.7â. â<<== added, maybe instead of pharo4.x could be common" > -=-=- > development: spec > <symbolicVersion: #'development'> > > spec for: #'common' version: '2.3-baselineâ. â<<== it is likely not necessary" > -=-=- > > I have changed it, because I think there should be two lines in Versioner: one with development label, second with stable label. > Then everything works. > Let me know if it helps. > Juraj > > Thank you Juraj, > that works .... better, but now, commiting the new configuration > shows a bunch of "Critical Issues" > Critical Warning missing recommend field... > Critcal Warning The name of package x does not match file name x.7 > Critical Warning No Version specified. > .... > > Not that easy. Maybe, the ConfigurationOfAthens was only written and updated by hand, does not work with Versionner? > > > > > I think, for now I will try to change the Configuration by hand without versionner. > > There three warnings revealed by: (MetacelloToolBox validateConfiguration: ConfigurationOfAthens). It is easy to fix, well I guess. The one is a misspelling, two are about missing #versionString: and I suppose there should be versionString: #âstableâ. It is fixed in ConfigurationOfAthens-JurajKubelka.46.mcz. Then I have created by hand version 2.8. The âstrangeâ think is that development do not point to the latest version. Is the 2.8 supposed to be stable or development version? ConfigurationOfAthens-JurajKubelka.46.mcz contains the 2.8 version as development version. Cheers, Juraj

Feb. 8, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40482 Home: https://github.com/pharo-project/pharo-core

Feb. 8, 2015

[pharo-project/pharo-core] f2a521: 40482

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f2a521712cf04c935e25f77fd35c8e7c67ff2390 https://github.com/pharo-project/pharo-core/commit/f2a521712cf04c935e25f77f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-08 (Sun, 08 Feb 2015) Changed paths: M Nautilus-Tests.package/PackageTreeNautilusTest.class/README.md M Nautilus-Tests.package/PackageTreeNautilusTest.class/definition.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/accessing/compiledMethod_.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertMethodWidget.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertPackageMorph_.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertPackageWidget.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/running/tearDown.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/setUp.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueIsNil.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueNotNil.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueNotNil2.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseLastValueNotNilSelectedCategoryIsNil.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testFullBrowseOnClass.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpen.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenLastValueIsNil.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenLastValueNotNil.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethod.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethodLastValueIsNil.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testOpenOnMethodLastValueNotNil.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testPackagePatternString.st A Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/tests/testPackagePatternStringRootPackageTag.st A Nautilus.package/MethodWidget.class/instance/private/methodsList.st M Nautilus.package/Nautilus.class/class/opening/openOnMethod_inEnvironment_.st M Nautilus.package/NautilusUI.class/instance/displaying/open.st M Nautilus.package/PackageTreeNautilusUI.class/definition.st M Nautilus.package/PackageTreeNautilusUI.class/instance/menus behavior/fullBrowse.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packageSearchUpdate_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/updatePackages.st A Nautilus.package/PackageTreeWidget.class/instance/updating/updateContentsWithPreviouslyExpanded_.st A Nautilus.package/PackageWidget.class/instance/private/packagesList.st A Nautilus.package/extension/RPackage/instance/asNautilusItemPath.st A Nautilus.package/extension/RPackageTag/instance/asNautilusItemPath.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script482.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40482.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Slot.package/AbstractLayout.class/instance/printing/printSlotDefinitionOn_.st R Slot.package/LayoutAbstractScope.class/instance/printing/printSlotDefinitionOn_.st R Slot.package/LayoutClassScope.class/instance/printing/printSlotDefinitionOn_.st R Slot.package/LayoutEmptyScope.class/instance/printing/printSlotDefinitionOn_.st R Slot.package/PointerLayout.class/instance/printing/printSlotDefinitionOn_.st Log Message: ----------- 40482 14886 remove #printSlotDefinitionOn: https://pharo.fogbugz.com/f/cases/14886 14865 Browse full command does not display full class definition https://pharo.fogbugz.com/f/cases/14865 http://files.pharo.org/image/40/40482.zip

Feb. 8, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Tudor Girba

Hi Nicolai, On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools > #development > "From this version onwards the development version should be integrated." > > Is this a good idea? Does the #development version always include *all* > the latest > changes, because after Andrei opened > 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools > (which got integrated in 40475) > I uploaded some changes for issue > 14608 <https://pharo.fogbugz.com/default.asp?14608> > ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to Spotter > methods > I set the status to "Fix Review needed", > but my changes are integrated in 40475 too! > I think that in the current situation, it is actually a good idea. And yes, the integration does include all latest versions of GT-related packages. Before changing to development, we required a stable release for the integration. That implied: 1. creating a stable release and 2. integrating it in the Pharo through a separate issue. Yet, in GT we all work on the very latest version, and creating a "stable" release is somewhat artificial given the speed at which things are changing now. Creating the "stable" version also led to delays between a fix in GT and an integration in Pharo (sometimes measured in weeks). So, in the case of GT requiring the stable release did not provide any added value, but it has the negative consequence of delays. I am not satisfied with the way external packages are handled. > 1. if there is not one slice/changeset per issue, it is even less likely > someone will > review the changes. > 2. you don't know who works when on a issue. They are solved in a bulk. > 3. a new configuration might not only includes bugfixes but new features > as well. > 4. often we have unbound globals / undeclared references or other test > failures. > > Can we use the build server for those external projects (like > GToolkitCore, Athens, TxText), > and that if a project makes a new configuration, it uses the same > issue validator for loading and testing that configuration? > We already have a GToollkitCore job, but it only runs the GT tests. Perhaps this is not enough? https://ci.inria.fr/moose/job/gtoolkitcore/ But, could the Monkey not be able to run all tests before an integration of the development version? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Feb. 8, 2015

Re: [Pharo-dev] Howto create a new configuration?

by Nicolai Hess

2015-02-07 13:17 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-02-06 22:02 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > >> I have changed two methods of the configuration: >> >> -=-=- >> stable: spec >> <symbolicVersion: #stable> >> >> spec for: #'pharo2.x' version: '2.1'. >> "after some modification in NB made it incompatible with 3.0" >> spec for: #'pharo3.x' version: '2.3'. >> *spec for: #'pharo4.x' version: '2.7â. â<<== added, maybe instead of >> pharo4.x could be common"* >> -=-=- >> development: spec >> <symbolicVersion: #'development'> >> >> spec for: #'common' version: '*2.3-baseline*â. â<<== it is likely not >> necessary" >> -=-=- >> >> I have changed it, because I think there should be two lines in >> Versioner: one with development label, second with stable label. >> Then everything works. >> Let me know if it helps. >> Juraj >> > > Thank you Juraj, > that works .... better, but now, commiting the new configuration > shows a bunch of "Critical Issues" > Critical Warning missing recommend field... > Critcal Warning The name of package x does not match file name x.7 > Critical Warning No Version specified. > .... > > Not that easy. Maybe, the ConfigurationOfAthens was only written and > updated by hand, does not work with Versionner? > > > I think, for now I will try to change the Configuration by hand without versionner.

Feb. 8, 2015

Re: [Pharo-dev] Pharo 4 & NeoCSV

by stepharo

Le 7/2/15 18:48, Sven Van Caekenberghe a Ã©crit : >> On 07 Feb 2015, at 17:21, stepharo <stepharo(a)free.fr> wrote: >> >> sven I'm adding a menu to the configuration browser to define the corresponding repo in MC because I'm tired to add repo manually. > OK. > > I always just load a random small thing to get the repo defined ;-) :) I don't and imagine normal people do the same so now the UI is better Stef > >> Stef >> >> Le 7/2/15 14:19, Sven Van Caekenberghe a Ã©crit : >>> Hi Andreas, >>> >>> I added it. >>> >>> Sven >>> >>>> On 07 Feb 2015, at 13:59, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >>>> >>>> I miss the configuration of NeoCSV in the configuration browser of Pharo 4. Is there any reason for the lack of it? >>>> NeoJSON is available, thoughâ¦ >>>> >>>> Regards >>>> Andreas >>> >> > >

Feb. 8, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

> On 07 Feb 2015, at 21:11, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Sat, Feb 7, 2015 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> On 07 Feb 2015, at 18:29, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >> >> On Fri, Feb 6, 2015 at 10:13 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> I want relationships for certain modeling purposes >> What I like is that we should arrive to get a collection of useful slots with optimal implementation instead all of us reinventing the wheel. >> >> I have started to collect the examples in Slots-Examples (in #481). >> At the start these are artificial (just testing/showing something), but slowly we will add useful ones, too. >> >> I started to implement PropertySlot, this uses hidden slots, initialisation (to set the empty dictionary of the base slot), virtual slots >> (the proper slots), reflectively changing the class both when adding and removing (to add the base slot and remove it as needed). >> > and custom byte code generation to read and write with just #at: and #at:put on the base slotâ¦ > > and remember that the closure bytecodes can access a field without a bounds check > > 140 10001100 kkkkkkkk jjjjjjjj Push Temp At kkkkkkkk In Temp Vector At: jjjjjjjj > 141 10001101 kkkkkkkk jjjjjjjj Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj > 142 10001110 kkkkkkkk jjjjjjjj Pop and Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj Yes! We can make a Slot that stores in a hidden Arrayâ¦ should be very efficient (both space and speed-wise). (of course with Spur no that needed anymoreâ¦) Marcus

Feb. 8, 2015

Re: [Pharo-dev] Spotter idea - exclusion filter and google search syntax

by Ben Coman

On Sun, Feb 8, 2015 at 8:53 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-02-08 0:32 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> Just a random idea for Spotter, being able to exclude items from the >> search using a hyphen/minus sign. >> >> I don't have a use case right now, but it "feels" right, so maybe one >> will turn up soon. Its a broadly used paradigm per google search ( >> https://support.google.com/mail/answer/7190?hl=en) >> >> >> Also, it would be useful to be able to search on multiple terms similar >> to a regular web search. >> >> A slightly contrived use case is that I want to investigate drag handling >> of morphs. So I guess entities will have the word "drag" and then maybe >> "handler" or "handle" but in which order? Will it be #dragHandler or >> #handleDrag or #handleEventDrag or #handlesMouseOverDragging: ? A single >> search term restricts me to having to guess and manually retry each >> possible order. Searching on "drag hand" and getting all possible >> ordering would be real nice. >> >> cheers -ben >> > > +1 for exclusion filter > (You can already combine search terms - sequentiel. > 1. search drag and in the result list (implementors) > 2. search again with the term handler) > > Thanks for the tip, thats cool. Still, doing it from the first window would be more immediate. cheers -ben

Feb. 8, 2015

Re: [Pharo-dev] Spotter idea - exclusion filter and google search syntax

by Nicolai Hess

2015-02-08 0:32 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > Just a random idea for Spotter, being able to exclude items from the > search using a hyphen/minus sign. > > I don't have a use case right now, but it "feels" right, so maybe one will > turn up soon. Its a broadly used paradigm per google search ( > https://support.google.com/mail/answer/7190?hl=en) > > > Also, it would be useful to be able to search on multiple terms similar to > a regular web search. > > A slightly contrived use case is that I want to investigate drag handling > of morphs. So I guess entities will have the word "drag" and then maybe > "handler" or "handle" but in which order? Will it be #dragHandler or > #handleDrag or #handleEventDrag or #handlesMouseOverDragging: ? A single > search term restricts me to having to guess and manually retry each > possible order. Searching on "drag hand" and getting all possible > ordering would be real nice. > > cheers -ben > +1 for exclusion filter (You can already combine search terms - sequentiel. 1. search drag and in the result list (implementors) 2. search again with the term handler)

Feb. 8, 2015