[Click] "Graft" ports
Eddie Kohler
kohler at cs.ucla.edu
Fri Jan 21 19:47:13 EST 2011
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<
>>> philipp_subx at redfish-solutions.com> 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
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
More information about the click
mailing list