myhdl-list

[myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

Jan suggested this feature request 
<https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group_id=91207> 
here on the list.

I suppose "wrapping around" is the default behaviour of any logic. So to 
implement it checkBounds just need to be inhibited.

"Saturate" instead of "wrapping around" makes may DSP circuit behaving 
like an analog circuit. Overflow is not so desasterous in saturate mode 
as in warp around mode. In Python itself a saturate mode is useless as 
there is no minimal and maximal value for integers (and extremly high 
limits for floats).


BTW, I tried the follwing:

---------------------------
class analogbv(intbv):
	
	def _checkBounds():
		return

---------------------------

It does not work, because in _Signal.py _checkBounds from _intbv.py is 
used and not my own _ceckBounds. It is not easy to add new types to myhdl.

Thomas

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Jan D. <ja...@ja...>]

Thomas Traber wrote:

> Jan suggested this feature request 
<https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group_id=91207> here on the list.

It would be useful if anyone that is both doing DSP development and
using MyHDL takes a look at that feature request, and the discussions.

> I suppose "wrapping around" is the default behaviour of any logic.

I see it differently. Wrap around is the behavior of a typical hardware
implementation. Therefore, most hardware designers think that this
is somehow "normal" or even useful. Which is why Verilog regs and
VHDL signed/unsigned behave the way I do.

One of the goals of the intbv type is to show that there is a better way.
It wants to be an int in the first place. If you need wrap-around, it
insists to do this explicitly with a test or a modulo operation.

>  So to implement it checkBounds just need to be inhibited.

As a consequence of the above, no. If you inhibit that test, the intbv
acts as a Python int.

>
> BTW, I tried the follwing:
>
> ---------------------------
> class analogbv(intbv):
>
>     def _checkBounds():
>         return
>
> ---------------------------
>
> It does not work, because in _Signal.py _checkBounds from _intbv.py is used and not my own 
_ceckBounds. It is not easy to add new types to myhdl.


The culprit is the intbv class, not Signal.

The intbv operations return new intbv instances, not instances of the subclass.
It won't work well with subclassing currently. I know I suggested this to you
before. It's not a good idea. Sorry.

Let's try to clarify this. What is your goal - modeling, or also
conversion, synthesis and implementation?

If it's only modeling, there's little need to have this discussion. Just
use your own types. MyHDL - the modelling language for event-driven
hardware systems - is intended to be fully generic. In particular, the Signal
class is intended to work with any data type, not just MyHDL-defined types.

If it's also conversion and implementation, I think you'll have to lower
your expectations drastically. There are a lot of severe restrictions,
similar to restrictions on synthesizable HDL code.

The intbv class is in the middle between the high-level view and the
implementation-oriented view. It's the work-horse for implementation-oriented
code, but it attempts to be higher level than what other HDLs offer for
this purpose.

Now, suppose intbv subclassing would work and you define a subclass with
different behavior. What you cannot expect that this will somehow
magically make it to equivalent converted Verilog. All MyHDL behavior
that is supported by the conversion tools has to be mapped explicitly
(and painstakingly) in them.

Again, I don't know if DSP languages such as Simulink do this (conversion
and implementation), and if they do, it doesn't seem trivial (in general,
for the whole set of operations).

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Tom D. <TD...@di...>]

On Saturday 30 June 2007 03:14:41 am Jan Decaluwe wrote:
> Thomas Traber wrote:
> > Jan suggested this feature request
>
> <https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group
>_id=91207> here on the list.
>
> It would be useful if anyone that is both doing DSP development and
> using MyHDL takes a look at that feature request, and the discussions.


We do a lot of DSP type modeling and logic, and I prefer the way MyHDL handles 
it now, which is throwing an error. 

In all the designs we have done, we either make sure an overflow won't happen 
or test and saturate.

I can't see why you would want it to wrap around for a math application.

I prefer to have my model stop on an overflow, so that i can fix the problem 
as I always consider it a problem if an overflow occurs that isn't saturated.

Tom

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

I agree with Tom. There is not much use of wrap around in a DSP 
application. The only thing I know and where I first encountered this 
problem is a NCO. I tried it in the old fashioned way in myhdl.
For this single problem it is not worth to invest a lot of work in 
modifing _intbv. As I already told, I just considered wrap around as 
normal behaviour. (Jan might be right, when he states, that not applying 
_checkBounds will make myhdl behave like a python int, but the verilog 
code would wap around.)

Jan wrote:
> Let's try to clarify this. What is your goal - modeling, or also
> conversion, synthesis and implementation?

My goal is to use myhdl for doing DSP on an FPGA chip. I want to use 
MyHDL instead of Simulink. I just started to work with QuartusII on a 
Altera Cylcone chip.
Of course, I not only want to programm the FPGA via myHDL, I also want 
to do extensive testing and simulation with myHDL.

> If it's also conversion and implementation, I think you'll have to lower
> your expectations drastically. There are a lot of severe restrictions,
> similar to restrictions on synthesizable HDL code.

Yes, I am currently in the phase of discovering these restrictions and 
unfortunately having some difficulties to distinguish between bug and 
restriction.

> Again, I don't know if DSP languages such as Simulink do this (conversion
> and implementation), and if they do, it doesn't seem trivial (in general,
> for the whole set of operations).

For my current work tasks I can live without that features.
But, of course, it would be great, if myHDL evolves into a real 
alternative for Simulink.

Thomas

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

Picking up an rather old issue again:


In the discussion about the missing wrap around behaviour of intbv I wrote:

> I agree with Tom. There is not much use of wrap around in a DSP 
> application.

I have to withdraw this statement.

Just wanted to implement a CIC filter. For that the wrapping behaviour 
is definitely needed.

I tried to modifiy myhdl. But, as Jan mentioned last year, this is not 
an easy task.
As there is no need to modify the conversion code I thought subclassing 
would help, but I didn't get it to work  - yet.
So, the only short time workaround is to use "__verilog__" and "__debug__".

Any suggestions?



BTW:
__slot__ (without __dict__) in _Signal.py and _intbv.py could be a 
considered good to prevent different behaviour of myhdl code and 
converted code. But I would suggest to allow new attributes and raising 
a warning at conversion time if there is something different.

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Jan D. <ja...@ja...>]

Thomas Traber wrote:
> Picking up an rather old issue again:
> 
> 
> In the discussion about the missing wrap around behaviour of intbv I wrote:
> 
>> I agree with Tom. There is not much use of wrap around in a DSP 
>> application.
> 
> I have to withdraw this statement.
> 
> Just wanted to implement a CIC filter. For that the wrapping behaviour 
> is definitely needed.
> 
> I tried to modifiy myhdl. But, as Jan mentioned last year, this is not 
> an easy task.
> As there is no need to modify the conversion code I thought subclassing 
> would help, but I didn't get it to work  - yet.
> So, the only short time workaround is to use "__verilog__" and "__debug__".
> 
> Any suggestions?

Why can't you use modulo operations ('%')

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

> Why can't you use modulo operations ('%')

I can use it.
As conversion of modulo to Verilog works, I could skip the 
__debug__/__verilog__ clause  - in the hope that the compiler optimizes 
the modulo operation out (not tested yet).

Christopher's hint at putting the comb before the integrator could also 
be useful. But with large decimation rates the delay for this first comb 
grows large too.




Thomas

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Christopher L. F. <chr...@gm...>]

Attached is an example of the CIC filter without using 2's compliment  
wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The  
plot attached is of the frequency response of the filter, green is  
averaged input spectrum and the blue is the averaged output spectrum.   
You can see that after scaling the response is expected for a D=5  
(comb delay = 5) cic filter.  Only simulation thus far, haven't  
converted to Verilog or VHDL.

Note, Because the comb filter is before the integrator (to help  
control infinite gain of the integrator, hence no wrap) cannot take  
advantage of inserting the decimation before the comb filter to  
reduced storage (# registers) for the comb.  this could be a draw  
backs (depending on how you look at it).


Also, for this implementation I had to "hack" the MyHDL space.  This  
is a complete hack (just temporary to do what I wanted to do).  Also  
attached are the diff's that I had to make to allow the numpy types in  
the generator (?).

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Blubaugh, D. A. <dbl...@be...>]

 
Chris,


Please tell us as to when you have finally generated Verilog or VHDL
source code.  This sounds truly interesting to have NUMPY integrated
with the MyHDL environment.  



David


  




-----Original Message-----
From: myh...@li...
[mailto:myh...@li...] On Behalf Of
Christopher L. Felton
Sent: Thursday, July 10, 2008 8:36 AM
To: General discussions on MyHDL
Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap

Attached is an example of the CIC filter without using 2's compliment
wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The
plot attached is of the frequency response of the filter, green is  
averaged input spectrum and the blue is the averaged output spectrum.   
You can see that after scaling the response is expected for a D=5 (comb
delay = 5) cic filter.  Only simulation thus far, haven't converted to
Verilog or VHDL.

Note, Because the comb filter is before the integrator (to help control
infinite gain of the integrator, hence no wrap) cannot take advantage of
inserting the decimation before the comb filter to reduced storage (#
registers) for the comb.  this could be a draw backs (depending on how
you look at it).


Also, for this implementation I had to "hack" the MyHDL space.  This is
a complete hack (just temporary to do what I wanted to do).  Also
attached are the diff's that I had to make to allow the numpy types in
the generator (?).


This e-mail transmission contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you receive 
this e-mail in error, please do not read, copy or disseminate it in any manner. 
If you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Christopher L. F. <cf...@uc...>]

I started (WIP) a wiki page for this, it is more convenient for  
outlining code and displaying plots than the newsgroup, http://myhdl.jandecaluwe.com/doku.php/projects:gcicexample?do=backlink 
.

Example is intended to illustrate parameterizable modules in MyHDL and  
designing the CIC for max gain (no integrator overflows).  Which  
requires more resources (bits and delay elements in the comb) but  
works good for higher order and no overflows.


On Jul 10, 2008, at 8:35 AM, Blubaugh, David A. wrote:

>
> Chris,
>
>
> Please tell us as to when you have finally generated Verilog or VHDL
> source code.  This sounds truly interesting to have NUMPY integrated
> with the MyHDL environment.
>
>
>
> David
>
>
>
>
>
>
>
> -----Original Message-----
> From: myh...@li...
> [mailto:myh...@li...] On Behalf Of
> Christopher L. Felton
> Sent: Thursday, July 10, 2008 8:36 AM
> To: General discussions on MyHDL
> Subject: Re: [myhdl-list] intbv.saturate, intbv.wrap
>
> Attached is an example of the CIC filter without using 2's compliment
> wrapping or modulus.  Adjusted the bitwidth for the maximum gain.  The
> plot attached is of the frequency response of the filter, green is
> averaged input spectrum and the blue is the averaged output spectrum.
> You can see that after scaling the response is expected for a D=5  
> (comb
> delay = 5) cic filter.  Only simulation thus far, haven't converted to
> Verilog or VHDL.
>
> Note, Because the comb filter is before the integrator (to help  
> control
> infinite gain of the integrator, hence no wrap) cannot take  
> advantage of
> inserting the decimation before the comb filter to reduced storage (#
> registers) for the comb.  this could be a draw backs (depending on how
> you look at it).
>
>
> Also, for this implementation I had to "hack" the MyHDL space.  This  
> is
> a complete hack (just temporary to do what I wanted to do).  Also
> attached are the diff's that I had to make to allow the numpy types in
> the generator (?).
>
>
> This e-mail transmission contains information that is confidential  
> and may be
> privileged. It is intended only for the addressee(s) named above. If  
> you receive
> this e-mail in error, please do not read, copy or disseminate it in  
> any manner.
> If you are not the intended recipient, any disclosure, copying,  
> distribution or
> use of the contents of this information is prohibited. Please reply  
> to the
> message immediately by informing the sender that the message was  
> misdirected.
> After replying, please erase it from your computer system. Your  
> assistance in
> correcting this error is appreciated.
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Jan D. <ja...@ja...>]

Christopher L.Felton wrote:
> I started (WIP) a wiki page for this, it is more convenient for  
> outlining code and displaying plots than the newsgroup, http://myhdl.jandecaluwe.com/doku.php/projects:gcicexample?do=backlink 

Thanks - I have added sidebar navigation for this. BTW, this
is done simply through a wiki page called 'sidebar' in a
certain namespace.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Thomas T. <tho...@de...>]

I just started to look at Christophers script.

At first:

Instead of 

 > if not isinstance(obj, list) and not isinstance(obj, numpy.ndarray): 

in his _Waiter.diff, I would prefer the more general approach:

 > if not hasattr(obj,"__iter__"): 

In the hope that it is not too general.

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Christopher L. F. <cf...@uc...>]

Yes, definitely a more general approach was needed.  That looks like a  
good solution.

On Jul 17, 2008, at 2:56 AM, Thomas Traber wrote:

> I just started to look at Christophers script.
>
> At first:
>
> Instead of
>
>> if not isinstance(obj, list) and not isinstance(obj, numpy.ndarray):
>
> in his _Waiter.diff, I would prefer the more general approach:
>
>> if not hasattr(obj,"__iter__"):
>
> In the hope that it is not too general.
>
>
>
>
>
>
>
>
> < 
> _Waiter 
> .diff 
> > 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Jan D. <ja...@ja...>]

Christopher L.Felton wrote:
> Yes, definitely a more general approach was needed.  That looks like a  
> good solution.

Is this patch needed for you new webpage to work? In that case it
should probably be included in the codebase. The procedure that
minimizes my work is as follows :-):

* describe shortly why the patch is needed, what it does
* discuss shortly why it won't break forseeable things
* as a minimum, run test/core to check nothing breaks
* use mercurial to commit and use "hg bundle" to generate a
   patch file to send me

The last step makes it really easy for me to apply and check
the patch. Moreover, it preserves the patch author, so you
get eternal credit for your work :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Christopher F. <cf...@uc...>]

Yes, the fix is needed for the added wiki page.  But I have not posted 
the code that is dependent on the fix, yet.

Thanks for the procedure, sounds good and will do.  I am not familiar 
(yet) with mercurial, I will acquaint myself with the tool.

Sounds like Thomas has taken care of this issue (diff, etc?).

I have seen this issue/error before as well, when the following 
conditional is used in the code

in (posedge, negedge)

  


On Mon, 21 Jul 2008 22:38:04 +0200
  Jan Decaluwe <ja...@ja...> wrote:
> Christopher L.Felton wrote:
>> Yes, definitely a more general approach was needed.  That looks like 
>>a  
>> good solution.
> 
> Is this patch needed for you new webpage to work? In that case it
> should probably be included in the codebase. The procedure that
> minimizes my work is as follows :-):
> 
> * describe shortly why the patch is needed, what it does
> * discuss shortly why it won't break forseeable things
> * as a minimum, run test/core to check nothing breaks
> * use mercurial to commit and use "hg bundle" to generate a
>   patch file to send me
> 
> The last step makes it really easy for me to apply and check
> the patch. Moreover, it preserves the patch author, so you
> get eternal credit for your work :-)
> 
> Jan
> 
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>challenge
> Build the coolest Linux based applications with Moblin SDK & win 
>great prizes
> Grand prize is a trip for two to an Open Source event anywhere in 
>the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Jan D. <ja...@ja...>]

Christopher Felton wrote:
> Yes, the fix is needed for the added wiki page.  But I have not posted 
> the code that is dependent on the fix, yet.
> 
> Thanks for the procedure, sounds good and will do.  I am not familiar 
> (yet) with mercurial, I will acquaint myself with the tool.
> 
> Sounds like Thomas has taken care of this issue (diff, etc?).
> 
> I have seen this issue/error before as well, when the following 
> conditional is used in the code
> 
> in (posedge, negedge)

This would compare using '=='. Thomas has proposed to replace
this with 'is' test. I still don't really see what difference
this would make. Can you explain issue/error that you
are seeing?

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Thomas T. <tho...@de...>]

> This would compare using '=='. Thomas has proposed to replace
> this with 'is' test. I still don't really see what difference
> this would make. Can you explain issue/error that you
> are seeing?

I proposed to remove the tuple because there is a problem with numpy 
comparison.
This is a short test on the interactiv shell.

===============================================
 >>> a=[1,2]
 >>> b=[4,5]
 >>> a in b
   = False
 >>> from numpy import arange
 >>> a = arange(3)
 >>> a in b
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

ValueError: The truth value of an array with more than one element is 
ambiguous.
  Use a.any() or a.all()
=================================================

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Christopher L. F. <chr...@gm...>]

>
>> This would compare using '=='. Thomas has proposed to replace
>> this with 'is' test. I still don't really see what difference
>> this would make. Can you explain issue/error that you
>> are seeing?

> I proposed to remove the tuple because there is a problem with numpy
> comparison.
> This is a short test on the interactiv shell.
>
> ===============================================
>>>> a=[1,2]
>>>> b=[4,5]
>>>> a in b
>   = False
>>>> from numpy import arange
>>>> a = arange(3)
>>>> a in b
> ---------------------------------------------------------------------------
> ValueError                                Traceback (most recent  
> call last)
>
> ValueError: The truth value of an array with more than one element is
> ambiguous.
>  Use a.any() or a.all()
> =================================================

I had not realized that this error was only for numpy arrays as the  
example Thomas provided demonstrates.  I had originally thought this  
would have failed for a list as well.  Is this an issue/error with the  
numpy array?

Here is the snippet of code that I am using that fails.

  @instance
     def stimulus():
         """
         The following is a basic testbench to stimulate the CIC filter
         and create some plots.
         """

         yield clk.posedge
         rst.next = True
         yield delay(10)
         rst.next = False
         yield delay(10)

         for ii in range(Nloops):
             for jj in range(Nfft):
                 x.next = int(L * uniform(-1, 1))
                 xs[jj] = float(x)/L

                 ysave[jj] = float(y._val)/L  # Undo fix-point
                 yield clk.negedge

             favg = favg + abs(fft(ysave, Nfft)) / Nfft
             xfavg = xfavg + abs(fft(xs))/Nfft

         favg = favg / Nloops
         xfavg = xfavg / Nloops

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Jan D. <ja...@ja...>]

Christopher L. Felton wrote:

> I had not realized that this error was only for numpy arrays as the  
> example Thomas provided demonstrates.  I had originally thought this  
> would have failed for a list as well.  Is this an issue/error with the  
> numpy array?

I have applied and pushed Thomas' patch to the main repo, perhaps
you can try it and see if it works.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Christopher L. F. <chr...@gm...>]

I found another instance of the same/similar issue with the numpy  
array while testing the latest change.  After the attached change and  
the latest code from http://myhdl.sourceforge.net/hg/myhdl the code in  
development ran without error.  Also all the test/core passed.

This should be a benign change because the previous code simply tested  
"if obj".  Again the numpy array errors in this test.  Explicitly  
testing that obj is not None, "obj != None" prevented the error.

I created (maybe?) one of those bundle things.  I don't quite have the  
mercurial process down, I did a commit and wasn't able to diff after  
the commit, which I guess make sense since there isn't no difference.   
But I wasn't sure what bundle did?  So I have a bundle before commit  
and after. Figured it would take me a little longer to review the  
documentation and didn't want to hold up the changes.

[myhdl-list] Adding new files

[Christopher L. F. <cf...@uc...>]

What is the best way to add new files in mercurial?  I added a simple  
makefile for cver on OS X.  The file is attached, this was based on  
the makefile.lnx should be straight forward.

[myhdl-list] Adding new files

[Christopher L. F. <cf...@uc...>]

What is the best way to add new files in mercurial?  I added a simple  
makefile for cver on OS X.  The file is attached, this was based on  
the makefile.lnx should be straight forward.

Re: [myhdl-list] Adding new files

[Jan D. <ja...@ja...>]

Christopher L. Felton wrote:
> What is the best way to add new files in mercurial?  I added a simple 
> makefile for cver on OS X.  The file is attached, this was based on the 
> makefile.lnx should be straight forward.

hg add <yourfile>
hg commit

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Jan D. <ja...@ja...>]

Christopher L. Felton wrote:
> I found another instance of the same/similar issue with the numpy array 
> while testing the latest change.  After the attached change and the 
> latest code from http://myhdl.sourceforge.net/hg/myhdl the code in 
> development ran without error.  Also all the test/core passed.

I believe you and have applied/pushed it.

> This should be a benign change because the previous code simply tested 
> "if obj".  Again the numpy array errors in this test.  Explicitly 
> testing that obj is not None, "obj != None" prevented the error.

... though I think the idiomatic test should be 'obj is not None'.

> I created (maybe?) one of those bundle things.  I don't quite have the 
> mercurial process down, I did a commit and wasn't able to diff after the 
> commit, which I guess make sense since there isn't no difference.

Of course, both commit and diff are local in your local repository.

All distributed revision control systems differ from centralized ones
in that they add a "second level" of commands. Some commands work
locally in your local repo's, some work between repo's. This is a
point that you'll have to understand in order to use it effectively.

 > But I
> wasn't sure what bundle did?  So I have a bundle before commit and 
> after. Figured it would take me a little longer to review the 
> documentation and didn't want to hold up the changes.

Look at it this way. After a (local) commit, you may want to publish
your changes, right?

To see the changes between your local repo and the parent repo:

hg out   # use the -vp option to review the patch

Now you would want to do:

hg push

to propagate your changes to the parent repo, just as you do
'hg pull' to download changes from the parent repo.

Except, this won't work for the myhdl repo at sourceforge. You can't
push to a http url, and moreover, I wouldn't let you :-)

Think of 'hg bundle' as an 'hg push' with me in the middle :-) It
does a similar thing, except that you have to send me the bundle file
and let me do the pull/push (after reviewing).

It's probably clear now why your pre-commit bundle didn't contain
any changesets, and why your post-commit bundle had the change
you described.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] _Waiter.diff [was: intbv.saturate, intbv.wrap]

[Christopher L. F. <cf...@uc...>]

>
>
>> This should be a benign change because the previous code simply  
>> tested
>> "if obj".  Again the numpy array errors in this test.  Explicitly
>> testing that obj is not None, "obj != None" prevented the error.
>
> ... though I think the idiomatic test should be 'obj is not None'.

Thanks for the hg information!  So I created another bundle that used  
the test "obj is not None" as you pointed out.  And includes the  
makefile.  Ran the tests again.