[M3devel] source paths to generics?

[Jay K]

Good point, and C++ systems do handle this.When you step into std::vector<char>::foo, the debugger knows that the source line occurs many places and can prompt you for which you want,or it can assume you mean the current one.
If you haven't yet stepped into it, it can prompt for which.
Now, 1) this stuff is often inlined and 2) std::vector<short> and std::vector<unsigned short>, usually end up being identical code, so you can't break on them separately. The linker does these optimization, and some compilers.Even Modula-3 is subject to this optimization -- since the linker does it.
It is *mostly* good, mostly just makes things smaller, but it also confuses a lot of people.
The linker I believe has to be a little pessimistic, like if you take the address of a function, that can inhibit optimization, lest someone is comparing function pointers for equality, which is rare and frowned upon, but is sort of in the languages. it also has to get function comparison correct, which is a little tricky, what with functions referencing data and other functions.
m3gdb is interpreting these strings I guess.
what is with the strings that have only a directory and not a file name on the right side -- in M3Header.m3.
If I make the left hand side just a leaf name, foo.m3, w/o ../AMD64_LINUX, that'll be nearly equivalent?i.e. it is assuming current directory is already AMD64_LINUX, or it is assuming src?
See, funny thing is, the current paths resolve the same either way, but if I remove "../AMD64_LINUX", they don't.
 - Jay



> Date: Wed, 29 Jun 2016 12:01:08 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] source paths to generics?
> 
> 
> 
> On 06/29/2016 04:44 AM, Jay K wrote:
> > I haven't fully verified this, but it appears for example if I debug a generic, or fail an assert in a generic,
> > the source file I am told about is the instantiated i3/m3 file.
> >
> > This isn't particularly useful for the programmer or convenient for the compiler, right?
> >
> > The programmer would rather see the .ig/.mg files, and this is easy to provide in the compiler?
> > I guess it is slightly easier in the compiler, but easy to do better?
> 
> Yes.  m3gdb does this, in many cases:
> ------------------------------------------------------------------------------------------------------------
> (m3gdb) b VarArray.mg:136
> Breakpoint 2 at 0x4073c3: file ../AMD64_LINUX/IntIntVarArray.m3 => ../src/VarArray.mg, line 136.
> (m3gdb) c
> Continuing.
> 
> Breakpoint 2, New (InitElemValue=-9223372036854775808, InitialAlloc=
>      RECORD Lo = 9223372036854775807; Hi = -9223372036854775808;  END, ExpansionFactor=1.10000002)
>      at ../AMD64_LINUX/IntIntVarArray.m3 => ../src/VarArray.mg:136
> 136	      LExpansionFactorR := MAX ( ExpansionFactor , MinExpansionFactorR )
> (m3gdb)
> 
> ------------------------------------------------------------------------------------------------------------
> 
> It has a bug though.  Setting a breakpoint to a .mg file before any execution has
> started appears to work, but the breakpoint won't trigger.
> 
> I have not looked at cases like runtime errors without m3gdb.
> 
> This does raise the question, however, that you might very well want to distinguish
> different instantiations of the same generic when setting a breakpoint.
> 
> This is a good example of where a debugger needs to have awareness of your language.
> Modula-3 instantiations, being separate compilation units and having separate
> generic and instantiation files is a model that, AFAIK, does not occur in other
> languages.
> 
> >
> > I should look into make it so?
> >
> > My real agenda is I want to see:
> >    ../src/foo.mg
> >
> > instead of
> >   I386_DARWIN/foo.m3
> >
> > I don't want the target variation, but other points seem true also, right?
> >
> > Right? The line numbers match between them, and the generic syntax is so close to "normal" that a programmer not used to it won't be confused, right?
> >
> > I'll try to poke around more.
> >
> >   - Jay
> >
> >   		 	   		
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://m3lists.elegosoft.com/mailman/listinfo/m3devel
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160629/1f3e4afc/attachment-0003.html>