Thread: [myhdl-list] MEP-108 Bundle
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Christopher F. <chr...@gm...> - 2012-05-30 02:25:22
Attachments:
mep_108.hg
|
Attached is the MEP-108 patch. This patch is to add support for the conversion of top-level methods. Description of the enhancement can be found here, http://www.myhdl.org/doku.php/meps:mep-108 Regards, Chris Felton |
|
From: Jan D. <ja...@ja...> - 2012-05-30 14:46:16
|
On 05/30/2012 04:25 AM, Christopher Felton wrote:
> Attached is the MEP-108 patch. This patch is to add support for the conversion of top-level methods.
When I do
hg in mep_108.hg
I get:
comparing with /home/jand/mep_108.hg
abort: 00changelog.i@d61bf91023b7: unknown parent!
Probably this means that the bundle was created against some
other repo of yours with changesets not in the public repo.
In that case, I think the solution is to list the public
repo explicitly when creating the bundle:
hg bundle mep_108.hg http://hg.myhdl.org/myhdl
The goals is to bundle all changesets not in the public repo.
Reviewing bundle contents is a little inconvenient but can
be done within a fresh clone of the public repo:
http://myhdl.org/doku.php/dev:patches#reviewing_bundle_content
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com
|
|
From: Christopher F. <chr...@gm...> - 2012-05-31 01:07:47
Attachments:
mep_108_take2.hg
|
On 5/30/12 9:45 AM, Jan Decaluwe wrote: > On 05/30/2012 04:25 AM, Christopher Felton wrote: >> Attached is the MEP-108 patch. This patch is to add support for the conversion of top-level methods. > > When I do > > hg in mep_108.hg > > I get: > > comparing with /home/jand/mep_108.hg > abort: 00changelog.i@d61bf91023b7: unknown parent! > > Probably this means that the bundle was created against some > other repo of yours with changesets not in the public repo. > In that case, I think the solution is to list the public > repo explicitly when creating the bundle: > > hg bundle mep_108.hg http://hg.myhdl.org/myhdl > > The goals is to bundle all changesets not in the public repo. > > Reviewing bundle contents is a little inconvenient but can > be done within a fresh clone of the public repo: > > http://myhdl.org/doku.php/dev:patches#reviewing_bundle_content > > > It should have the correct parent now. Clone a fresh from the public and reviewed in hg in. Should work this time. Thanks, Chris |
|
From: Jan D. <ja...@ja...> - 2012-05-31 20:17:20
|
On 05/31/2012 03:07 AM, Christopher Felton wrote: > > It should have the correct parent now. Clone a fresh from the public and reviewed in hg in. Should work this time. Ok, published. I think we should have a go at MEP 108 to remove the confusing "class attribute" terminology. Perhaps the explanations make it less clear than just stating what this MEP is about. Perhaps we should just talk about a method at the top level - I understand methods at lower levels already worked without this MEP. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-06-24 16:46:45
|
On 6/15/12 4:07 AM, Jan Decaluwe wrote: > On 06/01/2012 03:35 AM, Christopher Felton wrote: > >>> I think we should have a go at MEP 108 to remove the >>> confusing "class attribute" terminology. Perhaps the >>> explanations make it less clear than just stating what >>> this MEP is about. Perhaps we should just >>> talk about a method at the top level - I understand >>> methods at lower levels already worked without this MEP. >>> >> >> Sounds good, I should have some time tomorrow to work >> through the modifications you suggested. > > About the "self" argument: the MEP says that the > implementation looks for this argument and assumes it > has the usual meaning. This is just fine with me, > provided it is the *first* argument as per convention. > Probably this is what the implemenation does? If not, > it should, and the documentation should be adapated > also. > > There are two locations in the code that were modified. First, the top-level visitor. These modifications didn't require the use of the "self". The second in the extract hierarchy , the original code uses a different mechanism (not ast) to determine if user defined code is present. The modifications here do not enforce the "self" as the first argument. The code where the changes were added uses the python profile extraction to identify a function on a return event. For a method, the "func" from the global space would be None, if that was the case then self was retrieved from the local space and funcname was checked as an attribute. What does this all mean, it means it doesn't enforce "self" to be the first position but it will only use self if it has the /function/ that it is looking for (funcname). If the code fails to find the funcname in the global space or as an attribute (method) of "self" in the localspace. I will investigate if there is a mechanism to also verify "self" is the first argument. I tried to find a means to not use "self" but with the profile extraction I was not successful. Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-06-25 08:56:20
|
On 06/24/2012 06:46 PM, Christopher Felton wrote: > On 6/15/12 4:07 AM, Jan Decaluwe wrote: >> On 06/01/2012 03:35 AM, Christopher Felton wrote: >> >>>> I think we should have a go at MEP 108 to remove the >>>> confusing "class attribute" terminology. Perhaps the >>>> explanations make it less clear than just stating what >>>> this MEP is about. Perhaps we should just >>>> talk about a method at the top level - I understand >>>> methods at lower levels already worked without this MEP. >>>> >>> >>> Sounds good, I should have some time tomorrow to work >>> through the modifications you suggested. >> >> About the "self" argument: the MEP says that the >> implementation looks for this argument and assumes it >> has the usual meaning. This is just fine with me, >> provided it is the *first* argument as per convention. >> Probably this is what the implemenation does? If not, >> it should, and the documentation should be adapated >> also. >> >> > > There are two locations in the code that were modified. First, the > top-level visitor. These modifications didn't require the use of the > "self". > > The second in the extract hierarchy , the original code uses a different > mechanism (not ast) to determine if user defined code is present. The > modifications here do not enforce the "self" as the first argument. The > code where the changes were added uses the python profile extraction to > identify a function on a return event. For a method, the "func" from > the global space would be None, if that was the case then self was > retrieved from the local space and funcname was checked as an attribute. > > What does this all mean, it means it doesn't enforce "self" to be the > first position but it will only use self if it has the /function/ that > it is looking for (funcname). If the code fails to find the funcname in > the global space or as an attribute (method) of "self" in the localspace. Perhaps that is an indirect check of the conventional use of self, including the position? > I will investigate if there is a mechanism to also verify "self" is the > first argument. I tried to find a means to not use "self" but with the > profile extraction I was not successful. Mm, in any case it looks like a very minor issue (if any) and I don't want to cause too much extra effort on it. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-06-01 01:36:09
|
On 5/31/12 3:16 PM, Jan Decaluwe wrote: > On 05/31/2012 03:07 AM, Christopher Felton wrote: > >> >> It should have the correct parent now. Clone a fresh from the public and reviewed in hg in. Should work this time. > > Ok, published. > > I think we should have a go at MEP 108 to remove the > confusing "class attribute" terminology. Perhaps the > explanations make it less clear than just stating what > this MEP is about. Perhaps we should just > talk about a method at the top level - I understand > methods at lower levels already worked without this MEP. > Sounds good, I should have some time tomorrow to work through the modifications you suggested. Regards, Chris |
|
From: Christopher F. <chr...@gm...> - 2012-06-01 19:43:53
|
>> >> I think we should have a go at MEP 108 to remove the >> confusing "class attribute" terminology. Perhaps the >> explanations make it less clear than just stating what >> this MEP is about. Perhaps we should just >> talk about a method at the top level - I understand >> methods at lower levels already worked without this MEP. >> > > Sounds good, I should have some time tomorrow to work > through the modifications you suggested. > Ok, I was updating MEP-108 and saved and now I can't access myhdl.org? Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-06-01 21:37:38
|
On 06/01/2012 09:43 PM, Christopher Felton wrote: >>> >>> I think we should have a go at MEP 108 to remove the >>> confusing "class attribute" terminology. Perhaps the >>> explanations make it less clear than just stating what >>> this MEP is about. Perhaps we should just >>> talk about a method at the top level - I understand >>> methods at lower levels already worked without this MEP. >>> >> >> Sounds good, I should have some time tomorrow to work >> through the modifications you suggested. >> > > Ok, I was updating MEP-108 and saved and now I can't > access myhdl.org? ? didn't notice any issues -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-06-02 12:42:30
|
On 6/1/12 4:37 PM, Jan Decaluwe wrote: > On 06/01/2012 09:43 PM, Christopher Felton wrote: >>>> >>>> I think we should have a go at MEP 108 to remove the >>>> confusing "class attribute" terminology. Perhaps the >>>> explanations make it less clear than just stating what >>>> this MEP is about. Perhaps we should just >>>> talk about a method at the top level - I understand >>>> methods at lower levels already worked without this MEP. >>>> >>> >>> Sounds good, I should have some time tomorrow to work >>> through the modifications you suggested. >>> >> >> Ok, I was updating MEP-108 and saved and now I can't >> access myhdl.org? > > ? didn't notice any issues > Good, it looks like it was some weird ISP problem here. Half the websites were accessible and email worked fine, hmmm. ISP is behaving now, I updated MEP-108. Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-06-15 09:07:59
|
On 06/01/2012 03:35 AM, Christopher Felton wrote: >> I think we should have a go at MEP 108 to remove the >> confusing "class attribute" terminology. Perhaps the >> explanations make it less clear than just stating what >> this MEP is about. Perhaps we should just >> talk about a method at the top level - I understand >> methods at lower levels already worked without this MEP. >> > > Sounds good, I should have some time tomorrow to work > through the modifications you suggested. About the "self" argument: the MEP says that the implementation looks for this argument and assumes it has the usual meaning. This is just fine with me, provided it is the *first* argument as per convention. Probably this is what the implemenation does? If not, it should, and the documentation should be adapated also. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X