[M3devel] source paths to generics?

[Rodney M. Bates]

On 06/30/2016 11:11 AM, Jay K wrote:
> I put in a bunch of calls to RTIO.PutText("I'm here 1"); RTIO.Flush(), RTIO.PutText("I'm here 2"); RTIO.Flush().
>
> When I saw those I knew I missed it somehow and looked again.
>
> I still don't see the strings in the output though.
>
>   - Jay
>
>

The missing call to M3Front.ParseImports is at cm3/src/Builder.m3:2007.
It's in my previous grep output, plain as day.
I must have just missed it in all the noise.

But I'm still pretty sure the "=>" ("1=>"?) inserted by M3Header.Parse will
never find its way into any output.

>
> ----------------------------------------
>> Date: Thu, 30 Jun 2016 10:53:34 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] source paths to generics?
>>
>>
>>
>> On 06/29/2016 11:49 PM, Jay K wrote:
>>> I guess neither of us looked outside of m3front.
>>> The code runs. Not clear if the strings can get output.
>>> Maybe from asserts or Compiler.ThisFile in a generic?
>>> I"ll try some more.
>>>
>>
>> I started looking in all of m3-sys, since the different compiler
>> packages there are linked together into cm3. Later, I
>> looked in the entire cm3 repo and didn't see anything.
>> In any case, since it's part of the compiler, it really would be
>> strange to call it from outside m3-sys.
>>
>> But if it is executing, we must have missed something. How did you
>> find it executing? In a debugger? Can you do a backtrace?
>>
>>> jair:m3core jay$ grep -i parseimp ../../m3-sys/cm3/src/Builder.m3
>>> ids := M3Front.ParseImports (source, s.m3env);
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> Date: Wed, 29 Jun 2016 19:34:13 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] source paths to generics?
>>>>
>>>> Hmm. I poked around a bit, and it looks like there is some cruft here,
>>>> left over from something.
>>>>
>>>> The only call I can find on M3Header.Parse is M3Front.m3:37. This is
>>>> in M3Front.ParseImports. I can find no calls on that at all. (There
>>>> are other procedures by this name.)
>>>>
>>>> Also, it appears M3Header.ParseImports actually collects the exports, the imports,
>>>> the generic actuals.
>>>>
>>>> As for the concocted (by M3Header) name of the form <instantiation> => <generic>,
>>>> this looks to be used only to initialize the scanner's file number while scanning
>>>> up through the formals of the generic, but that is not used.
>>>>
>>>> On 06/29/2016 11:34 AM, Jay K wrote:
>>>>> There is similar code in Module.m3 and that is the code producing
>>>>> the data "I don't like".
>>>>>
>>>>> M3Header isn't dead but I haven't seen it run yet.
>>>>>
>>>>> I changed them from "=>" to "1=>" and "2=>" and looked
>>>>> where those occur in the output .s files under -keep.
>>>>>
>>>>> This is kinda something I wish were easier, like more strings
>>>>> need to be longer for easier finding w/o ambiguity (the flip
>>>>> side of my context arguments!)
>>>>>
>>>>> As things stand, I can't check that in.
>>>>> I suppose maybe with a CG.comment but nevermind.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: RE: [M3devel] source paths to generics?
>>>>>> Date: Wed, 29 Jun 2016 15:22:14 +0000
>>>>>>
>>>>>> mfront/src/misc/M3Header.m3 has this:
>>>>>>
>>>>>>
>>>>>> (* build a synthetic file name & start reading *)
>>>>>> filename := old_filename & " => " & filename;
>>>>>> Scanner.Push (filename, s.generic, is_main := Scanner.in_main);
>>>>>>
>>>>>>
>>>>>> and instantiated generics aren't what I thought.
>>>>>> I thought the build system or compiler did a textual
>>>>>> substitution of the generic parameters into the entire implementation,
>>>>>> and saved that to the file system,
>>>>>> and had the assert/debug paths point to it.
>>>>>>
>>>>>> So could step through what looks exactly like an .m3 file.
>>>>>>
>>>>>> But it doesn't. The instantiated file is a little stub, like:
>>>>>>
>>>>>> jair:libm3 jay$ more I386_DARWIN/TextAtomTbl.m3
>>>>>> (*generated by m3build*)
>>>>>>
>>>>>> MODULE TextAtomTbl = Table (Text, Atom) END TextAtomTbl.
>>>>>>
>>>>>>
>>>>>> so I have one or two proposals.
>>>>>>
>>>>>> 1) old_filename above contains the target, it looks like:
>>>>>>
>>>>>> "../I386_DARWIN/TextAtomTbl.m3 => ../src/table/Table.mg"
>>>>>> or
>>>>>> "../I386_DARWIN/TextAtomTbl.m3 => ../src/table"
>>>>>>
>>>>>> These both occur.
>>>>>> I'm not sure what the second is, seems like a mistake.
>>>>>>
>>>>>> I suggest the first string in both pairs be changed to be the leaf element, like:
>>>>>>
>>>>>> "TextAtomTbl.m3 => ../src/table/Table.mg"
>>>>>> or
>>>>>> "TextAtomTbl.m3 => ../src/table"
>>>>>>
>>>>>> and maybe the second string in both cases should be as it is in the second pair.
>>>>>>
>>>>>> 2) Possibly it should reall just be:
>>>>>> ../src/table/Table.mg
>>>>>>
>>>>>> and developer can step through that, knowing that it is a somewhat abstracted
>>>>>> form of what is running
>>>>>>
>>>>>> I'm willing to do this under like:
>>>>>>
>>>>>> CONST TemporaryForTargetConvergence = TRUE
>>>>>>
>>>>>> or
>>>>>> VAR TemporaryForTargetConvergence: BOOLEAN;
>>>>>>
>>>>>> and a command line switch, but I suspect it isn't really useful to anyone asis,
>>>>>> so might as well remove target unconditionally.
>>>>>>
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Wed, 29 Jun 2016 09:44:51 +0000
>>>>>>> Subject: [M3devel] source paths to generics?
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>   		 	   		
>

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