* Map Life Facts plugin

[Ron Melby]

Mike, I am sorry, this may not be enough information for you, however, this is what I am able to relate.

BACKGROUND
I have a csv system for place and address fields in my gedcom, missing parts are void values (not nil) that is comma followed by comma ,, as placeholders for my plugin processing. I often stare and compare everything to make sure there are n extraeneous spaces or missing commas via reports and work with data.

in MLF I use the Place fields only and Address fields only options.

PLAC fields are:
city/town,village, township/metro, county, state, nation
examples:
Bethersden,, Kent, EN, GBR
Limehouse, London, London, EN, GBR

ADDR fields are:
Building, Address, City, State, Zipcode/Postal Code/City Code, Nation
examples:
St. Mildred's Church, Church Road, Tenterden, EN, TN30 6AT, GBR
, 30197 CO Road 54, Grygla, MN, 56727, USA
Hønefoss Kirkegård, Kirkegata 12, Hønefoss, NO, 3510, NOR

Some time ago we had a discussion about special values I use...
[*Burial unidentified] and [*Cremated]
I am attempting to upgrade these where I can

any of these I can make a guess where they were buried or cremated I change
place is changed to the form:
[*Burial unidentified],,, EN, GBR
after a day of that I thought the better of it and changed the place to the form:
,,, EN, GBR
this left me with several 0 link places.
easy enough to sort by links and merge with a valid place to remove.


PROBLEM
ADDR:
[*Burial unidentified],,, EN,, GBR

[*Burial unidentified],,, ON,, CAN
as you know you reduce the ADDR to:
[*Burial unidentified], ON, CAN


for this next part, I will represent the space as <sp> where necessary.

every so often I would run a report after updating several records.
I noticed among the 'soft' errors that I had entered;
[*Burial unidentified],,,<sp> ON,,<sp><sp> CAN
work with data addresses and fixed the extra space (I only have one of these)

I believe I had several other minor fixes in the bunch, and then went into Map Life Facts to update place only and address only and it created a duplicate Facts Address sources were 43451 (original) and (43458 (fix) a duplicate:
[*Burial unidentified], ON, CAN

Since my GPS program works off your Facts Address entries adding information where needed it errored. I removed the 43451 entry, (and unfortunately ran MLF again, so I cannot give you the data file.

[tatewise]

Sorry for the delay in replying to this it got overlooked.

You mention that changing [*Burial unidentified],,, EN, GBR to ,,, EN, GBR left you with several 0 link places.
I suspect that is because you changed Fact Place fields instead of using the recommended Tools > Work with Data > Places dialogue or the Records Window > Places tab, which change the name of existing Place records and retain the links.
If you change Fact Place fields that creates new Place records and leaves the old Place records with 0 links.

I don't understand your PROBLEM description:

... it created a duplicate Facts Address sources were 43451 (original) and (43458 (fix) a duplicate:
[*Burial unidentified], ON, CAN

What are Facts Address sources and where do those numbers appear?

[Ron Melby]

the numbers are the @Snnnn@ numbers
they appeared in the Sources using Address Fields Only as Fact Addresses

regarding the zero link places, its going to happen since there is no reasonable way to change say.... 1/2 of them only.

[tatewise]

I guess that when using Locations From: Address Fields Only you have set the Database In: Source Records.
So if any Address text changes, Map Life Facts must create a new Source record for each new Address.

Regarding changing Place names, let us assume you have a Place named ABC (the details don't matter).
You want some Facts to continue using Place ABC but want other Facts to change to use Place XYZ.

So in the Records Window on the Places tab, create a new Place record for XYZ and copy any desired details such as Lat/Longitude from Place record ABC.

To change some Facts to use XYZ, in the Property Box click the [...] button to the right of the Place: ABC and Select the XYZ entry from the Place List. Repeat for each Fact Place that needs changing.
That will avoid 0 links for Place records

[Ron Melby]

this is a new discussion, but it doesnt seem to need a new thread, since it is about undertanding Map Life Facts, which I am trying to understand, because it seems like useful code for a plugin I am tring to make:

1. local function stringx_v3() -- this returns the function
2. local fh = {} -- Local environment table
<code> </code>
3. return fh -- what does returning the Local environment table do??
end -- local function stringx_v3

4. local stringx = stringx_v3() -- To access FH string extension module and variables

**QUESTION:
what is the purpose of 2 and 3?

thanks.

[tatewise]

That is the standard way of building a reusable library module.
All the data and functions are held in the table fh which is returned to the user when they call stringx_v3().
Then in this case the local stringx variable refers to that table.

If the user wishes to call a function such as xyz() defined within the module they use stringx.xyz()

i.e. It is just the same as say the iup library module where you invoke its functions using say iup.SetGlobal(...)

[Ron Melby]

still confused isnt that what
local stringx = stringx_v3() does?

[tatewise]

It uses what is known as a Function Prototype Closure.
The library function stringx_v3() defines the table local fh = {} and inserts functions and data into that table.
Many of my plugins all contain that same function stringx_v3() so I know they all behave the same way.

So inside the function stringx_v3() there will be a definition of function fh.split(strTxt,strSep)
There will also be internal local variables and functions that are not visible outside the function stringx_v3()

Only when the user calls the function stringx_v3() will the table local fh = {} become populated.

That function returns a pointer to the table fh which is assigned to local stringx.
So the table stringx now also points to fh and thus all the defined functions.

See the FHUG KB Progress Bar Function Prototype Version which is an example of the same Function Prototype library module concept where table local tblProgressBar in function NewProgressBar(tblGauge) is returned at the end and performs the same role as the table local fh in stringx_v3().

[Ron Melby]

Mike,
I am bedeviled.
this is too complex to fathom the concept.
I cannot debug it such that the fh would match with say, stringx
it seems kind of like fh builds as each general. stringx. iter. and so on is called, and eventually fh would contain all the fh modules and variables for all of them, and I would not expect that, seeing that fh is local to each module. I would expect them to be 'static' within themselves. but what I think I see, is that what is happening?

do you have an extremely simple plugin that is easier to track what is happening?

[tatewise]

You are correct that fh is a local table that holds the functions, etc, assigned to it.
The table fh inside each module is completely independent of any other variable with the same name.

Tables are handled as pointers so stringx points to the same table as fh points to.

Attached is a very simple example of a Function Prototype Closure module.

The function prototype Welcome encapsulates the table fh, the variable strWho, and the two functions.

It remembers strWho and returns the table fh to the local table say.
Notice that strWho and fh are not visible outside the Welcome function because they are local variables.

Run the plugin in debug mode with a breakpoint on line 12 function Welcome( strWho ) then Step Into each statement one by one and review all the variables.

[Ron Melby]

(I think I am as far as your simple plugin ...)
my issue is 'among the several'
Here is my confusion at the moment and it might seem arcane, but it is fundamental to understanding for me
*** in the explanation below
Map Life Facts


this is in iup_gui

3102 local function getDataFiles(strScope) -- Compose the Plugin Data file & path & root names
3103 --! local strPluginName = strToANSI(fh.Plugin) -- V4.0
3104 local strPluginName = fh.Plugin
3105 local strPluginPlain = stringx.plain(strPluginName)
3106 local strDataFile = getPluginDataFileName(strScope) -- Allow plugins with variant filenames to use same


set breakpoints at 3104, 3105, 3106
go

3104
fh in debug belongs to iup_gui (and it is visible)
general and stringx have been executed at this point in some other functions thats ok, just trying to understand what its gonna look like at a change

advance to
3105
to change, so no lua compiler monkey business going on.

step into
3105 going into stringx.

it will execute
function fh.plain(strTxt)
-- Prefix every magic pattern character with a % escape character,
-- where %% is the % escape, and %1 is the original character capture.
strTxt = tostring(strTxt or ""):gsub(strMagic,"%%%1")
return strTxt
end -- function plain

which is in the fh of stringx

****no fh on debug and no general or stringx on debug, fh(stringx) and stringx. should show, no?
is this an fh.debug error or is there some other explanation?
that leads to, when to call fh.plain and when to call stringx.plain***
I have additional questions based on some things you wrote in progress bar, (scoping stuff) but they will wait.

so step to return
now I am at but have not executed 3106
fh (iup_gui) stringx. and general. show again

[tatewise]

****no fh on debug and no general or stringx on debug, fh(stringx) and stringx. should show, no?
is this an fh.debug error or is there some other explanation?
that leads to, when to call fh.plain and when to call stringx.plain***

The variables general and stringx are not in scope here at line 69 because they are local variables not defined until later on lines 957 and 238 respectively. Local variables are never shown in debug prior to their definition. That is absolutely normal.

The table fh is not local to the function on line 69 but is known as an upvalue local to function stringx_v3().
If you insert a statement here such as local xyx = fh that uses fh then debug does list fh.

Conversely, if you remove the reference to upvalue strMagic then it is no longer listed here in debug.

Only call fh.plain within function stringx_v3() where fh is defined. Just like strMagic only exists here.
That fh only exists here and does not exist elsewhere. Also, stringx does not exist here.

Only call stringx.plain on lines greater than 238 after local stringx is defined which is the usual scope rule.
The fh defined local to function stringx_v3() does not exist here.

Just get used to the fact that fh and stringx both point to the same table of functions but with different scope.

[Ron Melby]

and that is what I am trying to figure is scope.

version_of_something = 5.9.1
local another

general_v3 (the whole thing)
stringx_v3 (the whole thing)
now does this follow normal compiling rules where
global version_of_something and local another are available to general_v3 and stringx_v3?

[tatewise]

Yes, but see the code below.
Inside function general_v3 (the_whole_thing) the debug does not show another even though it is in scope.
Inside function stringx_v3 (the_whole_thing) the debug shows another as an upvalue because it is used there.

Code: Select all

version_of_something = '5.9.1'
local another

function general_v3 (the_whole_thing)
	local zz = 0
end

function stringx_v3 (the_whole_thing)
	another = 0
end

general_v3 ( )
stringx_v3 ( )