Hashme things to watch out for

[LaserJon]

I thought I’d share some issues I ran into using the @hashme decorator, but was able to solve in my code. I believe at this time the best way to use @hashme is with the following pattern:

@hashme('samplecell','variable1','variable2',...)
def samplecell(variable1, variable2, ...):
    with nd.Cell(hashme=True) as cell:
        #INSERT CODE HERE
        #INSERT CODE HERE
    return cell

Things deviating from this pattern that screwed up the code/layout were:
1) Inserting a call to another @hashme decorated function inside of samplecell, before the “with nd.Cell(hashme=True) as cell:” line. If I remember correctly this generates an error
2) Instead of ending with “return cell”, something like “return wrapper(cell)”, where wrapper was another @hashme decorated function that added tapers to the ports to change their width.

The dangerous thing about (2) is that it did not generate an error. In my case I found that the first call to samplecell worked correctly, but in subsequent calls, the unwrapped cell was returned and placed in the layout. I’m not sure if this would be considered a bug, but it’s definitely something to watch out for.

Jon

[Ronald]

Dear Jon,

The hashme syntax to use is indeed as described in your code snippet, and as described in the hashme tutorial.

The decorator stores the function profile on a 1-level deep stack. This information is consumed by the first nd.Cell() encountered (possibly unwanted in a subroutine), and deleted at function closure.

In case (1) you describe, the nested hashme calls, the second hashme will override the first, so by the time you want to use the first, it is gone. This can be avoided placing calls after the with nd.Cell() statement. Note that hashme=True keyword assignment is optional in newer Nazca versions since about 2020.

In case (2) I think the hashme is not closed yet and this messes up the stack.

Hence, the hashme creates a 1-level max deep stack and this info is consumed by the first nd.Cell() statement. The stack can probably be made deeper to allow for nested calls to work as well (although a similar result can be achieved by placing function calls in a decorated function after the with statement as mentioned, but the designer has to do the housekeeping).

Ronald

[LaserJon]

Hi Ronald,

Thank you for explaining how it works with the 1-level max deep stack.

By the way I was able to do a pretty simple change to my code to get around these issues every time it occurred. It was just a matter of figuring out the issue, and now I know how to avoid it.

Best,
Jon

[Author]

Posts