[M3devel] release 3.6, and history

[Rodney M. Bates]

On 06/28/2016 11:08 PM, Jay K wrote:
> I'm wondering:
>   - if anyone has the 3.6 release, can make it available?
>   - I can probably find it. We can put it on github?
>
> And more so, history prior to 3.6? And between 3.6 and 4.0?
>
> Or if Bill Kalsow is still around and available to ask questions?
>
> The Scanner thing is wierd to me.
>
> I do see some changes..maybe I did this..
>
> old version:
> PROCEDURE Here (VAR file: TEXT; VAR line: INTEGER) =
> BEGIN
> file := files [offset DIV MaxLines];
> line := offset MOD MaxLines;
> END Here;
>
> PROCEDURE LocalHere (VAR file: TEXT; VAR line: INTEGER) =
> VAR fnum := offset DIV MaxLines;
> BEGIN
> IF (local_files[fnum] = NIL) THEN
> local_files[fnum] := Host.FileTail (files[fnum]);

                        ^------------------------
This explains it.  As currently coded, Here and LocalHere always just
return the same VAR parameter results, with LocalHere having the side
effect of copying the file name from array files to local_files.  But
local_files isn't used any other way, so the only effect is that a
subsequent call to LocalHere, for the same file, computes the same "file"
result slightly differently.

But as in this old version, Here gives the full path and LocalHere gives
a shortened one, as Host.FileTail computes.  local_files just caches this,
so it won't be recomputed. on a subsequent call.

I think this should give you what you want.  There are calls to LocalHere
in CG, WebInfo, and InfoThisFile, plus several elsewhere to Here.  So if
you put the Host.FileTail call back, Here & LocalHere make sense and give
you a choice at each place.

> END;
> file := local_files [fnum];
> line := offset MOD MaxLines;
> END LocalHere;
>
> There is this div/mod relationship, but I still find it wierd to use div there.
> You can see the FileTail which is maybe the change I want anyway.
>
>
> Here, yes, me:
>
>
>
> https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/Scanner.m3.diff?r1=1.5;r2=1.6
>
> Revision 1.6: download - view: text, markup, annotated - select for diffs
> Thu Feb 28 09:23:22 2008 MET (8 years, 4 months ago) by jkrell
> Branches: MAIN
> Diff to: previous 1.5: preferred, unified
> Changes since revision 1.5: +1 -1 lines
>   put full paths to source files in debug info
>
>   This has the minor downsides of:
>    1) grows the debug info (it is already huge; who is counting?)
>    2) reveals file system layout in debug info (privacy?)
>    3) does it inhibit debugging files from other people's machines or does gdb dir still work?
>
>   but definitely makes for a more pleasant debugging experience when
>   debugging stuff you have built yourself.
>
>   The linear searching to see if a name has been allocated a number yet
>    will obviously slow way down due to a large increase in common prefixes,
>    but that should be a hash table anyway. Linear search is lame.
>    (or a trie, but working from the ends of the strings, minus the last one or few
>    characters, due to common prefixes as well as common suffixes)
>
>   Note that both m3front and m3cc changes are needed as m3front has paths
>    relative to the current working directory or such.
>
>   For most packages, you can get by without the m3front change and just prepend
>    "../src/" to the path in m3cc, but that doesn't work for hierarchical packages
>    such as libm3 and m3core which I am debugging.
>
> I still believe debug info should have full paths.
> It always does on Windows for C and C++ (and this isn't a language thing).
> It didn't always but they fixed it at some point.
>
>
> But generic modules maybe something else -- like line directives and full paths back to the .mg files.
>
>
>   - Jay
>
>
>   		 	   		
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org