gEDA-dev: Broken slotting

Steve Meier smeier at alchemyresearch.com
Tue Sep 11 22:38:03 EDT 2007


Peter Clifton wrote:
>> //----------------------------------------------------------------
>> // compare two attribs to see if the have equivellent values
>> BOOL s_attrib_compare(ATTRIB *first_attrib, ATTRIB *second_attrib);
>>     
> Could do - where is it desired in the code though? I'm not saying it
> won't be useful - just there is no point adding it unless multiple code
> use-cases would benefit from it.
>   

I use it from a method

//-------------------------------------------------------------------
// if the two pins have the same hierarchical reference designator and
// pin number then return TRUE else return FALSE
// we also expect the parents object type to be a complex

BOOL o_pin_compare(OBJECT *first_pin, OBJECT *second_pin)

Specifically I want to know if two hierarchical nets are the same net?
They are if they share a pin. They can share a pin if one pin is from a
symbol pin and the other is from a schematic which has a hierarchical
i/o complex object.



>   
>> //----------------------------------------------------------------
>> // search the attributes of an object for one named by name
>> // return the value of the attribute of the first one found
>> // be sure caller free's return value
>> char *s_attrib_search_name(GList *list, char *name, int counter);
>>     
> What is the GList of? Attributes? Objects? How does counter work in
> either of those cases? 'n'th object with an "x" attribute. Does this
> work as intended if objects have multiple "x" attributes?
>
>   
The GList is a list of ATTRIB pointers. For each complex object I keep
two lists. One from the symbol file one from the schematic file. This
method doesn't care which list I give it to search.

>> //----------------------------------------------------------------
>> // for a complex object, find the value of the slot attribute
>> // be sure caller frees string
>> char *s_attrib_search_slot(OBJECT *object);
>>     
> No. Special case-tastic. If anything, we could make an {s|o}_slot.c and
> define slotting API there. Slots _use_ attributes, but aren't necessary
> in the attribute API its-self.
>
>   

I agree, slots probably should have their own structure and thus API

>> //----------------------------------------------------------------
>> // for a complex object, find the number of slots the object has
>> int s_attrib_search_numslots(OBJECT *object);
>>     
> Again, special case slot stuff.
>
>   
>> //----------------------------------------------------------------
>> // for a complex object, find which slot is the default slot
>> int s_attrib_search_default_slot(OBJECT *object);
>>     
> Again, special case slot stuff.
>
>   
>> //----------------------------------------------------------------
>> // return the pin type object that matches the sequence pin_number
>> // the list is a list of pins
>> // caller should not destroy the returned object
>> OBJECT *s_attrib_search_pinseq(GList *list, int pin_number);
>>     
> Again, special case slot stuff really.
>
>   
>> //----------------------------------------------------------------
>> // from a list of attributes find the slot deffinition string
>> // that coresponds to the slot number be sure caller frees string
>> char *s_attrib_search_slotdef(GList *attrib_list, int slotnumber);
>>     
> Again, special case slot stuff.
>
>   
>> //-----------------------------------------------------------------
>> // for an attribute GString determine its name and value
>> // if the name and value are non-null strings
>> // return TRUE else return false
>> // set the returned name and value function call perameters as well
>> BOOL s_attrib_get_name_value(GString *string, char **name, char **value);
>>     
> I'd stick with char* string personally.
>   

I am sure I did this out of being lazy.
>   
>> //----------------------------------------------------------------
>> // search the attributes of an object for oned named by name
>> // return the value of the attribute of the first one found
>> // be sure caller free's return value
>> char *s_attrib_search_name_single(OBJECT *object, char *name);
>>     
> How is this different to s_attrib_search_name(..) above? I guess its
> possible one will be used to implement the other.
>   

pre-existing code. This might only be used inside the s_attrib module
and thus shouldn't be publically exposed.
>   
>> //----------------------------------------------------------------
>> // find the text object that matches the string
>> // the caller should NOT destroy the returned OBJECT
>> OBJECT *s_attrib_search_string_list(GList *list, char *string);
>>     
> I don't like the name - implies we're searching for one of a list of
> strings. I'm not 100% sure where this API would be used.
>   

This is only used within s_attrib module and thus shouldn't be
publically exposed.

>   
>> //----------------------------------------------------------------
>> // find the pin number for a pin from a complex object with respect to a
>> slot number
>> // be sure caller free's return value
>> char *s_attrib_pin_sequence_slot_pinnumber(OBJECT *object, OBJECT
>> *pin_object, int slot);
>>     
> Special case slot stuff.
>
>   
>> //-----------------------------------------------------------------------------------------
>> // find the nth occurence starting from zero of the search_for string in
>> the list of attribs
>> // it is the responsibility of the caller to free the returned string
>> // returned string is the found value
>>
>> gchar *s_attrib_search_string_partial(GList *attribs, gchar *name, gchar
>> *partial, int nth);
>>     
> The name isn't clear, nor is the functionality. How is this different to
> s_attrib_search_string_list(...)? Could we combine their functions?
>
>   
see the above comments

>> //-------------------------------------------------------------------
>> // Search for the nth occurance of the attribute, starts from ZERO!
>> // zero being the first occurance
>> // caller is responsible for freeing returned string
>>
>> gchar * s_attrib_search_outside(GList *attribs, gchar *name, int
>> nth_occurance_value);
>>     
> Isn't clear what this function does, or why the other API can't do this.
>
>   

see the above comments
>> //-------------------------------------------------------------------
>> // test to see if a specific pin exists in a net attrib
>>
>> BOOL s_attrib_net_attrib_contains_pin(ATTRIB *net_attrib, gchar *pinnumber);
>>     
> I'm not sure what code would use this, anyhow - it seems like a special
> case for some function other than {s|o}_attrib.c
>
>   

this is such a special case method so crittically important that it
isn't used at all.

>> //-------------------------------------------------------------------
>> // use the viewer application graphic routines to draw the attribute in
>> the desired graphics context
>>
>> void s_attrib_draw(ATTRIB *this_attrib, BOOL color_mode, hidGC gc);
>>     
> Not in libgeda, although we do want some generic mechanism for notifying
> the client (gschem, gattrib, other..) of updates. This isn't attribute
> specific though.
>   

Here I disagree, This assumes, that a drawing method has been regestered
with the library and it is asking that the attribute draw itself by
calling that method.

In general, I am registering drawing methods with the library and asking
that a page draw itself. The page asks all of it's symbols, net
segments, bus segments, etc to draw them selves. They don't really draw
themselves they just call a regestered method and say hay here is the
info you need to draw me.

>
> Regards,
>
>   
At any rate taking this into account I will restructure my library and
rebuild my netlister and (very preliminary schematic capture like I can
draw schematics with text out of joint and zoom and pan) No select cut
copy paste insert or edit yet.

Steve Meier


More information about the geda-dev mailing list