[M3devel] source paths to generics?

[Jay K]

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



----------------------------------------
> 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