Eddie very recently made changes to the parser, allowing for new syntax and types of connections, so I would look at his recent commits.
Cliff On Fri, Jan 28, 2011 at 11:05 AM, Philip Prindeville < [email protected]> wrote: > On 1/21/11 6:48 PM, Eddie Kohler wrote: > >> On 01/21/2011 05:42 PM, Philip Prindeville wrote: >> >>> The original concern (with exposing global objects into the guts of an >>> elementclass) was that this would only work for a single instance is >>> valid... >>> that is, if A imports B, then you can only have a single object of class >>> A. >>> >> >> No, you could have many. But any element of class A will refer to the >> same imported element. Sometimes that's not what you want. Sometimes it >> is. >> >> The idea of "default connections" is interesting -- "include this >> connection only if the port was previously unused." You could get a >> somewhat similar effect with compound element overloading, but only somewhat >> similar. >> >> Eddie >> > > What's involved in coding up a patch for prototype testing? > > I've not looked into the innards of the click parser and intermediate code > generator. > > Thanks. > > -Philip > > > > The advantage of graft points was that you'd have to plumb instances >>> individually, same as for input and output ports. >>> >>> My only point about graft point was that (a) they would simplify keeping >>> track >>> of indices on complex objects (especially for objects that are generated >>> from >>> scripts with variable numbers of inputs and outputs); (b) they would >>> simplify >>> notation by specifying both input and output to the grafted-to object at >>> the >>> same time, and (c) they would impose rules about graft points being used >>> in >>> pairs that doesn't exist for inputs and outputs which are orthogonal to >>> each >>> other (at least with respect to an object's perspective of the outside >>> world). >>> >>> I thought about it some more, and if the default for any unspecified >>> (graft) >>> connection was :: { input -> output } then that would make it very easy >>> to >>> "pepper" an object with various inspection and instrumentation points, or >>> points where you might later want to apply additional processing on a >>> packet >>> as it flows through the innards of a class. >>> >>> I could easily foresee a complex object where I had graft points for: >>> >>> [0] the packet at ingress; >>> [1] the packet after it has SNATting performed; >>> [2] the packet after deep inspection into layer 7 and rewriting of >>> addresses; >>> [3] resetting the timer on the association; >>> ... >>> [n] the packet at egress; >>> >>> And you wouldn't need to recode an object to add to peek into it at >>> various >>> well-known (and previously defined) places. >>> >>> Like I said: graft points are just a notational convenience. At the end >>> of the >>> day, they would just map into pairs of input and output ports... but the >>> implementation would be handled by the preprocessor. >>> >>> >>> On 1/21/11 4:47 PM, Eddie Kohler wrote: >>> >>>> Hey, a couple points. >>>> >>>> (1) Unlike Cliff and Ian, I see some value for importing external >>>> elements >>>> into a compound. Perhaps a statement like "import(ELEMENTNAME)" would be >>>> required. Although new errors could happen, they'd be pretty easy to >>>> understand even now, and the messages could be improved. >>>> >>>> (2) On the below, we generally write debuggers like this: >>>> >>>> // elementclass Debugger {$tag | input -> output}; >>>> elementclass Debugger {$tag | input -> IPPrint($tag, MAXLENGTH 64) -> >>>> output}; >>>> >>>> Then you refer to Debugger as an element. >>>> >>>> I want to note that graft points as used in THIS mail are supported now; >>>> they are implemented as normal inputs and outputs. I don't understand >>>> what >>>> you gain by treating grafts as separate from normal inputs and outputs. >>>> They >>>> must always be connected or there are errors. >>>> >>>> Eddie >>>> >>>> >>>> On 01/20/2011 04:11 PM, Philip Prindeville wrote: >>>> >>>>> One other nice property about graft-points is this: >>>>> >>>>> elementclass MyIncrediblyHairyObject { >>>>> ... >>>>> } >>>>> >>>>> miho :: MyIncrediblyHairyObject; >>>>> ... >>>>> >>>>> miho [0]<-> null :: { input -> output }<-> [0] miho; >>>>> // miho [0]<-> dbg0 :: { IPPrint("Inspection 0", MAXLENGTH=64) }<-> [0] >>>>> miho; >>>>> >>>>> >>>>> and by just moving the comment prefix around, I can turn on or off >>>>> debugging, without having to disturb the body of the elementclass >>>>> itself. >>>>> >>>>> >>>>> >>>>> >>>>> On 1/20/11 3:59 PM, Philip Prindeville wrote: >>>>> >>>>>> I've been thinking about this some more... >>>>>> >>>>>> If I have the following: >>>>>> >>>>>> elementclass Foo { >>>>>> >>>>>> stuff1 -> external-object -> stuff2; >>>>>> >>>>>> } >>>>>> >>>>>> then this can be rewritten as: >>>>>> >>>>>> elementclass Foo { >>>>>> stuff1 -> [N] output; >>>>>> input [M] -> stuff2; >>>>>> } >>>>>> >>>>>> f :: Foo; >>>>>> >>>>>> f [N] -> external-object -> [M] f; >>>>>> >>>>>> I'd like to propose a notational convenience called "graft" (as in a >>>>>> graft-point). >>>>>> >>>>>> graft[0] would be short-hand for 1+ the highest used input, and [0] >>>>>> graft >>>>>> would be 1+ the highest used input. >>>>>> >>>>>> (and so on for [1], [2], etc.) >>>>>> >>>>>> We'd need a new operator for graft-points. Maybe: >>>>>> >>>>>> f [G]<-> [a] external-object [b]<-> [G] f; >>>>>> >>>>>> it would be a syntactic error to mismatch subscripts for the object >>>>>> being >>>>>> grafted to. >>>>>> >>>>>> The notation inside the elementclass would be: >>>>>> >>>>>> elementclass Foo { >>>>>> stuff1 -> graft [G] -> stuff2; // or ... [G] graft ... >>>>>> } >>>>>> >>>>>> Does that make sense? >>>>>> >>>>>> -Philip >>>>>> >>>>>> >>>>>> On 1/18/11 3:43 PM, Beyers Cronje wrote: >>>>>> >>>>>>> The config you posted below Ian explicitly states "This would be >>>>>>> legal:" at >>>>>>> the top. I think Ian is referring to the second config that will >>>>>>> cause >>>>>>> issues: >>>>>>> >>>>>>> " >>>>>>> I think this should complain that fd[0] is being used twice (port >>>>>>> connection error), although it may take a minute to see why that's >>>>>>> the >>>>>>> case (and would be much trickier to see in a more complex config): >>>>>>> -------------------------------------- >>>>>>> fd::FromDevice(...); >>>>>>> >>>>>>> elementclass Bar { >>>>>>> fd[0] -> Print() -> [0]output; >>>>>>> } >>>>>>> >>>>>>> a::Bar() -> Discard(); >>>>>>> b::Bar() -> Discard(); >>>>>>> -------------------------------------- >>>>>>> " >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 19, 2011 at 12:32 AM, Philip Prindeville< >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> On 1/18/11 7:34 AM, Ian Rose wrote: >>>>>>>> >>>>>>>>> If I am thinking this through correctly, IMHO it wouldn't be a good >>>>>>>>> idea >>>>>>>>> to allow elementclasses to do this. Reason being that in some cases >>>>>>>>> you >>>>>>>>> could create port connection errors merely through declaring >>>>>>>>> multiple >>>>>>>>> elements of your new elementclass type. This would be an unexpected >>>>>>>>> and >>>>>>>>> confusing error since its impossible to do currently. AFAIK >>>>>>>>> currently >>>>>>>>> there are no errors that can occur merely by *declaring* too many >>>>>>>>> elements of some type. So this would introduce a whole new category >>>>>>>>> of >>>>>>>>> error. Some examples: >>>>>>>>> >>>>>>>>> This would be legal: >>>>>>>>> -------------------------------------- >>>>>>>>> fd::FromDevice(...); >>>>>>>>> >>>>>>>>> elementclass Bar { >>>>>>>>> fd[0] -> Print() -> [0]output; >>>>>>>>> } >>>>>>>>> >>>>>>>>> a::Bar() -> Discard(); >>>>>>>>> -------------------------------------- >>>>>>>>> >>>>>>>>> I think this should complain that fd[0] is being used twice (port >>>>>>>>> connection error), although it may take a minute to see why that's >>>>>>>>> the >>>>>>>>> case (and would be much trickier to see in a more complex config): >>>>>>>>> >>>>>>>> Sorry, not seeing why the above case represents using the port >>>>>>>> twice... >>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>>> fd::FromDevice(...); >>>>>>>>> >>>>>>>>> elementclass Bar { >>>>>>>>> fd[0] -> Print() -> [0]output; >>>>>>>>> } >>>>>>>>> >>>>>>>>> a::Bar() -> Discard(); >>>>>>>>> b::Bar() -> Discard(); >>>>>>>>> -------------------------------------- >>>>>>>>> >>>>>>>>> In order to cause this same error currently (without the proposed >>>>>>>>> elementclass enhancement) you'd have to do this, which I think >>>>>>>>> makes the >>>>>>>>> error more obvious: >>>>>>>>> -------------------------------------- >>>>>>>>> fd::FromDevice(...); >>>>>>>>> >>>>>>>>> elementclass Bar { >>>>>>>>> input[0] -> Print() -> [0]output; >>>>>>>>> } >>>>>>>>> >>>>>>>>> fd[0] -> a::Bar() -> Discard(); >>>>>>>>> fd[0] -> b::Bar() -> Discard(); >>>>>>>>> -------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> Just my $0.02. >>>>>>>>> >>>>>>>>> - Ian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 01/17/2011 07:55 PM, Philip Prindeville wrote: >>>>>>>>> >>>>>>>>>> Yeah, it especially makes sense to have arpfoo be global if it >>>>>>>>>> needs to >>>>>>>>>> >>>>>>>>> be accessible from two different elementclass's, one that deals >>>>>>>> with the IP >>>>>>>> flow (input [0] and output [0]) and another one that deals strictly >>>>>>>> with >>>>>>>> the >>>>>>>> ARP request/reply flow (input [1] and output [1]). >>>>>>>> >>>>>>>>> Someone else will have to come up with the patches... I've not yet >>>>>>>>>> >>>>>>>>> dabbled in the code itself. >>>>>>>> >>>>>>>>> >>>>>>>>>> On 1/17/11 4:35 PM, Eddie Kohler wrote: >>>>>>>>>> >>>>>>>>>>> Hi Philip, >>>>>>>>>>> >>>>>>>>>>> I can see why you thought compound elements would work that way, >>>>>>>>>>> but >>>>>>>>>>> >>>>>>>>>> they don't. They are very strictly encapsulated: all connections >>>>>>>> to other >>>>>>>> elements must take place through explicit inputs and outputs. >>>>>>>> >>>>>>>>> I admit it would make sense to do it the way you've imagined. >>>>>>>>>>> Patches >>>>>>>>>>> >>>>>>>>>> welcome... >>>>>>>> >>>>>>>>> Eddie >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 1/15/11 2:53 PM, Philip Prindeville wrote: >>>>>>>>>>> >>>>>>>>>>>> I've got a configuration where I do: >>>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> arpfoo :: ARPQuerier(...); >>>>>>>>>>>> >>>>>>>>>>>> elementclass Bar { >>>>>>>>>>>> ... >>>>>>>>>>>> class :: classifier(...); >>>>>>>>>>>> ... >>>>>>>>>>>> class [2] -> [1] arpfoo; >>>>>>>>>>>> ... >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> but it complains that "unknown element class 'arpfoo'" in a few >>>>>>>>>>>> >>>>>>>>>>> places, and that input 1 isn't used... >>>>>>>> >>>>>>>>> So I'm confused. Everything is scoped globally... even stuff >>>>>>>>>>>> defined >>>>>>>>>>>> >>>>>>>>>>> within an elementclass gets scoped globally. >>>>>>>> >>>>>>>>> Why then can't I access a global variable from within an >>>>>>>>>>>> >>>>>>>>>>> elementclass's scope? >>>>>>>> >>>>>>>>> What am I missing? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Philip >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
