bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] gawk 5.0.1 patch to allow *valid* awk variable names to b


From: pjfarley3
Subject: Re: [bug-gawk] gawk 5.0.1 patch to allow *valid* awk variable names to be assigned to SYMTAB
Date: Tue, 15 Oct 2019 15:20:04 -0400

Hi Tom,

Yes, and in fact I have been doing that with my own array, and it is
powerful, as you say.

Consistent spelling accuracy is my bane however, especially when using mixed
case names.  I probably need to use the gawk feature to warn about undefined
variable and array references to keep me on target while debugging new code.

Peter

> -----Original Message-----
> From: Tom Gray <address@hidden>
> Sent: Monday, October 14, 2019 12:14 PM
> To: address@hidden; address@hidden
> Cc: address@hidden
> Subject: RE: [bug-gawk] gawk 5.0.1 patch to allow *valid* awk variable
names
> to be assigned to SYMTAB
> 
> HI Peter,
> 
> Have you considered using your own array instead of SYMTAB[] Lets call it
> mem[] ... to represent some generic storage space.
> Then the index will not have any "nice variable name" restrictions.
> 
>       FNR == 1 { for (I = 1; I <= NF; i++) { mem[$i] = computed_value } }
> 
>       If ((mem[MyVar] > x) && (mem[MyVar] < y)) { do-something
> 
> In my opinion Gawks jagged arrays of arrays are the best thing since
sliced
> bread.
> Combined with recursion and indirect function calls you get incredible
power.
> 
> Do not underestimate the power of portability.  If you write something
cool, you
> want others to be able to use it.
> 
> Tom
> 
> -----Original Message-----
> From: bug-gawk <bug-gawk-bounces+tom_gray=address@hidden> On
> Behalf Of address@hidden
> Sent: Sunday, October 13, 2019 5:25 PM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: [bug-gawk] gawk 5.0.1 patch to allow *valid* awk variable
names
> to be assigned to SYMTAB
> 
> [EXTERNAL]
> 
> Hi Arnold,
> 
> In further testing of my patch to interpret.h, I have found that there is
at least
> one issue no doubt due to my ignorance of the correct structure and
linking of
> Node * structures.
> 
> In short, assigning a number of dynamic field names (e.g., field values
input from
> a file using $1, $2, etc.) into SYMTAB seems to leave all of those
newly-created
> variables pointing to the value of the last one entered into SYMTAB.
> 
> I have not yet nailed down why that happens, but as I said I suspect it is
my
> ignorance of the proper chaining and adjustment of the Node * structures
that is
> at fault.
> 
> Is there any internal developer design documentation on the actual
structure of
> the SYMTAB Node * structures other than the source code itself?  A visual
chart
> of any kind (ASCII art, Visio or any open source equivalent like
LibreOffice Draw
> or Pencil, etc.) would be a great help.
> 
> In particular, for the interpret.h operations Op_subscript_lhs and
Op_stor_sub,
> what value is the "lhs" Node * value pointing at after the assignment "lhs
=
> assoc_lookup(t1, t2);"?
> 
> I apologize for my ignorance about these internal structural issues.  I am
only
> trying to get to the place where I can safely assign dynamically created
variable
> names and then later use their dynamically assigned values, as in for
example:
> 
> FNR == 1 { for (I = 1; I <= NF; i++) { SYMTAB[$i] = computed_value } } #
Where $i
> has been previously verified as a valid gawk variable name value, or
suitably
> adjusted to be one
> 
> Where for instance $4 == "MyVar", and then later in the program I can use
code
> like:
> 
> If ((MyVar > x) && (MyVar < y)) { do-something }
> 
> -- or --
> 
> MyVar ~ /Some-valid-RE/ { do-something }
> 
> I admit that this is a limited use case, but it would be a significant
help in my
> personal projects (not intended for general distribution anywhere).
> 
> Peter
> 
> P.S. -- If I can gain an acceptable level of understanding of the Node *
structures
> and linking and no current visual representation is available, I would be
willing to
> create such a visual representation for the project to use.
> 
> > -----Original Message-----
> > From: address@hidden <address@hidden>
> > Sent: Tuesday, October 8, 2019 9:10 PM
> > To: 'address@hidden' <address@hidden>
> > Cc: 'address@hidden' <address@hidden>
> > Subject: RE: [bug-gawk] gawk 5.0.1 patch to allow *valid* awk variable
> names
> > to be assigned to SYMTAB
> >
> > Hi Arnold,
> >
> > You are welcome.  I do understand about paperwork issues, if needed I
> > will supply anything required.
> >
> > Let me know when you find the round tuits to look over the patch.  I
> > know
> all
> > too well how scarce those can be.
> >
> > Regards,
> >
> > Peter
> >
> > > -----Original Message-----
> > > From: address@hidden <address@hidden>
> > > Sent: Tuesday, October 8, 2019 3:25 AM
> > > To: address@hidden
> > > Cc: address@hidden
> > > Subject: Re: [bug-gawk] gawk 5.0.1 patch to allow *valid* awk
> > > variable names to be assigned to SYMTAB
> > >
> > > Hi.
> > >
> > > Thanks for this. I'll review the patch.
> > >
> > > > I assign any rights I may have in the patch code to GNU.
> > >
> > > Unfortunately, a simple statement such as this in an email just
> > > doesn't work.  If I decide to use the patch, and that the patch
> > > needs paperwork (it might be small enough to not require it) then
> > > you'll have to do a formal assignment of copyright to the FSF.
> > > (It's their code, I have to play by their rules.)
> > >
> > > This process is relatively painless, although often a bit tedious.
> > >
> > > I am busy for the next while, but I'll eventually give this some
> > > attention and get back to you.
> > >
> > > In all cases, *thank you* for wanting to contribute.
> > >
> > > Arnold
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]